On Mon, Sep 13, 2010 at 11:26 AM, Juhana Helovuo juhe@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