Linux Console Via Bluetooth

These days, I find myself hacking, reverse engineering, whatever, several mobile devices that run Windows Mobile. A really great tool that I've started using is called HaRET (Handset Reverse Engineering Tool). In most, it's necessary to get terminal access to them in order to perform low-level debugging. Sometimes, a mobile device will have Linux USB OTG support without any hassle, and I can use the g_ether kernel module to bring up usb0 as a network device at boot time, assigning a static IP address. Then, by using usbnet and other kernel modules on my workstation, I am able to communicate to the mobile device using telnet or ssh. Great!

However, in many cases, USB OTG does not work "out of the box". Furthermore, given that the LCD rarely ever works "out of the box", that leaves me with very few options for getting any type of feedback from the mobile device at all, aside from maybe generating morse code with the vibration unit - that's a joke... please believe me.

It's very necessary to have terminal access, or ICE access, to perform low-level debugging when porting Linux to a new mobile device. One option is to find unpopulated pads on the PCB, where a UART has possibly had pins brought out, and to solder some wires directly to those pads and create the appropriate level-shifter circuit, attaching an RS232 cable to the workstation. Another possibility is to use the JTAG port. In some cases, neither of those options will work because either a) the pins have not been brought out,  or b) the JTAG port has been fused (See my previous opinions on Fusing the JTAG port). In many cases, there is a debug port on the board, with an unpopulated header. Finding the appropriate header and FPC cable is sometimes possible, but in many cases it's like looking for a needle in a haystack. Luckily, I found that needle in my last reverse engineering project, and fabricated a small PCB to bring out the pins of the FFC connected to the UARTS of the embedded device.

When I don't find that needle, then I'm left having to do some very creative reverse engineering. My suggestion: Why not build a small daemon into the kernel that would actually bring up the system console over bluetooth? Most, if not all, mobile devices manufactured in the last decade have bluetooth hardware directly connected to one of the UARTS. I can't imagine that it would be terribly difficult to build something like this into the kernel. My only main concern would be missing valuable information that the Linux kernel spits out at boot time. To counter that, I would probably introduce a "consoledelay" boot parameter, that functioned much like the "rootdelay" boot parameter. Such a boot parameter would allow the underlying hardware of the console to initialize before performing any IO on it.

If anyone feels like funding me to build this into the kernel, I am very open to suggestions :)

Bundled Libraries in XBMC and Boxee

Recently, I became interested in building Boxee and XBMC and so I wrote up a quick ebuild, as I usually do with packages that I like to build. Incidentally, this happened on the same day that Mike Frysinger (a.k.a. vapier) submitted the media-tv/xbmc-9999 ebuild to the portage tree. A couple of bugs quickly arose, namely #198849, in which there was mention of this post by Diego (a.k.a flameeyes) where he warns about the use of bundled libraries.

Now, first of all, the term 'bundling a library' refers to the act of taking a snapshot of the source code of an open-source library, e.g. a jpeg library, and building it in to a separate application. While the separate application is in development, the original source code branch of the jpeg library could evolve and it could cover up vulnerabilities, etc, while the snapshot of the jpeg library used in the application is not updated. Bundling libraries is essentially 'forking' the project. Diego mentions that there are several reasons not to do this, including security reasons.

However, my main argument against bundling libraries, is that

bundling libraries makes tracking changes very, very, very difficult!

New applications may very well feel that it is necessary to bundle applications at the beginning of the project to avoid breakage due to API changes, and that has some merit. However, I would like to stress, that one of the initial goals of a new open-source project should be to remove those bundled libraries, and isolate which versions of external software packages are required. When that is done, changes can be made much, much easier and incrementally, making only tiny ripples in the 'dependency pond' as opposed to large waves.

