On 24.07.2010 23:22, Daniel Lenski wrote:
On Sat, 2010-07-24 at 10:16 +0200, Carl-Daniel Hailfinger wrote:
General remark: Can you order the eraseblock definitions by eraseblock size (smallest one first)? This allows us to use a better reflashing granularity in the first write/erase attempt, and reserves bigger granularities for the case where smaller granularities fail.
Got it, done.
I can't find the 52h SPI opcode in the datasheet. I can't find the 60h SPI opcode in the datasheet. (etc.)
Changed these. I found other versions of the datasheets that suggested these were valid and had been inadvertently omitted... but I think I'm probably erring on the wrong side of caution by doing that.
flashrom can deal fine with failing erase, so if you can dig up those datasheets again, please send a followup patch which adds those SPI erase opcodes again. I had assumed you were extrapolating, but having solid data is an entirely different thing. And yes, datasheets often contradict each other.
Can you add a comment so it looks like this:
.unlock = NULL, /* Two-byte status reg */Done. I made a careless mistake, which is that only the 032 and Q032 chips have the two-byte status reg and more complex protection features. The smaller-capacity ones can still use the standard spi_disable_blockprotect unlock function. I have corrected this in the patch.
OK. I have added support for some Atmel chips which need a more complicated unlocking, and maybe that can serve as a template for you. In the interest of full disclosure I should say that the structure of my unlock functions for AT25* is suboptimal, and probably would benefit from some generalization and/or refactoring.
One other feature of the A25L032 and A25LQ032 chips which Flashrom may want to be aware of: they have 64 bytes of one-time-programmable memory on them. Is reading/writing this outside the scope of Flashrom? I assume they'd be used for serial numbers or crypto keys... and it might be misleading to assume Flashrom was completely backing up/restoring a BIOS image if it can't read and write this OTP region.
Good point. Given that those are accessible with special commands only, and are not "normal" flash contents per se, I feel it is OK to ignore them for now. Future flashrom versions will have an interface which allows running arbitrary commands, and that interface could be used for OTP and security regions.
Revised patch is attached, with revised description.
Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Thanks for your patch, committed in r1118.
Regards, Carl-Daniel