2010/4/17 Keith Hui <span dir="ltr"><<a href="mailto:buurin@gmail.com">buurin@gmail.com</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I'll sign off on my next RFC, although as previously said, I'll say<br>
it's ready for commit only when I made a breakthrough like when I can<br>
power off.<br>
At that time I'd also like to see Idwer sign off on it too. You can go<br>
ahead and construct ACPI 2.0 compliant tables. I'm working off a DSDT<br>
table derived from the vendor BIOS and that could be a problem, at<br>
least legally.<br>
Now, technical question.<br>
Stefan gave me these inputs:<br>
Date: Wed, 14 Apr 2010 08:31:37 +0200<br>
From: Stefan Reinauer <<a href="mailto:stepan@coresystems.de">stepan@coresystems.de</a>><br>
To: <a href="mailto:coreboot@coreboot.org">coreboot@coreboot.org</a><br>
Subject: Re: [coreboot] [RFC] ACPI for ASUS P2B/P2B-LS (Intel<br>
Message-ID: <<a href="mailto:4BC56149.3030707@coresystems.de">4BC56149.3030707@coresystems.de</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<div class="im"><br>
On 4/14/10 5:54 AM, Keith Hui wrote:<br>
</div><div class="im">> irq 9: nobody cared (try booting with the "irqpoll" option)<br>
</div><div><div></div><div class="h5">This is caused by setting fadt->sci_int without an irqoverride source in<br>
the MADT.<br>
       current += acpi_create_madt_irqoverride((acpi_madt_irqoverride_t *)<br>
                current, 0, 9, 9, MP_IRQ_TRIGGER_LEVEL |<br>
Generally your fadt looks a bit off, still:<br>
+    fadt->sci_int = 9; // APM_CNT<br>
This is not APM control but the sci interrupt<br>
+    fadt->smi_cmd = 0;<br></div></div></blockquote><div><br>smi_cmd means smi command port ? <br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div class="h5">
This should be APM_CNT<br>
+    fadt->acpi_enable = 0xa1; // ACPI_ENABLE<br>
+    fadt->acpi_disable = 0xa0; // ACPI_DISABLE<br>
These two should be zero unless you have an SMM handler<br>
+    fadt->s4bios_req = 0x0;<br>
+    fadt->pstate_cnt = 0x0;<br>
With SMM it should look like this, assuming the APM_CNT port is 0xb2 on<br>
the 82371 too. (It is on the ICHx chips)<br>
#define APM_CNT         0xb2<br>
#define   CST_CONTROL   0x85<br>
#define   PST_CONTROL   0x80<br>
#define   ACPI_DISABLE  0x1e<br>
#define   ACPI_ENABLE   0xe1<br></div></div></blockquote><div> </div><div> This should be/go in i82371eb.h<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div class="h5">
       fadt->sci_int = 0x9;<br>
       fadt->smi_cmd = APM_CNT;<br>
       fadt->acpi_enable = ACPI_ENABLE;<br>
       fadt->acpi_disable = ACPI_DISABLE;<br>
       fadt->s4bios_req = 0x0;<br>
       fadt->pstate_cnt = PST_CONTROL;<br>
       fadt->cst_cnt = CST_CONTROL;<br>
I checked the PIIX4 datasheet, the APM_CNT is indeed at 0xb2, with<br>
0xb3 also available to pass data. Writes to 0xb2 triggers SMI# when<br>
thus enabled and this ACPI enable/disable method expects writing one<br>
byte to one port to accomplish it all.<br></blockquote><div><br>APMC at 0xb2 and APMS at 0xb3<br></div><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

On our boards, this is still correct:<br>
#define   ACPI_DISABLE  0xa0<br>
#define   ACPI_ENABLE   0xa1<br>
I checked the OEM DSDT and found POST debug code. 0xF5 does indeed<br>
mean some DSDT code is called when the machine is about to be put into<br>
S5 - soft off. Of course, I was trying to power down.<br></blockquote><div><br>/* For now only define 2 power states:<br> *  - S0 which is fully on<br> *  - S5 which is soft off<br> * Any others would involve declaring the wake up methods.<br>
 */<br><br>/* intel i82371eb (piix4e) datasheet, section 7.2.3, page 142 */<br>/*<br>000b / 0x0: soft off/suspend to disk (soff/std)            s5<br>001b / 0x1: suspend to ram (str)                s3<br>010b / 0x2: powered on suspend, context lost (poscl)        s1<br>
011b / 0x3: powered on suspend, cpu context lost (posccl)    s2<br>100b / 0x4: powered on suspend, context maintained (pos)    s4<br>101b / 0x5: working (clock control)                s0<br>110b / 0x6: reserved<br>111b / 0x7: reserved<br>
*/<br>Name (\_S0, Package () { 0x05, 0x05, 0x00, 0x00 })<br>Name (\_S5, Package () { 0x00, 0x00, 0x00, 0x00 })<br><br><br>S0 and S5 should be correct but since there's no SMI *yet* poweroff doesn't work.<br><br></div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
It means I need to write an SMI handler. Anyone has an easily<br>
understandable primer on it? How is the coreboot architecture for SMI<br>
handler? I traced some files and don't see the RSM instruction<br>
anywhere?<br></blockquote><div><br>Sorry, I don't know anything about SMI and a little about ACPI.<br>Have a look at SMI from, I believe, ICH7: <a href="http://tracker.coreboot.org/trac/coreboot/browser/trunk/src/southbridge/intel/i82801gx/i82801gx_smihandler.c">http://tracker.coreboot.org/trac/coreboot/browser/trunk/src/southbridge/intel/i82801gx/i82801gx_smihandler.c</a> and <a href="http://tracker.coreboot.org/trac/coreboot/browser/trunk/src/southbridge/intel/i82801gx/i82801gx_smi.c">http://tracker.coreboot.org/trac/coreboot/browser/trunk/src/southbridge/intel/i82801gx/i82801gx_smi.c</a><br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
PIIX4 supports only one 128KB SMRAM from 0xA0000-0xBFFFF. P6 family<br>
CPUs power up assuming this SMRAM is based at 0x30000. It can (and<br>
will have to be) relocated, but it can only be done INSIDE SMM mode<br>
ie. the SMI handler. I haven't dug deep enough at say the i82830 SMI<br>
handler, but any clean idea on how to do this? OEM BIOS has three<br>
instances of RSM instructions, implying 3 different SMI handlers for<br>
different purposes. Analysis is still ongoing.<br>
Now, Idwer, when I am done, I'll need you to test it as well. I<br>
compared the ACPI tables of our boards - at least the ones I can<br>
extract straight out of the OEM BIOS images - and they are identical<br>
except for a longer PCI IRQ routing table for the added onboard<br>
peripherals. So the ACPI work of either of us, should work for us<br>
both, well me if the additional IRQ routing added back in.<br>
<font color="#888888">Keith<br></font></blockquote><div> Still unfinished/WIP and unpolished; attaching my patch and signing off:<br></div></div><br>Signed-off-by: Idwer Vollering <<a href="mailto:vidwer@gmail.com">vidwer@gmail.com</a>><br>