Android ARMv4T Donut Patch (revisited)

Several people have responded to my previous ARMv4T patch for the "Donut" branch of Android, and have provided excellent feedback.

I recently checked out the code again, and thought that it would be wise to do some rigorous testing of all native binaries on the Android filesystem.

Please find an updated (but still incomplete) patch for ARMv4T here.

I've thrown together a small script to disassemble and check binaries for invalid opcodes. You can find the output here.

The output shows which executables and shared libraries still have non-ARMv4T machine code, and currently only 103 of 160 components pass the test. Therefore, there is still quite a bit of work to be done. For the remaining 57 components that fail, the illegal (non-ARMv4T) opcodes are also revealed.

NB: Just in case you find diffs generated with 'repo diff' just as annoying as I do, you can use this utility to automate the patching process.

update-20091215: The build system is doing "ok", but its still not perfect. Independent of compile-time issues are, of course run-time issues. The most major issue is the subject of dynamic code generation and you can read some of my thoughts here. To address the issue, I will be working with the android-on-freerunner people. For any further discussion about this topic, I suggest you join the android-on-freerunner mailing list.

Google Chrome Beta on Gentoo Linux

I had already tried the Google's Chrome browser (the developer edition was called Chromium) and thought it was great, aside from a few minor bugs. For  example, sometimes drop-down lists would not have any entries, the menu for the flash plugin would not respond, etc. It looks like yesterday, Google released a beta version for Linux that fixed several of the minor bugs that I noticed.

I modified an ebuild to download an install Chrome from the debian package. In any event, you can put it in your own portage overlay under www-client/google-chrome-bin/, and it should do the trick. You might have to add 'www-client/google-chrome-bin' to your /etc/portage/package.keywords file. To install Chrome, just run PORTDIR_OVERLAY="/path/to/my/portage/overlay" emerge -av google-chrome-bin.

Overall, the Chrome experience is quite good. It's very fast, and I haven't encountered any errors or bugs so far. Most pages render perfectly. You might also want to install FlashBlock.

Dalvik VM Internals

To anyone who is interested in Android, I would highly suggest that you check out this video if you haven't already, called "Dalvik VM Internals".

The video was probably published a long time ago already, but it shows just how much work went into the Dalvik VM by Dan Bornstein and others who worked on the project with him. Particularly, it really explains why it's necessary to think how code will be executed on a machine, even when writing in a high-level language such as Java, which is something C++ gurus have also been emphasizing for years.

Luckily, I do most of my work in C ;-) but I do periodically try to rewrite chunks of software in lower-level languages to mitigate certain overhead. That would involve, for example, converting pure Java or C++ image processing code to C or ASM. The topics covered in this Video do a good job at explaining ways to implement the features of higher-level languages essentially in machine code.

Very good presentation.

Alternative Browsers for Linux

All I can say right now is wow. Having been a long time user of Firefox, it's been a while since I last used a different browser under Linux... well... because there really weren't any better alternatives for a long time.

However, since webkit-gtk has been stabilizing lately, I decided to check out a couple of alternative browsers that were mentioned in the Linux Browser Shootout - namely Midori and Epiphany. I already tried Chrome (Chromium) a while ago and was quite impressed. What I really liked about Chrome was a) that it was blazingly fast, and b) that it did a great job of importing my Firefox preferences and bookmarks. There are still a few other issues with Chrome though. For example, some Flash functionality does not work properly. I'm sure that will be sorted out eventually.

So anyway, on to the good stuff. Most people are familiar with Epiphany (formerly Galeon) when it used the Gecko rendering engine (from the Mozilla project). Epiphany is the official browser of the Gnome desktop, if I'm not mistaken. Back when it was based on Gecko, it was good but just seemed like a less featured version of Mozilla or Firefox. Ever since they changed the default rendering engine to WebKit, it has been blazingly fast. Epiphany still suffers from having too few preference settings for the 'advanced' user. Also, when in full screen mode (which I tend to use frequently while browsing on my EEE 701) there is an annoying button at the top-right that says 'Leave Fullscreen', and it doesn't go away (until you leave fullscreen), which becomes bothersome when trying to actually view / click something that is underneath the button. Epiphany accomplished its goal of providing a very simple and easy-to-use browser for the Gnome desktop, but it really lacks appeal for advanced users.

