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
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
-- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
