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 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
Any ideas? Other than this one irritating glitch coreboot is working perfectly on this board.
Thanks!
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.11AMD 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 LinuxBIOSI'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 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
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
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.
On Thu, Feb 5, 2015 at 12:48 PM, Timothy Pearson tpearson@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 KollaschYep, 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
* 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)
Stefan
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.
-Kevin
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. :)
On 08.04.2015 22:55, Stefan Tauner wrote:
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. :)
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 0x0000000000000000-0x000000000009fbff] usable BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved BIOS-e820: [mem 0x0000000000100000-0x00000000cfec9fff] usable BIOS-e820: [mem 0x00000000cfeca000-0x00000000cfffffff] reserved BIOS-e820: [mem 0x00000000f0000000-0x00000000f3ffffff] reserved SMBIOS 2.7 present. DMI: LENOVO 2007VVT/2007VVT, BIOS CBET4000 4.0-7070-g2fc0a1d 10/18/2014 e820: update [mem 0x00000000-0x00000fff] usable ==> reserved e820: remove [mem 0x000a0000-0x000fffff] usable
Regards, Carl-Daniel
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@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. :)
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
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@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. :)
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
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
-
Aaron Durbin -
Carl-Daniel Hailfinger -
Jonathan A. Kollasch -
Kevin O'Connor -
Martin Roth -
Stefan Reinauer -
Stefan Tauner -
Timothy Pearson