[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Big endian in debian ARM

On Friday 27 May 2005 16:19, Lennart Sorensen wrote:
> On Fri, May 27, 2005 at 04:07:26PM +0200, Marco Canini wrote:
> > Normally you would be right but in the case of IXP2400 this's not
> > necessarily true. Indeed the IXP2400 is a network processor and here is
> > employed to transmit data at 3 Gbps. In my case I've no problems in
> > making byte swaps, but I had preferred not to. However in general making
> > byte swaps for every packet you process would result in a performance
> > loss.
> Doesn't the microengine chips have a byte swap instruction or some way
> to byteswap data to be exchanged with the xscale?  If it doesn't someone
> left out a rather useful feature in a network processor.

The microengines can also work in little endian, however the network is big 
endian, plus programming in this field shows that you don't want to waste any 
microengine cycles. So it's really inconvenient to put microengines in LE 
mode, and practically no one is doing that.
On the XScale side things are different. You get it right when you say that 
the XScale has to handle only exceptions, but you've to clear what you mean 
by exception. In this case the exception packets are not fixed and you can 
chose what you consider an exception. However the important part is that when 
a packet is marked as exception it's not passed to XScale, only a packet 
handle reaches the software running on that. So if you have to process a 
packet there you will finish to copy & byte swap all the parts of the packet 
you consider of some interest.
Since it's clearly easier to have the XScale running in BE mode that's what 
MontaVista has done.
So here I don't have a LE linux running on this hardware and using debootstrap 
I won't be able to install Debian starting from it.
That's make me think to use a port of Fedora to XScale BE, however I would 
prefer to use Debian.
Do you have some suggestions?


> And isn't the idea that the microengines process the network data based
> on the programs you load into them, and the xscale only suppervises and
> deals with special cases?  If one of the microengines process and
> byteswap the packet before giving it to the xscale, you shouldn't have
> any performance problem because of endianess.  And hopefully you
> wouldn't be passing too many packets to the xscale at all if the normal
> packet flow can be programed into the microengines directly.  Of course
> I may just not understand the point of the ixp2400 from the datasheet at
> all.
> > Considering that it's an embedded system with nfs root fs, serial console
> > and network access, what is the suggested/simplest method to install
> > Debian ARM?
> Well if your platform is one of the (few) supported ones, you follow the
> install guide.  If it isn't, then you need to somehow get linux or
> something going on the system enough that you can run debootstrap (a
> perl script) to create a new debian root fs and then boot to that.  once
> you get that going you are pretty much running debian on it.
> Unfortunately arm systems vary greatly with different boot loaders and
> kernels for every single system (just about) and are in general quite a
> hassle to support.
> I have done the debootstrap install on top of a redhat based
> distribution the board maker offered on a Compulab board (xscale PXA255
> based), and then after I got it booting their kernel with debian user
> space, I started the work of building a kernel the with the features I
> wanted and the patches from the board maker using make-kpkg to get a
> debian packge for the kernel which I could install and then fiddled with
> the boot firmware to make it able to make the system boot from a new
> kernel.  Far from trivial to get going at least.
> Len Sorensen

Marco Canini

Reply to: