You have to loosen it on the DRAM, too - you're loosening the tCL on the ASIC, but not the DRAM, throwing them off.
Interesting. So the memory controller (or driver) isn't smart enough to take tCL from SEQ_CAS_TIMING and use same value for MR0 Cas Latency?
edit: I don't even understand how this would work at all. If the controller is expecting the data 22 cycles after the read, but MR0 is programmed for 21, then wouldn't that cause a 100% error rate?
It actually seems to have a tolerance of one value up or down before it stops working entirely.
So I need to update MC_SEQ_MISC1, offset 54 in the hex string of the strap (offset 27 in bytes). Are the 3 hex chars at offset 55-57 the 12 bits for MR0, or is that MR1 and MR0 is 59-61?
I know I could figure it out by comparing different straps and seeing how the bits map to the register values, but since you seem to have already figured it out...
Original Samsung 4G ( your particular GPU ) 1625
555000000000000022CC1C00CE596B44D0570F1531CB2409004AE700 [ 0B03 | 1420 ] 7A8900A003000000170F2E36922A3217
--> MC_SEQ_MISC1
-- MR0
WL = 3, CL = 22, TM = 0, WR = 23, BA0 = 0, BA1 = 0, BA2 = 0, BA3 = 0
-- MR1
DS = 0, DT = 1, ADR = 1, CAL = 0, PLL = 0, RDBI = 0, WDBI = 0, ABI = 0,
RES = 0, BA0 = 0, BA1 = 1, BA2 = 0, BA3 = 0
Original Samsung 4G 1750
777000000000000022CC1C0010626C49D0571016B50BD509004AE700 [ 1405 | 1420 ] 7A8900A003000000191131399D2C3617
--> MC_SEQ_MISC1
-- MR0
WL = 4, CL = 23, TM = 0, WR = 25, BA0 = 0, BA1 = 0, BA2 = 0, BA3 = 0
-- MR1
DS = 0, DT = 1, ADR = 1, CAL = 0, PLL = 0, RDBI = 0, WDBI = 0, ABI = 0,
RES = 0, BA0 = 0, BA1 = 1, BA2 = 0, BA3 = 0
