On Thu, 2010-07-29 at 17:05 +0200, Carl-Daniel Hailfinger wrote:
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.
I had found an early (version number <1.0) version of the A25L020/A25L010/A25L512 datasheet that listed these, but I'm unfortunately not finding it now. It doesn't appear in any of the versions >=1.0, so it's probably wrong.
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.
I took a look at the at25f* unlock functions. If I understand correctly, they involve various manipulations of the standard 1-byte status register.
The A25L032/Q032 will require new functions to read and write the 2-byte status register. The good thing is that the standard commands can be used except when manipulating the second byte, AFAICT. Would you prefer one big ugly function to do the whole thing, or factor things out into separate functions to read/write the 2-byte SR?
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.
Perhaps a FEATURE_UNHANDLED_OTP bit (or something more concise to that effect) could be designed, which would just give a warning prior to read/write/erase? Something like the FEATURE_EVIL_TWIN bit that you proposed to warn about pairs like the A25L40P{T,U}.
I've coded up a small patch for that, to follow.
Dan