Having Fun with Embedded Gentoo on the TS72xx SBC

Hi everyone!

Having left Kiel last week and after a week of being back in Montréal doing some hard work, I've gotten my toolchains, overlays and binary package repositories for the TS72xx board to a very stable state.

I'm now using dropbear, openvpn, jamvm-1.5.1, classpath-0.97.1, and qmerge, thanks to the ease of building binary packages using Gentoo/Portage, xmerge, etc. Here are a couple of screenshots that can hopefully do justice to all of the work I've done with the 'compatibility' toolchain. The compatibility toolchain and binaries have been tested to be fully compatible with the kernel, libc, and so on distributed by Technologic Systems.








The toolchains, overlays, and repositories are for both arm-unknown-linux-gnu and armv4tl-maverick-linux-gnueabi. I've also updated the documentation on the Gentoo-Wiki:

Gentoo for the TS72xx (Old Toolchain)
Gentoo for the TS72xx Single Board Computer (Full Distro)

I had to fix the __NR_waitpid definition (removed it) in the linux kernel headers which solved a lot of glibc related issues I was having.

Next, I compiled busybox, etc, etc, got qmerge working on the board, and I've also compiled jamvm-1.5.1 and the classpath-0.97.1 . There was a slight problem with cross-compiling the GNU classpath shown below in the classpath bug.

One really strange problem that I had was with portage-utils. The md5sum code comes directly out of the busybox source code. The md5sum comman works perfectly on my board, but as is, the md5 calculations that qmerge made were always wrong. I didn't really want to spend too much time fixing the source code, so instead, I just created a patch for qmerge so that it calls 'md5sum' through popen. That fixed the problem, although the overhead is obviously very high. I should probably put in a patch since Ned Ludd, the original portage-utils author has been so helpful to me on the gentoo-embedded list. Thanks again Ned ;-)

I also noticed that busybox wouldn't reboot the system (using the older toolchain) so I had to make a patch which used the busybox-1.0.0 code for 'reboot'.

I'm hoping that some autotools / libtool genius decides to fix the classpath bug below, because I really don't want to spend any more time on it than I have to. The autotools should really _not_ abandon supporting cross-toolchains. There should really be a regular check made whenever AC_CHECK_LIB or AC_SEARCH_LIBS are made to see if the library location pulled from the .la file actually reflects the location of the .so or .a library in question.

As always, see my overlays for all patches to the original source code.

Some bugs filed:
Gentoo Bug #213690
Classpath Bug #35684

Follow Up to EABI / Maverick Userland

Hi Everyone,

I left off with instructions for creating an eabi / maverick toolchain for the ts72xx boards from EmbeddedARM.com, and am still sifting my way through some pretty dense decisions.

First of all, Gentoo's Portage build system makes it really easy to cross-compile packages and maintain dependencies. I think it's fantastic. The ony tricky part is in how the package database is maintained on-board. It's not even a database actually, it's right in the filesystem. Depending on the block size, even a 2-byte file could take up 4 kB of space, which is way beyond anything conceptual for an on-board package database for embedded devices.

I've considered writing in some sqlite code into the 'qmerge' app that comes with portage-utils. The benefit is that the sqlite file would save potentially doezens of kB of space. Furthermore, the sqlite file could be compressed in the filesystem after updates have taken place. When any package maintenance needs to be done, the sqlite database could be extracted to a tmpfs-mounted directory, and all of the operations could be performed there.

An alternative to that, is actually just to use the current filesystem-based package db and simply compress that directory without the sqlite backend. Then when updates were necessary, it would be possible to extract that to tmpfs, and re-compress when done.

Time is of the essence on my latest project, so it's likely that I won't be able to fully code that into portage-utils until my current project is matured and nearing completion. The matured stage is probably 1 month from now, and the completion stage is probably closer to 2 months away.

I'll post my instructions, as planned on gentoo-wiki.com for doing cross-compilation and building up to a certain stage, but more instructions on how to maintain packages on a live system may be delayed for some time.

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?