Database Info

[09/01/09] Android - Polaris Userspace and Testing thread

*** PLEASE READ CAREFULLY BEFORE INSTALLING OR FLASHING ANY SOFTWARE POSTED IN THIS THREAD ***
The software posted here is for TESTING purposes only, The Polaris Android Linux development team or any of the posters of software or links to software on this thread, take absolutely no responsibility or liability for damage caused by the result of installing or flashing software or links to software found on this thread - correctly or otherwise, you do so on the sole understanding that you do so at your own risk.
Previous thread was closed because too big you can find lot of information into it with the search button : http://forum.xda-developers.com/showthread.php?t=555000
Hello to all of you, Android user.
This thread is the right place to talk about non-kernel related discussions, questions and requests.
Please, remember that the thread is public, so don't use bad word
So...have fun
-------------------------------------------------------------------------------------------------------------------------------
01-09-09 - new link to files for working wifi
http://www.4shared.com/dir/19593527/...a/sharing.html
From Google Code Vogue-Android:
01-09-09 - Initrd - works with unpartitioned cards, otherwise no changes.
01-09-09 - Rootfs - works with unpartitioned cards, otherwise no changes.

Reserved for future use

Reserved for future use.

Reserved for future use,

Reserved for future use-

what packages do i have to dload? everything?

nicandris said:
what packages do i have to dload? everything?
Click to expand...
Click to collapse
From the first link (4share), you took all but rootfs and initrd, these one you could download it from the other links

You should put name Android in the title to know about what is this thread

whitealien said:
You should put name Android in the title to know about what is this thread
Click to expand...
Click to collapse
Thanks for the suggestion

@Mormy
Could you give us your startup/default haret script? With script whitch you uploaded to 4shared, graphics don't work properly.

Good thing to open a clean thread to speak about testing
I'm currently testing the SquashFs version, latest on http://code.google.com/p/vogue-android/downloads/list
With this system.sqsh : http://vogue-android.googlecode.com/files/hero.zip
And this base files : http://vogue-android.googlecode.com/files/squashfsbasefiles.zip
It's very stable. With this build I haven't got anymore the 'reload UI' problem when I go back to home screen.
But it's very slow. It takes more time to launch application, wake up the phone, open settings... But the scrolling is normally fast.
Wifi doesn't work for me with it.
Maybe I'll try this one tonight : system-090109r1.img on http://code.google.com/p/vogue-hero/downloads/list
I didn't understood how works the last one with 'userinit.sh' system, so I think I will not try it

Averne said:
@Mormy
Could you give us your startup/default haret script? With script which you uploaded to 4shared, graphics don't work properly.
Click to expand...
Click to collapse
I've tried Neocore and won't start either with the 4share startup and with mine.
By the way, this the one I usually have:
Code:
set RAMSIZE 0x08000000
set MTYPE 1723
set KERNEL zImage
set initrd initrd.gz
#
# The following kernel parameters are useful
# ppp.username - The username used to connect to the network when dialing
# ppp.password - The password used to connect to the network when dialing
# ppp.apn - Set apn of your provider
# ppp.nostart - Set ppp.nostart=1 to disable starting the ppp connection on boot
# msm_sdcc.msmsdcc_fmax - The maximum frequency (in Hz) used by the SD controller
# pm.sleep_mode - The mode used when the phone is off
# 0=Power Collapse Suspend, 1=Power Collapse, 2=Apps Sleep,
# 3=Slow Clock and Wait for Interrupt 4=Wait for Interrupt
# Default is 1, use 1 for best power savings
# board-htcpolaris.panel_type - Panel type used to power the panel off and on
# 0=Don't power off the panel (Default)
# 1=Sony 2=Topoly 3=Topoly (probably just the same as 2)
# lcd.density - Defaults to 160, 128 shows more on screen
#
set cmdline "board-htcpolaris.panel_type=3 ppp.apn=tre.it ppp.username=none ppp.password=none pm.sleep_mode=1 mddi.width=324 mddi.height=432 no_console_suspend board-htcpolaris-battery.battery_capacity=1350 clock-7x00.mddi=0xa51 mddi_client_vogue.vsync=0"
boot

Averne said:
@Mormy
Could you give us your startup/default haret script? With script whitch you uploaded to 4shared, graphics don't work properly.
Click to expand...
Click to collapse
Try with '1' instead of '3' for "board-htcpolaris.panel_type" property.

Averne said:
@Mormy
Could you give us your startup/default haret script? With script whitch you uploaded to 4shared, graphics don't work properly.
Click to expand...
Click to collapse
if you mean neocore then yes that is broken in this kernel.
if you are having display issues, then try changing the panel type or try to be more specific on what you mean by "graphics dont work properly".

Ok, this is my default.txt file:
Code:
set RAMSIZE 0x08000000
set MTYPE 1723
set KERNEL zImage
set initrd initrd.gz
set cmdline "board-htcpolaris.panel_type=0 ppp.apn=orange ppp.username=orange ppp.password=orange pm.sleep_mode=1 mddi.width=336 mddi.height=448 lcd.density=160 no_console_suspend board-htcpolaris-battery.battery_capacity=1350 mddi_client_vogue.vsync=0"
boot
With this settings display works fine, but you must disconnect usb cable before press [Run] button in haret.

Hi ,
with the last files taken from bally site I have wifi working but data connection li ke previous release taken from vogue-android sometime starts sometimes no.
And with this files I can't start calling it creashes.
No Gps..
Why start up logo is changed? and button mapping?

Averne said:
Ok, this is my default.txt file:
Code:
set RAMSIZE 0x08000000
set MTYPE 1723
set KERNEL zImage
set initrd initrd.gz
set cmdline "board-htcpolaris.panel_type=0 ppp.apn=orange ppp.username=orange ppp.password=orange pm.sleep_mode=1 mddi.width=336 mddi.height=448 lcd.density=160 no_console_suspend board-htcpolaris-battery.battery_capacity=1350 mddi_client_vogue.vsync=0"
boot
With this settings display works fine, but you must disconnect usb cable before press [Run] button in haret.
Click to expand...
Click to collapse
why have you got lcd density set at 160 and width and height at 336x448?
this is not my startup file. you should try that first.

Does somebody know what are the benefits of using 'squash FS' system instead of old standard system.img?

