cfi 0001
Hi,
I have a problem with writing to a Intel Strata flash and then doing a warm reset.
I have a jffs2 mounted on mtdblock which uses cfi_cmdset_0001 according to the console messages.
When I do a simple write echo "xxxx" > /MyFlash/test.text the flash writes but remain in the state that only 0080 can be read when I ioremap some address in the flash.
My problem is that the bootcode also exist in the flash so if the watchdog resets the everything just hang.
I running 2.6.10 but also tried to updated to mtd-snapshot-20060317 but success with that version either.
Is this a expected behavior or shouldn't a write put the flash in a readable state (on a hardware level)?
What should I do to debug this?
Thanks in advance, Tomas
Hi
Am Montag, 20. März 2006 16:12 schrieb Tomas E:
Quoted 9 lines
I have a problem with writing to a Intel Strata flash and then doing a warm reset.
I have a jffs2 mounted on mtdblock which uses
cfi_cmdset_0001according to the console messages.When I do a simple write echo "xxxx" > /MyFlash/test.text the flash writes but remain in the state that only 0080 can be read when I ioremap some address in the flash.
Hmmm... seems to be the status register!
Is there a function in the mtd subsystem that misses a read array command at the end of a flash function?
best regards
Signature · 4 lines
Wolfgang Muees Vor den Grashoefen 1 Auerswald GmbH & Co. KG D-38162 Cremlingen Hardware Development Germany Tel +49 5306 9219 0 Fax +49 5306 9219 94
Quoted 3 lines · Wolfgang Mües
Am Montag, 20. März 2006 16:12 schrieb Tomas E:
Quoted 2 lines
I have a problem with writing to a Intel Strata flash and then doing a warm reset.
Define 'warm reset'. Why isn't the reset line to the flash being asserted?
Quoted 1 line
Hmmm... seems to be the status register?
Yes, that's expected.
Quoted 2 lines
Is there a function in the mtd subsystem that misses a read array command at the end of a flash function?
No. You'd still be able to break it by resetting at the wrong time, and by having a half-arsed hack to stick it back in read mode at the end of each operation, you'd only _hide_ that problem. It's better for people to notice their error and fix up their reset sequence properly.
Signature · 1 line
dwmw2
Quoted 4 lines · Tomas E
Hi,
I have a problem with writing to a Intel Strata flash and then doing a warm reset.
How do you "warm reset" ?
Quoted 6 lines
When I do a simple write echo "xxxx" > /MyFlash/test.text the flash writes but remain in the state that only 0080 can be read when I ioremap some address in the flash.
My problem is that the bootcode also exist in the flash so if the watchdog resets the everything just hang.
How does the watchdog perform its reset?
Quoted 2 lines
Is this a expected behavior or shouldn't a write put the flash in a readable state (on a hardware level)?
Normally, the flash is put back into read mode with cfi_intelext_reset() through a reboot notifier handler, assuming of course that you're using a standard kernel interface to reboot your system.
Quoted 1 line
What should I do to debug this?
First you should tell us a bit more about your board reset.
Nicolas
Nicolas Pitre <[email protected]> skrev den Mon, 20 Mar 2006 11:08:19 -0500 (EST):
Hi,
Quoted 8 lines · Tomas E
Quoted 5 lines
Hi,
I have a problem with writing to a Intel Strata flash and then doing a warm reset.
How do you "warm reset" ?
I use the at91rm9200 built in watchdog on a custom board, which is very convient but there is no external pin from the watchdog to make the a reset of the flash.
The flash has several partitions starting with the bootloader and an other partition in the same flash is the jffs2 area.
Quoted 9 lines
Quoted 7 lines
When I do a simple write echo "xxxx" > /MyFlash/test.text the flash writes but remain in the state that only 0080 can be read when I ioremap some address in the flash.
My problem is that the bootcode also exist in the flash so if the watchdog resets the everything just hang.
How does the watchdog perform its reset?
As described above no reset on external hw (but on periphial on the chip) then ??? puts pc=0 where the flash is supposed to be located.
Quoted 7 lines
Quoted 3 lines
Is this a expected behavior or shouldn't a write put the flash in a readable state (on a hardware level)?
Normally, the flash is put back into read mode with
cfi_intelext_reset()through a reboot notifier handler, assuming of course that you're using a standard kernel interface to reboot your system.
A normal reset power on/off works well but the problem is this watchdog. Since there is no reset from the watchdog to the flash. I dont think I cannot do anything useful before this warm reset.
I was hoping to minimize the time when the flash was in a non readable state but with jffs2/mtdblock/cfi and caching/buffering is there anything that can be done?
Quoted 8 lines
Quoted 2 lines
What should I do to debug this?
First you should tell us a bit more about your board reset.
Nicolas
Tomas
Quoted 7 lines · Tomas
Nicolas Pitre <[email protected]> skrev den Mon, 20 Mar 2006 11:08:19 -0500 (EST):
Hi,Quoted 4 lines · Tomas E
Quoted 3 lines
Hi,
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
I have a problem with writing to a Intel Strata flash and then doing a warm reset.
How do you "warm reset" ?
I use the at91rm9200 built in watchdog on a custom board, which is very convient but there is no external pin from the watchdog to make the a reset of the flash.
You mean from include/asm-arm/arch-at91rm9200/system.h:
static inline void arch_reset(char mode)
{
/*
* Perform a hardware reset with the use of the Watchdog timer.
*/
at91_sys_write(AT91_ST_WDMR, AT91_ST_RSTEN | AT91_ST_EXTEN | 1);
at91_sys_write(AT91_ST_CR, AT91_ST_WDRST);
}then it is usually called from machine_restart() in arch/arm/kernel/process.c...
which is called from kernel_restart() in kernel/sys.c...
But kernel_restart() has called kernel_restart_prepare() which calls notifier_call_chain(&reboot_notifier_list, SYS_RESTART, cmd)...
And incidentally one of those reboot notifiers is cfi_intelext_reboot() in drivers/mtd/chips/cfi_cmdset_0001.c which calls cfi_intelext_reset() ... which has this comment:
/* force the completion of any ongoing operation
and switch to array mode so any bootloader in flash is accessible for soft reboot. */
That looks like what you need already.
Nicolas
Hi,
There are 2 things that I didn't expect:
First that the flash allways seems to be in non-readable state after a write. It will not change state until a read is performed. This might be by design for performance? The cfi-driver uses the buffered write and then returns. Next time the cfi-driver is called it checks if the operation done before was completed
and issue the current task?
The second thing is that it whole flash is put into a non-readable state in a write operation.
I have partition the flash in several partition by using physmap. I don't know how the cfi flash works but shoudn't it be possible to work on sector basis?
Thanks in advance, Tomas
Quoted 11 lines · Tomas
Hi,
There are 2 things that I didn't expect:
First that the flash allways seems to be in non-readable state after a write. It will not change state until a read is performed. This might be by design for performance? The cfi-driver uses the buffered write and then returns. Next time the cfi-driver is called it checks if the operation done before was completed
and issue the current task?
This has been like that forever. We added the hack David described earlier to force the chip back into read array mode after a write or erase. But it's not 100% safe.
Quoted 5 lines
The second thing is that it whole flash is put into a non-readable state in a write operation.
I have partition the flash in several partition by using physmap. I don't know how the cfi flash works but shoudn't it be possible to work on sector basis?
No, it's not. That isn't how NOR flash works. And partitions created with physmap are purely a software mechanism.
josh
Quoted 7 lines · Tomas
Hi,
There are 2 things that I didn't expect:
First that the flash allways seems to be in non-readable state after a write. It will not change state until a read is performed. This might be by design for performance?
Yes it is by design.
Quoted 5 lines
The second thing is that it whole flash is put into a non-readable state in a write operation.
I have partition the flash in several partition by using physmap. I don't know how the cfi flash works but shoudn't it be possible to work on sector basis?
No. Those partitions are only logical partitions. Most NOR flash parts are entirely unreadable when operations are performed on them.
Nicolas