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.
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.
One of the big issues I have noticed is that there is no rationale behind the version number assignment for a lot of the mod firmware. There are different modders using their own versioning, and there isn't even a hint of what version of android they are using, so we have things like;
"KiNgxKxROM Version 1.1r1"
"The Official Blur - Hero-V1.5.7 by Drizzy"
"JACxHEROSkiv2.2"
"CyanogenMod 4.1.11.1"
*** these all have the same problem... what version of android do they correspond to? How new IS each one of them?
I would like to propose a new standard to be adopted by everyone.
name-officialversion-modversion.
Of the form i.e.
"superxmod-1.6.DRC83-0.1.0.0"
***WHERE the modversion RESETS TO ZERO each time the official version increases, so for example, "CyanogenMod 4.1.11.1" should be called "CyanogenMod-1.6.DRC63-0.1.11.1".
* this will allow the user to immediately know where this rom comes from in terms of the official android versions and approximately how old it is.
I do my best
I do my best ... with the "limited space" we're given for Thread Titles on the forum.
~enom~
I support this though I find it unnecessary. The new beginner user will most likely READ atleast the first post of the thread and they will know what the ROM is based off of. The end user will of course know to read the thread before doing any flashing of any kind so organizing mod rom versioning isn't a necessity. It's convienent but not necessary
I support this because it would make ROM catalogs easier to build, which would benefit the whole community.
why not just post what android version the rom is based on in the first post. First post should always hold the most info anyways.
Since this thread hasn't been moved from the Dev section so far.
+1 for the versioning.
Also, how about we all stick to one benchmarking app (or is there any one app that we CAN rely on)
to test performance of ROMs, so that there's an objective way of figuring out
whether the latest frankenROM (thanks devs! ) is faster than X or Y?
Benchmark Pi has a score that's difficult to figure out, seeing as it throws up an
awesome number on a fairly sluggish HERO whereas the score for a fast-as-light
cyan ROM is way way worse. I know that Benchmark Pi isn't the answer,
not by a long shot. So is there a better alternative out there?
I'm tired of posts that go "THIS IS WAY FASTER! THANKS!" only to find
that the supposed speed increase is more rooted in perception than in
reality.
We need definitive numbers for ModelNumber+ROMVersion+CC/SwapSettings combinations.
Any help?
alritewhadeva said:
The end user will of course know to read the thread before doing any flashing of any kind
Click to expand...
Click to collapse
rofl. Funniest thing i've read all week.
+1
how about shorthand naming such as
for example:
CyanogenMod = CM-AOSP1.6r1-v4.20
If you're talking about cyanogen mod, you might want to add a couple more zeroes at the end. Anyway, I had proposed this too a while ago. I like your format, and I'll go one better; let's do cook-androidVersion-buildVersion-feature.bugfix
for example, the build I made this morning would be "jm-1.6-Donut eng.jubeh.20090930.070211-0.0"
jm is what I use for my builds (short for jubehMod)
1.6 is the current android branch (as per build.prop, no 1.6_r1 yet)
Donut eng.jubeh.20090930.070211 is the build number the compiler assigned to my build, people who work off of modding factory releases or build for dream_open are the ones who usually come up with things like CRC or DRC etc, I build for "AOSP for Dream" (it's a new "vendor" added)
first 0 is feature number, at this point my build is nothing but stock AOSP donut, no Google apps, no a2sd, no netfilter, no compcache, no bfs, just stock donut, so say I were to add a2sd, then I'd go up to 1, as I would have added one or more features (and this would be listed at the change log), basically, anything added that improves the build (and that's not a fix) is a +1 to feature
second 0 is bugfix. For example, right now my build works correctly in every sense, but I have a problem with the video camera where video is of very poor quality (real problem, I'm trying to figure it out), so say i get it fixed, then my bugfix number would go up 1, so basically, anything changed in the build strictly because it didn't work as intended is a bugfix
the last two numbers would be allowed to go past 9, so no more pressures to add .1s at the end like cyanogen was doing to prevent jumping to build # 4.2
karthikjr said:
+1 for the versioning.
Also, how about we all stick to one benchmarking app (or is there any one app that we CAN rely on)
to test performance of ROMs, so that there's an objective way of figuring out
whether the latest frankenROM (thanks devs! ) is faster than X or Y?
Benchmark Pi has a score that's difficult to figure out, seeing as it throws up an
awesome number on a fairly sluggish HERO whereas the score for a fast-as-light
cyan ROM is way way worse. I know that Benchmark Pi isn't the answer,
not by a long shot. So is there a better alternative out there?
I'm tired of posts that go "THIS IS WAY FASTER! THANKS!" only to find
that the supposed speed increase is more rooted in perception than in
reality.
We need definitive numbers for ModelNumber+ROMVersion+CC/SwapSettings combinations.
Any help?
Click to expand...
Click to collapse
yes just bench mark. its much better than benchmark pi only test the cpu really
by the way, I've been saving pretty much all roms that have been posted here (notable exceptions are haykuro's, jf's, and theduded's roms, I haven't been here THAT long) and I have them all saved on my computer separated by /cook/build/ for the Dream roms and /build/cook/ for the Hero ports. I guess I could run a quick filesystem lister and upload that list for people to see so they can sort of get an idea what mod release corresponds to what build
Here we go, I had to upload it inside a zip because of the stupid 2kb limitation on text files (this is 10kb)
lbcoder said:
One of the big issues I have noticed is that there is no rationale behind the version number assignment for a lot of the mod firmware. There are different modders using their own versioning, and there isn't even a hint of what version of android they are using, so we have things like;
"KiNgxKxROM Version 1.1r1"
"The Official Blur - Hero-V1.5.7 by Drizzy"
"JACxHEROSkiv2.2"
"CyanogenMod 4.1.11.1"
*** these all have the same problem... what version of android do they correspond to? How new IS each one of them?
I would like to propose a new standard to be adopted by everyone.
name-officialversion-modversion.
Of the form i.e.
"superxmod-1.6.DRC83-0.1.0.0"
***WHERE the modversion RESETS TO ZERO each time the official version increases, so for example, "CyanogenMod 4.1.11.1" should be called "CyanogenMod-1.6.DRC63-0.1.11.1".
* this will allow the user to immediately know where this rom comes from in terms of the official android versions and approximately how old it is.
Click to expand...
Click to collapse
................................
Hi jubeh,
Thanks, this kind of cataloging is exactly why the OP's suggestion will be helpful.
karthikjr said:
We need definitive numbers for ModelNumber+ROMVersion+CC/SwapSettings combinations.
Any help?
Click to expand...
Click to collapse
I'm not so sure that we do...
I think that that should be more of a "details" thing.
Maybe we can go with "name-officialversion-modversion[-custom]" (square braces mean optional). Name might be a good place to keep modelnumber (I assume you mean by that "dream", "magic", "hero", etc.),
i.e.: supercustomrom(DREAM)-1.6r1-0.0.0.0.0.0.0.1-cc_swap_a2sd
I have posted a device tree for Gingerbread for the HeroC. This has not had a lot of mileage, so don't expect that it will be at the level of AOSPs builds, but is a starting point for those who would like to build their own GB Roms.
Credit for this should go to those who did the REAL work, such as AOSP, Lox, Elemag, Darchstar, Cyanogen, and a host of others.
My contribution was just the assembly and cleanup of the existing efforts of others.
Still plenty of issues that need working on, and not sure how much time I will have to devote to moving this forward. I have tried to make it fairly self contained, with enough information to get folks started. I will not be able to provide much support, but I am making it available in the event that it is of interest.
Special thanks to AOSP for a working ROM to look at and learn from, and appreciation for some files and info that I shamelessly kanged from his build. Also thanks to Lox and Elemag for their hero device tree which also provided some significant pieces of the puzzle.
Good luck, thanks for the community, and please continue to help each other.
You can get the device tree from github by:
git clone git://github.com/wjb/android_device_htc_heroc_gb.git
README
Basic steps to build:
1 - Get local copy of CM7 repository
2 - Get copy of the device tree into device/htc/heroc
3 - Copy modified files from 'device/htc/heroc/buildmods' to proper directories:
a) definitions.mk into 'build/core' (Temporary fix for boot.img size issue)
b) vendorsetup.sh into 'vendor/cyanogen' (Add lunch combo)
c) prelink-linux-arm-heroc.map into 'vendor/cyanogen' (Map library locations)
d) AndroidProducts.mk into 'vendor/cyanogen/products' (Add cyanogen_heroc product)
e) cyanogen_heroc.mk into 'vendor/cyanogen/products' (Add cyanogen_heroc makefile)4 - Run get-rommanager in vendor/cyanogen directory
5 - Get proprietary files into 'vendor/htc/heroc/proprietary'
a) Put ROM (update.zip) in repo root and run 'unzip-files.sh' from the 'device/htc/heroc' directory
b) Use 'adb' to pull files from usb connected device by running 'extract-files.sh'
c) Copy files from expanded system directory on your local machine by running 'copy-files.sh'
d) Copy files from 'device/htc/heroc/proprietary' directory (also needs 'setup-makefiles.sh')6 - Setup build environment by sourcing envsetup file '. build/envsetup.sh'
7 - Run 'lunch' to select the build target 'lunch cyanogen_heroc-eng'
8 - Build the system with make, mka, etc.
Save for Updates
gingerbread futures
downloading does it compile witch working cam sensors etc.
aaronpoweruser said:
downloading does it compile witch working cam sensors etc.
Click to expand...
Click to collapse
It does compile and build a working ROM, including camera, gps, compass, wifi, etc.
If you have built other ROMS, this should be very straightforward. If not, follow standard guides for setting up and configuring your build environment.
Whoa jaybob, you're working on GB now?
Oh hell yes. Your updating of themes made CM6 the Goliath(sp?) I loved.
Welcome from the coldness that is frozen yogurt, and into the warmth of gingerbread.
Wait, let me clarify here, jaybob, are you going to put out new builds of CM7 as it comes out, in the same way you were before? I found yours to be of far higher quality than the nightly/stable releases.
Repo Update
Updated the repo to eliminate conflicts with 'lunch' for makefiles included in the buildmods directory.
Also added the quick and dirty 'install-buildmods.sh' script to copy the files from buildmods to the appropriate directories. Executing this script from the buildmods directory takes care of the copy actions indicated in step 3.
LiquidSolstice said:
Wait, let me clarify here, jaybob, are you going to put out new builds of CM7 as it comes out, in the same way you were before? I found yours to be of far higher quality than the nightly/stable releases.
Click to expand...
Click to collapse
ATM, I am just working on getting an environment that will let me build from source as it continues to develop. Without a device tree that works, there was not much I could do.
As things progress, I may put out CM7 builds, but I am still a ways from that point. I am starting to look at the TMO Theme Chooser approach to building installable themes. This would produce themes that are independent of the ROM, which would probably end up being a lot easier than the 5 separate builds that I produced for CM6.
I have only been playing with this for a couple days so far. Fortunately, there was a lot of other development efforts to leverage. I will continue to move this forward as my time and interest allows.
jaybob413 said:
ATM, I am just working on getting an environment that will let me build from source as it continues to develop. Without a device tree that works, there was not much I could do.
As things progress, I may put out CM7 builds, but I am still a ways from that point. I am starting to look at the TMO Theme Chooser approach to building installable themes. This would produce themes that are independent of the ROM, which would probably end up being a lot easier than the 5 separate builds that I produced for CM6.
I have only been playing with this for a couple days so far. Fortunately, there was a lot of other development efforts to leverage. I will continue to move this forward as my time and interest allows.
Click to expand...
Click to collapse
Awesome, really liked your past work.
jaybob413 said:
ATM, I am just working on getting an environment that will let me build from source as it continues to develop. Without a device tree that works, there was not much I could do.
As things progress, I may put out CM7 builds, but I am still a ways from that point. I am starting to look at the TMO Theme Chooser approach to building installable themes. This would produce themes that are independent of the ROM, which would probably end up being a lot easier than the 5 separate builds that I produced for CM6.
I have only been playing with this for a couple days so far. Fortunately, there was a lot of other development efforts to leverage. I will continue to move this forward as my time and interest allows.
Click to expand...
Click to collapse
Take your time. The work you do is quality stuff.
Thanks for this! Worked great, once I actually read the "also needs 'setup-makefiles.sh'" part and ran it. For whatever reason Gallery3D didn't get built, but I just downloaded it from the market. Everything else works as expected!
Worked great! Thanks for your efforts.
Sent from my HERO200 using XDA App
Repo Update
Updated kernel, wlan.ko, and additional loadable kernel modules after kernel rebuild to add scaling_available_frequencies virtual file needed by CPU settings.
Added libspeech.so to proprietaries, and minor build config changes.
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.
Hi guys,
I've written a completely new Android binder driver (for IPC), which is targeted to solve some fundamental issues in the existing driver. One main improvement is to make concurrent IPC calls possible. Some background info can be found in my earlier post on Android kernel group:
http: slash slash groups.google.com/group/android-kernel/browse_thread/thread/c57874670e4decb1
(oops external urls are not allowed for new users
There weren't many people interested due to low volume of the group. Now that I have completed the first version, which is back compatible with the existing driver, and fixed a few bugs. I've tested on the ICS emulator and my phone U8150 Froyo. It seems to be running quite well, but I want to see how it runs on other Android devices while I'm getting my new phone. Test results, bug/issue reports, and of course community comments will be very welcomed, which are important for me to determine how the code should further move on.
Although not proven, I'm expecting not only those dual core phones, but single core ones will get an overall smoother response in various parts of the system.
Okay if this still somehow interests you, you can find my project on github
https: slash slash github.com/rong1129/android-binder-ipc
and just dive into the release directory, use the latest version (0.4 so far) to patch your kernel source tree, then upload the new kernel image to your device and see whether it works for you.
Note this is still an early release and has very limited tests so far. Please make sure you understand the risk before you hack your phone and always back up everything before you started. As other disclaims go, I'm not responsible for any damage may be caused by or related to using or in the process of using the driver
Lastly, happy hacking!
Cheers,
Rong
*subscribing to this thread*
Hi Rong,
thank you so much
our phones, tablets, etc.
can't have too much smoothness
I hope that I'll find some time within the next weeks to also give this a test on the Xoom and see whether it works (with ICS; Team Eos kernel)
there at least seem to be issues with ICS on the SGS (galaxys s1)
http://forum.xda-developers.com/showpost.php?p=23937103&postcount=2502
I found this thread . Is this driver the same on all android devices and roms? Or do you have to mod it for every single device/rom?