Project

General

Profile

Actions

Bug #277

open

T420: RAM module type information stored in flash

Added by Christian S. over 3 years ago. Updated over 3 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
board support
Target version:
-
Start date:
07/29/2020
Due date:
% Done:

0%

Estimated time:
2.00 h
Affected versions:
Needs backport to:
Affected hardware:
Affected OS:

Description

After flashing coreboot on my T420, I came over a thing which seemed to be strange for me when reading back the image (using flashrom -r).
When you compare the read-out image, it should be exactly the same. This is true if you do it directly after flashing.
However, if you reboot your system and you read out the chip again, you will be surprised. The image differs from the original one you flashed (at least on the T420).
In the original case, exactly 1600 bytes are written to the area beginning at offset 0x00700000. In this area (which according to the coreboot Wiki belongs to the ME), normally a large section is initially filled with 0xFF (so probably free space to store information).

Now in midst of these mentioned 1600 bytes in question, I found the following:
*> 00700530: 0000 0500 dc05 0300 830b 4e54 3447 4336 ..........NT4GC6

00700540: 3442 3848 4730 4e53 2d43 0064 6623 0500 4B8HG0NS-C.df#..*
If you google the string in it, you will find the 4G SODIMM-RAM module I used for this boot.

If you insert a different SODIMM module before the next bootup, another 1600 bytes section is appended after the first one, containing the type information of this new module. So this seems to be kind of a list of hardware information, regarding RAM modules. All the rest of the ROM image did not change in my current observations.

I have not found any hint in the documentation that the flashed image would change itself upon booting...

Now my question is:
Why is this RAM configuration information stored in the flash memory, and not in NVRAM???
I thought the flash memory should be read-only! (except for dedicated situations when you flash it)

Or am I wrong here? It seems as if it might actually not be a bug, but then it should be explained in the documentation.

Actions #1

Updated by Christian S. over 3 years ago

Additional remark: After using me_cleaner.py to reduce the size of the ME to 84 kB, the issue is still observed.
But the section in question now seems to shift more to the beginning of the image, along with the ME:
From 0x00700000 to 0x00020000.

diff <(xxd coreboot.rom) <(xxd read_back.rom )
8193c8193
< 00020000: ffff ffff ffff ffff ffff ffff ffff ffff  ................
---
> 00020000: 0500 6a00 cf00 ffff ffff ffff ffff ffff  ..j.............
8198,8399c8198,8399

This seems to be some kind of header, after which the list containing the RAM module information follows:

> 00020050: 4d52 4344 3406 0000 7883 bddf 0500 0000  MRCD4...x.......
<...>
> 00020530: 0000 0500 dc05 0300 80ce 4d34 3731 4235  ..........M471B5
> 00020540: 3237 3343 4830 2d43 4b30 00e6 be12 3b00  273CH0-CK0....;.
<...>
> 00020610: 859b 4354 3531 3236 3442 4631 3630 424a  ..CT51264BF160BJ
> 00020620: 2e43 00a6 0e0d 2600 0000 0000 0000 0000  .C....&.........
<...>

More onwards, the sequence MRCD4 is repeated, and the list seems to repeat in some way (backup?).

> 000206a0: 4d52 4344 3406 0000 1304 235f 0500 0000  MRCD4.....#_....
<...>
> 00020b80: 0000 0500 dc05 0300 80ce 4d34 3731 4235  ..........M471B5
> 00020b90: 3237 3343 4830 2d43 4b30 00e6 be12 3b00  273CH0-CK0....;.
<...>

Note that I verified the read-out procedure with an external programmer once (so it cannot come from the system's memory / interfer with mmap on /dev/mem in some way).

Maybe this is completely out-of-topic and not related to coreboot at all.
However, I would be interested in the background here, if you could give me a hint?

Actions

Also available in: Atom PDF