Re: [U-Boot-Users] [RFC] CFI Driver Little-Endian write Issue
Please ignore my last question. Lately, I find out in your .c file that there are still some places using __LITTLE_ENDIAN.
However, I still have a question that in which condition CFG_FLASH_CFI_SWAP is required to set?
Best Regards, Leo
-----Original Message----- From: Li Yang-r58472 Sent: Tuesday, August 08, 2006 7:11 PM To: 'Yuli Barcohen'; u-boot-users@lists.sourceforge.net Cc: Sam Song; Wolfgang Denk Subject: RE: [U-Boot-Users] [RFC] CFI Driver Little-Endian write Issue
+#if defined(__LITTLE_ENDIAN) && !defined(CFG_FLASH_CFI_SWAP) +#define CFG_FLASH_CFI_SWAP +#endif
[snip] -#if defined(__LITTLE_ENDIAN) +#if defined(CFG_FLASH_CFI_SWAP)
Why use CFG_FLASH_CFI_SWAP instead of __LITTLE_ENDIAN. It seems that
they are
equivalent.
Best Regards, Leo
-----Original Message----- From: u-boot-users-bounces@lists.sourceforge.net [mailto:u-boot-users-bounces@lists.sourceforge.net] On Behalf Of
Yuli Barcohen
Sent: Tuesday, August 08, 2006 7:00 PM To: u-boot-users@lists.sourceforge.net Cc: Sam Song; Wolfgang Denk Subject: Re: [U-Boot-Users] [RFC] CFI Driver Little-Endian write
Issue
> Sam Song writes:
Zang> Where is the patch? I do not object. Our final goal is
to
Zang> enable the general flash driver work on the board. Sam> Sorry, I misused the word patch:-). The "patch" is Yuli's Sam> cfi_flash.c in his attached file. See your mail archive. It Sam> would be there. I tested that it was OK but still need your Sam> confirmation, I am afraid.OK, the patch is attached. As we know, it works on big-endian
systems.
On little-endian ones, it should change nothing.
--
========================================================================
Yuli Barcohen | Phone +972-9-765-1788 | Software Project
Leader
yuli@arabellasw.com | Fax +972-9-765-7494 | Arabella Software,
Israel
========================================================================
Li Yang writes:
Li> Please ignore my last question. Lately, I find out in your .c Li> file that there are still some places using __LITTLE_ENDIAN.
Li> However, I still have a question that in which condition Li> CFG_FLASH_CFI_SWAP is required to set?
As I mentioned, it's for byte lanes swapping. If you connect a 16-bit flash chip to a PPC, you need to connect only two byte lanes of the PPC data bus i.e. lines D0-D15. For PPC, D0 is MSB and D15 is LSB. For the flash, D0 is LSB and D15 is MSB. So, you can connect D0 to D15, D1 to D14, and so on. Another possibility D0-D7 of PPC to D7-D0 of the flash and D8-D15 of PPC to D15-D8 of the flash. The latter case is the case of swapped byte lanes because PPC's most significant byte goes always to D0-D7 and thus to the least significant byte of the flash. So, in the latter case, you have to define CFG_FLASH_CFI_SWAP. Without CFG_FLASH_CFI_SWAP, any flash command (which is always single byte) will go to PPC's D8-D15 and consequently to the most significant byte of the flash. This won't work because the commands must go to the flash's least significant byte. Of course, PPC is only an example, the same problem can occur with other CPUs too, it only depends on the bus architecture.
Yuli Barcohen wrote:
As I mentioned, it's for byte lanes swapping. If you connect a 16-bit flash chip to a PPC, you need to connect only two byte lanes of the PPC data bus i.e. lines D0-D15. For PPC, D0 is MSB and D15 is LSB. For the flash, D0 is LSB and D15 is MSB. So, you can connect D0 to D15, D1 to D14, and so on.
This is the correct way of interfacing flash chip per PowerPC documentation.
Another possibility D0-D7 of PPC to D7-D0 of the flash and D8-D15 of PPC to D15-D8 of the flash. The latter case is the case of swapped byte lanes because PPC's most significant byte goes always to D0-D7 and thus to the least significant byte of the flash.
This is really not the correct way to interface the Flash. It seems like hardware designer goofed up and asking the software guys to fix his/her mess.
So, in the latter case, you have to define CFG_FLASH_CFI_SWAP. Without CFG_FLASH_CFI_SWAP, any flash command (which is always single byte) will go to PPC's D8-D15 and consequently to the most significant byte of the flash. This won't work because the commands must go to the flash's least significant byte. Of course, PPC is only an example, the same problem can occur with other CPUs too, it only depends on the bus architecture.
Really it depends on the designer. The hardware designer can scramble the data bus in many more ways.
Best regards, Tolunay
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.
participants (3)
-
Li Yang-r58472 -
Tolunay Orkun -
Yuli Barcohen