Next, I tried Midori - and was really impressed. Not only was it fast (using the webkit-gtk engine), but it also had a few more settings that Epiphany was missing. Furthermore, it didn't have an annoying 'Leave Fullscreen' button to get in the way of things. There are a couple of issues I've found with it still, such as random cursor placement in a text area after pressing End / Left / Right / Down, etc, but I'm sure those will get ironed out eventually too.

I'm actually writing this entry using Midori, and have to say that it's very responsive and feels extremely light-weight. There is practically zero load time when going through GMail or Slashdot. Considering the Midori project has had less time to reach maturity than either Firefox or Epiphany, and has had less manpower, I would have to give it the best review overall.

Now, I am a huge fan of Firefox - Mozilla and its contributions to the Linux community have been fantastic over the years - but I have to admit that the webkit-gtk engine will probably take the GNU/Linux Desktop Browser crown once mature whether that is in Chromium, Midori or (with little likelihood) Epiphany.

Simple Fortran Cross-Compiler for ARM

Run Fortran code on my handheld ? Are you insane?

That's probably the first thing that comes to your mind after seeing the title of my latest post - but with the power of ARM processors of today, why wouldn't we run Fortran programs on them?

Fortran was (back in the 70's ... and arguably still is) the scientific computing language of choice for many academics and engineers. It became the basis for many of the most advanced matrix-algebra math libraries available to date, including BLAS, LINPACK, and LAPACK, which are used by the most powerful number-crunching machines in the world, not to mention all of the banks and stock-exchanges! What I find more interesting is that the popular math engine known as MATLAB makes heavy use of BLAS and LAPACK, as does a free MATLAB-like environment called Octave.

I should take a step back and say, that the simple cross-compiler I have devised is not in-itself a cross compiler, but a two-step solution using F2C and your friendly-neighborhood cross-GCC ;-) That is, the Fortran code is first translated to C code, and then cross-compiled into machine code. Although many people swear that a well written Fortran code pushed through a good Fortran compiler will always blow away C code (and they probably are right), it's always true that something is better than nothing. The advantage of using F2C is that you don't need to link your programs to libgfortran, and having fewer dependencies is always good in embedded systems.

In any event, F2C (and the resultant libf2c) were authored by several friendly and very smart people who were kind enough to make their software available to the general public on NetLib.Org.

Using a popular perl script called Fort77, and my tiny patch, you should be able to cross-compile Fortran code to object code (.f -> .o) just like you would with C (.c -> .o). You'll need a libf2c.so compiled for ARM as well as f2c.h installed and in your cross-compiler's default search paths. I built the cross-compiled libf2c using an armv5tel-softfloat toolchain using Gentoo's crossdev, and created a small overlay for the package, available here.

I have something special on my evil agenda for this... and will hopefully be announcing something about that within the not-to-distant future!

Lastly ... for all of the gadget-geeks that are reading this... what sort of devices are you hoping to find in your stockings this holiday season? I'm fairly infatuated with the Qualcomm Snapdragon / MSM devices, but the Nokia n900 (with an OMAP chip also looks very tempting).

Stmpe2401 Linux Driver

I just thought that I would post a message about one of my recent submissions to the Linux kernel.

The STMPE2401 is a multi-function device from ST Microelectronics intended for mobile, low-power applications. It provides an I²C interface for up to 24 extra GPIO lines, each with independent interrupt generation capabilities. Up to 20 of those lines can be used with the integrated 8x12 matrix keypad controller. Another 3 pins can be used for programmable PWM channels, and 3 other pins can be used for a rotator input. All of the subsystems can operate together, at the same time, and each subsystem also provides additional interrupt capabilities.

