[coreboot] [solved] Re: [Flashrom] No EEPROM/flash device found. on Syntax SV266A

[Paul Menzel]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090322/4d98e34a/attachment.sig>