Kiiv said:
Does somebody know what are the benefits of using 'squash FS' system instead of old standard system.img?
Click to expand...
Click to collapse
if you are really interested: (from http://groups.google.com/group/andr...ad/e4ce4f06f982d51b/30fa2b5deb6533b2?lnk=raot)
I think it would be a good idea to compress /system/bin and /system/
lib at least with squashfs, I have done this on a couple ubuntu and
gentoo systems and it actually increased performance and space
significantly!
Reasons (short version): decompressing data is faster than reading it
from the hard drive, in most current computers, especially when you
have multiple programs reading from the disk, causing thrashing, and/
or when the data on the disk is fragmented. You can read more details
about what was done and the results on http://forums.gentoo.org/viewtopic-p-4732709.html#4732709
Squashfs is intended for general read-only file system use and in
constrained block device/memory system, it can also be combined with a
union mount system like unionfs and aufs for read/write access.
We will be able to improve android boot time, app launch time, and
increase space, what more could we ask for? Maybe a little bit more
ram? Whats up with compcache too?
So now we just need to compile squashfs-tools for android and
experiment, im pretty damn excited to try this!
Also ubifs has lzo compression, not sure how that would work either,
it seems ubifs is favored over jffs2 and yaffs2
Well right now it looks squashfs+lzma wont be in the kernel until
2.6.30 found this via:
http://www.squashfs-lzma.org/
So I think we are left with UbiFS with lza compression but I have no
idea on how to add it to the kernel, and test this out, im really
interested in seeing some results and doing some benchmarks, if
someone more knowledgeable than me can help out that would be awesome
defcon
found a nice pdf comparing the filesystems:
http://free-electrons.com/doc/flash-filesystems.pdf
Benchmarks Of Yaffs2, JFFS2, SquashFS, & UBIFS:
http://free-electrons.com/pub/conferences/2008/elce/flash-filesystems...
Seems like people are already using ubifs on android:
http://groups.google.com/group/android-porting/browse_thread/thread/a...
Reference:
http://forums.gentoo.org/viewtopic-p-4732709.html#4732709
http://jt0.org/news/squashing_usr_and_the_2629_kernel

Hum, thank you for the link
So I don't understand why it's slower with squash FS on my phone... I will try to find other discussions on the subject.

BaCeM-TWEAK, Kernel Module for enable UV and Governor

sgy kernel have some issue related with cpu frequency.
first, cpu latency is not set correctly. the effect, non build-in freq governor can not working at all.
second, missing frequency table so cpu freq stat is not working. that bug make cpu spy (and other similar app) not working.
so, i write small loadable kernel module to solve that issue. i make my tweks as module so it can works with stock kernel. and for addition, i add under-voltage capability.
download and flash zip file in recovery mode. you can edit init.d script (00bacem-tweak) to change under-voltage.
if your device become unstable make both voltage higher, but keep it under stock kernel default value. i am not responsible to anything happen on your phone so be careful when tweak that value.
before install latest version (0.2), if you already install old version, flash bacem-remove-0.2.zip from recovery mode. and then flash bacem-tweak-0.2.zip
warning : it's not for noob (in real life)
to change uv manually run from terminal
Code:
echo -20mV > /proc/sys/bacem/volt/cpu
and to check if your under-voltage success
Code:
cat /proc/sys/bacem/volt/cpu
Source code
https://github.com/irfanbagus/BCM-tweak
BaCeM-tweak under bacem branch.
Build :
BCM-tweak 0.1
- Initial release
BCM-tweak 0.1.1
- Fix init.d script
- Add interactive governor
BaCeM-tweak 0.2
- Change name to BaCeM-tweak
- Support more than 2 freq
- Auto detect (and auto fix) missing cpufreq table
- Using sysctl to control under-voltage
- Real-time under-voltage. no need to unload module to change uv, and no need change frequency to apply under-voltage
BaCeM-tweak 0.2.1
- Apply workaround for instability on stock rom using init.d script. Not beautiful solution but at least it's work.
- Fix bug in memory allocation
- Fix for potential incompatibility with merruk kernel

Can use cygwin? If can maybe i will try.
Thanks for another work again and must follow.

I'd like to help but I'm completely newb in android and linux stuffs.

no need installed linux. using adb shell or ssh is enough. the reason i am not release yet because uv. without proper knowledge you could make your sgy over voltage easily.

i put source code in gitub
https://github.com/irfanbagus/BCM-tweak
and since nobody pm me, then i will test by myself. maybe need 1-2 days until i release binary build.

okay.. i think the CPU frequency table isn't going to be an easy job.
BCM21553 only allows x13 cpuspeed multipler on your thread about setcpu fix.. maybe..

ARVolutionz said:
okay.. i think the CPU frequency table isn't going to be an easy job.
BCM21553 only allows x13 cpuspeed multipler on your thread about setcpu fix.. maybe..
Click to expand...
Click to collapse
that the easiest part. ok, not real table but enough to make governor working. and because it's still using stock kernel, only 312mhz and 832mhz available. i am working on recovery zip file right know. i will upload in few next hour.

i already upload kernel module binary and init.d script. check first post. as soon as you find problem, disable init.d script and please report. i am not include custom governor yet. i already build ondemand, but it's make ui become lag so i am not include in zip file. tomorrow i will try to build interactive governor.
[edit]
just in case your phone failed to boot, use file in attachment to remove bcm-tweak. use from recovery mode.

I've changed the voltage value but both nofrills and antutu said that the frequencies are not changed. still showing 832 and 312mhz. the performance score indeed increased but how could we know that the module is really working or not?

kurotsugi said:
I've changed the voltage value but both nofrills and antutu said that the frequencies are not changed. still showing 832 and 312mhz. the performance score indeed increased but how could we know that the module is really working or not?
Click to expand...
Click to collapse
i think because still use stock kernel with same freq and from 1st post its only change voltage. maybe can see the different with app that can show our voltage before and after use bcm-tweak.
In init.d/00bcm-tweak what efect if you change echo 312000 to echo 600000 or else number?

kurotsugi said:
I've changed the voltage value but both nofrills and antutu said that the frequencies are not changed. still showing 832 and 312mhz. the performance score indeed increased but how could we know that the module is really working or not?
Click to expand...
Click to collapse
savie said:
i think because still use stock kernel with same freq and from 1st post its only change voltage. maybe can see the different with app that can show our voltage before and after use bcm-tweak.
In init.d/00bcm-tweak what efect if you change echo 312000 to echo 600000 or else number?
Click to expand...
Click to collapse
it does not change frequency and it should not give improvement to performance. its only effect 3 things : cpu voltage, cpu freq statistic, and cpufreq latency (only the number, not actual latency). to check if module loaded, make sure folder "/sys/module/bcm_tweak" exist.
be careful when change voltage, don't set too low. to see if voltage control is working, i try to change voltage 1V and it's successfully to ... death no error, no restart only stop working and i have to pull out battery to restart my phone.

irfanbagus said:
it does not change frequency and it should not give improvement to performance. its only effect 3 things : cpu voltage, cpu freq statistic, and cpufreq latency (only the number, not actual latency). to check if module loaded, make sure folder "/sys/module/bcm_tweak" exist.
be careful when change voltage, don't set too low. to see if voltage control is working, i try to change voltage 1V and it's successfully to ... death no error, no restart only stop working and i have to pull out battery to restart my phone.
Click to expand...
Click to collapse
Well that speaks that this is absolutely working, right?
Still observing it
Sent from my GT-S5360 using xda premium

I'm afraid the init.d script didn't work. I can't find bcm_tweak in /sys/module/. this is what I do to make it work. I edited '#!/system/xbin/busybox sh' to '#!/system/bin/sh' and 'bcm-tweak.ko' to 'bcm_tweak.ko', rename the ko file as in init.d script, reboot.

@ irfanbagus;
Can you share your custom kernel

kurotsugi said:
I'm afraid the init.d script didn't work. I can't find bcm_tweak in /sys/module/. this is what I do to make it work. I edited '#!/system/xbin/busybox sh' to '#!/system/bin/sh' and 'bcm-tweak.ko' to 'bcm_tweak.ko', rename the ko file as in init.d script, reboot.
Click to expand...
Click to collapse
sound like busybox applet problem. can you do this for me ? run in terminal
Code:
/system/xbin/busybox
and see if your busybox has build-in command "sh" and "insmod". i'll try to fix it tonight
premolikeshtc said:
@ irfanbagus;
Can you share your custom kernel
Click to expand...
Click to collapse
this is my 'custom kernel'

I want the boot.img,,

my busybox version doesn't have sh but it does have insmod. I forgot the version its 1.17 or something. I'm not sure if the newer one have sh. and btw, we already have insmod in /system/bin.

Work great.
Result with antutu after restart use bcm21553
1.non bcm-tweak 1375
2.bcm-tweak 1560
Result with antutu after restart use performance
1.non bcm-tweak 1572
2.bcm-tweak 1573
Still on original number not change anything in 00bcm-tweak file

@prem:
http://forum.xda-developers.com/showthread.php?t=1620243 --> kernel bootscript
http://forum.xda-developers.com/showthread.php?t=1598803 --> kernel dualboot
http://forum.xda-developers.com/showthread.php?t=1545930 --> ext4 modules for kernel

Thanks a lot
---------- Post added at 07:45 PM ---------- Previous post was at 07:43 PM ----------
Which governor is working actually ?

[ROOT][SECURITY] Root exploit on Exynos

EDIT: For general discussion about this topic, please post in the following location (and not here): http://forum.xda-developers.com/showthread.php?t=2057818
Now find a one-click root application at http://forum.xda-developers.com/showthread.php?t=2130276. More exploits coming.
Hi,
Recently discover a way to obtain root on S3 without ODIN flashing.
The security hole is in kernel, exactly with the device /dev/exynos-mem.
This device is R/W by all users and give access to all physical memory ... what's wrong with Samsung ?
Its like /dev/mem but for all.
Three libraries seems to use /dev/exynos-mem:
/system/lib/hw/camera.smdk4x12.so
/system/lib/hw/gralloc.smdk4x12.so
/system/lib/libhdmi.so
Many devices are concerned :
Samsung Galaxy S2
Samsung Galxy Note 2
MEIZU MX
potentialy all devices who embed exynos processor (4210 and 4412) which use Samsung kernel sources.
The good news is we can easily obtain root on these devices and the bad is there is no control over it.
Ram dump, kernel code injection and others could be possible via app installation from Play Store. It certainly exists many ways
to do that but Samsung give an easy way to exploit. This security hole is dangerous and expose phone to malicious apps.
Exploitation with native C and JNI could be easily feasible.
Edited
Some details :
/dev/exynos-mem seems to be used for graphic usage like camera, graphic memory allocation, hdmi.
By activating pid display in kmsg, surfaceflinger do mmap on the device (via one of the three shared libraries above ?? I have not see reference in binary to these libraires)
The operations allowed on the device are (from linux/drivers/char/mem.c) :
Code:
static const struct file_operations exynos_mem_fops = {
.open = exynos_mem_open,
.release = exynos_mem_release,
.unlocked_ioctl = exynos_mem_ioctl,
.mmap = exynos_mem_mmap,
}
and the default permissions (from linux/drivers/char/mem.c) :
Code:
#ifdef CONFIG_EXYNOS_MEM
[14] = {"exynos-mem", S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH
| S_IWOTH, &exynos_mem_fops},
#endif
ioctl request on /dev/exynos-mem permit to clean / flush L1 and L2 cache, set non cacheable page memory and set physical memory address for use with mmap.
Now the interesting part : mmap operation.
The only limit is to restrict access to lowmem (from linux/drivers/char/exynos-mem.c) :
Code:
/* TODO: currently lowmem is only avaiable */
if ((phys_to_virt(start) < (void *)PAGE_OFFSET) ||
(phys_to_virt(start) >= high_memory)) {
pr_err("[%s] invalid paddr(0x%08x)\n", __func__, start);
return -EINVAL;
}
The comment in above code could be frightening.
And an eye in Documentation/arm/memory.txt say :
Code:
Start End Use
--------------------------------------------------------------------------
PAGE_OFFSET high_memory-1 Kernel direct-mapped RAM region.
This maps the platforms RAM, and typically
maps all platform RAM in a 1:1 relationship.
In other words, this device only permit to own the physical memory including kernel code.
The question is why permissions are set to read/write for all in kernel AND in ueventd.smdk4x12.rc:
samsung developper in charge of this would lose his job
some samsung apps with basic rights need to access it (I doubt it)
a huge mistake
A simple patch could be to set permissions to 0660 or 0600 in ueventd.smdk4x12.rc, but I don't know how it would affect samsung applications/services.
In attachment, binary and source to obtain for root shell.

Removing either read or write permissions will kill the camera. I didn't see any other deterioration in anything else.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
My guess the best fix would be to limit the access to the DMA memory spaces which this thing actually needs, the definition of the different CMA areas are in /arch/arm/mach-exynos/mach-midas.c for the S3 and N2.
Front camera for example:
Code:
#ifndef CONFIG_USE_FIMC_CMA
{
.name = "fimc1",
.size = CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC1 * SZ_1K,
#if defined(CONFIG_MACH_GC1)
.start = 0x5ec00000,
#else
.start = 0x65c00000,
#endif
},
#endif
Generally all memory areas allocated through s5p_cma_region_reserve in /arch/arm/plat-s5p/reserve_mem.c would be treated as exceptions and everything else needs to be blocked.
Update: Low-level kernel fix for developers posted here.
A kernel based fix as I posted above is the only method to fix the security hole while also not breaking the camera. In all other cases if you are not able or willing to flash a kernel, use Chainfire's application.

Very interesting. Thanks for bringing that up. (Have also flagged some Samsung engineers to read this)
Also, I'm building an APK for this to make it easy.
EDIT: APK posted here: http://forum.xda-developers.com/showthread.php?t=2050297, download, install, run, and your device is rooted with SuperSU.
EDIT#2: This app now also lets you disable the exploit

@alephzain thanks for sharing the source code of the exploit: short, elegant, efficient, to me that's art
Your short documentation and clean writing style even made easier to learn from it.

Hey curio,
No need, here is a very quickly put together app in 5 mins that lets you toggle on/off world writability to /dev/exynos-mem
So you can toggle the fix off if you want to use the camera, then toggle it back on afterwards.
Github source: https://github.com/Ryan-ZA/exynosfix
APK Download: https://github.com/Ryan-ZA/exynosfix/raw/master/exynosfix.apk
Ryan
MOD EDIT: Removed attached download, as it is out of date compared to the linked download

jcase said:
Please explain how this is a remote exploit? This looks entirely local to me. Vulns happen, every vendor gets hit with them. Google does, Apple does Motorola does, HTC does, LG does, Samsung does, ASUS does, Nvidia, Qualcomm etc etc, it is all part of the game. Hell go look at the recent qualcomm disclosures, almost every qualcomm since 2009, wide open! Sh*t happens. Any device with root on it, be it exploit or whatever is open to permanent damage from malicious, want to nuke an htc with root? dd if=/dev/zero of=/dev/block/mmcblk0p4. Pantech/LG/Mostqualcoms hit all the bootloaders. Hell system user is enough on LG phones, and most other brands to brick them.
I'm not sure about rewards, but I have reported vulns and bugs to every major vendor, and the only three who ever respond to me are Google, Samsung and Motorola. All three respond promptly and polite, and occasionally follow up if requested. Vendor not getting back to you? [email protected] is quite good at getting them to respond, just tell them the vendor is not responding. More than once they have gotten a dialog with a vendor opened with me.
Understanding update timelines is another issue, vendor updates generally have to go through development, QA at the vendor (sent back if major issues found), then in the case of Sprint and other carriers, sent to carrier QA (returned to OEM if major issues found) . Major changes to the radio? Yep off to the FCC as well! Updates can take considerable time. Not excusing the "superbrick" bug, just pointing out a few weeks (or in the case of sprint or Vernon a few months) can be expected. Want faster updates? Buy an international device, and get a GSM carrier.
Click to expand...
Click to collapse
OK, we're getting into technicalities here, but I consider anything that can be exploited by a Market app without explicit user intervention beyond installing an app (reboot cycles, ADB, etc.) to be "remote". Adam covered how easy it is to bypass Bouncer at BABBQ, so relying on that is a bad idea.
Prior to this, all exploits (restoreRoot, mempodroid, etc) for ICS on Exynos4 devices required ADB to be involved. This doesn't.
And no, you can't cause permanent damage to an HTC with root. The example you provided isn't permanent damage, it can be repaired via JTAG at a service center. Superbrick is *permanent unrecoverable damage that requires a motherboard replacement - JTAG cannot bring a device that has been damaged back to operation*. That's a difference between 0 material costs and maybe 30 minutes of labor to repair at a service center and $200-300+ in material costs and significantly more labor.
And your "updates take considerable time" is bull****. Sprint FI27 was built on September 27 (check the kernel build date), 3 weeks after Samsung had the final version of their protection patch, and was deployed on Kies a matter of *days* later. They had an update scheduled, a patch ready to go for three weeks before the update was built, and they shipped without the patch. There's no excuse for that. At that time, it was an "open source problem" because it only affected custom firmwares, and any root exploits known required ADB. Their approach was dependent on an assumption that *an exploit like this would never happen* - which is a horrible assumption.
This exploit changes things - there is no a root exploit that can be used by an app straight from the market, in the background, with little to no user intervention.
As to the negative effects of 600 permissions on operation (such as killing camera) - as an interim, setting things to 660 instead of 666 makes things somewhat better protected but not as protected as they should be. I will run some tests later today to confirm that at least any old APK can't get privilege elevation if things are set so only the graphics group can diddle with the memory regions.

RyanZA said:
Hey curio,
No need, here is a very quickly put together app in 5 mins that lets you toggle on/off world writability to /dev/exynos-mem
So you can toggle the fix off if you want to use the camera, then toggle it back on afterwards. Will update this post shortly with github source.
Ryan
Click to expand...
Click to collapse
Yes what I also started writing allows to restore permissions on /dev/exynos-mem in case you need to use camera, I agree its useful!

fards said:
Camera is insisting on 666 on some builds.
Curious how some devices using same base code are using camera with diff permissions.
Neither my N7000 or N 8010 will play nicely with 600 or 660..
Click to expand...
Click to collapse
The assumption of similar base code isn't a good one... You'd be shocked how many deltas there are between I9100/I777/N7000 stock firmware codebases that shouldn't be there given how similar the devices are.
In the region of the system we're dealing with here (graphics memory allocation), there are significant differences in operation between Exynos 4210 and 4412. There are also significant deltas between the implementations in all of Samsung Mobile's devices and the official public reference source, and frequently deltas between Samsung's implementations for various handsets/tablets that shouldn't be there as you've discovered.
For example, the official reference source does allocations from FIMC1 memory regions in gralloc to support various graphics items. Nearly all of Mobile's implementations allocate ION memory instead of FIMC1 memory even when FIMC1 memory is requested (and yes, this change affects camera operation more than anything else.)
Thanks for the headsup on N80xx, I'll def. have to do a rebuild on N8013. It's pretty frequent for us to have brokenness that doesn't exist on I9300 and vice versa.

Hmm, odd... even when chmodded 660 system.graphics, the exploit appears to succeed on CM10.1 from within an ADB shell...
I need to look more closely at this.
Seems like the shell user is a member of the graphics group...
I think AndreiLux's approach he's working on may be the best.
Has anyone tested to see what the effect of 0600 is on hwaccel video playback? (Seems to be none on CM10.1).
Looks like it's anything that wants FIMC memory that needs exynos-mem, I'll double check ION, that should have failed...
Edit: Yeah, gralloc only accesses exynos-mem when attempting to access FIMC1 memory. I think camera is the main other place where FIMC is used. Actually, in any shipped handset, gralloc should never actually access exynos-mem - gralloc will give ION memory when you ask it for FIMC1 memory, and ION memory allocation doesn't use exynos-mem (hmm, unless libsecion does... I need to check that...)

Entropy512 said:
Hmm, odd... even when chmodded 660 system.graphics, the exploit appears to succeed on CM10.1 from within an ADB shell...
I need to look more closely at this.
Seems like the shell user is a member of the graphics group...
I think AndreiLux's approach he's working on may be the best.
Click to expand...
Click to collapse
Because your shell is in graphics group.

supercurio said:
Because your shell is in graphics group.
Click to expand...
Click to collapse
I was beginning to suspect that, thanks for confirming.
dennis.l said:
if this is a Samsung kernel issue would any of the custom kernel have the same flaws? otherwise would I be able to workaround the problem by installing a CM10 ROM instead of stock?
Click to expand...
Click to collapse
Right now older custom kernels will. CM's codebase was just patched earlier today to restrict that node to system.graphics 0660
It was done in the 10.1 branch, so it won't immediately affect all devices. We're working on transitioning all exynos4 devices over to 10.1 this week - it's about halfway done.

@alephzain, when running the exploit in an adb shell, sometimes the privilege escalation fails with:
Code:
[*] s_show->seq_printf format string found at: 0xC07A70A8
[*] sys_setresuid found at 0xC00945A0
[*] patching sys_setresuid at 0xC00945E4
[!] set user root failed: Operation not permitted
And it typically succeed after 1 or 2 more attempts.
Does it ring a bell?

ExynosAbuse APK updated to v1.10
I've just updated the ExynosAbuse APK to v1.10 !
This version allows you to disable the exploit (which may break camera), re-enable the exploit (if you need the camera) and to disable the exploit at boot (before any Android app runs). These options do require root (SuperSU or Superuser) to be installed as well. This is for people who actually *want* root. If you don't want root, you should use Supercurio's solution as it doesn't depend on being rooted it for dis/reenabling the exploit.
http://forum.xda-developers.com/showthread.php?t=2050297

Voodoo Instant fix for Exynos Mem Abuse vulnerability released.
I'm glad I have a blog, because things tend to disappear here ^^
Edit: Please use the following thread to discuss this specific solution: http://forum.xda-developers.com/showthread.php?t=2051290

RyanZA said:
Hey curio,
No need, here is a very quickly put together app in 5 mins that lets you toggle on/off world writability to /dev/exynos-mem
So you can toggle the fix off if you want to use the camera, then toggle it back on afterwards.
Github source: https://github.com/Ryan-ZA/exynosfix
APK Download: https://github.com/Ryan-ZA/exynosfix/raw/master/exynosfix.apk
Ryan
Click to expand...
Click to collapse
As per requests, I added in 'fix vulnerability on boot' functionality for those who like an open source fix.
Nice work on that app, curio.

Sooooo....
Here's a low-level fix for the kernel.
Source @ https://github.com/AndreiLux/Perseus-S3/commit/fb36195dab87e002721c7d1a8294a400c6b40a71
Edit: Follow-up commit for Note 2 (Possibly N8000 too) users @ https://github.com/AndreiLux/Perseus-S3/commit/81c95f6046880be48ef377ebae4e42c791f0813e
I did what I said in the first post. The mmap function checks the given memory addresses against all of the current CMA memory spaces on the device and denies access if the space it out of bound of any of the defined blocks. Furthermore on my S3 I, for now, couldn't find anything breaking beyond the main camera. So I added an additional condition that checks that the accessed memory block is "s3c-fimc" (The camera DMA block) and ignores the other blocks. The whole thing is totally neutered if CONFIG_CMA_DMA isn't used in the device configuration (Note 2 / Exynos 4412 devices with 2GB RAM). Edit: Fix works now the same for all devices.
Defined memory spaces:
Code:
[ 0.000000] c0 cma: CMA: reserved 16 MiB at 65800000
[ 0.000000] c0 [cma_region_descriptor_add] adding [s3c-fimc] (0x65800000)-(0x00f00000)
[ 0.000000] c0 cma: CMA: reserved 40 MiB at 5c800000
[ 0.000000] c0 [cma_region_descriptor_add] adding [s3c-mfc] (0x5c800000)-(0x02800000)
....
....
[ 0.000000] c0 S5P/CMA: Reserved 0x70000000/0x00a00000 for 'fimc_is'
[ 0.000000] c0 [cma_region_descriptor_add] adding [fimc_is] (0x70000000)-(0x00a00000)
[ 0.000000] c0 S5P/CMA: Reserved 0x71700000/0x00800000 for 'fimd'
[ 0.000000] c0 [cma_region_descriptor_add] adding [fimd] (0x71700000)-(0x00800000)
[ 0.000000] c0 S5P/CMA: Reserved 0x6c300000/0x03d00000 for 'fimc0'
[ 0.000000] c0 [cma_region_descriptor_add] adding [fimc0] (0x6c300000)-(0x03d00000)
[ 0.000000] c0 S5P/CMA: Reserved 0x71600000/0x00100000 for 'srp'
[ 0.000000] c0 [cma_region_descriptor_add] adding [srp] (0x71600000)-(0x00100000)
[ 0.000000] c0 [cma_region_descriptor_add] adding [mfc-normal] (0x64000000)-(0x00400000)
[ 0.000000] c0 S5P/CMA: Reserved 0x64000000/0x00400000 for 'mfc-normal'
[ 0.000000] c0 [cma_region_descriptor_add] adding [mfc-normal] (0x64000000)-(0x00400000)
[ 0.000000] c0 S5P/CMA: Reserving 0x6800000 for secure region aligned by 0x4000000.
[ 0.000000] c0 S5P/CMA: Reserved 0x5c000000/0x06800000 for 'secure_region'
[ 0.000000] c0 S5P/CMA: Reserved 0x5c000000/0x00800000 for 'sectbl'
[ 0.000000] c0 [cma_region_descriptor_add] adding [sectbl] (0x5c000000)-(0x00800000)
[ 0.000000] c0 S5P/CMA: Reserved 0x5c100000/0x03100000 for 'mfc-secure'
[ 0.000000] c0 [cma_region_descriptor_add] adding [mfc-secure] (0x5c100000)-(0x03100000)
[ 0.000000] c0 S5P/CMA: Reserved 0x5f200000/0x02f00000 for 'ion'
[ 0.000000] c0 [cma_region_descriptor_add] adding [ion] (0x5f200000)-(0x02f00000)
Running the exploit:
Code:
[email protected]:/ $ export PATH=/data/local/bin:$PATH
[email protected]:/ $ ./exynos-abuse
[!] Error mmap: Invalid argument|00000004
Behind the scenes during that:
Code:
[ 119.290791] c1 [exynos_mem_open:50] private_data(0xd0340b80)
[ 119.290889] c1 [exynos_mem_mmap] requesting access to (0x40000000)-(0x41000000)
[ 119.290960] c1 [exynos_mem_mmap] Checking space paddr(0x65800000)-(0x66700000) from 's3c-fimc'
[ 119.291046] c1 [exynos_mem_mmap] Checking space paddr(0x5c800000)-(0x5f000000) from 's3c-mfc'
[ 119.291299] c1 [exynos_mem_mmap] Checking space paddr(0x70000000)-(0x70a00000) from 'fimc_is'
[ 119.291386] c1 [exynos_mem_mmap] Checking space paddr(0x71700000)-(0x71f00000) from 'fimd'
[ 119.291465] c1 [exynos_mem_mmap] Checking space paddr(0x6c300000)-(0x70000000) from 'fimc0'
[ 119.291545] c1 [exynos_mem_mmap] Checking space paddr(0x71600000)-(0x71700000) from 'srp'
[ 119.291631] c1 [exynos_mem_mmap] Checking space paddr(0x64000000)-(0x64400000) from 'mfc-normal'
[ 119.291711] c1 [exynos_mem_mmap] Checking space paddr(0x64000000)-(0x64400000) from 'mfc-normal'
[ 119.291801] c1 [exynos_mem_mmap] Checking space paddr(0x5c000000)-(0x5c800000) from 'sectbl'
[ 119.291888] c1 [exynos_mem_mmap] Checking space paddr(0x5c100000)-(0x5f200000) from 'mfc-secure'
[ 119.291967] c1 [exynos_mem_mmap] Checking space paddr(0x5f200000)-(0x62100000) from 'ion'
[ 119.292034] c1 [exynos_mem_mmap] invalid paddr(0x40000000)-(0x41000000), accessing outside of DMA spaces
[ 119.292798] c1 [exynos_mem_release:58] private_data(0xd0340b80)
I didn't care about the permissions set to the sysfs interface as they don't matter anymore.
I'll be deploying the fix tomorrow throughout my kernels.
The only things that needs to be checked by then is if something else breaks, as HDMI or so. I can't test any of that since I don't have a dongle. In that case anyway the kernel log will tell you what other memory space is accessed and I can open that one up too if needed.
Note: Galaxy S2 / 4210 developers may have to add cma_region_descriptor_add calls to from wherever the memory blocks are defined (Machine file definition or arch/arm/plat-s5p/reserve_mem.c). My commit will work as is on S3 and N2 sources.
I'm off to bed.

Chainfire said:
and to disable the exploit at boot (before any Android app runs).
Click to expand...
Click to collapse
supercurio said:
Cannot protect efficiently against some potential attacks (typically, on boot).
Click to expand...
Click to collapse
First, thank you both for the hard work and quick release.
The main question here is, how efficient is the current implementation in both applications, regarding the protection at start up?
As long as I understand Chainfire somehow ensures that the fix will be applied before running any other (normal) application. Is it possible to install a new application, which to put itself on top of execution chain and exploit the hole, before your application is able to do a 0600 chmod?
If I understand correctly the supercurio's app doesn't promise anything on that matter?! If that is the case, then I guess the recommended app (for rooted phones) will be the Chainfire's solution, right?

julandroid said:
First, thank you both for the hard work and quick release.
The main question here is, how efficient is the current implementation in both applications, regarding the protection at start up?
As long as I understand Chainfire somehow ensures that the fix will be applied before running any other (normal) application. Is it possible to install a new application, which to put itself on top of execution chain and exploit the hole, before your application is able to do a 0600 chmod?
If I understand correctly the supercurio's app doesn't promise anything on that matter?! If that is the case, then I guess the recommended app (for rooted phones) will be the Chainfire's solution, right?
Click to expand...
Click to collapse
Correct.
At the moment, Supercurio's method relies on Android starting it at boot, using the same method any Android app uses to launch at boot. There is no guaranteed order of these apps being launched, and as such, a malicious app could be executing malicious code before the exploit is disabled.
RyanZA's method relies on the same mechanism as well and as such is still vulnerable. Furthermore, unlike Supercurio's and my own patch, RyanZA's patch chmod's to 0600 while ours chmod to 0400 or 0000. With 0600, system user can still run the exploit, so chaining a half-exploit that only gives system user followed by ExynosAbuse may still grant an attacker root access.
My method requires proper root and modifies /system, and disabling the exploit is done before any normal Android app (like those installed from the Play store) have a chance to execute their code. As long as you tell my app to disable the exploit at boot before you install a malicious app, and providing you do not grant a malicious app root (through SuperSU), this should protect against any exploit. Also note that after enabling applying the patch at boot, you can unroot in SuperSU again (SuperSU --> Settings --> Full Unroot) and the patch will keep working, but you'll be unrooted again (if you don't want root). On some devices it takes a reboot for SuperSU to truly disappear after that, by the way.
With my patch, I do advise testing the exploit was disabled after a reboot by running ExynosAbuse again, and verifying both checkboxes next to "Disable exploit" and "Disable exploit on boot" are enabled. These auto-detect the current state, and if the patch on boot was succesful both will be checked.

