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.