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.