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

[Warren Turkal]

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?

Thanks,
wt

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.
>
> Hello,
>
> 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
> http://www.coreboot.org/pipermail/coreboot/2010-August/059989.html
>
> 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.
>
> http://www.coreboot.org/pipermail/coreboot/2010-August/060014.html
>
> 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
> manner?
>
> Best regards,
> Juhana Helovuo
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>