cfi_cmdset_0002 and writes

cfi_cmdset_0002 and writes

[Tim Hockin]

ok, so I've got (in mylocal CVS, not checked in) some code that sets up our
flash ROM.  I have the MTD layer reading my device just fine.

What I DON'T have is writing working.

I don't know how the other devices supported by cfi_cmdset_0002 work, but
let me explain how our flash works.  I am hoping someone can then explain
to me how cfi_cmdset_0002 can work.

The flash can be erased by 64k blocks.  Since it is flash, you can only
reprogram '1' bits to '0' bits, and never vice versa.  What I don't find is
any hooks in cfi_cmdset_0002 to read a whole block, erase it, make changes
to the in-memory block and write it back to flash.

How/where does it do this?  Or are all the other chips that use this cmdset
more flexible?  Obviosuly, we don't want to do that for every write.


In my previous incarnation of a flashrom driver, the driver created the in
buffer shadow whenever a write occurred to a block. Then, on fsync() would
flush all the block back to flash.

Secondly, the specs call for specific spin checks (checkin the high bot of
each byte) rather than wait-times.

Is the existing model going to work for me at all?

feeling frustrated,
Tim


-- 
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
thockin@sun.com

Re: cfi_cmdset_0002 and writes

[David Woodhouse]

thockin@sun.com said:
>  The flash can be erased by 64k blocks.  Since it is flash, you can
> only reprogram '1' bits to '0' bits, and never vice versa.  What I
> don't find is any hooks in cfi_cmdset_0002 to read a whole block,
> erase it, make changes to the in-memory block and write it back to
> flash.

> How/where does it do this? 

It doesn't. Doing that kind of thing is scary and dangerous, and certainly
doesn't belong in the low-level driver. We have real filesystems and
translation layers which work on flash instead.

However, the primitive read/erase/modify/pray_we_don't_lose_power/writeback
behaviour you described is available in the 'mtdblock' driver, and it's sane
enough to use it if you only write to it during setup, then run it normally
in read-only mode.

--
dwmw2

Re: cfi_cmdset_0002 and writes

[David Woodhouse]

thockin@sun.com said:
>  Secondly, the specs call for specific spin checks (checkin the high
> bot of each byte) rather than wait-times. 

On erase, that's what we do, isn't it?

	rdy_mask = CMD(0x80);
	while ( ( (status = cfi_read(map,adr)) & rdy_mask ) != rdy_mask ) {

For writes, we watch the toggling bit and continue when either it stops
toggling or we've timed out.

--
dwmw2

Re: cfi_cmdset_0002 and writes

[Tim Hockin]

David Woodhouse wrote:
> 
> thockin@sun.com said:
> >  The flash can be erased by 64k blocks.  Since it is flash, you can
> > only reprogram '1' bits to '0' bits, and never vice versa.  What I
> > don't find is any hooks in cfi_cmdset_0002 to read a whole block,
> > erase it, make changes to the in-memory block and write it back to
> > flash.

> It doesn't. Doing that kind of thing is scary and dangerous, and certainly
> doesn't belong in the low-level driver. We have real filesystems and
> translation layers which work on flash instead.

Right, but this is our boot ROM we're dealing with :)  Can you suggest a
better alternative?  The device is rarely ever loaded, but when it is
loaded we want to read and re-program the whole thing as safely as
possible.

MTD seems to be geared more towards flash devices that get lots of use. 
How should I go about plugging this into MTD?
 
> However, the primitive read/erase/modify/pray_we_don't_lose_power/writeback
> behaviour you described is available in the 'mtdblock' driver, and it's sane
> enough to use it if you only write to it during setup, then run it normally
> in read-only mode.

We'll be loading the driver for our flash after potentially months of
uptime.  The new image will be flashed in, and the driver will be unloaded
until the next flash update.


-- 
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
thockin@sun.com

Re: cfi_cmdset_0002 and writes

[David Woodhouse]

thockin@sun.com said:
>  Right, but this is our boot ROM we're dealing with :)  Can you
> suggest a better alternative?  The device is rarely ever loaded, but
> when it is loaded we want to read and re-program the whole thing as
> safely as possible. 

It's sane enough. Just loading the 'mtdblock' driver will give you exactly 
the semantics you described. Alternatively, use the raw chardevice driver, 
and you have to issue the MEMERASE ioctl before rewriting a sector. There 
are utilities in CVS which do this for you, given an MTD device and a file 
to load into it.

Either way, the underlying flash device driver only deals with the physical 
capabilities of the flash chip. What you do on top of that is none of its 
business.

--
dwmw2

Re: cfi_cmdset_0002 and writes

[Bjorn Wesen]

On Wed, 18 Jul 2001, Tim Hockin wrote:
> Right, but this is our boot ROM we're dealing with :)  Can you suggest a
> better alternative?  The device is rarely ever loaded, but when it is
> loaded we want to read and re-program the whole thing as safely as
> possible.

If you have the space or can make space, the standard way is to
double-buffer the sector in question. Write a new one at a spare sector
with a checksum and sequence number, then after that erase the first
one. So if it crashes you always have at least one sane copy. 

If your code requires one sector, and you have a flash with at least 3
sectors, put code to choose the sane sector in sector 0 (the one which is
booted) and use sectors 1 and 2 for the boot code itself. And never update
sector 0 :) 

/Bjorn