Re: [decode-dimms] Crucial Ballistix BLS2K16G4D30AESB, cannot decode / understand timings

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Apr 16, 2019 at 5:36 PM Jean Delvare <jdelvare@xxxxxxx> wrote:
>
> On Tue, 16 Apr 2019 15:12:26 +0100, Dreamcat4 wrote:
> > A small further development:
> >
> > Found out there was actually a BIOS setting to enable SPD write after
> > all. Because this is an overclocking board. It was just buried in a
> > mess of menus / almost impossible to find.
> >
> > I enabled the option and rebooted. Unfortunately enabling the SPD
> > write, it did not change any of the bad behaviour.
> >
> > dmesg -w
> > [  147.799024] i801_smbus 0000:00:1f.4: SPD Write Disable is set
>
> Somehow the SPD protection is still enabled. Either the BIOS option is
> doing something else, or you need a cold boot to reset this
> configuration bit.

Thanks for the suggestion... as did not cold boot, just the normal
soft reboot. Anyhow this time i re-checked the setting back in BIOS,
then powered off system at PSU, waited. Then cold boot.

Same thing happened. Dmesg said 'spd write disabled bit = on'

BTW for anyone in future, the setting in question is in Extreme
Tweaker menu, then 'DRAM Timing' sub-menu. Then you scroll down all
the way to very bottom of page. At very bottom. This should be the
same also for certain other ASUS 'ROG' boards. If the option is
present, it should be found there.

Anyhow, one other thing i notices was, if you look at the 3 tables
printed by 'i2cdetect' program below:

[root:/sys/bus/i2c/devices] # ls
i2c-0  i2c-1
[root:/sys/bus/i2c/devices] # modprobe i2c-i801
[root:/sys/bus/i2c/devices] # ls
i2c-0  i2c-1  i2c-2
[root:/sys/bus/i2c/devices] #
[root:/sys/bus/i2c/devices] # i2cdetect 2
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-2.
I will probe address range 0x03-0x77.
Continue? [Y/n] Aborting on user request.
[root:/sys/bus/i2c/devices] # i2cdetect 2
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-2.
I will probe address range 0x03-0x77.
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- 08 -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- 18 -- 1a -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: 30 31 -- -- 34 35 -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- 44 -- -- -- -- -- -- -- -- -- -- --
50: 50 -- 52 -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
[root:/sys/bus/i2c/devices] # echo ee1004 0x50 >
/sys/bus/i2c/devices/i2c-2/new_device
[root:/sys/bus/i2c/devices] # i2cdetect 2
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-2.
I will probe address range 0x03-0x77.
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- 08 -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- 18 -- 1a -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: 30 31 -- -- 34 35 UU UU -- -- -- -- -- -- -- --
40: -- -- -- -- 44 -- -- -- -- -- -- -- -- -- -- --
50: UU -- 52 -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
[root:/sys/bus/i2c/devices] # echo ee1004 0x52 >
/sys/bus/i2c/devices/i2c-2/new_device
[root:/sys/bus/i2c/devices] # i2cdetect 2
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-2.
I will probe address range 0x03-0x77.
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- 08 -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- 18 -- 1a -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: 30 31 -- -- 34 35 UU UU -- -- -- -- -- -- -- --
40: -- -- -- -- 44 -- -- -- -- -- -- -- -- -- -- --
50: UU -- UU -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
[root:/sys/bus/i2c/devices] #
[root:/sys/bus/i2c/devices] # cd ~
[root:~] # ./decode-dimms.new
Cannot read /sys/bus/i2c/drivers/ee1004/2-0050/eeprom at
./decode-dimms.new line 2358.
[root:~] 6 #


See that? The UU was not there before I ran those 2 commands. So it is
almost definately not something else blocking the port. Those UU are
our driver. That is the only new information here. Everything else was
same as before.

dmesg -w output
[  184.468837] i801_smbus 0000:00:1f.4: SPD Write Disable is set
[  184.468874] i801_smbus 0000:00:1f.4: SMBus using PCI interrupt


[  403.633854] ee1004 2-0050: 512 byte EE1004-compliant SPD EEPROM, read-only
[  403.633870] i2c i2c-2: new_device: Instantiated device ee1004 at 0x50
[  419.489437] ee1004 2-0052: 512 byte EE1004-compliant SPD EEPROM, read-only
[  419.489453] i2c i2c-2: new_device: Instantiated device ee1004 at 0x52

[  481.110244] ee1004 2-0050: Failed to select page 0 (-6)





>
> > [  147.799056] i801_smbus 0000:00:1f.4: SMBus using PCI interrupt
> >
> > [  351.051412] ee1004 2-0050: 512 byte EE1004-compliant SPD EEPROM, read-only
> > [  351.051425] i2c i2c-2: new_device: Instantiated device ee1004 at 0x50
> >
> > [  362.268407] ee1004 2-0052: 512 byte EE1004-compliant SPD EEPROM, read-only
> > [  362.268426] i2c i2c-2: new_device: Instantiated device ee1004 at 0x52
> >
> > [  378.888376] ee1004 2-0050: Failed to select page 0 (-6)
> >
> >
> > So my suspicion / hunch is that:
> >
> > * Perhaps this is something missing or broken in the ee1004 driver,
> > that fails with these ASUS motherboards
> >
> > Is it that this ee1004 driver was not used for quite a while? And only
> > came back recently for the DDR4 support. Than maybe that would make
>
> The ee1004 driver is specific to DDR4 memory. It has been developed in
> November 2017 and went upstream in October 2018 (v4.20). It probably
> has not seen too much testing so far.
>
> > some sense. And if ASUS was not specifically tested as a hardware
> > configuration. Could be doing some strange thing perhaps. Standing
>
> Asus was not tested by me. I know at least one more user but I don't
> know on what hardware.
>
> > in-between mapping the smbus to access the RAM. It's just a hunch.
> > Really I have no idea! Best guess.
>
> I'm at the same point.
>
> --
> Jean Delvare
> SUSE L3 Support



[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux