Database Info

[Q] Jelly Bean wifi patch help

As many know, Jelly Bean wifi does not support enterprise wifi.
A fix was posted on the google forum that will hopefully work with the TF300t http://code.google.com/p/android/issues/detail?id=34212#c165
external/wpa_supplicant_8:
diff --git a/src/crypto/tls_openssl.c b/src/crypto/tls_openssl.c
index aaa920b..be94e8a 100644
--- a/src/crypto/tls_openssl.c
+++ b/src/crypto/tls_openssl.c
@@ -929,6 +929,11 @@ struct tls_connection * tls_connection_init(void *ssl_ctx)
#ifdef SSL_OP_NO_COMPRESSION
options |= SSL_OP_NO_COMPRESSION;
#endif /* SSL_OP_NO_COMPRESSION */
+#ifdef ANDROID
+ options |= SSL_OP_NO_TLSv1_1;
+ options |= SSL_OP_NO_TLSv1_2;
+ options |= SSL_OP_NO_TICKET;
+#endif /* ANDROID */
SSL_set_options(conn->ssl, options);
conn->ssl_in = BIO_new(BIO_s_mem());
(note similar patch in wpa_supplicant_6 if your build configuration uses that)
those shouldn't disable WiFi, just limit what TLS versions are used by wpa_supplicant to talk to the server. it should still use TLSv1.0 and SSLv3.0.
My understanding is that you have to apply the patch to the source code and recompile the file. I have no clue how to do this despite a few searches with explanations beyond my abilities. Could someone give me a newb guide on how to do this or uploaded a patched file to fix this common issue?
Many, many thanks!

Is it possible to apply the patch and recompile it in Windows 7? From my searches it seems that you need linux (Ubuntu?) or Mac. If so, can you point me in the right direction?
Thanks!

Sensorhub and Note 2 recovery maintainers

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.

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
Code:
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:
Code:
#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

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.
Phil3759 said:
Either I wait for Samsung to release their sources so that you fix the kernel
Click to expand...
Click to collapse
There is nothing to fix from the live kernel side, I hope you understand that...

AndreiLux said:
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...
Click to expand...
Click to collapse
AndreiLux said:
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.
Click to expand...
Click to collapse
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

Phil3759 said:
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
Click to expand...
Click to collapse
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.
Click to expand...
Click to collapse
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.

delete

[Q] Implement intell_plug

I'm attempting to implement faux123's intelli_plug into my kernel. It was added in this commit and enabled in "make menuconfig". However, it throws me errors during compilation:
Code:
arch/arm/hotplug/intelli_plug.c:166: error: undefined reference to 'avg_nr_running'
arch/arm/hotplug/intelli_plug.c:227: error: undefined reference to 'avg_cpu_nr_running'
make: *** [.tmp_vmlinux1] Error 1
I have reached out prior to this post, but that has gotten me nowhere.
Thanks in advance.

I have the same problem. Did you fix it?

take a look at the commit here:
https://github.com/faux123/android_kernel_oppo_n1/commit/64f86a98a0b70c42dc9d0a875164543b890012f4
i found the solution here and compile worked well
http://forum.xda-developers.com/showthread.php?p=55894825#post55894825
br,
nosedive

