xscale port of fedora core 2

Lennert Buytenhek buytenh at wantstofly.org
Tue Aug 10 14:03:52 UTC 2004


On Tue, Aug 10, 2004 at 10:45:07PM +1000, Russell Coker wrote:

> > > Is anyone making machines for general-purpose use based on the
> > > IXP2400 core?  Or is it just for routers?
> >
> > [ For those not in the know: the IXP2400 is basically just an xscale
> >   (which is Intel's version of ARM) processor, with some extra on-chip
> >   processing logic for fast network processing.  The chip itself has
> >   an integrated memory controller, 64b/66MHz PCI unit, 4Gbps SPI-3 bus,
> >   and 8 on-chip processors which have a very simple instruction set
> >   designed to do network-related things such as switching, routing,
> >   firewalling, etc.  It can do full wire speed 4xGbps processing, and
> >   its bigger brother, the IXP2800, does full wire speed 10xGbps.  ]
> 
> Sounds nice.  Those 8 on-chip processors, how fast are they and how
> complex are the operations that they can perform?  Could they be
> programmed to do AES or SHA1?  If so is there any idea of what the
> expected throughput of having all 8 processors doing crypto at the
> same time might be?

The IXP2850 (variant of the IXP2800) has an on-chip crypto engine.
See http://www.intel.com/design/network/products/npfamily/ixp2850.htm
It can do DES, 3DES, AES and SHA-1, up to 10 Gbps, or so they say.

I already had plans for offloading L2/L3 switching/routing, BPF and
perhaps even iptables to the on-chip network hardware, as I think
that an IXP-based design is a good alternative for any big-name
hardware router.  (In fact, I got started on the IXP stuff from the
desire not to have to shell out $30k (and that's for second hand
gear!) every time you need a 2-port or 3-port gigabit router with a
proper BGP implementation (I work for a Dutch internet provider.))
I don't see why HW ipsec accel shouldn't be implementable as well,
but that's not my first priority.

If you're not on an IXP2850 but on an IXP2400 or IXP2800..  I think
the microengine instruction set is general enough to perform crypto
ops, but I'm not sure whether you'll have enough instruction store
for that -- the instruction store is in a separate set of on-chip
registers, and there's only 4K or 8K (depending on the model)
instruction words per microengine.

(The IXP2400 has 8 microengines at 600MHz, but the IXP2800 has 16 of
them at 1.4GHz, plus triple interleaved 1066MHz RDRAM channels.  I'm
sure that you could program them to do FFTs or something like that
at mindboggling rates.)

(But I digress.)


> > We're thinking about having an ATX form factor board designed for it,
> > which would be perfectly well possible since the chip has basically
> > everything you'd need in a general purpose PC.  But no definite plans
> > on that yet.
> 
> Would it be possible to make that SMP?  A machine with 4 of those CPUs
> having all 32 processors doing crypto could have some fun possibilities.

Hmm, did anybody ever make an ARM SMP system? :)

There _are_ multiprocessor IXP designs, but all such designs I'm aware
of run a separate kernel per CPU.  (It would be very interesting to see
what could be done about that, of course.)


> Especially as ARM CPUs take little power, a rack full of such machines
> could have some interesting uses.

The IXP2850 takes ~27 watts typical, ~32 max at 1.4GHz.


> > My motivation for porting Fedora to it was thus: most people who use
> > the IXP2400 run some form of Montavista on it, but considering that
> > these processors run at 600MHz or 700MHz and typically have between
> > 256MB and 1GB of RAM, why not run a normal distro on it?  I'm used
> > to RH/FC, and I want to have all the tools I have available on my
> > desktop box on my 'embedded' platform as well.
> 
> Absolutely!
> 
> What do we have to do to start a Fedora port to an architecture that
> isn't supported by RHEL?  Are we ready to have fedora.us take on a
> new architecture?

I was planning on providing an apt repository of these packages myself,
but if fedora.us would want to distribute these, that'd be fine with me.

I doubt that there ever be an 'official' (i.e. Red Hat-blessed) xscale
Fedora port -- I'd be happy if the stock SRPMS just compile on the xscale.


> > > > I would like to start submitting the (surprisingly small number of)
> > > > needed patches so far back into Fedora, perhaps shifting my efforts
> > > > towards FC3.  What do people here think about such an effort?
> > >
> > > Sounds good.  Any time you port to a new architecture you are likely to
> > > shake out bugs that aren't obvious on i386.  I've found heaps of bugs
> > > by porting code to other CPUs.
> >
> > Yeah.  There are lots of strange things to be found in userland.  Like
> > openssl assuming that linux-elf == i386, for example.
> >
> > OK, so how do I go from here?  Should I just submit all my patches to
> > bugzilla and wait?
> 
> If any bug that you find is likely to impact IA64 or AMD64 then it
> should be submitted to bugzilla.  If it is strictly only going to
> affect ARM then it may be best to submit it as a bug against the
> upstream code base instead.

OK.  Some packages only need spec file diffs and I'll just send
those to bugzilla in any case.


--L





More information about the fedora-devel-list mailing list