[coreboot] Memtest86+ stuck

[Max Zim]

Hello,

I discovered the issue with Memtest86+ stuck on my Thinkpad x230 on the 
very first tests. Always on the same point, 52%. Every release since 4.8 
works this way, coreboot 4.7 works fine. Is this a known bug?

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

Re: [coreboot] Memtest86 SPD/DMI popups broken

[Ben Gardner]

Yes, lets revert it.
The popups work again after reverting commit 03e81e1
(https://review.coreboot.org/#/c/13900).

The other one (https://review.coreboot.org/#/c/13901/) doesn't make a
difference on my board.
Probably because I have VGA. I suppose that one can stay.

On Wed, Mar 9, 2016 at 1:57 PM, Martin Roth  wrote:
> Do you think we should revert those patches until we can get them fixed?
>
> On Wed, Mar 9, 2016 at 11:56 AM, Ben Gardner  wrote:
>> FYI -
>>
>> I just tried memtest86 with the popup patches that were added to coreboot.
>> I'm seeing issues with clearing the background before drawing the SPD popup.
>>
>> When I hit "c", the "settings" popup shows on both serial and VGA
>> properly. VGA has a black background and serial clears the area.
>>
>> When I select "display SPD data", it doesn't clear the background
>> before drawing the data and doesn't restore what was under when the
>> popup is lowered.
>>
>> Below is the output from the serial port when displaying the SPD data.
>> View in a fixed width font.
>>
>> -
>> Memtest86+ 5.01 coreboot 001| Intel(R) Atom(TM) CPU  E3845  @ 1.91GHz
>> CLK: 1917 MHz  (X64 Mode)   | Pass  0%
>> L1 CSPD Data: Slot 095 MB/s | Test 50% ###
>> L2 Cache: 1024K  22030 MB/s | Test #2  [Address test, own address Parallel]
>> L3 Cac92:13N0be03 04 19 02 02 03s11n01 0820a 001fe600  1965M of 4013M
>> Memory69:78069M3c 69811M18s81 20t08r3c 3ca01r40s83 05   | Time:   0:00:01
>> --00-00-00-00-00-00-00-00-00-84-00-00-00-00-00-00-
>> Core#:00 00M00 00s00l00)00|00C00 00m00 00R0f:01102M00 (DDR3-833) - BCLK:  83
>> State:00 00 00 00 00 00 00 00 00 00 00 00 00 00s00C00 9-9-9-10 @ 64-bit Mode
>> Cores:00100 00 00 00 00 00 00 00 00 00 00 00 00 00 000Errors:  0
>> --00-00 00 00 00 00 00 00 00 00 00 00 00 
>> 00-00-00-
>>   00 00 00 00 00 80 2c 00 00 00 00 00 00 00 c4 b1
>> Memory34P4b 54 46 32 35 36 36 34 48 5a 2d 31 47 36 45
>> --31-45 31 80 2c 00 00 00 00 00 00 00 00 00 00 00
>>   - Sl00 00 00 00 00 00 00 00 00 00 00 00 00 00600ZffG6E1E
>>   - Sl57 50 4e 3a 33 34 32 35 36 20 52 45 56 3a641ZffG6E1E
>>   32 30 34 38 20 4d 42 59 54 45 ff ff ff ff ff ff
>>   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>
>>
>>
>> Wabtec CPU-1900
>> (ESC)exit  (c)configuration  (SP)scroll_lock  (CR)scroll_unlock
>> -
>>
>> And what is shown after returning to the settings menu.
>>
>> -
>> Memtest86+ 5.01 coreboot 001| Intel(R) Atom(TM) CPU  E3845  @ 1.91GHz
>> CLK: 1917 MHz  (X64 Mode)   | Pass  0%
>> L1 CSPD Data: Slot 195 MB/s | Test 88% ##
>> L2 CaNo valid DMI Memory Devices info founding inversions, 1s & 0s Parallel]
>> L3 Cac92:13N0be03 04 19 02 02 03s11n01 0890a 006fe400  2048M of 4013M
>> Memory69:78069M3c 69811M18s81 20t08r3c 3cf01f40f83 05   | Time:   0:05:38
>> --00-00-00-00-00-00-00-00-00-84-00-00-00-00-00-00-
>> Core#:00 00M00 00s00l00)00|00C00 00m00 00R0f:01102M00 (DDR3-833) - BCLK:  83
>> State:00 00  00s00C00 9-9-9-10 @ 64-bit Mode
>> Cores:00100  Settings:   00 00 000Errors:  0
>> --00-00  
>> 00-00-00-
>>   00 00  (1) Test Selection  00 c4 b1
>> Memory34P4b  (2) Address Range   47 36 45
>> --31-45  (3) Error Report Mode   00 00 00
>>   - Sl00 00  (4) Core Selection  00600ZffG6E1E
>>   - Sl57 50  (5) Refresh Screen  3a641ZffG6E1E
>>   32 30  (6) Display DMI Dataff ff ff
>>   ff ff  (7) Display SPD Dataff ff ff
>>   ff ff  ff ff ff
>>   ff ff  (0) Continueff ff ff
>>
>>
>>
>> Wabtec CPU-1900
>> (ESC)exit  (c)configuration  (SP)scroll_lock  (CR)scroll_unlock
>> -
>>
>> Not sure what is going on here.
>> I don't have this issue without the popup patches.
>> I'll look into it a bit more.
>>
>> Ben
>>
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> https://www.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Memtest86 SPD/DMI popups broken

[Martin Roth]

Do you think we should revert those patches until we can get them fixed?

On Wed, Mar 9, 2016 at 11:56 AM, Ben Gardner  wrote:
> FYI -
>
> I just tried memtest86 with the popup patches that were added to coreboot.
> I'm seeing issues with clearing the background before drawing the SPD popup.
>
> When I hit "c", the "settings" popup shows on both serial and VGA
> properly. VGA has a black background and serial clears the area.
>
> When I select "display SPD data", it doesn't clear the background
> before drawing the data and doesn't restore what was under when the
> popup is lowered.
>
> Below is the output from the serial port when displaying the SPD data.
> View in a fixed width font.
>
> -
> Memtest86+ 5.01 coreboot 001| Intel(R) Atom(TM) CPU  E3845  @ 1.91GHz
> CLK: 1917 MHz  (X64 Mode)   | Pass  0%
> L1 CSPD Data: Slot 095 MB/s | Test 50% ###
> L2 Cache: 1024K  22030 MB/s | Test #2  [Address test, own address Parallel]
> L3 Cac92:13N0be03 04 19 02 02 03s11n01 0820a 001fe600  1965M of 4013M
> Memory69:78069M3c 69811M18s81 20t08r3c 3ca01r40s83 05   | Time:   0:00:01
> --00-00-00-00-00-00-00-00-00-84-00-00-00-00-00-00-
> Core#:00 00M00 00s00l00)00|00C00 00m00 00R0f:01102M00 (DDR3-833) - BCLK:  83
> State:00 00 00 00 00 00 00 00 00 00 00 00 00 00s00C00 9-9-9-10 @ 64-bit Mode
> Cores:00100 00 00 00 00 00 00 00 00 00 00 00 00 00 000Errors:  0
> --00-00 00 00 00 00 00 00 00 00 00 00 00 00-00-00-
>   00 00 00 00 00 80 2c 00 00 00 00 00 00 00 c4 b1
> Memory34P4b 54 46 32 35 36 36 34 48 5a 2d 31 47 36 45
> --31-45 31 80 2c 00 00 00 00 00 00 00 00 00 00 00
>   - Sl00 00 00 00 00 00 00 00 00 00 00 00 00 00600ZffG6E1E
>   - Sl57 50 4e 3a 33 34 32 35 36 20 52 45 56 3a641ZffG6E1E
>   32 30 34 38 20 4d 42 59 54 45 ff ff ff ff ff ff
>   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>
>
>
> Wabtec CPU-1900
> (ESC)exit  (c)configuration  (SP)scroll_lock  (CR)scroll_unlock
> -
>
> And what is shown after returning to the settings menu.
>
> -
> Memtest86+ 5.01 coreboot 001| Intel(R) Atom(TM) CPU  E3845  @ 1.91GHz
> CLK: 1917 MHz  (X64 Mode)   | Pass  0%
> L1 CSPD Data: Slot 195 MB/s | Test 88% ##
> L2 CaNo valid DMI Memory Devices info founding inversions, 1s & 0s Parallel]
> L3 Cac92:13N0be03 04 19 02 02 03s11n01 0890a 006fe400  2048M of 4013M
> Memory69:78069M3c 69811M18s81 20t08r3c 3cf01f40f83 05   | Time:   0:05:38
> --00-00-00-00-00-00-00-00-00-84-00-00-00-00-00-00-
> Core#:00 00M00 00s00l00)00|00C00 00m00 00R0f:01102M00 (DDR3-833) - BCLK:  83
> State:00 00  00s00C00 9-9-9-10 @ 64-bit Mode
> Cores:00100  Settings:   00 00 000Errors:  0
> --00-00  00-00-00-
>   00 00  (1) Test Selection  00 c4 b1
> Memory34P4b  (2) Address Range   47 36 45
> --31-45  (3) Error Report Mode   00 00 00
>   - Sl00 00  (4) Core Selection  00600ZffG6E1E
>   - Sl57 50  (5) Refresh Screen  3a641ZffG6E1E
>   32 30  (6) Display DMI Dataff ff ff
>   ff ff  (7) Display SPD Dataff ff ff
>   ff ff  ff ff ff
>   ff ff  (0) Continueff ff ff
>
>
>
> Wabtec CPU-1900
> (ESC)exit  (c)configuration  (SP)scroll_lock  (CR)scroll_unlock
> -
>
> Not sure what is going on here.
> I don't have this issue without the popup patches.
> I'll look into it a bit more.
>
> Ben
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Memtest86 SPD/DMI popups broken

