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!
Related
I need help from wince rom devs here. What I need now? I need all offsets from wince:
- xip start, hip end
- partitions offsets (start/end/type)
- ram start/end (I see from mtty command ramdump, ram offset start is 0x02e40000 but not sure if it is ram addresse becouse photon kernel offset start is 0x200000, so maybe kernel need to be adapted for 0x2e40000 ??
I used tinboot as a bootloader, created nbh image, uploaded it to nand and tried many times to get kernel booting but it could not boot. Also I see nothing in addresse 0x02e40000 after uploading tinboot to nand and (after) ussing mtty ramdump but I created nbh image including tinboot, kernel...etc to offset 0x2e40000 hmm, something is not good! Yes I understand it can not be good becouse I need to create image with proper offsets, edit mbr record...etc. Hmm, or maybe spl have some security check preventing tinboot to execute? I think first step need to be: understanding how it works, what we need, analysing ramdump, analysing RUU_signed.nbh(unpacking it, using only os.nb for analyse, finding all offsets inside...). If you coked roms succesfully and have that skills, please post here all your opinions, tools ...etc. Only hard part is geting kernel boot from nand, other parts is easy (creating system, data, cache partition)
Some interested links:
- emulating mtd device -> http://minimodding.com/tiki-index.php?page=ImageAccess
- best tutorial I seen (but not understand some parts like how to find xip start/end...offsets is problem!) -> http://forum.ppcgeeks.com/cdma-tp-development/70776-how-tos-developing-ii.html#post989528
- small bootloader (need to be adapted for photon!) -> http://www.neopeek.com/viewtopic.php?f=75&t=2319
Maybe you know where exist some tools for editing ram image, msflash, htc mbr...etc??
Maybe you have some friends who have skils with rom coking?
Maybe asking Cotulla (donating him also) for help? Whether you are willing to donate if he agrees to help?
Maybe mskip will help here?
All help is welcome!
I not know, but maybe dumping haret parts (including tags, boot, kernel, initrd) from memory, and porting it to nbh? Hmm, good idea , I will try
Some interesting links how to dump xip (hmm if successfully dump xip I will search for offsets in mtd dump... also partitions...etc) -> http://forum.xda-developers.com/showthread.php?t=616995
When we found all offsets it will be maybe easy to create android nbh (tinbot, kernel and initrd only - for probe... if success boot, than porting android to nand)
Start from porting LK bootloader
http://htc-linux.org/wiki/index.php?title=LK_Bootloader
get the one from codeaurora git. You may need to make adjustments to make it work on non-android msm7225. Maybe porting our fork for 7200A is easier. Depends on the AMSS (radio) version in your device.
this tree https://gitorious.org/lk-msm7200a-htc-wince/tinboot-for-lk-xda/trees/master contains the tinboot-based wrapper and scripts to embed LK bootloader binary into an NBH flashable to wince devices
sorry I cannot help you more here since I don't have photon and time to work on it, but if you spend more time reading htc-linux irc logs, you'll figure it out yourself
As for the boot address, it should be the same as in haret. Typically, 0x10000000
I need lk? Is possible using only tinboot to boot kernel? I tried to boot only kernel and zimage! Boot adrese for photon/haret is 0x200000
munjeni said:
I need lk? Is possible using only tinboot to boot kernel? I tried to boot only kernel and zimage! Boot adrese for photon/haret is 0x200000
Click to expand...
Click to collapse
tinboot sucks if not to say more. It is a nice thing on its own and is a great work from dzo but it is extremely annoying to make nand roms with it and you can get into serious problems like boot loop. LK gives nice features
1. fastboot protocol for flashing and recovery so you can just use OTA updates in CM7 like native devices
2. you can implement reboot to bootloader/reboot to recovery
3. it passes partition layout via ATAGs to kernel
4. you can enable some hardware (clocks, vregs) and be able to use single kernel for nand and haret
and most importantly, you can easily implement basic battery charging in LK. with tinboot, you can easily get stuck in the boot loop if you completely discharge your battery
ok I agre LK is better but we have not any android nand bootloader! I think smal bootloader will be best choice for first nand boot. Than porting LK bootloader after tinboot becouse tinboot is smaler and easy for the first test. Are you sure nand boot is possible? We not have hspl, we have perfect bootloader (spl)?? But tinboot have also option adding partition layout via ATAGs to kernel but I not care about partitions, only I was tried is to see black screen with white text dmesg in fb console (only kernel and initrd without nand partitioning) but I had no luck. Also, another thing, I no longer have a photon, I have now hd2 and try to figure out how everything works on it. Hehe, I can say that I was more comfortable with its compact photon (very fast android is in him, also colors is better in photon compared with the hd2!), hd2 phone is too big like as a building brick... maybe I will buy again photon
The only drawback is that there is not little support for photon by experienced developers, although the extra good phone, and I'm sorry about that!
You are right, I compiled LK from source and it runing ok in hd2, will try to port it to photon, thank you! There is also explanations for mbr record...etc...
photon nand is here:
http://pastebin.com/xAhnEXBU
djfastest said:
photon nand is here:
http://pastebin.com/xAhnEXBU
Click to expand...
Click to collapse
Yes, I created that paste and it is nand blocks! Os.nb start 0x02820000 block=321 from there is mbr...
munjeni said:
Yes, I created that paste and it is nand blocks! Os.nb start 0x02820000 block=321 from there is mbr...
Click to expand...
Click to collapse
munjeni: sspl
djfastest said:
munjeni- maybe this link be information
one man cah help
http://tiad8.com/nand-test-builds/455-nand-htc-hd-mini-android.html
Click to expand...
Click to collapse
you think this -> http://forum.xda-developers.com/showthread.php?t=1259659
i dont mind to try it but where's the nbh? and what ruu to use?
You need http://forum.xda-developers.com/showpost.php?p=18026197&postcount=10 and you need dft sspl. Also you need (after test attacment) to install wince rom but before you trying to install my attacment be sure to have an htc rom. Dft is one post before
munjeni said:
you think this -> http://forum.xda-developers.com/showthread.php?t=1259659
EDIT:
I created nbh image (only kernel), anyone want to try? If want, install RUU_signed.nbh with dft sspl and please let me know if you see black screen with white text on your screen after booting.
WARNING: do not try installing if you not have your favorite wince rom (original htc installer), becouse it will overwrite your wince rom!! Need testers! How to install wince again? Simple run your rom installer and all will back again to normal! It will not brick your device, it is safe, but you need to have original htc installer to install wince again!
Click to expand...
Click to collapse
OK i tested your boot .
The bootloader works well but remain in the white screen with green HTC, not black screen with white text.
Coming back to WM Rom. If you want i can test more changes today or tomorrow .
I think you are in the right way.
EDIT: WM again without problems. Good work munjeni.
Thank you!
It is possible to load in two ways - having collected nbh through враппер or харетом with such command line:
set ramsize 0x08000000
set ramaddr 0x00000000
set KERNEL lk.bin
set MTYPE 2006//well in general - everything, lk it isn't necessary, but харет it is necessary to deceive
set TAGS_OFFSET 0x300000
set KERNEL_OFFSET 0x00000000
pfw 0xa8250800 0//to disconnect MPU (protection of operative memory)
boot2
---------- Post added at 10:49 AM ---------- Previous post was at 10:37 AM ----------
sorry if you not understand what I posted here, google translate is BAD
how to start:
Start by reading http://htc-linux.org/wiki/index.php?title=LK_Bootloader
download original butloder (there is a link), then - for our wince device with gitorious, as well as
https://gitorious.org/lk-msm7200a-htc-wince...boot-for-lk-xda - wrapper to generate the nbh files vindovyh butlodera.
I do not know what to rpc and smem hd mini and how it is similar to the android, so I compare with the original butloder lk and see what's what. Rather, it is enough to copy all the stupid, that we have done for the 7200A, or even juzat it, despite the fact that you have a 7225 or 7227 - the code to control the CPU speed is not there, and everything else in these same SoC. So take my lk with gitorious, add your claret as has been done to htckovsky and htcrhodium. Carefully check the file target/msm7200a_htc_wince/init.c - it is necessary to check that the address is read from the model name devaysa, sure. here.
sorry if you not understand what I posted here, google translate is BAD
Did you tried...? Hmmm pfw 0xa8250800 0 ?? Maybe MPU realy need to be disabled before boot? Ok, but why zImage/haret not need mpu disabling? What address is for mpu? Where you found that info about haret/lk/mpu ?? Have link? Also, maybe problem is: we need new radio (I tried magldr in hd2 phone with new radio and magldr could not boot if you not have old radio!!!)...so hard job will be geting tinboot or lk working!
See memory map
Code:
v=virtual
p=physhical
==========================================================
v80000000-8cb00000 -> p00100000-0cc00000 cb00000
v8cb00000-8cc00000 -> p00000000-00100000 100000
v8cc00000-8cd00000 -> p0ff00000-10000000 100000
v8cd00000-8da00000 -> p0f200000-0ff00000 d00000
v90000000-90100000 -> p98000000-98100000 100000
v90100000-90200000 -> p9c000000-9c100000 100000
v90200000-90f00000 -> pac000000-acd00000 d00000
v90f00000-91000000 -> pa0e00000-a0f00000 100000
v91000000-91100000 -> pa0d00000-a0e00000 100000
v91100000-91200000 -> pa0d00000-a0e00000 100000
v91200000-91300000 -> pa0c00000-a0d00000 100000
v91300000-91500000 -> pa0a00000-a0c00000 200000
v91500000-91600000 -> pa0800000-a0900000 100000
v91600000-91700000 -> pa0700000-a0800000 100000
v91700000-91800000 -> pa0600000-a0700000 100000
v91800000-91900000 -> pa0500000-a0600000 100000
v91900000-91a00000 -> pa0400000-a0500000 100000
v91a00000-91c00000 -> pa0200000-a0400000 200000
v91c00000-91d00000 -> pa0100000-a0200000 100000
v91d00000-91e00000 -> pa0000000-a0100000 100000
v91e00000-91f00000 -> paa600000-aa700000 100000
v91f00000-92000000 -> paa500000-aa600000 100000
v92000000-92100000 -> paa300000-aa400000 100000
v92100000-92200000 -> pa8100000-a8200000 100000
v92200000-92300000 -> pa9d00000-a9e00000 100000
v92300000-92400000 -> pa9900000-a9a00000 100000
v92400000-92500000 -> pa8700000-a8800000 100000
v92500000-92600000 -> paa200000-aa300000 100000
v92600000-92700000 -> pa9c00000-a9d00000 100000
v92700000-92800000 -> pa9b00000-a9c00000 100000
v92800000-92900000 -> pa9a00000-a9b00000 100000
v92900000-92a00000 -> pa9800000-a9900000 100000
v92a00000-92b00000 -> pa9700000-a9800000 100000
v92b00000-92c00000 -> pa9600000-a9700000 100000
v92c00000-92d00000 -> pa9500000-a9600000 100000
v92d00000-92e00000 -> pa9400000-a9500000 100000
v92e00000-92f00000 -> pa9300000-a9400000 100000
v92f00000-93000000 -> pa9200000-a9300000 100000
v93000000-93100000 -> pa9100000-a9200000 100000
v93100000-93200000 -> pa9000000-a9100000 100000
v93200000-93300000 -> pa8800000-a8900000 100000
v93300000-93400000 -> pa8600000-a8700000 100000
v93400000-93500000 -> pa8500000-a8600000 100000
v93500000-93600000 -> pa8300000-a8400000 100000
v93600000-93700000 -> pa8200000-a8300000 100000
v93700000-93800000 -> pa8200000-a8300000 100000
v93800000-93900000 -> pa8200000-a8300000 100000
v93900000-93a00000 -> pa8200000-a8300000 100000
v93a00000-93b00000 -> pa8200000-a8300000 100000
v93b00000-93c00000 -> pa8000000-a8100000 100000
v93c00000-94100000 -> pc0000000-c0500000 500000
v94100000-94200000 -> p80100000-80200000 100000
v96000000-96200000 -> p88000000-88200000 200000
v96200000-98000000 -> p20000000-21e00000 1e00000
v98000000-98200000 -> p8c000000-8c200000 200000
v98200000-9a000000 -> p21e00000-23c00000 1e00000
v9a000000-9a200000 -> p90000000-90200000 200000
v9a200000-9c000000 -> p23c00000-25a00000 1e00000
v9c000000-9c100000 -> p94000000-94100000 100000
v9c100000-9d000000 -> p25a00000-26900000 f00000
v9d000000-9d100000 -> p98000000-98100000 100000
v9d100000-9e000000 -> p26900000-27800000 f00000
v9e000000-9e200000 -> p9c000000-9c200000 200000
v9e200000-9ea00000 -> p27800000-28000000 800000
v9f000000-9f100000 -> p80000000-80100000 100000
vf0400000-f0500000 -> p00000000-00100000 100000
vfffd0000-fffd4000 -> p01a10000-01a14000 4000
vffff0000-ffff1000 -> p01a14000-01a15000 1000
vffffc000-ffffd000 -> p01a15000-01a16000 1000
Also zImage from haret is loaded to 0x200000 ...etc
Also disabling memory protection is risic becouse if you disable memory protection maybe you overwrite spl (brick your device)... so I think disabling mpu is not necesarry!
Also I found good nbh generator (auto generate mbr record, 0xff bute, auto size "proper size"...etc), also there is explanation how mbr record working, how to calculate partition size and add to mbr...etc...etc:
Code:
/*
* nbgen.c
*
* Created on: Mar 22, 2011
* Author: cedesmith
*/
#include <sys/stat.h>
#include <stdlib.h>
#include <stdio.h>
#include <strings.h>
#include <string.h>
#include <stdint.h>
struct NbgPart
{
char* fileName;
int start;
int end;
};
struct NbgData
{
char header[2*0x800];
int noParts;
struct NbgPart parts[16];
};
struct NbgData data;
struct PartEntry {
uint8_t BootInd;
uint8_t FirstHead;
uint8_t FirstSector;
uint8_t FirstTrack;
uint8_t FileSystem;
uint8_t LastHead;
uint8_t LastSector;
uint8_t LastTrack;
uint32_t StartSector;
uint32_t TotalSectors;
};
//#define blocks(x)((x)/0x20000+((x)%0x20000!=0?1:0))
void save(char* file, int nb);
int blocks(size_t bytes);
void PartSetCHS(struct PartEntry* part);
int main(int argc, char* argv[])
{
printf("nbgen v1.0 by cedesmith\n");
if(argc<2){
fprintf(stderr, " Usage: os.nb|os.payload\n", argv[0]);
return 1;
}
struct stat st;
if(stat("lk.bin", &st)!=0){
fprintf(stderr, "lk.bin not found\n", argv[1]);
return 3;
}
data.parts[0].fileName="lk.bin";
data.parts[0].start=2;
data.parts[0].end=blocks(st.st_size+0x800*2)*64;
data.noParts++;
//make file header
memset(data.header, 0, 0x800); //fill 1st sector with 00
data.header[0]=0xE9; //fill signature bytes
data.header[1]=0xFD;
data.header[2]=0xFF;
data.header[512-2]=0x55;
data.header[512-1]=0xAA;
//write partition
struct PartEntry* part = (struct PartEntry*)(data.header+0x1BE);
part->BootInd=0;
part->FileSystem=0x23;
part->StartSector=data.parts[0].start;
part->TotalSectors=data.parts[0].end-data.parts[0].start;
//cardsharing-x:
printf("part->BootInd=%x\n", part->BootInd);
printf("part->FileSystem=%x\n", part->FileSystem);
printf("part->StartSector=%x\n", part->StartSector);
printf("part->TotalSectors=%x\n", part->TotalSectors);
PartSetCHS(part);
//write MSFLASH50
memset(data.header+0x800, 0xFF, 0x800); //fill 2nd sector with FF
memset(data.header+0x800, 00, 0x64);
strncpy(data.header+0x800, "MSFLSH50", sizeof("MSFLSH50")-1); //MSFLSH50 signature
//save
int nb=0;
if(strcasecmp(strrchr(argv[1], '.'), ".nb")==0) nb=1;
save(argv[1], nb);
return 0;
}
void PartSetCHS(struct PartEntry* part)
{
uint32_t first=part->StartSector, last=part->StartSector+part->TotalSectors-1;
part->FirstHead=(uint8_t)(first%0x40 & 0xFF);
part->FirstTrack=(uint8_t)(first/0x40 & 0xFF);
part->FirstSector=(uint8_t)(((((first/0x40)>>8)<<6) & 0xFF)+1);
part->LastHead=(uint8_t) (last%0x40 & 0xFF);
part->LastTrack=(uint8_t)(last/0x40 & 0xFF);
part->LastSector=(uint8_t)(((((last/40)>>8)<<6) & 0xFF)+1);
//cardsharing-x:
printf("first head=%02x\n", part->FirstHead);
printf("first track=%02x\n", part->FirstTrack);
printf("first sector=%02x\n", part->FirstSector);
printf("last head=%02x\n", part->LastHead);
printf("last track=%02x\n", part->LastTrack);
printf("last sector=%02x\n", part->LastSector);
}
int blocks(size_t bytes)
{
// 1 physical nand block = 64 sectors = 0x20000 bytes
return bytes/0x20000+(bytes%0x20000!=0 ? 1 : 0);
}
void writetag(uint32_t no, uint32_t tag, FILE* out)
{
fwrite(&no, sizeof(no), 1, out);
fwrite(&tag, sizeof(tag), 1, out);
}
void save(char* file, int nb)
{
FILE* out=fopen(file, "w");
if(out==NULL){
fprintf(stderr, "failed to open %s\n", file);
exit(20);
}
uint32_t sectorNo=0x0, tag=0xFFFBFFFD;
// write file header block
fwrite(data.header, 1, 0x800, out);
if(nb) writetag(sectorNo, tag, out);
sectorNo++;
//write MSFLASH50 block
fwrite(data.header+0x800, 1, 0x800, out);
if(nb) writetag(sectorNo, tag, out);
sectorNo++;
char sector[0x800];
for(int i=0; i<data.noParts; i++){
struct NbgPart* part=&data.parts[i];
//write empty sectors before part
memset(sector, 0xFF, 0x800);
for(int is=sectorNo; is<part->start; is++){
fwrite(sector, 0x800, 1, out);
if(nb) writetag(0xFFFFFFFF, 0xFFFFFFFF, out);
sectorNo++;
}
//write part from file
printf("writing %s\n", part->fileName);
FILE* in=fopen(part->fileName, "r");
if(in==NULL){
fprintf(stderr, "Failed to open %s\n", part->fileName);
exit(21);
}
while(!feof(in)){
int readed=0;
memset(sector, 0xFF, 0x800);
while(!feof(in) && readed<0x800) readed+=fread(sector+readed, 1, 0x800-readed, in);
fwrite(sector, 0x800, 1, out);
if(nb){
tag=0xFFFFFFFF;
for(int ib=0; ib<0x800; ib++)
if(sector[ib]!=0xFF)
tag=(i==0?0xFFFBFFFD:0xFFFBFFFF);
if(tag!=0xFFFFFFFF) writetag(sectorNo, tag, out);
else writetag(0xFFFFFFFF, 0xFFFFFFFF, out);
}
sectorNo++;
}
fclose(in);
//printf("write empty sectors from %d to %d\n", sectorNo, part->end);
//write empty sectors at the end
memset(sector, 0xFF, 0x800);
for(int is=sectorNo; is<part->end; is++){
fwrite(sector, 0x800, 1, out);
if(nb) writetag(0xFFFFFFFF, 0xFFFFFFFF, out);
sectorNo++;
}
} //for(int i=0; i<data.noParts; i++)
fclose(out);
}
But huh huh no way to see my zImage boot (black screen with white text) , maybe protection is very good (radio or spl or something other or I am wrong with something, wrong offsets?)
Also lk bootloader is bassed on kernel, so I no want to use lk now, I want first to see my zImage with tinboot, if I see my zImage booting I will try to port lk. I will add asm for mpu but I can not try it and I can not responsible if you brick your device. I will use my phone back to try with nbgen again
munjeni,
Please try to build lk and get it working on hd mini. The thing is that your radio is very similiar to the one we have on msm7200A and since we have spent much time getting it to work on msm7200A and have fixed most obvious bugs, it is unwise to ignore this work.
You do not need to disable MPU because haret loads linux to 0x1000_0000 and LK is loaded to 0x0 to allow it to load kernel to 0x1000_0000 and further without erasing LK itself in RAM.
LK is not based on linux. In fact, you should read the source code of our lk port to wince devices prior to making assumptions about how stuff is supposed to work. You can probably use cedesmith's nbh generator, but my modified tinboot tree also contains the utility to do it. And it quite works for htc kovsky.
One problem is that you cannot just boot the haret kernel from nand. You will have to fix some rpc issues (time_remote handler at least) and never touch uart[1-3] clocks, otherwise the arm9 will just crash on boot. My LK (on gitorious) contains enough initialization code to use the same kernel on haret and nand provided that you fix rpc issues. In fact, I'd advise to try just adding your board and display init code to the msm7200A target of my LK.
Good luck with that. Sorry I cannot help you more since I do not have an HD Mini myself.
Hey dude, thanks, do you want hd mini? Maybe our users donate you to buy hd mini? I have hd2 and hd2 is not interested phone to me like hd mini...hd mini is the best phone I used (small, compact, fast, have all needed, have wince, have android, have linux Debian...etc)...hd2 is big phone (notebook in pocket )... I will back to photon if we get nand boot!
Why haret kernel and nand kernel is not the same, I not understand (haret load it to memory, nand kernel is in memory, what is diference)?
Munjeni link to: https://gitorious.org/lk-msm7200a-htc-wince/tinboot-for-lk-xda/trees/master
sp3dev said:
munjeni,
Please try to build lk and get it working on hd mini. The thing is that your radio is very similiar to the one we have on msm7200A and since we have spent much time getting it to work on msm7200A and have fixed most obvious bugs, it is unwise to ignore this work.
You do not need to disable MPU because haret loads linux to 0x1000_0000 and LK is loaded to 0x0 to allow it to load kernel to 0x1000_0000 and further without erasing LK itself in RAM.
LK is not based on linux. In fact, you should read the source code of our lk port to wince devices prior to making assumptions about how stuff is supposed to work. You can probably use cedesmith's nbh generator, but my modified tinboot tree also contains the utility to do it. And it quite works for htc kovsky.
One problem is that you cannot just boot the haret kernel from nand. You will have to fix some rpc issues (time_remote handler at least) and never touch uart[1-3] clocks, otherwise the arm9 will just crash on boot. My LK (on gitorious) contains enough initialization code to use the same kernel on haret and nand provided that you fix rpc issues. In fact, I'd advise to try just adding your board and display init code to the msm7200A target of my LK.
Good luck with that. Sorry I cannot help you more since I do not have an HD Mini myself.
Click to expand...
Click to collapse
munjeni said:
Hey dude, thanks, do you want hd mini? Maybe our users donate you to buy hd mini? I have hd2 and hd2 is not interested phone to me like hd mini...hd mini is the best phone I used (small, compact, fast, have all needed, have wince, have android, have linux Debian...etc)...hd2 is big phone (notebook in pocket )... I will back to photon if we get nand boot!
Why haret kernel and nand kernel is not the same, I not understand (haret load it to memory, nand kernel is in memory, what is diference)?
Click to expand...
Click to collapse
Please do not quote me becouse you use whole page with your post! Also you posted attacment (I not understand what with that)
Original thread by hashcode for RAZR http://forum.xda-developers.com/showthread.php?t=2181971
Here is a copy paste.
Hashcode said:
** WARNING: THIS THREAD SHOULD BE FOR KERNEL DEVELOPERS OR ROM DEVS.
Users please post questions in your ROM's support threads. **
** DEVS: If you choose to use a kexec kernel in your ROM add a "KERNEL CREDIT" for the first 4 people in the "WHO HAS WORKED ON THIS?" section below. This has been spectacular development and credit is due. **
TESTING ROMS FOR KEXEC KERNEL PROGRESS:
Droid RAZR:
[2013-03-12] cm-10.1 on v3.0.8 JB kernel:link removed for safety
GSM RAZR:
cm-10.1 on v3.0.8: link removed for safety
MAPPHONE 3.0.x KEXEC KERNEL:
For use on Motorola devices; Droid RAZR, GSM RAZR, RAZR MAXX, Bionic and Droid 4. (1 GB OMAP4 devices for now, 512MB support coming).
WHAT IS A KERNEL?
Also from Wikipedia: http://en.wikipedia.org/wiki/Kernel_%28computing%29
Summary: If you had to choose 1 binary file which connects the hardware components of your device to the OS layer whether it be Android or some other software, it would be the kernel.
WHAT IS KEXEC?
The best description is found here on Wikipedia: http://en.wikipedia.org/wiki/Kexec
Summary: kexec is a process for hot reloading a new kernel while a device is running.
WHERE DID THIS KERNEL COME FROM?
Initially the source came from Motorola. All GPL components of Android are posted on Sourceforge.net for Motorola devices:
http://sourceforge.net/motorola/
After that it's been worked on (see below) to support kexec function and work for our needs.
WHO HAS WORKED ON THIS?
Several people played a large role in making this happen:
Kholk & [MBM]: Initial development work done on the RAZR/Bionic under Gingerbread to setup kexec modules + booting kexec kernel (no 2nd cpu)
jonpry: Ported and improved Kholk/MBM's work for use on the Droid 3. Brought up 2nd CPU, fixes for audio and more.
Hashcode (myself): On going development of this kernel for flawless function on our devices.
A full kernel source history on github starting with omapzoom sources and migrating Motorola source in commit by commit
Fixes for clocks, local timers, GPMC setup, race conditions in irq's due to kexec and more.
On going development towards full support for current Android / Ubuntu Phone OS requirements (including 512MB and Droid 3 support).
Other's have also contributed code (and hopefully more will as well): kfazz(D4), jarveson(D3) and more.
WHERE IS THE SOURCE?
KERNEL SOURCES (ALL DEVICES):
https://github.com/STS-Dev-Team/kernel_mapphone_kexec
BRANCH: stock-ics-kexec
DESCRIPTION: This is a perfect copy of the ICS kernel running as kexec. For use with stock-based ROM's etc.
STATUS: Ready for use
BRANCH: jb-mr1
DESCRIPTION: Ongoing kernel branch for support of newer Android OS (Jellybean MR1 currently).
STATUS: Work-in-progress. Heavy development
KEXEC KERNEL-MODULE SOURCES FOR ICS/JB BASED DEVICES:
https://github.com/STS-Dev-Team/kernel_kexec_modules/tree/3.0.8-ics-spyder
Branch: 3.0.8-ics-spyder
Defconfig: mapphone_kexec_defconfig
KEXEC KERNEL-MODULE SOURCES FOR GB BASED DEVICES (Droid 3):
https://github.com/STS-Dev-Team/kernel_kexec_modules/tree/2.6.35-solana/
Branch: 2.6.35-solana
Defconfig: mapphone_defconfig
HOW TO KEXEC A DEVICE
1. Download kexec kernel modules + kexec binary for your base kernel version
(Most devices found here):
https://github.com/STS-Dev-Team/android_device_motorola_omap4-kexec-common/tree/cm-10.1/kexec
(Droid 3 Users need GB based modules here):
https://github.com/STS-Dev-Team/android_device_motorola_solana/tree/jb-mr1/kexec
2. Download the devtree for your device:
Droid RAZR: https://github.com/STS-Dev-Team/android_device_motorola_spyder/tree/jb-mr1/kexec
GSM RAZR: https://github.com/STS-Dev-Team/android_device_motorola_umts_spyder/tree/jb-mr1/kexec
Bionic: https://github.com/STS-Dev-Team/android_device_motorola_targa/tree/jb-mr1/kexec
Droid 4: https://github.com/STS-Dev-Team/android_device_motorola_maserati/tree/jb-mr1/kexec
Droid 3: Droid 4: https://github.com/STS-Dev-Team/android_device_motorola_solana/tree/jb-mr1/kexec
3. Need a kexec kernel binary from the above sources: renamed the zImage as "kernel".
4. Need a .gz cpio ramdisk named: ramdisk.img
**RAMDISK needs to take care of mounting related filesystems for your ROM.
Ususally Safestrap/BMM handles this in some way for rom-slots.
For easy kexec tests you can build a CWM ramdisk and use that.
Now boot up into a safe kexec point on the device be it BMM or Safestrap where you can use adb.
5. Move all of the above files onto the rootfs
6. Execute the following as a script:
Code:
# run this from a "safe" boot point (safestrap / bootmanager) where no mounts are active
cd /
chmod 755 /kexec
# you will lose USB function here till the new kernel boots -- hence the script
insmod /uart.ko
insmod /arm_kexec.ko
insmod /kexec.ko
/kexec -l /kernel --devtree=/devtree --ramdisk=/ramdisk.img
sleep 1
/kexec -e
CURRENT DEVELOPMENT ROAD MAP
Merge up to Linux Mainline v3.0.21 + Google kernel/common commits (where applicable)
Cherry-pick from TI's kernel tag 4AI.1.5 to 4.AI.1.6
Merge up to Linux Mainline v3.0.31 + Google kernel/common commits (where applicable)
Cherry-pick from TI's kernel tag 4AI.1.6 to 4.AI.1.7
Also pick up any p-android-omap-3.0 and p-android-omap-3.0-dev commits where needed
Merge up to current Linux Mainline + Google kernel/common commits (where applicable)
Click to expand...
Click to collapse
Currently, there is one kexec based rom for Atrix 2 CM10.1 by wanggjghost here.
Source Code for Atrix 2 http://sourceforge.net/projects/atrix2.motorola/files/
and http://sourceforge.net/projects/me865.motorola/files/ME865/
Other source code that can help you wanggjghost's github https://github.com/SunRain/android_device_motorola_edison
ISSUES TO BE SOLVED
The current major issue regarding Kexec is that some devices get a black screen once kexec is executed.
This thread to discuss and develop a solution for it. And once that is solved, to discuss custom kernels.
Here are a few things that might help.
kmsg when kexec boot up failed: http://www.mediafire.com/download.php?95raby988dvch74 (just open it with a text editor. It is corrupt but you can make out quite a lot.)
The dmesg for stock ics: http://www.mediafire.com/view/?z4pibf2at3u4i7e (Going through this will give you better idea as how things should be.)
And the panic msg after I soft reset it after a black screen: http://www.mediafire.com/view/?z4pibf2at3u4i7e (When I get a black sscreen, I hold vol up+ vol down+ pow for about 10 secs. that soft resets my phone and a panic msg is generated which I retrieve.)
From the kmsg, here is something interesting that appears to be the cause. (Note: I have made some edits to make it readable, not completely readable though.)
Code:
[ 2.745880,0] cannot apply mgr(lcd) on inactive device
[ 2.745971, ] omapfb omapfb: failed to apply dispc config
[ ².·46893¬0] cannot apply mgr(tv) on inactive device
[ 2.746154,0] omapfb omapfb: failed to apply dispc config
[ 2.746307,0] cannot aplly mgr(lcd2) on inactive(device
[ 2.7463¶8,0\ omapfb omapfb: failed to apply dispc config
[ 2.746520,0] DSI: dsi_fc_kmd = 0, dói_vc_video 9 1
[ 2®746582,0] DT: x_res=540 y_res=960 phy_w_mm=54 phy_h_mm=95
[ 2.·46673,0](ÄT: hfp=0 hsw=² hbp-2 vnp=0 ösw=1 vbp=1
[ 2®746795,0] DTº cìk_lanå=1 clk_pos90 d1_line=2 d1_pos=0 d2_lane=3 d2_pos=0
[ 2.746948,0](DT: d3_lane=0 d3_pos=0 d4_lane=0 d4_pos=0
[ ².747009,0] DT: panel_id= x1a000² type= 0
[ 2.747102,0] DT: regn=13 regm=230 regm3=6 regm4=6 lp_clk_div=9 lck_div=1 pck_div=4
[ 2.747222,0] DT: te_support=1, te_type=0
[ 2.747283,0] DT: number of power suppljes-±
[ 2.747436,0] DT: Supply #°, beg name=sw4, gpin=96,*gpio_en_val=1
[ 2.(43¸57,0] mmc2: card claims to support voltages below the defined range. These will be ignored.
[ 2.860656,0] omapdss DSI error: Failed to receive BTA
[ *2.861816,0] mmc2: quduing unknïwn CIS tupìe 0x99 (3 jytms)*[( 2.862792¬0] mmc2: .%w high speeä RDIG kard at address 0001
[ 2.962280,0] omapdss DSI error: Failed to receive BTA
[ 3.063781,0] omapdss DSI error: Failed to receive BTA
[ "3®091705,0] mmc0: host doås(not cupport reiding re!d-onlù switch. assuminç write-enable.
[ 3.0)5336,0] míc0: new hkgh speed SDHC cabd at address aaaa
[ 3.896496,0] mmcblk0:(mmc0:aaaa SU16G 14.8 GiB
[ 3®101·76,0] mmcblk : p1
[" 3.165374,0] omapdss DS (error: Fa)led to receire BTA
[ 3.26693',0] omapnss DSI error: Failed to rekeivm(BTA*[ ¨ 3®368538,0] kmapdss DS) ebror: Failed to receivm BTA
[ 3.<78062¬0Y omapdss DSI error: Failed to receive BTI
[ "3.571624,0] omapdss DSI error:(Failed to receive BTA
[ 3*673217,0](oma0dss DSI ezror: Failed to receive BTA
[ ³.774749,0] omapdss DSI error: Fâile` to rekeive BTA
[ 3.¸76312,0\ om!pdss SI erro2: Failed to receive BTA
[ 3.876556,0] check_mapxjone_panel_present: Faineä to recmive BTA ACK foz 10 times.
[ 3.877014,0] marphone_xanel_power_on:Paneì és not attached nò failed ðo send BTA.*[ 3.8772¸8,0] omapfb omapfb: Fáile$ to enable display 'lcd'
[ 3.¸77746,0] kmapfb omapfb: failed to inkpialize default display
[ 3.¸79821,0] omarfb omapfb: failed |o se4up omapf"Š[ 3.¸80279,0] omapfb: probe of omapfb fa)led with error -22
[ 3.882019,0] regulator_init_complete: vwlan1: disibling
[ " 3.882873,0] begulat/r_inét_complete: vrfref: dhsabling
[ 3.883544,0] renulator_init_coíphete: vbf²: disabling
Z 3.8:7145,0] regulator_check_voltage: v5sb: operation not allowed
[ 3.:91937,0] lm3532_bl_work: Display backlight(disable)
The issue appers to be regarding omapfb (frame buffers). might be an issue with the command line. wang's kernel uses
Code:
root=/dev/ram0 rw [email protected] console=null vram=10300K omapfb.vram=0:8256K,1:4K,2:2040K init=/init ip=off mmcparts=mmcblk1:p7(pds),p15(boot),p16(recovery),p17(cdrom),p18(misc),p19(cid),p20(kpanic),p21(system),p22(cache),p23(preinstall),p24(webtop),p25(userdata),p26(emstorage) mot_sst=1 androidboot.bootloader=0x0A74
However, using
Code:
root=/dev/ram0 rw [email protected] console=ttyO2,115200n8 init=/init ip=off mmcparts=mmcblk1:p7(pds),p15(boot),p16(recovery),p17(cdrom),p18(misc),p19(cid),p20(kpanic),p21(system),p22(cache),p23(preinstall),p24(webtop),p25(userdata) mot_sst=1 androidboot.bootloader=0x0A73
might solve.
Also, the following keeps repeating
Code:
PVR_K:(error):BridgedDispatchKM: Initialisation failed. Driver unusable
but PVR_K is related to display (I guess) and that again takes us back to omapfb.
Put in your thoughts as well but try to keep the thread clean.
Here's another panic log: http://pastebin.com/TdU31ERU
Regarding the "PVR_K: (Error): BridgedDispatchKM: Initialisation failed. Driver unusable." error that Ravi pointed out... and for my curiosity..
Can someone who has the kexec build running run these from a command line, please? (and post the output here):
Code:
adb shell
cat /proc/pvr/version
strings vendor/lib/egl/libGLESv2_POWERVR_SGX540_120.so | grep build
$ adb shell
* daemon not running. starting it now on port 5038 *
* daemon started successfully *
error: device not found
$ cat /proc/pvr/version
Version SGX_DDK_Android sgxddk 19 [email protected] (release) omap4430_android
System Version String: SGX revision = 1.2.0
_POWERVR_SGX540_120.so | grep build <
OpenGL ES GLSL ES 1.00 build [email protected]
OpenGL ES 2.0 build [email protected]
$
Sent from my MB865 using xda app-developers app
---------- Post added at 04:41 PM ---------- Previous post was at 04:35 PM ----------
Is that what u need?
Sent from my MB865 using xda app-developers app
jaymccoubrey said:
$ adb shell
* daemon not running. starting it now on port 5038 *
* daemon started successfully *
error: device not found
$ cat /proc/pvr/version
Version SGX_DDK_Android sgxddk 19 [email protected] (release) omap4430_android
System Version String: SGX revision = 1.2.0
_POWERVR_SGX540_120.so | grep build <
OpenGL ES GLSL ES 1.00 build [email protected]
OpenGL ES 2.0 build [email protected]
$
Sent from my MB865 using xda app-developers app
---------- Post added at 04:41 PM ---------- Previous post was at 04:35 PM ----------
Is that what u need?
Sent from my MB865 using xda app-developers app
Click to expand...
Click to collapse
Yup, thanks.. I was just chasing wild geese again..
[Edited to reduce clutter, etc.. ]
So, yea, wild goose chase...
--------------------------
Also, @Ravi - this is my current device BoardConfig:
Code:
# inherit from common
-include device/motorola/omap4-kexec-common/BoardConfigCommon.mk
# inherit from the proprietary version
-include vendor/motorola/edison/BoardConfigVendor.mk
# Processor
TARGET_BOOTLOADER_BOARD_NAME := edison
# Kernel
BOARD_KERNEL_CMDLINE := root=/dev/ram0 rw [email protected] console=null vram=10300K omapfb.vram=0:8256K,1:4K,2:2040K init=/init ip=off mmcparts=mmcblk1:p7(pds),p15(boot),p16(recovery),p17(cdrom),p18(misc),p19(cid),p20(kpanic),p21(system),p22(cache),p23(preinstall),p24(webtop),p25(userdata),p26(emstorage) mot_sst=1 androidboot.bootloader=0x0A72
BOARD_KERNEL_BASE := 0x80000000
BOARD_PAGE_SIZE := 0x4096
# Kernel Build
TARGET_KERNEL_SOURCE := kernel/motorola/omap4-kexec-common
TARGET_KERNEL_CONFIG := mapphone_1GB_defconfig
And I have the same BOARD_KERNEL_CMDLINE in the mapphone_1GB_defconfig.. but pretty sure I have other issues as well. Here's a kmsg from an attempt at booting mine: http://pastebin.com/VZzg0ALD - containing my favorite debug message ever: Bad BP 0[ID: 0x0], Is this a Phone ??
One more thing, take a look at the atags with a hex editor...
Im kimda limited on what i no how to do.. Tell me what to do and how ill do it.
Sent from my MB865 using xda app-developers app
---------- Post added at 06:32 PM ---------- Previous post was at 06:26 PM ----------
I download a hex Editor. Where do i look?
Sent from my MB865 using xda app-developers app
jaymccoubrey said:
Im kimda limited on what i no how to do.. Tell me what to do and how ill do it.
Sent from my MB865 using xda app-developers app
---------- Post added at 06:32 PM ---------- Previous post was at 06:26 PM ----------
I download a hex Editor. Where do i look?
Sent from my MB865 using xda app-developers app
Click to expand...
Click to collapse
Lol.. My ramblings weren't directed at you specifically.. It's just for general (possibly cluttered and useless) info.. And that last note was for Ravi actually - on the topic of board kernel command lines..
Sent from my MB865 using xda app-developers app
So do u need anything else. Ill help cause ur roms kick ass
Sent from my MB865 using xda app-developers app
jaymccoubrey said:
So do u need anything else. Ill help cause ur roms kick ass
Sent from my MB865 using xda app-developers app
Click to expand...
Click to collapse
Thanks.. But I'll post if I need/want to see something else from kexec running..
And this kexec and kernel stuff is new territory for me (well, android is relatively new to me still also..) - so I am just trying to learn/do what I can.. The more getting involved, the merrier.
Sent from my MB865 using xda app-developers app
I just received my dev Atrix 2 today thanks to rvalentin913.
My goal with the device is to get it running alongside our other devices (Droid3, Bionic, RAZR's and Droid 4) so that it can be merged into CM's official devices.
However there does seem to be some missing pieces so to speak in the kernel that I'll be looking to fix over the next few weeks.
I'll try and comment on what I'm seeing in the posts above:
1. "omapdss DSI error: Failed to receive BTA" This indicates that the LCD on some of the devices isn't directly supported by the kernel and/or not being setup correctly by the devtree. Also very likely the cause of a blank screen (obviously).
2. "PVR_Kerror):BridgedDispatchKM: Initialisation failed. Driver unusable" indicates that pvrsrvinit didn't complete the initialization of the SGX libs for 1 reason or another. This could many things here and possibly related to #1. I'll have to run a strace or other tests to see where it's failing.
3. I'm reverting the mem= param back to 1023M in the kexec kernels due to a bug in the way Motorola has the kernel setup. They set the SMC driver memory to 2M, but the driver itself will expand to a minimum of 3M. The way the kernel is setup this area is designated right at the very top of memory. So Motorola probably didn't understand why they were getting odd memory issues when using the 1024 setting (this effectively pushes the SMC area out of the 1GB RAM limit). So they dropped the mem= parameter to 1023 where the SMC driver would set the start of SMC memory to 1021M and drift up to 1024.
4. Also the ATAGS which point to the devtree memory location have a tendancy to be cleared out at the drop of a hat for some reason. And that causes an empty devtree to be read into memory. (IE: Bad BP 0[ID: 0x0], Is this a Phone). I'm also chasing this down to see what clears out this memory area. The first time it was an early cache setup by the SMC driver, but there's somewhere else now as well.
What makes this complicated is that the memory location for the devtree and atags is decided at the point of kexec. So it can be a bit random causing this issue to only occasionally show up.
Anyway, I'll try and post a full thread w/ full support once I get my end up and running on the Atrix 2.
I haven't decided yet how I want to boot the device into a 2nd ROM. Currently Safestrap doesn't use external SD cards for rom-slots and to use the internal area, I would need to play some tricks on the OS using the fuse daemon (treat it like an internal SD card). Personally, I think the internal area gives the best performance and I'm leaning towards this route.
But, I won't make anyone flash over their stock system. Ever.
EDIT: I just read through some of the bootlogs and I'm confused about the end of the one here:
http://www.mediafire.com/view/?z4pibf2at3u4i7e
- "init: cannot execve('/system/bin/debuggerd'): No such file or directory" This looks like an obvious missing file, but I wonder why it's being called in the first place.
- procfs_write: version magic '2.6.35.7 SMP preempt mod_unload ARMv7 ' should be '3.0.8 SMP preempt mod_unload ARMv7 '
- dirty_arm_kexec: version magic '2.6.35.7 SMP preempt mod_unload ARMv7 ' should be '3.0.8 SMP preempt mod_unload ARMv7 '
- dirty_kexec: version magic '2.6.35.7 SMP preempt mod_unload ARMv7 ' should be '3.0.8 SMP preempt mod_unload ARMv7 '
These are GB-based kernel modules built for kexec trying to execute at the end of the log? *boggle*
Hashcode said:
I just received my dev Atrix 2 today thanks to rvalentin913.
Click to expand...
Click to collapse
Nice (I was kinda hoping/guessing it was you).
Will be very glad to see you digging into this phone also. Let me (or any of us) know if you need any assistance..
And thanks again for your major efforts and contributions in general.
Sent from my MB865 using xda app-developers app
Hashcode said:
I haven't decided yet how I want to boot the device into a 2nd ROM. Currently Safestrap doesn't use external SD cards for rom-slots and to use the internal area, I would need to play some tricks on the OS using the fuse daemon (treat it like an internal SD card). Personally, I think the internal area gives the best performance and I'm leaning towards this route.
But, I won't make anyone flash over their stock system. Ever.
Click to expand...
Click to collapse
Sir, the moto guys at China have done that. They mount /data/media as internal sd. i.e., the stock me865 roms have it. I will upload the ramdisk, vold.fstab, vold.fstab.swap and the build.prop when I get to my comp. I tried using 2nd init with the changes in ramdisk, included the fstab files and made the changes in build.prop but that did help me.. let me know if anything else is required.. for bmm, we just mount data for int and the virtual systems are stored there.
And thanks again for all the work you have done..
Sent from my MB865 using Tapatalk 2
Ravikirancg said:
Sir, the moto guys at China have done that. They mount /data/media as internal sd. i.e., the stock me865 roms have it. I will upload the ramdisk, vold.fstab, vold.fstab.swap and the build.prop when I get to my comp. I tried using 2nd init with the changes in ramdisk, included the fstab files and made the changes in build.prop but that did help me.. let me know if anything else is required.. for bmm, we just mount data for int and the virtual systems are stored there.
And thanks again for all the work you have done..
Sent from my MB865 using Tapatalk 2
Click to expand...
Click to collapse
Ah, yep, the /data/media mount is managed via the fuse daemon as a simulated VFAT partition, and needs to have FUSE support in the kernel (easily done in kexec).
Any idea why there are GB kexec modules trying to execute in that log?
Hashcode said:
Ah, yep, the /data/media mount is managed via the fuse daemon as a simulated VFAT partition, and needs to have FUSE support in the kernel (easily done in kexec).
Any idea why there are GB kexec modules trying to execute in that log?
Click to expand...
Click to collapse
ah! It requires a modified kernel as well! Thank you. That was the missing piece when I tried it some months ago. Well any way, the good news is that I have managed to emulate internal sdcard on stock searet. I just need to make out all the necessary changes that need to be made in the build.prop. For now, I just used miui build.prop. So that issue is more or less solved except for att users may have to erase cid to flash the hktw boot.img
EDIT: Well a little more work needs to be done I guess.. just some fc..
regarding the GB modules, maybe I was just experimenting.. since its happening after phone is overclocked, its my doing I guess. I will try loading on stock rom again and will let you know..
and take a look at this. defy having kinda the same issue. http://mcbawse177.appspot.com/pastebin.com/31VLSvyJ
quarx might have an idea on how to solve this.. look at line 1046
alteredlikeness said:
One more thing, take a look at the atags with a hex editor...
Click to expand...
Click to collapse
that was interesting.. well, among the currently supported phones, all have that partition table except XT875. Only that has lbl and lbl_backup like our phone but it has an emstorage at p26 and p27 is sgpt. here (also take a look at the other models listed there.) I was once just trying kexec with all the devtrees and there was one devtree using which, my keypad got lighted up after kexec was executed. with all others, the keypad would turn off and stay as such. I will try them again. Oh and just for fun (if you have moto drivers software installed on comp), download the devtrees for all the devices, replace one of them, turn off phone, turn it back on with kexec enabled, connect the phone to comp and take a look at the drivers that windows install. change the devtree and do it again..
Ravikirancg said:
that was interesting.. well, among the currently supported phones, all have that partition table except XT875. Only that has lbl and lbl_backup like our phone but it has an emstorage at p26 and p27 is sgpt. here (also take a look at the other models listed there.) I was once just trying kexec with all the devtrees and there was one devtree using which, my keypad got lighted up after kexec was executed. with all others, the keypad would turn off and stay as such. I will try them again. Oh and just for fun (if you have moto drivers software installed on comp), download the devtrees for all the devices, replace one of them, turn off phone, turn it back on with kexec enabled, connect the phone to comp and take a look at the drivers that windows install. change the devtree and do it again..
Click to expand...
Click to collapse
Well, about the devtree - I found that wang added this to the finalize_release script that initializes the cmdefy bootmenu recovery (courtesy of Hashcode, apparently):
Code:
#!/sbin/sh
PATH="/system/xbin:/system/bin:/sbin:${PATH}"
DEVTREE_PARTITION=/dev/block/mmcblk1p12
KEXEC_DEVTREE=/system/etc/kexec/devtree
#For kexec boot, we need a special devtree from each phone model
#So dump a devtree
#Note /dev/block/mmcblk1p12 is the devtree partition for edison
#And 65K is enough
#Credits for Hashcode for this info
[ -f $KEXEC_DEVTREE ] && rm -r $KEXEC_DEVTREE
busybox dd if=$DEVTREE_PARTITION of=$KEXEC_DEVTREE bs=1 count=65000
I made it as a stand-alone script that I was running with my attempts at booting my kexec builds with BMM... no luck - but like I said, my current kexec build has other issues as well I think..
alteredlikeness said:
Nice (I was kinda hoping/guessing it was you).
Will be very glad to see you digging into this phone also. Let me (or any of us) know if you need any assistance..
And thanks again for your major efforts and contributions in general.
Sent from my MB865 using xda app-developers app
Click to expand...
Click to collapse
Ditto hash, great to see you grabbing a seat on A2train.
ALL ABOARD. NEXT STOP KEXEC. Please raise your trays. Lock your seat back to comfortable position, and enjoy the ride!
Any help I can bring, I am but a humble servant.
Sent from my MB865 using xda app-developers app
Hmm.. take a look at the tombstone.
http://pastebin.com/4jrTaAbF
Its just an issue with graphics driver? But it did boot up a couple of times.. and how does it boot up on some a2s?
Sent from my MB865 using Tapatalk 2
alteredlikeness said:
Well, about the devtree - I found that wang added this to the finalize_release script that initializes the cmdefy bootmenu recovery (courtesy of Hashcode, apparently):
Code:
#!/sbin/sh
PATH="/system/xbin:/system/bin:/sbin:${PATH}"
DEVTREE_PARTITION=/dev/block/mmcblk1p12
KEXEC_DEVTREE=/system/etc/kexec/devtree
#For kexec boot, we need a special devtree from each phone model
#So dump a devtree
#Note /dev/block/mmcblk1p12 is the devtree partition for edison
#And 65K is enough
#Credits for Hashcode for this info
[ -f $KEXEC_DEVTREE ] && rm -r $KEXEC_DEVTREE
busybox dd if=$DEVTREE_PARTITION of=$KEXEC_DEVTREE bs=1 count=65000
I made it as a stand-alone script that I was running with my attempts at booting my kexec builds with BMM... no luck - but like I said, my current kexec build has other issues as well I think..
Click to expand...
Click to collapse
Actually we were talking about this and it doesn't work. The devtree needs to be chopped off right at the last null in the file (where it starts turning to all "FF" in a hex editor.
I think it would be a great idea to modify this tho so that it does work.
Ravikirancg said:
Hmm.. take a look at the tombstone.
http://pastebin.com/4jrTaAbF
Its just an issue with graphics driver? But it did boot up a couple of times.. and how does it boot up on some a2s?
Sent from my MB865 using Tapatalk 2
Click to expand...
Click to collapse
This error reminds me more of when there is no gralloc.omap4.so symlink in /system/vendor/lib/hw. Doesn't look exactly kexec related.
Hi guys,
I'm here to explain my new fresh app that I tested on my HTC Desire 310 and it's faboulous. His name is...
MTKTransfROM
*What does it do?
- This app will let you do all the process of porting an MTK ROM to your MTK phone without a PC! You can choose a lot of options and method, like signing ZIP, Fix BootLoop/Stuck at Boot Logo and even READ BOOT.IMG DIRECTLY FROM YOUR PHONE and AUTOMATICALLY ADAPT THE ROM FOR YOUR PARTITION (/dev/block/mmcblk0p*)
*What do I have to do?
-All you have to do is select the ZIP ROM, choose chipset and options and then click "Port ROM for your device!". The default chipsets installed are taken on online forums, like XDA and 4pda.ru (thanks a lot for those guides), but you can build your own chipset method with a simple text editor!
*How can I build my chipset method?
-The chipset structure is like: e.g.
Code:
[B]system/bin/vold [/B] (Copy this file from your device)
[B]system/etc[I]/[/I][/B] (Copy entire directory, replacing existing files)
[B][I]-[/I]system/etc/ [/B] (First delete ROM folder and then copy entire folder)
[B]system/lib/libaudio[I]*[/I][/B] (Copy all files that starts with libaudio...)
Then save it as "{THE NAME YOU WANT}.txt" in your SDCard under "MTKTransfROM" named folder (e.g. /storage/sdcard0/MTKTransfROM/mt6589.txt)
*Bugs?
Existing bugs TODO:
-During porting, the UI lags. Don't worry, the app is working. If appears Not Responding error, just wait.
-For now, it's only in English.
*Changelog
**1.2
- Discarded zip4j for problems during extraction, using java.util.zip now
- Fixed Exception on some ROM structures
- Added Exit menu voice if activity doesn't terminate
**1.0
- Initial Release
*Credit
-Kellinwood for his ZipSigner class. Thanks a lot.
Now I need help from you community...
As you can see from Play Store screenshots, it has the "Port boot.img" function. However I'm searching a method to unpack and repack MTK boot.img directly from phone. If someone can help me, I will be the most happy man in the world!
As for now, it's the only thing I need to let this app became perfect!
Google Play Store URL: Click here to be redirected (If it says 1.0, is because it's updating or uploading, I'm writing this post while this app is updating).
P.S. Sorry for my English, I'm Italian.
Can you add support for MT6752 devices?
You can add it yourself putting your custom files in the folder I explained in the tutorial
RacerOttavio97 said:
You can add it yourself putting your custom files in the folder I explained in the tutorial
Click to expand...
Click to collapse
Thanks, I will try it and see if it works :fingers-crossed:
I was thinking of doing something similar with MT6732/52 devices...
[I'd be doing it from recovery as I have almost zero app making abilities]
Have a look at the MTKsplit file in the MTK folder in my sig. for the boot.img (un)pack - it works fine with the 64bit SoC's boot/recovery images - so not sure about the older ones.
HypoTurtle said:
I was thinking of doing something similar with MT6732/52 devices...
[I'd be doing it from recovery as I have almost zero app making abilities]
Have a look at the MTKsplit file in the MTK folder in my sig. for the boot.img (un)pack - it works fine with the 64bit SoC's boot/recovery images - so not sure about the older ones.
Click to expand...
Click to collapse
Thank you HypoTurtle, but I'm searching a tool that run on android phone itself, like a sh script or a linux binary.
RacerOttavio97 said:
Thank you HypoTurtle, but I'm searching a tool that run on android phone itself, like a sh script or a linux binary.
Click to expand...
Click to collapse
MTKsplit can/does run on android itself - thats why I wrote it. It's a sh - primarily using dd to split the boot/recovery. I removed the #! at the top so the same script can be run fron recovery and system (making it default to the shell that calls it - /sbin/sh in recovery and /system/bin/sh in system).
Just tested the MTKsplit against a 6592 recovery.img and it works fine:
Code:
[email protected]_phone:/tmp # ls -la
ls -la
-rwx------ root root 5867520 2015-10-05 16:22 recovery-6592.img
[email protected]_phone:/tmp # MTKsplit recovery-6592 unpack
MTKsplit recovery-6592 unpack
Unpacking recovery-6592 - will only take 30 seconds
All Done...
Command line: f30"
Ramdisk unpacked to /tmp/work
[email protected]_phone:/tmp # ls -la
ls -la
-rw------- root root 4265472 2015-10-05 16:24 kernel
-rw------- root root 512 2015-10-05 16:23 kernel_header
-rw------- root root 2048 2015-10-05 16:23 mtk_header
-rw------- root root 1598976 2015-10-05 16:24 ramdisk.cpio.gz
-rw------- root root 512 2015-10-05 16:24 ramdisk_header
-rwx------ root root 5867520 2015-10-05 16:22 recovery-6592.img
drwx------ root root 2015-10-05 16:24 work
Android sdk
Is it necessary to be the port rom is the same android sdk level of my mobile stock rom ?!
RacerOttavio97 said:
Hi guys,
I'm here to explain my new fresh app that I tested on my HTC Desire 310 and it's faboulous. His name is...
MTKTransfROM
*What does it do?
- This app will let you do all the process of porting an MTK ROM to your MTK phone without a PC! You can choose a lot of options and method, like signing ZIP, Fix BootLoop/Stuck at Boot Logo and even READ BOOT.IMG DIRECTLY FROM YOUR PHONE and AUTOMATICALLY ADAPT THE ROM FOR YOUR PARTITION (/dev/block/mmcblk0p*)
*What do I have to do?
-All you have to do is select the ZIP ROM, choose chipset and options and then click "Port ROM for your device!". The default chipsets installed are taken on online forums, like XDA and 4pda.ru (thanks a lot for those guides), but you can build your own chipset method with a simple text editor!
*How can I build my chipset method?
-The chipset structure is like: e.g.
Then save it as "{THE NAME YOU WANT}.txt" in your SDCard under "MTKTransfROM" named folder (e.g. /storage/sdcard0/MTKTransfROM/mt6589.txt)
*Bugs?
Existing bugs TODO:
-During porting, the UI lags. Don't worry, the app is working. If appears Not Responding error, just wait.
-For now, it's only in English.
*Changelog
**1.2
- Discarded zip4j for problems during extraction, using java.util.zip now
- Fixed Exception on some ROM structures
- Added Exit menu voice if activity doesn't terminate
**1.0
- Initial Release
*Credit
-Kellinwood for his ZipSigner class. Thanks a lot.
Now I need help from you community...
As you can see from Play Store screenshots, it has the "Port boot.img" function. However I'm searching a method to unpack and repack MTK boot.img directly from phone. If someone can help me, I will be the most happy man in the world!
As for now, it's the only thing I need to let this app became perfect!
Google Play Store URL: Click here to be redirected (If it says 1.0, is because it's updating or uploading, I'm writing this post while this app is updating).
P.S. Sorry for my English, I'm Italian.
Click to expand...
Click to collapse
playstore-item not found
what ca i do..??
link not work
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?