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/intel/i82801gx/i82801gx_smihandler.c and http://tracker.coreboot.org/trac/coreboot/browser/trunk/src/southbridge/intel/i82801gx/i82801gx_smi.c

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: