Re: [flashrom] Atmel AT49LH002 support missing

[Mattias Mattsson]

On Fri, Jul 15, 2011 at 02:34:07PM -0300, Marcos Felipe Rasia de Mello wrote:
> 2011/7/15 Stefan Tauner <[e-mail]>:
> > jup, this one is not supported yet.
> > the datasheet can for example be found here:
> > http://www.datasheetcatalog.org/datasheet/atmel/doc3377.pdf
> > it supports LPC and FWH so it may share some characteristics with the
> > Pm49FL002. patches are welcome ;)
>
> Thank you for the information. Unfortunately I won't stay much time
> with this board to test it, in case someone add support for the chip.

Please test the attached patch and post a verbose (-V) log.


Thanks,
-mattias

Atmel AT49LH002 support missing

[Stefan Tauner]

On Fri, 22 Jul 2011 08:46:12 +0200
Mattias Mattsson <[e-mail]> wrote:
> On Fri, Jul 15, 2011 at 02:34:07PM -0300, Marcos Felipe Rasia de Mello wrote:
> > 2011/7/15 Stefan Tauner <[e-mail]>:
> > > jup, this one is not supported yet.
> > > the datasheet can for example be found here:
> > > http://www.datasheetcatalog.org/datasheet/atmel/doc3377.pdf
> > > it supports LPC and FWH so it may share some characteristics with the
> > > Pm49FL002. patches are welcome ;)
> >
> > Thank you for the information. Unfortunately I won't stay much time
> > with this board to test it, in case someone add support for the chip.
>
> Please test the attached patch and post a verbose (-V) log.
> 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 */
> +		.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.
> +		.feature_bits	= FEATURE_REGISTERMAP,
> same here, although i think it is correct
> +		.tested		= TEST_UNTESTED,
> +		.probe		= probe_82802ab,
> same, but seems to be correct to be naive eyes from looking at the
> probe_82802ab code.
> +		.probe_timing	= 1,
> same, and i could not verify that
> +		.block_erasers	=
> +		{
> +			{
> +				.eraseblocks = {
> +					{64 * 1024, 3},
> +					{32 * 1024, 1},
> +					{8 * 1024, 2},
> +					{16 * 1024, 1},
> +				},
> +				.block_erase = erase_block_82802ab,
> +			}
> +		},
> 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.
> +		.unlock		= unlock_82802ab,
> +		.write		= write_82802ab,
> +		.read		= read_memmapped,
> dunno about those 3.
> +		.voltage	= {3000, 3600},
> +	},
> +
> +	{
>       .vendor		= "Bright",
>       .name		= "BM29F040",
>       .bustype	= CHIP_BUSTYPE_PARALLEL,
> Index: flashchips.h
> ===================================================================
> --- flashchips.h	(revision 1380)
> +++ flashchips.h	(working copy)
> @@ -184,6 +184,7 @@
>  #define ATMEL_AT49F020		0x0B
>  #define ATMEL_AT49F002N		0x07	/* for AT49F002(N)  */
>  #define ATMEL_AT49F002NT		0x08	/* for AT49F002(N)T */
> +#define ATMEL_AT49LH002		0xE9
>
> /* Bright Microelectronics has the same manufacturer ID as Hyundai... */
>  #define BRIGHT_ID		0xAD	/* Bright Microelectronics */

everything else is
Acked-by: Stefan Tauner <[e-mail]>
-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

Atmel AT49LH002 support missing

[Uwe Hermann]

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

Atmel AT49LH002 support missing

[Marcos Felipe Rasia de Mello]

2011/7/22 Mattias Mattsson <[e-mail]>:
> On Fri, Jul 15, 2011 at 02:34:07PM -0300, Marcos Felipe Rasia de Mello wrote:
> > 2011/7/15 Stefan Tauner <[e-mail]>:
> > > jup, this one is not supported yet.
> > > the datasheet can for example be found here:
> > > http://www.datasheetcatalog.org/datasheet/atmel/doc3377.pdf
> > > it supports LPC and FWH so it may share some characteristics with the
> > > Pm49FL002. patches are welcome ;)
> >
> > Thank you for the information. Unfortunately I won't stay much time
> > with this board to test it, in case someone add support for the chip.
>
> Please test the attached patch and post a verbose (-V) log.

Sorry, I don't have it anymore. :( If I get another one, I'll test it.

Marcos