Hi,
I've tried Harald Gutman's ACPI patch for gigabyte m57sli and I can successfully boot Linux with it (straight from flash, 2MB), and, as a bonus, the proprietary NVIDIA driver for X works too with full glx acceleration, hurray!
There are still some errors in dmesg regarding ACPI, though, which is probably why the powernow cpu frequency scaling doesn't work yet. Most notably the FACP checksum is incorrect.
For some strange reason, the ethernet device is 'renamed' to eth1, eth0 doesn't work.
I've attached the output of dmesg.
On Tue, May 26, 2009 at 11:07:20PM +0200, Ronald Hoogenboom wrote:
I've tried Harald Gutman's ACPI patch for gigabyte m57sli and I can successfully boot Linux with it (straight from flash, 2MB), and, as a bonus, the proprietary NVIDIA driver for X works too with full glx acceleration, hurray!
There are still some errors in dmesg regarding ACPI, though, which is probably why the powernow cpu frequency scaling doesn't work yet. Most notably the FACP checksum is incorrect.
For some strange reason, the ethernet device is 'renamed' to eth1, eth0 doesn't work.
That's probably caused by udev, because the mac address for the network device is stored in the rom image (talk about an ... unfortunate design decision...) in mcp55.
Thanks, Ward.
On Tue, May 26, 2009 at 2:13 PM, Ward Vandewege ward@gnu.org wrote:
On Tue, May 26, 2009 at 11:07:20PM +0200, Ronald Hoogenboom wrote:
For some strange reason, the ethernet device is 'renamed' to eth1, eth0 doesn't work.
That's probably caused by udev, because the mac address for the network device is stored in the rom image (talk about an ... unfortunate design decision...) in mcp55.
mine does that with the factory bios ...
ron
On Tue, May 26, 2009 at 05:11:17PM -0700, ron minnich wrote:
On Tue, May 26, 2009 at 2:13 PM, Ward Vandewege ward@gnu.org wrote:
On Tue, May 26, 2009 at 11:07:20PM +0200, Ronald Hoogenboom wrote:
For some strange reason, the ethernet device is 'renamed' to eth1, eth0 doesn't work.
That's probably caused by udev, because the mac address for the network device is stored in the rom image (talk about an ... unfortunate design decision...) in mcp55.
mine does that with the factory bios ...
Oh, yeah, absolutely, it's a hardware 'feature' of that chipset.
Thanks, Ward.
On Tuesday 26 May 2009 23:07:20 Ronald Hoogenboom wrote:
Hi,
I've tried Harald Gutman's ACPI patch for gigabyte m57sli and I can successfully boot Linux with it (straight from flash, 2MB), and, as a bonus, the proprietary NVIDIA driver for X works too with full glx acceleration, hurray!
Nice to hear that!
There are still some errors in dmesg regarding ACPI, though, which is probably why the powernow cpu frequency scaling doesn't work yet. Most notably the FACP checksum is incorrect.
The problem of the FACP checksum I've not been investigating until now.
For some strange reason, the ethernet device is 'renamed' to eth1, eth0 doesn't work.
This is just udev and or cb related, because cb mac-address differs from the original mac, you chan change that somewhere in the config.lb i think.
I've attached the output of dmesg.
I'll have a look at that.
In the last few weeks I've not been working on that patch. The state of it ACPI in my cb-tree is ATM the one which is described in the wiki page of coreboot.org, the same with the PCI interrupt problems.
Until now it's just the dsdt.asl which needs to be created from scratch, because the used one is taken from the proprietary bios. After that step i think it should be possible to commit this code.
Another thing which could be done, or should be done, is to try to activate the ACPI suspend features, but i don't know the state of the code which has been written by Rudolf Marek for his Asus board.
Both, ACPI and PCI stuff, is working here on hardware rev2. I don't know exactly if this is the same for rev1.
Furthermore to get M57SLI ACPI support "complete" the acpi_fill_mcfg part should be done, but right now it seems that there is no address available in the cb code which represents the address needed.
The thing with m57sli is that v1 and v2 seem the be hardware-different in some interrupt/acpi related parts, so to get a fine patch which solves that problems it would be necessary to test and correct newly provided patches an both hardware versions.
For the working NVIDIA card which you pointed out: ATM your dsdt.asl is used to initialize that correctly and that's not the fine way to do it. It would be better/easier to correct mptable.c to suite the hardware (which i've allready done for v2 - without testing pci-e 1x) and then continue to create a valid dsdt.asl.
If you like to help me to get that stuff done, i think I'll have some more time in the next weeks/weekends.
Kind regards, Harald
Hi Harald, Thanks for the response.
Harald Gutmann schreef:
On Tuesday 26 May 2009 23:07:20 Ronald Hoogenboom wrote:
There are still some errors in dmesg regarding ACPI, though, which is probably why the powernow cpu frequency scaling doesn't work yet. Most notably the FACP checksum is incorrect.
The problem of the FACP checksum I've not been investigating until now.
There were some prototype/pointer type issues I had to fix to get the patch compiled in the latest svn code, which was in some checksum calculation call. Maybe that's related?
For some strange reason, the ethernet device is 'renamed' to eth1, eth0 doesn't work.
This is just udev and or cb related, because cb mac-address differs from the original mac, you chan change that somewhere in the config.lb i think.
I'll find where the mac address is stored and replace it with the same one in the factory bios. I thought I did that already long ago, but maybe the location has been changed since?
I've attached the output of dmesg.
I'll have a look at that.
In the last few weeks I've not been working on that patch. The state of it ACPI in my cb-tree is ATM the one which is described in the wiki page of coreboot.org, the same with the PCI interrupt problems.
The PCI interrupts seems to be the thing that is fixed by your patch, because the nvidia display driver used to complain about interrupts not working without your patch, now it works fine.
Until now it's just the dsdt.asl which needs to be created from scratch, because the used one is taken from the proprietary bios. After that step i think it should be possible to commit this code.
Does it also contain fixed powernow speed/voltages for YOUR processor? Linux complains about a device not found, which is probably your processor, which is different from mine...
Another thing which could be done, or should be done, is to try to activate the ACPI suspend features, but i don't know the state of the code which has been written by Rudolf Marek for his Asus board.
ACPI power off works fine, which is the most important for me (and probably most others...).
Both, ACPI and PCI stuff, is working here on hardware rev2. I don't know exactly if this is the same for rev1.
I only have a V2 board.
Furthermore to get M57SLI ACPI support "complete" the acpi_fill_mcfg part should be done, but right now it seems that there is no address available in the cb code which represents the address needed.
Is that essential?
The thing with m57sli is that v1 and v2 seem the be hardware-different in some interrupt/acpi related parts, so to get a fine patch which solves that problems it would be necessary to test and correct newly provided patches an both hardware versions.
For the working NVIDIA card which you pointed out: ATM your dsdt.asl is used to initialize that correctly and that's not the fine way to do it. It would be better/easier to correct mptable.c to suite the hardware (which i've allready done for v2 - without testing pci-e 1x) and then continue to create a valid dsdt.asl.
If you like to help me to get that stuff done, i think I'll have some more time in the next weeks/weekends.
Kind regards, Harald
Thanks, I'll keep you posted. Ronald.
On Wednesday 27 May 2009 19:04:53 you wrote:
Hi Harald, Thanks for the response.
No problem, it's also in my interest to get ACPI working on M57SLI.
There were some prototype/pointer type issues I had to fix to get the patch compiled in the latest svn code, which was in some checksum calculation call. Maybe that's related?
The problem with the FACP checksum always occurred here. I don't know if this is related to your changes, but for me it has never worked.
I'll find where the mac address is stored and replace it with the same one in the factory bios. I thought I did that already long ago, but maybe the location has been changed since?
The PCI interrupts seems to be the thing that is fixed by your patch, because the nvidia display driver used to complain about interrupts not working without your patch, now it works fine.
This just seems to be, because IRQ routing is stored is some different tables. Until my patch it used to be the MPTABLE which is filled through the mptable.c, which is not really fixed now, but Linux uses now the ACPI table for the IRQ routing descriptions, which is in fact the vendors dsdt.asl, and this one we are not allowed to use in coreboot.
So this problems are not fixed, but the ACPI layer just "hided" this problem. Most for most of the mptable stuff I have some patches, which also allow to use the graphics device without ACPI enabled coreboot. This should be no big thing to get fixed, because most of the work is already done, it would be good if someone could check this on his hardware, and the code too. (Fixing it in mptable.c is not really necessary when you put a correct ACPI table in the dstd.asl, but I'd prefer this solution to fix/test, because the changes are quite marginal.)
When we have a fine/correct mptable.c it should be not really much work to set up an own, short, free dsdt.asl and maybe then use the mptable just when ACPI is turned off in the config.
Does it also contain fixed powernow speed/voltages for YOUR processor? Linux complains about a device not found, which is probably your processor, which is different from mine...
PowerNow has worked here, but it offered one more option on the processor for setting it's speed. I checked the values in cpuinfo or with x86info and calculated had a look at the bios ... manual from AMD for my processor and everything seemed to be correct.
Also on the IRC channel (or even on the ML?) some people thought that this is a "bug" in the vendors bios to not offer that mode.
ACPI power off works fine, which is the most important for me (and probably most others...).
Yes, that works fine on v2 too, and i think it should be quite easy to add some more ACPI features based on the code from Rudolf Marek who implemented S3 wakeup on his board.
I only have a V2 board.
Me too, but i don't wan't to break something for v1 on committing some changes which are proved to work on v2 only.
Furthermore to get M57SLI ACPI support "complete" the acpi_fill_mcfg part should be done, but right now it seems that there is no address available in the cb code which represents the address needed.
Is that essential?
Not really, and I think this could be ignored, but it would be fine to have it, so that booting is "error-free".
Thanks, I'll keep you posted. Ronald.
Kind regards, Harald
PS: I think it would be better to keep this discussion on the mailing list, so everyone can post his hints/opinions/suggestions to that topic.
Hi Harald,
I fixed some stuff and made a new build. * now my NIC MAC address is same as factory (in romstrap.inc): no 'renaming' anymore. * now the FACP checksum is correct (new fadt.c attached) * powernow still doesn't work (enabled the commented acpi_fill_ssdt_generator in acpi.c, but doesn't help...)
New artefact: ACPI Error (evgpeblk-1156): GPE0 block (GPE 0 to 31) overlaps the GPE1 block (GPE 20 to 59) - Ignoring GPE1 [20070126]
Continued artefacts: ACPI Exception (processor_core-0818): AE_NOT_FOUND, Processor Device is not present [20070126] (2 times) powernow-k8: MP systems not supported by PSB BIOS structure (2 times)
On Wed, 2009-05-27 at 20:54 +0200, Harald Gutmann wrote:
PS: I think it would be better to keep this discussion on the mailing list, so everyone can post his hints/opinions/suggestions to that topic.
Mailing list is copied too...
Best regards, Ronald.
On Wednesday 27 May 2009 22:25:34 Ronald Hoogenboom wrote:
Hi Harald,
I fixed some stuff and made a new build.
- now my NIC MAC address is same as factory (in romstrap.inc): no
'renaming' anymore.
- now the FACP checksum is correct (new fadt.c attached)
- powernow still doesn't work (enabled the commented
acpi_fill_ssdt_generator in acpi.c, but doesn't help...)
New artefact: ACPI Error (evgpeblk-1156): GPE0 block (GPE 0 to 31) overlaps the GPE1 block (GPE 20 to 59) - Ignoring GPE1 [20070126]
Needs to be investigated. I did see such errors, but i don't really know how to fix it. I always compared the acpidump/iasl disassembled table files with the original bios files to find and eliminate errors.
Continued artefacts: ACPI Exception (processor_core-0818): AE_NOT_FOUND, Processor Device is not present [20070126] (2 times) powernow-k8: MP systems not supported by PSB BIOS structure (2 times)
I know that message, and it's quite simple to fix as i can remember, which will also enable PowerNow the right way (Maybe there has been some more modification to get it working.), but where has it been.... - for sure this is dsdt.asl related.
For two CPU's try e.g:
Scope (_PR) { Processor (_PR.C000, 0x00, 0x00000000, 0x00) {} Processor (_PR.C001, 0x01, 0x00000000, 0x00) {} }
This should be found on quite top of the dsdt.asl file. The original dsdt.asl from one of my first patches contains there fore lines for processors, and as there are e.g. two cores available you get that errors on booting.
(It could also be solved including the "amdk8_util.asl" in your dsdt.asl, and removing the right parts which are given/generated by the "amdk8_util.asl" file.)
Include ("../../../../src/northbridge/amd/amdk8/amdk8_util.asl")
I don't know which CPU you use, and which dsdt.asl (or which version of my patch), but try to modify dsdt.asl that far, that there are only that much CPU entries as your CPU has cores.
On Wed, 2009-05-27 at 20:54 +0200, Harald Gutmann wrote:
PS: I think it would be better to keep this discussion on the mailing list, so everyone can post his hints/opinions/suggestions to that topic.
Mailing list is copied too...
Fine, at the first mail i didn't recognize that it was CC'd to the ML.
Best regards, Ronald.
Kind regards, Harald
PS: I'll be off for the next few days (maybe till Monday).
On Wednesday 27 May 2009 22:25:34 Ronald Hoogenboom wrote:
Hi Harald,
I fixed some stuff and made a new build.
- now my NIC MAC address is same as factory (in romstrap.inc): no
'renaming' anymore.
- now the FACP checksum is correct (new fadt.c attached)
I had a quick look at the fadt.c and it looks good!
The TODO you added is also a known problem, but i think it's not a big problem. But i also can't say if this will disappear if you turn off acpi-debug, because here it's enabled too.
This time i added a diff on my acpi tree of cb to the acpi_tables.c file. You also *need* the DYNDATA generator to get PowerNow working. Have a look on that, it *should* work, i don't know it exactly, because it's a few weeks over when I experimented the last time with this code.
I think the essential part of the diff is this one: + /* DYNADATA */ /* used by the PowerNow! generator */ + acpi_create_ssdt_generator(ssdt, "DYNADATA"); + current += ssdt->length; + acpi_add_table(rsdt, ssdt);
- powernow still doesn't work (enabled the commented
acpi_fill_ssdt_generator in acpi.c, but doesn't help...)
Hopefully you'll get that with my comments. :)
Kind regards, Harald
Best regards, Ronald.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi all,
Just FYI http://www.coreboot.org/ACPI_in_coreboot
I added there some time ago info about the ACPIGEN.
Rudolf
Hi Harald,
I added the DYNADATA and the other stuff that was missing (HPET, SLIT, SSDT) in my acpi_tables.c according to your patch (thanks!).
I removed 2 of the 4 processors in dsdt.dsl.
Now the processor device not present is gone. powernow still doesn't work: powernow-k8: MP systems not supported by PSB BIOS structure The message about overlapping GPE0 and GPE1 is still there.
There are new errors (twice): BIOS reported wrong ACPI idfor the processor ACPI Exception (evxface-0544): AE_NOT_EXIST, Removing notify handler [20070126]
Regards, Ronald.
-
Harald Gutmann -
ron minnich -
Ronald Hoogenboom -
Ronald Hoogenboom -
Rudolf Marek -
Ward Vandewege