Hi,
I have resolved my problem with cfi_flash driver. I would like to share what I have learned during my struggle with cfi_flash driver.
The posts for that problem;
http://sourceforge.net/mailarchive/message.php?msg_id=11994639
http://sourceforge.net/mailarchive/message.php?msg_id=12058552
What caused the problem and how is it solved:
Flash chips in my board are connected to 64 bit data bus. And the problem is simply about writing 64 bit data at once. cfi_flash driver used "unsigned long long" variables for 64 bit data and write them to the bus simply using long long pointers (For me that is a bug. And I would like to release a patch for it). Any integer definition (like int, long, long long etc.) makes gcc to use 32 bit registers of the cpu (for 32 bit ppc's). Long long is 64 bit on the memory that is true, but transfering a long long requires two cycles. To write a 64 bit data at once we have to use floating point registers. A way of using these registers in C is to define the variables as "double". But somehow defining double didn't work in u-boot or with my ppc_82xx-gcc compiler (eldk's compiler). An other way is to use assembly floating point instructions but double precision forms. Such as "lfd" and "strfd" commands for ppc have to be used.
Jerry Van Baren had warned me previously but I couldn't make sense with his suggestions at the moment. What make me confused that writing flash commands from u-boot shell by using mw.l command was working for protect and erase operations. Since mw.l makes 32 bit bus transaction, for example a 0x60606060 command was beeing recognized by all the four flash chips. On the other way a 0x00600060 command is caused failure (I had expected that it will work two out of four flash chips). Now when I solved the problem by using floating point registers, I understood Jerry's suggestions exactly! You can reach his post by the link. (http://sourceforge.net/mailarchive/message.php?msg_id=11994640) But I still can not solve the magic that while sending 0x60606060 by mw.l command works but 0x00600060 not!
Lessons:
So lesson-1: if hardware people gives you a 64 bit bus, use double or directly asm floating point instructions.
I think cfi_driver works with the boards that the flash chips are selected by chip select signals for each 32 bit portion of the data bus. In our board all the flash chips are connected to the same chip select signal that caused the problem.
Lesson-2: first of all examine your hardware well and be aware of your hardware.
Thanks for your help: Jerry Van Baren, Yuli Barcohen, Richard Woodruff.
The patch (unformatted):
1. The following function is added.
static void write_via_fpu (vu_long * addr, ulong * data)
{
__asm__ __volatile__ ("lfd 1, 0(%0)"::"r" (data));
__asm__ __volatile__ ("stfd 1, 0(%0)"::"r" (addr));
}
2. in /drivers/cfi_flash.c
line 850;
- *addr.llp = cword.ll;
+ write_via_fpu((vu_long*)addr.llp, (ulong*)&cword.ll);
line 1159;
- cptr.llp[0] = cword.ll;
+ write_via_fpu((vu_long*)cptr.llp, (ulong*)&cword.ll);
P.S. this function will work if fpu is enabled. If not it may be enabled by setting the fpu bit in msr as follows;
unsigned long msr;
msr = get_msr();
set_msr(msr | MSR_FP);
*_msr functions may be found by grepping the uboot directory.
3. The patch is not tested when CFG_FLASH_USE_BUFFER_WRITE is defined.
Same changes as in 2 should be done for that case.
If those changes are accepted, I can arrange a formal patch.
Finally, I would like to ask about the Tolunay Orkun's patch about tout in flash_status_check function. what is the last thought for that patch
Is it planned to be released? Because it's really a bug! (Last post for the thread; http://sourceforge.net/mailarchive/message.php?msg_id=11936556)
Best Wishes.
Yusuf.
###################################################################### Dikkat:
Bu elektronik posta mesaji kisisel ve ozeldir. Eger size gonderilmediyse lutfen gondericiyi bilgilendirip mesaji siliniz. Firmamiza gelen ve giden mesajlar virus taramasindan gecirilmekte, guvenlik nedeni ile kontrol edilerek saklanmaktadir. Mesajdaki gorusler ve bakis acisi gondericiye ait olup Aselsan A.S. resmi gorusu olmak zorunda degildir.
###################################################################### Attention:
This e-mail message is privileged and confidential. If you are not the intended recipient please delete the message and notify the sender. E-mails to and from the company are monitored for operational reasons and in accordance with lawful business practices. Any views or opinions presented are solely those of the author and do not necessarily represent the views of the company.
######################################################################