[LinuxBIOS] i82801DB PCI Bridge locking up
joe at smittys.pointclark.net
joe at smittys.pointclark.net
Fri Sep 14 08:49:58 CEST 2007
Quoting Tom Sylla <tsylla at gmail.com>:
> Can you check the SERR and PERR status in the bridge before the
> enable? (they are in offset 1f of config space) If you clear them
> first, does it help? We have a platform with a different southbridge
> where we find that to be the case (clearing the status bits first
> makes it not hang)
>
> On 9/13/07, joe at smittys.pointclark.net <joe at smittys.pointclark.net> wrote:
>> Quoting Peter Stuge <peter at stuge.se>:
>>
>> > On Thu, Sep 13, 2007 at 02:40:16AM -0400,
>> joe at smittys.pointclark.net wrote:
>> >> I wonder if my nic needs the pci rom to get it going, and this
>> >> would solve the problem?
>> >
>> > The ROM would be used much later in the init process, so no, it's not
>> > likely to help. :\
>> >
>> >
>> After a few tests I found the problem. It is locking up on this line:
>>
>> pci_write_config16(dev, PCI_COMMAND, command);
>>
>> It is trying to write to the CMD(0x04) register of the PCI Bridge.
>> Looks like it is trying to write 0x0141. Setting the SERR# Enable
>> (SERR_EN), Parity Error Response (PER), and I/O Space Enable (IOSE).
>>
>> I have no idea why this would cause a lock up??? I doesn't on any of
>> the other devices?? Could someone take a look at the i82801DB
>> datasheet and tell me if I am missing something?? Sometimes two (or
>> more) heads are better than one.
>>
>>
OK, I think I know what is going on here. When the
pci_bus_enable_resources() function runs it sets the Parity Error
Response Enable and SERR# Enable bits in the Bridge Control Register
(0x3E). And then it goes to the pci_dev_enable_resources() function
and Parity Error Response Enable and SERR# Enable bits in the Command
Register (0x04). I found this in the datasheet:
-------------------------------------------
BRIDGE_CNT?Bridge Control Register
SERR# Enable ? R/W.
0 = Disable
1 = If this bit is set AND bit 8 in CMD register (D30:F0 Offset 04h)
is also set, the ICH4 will set the SSE bit in PD_STS register (D30:F0,
offset 06h, bit 14) and also generate an NMI (or SMI# if NMI routed to
SMI) when the SERR# signal is asserted.
--------------------------------------------
So, I should just need to clear any parity and serr errors after
pci_bus_enable_resources() function runs but before the
pci_dev_enable_resources() function runs. Like this:
-------------------------------------------
void pci_bus_enable_resources(struct device *dev)
{
uint16_t ctrl;
/* enable IO in command register if there is VGA card
* connected with (even it does not claim IO resource) */
if (dev->link[0].bridge_ctrl & PCI_BRIDGE_CTL_VGA)
dev->command |= PCI_COMMAND_IO;
ctrl = pci_read_config16(dev, PCI_BRIDGE_CONTROL);
ctrl |= dev->link[0].bridge_ctrl;
ctrl |= (PCI_BRIDGE_CTL_PARITY + PCI_BRIDGE_CTL_SERR); /* error check */
printk_debug("%s bridge ctrl <- %04x\n", dev_path(dev), ctrl);
pci_write_config16(dev, PCI_BRIDGE_CONTROL, ctrl);
/* Clear any signaled system and parity errors */
ctrl = pci_read_config16(dev, PCI_STATUS);
ctrl |= dev->ctrl;
ctrl |= (PCI_STATUS_SIG_SYSTEM_ERROR + PCI_STATUS_DETECTED_PARITY);
pci_write_config16(dev, PCI_STATUS, ctrl);
ctrl = pci_read_config16(dev, PCI_SEC_STATUS);
ctrl |= dev->ctrl;
ctrl |= (PCI_STATUS_SIG_SYSTEM_ERROR + PCI_STATUS_DETECTED_PARITY);
pci_write_config16(dev, PCI_SEC_STATUS, ctrl);
pci_dev_enable_resources(dev);
enable_childrens_resources(dev);
}
-----------------------------------------------
I think this should work?? If it does work, how does everyone feel
about a patch for pci_device.c. This will effect alot of motherboards,
I'm supprised it hasn't already been an issue with other Intel PCI
Bridges.
I will test it and get back.
Thanks - Joe
More information about the coreboot
mailing list