Database Info

[DEV] Framebuffer console

Make a backup first.
So i have managed to get framebuffer console output , but its stil not working.
So any help is wellcome.
The error i get is more the same as This.
You can try this kernel ( fastboot flash zimage zImage ) <- Dont flash if you dont know what your doing .
more info about whats going on is here.
Vids
With framebuffer active , but display is scrambled!.
With framebuffer console and display fixed.
For thoose that dont know what this is , its simpel.
For GNU/Linux we need this to work.
Some Info:
You could use any kernel that works with DHD , mine is Leedroid's Ace Kernel
.Config File
Mod file /drivers/video/msm/msm_fb.c to look (ADD) like this ( add x = 0; y = 0; w = msmfb->xres; h = msmfb->yres; )
x = msmfb->update_info.left;
y = msmfb->update_info.top;
w = msmfb->update_info.eright - x;
h = msmfb->update_info.ebottom - y;
x = 0; y = 0; w = msmfb->xres; h = msmfb->yres; <-----------Do not add this airow
Thats it. Start modding

change log space
0.1 - Enabled frambuffer -> makes screen scrambled
0.2 - Fixed lcd but got atomic panic.
0.3 - fixed Frambuffer console and lcd trying to boot ubuntu but sdcard is mounted after command line partition list is mmcblk0** needs to be mmcblk1p2

Did we realy need console output to the framebuffer to boot ubuntu nativ, or would it only be a importend debug feature during porting?
Following video shows meego booting on an desire, but the have no console output during the boot. Maybe the have the same bug when the use tty on the framebuffer!?
http://www.youtube.com/watch?v=GtnfHNjcdzg

Not needed !!!! -->
Most for debugging , and evry thing i try i cant get ubuntu to boot.
Also did find sometging about cmdline hack as command line seems to be skipt --> look at setup.c the modded command line.

This could be an alternative:
http://sven.killig.de/android/N1/serial/

Try following zImage.

Jhinta said:
Make a backup first.
So i have managed to get framebuffer console output , but its stil not working.
So any help is wellcome.
The error i get is more the same as This.
You can try this kernel ( fastboot flash zimage zImage ) <- Dont flash if you dont know what your doing .
more info about whats going on is here.
Vids
With framebuffer active , but display is scrambled!.
With framebuffer console and display fixed.
For thoose that dont know what this is , its simpel.
For GNU/Linux we need this to work.
Some Info:
You could use any kernel that works with DHD , mine is Leedroid's Ace Kernel
.Config File
Mod file /drivers/video/msm/msm_fb.c to look (ADD) like this ( add x = 0; y = 0; w = msmfb->xres; h = msmfb->yres; )
x = msmfb->update_info.left;
y = msmfb->update_info.top;
w = msmfb->update_info.eright - x;
h = msmfb->update_info.ebottom - y;
x = 0; y = 0; w = msmfb->xres; h = msmfb->yres; <-----------Do not add this airow
Thats it. Start modding
Click to expand...
Click to collapse
Hi can you help out on enabling Mediatek framebuffer, Alcatel OT918D ?
On compiling I get this error
http://pastebin.com/N6Ct51ub
I think the problem is the files are not in the linux/kernel/drivers/video directory
here is the makefile in linux/kernel/drivers/video
http://pastebin.com/3kfRnrKA
while in the mediatek/drivers directory we have :
http://pastebin.com/mDSTthG0
I need framebuffer console for debugging, please help out if you can.

[dev] real MAC wifi reading

