Sensorhub and Note 2 recovery maintainers

[AndreiLux]

Please compile, if possible, your embedded recovery kernels without the sensorhub defconfig options.

CONFIG_SENSORS_SSP=y
CONFIG_SENSORS_SYSFS=y
CONFIG_SENSORS_SSP_ACCELEROMETER_POSITION=7
CONFIG_SENSORS_SSP_GYROSCOPE_POSITION=7
CONFIG_SENSORS_SSP_MAGNETOMETER_POSITION=7
CONFIG_SENSORS_SSP_LSM330=y
CONFIG_SENSORS_SSP_CM36651=y
CONFIG_SENSORS_SSP_AK8963C=y
CONFIG_SENSORS_SSP_BMP182=y
CONFIG_SENSORS_SSP_AT32UC3L0128=y
CONFIG_SENSORS_SSP_SENSORHUB=y

The kernel flashes over the sensorhub firmware on every single entry of recovery, and rebooting into the normal kernel, if the embedded kernel firmware mismatches the live hardware firmware. I consider this dangerous because firstly I don't know what happens if a firmware flash fails on boot, and secondly, the whole procedure is done over the I2C bus and takes about 22 seconds, increasing the boot time (and recovery entry) dramatically. The firmware changes relatively often and we have like 4 different versions out there in the wild at this moment and they will surely increase.

Off-topic: The sensorhub is a new dedicated micro-controller chip found on the Note 2 which handles all device sensors, instead of them being handled by the main CPU itself. The point of the thing is to offload that work from the CPU to vastly improve battery life.

 

[Phil3759]

Thank you a lot for the feedback and input about this issue

When compiling recoveries, we get the binary (recovery file) and the kernel. Sorry if I seem noob here, but I do not compile kernels, I am only used to cwm source. And in the recovery binary sources, there is no sensors flashed, it is the kernel that is repacked with it.

Now, if I take a recovery.img as it is outputted when compiled from cm10 sources, that is packed with a cm10 kernel, the recovery will boot without a delay.

However, that will break exfat support since we cannot insmod the external modules

So, the only choice is to repack the recovery ramdisk with a stock Samsung kernel, and that's what I do in my recoveries. However, this seems to induce the boot delay for people using custom kernels built around some sources (redpill, Perseus)

These recoveries repacked with a Samsung kernel will run fine along stock kernels and Note2core custom kernel (also a 4.1.2 source).

One of the potential causes is this part of code I believe (have no Note 2 to debug it)

