arm eabi port available (was: Re: arm eabi port, patches)
On Wed, Jan 10, 2007 at 08:43:12PM +0100, Lennert Buytenhek wrote:
> > > I can't share the debs yet (internal and customer use only for now),
> >
> > Is publishing estimated how soon?
>
> I hope soon, but I can't say yet, and I'm not the one deciding this.
> In my opinion, it's only fair that the people who paid for the work
> get the opportunity to implement and use it for some time before
> other people do.
As it doesn't really make a lot of sense anymore to keep the port
private at this point, ADS decided that it should be opened up to
the public. Yay.
Where:
A build-essential root filesystem (117M) tarball is available at:
http://armel.applieddata.net/developers/linux/eabi/armel-root-fs.tar.bz2
http://armel.applieddata.net/developers/linux/eabi/armel-root-fs.tar.bz2.md5
MD5:
5df0e63693f473ec93cfd561862bd96e armel-root-fs.tar.bz2
The deb repository, with close to 9000 packages, is located at
http://armel-debs.applieddata.net/debian/. The DNS entry for armel-debs
might not have propagated yet -- if not, point your box to 83.160.184.112
for now (e.g. by putting an entry in /etc/hosts for it.) The root
filesystem mentioned above has such an entry preconfigured. (Note that
this is temporary.) Sorry about this.
Thanks:
Yauheni Kaliuta has also been working on an EABI port (independent
from our effort), and made a lot of progress on it, for which I would
like to thank him -- his work was one reason for ADS to release their
port. I'd also like to thank the OpenEmbedded people, whose work I
used to bootstrap the initial armel port from, and I'd like to thank the
people that have worked on upstream EABI support for gcc, glibc and
the Linux kernel. They're the ones who really did all of the hard work.
What are the advantages of this EABI thing:
See http://wiki.debian.org/ArmEabiPort for some of the advantages of
the EABI.
Requirements:
To run an EABI userland, you will need a recent Linux kernel (I think
that 2.6.16 is the minimum version that works satisfactorily), built in
EABI mode. This is done by setting CONFIG_AEABI=y.
You might also want to turn on CONFIG_OABI_COMPAT in your kernel
configuration to be able to use old-ABI binaries to a certain extent
(this won't work for applications using ALSA, for example.)
To build an EABI kernel, you'll need at least gcc 4.1. It's fairly
easy to build one yourself, as you don't need glibc, but if there is
demand, I'll make a gcc 4.1 cross-toolchain available.
At the suggestion of Joey Hess, I'm currently building an EABI version
of the standard debian (arm) kernel package, so that people with slugs
or other IXP machines can try out the EABI chroot without having to
bother with building their own kernel.
How to use it:
Untar the tarball somewhere and chroot into it, or boot from it. You'll
probably have to configure such things as /etc/hosts, /etc/resolv.conf,
set the host name, etc., just as you would do with a regular debootstrap.
The rootfs comes with a preconfigured sources.list, which should give you
access to all packages built so far.
More info about the port:
The version of gcc used is a 4.1.x sid package, patched with Paul
Brook's fix for PR28516 from gcc bugzilla (which makes gcc require a
newer version of binutils than what's available in sid) and a patch
that changes the default CPU for linux-eabi from arm10tdmi to
arm9tdmi, so that the port will still work on armv4t CPUs such as the
Cirrus Logic ep93xx. Thumb interworking is enabled as per default.
(Note that Netwinders, being based on a non-bx supporting CPU, are
_not_ supported by this port!)
With the PR28516 fix applied, and the PR27363 fix which has already
been integrated into the gcc-4.1 sid package, gcc-4.1 has been working
very well for me. The only thing that it has trouble with is natively
compiling libfortran (segfaults the compiler), everything else has
been working flawlessly so far.
The binutils and glibc packages used are both from experimental. Sid
carries (IIRC) glibc 2.3.6, which doesn't have the necessary EABI bits
integrated, but glibc 2.5 from experimental does. A recent version of
binutils is required because of the applied gcc PR28516 fix.
Most packages were built with DEB_BUILD_GNU_TYPE=arm-linux-gnu. As per
Guillem Jover's previous post, this should be changed to -gnueabi, a
scan should probably be made through the archive to find packages that
break with this change, and everything rebuilt.
The patches used are available at http://armel-debs.applieddata.net/diffs/
(again, you probably need to set a hosts entry for now.) I've not spent
any effort on trying to produce clean patches, what is there gets things
built and that's all. Many of these patches will have to be reworked
before being submission-ready.
TODO:
gcc currently segfaults (not ICEs, but segfaults) when natively building
libfortran. This needs looking into.
A migration path for current old-ABI Debian users needs to be worked out.
I have to verify that the diffs available indeed build cleanly.
Questions?
Reply to: