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

Mon Apr 26 03:55:57 CEST 2010

2010/4/17 Keith Hui <buurin at 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 at coresystems.de>
> To: coreboot at coreboot.org
> Subject: Re: [coreboot] [RFC] ACPI for ASUS P2B/P2B-LS (Intel
>       440BX/82371EB)
> 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 |
> 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.cand
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:

Signed-off-by: Idwer Vollering <vidwer at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100426/64028bca/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: coreboot_r5500_asus_p2b_ram+keithhui-pm+acpi-wip.patch
Type: text/x-diff
Size: 34693 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100426/64028bca/attachment.bin>