Re: [coreboot] [RFH] Status of the Lenovo X201

[Nicola Corna]

April 18, 2018 3:54 PM, "Kyösti Mälkki"  wrote:
> Having romstage stack smashed seems irrelevant for the no-boot issue.
> That nehalem raminit code, struct raminfo, seems to eat a lot of stack
> and an error message for that case was added with commit 2c3fd49. You
> could try parent of that commit, but rumour is lenovo/x201 was a
> no-boot case long time before that.

I'll do some tests to find which commit caused the no-boot.
> I can see int15h messages interleaved with SMP init, that looks odd to
> me. Also, did the log really end inside 0:1f.0 PCI finalize or was
> usbdebug logging just interrupted for some reason at that point?

The log really ends there.
> Try current master with default config instead of a one derived from
> last reported board_status. There has been lot of changes on
> framebuffer kconfig settings. And we probably need the .config you
> used to assess what's happening there.

I've tried with the current master on a fresh config, but the result is
the same. Attached you can find the log and the .config.

If needed I can do some tests on this PC.

Nicola

[RFH] Status of the Lenovo X201

[diffusae]

Hi!

I'm also interested in a running version of current master.

On 25.04.2018 12:51, Nicola Corna wrote:
> If needed I can do some tests on this PC.

I also would do some testing on this machine, if that helps.

Regards,
Reiner

[RFH] Status of the Lenovo X201

[Kyösti Mälkki]

On Wed, Apr 25, 2018 at 1:51 PM, Nicola Corna  wrote:
> April 18, 2018 3:54 PM, "Kyösti Mälkki"  wrote:
> > Having romstage stack smashed seems irrelevant for the no-boot issue.
> > That nehalem raminit code, struct raminfo, seems to eat a lot of stack
> > and an error message for that case was added with commit 2c3fd49. You
> > could try parent of that commit, but rumour is lenovo/x201 was a
> > no-boot case long time before that.
>
> I'll do some tests to find which commit caused the no-boot.

Well, smashed stack in romstage -error is no longer in the log,
possibly because this boot used MRC cache now.
> > I can see int15h messages interleaved with SMP init, that looks odd to
> > me. Also, did the log really end inside 0:1f.0 PCI finalize or was
> > usbdebug logging just interrupted for some reason at that point?
>
> The log really ends there.

With config PARALLEL_CPU_INIT=y so SMP / SMM init in initialize_cpus()
will never call wait_other_cpus() at all. That actually regressed in
my commit 0cc2ce4 [1] but I can't test if reverting it solves this for
you. I'll push a regression fix soonish for review.

[1] https://review.coreboot.org/c/coreboot/+/21088

Kyösti