[coreboot] memtest86 reading 0k memory

[Stefan Tauner]

On Thu, 19 Feb 2015 10:43:44 -0500
"Kevin O'Connor" <kevin at koconnor.net> wrote:

> On Wed, Feb 18, 2015 at 10:26:21PM +0100, Stefan Reinauer wrote:
> > * Timothy Pearson <tpearson at raptorengineeringinc.com> [150205 19:23]:
> > > e820: BIOS-provided physical RAM map:
> > > BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
> > > BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
> > > BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
> > > BIOS-e820: [mem 0x0000000000100000-0x000000003ffacfff] usable
> > > BIOS-e820: [mem 0x000000003ffad000-0x000000003fffffff] reserved
> > > BIOS-e820: [mem 0x00000000e0000000-0x00000000efffffff] reserved
> >  
> > One of the issues seems to be that the coreboot table space is not
> > marked as reserved (i.e. the lower 4k should be marked as reserved, and
> > whatever is used at the top of memory)
> 
> coreboot tends to reserve the first 4K, but this breaks lots of
> bootloaders.  So, SeaBIOS always overrides coreboot and unreserves the
> first 4K.  My experience is that the first one megabyte of the e820 is
> just "magical" and should always read as listed above.
> 
> Separately, it is possible for SeaBIOS to remove the coreboot table
> forwarder, and thus force memtest86 to not use the coreboot tables.
> I'm not sure if this would affect other programs though.

I ran into the problem today when trying to verify that the ASRock
IMB-A180-H works correctly with coreboot. Is there any consensus on
what to do? IMHO this is a bug in SeaBIOS... it creates the discrepancy
between the tables and that leads to problems downstream... but that's
arguable. What is not arguable: some action is required. :)

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner