| Message ID | 20220127003656.330161-1-linus.walleij@linaro.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | IXP4xx spring cleaning | expand |
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.
On Thu, Jan 27, 2022 at 1:36 AM Linus Walleij <linus.walleij@linaro.org> wrote: > > This cleans out the remaining board files from IXP4xx and > makes it an exclusive device tree subarchitecture without any > special weirdness in arch/arm/mach-ixp4xx. > > The biggest noticeable change is the removal of the old PCI > driver and along with that the removal of the special DMA > coherency code and defines and the DMA bouncing. Very nice! > I tried to convert the IXP4xx to multiplatform on top of > this but it didn't work because IXP4xx wants to be big > endian and multiplatform config creates a problem like > this: > > ../arch/arm/kernel/head.S: Assembler messages: > ../arch/arm/kernel/head.S:94: Error: selected processor does not support `setend be' in ARM mode > > I think this is because MULTI_V5 turns on CPUs that cannot > do big endian, and IXP4xx turn on big endian. The issue appears to be some mixup between BE8 and BE32 mode, as this instruction only available on ARMv6 and higher with their moder BE8 mode, while ARMv5 used the old-style BE32 mode that does not have the setend instruction. I don't know how you got to a configuration with BE8 mode on ARMv5, but I'm sure this can be solved. > (It crashes if I try to boot in little endian mode, sorry. It really > wants to run big endian.) My best guess is that this is caused by drivers using the "wrong" register accessors, it should be possible to fix as well, but would likely need fixes in a lot of files. I don't know what the right way to do register accesses on BE8 is any more, but apparently ixp4xx was working both ways in the past. It would be nice to be able to run Debian armel user space. Arnd
Hi Arnd, Arnd Bergmann <arnd@arndb.de> writes: > It would > be nice to be able to run Debian armel user space. Exactly. OTOH we need to remember IXP4xx is a single core, ARMv5, no NEON, no hw FP, max 256 MB RAM (455/46x - 512 MB RAM IIRC), the clocks are from 266 up to 533/667 MHz IIRC, the PCI limitations and so on.
On Thu, Jan 27, 2022 at 1:17 PM Krzysztof Hałasa <khalasa@piap.pl> wrote: > Arnd Bergmann <arnd@arndb.de> writes: > > > It would > > be nice to be able to run Debian armel user space. > > Exactly. > > OTOH we need to remember IXP4xx is a single core, ARMv5, no NEON, no hw > FP, max 256 MB RAM (455/46x - 512 MB RAM IIRC), the clocks are from 266 > up to 533/667 MHz IIRC, the PCI limitations and so on. I think that is fairly typical for hardware that can run Debian armel user space, which nowadays means mostly ARM926 based SoCs like sam9 or f1c100s. While there used to be popular ARMv5 and ARMv6 implementations that are a bit faster like Kirkwood or IOP13xx, those have mostly been replaced by ARMv7 or ARMv8 chips in practice, leaving Debian armel for this bottom end of the scale. Arnd