-
Lennert Buytenhek authored
Patch from Lennert Buytenhek This is an old patch from 2.6.9-rc3-ds2 that never made it upstream. The IXP2000 slowport has two modes of operation, 8-bit and 32-bit. The slowport itself is a byte-wide bus, and in 8-bit mode, it does the more-or-less obvious thing: every word read causes four byte reads, and those bytes are then combined into a word according to the xscale core's current endian setting. So, what value you get depends on what endianity your IXP2000 is running in. In 32-bit mode, however, it is the slowport itself which combines bytes into words, and for this it unconditionally uses little endian mode. In this mode, word reads from the slowport will return the same value no matter whether the xscale core is running in big or little endian mode. This can be a plus in some cases. Byte (and halfword) accesses in 32-bit mode have rather useless semantics due to this, though. The usefulness of 32-bit mode is limited to the initial boot. When the IXP2000 resets, the slowport is always in 32-bit mode, so if you flash the bootloader into flash (which is connected to the slowport) using little-endian byte ordering, the xscale will always read the instruction stream correctly, no matter whether it's running in big or little endian mode. After booting it makes no sense to use 32-bit mode anymore. Especially since the slowport's word ordering in 32-bit mode is little endian, and the IXP2000 is conventionally run in big endian, which gives all kinds of fun issues when trying to access peripherals connected to the slowport. In fact, the current MTD map driver for IXP2000 already sets the slowport to 8-bit mode because it cannot access the flash otherwise. However, this means that if the MTD map driver is not compiled in for some reason, the slowport will stay in 32-bit mode after the initial boot, which will cause peripheral accesses to unexpectedly break! Signed-off-by: Lennert Buytenhek Signed-off-by: Russell King
bb12ca40