ACPI patches for Tyan s2895, s2892, s2891

[Myles Watson]

These patches let Ubuntu 8.10 boot with ACPI support and no ACPI
table-related warnings.  I haven't done SMM support yet, so that still
complains and disables IRQ 9.

Windows still doesn't like something, but I thought I'd contribute
this code before I started using munged factory tables to see if I can
get it to work that way.  Because resource allocation is totally
different, the tables will need to be munged quite a bit :(

_Tyan_common_tables.diff_

This patch adds common elements for ck804-based boards.

changes by file:
src/arch/i386/boot/acpi.c:
    Be Paranoid and set srat_lapic table to zero before filling it.
    Enable SLIT filling if acpi_create_slit gets called.

src/northbridge/amd/amdk8/northbridge.c:
    Add high tables code ala Stefan's code for the i945.

src/northbridge/amd/amdk8/amdk8_util.asl:
    Put this file here instead of every board having a personal copy.

src/southbridge/nvidia/ck804/ck804_lpc.c:
    Enable High Precision Event Timers.
    Add pm_base for ACPI.

src/northbridge/amd/amdk8/amdk8_acpi.c
    Silence warnings about implicit functions and format strings.

src/arch/i386/include/arch/acpi.h:
    Add slit prototype and minor whitespace.

src/southbridge/nvidia/ck804/ck804_fadt.c:
    Since fadt is only dependent on the Southbridge, add it here.

src/southbridge/nvidia/ck804/Config.lb:
    Compile in ck804_fadt.c

_s289X_tables.diff_

changes by file:

src/mainboard/tyan/s289X/Options.lb:
    Add options and defaults for ACPI tables and resources.

src/mainboard/tyan/s289X/mainboard.c:
    Add high_tables resource ala Stefan's code for the Kontron.

src/mainboard/tyan/s289X/acpi_tables.c:
    Fill out the ACPI tables, using existing code where possible.
    Only the madt is different between the boards, to be combined later.

src/mainboard/tyan/s289X/Config.lb:
    Compile in acpi_tables.c and dsdt.dsl.
    Turn on the parallel port and the real-time-clock.

src/mainboard/tyan/s289x/dsdt.dsl:
    The board layout (thanks Rudolf) and interrupts from mptable.c

src/mainboard/tyan/s289x/mptable.c:
    Minor formatting changes to make them diff better.

src/superio/smsc/lpc47b397/superio.c: (s2895 only)
    Correct the size of the real-time-clock so it can be where it belongs.

Signed-off-by: Myles Watson

Thanks,
Myles

[Myles Watson]

On Fri, Feb 27, 2009 at 3:23 PM, Myles Watson  wrote:
> These patches let Ubuntu 8.10 boot with ACPI support and no ACPI
> table-related warnings.  I haven't done SMM support yet, so that still
> complains and disables IRQ 9.

I've only tested s2892 and s2895.  s2891 is really similar, build-tested only.

Thanks,
Myles

[Carl-Daniel Hailfinger]

On 27.02.2009 23:23, Myles Watson wrote:
> These patches let Ubuntu 8.10 boot with ACPI support and no ACPI
> table-related warnings.  I haven't done SMM support yet, so that still
> complains and disables IRQ 9.
>
> Windows still doesn't like something, but I thought I'd contribute
> this code before I started using munged factory tables to see if I can
> get it to work that way.  Because resource allocation is totally
> different, the tables will need to be munged quite a bit :(
>
> _Tyan_common_tables.diff_
>
> This patch adds common elements for ck804-based boards.
>
> changes by file:
> src/arch/i386/boot/acpi.c:
>    Be Paranoid and set srat_lapic table to zero before filling it.
>    Enable SLIT filling if acpi_create_slit gets called.
>
> src/northbridge/amd/amdk8/northbridge.c:
>    Add high tables code ala Stefan's code for the i945.
>
> src/northbridge/amd/amdk8/amdk8_util.asl:
>    Put this file here instead of every board having a personal copy.

I didn't see the deletion of the per-board copies. Did subversion forget
to include them in the diff?

Besides that, moving the related fam10 file as well would be nice. Maybe
also a splitout of the K8 util ACPI code from the DBM690T and Pistachio
code, but that seems to be more work.
> src/northbridge/amd/amdk8/amdk8_acpi.c
>    Silence warnings about implicit functions and format strings.
>
> src/arch/i386/include/arch/acpi.h:
>    Add slit prototype and minor whitespace.
>
> Signed-off-by: Myles Watson

Regards,
Carl-Daniel

[Myles Watson]

> > src/northbridge/amd/amdk8/amdk8_util.asl:
> >    Put this file here instead of every board having a personal copy.
>
> I didn't see the deletion of the per-board copies. Did subversion forget
> to include them in the diff?

I meant the copies for the boards I was supporting.  I was figuring another
patch could unify it even more.  I feel like patches that get too large are
harder to review.
> Besides that, moving the related fam10 file as well would be nice. Maybe
> also a splitout of the K8 util ACPI code from the DBM690T and Pistachio
> code, but that seems to be more work.

I agree that needs to be done too.

Thanks,
Myles

[Myles Watson]

I refactored the patches to simplify reviewing.  In a coming patch
there are some bugfixes in amdk8_util.asl, so this will help with
maintenance.

changes by file:
src/arch/i386/boot/acpi.c:
       Be Paranoid and set srat_lapic table to zero before filling it.
       Enable SLIT filling if acpi_create_slit gets called.

src/northbridge/amd/amdk8/amdk8_util.asl:
       Put this file here instead of every board having a personal copy.

src/northbridge/amd/amdfam10/amdfam10_util.asl:
       Put this file here instead of every board having a personal copy.

src/mainboard/.../dsdt.dsl:
       Change the path to amd*_util.asl

src/arch/i386/include/arch/acpi.h:
       Add slit prototype and minor whitespace.

This patch is abuild tested.

Signed-off-by: Myles Watson
> > I didn't see the deletion of the per-board copies. Did subversion forget
> > to include them in the diff?

I will follow the patch with

svn rm src/mainboard/iwill/dk8_htx/dx/amdk8_util.asl
svn rm src/mainboard/amd/serengeti_cheetah/dx/amdk8_util.asl
svn rm src/mainboard/amd/serengeti_cheetah_fam10/dx/amdfam10_util.asl
svn rm src/mainboard/asus/m2v-mx_se/amdk8_util.asl
> > Besides that, moving the related fam10 file as well would be nice.

Done.
> > Maybe
> > also a splitout of the K8 util ACPI code from the DBM690T and Pistachio
> > code, but that seems to be more work.

The ACPI code is totally different for those boards.  It doesn't even
use the same functions.  The util files for those boards could be
moved somewhere central, but I think it's best left for another patch.

Thanks,
Myles

[Rudolf Marek]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

/* If this is the SouthBridge node and link, add a DRAM region. */
+                                If (LOr (LAnd (LEqual (Arg1, 0xFF), LEqual
(Arg0, 0x00)), LEqual (Arg1, _SB.PCI0.SBLK)))
+                                {
+                                    Store (_SB.PCI0.TOM1, MMIN)
+                                    Subtract (MMAX, MMIN, MLEN)
+                                    Increment (MLEN)
+                                }
+

This part cause Windows 7 to BSOD and restart. Did not look at it yet. It starts
 otherwise. (I added also the another Increment (MLEN), its late for me now to
test without that).

If you commit it with a proposed I think we can check in the patch. (dont know
for fam10  maybe same change is needed).

Acked-by: Rudolf Marek

Rudolf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkm1oXMACgkQ3J9wPJqZRNUhHgCeKcCN6jp47OIlQ967pNhsheuo
0VYAnidQifLzUwsd8G6j7z0MPqDBhKdG
=QUMG
-----END PGP SIGNATURE-----

[Rudolf Marek]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Acked-by: Rudolf Marek

If you can explain to me why the superIO changes. Also The SMM does nothing to
do with IRQ9. Get rid of SMM for now. The IRQ 9 needs to be setup for ACPI in
SB. Thats it (and perhaps it needed also an IRQ override).

It looks fine, assuming it works for you then lets put it in. A lot of people is
trying to get ACPI working those days.

Please note that some changes to second patch needs to be done too. For the
global acpik8_util

Rudolf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkm1ox8ACgkQ3J9wPJqZRNVh8wCgh07/lzRaV1OWCEYNOn3FHngi
mtUAoKBLcDT6yePbSeeb0bP1JSHoE5fj
=2V8O
-----END PGP SIGNATURE-----

[Myles Watson]

On Mon, Mar 9, 2009 at 4:15 PM, Rudolf Marek  wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> Acked-by: Rudolf Marek
>
> If you can explain to me why the superIO changes.

For some reason the SuperIO puts the RTC at 0x400, even though it's
usually at 0x70.  If I put it at 0x70 the keyboard and mouse don't
work :(  I put it at 0x90 and corrected the size so that it wouldn't
conflict with other devices.  That makes Linux happy with it.  It
still could be a problem for Windows not to have it at 0x70.
> Also The SMM does nothing to
> do with IRQ9. Get rid of SMM for now. The IRQ 9 needs to be setup for ACPI in
> SB. Thats it (and perhaps it needed also an IRQ override).

Sorry I must have misunderstood this again.  I thought this was why I
keep getting : IRQ9 nobody cared messages from Linux.

It's the last thing that Linux complains about.  I'm not sure what I
should do so that somebody cares.
> It looks fine, assuming it works for you then lets put it in. A lot of people is
> trying to get ACPI working those days.

It's mostly working.
> Please note that some changes to second patch needs to be done too. For the
> global acpik8_util

Yes.  I was trying to implement what I thought was the intent of the
original.  Since then I've taken out the VGA IO port regions and the
DRAM region.  It's a lot more complicated because I have multiple root
 buses.  As far as I can tell the factory BIOS is also not 100%
compliant with the spec, which is making it harder to see what's wrong
with mine.

My current state is hopefully better than what it was when I first
submitted these patches, but the BSOD is the same.

Thanks,
Myles

[Rudolf Marek]

> > If you can explain to me why the superIO changes.
>
> For some reason the SuperIO puts the RTC at 0x400, even though it's
> usually at 0x70.  If I put it at 0x70 the keyboard and mouse don't
> work :(  I put it at 0x90 and corrected the size so that it wouldn't
> conflict with other devices.  That makes Linux happy with it.  It
> still could be a problem for Windows not to have it at 0x70.

Well maybe the RTC chip is elsewhere too?
> > Also The SMM does nothing to
> > do with IRQ9. Get rid of SMM for now. The IRQ 9 needs to be setup for ACPI in
> > SB. Thats it (and perhaps it needed also an IRQ override).
>
> Sorry I must have misunderstood this again.  I thought this was why I
> keep getting : IRQ9 nobody cared messages from Linux.

What devices you think you have at IRQ9?
Maybe some spurious serial IRQ form superIO?

Generally IRQ9 is used as ACPI SCI int.
Just pressing the power button generates the IRQ for example. To make it work 
you need:

1) Set IRQ9 in chipset as ACPI IRQ
2) Set the IRQ 9 override to level/low in MADT
3) Fill the FADT sci int to 9

I think you have 2) 3) I failed to find 1) Please check. Also 
cat/proc/interrupts should state:

