Building ARM in big-endian mode

Joel Sherrill joel.sherrill at OARcorp.com
Wed Feb 26 15:39:18 UTC 2003



Charles Steaderman wrote:
> 
> Quoting Ralf Corsepius <corsepiu at faw.uni-ulm.de>:
> 
> > Am Mon, 2003-02-24 um 21.34 schrieb Charles Steaderman:
> > > I would like to rebuild RTEMS and my application for ARM in big-endian
> > mode.
> >
> > Meanwhile, having investigated a bit further, I found that
> >
> > 1.
> > * arm-rtems-gcc and arm-rtems-binutils both support big-endian arm.
> > * arm-rtems-newlib currently is only built for little-endian.
> >
> > => The current arm-rtems-gcc+newlib toolchain only supports
> > little-endian arm.
> >
> > Extending arm-rtems-gcc+newlib to support big-endianness would be
> > trivial, but doesn't make much sense unless 2. below can be resolved.
> >
> > 2. The arm port in RTEMS currently only supports little-endian arm, but
> > probably can extended to big-endian arm without too much effort by
> > someone actually using big-endian arm.
> >
> >
> > So the crucial questions would be:
> > * Why do you want to use ARM in big-endian mode?
> 
> The chip that we are working with is a NetSilicon NET+40. NetSilicon used to
> support a development based upon uCLinux (Net+Lx). Unfortunately, the platform
> was not super stable. NetSilicon then release a new OS (NET+OS) to support their
> chip which is based on ThreadX and the Fusion(?) network stack. It appears to be
> stable, but performance is terrible (drops 30% of flood ping packets) and it
> doesn't support routing. I had hoped that a port of RTEMS to NET+40 would be
> more stable than the Net+Lx port, but so far we still have frequent Data Abort
> situation. We based the RTEMS ethernet driver off of the NET+OS driver. One key
> difference between NET+OS and the other OSs is that NET+OS is built for big
> endian. I fear that there is a DMA/Ethernet problem in the NET+40 chip that
> somehow works better in big endian mode, but I can't prove this.

I waited on your reply before mentioning another odd case I ran into 
a few years ago where someone wanted to use a mips in little endian
mode.
Their device was in a system in shared memory with a mix of ix86 and
mips devices and using the mips in little endian mode significantly
would have improved performance since there was a lot of data being
shared.  The common format would have been nice.  I don't know if they
ever did it or not.  But it makes sense in this situation.

I would like to see RTEMS on the NetSilicon.  It has always appeared to
be interesting. :)

> > * What is it that prevents you from using little endian arm?
> > * Would you be willing to extend RTEMS arm port to big endianness?
> >
> > Ralf
> >
> >
> >
> 
> --
> Charlie Steaderman
> charlies at poliac.com
> VP Engineering
> Poliac Research Corporation
> Phone: 952.707.6245
> Cel: 612.242.6364



More information about the users mailing list