[Ben Gardner]

FYI -

I just tried memtest86 with the popup patches that were added to coreboot.
I'm seeing issues with clearing the background before drawing the SPD popup.

When I hit "c", the "settings" popup shows on both serial and VGA
properly. VGA has a black background and serial clears the area.

When I select "display SPD data", it doesn't clear the background
before drawing the data and doesn't restore what was under when the
popup is lowered.

Below is the output from the serial port when displaying the SPD data.
View in a fixed width font.

-
Memtest86+ 5.01 coreboot 001| Intel(R) Atom(TM) CPU  E3845  @ 1.91GHz
CLK: 1917 MHz  (X64 Mode)   | Pass  0%
L1 CSPD Data: Slot 095 MB/s | Test 50% ###
L2 Cache: 1024K  22030 MB/s | Test #2  [Address test, own address Parallel]
L3 Cac92:13N0be03 04 19 02 02 03s11n01 0820a 001fe600  1965M of 4013M
Memory69:78069M3c 69811M18s81 20t08r3c 3ca01r40s83 05   | Time:   0:00:01
--00-00-00-00-00-00-00-00-00-84-00-00-00-00-00-00-
Core#:00 00M00 00s00l00)00|00C00 00m00 00R0f:01102M00 (DDR3-833) - BCLK:  83
State:00 00 00 00 00 00 00 00 00 00 00 00 00 00s00C00 9-9-9-10 @ 64-bit Mode
Cores:00100 00 00 00 00 00 00 00 00 00 00 00 00 00 000Errors:  0
--00-00 00 00 00 00 00 00 00 00 00 00 00 00-00-00-
  00 00 00 00 00 80 2c 00 00 00 00 00 00 00 c4 b1
Memory34P4b 54 46 32 35 36 36 34 48 5a 2d 31 47 36 45
--31-45 31 80 2c 00 00 00 00 00 00 00 00 00 00 00
  - Sl00 00 00 00 00 00 00 00 00 00 00 00 00 00600ZffG6E1E
  - Sl57 50 4e 3a 33 34 32 35 36 20 52 45 56 3a641ZffG6E1E
  32 30 34 38 20 4d 42 59 54 45 ff ff ff ff ff ff
  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff



Wabtec CPU-1900
(ESC)exit  (c)configuration  (SP)scroll_lock  (CR)scroll_unlock
-

And what is shown after returning to the settings menu.

-
Memtest86+ 5.01 coreboot 001| Intel(R) Atom(TM) CPU  E3845  @ 1.91GHz
CLK: 1917 MHz  (X64 Mode)   | Pass  0%
L1 CSPD Data: Slot 195 MB/s | Test 88% ##
L2 CaNo valid DMI Memory Devices info founding inversions, 1s & 0s Parallel]
L3 Cac92:13N0be03 04 19 02 02 03s11n01 0890a 006fe400  2048M of 4013M
Memory69:78069M3c 69811M18s81 20t08r3c 3cf01f40f83 05   | Time:   0:05:38
--00-00-00-00-00-00-00-00-00-84-00-00-00-00-00-00-
Core#:00 00M00 00s00l00)00|00C00 00m00 00R0f:01102M00 (DDR3-833) - BCLK:  83
State:00 00  00s00C00 9-9-9-10 @ 64-bit Mode
Cores:00100  Settings:   00 00 000Errors:  0
--00-00  00-00-00-
  00 00  (1) Test Selection  00 c4 b1
Memory34P4b  (2) Address Range   47 36 45
--31-45  (3) Error Report Mode   00 00 00
  - Sl00 00  (4) Core Selection  00600ZffG6E1E
  - Sl57 50  (5) Refresh Screen  3a641ZffG6E1E
  32 30  (6) Display DMI Dataff ff ff
  ff ff  (7) Display SPD Dataff ff ff
  ff ff  ff ff ff
  ff ff  (0) Continueff ff ff



Wabtec CPU-1900
(ESC)exit  (c)configuration  (SP)scroll_lock  (CR)scroll_unlock
-

Not sure what is going on here.
I don't have this issue without the popup patches.
I'll look into it a bit more.

Ben

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] memtest86+ test fails at 3070.7MB

[Jonathan A. Kollasch]

On Thu, Aug 20, 2015 at 06:36:00PM +0800, Iru Cai wrote:
 Hi,
 
 I installed coreboot(4.1-315-gf58746b) on a ThinkPad X220, with factory VGA
 option ROM and SeaBIOS 1.7.5 as payload. When I run memtest86+ on this
 machine, it reports a fail at 3070.7MB. If I just install a 2GB memory
 module, it passes the test. So what makes memtest86+ give a test failure?

Any other differences, particularly with respect to attached USB devices
between each test?

