cfi 0001

cfi 0001

[Tomas E]

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

Re: cfi 0001

[Wolfgang Mües]

Hi

Am Montag, 20. März 2006 16:12 schrieb Tomas E:
> 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.

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
-- 
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

Re: cfi 0001

[David Woodhouse]

On Mon, 2006-03-20 at 16:22 +0100, Wolfgang Mües wrote:
> Am Montag, 20. März 2006 16:12 schrieb Tomas E:
> > 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?

> Hmmm... seems to be the status register?

Yes, that's expected.

> 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.

-- 
dwmw2

Re: cfi 0001

[Nicolas Pitre]

On Mon, 20 Mar 2006, Tomas E wrote:

> Hi,
> 
> I have a problem with writing to a Intel Strata flash
> and then doing a warm reset.

How do you "warm reset" ?

> 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?

> 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.

> What should I do to debug this?

First you should tell us a bit more about your board reset.


Nicolas

Re: cfi 0001

[Tomas]

Nicolas Pitre <nico@cam.org> skrev den Mon, 20 Mar 2006 11:08:19 -0500 
(EST):
Hi,

> On Mon, 20 Mar 2006, Tomas E wrote:
>
>> 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.

>
>> 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.

>
>> 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?

>
>> What should I do to debug this?
>
> First you should tell us a bit more about your board reset.
>
>
> Nicolas
>

Tomas

Re: cfi 0001

[Nicolas Pitre]

On Mon, 20 Mar 2006, Tomas wrote:

> Nicolas Pitre <nico@cam.org> skrev den Mon, 20 Mar 2006 11:08:19 -0500 (EST):
> Hi,
> 
> > On Mon, 20 Mar 2006, Tomas E wrote:
> > 
> > > 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.

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

Re: cfi 0001

[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?

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

Re: cfi 0001

[Josh Boyer]

On 3/21/06, Tomas <Tomas2003@home.se> wrote:
> 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.

> 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

Re: cfi 0001

[Nicolas Pitre]

On Tue, 21 Mar 2006, Tomas wrote:

> 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.

> 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