[coreboot] Gigabyte M57SLI-S4 PCI-Initialisation Problems

[Harald Gutmann]

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>