...
   7:          0          0   IO-APIC-edge      parport0
   8:          1          0   IO-APIC-edge      rtc0
   9:          0          0   IO-APIC-fasteoi   acpi
  16:    1645904          0   IO-APIC-fasteoi   uhci_hcd:usb1, ahci, nvidia
  17:          0          0   IO-APIC-fasteoi   uhci_hcd:usb2, ide0, ide1

The IRQ9 should be level/low - APIC-fasteoi

Please post /proc/interrupts

Thanks,
Rudolf
> It's the last thing that Linux complains about.  I'm not sure what I
> should do so that somebody cares.
> > It looks fine, assuming it works for you then lets put it in. A lot of people is
> > trying to get ACPI working those days.
>
> It's mostly working.
> > Please note that some changes to second patch needs to be done too. For the
> > global acpik8_util
>
> Yes.  I was trying to implement what I thought was the intent of the
> original.  Since then I've taken out the VGA IO port regions and the
> DRAM region.  It's a lot more complicated because I have multiple root
>  buses.  As far as I can tell the factory BIOS is also not 100%
> compliant with the spec, which is making it harder to see what's wrong
> with mine.
>
> My current state is hopefully better than what it was when I first
> submitted these patches, but the BSOD is the same.
>
> Thanks,
> Myles