Chainfire said:
Correct.
At the moment, Supercurio's method relies on Android starting it at boot, using the same method any Android app uses to launch at boot. There is no guaranteed order of these apps being launched, and as such, a malicious app could be executing malicious code before the exploit is disabled.
RyanZA's method relies on the same mechanism as well and as such is still vulnerable. Furthermore, unlike Supercurio's and my own patch, RyanZA's patch chmod's to 0600 while ours chmod to 0400. With 0600, system user can still run the exploit, so chaining a half-exploit that only gives system user followed by ExynosAbuse may still grant an attacker root access.
My method requires proper root and modifies /system, and disabling the exploit is done before any normal Android app (like those installed from the Play store) have a chance to execute their code. As long as you tell my app to disable the exploit at boot before you install a malicious app, and providing you do not grant a malicious app root (through SuperSU), this should protect against any exploit. Also note that after enabling applying the patch at boot, you can unroot in SuperSU again (SuperSU --> Settings --> Full Unroot) and the patch will keep working, but you'll be unrooted again (if you don't want root). On some devices it takes a reboot for SuperSU to truly disappear after that, by the way.
With my patch, I do advise testing the exploit was disabled after a reboot by running ExynosAbuse again, and verifying both checkboxes next to "Disable exploit" and "Disable exploit on boot" are enabled. These auto-detect the current state, and if the patch on boot was succesful both will be checked.
Click to expand...
Click to collapse
As a preliminary quick-fix the chmod could also be handled in ramfs to ensure it's applied as soon as possible in the boot process.
By the way chmodding to 600 didn't brake any of both cameras on a Samsung 4.1.2 based ROM using the old libs with an update 6 kernel on my dev. S3. Will check if it's also behaving like this on 4.1.1 later today.
JP.
Sent from my custom Paranoid Android 2.54 / Yank555.lu CM10 kernel v1.3b Aroma (Linux 3.0.56) powered Galaxy S3 i9300 using Tapatalk 2

