This is a follow on article to my report on the Sylvania Netbook and based on the fact that I bought a Flytouch IPad knock-off tablet. This is what I have found out about the tablet and since all the information is spread accross several chat groups it seemed appropriate to do an article to try and get the data in one place. Another problem with the current data on the tablet is that most of the chat information is from people with little experience or as you will - "nu-bees" and thus there is lots of missing data because of it. I will try and gather it up and see if I can't clarify some of it.
First up is the unit itself - there was an early pre-production unit and the current unit like what I have. I have seen some reviews of the pre-production unit and they were less than flattering - pretty much a don't buy. The current production units, or at least the one I got in November of 2010, work well and has only a few problems to contend with. The pre-production unit has no symbols on the case end where the power and dongle connector is located. I understand that this model's dongle is 30 pins and has the USB ports facing the power connector and thus it is USB or power not both. The current version has a 24 pin dongle that has the USB ports covering the SD slot and thus is only a problem when load or unloading the SD - unplug dongle first. I understand there are differences inside the unit and the pre-version will display WMT1.9_90, while the current one is WMT2.0_105.
Now in reading some of the chat groups, it appears there might even be an official verion "II" that is more recent than mine with an updated CPU. However it is hard to know for sure if they are refering to pre-production and production units instead. These units are flooding the market and it seems that most of the reviewers and chatters are new to the whole concept and toss around terms without a lots facts or indepth work. Let me say and complement those few who have done and are doing their best to clear the matter up. You will find people like "projectgus" who are doing their best to keep up with the issues, but new models are coming fast and furiously from China almost daily- making this a difficult probem for the best of us.
I guess a first and very important point to cover for most people is a simple what can be done with the units. These samll units, both the netbooks and the tablets are simply big brothers to cell phones and are not in anyway comparable to a standard x86 laptop or the more expensive and real IPod units. All of those units run expensive power hungry devices with lots of memory and hard drives. These units on the other hand are smaller, lighter, simpler, and right now, rather cheap. Thanks to lots of work on the part of others, it is also possible to put other versions of an operating system on them. My interest in both the netbook and the tablet is for doing industrial control sorts of projects. Let me explain and give you an idea about their limits.
I have been working on a project to design a solar based control cabinet that would house all the needed equipment to provide power for remote or emergency sites. What I wanted to do was provide a control panel and display that monitored the equipment and power usage with a display something similar to what you see in the Prius automobile. The prius unit has a touch screen that has several menu keys to select the type of display and make changes if needed. I want the similar ability, yet I do not want to do a custom design as was done with the prius. The netbooks and tablets is cheap enough seem to match the design concept and cost limits exactly.
Can these units work well as regular laptop systems - barely. The CPU is only 300mhz, you have only 128 or 256 MB of ram, and 2GB of flash drive for system storage. Now it is true that a typical x86 system file system would be 3 to 4GB, while these units can provide the same abilties in half a GB or less. ARM files seem to be rather smaller than x86 files of equal abiltiy. So we can get similar abilties in less size, but overall the performance is less than ideal. Part of that problem is the normal user expects to do lots of graphics and run movies and such. These units are both small and slow doing intensive graphics. However, limit the graphics, do mostly terminal entry and run limited number of programs and they work just fine.
You can see my netbook working as a web server by following the links below. I ran into some problems in that one of my USB devices produced clearly bad data on the netbook, yet works fine on a x86 machine. I found Apache2 problems and suspect there are many little difference that could cause the average user all sorts of problems. For dedicated uses and when experienced developers take on these units, I expect over time we will fix many of these problems or find solutions. My ccii_15 is an article in development based on that just that need to fix data collection using the netbook.
One of the first things you need to understand is how the computer is put together. From taking my netbook apart and seeing pictures of the flytouch apart, all these units are pretty much done the same way. My guess is that WonderMedia builds the daughter boards and the completed product is designed by - in my case - Gnome and assembled into a working system. The daughter board means that almost all the units will have the same cpu/memory design, but all the I/O can be different and in most cases will require different drivers to work. The WiFi is a good example where different vendors put different WiFi daughter boards and thus need a matching driver to make them work. Graphic is also different with some using touch screens and netbooks using builtin keyboards and touch pads.
I tried using the "foyo" android improvement but was unsucessful. I hunted around and it appears that there is an issue with the cpu that will prevent WM8505 chips from using the android version above about 1.9, with some luck getting 2.1 to work. I suspect it is a combination of things and not just the cpu that is preventing upgrades. In using the android OS, I was less than happy doing so. Some of that is from the fact that I am an old hand at linux, and do almost all my work using the command line. I saw severel comments about the nature of the flytouch screen design thatg says it is not very good. Using the screen proves those comments, as it is a bit hard to make work all the time. I found it necessary to "tap" the screen more than once before it will accept command and do something.
Now my usage is low on the touch screen and more focused on getting the unit to work remotely as well as being able to display graphic data of a limited type and nature - i.e. charts and graphs, but not movies. I had considered trying to figure out how to remove the java layer of the android system and work with the debian kernel. I started searching the web and found what I was looking for instead. It is called the "debian-flytouch-v0.3.img" and took some time to find. This image is intended to be used on a linux system with "dd if=debian-flytouch-v0.3.img of=/dev/sdc" where "if" stands for "input file" and "of" stands for "output file". You probably need a 2GB SD device that has not been pre-formatted, as "dd" will overwrite the entire device with new data. The "/dev/sdc" is the whole SD device and may differ on your system - use "cat /proc/partitions" to see a list of all the partitons the system knows about.
I don't like this process at all, as it overwrites the manufacturers data on the device. Each manufacturer puts various bits of information that defines the type of SD device and sets some parameters for it's use. Changing those can infact make some chips totally useless - I know since I had it happen some time ago. What really needs to be provided are the file tree structures, typically in a "tar" or "zipped" format for each of the required partitons on the device. By doing so, you also allow people to edit, change sizes, and see what is going where. The img is of a 1GB device, yet when broken out the two images can be put on a 2GB device very easily. This is a side effect of people with limited experience doing this work - you can get poor or just bad advice if you get any at all.
It is rather important however that I make sure everyone knows that I am, and I think a lot of people are, very happy that these people did do the initial work. I will later review the steps to do it correctly, as well as provide the needed tar files. It would not have been possible for me to do these upgrades with out other people doing some of it first. I know all the data is out there, but putting it in one place can be a real problem. For now you can do what I did and that was, do dd to a 2GB SD device, then copy the data out of the device on to your file system, format a different 2GB device with say 64MB vfat (/sbin/mkfs.vfat) and the rest as ext2 (/sbin/mkfs.ext2) ( do /sbin/fdisk /dev/sdc to set partitons first). Then you can copy the file system on to the new device and you are ready to go. I believe the need to do a "img" was for those using windows, but if your going to use linux on the machine, you really need a linux workstation to support what you do and help you learn the inner details of linux. Keep in mind that if you use windows, you will need to find numerous tools not available normally on windows.
It is time to repeat a known issue with SD devices and Uboot. Uboot is the ARM embedded BIOS and boot tool used on most all of these devices. The last I checked, the Uboot version is 1.4 ( which seems to be the normal version used ) does not support 4GB and above devices. The 4GB devices use a different format for storing data and as such the Uboot can not read that format. When working on the atmel gateway server demo board, I had limited luck formatting larger devices with smaller partitions, but it is much simpler to just use 2GB devices to boot from, as once booted most of the linux systems will then be able to read larger sizes. Please note that it is getting harder to find 2GB devices and as such you should stock up on them before they are all gone.
Let me say right off that the debian port is just great! It seems to have just enough graphic tools to get things going, yet it is not overloaded with tons of extra stuff. The only thing I find curious, is why it keeps needing to do "fsck" of the file system when starting it up for the first time. My other debian SD driven setups don't have this issue. I guess over time I will find out the reason, but for now, just let it do the fsck and reboot and all will be fine. I am also happy to report that it was able to read and write to a 160GB USB hard drive I used to unload the internal flash to. I suspect with a little tweaking I can have this code running from the USB hard drive as well ( I am now using the SD+USB method on my netbook during development).
I have done both the "dd img to SD" and the "SD to file to formatted SD" and they both work fine. I used the dongle for both keyboard and mouse, and USB drive and mouse with great success. I even used the on-screen keyboard for several operations. I used the wifi setup tool and got my wifi to work - although some users will be puzzled by the questions and might have to do some digging into how their network is setup. All the questions ask for IP addresses and so you will need to know what IP you want the unit to have, gateway, dns host ip, that sort of stuff. My units wifi works very well and I was able to do an apt-get, but it failed on one of the update sites for some reason.
I do all my work remotely and so after getting the wifi working, I was able to connect using ssh. You will want to change the "root" password to one of your own choosing - do "passwd" from the command line ( run the terminal session and follow the prompts). After doing that you can do a "ssh root@new.ip.of.tablet", and after entering password, you can now do all you work from your workstation remotely. This frees up the two USB ports as you don't really need them when you do all your work remotely. This allows you to do cutting and pasting from one screen to another, as well as copy data from the remote to local files on your work station. I tried the "sftp" command but it failed for some reason - I suspect the full shh tool set is not loaded. For windows users you will need to add "putty" for the ssh functions.
I have been doing some more work on the debian port and discovered a few problems and the possible solutions. I think the problem with the fsck happening is based on the clock setting of the table when it boots up. I was trying various ext2 systems under the SD+USB option and was seeing some pretty odd action. If you look at the long listing of the "/var/log" directory, you might see a date of "2016" instead of something current for the boot log file. This file is created at boot time before the system has a chance to do a ntp lookup and set the system clock correctly. The date time is obtained from the hardware's rtc device and is typically reset when the system goes down properly.
I did some looking around and found in the "/etc/init.d" a couple of "hwclock" scripts, that I assume would set the clock properly. When I ran one of the them, the system locked up and required a power reset. I did some searching of the file system for "rtc" and "clock" and got nothing. I looked at the list of android files and pulled a blank as well. I also checked my netbook and found there a "wmt-rtc" program. I had noticed before that the tablets debian is using squeeze and not stable as the update verison for apt-get. I did try a squeeze update on the netbook to only have it lock the system up. I ran the "hwclock" utiltiy on the netbook, only to have it return an error and not lock up. From that I assume the squeeze version of the hwclock routine is not working properly yet - as the squeeze version is still under development.
I copied the "wmt-rtc" program from the netbook and used it on the tablet and was able to get the correct time set. You can tell that when it boots and looking at the time stamps on the files in the "/var/log" directory. I have this now in my ext2 setups and am no longer bothered by the "fsck" on boot. At this point I can not recommend using squeeze, as it is not an official stable release. You can continue to use squeeze however, if your willing to hunt down the now rare problems that might crop up. I say "rare" since the release is in the last bit of testing and should be officially release sometime soon. I feel however, that support for things like the ARM system, is probably low on the list and apt to be one of the last to get fixed. Thus you might see a few more problems crop up with ARM, than with x86. You have been warned. By the way here is the correct command to set the rtc after your system clock is correct - "/sbin/wmt-rtc --sys2hw".
I might add here that one option you have, if you left android on your tablet, is simply to boot back into android and let it set the clock properly. Then your first boot will have the correct time. However if you re-boot into debian again, you will find the clock set to a value 4 or 5 years ahead. It seems to push it ahead everytime you reboot and thus only makes things worse. I modified the files "hwclock" to "hwclock.old" and thus they are no longer being used and causing problems. You might consider the same. For now everything else does seem to work as adveritsed.
While talking about discoveries, I took apart the housing of the dongle, and discovered that it has four pins marked "3v,rxd,txd,gnd", which means the serial port for talking to it while it boots up - or talking to Uboot directly - is actually on the dongle. This means you can talk low level to the unit using the dongle without opening the unit. I would guess that the units are setup by hooking up the dongle during manufacturing and downloading the software into flash that way. So if you want to do low level interfacing, just solder pins onto the dongles serial pins and away you go. A little simpler than I would have thought.
In conclusion let me say that the tablets seem like good units, but just not what I am looking for. My original task was to find a unit that would display data about the solar arrays output and overall performance, much like a prius displays driving stats. These unit do have a touch screen, but mounting them and getting the signals into and out of them is not ideal. I think what I am looking for is a combination of the netbook and the tablet or something like the current group of cellphones that have a sliding keyboard. My concept is something like this: a touch screen that faces out, but under it is a keyboard, but more importantly is that all the signals and power is suppled through a connector on the underside and thus when mounted hidden.
I recently got my son a new cellphone and he picked one of the clam shell styles, where the phone normally is just a touch screen. But giving the screen a push and it slides up and exposes a keyboard. I would like a netbook just like that, but with a docking feature much like what comes with full size laptops. Most current laptops have an optional docking station that the unit can be connected to that has power, network connector, and several USB connectors. I would like the same, but in a 7 inch size and at the less than $100 price range. My flytouch is close, as the dongle does most of what a docking station does. I suppose you could use a right angle extension cable and have the actual dongle behind the mounting panel, but it would be nicer if the connector was in the back and thus hidden when mounted.
At the moment I am not sure how I am going to use the tablet, as the netbook is better suited for what my needs are. I suspect over time, I will find another solution that better matches my needs. However, the tablets do provide some features that work well and can meet a part of my long term objective. If nothing else, these units show that the choices are getting close to meeting my specific needs. I found as well, that installing linux and using them turned out to be a simple process with few problems.
Bill.
Till then enjoy!
Links
The SYNET07526-R on-line - see web pages from the netbook.
VIA8505_WMT2.0_105.zip - In case the android system gets corrupted - use this to restore to orginial.
ext2.tar.gz - updated ext2 with proper permissions and date settings.
flytouch.tar.gz - the files in fash -android system files.
latest.tar.gz - latest version of ext2 with current patches.
vfat.tar.gz - standard vfat for use with ext2 on same SD device.
vfat_usb.tar.gz - vfat that will load the ext2 from USB drive - not SD device.