[flashrom] [PATCH] Add preliminary support for AMIC chips with uniform 4kB sectors

[Carl-Daniel Hailfinger]

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 at gmx.net>

Thanks for your patch, committed in r1118.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/