Yank555 said:
As a preliminary quick-fix the chmod could also be handled in ramfs to ensure it's applied as soon as possible in the boot process.
By the way chmodding to 600 didn't brake any of both cameras on a Samsung 4.1.2 based ROM using the old libs with an update 6 kernel on my dev. S3. Will check if it's also behaving like this on 4.1.1 later today.
Click to expand...
Click to collapse
Correct. Modifying it in initramfs would be even quicker, but a generic app can't do that. Also chmod to 0400, not 0600.

hunds 3.4 ET kernel hotplug config questions

I was able to install the new kernel to cromi-x 5.04 but I want to tune the hotplugging configuration for better battery life.
0 0 0 is the benchmarking performance mode right? Is 8 12 16 a normal setting good for battery life? Also these settings are in both 50cleantweeks and 99hundsapp init files. Hunds app only updates his script. Should I manually change 50cleantweaks to show the same values or are they over written by the 99hundsapp when its loaded during boot?

troyboy162 said:
I was able to install the new kernel to cromi-x 5.04 but I want to tune the hotplugging configuration for better battery life.
0 0 0 is the benchmarking performance mode right? Is 8 12 16 a normal setting good for battery life? Also these settings are in both 50cleantweeks and 99hundsapp init files. Hunds app only updates his script. Should I manually change 50cleantweaks to show the same values or are they over written by the 99hundsapp when its loaded during boot?
Click to expand...
Click to collapse
The init.d script will executethe 50 before the 99. So the 99hundsapp will be your setting.. You can remove the one in the 50cleanTWEAKS or put a number sign in front of it to comment it out. 0 0 0 is used when you want to disable the hotplug... The default for hund v3.4 is 7 10 12. The first number is the numbers of active threads before the second core is running and so on.. I could be wrong, haha. You can find more information on hund post..

