Re: [coreboot] SPD CRC failed

[Michael Gerlach]

Okay here we go...

I memtested the modules again and as expected no defect was found. So i
retried latest master today and quite unusually it just boots up.

It does not reach payload-state still, but ram and frequency is detected
correctly. Fan is turning on and backlight gets activated but no output
is displayed. Besides it seems to die at unpredictable states. I
attached 3 different boot logs..

The only assumption could be a defect in some piece of hardware, but i
do not had any trouble with this x230 yet..

On the other hand _this_ build was compiled on the x230 itself, while
the other builds were compiled on a x201 with an identical bootstrapped
toolchain..

Any idea what possibly cause a similar behavior too?



Best regards,

n3ph


On 05/20/15 23:45, David Hendricks wrote:
  
 
 On Wed, May 20, 2015 at 1:13 PM, Michael Gerlach <n3ph(a)terminal21.de
 <mailto:[e-mail]>> wrote:
 
     -----BEGIN PGP SIGNED MESSAGE-----
     Hash: SHA1
 
     I forgot to mention that somehow the ram frequency is not detected
     correctly...
 
      PLL busy...done
     PLL didn't lock. Retrying at lower frequency
      PLL busy...done
     PLL didn't lock. Retrying at lower frequency
      PLL busy...done
     PLL didn't lock. Retrying at lower frequency
      PLL busy...done
     PLL didn't lock. Retrying at lower frequency
     No lock frequency found
 
 
 The SPD data should be read via SMBus long before PLL locking for the
 DRAM itself takes place.
 
 If you're unable to successfully read the SPDs, then it makes sense that
 later init would fail.
 
 -- 
 David Hendricks (dhendrix)
 Systems Software Engineer, Google Inc.

-- 
Bitte benutzt GPG: http://de.wikipedia.org/wiki/GNU_Privacy_Guard

SPD CRC failed

[Timothy Pearson]

On 05/21/2015 09:19 AM, Michael Gerlach wrote:
  Okay here we go...

 I memtested the modules again and as expected no defect was found. So i
 retried latest master today and quite unusually it just boots up.

 It does not reach payload-state still, but ram and frequency is detected
 correctly. Fan is turning on and backlight gets activated but no output
 is displayed. Besides it seems to die at unpredictable states. I
 attached 3 different boot logs..

 The only assumption could be a defect in some piece of hardware, but i
 do not had any trouble with this x230 yet..

 On the other hand _this_ build was compiled on the x230 itself, while
 the other builds were compiled on a x201 with an identical bootstrapped
 toolchain..

 Any idea what possibly cause a similar behavior too?



 Best regards,

 n3ph
If you suspect build variances please verify that your current git hash 
is the same on both systems, and that you are using the same coreboot 
toolchain on both.  Note that if you are using an older tree on one of 
the machines it may have retained an older crossgcc version.

If the trees are identical compare the romstage/ramstage sizes from both 
builds.  If they are significantly different there *might* be a problem...

-- 
Timothy Pearson
Raptor Engineering
[phone]
http://www.raptorengineeringinc.com

SPD CRC failed

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 21.05.2015 16:19, Michael Gerlach wrote:
  Okay here we go...
 
 I memtested the modules again and as expected no defect was found. So i
 retried latest master today and quite unusually it just boots up.
Quite possibly you were just missing microcode update.
  It does not reach payload-state still, but ram and
frequency is detected
 correctly. Fan is turning on and backlight gets activated but no output
 is displayed. Besides it seems to die at unpredictable states. I
 attached 3 different boot logs..
 
 The only assumption could be a defect in some piece of hardware, but i
 do not had any trouble with this x230 yet..
 
 On the other hand _this_ build was compiled on the x230 itself, while
 the other builds were compiled on a x201 with an identical bootstrapped
 toolchain..
 
 Any idea what possibly cause a similar behavior too?
It could be something with modules. They may have very unusual
high-frequency characteristics. I didn't see it occur with code that we
have currently but it remains a theoretical possibility.
  
 
 Best regards,
 
 n3ph
 
 
 On 05/20/15 23:45, David Hendricks wrote:
 

 On Wed, May 20, 2015 at 1:13 PM, Michael Gerlach <n3ph(a)terminal21.de
 <mailto:[e-mail]>> wrote:

     -----BEGIN PGP SIGNED MESSAGE-----
     Hash: SHA1

     I forgot to mention that somehow the ram frequency is not detected
     correctly...

      PLL busy...done
     PLL didn't lock. Retrying at lower frequency
      PLL busy...done
     PLL didn't lock. Retrying at lower frequency
      PLL busy...done
     PLL didn't lock. Retrying at lower frequency
      PLL busy...done
     PLL didn't lock. Retrying at lower frequency
     No lock frequency found


 The SPD data should be read via SMBus long before PLL locking for the
 DRAM itself takes place.

 If you're unable to successfully read the SPDs, then it makes sense that
 later init would fail.

 -- 
 David Hendricks (dhendrix)
 Systems Software Engineer, Google Inc.