That's how you implement Intelliplug 4.0 properly.
https://github.com/olokos/OK-Kernel-Z1-LP/commit/bdda0d6b2edf66734f9a7b2b72797896028fbf16
Please do mention me when you use my commit as it took me a few hours to track down every single intelliplug change (it's spread between three different devices) and then merge it into a single working commit.

Op if it works please release it.

Hello I have the sam eproblem with implementaion of Intelli_plug to Samsung Exynos platform:
the same errors with avg_nr_running - Ive added codes to the core.c but in shed.h I have not the same codes as You have means no for ex. :
Code:
static inline void inc_nr_running(struct rq *rq) - I HAVE NO this function..
{
#ifdef CONFIG_INTELLI_PLUG
struct nr_stats_s *nr_stats = &per_cpu(runqueue_stats, rq->cpu);
#endif
sched_update_nr_prod(cpu_of(rq), rq->nr_running, true);
#ifdef CONFIG_INTELLI_PLUG
write_seqcount_begin(&nr_stats->ave_seqcnt);
nr_stats->ave_nr_running = do_avg_nr_running(rq);
nr_stats->nr_last_stamp = rq->clock_task;
#endif
rq->nr_running++;
#ifdef CONFIG_INTELLI_PLUG
write_seqcount_end(&nr_stats->ave_seqcnt);
#endif
and alwyas I have compilling error .
I put my shed.h file
View attachment sched.h
Thx for any help

Fixing boot on custom kernels support that targets CyanogenMod

I get a lot of question that my custom kernel breaks support their own AOSP-based ROMs.
So I'm here to how to fix that from your side.
The culprit is CyanogenMod's /init.environ.rc.
CM has been messing around that in recent months.
Changing BOOTCLASSPATH does not break cross-compatibility between different AOSP forks, as long as they don't remove stuffs and just adds stuff.
The problem is SYSTEMSERVERCLASSPATH. If any new stuffs are added, Android RunTime will just abort itself and refuse to boot.
And recently, CyanogenMod added Cyanogen Platform API.
That additionally adds /system/framework/org.cyanogenmod.platform.jar to the /init.environ.rc's SYSTEMSERVERCLASSPATH.
That breaks other AOSP-forks that doesn't use Cyanogen Platform API.
So those ROM developers have 3 options.
They can..
1. Just go and use Cyanogen Platform API. Undoubtedly, this would be super hard if your ROM is not already based on CyanogenMod.
2. Ask custom kernel developers to release a separate version just for your ROM. Very unlikely.
3. Solution below.
Most elegant solution I ended up so far is patch your Android RunTime(android_art) to just bypass extra SYSTEMSERVERCLASSPATH.
Just go to art/runtime/native/dalvik_system_DexFile.cc.
Around line 380..
Code:
diff --git a/runtime/native/dalvik_system_DexFile.cc b/runtime/native/dalvik_system_DexFile.cc
index 3298b46..50aa44c 100644
--- a/runtime/native/dalvik_system_DexFile.cc
+++ b/runtime/native/dalvik_system_DexFile.cc
@@ -382,14 +382,6 @@ static jbyte IsDexOptNeededInternal(JNIEnv* env, const char* filename,
// Logging of reason for returning kDexoptNeeded or kPatchoatNeeded.
const bool kReasonLogging = true;
- if ((filename == nullptr) || !OS::FileExists(filename)) {
- LOG(ERROR) << "DexFile_isDexOptNeeded file '" << filename << "' does not exist";
- ScopedLocalRef<jclass> fnfe(env, env->FindClass("java/io/FileNotFoundException"));
- const char* message = (filename == nullptr) ? "<empty file name>" : filename;
- env->ThrowNew(fnfe.get(), message);
- return kUpToDate;
- }
-
// Always treat elements of the bootclasspath as up-to-date. The
// fact that code is running at all means that this should be true.
Runtime* runtime = Runtime::Current();
Remove those 7 lines and your ROM will be now compatible with custom kernels targeting CyanogenMod.
(Git style patch is added for 'git am' command. I'd appreciate it if you maintain Git repository, apply that Git patch for authorship.)
The only problem so far would be that this will break compatibility with Xposed, which replaces Android RunTime thus reverting this modification.

Patching kernel in a module. HELP.

Hello, everyone,
I wrote (I'm writing) an android kernel module to patch a few bytes in kernel code.
I know I can just patch the bytes and boot from it or flash it directly, and I did and it works.
But I wish to put the patches in a kernel module which will be more portable and easier to install/uninstall.
As of now, after the usual module initialization and character device setup, the main code searches for a pattern starting from a function address and resturns the address to patch:
C:
p=kallsyms_lookup_name("ip_forward"); // for example
//printk("The len of %s is: %d\n",data,len );
printk("The address of ip_forward is: %lx\n",p );
printk("The content of %lx is: %lx\n",p,*(unsigned long *)p );
ff=bfind((void *)p,needle,0x1000); // ff contains the address where the patch must be applied, needle contains the bytes to search for.
printk("Found code at: %lx\n",ff);
printk("Code at: %lx\n",(unsigned int)ff[0]); // original code present at address in "ff".
[missing: disable kernel code protection]
ff[0]=0xd503201fd503201f; // two NOPS // commenting this the module works. With this it reboots.
[missing: re-enable kernel code protection]
My test device is running android 12 (4.14.190-perf or 4.14.180-perf kernel version).
Any code present on github that I tested didn't work.
The system reboots as I write the bytes.
Please help.

Zibri said:
Hello, everyone,
I wrote (I'm writing) an android kernel module to patch a few bytes in kernel code.
I know I can just patch the bytes and boot from it or flash it directly, and I did and it works.
But I wish to put the patches in a kernel module which will be more portable and easier to install/uninstall.
As of now, after the usual module initialization and character device setup, the main code searches for a pattern starting from a function address and resturns the address to patch:
C:
p=kallsyms_lookup_name("ip_forward"); // for example
//printk("The len of %s is: %d\n",data,len );
printk("The address of ip_forward is: %lx\n",p );
printk("The content of %lx is: %lx\n",p,*(unsigned long *)p );
ff=bfind((void *)p,needle,0x1000); // ff contains the address where the patch must be applied, needle contains the bytes to search for.
printk("Found code at: %lx\n",ff);
printk("Code at: %lx\n",(unsigned int)ff[0]); // original code present at address in "ff".
[missing: disable kernel code protection]
ff[0]=0xd503201fd503201f; // two NOPS // commenting this the module works. With this it reboots.
[missing: re-enable kernel code protection]
My test device is running android 12 (4.14.190-perf or 4.14.180-perf kernel version).
Any code present on github that I tested didn't work.
The system reboots as I write the bytes.
Please help.
Click to expand...
Click to collapse
Why not just build the kernel from source and including your changes in the new kernel?

Droidriven said:
Why not just build the kernel from source and including your changes in the new kernel?
Click to expand...
Click to collapse
The kernel you get by compiling the sources is NOT the same as the original.
I can apply the patch on the kernel itself (and I did) and it works.
I just want to know how to do what I asked.

Zibri said:
The kernel you get by compiling the sources is NOT the same as the original.
I can apply the patch on the kernel itself (and I did) and it works.
I just want to know how to do what I asked.
Click to expand...
Click to collapse
That may be so, but, a kernel can still be compiled with the modules built-in, they don't "have" to be loaded or installed separately.
But, have it your way.

How you patch it ?

Mr Hassan said:
How you patch it ?
Click to expand...
Click to collapse
I just patched 2 bytes inside the kernel binary and repackaged it.
It works.
But I wish to do a module that patches the running kernel.
To answer your question: READ HERE

Anyone?