Project

General

Profile

Actions

Bug #624

open
RN AP

Memory speed in SMBIOS is incorrectly doubled on Haswell

Bug #624: Memory speed in SMBIOS is incorrectly doubled on Haswell

Added by Ron Nazarov about 2 months ago. Updated 16 days ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
chipset configuration
Target version:
Start date:
01/21/2026
Due date:
% Done:

100%

Estimated time:
1.00 h
Affected versions:
Needs backport to:
Affected hardware:
Haswell
Affected OS:

Description

Tested on a Dell Precision T1700 SFF with NRI, my 1600 MT/s (800 MHz) RAM is reported by dmidecode -t 17 as running at 3200 MT/s.

This bug was introduced in https://review.coreboot.org/c/coreboot/+/89598/6. The frequency is doubled in dimm->ddr_frequency = ddr_freq_mhz * 2; /* In MT/s */, however (at least on NRI, I did not test MRC), ddr_freq_mhz (defined as (mchbar_read32(MC_BIOS_DATA) * 13333 * 2 + 50) / 100) is actually in MT/s, and so already doubled.

I also see this in coreboot logs: [DEBUG] memcfg DDR3 clock 1600 MHz. This debug print (added in https://review.coreboot.org/c/coreboot/+/89599/4) is printing DIV_ROUND_CLOSEST(mchbar_read32(MC_BIOS_DATA) * 13333 * 2, 100), which is pretty much the same as ddr_freq_mhz (except using DIV_ROUND_CLOSEST).


Related links

Change that introduced the regression: https://review.coreboot.org/89598

Change that fixes the regression: https://review.coreboot.org/91375

AP Updated by Angel Pons 16 days ago Actions #1

  • Status changed from New to In Progress
  • Related links updated (diff)

AP Updated by Angel Pons 16 days ago ยท Edited Actions #2

  • Related links updated (diff)

Looking back at that code, I should also check if forcing a 100 MHz ref clock results in the wrong speed being reported.

Also, "related links" having such a giant text box tricked me.

AP Updated by Angel Pons 16 days ago Actions #3

  • Category set to chipset configuration
  • % Done changed from 0 to 100
  • Estimated time set to 1.00 h
  • Related links updated (diff)

Looking at https://review.coreboot.org/89598 again, it seems that the bug already existed in the Haswell MRC codepath. The Broadwell MRC codepath did not have this issue, and NRI was N/A since it did not set up memory info until https://review.coreboot.org/89600 landed (which used the code factored out in the change that introduced the regression).

Well, https://review.coreboot.org/91375 fixes this, and also fixes memory frequency reporting when using the 100 MHz reference clock (the code assumed a fixed 133 MHz reference clock). This is the same for all three raminit codepaths (Haswell MRC, Broadwell MRC, NRI), since the encoding of the MC_BIOS_REQ and MC_BIOS_DATA registers is the same.

Will close once the change gets submitted. If I don't forget, heh.

Actions

Also available in: PDF Atom