On 02/05/2015 12:59 PM, Aaron Durbin wrote:
On Thu, Feb 5, 2015 at 12:48 PM, Timothy Pearson
<tpear...@raptorengineeringinc.com> wrote:
On 02/05/2015 12:38 PM, Jonathan A. Kollasch wrote:
That's a pretty old memtest86+. Also, memtest86+ prefers
linuxbios/coreboot memory map to e820. This becomes a problem
when SeaBIOS sets up a USB controller to DMA to e820-reserved
memory that wasn't reserved by coreboot.
Try a modern memtest86+ with the coreboot table probe patched out.
Jonathan Kollasch
Yep, that was it. Didn't catch the obsolete version number.
I'm trying to figure out the point of memtest86 reading the coreboot tables.
It doesn't help that the coreboot tables / e820 map are apparently wrong;
memtest86+ almost immediately started stepping on the lower MMIO regions
(e.g. 0xb800) rendering the display mostly useless. Interestingly Linux
doesn't seem to have any problems; I'll need to investigate further.
Your e820 looks fine to me. memtest86 should just be testing the
usable regions. Since b800 isn't in there, the only issue that could
arise is it using that physical address as a mmio bar. However, that'd
be an OS level thing, and I wouldn't expect the memtest86 doing any
such things. It sounds more like it does a merge of some sort with
e820 and its notion of valid memory instead relying on e820 proper.
Thanks for the information. The e820 map is comparable to the one
generated from the proprietary BIOS so I agree it is likely correct.
That leaves the coreboot tables themselves and/or memtest86's
interpretation of them.
BTW it looks I am not the only one to have run into this:
http://www.coreboot.org/pipermail/coreboot/2010-December/062245.html
At this point I'm not sure if the bug is in coreboot, SeaBIOS, or memtest86.
--
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645
http://www.raptorengineeringinc.com
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
