Dasharo
SMBIOS type 17 table doesn't show reliable data
Component
Dasharo firmware
Device
MSI Pro Z790-P, NovaCustom NV4x 12th Gen, other
Dasharo version
No response
Dasharo Tools Suite version
No response
Test case ID
No response
Brief summary
SMBIOS Memory Device table doesn't show correct data. Device and Bank Locator is constant between all DIMMs, which makes it impossible to differentiate between them, at least without comparing serial numbers (which usually are encoded in a way that doesn't match what is on a sticker). On top of that, SMBIOS specification clearly states that type 17 entry must be produced also for non-populated slots. Currently such entries are skipped for most Intel SoCs, probably due to the code being copied for each new family from an existing one. Example for Alderlake, but others are similar - entry is saved only if DIMM is present.
How reproducible
No response
How to reproduce
sudo dmidecode -t 17
Expected behavior
Proper locators should be reported. Empty DIMM slots should also be reported.
Actual behavior
ubuntu@3mdeb:~$ sudo dmidecode -t 17
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 3.3.0 present.
Handle 0x000B, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x000A
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 8 GB
Form Factor: SODIMM
Set: None
Locator: Channel-0-DIMM-0
Bank Locator: BANK 0
Type: DDR4
Type Detail: Unknown Synchronous
Speed: 3200 MT/s
Manufacturer: Kingston
Serial Number: ff9ace91
Asset Tag: Channel-0-DIMM-0-AssetTag
Part Number: 9905700-118.A00G
Rank: 1
Configured Memory Speed: 3200 MT/s
Minimum Voltage: 1.2 V
Maximum Voltage: 1.2 V
Configured Voltage: 1.2 V
Handle 0x000C, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x000A
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 8 GB
Form Factor: SODIMM
Set: None
Locator: Channel-0-DIMM-0
Bank Locator: BANK 0
Type: DDR4
Type Detail: Unknown Synchronous
Speed: 3200 MT/s
Manufacturer: Kingston
Serial Number: ff9aee4a
Asset Tag: Channel-0-DIMM-0-AssetTag
Part Number: 9905700-118.A00G
Rank: 1
Configured Memory Speed: 3200 MT/s
Minimum Voltage: 1.2 V
Maximum Voltage: 1.2 V
Configured Voltage: 1.2 V
Screenshots
No response
Additional context
No response
Solutions you've tried
No response
Question: is this about RAM slots and their numbering? If not, let me know and file a seperate issue.
From a end-user perspective this results for example on an OptiPlex 9010 w/ Dasharo v0.2 RC 3 (released 2021-09-24) in that Memtest has the slots all wrong:
Mainboard | Memtest
Slot | Slot
-------------------
3 |0
1 |1
4 |2
2 |3
@Firminator AFAICT Memtest iterates over I2C addresses, which aren't necessarily lined up with how the slots are laid out on the board. I2C addresses are hardwired and can't be changed. It may be possible to modify Memtest to use locators from SMBIOS instead, but I2C addresses are much more predictable and by design they are unique. Another reason why Memtest had chosen to use those indices may be that they are short, while SMBIOS locators are strings with unbounded length, which could easily overflow the screen width.
I'm afraid this isn't something that can be fixed by changes to Dasharo. It would be possible to make SMBIOS numbering the same as Memtest, but then it wouldn't match labels on the board, which would be even worse.
Thanks for the reply Krystian. So this is actually an 'issue' with Memtest and not Dasharo firmware. Interesting. I wonder if I should just ignore this... or if there are chances this can be addressed by Memtest. Sounds like a long stretch and lots of core code changes if they have to change the way how to identify memory slots. It's definitely confusing for users being pointed to an incorrect RAM slot given that's the whole purpose of Memtest. Maybe it's only affecting certain mainboards? I think I give opening an issue with Memtest a try and see what happens. Thanks.
Maybe it's only affecting certain mainboards?
Maybe. How vendor wants to label slots on the mainboard is entirely up to them. It seems that in case of OptiPlex they decided to number them according to suggested order of population, which is one of the reasonable possibilities. There are users which are technical enough to install new module, but not enough to understand channels (or worse, those who misunderstand how channels work), and this approach of labeling the slots is perfect for them.
In any case, at least for some platforms Dasharo reports that each DIMM is in Channel-0-DIMM-0. I haven't checked if OptiPlex is also impacted by this issue.
When I populate slot 1 and 2 (both white), and leave slots 3 and 4 (both black) unpopulated, then DTS reports:
RAM Channel-0-DIMM-1 RAM Channel-1-DIMM-1
But that's with v0.2 RC 3 (released 2021-09-24) ... one of the first releases when Michal Z. initially reverse-engineered the platform ('cursed EC'!; https://blog.3mdeb.com/2021/2021-06-01-optiplex_part2/ ) and adopted it to coreboot. Not sure yet what v0.1.1 from December 2024 will look like. I'm in the process of updating currently.
I think the DIMM locator issue can be handled by properly implementing smbios_fill_dimm_locator in mainboard code
I think the DIMM locator issue can be handled by properly implementing
smbios_fill_dimm_locatorin mainboard code
Usually, the soc code parses the FSP HOB to produce this data. I have been fixing the parsing for a couple of platforms already in the past. Otherwise it is just ordered per I2C address.
Is the 9010 one of those platforms that hasn't been fixed (or cannot be fixed) and that's why it's using the I2C address? Or in other words will implementing the smbios_fill_dimm_locator method fix the RAM slot order presented to other OS (like Memtest)?
Is the 9010 one of those platforms that hasn't been fixed (or cannot be fixed) and that's why it's using the I2C address? Or in other words will implementing the
smbios_fill_dimm_locator methodfix the RAM slot order presented to other OS (like Memtest)?
I2C address should be always correct by convention. The stickers on the board can be just RAM population order, as @krystian-hebel explained. Nothing to fix here for 9010. Example SMBIOS from Dell OptiPlex running coreboot/Dasharo:
Handle 0x000A, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x0009
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 4 GB
Form Factor: DIMM
Set: None
Locator: Channel-0-DIMM-1
Bank Locator: BANK 0
Type: DDR3
Type Detail: Synchronous Unbuffered (Unregistered)
Speed: 800 MT/s
Manufacturer: Hynix/Hyundai
Serial Number: 33399e81
Asset Tag: Channel-0-DIMM-1-AssetTag
Part Number: HMT451U6AFR8C-PB
Rank: 1
Configured Memory Speed: 800 MT/s
Minimum Voltage: Unknown
Maximum Voltage: Unknown
Configured Voltage: Unknown
Slot numbering in SMBIOS/DMI and memtest is correct from the hardware point of view. The numbering on stickers is RAM population order, not the slot numbering. Two different things.
The numbering on stickers is RAM population order, not the slot numbering.
Thanks for the clarification.
Fix for DIMM locators on NovaCustom laptops: https://github.com/Dasharo/coreboot/pull/663