Hi Florentin, thanks for your answer, that and Peter Stuge helped me a lot to get further informations on that problem.
First, to describe what i did: Build coreboot from buildrom devel with a filo payload, flashed it and bootet coreboot on the gigabyte m57sli v2. After that i wrote that little piece of software you described in that mail in point -2). (source below.)
Then i tried to figure out what exactly to do, as you told in point -1). As i discussed this point with Peter in #coreboot it we/i got to the conclusion that the value i need to start reading in coreboot was 3c00. In the proprietary bios it is the value e000.
I hope you can verify that values according to the lspci outputs i append on the end of the mail.
The result of my testing/work/funny Sunday afternoon is the appended file data.tar.gz which contains 5x reading the 256bytes with coreboot and 5x the same from the proprietary bios. Until now i didn't start to compare them.
What makes me a little worried is that the output on the proprietary bios has much more zero values in it.
Here the outputs/sources which i mentioned above:
#include <sys/io.h> #include <stdio.h>
int main() { iopl(3); //grant access to all io ports - root privileges needed /* ioperm can only give access from 0x000-0x3ff ioperm(start_port, range, 1); //set permissions to have access ioperm(start_port, range, 0); //set permissions to remove access */
unsigned char input; int count=0;
FILE *output; output = fopen("./io_gpio-data", "w");
for(count=0; count <=255; count++){ input = inb(0xe000+count); //starting value for the proprietary bios fputc(input, output); }
fclose(output); iopl(0); //remove access to io ports }
//on the proprietary bios: benchvice:/home/hargut/coreboot-stuff# lspci -vvv -s 00:01.1 00:01.1 SMBus: nVidia Corporation MCP55 SMBus (rev a2) Subsystem: Giga-byte Technology Device 0c11 Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Interrupt: pin A routed to IRQ 11 Region 0: I/O ports at e000 [size=64] Region 4: I/O ports at 1c00 [size=64] Region 5: I/O ports at 1c80 [size=64] Capabilities: [44] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: nForce2_smbus Kernel modules: i2c-nforce2
//on running coreboot lspci -v -xxx -s 00:01.1 00:01.1 SMBus: nVidia Corporation MCP55 SMBus (rev a2) Subsystem: Advanced Micro Devices [AMD] Device 2b80 Flags: 66MHz, fast devsel, IRQ 10 I/O ports at 3c00 [size=64] I/O ports at 3c40 [size=64] I/O ports at 3c80 [size=64] Capabilities: [44] Power Management version 2 Kernel driver in use: nForce2_smbus Kernel modules: i2c-nforce2
On Sunday 08 February 2009 12:54:18 you wrote:
Hi Harold,
For your questions: *1) Probing the PCI bus was usefull to figure out that the "GPIO multiplexer" of the SB was misconfigured, and the PCI configuration requests weren't understood by a card plugged in the first PCI slot. I didn't have time to do the same test for the second PCI slot. What is a little disturbing is that after patching the coreboot code with GPIO configuration values extracted from the proprietary BIOS configuration, the second PCI slot is still unfunctional. So, indeed I think that it is necessary to probe the second PCI slot.. (If you don't have access to a good oscilloscope, I can do this test maybe later next week, let me know..) *4) Unfortunately I lost this little quickie, but it is not very complicated to write from scratch.. What you need to do: -1) after booting under Linux/legacy_BIOS, read the SYSCTRL_REG (0x64?) of the 00:01.1 PCI device (the LPC bridge?) to verify that it holds the value 0x1400. -2) write a little program which dumps 256 bytes from the IO address 0x1400 (of course you have to adjust the iopl of your program in order to have access to the IO space..)