[coreboot] [RFC] ACPI for ASUS P2B/P2B-LS (Intel 440BX/82371EB)

Keith Hui buurin at gmail.com
Sat Apr 17 05:15:58 CEST 2010

I'll sign off on my next RFC, although as previously said, I'll say
it's ready for commit only when I made a breakthrough like when I can
power off.

At that time I'd also like to see Idwer sign off on it too. You can go
ahead and construct ACPI 2.0 compliant tables. I'm working off a DSDT
table derived from the vendor BIOS and that could be a problem, at
least legally.

Now, technical question.

Stefan gave me these inputs:

Date: Wed, 14 Apr 2010 08:31:37 +0200
From: Stefan Reinauer <stepan at coresystems.de>
To: coreboot at coreboot.org
Subject: Re: [coreboot] [RFC] ACPI for ASUS P2B/P2B-LS (Intel
Message-ID: <4BC56149.3030707 at coresystems.de>
Content-Type: text/plain; charset="iso-8859-1"

On 4/14/10 5:54 AM, Keith Hui wrote:
> irq 9: nobody cared (try booting with the "irqpoll" option)
This is caused by setting fadt->sci_int without an irqoverride source in
the MADT.

       current += acpi_create_madt_irqoverride((acpi_madt_irqoverride_t *)
                current, 0, 9, 9, MP_IRQ_TRIGGER_LEVEL |

Generally your fadt looks a bit off, still:
+    fadt->sci_int = 9; // APM_CNT
This is not APM control but the sci interrupt
+    fadt->smi_cmd = 0;
This should be APM_CNT
+    fadt->acpi_enable = 0xa1; // ACPI_ENABLE
+    fadt->acpi_disable = 0xa0; // ACPI_DISABLE
These two should be zero unless you have an SMM handler
+    fadt->s4bios_req = 0x0;
+    fadt->pstate_cnt = 0x0;

With SMM it should look like this, assuming the APM_CNT port is 0xb2 on
the 82371 too. (It is on the ICHx chips)

#define APM_CNT         0xb2
#define   CST_CONTROL   0x85
#define   PST_CONTROL   0x80
#define   ACPI_DISABLE  0x1e
#define   ACPI_ENABLE   0xe1

       fadt->sci_int = 0x9;
       fadt->smi_cmd = APM_CNT;
       fadt->acpi_enable = ACPI_ENABLE;
       fadt->acpi_disable = ACPI_DISABLE;
       fadt->s4bios_req = 0x0;
       fadt->pstate_cnt = PST_CONTROL;
       fadt->cst_cnt = CST_CONTROL;

I checked the PIIX4 datasheet, the APM_CNT is indeed at 0xb2, with
0xb3 also available to pass data. Writes to 0xb2 triggers SMI# when
thus enabled and this ACPI enable/disable method expects writing one
byte to one port to accomplish it all.

On our boards, this is still correct:
#define   ACPI_DISABLE  0xa0
#define   ACPI_ENABLE   0xa1

I checked the OEM DSDT and found POST debug code. 0xF5 does indeed
mean some DSDT code is called when the machine is about to be put into
S5 - soft off. Of course, I was trying to power down.

It means I need to write an SMI handler. Anyone has an easily
understandable primer on it? How is the coreboot architecture for SMI
handler? I traced some files and don't see the RSM instruction

PIIX4 supports only one 128KB SMRAM from 0xA0000-0xBFFFF. P6 family
CPUs power up assuming this SMRAM is based at 0x30000. It can (and
will have to be) relocated, but it can only be done INSIDE SMM mode
ie. the SMI handler. I haven't dug deep enough at say the i82830 SMI
handler, but any clean idea on how to do this? OEM BIOS has three
instances of RSM instructions, implying 3 different SMI handlers for
different purposes. Analysis is still ongoing.

Now, Idwer, when I am done, I'll need you to test it as well. I
compared the ACPI tables of our boards - at least the ones I can
extract straight out of the OEM BIOS images - and they are identical
except for a longer PCI IRQ routing table for the added onboard
peripherals. So the ACPI work of either of us, should work for us
both, well me if the additional IRQ routing added back in.


More information about the coreboot mailing list