Hi gentlemens,
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[3]# (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[3] 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 processors in 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 apparently.. - 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!
Best regards, Florentin
Quoting Ward Vandewege ward@gnu.org:
Hi Florentin,
On Thu, Oct 04, 2007 at 05:32:21AM +0200, echelon@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
LinuxBIOS!
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?
Thanks! Ward.
-- Ward Vandewege ward@fsf.org Free Software Foundation - Senior System Administrator