Related
New 32A Magic Kernel Patches Thread, Please upgrade to V3 patch!
Apparently HTC have released their kernel sources for the 32A magic @ http://developer.htc.com/
Thank you for your help everyone!
I have just reviewed the HTC kernel source and it looks like HTC actually pulled their thumbs out of their arse! Apart from the two different memory locations below, HTC have also added some logic to their kernel source which will probably be of great benefit to everyone.
There are two differences between my kernel patch and HTC's. They are:
Mine:
VMALLOC_END (PAGE_OFFSET + 0x19200000)
Theirs:
VMALLOC_END (PAGE_OFFSET + 0x20000000)
Mine:
MSM_EBI_SIZE 0x0CE00000
Theirs:
MSM_EBI_SMI32_256MB_SIZE 0x0C600000
You can't really blame me too much for these as they were impossible to reverse engineer. I could only come to a size based on differential calculation from the 32B source.
Also, those who know, will recall that I wasn't too sure about my EBI size.
::ROLOGUE:::
After many countless hours that I have spent bashing away at the keyboard, and many tears of blood, sweat and sorrow, we seem to finally have a booting 32A Kernel which seems to behave properly.
If anybody has any problems with the kernel and/or memory addresses, please can you forward them to me and I will look into it. OR you can post the details here, I'm sure we'll look at it. I'm sad to have to say this, but any memory location problems/kernel errors relating to memory issues are probably my fault. I did the best that I could. I am fairly confident that the memory addresses are correct, although there is that niggling in the back of my mind that there is something not right but judging by the response and dmesg and logcats, I have found no such evidence. If there are any problems with memory addresses and something ends up happening, burning down your house or whatever, I'm not responsible. Sure, I'll be more than happy to fix any mistakes (if there are any), but come on, cut me some slack.
In fact, blame HTC for not releasing the kernel patches (They are legally obliged to). I think that perhaps when they do end up releasing the kernel patches, only then will I find out how good my calculations were and even then, some things you would not be able to found out purely by calculations alone. Also, the memory layout for the 32A kernels is quite the opposite to the 32B kernels. Did they do this on purpose or was it a rush job?
Why HTC, WHY?
:::END:::
Result: GREAT SUCCESS!
What this means for the layman is that we will be able to finally get tethering support and any future kernel developments (ROM features) that are in 32B ROM's and we 32A users could not use them!
Developers, please note, after you apply this kernel patch, you will NOT be able to build 32B kernels from the same source. There have been quite a few forks.
Thank you rayman84 for the help! Special thanks to zinx @Freenode for your awesome diagnostic app to help discover ADSP/Camera!
To everyone with a 32A handset that is looking forward to this, feel free to try compile your own kernel but also remember that things are likely to change as more discoveries are made. If you want a stable 32A kernel with iptables and netfilter with all features working, you're going to have to wait a little longer. I'm working on this as much as I can and ALL help is appreciated from everyone! Fixing the kernel for the 32A platform will benefit everyone! If you feel you can help, please do! Any changes you make or suggestions will be taken seriously.
I have posted my own kernel patch for the latest 2.6.27 kernel. This is still experimental but everything seems to be working!
- - - - - This is for developers only and is very experimental! Backup your files, patch is (un)likely to change. - - - - -
2.6.27 Kernel Patch v2 - Link removed to prevent people downloading this for the time being. Please check the new thread for files.
- - - - - This is for developers only and is very experimental! Backup your files, patch is (un)likely to change. - - - - -
* Changelog:
V3 - COMING SOON
Changed Makefile.boot back to V1 - initrd_phys-y := 0x19A00000
Changed EBI_SIZE to the same size as the HTC released kernel source.
Changed VMALLOC to the same size as the HTC released kernel source.
V2
Changed Makefile.boot - changed to initrd_phys-y := 0x1A200000 (credit to rayman84)
---------------------------------------------------------------------------------------------------------------------
Credits:
* TigerTael - That's me! I spent hours picking away at the kernel, doing differential calculations, picking through dmesg's and logcat's. No donations necessary! This is for you guys!
* rayman84 - Thanks for your help! If you had not come along when you did, I might've spent countless hours without results if it weren't for you. (I forgot to edit my Makefile.boot)
* Radix999 - Thanks for your help man! I appreciated all the support.
* zinx @ Freenode - Thanks man! Your help made this possible!
* setenza01, kingchris, Wysie, thanks for all your dmesg/logcat/other herlp! We would've not gotten this far.
* gboddina - gboddina's kernel with his kernel config and wlan module, iptables, etc. (Note: This includes a ramdisk, may not work properly on all ROMS. Have the ROM cooker integrate this kernel for you!). V4 apparently works just fine. V5 was giving me time issues.* #android @ Freenode
* biktor_gj - Thanks for chipping in and general help!
* Maxisma - Thanks bud!
* Thank you everyone else! We still need your help! (The Android community as well as any bug reports)
Things that are working:
* SDCard
* Memory - (All memory)
* Camera - (Special thanks to zinx @ Freenode!)
* GPU1 - (Pretty sure this is right)
* ADSP - (Pretty sure this is right)
* MDP - (Untested)
* LED's - working fine.
* GPS -working fine.
* Bluetooth - working fine.
* WLAN - Working 100%
Things that are not working yet:
* Unkown (Hopefully none)
Sapphire 32B :
cat /proc/iomem
00700000-007fffff : msm_panel.0
10000000-164fffff : System RAM
10024000-10352fff : Kernel text
10354000-104293b7 : Kernel data
16d00000-16d1ffff : ram_console
a0200000-a0200fff : msm_serial_hs.0
a0400000-a0400fff : msm_sdcc.1
a0500000-a0500fff : msm_sdcc.2
a0800000-a0801000 : msm_hsusb
a9900000-a9900fff : msm_i2c.0
a9900000-a9900fff : msm_i2c
a9a00000-a9a00fff : msm_serial.0
a9a00000-a9a00fff : msm_serial
aa200000-aa2effff : mdp
aa600000-aa600fff : msm_mddi.0
e8100010-e8100017 : leds-cpld
@setenza01,
Thanks for that, it will help...
Could you possibly do 'dmesg' and pastebin it please? This is also important!
Fore dmesg : http://pastebin.com/m14bad41a
@setenza01,
Thank you again. Hopefully with this I can backwards calculate the memory locations with the current sapphire source and then examine the dmesg from a working 32A kernel and calculate the differences.
Good luck and thanks for the hard work! Are you working with biktor_gj?
Godspeed
Wysie said:
Good luck and thanks for the hard work! Are you working with biktor_gj?
Click to expand...
Click to collapse
At the moment, I'm not working with biktor_gj, but we have exchanged words in other threads and I found his other thread where he is attempting to get a 32A flashed with a 32B radio, up and running with all its memory.
My attempt is the opposite of this as I am trying to actually compile the kernel purely for a 32A with a radio that is made for 32A devices (I.E. stock radio). We're not exactly working together, but I will be keeping an eye on his attempts. Perhaps we can learn from each other and may end up cooperating. I'll be working on this tomorrow afternoon I think, as I have studies in the morning.
Ah ok, thanks for the hard work ! Haha. Hopefully both of you or one of you find a way!
TigerTael said:
At the moment, I'm not working with biktor_gj, but we have exchanged words in other threads and I found his other thread where he is attempting to get a 32A flashed with a 32B radio, up and running with all its memory.
My attempt is the opposite of this as I am trying to actually compile the kernel purely for a 32A with a radio that is made for 32A devices (I.E. stock radio). We're not exactly working together, but I will be keeping an eye on his attempts. Perhaps we can learn from each other and may end up cooperating. I'll be working on this tomorrow afternoon I think, as I have studies in the morning.
Click to expand...
Click to collapse
Thnak you man! make it work and we (I) will donate you a drink for sure!
Thanks to setenza01 for the previous dmesg.
However, I need somebody else to do a 'dmesg' for me. setenza is using a newer kernel, 2.6.29, and I am currently trying to reverse engineer a 2.6.27 kernel.
I will try and use this dmesg, but one that is running a true 2.6.27 would be more beneficial.
I have been working on this for 6 hours or so, and I have made a very small bit of progress. The kernel is still not booting the phone, but now the kernel is rebooting the phone instead. Not very much progress, but I think I may be very close here.
There is something else I need though...
Can someone turn off their phone, hook it up to their computer, go to a console where they have adb installed and do this please:
adb logcat > logcat.txt
You will get a prompt telling you that it is waiting for device. Let the phone boot up all the way into android, where you can see the desktop and then ctrl + C in the command prompt window.
Can you then open logcat.txt and paste the entire thing to a pastebin. This is quite important, I feel that this is going to give me a few more crucial clues.
I need one from a 32B Magic/Sapphire/myTouch and a 32A Magic/Sapphire/Mytouch
If you know of anyone with either of these devices, please can you bend their ear to get them to do it. Also, please state which device you are running and possibly which ROM.
Hiya, as requested:
http://pastebin.com/m735842f8
I have a 32A Magic, running Amon_RA's RAv1.1.0 . Hope it helps! Thanks for the hard work!
http://pastebin.com/f119730bb
32b Magic running Cyanogen 3.9.10
hope it helps
@Wysie, @kingchris,
Thank you guys. These contributions will help. No more need for any logfiles guys, I have all that I'm going to be able to get out of these running phones/kernels.
Tomorrow, I will be correlating the data and trying to make sense of it all. It's a bit late and I'm getting moaned at for spending so much time with my phone.
But never fear, I will continue to work on this. Hopefully I don't meet with a dead end, but with the data so far I am quite hopeful. I hope to have good news for everyone soon.
No problem . Hope to hear good news!
Oh wow, good luck man.
I've just stumbled onto something else that may help me.
I need a dmesg from an 32B HTC Magic/Sapphire/myTouch/etc running 2.6.27 kernel
If you have a phone running this kernel, PLEASE can you pastebin it or something. It is very helpful.
I have been working on this today but have not had much progress yet. It's taking a lot of my patience to work on this but I know that people need it and so do I. Hopefully I can come right with this.
ok.. how do I export this to a file...
Okay, another 7 hours later, I managed to figure out some more memory addresses, but I am still having trouble with this.
Looking through a 32A dmesg, there is something else which is present which is not present in a 32B dmesg. Here is one of the main difference which I believe is responsible for not letting me boot:
Code:
<4>[ 0.595220] +setup_mdp_sync_config()
<4>[ 0.595251] mdp_base=cc900000, phys_to_virt=51000000
<4>[ 0.595281] Enabling MDP_CLK; GLBL_CLK_ENA=221bfe2f
<4>[ 0.595312] set MDP_SYNC_CONFIG_0 from ffcfffff to 7af01192
<4>[ 0.595312] set MDP_SYNC_THRESH_0 from 40004000 to b0b
There is some other function that HTC made which is not in the source of the kernel. Unfortunately, 0xcc900000 doesn't really make much sense to me unless it's some other graphics buffer. Perhaps this is just some more debug info? I'm not sure. I have gathered all the memory locations I have and will post them now.
Things that I am very sure about the 32A Kernel (That is working):
Code:
MSM_PMEM_GPU0 Start 0x0
MSM_PMEM_GPU0 End 0x700000
MSM_FB_BASE Start 0x700000
MSM_FB_BASE End 0x079B00
MSM_RAM_CONSOLE_BASE Start 0x7A0000
MSM_RAM_CONSOLE_BASE End 0x7C0000
MSM_SMI_BASE Start 0x0
MSM_SMI_BASE End 0x800000
SMI32_MSM_LINUX_BASE Start 0x19200000
SMI32_MSM_LINUX_BASE End 0x25800000
MSM_PMEM_GPU1_BASE Start 0x25800000
MSM_PMEM_GPU1_BASE End 0x26000000
EBI_BASE Start ?
(AFAIK, should be where Linux base starts, but possibly needs to envelop ram_console)
EBI_BASE End ?
(AFAIK, should be where Linux base ends or perhaps slightly beyond)
Things that I am unsure about:
1) I am not sure if there are 1 or 2 memory banks, so I have had to test them both but there are so many variables. Knowing for sure how many would definitely help.
2) Additional code besides the memory addresses and the memory fixup seems to be missing. Function "+setup_mdp_sync_config()" is nowhere to be found and I think this is the mean reason why I am not getting anywhere.
I will continue to work on this, but without these functions I'm not sure if I'm going to get this working without it. I am posting this information here just so that people who might be able to suggest something to try can give an educated guess.
Okay, I gotta get to bed. It's getting late, work tomorrow.
Just FYI, when you compile the kernel, it subtracts 1 from the end point so as not to have memory overlapping.
I think that some devs already knew this and they are working on this, but I cannot understand why they didn't tell this to other devs.
download HTC desirec_2.6.29 kernel sources here:
http://developer.htc.com/ , if you couldn't see it, use tor or some other proxy software to visit the site.
extract it. look into arch/arm/configs folder.
you will find a file named "0001-Symptom-HeroC-remove-other-project-board-config-fi.patch"
revert this patch, you will get almost all board files. with some minor changes, you could boot the HTC official 2.6.29 kernel on your devices.
what changes? 32A new radio for example:
1. the "EBI1 supports 256MB" is removed, add it or make your changes, a simple modification, at beginning of board-sapphire.h:
#ifndef __ARCH_ARM_MACH_MSM_BOARD_SAPPHIRE_H
#define __ARCH_ARM_MACH_MSM_BOARD_SAPPHIRE_H
#define CONFIG_MSM_AMSS_SUPPORT_256MB_EBI1 //add this line.
2. the freq table for 32A is not added (this is the main reason why you can't boot), edit it in the acpulock-arm11.c:
static struct freq_tbl_map acpu_freq_tbl_list[] = {
/* you do not need to comment out these devices, though they are useless for 32A
TABLE_CONFIG(LEGEND, 7227),
TABLE_CONFIG(LATTE, 7227),
TABLE_CONFIG(LIBERTY, 7227),
TABLE_CONFIG(BAHAMAS, 72xx),
TABLE_CONFIG(MEMPHIS, 72xx),
TABLE_CONFIG(PARADISE, 72xx),
TABLE_CONFIG(HERO, 72xx),
TABLE_CONFIG(HEROC, 72xx),
TABLE_CONFIG(DESIREC, 72xx),
*/
TABLE_CONFIG(SAPPHIRE, 72xx), //our device
{ 0, 0, 0}
};
3. touchscreen data for elan hardware is not correct. but our 32A phone don't use it. comment out these things in board-sapphire.c:
/* comment out this
static struct elan_i2c_platform_data elan_i2c_data[] = {
{
.version = 0x104,
.abs_x_min = 0,
.abs_y_min = 0,
.intr_gpio = SAPPHIRE_GPIO_TP_ATT_N,
.power = sapphire_ts_power,
.display_width = 320, //me
.display_height = 480, //me
},
{
.version = 0x103,
.abs_x_min = 0,
.abs_x_max = 512 * 2,
.abs_y_min = 0,
.abs_y_max = 896 * 2,
.intr_gpio = SAPPHIRE_GPIO_TP_ATT_N,
.power = sapphire_ts_power,
.display_width = 320, //me
.display_height = 480, //me
},
{
.version = 0x102,
.abs_x_min = 0,
.abs_x_max = 384,
.abs_y_min = 0,
.abs_y_max = 576,
.intr_gpio = SAPPHIRE_GPIO_TP_ATT_N,
.power = sapphire_ts_power,
.display_width = 320, //me
.display_height = 480, //me
},
{
.version = 0x101,
.abs_x_min = 32 + 1,
.abs_x_max = 352 - 1,
.abs_y_min = 32 + 1,
.abs_y_max = 544 - 1,
.intr_gpio = SAPPHIRE_GPIO_TP_ATT_N,
.power = sapphire_ts_power,
.display_width = 320, // or you could just comment out these fields (in all structs in this array)
.display_height = 480, // in this case, you don't need to comment out all elan things.
}
};
*/
static struct i2c_board_info i2c_devices[] = {
{
I2C_BOARD_INFO(SYNAPTICS_I2C_RMI_NAME, 0x20),
.platform_data = sapphire_ts_data,
.irq = SAPPHIRE_GPIO_TO_INT(SAPPHIRE_GPIO_TP_ATT_N)
},
/* comment out this, if you disabled the entire elan data array.
{
I2C_BOARD_INFO(ELAN_8232_I2C_NAME, 0x10),
.platform_data = &elan_i2c_data,
.irq = SAPPHIRE_GPIO_TO_INT(SAPPHIRE_GPIO_TP_ATT_N),
},
*/
{
I2C_BOARD_INFO("akm8976", 0x1C),
.platform_data = &compass_platform_data,
.irq = SAPPHIRE_GPIO_TO_INT(SAPPHIRE_GPIO_COMPASS_IRQ),
},
};
maybe there are other modifications to be needed by compiling the kernel, but they could be found easily, just follow the output by your compiler.
I remembered that with only these changes, the kernel could be compiled, the device could be booted, and all things were working fine except the color of the screen is not correct(for this problem, we could get right settings from htc-kernel-2.6.27 for sapp and hero).
I am under Windows now so I can't make a patch which would work directly. but with the original leaked patch, I think that it is not difficult to make things right by yourselves.
Great news Sanpei. Now maybe our android 2.1 will work better on new radio.
Thats more than great news What can we say more ? Thank U for that But there are not many devs who wants to play with kernels for Magic ;P You were the only one Hope one day U`ll bring us good .29 to live Cheers !
And it only took you about six months to share this info with others. How great...
Nevertheless, thanks.
Case_ at least he is sharing it now
sanpei I'm working off HeroC source:
http://github.com/toastcfh/CdMa-HeRoC-2.6.29/
The correct changes were made in board-sapphire files already. Might be other stuff.
All devs need is to add the EBI1 config!
there are additional mods sanpei has not mentioned. maybe that's why his kernels have been a little finicky. but this is probably it: http://github.com/cyanogen/cm-kernel/commit/fef60feb4caa22d82a35636b1679243e67512ce5#L7L160
CPU freq tablets already fully support our CPU there. Overclock should work as well.
As for eflan, I'll have to play with it
toastcfh sent me a compile last night with board files added, but I think there was still some stuff missing, but...
EBI1 was why my device didn't boot! Going to compile that and see what happens now!
As for him not sharing it, at least he is sharing it now.
Thanks sanpei my fellow countryman
I feel dumb for compiling the source when the board files wheren't even there. I don't know if this is all I needed to do but this is a big step in the right direction. I have no knowledge of how stuff like this works. I am not a dev still.
sanpei I wish I had better understanding of all this code. But I don't. In any case thanks for sharing this with us now.
the only two reasons i didnt make the patch public is one because of the EVO (superconic) source in it, second in hopes that it wouldnt be the last mess up by HTC. the source has ony been up for 3 or 4 weeks. so the 6 months idk. i released the source as i got it to compile. i had other projects also like making source for the CDMA heroc. which oddly enough the patch says heroc on it :/ but lacks source for our device. as soon as i finished the heroc project of creating board files compatible with the heroc, i moved on to commitig the board files for the other devices. starting with the GSM hero (which was unfinished) and then the Sapphire (also unfinished). all know devices have been commited and someone at least informed of the files being there. im a busy person and have a life of my own. the patch did me no good while i was creating board files for the CDMA hero. once i finished that i turned my attention to releasing the rest of the devices. but yeah i doubt HTC will make this mistake again for sure now that its publicly announced.
so yeah i only was trying to protect a interest that everyone can gain from.
interesting none the less...
first try didn't go (defined ebi1 in .h file, compiled and flashed)
i'm giving it another last chance, this time defining ebi1 in the kconfig.
i might be missing more stuff than this.
edit: I'm blind. didnt' edit acpuclock properly. lol. doing another compile.
for the color issues look into ur panel settings. its most likely the reason the color is messed up. maybe wrong settings
Holy **** it's booting
Colors look okay actually. My touchscreen is broked though!
Cursorsense too lol
BUTTONS ALL OKAY
sounds interesting lets see what you get fixed
I'm hoping you can get it to work properly, good luck mate, crossed fingers !
All you need to start with to get 2.1 roms working
Not all of sanpei's changes are needed to fix what is on toastcfh's github.
My .config is still messed I bet.
In Cursorsense pretty much everything is broken.
http://www.youtube.com/watch?v=lasToRLQQCA&feature=player_embedded
I HAVE A BOOTSCREEN ON AHERO
For devs, if you are working off toastcfh's github source, this is what you need to get it working:
a)
acpuclockarm11.c sanpei mentioned
edit it in the acpulock-arm11.c:
static struct freq_tbl_map acpu_freq_tbl_list[] = {
/* you do not need to comment out these devices, though they are useless for 32A
TABLE_CONFIG(LEGEND, 7227),
TABLE_CONFIG(LATTE, 7227),
TABLE_CONFIG(LIBERTY, 7227),
TABLE_CONFIG(BAHAMAS, 72xx),
TABLE_CONFIG(MEMPHIS, 72xx),
TABLE_CONFIG(PARADISE, 72xx),
TABLE_CONFIG(HERO, 72xx),
TABLE_CONFIG(HEROC, 72xx),
TABLE_CONFIG(DESIREC, 72xx),
*/
TABLE_CONFIG(SAPPHIRE, 72xx), //our device
{ 0, 0, 0}
};
Click to expand...
Click to collapse
b) touchscreen fix by using the aosp synaptics driver here (rename this file)
http://github.com/toastcfh/CdMa-HeRoC-2.6.29/tree/master/drivers/input/touchscreen/
synaptics_i2c_rmi.c-AOSP-fix -> synaptics_i2c_rmi.c
c)
make changes to 'Kconfig' here, and enabled the config option during make
http://github.com/cyanogen/cm-kernel/commit/fef60feb4caa22d82a35636b1679243e67512ce5
The board files that are up work perfectly.
d) work off my config or similar:
http://pastebin.com/cKkBNtKJ
e) download aHero for GSM Hero here:
http://forum.xda-developers.com/showthread.php?t=638584
e) PROFIT
note that all apps are force-closing on aHero right now. but launcher works. boot screen works. radio works.
I will play with this later. For now I need a working phone.
Did a wipe. Most apps work. Random stuff is broken but that's okay.
But I talked to zinx in irc. He said CM-Kernel actually already supports new radio Magics.
commited the changes above to alow the sapphire to boot
github.com/toastcfh
It boots but the drivers are broked. I messed up my source and don't want to touch it for a while.
Sanpei?
Case_ said:
And it only took you about six months to share this info with others. How great...
Nevertheless, thanks.
Click to expand...
Click to collapse
do you know when the desirec_2.6.29 had been released? or, do you think that I was a time traveler?
I found this leaked patch 1~2 weeks ago. I was working on my career jobs these days (I even didn't have time to visit here), and I thought that others would find it and share with each other, so I didn't post it immediately.
yesterday, when I visited here, I found that it was not mentioned by any other people. so I decided to write something.
and hope that it won't surprise you, the .29 and .32 kernel builds made by me are not based on htc-kernels, and I never use any files from HTC. I just made aosp kernel working with our devices.
to put it simply: for 32A device, I don't need any pieces of codes from HTC, I just need the information about radio versions and interfaces between hardware and software, and I already know/understand some of them.
to be honest, I never change my mind. I won't open "my" sources before I would have considered that they could be open.
but this patch, it is leaked from HTC's sources and I don't make any efforts on it. so I think that if I shared this information, all of you will get what you want, and it is not conflict with my "moral standards" what I had mentioned in previous arguments.
maybe you and others think that I am a selfish man or bad person. I don't care. take what you want, and leave me alone.
but if you and others could reconsider what I am, and think about if I could be a friend of you, I will be very happy.
Oh but we (I) did make a thread. It should be on the 3rd page or so by now. This ROM is flooded by rom ports and has zero dev activity. There's just hopelessly few devs on Sapphire forums. That's why all you see see are ports and no AOSP stuff.
But since you have a .3X kernel anyways I don't see you really needing this. Toastcfh did remind me to replace the synaptic touchscreen driver to get it working properly for the Sapphire.
Or we could use your source. Because I have no idea what I need to do to fix wifi and camera on my port. I have CM5 working with sound, rotation, sleep, Youtube, 3D on a 32A Magic. It's not my phone though so I wont try much more on it now.
I first booted into Cursorsense, then aHero and finally Cyanogenmod 5. CM5 as a ***** because squash fs didn't compile, so it broke my xbin completely. I worked around it by extracting xbin through my virtual machine since my PC runs windows before I realized I can just install busybox from the recovery onto the phone. I pushed the lib*camera*.so files from aHero and after data wipe I had ZERO force closes, bluetooth + audio + video + rotation. Not bad for a noob, but I have no idea how to fix. This isn't my career path
toastcfh helped me a lot
Question
Doesn't it make more sense to get Cyanogen's kernel source working? All it needs is AMSS 6355 support, and the code difference doesn't seem to be that great. It already has up to AMSS6350 the last time I checked. It's actually not that bad to add new phones, but their kernel source is kind of different than HTC's now that it's now harder to just add new phones. zinx expressed interest, and I'm sure bcrook is interested as well.
We can use a plain HTC source and adapt it, but CM already should have a lot of 32a bits in it including native EBi1 support, compatible makefiles and a kernel version ready to boot any 2.1 rom.
The major differences between the AMSS versions 6350 and 6355 seem to be in the multimedia msm drivers. That's probably less than 10 files to edit in total.
The existing CM5 config should build new radio 32As no problem.
But is there a point anymore? Sanpei your kernel seems pretty darn stable right now. If I figure out how to throw it in Koush Anykernel we can probably have working ports for every ROM out there. The only thing is since you have source code sometimes the local version doesn't work well with some ROMs. So yes we still want your source because it works well.
xaueious said:
Oh but we (I) did make a thread. It should be on the 3rd page or so by now. This ROM is flooded by rom ports and has zero dev activity. There's just hopelessly few devs on Sapphire forums. That's why all you see see are ports and no AOSP stuff.
But since you have a .3X kernel anyways I don't see you really needing this. Toastcfh did remind me to replace the synaptic touchscreen driver to get it working properly for the Sapphire.
Or we could use your source. Because I have no idea what I need to do to fix wifi and camera on my port. I have CM5 working with sound, rotation, sleep, Youtube, 3D on a 32A Magic. It's not my phone though so I wont try much more on it now.
I first booted into Cursorsense, then aHero and finally Cyanogenmod 5. CM5 as a ***** because squash fs didn't compile, so it broke my xbin completely. I worked around it by extracting xbin through my virtual machine since my PC runs windows before I realized I can just install busybox from the recovery onto the phone. I pushed the lib*camera*.so files from aHero and after data wipe I had ZERO force closes, bluetooth + audio + video + rotation. Not bad for a noob, but I have no idea how to fix. This isn't my career path
toastcfh helped me a lot
Question
Doesn't it make more sense to get Cyanogen's kernel source working? All it needs is AMSS 6355 support, and the code difference doesn't seem to be that great. It already has up to AMSS6350 the last time I checked. It's actually not that bad to add new phones, but their kernel source is kind of different than HTC's now that it's now harder to just add new phones. zinx expressed interest, and I'm sure bcrook is interested as well.
We can use a plain HTC source and adapt it, but CM already should have a lot of 32a bits in it including native EBi1 support, compatible makefiles and a kernel version ready to boot any 2.1 rom.
The major differences between the AMSS versions 6350 and 6355 seem to be in the multimedia msm drivers. That's probably less than 10 files to edit in total.
The existing CM5 config should build new radio 32As no problem.
But is there a point anymore? Sanpei your kernel seems pretty darn stable right now. If I figure out how to throw it in Koush Anykernel we can probably have working ports for every ROM out there. The only thing is since you have source code sometimes the local version doesn't work well with some ROMs. So yes we still want your source because it works well.
Click to expand...
Click to collapse
no, it is not that "my" kernel works well, it is the original aosp kernel works well, except some minor bugs (which are already fixed in my kernel build). and I think that .32 is more suitable than .33, since .33 is marked as experimental by Google.
some "custom" mods of .33 use older drivers which are taken from kernel sources of an older version. I can't sure if these drivers could work properly with new radio, though you could boot your device and most features will works.
and sorry, I don't want to talk about other's works. but I must repeat again: all "custom" kernels are just original kernels from Google/Qualcomm/HTC's repo, and with little public patches made by some real programmers.
so don't care about their brands. you should find out what they are using: drivers, hacks, and patches of features.
if you use a lib (in userspace or android layer) because it is necessary for a radio version (because the lib and the radio have some conventions directly), then you should choose the kernel driver which could work with this lib. KERNEL itself is NOT the KEY problem in this case.
in fact, the most programming jobs I had done are in android layer; and if I have spare time, what I would work on are in android layer too. (except OC or other things which do most things in the kernel).
for devs who don't have enough experiences in kernel jobs or programming, and if they want a most stable kernel which would works with new radio, I recommend them start from htc-kernel. it's always more reliable, because we (I, you and others) can't know every changes of hardware configurations between each radio versions, and HTC knows these things exactly.
but why I would still be working on .32 kernel?
because I think that I could fix every bugs (if we would encounter) by myself , and I want to learn and remember the new changes Google made in kernel. thus, I wouldn't need to learn these things again when newer versions of android (they might need these changes in kernel) will be coming.
a kernel and some libs for new radio, and they could work with both AOSP and HTC ROMs, it's my current goal. and you could see giant's work on AOSP ROM, I think that we are more close to this goal now.
"my" sources..., I will think about it (and I often considered if it's the time). but I am rather obstinate
and for problems of using htc-kernel, I can't remember all the details of my tweaks and tests. maybe I will take a look for you. but I won't make any promise, since I really don't have enough time at current.
Here is a slightly separate but related thought.
It seems to me (and I am the first to admit I am not knowledgeable in this stuff so I could be wrong) that one of the following statements are true regarding the devs working on the G1 and other phones:
(1) Either they are not very knowledgeable when it comes to kernel programming and development (and so they are not capable of getting a kernel working on the 32a like Sanpei did), or
(2) The other devs are not interested about the 32a user community enough to spend their time providing us with support (and so they do not focus their time getting a kernel working on the 32a).
My guess is that it is a combination of the two possibilities above. Devs are not as knowledgeable as we think when it comes to kernel development and the required changes HTC and qualcomm do to get a kernel working on different phones especially the 32a, and even if they could do some reverse engineering and some hacking that they don't want to spend the time and energy supporting the 32a user community which is probably a lot smaller than the 32b community. (I don't fault anyone for not wanting to support a community - it takes time and there is probably very little financial reward.)
I believe the lack of a working new radio kernel for 32a supports Sanpei's view that other devs should not be branding the kernel with their names after they have done some minor tweaks. I believe that anyone capable of doing major work on a kernel worth re-branding the kernel to their own name would have already been able to get it working on the 32a properly.
But what do I know.
Lastly, I don't mean to disrespect any dev with these views. All of the devs have contributed - big or small - to the user experience and all devs have done a lot more than I will or could ever do to support Android. However, I do think we should be honest about what we can and can't do and what we take credit for.
It is also interesting....
(1) How xaueious has good things to say about "Sanpei's" kernel
(2) How Sanpei refuses to call it his kernel, or to take credit for the 6.35 .32 kernel, and how Sanpei actually plays down or belittles what he had to do to get the .32 kernel working on the new radio (something which no one else has done), and
(3) How guys like Alan who know very little about kernel development choose to criticise the .32 new radio kernel ported by Sanpei, going so far to call it "garbage"
All of these things point to people's approach and character.
Hello,
I have released a very ugly, hacked up dump of my work from July when I attempted to port CyanogenMod 9 to the Nexus Q. It is incomplete, but compiles still, and functional. Developers might find this of use.
There was a large amount of interest in this work when I released a video of 'proof of concept' that went viral in July, before the consumer launch. This work was all created before Google pulled the launch (July), and many weeks before AOSP or OMAP repos had the source for device/vendor.
I call it "Tuna balls" due to the fact it's a raw rip off of the Tuna/Maguro base from CM9, dated July 2012, when I forked and modified it.
The codenames of the branches may be wrong. A lot of the 'bugs' may be easy to fix. Unfortunately, I never came back to this project after July.
As someone who strives for complete, QA process builds, I kept this private for months. I know it's not complete, please understand things don't work flawlessly. No audio (possibly hard to fix) and crashing System UI (probably easy to fix) can ruin your experience, but this can be hacked into shape
* GIT SOURCE *
https://github.com/kornyone/android_device_google_steelhead
https://github.com/kornyone/android_device_tuna_balls
https://github.com/kornyone/vendor_google_steelhead
https://github.com/kornyone/google-kernel-steelhead
Here are my notes/bug list from Github:
"Operation Tuna Balls"
This is a partially complete attempt at porting CyanogenMod 9 (Android 4.0.4) to the Nexus Q.
At the time of original creation (July), there was no other source available. As such, I used the Tuna/Maguro bases to port to the Steelhead, as there were so many common pieces.
This combination worked well for the majority of things. Known bugs never resolved since this project was orphaned in July include:
* No working audio. Mixers fail to load with tuna audio_hw.c. The OMAP "Steelhead" and AOSP "Phantasm" repositiories online have a -very- hacked up version of this file, but intended for Jellybean (as of writing). Also, OMAP has the audio listed as a known issue in their source releases.
* No working NFC. This could be easy to solve, I did not spend much time on it.
* System UI crashes. This should be a simple matter of finding this conflicting Tablet/Phone System UI layouts being requested (should be an overlay setting, likely).
Most everything else works. This includes:
* Bluetooth pair all the things, no hacks needed.
* Wifi works.
* XHDPI resolution works (when System UI doesn't crash).
* HW Acceleration in games work.
* Google Play Market is open for use.
--------------
While I am a maintainer for CyanogenMod, this work is not official in any way. It is incomplete, and I am more or less abandoning it at this point due to a broken Nexus Q and lack of free time. Please hit me up on Freenode (kornyone) for questions, ##nexusq is still open.
Thanks!
Proof of concept (so people don't have to dig this stuff up):
Video concept -- (Very rough) --
Photo gallery on G+ with screenshots -- https://plus.google.com/100539377198423911977/posts/GRxhSLRnNss
very nice mate
Sent from my Xperia T using tapatalk 2
kornyone. I was wondering where you put this. Thanks for the source release, it will come in use. I have a big move coming up but plan to pick up where you left off and maybe get some other devs in on this. Again, thanks for the xmas present!
how hard would this be to run cm 10 on it?
kornyone,
I was able to build and install your cm9!
Of course I have the same issues as you (systemui crashes, no sound) but hey it's something!
Thanks for everything and I hope there is still some progession on this!
Ehm... hello everyone
Our phone is quite a little powerful beast, but Xiaomi really made a crappy job on optimizing it, right?
After unlocking the bootloader I felt the need to go back to my roots and get my hands dirty to fix the wrongs in the kernel they released. The phone felt slow and heavy, the battery barely lasted a day. I use my phone for my job and I need to be snappy, stable and last way more than a day. So I started tweaking, digging and experimenting and the result is this kernel that I'm releasing today, in an attempt to make our MI9SE a bit better for all those people who actually use this phone... as a phone...
This kernel is GSI / AOSP only. Don't flash it on Miui based roms unless you are suicidal or want to lose some features, in which case you're free to do as you please and I'm free to ignore your posts, right?
There will be, from time to time, experimental/unstable versions that I release for public testing (usually they're not harmful, but... ehm.... ok you get it) so watch out for the second post if you feel brave and want to be on the bleeding edge. Official kernels are released when the beta testing phase is done and 100% of the feedback is positive.
Don't ask for ETA or you'll be fish slapped... badly! Ignore this warning only in case a nasty bug slips in the release, then you can fish slap me
Ok, enough talk, let's get down to business now.
Features
* Compiled in release mode (all debug stripped)
* Removed all auditing
* Disabled modules support to avoid interference from Xiaomi vendor
* Battery friendly, performance aware
* DT2W support. If disabled the display and touchscreen will power down
* 3G modem small optimizations
* K-Lapse 5.0 support (thanks to tanish2k09 for this awesome piece of code)
* Flicker Reduction via heavily modified Exposure Adjustment module from Sony
* Boeffla Wakelock Blocker pre-configured to block most of the bad boys
* BFQ and CFQ I/O Schedulers
* Adreno Idler support (your gpu will thank me)
* Westwood TCP congestion algorithm enabled by default (and a lot more enabled)
* Support for NTFS (read only)
* Support for F2FS
* And loads more... yeah just ask or check my github
Q & A
Q: Battery !!! Why it's so baaaad ! My phone doesn't sleep !!!
A: Well, don't get it badly, it's not really my problem, is it ? 99.999% is an app you have installed that's preventing deep sleep... go ahead and install BetterBatteryStats, check the Partial Wakelocks and se what's killing your phone. Have fun
Q: App X crashes ! OMG all my data is gone !!!
A: Read again on top, not my fault, sorry. I try my best to give out a stable kernel, but "**** happens" and i can't control it...
Q: I get tons of bsods, my phone doesn't wake up from sleep, it freezes and omg... it just exploded !!!
A: No dmesg / logcat, no party. And please don't post messages like those in the thread if you're not ready to attach a log to the post.
Q: When will you enable gpu overclock, road runner speed mode or wile e. coyote immortality ?
A: Never... on a second thought... maybe... who knows ?
Q: When will you release the new version ? It's a week we're using the old one !!
A: Is it stable ? Then please allow me to fish slap you with a huge trout !
Downloads
All downloads for Kowalski Kernel will be linked in the second post AND in the thread when a new version is released and a changelog will be filed accordingly.
The downloads are labeled as "kowalski-XY-grus" where X can be either "r" for release or "b" for beta. Y is the version number. Eg: kowalski-r1.4-grus is a release, while kowalski-b4-grus is a beta version.
Source will be pushed to my github about 2 or 3 days after a release (or before if I'm not careful), to make sure that no major bugs are introduced in the public repository. You can find the magic code here
This kernel can be compiled with any clang 4.9.x that supports the aarch64-linux-gnu target, so if you want to compile it by yourself you'll have either to build your own toolchain, or use one of the many prebuilt ones (for example from aosp).
Please don't rip-off my work. Please don't kang this kernel. Please don't c&p from my github without proper credit. I'm a nice guy, but i will report you.
Little code of conduct for my threads is necessary: no drama, no OT. Oh and please don't message me on Telegram privately when we have this awesome platform where everyone can benefit from the Q&A.
Thanks
* Okita for the awesome job she made on the base kernel cleanup (this kernel is based on one of her first releases)
* Linus, well, for the linux kernel
* francescod for taking the risks of testing possibly harmful pre-releases
* qualcomm, because codeaurora is awesome!
* osm0sis, the one who allowed us mortals to provide flashable kernels without pain
Oh, I was almost forgetting... on a side note... i'm not really responsible if you decide to test it and your phone melts... right ?
XDA:DevDB Information
Kowalski Kernel, Kernel for the Xiaomi Mi 9 SE
Contributors
pengus77, okitavera, francescod
Source Code: https://github.com/pengus77/kowalski-grus
Kernel Special Features:
Version Information
Status: Stable
Current Stable Version: r1.9.3
Stable Release Date: 2019-09-13
Created 2019-07-25
Last Updated 2019-09-13
Version 1.9.3 release - Download here
* Implement display idle states and expose sysfs nodes to manage them
* qcacld-3.0: Add sme_power_save_api.h include
* Add toggle for disabling newly added USB devices
* sched: don't allow userspace to boost at will
* defconfig: disable misc device and rework a bit
* kernel: implement vDSO64 and vDSO32
* spi: increase timeout to make FOD more reactive
* Bump Linux version to 4.9.192
Version 1.9.1 release - Download here
* updated ion, binder and uapi apis to latest upstream versions
* backported schedutil governor from 4.14 with a subset of improvements tree-wide
* backported qcacld-3.0 from 4.14 msm nicobar tree and cleaned it up
Version 1.8 release - Download here
* reverted the update to the latest wifi driver
* disable ssbd mitigations
* mm:compaction: raise priority
* kernel:sched:fair: align periods to our kernel config (100Hz)
* techpack:audio: remove compat code
* mmage-writeback: tune values for better memory handling
* kernel: nasty hack to bypass VTS/VINTF checks
* defconfig: disable AUDIT,PROFILING,TRACING and MORE...
* kernel: build with -O3 optimizations
* defconfig: re-enable BFQ as default scheduler
* block: add zen scheduler
* binfmt_elf.c: use get_random_int() to fix entropy depleting
* net/wireguard: add wireguard
* PM: devfreq: Use high priority workqueue
* cpuidle: don't disable cpuidle when entering suspend
* gpu:drm:msm: convert all pr_info into pr_debug
* Version 1.7 release - Download here
* Merged Linux v4.9.189 from upstream
* Version 1.6 release - Download here
* Merged Linux v4.9.188 into MSM base
* Fixed a few wifi issues
* Fixed a possible memory leak in the ext4 driver
* Limited zRam to 1GB
* Rewritten defaults for blu_schedutil with an eye on power saving
* Disabled spammy audit logs
* Stripped all symbols from the kernel (smaller, speedier)
* Reverted an old commit in F2FS that was considered harmful
* Version 1.5 release - Download here
* Merged Linux v4.9.187 from upstream
* Fixed K-LAPSE upper bounds and drafted a "saner" default target
* Reinstated VTS / VINTF compliancy
* Version 1.4 release - Download here
* Pretty much initial release with all the goodies from OP after a month of testing...
All the kernel tweaks can be edited as usual with any kernel management app (EX, FK, etc...)
About the Flicker Reduction system, if your ROM doesn't support it or if you want to tweak it a bit and you feel adventurous, you can play with these sysfs endpoints
* /sys/devices/platform/soc/soc:qcom,[email protected]/msm_fb_ea_min (the minimum amount of exposure added)
* /sys/devices/platform/soc/soc:qcom,[email protected]/msm_fb_ea_enable (kinda self explanatory, isn't it? 1 = enabled, 0 = disabled)
* /sys/devices/platform/soc/soc:qcom,[email protected]/msm_fb_ea_elvss_off_treshold (the brightness threshold under which the system is enabled)
Wow, finally a full battery and features oriented kernel. Great to see it for our little beast. And with no Miui support
I hope you don't fall in modern famous useless stuff as Overclock/Overvolting Cpu-Gpu and Overclocking display. Grus doesn't need it at all, at least now.
I'd like to thank you of course, for all of your hard work done. It was a pleasure to help just a little with testing!
After many test of various configurations I've come to these stable settings useful only if you're searching for some more battery juice, so, no high demanding games at all! Performances on daily light use, seem to me like the same as with stock values.
Cpu Governor: Blu_Schedutil
Freq small cores: 576-1516MHz
Freq big cores: 300-1536MHz
wq_power_saving: enabled
Gpu Governor: Simple_ondemand
Freq: 180-267MHz
Adreno Idler: active (should work only on MsmAdreno Governor, but I like to see it enabled anyway)
I/O scheduler: Maple
Readahead 384kb
Fsync: disabled
Tcp congestion algorithm: bbr or westwood
To maximize even more the battery saving use black/dark grey apps as much as possible, use the right brightness, turn off any fancy features as AOD, FOD, AmbientDisplay, PocketMode, every unused sensors, install AdAway, Greenify, use 2G when in Wi-Fi or 2G/3G/4G on mobile connection and pray for someone :cyclops:
All of these settings are fine on my device with my personal use and my personal apps, so, don't complain about bad behavior on your phone.
Which what GSI are you using your kernel? I'm on PE but it will be snappy to have your same experience... :fingers-crossed:
champagne66601 said:
Which what GSI are you using your kernel? I'm on PE but it will be snappy to have your same experience... :fingers-crossed:
Click to expand...
Click to collapse
Hey there, at the moment I'm on Floko because I need stability. Using it with latest xiaomi.eu vendor/firmware blobs and all is good so far
I know people using this on crDroid or Havok and no problems or issues are known so far.
Stupid question: What is different / advantage against Okita kernel?
I'm glad to see new and new kernels and ROMs for 9 SE. Thank you @pengus77
Does it work in miui rooms? Thanks
Fran Montero said:
Does it work in miui rooms? Thanks
Click to expand...
Click to collapse
Read the OP.
vecino said:
Stupid question: What is different / advantage against Okita kernel?
Click to expand...
Click to collapse
This is a fully debloated Kernel from Miui/useless/redundant stuff, so, for an only custom roms lover as me, it's perfect.
K-Lapse, Adreno Idler, unlocked frequencies and flickering reduction are the main visible points, with ofc more under the hood. I left OkitaKernel when it was perhaps on v4 build, so check it out what's changed recently on it.
While they're born from the same base, each Dev makes own customization, so it's up to you to try them both and choose the one who satisfies you better.
Finally I wanna thank again @okitavera for her dedication. Probably without her kernel I wouldn't have bought the 9 SE so fast :highfive:
@pengus77
I flashed your kernel ... is it working but after every restart I give this message: "Device has an internal problem. Contact the manufacturer for more information." Is it problém with firmware / vendor?
vecino said:
@pengus77
I flashed your kernel ... is it working but after every restart I give this message: "Device has an internal problem. Contact the manufacturer for more information." Is it problém with firmware / vendor?
Click to expand...
Click to collapse
Hi, yeah, it's absolutely normal and harmless. It's a standard thing Android *****es about on GSIs when the kernel is too "stripped" and can't neither debug it nor load modules and/or there is a mismatch between system and vendor props. Search for that message in XDA and you'll see that tons of people have the same "issue". It's nothing to worry about, the system will work just fine.
Some ROMs are more strict than others. I know Floko says that, while Havok doesn't.
Roger that - I will be keep testing.
Testing on havoc
Enviado desde mi MI 9 SE mediante Tapatalk
Kernel have in default min 576 MHz - is it so intentionally? Otika was 300 MHz if I'm not wrong. Doesn't this have a negative effect on higher consumption?
vecino said:
Kernel have in default min 576 MHz - is it so intentionally? Otika was 300 MHz if I'm not wrong. Doesn't this have a negative effect on higher consumption?
Click to expand...
Click to collapse
It's just the default to keep it a bit more responsive. Little technical explanation follows: When the phone is in suspend, the cores are disabled and the cpu goes in low power state, so the frequency doesn't really matter. When in active use, the energy and time required to reach a target frequency (when boosting on touch for example) is pretty high. Having a tiny higher min frequency actually lowers the power needed when a boost is required and the time to reach the target frequency is lower. When idling the energy consumption between 576 and 300 is basically the same and doesn't impact the battery life.
Of course the frequencies are unlocked, so you can set it back down to 300 if you feel more comfortable with it
Beta Release [ b1.5a ]
In the releases page on my github (and in the second post) I just pushed a little beta release.
Thanks @fereidooni for finding out a nasty bug occurring during hard memory copy operations .Will fix it soon, in the meantime ignore this version.
Changes:
* Adopted a drastically more power-efficient and reduced IOMMU implementation (your battery will say thank you)
* Cleaned up a few things (this will never end I think... sigh...)
* Disabled the MSM Performance min frequency override. Now YOU decide, not qualcomm.
Have fun
pengus77 said:
In the releases page on my github (and in the second post) I just pushed a little beta release.
Changes:
* Adopted a drastically more power-efficient and reduced IOMMU implementation (your battery will say thank you)
* Cleaned up a few things (this will never end I think... sigh...)
* Disabled the MSM Performance min frequency override. Now YOU decide, not qualcomm.
Have fun
Click to expand...
Click to collapse
Hi
I tried this version
Any video playing cause phone restarted
Thanks for your work
fereidooni said:
Hi
I tried this version
Any video playing cause phone restarted
Thanks for your work
Click to expand...
Click to collapse
Wow thanks mate, an adventurous soul that tested a beta version... gotta love this people
Anyway, just confirmed the problem and will soon get to fix it. In the meantime use the stable version if you want. It should be safe
pengus77 said:
Wow thanks mate, an adventurous soul that tested a beta version... gotta love this people
Anyway, just confirmed the problem and will soon get to fix it. In the meantime use the stable version if you want. It should be safe
Click to expand...
Click to collapse
Thanks mate
Sure I'm using stable version
I am using beta about 10 hors and I had only one problem with UI FC but after wipe cache and dalvik is all ok.
This is a general service announcement. There is vulnerability in the Mali GPU drivers that allows for root access discovered by security researcher Man Yue Mo (CVE-2022-38181). The vulnerability goes way back and affects almost any device with a Mali GPU. That covers most of the FireHD tablets from the last 5 years, most of the FireTV televisions, and the 1st, 2nd and 3rd gen Cubes (and FireTV pendant).
Man Yue Mo posted a POC for the Pixel 6, that was adapted to work on the 2nd and 3rd gen FireTV Cubes. It takes a non-trivial number of changes to get it to work on other devices, and I don't have any FireHD tablets to work through it on. It appears that the cat's out of the bag on this exploit now, because the 2nd gen Cube just got an update that patches the POC. So I'm assuming a patch is coming (possibly even present) to other Fire devices as well, otherwise I would have kept it quiet for longer to try to work through some other devices.
Rortiz2 said:
This is really interesting and exciting. I wonder if this vulnerability affects any other Fire HD devices as well (obviously those using Mali GPUs). If you don't mind me asking, what are your plans regarding the PoC's source code? (nevermind, I think I found the original POC here). Could you give some hints regarding to what needs to be changed in order to port the exploit to other devices? I'd love to test it and learn more about this CVE.
Click to expand...
Click to collapse
I will try to post the source for the two Cube versions within the next day.
The Pixel 6 POC has to be modified for 32bit userspace, and there may need to be modifications to some of the struct's depending on which version of the Mali driver your device is using.
Kallsyms offsets need to be changed for any firmware you want to cover
Pool_size should be verified on your device
I'd also double check the path for define Mali, I've seen a couple devices that don't use the default path.
Lastly disabling selinux may need to be modified depending on the kernel version.
I'd start out with a device that you already have root on so that you can get any values needed, and use it as a potential template.
Edit: added 2nd and 3rd gen source code
Pro-me3us said:
I will try to post the source for the two Cube versions within the next day.
The Pixel 6 POC has to be modified for 32bit userspace, and there may need to be modifications to some of the struct's depending on which version of the Mali driver your device is using.
Kallsyms offsets need to be changed for any firmware you want to cover
Pool_size should be verified on your device
I'd also double check the path for define Mali, I've seen a couple devices that don't use the default path.
Lastly disabling selinux may need to be modified depending on the kernel version.
I'd start out with a device that you already have root on so that you can get any values needed, and use it as a potential template.
Edit: added 2nd and 3rd gen source code
Click to expand...
Click to collapse
Thank you for your the brief explanation regarding the changes that need to be made. We are currently attempting to exploit the Fire HD8 2020 (onyx), but have encountered an issue. We were able to extract the kallsyms table using this script, which seemed to work correctly. However, we have discovered that some of the kallsyms appear to be missing, specifically:
sel_read_handle_unknown: ffffff80083b08b0
selinux_enforcing: Doesn't seem to exist.
init_creds: Doesn't seem to exist.
commit_creds: ffffff80080dc530
add_init: Doesn't seem to exist.
add_commit: Doesn't seem to exist.
We have also observed that the tablet crashes after increasing FLUSH_SIZE (which seems to be normal as per the comments in the source code of the PoC), probably indicating that this device is indeed vulnerable to the CVE. Do you have any suggestions on how we can proceed with regards to the missing kallsyms?
Rortiz2 said:
Do you have any suggestions on how we can proceed with regards to the missing kallsyms?
Click to expand...
Click to collapse
I don't know if it's a good idea to go through methods publicly since it will help instruct Amazon on how to make future probing and intrusions harder for other exploits. I'll pm you
Rortiz2 said:
Thank you for your the brief explanation regarding the changes that need to be made. We are currently attempting to exploit the Fire HD8 2020 (onyx), but have encountered an issue. We were able to extract the kallsyms table using this script, which seemed to work correctly. However, we have discovered that some of the kallsyms appear to be missing, specifically:
sel_read_handle_unknown: ffffff80083b08b0
selinux_enforcing: Doesn't seem to exist.
init_creds: Doesn't seem to exist.
commit_creds: ffffff80080dc530
add_init: Doesn't seem to exist.
add_commit: Doesn't seem to exist.
We have also observed that the tablet crashes after increasing FLUSH_SIZE (which seems to be normal as per the comments in the source code of the PoC), probably indicating that this device is indeed vulnerable to the CVE. Do you have any suggestions on how we can proceed with regards to the missing kallsyms?
Click to expand...
Click to collapse
FYI, if you want to test anything on other devices i have almost everything 10 gen and below, including the hd8 (10). Totally dont care if i brick them, they arent used regularly... Including a unlocked and locked fire 7 (2019)
Graphics adapter
ARM Mali-T720 MP
I'll gladly run any testing on my devices as well. Fire 7 (2019) and HD 10+ (2021) both running firmware version 7.3.2.1.
I have an already-rooted Karnak (8th gen HD 8) that I can reflash to any OS needed - do let me know if it can be of any service to the cause.
Pro-me3us said:
I don't know if it's a good idea to go through methods publicly since it will help instruct Amazon on how to make future probing and intrusions harder for other exploits. I'll pm you
Click to expand...
Click to collapse
I am also facing trouble to find kallsyms - add_init add_commit values. can you help me to find that
mind _spacer said:
I am also facing trouble to find kallsyms - add_init add_commit values. can you help me to find that
Click to expand...
Click to collapse
The values you're referring to are not kernel symbols, but rather shellcode(s). You'll need to adjust the ADD_* values to align them with your specific kallsyms. The following example shows the correct values for the Amazon Fire HD8 2020 (onyx):
Code:
#define AVC_DENY_7314_1443 0x3252F4 // avc_denied.isra.6
#define SEL_READ_HANDLE_UNKNOWN_7314_1443 0x3308B0
#define PREPARE_KERNEL_CRED_7314_1443 0x5C8E8
#define COMMIT_CREDS_7314_1443 0x5C530
#define ADD_PREPARE_KERNEL_CRED_7314_1443 0x9123a108 // add x8, x8, #0x8E8 <-- prepare_kernel_cred
#define ADD_COMMIT_7314_1443 0x9114c108 // add x8, x8, #0x530 <-- commit_creds
As you can see, these values are ARM assembly opcodes encoded as 32-bit constants. In this case, they represent the add operation on the x8 register. To create these constants, you can use online converters or the ARM instruction set encoding.
For instance, add x8, x8, #0x8E8 is encoded into the 32-bit value 0x9123a108 using the following breakdown:
91000000 - Base value for ADD (immediate) instruction with 64-bit registers (this will be different for non-ARM64 archs).
00001000 - Destination and first operand register (x8 in binary).
00111010 - Immediate value to be added, rotated right by 12 bits (0x8E8 rotated - prepare_kernel_cred).
00000001 - Shift amount for immediate value (1*12, since immediate value is specified in multiples of 12).
I actually implemented a function to dynamically craft the values, but I never tried it so far. In case anyone is interested, this is how it looked like:
Code:
#define ADD_OPCODE_ARM64 0x91000000 // ARM64
#define ADD_OPCODE_ARM32 0xE0000000 // ARM32
uint32_t add_off_to_reg(uint32_t offset, uint8_t reg) {
uint32_t add_value = ADD_OPCODE_ARM64;
add_value |= reg; // Rd
add_value |= reg << 5; // Rn
add_value |= (offset & 0xFFF) << 10; // imm12
LOG("add x%d, x%d, %#x: 0x%08X\n", reg, reg, offset, add_value);
return add_value;
}
I hope this helps you!
Rortiz2 said:
The values you're referring to are not kernel symbols, but rather shellcode(s). You'll need to adjust the ADD_* values to align them with your specific kallsyms. The following example shows the correct values for the Amazon Fire HD8 2020 (onyx):
Code:
#define AVC_DENY_7314_1443 0x3252F4 // avc_denied.isra.6
#define SEL_READ_HANDLE_UNKNOWN_7314_1443 0x3308B0
#define PREPARE_KERNEL_CRED_7314_1443 0x5C8E8
#define COMMIT_CREDS_7314_1443 0x5C530
#define ADD_PREPARE_KERNEL_CRED_7314_1443 0x9123a108 // add x8, x8, #0x8E8 <-- prepare_kernel_cred
#define ADD_COMMIT_7314_1443 0x9114c108 // add x8, x8, #0x530 <-- commit_creds
As you can see, these values are ARM assembly opcodes encoded as 32-bit constants. In this case, they represent the add operation on the x8 register. To create these constants, you can use online converters or the ARM instruction set encoding.
For instance, add x8, x8, #0x8E8 is encoded into the 32-bit value 0x9123a108 using the following breakdown:
91000000 - Base value for ADD (immediate) instruction with 64-bit registers (this will be different for non-ARM64 archs).
00001000 - Destination and first operand register (x8 in binary).
00111010 - Immediate value to be added, rotated right by 12 bits (0x8E8 rotated - prepare_kernel_cred).
00000001 - Shift amount for immediate value (1*12, since immediate value is specified in multiples of 12).
I actually implemented a function to dynamically craft the values, but I never tried it so far. In case anyone is interested, this is how it looked like:
Code:
#define ADD_OPCODE_ARM64 0x91000000 // ARM64
#define ADD_OPCODE_ARM32 0xE0000000 // ARM32
uint32_t add_off_to_reg(uint32_t offset, uint8_t reg) {
uint32_t add_value = ADD_OPCODE_ARM64;
add_value |= reg; // Rd
add_value |= reg << 5; // Rn
add_value |= (offset & 0xFFF) << 10; // imm12
LOG("add x%d, x%d, %#x: 0x%08X\n", reg, reg, offset, add_value);
return add_value;
}
I hope this helps you!
Click to expand...
Click to collapse
Thank you for the brief reply, definitely it helped a lot.
Pro-me3us said:
I will try to post the source for the two Cube versions within the next day.
The Pixel 6 POC has to be modified for 32bit userspace, and there may need to be modifications to some of the struct's depending on which version of the Mali driver your device is using.
Kallsyms offsets need to be changed for any firmware you want to cover
Pool_size should be verified on your device
I'd also double check the path for define Mali, I've seen a couple devices that don't use the default path.
Lastly disabling selinux may need to be modified depending on the kernel version.
I'd start out with a device that you already have root on so that you can get any values needed, and use it as a potential template.
Edit: added 2nd and 3rd gen source code
Click to expand...
Click to collapse
Is this POC works on android devices (such as samsung) having mali driver , if its works can you tell me the modifications need to done on struct's and disable selinux depending on kernel version(which u mentioned) and what are the changes do we need to do?
mind _spacer said:
Is this POC works on android devices (such as samsung) having mali driver , if its works can you tell me the modifications need to done on struct's and disable selinux depending on kernel version(which u mentioned) and what are the changes do we need to do?
Click to expand...
Click to collapse
Knowing nothing about your device, it's hard to know what changes are required to get the POC to run. What is the device kernel version and Mali driver type and version? Is it using a 32bit or 64bit version of Android? Do you have a copy of the firmware that your device is currently using (most importantly boot.img)? Do you have the source code for the kernel? Is the source code for the same version of the firmware that your device is currently running?
There are a few ways to do things depending on what resources you have available to you.
Following....with my 2021 Fire HD 10 running 7.3.2.1
Pro-me3us said:
Knowing nothing about your device, it's hard to know what changes are required to get the POC to run. What is the device kernel version and Mali driver type and version? Is it using a 32bit or 64bit version of Android? Do you have a copy of the firmware that your device is currently using (most importantly boot.img)? Do you have the source code for the kernel? Is the source code for the same version of the firmware that your device is currently running?
There are a few ways to do things depending on what resources you have available to you.
Click to expand...
Click to collapse
This is the spec of my device:
Samsung M30s (M307FXXU4CVD1)
Android 11, 64-bit version
Kernel - 4.14.113
Security patch level - 1 Mar 2022
Mali - G72 MP3, version - r26 p0
I have the source code and firmware image of this device. And I have found the device specific offsets (from elf of kernel) and @Rortiz2 helped me to find some of it, kernel base address (by reading header of boot.img) and path defined for mali is correct.
I tried to run the original POC but device reboots at the after it prints "Cleanup flush region" part.
then, I tried ur poc which ends by "Release_mem_pool" and reboot.
Hope you could help me.
mind _spacer said:
G72 MP3, version - r26 p0
I have the source code and firmware image of this device. And I have found the device specific offsets (from elf of kernel) and @Rortiz2 helped me to find some of it, kernel base address (by reading header of boot.img) and path defined for mali is correct.
I tried to run the original POC but device reboots at the after it prints "Cleanup flush region" part.
then, I tried ur poc which ends by "Release_mem_pool" and reboot.
Click to expand...
Click to collapse
I'm assuming that Mali driver type is Valhall? or Bifrost? Midgard?
Valhall r26p0 might be recent enough that you don't need to make any struct changes to for older driver compatibility.
Since your device is using 64bit Android, I'd stick to the original Pixel6 POC. A lot of the changes in my two POCs was 64bit to 32bit conversations. The 32bit POC may work on your device, but I don't know if there are any incompatibilities. Better to avoid any potential 32bit complications.
What are the 6 kernel addresses that you plugged in to the Pixel6 POC for your device?
Pro-me3us said:
I'm assuming that Mali driver type is Valhall? or Bifrost? Midgard?
Valhall r26p0 might be recent enough that you don't need to make any struct changes to for older driver compatibility.
Since your device is using 64bit Android, I'd stick to the original Pixel6 POC. A lot of the changes in my two POCs was 64bit to 32bit conversations. The 32bit POC may work on your device, but I don't know if there are any incompatibilities. Better to avoid any potential 32bit complications.
What are the 6 kernel addresses that you plugged in to the Pixel6 POC for your device?
Click to expand...
Click to collapse
I'm trying to work with your gazelle POC as a base for amazon mustang (midgard r26p0), but I have some questions; what is alloc.in.flags (1 << 22) in spray()? It doesn't seem to match any base_mem_alloc_flags I could find for either the cube or the mustang.
I'm also getting -EPERM on the alias_sprayed_regions() mmap(), presumably because of MAP_SHARED. When ORed with MAP_ANON the mmap64 call succeeds, however find_pgd() then fails because the pages are all zeroed. Can you advise?
@Pro-me3us
A temp root would be great - at least, to make backups easier. is this new exploit realistic to get working on hd tablets? Do you have a tablet like that to try ?
relalis said:
I'm trying to work with your gazelle POC as a base for amazon mustang (midgard r26p0), but I have some questions; what is alloc.in.flags (1 << 22) in spray()? It doesn't seem to match any base_mem_alloc_flags I could find for either the cube or the mustang.
I'm also getting -EPERM on the alias_sprayed_regions() mmap(), presumably because of MAP_SHARED. When ORed with MAP_ANON the mmap64 call succeeds, however find_pgd() then fails because the pages are all zeroed. Can you advise?
Click to expand...
Click to collapse
I have never taken a look at Midgard.
Midgard r26p0 - July, 2018 (mustang)
Bifrost r25p0 - June, 2020 (gazelle)
Bifrost r16p0 - December, 2018 (raven)
Based on the timing, I would use the raven POC as your base, because the driver is likely more similar. This is related to the issue you were asking about. Bifrost r16p0 doesn't support the memory pool group which is that flag. Support for that was added somewhere between Bifrost r16p0 and r25p0, and Midgard r26p0 may not support it either. Check out the changes made in Raven, I basically just removed it.
bibikalka said:
@Pro-me3us
A temp root would be great - at least, to make backups easier. is this new exploit realistic to get working on hd tablets? Do you have a tablet like that to try ?
Click to expand...
Click to collapse
There are two parts to the POC, the GPU driver exploit, and disabling selinux to open a root shell. The GPU exploit portion should be mostly compatible between devices. If your device is using 64bit userspace, use the original Pixel6 POC which shouldn't have any driver incompatibilities back to about Bifrost r25p0 (2020). The Pixel6 uses Valhall, i'm not sure what driver version was available in 2020. If you have a device with 32bit userspace like most Amazon devices, then either the raven or gazelle POC should work for the GPU exploit portion. Midgard may have other unknown differences that need to be addressed
Disabling selinux / rootshell fixup portion is the part that needs to be modified to get the POC working with any individual tablet, because this portion has kernel specific instructions. This part of the POC probably isn't going to be as simple as swapping a couple kallsyms addresses. I think @Rortiz2 was working on getting the selinux / rootshell fixup working a few of the tablets. Using that as a base for the other MediaTek tablets might be more useful than my POCs, assuming they are more similar.
The new POC uses a race condition and the GPU portion is a bit more complicated, and may need more device specific tuning. The selinux / rootshell portion is mostly the same as the older exploit. The new user_buf exploit exploit mostlyonly has the advantage of working on Bifrost r38p0 which is the driver Amazon updated the Cubes to, to patch the shrinker exploit.
@mind _spacer sorry, I didn't notice your device kernel version before. The pixel6 POC handles the rootshell portion by disabling AVC_deny, for kernels older than 5.0 it may be easier to substitute selinux_enforcing, at least that's what was done for raven. I struggled a bit to get the rootshell portion working on both raven and gazelle. @rortiz was able to adapt it to one of the FireTablets in just a couple days, so he probably has a much better understanding and might be able to offer insights.
Pro-me3us said:
There are two parts to the POC, the GPU driver exploit, and disabling selinux to open a root shell. The GPU exploit portion should be mostly compatible between devices. If your device is using 64bit userspace, use the original Pixel6 POC which shouldn't have any driver incompatibilities back to about Bifrost r25p0 (2020). The Pixel6 uses Valhall, i'm not sure what driver version was available in 2020. If you have a device with 32bit userspace like most Amazon devices, then either the raven or gazelle POC should work for the GPU exploit portion. Midgard may have other unknown differences that need to be addressed
Disabling selinux / rootshell fixup portion is the part that needs to be modified to get the POC working with any individual tablet, because this portion has kernel specific instructions. This part of the POC probably isn't going to be as simple as swapping a couple kallsyms addresses. I think @Rortiz2 was working on getting the selinux / rootshell fixup working a few of the tablets. Using that as a base for the other MediaTek tablets might be more useful than my POCs, assuming they are more similar.
Click to expand...
Click to collapse
A bulk of Fire HDs was 32 bit user space indeed, armv8l was the kernel on many (HD10 2019 that i have). HD10 2021 became aarch64.
I thought @diplomatic had a fairly generic code to disable selinux fairly for all devices within his MTK exploit? Or was that a lot more different than here? Too bad a lot of old crew seems to have scattered, so much less capability around here these days (looking at @k4y0z here ).
What's the best way to find out the version of MALI driver that the device is using?
bibikalka said:
What's the best way to find out the version of MALI driver that the device is using?
Click to expand...
Click to collapse
KBASE_IOCTL_VERSION_CHECK will return param.major and param.minor API versions, as to the driver type (midgard/bifrost/valhal) you'll have to look at Amazon's source code release for the individual devices, or perhaps find the relevant page on postmarketos wiki