[Kernel][K3-Note]DC-MTK-m1-v3 - A fully working kernel for VIBEUI_V3.5_1631

Build a fully working kernel for K3-Note
In the past few years, many excellent price/performance phones would use MTK chips. Last year, I got a K3Note from a friend. At that time, mt6752 and 2G/16G was approaching the top ranking performance. Lenovo had development updates and it could more or less keep up with the current Android. Seemed no immediate needs for a custom ROM. This summer, the last development update was out. I started gathering some info. Sadly, every bit of info. I got were old, incomplete or for other devices. Kernel source is the basic Linux requirement. We can get it in the Lenovo support. Having been playing with custom ROMs for three years, I thought I saw everything. MTK and Lenovo show me there is another level below...
All kernel sources I've tried so far, no matter how messy and ugly in coding, could at least be built and replaced the one in the stock ROM. The one from Lenovo told me otherwise... If you follow the instruction and build it right away, it won't even boot! It's OK that MTK use the headers. If you like problem solving, it could be fun too. After a few recoveries by the AIO flash tool, I finally built a bootable one. The joy lasted a minutes after it boot up. It just hanged shortly. Dumping the log and kmsg would easily tell you why. The device "/dev/tfa9897" was missing! That means there was something missing in the source! That's why there were only few ROMs and mostly (I think all) were using pre-built kernels from stock ROMs. How can anyone survive without audio in a phone!
Some people are developing/supporting other devices with MTK chips, or even other Lenovo devices. They don't have big issues. I can only conclude that the team releasing the K3 Note kernel source are the prime culprit. I don't know who made that evil decision to deliberately remove that part from the source! Their action just disgraced the brand and their products. Besides cursing, I would thank them. They really piss me off and force me to learn how to write my own driver!
After a desperate and sweaty week, I finally made it work. Thanks to the open source community. I don't need to do everything from scratch. I'm now sharing my experiences here. If there are similar situation in other devices. You are welcome to use and share my experiences. Don't keep it to yourself, share yours too! Just tell those stupid, selfish and idiotic "so call developers" they are not welcome to the open source community...
To other developers, the door is opened now. With the working kernel source, we have the chance to go beyond Marshmallow. I look forward to seeing more custom ROMs for K3-Note. Cheers!
Unleash the existing issues:
There is a file Android.mk in the root of the kernel. Clearly it's from MTK and was there for some time. Even though we don't need it, there are many good info. for us.
I. MTK Headers
MTK devices' bootloader require the ramdisk (initramfs) and kernel to have a header. Before packing it to boot.img, you have to add the header first. Otherwise, it won't boot.
The size of the header is 512 bytes and its format is:
(key)+(size)+(name)+(fill)
key: 　 4 bytes 　 　 　　　　= 0x88 0x16 0x88 0x58
size: 　4 bytes little endian int = size of the file followed
name: 32 bytes c string 　 　　in [KERNEL|BOOTFS|RECOVERY]
　KERNEL = the file is kernel binary
　BOOTFS = the file is initramfs (ramdisk)
　RECOVERY = the file is recovery ramdisk
fill: 472 bytes of 0xFF to fill the header to 512 bytes
Tools
The mkimage, I think MTK provided it.
To add header to an image:
./mkimage <img file> [KERNEL|ROOTFS|RECOVERY] > <out img>
Pearl scripts mtk-tools by @bgcngm
unpack-MTK.pl issue:
If the cmdline has more than one entries (seperate by space), it would make the subsequent repack failed. I double quoted the cmdline in unpack_boot().
repack-MTK.pl issue:
After a few fails, I found that the repack-MTK.pl is no longer working for K3-Note. I don't know if its POSIX, my version of cpio or else. The bootloader just fail to recognize the cpio and reboot to recovery. last_kmsg would shows "restorecon failed: init". I rewrote the repack_boot(). I used mkimge to add header and mkbootfs to pack the ramdisk. The script is simplified and it is working now. I called it View attachment mtk-tools-5.15.zip. The utilities mkimage, mkbootfs and mkbootimg are grouped in the bin folder. Already take care different platform but I only have the Linux version of mkimage and mkbootfs in hand. If you're in different platfrom, you may put the executable for your platforms in bin.
II. The mt6752 kernel requires dtb
The kernel binary for mt6752 requires the dtb image being attached at the end.
Building the kernel
Build alone:
In this case, both Image.gz and Image.gz-dtb (or zImage and zImage-dtb for 32 bits) will be created at <output path>arch/arm64/boot
After that, you may use the the above mentioned repack-MTK.pl to repack the boot.img with your ramdisk.
Build in a custom ROM: (eg. omni or cm)
I have been building Omni for other devices so I used omni to build. I had created a device tree for aio_otfp_m (the name in build.prop of the stock ROM).
The file build/core/task/kernel.mk which most custom ROM have would do the job. The default dtbs in kernel.mk was for Qualcomm. It would not build the Image.gz-dtb we needed. Some changes were required.
Here is the View attachment omni-build.patch for Omni's build. Following the same commit, it would work for CM too. A build flag TARGET_MTK_KERNEL is added. Put it in BoardConfig.mk and set it to true for mt6752 (or other MTK) kernel.
To pack the kernel to boot.img we need a BOARD_CUSTOM_BOOTIMG_MK. If your ROM doesn't have BOARD_CUSTOM_BOOTIMG_MK support (eg. stock AOSP). You need to modify build/core/Makefile to make it work or build the kernel separately and included to your ROM as a pre-built kernel. Here is the View attachment bootimg.mk.txt I made:
Note: With this bootimg.mk, <out path>/target/product/aio_otfp_m/kernel would include the header and ready for repacking.
III. Where is the tfa9897 driver?!
When we managed to build a bootable kernel, the joy might last for a minute! It just stucked at certain point. Log and kmsg showed that it couldn't find the device /dev/tfa9897. If we rename the the folder /system/etc/tfa9897, it would boot up and everything seems normal. What a hell is going on! How can any phone survive without audio! That kind of questions and scraming were all over my head. After a few searches, the picture was clear. Most of the developer were stucked and forced to quit at that point. It really pissed me off and I want to find out why. The deeper I dug the more I was convinced that it was deliberately removed. There were traces in the older sources that it was there. At that moment, I decided to "make it right"! I searched the nxp website. All I got was the pdf spec. I searched github and the linux communities. I found some drivers/codecs for tfa98xx and a few smartpa drivers for tfa98xx too. I then looked into the stock ROM's sysfs.
Code:
[email protected]_otfp_m: $ cd /sys
[email protected]_otfp_m:/sys $ find -name tfa*
./bus/i2c/drivers/tfa9897
./bus/platform/devices/tfa9897.36
./bus/platform/drivers/tfa9897
./bus/platform/drivers/tfa9897/tfa9897.36
./devices/bus.2/tfa9897.36
./devices/virtual/misc/tfa9897
./class/misc/tfa9897
[email protected]_otfp_m: $ cd /sys/devices/bus.2/tfa9897.36
[email protected]_otfp_m:/sys/devices/bus.2/tfa9897.36 $ ls -l
lrwxrwxrwx root root 2016-10-11 23:16 driver -> ../../../bus/platform/drivers/tfa9897
-r--r--r-- root root 4096 2016-10-11 23:16 modalias
drwxr-xr-x root root 2016-10-11 23:16 power
lrwxrwxrwx root root 2016-10-11 23:16 subsystem -> ../../../bus/platform
-rw-r--r-- root root 4096 2016-10-11 23:16 uevent
[email protected]_otfp_m:/sys/devices/bus.2/tfa9897.36 $ cat uevent
DRIVER=tfa9897
OF_NAME=tfa9897
OF_FULLNAME=/bus/[email protected]
OF_COMPATIBLE_0=mediatek,tfa9897
OF_COMPATIBLE_N=1
MODALIAS=of:Ntfa9897T<NULL>Cmediatek,tfa9897
In the first kernel I built, after rename /system/etc/tfa98xx, I got this
./bus/platform/devices/tfa9897.36
./devices/bus.2/tfa9897.36
With dummy driver I built later, I got this
./bus/platform/devices/tfa9897.36
./bus/platform/drivers/tfa9897
./devices/bus.2/tfa9897.36
./devices/virtual/misc/tfa9897
./class/misc/tfa9897
[email protected]_otfp_m:/sys/devices/bus.2/tfa9897.36 $ cat uevent
OF_NAME=tfa9897
OF_FULLNAME=/bus/[email protected]
OF_COMPATIBLE_0=mediatek,tfa9897
OF_COMPATIBLE_N=1
MODALIAS=of:Ntfa9897T<NULL>Cmediatek,tfa9897
A misc driver, a platform driver and a i2c driver were missing! I didn't know why it was so complicated. I decided to write a dummy misc driver to see what's going on. I repacked the kernel I built and the stock ramdisk to boot.img. Flash it to the BOOT partition with TWRP.
Here was the View attachment dummy_smartpa.c. I included it in the sound/soc/mediatek/Makefile
With the dummy driver, I can boot up and everything seems normal. After a while, the system might hang.
I studied the kmsg and found the following:
1) The two .cnt files in /system/etc/tfa9897 are the same. I think it's the default settings of the chip.
2) At start, libtfa9897_interface.so check which chip inside and download the corresponding .cnt via /dev/misc/tfa9897's write.
3) Each time before data was send to /dev/misc/tfa9897, unlocked_ioctl was called
4) As I see no codec under the name tfa98xx, I think the codec was not in the kerenl as some qualcomm kernel would do
Tfa98xx drivers for Qualcomm devices all carried codecs. I found a few nxp smartpa drivers in a devices with mt6595 cpu (forgot which manufacturer). None of them seems fit all the requirements. The closest would be the one for tfa9800 which was the ancestor of tfa9897. After a few trials, I finally pull everything together and come up with a driver that produce the same sysfs structure as the stock kernel.
1) There is the misc device
2) There is a platform driver
3) An I2C driver which was created at probe
Here is the initial driver View attachment AudDrv_tfa9897_v0.c. I put it in sound/soc/mediatek/nxp_tfa9897. As its for an Android Linux kernel, I used AOSP's GNU GPL.
There were still missing GPIO's which was the dead end. The stock driver don't have entries in dts so functions like of_property_read_u32_index() would return null...
After studying for a while, I found that the GPIO is in a codegen.dws file. With tools/dct/DrvGen to browser drivers/misc/mediatek/mach/mt6752/aio_otfp_m/dct/dct/codegen.dws. I found something similar. Eventually, I found the generated header files in out/target/product/aio_otfp_m/obj/KERNEL_OBJ/drivers/misc/mediatek/mach/mt6752/aio_otfp_m/dct/dct/inc
Here are the related GPIOs I copied from cust_gpio_usage.h. I then dump the values from the phone on stock ROM.
Code:
#define GPIO_SMARTPA_LDO_EN_PIN (GPIO118 | 0x80000000)
#define GPIO_SMARTPA_LDO_EN_PIN_M_GPIO GPIO_MODE_00
#define GPIO_SMARTPA_LDO_EN_PIN_M_EINT GPIO_MODE_04
#define GPIO_SMARTPA_LDO_EN_PIN_M_DPI_D GPIO_MODE_01
#define GPIO_SMARTPA_LDO_EN_PIN_M_DBG_MON_B GPIO_MODE_07
#define GPIO_SMARTPA_EINT_PIN (GPIO123 | 0x80000000)
#define GPIO_SMARTPA_EINT_PIN_M_GPIO GPIO_MODE_00
#define GPIO_SMARTPA_EINT_PIN_M_EINT GPIO_MODE_04
#define GPIO_SMARTPA_EINT_PIN_M_DBG_MON_B GPIO_MODE_07
#define GPIO_SMARTPA_RST_PIN (GPIO125 | 0x80000000)
#define GPIO_SMARTPA_RST_PIN_M_GPIO GPIO_MODE_00
#define GPIO_SMARTPA_RST_PIN_M_CLK GPIO_MODE_03
#define GPIO_SMARTPA_RST_PIN_M_EINT GPIO_MODE_04
#define GPIO_SMARTPA_RST_PIN_M_DBG_MON_B GPIO_MODE_07
#define GPIO_SMARTPA_I2S_BCK_PIN (GPIO127 | 0x80000000)
#define GPIO_SMARTPA_I2S_BCK_PIN_M_GPIO GPIO_MODE_00
#define GPIO_SMARTPA_I2S_BCK_PIN_M_EINT GPIO_MODE_04
#define GPIO_SMARTPA_I2S_BCK_PIN_M_I2S3_BCK GPIO_MODE_02
#define GPIO_SMARTPA_I2S_BCK_PIN_M_DBG_MON_B GPIO_MODE_07
#define GPIO_SMARTPA_I2S_WS_PIN (GPIO128 | 0x80000000)
#define GPIO_SMARTPA_I2S_WS_PIN_M_GPIO GPIO_MODE_00
#define GPIO_SMARTPA_I2S_WS_PIN_M_EINT GPIO_MODE_04
#define GPIO_SMARTPA_I2S_WS_PIN_M_I2S3_LRCK GPIO_MODE_02
#define GPIO_SMARTPA_I2S_WS_PIN_M_DBG_MON_B GPIO_MODE_07
#define GPIO_SMARTPA_I2S_DOUT_PIN (GPIO129 | 0x80000000)
#define GPIO_SMARTPA_I2S_DOUT_PIN_M_GPIO GPIO_MODE_00
#define GPIO_SMARTPA_I2S_DOUT_PIN_M_EINT GPIO_MODE_04
#define GPIO_SMARTPA_I2S_DOUT_PIN_M_DPI_VSYNC GPIO_MODE_01
#define GPIO_SMARTPA_I2S_DOUT_PIN_M_I2S3_DO GPIO_MODE_02
#define GPIO_SMARTPA_I2S_DOUT_PIN_M_DBG_SDA GPIO_MODE_03
#define GPIO_SMARTPA_I2S_DOUT_PIN_M_DBG_MON_B GPIO_MODE_07
#define GPIO_SMARTPA_I2S_DIN_PIN (GPIO133 | 0x80000000)
#define GPIO_SMARTPA_I2S_DIN_PIN_M_GPIO GPIO_MODE_00
#define GPIO_SMARTPA_I2S_DIN_PIN_M_CLK GPIO_MODE_03
#define GPIO_SMARTPA_I2S_DIN_PIN_M_EINT GPIO_MODE_04
#define GPIO_SMARTPA_I2S_DIN_PIN_M_I2S0_DI GPIO_MODE_01
#define GPIO_SMARTPA_I2S_DIN_PIN_M_AGPS_SYNC GPIO_MODE_02
#define GPIO_SMARTPA_I2S_DIN_PIN_M_DBG_MON_B GPIO_MODE_07
Values from the phone:
[email protected]_otfp_m:/ $ cd /sys
[email protected]_otfp_m:/sys $ find -name *gpio*
find: No ./fs/cgroup: Permission denied
./bus/platform/devices/10001e00.gpio
./bus/platform/drivers/mt-gpio
./devices/bus.2/10001e00.gpio
./devices/virtual/misc/mtgpio
./class/misc/mtgpio
find: No ./power/tuxonice: Permission denied
./kernel/debug/tracing/events/gpio
./kernel/debug/tracing/events/gpio/gpio_direction
./kernel/debug/tracing/events/gpio/gpio_value
./kernel/debug/gpio
./module/mt_sleep/parameters/slp_dump_gpio
[email protected]_otfp_m:/sys $ cd /sys/devices/virtual/misc/mtgpio <
[email protected]_otfp_m:/sys/devices/virtual/misc/mtgpio $ ls -l
-r--r--r-- root root 4096 2016-10-18 11:28 dev
-rw-rw-r-- root root 4096 2016-10-18 11:28 pin
drwxr-xr-x root root 2016-10-18 11:28 power
lrwxrwxrwx root root 2016-10-18 11:28 subsystem -> ../../../../class/misc
-rw-r--r-- root root 4096 2016-10-18 11:28 uevent
[email protected]_otfp_m:/sys/devices/virtual/misc/mtgpio $ cat pin
PIN: [MODE] [PULL_SEL] [DIN] [DOUT] [PULL EN] [DIR] [IES] [SMT]
0:10001111
...
118:01111110
...
123:41001010
...
125:00000110
...
127:20000110
128:20000110
129:20000110
...
133:10001010
After consulting the pdf spec. for tfa9800 and tfa9897, I had a clearer picture what these vaules were.
Now I had the GPIO and the init values. All the blanks were filled in View attachment AudDrv_tfa9897_v1.c
Everything seems reasonable now but still doesn't work... frustrated!
Here is the View attachment stock_kmsg.txt
Code:
My kmsg:
4,3670,9868743,-; (3)[287:mediaserver]Audio_Mic1_Mode_Select_Set()
4,3671,9868756,-; (3)[287:mediaserver]Audio_Mic1_Mode_Select_Set() mAudio_Analog_Mic1_mode = 0
4,3672,9868846,-; (3)[287:mediaserver]Audio_Mic2_Mode_Select_Set()
4,3673,9868852,-; (3)[287:mediaserver]Audio_Mic2_Mode_Select_Set() mAudio_Analog_Mic2_mode = 0
4,3674,9868930,-; (3)[287:mediaserver]Audio_Mic3_Mode_Select_Set()
4,3675,9868937,-; (3)[287:mediaserver]Audio_Mic3_Mode_Select_Set() mAudio_Analog_Mic3_mode = 0
4,3676,9869017,-; (3)[287:mediaserver]Audio_Mic4_Mode_Select_Set()
4,3677,9869023,-; (3)[287:mediaserver]Audio_Mic4_Mode_Select_Set() mAudio_Analog_Mic4_mode = 0
4,3678,9869169,-; (3)[287:mediaserver]+Audio_i2s0_hdoutput_Set()
4,3679,9869177,-;-(3)[287:mediaserver]-----------AudDrv_Clk_On, Aud_AFE_Clk_cntr:0
4,3680,9869193,-; (3)[287:mediaserver]+EnableApll1 bEnable = 1 APLL1State = 0
4,3681,9869203,-; (3)[287:mediaserver]+AudDrv_APLL22M_Clk_On enable_clock ADC clk(0)
4,3682,9869248,-; (3)[287:mediaserver]-EnableApll1 bEnable = 1
4,3683,9869255,-; (3)[287:mediaserver]+EnableApll2 bEnable = 1 APLL2State = 0
4,3684,9869262,-; (3)[287:mediaserver]+AudDrv_APLL24M_Clk_On enable_clock ADC clk(0)
4,3685,9869305,-; (3)[287:mediaserver]-EnableApll2 bEnable = 1
4,3686,9869312,-; (3)[287:mediaserver]EnableI2SDivPower Diveder_name = 8 bEnable = 1
4,3687,9869320,-; (3)[287:mediaserver]GetI2SDivCounter Diveder_name = 8 index = 0 mAPLL1I2SDividercounter[index] = 0
4,3688,9869327,-; (3)[287:mediaserver]EnableI2SDivPower Diveder_name = 8 bEnable = 1
4,3689,9869334,-; (3)[287:mediaserver]EnableI2SDivPower Diveder_name = 16 bEnable = 1
4,3690,9869341,-; (3)[287:mediaserver]GetI2SDivCounter Diveder_name = 16 index = 0 mAPLL2I2SDividercounter[index] = 0
4,3691,9869348,-; (3)[287:mediaserver]EnableI2SDivPower Diveder_name = 16 bEnable = 1
4,3692,9869355,-;-(3)[287:mediaserver]------------AudDrv_Clk_Off, Aud_AFE_Clk_cntr:0
4,3693,9869385,-;-(3)[287:mediaserver]-----------AudDrv_Clk_On, Aud_AFE_Clk_cntr:0
4,3694,9869394,-; (3)[287:mediaserver]Audio_i2s0_SideGen_Set() samplerate = 0, mi2s0_hdoutput_control = 1, mi2s0_extcodec_echoref_control = 0
4,3695,9869404,-; (3)[287:mediaserver]SetMemoryPathEnable Aud_block = 16 bEnable = 1
4,3696,9869411,-; (3)[287:mediaserver]SetMemoryPathEnable Aud_block = 16 mAudioMEMIF[Aud_block]->mUserCount = 1
3,3697,9875980,-; (3)[287:mediaserver]AudDrv_tfa9897_ioctl: cmd = 0x703 arg = 52
3,3697,9875982,-; (3)[287:mediaserver]ERROR,627: id=2,addr: 36, transfer error
3,3698,9875994,-; (3)[287:mediaserver]ERROR,633: I2C_ACKERR
3,3697,9875996,-; (3)[287:mediaserver]AudDrv_tfa9897_ioctl: cmd = 0x703 arg = 52
3,3699,9876163,-; (3)[287:mediaserver]ERROR,627: id=2,addr: 36, transfer error
3,3700,9876170,-; (3)[287:mediaserver]ERROR,633: I2C_ACKERR
3,3697,9876178,-; (3)[287:mediaserver]AudDrv_tfa9897_ioctl: cmd = 0x703 arg = 52
3,3701,9877681,-; (2)[287:mediaserver]ERROR,627: id=2,addr: 36, transfer error
3,3702,9877694,-; (2)[287:mediaserver]ERROR,633: I2C_ACKERR
3,3697,9877701,-; (3)[287:mediaserver]AudDrv_tfa9897_ioctl: cmd = 0x703 arg = 52
3,3703,9877993,-; (2)[287:mediaserver]ERROR,627: id=2,addr: 36, transfer error
3,3704,9878004,-; (2)[287:mediaserver]ERROR,633: I2C_ACKERR
3,3697,9878010,-; (3)[287:mediaserver]AudDrv_tfa9897_ioctl: cmd = 0x703 arg = 52
3,3705,9878225,-; (2)[287:mediaserver]ERROR,627: id=2,addr: 36, transfer error
3,3706,9878235,-; (2)[287:mediaserver]ERROR,633: I2C_ACKERR
4,3707,9883522,-; (2)[287:mediaserver]Audio_i2s0_SideGen_Set() samplerate = 0, mi2s0_hdoutput_control = 1, mi2s0_extcodec_echoref_control = 0
It's been a week and I knew it's almost there. 36 was a decimal number which seemed not related to the i2c address. I had tried a few possible values. In the spec. for tfa9800 (tfa9897 didn't have this info. I assumed its the same as tfa9800), 0x68-0x6f are the 4 registers with the LSB indicates r/w. Shift right 1 would become 0x34-0x37. Pretty sure 52(0x34) was the i2c device address of the tfa9897. I suspected libtfa9897_interface.so didn't got this value in probe. Since no matter what value I put in Tfa9897_dev, it always send 52(0x34) to AudDrv_tfa9897_ioctl. After cool it down for a day, I studied the sysfs in stock ROM again. What really were on the i2c bus?
Code:
[email protected]_otfp_m:/ $ cd /sys
[email protected]_otfp_m:/sys $ find -name tfa*
find: No ./fs/cgroup: Permission denied
./bus/i2c/drivers/tfa9897
./bus/platform/devices/tfa9897.36
./bus/platform/drivers/tfa9897
./bus/platform/drivers/tfa9897/tfa9897.36
./devices/bus.2/tfa9897.36
./devices/virtual/misc/tfa9897
./class/misc/tfa9897
find: No ./power/tuxonice: Permission denied
[email protected]_otfp_m:/ $ cd /sys/bus/i2c
[email protected]_otfp_m:/sys/bus/i2c $ ls -l
drwxr-xr-x root root 2016-10-17 23:01 devices
drwxr-xr-x root root 2016-10-17 23:01 drivers
-rw-r--r-- root root 4096 2016-10-17 23:01 drivers_autoprobe
--w------- root root 4096 2016-10-17 23:01 drivers_probe
--w------- root root 4096 2016-10-17 23:01 uevent
[email protected]_otfp_m:/sys/bus/i2c $ cd devices
[email protected]_otfp_m:/sys/bus/i2c/devices $ ls -l
lrwxrwxrwx root root 2016-10-17 23:01 0-0036 -> ../../../devices/bus.2/11007000.I2C0/i2c-0/0-0036
lrwxrwxrwx root root 2016-10-17 23:01 0-003e -> ../../../devices/bus.2/11007000.I2C0/i2c-0/0-003e
lrwxrwxrwx root root 2016-10-17 23:01 0-005d -> ../../../devices/bus.2/11007000.I2C0/i2c-0/0-005d
lrwxrwxrwx root root 2016-10-17 23:01 0-0064 -> ../../../devices/bus.2/11007000.I2C0/i2c-0/0-0064
lrwxrwxrwx root root 2016-10-17 23:01 0-006b -> ../../../devices/bus.2/11007000.I2C0/i2c-0/0-006b
lrwxrwxrwx root root 2016-10-17 23:01 0-0075 -> ../../../devices/bus.2/11007000.I2C0/i2c-0/0-0075
lrwxrwxrwx root root 2016-10-17 23:01 1-000d -> ../../../devices/bus.2/11008000.I2C1/i2c-1/1-000d
lrwxrwxrwx root root 2016-10-17 23:01 1-0018 -> ../../../devices/bus.2/11008000.I2C1/i2c-1/1-0018
lrwxrwxrwx root root 2016-10-17 23:01 1-0028 -> ../../../devices/bus.2/11008000.I2C1/i2c-1/1-0028
lrwxrwxrwx root root 2016-10-17 23:01 1-002e -> ../../../devices/bus.2/11008000.I2C1/i2c-1/1-002e
lrwxrwxrwx root root 2016-10-17 23:01 1-0034 -> ../../../devices/bus.2/11008000.I2C1/i2c-1/1-0034
lrwxrwxrwx root root 2016-10-17 23:01 1-0049 -> ../../../devices/bus.2/11008000.I2C1/i2c-1/1-0049
lrwxrwxrwx root root 2016-10-17 23:01 1-0068 -> ../../../devices/bus.2/11008000.I2C1/i2c-1/1-0068
lrwxrwxrwx root root 2016-10-17 23:01 1-0077 -> ../../../devices/bus.2/11008000.I2C1/i2c-1/1-0077
lrwxrwxrwx root root 2016-10-17 23:01 2-006b -> ../../../devices/bus.2/10059c00.SCP_I2C2/i2c-2/2-006b
lrwxrwxrwx root root 2016-10-17 23:01 3-0010 -> ../../../devices/bus.2/11009000.I2C2/i2c-3/3-0010
lrwxrwxrwx root root 2016-10-17 23:01 3-0018 -> ../../../devices/bus.2/11009000.I2C2/i2c-3/3-0018
lrwxrwxrwx root root 2016-10-17 23:01 3-001a -> ../../../devices/bus.2/11009000.I2C2/i2c-3/3-001a
lrwxrwxrwx root root 2016-10-17 23:01 3-007f -> ../../../devices/bus.2/11009000.I2C2/i2c-3/3-007f
lrwxrwxrwx root root 2016-10-17 23:01 i2c-0 -> ../../../devices/bus.2/11007000.I2C0/i2c-0
lrwxrwxrwx root root 2016-10-17 23:01 i2c-1 -> ../../../devices/bus.2/11008000.I2C1/i2c-1
lrwxrwxrwx root root 2016-10-17 23:01 i2c-2 -> ../../../devices/bus.2/10059c00.SCP_I2C2/i2c-2
lrwxrwxrwx root root 2016-10-17 23:01 i2c-3 -> ../../../devices/bus.2/11009000.I2C2/i2c-3
[email protected]_otfp_m:/sys/bus/i2c/devices $ cd ../drivers/tfa98*
[email protected]_otfp_m:/sys/bus/i2c/drivers/tfa9897 $ ls -l
lrwxrwxrwx root root 2016-10-17 23:02 1-0034 -> ../../../../devices/bus.2/11008000.I2C1/i2c-1/1-0034
--w------- root root 4096 2016-10-17 23:02 bind
--w------- root root 4096 2016-10-17 23:02 uevent
--w------- root root 4096 2016-10-17 23:02 unbind
It's quite clear that .36 was not related to i2c address. Tfa9897 was on i2c bus#2 and address#0x34.
I suddenly remembered a constant TFA_I2C_CHANNEL. It was set to (2) in every drivers I found. I was thinking it meant bus# but it didn't. I notice the line "...devices/bus.2/11008000.I2C1/i2c-1/1-0034". Seems 0x34 was in channel 1. So I changed TFA_I2C_CHANNEL to (1) and rebuilt...
OMG, Yes! It work!!! Audio is working now! I've tested for a few days. Everything else seems working the same as the stock kernel.
I updated the kernel to 3.10.103 and added the MTK_I2C_EXTENSION support. The final working version is in my github. Everything is ready now. Cheers! :highfive:
Source:　https://github.com/danielhk/android_kernel_lenovo_aio_otfp_m
Download:　AndroidFileHost,　DevHost,　百度网盘
Installation:
** backup your current /boot partition first **
Since only the /boot partition is replaced, you don't need to wipe anything before or after flashing. If you are rooted, it will also be preserved. (SuperSU 2.52 is recommended, newer systemless SuperSU might not work)
1. Flash zip in Recovery (TWRP is recommended)
2. Use AIO Flash tool (Lenovo's AIO_Upgrade_Tools_v5.1436.00.000 is recommended)
　Newer AIO Flash tool might fail to boot
Change Log:
Code:
[COLOR="Blue"][B]version m1:[/B][/COLOR]
[COLOR="Blue"][B]2016/10/25 - v3[/B][/COLOR]
　　- alsps: use drvier from 3.10.61
[COLOR="Blue"][B]2016/10/24 - v2[/B][/COLOR]
　　- ramdisk: reinstate some services in init.mt6752.rc
[COLOR="Blue"][B]2016/10/19[/B][/COLOR]
　　- upgrade to linux-3.10.103
　　- Fix the CONFIG_TOUCHSCREEN_MTK_HD bug in touchpanel/GT9XX_aio/tpd_custom_gt9xx.h
　　- Fix a few unreasonable warnings
　　- Remove duplicated lines in scripts/drvgen/drvgen.mk
　　- use dtb image: aio_otfp_m
　　- Add the audio driver tfa9897
　　- Add MTK_I2C_EXTENSION support (DMA mode i2c for tfa9897)
　　- ramdisk: remove unnecessary files
　　- ramdisk: remove duplicate services in init.modem.rc
　　- ramdisk: remove duplicate entries in init.rc
　　- ramdisk: sepolicy ready for ROOT

Great job :thumbup: Can't wait to test your kernel in a full working ROM :thumbup:
Gesendet von meinem Lenovo K50-t5 mit Tapatalk 2

Thanks for your big help tfa was a serious bug in kernel source

Hi. Good job bro.
I have one question, can you add "double tap 2 wake"? Thanks

daradan said:
Hi. Good job bro.
I have one question, can you add "double tap 2 wake"? Thanks
Click to expand...
Click to collapse
It's already there. I'm using stock dev V3.5_1631. DT2W is working well.
I had ported DT2W to a few other devices. I wouldn't say it cause a drain but it consume some power for sure. Since it's handled in the kernel, Doze mode has no effect.

wow..thanks for your work

daniel_hk said:
It's already there. I'm using stock dev V3.5_1631. DT2W is working well.
Click to expand...
Click to collapse
I use our custom 1631 rom, and I try reinstall your boot, but dt2w not earned
and when call don't display off

Awesome work bro, but some bugs,
proximity and light sensors are not working. please fix bro..

jomypjose said:
proximity and light sensors are not working. please fix bro..
Click to expand...
Click to collapse
There are similar reports in the local forum too. I don't have problem with the original stock 1631. It is quite clear that stock 1631 doesn't have this issue.
I think you are not using the original stock 1631. You may compare the /system/lib/hw/sensors.mt6752.so and /system/lib64/hw/sensors.mt6752.so with the one in original stock 1631. If they are different, replace it. Otherwise, you should compare the libraries in lib and lib64.
Good luck!
Edit:
Just found that there is a page in engineer mode to calibrate the sensitivity of that sensor.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}

daniel_hk said:
There are similar reports in the local forum too. I don't have problem with the original stock 1631. It is quite clear that stock 1631 doesn't have this issue.
I think you are not using the original stock 1631. You may compare the /system/lib/hw/sensors.mt6752.so and /system/lib64/hw/sensors.mt6752.so with the one in original stock 1631. If they are different, replace it. Otherwise, you should compare the libraries in lib and lib64.
Good luck!
Click to expand...
Click to collapse
can you share that two library files. iam using stock s433 rom, i am also have 1631 dev rom. i swaped that library files with my stock one. but still its not working.

jomypjose said:
can you share that two library files. iam using stock s433 rom, i am also have 1631 dev rom. i swaped that library files with my stock one. but still its not working.
Click to expand...
Click to collapse
Frankly, I don't know what s433 is... If you have the dev 1631, you got everything I have. Anyway, I included my sensors.mt6752.so View attachment system-1631.zip
You may try flashing the stock dev 1631 first. See if your problem solved.
Good luck!

daniel_hk said:
Frankly, I don't know what s433 is... If you have the dev 1631, you got everything I have. Anyway, I included my sensors.mt6752.so View attachment 3909881
You may try flashing the stock dev 1631 first. See if your problem solved.
Good luck!
Click to expand...
Click to collapse
thank you bro

Yes the kernel is fine is with vibeui other roms it has proximity bugs and light sensor bug

sandeep.sethi said:
Yes the kernel is fine is with vibeui other roms it has proximity bugs and light sensor bug
Click to expand...
Click to collapse
I don't know why you think it as a bug?
It is quite clear and proved that something is missing or outdated in the other ROMs you referred to. There might be extra entries in the ramdisk of those ROMs. It might not work if flash directly without repack. Or, there might be some old blobs using different name in sysfs, etc.. Only the right HAL would fully support the latest driver in the kernel.
The tree I pick is aio_otfp_m which is also used in the last dev VIBEUI V3.5 1631. I think it meant for Mashmallow. I don't know which other ROMs you referred to. The source Lenovo released is for VIBEUI (the last M is 1631). That means you need to update the blobs from VIBEUI 1631 if you want to use the kernel for M.

daniel_hk said:
I don't know why you think it as a bug?
It is quite clear and proved that something is missing or outdated in the other ROMs you referred to. There might be extra entries in the ramdisk of those ROMs. It might not work if flash directly without repack. Or, there might be some old blobs using different name in sysfs, etc.. Only the right HAL would fully support the latest driver in the kernel.
The tree I pick is aio_otfp_m which is also used in the last dev VIBEUI V3.5 1631. I think it meant for Mashmallow. I don't know which other ROMs you referred to. The source Lenovo released is for VIBEUI (the last M is 1631). That means you need to update the blobs from VIBEUI 1631 if you want to use the kernel for M.
Click to expand...
Click to collapse
I know what you meant
I am using my own rom that i ported using 1631 blobs and I am sorry to say but for led notification light youhave to add in the kernel source
And I am reallysorry if this hurts you.
-ADev79

sandeep.sethi said:
I know what you meant
I am using my own rom that i ported using 1631 blobs and I am sorry to say but for led notification light youhave to add in the kernel source
And I am reallysorry if this hurts you.
-ADev79
Click to expand...
Click to collapse
Cool down. I meant no unrespectful. You don't need to say sorry. It's nobody's fault. I just don't have enough info. to understand your situation. I already stated in the tittle it's for VIBEUI. I won't feel hurt in any way. I don't want you to feel hurt neither.
You said light sensor and proximity sensor. If the library is missing. It won't work on VIBEUI, right?
So LED is another, right?
Again, it work in VIBEUI, right?
Clearly there are something missing or different in your ROM. Let's find out why, OK?
It's impossible for me to guess with nothing in hand. Do you mind to give me your ROM? I can take a look this weekend when I have time?
Sent from my Lenovo K50-t5 using Tapatalk

Yes ofcourse i can give my rom but i need 2 days bro because im out of my city i will upload as soon as i reach home
Hope u can wait

sandeep.sethi said:
Yes ofcourse i can give my rom but i need 2 days bro because im out of my city i will upload as soon as i reach home
Hope u can wait
Click to expand...
Click to collapse
Sure, no rush and bon voyage.
Since I need dual sim, my K3-note is the daily driver. I can only test it after late night briefly... It would be even better if you can provide the log and ksmg.
Sent from my Lenovo K50-t5 using Tapatalk

Yeah sure
But the led notifocation light needs to be setup in kernel source for sure
Because Cheshkin the russian dev who compiled a mm based kernel is the only kernel that has notification lights working and the problem is he doesnot help anyone.
And thanks again to fix the kernel bugs and made it open sourced

jomypjose said:
proximity and light sensors are not working. please fix bro..
Click to expand...
Click to collapse
sandeep.sethi said:
Yes the kernel is fine is with vibeui other roms it has proximity bugs and light sensor bug
Click to expand...
Click to collapse
There might be some variants with different RIL service. I had disabled some unused services and log in init.mt6752.rc. A friend in local forum help dumping the sysfs with adb. It showed that the driver was not registered. I don't know if those services and logd might stop the registration of the light/proximity sensor driver in some device. But, its quite sure there are differenced in *.rc.
I reinstate some services in init.mt6752.rc again. See if it work for other variants. The tag m1 in the last zip means version 1 in MM. I added -v2 to the new one since nothing was changed in the kernel but the ramdisk.
Since I don't have that kind of "variants". I can't test it myself. Those who have the issue before might help. It would be even better if you help dumping your sysfs. I can show you how.
If the issue persist, I might prepare another zip with AIK and do the repack during flashing. This would keep your existing ramdisk. Cheers!