[coreboot] Gigabyte M57SLI-S4 PCI-Initialisation Problems
Harald Gutmann
harald.gutmann at gmx.net
Sun Feb 8 18:18:55 CET 2009
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..)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: data.tar.gz
Type: application/x-compressed-tar
Size: 881 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090208/098417a9/attachment.tar.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090208/098417a9/attachment.sig>
More information about the coreboot
mailing list