If you run memtest86+ on SeaBIOS w/ USB (or other DMA-using hardware)
on coreboot, you can expect to see memory test failures due to DMA
clobbering the memory you're trying to test.  You need a memtest86+
patched to not check for a coreboot/linuxbios memory map.  SeaBIOS
reserves its own memory in the BIOS memory map, but not the coreboot
memory map, so when running SeaBIOS the coreboot memory map is wrong.

Jonathan Kollasch

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] memtest86+ test fails at 3070.7MB

[Iru Cai]

Hi,

I installed coreboot(4.1-315-gf58746b) on a ThinkPad X220, with factory VGA
option ROM and SeaBIOS 1.7.5 as payload. When I run memtest86+ on this
machine, it reports a fail at 3070.7MB. If I just install a 2GB memory
module, it passes the test. So what makes memtest86+ give a test failure?

Iru
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] memtest86 reading 0k memory

[Kevin O'Connor]

On Thu, Apr 09, 2015 at 11:03:43AM -0600, Martin Roth wrote:
 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?

It's technically possible, but I don't think it's a good idea.  It
would be complex to do and it could lead to confusion when
troubleshooting.

As far as I know, only memtest86 has this problem.  Is it possible to
get your patch into its upstream repo?

-Kevin

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [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 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 0x-0x0009fbff] usable
BIOS-e820: [mem 0x0009fc00-0x0009] reserved
BIOS-e820: [mem 0x000f-0x000f] reserved
BIOS-e820: [mem 0x0010-0x3ffacfff] usable
BIOS-e820: [mem 0x3ffad000-0x3fff] reserved
BIOS-e820: [mem 0xe000-0xefff] 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


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] memtest86 reading 0k memory

[Kevin O'Connor]

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 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 0x-0x0009fbff] usable
BIOS-e820: [mem 0x0009fc00-0x0009] reserved
BIOS-e820: [mem 0x000f-0x000f] reserved
BIOS-e820: [mem 0x0010-0x3ffacfff] usable
BIOS-e820: [mem 0x3ffad000-0x3fff] reserved
BIOS-e820: [mem 0xe000-0xefff] 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

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] memtest86 reading 0k memory

[Stefan Tauner]

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 0x-0x0009fbff] usable
   BIOS-e820: [mem 0x0009fc00-0x0009] reserved
   BIOS-e820: [mem 0x000f-0x000f] reserved
   BIOS-e820: [mem 0x0010-0x3ffacfff] usable
   BIOS-e820: [mem 0x3ffad000-0x3fff] reserved
   BIOS-e820: [mem 0xe000-0xefff] 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

Re: [coreboot] memtest86 reading 0k memory

[Carl-Daniel Hailfinger]

On 08.04.2015 22:55, Stefan Tauner wrote:
 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 0x-0x0009fbff] usable
 BIOS-e820: [mem 0x0009fc00-0x0009] reserved
 BIOS-e820: [mem 0x000f-0x000f] reserved
 BIOS-e820: [mem 0x0010-0x3ffacfff] usable
 BIOS-e820: [mem 0x3ffad000-0x3fff] reserved
 BIOS-e820: [mem 0xe000-0xefff] 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. :)

The Linux kernel expects coreboot+SeaBIOS to lie and marks the first 4K
as reserved again. Excerpt from my dmesg on a T60 running coreboot+SeaBIOS:

e820: BIOS-provided physical RAM map:
BIOS-e820: [mem 0x-0x0009fbff] usable
BIOS-e820: [mem 0x0009fc00-0x0009] reserved
BIOS-e820: [mem 0x000f-0x000f] reserved
BIOS-e820: [mem 0x0010-0xcfec9fff] usable
BIOS-e820: [mem 0xcfeca000-0xcfff] reserved
BIOS-e820: [mem 0xf000-0xf3ff] reserved
SMBIOS 2.7 present.
DMI: LENOVO 2007VVT/2007VVT, BIOS CBET4000 4.0-7070-g2fc0a1d 10/18/2014
e820: update [mem 0x-0x0fff] usable == reserved
e820: remove [mem 0x000a-0x000f] usable

Regards,
Carl-Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] memtest86 reading 0k memory

[Kevin O'Connor]

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 0x-0x0009fbff] usable
  BIOS-e820: [mem 0x0009fc00-0x0009] reserved
  BIOS-e820: [mem 0x000f-0x000f] reserved
  BIOS-e820: [mem 0x0010-0x3ffacfff] usable
  BIOS-e820: [mem 0x3ffad000-0x3fff] reserved
  BIOS-e820: [mem 0xe000-0xefff] 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.

-Kevin

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] memtest86 reading 0k memory

[Stefan Reinauer]

* Timothy Pearson tpear...@raptorengineeringinc.com [150205 19:23]:
 e820: BIOS-provided physical RAM map:
 BIOS-e820: [mem 0x-0x0009fbff] usable
 BIOS-e820: [mem 0x0009fc00-0x0009] reserved
 BIOS-e820: [mem 0x000f-0x000f] reserved
 BIOS-e820: [mem 0x0010-0x3ffacfff] usable
 BIOS-e820: [mem 0x3ffad000-0x3fff] reserved
 BIOS-e820: [mem 0xe000-0xefff] 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)

Stefan

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] memtest86 reading 0k memory

[Timothy Pearson]

On 02/05/2015 09:45 PM, Timothy Pearson wrote:

On 02/05/2015 09:13 PM, Scott Duplichan wrote:

Timothy Pearson [mailto:tpear...@raptorengineeringinc.com] wrote:

]Sent: Thursday, February 05, 2015 06:49 PM
]To: Coreboot
]Subject: Re: [coreboot] memtest86 reading 0k memory
]
]On 02/05/2015 06:42 PM, Timothy Pearson wrote:
] On 02/05/2015 02:06 PM, Timothy Pearson wrote:
] On 02/05/2015 01:51 PM, Aaron Durbin wrote:
] Do you have the coreboot console log? Looking at memtest86 it
] constructs its own e820 when using linuxbios. Additionally, it also
] has some concept of a window to test as well as plim_lower and
] plim_upper variables that seem to add to the mix.
]
] What's super frightening is that find_chunks(int tst) is called
in the
] code as find_chunks() while the find_chunks() function actually
] references tst as an array index. That's all from config.c. But I
] think that's only if you hit c on the keyboard. I wouldn't do
that...
]
] I can't make heads or tails of that code at the moment. for
selecting
] the window to test.
]
] Please see text log attached. It looks like the failing accesses
start
] at 0xa, which (judging by memtest's effects on the screen)
appears
] to be mapped to the VGA text buffer. That region is *not* reserved
under
] the proprietary BIOS's e820 map.
]
] Thanks!
]
]
] I was able to resolve the lower MMIO region failures (coreboot driver
] patch in for review), but memtest86 is stubbornly insisting on testing
] reserved memory, causing a single failure at 3ffade80. The e820 map
says
] that address is out of bounds but the coreboot tables do not:
]
] e820 map has 6 items:
] 0:  - 0009fc00 = 1 RAM
] 1: 0009fc00 - 000a = 2 RESERVED
] 2: 000f - 0010 = 2 RESERVED
] 3: 0010 - 3ffad000 = 1 RAM
] 4: 3ffad000 - 4000 = 2 RESERVED
] 5: e000 - f000 = 2 RESERVED
]
] coreboot table: 460 bytes.
] CBMEM ROOT 0. 3000 1000
] CONSOLE 1. 3ffdf000 0002
] TIME STAMP 2. 3ffde000 1000
] GDT 3. 3ffdd000 1000
] SMP TABLE 4. 3ffdc000 1000
] ACPI 5. 3ffb8000 00024000
] SMBIOS 6. 3ffb7000 1000
] COREBOOT 7. 3ffaf000 8000
]
] Why the discrepancy? Am I correct in assuming this is a bug in
coreboot
] that needs to be fixed?
]
]
]Sorry, wrong coreboot table above:
]
]Writing coreboot table at 0x3ffaf000
]rom_table_end = 0x3ffaf000
]... aligned to 0x3ffb
] 0. -0fff: CONFIGURATION TABLES
] 1. 1000-0009: RAM
] 2. 000a-000a: RESERVED
] 3. 000b-000b7fff: RAM
] 4. 000b8000-000b: RESERVED
] 5. 000c-3ffaefff: RAM
] 6. 3ffaf000-3fff: CONFIGURATION TABLES
] 7. e000-efff: RESERVED
]
]I assume something is placing itself at 3ffad000 (coreboot? SeaBIOS?)
]and that overwriting it is a Bad Thing, but whatever it is does not
]update the coreboot tables and memtest86 promptly stomps on it.

