[coreboot] [PATCH] Add support for Asus M4A785-M, with build instructions
mylesgw at gmail.com
Mon Sep 13 18:29:05 CEST 2010
On Mon, Sep 13, 2010 at 10:08 AM, Juhana Helovuo <juhe at iki.fi> wrote:
> On Mon, 2010-09-13 at 09:08 -0600, Myles Watson wrote:
>> Thanks for tracking it down. I committed the patches as
>> Rev 5805 (PCI & SB700)
>> Rev 5806 (Multiboot tables)
>> Rev 5807 (fam10 UMA)
>> Rev 5808 (fam10 reserved regions)
>> Rev 5809 (Asus M4A785-M)
> Thanks a lot for all your troubles and advice!
>> > * 5796 + your simplified patches --> SATA failure
>> > It seems to me that the patches are ok, but some trunk change from 5795
>> > to 5796 is causing the problems.
>> There seems to be a problem with CONFIG_MMCONF_SUPPORT vs.
>> This should work for you until it's fixed. If it doesn't, I need to
>> dig a little deeper.
> Hmm. I just checked out 5810 and tested. Configuration and building go
> smoothly (although menuconfig gives wrong ROM size by default, should
> be 1 MByte), but Linux still fails on SATA and USB.
> I edited away MMCONF_SUPPORT before configuring like you wrote, but it
> does not help.
> Also, I ran into another problem:
> When I upgrade RAM from 2 GB to 4 GB (or 6 GB), executing the VGA BIOS
> gets stuck. Coreboot jumps into the BIOS code, but it never returns.
> With more RAM, the UMA gets mapped to 0xd0000000 and PCI iomem areas get
> mapped over real RAM, starting at 0xe0000000. In the boot log I found
> the following line:
> Warning: Can't set up MTRR hole for UMA due to pre-existing MTRR hole.
> This message does not appear with 2 GB RAM.
> More test results with 6 GB RAM:
> * If I disable the GFXUMA option, do not include VGA BIOS on CBFS, and
> install another VGA card in a PCI slot, I get the same results. Coreboot
> locates the BIOS on the external card, copies to low RAM, jumps into it,
> and gets stuck.
> * If I hardwire UMA start address to be 0x70000000 and UMA size 64M in
> mainboard.c, the BIOS does not get stuck and Coreboot launches Grub2.
> However, Grub2 is very unstable and crashes randomly. I also sometimes
> get random garbage on VGA. Loading Linux does not work, causes machine
> to get stuck or reboot.
> Apparently there is some address conflict, but where should I start
The problem seems to be that the mainboard code gets its information
on the size of memory from TOP_MEM, but that hasn't been set correctly
with respect to the PCI resources yet.
m4a785m_enable, TOP MEM: msr.lo = 0xe0000000, msr.hi = 0x00000000
m4a785m_enable, TOP MEM2: msr2.lo = 0xa0000000, msr2.hi = 0x00000001
m4a785m_enable: uma size 0x10000000, memory start 0xd0000000
Root Device assign_resources, bus 0 link: 0
split: 64K table at =cfff0000
0: mmio_basek=00300000, basek=00400000, limitk=00680000
Adding UMA memory area
So even though there are PCI resources located at 0xc0000000, RAM gets
used for UMA at 0xd0000000 and tables get placed at 0xcfff0000.
You could test that theory by hard coding the top mem logic in mainboard.c.
Because the mainboard device is at the root of the tree, the
northbridge initialization hasn't been done yet, so the values it
wants haven't been calculated.
More information about the coreboot