[coreboot] [PATCH] Add support for Asus M4A785-M, with build instructions

[Myles Watson]

On Mon, Sep 13, 2010 at 11:26 AM, Juhana Helovuo <juhe at iki.fi> wrote:
> On Mon, 2010-09-13 at 10:29 -0600, Myles Watson wrote:
>
>>
>> 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.
>
> I tried with the following:
>
>        /* TOP_MEM: the top of DRAM below 4G */
>        msr = rdmsr(TOP_MEM);
>        //hardwire this for testing
>        if (msr.lo > 0x80000000) { msr.lo = 0x80000000; }
>
>
> This code manages to set UMA to a lower address, but the effect is the
> same as with hardwiring UMA address. Boot proceeds past VGA BIOS, but
> results in random crashes and reboots.
>
> Or did you mean some other hardwiring?
I thought more about the problem than the solution :)

> Since variable "msr" here is local to the routine, I don't see how it
> could have effect on anything else but the UMA location and size. The
> value read from TOP_MEM2 isn't even used for anything but printing.

I was hoping that changing the uma location would be enough to affect the rest.

Could you try

        if (msr.lo > 0xc0000000) { msr.lo = 0xc0000000; }

I'm thinking that would place uma at 0xb0000000 & coreboot tables at 0xafff0000.

Then could you send the log if that's still unstable.

Thanks,
Myles