[U-Boot-Users] Re: Trouble in cfi_flash, help please!
Yusuf Ibrahim Ozkok writes:
Yusuf> Thanks for your reply. I'm also still working on, to find out Yusuf> the magic. And I'm getting crazy, since it's a very easy Yusuf> issue I couldn't over come it :-(
Yusuf> I have downloaded the last version of cfi_flash.c from Yusuf> CVS. So now it includes all the accepted patches.
Yusuf> Below you can find the debug output. I defined "DEBUG" in Yusuf> include/common.h. I couldn't see any other command (0xff as Yusuf> you said) between 0x60 and 0xd0.
It was in your previous mail. Probably some lines were not printed so it looked like a 0xff in the middle.
Yusuf> So there shouldn't be a command sequence error actually.
Yusuf> An other thing, I couldn't understand why we need to re Yusuf> protect all other sectors again in "flash_real_protect()".
Yusuf> There is a comment in the code /* Intel's unprotect Yusuf> unprotects all locking */
Yusuf> But I tried it and found that other sectors are not being Yusuf> unlocked!
...
It depends on the chip. For some chips, all sectors are unprotected, for others (like the chip you're working with) only one sector is unprotected. What I see from the debug prints is what I suspected: unprotect works OK but protecting already protected sector results in time-out (though Intel's docs don't say it's a forbidden operation). Note: time-out appears after 0x60 0x01 sequence, not after 0x60 0xD0. If you try to write/erase the sector which you tried to unprotect, I think you'll succeed. All sectors (on this chip) are protected after power-up so `protect off' will try to re-protect them. Correct operation would be reading sector protection status (it's available after Read ID command) and comparing it to the flash info structure. If the flash info indicates that the sector should be protected but it's unprotected, only then should the driver issue protect command. As a "quick and dirty" workaround, just `protect off all'.
It depends on the chip. For some chips, all sectors are unprotected, for
others (like the chip you're working with) only one sector is
unprotected. What I see from the debug prints is what I suspected:
unprotect works OK but protecting already protected sector results in
time-out (though Intel's docs don't say it's a forbidden
operation).
That's right, I had already thought it previously and had commented out the code reprotecting the sectors that are not to be unprotected.
While I was capturing the debug output to send you, I used the last orijinal cfi_flash driver, which I downloaded from CVS. But in my modified (see below) driver it's commented out. And it still doesn't work.
********************************************************
if ((retcode =
flash_full_status_check (info, sector, info->erase_blk_tout,
prot ? "protect" : "unprotect")) == 0) {
info->protect[sector] = prot;
/*yio: commented out the following part, due to Intel 28F640C3T do not unprotects all sectors.*/
/*Intel's unprotect unprotects all locking *
if (prot == 0) {
flash_sect_t i;
for (i = 0; i < info->sector_count; i++) {
if (info->protect[i])
flash_real_protect (info, i, 1);
}
}*/
}
return retcode;
***********************************
Note: time-out appears after 0x60 0x01 sequence, not after
0x60 0xD0. If you try to write/erase the sector which you tried to
unprotect, I think you'll succeed.
That is the an other strange thing. When the region that I want to unprotect is erased, unprotection operation works well.
But if something is written in that region it fails. (???) Since I tried it hundreds of times, in my previous mail, I simply powered on the board and run the protect off command ignoring this issue. Unluckily the region was erased and you naturally observed it as if it works.
debug messages are as follows;
**********************************************
=> md ff040000
ff040000: 27051956 552d426f 6f742031 2e312e32 '..VU-Boot 1.1.2
ff040010: 20284a75 6e202037 20323030 35202d20 (Jun 7 2005 -
ff040020: 31363a31 313a3438 29000000 00000000 16:11:48).......
ff040030: 00000000 00000000 00000000 00000000 ................
ff040040: 00000000 00000000 00000000 00000000 ................
=> 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 (R
=> protect off ff040000 ff07ffff
Un-Protecting sectors 1..1 in bank 1
fwrite addr ff040000 cmd 50 0050005000500050 64 bit x 16 bit
fwrite addr ff040000 cmd 60 0060006000600060 64 bit x 16 bit
fwrite addr ff040000 cmd d0 00d000d000d000d0 64 bit x 16 bit
flash_is_busy: 1
long addr is at ff040000 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] = 0x32
addr[10] = 0x20
addr[11] = 0x28
addr[12] = 0x4a
addr[13] = 0x75
addr[14] = 0x6e
addr[15] = 0x20
addr[16] = 0x20
addr[17] = 0x37
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 ff040000 data 326f2037
fwrite addr ff040000 cmd ff 00ff00ff00ff00ff 64 bit x 16 bit
is= cmd 80(?) addr ff040000 is= 27051956552d426f 0080008000800080
Flash unprotect error at address ff040000
fwrite addr ff040000 cmd ff 00ff00ff00ff00ff 64 bit x 16 bit
.Un-Protected 1 sectors
=> 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:
Sector Start Addresses:
**************************************************
Regards
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.
######################################################################
participants (2)
-
Yuli Barcohen -
Yusuf Ibrahim Ozkok