I imagine SeaBIOS is taking memory from the end of free RAM below
4GB for USB structures. There is probably an incrementing frame
counter at 3ffade80. It looks like SeaBIOS builds the E820 table
to properly account for the memory it uses. If memtest86 uses the
coreboot tables even when an E820 handler is installed, that seems
wrong. Unless SeaBIOS is supposed to adjust the coreboot tables to
reflect its memory usage, which I don't think is the case.


I suspect you're right about the USB structures; my USB keyboard quit
working when memtest started. Looks like I'll be building memtest86 with
coreboot support disabled; judging by the numerous problems reported by
other coreboot users memtest badly needs an update to disable coreboot
support by default.



Recompiling memtest with the coreboot table detection bypassed resolved 
the problem.


Thanks for the help!

--
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645
http://www.raptorengineeringinc.com

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] memtest86 reading 0k memory

[Timothy Pearson]

On 02/05/2015 09:13 PM, Scott Duplichan wrote:

Timothy Pearson [mailto:tpear...@raptorengineeringinc.com] wrote:

]Sent: Thursday, February 05, 2015 06:49 PM
]To: Coreboot
]Subject: Re: [coreboot] memtest86 reading 0k memory
]
]On 02/05/2015 06:42 PM, Timothy Pearson wrote:
]  On 02/05/2015 02:06 PM, Timothy Pearson wrote:
]  On 02/05/2015 01:51 PM, Aaron Durbin wrote:
]  Do you have the coreboot console log? Looking at memtest86 it
]  constructs its own e820 when using linuxbios. Additionally, it also
]  has some concept of a window to test as well as plim_lower and
]  plim_upper variables that seem to add to the mix.
]
]  What's super frightening is that find_chunks(int tst) is called in the
]  code as find_chunks() while the find_chunks() function actually
]  references tst as an array index. That's all from config.c. But I
]  think that's only if you hit c on the keyboard. I wouldn't do that...
]
]  I can't make heads or tails of that code at the moment. for selecting
]  the window to test.
]
]  Please see text log attached. It looks like the failing accesses start
]  at 0xa, which (judging by memtest's effects on the screen) appears
]  to be mapped to the VGA text buffer. That region is *not* reserved under
]  the proprietary BIOS's e820 map.
]
]  Thanks!
]
]
]  I was able to resolve the lower MMIO region failures (coreboot driver
]  patch in for review), but memtest86 is stubbornly insisting on testing
]  reserved memory, causing a single failure at 3ffade80. The e820 map says
]  that address is out of bounds but the coreboot tables do not:
]
]  e820 map has 6 items:
]  0:  - 0009fc00 = 1 RAM
]  1: 0009fc00 - 000a = 2 RESERVED
]  2: 000f - 0010 = 2 RESERVED
]  3: 0010 - 3ffad000 = 1 RAM
]  4: 3ffad000 - 4000 = 2 RESERVED
]  5: e000 - f000 = 2 RESERVED
]
]  coreboot table: 460 bytes.
]  CBMEM ROOT 0. 3000 1000
]  CONSOLE 1. 3ffdf000 0002
]  TIME STAMP 2. 3ffde000 1000
]  GDT 3. 3ffdd000 1000
]  SMP TABLE 4. 3ffdc000 1000
]  ACPI 5. 3ffb8000 00024000
]  SMBIOS 6. 3ffb7000 1000
]  COREBOOT 7. 3ffaf000 8000
]
]  Why the discrepancy? Am I correct in assuming this is a bug in coreboot
]  that needs to be fixed?
]
]
]Sorry, wrong coreboot table above:
]
]Writing coreboot table at 0x3ffaf000
]rom_table_end = 0x3ffaf000
]... aligned to 0x3ffb
]  0. -0fff: CONFIGURATION TABLES
]  1. 1000-0009: RAM
]  2. 000a-000a: RESERVED
]  3. 000b-000b7fff: RAM
]  4. 000b8000-000b: RESERVED
]  5. 000c-3ffaefff: RAM
]  6. 3ffaf000-3fff: CONFIGURATION TABLES
]  7. e000-efff: RESERVED
]
]I assume something is placing itself at 3ffad000 (coreboot? SeaBIOS?)
]and that overwriting it is a Bad Thing, but whatever it is does not
]update the coreboot tables and memtest86 promptly stomps on it.

I imagine SeaBIOS is taking memory from the end of free RAM below
4GB for USB structures. There is probably an incrementing frame
counter at 3ffade80. It looks like SeaBIOS builds the E820 table
to properly account for the memory it uses. If memtest86 uses the
coreboot tables even when an E820 handler is installed, that seems
wrong. Unless SeaBIOS is supposed to adjust the coreboot tables to
reflect its memory usage, which I don't think is the case.


I suspect you're right about the USB structures; my USB keyboard quit 
working when memtest started.  Looks like I'll be building memtest86 
with coreboot support disabled; judging by the numerous problems 
reported by other coreboot users memtest badly needs an update to 
disable coreboot support by default.


--
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645
http://www.raptorengineeringinc.com

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] memtest86 reading 0k memory

[Aaron Durbin via coreboot]

On Thu, Feb 5, 2015 at 12:48 PM, Timothy Pearson
tpear...@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.

 --
 Timothy Pearson
 Raptor Engineering
 +1 (415) 727-8645
 http://www.raptorengineeringinc.com

 --
 coreboot mailing list: coreboot@coreboot.org
 http://www.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [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
tpear...@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

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] memtest86 reading 0k memory

[Timothy Pearson]

On 02/05/2015 02:06 PM, Timothy Pearson wrote:

On 02/05/2015 01:51 PM, Aaron Durbin wrote:

Do you have the coreboot console log? Looking at memtest86 it
constructs its own e820 when using linuxbios. Additionally, it also
has some concept of a window to test as well as plim_lower and
plim_upper variables that seem to add to the mix.

What's super frightening is that find_chunks(int tst) is called in the
code as find_chunks() while the find_chunks() function actually
references tst as an array index. That's all from config.c. But I
think that's only if you hit c on the keyboard. I wouldn't do that...