drivers/sensor/ak8963.c

		if (retry_count < 5) {
			retry_count++;
			pr_warn("############################################");
			pr_warn("%s, retry_count=%d\n", __func__, retry_count);
			pr_warn("############################################");
			goto retry;
		} else {

There is a check routine repeated 5 times, and on each repeat count a goto loop. The retry loop restarts much above in the code
retry:

#ifdef FACTORY_TESTstatic int ak8963c_selftest(struct akm8963_data *ak_data, int *sf){
.
.
.
retry:
	/* read device info */
	i2c_smbus_read_i2c_block_data(ak_data->this_client,
					AK8963_REG_WIA, 2, buf);
	pr_info("%s: device id = 0x%x, info = 0x%x\n",
		__func__, buf[0], buf[1]);

	/* set ATSC self test bit to 1 */
	i2c_smbus_write_byte_data(ak_data->this_client,
					AK8963_REG_ASTC, 0x40);

	/* start self test */
	i2c_smbus_write_byte_data(ak_data->this_client,
					AK8963_REG_CNTL1,
					AK8963_CNTL1_SELF_TEST);

	/* wait for data ready */
	while (1) {
		msleep(20);
		if (i2c_smbus_read_byte_data(ak_data->this_client,
						AK8963_REG_ST1) == 1) {
			break;
		}
	}

	i2c_smbus_read_i2c_block_data(ak_data->this_client,
					AK8963_REG_HXL, sizeof(buf), buf);

	/* set ATSC self test bit to 0 */
	i2c_smbus_write_byte_data(ak_data->this_client,
					AK8963_REG_ASTC, 0x00);

	x = buf[0] | (buf[1] << 8);
	y = buf[2] | (buf[3] << 8);
	z = buf[4] | (buf[5] << 8);

	/* Hadj = (H*(Asa+128))/256 */
	x = (x*(ak_data->asa[0] + 128)) >> 8;
	y = (y*(ak_data->asa[1] + 128)) >> 8;
	z = (z*(ak_data->asa[2] + 128)) >> 8;

	pr_info("%s: self test x = %d, y = %d, z = %d\n",
		__func__, x, y, z);
	if ((x >= -200) && (x <= 200))
		pr_info("%s: x passed self test, expect -200<=x<=200\n",
			__func__);
	else
		pr_info("%s: x failed self test, expect -200<=x<=200\n",
			__func__);
	if ((y >= -200) && (y <= 200))
		pr_info("%s: y passed self test, expect -200<=y<=200\n",
			__func__);
	else
		pr_info("%s: y failed self test, expect -200<=y<=200\n",
			__func__);
	if ((z >= -3200) && (z <= -800))
		pr_info("%s: z passed self test, expect -3200<=z<=-800\n",
			__func__);
	else
		pr_info("%s: z failed self test, expect -3200<=z<=-800\n",
			__func__);

	sf[0] = x;
	sf[1] = y;
	sf[2] = z;

	if (((x >= -200) && (x <= 200)) &&
		((y >= -200) && (y <= 200)) &&
		((z >= -3200) && (z <= -800))) {
		pr_info("%s, Selftest is successful.\n", __func__);
		return 1;
	} else {
		if (retry_count < 5) {
			retry_count++;
			pr_warn("############################################");
			pr_warn("%s, retry_count=%d\n", __func__, retry_count);
			pr_warn("############################################");
			goto retry;
		}

These are many retries using a non efficient goto loop.

Basically, here's the current possibilities I see:
- if we repack the recovery with your kernel or redpill, people will get delay issues on stock ROMs/Kernels
- if we use cm10 kernel: no delays but we loose exfat support
- if we use note2core kernel we'll probably loose exfat support
- if I recompile kernel from samsung sources without the sensors, it seems it will also break exfat

So, at the end I do not see a good choice that will satisfy every one. Either I wait for Samsung to release their sources so that you fix the kernel or I repack with 2 kernels: Samsung stock and redpill, so people can chose

Hope I am not getting it all wrong, but that's how I understand it

 

[AndreiLux]

All that code is totally irrelevant and has nothing to do with the issue. I also don't understand what you want to say about that loop? Goto is inefficient? Nonsense.

The firmware flash and logic happens in /drivers/sensorhub/ssp_firmware.c and its just a few lines of code. The whole flash process is logged in kmsg at boot so you can just retrieve that and see for yourself.

And you're missing the point, as long as you embed ANY kernel with the sensorhub drivers, they will flash it. There are stock kernels out there with versions 91100, 92600, 92800, 102600 (just from the top of my head, might differ). If you use any recovery kernel whose version mismatches the boot.img kernel firmware, you will get the issue.

And to be honest, I don't understand what the fuss is about fixing it, TWRP includes now a kernel with exFat and removed sensor drivers. You just have to do the same.

Either I wait for Samsung to release their sources so that you fix the kernel

There is nothing to fix from the live kernel side, I hope you understand that...

 

[Phil3759]

All that code is totally irrelevant and has nothing to do with the issue. I also don't understand what you want to say about that loop? Goto is inefficient? Nonsense.

The firmware flash and logic happens in /drivers/sensorhub/ssp_firmware.c and its just a few lines of code. The whole flash process is logged in kmsg at boot so you can just retrieve that and see for yourself.

And you're missing the point, as long as you embed ANY kernel with the sensorhub drivers, they will flash it. There are stock kernels out there with versions 91100, 92600, 92800, 102600 (just from the top of my head, might differ). If you use any recovery kernel whose version mismatches the boot.img kernel firmware, you will get the issue.

And to be honest, I don't understand what the fuss is about fixing it, TWRP includes now a kernel with exFat and removed sensor drivers. You just have to do the same.
There is nothing to fix from the live kernel side, I hope you understand that...

Sorry but you're a bit out of bound here with accusing kernel developers and doing such claims about the source of the issue while you seem pretty ignorant about the technical aspects of the problem.




As I said and explained in the thread you linked, the problem lies with the recovery and not the boot kernel. You're the one who will have to adapt your embedded kernel that you include here.

You also seem a bit ignorant about recoveries

TWRP doesn't included any custom kernel with exfat support. It comes with cm9 kernel and maybe now cm10.1 since they moved sources to 4.2 recently. Their source is just the android/bootable/recovery part built around cyanogenmod source. CM kernel, as I said in my answer, doesn't flash the sensors that's why there is no delay. That's the only reason why twrp won't have the delay. I can also include cm10 kernel and no more delays, but say good bye to exfat.

TWRP includes native exfat support where as CM and AOKP choose to not include it in their source (thus cwm) because it is not legal (MS patent). Only thing cwm devs can do:
- import twrp source for exfat support and break the MS patent
- use Samsung genuine kernel to get exfat support

So, not an easy decision / move as you suggest

 

[AndreiLux]

TWRP doesn't included any custom kernel with exfat support. It comes with cm9 kernel and maybe now cm10.1 since they moved sources to 4.2 recently. Their source is just the android/bootable/recovery part built around cyanogenmod source. CM kernel, as I said in my answer, doesn't flash the sensors that's why there is no delay. That's the only reason why twrp won't have the delay. I can also include cm10 kernel and no more delays, but say good bye to exfat.

TWRP includes native exfat support where as CM and AOKP choose to not include it in their source (thus cwm) because it is not legal (MS patent). Only thing cwm devs can do:
- import twrp source for exfat support and break the MS patent
- use Samsung genuine kernel to get exfat support

So, not an easy decision / move as you suggest

Sorry but almost everything you said its wrong.

TWRP includes a modified CM kernel with added exFat and since I've made Bigbiff aware, also removes the sensorhub drivers.

CM kernel, as I said in my answer, doesn't flash the sensors that's why there is no delay.

The CM kernel is based on the Samsung sources and has the flash logic intact, because it's obviously needed in the OS to even have functioning sensors. It's not flashing in your case because you have matching firmwares, and that's all.

Sorry but I suggest you inform yourself here a bit more, I've explained it pretty clearly yet you seem to be ranting about things which are just not correct.

 

[Phil3759]

delete