[U-Boot-Users] cfi_flash is now working with 64 bit port width
Yusuf Ibrahim Ozkok
yozkok at aselsan.com.tr
Thu Jun 30 10:23:31 CEST 2005
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.
######################################################################
More information about the U-Boot
mailing list