I can't make heads or tails of that code at the moment. for selecting
the window to test.


Please see text log attached. It looks like the failing accesses start
at 0xa, which (judging by memtest's effects on the screen) appears
to be mapped to the VGA text buffer. That region is *not* reserved under
the proprietary BIOS's e820 map.

Thanks!



I was able to resolve the lower MMIO region failures (coreboot driver 
patch in for review), but memtest86 is stubbornly insisting on testing 
reserved memory, causing a single failure at 3ffade80.  The e820 map 
says that address is out of bounds but the coreboot tables do not:


e820 map has 6 items:
  0:  - 0009fc00 = 1 RAM
  1: 0009fc00 - 000a = 2 RESERVED
  2: 000f - 0010 = 2 RESERVED
  3: 0010 - 3ffad000 = 1 RAM
  4: 3ffad000 - 4000 = 2 RESERVED
  5: e000 - f000 = 2 RESERVED

coreboot table: 460 bytes.
CBMEM ROOT  0. 3000 1000
CONSOLE 1. 3ffdf000 0002
TIME STAMP  2. 3ffde000 1000
GDT 3. 3ffdd000 1000
SMP TABLE   4. 3ffdc000 1000
ACPI5. 3ffb8000 00024000
SMBIOS  6. 3ffb7000 1000
COREBOOT7. 3ffaf000 8000

Why the discrepancy?  Am I correct in assuming this is a bug in coreboot 
that needs to be fixed?


--
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645
http://www.raptorengineeringinc.com

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] memtest86 reading 0k memory

[Timothy Pearson]

On 02/05/2015 06:42 PM, Timothy Pearson wrote:

On 02/05/2015 02:06 PM, Timothy Pearson wrote:

On 02/05/2015 01:51 PM, Aaron Durbin wrote:

Do you have the coreboot console log? Looking at memtest86 it
constructs its own e820 when using linuxbios. Additionally, it also
has some concept of a window to test as well as plim_lower and
plim_upper variables that seem to add to the mix.

What's super frightening is that find_chunks(int tst) is called in the
code as find_chunks() while the find_chunks() function actually
references tst as an array index. That's all from config.c. But I
think that's only if you hit c on the keyboard. I wouldn't do that...

I can't make heads or tails of that code at the moment. for selecting
the window to test.


Please see text log attached. It looks like the failing accesses start
at 0xa, which (judging by memtest's effects on the screen) appears
to be mapped to the VGA text buffer. That region is *not* reserved under
the proprietary BIOS's e820 map.

Thanks!



I was able to resolve the lower MMIO region failures (coreboot driver
patch in for review), but memtest86 is stubbornly insisting on testing
reserved memory, causing a single failure at 3ffade80. The e820 map says
that address is out of bounds but the coreboot tables do not:

e820 map has 6 items:
0:  - 0009fc00 = 1 RAM
1: 0009fc00 - 000a = 2 RESERVED
2: 000f - 0010 = 2 RESERVED
3: 0010 - 3ffad000 = 1 RAM
4: 3ffad000 - 4000 = 2 RESERVED
5: e000 - f000 = 2 RESERVED

coreboot table: 460 bytes.
CBMEM ROOT 0. 3000 1000
CONSOLE 1. 3ffdf000 0002
TIME STAMP 2. 3ffde000 1000
GDT 3. 3ffdd000 1000
SMP TABLE 4. 3ffdc000 1000
ACPI 5. 3ffb8000 00024000
SMBIOS 6. 3ffb7000 1000
COREBOOT 7. 3ffaf000 8000

Why the discrepancy? Am I correct in assuming this is a bug in coreboot
that needs to be fixed?



Sorry, wrong coreboot table above:

Writing coreboot table at 0x3ffaf000
rom_table_end = 0x3ffaf000
... aligned to 0x3ffb
 0. -0fff: CONFIGURATION TABLES
 1. 1000-0009: RAM
 2. 000a-000a: RESERVED
 3. 000b-000b7fff: RAM
 4. 000b8000-000b: RESERVED
 5. 000c-3ffaefff: RAM
 6. 3ffaf000-3fff: CONFIGURATION TABLES
 7. e000-efff: RESERVED

I assume something is placing itself at 3ffad000 (coreboot? SeaBIOS?) 
and that overwriting it is a Bad Thing, but whatever it is does not 
update the coreboot tables and memtest86 promptly stomps on it.


--
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645
http://www.raptorengineeringinc.com

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] memtest86 reading 0k memory

[Scott Duplichan]

Timothy Pearson [mailto:tpear...@raptorengineeringinc.com] wrote:

]Sent: Thursday, February 05, 2015 06:49 PM
]To: Coreboot
]Subject: Re: [coreboot] memtest86 reading 0k memory
]
]On 02/05/2015 06:42 PM, Timothy Pearson wrote:
] On 02/05/2015 02:06 PM, Timothy Pearson wrote:
] On 02/05/2015 01:51 PM, Aaron Durbin wrote:
] Do you have the coreboot console log? Looking at memtest86 it
] constructs its own e820 when using linuxbios. Additionally, it also
] has some concept of a window to test as well as plim_lower and
] plim_upper variables that seem to add to the mix.
]
] What's super frightening is that find_chunks(int tst) is called in the
] code as find_chunks() while the find_chunks() function actually
] references tst as an array index. That's all from config.c. But I
] think that's only if you hit c on the keyboard. I wouldn't do that...
]
] I can't make heads or tails of that code at the moment. for selecting
] the window to test.
]
] Please see text log attached. It looks like the failing accesses start
] at 0xa, which (judging by memtest's effects on the screen) appears
] to be mapped to the VGA text buffer. That region is *not* reserved under
] the proprietary BIOS's e820 map.
]
] Thanks!
]
]
] I was able to resolve the lower MMIO region failures (coreboot driver
] patch in for review), but memtest86 is stubbornly insisting on testing
] reserved memory, causing a single failure at 3ffade80. The e820 map says
] that address is out of bounds but the coreboot tables do not:
]
] e820 map has 6 items:
] 0:  - 0009fc00 = 1 RAM
] 1: 0009fc00 - 000a = 2 RESERVED
] 2: 000f - 0010 = 2 RESERVED
] 3: 0010 - 3ffad000 = 1 RAM
] 4: 3ffad000 - 4000 = 2 RESERVED
] 5: e000 - f000 = 2 RESERVED
]
] coreboot table: 460 bytes.
] CBMEM ROOT 0. 3000 1000
] CONSOLE 1. 3ffdf000 0002
] TIME STAMP 2. 3ffde000 1000
] GDT 3. 3ffdd000 1000
] SMP TABLE 4. 3ffdc000 1000
] ACPI 5. 3ffb8000 00024000
] SMBIOS 6. 3ffb7000 1000
] COREBOOT 7. 3ffaf000 8000
]
] Why the discrepancy? Am I correct in assuming this is a bug in coreboot
] that needs to be fixed?
]
]
]Sorry, wrong coreboot table above:
]
]Writing coreboot table at 0x3ffaf000
]rom_table_end = 0x3ffaf000
]... aligned to 0x3ffb
]  0. -0fff: CONFIGURATION TABLES
]  1. 1000-0009: RAM
]  2. 000a-000a: RESERVED
]  3. 000b-000b7fff: RAM
]  4. 000b8000-000b: RESERVED
]  5. 000c-3ffaefff: RAM
]  6. 3ffaf000-3fff: CONFIGURATION TABLES
]  7. e000-efff: RESERVED
]
]I assume something is placing itself at 3ffad000 (coreboot? SeaBIOS?) 
]and that overwriting it is a Bad Thing, but whatever it is does not 
]update the coreboot tables and memtest86 promptly stomps on it.

