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?
3 comments:
Hi Christopher,
I have always kept the package database in my offboard system, and used tar to remove it when sending the bits I want to the embedded system. When the embedded system has only a few MByte of flash, all the space saving you can get is vital.
Perviously I have grafted Gentoo onto Scratchbox (Maemo) to provide a cross build environment, and while that works well, it is complex and adding new targets is a major pain. I have been casting round for a simpler approach that still works with the packages that don't cross-compile, but have yet to find one.
I have managed to compile ruby and python under scratchbox, so although heavyweight, it does iron out package wrinkles.
meanwhile, looking forwards to your howto.
Andrew
I've never really worried about cross-compiling ruby, but I have tried python a couple of times. Python-2.4.4 cross-compiles very cleanly using the ebuild, but 2.5 was just such a complete pain that I gave up.
After a couple of years of encountering a lot of packages that try to compile binaries to perform checks, or use pkgconfig, I am decidedly against using software that is not cross-compile friendly from the start.
Hi Andrew,
Normally I do exactly the same thing that you do.
I thought originally that /var/db/pkg was not that big, but having a second look at it - ITS HUGE!!! There's no way i'm going to let that pollute my nice trim embedded filesystem.
Arg... what a pain!
The main thing that I really want an on-board package manager for is the ability to have certain files automatically removed when they would otherwise not be overwritten by an upgrade.
Aside from that, it would be nice to have a package manager that would automatically check free disk space before an installation was to take place...
Arrgg!! I hate having to re-invent the wheel, but it sounds as though there's nothing pre-made by gentoo that can do this properly.
Post a Comment