[coreboot] [RFH] Status of the Lenovo X201

[qtux]

Thanks for your detailed explanation. So in essence shall I ignore the
messages or blacklist lpc_ich?

Besides, while preparing the status report, I sometimes find a "Smashed
stack detected in romstage!" message in the console log, just before
ramstage is starting. Is there something to worry about there?

It may correlate with another issue I found: Sometimes (mostly after
some experimentation) SeaBios loads a long time (about 10 to 20 seconds)
and is not able to find my SATA drive (though, payloads from cbfs can
still be loaded). Restarting with Ctrl+Alt+Del is sufficient in these
cases to solve the issue until the next time I tinker with coreboot (in
particular experimenting with me_cleaner seems to cause this issue quite
often).

Cheers,
Matthias

On 02/05/18 00:42, Nico Huber wrote:
> On 02.05.2018 00:03, qtux wrote:
>> ...
>> ACPI Warning: SystemIO range 0x0000000000000480-0x00000000000004AF
>> conflicts with OpRegion 0x0000000000000480-0x00000000000004EB (\GPIO)
>> (20180105/utaddress-247)
>> ACPI: If an ACPI driver is available for this device, you should use it
>> instead of the native driver
>> lpc_ich: Resource conflict(s) found affecting gpio_ich
>>
>> Maybe these are also caused by copy pasting Sandy Bridge code as I found
>> a reference to PMIO and GPIO with matching addresses in
>> src/southbridge/intel/bd82x6x/acpi/pch.asl. Do you have any ideas on
>> this issue?
> 
> It's pretty simple. When the firmware was written (both coreboot and the
> one from Lenovo) this `lpc_ich` driver didn't exist in Linux and wasn't
> accounted for. From a firmware point of view, that driver shouldn't
> exist at all and our ACPI code claims the device's resources therefore.
> I don't think the driver was meant to be included into generic Linux
> distributions.
> 
> Related story: The same applies to other drivers like the buggy intel-
> spi. That one even warns in Kconfig "Say N here unless you know what you
> are doing.". Due to a simple off-by-one in the code, it bricked[1] a lot
> of systems with Ubuntu 17.10 and they had to withdraw their images.
> That's what you get when you blindly enable all modules and ship them to
> humble users.
> 
> Well, you better know what you are doing ;)
> 
> Nico
> 
> [1] It only write-protected the firmware flash by accident, the actual
>     brick was caused by the UEFI shipping on the affected systems.
>