[coreboot] memtest86 reading 0k memory

[Timothy Pearson]

On 02/05/2015 12:59 PM, Aaron Durbin wrote:
> On Thu, Feb 5, 2015 at 12:48 PM, Timothy Pearson
> <tpearson at 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