[Myles Watson]

On Tue, Mar 10, 2009 at 7:00 AM, Rudolf Marek  wrote:
> > > If you can explain to me why the superIO changes.
> >
> > For some reason the SuperIO puts the RTC at 0x400, even though it's
> > usually at 0x70.  If I put it at 0x70 the keyboard and mouse don't
> > work :(  I put it at 0x90 and corrected the size so that it wouldn't
> > conflict with other devices.  That makes Linux happy with it.  It
> > still could be a problem for Windows not to have it at 0x70.
>
> Well maybe the RTC chip is elsewhere too?
> > > Also The SMM does nothing to
> > > do with IRQ9. Get rid of SMM for now. The IRQ 9 needs to be setup for
> > > ACPI in
> > > SB. Thats it (and perhaps it needed also an IRQ override).
> >
> > Sorry I must have misunderstood this again.  I thought this was why I
> > keep getting : IRQ9 nobody cared messages from Linux.
>
> What devices you think you have at IRQ9?

I don't think I have any.
> Maybe some spurious serial IRQ form superIO?
>
> Generally IRQ9 is used as ACPI SCI int.
> Just pressing the power button generates the IRQ for example. To make it
> work you need:
> Set IRQ9 in chipset as ACPI IRQ

I don't know where I would do this.  I'm assuming you mean southbridge
when you say chipset.
> Set the IRQ 9 override to level/low in MADT
> Fill the FADT sci int to 9
>
> I think you have 2) 3) I failed to find 1) Please check. Also
> cat/proc/interrupts should state:
>
> ...
>  7:          0          0   IO-APIC-edge      parport0
>  8:          1          0   IO-APIC-edge      rtc0
>  9:          0          0   IO-APIC-fasteoi   acpi
>  16:    1645904          0   IO-APIC-fasteoi   uhci_hcd:usb1, ahci, nvidia
>  17:          0          0   IO-APIC-fasteoi   uhci_hcd:usb2, ide0, ide1
>
> The IRQ9 should be level/low - APIC-fasteoi
>
> Please post /proc/interrupts

