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 mylesgw@gmail.com
Thanks, Myles
On Fri, Feb 27, 2009 at 3:23 PM, Myles Watson mylesgw@gmail.com 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
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 mylesgw@gmail.com
Regards, Carl-Daniel
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
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 mylesgw@gmail.com
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
-----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 r.marek@assembler.cz
Rudolf
On Mon, Mar 9, 2009 at 5:08 PM, Rudolf Marek r.marek@assembler.cz 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 r.marek@assembler.cz
Committed Rev 3986.
Thanks, Myles
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
Acked-by: Rudolf Marek r.marek@assembler.cz
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
On Mon, Mar 9, 2009 at 4:15 PM, Rudolf Marek r.marek@assembler.cz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
Acked-by: Rudolf Marek r.marek@assembler.cz
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
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
On Tue, Mar 10, 2009 at 7:00 AM, Rudolf Marek r.marek@assembler.cz 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
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
On Tue, Mar 10, 2009 at 7:19 AM, Rudolf Marek r.marek@assembler.cz 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
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
On Tue, Mar 10, 2009 at 7:44 AM, Rudolf Marek r.marek@assembler.cz 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
On Tue, Mar 10, 2009 at 8:09 AM, Myles Watson mylesgw@gmail.com wrote:
On Tue, Mar 10, 2009 at 7:44 AM, Rudolf Marek r.marek@assembler.cz 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 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
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Peter Stuge Sent: Tuesday, March 10, 2009 4:18 PM To: coreboot@coreboot.org 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
On Mon, Mar 9, 2009 at 5:15 PM, Rudolf Marek r.marek@assembler.cz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
Acked-by: Rudolf Marek r.marek@assembler.cz
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 mylesgw@gmail.com
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
On 10.03.2009 21:27 Uhr, Myles Watson wrote:
On Mon, Mar 9, 2009 at 5:15 PM, Rudolf Marek r.marek@assembler.cz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
Acked-by: Rudolf Marek r.marek@assembler.cz
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 mylesgw@gmail.com
Acked-by: Stefan Reinauer stepan@coresystems.de
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
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On Tue, Mar 10, 2009 at 2:31 PM, Stefan Reinauer stepan@coresystems.de wrote:
On 10.03.2009 21:27 Uhr, Myles Watson wrote:
On Mon, Mar 9, 2009 at 5:15 PM, Rudolf Marek r.marek@assembler.cz 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 mylesgw@gmail.com
Acked-by: Stefan Reinauer stepan@coresystems.de
Rev 3988.
Thanks, Myles
On Mon, Mar 9, 2009 at 5:15 PM, Rudolf Marek r.marek@assembler.cz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
Acked-by: Rudolf Marek r.marek@assembler.cz
Rev 3989.
Thanks, Myles