Building ARM in big-endian mode

[Ralf Corsepius]

Am Mon, 2003-02-24 um 22.20 schrieb Joel Sherrill:
> Charles Steaderman wrote:
> > 
> > I would like to rebuild RTEMS and my application for ARM in big-endian mode.
> > Currently, I have RPM based tools installed under Linux (gcc-3.2.1/newlib-1.10).
> > When I modify my bsp cfg file with -mbig-endian and rebuild RTEMS, I get the
> > following error:
> > 
> > arm-rtems-gcc --pipe -B../../../../lib/ -B../../../../pwrlink/lib/ -specs
> > bsp_specs -qrtems     -ansi -fasm      -O3 -mcpu=arm7tdmi
> > -mstructure-size-boundary=8 -mbig-endian  -o o-optimize/no-dpmem.o -c
> > ../../../../../../rtems/c/src/optman/rtems/no-dpmem.c
> > test -d o-optimize || mkdir o-optimize
> > arm-rtems-gcc --pipe -B../../../../lib/ -B../../../../pwrlink/lib/ -specs
> > bsp_specs -qrtems  -O3 -mcpu=arm7tdmi -mstructure-size-boundary=8 -mbig-endian
> >    -L ../../../../pwrlink/lib -o o-optimize/no-dpmem.rel -qnolinkcmds -nostdlib
> > -Wl,-r  o-optimize/no-dpmem.o
> > /opt/rtems/lib/gcc-lib/arm-rtems/3.2.1/../../../../arm-rtems/bin/ld:
> > o-optimize/no-dpmem.o: compiled for a big endian system and target is little endian
> > File in wrong format: failed to merge target specific data of file
> > o-optimize/no-dpmem.o
> > collect2: ld returned 1 exit status
> > gmake[4]: *** [o-optimize/no-dpmem.rel] Error 1
> > 
> > I assume that this means I need to rebuild newlib? 
> 
> No these files are part of RTEMS.
That's irrelevant at this point. 

The cause of this breakdown is the arm-rtems-binutils/gcc toolchain not
supporting big-endian targets.

> > At what point in the
> > configure/make process do I specify that I want big-endian and are there other
> > defines (-DBIG_ENDIAN???) that I need to specify?
> 
> This is more right.  Apparently, -mbig-endian is not being honored by
> the 
> loader (ld) so when we do "ld -r" it doesn't like that the source is big
> endian and the default target is little endian. 
No, this analysis is not correct.

arm-rtems-ld supports big-endian target, it's arm-rtems-gcc which
doesn't.

It's ld failing to link, because it finds that rtems has been compiled
for big-endian, while the gcc/newlib-infrastructure only supports
little-endian targets.

> Honestly, if you want big endian through out, I think you would be
> better off
> building another entire toolset variant like armbe-rtems or whatever it
> is
> called so the defaults match up nicely.  This will take a bit of
> tinkering
> with the aclocal macros that determine the RTEMS CPU name from the
> target
> name.  And no matter what, the code inside RTEMS that says the arm is
> big or little endian will have to be conditional based upon something
> the toolset says.
Though this approach probably would work, I am against it.

Implementing a arm/bigendian multilib variant into gcc would be much
easier to use for RTEMS.

Ralf