Intel 28F640 cfi_cmdset_0001 chip is FL_STATUS after MTD_close

Intel 28F640 cfi_cmdset_0001 chip is FL_STATUS after MTD_close

[Cam]

Hello,

I hope I have the right list for this question.

I'm looking into a problem with some Intel 28F640 flash on a powerPC 
board. I find that the cfi_cmdset_0001 code leaves the flash in the 
FL_STATUS state after MTD_close. The chips remain in this state which 
leaves the memory unreadable.

I would have expected the flash to be left in the read array state when 
not in use.

I think the chip status in the driver and that in the chip is in sync, 
ie. the driver is deliberately leaving the chip in this state.

I found a previous reference to a similar problem:

http://lists.infradead.org/pipermail/linux-mtd/2001-November/003603.html

The problem described there is more serious in that the chip and the 
driver seem to get out of step with regards to the FL_STATUS state.

Is there a reason why the chip is not left in the read array state after 
an MTD_close? My first thought is to modify cfi_intelext_sync, called by 
MTD_close so that the chip is left in the read array state after the 
sync command, but being a newcomer to this code I might be missing 
something important.

Comments?

-Cam
-- 
camilo@mesias.co.uk                                                 <--

Re: Intel 28F640 cfi_cmdset_0001 chip is FL_STATUS after MTD_close

[David Woodhouse]

On Wed, 2004-02-11 at 15:17 +0000, Cam wrote:
> I would have expected the flash to be left in the read array state when 
> not in use.

Why? If we've just finished writing to the device, and we're about to
write to the device again... why change it into read mode?

> Is there a reason why the chip is not left in the read array state after 
> an MTD_close? My first thought is to modify cfi_intelext_sync, called by 
> MTD_close so that the chip is left in the read array state after the 
> sync command, but being a newcomer to this code I might be missing 
> something important.

Mostly if you're going to need this it's because you forgot to wire up
the RESET line to the flash chips properly, and you're already going to
die if the user hits the RESET button at the wrong time, or reboots or
hits SysRq-B, etc. I prefer not to work around this in the generic code,
since it's actually helpful for some people to realise this problem
early on. 

-- 
dwmw2

Re: Intel 28F640 cfi_cmdset_0001 chip is FL_STATUS after MTD_close

[Cam]

David

Thanks for the speedy reply,

>>I would have expected the flash to be left in the read array state when 
>>not in use.
> 
> 
> Why? If we've just finished writing to the device, and we're about to
> write to the device again... why change it into read mode?

After the mtd device has been closed, is it not perverse to leave the 
chips unredable? I don't mind if they are showing FL_STATUS while the 
device is busy.

> Mostly if you're going to need this it's because you forgot to wire up
> the RESET line to the flash chips properly, and you're already going to
> die if the user hits the RESET button at the wrong time, or reboots or
> hits SysRq-B, etc. I prefer not to work around this in the generic code,
> since it's actually helpful for some people to realise this problem
> early on. 

It seems as if the linux commands erase and dd behave strangely on my 
board, although what you say about the reset line is also true (I had 
already emailed the board designer).

I have a patch to leave the chip (and driver) in FL_READY state after 
sync, but it sounds like no-one will be interested.

-Cam


-- 
camilo@mesias.co.uk                                                 <--

Re: Intel 28F640 cfi_cmdset_0001 chip is FL_STATUS after MTD_close

[David Woodhouse]

On Wed, 2004-02-11 at 15:44 +0000, Cam wrote:
> After the mtd device has been closed, is it not perverse to leave the 
> chips unredable? I don't mind if they are showing FL_STATUS while the 
> device is busy.

You might consider it perverse. On the other hand, I consider it _more_
perverse to paper over hardware problems, given that anything we could
do wouldn't be 100% reliable. :)

> I have a patch to leave the chip (and driver) in FL_READY state after 
> sync, but it sounds like no-one will be interested.

I wonder if you'd do better to do it in machine_restart() or register a
reboot notifier.

-- 
dwmw2