cfi_cmdset_0002 and writes
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
Signature · 4 lines
Tim Hockin Systems Software Engineer Sun Microsystems, Cobalt Server Appliances [email protected]
Quoted 7 lines · [email protected] 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 incfi_cmdset_0002to 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
Quoted 11 lines · David Woodhouse
Quoted 5 lines · [email protected] 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 incfi_cmdset_0002to 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?
Quoted 4 lines
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.
Signature · 4 lines
Tim Hockin Systems Software Engineer Sun Microsystems, Cobalt Server Appliances [email protected]
Quoted 4 lines · [email protected] 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
Quoted 4 lines · Tim Hockin
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
Quoted 2 lines · [email protected] 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