Hello,
a few hours ago i started to address the PCI/PCI-E problems on the M57SLI-S4 (rev. 2) and here is the result of the moment.
PCI-E grapic adapter works fine with the proprietary nvidia driver! (And the GPIO configuration in cache_as_ram_auto.c should be fully corrected.)
The patch for that solution(s) is attached. (I don't know if this will work on v1 too, but i assume it will. I also don't know right now if there are more problems cleaned out with that patch.)
Please be so kindly, and don't ask why the value has changed from "68" (which is the same in original bios) to "A8", but recently it's necessary to do it, because otherwise the value is wrong when you read it out from a running system.
Kind Regards, Harald
If someone can test and confirm that patch, here is my:
Signed-off-by: Harald Gutmann harald.gutmann@gmx.net
Kind regards, Harald
On Tuesday 24 March 2009 18:54:37 Harald Gutmann wrote:
Hello,
a few hours ago i started to address the PCI/PCI-E problems on the M57SLI-S4 (rev. 2) and here is the result of the moment.
PCI-E grapic adapter works fine with the proprietary nvidia driver! (And the GPIO configuration in cache_as_ram_auto.c should be fully corrected.)
The patch for that solution(s) is attached. (I don't know if this will work on v1 too, but i assume it will. I also don't know right now if there are more problems cleaned out with that patch.)
Please be so kindly, and don't ask why the value has changed from "68" (which is the same in original bios) to "A8", but recently it's necessary to do it, because otherwise the value is wrong when you read it out from a running system.
Kind Regards, Harald
So, after trying to figure out some stuff, and getting helped in some cases, here is the next result.
This Fix patches some incorrect things in mptable.c and includes the first patch as well. The difference now is, that PCI-E graphics work well without ACPI support (which is in work for that board.) Last time the PCI-E card worked here because i used my source tree with acpi- support and not a plain v2 tree. In that acpi-tree there was the original bios dsdt.asl, which included the pci routing table.
I want to give special thanks to Rudolf Ruik Marek which helped me to figure out the right PCI Routing Table from the vendors dsdt.asl file. *Thanks!*
My patch is attached, and works here on the hardware revision 2 of the m57sli. I hope it will work also on v1 and is helpful to others. In the patch there are a few TODO's marked, maybe someone could help to find that out/fix that. (Most of this is checking the configuration again.) Maybe there stay some errors with the interrupt routing on the PCI-E 1x ports, but i can't do that easily because i've no hardware which uses PCI-E 1x.
After having that patch verified by others, it should be possible to complete the ACPI-support for the M57SLI in a few hours. Otherwise it would be necessary to get some information of the v1 boards. (dsdt.asl/dsl (use acpidump, iasl), dmesg | grep -i acpi, lspci from linux running the vendors bios.)
I hope that this could be done in the next days, and i'm really looking forward to a fully working coreboot support for M57SLI. :)
Hi Harald,
Great work! I'll test it tomorrow on a v1 board.
On Tue, Mar 31, 2009 at 05:44:50PM +0200, Harald Gutmann wrote:
/* TODO: Check why udev renames eth0 to eth1 at boot time */- PCI_INT(0,sbdn+8,0, 22); /* GBit Ether */
If you check, you'll find your mac address to be different under coreboot. That's because for mcp55-based nics, the mac address is stored in the bios rom image.
I have a script that I use to binary patch coreboot rom images with a different mac address. It's attached.
Thanks, Ward.
On Tuesday 31 March 2009 17:57:40 Ward Vandewege wrote:
Hi Harald,
Great work! I'll test it tomorrow on a v1 board.
That would be really fine, because if there are some differences we need to find a way to get the source working on both hardware revisions. We could use for that reasons a new CONFIG entry in the Config.lb, but hopefully we won't need that stuff.
On Tue, Mar 31, 2009 at 05:44:50PM +0200, Harald Gutmann wrote:
/* TODO: Check why udev renames eth0 to eth1 at boot time */- PCI_INT(0,sbdn+8,0, 22); /* GBit Ether */
If you check, you'll find your mac address to be different under coreboot. That's because for mcp55-based nics, the mac address is stored in the bios rom image.
I have a script that I use to binary patch coreboot rom images with a different mac address. It's attached.
Fine, that's nice to know, i just looked in the source and saw that the MAC- address is set in romstrap.inc under src/southbridge/nvidia/mcp55/romstrapc.inc. So one TODO is already done, the others should be also easy to clear if someone could send the output's which are necessary to verify from a v1 board. I mentioned those things in the first mail according to that patch.
Maybe it would be good to add a configuration-field in the buildrom-devel to be able to set this before building the image.
Thanks, Ward.
Kind regards, Harald
Hello once again, today Ward was able to test this patch on his mainboard, and it seems that nearly everything worked like supposed.
I missed, that this mainboard has a second PCI-E 16x port which wasn't initialized correctly in my previous patch.
This patch appended should clean up initialization of the second PCI-E 16x port too. I also just forgot in the last patch to do a correct init of the IDE controller.
What has not been verified until now are the PCI-1x ports, but neither Ward nor i own PCI-1x hardware. So it would be good if someone else, which has this mainboard and a PCI-1x card could help us to get the last PCI-(E) things working.
It would be grate if someone could verify my changes.
Signed-off-by: Harald Gutmann harald.gutmann@gmx.net
Kind regards, Harald
The last patch had a mistake somewhere because patch complains about a malform patch format.
This one is the same, and just comments have been modified slightly.
Signed-off-by: Harald Gutmann harald.gutmann@gmx.net
Kind Regards, Harald
On Thu, Apr 02, 2009 at 10:01:36PM +0200, Harald Gutmann wrote:
The last patch had a mistake somewhere because patch complains about a malform patch format.
This one is the same, and just comments have been modified slightly.
OK, so this one makes the second (black) pcie x16 slot happy:
[ 6.126711] 0000:02:00.0: eth2: (PCI Express:2.5GB/s:Width x4) 00:15:17:0b:d4:9e [ 6.128034] 0000:02:00.0: eth2: Intel(R) PRO/1000 Network Connection [ 6.132110] 0000:02:00.0: eth2: MAC: 0, PHY: 4, PBA No: d50868-001 [ 6.136087] e1000e 0000:02:00.1: setting latency timer to 64 [ 6.318689] 0000:02:00.1: eth3: (PCI Express:2.5GB/s:Width x4) 00:15:17:0b:d4:9f [ 6.320033] 0000:02:00.1: eth3: Intel(R) PRO/1000 Network Connection [ 6.324106] 0000:02:00.1: eth3: MAC: 0, PHY: 4, PBA No: d50868-001
I tested by copying a large (400M) file at wirespeed from both of those interfaces. No problems.
I also have an old 3com nic in this machine, in one of the PCI slots (the one closest to the edge). I also copied that large file from that nic, without problems.
However, I got this after having the machine up for a while:
[ 999.664992] Uhhuh. NMI received for unknown reason 00. [ 999.665144] Uhhuh. NMI received for unknown reason a1. [ 999.665147] You have some hardware problem, likely on the PCI bus. [ 999.665149] Dazed and confused, but trying to continue [ 999.667309] Do you have a strange power saving mode enabled? [ 999.667309] Dazed and confused, but trying to continue
This was right after I did
cat /proc/interrupts
a couple times - but that may have been a coincidence.
Ideas?
Thanks, Ward.
On Friday 03 April 2009 21:33:15 Ward Vandewege wrote: The first part of your message was fine to read, but this one worries me a little bit.
However, I got this after having the machine up for a while:
[ 999.664992] Uhhuh. NMI received for unknown reason 00. [ 999.665144] Uhhuh. NMI received for unknown reason a1. [ 999.665147] You have some hardware problem, likely on the PCI bus. [ 999.665149] Dazed and confused, but trying to continue [ 999.667309] Do you have a strange power saving mode enabled? [ 999.667309] Dazed and confused, but trying to continue
This was right after I did
cat /proc/interrupts
a couple times - but that may have been a coincidence.
I think it could have been a coincidence, but i'd be interested in further details, as this is maybe a result of a "wrong" mptable setup.
Which kernel version did you use on which distribution? dmesg output, lspci output, /proc/interrupts, and anything else which could be interesting. :)
Ideas?
Right now, not really, but i saw according to your last outputs of m57sli which you gave to me, that something with the interrupts is different on v1 and v2 and proprietary bios. This could also be a related to different bios versions we use, but also it could be a hardware difference which we should take care about.
I think for simplifying/sorting out things, it would be good if you could switch to the same vendor bios version that i use and resend me your acpidump/dmesg/lspci from the vendor bios. I use version FG for v2 which is dated on 2008/03/07 and, i think, is equal to F14 of v1 which is dated on the same day.
Maybe it will be necessary to introduce some config value like: CONFIG_M57SLI_HARDWARE_REVISION to get the interrupt problem fixed on both versions of m57sli. A hardware difference could also have been the reason why Soft-Poweroff didn't work on your v1 while it worked fine on my v2.
I hope we can avoid that step and the mistake is located somewhere else, but we'll see.
Thanks, Ward.
Thanks for testing, kind regards Harald
On Sat, Apr 04, 2009 at 12:54:52PM +0200, Harald Gutmann wrote:
On Friday 03 April 2009 21:33:15 Ward Vandewege wrote: The first part of your message was fine to read, but this one worries me a little bit.
However, I got this after having the machine up for a while:
[ 999.664992] Uhhuh. NMI received for unknown reason 00. [ 999.665144] Uhhuh. NMI received for unknown reason a1. [ 999.665147] You have some hardware problem, likely on the PCI bus. [ 999.665149] Dazed and confused, but trying to continue [ 999.667309] Do you have a strange power saving mode enabled? [ 999.667309] Dazed and confused, but trying to continue
This was right after I did
cat /proc/interrupts
a couple times - but that may have been a coincidence.
I think it could have been a coincidence, but i'd be interested in further details, as this is maybe a result of a "wrong" mptable setup.
OK.
Which kernel version did you use on which distribution?
Linux radio 2.6.27-7-generic #1 SMP Tue Nov 4 19:33:06 UTC 2008 x86_64 GNU/Linux
That's on ubuntu 8.10, 64 bit as you can see.
dmesg output, lspci output, /proc/interrupts, and anything else which could be interesting. :)
Sure. This is with the f14 bios:
http://ward.vandewege.net/coreboot/m57sli/v1.1/m57sli-v1.1-f14-nic-in-black-... http://ward.vandewege.net/coreboot/m57sli/v1.1/m57sli-v1.1-f14-nic-in-black-... http://ward.vandewege.net/coreboot/m57sli/v1.1/m57sli-v1.1-f14-nic-in-black-... http://ward.vandewege.net/coreboot/m57sli/v1.1/m57sli-v1.1-f14-nic-in-black-... http://ward.vandewege.net/coreboot/m57sli/v1.1/m57sli-v1.1-f14-nic-in-black-...
And this is with your latest patch:
http://ward.vandewege.net/coreboot/m57sli/v1.1/m57sli-v1.1-cb-interrupt-patc... http://ward.vandewege.net/coreboot/m57sli/v1.1/m57sli-v1.1-cb-interrupt-patc... http://ward.vandewege.net/coreboot/m57sli/v1.1/m57sli-v1.1-cb-interrupt-patc... http://ward.vandewege.net/coreboot/m57sli/v1.1/m57sli-v1.1-cb-interrupt-patc... http://ward.vandewege.net/coreboot/m57sli/v1.1/m57sli-v1.1-cb-interrupt-patc...
The machine seems a bit unhappy - sluggish over ssh but not on console. X was sucking up a lot of CPU too. Something isn't quite right I think.
Thanks, Ward.
On Tuesday 07 April 2009 22:16:08 Ward Vandewege wrote:
On Sat, Apr 04, 2009 at 12:54:52PM +0200, Harald Gutmann wrote:
On Friday 03 April 2009 21:33:15 Ward Vandewege wrote: The first part of your message was fine to read, but this one worries me a little bit.
However, I got this after having the machine up for a while:
[ 999.664992] Uhhuh. NMI received for unknown reason 00. [ 999.665144] Uhhuh. NMI received for unknown reason a1. [ 999.665147] You have some hardware problem, likely on the PCI bus. [ 999.665149] Dazed and confused, but trying to continue [ 999.667309] Do you have a strange power saving mode enabled? [ 999.667309] Dazed and confused, but trying to continue
This was right after I did
cat /proc/interrupts
a couple times - but that may have been a coincidence.
I think it could have been a coincidence, but i'd be interested in further details, as this is maybe a result of a "wrong" mptable setup.
OK.
Which kernel version did you use on which distribution?
Linux radio 2.6.27-7-generic #1 SMP Tue Nov 4 19:33:06 UTC 2008 x86_64 GNU/Linux
That's on ubuntu 8.10, 64 bit as you can see.
dmesg output, lspci output, /proc/interrupts, and anything else which could be interesting. :)
Sure. This is with the f14 bios:
http://ward.vandewege.net/coreboot/m57sli/v1.1/m57sli-v1.1-f14-nic-in-black -pcie-lspci http://ward.vandewege.net/coreboot/m57sli/v1.1/m57sli-v1.1-f14-nic-in-black -pcie-lspci-vvvvvxxxxxx http://ward.vandewege.net/coreboot/m57sli/v1.1/m57sli-v1.1-f14-nic-in-black -pcie-dmesg http://ward.vandewege.net/coreboot/m57sli/v1.1/m57sli-v1.1-f14-nic-in-black -pcie-cat-proc-interrupts http://ward.vandewege.net/coreboot/m57sli/v1.1/m57sli-v1.1-f14-nic-in-black -pcie-acpidump
And this is with your latest patch:
http://ward.vandewege.net/coreboot/m57sli/v1.1/m57sli-v1.1-cb-interrupt-pat ch-20090403-nic-in-black-pcie-lspci http://ward.vandewege.net/coreboot/m57sli/v1.1/m57sli-v1.1-cb-interrupt-pat ch-20090403-nic-in-black-pcie-lspci-vvvvvxxxxxx http://ward.vandewege.net/coreboot/m57sli/v1.1/m57sli-v1.1-cb-interrupt-pat ch-20090403-nic-in-black-pcie-dmesg http://ward.vandewege.net/coreboot/m57sli/v1.1/m57sli-v1.1-cb-interrupt-pat ch-20090403-nic-in-black-pcie-cat-proc-interrupts http://ward.vandewege.net/coreboot/m57sli/v1.1/m57sli-v1.1-cb-interrupt-pat ch-20090403-nic-in-black-pcie-acpidump
The machine seems a bit unhappy - sluggish over ssh but not on console. X was sucking up a lot of CPU too. Something isn't quite right I think.
That's also my opinion, maybe most of the code in the tree is right for v1 (especially the dwords), and just a few lines are false/missing.
Maybe this patch is enough for v1.
Thanks, Ward.
Kind regards, Harald
Index: mptable.c
--- mptable.c (revision 4027) +++ mptable.c (working copy)
Please always add a Signed-off-by to all patches you send, see
http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure
Thanks, Uwe.
-
Harald Gutmann -
Uwe Hermann -
Ward Vandewege