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!
I've flashed cm 14.1 osprey and it is working all fine accept I've lost root and my incoming and outgoing calls are not working in one sim(data is working fine) and second problem is my root access has lost after some time. I tried with latest update of SuperSU but both sim card not shows up, with old versions supersu just don't get installed.
And yes i flashed it more than one time but the problem continues .
Phone status:
Moto g3 ,twrp latest version installed, everything working fine accept these two problems.
Plz help ,any small help will be appreciated.
Clean flash again, don't flash superSU instead use built in root method. Because CM is already rooted.
aadison said:
Clean flash again, don't flash superSU instead use built in root method. Because CM is already rooted.
Click to expand...
Click to collapse
Done clean flashing but still not incoming and outgoing not working on one sim slot.
And thanks for replying.
manmali said:
Done clean flashing but still not incoming and outgoing not working on one sim slot.
And thanks for replying.
Click to expand...
Click to collapse
Wipe system and reflash ROM an gapps, or better yet clean flash the whole thing... Not really sure what calls would have to do with root access though.
acejavelin said:
Wipe system and reflash ROM an gapps, or better yet clean flash the whole thing... Not really sure what calls would have to do with root access though.
Click to expand...
Click to collapse
I always flash rom after a deep wipe and i flashed 3 updates of cm 14.1 but same problem occured in all.
You must think may be slot is not working but to check this i flashed stock rom once, it just worked. Now what to do??
And thanks for suggestions
manmali said:
I always flash rom after a deep wipe and i flashed 3 updates of cm 14.1 but same problem occured in all.
You must think may be slot is not working but to check this i flashed stock rom once, it just worked. Now what to do??
And thanks for suggestions
Click to expand...
Click to collapse
Try a different ROM... AICP or RR or something.
acejavelin said:
Try a different ROM... AICP or RR or something.
Click to expand...
Click to collapse
I don't know about any other roms accept cm, I'll read about them if they are good, I'll try flashing em. Thanks
manmali said:
I don't know about any other roms accept cm, I'll read about them if they are good, I'll try flashing em. Thanks
Click to expand...
Click to collapse
Lol... I have nothing against CM, but there are definitely other good roms out there, CM is very basic and bland, which is not intended to be negative, but there are much more feature packed roms out there. I hope you enjoy your "journey" past CM.
acejavelin said:
Lol... I have nothing against CM, but there are definitely other good roms out there, CM is very basic and bland, which is not intended to be negative, but there are much more feature packed roms out there. I hope you enjoy your "journey" past CM.
Click to expand...
Click to collapse
Thankyou , suggest me which rom should i try first??
manmali said:
Thankyou , suggest me which rom should i try first??
Click to expand...
Click to collapse
I don't know... Rez Remix was always my favorite on G3, personally I would stick with Marshmallow for now too. Dirty Unicorns, AICP, and BrokenOS are solid options as well.
acejavelin said:
I don't know... Rez Remix was always my favorite on G3, personally I would stick with Marshmallow for now too. Dirty Unicorns, AICP, and BrokenOS are solid options as well.
Click to expand...
Click to collapse
I going for aicp, it's ui customization features seems pretty good. Thanks for your time
manmali said:
I always flash rom after a deep wipe and i flashed 3 updates of cm 14.1 but same problem occured in all.
You must think may be slot is not working but to check this i flashed stock rom once, it just worked. Now what to do??
And thanks for suggestions
Click to expand...
Click to collapse
Same for me on the oneplus-3t. Our similarity is that I also use cm-14.1.
The error message is lengthy (170 lines) and reports things like:
WARNING: linker: /su/bin/sush: unused DT entry: type 0xaa1303e0d00000c1 arg 0x97ff73519111c021
WARNING: linker: /su/bin/sush: unused DT entry: type 0xd00000c134000fa0 arg 0x9111e021aa1303e0
WARNING: linker: /su/bin/sush: unused DT entry: type 0x350010e097ff734c arg 0x910b8062d00000c3
CANNOT LINK EXECUTABLE "/su/bin/sush": empty/missing DT_HASH/DT_GNU_HASH in "/su/bin/sush" (new hash type from the future?)
Aborted
In a different root shell I was able to verify, that the binaries /su/bin/app_process and /su/bin/sush changed both, content and date.
Old (working) version
ls -lani:
23 -rwxr-xr-x 1 0 0 279K 1970-01-17 19:09 /su/bin/sush*
24 -rwxr-xr-x 1 0 0 18K 1970-01-17 19:09 /su/bin/app_process*
md5sum:
daf9ea634bfd1577e62dcf30a998586f /su/bin/sush
4aadf50b46676e6da7c38ab40c0f1ac7 /su/bin/app_process
broken version:
ls -lani
23 -rwxr-xr-x 1 0 0 279K 1970-01-17 19:09 /su/bin/sush*
24 -rwxr-xr-x 1 0 0 18K 1970-01-17 19:09 /su/bin/app_process*
md5sum:
4fddfedaeaea883514cd6d78d2412766 /su/bin/sush
71f9cf0c48095fdf41fab958407bc265 /su/bin/app_process
A reboot fixes the issue. I'll try and see if there are files with the given md5sum on the phone. I tried to find those files: no success. Just to find that sush and app_process vanished altogether. Still: rebooting fixes this.
mrcvs said:
Same for me on the oneplus-3t. Our similarity is that I also use cm-14.1.
The error message is lengthy (170 lines) and reports things like:
WARNING: linker: /su/bin/sush: unused DT entry: type 0xaa1303e0d00000c1 arg 0x97ff73519111c021
WARNING: linker: /su/bin/sush: unused DT entry: type 0xd00000c134000fa0 arg 0x9111e021aa1303e0
WARNING: linker: /su/bin/sush: unused DT entry: type 0x350010e097ff734c arg 0x910b8062d00000c3
CANNOT LINK EXECUTABLE "/su/bin/sush": empty/missing DT_HASH/DT_GNU_HASH in "/su/bin/sush" (new hash type from the future?)
Aborted
In a different root shell I was able to verify, that the binaries /su/bin/app_process and /su/bin/sush changed both, content and date.
Old (working) version
ls -lani:
23 -rwxr-xr-x 1 0 0 279K 1970-01-17 19:09 /su/bin/sush*
24 -rwxr-xr-x 1 0 0 18K 1970-01-17 19:09 /su/bin/app_process*
md5sum:
daf9ea634bfd1577e62dcf30a998586f /su/bin/sush
4aadf50b46676e6da7c38ab40c0f1ac7 /su/bin/app_process
broken version:
ls -lani
23 -rwxr-xr-x 1 0 0 279K 1970-01-17 19:09 /su/bin/sush*
24 -rwxr-xr-x 1 0 0 18K 1970-01-17 19:09 /su/bin/app_process*
md5sum:
4fddfedaeaea883514cd6d78d2412766 /su/bin/sush
71f9cf0c48095fdf41fab958407bc265 /su/bin/app_process
A reboot fixes the issue. I'll try and see if there are files with the given md5sum on the phone. I tried to find those files: no success. Just to find that sush and app_process vanished altogether. Still: rebooting fixes this.
Click to expand...
Click to collapse
Unhappy coensidence, I'm getting the same issue right now on my zte axon 7 and I'm in total panic mode after uncountable firmware flashing and trials, My Phone's nand won't stand long, even tho it's ufs 2.0
different phones, different softwares and the same error, I think supersu is getting weak in general with google's latest policy against modding. It's just...xposed is doa, cm is long gone with the theme engine that everyone loved, rooting is not as easy as it used to be and simple things are getting harder and harder. besides everything, going off-road here, Im sick of dealing with google's bad temper about this, This is the first time in my life I consider a jailbroken iphone over android, which is sad.
anyways, Im looking for a fix of this very annoying issue, btw what file system you use?
maybe f2fs is the reason for all this?
Hey guys! Some of you might know me from the LG G5 scene, but I have since moved on from there and am hoping to make some progress with the Gear S3
After doing some digging and paying zero attention in class today, I came across the kernel source files for the Exynos 7270 and the combination firmwares for the Gear 3 Classic and Frontier versions.
If you don't know what combination files are here (link removed) is a great explanation but the TL;DR is that this is the internal firmware Samsung uses to reset devices, so it gives you full read/write access to the device including root access. So basically this is a pre-rooted firmware, and I assume that it is bootloader unlocked as it appears to flash an engineer sboot (bootloader), so I believe this would be the first step towards porting Android Wear/TWRP!
The kernel source is what we will actually use to port over AW/TWRP. It does not seem to have been posted before, and took me a few hours of digging to find. My watch comes in tomorrow, and after I flash this firmware I will pull the boot.img and start making a device/vendor tree to attempt and make a kernel!
Here is the kernel source for the Exynos 7270: https://github.com/HonestlyAnnoying/tizen_kernel_exynos7270
Here is the kernel source for the Gear S3 (all versions) (will upload to GitHub in the morning): Samsung Opensource
Here is the SM-R770 (Classic) combination firmware [R770XXU2BQC2]: link
Here is the SM-R760 (Frontier) combination firmware [R760XXU2BQC2]: link
The road to porting Android Wear is going to take a lot of work, and any help developing (not testing for now!) would be EXTREMELY appreciated (looking at you guys @cipherswitch @biktor_gj !). If you would like to help with development or would like to contribute in any way, please PM me or hit me up on Skype (honestly.annoying)!
Here is a Google Drive folder with all files I have for this, it will be updated as new things are found
The one thing that might persuade me to try a sammy product! Thanks for your efforts @Honestly Annoying
Update: have flashed this, can confirm it has root access!! Pulling images now
Wow!!! Fingers crossed!!
@Honestly Annoying
Please, can you tell us what you see on Screen?
Maybe screenshot if posible...
I have flashed just for fun the older Z1 Combination I have... AOC1... and my SM-Z130H shows testmode Icons...
Later I can upload Screenshot... I have to remove something...
But in this Firmware I can enter all testmode Codes via Keys... like:
*#197328640#
And more... this is blocked in normal Firmware...
Cool. su work nice...
I can enter su in Shell and Super User is active... instead SDB Command:
sdb root on
Best Regards
Edit 1.
Screenshot from Combination Firmware AOC1 I have added in this Post:
https://forum.xda-developers.com/showpost.php?p=71744490&postcount=413
adfree said:
@Honestly Annoying
Please, can you tell us what you see on Screen?
Maybe screenshot if posible...
I have flashed just for fun the older Z1 Combination I have... AOC1... and my SM-Z130H shows testmode Icons...
Later I can upload Screenshot... I have to remove something...
But in this Firmware I can enter all testmode Codes via Keys... like:
*#197328640#
And more... this is blocked in normal Firmware...
Cool. su work nice...
I can enter su in Shell and Super User is active... instead SDB Command:
sdb root on
Best Regards
Edit 1.
Screenshot from Combination Firmware AOC1 I have added in this Post:
https://forum.xda-developers.com/showpost.php?p=71744490&postcount=413
Click to expand...
Click to collapse
I'm just going to start dumping information I find in this thread
this is the partition scheme
Code:
sh-3.2# ls -l /dev/disk/by-partlabel
total 0
lrwxrwxrwx 1 root root 15 Apr 6 09:52 boot -> ../../mmcblk0p8
lrwxrwxrwx 1 root root 15 Apr 6 09:52 cm -> ../../mmcblk0p7
lrwxrwxrwx 1 root root 15 Apr 6 09:52 cpnvcore -> ../../mmcblk0p3
lrwxrwxrwx 1 root root 15 Apr 6 09:52 csa -> ../../mmcblk0p2
lrwxrwxrwx 1 root root 16 Apr 6 09:52 csc -> ../../mmcblk0p11
lrwxrwxrwx 1 root root 16 Apr 6 09:52 module -> ../../mmcblk0p10
lrwxrwxrwx 1 root root 15 Apr 6 09:52 param -> ../../mmcblk0p6
lrwxrwxrwx 1 root root 15 Apr 6 09:52 ramdisk1 -> ../../mmcblk0p5
lrwxrwxrwx 1 root root 15 Apr 6 09:52 ramdisk2 -> ../../mmcblk0p4
lrwxrwxrwx 1 root root 15 Apr 6 09:52 recovery -> ../../mmcblk0p9
lrwxrwxrwx 1 root root 16 Apr 6 09:52 rootfs -> ../../mmcblk0p14
lrwxrwxrwx 1 root root 16 Apr 6 09:52 steady -> ../../mmcblk0p15
lrwxrwxrwx 1 root root 16 Apr 6 09:52 system-data -> ../../mmcblk0p12
lrwxrwxrwx 1 root root 15 Apr 6 09:52 tup -> ../../mmcblk0p1
lrwxrwxrwx 1 root root 16 Apr 6 09:52 user -> ../../mmcblk0p13
Code:
sh-3.2# ls -l /dev/disk/by-label
total 0
lrwxrwxrwx 1 root root 16 Apr 6 09:52 modules -> ../../mmcblk0p10
lrwxrwxrwx 1 root root 10 Apr 6 09:52 ramdisk -> ../../ram0
lrwxrwxrwx 1 root root 15 Apr 6 09:52 ramdisk-recovery -> ../../mmcblk0p4
lrwxrwxrwx 1 root root 16 Apr 6 09:52 rootfs -> ../../mmcblk0p14
lrwxrwxrwx 1 root root 16 Apr 6 09:52 tizen -> ../../mmcblk0p13
Honestly Annoying said:
Update: have flashed this, can confirm it has root access!! Pulling images now
Click to expand...
Click to collapse
Did it erase the serial number of the device?
10urshin said:
Did it erase the serial number of the device?
Click to expand...
Click to collapse
nope
Honestly Annoying said:
nope
Click to expand...
Click to collapse
How about knox trip?
10urshin said:
How about knox trip?
Click to expand...
Click to collapse
how can I check?
Honestly Annoying said:
how can I check?
Click to expand...
Click to collapse
Good question. I don't know. I thought it might show on download mode but it doesn't.
This is the boot.img and recovery.img. The Tizen does not seem to extract like an Android kernel, will have to look into this more...
Also, they are both 16.8MB in size, possibly the same image?
Check this path:
/home/developer
Here is device-profile.xml inside...
This allow Privileges of all 3 Levels:
Public
Partner
Platform
But for now only if this Combination Firmware is flashed... it ignores Serial Number/DUID... maybe by these 0 Byte Flag file(s) in CSC...
Best Regards
Edit 1.
... seems my fault...
All Certs are inside...
Code:
usr/share/cert-svc/certs/code-signing/tizen
So fingerprint should be similar like in Reference devices...
Code:
usr/share/wrt-engine
Will later check with open eyes... now better sleep...
adfree said:
Check this path:
/home/developer
Here is device-profile.xml inside...
This allow Privileges of all 3 Levels:
Public
Partner
Platform
But for now only if this Combination Firmware is flashed... it ignores Serial Number/DUID... maybe by these 0 Byte Flag file(s) in CSC...
Best Regards
Click to expand...
Click to collapse
here ya go
Thank you for device-profile.xml...
Should be same here...
https://forum.xda-developers.com/showpost.php?p=71737611&postcount=18
And maybe in all FTMA Combination files... all Gear... all Z-Mobiles...
But reason for working seems not this file...
Sorry, my fault...
But difference in these 2 folders...
Code:
usr/share/wrt-engine/fingerprint_list.xml
and in commercial devices... Certs missing...
Code:
usr/share/cert-svc/certs/code-signing/tizen
This is what I did long time ago in my rooted Zseries Firmware...
By "mistake"... :laugh:
I have nuked device-profile.xml... because I was tooo lazy to register my Email and Certs...
Best Regards
Currently trying to extract the boot.img... should be studying for the SAT but screw it
I did lose Samsung Pay, but to me that is not a big deal. Waiting for a USA firmware to be released to reflash
EDIT: JUST KIDDING. It's still there! I'm an idiot lol
This is great to see! Good luck guys, hope you get this all worked out. Android Wear on the Gear S3 would be the perfect combination! :good:
I have the S3 Frontier, but not all that knowledgeable with Android dev unfortunately.
the_scotsman said:
This is great to see! Good luck guys, hope you get this all worked out. Android Wear on the Gear S3 would be the perfect combination! :good:
I have the S3 Frontier, but not all that knowledgeable with Android dev unfortunately.
Click to expand...
Click to collapse
Honestly at this point any help would be greatly appreciated. Do you have any interest/time available to help out?
Hi,
my S6 (g920f) has slowly and steadily spiraled down and lost functionality over the many custom ROMs that I flashed (which I totally don't get because wiping should clear the gunk and fix broken things, at least it did for my S1). First I lost USB connectivity with the computer (apart from download mode), then I lost 4G, then I lost my boot logo and it became white noise, and now I lost wifi which is the point where I'd say this device is becoming useless.
All I want now is the most complete reset possible, including boot, partitiontables, everything that can ever be reset. Ideally to the exact software that it ran when I bought the phone. Does anyone know how to do this the best way?
I'm a bit sad, I feel like Samsung put so much effort into crap like KNOX and does nothing to make my life easier if I want open source android with no google spyervices framework, just my device being mine. :crying:
Cheers
Alternatively, could someone upload a full TWRP backup of a clean empty phone? Without EFS for privacy reasons, and I have my own EFS and MODEM backed up since a long time. Much appreciated!
pingguo said:
Hi,
my S6 (g920f) has slowly and steadily spiraled down and lost functionality over the many custom ROMs that I flashed (which I totally don't get because wiping should clear the gunk and fix broken things, at least it did for my S1). First I lost USB connectivity with the computer (apart from download mode), then I lost 4G, then I lost my boot logo and it became white noise, and now I lost wifi which is the point where I'd say this device is becoming useless.
All I want now is the most complete reset possible, including boot, partitiontables, everything that can ever be reset. Ideally to the exact software that it ran when I bought the phone. Does anyone know how to do this the best way?
I'm a bit sad, I feel like Samsung put so much effort into crap like KNOX and does nothing to make my life easier if I want open source android with no google spyervices framework, just my device being mine. :crying:
Cheers
Click to expand...
Click to collapse
I am also in the same situation
pingguo said:
Alternatively, could someone upload a full TWRP backup of a clean empty phone?
Click to expand...
Click to collapse
Code:
~$ ls -al /dev/block/platform/15570000.ufs/by-name/
total 0
drwxrwxr-x 2 system radio 460 2018-09-02 20:39 .
drwxr-xr-x 4 root root 560 2018-09-02 20:39 ..
lrwxrwxrwx 1 root root 15 2018-09-02 20:39 BOOT -> /dev/block/sda8
lrwxrwxrwx 1 root root 15 2018-09-02 20:39 BOTA0 -> /dev/block/sda1
lrwxrwxrwx 1 root root 15 2018-09-02 20:39 BOTA1 -> /dev/block/sda2
lrwxrwxrwx 1 root root 16 2018-09-02 20:39 CACHE -> /dev/block/sda19
lrwxrwxrwx 1 root root 16 2018-09-02 20:39 CARRIER -> /dev/block/sda20
lrwxrwxrwx 1 root root 16 2018-09-02 20:39 DNT -> /dev/block/sda13
lrwxrwxrwx 1 root root 15 2018-09-02 20:39 EFS -> /dev/block/sda3
lrwxrwxrwx 1 root root 16 2018-09-02 20:39 OTA -> /dev/block/sda10
lrwxrwxrwx 1 root root 15 2018-09-02 20:39 PARAM -> /dev/block/sda7
lrwxrwxrwx 1 root root 16 2018-09-02 20:39 PERSDATA -> /dev/block/sda16
lrwxrwxrwx 1 root root 16 2018-09-02 20:39 PERSISTENT -> /dev/block/sda14
lrwxrwxrwx 1 root root 16 2018-09-02 20:39 RADIO -> /dev/block/sda11
lrwxrwxrwx 1 root root 15 2018-09-02 20:39 RECOVERY -> /dev/block/sda9
lrwxrwxrwx 1 root root 16 2018-09-02 20:39 SBFS -> /dev/block/sda17
lrwxrwxrwx 1 root root 16 2018-09-02 20:39 STEADY -> /dev/block/sda15
lrwxrwxrwx 1 root root 16 2018-09-02 20:39 SYSTEM -> /dev/block/sda18
lrwxrwxrwx 1 root root 16 2018-09-02 20:39 TOMBSTONES -> /dev/block/sda12
lrwxrwxrwx 1 root root 16 2018-09-02 20:39 USERDATA -> /dev/block/sda21
lrwxrwxrwx 1 root root 15 2018-09-02 20:39 m9kefs1 -> /dev/block/sda4
lrwxrwxrwx 1 root root 15 2018-09-02 20:39 m9kefs2 -> /dev/block/sda5
lrwxrwxrwx 1 root root 15 2018-09-02 20:39 m9kefs3 -> /dev/block/sda6
~$
All of them?
Any "reset" really cleans USERDATA as the maximum.
Any firmware file flashes less than a half of these.
pingguo said:
Hi,
my S6 (g920f) has slowly and steadily spiraled down and lost functionality over the many custom ROMs that I flashed (which I totally don't get because wiping should clear the gunk and fix broken things, at least it did for my S1). First I lost USB connectivity with the computer (apart from download mode), then I lost 4G, then I lost my boot logo and it became white noise, and now I lost wifi which is the point where I'd say this device is becoming useless.
All I want now is the most complete reset possible, including boot, partitiontables, everything that can ever be reset. Ideally to the exact software that it ran when I bought the phone. Does anyone know how to do this the best way?
I'm a bit sad, I feel like Samsung put so much effort into crap like KNOX and does nothing to make my life easier if I want open source android with no google spyervices framework, just my device being mine. :crying:
Cheers
Click to expand...
Click to collapse
Hey! I have found a website that provides stock roms. I have installed one and my phone is factory new. I even get OTA updates and everything is official. the only thing about my phone is that i tripped knox lol. the website is
updato
I then found a "how to install an officialsamsung stock firmware using odin" and followed that guide
The rom I downloaded and flashed using Odin is here (just copy and paste this at the end of updato
firmware-archive-select-model?record=583A76F4915811E89F15FA163EE8F90B
the way i did it was wipe the usual stuff when you want to flash a custom rom but instead you use the stock ROM. only down point is that it puts your recovery back to stock to. So if you want twrp again just flash it and it should be good to go
if i could post links i would so if you want them then message me and i will link things to you
Staritegaming said:
I am also in the same situation
Click to expand...
Click to collapse
Good news dude, I got everything fixed. I'll post the solution below.
bbsc said:
Code:
~$ ls -al /dev/block/platform/15570000.ufs/by-name/
All of them? [...] [/QUOTE]
I got it done, but thanks a lot for offering help! Would have really needed it if my way didn't work out.
[QUOTE="Staritegaming, post: 77539800, member: 9368858"]Hey! I have found a website that provides stock roms. [...] [/QUOTE]
Also my thanks to you for this, it was part of the solution, in fact.
---
The solution to all the problems for me was:
[LIST=1]
[*]Wiped NAND and repartitioned in Odin using the G920F-2BOG8_EUR_OPEN.pit - This might be risky or stupid but anyways, that's what I did. I was mad.
[*]Installed most recent official firmware with XEU (French) country code with Odin
[*]Odin-flashed most recent TWRP recovery (3.2.3 as of that time)
[*]Opted for FrankensteinS6 SR v4.5 because I need my customization! It came with its own skin included but you can disable and delete it if you like, that's what I did. I recommend to use a TW-based ROM like this one.
[*]Flashed Magisk, reboot, flashed xposed standard/non-magisk, reboot, flashed microG, reboot. (I experienced issues chainflashing without reboots... Also I didn't get the ROM to run very reliably when xposed was loaded as magisk module, same for NanoDroid-microG)
[*][COLOR="Red"]TO FIX USB[/COLOR] - Here's the mindf**k: The only way is to dial *#0808# and to opt for AP mode, and in the list that opens you can select what you need, I just enabled everything. Don't press reboot, just go with OK. You will also have to repeat this after every reboot. Thanks for nothing Samsung.
[*]That's it. WiFi, 4G, USB working again, bootscreen is still pixel mash but that's not too essential anyways. My phone runs very reliably, alarms always trigger correctly and wake me up in time, and I'm happy to keep this device. I might even replace the battery to prolong its life.
[/LIST]
I know that the instructions are a bit on the sparse/expert-level and that I haven't provided download links so far. If you need more information PM me, I can upload any of those files with checksums and everything, and I can elaborate on the instructions. Just thought probably nobody is reading this or whoever is here already threw their phone out of the window. :silly:
Click to expand...
Click to collapse