Bug #10: nvramtool fails to extract CMOS layout from CBMEM - coreboot - Issue Tracker

Actions

Copy link

Bug #10

closed

nvramtool fails to extract CMOS layout from CBMEM

Added by Timothy Pearson about 9 years ago. Updated almost 9 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Category:

os_handoff

Target version:

Start date:

11/25/2015

Due date:

% Done:

Estimated time:

Affected versions:

Needs backport to:

Affected hardware:

Affected OS:

Description

On all ASUS KGPE-D16 systems across every supported coreboot revision nvramtool fails to find a valid CBMEM table:
nvramtool: coreboot table not found. coreboot does not appear to
be installed on this system. Scanning for the table produced the
following results:

        0 valid signatures were found with bad header checksums.
        1 valid headers were found with bad table checksums.

cbmem -t has a different take on the table validity:
16 entries total:

0:1st timestamp 412,121
1:start of rom stage 412,836 (715)
2:before ram initialization 1,136,999 (724,162)
3:after ram initialization 15,498,973 (14,361,974)
4:end of romstage 15,624,631 (125,657)
10:start of ramstage 15,700,842 (76,211)
30:device enumeration 15,704,011 (3,168)
40:device configuration 18,181,771 (2,477,760)
50:device enable 18,188,003 (6,232)
60:device initialization 18,190,394 (2,391)
70:device setup done 18,883,332 (692,937)
75:cbmem post 18,884,387 (1,055)
80:write tables 18,885,443 (1,055)
90:load payload 18,903,332 (17,888)
15:starting LZMA decompress (ignore for x86) 18,903,988 (656)
16:finished LZMA decompress (ignore for x86) 18,935,555 (31,566)
99:selfboot jump 18,937,670 (2,115)

I suspect the cbmem tool handles the tables differently (more correctly?) than nvramtool, but don't really have time to track this down, considering that nvramtool -y is a functional workaround.

I can provide more debug information if needed, but there is nothing out of the ordinary in either the coreboot console or dmesg, so I would probably need to know which parts of the code to instrument before being able to provide anything useful.

Thanks!

Actions

Copy link

Updated by Timothy Pearson about 9 years ago

Sorry, I meant to post cbmem -l output above, but somehow inexplicably posted cbmem -t output instead:

CBMEM table of contents:
    ID           START      LENGTH
 0. IMD ROOT     bffffff8   00001000
 1. IMD SMALL    bfffeff8   00001000
 2. CAR GLOBALS  bfff3ff8   0000a380
 3. CONSOLE      bffd3ff8   00020000
 4. AMDMEM INFO  bffc9ff8   000090ca
 5. ACPI RESUME  bfcc9ff8   00300000
 6. IRQ TABLE    bfcc8ff8   00001000
 7. SMP TABLE    bfcc7ff8   00001000
 8. ACPI         bfca3ff8   00024000
 9. TCPA LOG     bfc93ff8   00010000
10. SMBIOS       bfc92ff8   00000800
11. COREBOOT     bfc8aff8   00008000

Actions

Copy link

Updated by Aaron Durbin about 9 years ago

I've never ran nvramtool before. It looks like it's scanning memory for the lb tables? But that's just failing?

Actions

Copy link

Updated by Timothy Pearson about 9 years ago

Aaron Durbin wrote:

I've never ran nvramtool before. It looks like it's scanning memory for the lb tables? But that's just failing?

Yes, I was wondering if perhaps the tables were updated along with cbmem but somehow nvramtool was overlooked. My first guess was the memory aperture problem but I don't see an invalid access in dmesg like I did with cbmem.

In any case nvramtool works on the KFSN4-DRE, but not on any of the SR5650-based platforms. I haven't checked other AMD systems as I don't have access to any other coreboot-compatible boards.

Actions

Copy link

Updated by Aaron Durbin about 9 years ago

map_pages() in there can munmap() the previous mapping. However, lbtable_scan() is calling map_pages() but using a previous instance of phystov(). Basically, any variable assignment using phystov() needs to be reevaluated after a map_pages() call. Try this?


diff --git a/util/nvramtool/lbtable.c b/util/nvramtool/lbtable.c
index 1c7bc0a..5db61c5 100644
--- a/util/nvramtool/lbtable.c
+++ b/util/nvramtool/lbtable.c
@@ -489,6 +489,9 @@ static const struct lb_header *lbtable_scan(unsigned long start,
                }

                map_pages(p, table->table_bytes + sizeof(*table));
+
+               table = (const struct lb_header *)phystov(p);
+
                /* validate table checksum */
                if (table->table_checksum !=
                    compute_ip_checksum(((char *)table) + sizeof(*table),

Actions

Copy link

Updated by Timothy Pearson about 9 years ago

Aaron Durbin wrote:

map_pages() in there can munmap() the previous mapping. However, lbtable_scan() is calling map_pages() but using a previous instance of phystov(). Basically, any variable assignment using phystov() needs to be reevaluated after a map_pages() call. Try this?
diff --git a/util/nvramtool/lbtable.c b/util/nvramtool/lbtable.c
index 1c7bc0a..5db61c5 100644
--- a/util/nvramtool/lbtable.c
+++ b/util/nvramtool/lbtable.c
@@ -489,6 +489,9 @@ static const struct lb_header *lbtable_scan(unsigned long start,
                }

                map_pages(p, table->table_bytes + sizeof(*table));
+
+               table = (const struct lb_header *)phystov(p);
+
                /* validate table checksum */
                if (table->table_checksum !=
                    compute_ip_checksum(((char *)table) + sizeof(*table),

This fixes the issue, thanks!

Actions

Copy link