Tolunay Orkun writes:
Yuli> As I mentioned, it's for byte lanes swapping. If you connect a Yuli> 16-bit flash chip to a PPC, you need to connect only two byte Yuli> lanes of the PPC data bus i.e. lines D0-D15. For PPC, D0 is Yuli> MSB and D15 is LSB. For the flash, D0 is LSB and D15 is Yuli> MSB. So, you can connect D0 to D15, D1 to D14, and so on.
Tolunay> This is the correct way of interfacing flash chip per Tolunay> PowerPC documentation.
In most cases, yes, though there is no single "correct" way.
Yuli> Another possibility D0-D7 of PPC to D7-D0 of the flash and Yuli> D8-D15 of PPC to D15-D8 of the flash. The latter case is the Yuli> case of swapped byte lanes because PPC's most significant byte Yuli> goes always to D0-D7 and thus to the least significant byte of Yuli> the flash.
Tolunay> This is really not the correct way to interface the Tolunay> Flash. It seems like hardware designer goofed up and asking Tolunay> the software guys to fix his/her mess.
It depends. In most cases, it's a designer's mistake. However, I saw it on roughly half of all boards I worked with so probably it can be declared a "feature." Linux MTD includes support for it. In some cases, it's not a mistake but the only way to connect the flash. For example, there are many flash chips which can work in both 8-bit and 16-bit modes. If you want to have both options on your board (probably, you're building an evaluation board or reference design), you have to swap the byte lanes if you want to preserve glueless PPC-flash interface.
Yuli> So, in the latter case, you have to define Yuli> CFG_FLASH_CFI_SWAP. Without CFG_FLASH_CFI_SWAP, any flash Yuli> command (which is always single byte) will go to PPC's D8-D15 Yuli> and consequently to the most significant byte of the Yuli> flash. This won't work because the commands must go to the Yuli> flash's least significant byte. Of course, PPC is only an Yuli> example, the same problem can occur with other CPUs too, it Yuli> only depends on the bus architecture.
Tolunay> Really it depends on the designer. The hardware designer Tolunay> can scramble the data bus in many more ways.
Because of this, I think that using #ifdef __LITTLE_ENDIAN is not a good idea but I preserved the existing algorithm because I have no little-endian systems to test possible changes.