[PATCH 00/13] IXP4xx spring cleaning

[Krzysztof Hałasa]

Hi Linus,

Linus Walleij <linus.walleij at linaro.org> writes:

> I think this is because MULTI_V5 turns on CPUs that cannot
> do big endian, and IXP4xx turn on big endian. (It crashes if
> I try to boot in little endian mode, sorry. It really wants
> to run big endian.)

The IXP4xx used to work little-endian, with certain limitations, I guess
it could be easily made to work again.

The limitations were a bit of headache, though. The most problematic was
the network buffers were big-endian and required on-the-fly swapping,
which limited e.g. routing performance (I don't remember the numbers).
Also the crypto operations may have been affected (not sure, perhaps
there was an endianness flag for the crypto coprocessor).

There was a special memory mode where the CPU could swap the buffers in
hardware (it was an MMU page attribute). This special mode wasn't
available on the first CPU revision. I had an experimental, a bit
complicated patch which made use of this feature. This way I was able to
run off-the-shelf little-endian system (like Debian) without the network
performance hit.

IIRC the first CPU revision was used in certain routers (access
servers?) perhaps by US Robotics (3Com?). I had an experimental board
with this early chip as well. Otherwise I think most hardware used the
second revision. The newer chips (IXP43x and 45x/46x) had the feature
from the start, basically I think only the IXP425 rev. A0 (also called
IXC1100 by Intel?) was a problem.
-- 
Krzysztof "Chris" Hałasa

Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa