On Mon, Apr 15, 2019 at 12:47 PM Jarkko Nikula <jarkko.nikula@xxxxxxxxxxxxxxx> wrote: > > On 4/12/19 9:42 PM, Jean Delvare wrote: > > On Fri, 12 Apr 2019 19:15:54 +0100, Dreamcat4 wrote: > >> On Fri, Apr 12, 2019 at 3:43 PM Jean Delvare <jdelvare@xxxxxxx> wrote: > >>> > >>> On Thu, 11 Apr 2019 21:08:54 +0100, Dreamcat4 wrote: > >>>> [root:/sys/bus/i2c/devices] # cat /sys/bus/i2c/drivers/ee1004/2-0050/eeprom > >>>> cat: /sys/bus/i2c/drivers/ee1004/2-0050/eeprom: No such device or address > >>>> > >>>> and that command ^ causes this error msg in dmesg log: > >>>> > >>>> dmesg -w > >>>> [12555.445082] ee1004 2-0050: Failed to select page 0 (-6) > >>> > >>> OK, so the problem is that the EEPROMs on your memory modules do not > >>> behave the way the ee1004 driver expects. I thought EE1004 was a > >>> standard for all DDR4 modules... I have no satisfactory explanation for > >>> what you observe. Either Crucial used non-standard SPD EEPROMs, or the > >>> SMBus controller is messing up with the commands before they reach the > >>> EEPROMs. But both are pretty unlikely. > >>> > >>> Out of curiosity, what's your SMBus controller? > >>> > >>> # lspci -nn | grep SMBus > >> > >> [root:~] 6 # lspci -nn | grep SMBus > >> 00:1f.4 SMBus [0c05]: Intel Corporation 200 Series/Z370 Chipset Family > >> SMBus Controller [8086:a2a3] > >> [root:~] # > > > > Jarkko, are you aware of any setting of the Z370 SMBus controller that > > would block writes to I2C address 0x36? I have a vague memory of some > > setting that aimed at protecting SPD EEPROMs but as I remember it was > > only for address range 0x50-0x57. But I don't remember the details to > > be honest. > > > Not sure but specification for SMBus Host Configuration register (0x40) > bit SPD Write Disable (SPDWD) says only 0x50-0x57: > > "When this bit is set to 1, writes to SMBus addresses 50h – 57h are > disabled. Note: This bit is R/WO and will be reset on PLTRST# assertion. > This bit should be set by BIOS to ‘1’. Software can only program this > bit when both the START bit and Host Busy bit are ‘0’; otherwise, the > write may result in undefined behavior." Well that is a very interesting topic indeed. Although was not trying to write or change any data in my ram spd, just only read from it via the supplied program(s) and driver(s). It's still a really good topic to bring up! For those others who do need to modify their SPDs on linux. Although that is not what we were trying to accomplish here. Its still a great idea! To go sideways here and answer the question about that feature (why its disabled, and how to enable!), it seems the people over on windows who writes the Thaiphoon Burner software have already been very helpful. It seems that there are many intel motherboards who disable this bit early in boot time. And the only solution to (re-enable) write access to spd is to modify the manufacturer's BIOS. For AMI based bios, they have kindly provided instructions ilnked below here: http://www.softnology.biz/tips_spdwritecap.html http://softnology.biz/tips_spdwritecap2.html In my own case, we might assume that my motherboard here (asus maximus ix apex) has followed intel's wishes, and has disabled spd writes by setting that bit. And there is probably no exposed BIOS option to prevent that default behaviour. I don't actually have time over here to check, let alone modify the BIOS myself. Since I cannot reboot ATM. However we can guess that it's probably not in the menu. Because it seems they don't want to provide the option. > -- > Jarkko