I imagine SeaBIOS is taking memory from the end of free RAM below
4GB for USB structures. There is probably an incrementing frame
counter at 3ffade80. It looks like SeaBIOS builds the E820 table
to properly account for the memory it uses. If memtest86 uses the
coreboot tables even when an E820 handler is installed, that seems
wrong. Unless SeaBIOS is supposed to adjust the coreboot tables to
reflect its memory usage, which I don't think is the case.

]-- 
]Timothy Pearson
]Raptor Engineering
]+1 (415) 727-8645
]http://www.raptorengineeringinc.com



-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] memtest86 reading 0k memory

[Jonathan A. Kollasch]

On Thu, Feb 05, 2015 at 12:23:40PM -0600, Timothy Pearson wrote:
 All,
 
 I have a board here that loads memtest86 but won't actually test memory.
 
 This is the output:
 
   Memtest86+ v2.11
 AMD K10 CPU @ 2312 MHz
 L1 Cache:   64K  35028 MB/s
 L2 Cache:  512K   6963 MB/s
 L3 Cache: 2048K   6052 MB/s
 Memory  :0K |-
 Chipset :
 
 
 
 
  0K  LinuxBIOS
 
 
 
 I'm guessing memtest86 doesn't understand coreboot's memory
 tables/structure, but I have no idea why that would be.  The e820
 map is valid:
 e820: BIOS-provided physical RAM map:
 BIOS-e820: [mem 0x-0x0009fbff] usable
 BIOS-e820: [mem 0x0009fc00-0x0009] reserved
 BIOS-e820: [mem 0x000f-0x000f] reserved
 BIOS-e820: [mem 0x0010-0x3ffacfff] usable
 BIOS-e820: [mem 0x3ffad000-0x3fff] reserved
 BIOS-e820: [mem 0xe000-0xefff] reserved
 
 Any ideas?  Other than this one irritating glitch coreboot is
 working perfectly on this board.

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

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] memtest86 reading 0k memory

[Timothy Pearson]

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.


--
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645
http://www.raptorengineeringinc.com

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] memtest86 reading 0k memory

[Timothy Pearson]

All,

I have a board here that loads memtest86 but won't actually test memory.

This is the output:

  Memtest86+ v2.11
AMD K10 CPU @ 2312 MHz
L1 Cache:   64K  35028 MB/s
L2 Cache:  512K   6963 MB/s
L3 Cache: 2048K   6052 MB/s
Memory  :0K 
|-

Chipset :




 0K  LinuxBIOS



I'm guessing memtest86 doesn't understand coreboot's memory 
tables/structure, but I have no idea why that would be.  The e820 map is 
valid:

e820: BIOS-provided physical RAM map:
BIOS-e820: [mem 0x-0x0009fbff] usable
BIOS-e820: [mem 0x0009fc00-0x0009] reserved
BIOS-e820: [mem 0x000f-0x000f] reserved
BIOS-e820: [mem 0x0010-0x3ffacfff] usable
BIOS-e820: [mem 0x3ffad000-0x3fff] reserved
BIOS-e820: [mem 0xe000-0xefff] reserved

Any ideas?  Other than this one irritating glitch coreboot is working 
perfectly on this board.


Thanks!

--
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645
http://www.raptorengineeringinc.com

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] memtest86 reading 0k memory

[Aaron Durbin]

On Thu, Feb 5, 2015 at 1:15 PM, Timothy Pearson
tpear...@raptorengineeringinc.com wrote:
 On 02/05/2015 12:59 PM, Aaron Durbin wrote:

 On Thu, Feb 5, 2015 at 12:48 PM, Timothy Pearson
 tpear...@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.


Do you have the coreboot console log? Looking at memtest86 it
constructs its own e820 when using linuxbios. Additionally, it also
has some concept of a window to test as well as plim_lower and
plim_upper variables that seem to add to the mix.

What's super frightening is that find_chunks(int tst) is called in the
code as find_chunks() while the find_chunks() function actually
references tst as an array index. That's all from config.c. But I
think that's only if you hit c on the keyboard. I wouldn't do that...

I can't make heads or tails of that code at the moment. for selecting
the window to test.



 --
 Timothy Pearson
 Raptor Engineering
 +1 (415) 727-8645
 http://www.raptorengineeringinc.com

 --
 coreboot mailing list: coreboot@coreboot.org
 http://www.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Memtest86+ failing on coreboot system.

[Patrick Georgi]

Am 25.01.2010 17:13, schrieb Knut Kujat:
 - booting interrupts for about 4 minutes on Stage: loading
 fallback/coreboot_ram @ 0x20 (360448 bytes), entry @ 0x20
   
For this issue, the following change might help:
--- src/cpu/amd/mtrr/amd_earlymtrr.c(revision 5054)
+++ src/cpu/amd/mtrr/amd_earlymtrr.c(working copy)
@@ -45,8 +45,13 @@
 /* enable write through caching so we can do execute in place
  * on the flash rom.
  */
-set_var_mtrr(1, CONFIG_XIP_ROM_BASE, CONFIG_XIP_ROM_SIZE,
MTRR_TYPE_WRBACK);
+#if defined(CONFIG_TINY_BOOTBLOCK)  CONFIG_TINY_BOOTBLOCK
+#define REAL_XIP_ROM_BASE AUTO_XIP_ROM_BASE
+#else
+#define REAL_XIP_ROM_BASE CONFIG_XIP_ROM_BASE
 #endif
+set_var_mtrr(1, REAL_XIP_ROM_BASE, CONFIG_XIP_ROM_SIZE,
MTRR_TYPE_WRBACK);
+#endif

 /* Set the default memory type and enable fixed and variable MTRRs
  */

If it does, please let us know, so we can add it to the tree.

Regards,
Patrick

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Memtest86+ failing on coreboot system.

[Knut Kujat]

Patrick Georgi escribió:
 Am 25.01.2010 17:13, schrieb Knut Kujat:
   
 - booting interrupts for about 4 minutes on Stage: loading
 fallback/coreboot_ram @ 0x20 (360448 bytes), entry @ 0x20
   
 
 For this issue, the following change might help:
 --- src/cpu/amd/mtrr/amd_earlymtrr.c(revision 5054)
 +++ src/cpu/amd/mtrr/amd_earlymtrr.c(working copy)
 @@ -45,8 +45,13 @@
  /* enable write through caching so we can do execute in place
   * on the flash rom.
   */
 -set_var_mtrr(1, CONFIG_XIP_ROM_BASE, CONFIG_XIP_ROM_SIZE,
 MTRR_TYPE_WRBACK);
 +#if defined(CONFIG_TINY_BOOTBLOCK)  CONFIG_TINY_BOOTBLOCK
 +#define REAL_XIP_ROM_BASE AUTO_XIP_ROM_BASE
 +#else
 +#define REAL_XIP_ROM_BASE CONFIG_XIP_ROM_BASE
  #endif
 +set_var_mtrr(1, REAL_XIP_ROM_BASE, CONFIG_XIP_ROM_SIZE,
 MTRR_TYPE_WRBACK);
 +#endif

  /* Set the default memory type and enable fixed and variable MTRRs
   */

 If it does, please let us know, so we can add it to the tree.

 Regards,
 Patrick

   
