[coreboot] AMD Tilapia / simnow: endless looping in functionpci_scan_bus

[Scott]

-----Original Message-----
From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] On Behalf Of Myles Watson
Sent: Wednesday, September 01, 2010 02:22 PM
To: Scott
Cc: coreboot at coreboot.org
Subject: Re: [coreboot] AMD Tilapia / simnow: endless looping in functionpci_scan_bus

On Wed, Sep 1, 2010 at 12:50 PM, Scott <scott at notabs.org> wrote:
> Hello,
>
> When booting the AMD Tilapia coreboot BIOS on simnow I encounter
> an endless loop in pci_scan_bus(). The reason is that pci_scan_bus
> expects a valid argument for max_devfn, yet receives 0xFFFFFFFF.
>
> The origin of the invalid max_devfn argument is line 596 of
> hypertransport.c:
>
>   max = pci_scan_bus(bus, 0x00, ((next_unitid-1) << 3)|7, max);
>
> With my setup, next_unitid is zero, which causes a bad argument
> to be passed to pci_scan_bus. As a work-around, I change the code
> to recognize and handle this case by passing 0xFF (all devices).
>
> Does anyone else encounter this situation on AMD boards? I ask
> because I am using simnow in place of real hardware.

Juhana Helovuo reported this in the thread "Porting to Asus M4A785-M".

Thanks,
Myles

-- 
coreboot mailing list: coreboot at coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot


Thanks Myles. That problem description and work-around matches my
situation exactly. Even if the bad value passed to pci_scan_bus is
only a side-effect of another problem, special handling for it should
be considered in order to simplify debugging.

The same thead covers another problem I encounter with Tilapia. When
I enable ACPI table generation, an overlap causes the seabios payload
to overwrite the ACPI tables. I temporarily worked around this problem
by deselecting GFXUMA. I am using PCI video so I can boot with no uma.

Thanks,
Scott