[coreboot] [solved] Re: [Flashrom] No EEPROM/flash device found. on Syntax SV266A
paulepanter at users.sourceforge.net
Sun Mar 22 08:25:19 CET 2009
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
Thanks for your help so far.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
More information about the coreboot