On 5/12/06, Pjotr Kourzanov <[EMAIL PROTECTED]> 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 EABI.
I've had good experience with the latest Debian binutils, gcc-4.1, linux-2.6.1[67] and a modified glibc-2.3.6-6 with tar.bz2 taken from glibc-2.4 CVS. 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 enabled). 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 http://freaknet.org/martin/qemu
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 voice. 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 meanings. Ha! 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. M (*) http://lists.debian.org/debian-devel/2004/06/msg00176.html