When a project gets to be as large as Boxee, having a dozen or more bundled libraries, at a point in it's development cycle that is so close to a major release, the job of reducing and upstreaming the respective changesets of each individual bundled library becomes enormous. I can say, honestly, because I am currently packaging both XBMC and Boxee, is that it is ugly, and I don't want to be stuck with the job of committing upstream changesets. Furthermore, XBMC / Boxee will not achieve an acceptible, stable state in the portage tree by Gentoo (and potentially other distros) until they stop bundling libraries.

My advice to the maintainers of these projects is to 'prune' their trees one-bundled-library at-a-time. Please help to reduce package maintainer headaches.

Fusing the JTAG port

One thing has really been dwelling on my conscience since I interviewed with a certain mobile device manufacturer. They disclosed something to me which could very well be common practice for a large part of the industry, but really shouldn't be.

For those unfamiliar with JTAG, it's a programming / testing methodology for highly integrated circuits and chips on a circuitboard. Essentially, JTAG is a software-controllable circuit probing method that goes where hands cannot. Manufacturers have used it for a long time to mass-program their mobile devices. All of phone's firmware can be programmed at once through this interface, even if that firmware lives on multiple chips.

However, some chip and mobile device manufacturers have taken it upon themselves to actually fuse the JTAG port, so that once it's been programmed, that interface can be burned - made permanently, electrically disconnected. While this is good on some levels for security purposes, it has the awful side-effect that the device can never be re-used or refurbished. When a device can never be reused or refurbished, it often ends up in the scrap heap, just like billions of other mobile phones.

Aside from restricting the owner's freedom to do as he or she whishes with the mobile device, the Free Software Foundation would also term such manufacturing practices as 'defective by design'.

Google Genealogy?

I guess because I became a dad about a 9 months ago, I'm experiencing an even larger curiosity of the origins of my forefathers. So today I created the beginnings of Julien's Family Tree, but spun a different approach on it. I used Google Maps.

If you create a Google account, you can actually have a 'My Maps' section on Google Maps. On Julien's Family Tree, each person is represented by a placemark where that person 'grew up', and each line represents a parent / child relationship. Every placemark has a comment associated with it, in which the birth date (and possibly death date) of each ancestor appears, along with comments about the life of that person. Google Maps also lets the user put links to Wikipedia info, photos, et cetera.

What would be really cool, would be if some clever web developer were to integrate the Google Map API, some AJAXy glue code, and a database.

Having directed line segments joining parent and child would be useful. You could graphically see the journey that your ancestors made throughout their life, with fairly accurate historical info one click away at the Wikipedia. Maybe it would be possible to have a dynamic application built to scan the Wikipedia and narrate based on a combination of historical info and per-person tidbits.

I love hearing the stories that my grandparents tell me to this day - they're full of thrills and drama. Every grandparent should have a book or movie created about their lives, in my opinion. I'm really glad that Julien met his great-grandparents. I sometimes wish that we lived around the block, so that we could hang out every day after work ;-)

ZFS at Home

The days are gone, when the average consumer only required reliable data storage at the office. Today, many people need reliable storage at home for everything ranging from digital media, to tax and business records, or massive data sets for research. In my case, I work mainly from home, and using the remote storage at my office is sometimes a slow and painful process. Also, my wife is in the middle of a PhD and she is constantly working with several versions of data sets that each span several hundreds of megabytes. Both of us, on the other hand, would love to have a Home Theatre PC (HTPC), to play audio, view our photos, and watch video from a central location.

That being said, reliability is not the solution to end all problems. Data can be lost by a simple overwrite, which is more human error than anything. Luckily, the clever folks at Sun Microsystems have taken human error into account and have designed a filesystem with versioning for each file. This allows the active version of a file to be 'rolled back' and also 'rolled forward'. The filesystem is called ZFS.

ZFS is a filesystem that works very similarly to Apple's Time Machine, although I'm not sure which came first. Unlike Time Machine, ZFS scales from 1 disk to many, but works best under the same conditions as RAID. Like RAID, ZFS will take advantage of having several physical hard disks pooled together, but unlike RAID, ZFS goes a step further and periodically takes a snapshot of your files. This positions ZFS and Sun Microsystems at the forefront of the market for data storage. Using ZFS, a snapshot only takes a fraction of a second for tens of gigabytes of data, and it doesn't necessarily increase the amount of disk space substantially, by clever use of file deltas.

