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