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@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@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot