[coreboot] memtest86 reading 0k memory

[Martin Roth]

On 04/08/2015 08:45 PM, Kevin O'Connor wrote:
> On Wed, Apr 08, 2015 at 10:55:18PM +0200, Stefan Tauner wrote:
>> 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. :)
> I don't agree the above is a defect in SeaBIOS.  SeaBIOS properly
> reads the memory tables from coreboot, and it properly provides
> updated memory tables to clients.
>
> SeaBIOS could try to force memtest86 to not use the coreboot memory
> table (by deleting the coreboot forwarding table), but I suspect that
> will interfere with other users of the coreboot tables.  (For example,
> it's unclear to me if "cbmem" will continue to work from linux if
> SeaBIOS removes the forwarding table.)
>
> I'd guess it would be better to change memtest86 to not use the
> coreboot table if it is started via a BIOS.
>
> -Kevin
>
To fix this for myself, I've updated memsize.c file with the following:

   void mem_size(void)
  {
      int i, flag=0;
      v->test_pages = 0;
      unsigned long intvect = *(unsigned long *)(0x15 * sizeof (void *));

      /* Get the memory size from the BIOS */
      /* Determine the memory map */
      if (intvect && query_pcbios()) {
          flag = 2;
      }
      else if (query_linuxbios()) {
          flag = 1;
      }
  ...

This tells it to use SeaBIOS's int15 tables first if they exist. This 
way anything that SeaBIOS has reserved gets picked up.  If the Int 15h 
vector isn't there, such as when memtest is being run directly from 
coreboot as a payload, it uses the coreboot memory tables instead.  
Unfortunately, this doesn't solve the problem for all the other copies 
of memtest86+ that could be run.

In regards to other approaches, instead of removing coreboot's memory 
tables, would it be better if SeaBIOS updated the tables with what it 
had changed instead of deleting the tables?

Martin