Flash left in a write mode

Flash left in a write mode

[Allen Curtis]

I have observed a problem where the flash is left in a write mode even after
the file-system is unmounted. (Intel Strata flash, cmdset_0001.c)

The problem is this: if the flash is written to and then the system is
immediately rebooted, the flash is left in a write state. (if you read it
you get status information not flash contents.) If you then try to boot off
of this device, it will fail. If you read the flash, with a "dd" command for
instance, then you can reboot successfully.

I am surprised that this problem has not been reported. It should be an easy
fix. (something that I will handle in BIOS code until it is patched.)

Thanks

Re: Flash left in a write mode

[Arne Jonsson]

Hi!

Another problem is when you have your interrupt vectors stored
in the flash you are accessing.
If you get an interrupt and have unlocked the flash your interrupt
vectors are not seen by the CPU, and off you go into the deep binary
space.
I had to disable interrupts at all times when the flash was "unlocked".
Maybe this is something that we could have a switch/define for ?
Putting the boot address and hard interrupt vectors in the same address
range
is IMHO _very_ bad chip design.
Another approach would be to have external hardware for the boot vector,
switching to the flash and have RAM at the address of the interrupt
vectors, but the extra HW is an extra cost.

Best regards,
/Arne Jonsson

-- 
Arne Jonsson
i3 micro technology AB
Phone:+46-8-506 388 00
Fax:  +46-8-506 388 75

RE: Flash left in a write mode

[Allen Curtis]

Luckily our boot ROM is not the same device as the flash file-system.
Another recommendation for hardware designers. Separate your flash
functions.

Thanks for the feedback.

> -----Original Message-----
> From: linux-mtd-admin@lists.infradead.org
> [mailto:linux-mtd-admin@lists.infradead.org]On Behalf Of Arne Jonsson
> Sent: Thursday, February 07, 2002 11:06 PM
> To: acurtis@onz.com
> Cc: linux-mtd@lists.infradead.org
> Subject: Re: Flash left in a write mode
>
>
> Hi!
>
> Another problem is when you have your interrupt vectors stored
> in the flash you are accessing.
> If you get an interrupt and have unlocked the flash your interrupt
> vectors are not seen by the CPU, and off you go into the deep binary
> space.
> I had to disable interrupts at all times when the flash was "unlocked".
> Maybe this is something that we could have a switch/define for ?
> Putting the boot address and hard interrupt vectors in the same address
> range
> is IMHO _very_ bad chip design.
> Another approach would be to have external hardware for the boot vector,
> switching to the flash and have RAM at the address of the interrupt
> vectors, but the extra HW is an extra cost.
>
> Best regards,
> /Arne Jonsson
>
> --
> Arne Jonsson
> i3 micro technology AB
> Phone:+46-8-506 388 00
> Fax:  +46-8-506 388 75
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: Flash left in a write mode

[David Woodhouse]

On Fri, 8 Feb 2002, Arne Jonsson wrote:

> Hi!
> 
> Another problem is when you have your interrupt vectors stored
> in the flash you are accessing.
> If you get an interrupt and have unlocked the flash your interrupt
> vectors are not seen by the CPU, and off you go into the deep binary
> space.

Can't you move the interrupt vectors? At least by using the MMU?

What CPU are you using?

-- 
dwmw2

Re: Flash left in a write mode

[Adam Wozniak]

Allen Curtis wrote:
> 
> I have observed a problem where the flash is left in a write mode even after
> the file-system is unmounted. (Intel Strata flash, cmdset_0001.c)
> 
> The problem is this: if the flash is written to and then the system is
> immediately rebooted, the flash is left in a write state. (if you read it
> you get status information not flash contents.) If you then try to boot off
> of this device, it will fail. If you read the flash, with a "dd" command for
> instance, then you can reboot successfully.
> 
> I am surprised that this problem has not been reported. It should be an easy
> fix. (something that I will handle in BIOS code until it is patched.)

Yeah, I've seen that.  I patched my reboot code to always throw the
flash
into read mode.

--Adam
-- 
Adam Wozniak (KG6GZR)   COM DEV Wireless - Digital and Software Systems
awozniak@comdev.cc      3450 Broad St. 107, San Luis Obispo, CA 93401
                        http://www.comdev.cc
                        Voice: (805) 544-1089       Fax: (805) 544-2055

Re: Flash left in a write mode

[David Woodhouse]

On Thu, 7 Feb 2002, Allen Curtis wrote:

> I have observed a problem where the flash is left in a write mode even after
> the file-system is unmounted. (Intel Strata flash, cmdset_0001.c)
> 
> The problem is this: if the flash is written to and then the system is
> immediately rebooted, the flash is left in a write state. 

Define 'rebooted'? Hitting the reset button if you have one should reset 
the flash (although sometimes it doesn't - bogus f***wit points to whoever 
designed the Assabet for that one)

If you're implementing machine_restart() for your platform, then it should 
be ensuring that the hardware is in a state sufficiently close to the 
power-up state, for the benefit of the bootloader. That means turning off 
the MMU and jumping to the startup vector, at the very least. Often it 
means resetting bus controllers where we've moved around the physical 
memory map too - it could be argued that this preparation should include 
resetting the flash too.

I'm willing to entertain the notion that the flash driver should do this 
on close, or we should have a reboot notifier registered that calls a new 
method in the mtd_info to reset the flash. 

I'll consider if it a clean patch is presented - but I'm not going to go 
out of my way to fix it myself - I don't consider it particularly broken.

-- 
dwmw2

RE: Flash left in a write mode

[Allen Curtis]

> Define 'rebooted'? Hitting the reset button if you have one should reset
> the flash (although sometimes it doesn't - bogus f***wit points
> to whoever
> designed the Assabet for that one)
>
> If you're implementing machine_restart() for your platform, then
> it should
> be ensuring that the hardware is in a state sufficiently close to the
> power-up state, for the benefit of the bootloader. That means turning off
> the MMU and jumping to the startup vector, at the very least. Often it
> means resetting bus controllers where we've moved around the physical
> memory map too - it could be argued that this preparation should include
> resetting the flash too.

This is a normal reboot operation. Calling machine_restart() and jumping
into the boot ROM. I don't believe that this is the proper place to reset
the flash or any other optional feature of a system. All cleanup operations
for optional components should be localized to that components
implementation.

> I'll consider if it a clean patch is presented - but I'm not going to go
> out of my way to fix it myself - I don't consider it particularly broken.

I will work on a fix that is implemented with the rest of the driver code.
As for being broken, it is.... I don't have to patch my hard driver code to
get the system to reboot reliably. My guess is that may of the users of
these libraries are embedded systems programmers, who do not have hard
drives and are using the flash as their root file system. If your primary
boot device does not work reliably, it is broken.

Re: Flash left in a write mode

[Kenneth Johansson]

David Woodhouse wrote:
 
> I'm willing to entertain the notion that the flash driver should do this
> on close, or we should have a reboot notifier registered that calls a new
> method in the mtd_info to reset the flash.

Is this needed ?? I have never seen a reboot without some type of reset
signal sent by the CPU. Not connecting that to the FLASH is the bug.


-- 
Kenneth Johansson	
Ericsson Telecom                  Tel: +46 8 404 71 83
Viderögatan 3                     Fax: +46 8 404 72 72
164 80 Stockholm                  kenneth.johansson@etx.ericsson.se