Now, if Sun Microsystems, or any OEM reseller, really wants to make money, what they will do, is develop a 4-disk network attached storage solution using ZFS for the home. The network attached storage (NAS) system could be easily powered by Solaris, FreeBSD, and (hopefully soon) Linux. It could provide a nice web interface for management, with the familiar CIFS (windows file sharing) which works across all operating systems.

However, in order to really harness the buying power of the general consumer, the reseller should also provide a network API and tools so that home users could take advantage of the Time-Machine-like features of ZFS, but from the comfort of their own desktop or laptop. That means, having a windows-explorer-like application, where the user can easily navigate to their file of choice, right click, and have instant access to choose which version of the file they would like active.

Now, because there is the possibility for having several networked users accessing the same file, at the same time, but with different versions, it might make sense to have

a) simple file locks
* only one version is active, and in use, at one time by any user
b) or per-user versioning

I would suggest going with option 'a' for simplicity's sake. In the end, several users at home can back up their digital media and important documents at an easy-to-use and well integrated centralized location, without fear that they could lose their data, and also with the added benefit that they can use a copy of that data from any point in time.

Here is a small table containing typical use-cases for the general consumer.

File Type	Importance
	Reliability?	Versioning?
Media (Audio/Video)	Yes	No
Media (Photos)	Yes	No
Business Documents	Yes	Yes
Tax Documents	Yes	Yes

As you can see, versioning is quite important, but most people will accept nothing less than reliable storage. If we were to make a use case for people who work with multimedia, then versioning also becomes very important.

This clearly translates into sales for any company that can implement a ZFS NAS for the home user, including management software. It does go against the current trend of the big players to migrate toward cloud-computing, where all of the end-users' data is isolated somewhere on the remote network. Realistically though, many people like to have direct access to their data with very little delay. Several latency issues would arise if cloud-storage were to be used for all digital media, which also supports the business model for having ZFS at home.

If anyone feels that this idea has some merit, particularly from Sun or any OEM of NAS equipment, then please let me know - I'm open for business.

DIY Surface Mount Soldering

There are really only three DIY SMT soldering techniques that I am aware of

1) fine-tipped soldering iron and magnifying glass
2) a toaster / reflow oven
3) a reflow hotplate

However, if one needs to solder a BGA device, then the latter two methods are are the only ones possible.

I just thought I would post links ot a couple of interesting articles I found on techniques 2 and 3.

DIY techniques can save you literally thousands of dollars - I've seen reflow ovens for sale for over $2500 and reflow hotplates for over $1200 !

I also just thought that I would mention, that it is possible to use a regular computer or laptop as a PID controller, if one connects uses a solid-state relay for current control of the toaster / reflow oven, with an accurate temperature sensor.

There's also a great tutorial for applying solder paste to a PCB with stencil . Always check whether or not the BGA solder balls contain flux - in many cases they do not, and you should apply a bit of flux to the PCB before baking it.

SRF02 Ultra-Sonic Ranger and Linux

Hi everyone,

Recently I've been working on a project that requires the use of an ultra-sonic range detector. The sensor works by emitting an ultrasonic chirp at approximately 40 kHz and timing the delay before the sound wave bounces off something and an echo is received. Given that the speed of sound in air is fixed for a specific humidity, temperature, and air pressure, the SRF02 is able to accurately determine the distance a wavefront has travelled using its built-in microcontroller. The built-in timer feature means that a host computer does not need to constantly poll the sensor to see if the echo has been detected, which saves resources (cpu bandwidth, interrupt, timer, etc) in the long run.

I thought I would post this, just in case another engineer needs to interface with the SRF02 sonar device, using the USB_I2C module from DevanTech.

