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.