Hi,
I've got the mobo in a state where it finishes the coreboot, elfboot fetches the linux kernel from SPI flash and I can see the 'earlyprintk' messages generated by that kernel on the serial port. The VGA console is not working, though.
My VGA is a nvidia 8600GT (10de/0402).
Looking at the messages related to the VGA initialization, I notice the following:
-- During coreboot 'Initializing devices', the following is printed:
rom address for PCI: 07:00.0 = f7000000 Incorrect Expansion ROM Header Signature ffff
-- The VGA card is on PCI bus 07 according to coreboot, but on bus 02 according to 'lspci' when booted with proprietary bios.
-- Several memory ranges are different.
lspci: Memory at fa000000 (32-bit, non-prefetchable) [size=16M] coreb: [0x00f6000000 - 0x00f6ffffff] size 0x01000000 gran 0x18 mem
lspci: Memory at e0000000 (64-bit, prefetchable) [size=256M] coreb: [0x00f4000000 - 0x00f5ffffff] size 0x02000000 gran 0x19 mem64
lspci: Memory at f8000000 (64-bit, non-prefetchable) [size=32M] coreb: [0x00f4000000 - 0x00f5ffffff] size 0x02000000 gran 0x19 mem64
lspci: I/O ports at 9000 [size=128] coreb: [0x0000001000 - 0x000000107f] size 0x00000080 gran 0x07 io
lspci: [virtual] Expansion ROM at fb000000 [disabled] [size=128K] coreb: [0x00f7000000 - 0x00f701ffff] size 0x00020000 gran 0x11 romem
** This last one is where the signature is wrong
When the kernel switches from the 'earlyprintk' console to the normal console, it sometimes hangs just before and sometimes right after. It reports using a 'dummy colour VGA console' then (probably because there isn't a real one...).
Is the PCI bus number difference an issue here? I think it just means that the K8 HT Host bridge is initialized differently... Shouldn't be a problem(?). The expansion ROM signature ffff seems to me that the reported memory range is NOT where the ROM actually is. How can that be gotten wrong? PCI should be Plug and Play, not? Is the expansion ROM actually used for VGA console?
Please help. I think other users would be interested to see this setup work. Nice addition to the m57sli tutorial.
Ronald.
On Feb 9, 2008 2:33 PM, Ronald Hoogenboom ronald@zonnet.nl wrote:
-- During coreboot 'Initializing devices', the following is printed:
rom address for PCI: 07:00.0 = f7000000 Incorrect Expansion ROM Header Signature ffff
Hmm. that's bad. :-)
-- The VGA card is on PCI bus 07 according to coreboot, but on bus 02 according to 'lspci' when booted with proprietary bios.
That's ok. Bus ordering can be different on these newer systems.
lspci: [virtual] Expansion ROM at fb000000 [disabled] [size=128K] coreb: [0x00f7000000 - 0x00f701ffff] size 0x00020000 gran 0x11 romem
I don't think this is an issue.
0xffff means it's not set up correctly and so you're just reading back 'floating bus'.
weird.
Is the PCI bus number difference an issue here? I think it just means that the K8 HT Host bridge is initialized differently... Shouldn't be a problem(?).
Right.
The expansion ROM signature ffff seems to me that the reported memory range is NOT where the ROM actually is. How can that be gotten wrong? PCI should be Plug and Play, not? Is the expansion ROM actually used for VGA console?
Yeah. I am not sure what could be wrong here. Usually this step works just fine.
You should try to DISABLE vga in bios, and try to get it to boot at all, and then work on it from single user mode. That would be my debug strategy anyway.
ron
On Sat, 2008-02-09 at 14:39 -0800, ron minnich wrote:
Yeah. I am not sure what could be wrong here. Usually this step works just fine.
You should try to DISABLE vga in bios, and try to get it to boot at all, and then work on it from single user mode. That would be my debug strategy anyway.
OK, I've switched to all-serial console using kernel parameters "ro root=/dev/sda2 rhgb earlyprintk=serial,ttyS0,115200 console=ttyS0,115200 noapic". When using kexec with the same elf image, I get a bash prompt on the serial line. The 'noapic' was needed because otherwise there is trouble with the APIC timer. Booting with coreboot gets me a lot further than before, but now it fails to find the root filesystem on the SATA disk. Clues to why this is can be found in these kernel messages:
PCI: No IRQ known for interrupt pin A of device 0000:00:05.0. Please try using pci=biosirq. IRQ handler type mismatch for IRQ 0 current handler: timer
Call Trace: [<ffffffff8025af50>] setup_irq+0x1ba/0x1d5 ... [<ffffffff8020c1ce>] child_rip+0x0/0x12
sata_nv: probe of 0000:00:05.0 failed with error -16
...(same for 00:05.1 and 00:05.2)
Using the suggested 'pci=biosirq' doesn't help, because: 'PCI: Unknown option `biosirq''...
It seems that the IRQ for the SATA controllers isn't set up by coreboot, so it generates IRQ0, which is the timer tick. Could this be related with the 'noapic' parameter? If so, how to fix the APIC timer issue?
Ronald.
Hi Ronald,
On Mon, Feb 11, 2008 at 12:53:30AM +0100, Ronald Hoogenboom wrote:
It seems that the IRQ for the SATA controllers isn't set up by coreboot, so it generates IRQ0, which is the timer tick. Could this be related with the 'noapic' parameter? If so, how to fix the APIC timer issue?
Uhm - at this point I really want to know what hardware you have. Is this an SPI version of the m57sli? I've got several m57sli boards in production (both PLCC and SPI versions) that work just fine with coreboot.
Thanks, Ward.
Hi Ward,
On Sun, 2008-02-10 at 20:11 -0500, Ward Vandewege wrote:
Uhm - at this point I really want to know what hardware you have. Is this an SPI version of the m57sli? I've got several m57sli boards in production (both PLCC and SPI versions) that work just fine with coreboot.
I've got a m57sli rev.2.0 board (SPI) with Athlon64-X2 5600+ (winchester), 2GB RAM (2x1G), SATA2 hard disk and nvidia GeForce 8600 GT 256MB. I'm using coreboot v2 svn rev. 3100.
I've fitted a second SPI flash SST25VF016B (2MB) on the second land pattern and installed a spdt switch on the CE pins.
I've modified the rom_stream to do pio mode read, because the lower 1.5MB of the flash is not readable memory mapped (thanks to the it8716f superio). (see the previous email thread about the SST25VF016B on m57sli) I'll post a patch when all is working here.
I've created an elf image from the normal kernel I also use when booting with the proprietary bios and compressed it with lzma to make it fit in the flash.
The elfboot loads the image just fine, as far as I can see. Kernel starts, but there are problems with VGA (rom signature wrong) and SATA (irq routed wrong). I think that this last could be related with the 'noapic' kernel parameter, as the SATA irqs are 20, 23 and 21 (see mptable.c). It also seems that the ACPI is still not working properly, but that's for later.
Do you also use the 'noapic' parameter (like suggested in the tutorial)?
As a general rule, should the io, memory and irq mapping for the devices be the same as when booted proprietary? If not, should this be reason for concern and/or change?
I can send the complete messages on the serial port if you like too (loooooonnnnngggg!)
Thanks, Ward.
Thanks to you too, Ronald.
Hi Ronald,
On Mon, Feb 11, 2008 at 04:29:57PM +0100, Ronald Hoogenboom wrote:
On Sun, 2008-02-10 at 20:11 -0500, Ward Vandewege wrote:
Uhm - at this point I really want to know what hardware you have. Is this an SPI version of the m57sli? I've got several m57sli boards in production (both PLCC and SPI versions) that work just fine with coreboot.
I've got a m57sli rev.2.0 board (SPI) with Athlon64-X2 5600+ (winchester), 2GB RAM (2x1G), SATA2 hard disk and nvidia GeForce 8600 GT 256MB. I'm using coreboot v2 svn rev. 3100.
I've fitted a second SPI flash SST25VF016B (2MB) on the second land pattern and installed a spdt switch on the CE pins.
Nice! I've added a soic socket on the second pad of one of our SPI boards. I also bought SST25VF016B chips because they were the only 2+MB ones I could source here.
I've modified the rom_stream to do pio mode read, because the lower 1.5MB of the flash is not readable memory mapped (thanks to the it8716f superio). (see the previous email thread about the SST25VF016B on m57sli) I'll post a patch when all is working here.
Looking forward to that patch :)
I've created an elf image from the normal kernel I also use when booting with the proprietary bios and compressed it with lzma to make it fit in the flash.
The elfboot loads the image just fine, as far as I can see. Kernel starts, but there are problems with VGA (rom signature wrong) and SATA (irq routed wrong). I think that this last could be related with the 'noapic' kernel parameter, as the SATA irqs are 20, 23 and 21 (see mptable.c). It also seems that the ACPI is still not working properly, but that's for later.
Do you also use the 'noapic' parameter (like suggested in the tutorial)?
Well, here's the thing. On the PLCC version of the board as of kernel 2.6.22.1 (stock kernel.org release) I need noapic *only* with the proprietary bios, not with coreboot.
As a general rule, should the io, memory and irq mapping for the devices be the same as when booted proprietary? If not, should this be reason for concern and/or change?
Good question. I'm sure others can answer it - I'm not sure. Seems like irq mapping would have to be correct, but I'm far from an export on this stuff.
Thanks, Ward.
On Mon, 2008-02-11 at 15:29 -0500, Ward Vandewege wrote:
Do you also use the 'noapic' parameter (like suggested in the tutorial)?
Well, here's the thing. On the PLCC version of the board as of kernel 2.6.22.1 (stock kernel.org release) I need noapic *only* with the proprietary bios, not with coreboot.
Strange. I use kernel 2.6.23.12 (from fedora fc7) and I don't need noapic with proprietary bios, but after coreboot, it complains that '8254 timer not connected to IO-APIC' and then goes into panic, saying that 'IO-APIC + timer doesn't work' with suggestion to use the 'noapic' parameter. With the 'noapic' it doesn't go into panic there, but other troubles occur (with the SATA irq).
What VGA do you use? (if any...) Did you experience any trouble there? What about the 'CONFIG_VGA_ROM_RUN' option? No chance for me as long as this rom signature is wrong... or?
As a general rule, should the io, memory and irq mapping for the devices be the same as when booted proprietary? If not, should this be reason for concern and/or change?
Good question. I'm sure others can answer it - I'm not sure. Seems like irq mapping would have to be correct, but I'm far from an export on this stuff.
Who can tell me? Anyone? What files to modify to get the mappings the same -- without breaking everything else?
Thanks, Ronald.
On Sat, 2008-02-09 at 23:33 +0100, Ronald Hoogenboom wrote:
-- During coreboot 'Initializing devices', the following is printed:
rom address for PCI: 07:00.0 = f7000000 Incorrect Expansion ROM Header Signature ffff
I've now discovered that this was due to the fact that I was always doing a SOFT reboot into coreboot. If I do a poweroff first, then this doesn't happen. The clue was in the lspci:
lspci: [virtual] Expansion ROM at fb000000 [disabled] [size=128K] coreb: [0x00f7000000 - 0x00f701ffff] size 0x00020000 gran 0x11 romem
Something in the previous 'session' had turned the memory area 'off' and coreboot obviously doesn't re-enable it. A cold boot will render the area as 'on' and the signature isn't wrong anymore.
So now I get in the 'initializing devices'-stage:
rom address for PCI: 07:00.0 = f7000000 copying VGA ROM Image from 0xf7000000 to 0xc0000, 0xda00 bytes entering emulator halt_sys: file /home/ronald/coreboot/src/devices/emulator/x86emu/ops.c, line 4387
And there still isn't any VGA output. Other than that, the kernel boots fine. I can use the network and serial port logins do work, but no display, no text, no graphics (the ps2 keyboard is also fine).
Is this halt_sys supposed to be there?
Ronald.
On Mon, Feb 18, 2008 at 01:12:23AM +0100, Ronald Hoogenboom wrote:
So now I get in the 'initializing devices'-stage:
rom address for PCI: 07:00.0 = f7000000 copying VGA ROM Image from 0xf7000000 to 0xc0000, 0xda00 bytes entering emulator halt_sys: file /home/ronald/coreboot/src/devices/emulator/x86emu/ops.c, line 4387
Looks good.
And there still isn't any VGA output.
:(
Can you try a few different graphics cards? My GeForce 6200 cheapo card works well.
Is this halt_sys supposed to be there?
Yes. The emulator halts after returning from the call to the VGA ROM entry point. I sent a patch to add a friendlier message to explain this at runtime but it got no feedback.
Changing the halt_sys message itself is not trivial because the message is printed in a debugging function in the emulator generic for all opcodes. My patch simply added a new message.
http://marc.info/?l=linuxbios&m=120173549921329
Torsten suggested to also check that the halt is indeed after return from the VGA ROM and not within the ROM, which is a good idea, but I don't have an implementation.
//Peter
Hi Peter,
And there still isn't any VGA output.
:(
Can you try a few different graphics cards? My GeForce 6200 cheapo card works well.
I've been able to borrow a cheapo ATI RV515 [Radeon X1300] and that one indeed works. So what is the story with the Nvidia GeForce 8600GT? Why doesn't the bootrom on the card initialize it properly via the x86 emulator?
Is there /ANYBODY/ who has had some success with an nvidia 8600GT and coreboot? Or are there other VGA cards that have similar problems?
Something else I noticed is that the CPU fan speed isn't regulated with coreboot. The K8-temp goes over 90 C and the fan is still reving slow at 800 RPM (nice and quiet, but not so good for my athlons health).
Ronald.
On Mon, Feb 18, 2008 at 09:18:12PM +0100, Ronald Hoogenboom wrote:
Can you try a few different graphics cards? My GeForce 6200 cheapo card works well.
I've been able to borrow a cheapo ATI RV515 [Radeon X1300] and that one indeed works. So what is the story with the Nvidia GeForce 8600GT? Why doesn't the bootrom on the card initialize it properly via the x86 emulator?
Weird. I've got machines running with a few different cheapo Nvidia 7xxx class cards.
Is there /ANYBODY/ who has had some success with an nvidia 8600GT and coreboot? Or are there other VGA cards that have similar problems?
I have not come across any.
Something else I noticed is that the CPU fan speed isn't regulated with coreboot. The K8-temp goes over 90 C and the fan is still reving slow at 800 RPM (nice and quiet, but not so good for my athlons health).
I submitted some code a long time ago (r2620) to set the fans to automatic control on the it8716f superio. That was of course based on a PLCC version of the board. Check src/superio/ite/it8716f/superio.c.
Perhaps there's a bug there - or maybe something has changed on the SOIC version of the m57sli.
Thanks, Ward.
On Mon, 2008-02-18 at 15:29 -0500, Ward Vandewege wrote:
On Mon, Feb 18, 2008 at 09:18:12PM +0100, Ronald Hoogenboom wrote:
<...>
Something else I noticed is that the CPU fan speed isn't regulated with coreboot. The K8-temp goes over 90 C and the fan is still reving slow at 800 RPM (nice and quiet, but not so good for my athlons health).
I submitted some code a long time ago (r2620) to set the fans to automatic control on the it8716f superio. That was of course based on a PLCC version of the board. Check src/superio/ite/it8716f/superio.c.
Perhaps there's a bug there - or maybe something has changed on the SOIC version of the m57sli.
Now with the patched superiotool, I have been able to spot all the differences for the auto fan control. If I put the following in the superio.c (init_ec()) file after your code:
/* set the correct sensor types 1,2 thermistor; 3 diode */ pnp_write_index(base, 0x51, 0x1c); /* set the 'zero' voltage for diode type sensor */ pnp_write_index(base, 0x5c, 0x80); pnp_write_index(base, 0x56, 0xe5); pnp_write_index(base, 0x57, 0xe5); pnp_write_index(base, 0x59, 0xe5); pnp_write_index(base, 0x5c, 0x00); /* fan1 (controlled by temp3) control parameters */ /* fan off limit */ pnp_write_index(base, 0x60, 0xff); /* fan start limit */ pnp_write_index(base, 0x61, 0x14); /* ???? */ pnp_write_index(base, 0x62, 0x00); /* start PWM */ pnp_write_index(base, 0x63, 0x27); /* smooth and slope PWM */ pnp_write_index(base, 0x64, 0x90); /* direct-down and interval */ pnp_write_index(base, 0x65, 0x03); /* fan1 auto controlled by temp3 */ pnp_write_index(base, 0x15, 0x82); /* fan2 soft controlled, max speed */ pnp_write_index(base, 0x16, 0x7f); /* fan3 soft controlled, 75% speed */ pnp_write_index(base, 0x17, 0x60); /* all fans enable, fan1 ctl smart */ pnp_write_index(base, 0x13, 0x71);
Then the fan is properly controlled. BUT this stuff is far too mainboard specific (as opposed to superio specific) to be in this file. It should be in a file in the mainboard/gigabyte/m57sli directory (probably even V2.0 specific). But I wouldn't know how to link it in so it gets called in the ec_init routine. Do you have some suggestions? Maybe there is a way to put it in the Config.lb file?
Thanks, Ward.
Regards, Ronald.
On 22.02.2008 23:52, Ronald Hoogenboom wrote:
On Mon, 2008-02-18 at 15:29 -0500, Ward Vandewege wrote:
On Mon, Feb 18, 2008 at 09:18:12PM +0100, Ronald Hoogenboom wrote:
<...>
Something else I noticed is that the CPU fan speed isn't regulated with coreboot. The K8-temp goes over 90 C and the fan is still reving slow at 800 RPM (nice and quiet, but not so good for my athlons health).
I submitted some code a long time ago (r2620) to set the fans to automatic control on the it8716f superio. That was of course based on a PLCC version of the board. Check src/superio/ite/it8716f/superio.c.
Perhaps there's a bug there - or maybe something has changed on the SOIC version of the m57sli.
Now with the patched superiotool, I have been able to spot all the differences for the auto fan control. If I put the following in the superio.c (init_ec()) file after your code:
/* set the correct sensor types 1,2 thermistor; 3 diode */ pnp_write_index(base, 0x51, 0x1c); /* set the 'zero' voltage for diode type sensor */ pnp_write_index(base, 0x5c, 0x80); pnp_write_index(base, 0x56, 0xe5); pnp_write_index(base, 0x57, 0xe5); pnp_write_index(base, 0x59, 0xe5); pnp_write_index(base, 0x5c, 0x00); /* fan1 (controlled by temp3) control parameters */ /* fan off limit */ pnp_write_index(base, 0x60, 0xff); /* fan start limit */ pnp_write_index(base, 0x61, 0x14); /* ???? */ pnp_write_index(base, 0x62, 0x00); /* start PWM */ pnp_write_index(base, 0x63, 0x27); /* smooth and slope PWM */ pnp_write_index(base, 0x64, 0x90); /* direct-down and interval */ pnp_write_index(base, 0x65, 0x03); /* fan1 auto controlled by temp3 */ pnp_write_index(base, 0x15, 0x82); /* fan2 soft controlled, max speed */ pnp_write_index(base, 0x16, 0x7f); /* fan3 soft controlled, 75% speed */ pnp_write_index(base, 0x17, 0x60); /* all fans enable, fan1 ctl smart */ pnp_write_index(base, 0x13, 0x71);Then the fan is properly controlled. BUT this stuff is far too mainboard specific (as opposed to superio specific) to be in this file. It should be in a file in the mainboard/gigabyte/m57sli directory (probably even V2.0 specific). But I wouldn't know how to link it in so it gets called in the ec_init routine. Do you have some suggestions? Maybe there is a way to put it in the Config.lb file?
Ronald,
you did great work tracking this down. Congratulations! We have to make sure we can handle such settings in v3 easily.
There is another possible problem with fan settings: Do they belong to (in the sense of copyright) the mainboard vendor or the BIOS vendor? I don't want to get nasty letters from anyone.
Regards, Carl-Daniel
On Sat, Feb 23, 2008 at 12:10:48AM +0100, Carl-Daniel Hailfinger wrote:
/* set the correct sensor types 1,2 thermistor; 3 diode */ pnp_write_index(base, 0x51, 0x1c); /* set the 'zero' voltage for diode type sensor */ pnp_write_index(base, 0x5c, 0x80); pnp_write_index(base, 0x56, 0xe5); pnp_write_index(base, 0x57, 0xe5); pnp_write_index(base, 0x59, 0xe5); pnp_write_index(base, 0x5c, 0x00); /* fan1 (controlled by temp3) control parameters */ /* fan off limit */ pnp_write_index(base, 0x60, 0xff); /* fan start limit */ pnp_write_index(base, 0x61, 0x14); /* ???? */ pnp_write_index(base, 0x62, 0x00); /* start PWM */ pnp_write_index(base, 0x63, 0x27); /* smooth and slope PWM */ pnp_write_index(base, 0x64, 0x90); /* direct-down and interval */ pnp_write_index(base, 0x65, 0x03); /* fan1 auto controlled by temp3 */ pnp_write_index(base, 0x15, 0x82); /* fan2 soft controlled, max speed */ pnp_write_index(base, 0x16, 0x7f); /* fan3 soft controlled, 75% speed */ pnp_write_index(base, 0x17, 0x60); /* all fans enable, fan1 ctl smart */ pnp_write_index(base, 0x13, 0x71);Then the fan is properly controlled. BUT this stuff is far too mainboard specific (as opposed to superio specific) to be in this file. It should be in a file in the mainboard/gigabyte/m57sli directory (probably even V2.0 specific). But I wouldn't know how to link it in so it gets called in the ec_init routine. Do you have some suggestions? Maybe there is a way to put it in the Config.lb file?
Ronald,
you did great work tracking this down. Congratulations! We have to make sure we can handle such settings in v3 easily.
There is another possible problem with fan settings: Do they belong to (in the sense of copyright) the mainboard vendor or the BIOS vendor? I don't want to get nasty letters from anyone.
I think that's going too far. This stuff comes straight from the superio datasheet (check out the comments). There's no way anyone can claim copyright on a bunch of configuration settings imo.
Thanks, Ward.
On Sat, 2008-02-23 at 00:10 +0100, Carl-Daniel Hailfinger wrote: <...>
There is another possible problem with fan settings: Do they belong to (in the sense of copyright) the mainboard vendor or the BIOS vendor? I don't want to get nasty letters from anyone.
I can say one thing: IANAL, but, technically: It's all to do with how the mainboard is laid-out (electrical connections) that dictate the needed register settings, so that would be the mainboard vendor who did that.
Regards, Carl-Daniel
Ronald.
On Fri, 2008-02-22 at 23:52 +0100, Ronald Hoogenboom wrote:
Then the fan is properly controlled. BUT this stuff is far too mainboard specific (as opposed to superio specific) to be in this file. It should be in a file in the mainboard/gigabyte/m57sli directory (probably even V2.0 specific). But I wouldn't know how to link it in so it gets called in the ec_init routine. Do you have some suggestions? Maybe there is a way to put it in the Config.lb file?
I've found a way: provide the ec_init routine in a source file in the mainboard/gigabyte/m57sli directory. I've also added a Config variable 'HAVE_FANCTL' to notify to superio.c to get the ec_init externally.
This patch adds automatic fan control for the CPU fan on the m57sli board.
Signed-off-by: Ronald Hoogenboom hoogenboom30@zonnet.nl
On Sunday 24 February 2008, Ronald Hoogenboom wrote:
I've found a way: provide the ec_init routine in a source file in the mainboard/gigabyte/m57sli directory.
Neat.
I've also added a Config variable 'HAVE_FANCTL' to notify to superio.c to get the ec_init externally.
Is there anyone who would want to run the board without fan control, now that it's here? If not, let's not make that optional.
Torsten
On Mon, Feb 25, 2008 at 02:21:00AM +0100, Torsten Duwe wrote:
On Sunday 24 February 2008, Ronald Hoogenboom wrote:
I've found a way: provide the ec_init routine in a source file in the mainboard/gigabyte/m57sli directory.
Neat.
Indeed!
I've also added a Config variable 'HAVE_FANCTL' to notify to superio.c to get the ec_init externally.
Is there anyone who would want to run the board without fan control, now that it's here? If not, let's not make that optional.
It should not be optional if it sets the board to auto-manage the fans (hardware control), which is what I understand it does. If things are properly configured, one can still flip the bit that turns the fans back to manual/software control, all the way from userland.
So I think this is fine.
Ronald, I plan to test this tomorrow on the plcc and spi versions of the m57sli, and will ack and commit if it works fine for me (and unless someone else opposes!).
Thanks, Ward.
Hi Ronald,
On Sun, Feb 24, 2008 at 11:18:16PM +0100, Ronald Hoogenboom wrote:
On Fri, 2008-02-22 at 23:52 +0100, Ronald Hoogenboom wrote:
Then the fan is properly controlled. BUT this stuff is far too mainboard specific (as opposed to superio specific) to be in this file. It should be in a file in the mainboard/gigabyte/m57sli directory (probably even V2.0 specific). But I wouldn't know how to link it in so it gets called in the ec_init routine. Do you have some suggestions? Maybe there is a way to put it in the Config.lb file?
I've found a way: provide the ec_init routine in a source file in the mainboard/gigabyte/m57sli directory. I've also added a Config variable 'HAVE_FANCTL' to notify to superio.c to get the ec_init externally.
This patch adds automatic fan control for the CPU fan on the m57sli board.
Signed-off-by: Ronald Hoogenboom hoogenboom30@zonnet.nl
Great work! I've tested it on the PLCC and SOIC/SPI version of the m57sli, and it works.
Acked-by: Ward Vandewege ward@gnu.org
Committed in r3116.
Thanks, Ward.
On Mon, 2008-02-25 at 14:37 -0500, Ward Vandewege wrote:
Great work! I've tested it on the PLCC and SOIC/SPI version of the m57sli, and it works.
Why did you comment it out in r3118? Did you have some trouble after all?
Ronald.
PS. I also saw that the static functions (pnp_read/write_index) just before the init_ec aren't used by anything else, so they can also be included in the #if .. #else.
On Thu, Feb 28, 2008 at 12:13:13AM +0100, Ronald Hoogenboom wrote:
On Mon, 2008-02-25 at 14:37 -0500, Ward Vandewege wrote:
Great work! I've tested it on the PLCC and SOIC/SPI version of the m57sli, and it works.
Why did you comment it out in r3118? Did you have some trouble after all?
It switches the cpu fan off on v1 of the board (PLCC) which is not ideal :/ I'm in the process of debugging that, which I hope to to finish on Friday when I'm back at the office.
It did work as expected on v2 (SOIC/SPI) of the board.
See the commit message.
Thanks, Ward.
On 18.02.2008 21:18, Ronald Hoogenboom wrote:
And there still isn't any VGA output.
:(
Can you try a few different graphics cards? My GeForce 6200 cheapo card works well.
I've been able to borrow a cheapo ATI RV515 [Radeon X1300] and that one indeed works. So what is the story with the Nvidia GeForce 8600GT? Why doesn't the bootrom on the card initialize it properly via the x86 emulator?
Is there /ANYBODY/ who has had some success with an nvidia 8600GT and coreboot? Or are there other VGA cards that have similar problems?
Have you tried vm86 and x86emu? Sometimes only vm86 works due to quirks not addressed by the emulator.
Something else I noticed is that the CPU fan speed isn't regulated with coreboot. The K8-temp goes over 90 C and the fan is still reving slow at 800 RPM (nice and quiet, but not so good for my athlons health).
That would be a really big bad bug. Do you know which chip controls the fan on your board?
Regards, Carl-Daniel
On Mon, 2008-02-18 at 21:43 +0100, Carl-Daniel Hailfinger wrote:
Have you tried vm86 and x86emu? Sometimes only vm86 works due to quirks not addressed by the emulator.
Can you tell me how to select the vm86 instead of x86emu? Is that v3 only? (I'm using v2!)
That would be a really big bad bug. Do you know which chip controls the fan on your board?
That would be the superio IT8716f.
I also noticed that the k8 powernow doesn't work: 'powernow-k8: MP systems not supported by PSB BIOS structure' the kernel says. On top of that, the vid voltage is set to 1.35V with coreboot (without powernow) and to 1.10V (min. speed) - 1.30V (max. speed) booted with proprietary bios (with powernow), which heats the processor even faster.
Regards, Carl-Daniel
Regards, Ronald.
On Mon, Feb 18, 2008 at 11:01:23PM +0100, Ronald Hoogenboom wrote:
I also noticed that the k8 powernow doesn't work: 'powernow-k8: MP systems not supported by PSB BIOS structure' the kernel says.
Yeah - I always thought that was related to the lack of ACPI support.
On top of that, the vid voltage is set to 1.35V with coreboot (without powernow) and to 1.10V (min. speed) - 1.30V (max. speed) booted with proprietary bios (with powernow), which heats the processor even faster.
How are you reading out those values? The lm-sensor code returns this stuff but a lot of it seems bogus - both under the proprietary bios and coreboot, and sometimes in different ways :)
Thanks, Ward.
Hi Ward,
On Mon, 2008-02-18 at 17:07 -0500, Ward Vandewege wrote:
On Mon, Feb 18, 2008 at 11:01:23PM +0100, Ronald Hoogenboom wrote:
I also noticed that the k8 powernow doesn't work: 'powernow-k8: MP systems not supported by PSB BIOS structure' the kernel says.
Yeah - I always thought that was related to the lack of ACPI support.
How to tackle this issue? There are some boards that do have ACPI support in coreboot, why not m57sli-s4?
On top of that, the vid voltage is set to 1.35V with coreboot (without powernow) and to 1.10V (min. speed) - 1.30V (max. speed) booted with proprietary bios (with powernow), which heats the processor even faster.
How are you reading out those values? The lm-sensor code returns this stuff but a lot of it seems bogus - both under the proprietary bios and coreboot, and sometimes in different ways :)
I indeed use lm-sensors, and I would disagree that the values are bogus, they just need to be taken with a grain of salt (or common sense with a datasheet of the chip in question (it7816f)). Some values read depend on the configuration of the EC part. Others (specifically the voltages) depend on the external resistors used on the mainboard, these will not change by using coreboot or any other bios. It would be handy if the superiotool could dump this EC config too, so I can compare apples with apples. But the vid just depends on 5 wires connected to the cpu and I can see a direct linear relation between the vid decoded voltage value and the measured core voltage, so the CPU indeed gets always at least 50 mV more than when powernow is active. And the 800RPM might not be the exact RPM with the same division factor, but if it doesn't change, it still means that the so-called 'SmartGuardian' regulation doesn't work. The core temperature is read via the k8-temp module (temperature sensor inside the CPU), which is not dependent on any config of the it8716f.
I think I'll go and extend superiotool... But not tonight.
Thanks, Ward.
Regards, Ronald.
On Tue, Feb 19, 2008 at 12:18:00AM +0100, Ronald Hoogenboom wrote:
I also noticed that the k8 powernow doesn't work: 'powernow-k8: MP systems not supported by PSB BIOS structure' the kernel says.
Yeah - I always thought that was related to the lack of ACPI support.
How to tackle this issue? There are some boards that do have ACPI support in coreboot, why not m57sli-s4?
Personally I would really prefer if we didn't need ACPI. Marc/Jordan - do you know if there's an easy way to short-circuit the PSB BIOS structure in the kernel powernow driver?
//Peter
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Personally I would really prefer if we didn't need ACPI. Marc/Jordan
- do you know if there's an easy way to short-circuit the PSB BIOS
structure in the kernel powernow driver?
Hmm the PSB works only for singlecores :/
Rudolf
On 19/02/08 22:00 +0100, Rudolf Marek wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Personally I would really prefer if we didn't need ACPI. Marc/Jordan
- do you know if there's an easy way to short-circuit the PSB BIOS
structure in the kernel powernow driver?
Hmm the PSB works only for singlecores :/
Indeed. This is one of those cases where we just can't avoid ACPI. Sorry.
Jordan
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHu0OG3J9wPJqZRNURAva4AKC/iwp7TSCrcXXISyZIHPrfirO5vgCfc9n4 2xmdUsEw//CgrzHyxQGCVic= =UuBg -----END PGP SIGNATURE-----
-- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On Mon, 2008-02-18 at 21:43 +0100, Carl-Daniel Hailfinger wrote:
Is there /ANYBODY/ who has had some success with an nvidia 8600GT
and
coreboot? Or are there other VGA cards that have similar problems?
Have you tried vm86 and x86emu? Sometimes only vm86 works due to quirks not addressed by the emulator.
I've seen that vm86 is only available in V3. Is there a 'backport' for V2 for this vm86 method for executing vga-bios-rom?
Ronald.
On Sunday 24 February 2008, Ronald Hoogenboom wrote:
On Mon, 2008-02-18 at 21:43 +0100, Carl-Daniel Hailfinger wrote:
Is there /ANYBODY/ who has had some success with an nvidia 8600GT
and
coreboot? Or are there other VGA cards that have similar problems?
Have you tried vm86 and x86emu? Sometimes only vm86 works due to quirks not addressed by the emulator.
I've seen that vm86 is only available in V3. Is there a 'backport' for V2 for this vm86 method for executing vga-bios-rom?
No. V2 should always run the emulator.
Torsten
Torsten Duwe wrote:
I've seen that vm86 is only available in V3. Is there a 'backport' for V2 for this vm86 method for executing vga-bios-rom?
No. V2 should always run the emulator.
That is too bad... Is it really not possible to get vm86 into V2? Or gigabyte m57sli in V3? Which would be the least effort? Or is V3 not nearly usable? It would really be a pitty if I were to have to use the proprietary bios in the end, just because of an unfortunate choice of VGA card.
Ronald.
On 25.02.2008 21:00, Ronald Hoogenboom wrote:
Torsten Duwe wrote:
I've seen that vm86 is only available in V3. Is there a 'backport' for V2 for this vm86 method for executing vga-bios-rom?
No. V2 should always run the emulator.
That is too bad... Is it really not possible to get vm86 into V2? Or gigabyte m57sli in V3? Which would be the least effort? Or is V3 not nearly usable? It would really be a pitty if I were to have to use the proprietary bios in the end, just because of an unfortunate choice of VGA card.
It would be very interesting to try the x.org version of x86emu (i.e. have x.org boot your card as if it was a secondary card). It could even work fine. Least effort.
Stefan's mail from today in this thread pointed to some code which uses vm86 in v2. Medium effort needed.
Adding support for the M57SLI to v3 is possible, but it will take a lot of developer time because neither the chipset nor the processor are supported in v3.
Regards, Carl-Daniel
On Mon, Feb 25, 2008 at 12:00 PM, Ronald Hoogenboom hoogenboom30@zonnet.nl wrote:
Is it really not possible to get vm86 into V2?
before we had the emulator we ran the VGA BIOS directly. It should stlil be possible to do that in v2.
ron
Ronald Hoogenboom wrote:
On Mon, 2008-02-18 at 21:43 +0100, Carl-Daniel Hailfinger wrote:
Is there /ANYBODY/ who has had some success with an nvidia 8600GT
and
coreboot? Or are there other VGA cards that have similar problems?
Have you tried vm86 and x86emu? Sometimes only vm86 works due to quirks not addressed by the emulator.
I've seen that vm86 is only available in V3. Is there a 'backport' for V2 for this vm86 method for executing vga-bios-rom?
The VIA Epia-M does something like that, in the board specific directory. If more people start using it, it should be moved to a more generic place.
-
Carl-Daniel Hailfinger -
Jordan Crouse -
Peter Stuge -
ron minnich -
Ronald Hoogenboom -
Ronald Hoogenboom -
Rudolf Marek -
Stefan Reinauer -
Torsten Duwe -
Ward Vandewege