2010/4/17 Keith Hui buurin@gmail.com
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;
smi_cmd means smi command port ?
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
This should be/go in i82371eb.h
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.
APMC at 0xb2 and APMS at 0xb3
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.
/* For now only define 2 power states: * - S0 which is fully on * - S5 which is soft off * Any others would involve declaring the wake up methods. */
/* intel i82371eb (piix4e) datasheet, section 7.2.3, page 142 */ /* 000b / 0x0: soft off/suspend to disk (soff/std) s5 001b / 0x1: suspend to ram (str) s3 010b / 0x2: powered on suspend, context lost (poscl) s1 011b / 0x3: powered on suspend, cpu context lost (posccl) s2 100b / 0x4: powered on suspend, context maintained (pos) s4 101b / 0x5: working (clock control) s0 110b / 0x6: reserved 111b / 0x7: reserved */ Name (_S0, Package () { 0x05, 0x05, 0x00, 0x00 }) Name (_S5, Package () { 0x00, 0x00, 0x00, 0x00 })
S0 and S5 should be correct but since there's no SMI *yet* poweroff doesn't work.
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?
Sorry, I don't know anything about SMI and a little about ACPI. Have a look at SMI from, I believe, ICH7: http://tracker.coreboot.org/trac/coreboot/browser/trunk/src/southbridge/inte... http://tracker.coreboot.org/trac/coreboot/browser/trunk/src/southbridge/inte...
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
Still unfinished/WIP and unpolished; attaching my patch and signing off:
Signed-off-by: Idwer Vollering vidwer@gmail.com