Hi devs, I have idea for MAC reading. First, I know real MAC is located in SPL (I know this becouse I'm tried), I'm tried to read MAC from kernel side but problem is reading SPL becouse board-photon.h have defined:
Code:
#define MSM_MEM1_BASE 0x00000000
#define MSM_LINUX_BASE_OFFSET 0x00200000
#define MSM_PHOTON_LINUX1_BASE (MSM_MEM1_BASE + MSM_LINUX_BASE_OFFSET) /* 2MB alignment */
#define MSM_PHOTON_LINUX1_SIZE (MSM_MEM1_SIZE - MSM_LINUX_BASE_OFFSET)
SPL have size of 0x80000 and we skipped it. My idea is:
- patch haret to copy some SPL addreses (addrese where is wifi nvs ram) to another memory location
- read these location from kernel side
or
- edit kernel code to read this location or edit kernel to copy SPL to an memory location
What you think? Maybe you have idea how to read SPL?

i think there is solutions easier than SPL to get MAC addr

real mac == winMo?

i have an idea, but not tested yet:
simply remove "macaddr=00:11:22:33:44:55\n" from htc_wifi_nvs.c
recompile
it should work now
(my guess is the driver already read the good address, but we overwrite it with bad value)

No, I'm tried without static nvs! Only sense I think is reading these nvs from memory, but if we want to read this we must have access to first 0x80000 bytes (SPL), or maybe adding kernel code (command line parameter), or maybe DEX call (I dont know if is possible)
See picture, you will see where is nvs in spl, also you will see we have defined static_nvs diferent than nvs in spl!

you're totaly right.
and htc_wifi_nvs.c for liberty is extracting the NVS from bootloader.
i think the address we have is wrong:
This is the address for Liberty:
#define ATAG_MSM_WIFI 0x57494649 /* MSM WiFi */
Click to expand...
Click to collapse
For our bootloader, it must be different. i'll investigate.

Is the MAC in startup.txt used by Android?
If that is the case, may it is more easy to write a WinMo app that adjusts the startup.txt with the MAC know by WinMo.
Or is that to easy?

-r0bin- said:
you're totaly right.
and htc_wifi_nvs.c for liberty is extracting the NVS from bootloader.
Click to expand...
Click to collapse
I think is not from bootloader becouse liberty bootloader start at 0x0 and is size < 1M, but ok, good thing is - you understand me, and I thk you for it!
We need to read:
- start at 0x65720
- read 0x239 bute

munjeni said:
I think is not from bootloader becouse liberty bootloader start at 0x0 and is size of 1M, but ok, good thing is - you understand me, and I thk you for it!
We need to read:
- start at 0x65720
- read 0x239 bute
Click to expand...
Click to collapse
thanks, but what address do you dump? (0x65720 is only the offset)
how do you create this memory dump?

I showed you how I do it, but you're not ...attention to my post. I'll tell you, unlike you who is hiding information
see this link how I dump memmory.
Code:
976 // cardsharing smem dump
977 /*int i;
978 int x[1000];
979 printk("Battery hex smem dump: ");
980 for (i=0; i<1000; i++)
981 {
982 x[i] = readl(MSM_SHARED_RAM_BASE + 0xfc000 + i) & 0x000000ff;
983 printk("%02x", x[i]);
984 }
985 printk("\n");*/
Problem is: we not have access to spl!

Maybe from this way:
msm_nand_read: 65720 239
Code:
msm_nand_read(struct mtd_info *mtd, loff_t from, size_t len,
size_t *retlen, u_char *buf)
{
int ret;
struct mtd_oob_ops ops;
/* printk("msm_nand_read %llx %x\n", from, len); */
ops.mode = MTD_OOB_PLACE;
ops.len = len;
ops.retlen = 0;
ops.ooblen = 0;
ops.datbuf = buf;
ops.oobbuf = NULL;
ret = msm_nand_read_oob(mtd, from, &ops);
*retlen = ops.retlen;
return ret;
}
return wifi_nvs;
What you think?

munjeni said:
but if we want to read this we must have access to first 0x80000 bytes (SPL)
Click to expand...
Click to collapse
first 0x80000 bytes of what? memory?
munjeni said:
See picture, you will see where is nvs in spl, also you will see we have defined static_nvs diferent than nvs in spl!
Click to expand...
Click to collapse
how did you generated this picture?
i mean, what address did you used?

yes, of memory
haret: pwf spl.dump 0x0 0x80000
Program used to read spl.dump is: X&D hex editor
Program used to screen capture is: FastStone Capture
From kernel side I'm tried to dump android memory (spl from 0x0 len 0x80000), but without success, I think is not possible in this time, we need modifications to do that!

oook i got it!
physical address = 0x65720
thats sounds easy!
and you cannot dump memory like this under Linux, it uses virtual address!!!

ok, good if is easy! Please report here if you got it and how you got it, I need that knownledge for my future development, ok?

munjeni said:
ok, good if is easy! Please report here if you got it and how you got it, I need that knownledge for my future development, ok?
Click to expand...
Click to collapse
under android, when i use this func: "phys_to_virt(0x65720)" it gives me this virtual address: 0xbfe65720
unfortunately system crash when i try to access it.
there must be another way...

maybe is empty virtual (or we not have permisions to read) becouse we skipped first 0x100000 (board_photon.h) from psychical, hmm I not understand why crashed? I'm also tried and also with crashing. If I'm right MSM_SHARED_RAM_BASE is psychical and other defined in board_photon.h is also psychical?

found by schlund:
https://gitorious.org/linux-on-winc...ter/arch/arm/mach-msm/board-htcleo-wifi-nvs.c
on HTC Leo, they read SMEM and can retrieve MAC addr, it is encrypted by CRC32

good! But maybe we also need to change hardcoded_nvs bassed on picture. Are you got mac from smem after crc decode? I've not tried to read

actually it's not the real MAC addr, its a random one
regarding the real NVS data from hardware:
- either the bootloader memory has a special protection
- either we are using the wrong RAM virtual address
- either we dont have the good access method

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] Help ?? trying to set up ddr ram for kernel 3.0.8 properly [ not a dummy ]

