Am Sonntag, den 22.03.2009, 01:43 +0100 schrieb Carl-Daniel Hailfinger:
On 21.03.2009 22:59, Paul Menzel wrote:
Am Samstag, den 21.03.2009, 19:23 +0100 schrieb Carl-Daniel Hailfinger:
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?
The delay should not influence the dump, but the id1, id2 responses. If id1,id2 were the same for all delays, that means the delay is irrelevant to the problem. Either the writes are not passed through or they are mangled by cache effects. It would be interesting to know the MTRR settings (/proc/mtrr) of that machine.
$ cat /proc/mtrr reg00: base=0x00000000 ( 0MB), size= 512MB: write-back, count=1 reg01: base=0xd0000000 (3328MB), size= 128MB: write-combining, count=1 reg02: base=0xd0000000 (3328MB), size= 128MB: write-combining, count=1 reg03: base=0xd8000000 (3456MB), size= 64MB: write-combining, count=1
An area can be covered by multiple MTRRs. As long as at least one MTRR covering the area is "uncachable", everything is OK. If no MTRR is covering the area, you have to find out MTRRdefType (no idea how to do this without a special program).
If you have time for it, extending flashrom to read MTRRs and calculate ROM cache settings would be great!
In addition to not much time, I also do not have any knowledge about this stuff. So this is not something to expected from me in the near future. Sorry.
Thanks for your help so far.
Paul