[oe] [PATCH] package_deb.bbclass: armel architecture name for eabi systems.

[Khem Raj]

On (21/02/11 16:41), Leon Woestenberg wrote:
> Hello,
> 
> On Mon, Feb 21, 2011 at 4:12 PM, Phil Blundell <philb at gnu.org> wrote:
> > On Fri, 2011-02-18 at 14:50 -0700, Tom Rini wrote:
> >> I'm a little puzzled. So little endian gnueabi ARM is armel, little
> >> endian OABI ARM is arm.  What about big endian ARM cases?  Thanks!
> >
> > Debian has never had big-endian ARM as an officially supported
> > architecture, so to that extent there's no precedent to follow in this
> > area.
> >
> > The natural name for a big-endian gnueabi port would obviously be
> > "armeb".  That does leave big-endian OABI somewhat out in the cold but,
> > given that OABI has been obsolescent for the best part of a decade, this
> > doesn't seem totally unreasonable.  If anybody did want to use dpkg with
> > such a thing (and wanted to avoid colliding with armeb) then I guess
> > they'd have to name it "armob" or something.
> >
> 
> adding some history here:
> 
> <quoting Lennert Buytenhek>
> 
> > It's not so unusual anymore since intel introduced the IXP series
> > of chips which come with mostly BE oriented reference designs.
> 
> The nslu2 itself comes with an ixp4xx CPU, but the armeb port is also
> used on a number of ixp2000 boards. Having a big-endian arm distro to
> run on the ixp2000 was an important reason for developing this port.
> 
> As to why I chose armeb instead of armbe, partially because of the
> -EB/-EL thing, partially because the arch name also has the endianity
> at the end (armv4b, armv4l, armv5teb, armv5tel), partially because when
> I first started porting a distro to armeb, a number of tools (binutils?
> I can't remember now.) did accept arm*b-*-* as target string but didn't
> accept armbe-*-*.
> 
> The latter might have changed in the meanwhile, but the original
> decision to use armeb instead of armbe was made over two years ago.
> 
> cheers,
> Lennert
> </quoting Lennert Buytenhek>
> 
> 
> Please note that there have been lots of issues with armbe (in
> configure scripts etc), so I would recommend using armeb.

In OE we have EABI as default on ARM and boards from armv4+ therefore
oabi is less of an issue moving forwards. We should be fine using
armeb for BE ARM EABI only as I dont expect any oabi port for armeb in
future

-Khem