Am Samstag, den 21.03.2009, 19:23 +0100 schrieb Carl-Daniel Hailfinger:
On 21.03.2009 18:57, Paul Menzel wrote:
Am Sonntag, den 22.03.2009, 01:28 +0800 schrieb FENG Yu Ning:
Paul Menzel wrote:
Right. Removing the sticker sure helps. Atmel AT49F002NT is written on the chip, which is supposed to be supported by Flashrom.
test.rom also has not only null written to it, so it seems to be working.
What could be done, that the chip is auto-detected?
Anything else I can do?
Since the reported IDs differ from those(id1 = 1Fh, id2 = 08h) in datasheet of AT49F002NT, I am not sure whether access to the flash is properly done. Let's do some investigation before going further.
You may want to take a closer look at test.rom.
- How do the first few bytes look like? Do they look like magic
numbers(0xff00, 0x55aa, ..)?
What is the correct command for doing this. hexdump first lines look like
0000000 e425 6c2d 3568 6f2d 0129 0000 0200 0000
OK, the ID cycle is not working. Basically, if the first two bytes of a dump are identical to id1,id2 then id1,id2 are not responses to the ID command. Try shorter (down to 10 us) or longer (up to 40 ms) delays in probe_jedec.
I did change the following myusec_delay() in probe_jedec() in jedec.c
/* Older chips may need up to 100 us to respond. The ATMEL 29C020 * needs 10 ms according to the data sheet. */ myusec_delay(10000);
I tried 10, 100, 1000, 10000 and 40000 (all us) and all produced identical images (checked with diff).
Can this happen? Or did I do something incorrectly?
By the way, using "xxd" or "hexdump -C" makes sure the bytes in the output are not switched around pairwise.
Thanks for the tip.
Bests,
Paul