2.12.2010 17:31, Scott Duplichan kirjoitti:
]Also a modified Memtest86 can be executed from SeaBIOS, but clearly it ]gets a wrong idea of memory regions to test and quickly overwrites the ]VGA buffer (display trashed) and its own executable (crash with register ]dump). If the memtest is quickly interrupted to configuration menu and ]the test region is limited to only, e.g. addresses 300M - 1G, then it ]seems to run ok. Memtest claims that it is reading the coreboot tables ]to find out RAM areas to test.
I am not too familiar with memtest86, but an overwrite of the UMA memory should be easy to debug. From your e820 map, it looks like the DRAM reserved for UMA use is at 30000000-3fffffff. The frame buffer maps the same DRAM to a different address, such as D0000000. If the display is written, then one of these two ranges is getting written. What is your frame buffer address?
An experiment you could do is add a PCI video card and build without UMA graphics support.
Hello Scott,
Coreboot maps the frame buffer (or overall GPU memory) to e0000000-efffffff.
Testing without UMA also crossed my mind, but it has to wait until I manage to get a VGA card with DVI and PCI or PCI-E, so I can connect to the mainboard and monitor. My current junk^H^H^H^Hspare parts box has only cards with either analog VGA & PCI or DVI & AGP.
Still, my main concern is not memtest86, but getting Linux to boot at least so far that I can see some kernel boot messages to know what is happening.
Best regards, Juhana Helovuo