Attached.

Thanks,
Myles

[Rudolf Marek]

> I don't think I have any.

Check if some superIO has not irq9 configured.
> > Generally IRQ9 is used as ACPI SCI int.
> > Just pressing the power button generates the IRQ for example. To make it
> > work you need:
> > Set IRQ9 in chipset as ACPI IRQ
> I don't know where I would do this.  I'm assuming you mean southbridge
> when you say chipset.

Yes. Maybe it is hardcoded in chip (IRQ9).

9:          1        276         15      99709   IO-APIC-fasteoi   acpi

Huh quite big number. Is it from coreboot or legacy BIOS? Maybe some ACPI GP 
timer is generating the IRQ9?

Rudolf

[Myles Watson]

On Tue, Mar 10, 2009 at 7:19 AM, Rudolf Marek  wrote:
> > I don't think I have any.
>
> Check if some superIO has not irq9 configured.
> > > Generally IRQ9 is used as ACPI SCI int.
> > > Just pressing the power button generates the IRQ for example. To make it
> > > work you need:
> > > Set IRQ9 in chipset as ACPI IRQ
> > I don't know where I would do this.  I'm assuming you mean southbridge
> > when you say chipset.
>
> Yes. Maybe it is hardcoded in chip (IRQ9).
>
> 9:          1        276         15      99709   IO-APIC-fasteoi   acpi
>
> Huh quite big number. Is it from coreboot or legacy BIOS?

