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:n3ph@terminal21.de>> 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.