problem with strataflash after suspend and resume

problem with strataflash after suspend and resume

[Ian Campbell]

Hi,

I have a PXA255 (Xscale/ARM) platform with a strataflash part on it
(28F128J3). With 2.6.11.11 (the only previous version I have convenient
access to) I can suspend and resume repeatedly just fine, however with
2.6.13-rc7 I occasionally get something like this just after resume:

        Waiting for chip to be ready timed out. Status 0
        Write of 68 bytes at 0x00b99f3c failed. returned -5, retlen 0
        Not marking the space at 0x00b99f3c as dirty because the flash driver returned retlen zero

Any attempt to write a file results in a similar message.

Once it has occurred it seems to happen every time unless I do an
mtd-unlock. Doing an mtd-unlock on the device seems to fix it (most of
the time) even though I don't think the device is locked (I didn't lock
it and J3 parts don't reset locked). I've occasionally observed that
just doing "dd if=/dev/mtd1 of=/dev/null bs=1 count=0" seems to work
too. Other times it seems to sort itself out if left alone for a bit
(but not consistently).

The error originates in drivers/mtd/chips/cfi_cmdset_0001.c get_chip()
which is returning EIO at line 659. The call is made via
cfi_intelext_write_buffers() which calls do_write_buffer() which calls
get_chip().

I've seen status 0 as well as 0xF018, 0xFF0A, 0x203A, 0x4946, 0x7465,
0x312e -- none of which appear to make much sense and I suspect they are
just garbage.

I also occasionally see "SR.4 or SR.5 bits set in buffer write (status
8dff). Clearing." after resume but they don't appear to be a problem...

The flash would appear to be readable, since resuming involves running
the very early parts of the bootloader, which is stored in flash.

I've also tried using the latest MTD CVS stuff on top of 2.6.13-rc7 but
have the same problem.

Any ideas? I'd blame hardware if 2.6.11.11 didn't appear to work
flawlessly... (I can do 30+ suspend resume iterations with 2.6.11.11,
with 2.6.13-rc7 I'm lucky to get 4).

Thanks,
Ian.
-- 
Ian Campbell, Senior Design Engineer
                                        Web: http://www.arcom.com
Arcom, Clifton Road,                    Direct: +44 (0)1223 403 465
Cambridge CB1 7EA, United Kingdom       Phone:  +44 (0)1223 411 200

Re: problem with strataflash after suspend and resume

[Nicolas Pitre]

On Thu, 25 Aug 2005, Ian Campbell wrote:

> Hi,
> 
> I have a PXA255 (Xscale/ARM) platform with a strataflash part on it
> (28F128J3). With 2.6.11.11 (the only previous version I have convenient
> access to) I can suspend and resume repeatedly just fine, however with
> 2.6.13-rc7 I occasionally get something like this just after resume:
> 
>         Waiting for chip to be ready timed out. Status 0
>         Write of 68 bytes at 0x00b99f3c failed. returned -5, retlen 0
>         Not marking the space at 0x00b99f3c as dirty because the flash driver returned retlen zero
> 
> Any attempt to write a file results in a similar message.

This rings a bell...

> Once it has occurred it seems to happen every time unless I do an
> mtd-unlock. Doing an mtd-unlock on the device seems to fix it (most of
> the time) even though I don't think the device is locked (I didn't lock
> it and J3 parts don't reset locked). I've occasionally observed that
> just doing "dd if=/dev/mtd1 of=/dev/null bs=1 count=0" seems to work
> too. Other times it seems to sort itself out if left alone for a bit
> (but not consistently).

Yeah...  Anything that is likely to resynchronize the state machine with 
reality will do.

> The error originates in drivers/mtd/chips/cfi_cmdset_0001.c get_chip()
> which is returning EIO at line 659. The call is made via
> cfi_intelext_write_buffers() which calls do_write_buffer() which calls
> get_chip().
> 
> I've seen status 0 as well as 0xF018, 0xFF0A, 0x203A, 0x4946, 0x7465,
> 0x312e -- none of which appear to make much sense and I suspect they are
> just garbage.

They are probably just flash content.  0x203a is " :", 0x4946 is "IF", 
0x7465 is "te", 0x312e is "1." (or the other way around) and so on.

> The flash would appear to be readable, since resuming involves running
> the very early parts of the bootloader, which is stored in flash.

And that's the problem.  The flash is in data mode while the driver 
probably still thinks it is in status mode.

Make sure that cfi_intelext_suspend() gets called prior going to sleep 
and that cfi_intelext_resume() is called upon getting back from sleep 
mode.  If those calls don't take place you'll have inconsistent driver 
state, or worse inconsistent flash content.


Nicolas

Re: problem with strataflash after suspend and resume

[Todd Poynor]

Nicolas Pitre wrote:
> On Thu, 25 Aug 2005, Ian Campbell wrote:
>>I have a PXA255 (Xscale/ARM) platform with a strataflash part on it
>>(28F128J3). With 2.6.11.11 (the only previous version I have convenient
>>access to) I can suspend and resume repeatedly just fine, however with
>>2.6.13-rc7 I occasionally get something like this just after resume:
>>
>>        Waiting for chip to be ready timed out. Status 0
...
>>The flash would appear to be readable, since resuming involves running
>>the very early parts of the bootloader, which is stored in flash.
> 
> 
> And that's the problem.  The flash is in data mode while the driver 
> probably still thinks it is in status mode.
> 
> Make sure that cfi_intelext_suspend() gets called prior going to sleep 
> and that cfi_intelext_resume() is called upon getting back from sleep 
> mode.  If those calls don't take place you'll have inconsistent driver 
> state, or worse inconsistent flash content.

Since the bootloader is running I'll guess the PXA255 suspend mode 
chosen powers the system (and flash chips) down and up during 
suspend/resume (as do some PXA27x modes), so the mtd chip driver state 
machine is out of sync with the hardware state.  Those routines will 
force the hardware and software back to consistent state.  Getting those 
routines called involves adding LDM support and suspend/resume callbacks 
a la drivers/mtd/maps/sa1100-flash.c, and registering a platform_device 
in the board files.


-- 
Todd