[LinuxBIOS] badly initialized (?) pci bridge on the M57SLI (with irq table and mptable)

echelon at free.fr echelon at free.fr
Thu Oct 11 13:47:12 CEST 2007


Hi Ward,

 Yes I confirm this behaviour, I observed it too (but omitted to mention it in
my previous posts..).
 Unfortunately I have no rational explanation for this. Btw it is extremely
difficult and time (and nerve!) consuming to work without at least a token
amount of technical documentation!..
 Please, please, if someone from NVidia is still reading this mailinglist, could
he/she answer for this very specific topic (the IO configuration for the PCI
signals of the MCP55 chip)? We are not asking for nothing else!..
 Thank you in advance!
  Florentin Demetrescu

Quoting Ward Vandewege <ward at gnu.org>:

> Hi Florentin,
>
> On Mon, Oct 08, 2007 at 03:27:20AM +0200, echelon at free.fr wrote:
> >  I don't think that my little "quickie" deserves so much consideration, but
> I
> > will post it, hopping that it could be usefull for someone..
>
> Thank you!
>
> >  Btw you have to do first a "setpci -s 00:01.1 64.l" to retrieve the base
> >  address of the SYSCTRL register table. Use this value as a parameter for
> >  my program to dump the io configuration (the gpio registers seem to start
> >  @ offset 0xc0 into this table..)
>
> Yes, I've been able to verify all this. Your fix enables 1 of the 2 pci slots
> (the one closest to the edge of the board is still broken).
>
> There is something I don't understand, however.
>
> When using io_dump under the proprietary BIOS, I see:
>
>  000014e5 : 00000068
>  000014e6 : 00000068
>  000014e7 : 00000068
>  000014e8 : 00000048
>
> When booted under LinuxBIOS (without your patch), I see this (the io
> configuration starts at 0x2401 instead of 0x1401 under LB):
>
>  000024e5 : 00000004
>  000024e6 : 00000004
>  000024e7 : 00000004
>  000024e8 : 00000004
>
> The intriguing thing is that the LB code writes the following values to those
> registers:
>
>         RES_PORT_IO_8, SYSCTRL_IO_BASE + 0xc0+37, 0x00, 0x44,/* GPIO38
> PCI_REQ3 */ \
>         RES_PORT_IO_8, SYSCTRL_IO_BASE + 0xc0+38, 0x00, 0x44,/* GPIO39
> PCI_GNT3 */ \
>         RES_PORT_IO_8, SYSCTRL_IO_BASE + 0xc0+39, 0x00, 0x44,/* GPIO40
> PCI_GNT2 */ \
>         RES_PORT_IO_8, SYSCTRL_IO_BASE + 0xc0+40, 0x00, 0x44,/* GPIO41
> PCI_REQ2 */ \
>
> So why are those registers not all set to 0x44 as I would expect?
>
> After applying your patch the code sets the registers to these values:
>
>         RES_PORT_IO_8, SYSCTRL_IO_BASE + 0xc0+37, 0x00, 0x44,/* GPIO38
> PCI_REQ3 */ \
>         RES_PORT_IO_8, SYSCTRL_IO_BASE + 0xc0+38, 0x00, 0x68,/* GPIO39
> PCI_GNT3 */ \
>         RES_PORT_IO_8, SYSCTRL_IO_BASE + 0xc0+39, 0x00, 0x44,/* GPIO40
> PCI_GNT2 */ \
>         RES_PORT_IO_8, SYSCTRL_IO_BASE + 0xc0+40, 0x00, 0x44,/* GPIO41
> PCI_REQ2 */ \
>
> After booting into LB, we find:
>
>  000024e5 : 00000004
>  000024e6 : 00000028
>  000024e7 : 00000004
>  000024e8 : 00000004
>
> So the 68h has turned into 28h - but the PCI slot works!
>
> Can you confirm what you see when you read out the values after booting in
> LinuxBIOS, with your patch?
>
> I've added debug code to src/northbridge/amd/amdk8/setup_resource_map.c to
> make it be explicit about what it's doing.
>
> 0018: 22 000024e5 <- & 00000000 | 00000044
> original value: 00000068
> after &: 00000000
> after |: 00000044
> confirmed value: 00000044
> 0019: 22 000024e6 <- & 00000000 | 00000068
> original value: 00000068
> after &: 00000000
> after |: 00000068
> confirmed value: 00000028
> 001a: 22 000024e7 <- & 00000000 | 00000044
> original value: 00000068
> after &: 00000000
> after |: 00000044
> confirmed value: 00000044
> 001b: 22 000024e8 <- & 00000000 | 00000044
> original value: 00000068
> after &: 00000000
> after |: 00000044
> confirmed value: 00000044
>
> So somehow 68h is turned into 28h when read back. It's as if there is a
> sticky bit on that register.
>
> And it looks like something is doing an & 10111111 sometime later during the
> boot process turning 44h into 4h, but I have not figured out where that might
> be happening.
>
> Any thoughts?
>
> Thanks,
> Ward.
>
>
> --
> Ward Vandewege <ward at fsf.org>
> Free Software Foundation - Senior System Administrator
>






More information about the coreboot mailing list