Hello,

#if defined(CONFIG_XIP_ROM_SIZE)
 /* enable write through caching so we can do execute in place
  * on the flash rom.
  */
 #if defined(CONFIG_TINY_BOOTBLOCK)  CONFIG_TINY_BOOTBLOCK
   #define REAL_XIP_ROM_BASE AUTO_XIP_ROM_BASE
 #else
   #define REAL_XIP_ROM_BASE CONFIG_XIP_ROM_BASE
 #endif
 set_var_mtrr(1, REAL_XIP_ROM_BASE,
CONFIG_XIP_ROM_SIZE,MTRR_TYPE_WRBACK);

#endif

It still hangs at

Stage: loading
fallback/coreboot_ram @ 0x20 (360448 bytes), entry @ 0x20

for exactly 2min 28sec so I think it speed up a little :).

Thanks I really appreciate your help.

Knut Kujat. 


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Memtest86+ failing on coreboot system.

[Knut Kujat]

Hi,
I would love to send the new board to the list but there are several
issues still remaining like:
- SMBus gets irq 0 instead of 5
- ACPI not working
- booting interrupts for about 4 minutes on Stage: loading
fallback/coreboot_ram @ 0x20 (360448 bytes), entry @ 0x20

and the strangest thing: I created a new folder h8qme_fam10 (I was
working in h8dmr_fam10 all the time)  made the different changes to be
able to compile everything correctly and now it refuses to boot. It just
halts somewhere or does several soft resets at different places.

bye!

PS: Ward, if you are still interested I can send it to you.

Ward Vandewege escribió:
 On Fri, Jan 22, 2010 at 12:09:59AM +0100, Knut Kujat wrote:
   
 sorry, of course. I did the necessary changes on the alrady existing
 supermicro h8dmr_fam10 board to make it work on a h8qme_fam10.
 

 I'm interested in your port. It should go into the tree. Do you want to send
 a patch to the list?

 Thanks,
 Ward.

   


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Memtest86+ failing on coreboot system.

[Patrick Georgi]

Am 25.01.2010 17:13, schrieb Knut Kujat:
 Hi,
 I would love to send the new board to the list but there are several
 issues still remaining like:
 - SMBus gets irq 0 instead of 5
 - ACPI not working
   
We have lots of boards with (at best) incomplete ACPI support. That
shouldn't stop you from releasing :-)
 - booting interrupts for about 4 minutes on Stage: loading
 fallback/coreboot_ram @ 0x20 (360448 bytes), entry @ 0x20
   
You could try to dump the MTRRs right before loading the ramstage. 4
minutes sounds like there's some problem with caching.
 and the strangest thing: I created a new folder h8qme_fam10 (I was
 working in h8dmr_fam10 all the time)  made the different changes to be
 able to compile everything correctly and now it refuses to boot. It just
 halts somewhere or does several soft resets at different places.
   
Did you check that there is no h8dmr_fam10 or H8DMR_FAM10 in the new
directory? Is that directory hooked up in kconfig (if you're using
kconfig, that is)?
If you mix up the names, it might just build a mix of code for your
board and another supermicro board.


Patrick

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Memtest86+ failing on coreboot system.

[Knut Kujat]

Patrick Georgi escribió:
 Am 25.01.2010 17:13, schrieb Knut Kujat:
   
 Hi,
 I would love to send the new board to the list but there are several
 issues still remaining like:
 - SMBus gets irq 0 instead of 5
 - ACPI not working
   
 
 We have lots of boards with (at best) incomplete ACPI support. That
 shouldn't stop you from releasing :-)
   
 - booting interrupts for about 4 minutes on Stage: loading
 fallback/coreboot_ram @ 0x20 (360448 bytes), entry @ 0x20
   
 
 You could try to dump the MTRRs right before loading the ramstage. 4
 minutes sounds like there's some problem with caching.
   
 and the strangest thing: I created a new folder h8qme_fam10 (I was
 working in h8dmr_fam10 all the time)  made the different changes to be
 able to compile everything correctly and now it refuses to boot. It just
 halts somewhere or does several soft resets at different places.
   
 
 Did you check that there is no h8dmr_fam10 or H8DMR_FAM10 in the new
 directory? Is that directory hooked up in kconfig (if you're using
 kconfig, that is)?
 If you mix up the names, it might just build a mix of code for your
 board and another supermicro board.


 Patrick
I was very careful with not mixing names. I tried to just rename the
existing folder as well with the same result, it's just so annoying
because I know I must be forgetting something really stupid.

thx,
Knut Kujat.

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Memtest86+ failing on coreboot system.

[Myles Watson]

 Patrick Georgi escribió:
  Am 25.01.2010 17:13, schrieb Knut Kujat:
 
  Hi,
  I would love to send the new board to the list but there are several
  issues still remaining like:
  - SMBus gets irq 0 instead of 5
  - ACPI not working
 
  We have lots of boards with (at best) incomplete ACPI support. That
  shouldn't stop you from releasing :-)

I agree.

 I was very careful with not mixing names. I tried to just rename the
 existing folder as well with the same result, it's just so annoying
 because I know I must be forgetting something really stupid.

If you send it to the list, others will be able to help you spot things.  As
long as you're working toward making it better, I don't think anyone minds
having ports that are in progress in the tree.

Thanks,
Myles


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Memtest86+ failing on coreboot system.

[Stefan Reinauer]

On 1/22/10 12:36 AM, Myles Watson wrote:
 I modified SeaBIOS to destroy the
 marker for the LinuxBIOS tables after reading them (since they are no longer
 useful.)  
Unless you ever plan to change CMOS settings, or update your BIOS and
want flashrom to know _reliably_ what mainboard you're using.

Stefan


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: i...@coresystems.de  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Memtest86+ failing on coreboot system.

[Myles Watson]

 On 1/22/10 12:36 AM, Myles Watson wrote:
  I modified SeaBIOS to destroy the
  marker for the LinuxBIOS tables after reading them (since they are no
 longer
  useful.)
 Unless you ever plan to change CMOS settings, or update your BIOS and
 want flashrom to know _reliably_ what mainboard you're using.

I did say it was an ugly hack :)  I should have said that I only used that
broken version of SeaBIOS when I wanted to run Memtest.  Since it's a pretty
simple change, maybe someone should push high tables support upstream into
memtest.

Thanks,
Myles


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Memtest86+ failing on coreboot system.

[Knut Kujat]

Hello,

I've finally got my board working with Coreboot now I started to stress
test the whole system to know if it is stable. Now, when I'm trying to
test my memory with Memtest86+ it doesn't starts! instead it shows correct
information about my cpus and caches but at Memory there is just a 0K
and in the middle of the screen a 0K LxBIOS what is that mean? After
waiting a few minutes I'm getting the whole screen full of rubbish symbols
and than the monitors goes off.

I already tried several versions of memtest86+ without luck. I know there
is a payload with Memtest86+ I haven't tried yet but I just don't think it
will make any difference, won't it?

THX,
Knut Kujat


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Memtest86+ failing on coreboot system.