It's from Coreboot.

Here's the same line from the factory BIOS:

9:          0           0            0              0
IO-APIC-fasteoi   acpi
> Maybe some ACPI GP
> timer is generating the IRQ9?

I wish I knew more about interrupts.  I'm surprised how different the
routing is for interrupts between the factory BIOS and Coreboot, but
I've been assuming they're routed correctly.  I've attached
/proc/interrupts from the factory BIOS.

Thanks,
Myles

[Rudolf Marek]

> Here's the same line from the factory BIOS:
> 9:          0           0            0              0

Yes this how it should look like ;)
> I wish I knew more about interrupts.  I'm surprised how different the
> routing is for interrupts between the factory BIOS and Coreboot, but
> I've been assuming they're routed correctly.  I've attached
> /proc/interrupts from the factory BIOS.

Hmm perhaps the chipset is setup differently. Question is from where the IRQ9 
comes from. Maybe some ACPI timer, but it is hard to tell. Maybe it is HPET?
Can you switch off hpet again?

Rudolf

[Myles Watson]

On Tue, Mar 10, 2009 at 7:44 AM, Rudolf Marek  wrote:
> > Here's the same line from the factory BIOS:
> >
> > 9:          0           0            0              0
>
> Yes this how it should look like ;)
> > I wish I knew more about interrupts.  I'm surprised how different the
> > routing is for interrupts between the factory BIOS and Coreboot, but
> > I've been assuming they're routed correctly.  I've attached
> > /proc/interrupts from the factory BIOS.
>
> Hmm perhaps the chipset is setup differently. Question is from where the
> IRQ9 comes from. Maybe some ACPI timer, but it is hard to tell. Maybe it is
> HPET?
> Can you switch off hpet again?

I did, but the interrupts are still there.  When the HPET is on, I get
this in my boot log:

hpet0: at MMIO 0xfed00000, IRQs 2, 8, 31
 hpet0: 3 32-bit timers, 25000000 Hz

At least no mention of IRQ 9 there.

Thanks,
Myles

[Myles Watson]

On Tue, Mar 10, 2009 at 8:09 AM, Myles Watson  wrote:
> On Tue, Mar 10, 2009 at 7:44 AM, Rudolf Marek  wrote:
> > > Here's the same line from the factory BIOS:
> > >
> > > 9:          0           0            0              0
> >
> > Yes this how it should look like ;)
> > > I wish I knew more about interrupts.  I'm surprised how different the
> > > routing is for interrupts between the factory BIOS and Coreboot, but
> > > I've been assuming they're routed correctly.  I've attached
> > > /proc/interrupts from the factory BIOS.
> >
> > Hmm perhaps the chipset is setup differently. Question is from where the
> > IRQ9 comes from.

I think it's interesting that there are no interrupt sources with that
many interrupts in the factory BIOS.  Maybe that's a hint?

Thanks,
Myles

[Myles Watson]

On Mon, Mar 9, 2009 at 5:08 PM, Rudolf Marek  wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> /* If this is the SouthBridge node and link, add a DRAM region. */
> If (LOr (LAnd (LEqual (Arg1, 0xFF), LEqual
>
> (Arg0, 0x00)), LEqual (Arg1, _SB.PCI0.SBLK)))
> {
> Store (_SB.PCI0.TOM1, MMIN)
> Subtract (MMAX, MMIN, MLEN)
> Increment (MLEN)
> }
>
> This part cause Windows 7 to BSOD and restart. Did not look at it yet. It starts
>  otherwise. (I added also the another Increment (MLEN), its late for me now to
> test without that).
>
> If you commit it with a proposed I think we can check in the patch. (dont know
> for fam10  maybe same change is needed).
>
> Acked-by: Rudolf Marek

