Database Info

[dev] do you want HTC official kernel 2.6.29 sources for ALL devices?

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.

[PATCH][KERNEL] EB13 camera video lag & sports mode FC fix

Attached is a kernel source patch that fixes the EB13 camera video lag and "Sports" scene mode force-close. It's actually the same kernel bug that's responsible for both.
Also attached is an Odin/redbend-flashable, otherwise stock EB13 kernel with this patch applied. It's intended for anyone who wishes to further test the fix and who is familiar with Odin and/or redbend_ua. For others, I'd recommend waiting until one of the custom kernels integrates the patch or until Sprint releases an official update.
I'll update this post in the morning with a workup of the bug (done, see below), since it's a bit interesting/illustrative. And yes, it's very simple and very silly. One of those things that really never should've happened. Thanks to everyone in the solutions thread for providing clues that were instrumental in locating it.
Bug details:
Shortly after the release of EB13 folks reported lag when recording videos, particularly in low light. Although not obviously related at the time, folks also reported that switching to "Sports" scene mode results in a force-closed (and in my experience, renders the screen inoperable as well, sigh). Folks in the solutions thread also reported that (i) these problems are new to EB13, they weren't present in DK28; and (ii) replacing the user-space camera components (app, libraries, etc.) with DK28 versions did not resolve the problems, implying they were likely due to one or more kernel bugs.
Unfortunately we do not have the DK28 source code to compare EB13 against, but at least knowing that these problems weren't present in DK28 helps narrow down the possible bug locations quite dramatically. Furthermore, it's quite likely that this bug was introduced rather recently, as I imagine it would've been caught by internal testing had it been present in say, December.
So with that in mind, I sorted the kernel source files by modification time and started looking for the most recently-changed files that might be relevant to the camera driver. "include/linux/videodev2_samsung.h" was the first hit with a modification date of 2/8, and indeed it's used by the camera driver ("drivers/media/video/victory/ce147.c", itself last modified on 12/1). Again, we don't have DK28 sources for comparison, but fortunately header files typically don't change too significantly and a comparison (diff) against the DI18 version was rather easy to follow.
And yes, a snippet of code stood out right away as rather strange, especially given the cirumstances of the problem:
Code:
enum v4l2_iso_mode {
ISO_AUTO = 0,
ISO_50,
ISO_100,
ISO_200,
ISO_400,
ISO_800,
ISO_1600,
ISO_FIREWORKS, // Added since DI18.
ISO_SPORTS,
ISO_NIGHT,
ISO_MOVIE,
ISO_MAX,
};
For folks less-familiar with C, this code defines an enumerated type, basically a mapping of "descriptive labels" to numeric values; in this case: ISO_AUTO=0 ISO_50=1, ISO_100=2, etc. This enables kernel code to contain descriptive statements like "iso_mode = ISO_200;" instead of the more arbitrary "iso_mode = 3;".
Now, as the above comment (which I added, but the diff points it out) suggests, ISO_FIREWORKS is a new speed that was added to the middle of the enum since DI18. Seasoned C programmers will recognize that, this is often something that leads to trouble. To understand why, compare the "before" and "after" enum mappings:
Code:
Before: After:
ISO_AUTO: 0 ISO_AUTO: 0
ISO_50: 1 ISO_50: 1
ISO_100: 2 ISO_100: 2
ISO_200: 3 ISO_200: 3
ISO_400: 4 ISO_400: 4
ISO_800: 5 ISO_800: 5
ISO_1600: 6 ISO_1600: 6
ISO_SPORTS: 7 ISO_FIREWORKS: 7
ISO_NIGHT: 8 ISO_SPORTS: 8
ISO_MOVIE: 9 ISO_NIGHT: 9
ISO_MOVIE: 10
The addition of ISO_FIREWORDS to the middle of the enum shifts the mapping of any labels below it, in this case ISO_SPORTS, ISO_NIGHT, and ISO_MOVIE. This isn't fatal, but it does mean that all code that uses the enum needs to be recompiled to reflect the new mapping. Often, kernel header files contain data types that are exclusive to the kernel, so any relevant code gets recompiled as part of the process of compiling a kernel.
But as it turns out, the entries in this enum are used in exactly one location (on the Epic anyways) in the kernel: as a case in a switch statement in the camera driver that sets the ISO mode in a camera hardware register. This means, assuming these values are used at all, they must be provided by a user-space library. In other words, the enum mapping is an integral part of the driver API, and not something that can be altered willy-nilly.
So basically, on EB13 when the Camera app goes to record a movie, it sets mode ISO_MOVIE (9), which the kernel interprets as ISO_NIGHT and sends to the camera hardware. Presumably ISO_NIGHT biases picture quality over shutter speed, hence the blurry laggy video when recording. Similarly, ISO_NIGHT => 8 => ISO_SPORTS (which no one noticed), and ISO_SPORTS => 7 => ISO_FIREWORKS. Except ISO_FIREWORKS isn't implemented, so the driver call fails which results in the force close. Oops!
The fix is fairly simple, just remove ISO_FIREWORKS from the enum. This allows the kernel and the user-space libraries to agree on the mapping. And since ISO_FIREWORKS isn't even implemented in the kernel, no harm can possibly come from it.
Finally, as I stated earlier, this is a bug that never should've happened, for two reasons. First, it was introduced into the Epic kernel source tree after DK28. Now, keep in mind that DK28 was effectively a Froyo "release candidate", especially given that it was packaged up as an OTA update and accidentally pushed to some handsets. Any changes made to the kernel post-DK28 should be limited to strict bug fixes only. The addition of ISO_FIREWORKS to the enum is not part of any bug fix (indeed it introduces one), rather one would consider it a "new feature". But "new features" shouldn't creep into stable code trees. This suggests poor code management.
Second, this alteration would've been a non-issue had ISO_FIREWORKS been appended to the end of the enum, just before ISO_MAX (which, presumably just reports the numer of entries in the enum as opposed to describing a particular mode). This would've assiged ISO_FIREWORKS to an unused value, instead of remapping existing values. Adding ISO_FIREWORKS to the middle of the enum is a particularly short-sighted choice, as it immediately renders any code that uses it unnecessarilly incompatible with new kernels. Adding ISO_FIREWORKS to the end preserves backwards compatibility, for free, with absolutely no downsides--why not do that instead?
So, in short, the failure to properly consider both of these issues, as well as the neglect to notice the change, bespeaks of an incompetent moment on the part of Samsung. If the change really was made on 2/8, one can't really blame Sprint for failing to pick it up during last-minute testing. I'm not sure how much this particular bug was a factor in Sprint pulling the EB13 update, but it's pretty embarassing that it made it out there in the first place.
Mirror links (does not require forum login):
epic_camera_fix-EB13.diff
epic_camera_fix-EB13.tar
epic_stock-EB13.tar (for flashing back to the stock EB13 kernel)

