On Fri, Jul 15, 2011 at 02:34:07PM -0300, Marcos Felipe Rasia de Mello wrote:
2011/7/15 Stefan Tauner stefan.tauner@student.tuwien.ac.at:
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
On Fri, 22 Jul 2011 08:46:12 +0200 Mattias Mattsson vitplister@gmail.com wrote:
On Fri, Jul 15, 2011 at 02:34:07PM -0300, Marcos Felipe Rasia de Mello wrote:
2011/7/15 Stefan Tauner stefan.tauner@student.tuwien.ac.at:
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 stefan.tauner@student.tuwien.ac.at
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.
2011/7/22 Mattias Mattsson vitplister@gmail.com:
On Fri, Jul 15, 2011 at 02:34:07PM -0300, Marcos Felipe Rasia de Mello wrote:
2011/7/15 Stefan Tauner stefan.tauner@student.tuwien.ac.at:
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