How to cope with locked flash

How to cope with locked flash

[Konstantin Kletschke]

How do you people cope with flash devices that power up locked?

I have intel K3 devices which are unlocked by flash_unlocke in the /etc/inittab
while booting the system.
However, if the fs was never mounted before the jffs2 hangs with this
in an endless loop:

jffs2_write_dirent in garbage_collect_dirent failed: -30
Write of 43 bytes at 0x00363928 failed. returned -30, retlen 0
Not marking the space at 0x00363928 as dirty because the flash driver returned retlen zero

Is there any help to avoid this situation?

Konsti

PS.: sorry, I missed the subject in my mail before so it looks like
spam :( I am still trying to get used to my new MUA :-/


-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

Re: How to cope with locked flash

[Todd Poynor]

Konstantin Kletschke wrote:
> How do you people cope with flash devices that power up locked?
> 
> I have intel K3 devices which are unlocked by flash_unlocke in the /etc/inittab
> while booting the system.
> However, if the fs was never mounted before the jffs2 hangs with this
> in an endless loop:
> 
> jffs2_write_dirent in garbage_collect_dirent failed: -30
> Write of 43 bytes at 0x00363928 failed. returned -30, retlen 0
> Not marking the space at 0x00363928 as dirty because the flash driver returned retlen zero
> 
> Is there any help to avoid this situation?

Sounds like your root fs is jffs2; if so I'd suggest using a read-only 
partition for root (using fs such as cramfs), unlock writeable jffs2 
partition from rc script, then mount jffs2.  (It's probably a good thing 
to allow access to system files while the writeable partition is being 
erased/written anyhow, assuming there are multiple chips or the chips 
handle concurrent reads/writes from different chip partitions.)

Some people hack the kernel to unlock writeable partitions during the 
boot sequence.  One of these days should look at adding flags to jffs2 
to unlock the flash at mount time.

Hope that helps,

-- 
Todd

Re: How to cope with locked flash

[Jörn Engel]

On Thu, 15 September 2005 09:38:51 -0700, Todd Poynor wrote:
> 
> Some people hack the kernel to unlock writeable partitions during the 
> boot sequence.  One of these days should look at adding flags to jffs2 
> to unlock the flash at mount time.

We created a patch for our bootloader to do the work.  If the
bootloader needs flash write support anyway, it is the natural place
for the code.

Next best thing, imo, would be the mtd mapping driver.  JFFS2 should
stay clear of this, if possible.  We should aim to isolate hardware
stuff to drivers/mtd/ and keep fs/* unaware.  Some things like wbuf
require fs knowledge, but unlock doesn't.

Jörn

-- 
Those who come seeking peace without a treaty are plotting.
-- Sun Tzu

Re: How to cope with locked flash

[Todd Poynor]

Jörn Engel wrote:

> Next best thing, imo, would be the mtd mapping driver.  JFFS2 should
> stay clear of this, if possible.  We should aim to isolate hardware
> stuff to drivers/mtd/ and keep fs/* unaware.  Some things like wbuf
> require fs knowledge, but unlock doesn't.

Last time I sent a chip-driver-level patch (which knows the power-up 
locking behavior for the particular chips, it was rather ugly since it 
needed a notifier to know when writeable partitions were added), at 
which time the JFFS2 alternative was suggested.  An explicit call from 
the map driver, after parititions are registered, to the chip driver 
should work, avoiding the need for a notifier, and the map driver has 
the "master" struct mtd handle needed for info on the locking behavior 
of the chip (unlock is slow on some chips, best avoided if not needed). 
  I'll float a patch soon.

-- 
Todd