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. > -- coreboot mailing list: [email protected] https://mail.coreboot.org/mailman/listinfo/coreboot
