[coreboot] AMD Tilapia / simnow: endless looping in functionpci_scan_bus
wt at penguintechs.org
Sat Sep 4 05:12:02 CEST 2010
Who's responsible for the tilapia port? I am trying to assign this to
someone in the patchwork system, but I don't know who to assign it to.
Also, is there a testbed that can run this change to make sure it
doesn't break non-tilapia systems?
On Thu, Sep 2, 2010 at 12:18 AM, Juhana Helovuo <juhe at iki.fi> wrote:
> 1.9.2010 23:00, Scott kirjoitti:
>> 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.
> I had similar problems recently. I did a patch for Asus M4A785-M, which is
> derived from the AMD Tilapia port.
> The patch can be found at
> There is another patch that sets up UMA and coreboot/ACPI/etc. tables as
> reserved areas in the multiboot tables. Without this patch booting with Grub
> to Linux suffers from the same problem of overwriting tables.
> I do not know if these are going to be integrated to the Coreboot trunk, but
> currently they are available as patch files.
> How does SeaBIOS detect which RAM is usable and which is not? Maybe the
> memory conflict with UMA and ACPI tables could be avoided in a similar
> Best regards,
> Juhana Helovuo
> coreboot mailing list: coreboot at coreboot.org
More information about the coreboot