The USB_I2C module is currently not supported in the Linux kernel as an I2C adapter, but it's easily accessible from userspace through the /dev/ttyUSB0 node. It's very similar to the TinyI2C USB adapter here, but connects using an FTDI chip as opposed to an Atmel controller.

Originally, I saw some example code from Kevin Nickels which seemed to provide the only readily available app to interface with the SRF02 under Linux. It was fairly legible, but still a bit scattered, so I thought I would provide a really simple app written in C for people to test out their units with.

Binary

Source

The USB_I2C is not very well documented, and I found that when reading multiple registers, it would prefix the data with 0x01 and suffix it with 0x00. This meant, for example, that reading all 6 registers of the SRF02 sequentially, actually requires 8 bytes of storage.

int fd;

unsigned char sbuf[8];

...

read(fd, sbuf, 8);     // sbuf should read { 01, 05, 18, 00, 19, 00, 10, 00 } (in hex) 

                       // 01    := prefix
                       // 05    := revision 
                       // 18    := 'unused' register
                       // 00,19 := high / low byte for range          (25cm)
                       // 00,10 := high / low bytes for minimum range (16cm)
                       // 00    := suffix

Please read the source code for more info, and also check out Kevin's work. My future work with this device will include JNI code and Java class for easy interfacing. It would be nice, of course, to have a kernel module for the USB_I2C adapter from DevanTech, as well as an I2C client (device) module for the SRF02, but my early attempts with that show that there is some friction between Linux and the DevanTech I2C code. However, I'll likely end up submitting some kernel source for this eventually after initial work has been done and my project is out the door.

PS: Thanks Kevin for your example code.

Android on the EEE PC

I have to admit, since the first time I saw it on android-porting, that people were talking about porting Android to x86, I was very skeptical.

Then, apparently one of the engineers at Google confessed on the list that there actually was an x86 port that someone had been working on internally (not the Qemu-based emulator, but a full-fledged port).

Now, as it turns out, a couple of people have actually run Android on the EEE PC 701 !!

Personally, I probably wouldn't put this on my own EEE, which currently runs a heavily tweaked version of Gentoo Linux, but maybe on Erin's :)

A couple of things will definitely need to happen first though - one is full browser integration, with a flash player, adobe pdf reader, etc, and the other is an office suite. On an x86, like the EEE PC, the best bet for the office suite would be OpenOffice.org but it's very unlikely that Google will port OOo to their framebuffer-driven UI, especially considering that they have their own network-based office productivity suite. If Google's office suite was available as a stand-alone app, or a Dalvik appication, then I could see Android on the EEE and potentially other MIDs.

The people responsible receive an A+ for novelty though :)

Shape-Writing or "Swyping"

Shape-writing, or "swyping" (instead of typing) seems to be the newest trend among touchscreen enabled devices. Of course, along with any new idea comes a slew of conflicting software patents that were accepted (where else?) at the United States Patent Office.

I believe that Apple, the original T9 creator, and Shape Writer Inc each have patents for what is essentially the same 'technology'. Please humor my quoted use of the word technology, because I am one of several billions of people who do not believe that software (which is what this is) should be patented.

This technology is very interesting in that it uses 'intelligent algorithms' to determine what word the user is trying to write. I thought that I would outline the fundamentals of these intelligent algorithms, just in case anyone in the FLOSS universe would like to implement them for a fun project in their spare time.

First of all, let's define the path that the users' finger or stylus traces on the touch screen. There exists 1) a starting point, 2) a finite number of 'corners'. If we assume that such a trace or path lies atop a coordinate system, for example, the imaginary plane, then the sequence of 'corners' simply become ordered coordinates in the complex domain.

Let's use a box, for example.

[ (0 + 0j), (0 + 11j), (11 + 11j), (11 + 11j), (0 + 0j) ]

The above set of ordered coordinates traces a box, starting at the origin, and continuing clockwise. The area of the box is (11x11) units squared.

