From: "Krzysztof Hałasa" <khalasa@piap.pl>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-arm-kernel@lists.infradead.org,
Imre Kaloz <kaloz@openwrt.org>, Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH 00/13] IXP4xx spring cleaning
Date: Thu, 27 Jan 2022 07:18:28 +0100 [thread overview]
Message-ID: <m3tudpya4r.fsf@t19.piap.pl> (raw)
In-Reply-To: <20220127003656.330161-1-linus.walleij@linaro.org> (Linus Walleij's message of "Thu, 27 Jan 2022 01:36:43 +0100")
Hi Linus,
Linus Walleij <linus.walleij@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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-01-27 6:20 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-27 0:36 [PATCH 00/13] IXP4xx spring cleaning Linus Walleij
2022-01-27 0:36 ` [PATCH 01/13] ARM: ixp4xx: Delete Gateway 7001 boardfiles Linus Walleij
2022-01-27 0:36 ` [PATCH 02/13] ARM: ixp4xx: Delete the Goramo MLR boardfile Linus Walleij
2022-01-27 0:36 ` [PATCH 03/13] ARM: ixp4xx: Delete old PCI driver Linus Walleij
2022-01-27 0:36 ` [PATCH 04/13] ARM: ixp4xx: Drop stale Kconfig entry Linus Walleij
2022-01-27 0:36 ` [PATCH 05/13] ARM: ixp4xx: Drop UDC info setting function Linus Walleij
2022-01-27 0:36 ` [PATCH 06/13] soc: ixp4xx: Add features from regmap helper Linus Walleij
2022-01-27 0:36 ` [PATCH 07/13] soc: ixp4xx-npe: Access syscon regs using regmap Linus Walleij
2022-01-27 0:36 ` [PATCH 08/13] net: ixp4xx_eth: Drop platform data support Linus Walleij
2022-01-27 0:36 ` [PATCH 09/13] net: ixp4xx_hss: Check features using syscon Linus Walleij
2022-01-27 0:36 ` [PATCH 10/13] ARM: ixp4xx: Remove feature bit accessors Linus Walleij
2022-01-27 0:36 ` [PATCH 11/13] ARM: ixp4xx: Drop custom DMA coherency and bouncing Linus Walleij
2022-01-27 6:38 ` Christoph Hellwig
2022-01-27 10:00 ` Arnd Bergmann
2022-01-31 6:54 ` Christoph Hellwig
2022-01-27 0:36 ` [PATCH 12/13] ARM: ixp4xx: Drop all common code Linus Walleij
2022-01-27 0:36 ` [PATCH 13/13] ARM: ixp4xx: Convert to SPARSE_IRQ and P2V Linus Walleij
2022-01-27 6:18 ` Krzysztof Hałasa [this message]
2022-01-27 7:55 ` [PATCH 00/13] IXP4xx spring cleaning Arnd Bergmann
2022-01-27 12:17 ` Krzysztof Hałasa
2022-01-27 13:11 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3tudpya4r.fsf@t19.piap.pl \
--to=khalasa@piap.pl \
--cc=arnd@arndb.de \
--cc=kaloz@openwrt.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.