Beware that patch is incomplete! Coreboot dies at src/southbridge/intel/common/acpi_pirq_gen.c line 97:
if (!lpcb_path) die("ACPI_PIRQ_GEN: Missing LPCB ACPI path\n");
You have to add the lpc_acpi_name function to src/southbridge/intel/ibexpeak/lpc.c as in src/southbridge/intel/bd82x6x/lpc.c to circumvent this issue.
I was preparing to upload my patch when I saw yours (which is almost identical). Additionally, I already tested my patch on a Lenovo X201i. Shall I edit your patch on gerrit or upload mine in a separate merge request, or do something else?
Cheers, Matthias
On 01/05/18 18:45, Kyösti Mälkki wrote:
On Mon, Apr 30, 2018 at 6:46 AM, qtux mail@qtux.eu wrote:
I wrote a patch [0] for the finalize code issue. With that my X201i is working fine on current master besides an regression introduced in commit 7f5efd90e598320791200e03f761309ee04b58a3 [1]. With that regression USB and SD card is not working anymore and it raises the following errors:
Thanks for patching _and_ testing, your patch for finalize was just merged.
can't derive routing for PCI INT A PCI INT A: no GSI
As for IRQ regressions, I think I can see where it went wrong, find my attempt to fix it blind-folded [1].
[1] https://review.coreboot.org/#/c/coreboot/+/25965
Kyösti
Thank you Kyösti, your patch solves all irq issues and USB is working again on my X201i. I opened a review for adding the X201i as an X201 variant: https://review.coreboot.org/#/c/coreboot/+/25971/
Apart from that I have the following ACPI conflict with PMIO and GPIO:
ACPI: Battery Slot [BAT0] (battery present) ACPI: Battery Slot [BAT1] (battery absent) ACPI: AC Adapter [AC] (on-line) ACPI Warning: SystemIO range 0x0000000000000528-0x000000000000052F conflicts with OpRegion 0x0000000000000500-0x000000000000057F (\PMIO) (20180105/utaddress-247) ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver ACPI Warning: SystemIO range 0x00000000000004C0-0x00000000000004CF 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 ACPI Warning: SystemIO range 0x00000000000004B0-0x00000000000004BF 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 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?
Cheers, Matthias
On 01/05/18 19:35, qtux wrote:
Beware that patch is incomplete! Coreboot dies at src/southbridge/intel/common/acpi_pirq_gen.c line 97:
if (!lpcb_path) die("ACPI_PIRQ_GEN: Missing LPCB ACPI path\n");
You have to add the lpc_acpi_name function to src/southbridge/intel/ibexpeak/lpc.c as in src/southbridge/intel/bd82x6x/lpc.c to circumvent this issue.
I was preparing to upload my patch when I saw yours (which is almost identical). Additionally, I already tested my patch on a Lenovo X201i. Shall I edit your patch on gerrit or upload mine in a separate merge request, or do something else?
Cheers, Matthias
On 01/05/18 18:45, Kyösti Mälkki wrote:
On Mon, Apr 30, 2018 at 6:46 AM, qtux mail@qtux.eu wrote:
I wrote a patch [0] for the finalize code issue. With that my X201i is working fine on current master besides an regression introduced in commit 7f5efd90e598320791200e03f761309ee04b58a3 [1]. With that regression USB and SD card is not working anymore and it raises the following errors:
Thanks for patching _and_ testing, your patch for finalize was just merged.
can't derive routing for PCI INT A PCI INT A: no GSI
As for IRQ regressions, I think I can see where it went wrong, find my attempt to fix it blind-folded [1].
[1] https://review.coreboot.org/#/c/coreboot/+/25965
Kyösti
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.
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.
On 02.05.2018 18:37, qtux wrote:
Thanks for your detailed explanation. So in essence shall I ignore the messages or blacklist lpc_ich?
Yes, either ;)
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?
Um, yes. I think that's not good. But I wonder why it's not happening consistently.
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).
With the ME in general: Don't write it's firmware region unless you have to test a change there. And in this case, don't touch the BIOS region. After you have flashed the ME firmware you have to make incredibly sure that it's reset and in a valid state (hard to tell because an error state is expected with me_cleaner). Only then you can reason about core- boot.
Even though some people are unhappy with limited access to the ME firm- ware, the best thing to do during coreboot development is to keep it locked (or write-protected at least).
Nico
On Wed, May 2, 2018 at 8:53 PM, Nico Huber nico.h@gmx.de wrote:
On 02.05.2018 18:37, qtux wrote:
Thanks for your detailed explanation. So in essence shall I ignore the messages or blacklist lpc_ich?
Yes, either ;)
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?
Um, yes. I think that's not good. But I wonder why it's not happening consistently.
I commented about that earlier in this thread. Seemed like actual raminit eats a lot of stack, but loading from MRC cache or equivalent does not. One could find that struct and move it to BSS, declared with CAR_GLOBAL. I would rather not extend the boundary for stack-smashing detection.
Kyösti
Hi Nico,
On 02.05.2018 00:42, Nico Huber wrote:
Well, you better know what you are doing ;)
that's indeed really true. :-)
Regards, Reiner
-
diffusae -
Kyösti Mälkki -
Nico Huber -
qtux