linux-kernel - Re: ICM20602 buffer issues with the inv

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 22 May 2019 14:33:44 +0000
From:   Jean-Baptiste Maneyrol <JManeyrol@...ensense.com>
To:     Andreea Lutac <andreea.lutac@...position.ch>
CC:     "stevemo@...dio.com" <stevemo@...dio.com>,
        "jic23@...nel.org" <jic23@...nel.org>,
        "knaack.h@....de" <knaack.h@....de>,
        "lars@...afoo.de" <lars@...afoo.de>,
        "pmeerw@...erw.net" <pmeerw@...erw.net>,
        "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: ICM20602 buffer issues with the inv_mpu6050 driver

Hello,

I had a look inside the driver to verify the buffer implementation. It looks correct to me. I don't see where the problem can come from. I am sorry I don't have a setup currently to test in live.

For sure you can have a different result by reading the buffer through the char device file compared to reading the raw sysfs entry. The buffer is taking the data from the FIFO and the raw sysfs from the sensor data registers.

You can perhaps test value 1 by 1 in the buffer, and verify the correctness of every attributes. If you can also send a complete buffer log that would be helpful.
Every data is 2 bytes long and in the following order: accel_x, accel_y, accel_z, temp, gyro_x, gyro_y, gyro_z

Best regards,
JB Maneyrol

From: Andreea Lutac <andreea.lutac@...position.ch>
Sent: Tuesday, May 21, 2019 12:40
Cc: Jean-Baptiste Maneyrol; stevemo@...dio.com; jic23@...nel.org; knaack.h@....de; lars@...afoo.de; pmeerw@...erw.net; linux-iio@...r.kernel.org; linux-kernel@...r.kernel.org
Subject: ICM20602 buffer issues with the inv_mpu6050 driver

Hello,

I've been trying to get some data samples from the ICM20602 IMU using the mpu6050 driver which recently added support for it, but I'm encountering an issue with the ordering of the data in the FIFO.
According to the specs of the device, if the accel and gyro XYZ channels are enabled, then the hardware FIFO is filled with 14 bytes corresponding to the following channels: accel_x, accel_y, accel_z, temp, anglvel_x, anglvel_y, anglvel_z. However, when reading out the buffer, the value I get for anglvel_x seems to actually be the temperature. This  occurs both when reading with iio_channel_read (via libiio) and also if I read directly from /dev/iio:device with only in_anglvel_x_en set. But in_anglvel_x_raw reports correct values, which made me suspect that maybe somewhere in the driver this interleaved temp channel is not accounted for in the buffer structure.

I had a look at the driver code and inv_mpu6050_read_fifo() in particular, but I can't identify anything amiss. I've applied the recent patch that added the extra 2 temperature bytes ( ), but the problem persists. So far I've tried changing the size of the data buffer, defined in inv_mpu_iio.h:

/* 6 + 6 round up and plus 8 */
#define INV_MPU6050_OUTPUT_DATA_SIZE     24

from 24 to 32, according to the intuition that 24 corresponds to readings without temperature (i.e. 6 bytes for accel, rounded up to 8 + 6 bytes for gyro, rounded up to 8 + 8 bytes for the timestamp = 24) and thus another 8 bytes would be needed, but that doesn't seem to have solved it.

I'm quite new to driver development though, so I think there might be something I'm not getting. I would be really grateful if anyone could shed some light over what's happening here or give some advice as to what I could be doing wrong.

Best regards,
Andreea Lutac