ARM big-endian

[Krzysztof Halasa <khc at pm dot waw dot pl>]

Hello,

I'm working on IXP425 (Intel XScale) based system (currently Intel's
devel board). My build platform is i686/Linux-2.6. Are the following
problems known, nobody does that, or am I doing something wrong?

I've compiled binutils (Fedora Core 2 source, binutils-2.15.90.0.3)
with --target=armeb-pc-linux-gnu. Is it the correct target? I want
big-endian (the usual default is little-endian) ARM code, as the IXP425
is big-endian by default. Or should I use little-endian code/mode?

I've compiled gcc (FC2 source, gcc-3.3.3-20040413). Gcc doesn't
support big-endian default ARM, so I added a respective config file
which defaults to BE on armeb-pc-linux-gnu. cpu=xscale.

I've compiled the kernel (current 2.6) and it seems to work fine
(with initramfs).


* now the easy part seems to be gone *


I've compiled glibc (first FC2 source, then CVS) with this cross-compiler.
It complained about undefined BUS_ISA (changed it to CTL_BUS_ISA, will
check it later to see if the fix is correct), and the math subdir caused
internal gcc error (I skipped math/ - should I file a bug report or is
it a known problem with such cross compiler?). Installed glibc, fixed
libc.so linker script (*** BUG in libc/scripts/output-format.sed ***
elf32-bigarm,elf32-littlearm, will look at it later).

Compiled busybox and run it on the IXP425 as /init and /bin/sh.


Now: busybox runs (i.e. doesn't segfault at once etc). It seems it has
problems with some string functions, displaying things like (note
missing chars):

init started:  BusyBox v1.00-pre8 (2004.06.03-23:35+0000) multi-call binary
Bummer, could not run '/etc/init.d/': No such file or director
-shHO: can't access tty; job control turned off
hel: applet not found
BUSYBOX
-shHO: BUSY: not foun
busybox mount /proc
moun:
Cannot read /etc/fstabInvalid argument
busybox mount none /proc -t proc
busybox ifconfig -a
lo        Link encap:Local Loopba
...

It frequently does:
busybox ls
Segmentation fau


Should I additionally tell glibc about the big-endian code? Are the
above problems caused by little-endian-only functions?

I haven't tried to build native gcc/glibc yet, as I doubt gcc will work
with such broken glibc at all, and I hope to avoid using, for example,
uClinux libc just to have a native compiler (I need glibc anyway, and
a native compiler would only help to compile the math subdirectory).


I'm going to have it all working (maybe except the glibc/math/
cross-compilation, if it's a known problem and no solution exist).
Where should I send gcc and glibc patches?
--
Krzysztof Halasa, B*FH