On Thu, 19 Feb 2015 10:43:44 -0500 "Kevin O'Connor" <ke...@koconnor.net> wrote:
> On Wed, Feb 18, 2015 at 10:26:21PM +0100, Stefan Reinauer wrote: > > * Timothy Pearson <tpear...@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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot