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 <[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.

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...

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 <[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.