Feature #68
closedGM45: Type D DIMMs fail training
0%
Description
The T500 fails to boot using native RAM init with 4GB RAM modules. Log from a failed boot with 2x 4GB DIMMs (note that it also fails with only one 4GB DIMM as well):
coreboot-4.4-1259-gdef0d45-dirty Tue Aug 23 21:40:04 UTC 2016 romstage starting...
running main(bist = 0)
WARNING: Ignoring S4-assertion-width violation.
Stepping B3
2 CPU cores
AMT enabled
capable of DDR2 of 800 MHz or lower
VT-d enabled
GMCH: GM45
TXT enabled
Render frequency: 533 MHz
IGD enabled
PCIe-to-GMCH enabled
GMCH supports DDR3 with 1067 MT or less
GMCH supports FSB with up to 1067 MHz
SMBus controller enabled.
0:50:b
2:51:b
DDR mask 5, DDR 3
Bank 0 populated:
Raw card type: D
Row addr bits: 15
Col addr bits: 10
byte width: 1
page size: 1024
banks: 8
ranks: 2
tAAmin: 105
tCKmin: 15
Max clock: 533 MHz
CAS: 0x01c0
Bank 1 populated:
Raw card type: D
Row addr bits: 15
Col addr bits: 10
byte width: 1
page size: 1024
banks: 8
ranks: 2
tAAmin: 105
tCKmin: 15
Max clock: 533 MHz
CAS: 0x01c0
Trying CAS 7, tCK 15.
Found compatible clock / CAS pair: 533 / 7.
Timing values:
tCLK: 15
tRAS: 20
tRP: 7
tRCD: 7
tRFC: 104
tWR: 8
tRD: 11
tRRD: 4
tFAW: 20
tWL: 6
Changing memory frequency: old 3, new 6.
Setting IGD memory frequencies for VCO #1.
Memory configured in dual-channel assymetric mode.
Memory map:
TOM = 512MB
TOLUD = 512MB
TOUUD = 512MB
REMAP: base = 65535MB
limit = 0MB
usedMEsize: 0MB
Performing Jedec initialization at address 0x00000000.
Performing Jedec initialization at address 0x08000000.
Performing Jedec initialization at address 0x10000000.
Performing Jedec initialization at address 0x18000000.
Timing under-/overflow during receive-enable calibration.
Files
Updated by Nico Huber over 8 years ago
Timothy Pearson wrote:
Raw card type: D
That might be a problem, I can't recall having ever seen anything other
than type F. The code might just be untested on that path. Also comments
in raminit_receive_enable_calibration.c don't mention type D, only A-C
and F while we explicitly probe for A-D and F during SPD; pretty odd.
Timing under-/overflow during receive-enable calibration.
IIRC, the code expects multiple low/high edges in the range of allowed
timings. But it might be just a corner case where an edge is out of
range and we would be fine with approximating it as zero (we had that
problem fixed for read/write training).
Unfortunately the code is very quiet. For a start, please add printks to
the find_* functions in raminit_receive_enable_calibration.c plus a full
trace of the tried timings in program_timing() (like printed in line
262). I'd like to brood over a more verbose log.
Updated by Timothy Pearson over 8 years ago
- File t500_4g_ram_log.txt t500_4g_ram_log.txt added
See attached log. This was only run with 1 DIMM installed to reduce confusion.
Updated by Nico Huber over 8 years ago
Nico Huber wrote:
Timothy Pearson wrote:
Raw card type: D
That might be a problem, I can't recall having ever seen anything other
than type F. The code might just be untested on that path. Also comments
in raminit_receive_enable_calibration.c don't mention type D, only A-C
and F while we explicitly probe for A-D and F during SPD; pretty odd.
I've checked the reference: D isn't handled any different than type A-C.
But it might still be the less tested path.
Timothy Pearson wrote:
See attached log. This was only run with 1 DIMM installed to reduce confusion.
It stops now with
Timing overflow during read training.
Read training failure: lower bound.
So the receive-enable calibration succeeds. Did the behavior change with
the added debug output? Or does it always get that far with only one
module?
Also can you verify if the modules work with the vendor BIOS? If so,
please provide a dump of inteltool -m.
Updated by Timothy Pearson over 8 years ago
- Status changed from New to Rejected
After fighting some with the proprietary BIOS it appears at least one of these modules was either defective or completely unsupported. I am not convinced these laptops support type D modules at all.
Updated by Nico Huber over 7 years ago
- Subject changed from T500 4GB RAM module initialization fails to GM45: Type D DIMMs fail training
- Due date set to 08/13/2017
- Category set to chipset configuration
- Status changed from Rejected to In Progress
- Assignee set to Nico Huber
- Start date changed from 08/24/2016 to 08/10/2017
Stumbled upon two 4GiB type d modules. They fail in two X200s' with coreboot but seem to work (currently running Memtest86+, Test #5 nearly passed) in a X301 (practically same schematics) with vendor firmware. Should prove type d support is possible, thus reopen.
Updated by Nico Huber over 7 years ago
- File corsair-cm3x8gsdkit1066_x200s.log corsair-cm3x8gsdkit1066_x200s.log added
- Tracker changed from Bug to Feature
- Status changed from In Progress to Rejected
Alas, unsupported DIMMs again. The X301 has the same chipset but a processor that limits the FSB (and thereby the RAM too) to 400MHz. But they just don't work (also not with vendor firmware) in an X200 at their rated speed of 533MHz. I've also tried to increase CAS without success. Only thing that seems to work is forcing 400MHz.
For reference this was with Corsair CM3X8GSDKIT1066. Log attached.