Thank you! This will be in the ACS kernel team's kernel.

Excellent, patching up as we speak.
Sent from my SPH-D700 using XDA App

Just wanted to be 3rd
Sent from my SPH-D700 using Tapatalk

Cool, looks good.
Sent from my SPH-D700 using Tapatalk

patching myself too thx will be in Genocide Kernel 0.3a

THANKS! leave it up to xda to do a better job then Samsung lol
Sent from my SPH-D700 using XDA App

Sweet,
tested working perfect. the LSD trails in video are gone and no FC in sports mode. TY so much.

fix worked great! i just released genocide 0.3a with this patch included! thanks again!

Gotta love 1 line fixes

Would like to try this but only have mac os so odin...

Awesome, thanks man!
Sent from my SPH-D700 using XDA App

Noob question.
Do you put this in PDA? Also no need for PIT or modem file right?
Via TapaTalk on Nook Tablet
-Edit-
Okay, used Odin, put patch in PDA with nothing else set. Worked perfectly! Thanks to all!

You sir a genius....thx for this fix!!!

What is sports mode? I can't find it.

Silent25r said:
What is sports mode? I can't find it.
Click to expand...
Click to collapse
Still camera, settings (gear button)>Scene Mode> Sports Before the fix it's an automatic FC

Can't wait to hear the details behind the bug.
Sent from my SPH-D700 using XDA App

