On Thu, 19 Feb 2015 10:43:44 -0500 "Kevin O'Connor" kevin@koconnor.net wrote:
On Wed, Feb 18, 2015 at 10:26:21PM +0100, Stefan Reinauer wrote:
- Timothy Pearson tpearson@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. :)