[LinuxBIOS] badly initialized (?) pci bridge on the M57SLI (with irq table and mptable)
echelon at free.fr
echelon at free.fr
Fri Oct 5 15:00:15 CEST 2007
Sorry for answering so late, but Im back after 3 sleepless nights so Im under
continuous coffee perfusion simply to stay awake..
Firstly to answer to Yinghai, I didn't use dumpio (I don't know what is
this..). I'm mostly a hardware guy (I come from the "embedded world") so my
first reaction was to put an oscilloscope probe on the PCI bus..
So what have I found out?
- 1) with the initial LinuxBIOS code, it looks like some control signals of
the PCI bus are not correctly driven when on tries to do configuration requests
under Linux. More specifically, when a 32b read is done on the CONFIG_DATA port
(0cfc) which should trigger a pci configuration register read, one can see that
the signal C/BE# (pin 26 - side B on a PCI slot) doesn't rise at a logical
level of "1" as it should do. Indeed, the PCI bus spec says that the signals
C/BE carry the PCI command code at the beginning of a PCI transaction (p.23 -
chapter 3 "Bus Operation"). This code should be "1010" for a configuration read,
so C/BE should be '1'. In fact it doesn't .. (I have some pics with my
oscilloscope measurement, if someone is interested by them plz let me know..)
- 2) after analising a little bit the code of the mcp55 southbridge in the LB
source tree (especially the mcp55_early_setup_car.c file), I realised the the
mcp55 southbridge has some kind of "IO multiplexer" unit (like some modern
the embedded world) which enables the configuration of the mcp55 pins either as
GPIOs, either as "nominal" functions (PCI control signals for example). So, I
asked my self if the GPIO configuration was not fitted for the m57sli board..
- 3) Btw I figured out that registers of the "IO control unit" of mcp55 can be
mapped into the IO space by writting into the SYSCTRL_REG of the 00:01.1 pci
device integrated into the SB. Indeed by using this value as a base (under
Linux, this register holds the value 0x1400) one can access the GPIO registers
of MCP55 (beginning @ the 0xc0 offset? maybe..) These are 8 bit registers
- 4) After booting with the proprietary Award bios, I dumped this table under
Linux (with a simple custom utility that I wrote for this purpose..). I dumped
256 bytes from 0x1400.
- 5) I switched (manually.. ;o)) to LinuxBIOS and repeated the operation. I
compared the 2 dump files. I found out that some values do indeed differ, and
one of them corresponds to "GPIO39" as it appears in the "cache_as_ram_auto.c"
file. I changed this value accordingly end rebuild LinuxBIOS.
- 6) I reflashed and .. voila!..
(Btw I found that "GPIO40" differs as well and should have the value 0x68, but I
didn't dare to do this change yet.. :o))
Now, after taking a break, I will help with the implementation of the flashrom
support on the m57sli board.. But right now I need to sleep!
Quoting Ward Vandewege <ward at gnu.org>:
> Hi Florentin,
> On Thu, Oct 04, 2007 at 05:32:21AM +0200, echelon at free.fr wrote:
> > I propose:
> > $(LB)/src/mainboard/gigabyte/m57sli/cache_as_ram_auto.c
> > 138c138
> > < RES_PORT_IO_8, SYSCTRL_IO_BASE + 0xc0+38, 0x00, 0x44,/* GPIO39 PCI_GNT3
> */ \
> > ---
> > > RES_PORT_IO_8, SYSCTRL_IO_BASE + 0xc0+38, 0x00, 0x68,/* GPIO39 PCI_GNT3
> */ \
> > My vga pci card and a pci network card are recognised with this under
> > I don't understand why this works, but it works..
> > (I will explain tomorrow how I found this value)
> > Please can someone validate my change?a
> I've tried it on a v1.1 m57sli (the plcc version).
> Great work! This fixes one of the PCI slots (01:07.0), but not the second
> slot (01:08.0, closest to the edge of the board). Can you explain how you got
> to this value, so that we can activate the second PCI slot as well?
> Ward Vandewege <ward at fsf.org>
> Free Software Foundation - Senior System Administrator
More information about the coreboot