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