I was wondering if maybe someone here can maybe help me out with this. ive been working on it on and off for about 8 months now.
I am The lead developer for Team Osiris.
currently, still finishing up cm10 for the Zte warp.
Which is MSM8655 / MSM7X30 based
512mb ram
the problem iam having is with the 3.0.8 kernel iam developing.
we took the kernel source for the warp sequent. and modified it, and got it to boot on the warp.
we were using a moddified board-msm-7x30, but i recently made a new board file from scratch based on a Code Aurora generic board-msm-7x30.
i reworked the entire board, added and removed what needed to be done.
then i get to the real issue ive been trying to solve forever.
it seems no matter what i do. the system only sees 116mb ram. i know some is reserved for the os and what not. so i know thats not the issue.
on stock gb we had 512 physical, with 378 free.
this very same problem was also encounterd and fixed when we started cm10 using the 2.6.35.7 source for the phone.
that one turned out that memory4 was not online.. simple fix.
ive tried that on the 3x kernel with no luck.
memory4 doesnt even exist.
only memory0. using either board file.
Here is a snipet of the code iam trying to get memory online in the board.
Code:
// MEMBANKS
#define DDR_BANK1 0X20000000
#define DDR_BANK1_SIZE 0x00000100
#define DDR_BANK2 0X40000000
#define DDR_BANK2_SIZE 0x00000100
/// DO AWAY WITH ZTE FIXUP, IN FAVOR OF MSM7X30_FIXUP
static void __init msm7x30_fixup(struct machine_desc *desc,
struct tag *tags,
char **cmdline,
struct meminfo *mi)
{
mi->bank[0].start = DDR_BANK1 + PHYS_OFFSET;
mi->bank[0].size = DDR_BANK1_SIZE;
mi->bank[1].start = DDR_BANK2;
mi->bank[1].size = DDR_BANK2_SIZE;
return ;
}
static void __init msm7x30_init_early(void)
{
msm7x30_allocate_memory_regions();
}
again, the hex values may not be right.
ive done my research and iam kind of at a loss right now. in 2.6 it seems everything was in ebi0
and also with 8655 cpus everything is in ebi0.
ive tried other memory layouts from phones with the same hardware. no luck..
any help or direction would be appreciated

[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!