This patched worked perfectly on the genocide kernal!! Thanks For Your Hard Work!!
Now Just Waiting For Bonsai!!

The geniuses at XDA strike again! Brilliant! Thanks!

MoCoTerp said:
Noob question.
Do you put this in PDA? Also no need for PIT or modem file right?
Via TapaTalk on Nook Tablet
Click to expand...
Click to collapse
Help please? I've flashed lots of roms but never a kernal like this. i'd like to stay with the stock ROM. Can't find anything on a search. Can someone either post a link or instructions.

[Q] How to debug Ezekeel's DeepIdle - Found bug?

I have compiled Ezekeel's deepidle into my JellyBean kernel (stock merged to 3.0.39 + voodoo + blx) and got it to run. The kernel seems stable, and I get top-on and top-off stats when I enable WI-FI, but when I disable WI-FI, the stats stop counting.
[EDIT2] I worked out what I think is a bug - see the next post. I am testing my fix now...[/EDIT]
[EDIT] I coded debugging within the DI code and found the offensive DI check. The reason DI does not activate is because the S3C_HSMMC_CLOCK_CARD_EN bit is set for S3C_DEV_HSMMC1 when wi-fi is deactivated. In fact the 'reg2' within cpuidle.c is 0x000f ( it is normally 0xe0003 when wifi is on). To be consistent with Ezekeel's approach I am investigating the S3C_HSMMC_PWRCON registers to see if they can be used. Alternatively if other devices never have 0x000f for reg2, I will use that for a quick 'hack'.
1. Any idea why the S3C_DEV_HSMMC1 register is different for JellyBean vs ICS and GB?
2. How, using the MSMMC registers, can I determine that a device (wi-fi in this case) has been shut down?
[/EDIT]
[ I eagerly await thalamus' IDLE2, but when I compiled it (v 0.213) into my kernel there was an idle battery drain issue. (The screen-off drain was many times my norm, even without music playing...) ]
--== HurryNwait ==--

I think I found the problem, but I feel rather arrogant making the following statement. I think there was a bug in DI all along... (I hope I'm right - maybe someone can check my findings.)
Relevant code:
Code:
#define S3C_HSMMC_CLKCON (0x2c)
...
#define S3C_HSMMC_CLOCK_CARD_EN 0x0004
...
unsigned int reg1, reg2;
...
reg2 = readl(base_addr + S3C_HSMMC_CLKCON);
return !!(reg1 & (S3C_HSMMC_CMD_INHIBIT | S3C_HSMMC_DATA_INHIBIT)) ||
(reg2 & S3C_HSMMC_CLOCK_CARD_EN);
Register offsets and values:
#define S3C_HSMMC_CLKCON (0x2c)
#define S3C_HSMMC_DIVIDER_SHIFT 8
#define S3C_HSMMC_CLOCK_EXT_STABLE 0x0008
#define S3C_HSMMC_CLOCK_CARD_EN 0x0004
#define S3C_HSMMC_CLOCK_INT_STABLE 0x0002
#define S3C_HSMMC_CLOCK_INT_EN 0x0001
Since an unsigned int is 4 bytes, then the "reg2 = read1" line is reading the two bytes we want, and two bytes from the next offset (the last two bytes).
When we do the bitwise comparison - specifically "(reg2 & S3C_HSMMC_CLOCK_CARD_EN)" we are looking at the last two bytes rather than the first two because S3C_HSMMC_CLOCK_CARD_EN is 0x0004 which is compared as 0x00000004.
Also, as it turns out first two bytes are generally 0x000e, so the bitwise test for S3C_HSMMC_CLOCK_CARD_EN always fails if the device is on. Although I could have disabled this test (since it had a bug from the beginning), I am guessing that this test is important, so I changed it to test the S3C_HSMMC_CLOCK_INT_EN bits. I will test it both ways...
I changed the code and now DI works on Jellybean with WI-FI turned off. I am stress testing now and will post my results...
[EDIT] Tested music over bluetooth for 3 hours - no problems - idle stats never stop. Testing music through headphones now... [/EDIT]
(I would be posting in the development section, but I don't have enough posts...)
--== HurryNwait ==--

Well deepidle stats are counting, but I'm back to an old familiar problem. Deep idle is not always stable. I got a reboot while playing music through headphones...
I am currently running ondemand 100 - 1000. I will try something faster...
I am in the process of testing the second iteration of my deepidle fix, and I will ultimately post my patch for the WI-FI off DI bug when I decide if one way is better than the other...
--== HurryNwait ==--

[Guide] demystifying build.prop [Valid entries]

Tired of see so many "tweaks" that do not work, I decided to dig deeper.
Scavenging the entire Android source, I checked entries which are actually valid.
Note 1: Ignored the build.prop entries created by buildinfo.sh (default entries)
Note 2: I'll update/upgrade the topic gradually.
I accept all help, suggestions, observations, comments and so on.
Entries that DO NOT exist in the source:
(Again: I scaveged all Android source code)
ro.ril.disable.power.collapse
ro.mot.eri.losalert.delay
ro.config.hw_fast_dormancy
ro.config.hw_power_saving
windowsmgr.max_events_per_sec
persist.cust.tel.eons
ro.max.fling_velocity
ro.min.fling_velocity
ro.kernel.checkjni
dalvik.vm.verify-bytecode
debug.performance.tuning
video.accelerate.hw
ro.media.dec.jpeg.memcap
ro.config.nocheckin
profiler.force_disable_ulog
profiler.force_disable_err_rpt
ersist.sys.shutdown.mode
ro.HOME_APP_ADJ
Notes:
dalvik.vm.verify-bytecode
Previous version of the runtime supported the boolean
dalvik.vm.verify-bytecode property, but that has been
superceded by dalvik.vm.dexopt-flags.
ro.kernel.checkjni
The correct entry is ro.kernel.android.checkjni
ro.HOME_APP_ADJ
The interaction with this is been removed.
From google:
This is a process holding the home application -- we want to try
avoiding killing it, even if it would normally be in the background,
because the user interacts with it so much.
All ro.media.enc* entries
A more elegant alternative would be to edit /system/etc/media_profiles.xml
Valid entries on CyanogenMod and AOSP:
dalvik.vm.checkjni and ro.kernel.android.checkjni
platform_frameworks_base/core/jni/AndroidRuntime.cpp (480:489/466:475)
Code:
property_get("dalvik.vm.checkjni", propBuf, "");
if (strcmp(propBuf, "true") == 0) {
checkJni = true;
} else if (strcmp(propBuf, "false") != 0) {
/* property is neither true nor false; fall back on kernel parameter */
property_get("ro.kernel.android.checkjni", propBuf, "");
if (propBuf[0] == '1') {
checkJni = true;
}
}
wifi.supplicant_scan_interval
android_external_wpa_supplicant/wpa_supplicant.c (2459:2460)
Code:
if (property_get("wifi.supplicant_scan_interval", scan_prop, "5") != 0) {
wpa_s->scan_interval = (int)strtol(scan_prop, &endp, 0);
service.adb.tcp.port
platform_system_core/adb/adb.c (1366:1372/1350:1356)
Code:
// If one of these properties is set, also listen on that port
// If one of the properties isn't set and we couldn't listen on usb,
// listen on the default port.
property_get("service.adb.tcp.port", value, "");
if (!value[0]) {
property_get("persist.adb.tcp.port", value, "");
}
ro.sf.lcd_density and qemu.sf.lcd_density
platform_frameworks_base/core/java/android/util/DisplayMetrics.java (286:294)
Code:
private static int getDeviceDensity() {
// qemu.sf.lcd_density can be used to override ro.sf.lcd_density
// when running in the emulator, allowing for dynamic configurations.
// The reason for this is that ro.sf.lcd_density is write-once and is
// set by the init process when it parses build.prop before anything else.
return SystemProperties.getInt("qemu.sf.lcd_density",
SystemProperties.getInt("ro.sf.lcd_density", DENSITY_DEFAULT));
}
}
debug.sf.nobootanimation
platform_frameworks_base/cmds/bootanimation/bootanimation_main.cpp (45:49)
Code:
char value[PROPERTY_VALUE_MAX];
property_get("debug.sf.nobootanimation", value, "0");
int noBootAnimation = atoi(value);
ALOGI_IF(noBootAnimation, "boot animation disabled");
persist.adb.notify
Cyanogen: android_frameworks_base/services/java/com/android/server/usb/UsbDeviceManager.java (747:753)
Code:
if (mAdbEnabled && mConnected) {
if ("0".equals(SystemProperties.get("persist.adb.notify"))
|| Settings.Secure.getInt(mContext.getContentResolver(),
Settings.Secure.ADB_NOTIFY, 1) == 0)
return;
AOSP: android_frameworks_base/services/java/com/android/server/usb/UsbDeviceManager.java (714:715)
Code:
if (mAdbEnabled && mConnected) {
if ("0".equals(SystemProperties.get("persist.adb.notify"))) return;
net.rmnet0.dns* and net.dns*
This is ok for Wifi and 2G/3G conection
wifi.supplicant_scan_interval
android_external_wpa_supplicant/wpa_supplicant.c (2459:2460)
Code:
if (property_get("wifi.supplicant_scan_interval", scan_prop, "5") != 0) {
wpa_s->scan_interval = (int)strtol(scan_prop, &endp, 0);
Valid entries only on CyanogenMod:
persist.sys.purgeable_assets
android_frameworks_base/core/jni/android/graphics/BitmapFactory.cpp (632:634)
Code:
char value[PROPERTY_VALUE_MAX];
property_get("persist.sys.purgeable_assets", value, "0");
mPurgeableAssets = atoi(value) == 1;
persist.sys.use_dithering
android_packages_app_CMParts/src/com/cyanogenmod/cmparts/activities/PerformancesettingsActivity.java (102)
Code:
String useDithering = SystemProperties.get(USE_DITHERING_PERSIST_PROP, USE_DITHERING_DEFAULT);
persist.sys.jit-mode (Only "fast" and "portable" modes)
android_packages_app_CMParts/src/com/cyanogenmod/cmparts/activities/PerformancesettingsActivity.java (96:99)
Code:
mJitPref = (CheckBoxPreference) prefSet.findPreference(JIT_PREF);
String jitMode = SystemProperties.get(JIT_PERSIST_PROP,
SystemProperties.get(JIT_PROP, JIT_ENABLED));
mJitPref.setChecked(JIT_ENABLED.equals(jitMode));
pm.sleep_mode (Do not work on Non-MSM chipsets)
See sleep modes on device kernel in pm-data.c and pm.h
:highfive:
Some background info:
XLOUD, ClearAudio
If, and ONLY if your phone support xloud on stock ROM, is highly probable that this is ported for CyanogenMod and AOSP based roms, because these custom roms use proprietary drivers, firmwares, frameworks, app....
To enable, use this:
Code:
ro.semc.sound_effects_enabled=true
ro.semc.xloud.supported=true
persist.service.xloud.enable=1
The same is valid for ClearAudio. To enable use this:
Code:
ro.semc.sound_effects_enabled=true
ro.semc.clearaudio.supported=true
persist.service.clearaudio.enable=1

For ics 4.0 .4 ?
Sent from my MegaFon_SP-AI using xda premium

Ranisblogru said:
For ics 4.0 .4 ?
Sent from my MegaFon_SP-AI using xda premium
Click to expand...
Click to collapse
I'm looking at latest GIT tree of Android source code and latest CyanogenMod source code, so this topic is valid for latests releases (KK, JB, CM10.X, CM11), but may not be the same for earlier versions (to be sure I'm would have to look old commits...).

wow...I ve always wanted to do this resarch...but nerver had time
so all the "famous" build.prop tweaks are useless ????[

Crostantin said:
wow...I ve always wanted to do this resarch...but nerver had time
so all the "famous" build.prop tweaks are useless ????[
Click to expand...
Click to collapse
Yes they have been fake all the time, you might even get surprised when I tell you battery calibration is also totally bogus (it's for emulator only)

really?? I am surprise !!!!
You mean that i haven't to charge one for month from 0% to 100% and etc.......
If it's true a lot stuff I red about Lithium batteries make sense.....maybe

Most of the tweaks are useless, i totally agree!
Funny to see people "copy & paste" everything they see on the internet, just to "magically" make their phones faster...
Some interesting links regarding the topic:
First one...
Second one...
Take care

Wooaarr said:
Most of the tweaks are useless, i totally agree!
Funny to see people "copy & paste" everything they see on the internet, just to "magically" make their phones faster...
Some interesting links regarding the topic:
First one...
Second one...
Take care
Click to expand...
Click to collapse
what about 3G fast dormancy??
the tweak should be:
ro.rill.fast.dormancy.rule=0
...your opinion??

@LaraCraft304 great guide, might want to mention the fact that those cyanogenmod specific changes can be found in performance settings anyway so although the build.prop lines would work, there is no need to use them.

Your post looks eerily similar to Jeff Mixon's article.
http://www.jeffmixon.com/examining-build-prop-tweaks-for-android-ics-a-comprehensive-guide-part-1/
http://www.jeffmixon.com/examining-build-prop-tweaks-android-ics-comprehensive-guide-part-2/
And FYI, this is a Motorola build.prop tweak ("mot") that in fact works (or at least used to) on Motorola devices.
Code:
ro.mot.eri.losalert.delay

upndwn4par said:
Your post looks eerily similar to Jeff Mixon's article.
http://www.jeffmixon.com/examining-build-prop-tweaks-for-android-ics-a-comprehensive-guide-part-1/
http://www.jeffmixon.com/examining-build-prop-tweaks-android-ics-comprehensive-guide-part-2/
And FYI, this is a Motorola build.prop tweak ("mot") that in fact works (or at least used to) on Motorola devices.
Code:
ro.mot.eri.losalert.delay
Click to expand...
Click to collapse
But not quite, as "pm.sleep_mode" was debunked at that blog post. Atleast here it is stated that it does something for Qualcomm/MSM Devices.
@LaraCraft304 - Kudos to your work!

Does are only some "lines" some do really work like ones for ultra fast boot and deep sleep states
It depends on the device's chipset actually. It works on Qualcomms, Idk about exynos and nvidia

How about the Killjoy mod pack?

broodplank1337 said:
Yes they have been fake all the time, you might even get surprised when I tell you battery calibration is also totally bogus (it's for emulator only)
Click to expand...
Click to collapse
Haha..I've have that same debate for a while now with some friends. I agree 100% with you..But who am I a lowly Xda user with small thanks amount

yeah, I was surprised when I found out that lots of those tweaks were fake, I thought XDA folks knew better than that. I think the main reason people think they work is that to apply them you have to reboot your device, and EVERY device feels snappier after rebooting.

Please answer some of my questions related to build.prop and they are too many, can't be posted here. Located here: Please answer them!
http://forum.xda-developers.com/showthread.php?p=76239
Sent from my ST25i using XDA Premium 4 mobile app

Are you sure that the various APP_ADJ weren't implemented in Gingerbread? I remember seeing them in Samsung stock firmwares (although commented)...

In my opinion this is one of the most useful informative threads I have seen in a while.
I hope now everybody will realise that they have to be careful when reading the list of features of so many blazing fast and buttery smooth roms.
A lot of users and rom chefs use those build.prop tweaks just because everybody use them and because they have read tons of times that it improves the battery life, performance, etcetera. But the truth is that none of them checked or proved if those lines make a difference, so it's good to see that someone made research to prove that some of the most famouse buildprop tweaks are placebo effect.
I personally always wanted to understand what those "tweaks" exactly do and check if there is some kind of documentation that proves that it works before applying those changes to my phone. I wouldn't be surprised if the list of placebo effect tweaks gets bigger!

Sad part is that despite the build.prop tweaks being disproved, or rather most of them, it won't stop people from trying. Its the same as the Entropy generator thing we saw a while back. All these tweaks are pointless as if there was something you could change in terms of performance or battery then Google or the OEMs would have done it already.
Edit: should mention that when I was doing custom ROMs, the only tweaks I used where ones to the VM which I spent many countless hours investigating whether it improved or not, and the home screen lock (back when it did something).

hillbeast said:
......All these tweaks are pointless as if there was something you could change in terms of performance or battery then Google or the OEMs would have done it already.......
Click to expand...
Click to collapse
+10000000

Potential ARM Mali GPU based root (FireHD 8th -12th gen affected)

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