Hiccups bringing ACPI support to p3b-f

[Keith Hui]

I just sent in this patch to bring ACPI to p3b-f, after way too long:

https://review.coreboot.org/c/coreboot/+/41098

I've run into two problems with this work and hoping for insights.

First, Linux kernel is throwing a warning. Full dmesg (from kernel
start to prompt) attached, but it's these lines in particular:

[    5.977786] ACPI Warning: SystemIO range
0x0000000000000F00-0x0000000000000F07 conflicts with OpRegion
0x0000000000000F00-0x0000000000000F06 (\SM00) (20150930/utaddress-254)
[    5.978202] ACPI: If an ACPI driver is available for this device,
you should use it instead of the native driver

It is probably related to some SMBus manipulation I imported from OEM
firmware that is going to be needed for S3 suspend - It actually has
code to talk to an onboard proprietary ASIC over SMBus to blink the
power LED and turn off the fan among other things. I later dumped the
coreboot SSDT and found that it wrote a device claiming the PIIX4
PM/SMBus ports, so I revised my other patch to completely drop mine,
but the conflict remains. Now I can't pinpoint where the conflict
comes from.

Second, the command I needed to run to enable flashrom no longer
works. i2cset simply said "Write failed". I have to completely disable
ACPI to be able to flash. The two problems may be related, but I can't
tell for sure.

One thing I could do for the second problem is to do the sequence in
mainboard ramstage init, but it depends on the southbridge GPO setting
to put that chip into the right state. How are these device enable
hooks ordered? Does all southbridge hooks get run first before
mainboard hooks?

Thanks for your help
Keith

[Nico Huber]

Hi Keith,

On 06.05.20 18:50, Keith Hui wrote:
> I've run into two problems with this work and hoping for insights.
>
> First, Linux kernel is throwing a warning. Full dmesg (from kernel
> start to prompt) attached, but it's these lines in particular:
>
> [    5.977786] ACPI Warning: SystemIO range
> 0x0000000000000F00-0x0000000000000F07 conflicts with OpRegion
> 0x0000000000000F00-0x0000000000000F06 (\SM00) (20150930/utaddress-254)

I'm not 100% sure but looking at Linux `drivers/i2c/busses/i2c-piix4.c`,
it seems Linux anticipates that ACPI might use the SMBus too. But you
have to make it aware that this is about the same device. Maybe you
also have to match the i/o region's size, e.g. make your `OpRegion`
8 ports long.

You should move your SMBus ASL code into a `Device` node below `PCI0`.
AFAICT

Device (SMB0) {
            Name (_ADR, 0x00040003) /* PCI 0:04.3, right? */

...
    }

I guess this should actually live in `src/southbridge/intel/i82371eb/
acpi/i82371eb.asl`. The mainboard code could then call the `WBYT` and
`RBYT` methods.

If this doesn't work, it might still be possible to make the resource
conflict less obvious to Linux.

Again, not 100% sure how this works, but I'm sure this is the right
direction. Your other issues seems related.

Hope this helps,
Nico

[Keith Hui]

Hi Nico,

I tried a few things. Looks like Linux kernel activated a couple PCI
quirks and claimed the ACPI and SMBus port ranges on top of what we
already reported. Seems to be the source of the conflict.
I have to omit the SMBus port range in pwrmgt_read_resources() in
southbridge/intel/i82371eb/smbus.c to make the conflict go away, but
that is not exactly correct.

