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 <[email protected]> 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: [email protected] > http://www.coreboot.org/mailman/listinfo/coreboot > -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
