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
Coreboot maps the frame buffer (or overall GPU memory) to
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