3

Background

dmidecode utility is able to create a raw binary dump using --dump-bin option:

root@here:~$ dmidecode --dump-bin foo.dump

which can be re-used on another machine, producing effect as if dmidecode is running on the original machine:

me@elsewhere:~$ dmidecode --dump-bin foo.dump
# dmidecode 2.12
SMBIOS 2.7 present.
68 structures occupying 2688 bytes.
Table at 0xBAE9D000.
[...]

I do have these binaries from some machines and use them for testing a script that wraps around dmidecode (hence, I need to simulate dmidecode behavior as if the hardware setup was different).

Problem

But from a several machines, I don't have the raw binary, but do have copy of /sys/firmware/dmi/tables as exposed by 4.* kernel. Docs at kernel.org say:

[...] The dmi/tables provides raw SMBIOS entry point and DMI tables through sysfs as an alternative to utilities reading them from /dev/mem. The raw SMBIOS entry point and DMI table are presented as binary attributes and are accessible via:

/sys/firmware/dmi/tables/smbios_entry_point
/sys/firmware/dmi/tables/DMI

The complete DMI information can be obtained using these two tables.

Question

Is it possible to use the /sys/firmware/dmi/tables files to re-construct (in a Bash/Python/Perl/... script) the raw binary dump so that it can be re-used as in first example?

I tried to just cat the files together but I was not successful (Invalid entry length (0). DMI table is broken! Stop.).

Improve this question
2
  • In my Lamobo R1 I am fortunate enough to also have the tables. However I am considering buying hardware in a near future, and I am aware of this problem. Just to be sure, are you talking about ARM SBCs with closed design where the vendor hacked some kernel by hand? Commented Dec 21, 2015 at 9:19
  • @RuiFRibeiro I'm "harvesting" the data from a Beaker testing repo. The set is relatively diverse; there are various types of machines (even a laptop). I'd guess they were collected using some recent RHEL or Fedora version. ... did that answer your question? Commented Dec 21, 2015 at 14:06

2 Answers 2

Reset to default
2

enter image description here

enter image description here

enter image description here

You can ref code from https://github.com/mirror/dmidecode/blob/master/dmidecode.c . Good luck for you.

enter image description here

Example: 7f + 00 + 80 + 30 + 7b = 18a

18a hold 8bit = 8a

New address of DMI is hard coded to 0x20.

Improve this answer
0

If you compare a hex dump of smbios_entry_point with the binary output of dmidecode, you'll see it is similar to bytes 0-31 of dmidecode's output. Likewise, DMI matches bytes 32+. Byte 32 is missing; I assume it's always null.

It looks close enough that I had hopes of it working.

echo -en '\0' >NUL
sudo cat /sys/firmware/dmi/tables/smbios_entry_point NUL /sys/firmware/dmi/tables/DMI >table
dmidecode --from-dump table

However, dmidecode crashes with the following output:

# dmidecode 2.12-dmifs
Reading SMBIOS/DMI data from file table.
SMBIOS 2.8 present.
Bus error (core dumped)

The SMBIOS/DMI spec is available on the internet (pdf); it shouldn't be too hard to determine acceptable dummy values for the header. I'm leaving that as an exercise for the reader, at least for the moment ;)

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.