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@coresystems.de To: coreboot@coreboot.org Subject: Re: [coreboot] [RFC] ACPI for ASUS P2B/P2B-LS (Intel 440BX/82371EB) Message-ID: 4BC56149.3030707@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 | MP_IRQ_POLARITY_HIGH);
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 anywhere?
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.
Thanks Keith