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

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

 



Hi Jean,
Here is the output you requested

[root:~] # sudo modprobe i2c-i801
[root:~] # sudo i2cdetect -l
i2c-1    i2c           NVIDIA i2c adapter 5 at 1:00.0      I2C adapter
i2c-2    smbus         SMBus I801 adapter at f000          SMBus adapter
i2c-0    i2c           NVIDIA i2c adapter 4 at 1:00.0      I2C adapter
[root:~] # i2cset 2 0x36 0x00 0x00
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will write to device file /dev/i2c-2, chip address 0x36, data address
0x00, data 0x00, mode byte.
Continue? [Y/n] y
Error: Write failed
[root:~] 1 #

& thank you for making these upstream patch(es) for this. Kind regards

On Mon, May 6, 2019 at 10:06 AM Jean Delvare <jdelvare@xxxxxxx> wrote:
>
> On Tue, 23 Apr 2019 17:55:54 +0300, Jarkko Nikula wrote:
> > On 4/19/19 11:31 PM, Jean Delvare wrote:
> > > This was only for testing... I'll post clean patches soon.
> > >
> > > Thanks for testing so quickly, appreciated.
> >
> > Your updated ee1004 driver works here too on 2* and 4* Crucial DIMMs
> > cases. I.e. decode-dimms is detecting them and outputting sensible
> > looking data which was possible before only when both 2* Crucial + 2*
> > Micron DIMMs were plugged in together.
>
> Thank you Jarkko and Dreamcat4 for all the tests so far. As I was about
> to send the patches for upstream inclusion, I noticed that the driver
> doesn't actually use the SMBus command which is mentioned in the EE1004
> specification to select the page. The driver sends one dummy byte after
> the I2C device address, while the specification says to send two dummy
> bytes.
>
> Well, to be honest I can't see from a technical perspective how 2 dummy
> bytes could succeed if 1 dummy byte fails - I assume the NACK is sent
> by the EEPROM after the 1st dummy byte before it has any idea if
> anything is coming next - but to be on the safe side, I would
> appreciate if either of you could try the following command with the
> "failing" setup (2* Crucial):
>
> # i2cset <N> 0x36 0x00 0x00
>
> (where <N> is the I2C bus number of the i2c-i801)
>
> If it still fails they I'll submit what I have. It it does work then
> I'll write a different patch.
>
> Thanks,
> --
> 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