This device appears on the Peek handheld, among many others. I wrote this driver for another device which I am still unable to mention (sorry about that).

There's actually a newer chip, called the STMPE2403, I believe, which makes a couple of improvements over the original. Namely, it has an automatic sleep function that ensures the lowest power consumption possible, but it's still capable of running in 2401 compatibility mode.

In the linux kernel, this should eventually show up under drivers/mfd, with sub-components showing up in drivers/gpio/chip, drivers/input, and so on. Currently, I've only implemented the keypad functionality but have provided lots of structure for the other subsystems. Here is the patch.

Enjoy!

Motorola Q9h

So I wrote Motorola recently to see if they would like to cooperate in my effort to port Linux and Android to the Q9h, and although a couple of engineers on the motodev site seemed enthusiastic, I still haven't heard any kind of definitive reply.

The next logical step was to disassemble a broken Motorola Q9h I found on eBay :) I'm not entirely finished this tear-down yet, because I'm still trying to pry-off a few remaining EMI shields, but its coming along smoothly.

 I'd have to say, that I'm amazed with all of the components that went into this device from various vendors. Of course, there's the TI OMAP2420, a TI power management chip, some Samsung memory, Elpida memory, a Broadcom (I'm guessing bluetooth) transceiver, several FreeScale parts that I haven't yet identified, the SiRF 5000 AGPS receiver, a few random sensors (ambient light, ...), etc.

I'll be specifically looking for a 'companion chip' sort of like the TWL4030, to see what I can get out of the USB pins. I believe that D+ / D- are not fully muxed with UART2, but they are with GPIO 107 / 108, which means I might have to write a small soft-uart driver for the Linux kernel. 

Most of the Linux-OMAP code for the 2420 device is already present upstream in the kernel (mainly written by Nokia engineers), so in terms of the Linux porting effort, it's really just a matter of configuration. There may be a couple of non-standard peripheral devices, but I'm not expecting any major difficulties.

I hope you eagerly await some photos of the internals :) I'll have to take a pause in order to get back to the library and resume studying for my wireless communication exam, but I should be done the teardown in another day or two.

Wish me luck!

Update-20091002: Teardown
Update-20091002: OpenEZX Page

Two of my Three Favourite Things

2GHz Multi-Core ARM Processors on the Horizon

... Wow!

Gentoo BootSplash for ARM FrameBuffers

With Gentoo now running on several mobile devices, including the OpenMoko devices, HTC Wizard, and one that I'm still unable to mention due to NDA, I thought that it would be advantageous to be able to package splashutils for ARM devices in order to make the Gentoo boot process as visually appealing as others (notably Angstrom).

One major blocker in that process was being able to (cross-)compile klibc for ARM devices. Although that has been working well for a couple of years already, klibc was unavailable for Gentoo / ARM without an arm keyword. So I had to edit the klibc ebuild considerably and make it cross-compile friendly. In the process I added a couple of useful features and bug-fixes that were already in OpenEmbedded, like wc, losetup, etc. You can see the efforts of my klibc ebuild at Gentoo's Bugzilla under bug #284957. It's currently working without any issues. Incidentally, the ebuild configures for the ARM EABI if it's applicable.

Once that was ready to go, I contacted Spock and he assured me that his splashutils would work for generic framebuffers, and not just vesa or vga style devices. Then, it was just a matter of emerge-ing splashutils, and creating a theme.

I chose to modify the natural_gentoo theme because it was relatively clean-looking and recent. There are definitely hundreds of themes to choose from though. Here are the modified version for resolutions 240x320 (silent), 240x320 (verbose), 320x240 (silent), and 320x240 (verbose). My 240x320.cfg file is available here and a feature request has been added at Gentoo's Bugzilla under bug #285088.

 

Note: Ned Ludd and Angelo from #gentoo-embedded had apparently done this a year ago, but I guess they hadn't submitted it to the main portage tree. I was unaware of their efforts unfortunately, and maybe could have spared myself some time if I would have known about it beforehand.