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.
Showing posts with label armv4t. Show all posts
Showing posts with label armv4t. Show all posts
20090821
Android ARMv4T Donut Patch
On my most recent flight from Canada to Germany, and in spite of having a great conversation with a single-serving friend, I got a bit bored and decided to try and build Donut for ARMv4T, which is quite unstable at the moment. The single-serving friend, whose name I never learned, was in a very similar boat as me - he said he was in the middle of an MSc in biomedical engineering in Lyon, and was originally from Kentucky. It's nice to actually have a decent conversation on an overseas flight for a change.Anyway - back to the topic at hand.
The reason I'm working on the Donut branch of Android, and patching it for ARMv4T, is that I would eventually like to use it on my OpenMoko FreeRunner, which currently uses Android-Cupcake from KoolU / Michael Trimarchi. Although the generic Donut branch now builds successfully with my patch, I still need to migrate all of the hardware-specific FreeRunner changes that KoolU (any many others) made.
If you feel interested in starting from the upstream end and working downstream, as opposed to starting from KoolU git and working upstream, then check out my patch (update: see bottom of post for updated patches) and give me some feedback. I'm not inclined to submit it upstream yet, without having tested out an an actual device, so it's in very early stages right now, but it definitely builds.
You'll need to create a buildspecs.mk file, like the one below, and put it in the base of your android build directory:
TARGET_SIMULATOR := false
TARGET_BUILD_TYPE := release
TARGET_ARCH_VERSION := armv4t
Happy hacking!
update-20090824:
update-20090825:
- While working on the above patch, I discovered that a lot of upstream work has been done on Android under the hood to support ARMv4T. That includes v4T assembly optimization for opencore, dalvik, etc. Bottom line - this is good for the FreeRunner! However, there are still a few places which need improvement though, and equivalent v4 asm. I filled in some of the gaps (external/opencore/codecs_v2/video/m4v_h263/enc/src/fastquant_inline.h) last night, but the rest are mainly all of the files that think CLZ is an V4 ARM instruction (sheesh!). They were easy enough to convert to C-equivalent code.
- Recently Michael Trimarchi also announced some work was underway to integrate the libGlamo code into Android's GL. Not too shabby! Perhaps we might see an accelerated Android on the OpenMoko FreeRunner in the near future!
- I recently put some thought to the Glamo's limited 511x511 buffer and limit of 7Mb/s to memory. Sure, it sucks, that we can't do everything at 640x480 (as advertised), but aren't there other ways to get around it? Such as performing acceleration on one quadrant of the FB at a time? Or switching to/from a lower or higher resolution when playing video / games ? We essentially have to beg for, borrow, cheat & steal those accelerated pixels if acceleration is to work.
update-20091214: Please see my newer post for a continuation of the effort.
20081022
Android FreeRunner Updates
There obviously needs to be a different kernel configuration, but Benno has already done that.
20080203
More Maverick/EABI fun ;-)
I've just finished cross-compiling an entire root filesystem from scratch for the TS72xx boards with the EABI and it's working out very well! The softfp floating-point ABI has indeed shown a dramatic increase in speed! I've tested out using emqbit-bench and the performance improvements match those found in the article "Why ARM's EABI Matters". I haven't yet been able to try out some hard floating point calculations, such as those done by Martin Guy, but hopefully I'll get to that soon.
The entire HowTo is written up right now and I've tested the procedure with both the arm-softfloat-linux-gnu toolchain/kernel/filesystem and the armv4t-maverick-linux-gnueabi toolchain/kernel/filesystem.
The kernel config /patches are working perfectly for linux-2.6.23.1 . I should have an article up on Gentoo-Wiki.com specifically assisting TS-72xx users in creating a manageable build environment for their boards.
After I get the article up, my next goal will be to determine a suitable binary package manager for live system updates. Thus far, I've looked at Paludis and iPkg [ 20080207 Update: ] and Qmerge which is one of the 'q' tools that comes with app-portage/portage-utils.
After reading an interview with Ciaran McCreesh, I've really gained an appreciation for what Paludis is doing with ebuild syntax modification. Some of those modifications are just so intuitive, convenient, and easily implemented, that I really wish they were already in Gentoo's Portage system. Actually, the article explains in some detail why that isn't already the case.
Paludis also requires a C++ runtime, just because it would have been quite difficult to code it entirely in C, although a rewrite is still possible I suppose. I'd rather not get into C++ right now on production systems. Also it seems that there is still a dependency for the entire portage / paludis ebuild tree to reside on the host, and that is definitely not happening.
On the other hand, iPkg has been in use for quite some time for embedded Linux package management and takes up only a few tens of kilobytes. It's recently been completely rewritten in C, which is fantastic news.
If I were to go with iPkg, then the other issue would be in conversion between Gentoo's tbz2 binary package format and iPkg's .ipkg binary format. Such a converter exists, but still requires some fine tuning.
[ 20080207 Update1: ] I've 95% decided to go with qmerge as my preferred on-board package manager. There are only a few things I need to check out before I go ahead with it fully. Namely, I need to do some test to make sure that it maintains a package database as I would expect, and that it can somehow report exact package versions when told to list installed packages (that might require some work on my part).
[ 20080207 Update2: ] Oh Gawd! Gentoo strikes again... I swear, I've never known a distro that so vagrantly throws around resources as if they were nothing... I think the dependency on /var/db/pkg might have bj@rkskt my idea of using qmerge as an embedded package manager. I'd rather not have to do any feature-adding if i can avoid it... qmerge was 95 percent there... maybe I should just write in some sqlite code and get it over with... I wonder how much that would actually improve things, if at all.
What puzzles me these days about all of the different Linux distro's having different package managers, is that the fundamental issue that they're all trying to solve is the same. Some of them handle that issue better than others, some of them lack certain features that others have, and some lean toward binary package distribution more than others (actually most). Fundamentally, the entire problem lies in solving dependency issues and tieing that together with the package database.
With embedded systems, the size of the package DB has to be extremely small, or else it needs to be maintained off-board.
[ Update 20080207: ] I think that I might be mistaken on the size of the portage db - it's much larger than expected!! For instance du -hs /var/db/pkg/net-wireless/wireless-tools is 128 kB !! That's WAY too big. Maybe I'm looking in the wrong place here - was I wrong to expect an actual database and not a filesystem for recording all of the relevent package information?
The entire HowTo is written up right now and I've tested the procedure with both the arm-softfloat-linux-gnu toolchain/kernel/filesystem and the armv4t-maverick-linux-gnueabi toolchain/kernel/filesystem.
The kernel config /patches are working perfectly for linux-2.6.23.1 . I should have an article up on Gentoo-Wiki.com specifically assisting TS-72xx users in creating a manageable build environment for their boards.
After I get the article up, my next goal will be to determine a suitable binary package manager for live system updates. Thus far, I've looked at Paludis and iPkg [ 20080207 Update: ] and Qmerge which is one of the 'q' tools that comes with app-portage/portage-utils.
After reading an interview with Ciaran McCreesh, I've really gained an appreciation for what Paludis is doing with ebuild syntax modification. Some of those modifications are just so intuitive, convenient, and easily implemented, that I really wish they were already in Gentoo's Portage system. Actually, the article explains in some detail why that isn't already the case.
Paludis also requires a C++ runtime, just because it would have been quite difficult to code it entirely in C, although a rewrite is still possible I suppose. I'd rather not get into C++ right now on production systems. Also it seems that there is still a dependency for the entire portage / paludis ebuild tree to reside on the host, and that is definitely not happening.
On the other hand, iPkg has been in use for quite some time for embedded Linux package management and takes up only a few tens of kilobytes. It's recently been completely rewritten in C, which is fantastic news.
If I were to go with iPkg, then the other issue would be in conversion between Gentoo's tbz2 binary package format and iPkg's .ipkg binary format. Such a converter exists, but still requires some fine tuning.
[ 20080207 Update1: ] I've 95% decided to go with qmerge as my preferred on-board package manager. There are only a few things I need to check out before I go ahead with it fully. Namely, I need to do some test to make sure that it maintains a package database as I would expect, and that it can somehow report exact package versions when told to list installed packages (that might require some work on my part).
[ 20080207 Update2: ] Oh Gawd! Gentoo strikes again... I swear, I've never known a distro that so vagrantly throws around resources as if they were nothing... I think the dependency on /var/db/pkg might have bj@rkskt my idea of using qmerge as an embedded package manager. I'd rather not have to do any feature-adding if i can avoid it... qmerge was 95 percent there... maybe I should just write in some sqlite code and get it over with... I wonder how much that would actually improve things, if at all.
What puzzles me these days about all of the different Linux distro's having different package managers, is that the fundamental issue that they're all trying to solve is the same. Some of them handle that issue better than others, some of them lack certain features that others have, and some lean toward binary package distribution more than others (actually most). Fundamentally, the entire problem lies in solving dependency issues and tieing that together with the package database.
With embedded systems, the size of the package DB has to be extremely small, or else it needs to be maintained off-board.
[ Update 20080207: ] I think that I might be mistaken on the size of the portage db - it's much larger than expected!! For instance du -hs /var/db/pkg/net-wireless/wireless-tools is 128 kB !! That's WAY too big. Maybe I'm looking in the wrong place here - was I wrong to expect an actual database and not a filesystem for recording all of the relevent package information?
Subscribe to:
Posts (Atom)