Re: armel port status
On 5/12/06, Pjotr Kourzanov <email@example.com> wrote:
On the ArmEabiPort wiki page you say that the toolchain should be
compiled with crosstool and it does not produce .deb's yet.
It doesn't *have* to be crosstool; that's just the only working path
I've found so far to produce a working crosscompiler targetting ARM
I've had good experience with the latest Debian binutils, gcc-4.1,
linux-2.6.1 and a modified glibc-2.3.6-6 with tar.bz2 taken from
I could produce the toolchain .deb's as well as compile a
lot of userland stuff (pretty much all of the core Debian),
That would be wonderful. I've been staring at this stuff myself for
far too long and am still overwhelmed by it.
Running an appropriately configured kernel with these binaries on an
OMAP1510 does not work yet, but that's a different story.
Well, the test run of crosstool includes compiling the kernel, and it
makes a working EABI kernel that runs fine under QEMU's system-board
mode emulating Integrator/CP (arm5vt arch, arm926 or 1026 CPU), using
an initrd busybox old-ABI userland (with the oldABI compatability mode
And of course, if you run QEMU on a fast AMD it gives you a faster ARM
than any existing ARM hardware I know of: on a 2.2 GHz AMD it reports
the bogomips of an 800MHz ARM.
I target that as a first system since it has kernel support, and with
QEMU, everybody can have one. Note though that u need special patches
to QEMU-CVS and a tiny kernel patch for this to work - available under
I used the arm-eabi name though (as well as armv4-eabi, armv5te-eabi
or more optimisations), since I started this before the
Extremadura meeting. This will of course be changed to armel later on...
This trick of "quietly deciding Debian arch names in a meeting" seems
to be becoming common practice(*) and is not to be recommended, since
it creates an inner circle of special people and excludes anyone not
physically present at the meeting from participating. Basically, if
you're not a member of the Debian/ARM Holiday Club, you don't have a
The actual letters of the name wouldn't matter, but in this case the
"decision" has concrete technical reasons for being one of the worst.
Users of the current old ABI "armeb" repository are to have the rug
pulled from under them on some random date, and forced to rebuild all
their systems totally to use a new incompatible arch of the same name
which will still be new and under testing. Not to speak of the
confusion it will cause for people over the following years when
anyone tries to think about the name "armeb", which will have two
almost identical but incompatible meanings. Of course, no existing
documents mentioning "armeb" will warn about the two incompatible
I've documented the stupid name choice in the wiki, but I'm not sure
we should feel bound by it.
Anyway, the generic new arch needs to target the minimum ARM system,
which seems to be ARMv5t at the moment because GCC support for EABI
under ARMv4t is said to be incomplete (I haven't verified this).
Ultimately the minimum arch should be ARMv4t. If people then want to
make repositories of cpu-specific packages, it should be possible to
use these with the main generic one(s).
There is one more trick we can pull in this case: the fact that we can
run old-abi and new-abi binaries on the same system could be used to
soften the bootstrapping problem:
- make an ARM EABI kernel package for the existing "arm" arch,
- build a debian system using that and old-ABI userland
- make ARM-EABI-generating toolchain package(s) existing "arm" arch
- "cross-compile" the new packages, and you can run "configure" or
whatever in a pure-EABI chroot
Mind u, that's just an idea I had yesterday: it sounds like you have
far more experience of this stuff than me.