Gigabyte M57SLI-S4 PCI-Initialisation Problems

[Harald Gutmann]

----------  Forwarded Message  ----------

Subject: Gigabyte M57SLI-S4 PCI-Initialisation Problems
Date: Saturday 07 February 2009
From: Harald Gutmann 
To: [e-mail]

Hello Florentin,

some times ago you figured out how to get some PCI ports on the Gigabyte M57SLI 
board initialized. One Port worked with your patch as it should and gets 
interrupts, but the other one doesn't. Also there are until now some problems 
existing with the PCI-E ports.

As time passed by there is until now no solution for the second PCI port and 
for the PCI-E interrupt problems.
After finishing my school, and finding some good job i've more time to work with 
things i'm interested, such as coreboot.

For the following i refer on your post from October 2007 on the LinuxBios 
Mailinglist: http://www.coreboot.org/pipermail/linuxbios/2007-
October/025442.html

My questions to that posting:
*1) Is it necessary/useful to measure somethings on the PCI-bus with an 
oscilloscope?
*4) Do you have the source for that simple custom utility you wrote that time 
to dump the SYSCTRL_REG which you mention in *3)?

I and some other coreboot users are interested in trying to fix that issues 
with coreboot on this mainboard, and i hope you can help us a bit.

Tanks in advance,
kind regards,
Harald Gutmann

-------------------------------------------------------

[Harald Gutmann]

I sent this message to Florentin (echelon at free.fr), and wanted to CC it to 
the coreboot-ml but i did a typo in the address of the ml, so i sent it a 
second time as forwarded message.

[Florentin Demetrescu]

Hi Harold,

Of course, I would like to contribute again to the coreboot project, but
unfortunately last year I had many personal problems to deal with and not much
time for coreboot.. :/
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..)

I would try to re-activate my coreboot test platforms this week.. If you have
further questions, Im will try to help you..

Best regards,
 Florentin Demetrescu

Quoting Harald Gutmann :
> ----------  Forwarded Message  ----------
>
> Subject: Gigabyte M57SLI-S4 PCI-Initialisation Problems
> Date: Saturday 07 February 2009
> From: Harald Gutmann 
> To: [e-mail]
>
> Hello Florentin,
>
> some times ago you figured out how to get some PCI ports on the Gigabyte
> M57SLI
> board initialized. One Port worked with your patch as it should and gets
> interrupts, but the other one doesn't. Also there are until now some problems
> existing with the PCI-E ports.
>
> As time passed by there is until now no solution for the second PCI port and
> for the PCI-E interrupt problems.
> After finishing my school, and finding some good job i've more time to work
> with
> things i'm interested, such as coreboot.
>
> For the following i refer on your post from October 2007 on the LinuxBios
> Mailinglist: http://www.coreboot.org/pipermail/linuxbios/2007-
> October/025442.html
>
> My questions to that posting:
> *1) Is it necessary/useful to measure somethings on the PCI-bus with an
> oscilloscope?
> *4) Do you have the source for that simple custom utility you wrote that time
> to dump the SYSCTRL_REG which you mention in *3)?
>
> I and some other coreboot users are interested in trying to fix that issues
> with coreboot on this mainboard, and i hope you can help us a bit.
>
> Tanks in advance,
> kind regards,
> Harald Gutmann

[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..)

[Peter Stuge]

Hi,

Harald Gutmann wrote:
> 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.

I didn't properly read the background that the I/O base is set by
SYSCTRL_REG 0x64 so I gave Harald some bad advice, but he's reading
out the relevant values as I type. I hope he'll send out an update
in a bit.

//Peter

[Harald Gutmann]

On Sunday 08 February 2009 18:31:27 Peter Stuge wrote:
> Hi,
>
> Harald Gutmann wrote:
> > 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.
>
> I didn't properly read the background that the I/O base is set by
> SYSCTRL_REG 0x64 so I gave Harald some bad advice, but he's reading
> out the relevant values as I type. I hope he'll send out an update
> in a bit.

Here are the new results which should be the right once.
original.txt = proprietary bios
coreboot.txt = coreboot bios
> //Peter

Regards,
Harald

[Peter Stuge]

Harald Gutmann wrote:
> Here are the new results which should be the right once.
> original.txt = proprietary bios
> coreboot.txt = coreboot bios

And here's a diff.

//Peter

[Carl-Daniel Hailfinger]

On 08.02.2009 18:54, Peter Stuge wrote:
> Harald Gutmann wrote:
> > Here are the new results which should be the right once.
> > original.txt = proprietary bios
> > coreboot.txt = coreboot bios
>
> And here's a diff.

That sounds like you could use the mcp55_io.c program Yinghai posted
roughly two years ago to debug such problems. I'll try to look it up.

Regards,
Carl-Daniel