[U-Boot-Users] help for cfi_flash
Hi all,
I'm in trouble with cfi_flash driver. Can you please help me?
We have ported u-boot to our custom MPC8245 board, except the flash driver. Now I'm trying to use cfi_flash driver of u-boot. But until now (with more then a week of work) I couldn't succedded. So I need some help!!!
We have an Intel 28F640C3T flash on our custom MPC8245 board. Four flash chips are connected to 64 bit address bus.
Since our flash chip supports CFI, I decided to use cfi driver, was it a wrong choice!
I have seen that there were several patches for cfi_flash driver in u-boot lists. Most of them were added to u-boot1.1.2 but as seen there were still discussions on cfi_flash after the relaese of ver 1.1.2.
I stated out my problem below. Can you point out me a way. What should I try after all?
The problem is;
When I boot with u-boot, flash initialization is completed. I can read the flash, but the problem is I can't erase, prog, or protect/uprotect flash. the command "protect off ff000000 ff03ffff" results with "flash is busy:1" warning messages. And obviously I can't erase or prog before successfully unprotect the flash.
After this brief describtion of my problem I want to list below, what I have done, and clues I obtained;
I want to state out that this board is also being used with vxworks. And vxworks flash driver works well. So there shouldn't be any hardware problem.
Our flash addressing is divided into two regions. first 16M is connected to 0xff000000 and other 16M is connected to 0x70000000. In vxworks second half of the flash is being used after PCI initialization. In u-boot we are aiming to use the first 16M for the first time.
I have defined required definitions for the CFI flash in our board configuration header file such as;
#define CFG_FLASH_CFI 1 /* Flash is CFI conformant */
#define CFG_FLASH_CFI_DRIVER 1 /* Use the common driver */
#define CFG_FLASH_BASE 0xFF000000
#define CFG_ENV_IS_IN_FLASH 0
#define CFG_FLASH_PROTECTION
#define CFG_MAX_FLASH_BANKS 1 /* max number of memory banks */
#define CFG_MAX_FLASH_SECT 127+8 /* max number of sectors on one chip */
/*there are 127 boot blocks, 128th block has 8 parameter blocks.*/
#define CFG_FLASH_BANKS_LIST {CFG_FLASH_BASE }
I have defined CFG_FLASH_PROTECTION because when I dive into the u-boot code I recognized that without defining this lag flash is not unprotected actually, but only a soft protection mechanism is employed.
Output of "fli" is below;
U-Boot 1.1.2 (Jun 7 2005 - 14:20:26)
CPU: MPC8245 Revision 1.4 at 349.999 MHz: 16 kB I-Cache 16 kB D-Cache
Board: akb8245 8245 Unity ##Test not implemented yet##
I2C: ready
DRAM: 64 MB
FLASH: 32 MB
*** Warning - bad CRC, using default environment
In: serial
Out: serial
Err: serial
Net: i82559#0
=>
=> fli
Bank # 1: CFI conformant FLASH (64 x 16) Size: 32 MB in 135 Sectors
Erase timeout 8192 ms, write timeout 0 ms, buffer write timeout 1 ms, buffer si
ze 1
Sector Start Addresses:
FF000000 (RO) FF040000 (RO) FF080000 (RO) FF0C0000 (RO) FF100000 (RO)
FF140000 (RO) FF180000 (RO) FF1C0000 (RO) FF200000 (RO) FF240000 (RO)
FF280000 (RO) FF2C0000 (RO) FF300000 (RO) FF340000 (RO) FF380000 (RO)
FF3C0000 (RO) FF400000 (RO) FF440000 (RO) FF480000 (RO) FF4C0000 (RO)
FF500000 (RO) FF540000 (RO) FF580000 (RO) FF5C0000 (RO) FF600000 (RO)
FF640000 (RO) FF680000 (RO) FF6C0000 (RO) FF700000 (RO) FF740000 (RO)
FF780000 (RO) FF7C0000 (RO) FF800000 (RO) FF840000 (RO) FF880000 (RO)
FF8C0000 (RO) FF900000 (RO) FF940000 (RO) FF980000 (RO) FF9C0000 (RO)
FFA00000 (RO) FFA40000 (RO) FFA80000 (RO) FFAC0000 (RO) FFB00000 (RO)
FFB40000 (RO) FFB80000 (RO) FFBC0000 (RO) FFC00000 (RO) FFC40000 (RO)
FFC80000 (RO) FFCC0000 (RO) FFD00000 (RO) FFD40000 (RO) FFD80000 (RO)
FFDC0000 (RO) FFE00000 (RO) FFE40000 (RO) FFE80000 (RO) FFEC0000 (RO)
FFF00000 (RO) FFF40000 (RO) FFF80000 (RO) FFFC0000 (RO) 00000000
00040000 00080000 000C0000 00100000 00140000
00180000 001C0000 00200000 00240000 00280000
002C0000 00300000 00340000 00380000 003C0000
00400000 00440000 00480000 004C0000 00500000
00540000 00580000 005C0000 00600000 00640000
00680000 006C0000 00700000 00740000 00780000
007C0000 00800000 00840000 00880000 008C0000
00900000 00940000 00980000 009C0000 00A00000
00A40000 00A80000 00AC0000 00B00000 00B40000
00B80000 00BC0000 00C00000 00C40000 00C80000
00CC0000 00D00000 00D40000 00D80000 00DC0000
00E00000 00E40000 00E80000 00EC0000 00F00000
00F40000 00F80000 00FC0000 00FC8000 00FD0000
00FD8000 00FE0000 00FE8000 00FF0000 00FF8000
=>
I have modified the tout in flash_status_check(), because it was too long!!! And although the "tout" is passed as a parameter, it's not used.
(I thing this chance is given as a patch previously)
- if (get_timer (start) > info->erase_blk_tout * CFG_HZ) {
+ if (get_timer (start) > tout) {
output of the protect command;
=>protect off ff000000 ff03ffff
flash_is_busy: 1
.
.
.
flash_is_busy: 1
flash_is_busy: 1
long addr is at ff000000 info->portwidth = 8
addr[0] = 0x27
addr[1] = 0x5
addr[2] = 0x19
addr[3] = 0x56
addr[4] = 0x55
addr[5] = 0x2d
addr[6] = 0x42
addr[7] = 0x6f
addr[8] = 0x6f
addr[9] = 0x74
addr[a] = 0x20
addr[b] = 0x31
addr[c] = 0x2e
addr[d] = 0x31
addr[e] = 0x2e
addr[f] = 0x31
addr[10] = 0x20
addr[11] = 0x28
addr[12] = 0x4d
addr[13] = 0x61
addr[14] = 0x79
addr[15] = 0x20
addr[16] = 0x20
addr[17] = 0x33
addr[18] = 0x20
addr[19] = 0x32
addr[1a] = 0x30
addr[1b] = 0x30
addr[1c] = 0x35
addr[1d] = 0x20
addr[1e] = 0x2d
addr[1f] = 0x20
Flash unprotect timeout at address ff000000 data 316f2033
fwrite addr ff000000 cmd ff 00ff00ff00ff00ff 64 bit x 16 bit
is= cmd 80(Ç) addr ff000000 is= 27051956552d426f 0080008000800080
Flash unprotect error at address ff000000
fwrite addr ff000000 cmd ff 00ff00ff00ff00ff 64 bit x 16 bit
.Un-Protected 1 sectors
=>
Thank you very much.
Yusuf.
Software Eng. - Aselsan Inc.
###################################################################### 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.
######################################################################
Yusuf Ibrahim Ozkok wrote:
Hi all,
I'm in trouble with cfi_flash driver. Can you please help me?
We have ported u-boot to our custom MPC8245 board, except the flash driver. Now I'm trying to use cfi_flash driver of u-boot. But until now (with more then a week of work) I couldn't succedded. So I need some help!!!
We have an Intel 28F640C3T flash on our custom MPC8245 board. Four flash chips are connected to 64 bit address bus.
In my experience, when the hardware engineers have given me a 64 data (not address - I assume that is a typo) bus, they _REQUIRE_ writes to be 64 bits at a time. In other words, you CANNOT write 8/16/32 bits (less than a full databus width) at a time. It saves them a gate or two, for some reason they think that is a big deal (it is, but not beneficial for software).
In my experience, I've always had to write 64 bits at a time. Writing 32 bits at a time (which is probably what you are currently doing) doesn't work because only half of your chips are going into write mode and everybody gets massively confused.
The solution is to load a floating point register (which is 64 bits) with the flash-destined data and write _that_, which does a single transaction 64 bit write (as opposed to two 32 bit writes). This is a pain to write initially, but once you get the technique working it really isn't a big deal.
Notes: * Check your processor documentation fine print: IIRC, you can do floating point loads and stores with the floating point unit "disabled" (which it probably is). Otherwise, you need to enable the FPU (no big deal).
* Reads work fine 8/16/32/64 bits at a time. Don't worry about reads, only writes.
* On the PowerPC, you cannot move data to/from integer registers to a FP register. You need to store it to RAM and load it in the FP register (or load constants directly).
* I don't know if the u-boot cfi driver knows how to do the 64 bit write trick. IIRC, other people have had this hardware limitation and have made u-boot work with it. Brows or use grep on the various boards and see what others have done.
[snip]
After this brief describtion of my problem I want to list below, what I have done, and clues I obtained;
I want to state out that this board is also being used with vxworks. And vxworks flash driver works well. So there shouldn't be any hardware problem.
How does the vxworks code do the flash writing? You need to do it in a _very_ similar way.
[snip]
Thank you very much.
Yusuf.
Software Eng. - Aselsan Inc.
Hope this helps. You're welcome. gvb
participants (2)
-
Jerry Van Baren -
Yusuf Ibrahim Ozkok