Woo-hoo!
Today I booked my flight back to Canada on the 14th of March, from Hamburg to Montréal. Can you tell that I have a huge smile on my face as I write this? Hehehe..
In the next month, I'll be writing my exams in Advanced Signals & Systems, Advanced Digital Signal Processing, and then I'm organizing to write my exam in Digital Communications at McGill via some awesome department that will proctor exams for external universities ;-) I've never even heard of that before.
But hey, if it means that I don't miss out on an exam and I get to be in my new apartment with my lady friend and Julien, then that's entirely wicked in my opinion!
Oh yes, and by the way, version 2.0 will be named Julien Jacob Friedt - although I'm not 100% sure of the spelling of all of it - Erin and I both agree that Julien should be with an 'e', but I sort of feel like using a 'k' in Jakob just because that's how they would spell it over here.
By the way, if anyone feels like buying a few baby clothes, these ones are definitely on the wish list:
http://www.thinkgeek.com/tshirts/kids/5ace/
http://www.thinkgeek.com/tshirts/kids/59cc/
http://www.thinkgeek.com/tshirts/kids/6c71/
and my personal favorite
http://www.thinkgeek.com/tshirts/kids/9b11/
Sigh, comic relief ;-)
I spoke to Sammy D.J. just yesterday, and He and Emily are also expecting a newcomer in July - Ethan Donald. Dwayne Williams also has one (or two) little ones already, and countless numbers of others must be married at this point - jeez, I'm starting to sound like a 30 year old! AAAAGGHH!!
It seems as if it were yesterday that we were wearing hospital pants and hardhats and getting completely $h17-faced in the 4th floor of Pitman Hall. I know, I'm a bit of a sentimental, but hey - what a wild time; the nights without sleep studying for exams, practically living in the basement of the building formerly known as T... sometimes I can't even believe that I'm here in Germany now doing my master's. I'm meeting so many people from all over the world - I hope I stay good friends with all of them, just because having friends in other countries just makes the best excuse to travel ;-)
Speaking of travel, the feeling that I will be 'going home' to Montréal hasn't even really sunk in yet. What I mean, is that it seems like I've been renting rooms for literally the last decade of my life! Moving from city to city, province to province, country, continent, etc. Now Erin & I are pretty much starting out together in a beautiful plateau apartement à côté du Parc LaFontaine. I can't wait! The next year of my life is going to be full of the most amazing experiences.
Well, I'd better get back to work / studying
Hasta Luego
20080218
MaverickCrunch / EABI Toolchain, Kernel, and Sysroot
Hi everyone,
I just announced a somewhat lengthy HowTo with information on building a fully compliant kernel, root filesystem, and toolchain for use with the ep93xx series of SOC's. This is really mainly addressed at Gentoo Linux users due to the build system in place.
GentooWiki:Gentoo_for_the_TS72xx_SBC_(Full_Distro)
The next few steps are getting a package manager working, a commissioning station, and also a database for storing client/host keys.
20080211
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.
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.
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?
20080201
Maverick-Crunch / EABI support for Crossdev
Since I've been using the TS-7xxx boards from Technologic Systems, I've been wanting to experiment a bit more with the Maverick-Crunch floating point coprocessor in order to squeeze a bit more performance in number-crunching apps.
Here are some simple instructions for creating an armv4tl-maverick-linux-gnueabi toolchain using Gentoo/Portage/Crossdev. These instructions are current as of 26. February 2008.
[ Update: 26. Feb, 2008 ]
The procedure is tested and I have yet to experience any bugs in any normal userspace applications. I know that lame now produces mp3s 25 times faster, and there were no audible errors, which basically confirms with Martin Guy's results that the Maverick FPU is being used.
The only thing that I am lacking is a better stress test - paranoia.c just segfaults, and I'm not really sure why.
I've moved the instructions, as well as instructions for creating an eabi Linux kernel and a full userland, to the Gentoo Wiki.
Subscribe to:
Posts (Atom)