[U-Boot-Users] CFI flash driver problem
U-Boot users:
I am having a problem using the CFI flash drivers on a new board and would appreciate any suggestions to find my mistakes. (Wolfgang: this is the AMCC Acadia board that is on its way to you). The processor is a PPC405ez.
When writing or erasing the flash, the processor has an Program Check Exception. Below you can see the exeption handling data I receive when trying to erase a sector on flash:
NIP: 00000700 XER: 00000000 LR: 03FDC27C REGS: 03f6a9a0 TRAP: 0700 DAR: 03FD0014 MSR: 00000000 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00
GPR00: 00000000 03F6AA90 FFFFFFFF 03FFD1A8 00000030 03F6AAA0 00000030 BE59D81C GPR08: 00000000 FF000000 03F6AAA5 00000005 574FBDE6 FFFFFFFF 03FF9800 0400D000 GPR16: FFFFFFFF FFFFFFFF DFFFFFFD 03F6ABAA 00000001 00000000 00000000 00000000 GPR24: 00000000 0000007F 03FFD9F4 03FFD1A8 03FFD1A8 03F6AF4C 03FF9E9C 00000040 ** Illegal Instruction ** Call backtrace: Program Check Exception
I have debugged the error, and when stepping through code in "human time," I do not get this exeption. So, I put in in some basic debugging printouts and I can see that the problem occuring some place in the flash_write_cmd() function when calling it with "flash_write_cmd (info, sect, 0, AMD_CMD_ERASE_SECTOR);" at around line 490 in flash_erase().
I've added wait states to the flash chip select with no change. Because the flash shares the EBC bus with memory through a bus transiever, I thought that possibly there were problems with the transiever's timing. But after adding the maximum number of wait states, I do not think this is the case.
Thanks for you help, JM
Jeff Mann wrote:
U-Boot users:
I have debugged the error, and when stepping through code in "human time," I do not get this exeption. So, I put in in some basic debugging printouts and I can see that the problem occuring some place in the flash_write_cmd() function when calling it with "flash_write_cmd (info, sect, 0, AMD_CMD_ERASE_SECTOR);" at around line 490 in flash_erase().
Did you update to the latest driver from git. If not please try and report back..
Best regards, Tolunay
Did you update to the latest driver from git. If not please try and
report back..
Of course. I've learned my lesson before :) In any case, cfi_flash.c has not changed since 2006-11-13.
The "Illegal Instruction" exeption really makes me suspecious of an access timing problem.
Thanks, JM
In message 1628E43D99629C46988BE46087A3FBB98BAB33@ep-01.EmbeddedPlanet.local you wrote:
Did you update to the latest driver from git. If not please try and
report back..
Of course. I've learned my lesson before :) In any case, cfi_flash.c has not changed since 2006-11-13.
You must be missing something, i. e. at least the following commits:
Commit: 3a197b2fe49d6fa03978e60af2394efe9c70b527 Author: Haiying Wang Haiying.Wang@freescale.com Wed, 21 Feb 2007 16:52:31 +0100
[PATCH v3] Add sync to ensure flash_write_cmd is fully finished
Some CPUs like PPC, BLACKFIN need sync() to ensure cfi flash write command is fully finished. The sync() is defined in each CPU's io.h file. For those CPUs which do not need sync for now, a dummy sync() is defined in their io.h as well.
Signed-off-by: Haiying Wang Haiying.Wang@freescale.com
plus 5 or 6 more commits that affect drivers/cfi_flash.c
Best regards,
Wolfgang Denk
I have debugged the error, and when stepping through code in "human time," I do not get this exeption. So, I put in in some basic debugging printouts and I can see that the problem occuring some place
in the flash_write_cmd() function when calling it with "flash_write_cmd (info, sect, 0, AMD_CMD_ERASE_SECTOR);" at around line 490 in
flash_erase().
UPDATE:
I am proving this update in case someone searches the list archives to solve a similar problem.
The problem was the result of both NOR Flash and Cellular RAM driving the EBC_READY signal (also called CRAM_WT, and WAIT in the CRAM documents). Because of this configuration, after doing an operation on the Flash that requires a delay, such as erase or write, the Flash held EBC_READY low for a long time while erading or writing. So the processor never saw the CRAM release CRAM_WT when its data was ready. The processor never could retrieve the next instruction and intrepreted this as an "illegal instruction."
The problem had nothing to do with bus transievers or accessing timing.
In "human time" the erase cycle completed before I made the next step in code.
-Jeffrey Mann
Jeff Mann wrote:
flash_write_cmd() function when calling it with "flash_write_cmd (info, sect, 0, AMD_CMD_ERASE_SECTOR);" at around line 490 in
flash_erase().
UPDATE:
I am proving this update in case someone searches the list archives to solve a similar problem.
The problem was the result of both NOR Flash and Cellular RAM driving the EBC_READY signal (also called CRAM_WT, and WAIT in the CRAM documents). Because of this configuration, after doing an operation on the Flash that requires a delay, such as erase or write, the Flash held EBC_READY low for a long time while erading or writing. So the processor never saw the CRAM release CRAM_WT when its data was ready. The processor never could retrieve the next instruction and intrepreted this as an "illegal instruction."
The problem had nothing to do with bus transievers or accessing timing.
In "human time" the erase cycle completed before I made the next step in code.
-Jeffrey Mann
Jeff,
Thank you for the update. Did you make changes to your board design to solve this problem?
One solution would be to disconnect nor flash from EBC_READY and configure that CS for appropriate number of wait cycles. Another would be to disable bus timeout if possible.
Tolunay
participants (3)
-
Jeff Mann -
Tolunay Orkun -
Wolfgang Denk