It is either this hack (which doesn't always work anyway), or rip the
SMBus driver out of DSDT, which S3 suspend for p3b-f is going to need,
or go expert mode and rebuild kernel with PCI_QUIRKS turned off. But I
also have a Realtek NIC with its own quirks, and turning PCI_QUIRKS
off kills that workaround as well.

What is my proper next step?

Thanks
Keith

On Thu, May 7, 2020 at 4:43 PM Nico Huber  wrote:
> Hi Keith,
>
> On 06.05.20 18:50, Keith Hui wrote:
> > I've run into two problems with this work and hoping for insights.
> >
> > First, Linux kernel is throwing a warning. Full dmesg (from kernel
> > start to prompt) attached, but it's these lines in particular:
> >
> > [    5.977786] ACPI Warning: SystemIO range
> > 0x0000000000000F00-0x0000000000000F07 conflicts with OpRegion
> > 0x0000000000000F00-0x0000000000000F06 (\SM00) (20150930/utaddress-254)
>
> I'm not 100% sure but looking at Linux `drivers/i2c/busses/i2c-piix4.c`,
> it seems Linux anticipates that ACPI might use the SMBus too. But you
> have to make it aware that this is about the same device. Maybe you
> also have to match the i/o region's size, e.g. make your `OpRegion`
> 8 ports long.
>
> You should move your SMBus ASL code into a `Device` node below `PCI0`.
> AFAICT
> Device (SMB0) {
>         Name (_ADR, 0x00040003) /* PCI 0:04.3, right? */
>
>         ...
> }
>
> I guess this should actually live in `src/southbridge/intel/i82371eb/
> acpi/i82371eb.asl`. The mainboard code could then call the `WBYT` and
> `RBYT` methods.
>
> If this doesn't work, it might still be possible to make the resource
> conflict less obvious to Linux.
>
> Again, not 100% sure how this works, but I'm sure this is the right
> direction. Your other issues seems related.
>
> Hope this helps,
> Nico

[Peter Stuge]

Keith Hui wrote:
> Looks like Linux kernel activated a couple PCI quirks

Why? Maybe coreboot can change to stop that from happening.
> and claimed the ACPI and SMBus port ranges on top of what we
> already reported. Seems to be the source of the conflict.

Regardless of any quirks, that seems like a bug in Linux.
> What is my proper next step?

Investigate why quirks are activated and if coreboot can do something to
avoid that, and report/fix the bug in Linux.

//Peter

[Angel Pons]

Hi all,

On Sat, May 16, 2020 at 2:23 AM Keith Hui  wrote:
> Hi Nico,
>
> I tried a few things. Looks like Linux kernel activated a couple PCI
> quirks and claimed the ACPI and SMBus port ranges on top of what we
> already reported. Seems to be the source of the conflict.
> I have to omit the SMBus port range in pwrmgt_read_resources() in
> southbridge/intel/i82371eb/smbus.c to make the conflict go away, but
> that is not exactly correct.
>
> It is either this hack (which doesn't always work anyway), or rip the
> SMBus driver out of DSDT, which S3 suspend for p3b-f is going to need,
> or go expert mode and rebuild kernel with PCI_QUIRKS turned off. But I
> also have a Realtek NIC with its own quirks, and turning PCI_QUIRKS
> off kills that workaround as well.
>
> What is my proper next step?

I would say: check why the quirk is getting enabled, and try to make
it not enable for coreboot. Otherwise, we have to make coreboot be
wrong just to make the kernel happy.
> Thanks
> Keith

Best regards,

Angel

[Keith Hui]

I read the kernel sources before writing about the PCI quirks. From
what I can see, quirks are enabled based on PCI VID/DID detected and
are only disabled by compiling the entire thing out of the kernel aka
PCI_QUIRKS=n. I haven't checked how the kernel would react if I do the
latter and boot it with vendor firmware.

Now I know the warning message pops up on dmesg as the module
i2c-piix4 is loaded.

The next message alludes to an ACPI driver. There is none, and I don't
know how practical it is to write one. Or do the opposite and
implement ATK0110 support into p3b-f (this is Asus' hardware
monitoring interface over ACPI, replacing the native hwmon driver).

Thanks
Keith

On Tue, May 19, 2020 at 1:53 PM Angel Pons  wrote:
> Hi all,
>
> On Sat, May 16, 2020 at 2:23 AM Keith Hui  wrote:
> > Hi Nico,
> >
> > I tried a few things. Looks like Linux kernel activated a couple PCI
> > quirks and claimed the ACPI and SMBus port ranges on top of what we
> > already reported. Seems to be the source of the conflict.
> > I have to omit the SMBus port range in pwrmgt_read_resources() in
> > southbridge/intel/i82371eb/smbus.c to make the conflict go away, but
> > that is not exactly correct.
> >
> > It is either this hack (which doesn't always work anyway), or rip the
> > SMBus driver out of DSDT, which S3 suspend for p3b-f is going to need,
> > or go expert mode and rebuild kernel with PCI_QUIRKS turned off. But I
> > also have a Realtek NIC with its own quirks, and turning PCI_QUIRKS
> > off kills that workaround as well.
> >
> > What is my proper next step?
>
> I would say: check why the quirk is getting enabled, and try to make
> it not enable for coreboot. Otherwise, we have to make coreboot be
> wrong just to make the kernel happy.
> > Thanks
> > Keith
>
> Best regards,
>
> Angel

[Keith Hui]

I've since found a couple interesting things.

Just stumbled upon this one from the Linux kernel mailing list, a
patch from an Intel guy back in 2016:
https://patchwork.kernel.org/patch/9011731/

This is exactly what I am seeing. He submitted a patch to block
further native SMBus port access if SMBus port is declared in ACPI.

But, the patch was only against ICH (aka i801) and should not have
affected PIIX4.

And then, I also found specs for the SMBus Control Method Interface:
http://smbus.org/specs/smbus_cmi10.pdf

And that Linux kernel has a driver for it!

That's my ticket, isn't it?

Now I'm going to try implementing SCMI on P3B-F and see what happens.

On Tue, May 19, 2020 at 2:41 PM Keith Hui  wrote:
> I read the kernel sources before writing about the PCI quirks. From
> what I can see, quirks are enabled based on PCI VID/DID detected and
> are only disabled by compiling the entire thing out of the kernel aka
> PCI_QUIRKS=n. I haven't checked how the kernel would react if I do the
> latter and boot it with vendor firmware.
>
> Now I know the warning message pops up on dmesg as the module
> i2c-piix4 is loaded.
>
> The next message alludes to an ACPI driver. There is none, and I don't
> know how practical it is to write one. Or do the opposite and
> implement ATK0110 support into p3b-f (this is Asus' hardware
> monitoring interface over ACPI, replacing the native hwmon driver).
>
> Thanks
> Keith
>
> On Tue, May 19, 2020 at 1:53 PM Angel Pons  wrote:
> > Hi all,
> >
> > On Sat, May 16, 2020 at 2:23 AM Keith Hui  wrote:
> > > Hi Nico,
> > >
> > > I tried a few things. Looks like Linux kernel activated a couple PCI
> > > quirks and claimed the ACPI and SMBus port ranges on top of what we
> > > already reported. Seems to be the source of the conflict.
> > > I have to omit the SMBus port range in pwrmgt_read_resources() in
> > > southbridge/intel/i82371eb/smbus.c to make the conflict go away, but
> > > that is not exactly correct.
> > >
> > > It is either this hack (which doesn't always work anyway), or rip the
> > > SMBus driver out of DSDT, which S3 suspend for p3b-f is going to need,
> > > or go expert mode and rebuild kernel with PCI_QUIRKS turned off. But I
> > > also have a Realtek NIC with its own quirks, and turning PCI_QUIRKS
> > > off kills that workaround as well.
> > >
> > > What is my proper next step?
> >
> > I would say: check why the quirk is getting enabled, and try to make
> > it not enable for coreboot. Otherwise, we have to make coreboot be
> > wrong just to make the kernel happy.
> > > Thanks
> > > Keith
> >
> > Best regards,
> >
> > Angel