In fact, the sequence of ordered coordinates comprimises a signal in the complex spatial domain (i.e. a 1-D signal), and as such (making several rudimentary assumptions), it can be mapped to a different coordinate space (the frequency domain), using the DFT (discrete fourier transform).

The most interesting part of this, I find anyway, is that taking the IDFT (inverse discrete fourier transform) of the 0-frequency component of such a signal, actually the 'mean', results in a single point lying at the geometric center of the box (i.e. the center of mass). Furthermore, the IDFT of the first two components result in a ellipse containing all points defined in the signal. As one would expect from summing successive components of a fourier representation, IDFTs of the next successive components result in a shape that increasingly resembles the original signal (i.e. a box).

It's pretty cool, at any rate. I had a lab excercise in Grundlagen der Geometrische Signalverarbeitung (Introduction to Geometric Signal Processing) in my first year at Uni-Kiel, which used a Christmas tree as an example.

In any event, if you define several points of interest in the complex domain, by overlaying the center-points of an on-screen-keyboard, then by careful application of Z-domain filtering, it's possible to determine the exact word that a person is trying to 'swype'. The Z-domain filtering is linear, and also unfortunately non-linear in nature. Why? Well, if you consider that corners represent signal components, then if a letter included in the signal just happens to be underneath the path, where no corner exists, then it's as if a component in the signal has been 'lost' during 'transmission'. It's as if higher frequency components are actually filtered out, so the 'intelligent' part of this algorithm is trying to associate a signal with another signal containing higher frequency components. This can be done, for example, by maximum likelihood or MMSE methods.

Alternatively, given a large enough sample group of input / output pairs, this problem can be solved quite easily using a lexicon or word association database. Given a path with a certain number of components, or corners, one should be able to do a very fast search to look up associated words in order of decreasing probability.

Ta Da!

I'm fairly certain that this 'technology' will be implemented in Android. However, I would also like to see it in the OpenMoko project.

Maybe such an app has already existed in the open-source world for some time. If not, or if anyone would like to volounteer to write such an app, then I would be very open to further explaination. Just submit a comment below.

Update (20100412): It appears that Samsung has integrated the idea of 'swyping' into Android on their new(ish) Galaxy S devices, as you can see from the video below. Very Cool.

Triple Booting the Neo FreeRunner

Hi everyone,

It's been a while since my last post, so I must apologize for that. Things have been very busy since November.

However, as some of you may already know, I was also experimenting with the Android operating system on my FreeRunner directly after the source code was released. In fact, I was arguably the first person to compile Android for the ARMv4T architecture. Thanks to the work of the community, it is now possible to run Android on the FreeRunner using KoolU's sources.

The private Android repository is to be merged with the official public repository sometime in Q4 2008, while the first release featuring an on-screen-keyboard will be Q1 2009. The areas I would like to concentrate on are WiFi, and Glamo improvements.

In any event, I'm currently triple-booting the FreeRunner with the latest OM image (or FDOM image), Android, and Gentoo. I'm planning using the Gentoo install for debugging things that will eventually go into the OM and Android images.

I'm using an 8GB uSD card with 4 primary partitions:

/dev/mmcblk0p1: MokoData (vfat) 5 GB
/dev/mmcblk0p2: AndroidData (ext2) 512 MB
/dev/mmcblk0p3: MokoRoot (ext2) 512 MB
/dev/mmcblk0p4: GentooRoot (ext2) 2 GB

Android is of course installed to the 'rootfs' partition in nand flash. MokoData contains uImage-android (from Sean McNeil), uImage-2008.9.bin, and uImage-2008.12.bin - the latter two are official OpenMoko kernels. I've updated the nand boot menu so that menu_2 boots OM 2008.9, menu_3 boots Android, and menu_4 boots Gentoo.

At some point in the near future, I'm hoping to create a torrent so that the configuration can be downloaded and shared by everyone in the community, but you may have guessed that Free Time(TM) is limited these days.