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>
<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>
<br>
Now, technical question.<br>
<br>
Stefan gave me these inputs:<br>
<br>
--------------<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>
440BX/82371EB)<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>
<br>
current += acpi_create_madt_irqoverride((acpi_madt_irqoverride_t *)<br>
current, 0, 9, 9, MP_IRQ_TRIGGER_LEVEL |<br>
MP_IRQ_POLARITY_HIGH);<br>
<br>
<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>
<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>
<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">
<br>
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>
...<br>
fadt->cst_cnt = CST_CONTROL;<br>
<br>
</div></div>--------------<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>
<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;">
<br>
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;">
<br>
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>
<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>
<br>
Thanks<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>