[ron minnich]

can you remind us what hardware this is?

ron

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Memtest86+ failing on coreboot system.

[Peter Stuge]

Knut Kujat wrote:
 Now, when I'm trying to test my memory with Memtest86+ it doesn't
 starts!

How are you trying to start it?


 I know there is a payload with Memtest86+ I haven't tried yet
 but I just don't think it will make any difference, won't it?

Using memtest as payload is the only way I have tried, and it works
for me. Feel free to grab http://stuge.se/memtest.elf and try if
using that as payload works any better.


//Peter

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Memtest86+ failing on coreboot system.

[Knut Kujat]

Hi,

sorry, of course. I did the necessary changes on the alrady existing
supermicro h8dmr_fam10 board to make it work on a h8qme_fam10.

Supermicro H8QME-2+
4 CPUs (Opterons)
16 GB ram
MCP55 PRO
AMD 8132

I used the memtest that comes with the OPENSuse 11.2 installation CD I
also installed memtest to my grub boot menu.
Seems like memtest doesn't find any memory at all?! But linux boots fine
and recognized the whole memory amount. I already did some benchmarks and
they finished without any problems.

thx.


 can you remind us what hardware this is?

 ron



-- 
Knut Kujat


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Memtest86+ failing on coreboot system.

[ron minnich]

memtest in many ways is not my favorite program. I would rather have a
simple non-GUI tester, because in the past I've had trouble with it
(it can fail) when it did not like the device it was trying to do its
GUI on.

Also, the way memtest finds top of memory can fail on some chipsets.
Have not seen that for a while but I did see it.

No idea if any of  this is your problem but ...

ron

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Memtest86+ failing on coreboot system.

[Knut Kujat]

OK, thx anyway. I found another one memtester 4.1 usable from linux so
it won't test the whole amount but memtest86 doesn't either :P.

bye!
 memtest in many ways is not my favorite program. I would rather have a
 simple non-GUI tester, because in the past I've had trouble with it
 (it can fail) when it did not like the device it was trying to do its
 GUI on.

 Also, the way memtest finds top of memory can fail on some chipsets.
 Have not seen that for a while but I did see it.

 No idea if any of  this is your problem but ...

 ron



-- 
Knut Kujat


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Memtest86+ failing on coreboot system.

[Knut Kujat]

Ah, ok! I'll try this.

At least now I know from you and ron that it isn't necessary my ram thats
failing.

thx a lot!
Knut.


 I used the memtest that comes with the OPENSuse 11.2 installation CD I
 also installed memtest to my grub boot menu.
 Seems like memtest doesn't find any memory at all?! But linux boots fine
 and recognized the whole memory amount. I already did some benchmarks
 and
 they finished without any problems.

 Your problem sounds very similar to the one I had.

 Memtest looks to see if you have LinuxBIOS tables, but doesn't support
 tables in high memory, so it fails.  Since you are using SeaBIOS, you'd
 prefer that it used the BIOS tables.  I modified SeaBIOS to destroy the
 marker for the LinuxBIOS tables after reading them (since they are no
 longer
 useful.)  It's a hack, but it's quick and easy.

 Suggestions:
 Use a similar hack to destroy the signature so Memtest doesn't get
 confused
 Use a version of Memtest that already supports high tables.

 Thanks,
 Myles





-- 
Knut Kujat


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Memtest86+ failing on coreboot system.

[Myles Watson]

 I used the memtest that comes with the OPENSuse 11.2 installation CD I
 also installed memtest to my grub boot menu.
 Seems like memtest doesn't find any memory at all?! But linux boots fine
 and recognized the whole memory amount. I already did some benchmarks and
 they finished without any problems.

Your problem sounds very similar to the one I had.

Memtest looks to see if you have LinuxBIOS tables, but doesn't support
tables in high memory, so it fails.  Since you are using SeaBIOS, you'd
prefer that it used the BIOS tables.  I modified SeaBIOS to destroy the
marker for the LinuxBIOS tables after reading them (since they are no longer
useful.)  It's a hack, but it's quick and easy.  

Suggestions:
Use a similar hack to destroy the signature so Memtest doesn't get confused
Use a version of Memtest that already supports high tables.

Thanks,
Myles
 


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Memtest86+ failing on coreboot system.

[Ward Vandewege]

On Fri, Jan 22, 2010 at 12:09:59AM +0100, Knut Kujat wrote:
 sorry, of course. I did the necessary changes on the alrady existing
 supermicro h8dmr_fam10 board to make it work on a h8qme_fam10.

I'm interested in your port. It should go into the tree. Do you want to send
a patch to the list?

Thanks,
Ward.

-- 
Ward Vandewege w...@fsf.org
Free Software Foundation - Senior Systems Administrator

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Memtest86

[Myles Watson]

Has anyone used memtest86 as a payload recently?  I can't get it to work
with qemu or Serengeti.  On Qemu it executes outside of RAM, and on
Serengeti it writes garbage to the screen.

Thanks,
Myles


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Memtest86

[Ward Vandewege]

On Thu, Aug 13, 2009 at 10:08:00AM -0600, Myles Watson wrote:
 Has anyone used memtest86 as a payload recently?  I can't get it to work
 with qemu or Serengeti.  On Qemu it executes outside of RAM, and on
 Serengeti it writes garbage to the screen.

I have gotten it to work 6 months or so ago iirc, but it highly depended on
the version I tried. I think, maybe, that 3.4 was working for me but I'm not
sure.

Thanks,
Ward.

-- 
Ward Vandewege w...@fsf.org
Free Software Foundation - Senior Systems Administrator

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Memtest86

[Cristi Magherusan]

On Thu, 2009-08-13 at 10:08 -0600, Myles Watson wrote:
 Has anyone used memtest86 as a payload recently?  I can't get it to work
 with qemu or Serengeti.  On Qemu it executes outside of RAM, and on
 Serengeti it writes garbage to the screen.
 
 Thanks,
 Myles
 
Hello,

Do you use mkelfImage prior to adding the ELF in CBFS?

Cristi

-- 
Ing. Cristi Măgherușan, System/Network Engineer
Technical University of Cluj-Napoca, Romania
http://cc.utcluj.ro  +40264 401247


signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Memtest86

[Myles Watson]

On Thu, Aug 13, 2009 at 10:26 AM, Cristi Magherusan 
cristi.magheru...@net.utcluj.ro wrote:

 On Thu, 2009-08-13 at 10:08 -0600, Myles Watson wrote:
  Has anyone used memtest86 as a payload recently?  I can't get it to work

 Do you use mkelfImage prior to adding the ELF in CBFS?

No I didn't.  Is that necessary?

Thanks,
Myles
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Memtest86

[Arnaud Maye]

Myles,

I've tried it with the serial output enabled as no VGA on the truxton so 
far. It did segfault and I had

no time to dig further in.

Arnaud

Myles Watson wrote:

Has anyone used memtest86 as a payload recently?  I can't get it to work
with qemu or Serengeti.  On Qemu it executes outside of RAM, and on
Serengeti it writes garbage to the screen.

Thanks,
Myles


  


*
*

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Memtest86

[ron minnich]

I would really like a memtest without the eye candy. In at least one
case on geode if I ran it in a non-80-column window it would fail --
honest!

One that did simple serial out would really make life simpler.

ron

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot