[flashrom] Atmel AT49LH002 support missing

Uwe Hermann uwe at hermann-uwe.de
Thu Sep 8 22:08:01 CEST 2011


On Fri, Jul 22, 2011 at 09:37:22AM +0200, Stefan Tauner wrote:
> > Please test the attached patch and post a verbose (-V) log.

Thanks, forward-ported to trunk and changed some things, committed as r1434.

There are a few TODOs left in the code, and we'll also need someone to
actually test on hardware.

 
> > Index: flashchips.c
> > ===================================================================
> > --- flashchips.c	(revision 1380)
> > +++ flashchips.c	(working copy)
> > @@ -2305,6 +2305,36 @@
> >  	},
> >  
> >  	{
> > +		.vendor		= "Atmel",
> > +		.name		= "AT49LH002",
> > +		.bustype	= CHIP_BUSTYPE_LPC | CHIP_BUSTYPE_FWH, /* A/A Mux */

Changed to BUS_LPC | BUS_FWH.


> > +		.manufacture_id	= ATMEL_ID,
> > +		.model_id	= ATMEL_AT49LH002,
> > +		.total_size	= 256,
> > +		.page_size	= 8 * 1024,
>                                 ^ dunno about this one.
> i am not familiar (with page sizes of) LPC/FWH chips.

I made this 

		.total_size	= 0, /* unused */

for now. It's used in unlock_82802ab() but I dropped that too, see
below. The 8kB size is not correct I think. As far as I can see this
would only work for uniform 8kB lockable blocks, but this chip has
non-uniform lock-blocks of various sizes. I think a different unlock
function has to be written, and page_size will not be needed/useful for
that. Someone please correct me if this is wrong.


> > +		.feature_bits	= FEATURE_REGISTERMAP,
> same here, although i think it is correct

Looks OK to me (for FWH mode). In LPC mode the registers are in a
different place, that might need some investigation, not sure how to
handle it.


> > +		.tested		= TEST_UNTESTED,

Left it as untested, as we don't know if it works (and parts of the code
are TODO).


> > +		.probe		= probe_82802ab,
> same, but seems to be correct to be naive eyes from looking at the
> probe_82802ab code.

Looks OK, except that 0xff (reset cmd according to code comments) is
used there, but that's not documented in the datasheet for this chip.
Maybe just an omission, maybe optional and harmless to still do the
0xff? Not sure. I left it in for now, if someone tests the chip we'll
know if it's needed or must be removed.


> > +		.probe_timing	= 1,
> same, and i could not verify that

Changed to TIMING_FIXME, coulnd't find the resp. value mentioned in the
datasheet upon a quick look.

 
> there is also a uniform erase that combines the last 4 to one sector.
> i.e. 
> 				.eraseblocks = {
> 					{64 * 1024, 4},
>                                 },
> the opcode is 20H. i did not look further. would be nice to support that
> too, if that's easily possible.

Yup, added the entry, but left the erase-fn as NULL, can be implemented
in a follow-up patch.


> > +		.unlock		= unlock_82802ab,
> > +		.write		= write_82802ab,
> > +		.read		= read_memmapped,
> dunno about those 3.

read_memmapped() and write_82802ab() are OK, unlock_82802ab() will
probably not work, see above, do I dropped it.

 
Uwe.
-- 
http://hermann-uwe.de     | http://sigrok.org
http://randomprojects.org | http://unmaintained-free-software.org




More information about the flashrom mailing list