Committed Rev 3986.

Thanks,
Myles

[Myles Watson]

On Mon, Mar 9, 2009 at 5:15 PM, Rudolf Marek  wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> Acked-by: Rudolf Marek

Here's the updated part of the patch.  I think it has changed enough
to need a second look.  I added a new place for high tables to live,
because when you have 4GB of RAM and no hoisting it messed up before.
I also disabled an extra ram_resource for the same case.

Signed-off-by: Myles Watson

Thanks,
Myles
> If you can explain to me why the superIO changes. Also The SMM does nothing to
> do with IRQ9. Get rid of SMM for now. The IRQ 9 needs to be setup for ACPI in
> SB. Thats it (and perhaps it needed also an IRQ override).
>
> It looks fine, assuming it works for you then lets put it in. A lot of people is
> trying to get ACPI working those days.
>
> Please note that some changes to second patch needs to be done too. For the
> global acpik8_util
>
> Rudolf

[Stefan Reinauer]

On 10.03.2009 21:27 Uhr, Myles Watson wrote:
> On Mon, Mar 9, 2009 at 5:15 PM, Rudolf Marek  wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hi,
> >
> > Acked-by: Rudolf Marek
>
> Here's the updated part of the patch.  I think it has changed enough
> to need a second look.  I added a new place for high tables to live,
> because when you have 4GB of RAM and no hoisting it messed up before.
> I also disabled an extra ram_resource for the same case.
>
> Signed-off-by: Myles Watson

Acked-by: Stefan Reinauer
> Thanks,
> Myles
> > If you can explain to me why the superIO changes. Also The SMM does nothing to
> > do with IRQ9. Get rid of SMM for now. The IRQ 9 needs to be setup for ACPI in
> > SB. Thats it (and perhaps it needed also an IRQ override).
> >
> > It looks fine, assuming it works for you then lets put it in. A lot of people is
> > trying to get ACPI working those days.
> >
> > Please note that some changes to second patch needs to be done too. For the
> > global acpik8_util
> >
> > Rudolf

[Myles Watson]

On Tue, Mar 10, 2009 at 2:31 PM, Stefan Reinauer  wrote:
> On 10.03.2009 21:27 Uhr, Myles Watson wrote:
>
> On Mon, Mar 9, 2009 at 5:15 PM, Rudolf Marek  wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> Here's the updated part of the patch.  I think it has changed enough
> to need a second look.  I added a new place for high tables to live,
> because when you have 4GB of RAM and no hoisting it messed up before.
> I also disabled an extra ram_resource for the same case.
>
> Signed-off-by: Myles Watson
>
> Acked-by: Stefan Reinauer

Rev 3988.

Thanks,
Myles

[Myles Watson]

On Mon, Mar 9, 2009 at 5:15 PM, Rudolf Marek  wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> Acked-by: Rudolf Marek

Rev 3989.

Thanks,
Myles

[Peter Stuge]

Myles Watson wrote:
> > Maybe some ACPI GP timer is generating the IRQ9?
>
> I wish I knew more about interrupts.

Ok. Which chipset is this? Can we have a look at the interrupt router
registers - maybe get them into msrtool - to see what is actually
configured to IRQ9 with coreboot?

//Peter

[Myles Watson]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Peter Stuge
> Sent: Tuesday, March 10, 2009 4:18 PM
> To: [e-mail]
> Subject: Re: [coreboot] ACPI patches for Tyan s2895, s2892, s2891
>
> Myles Watson wrote:
> > > Maybe some ACPI GP timer is generating the IRQ9?
> >
> > I wish I knew more about interrupts.
>
> Ok. Which chipset is this? Can we have a look at the interrupt router
> registers - maybe get them into msrtool - to see what is actually
> configured to IRQ9 with coreboot?

Nvidia ck804.  No docs, but Rudolf pointed out that someone has already
decoded some of the register values:
http://www.coreboot.org/Nvidia_CK804_Porting_Notes

I guess I could continue their work with setpci.  Is there a better way?

Thanks,
Myles