Related
http://www.engadget.com/2009/09/14/htc-hero-firmware-update-peps-up-the-sense-experience-to-somethi/
Good news for HTC Hero early adopters: HTC has a new firmware update out now for the device that considerably speeds up the interface, if the multitude of reports to be found on the internet can be believed. Seeing as this was the number one gripe with the overall excellent UI, we're incredibly glad HTC has gotten work on this, and we'll be spending some more time with the device to return our newly tinted impressions. There's a video after the break demonstrating changes, and most actions seems quite a bit quicker and smoother, all the way down to opening and closing the apps menu, and sliding between home screens.
Click to expand...
Click to collapse
I hope the devs are able to snatch up a copy of that and get it into our already awesome roms! I vote for MyHero 0.1.1 myself
Wow. WRONG SECTION.
Okay, you do realize that it's the KERNEL that provides an increase in speed for the Hero ported builds, right?
Well, if you didn't...now you do. The build number does not matter. As for that OTA update that HTC is delivering, that comes standard with the HTC kernel that XDA had ages ago...and is NO LONGER in use. Most developers are using 2.6.29.6 - not 2.6.27! You do the math and figure out which would be more recent. JAC and CC's latest is based on the 2.83 build. While Drizzy's latest is based on the 2.86 build.
That HTC update is only the 2.73 build packaged in-full.
Reignzone said:
Okay, you do realize that it's the KERNEL that provides an increase in speed for the Hero ported builds, right?
Well, if you didn't...now you do. The build number does not matter. As for that OTA update that HTC is delivering, that comes standard with the HTC kernel that XDA had ages ago...and is NO LONGER in use. Most developers are using 2.6.29.6 - not 2.6.27! You do the math and figure out which would be more recent. JAC and CC's latest is based on the 2.83 build. While Drizzy's latest is based on the 2.86 build.
That HTC update is only the 2.73 build packaged in-full.
Click to expand...
Click to collapse
Hmm... That's not quite correct. That's like saying MS Word is slow because of the Windows kernel. MS Word is most of the problem...
Yes, the devs here have done some great stuff squeezing more speed out of the kernels with swap partitions and BFS - but that is only half the equation. Sense UI is an APP that run on top of the kernel, so it stands to reason that HTC could have optimized the code in Sense UI (and other apps) to improve performance.
-V
Reignzone said:
Okay, you do realize that it's the KERNEL that provides an increase in speed for the Hero ported builds, right?
Well, if you didn't...now you do. The build number does not matter. As for that OTA update that HTC is delivering, that comes standard with the HTC kernel that XDA had ages ago...and is NO LONGER in use. Most developers are using 2.6.29.6 - not 2.6.27! You do the math and figure out which would be more recent. JAC and CC's latest is based on the 2.83 build. While Drizzy's latest is based on the 2.86 build.
That HTC update is only the 2.73 build packaged in-full.
Click to expand...
Click to collapse
Yea, this is really not accurate at all. The patched kernels help with things like compcache, bfs, etc but the app/ui itself is what has been optimized in this release and is SIGNIFICANTLY faster than the 1.73.xxx version, even using the same HTC kernel.
Also, WRONG FORUM!
what i am looking forward to is the sense ui they said will come native to htc magics. we wont need to port the hero one anymore when that comes. hopefully soon, october was the month rumored.
vro25 said:
Hmm... That's not quite correct. That's like saying MS Word is slow because of the Windows kernel. MS Word is most of the problem...
Yes, the devs here have done some great stuff squeezing more speed out of the kernels with swap partitions and BFS - but that is only half the equation. Sense UI is an APP that run on top of the kernel, so it stands to reason that HTC could have optimized the code in Sense UI (and other apps) to improve performance.
-V
Click to expand...
Click to collapse
Hate to correct you here when trying to prove me wrong but;
ROSIE is the APK that runs over SENSE, not the other way around. The userinterface integrates itself with the OS.
And yes, I am more correct than not. Microsoft has nothing to do with Android. That's an entirely different ballpark, regardless of whether or not they are both operating systems. That comparison is irrelevant...considering "BFS" is not packaged with Microsoft kernels. The End.
Again.
hakeem9 said:
Yea, this is really not accurate at all. The patched kernels help with things like compcache, bfs, etc but the app/ui itself is what has been optimized in this release and is SIGNIFICANTLY faster than the 1.73.xxx version, even using the same HTC kernel.
Click to expand...
Click to collapse
The official build is not optimized. It's an official release, therefore it's a feature-rich build. HTC does not cut-down the applications list, widgets, etc. because the company has standards based on increasing speed and reliability whilst not having to sacrifice any adds-on. The optimization you speak of is only relevant HERE...at XDA, because the Hero ported ROM developers OPTIMIZE them by removing applications, widgets, and various other things packaged BY HTC within their official build to increase responsiveness on OUR devices that do not necessarily have the abilities to operate at a caliber comparable to the HTC Hero. (Run-on sentence, I know, I know.)
Reignzone said:
The official build is not optimized. It's an official release, therefore it's a feature-rich build. HTC does not cut-down the applications list, widgets, etc. because the company has standards based on increasing speed and reliability whilst not having to sacrifice any adds-on. The optimization you speak of is only relevant HERE...at XDA, because the Hero ported ROM developers OPTIMIZE them by removing applications, widgets, and various other things packaged BY HTC within their official build to increase responsiveness on OUR devices that do not necessarily have the abilities to operate at a caliber comparable to the HTC Hero. (Run-on sentence, I know, I know.)
Click to expand...
Click to collapse
You obviously do not like being wrong and obviously have no programming experience either. If they have optimised sense ui ofcourse its not just the kernel. When programming there's plenty of different ways you can get the software to produce a result to end user. if they tidy up the code and compact it down ofcourse you can make it more speedy and efficient.
replies
Reignzone said:
Hate to correct you here when trying to prove me wrong but;
ROSIE is the APK that runs over SENSE, not the other way around. The userinterface integrates itself with the OS.
And yes, I am more correct than not. Microsoft has nothing to do with Android. That's an entirely different ballpark, regardless of whether or not they are both operating systems. That comparison is irrelevant...considering "BFS" is not packaged with Microsoft kernels. The End.
Click to expand...
Click to collapse
Ok, seriously, the biggest problem with the Hero rom performance is the shell called touchflo. If you take a hero rom and use the regular home instead of touchflo the performance is night and day better. This is obviously not because of any change in the kernel (since the only change was the home shell). Based on that, I would say that HTC could improve what they collectively call Sense UI very easily by improving the shell portion of the equation.
Since my question was pointed towards the new HTC release and merging it with the current roms, that to me would seem like a DEVELOPMENT question. I also got many great answers on here that all seem like DEVELOPMENT type answers.
Right Forum. Thanks for the replies so far everyone. Hopefully we can determine if HTC released changes to the Sense UI application that the devs already had or if these are new changes (not Kernel).
If Im not wrong most of the Hero builds around here are already based on 2.73, including myhero.
Also, the increase in speed is more than just the kernel. Although a scheduler like BFS can increase the performance, the 1.7x Hero builds are much slower than the 2.73. I remember one of the Hero devs saying that the 2.73 Rosie.apk is way smaller than the 1.7x one.
Anyway, just take any 1.7 Hero build and compare it to a 2.7 build, hopefully both without BFS. I'm sure you will find that Rosie is generally more responsive.
If Im not wrong most of the Hero builds around here are already based on 2.73, including myhero.
Also, the increase in speed is more than just the kernel. Although a scheduler like BFS can increase the performance, the 1.7x Hero builds are much slower than the 2.73. I remember one of the Hero devs saying that the 2.73 Rosie.apk is way smaller than the 1.7x one.
Anyway, just take any 1.7 Hero build and compare it to a 2.7 build, hopefully both without BFS. I'm sure you will find that Rosie is generally more responsive.
Reignzone said:
Hate to correct you here when trying to prove me wrong but;
ROSIE is the APK that runs over SENSE, not the other way around. The userinterface integrates itself with the OS.
And yes, I am more correct than not. Microsoft has nothing to do with Android. That's an entirely different ballpark, regardless of whether or not they are both operating systems. That comparison is irrelevant...considering "BFS" is not packaged with Microsoft kernels. The End.
Click to expand...
Click to collapse
Wow. Where to start...
Yes, you're right - Microsoft has nothing to do with Android - I was stating an example of an App vs. an OS Kernel. You clearly missed what was a fairly obvious comparison. That make me wonder the type of person we're debating with - as it seems it's everyone against, well, you. But go ahead and stick to your guns.
My point was, kernel enhancements being done here are - for the most part - to optimize the build so it runs on inferior hardware (Dream, Magic 32B). BFS is a different beast altogether and a welcome add-on.
HTC managed to speed up Hero without resorting to BFS, this is because most speed improvements in the UI come from improvements in the Rosie.apk - hence the devs here "slimming" it down to use less memory and run better on non-Hero hardware.
Of course, that's not to say that some of the latest Hero builds aren't already using parts of this official Hero build - they all come from official Hero builds (leaked or otherwise).
The point is you are absolutely wrong in your argument that performance gains only come from kernel version increments. So you can either get over it and learn something - or you can keep arguing with everybody. Frankly I've already spent enough time on you and if you don't get it by now you probably never will so there is no point in continuing any further... But I'm sure others will probably want to have some fun at your expense if you still refuse to see the light.
I have a feeling this isn't the first time you've been corrected and I'm positive it won't be your last. As such, you shouldn't be so quick to jump on others.
Do you know the saying, "a little bit of knowledge is dangerous..."
;-)
You know, for a really good example of how it's not the kernel that determines the speed of everything, just think of how your market apps get updated all the time and how some will say *speed improvements*. The app gets updated to utilize the hardware and performance available and in turn improves its own speed better. Now the kernel does determine a great deal, but the apps are just as important with how they're coded. I would say these leaked kernel's are probably better than the new Rosie update, however there may be optimizations in the rosie ui, or other apps, that I'm sure the devs will rip or have already ripped that will continue to make our lives interesting in the coming days!
This forum is freaking amazing and you all are what make the experience here so enjoyable! Thank you all, especially you devs for making this such a great community!
~*Apollo*~
So, since HTC is now almost 3 months past due releasing the kernel sources, I've been trying to adapt the GSM kernel to compile and work with our devices, by disassembling the stock kernel and going through line-by-line of the source to see what needs changing.
I started by copying all the '*hero*' files to be '*heroc*', and renamed all the symbols to be heroc as well. Then pulled /proc/config.gz to use as a base config. Also had to fix up the Kconfig's and Makefile's, as needed, to be able to support HEROC-specific stuff. That more or less gets it to a point where you can compile the kernel successfully, although it's still just a GSM kernel with the name and mtype of heroc.
Then I imported the stock kernel (extracted from boot.img, then decompressed) into IDA as a ROM, setup the CONST segment of string data, imported the symbols from /proc/kallsyms using an ida .idc script, and analyzed the remaining areas of the ROM. At that point, I had a virtually fully analyzed binary ROM in ida, complete with symbols. Then went through and renamed the important symbols from the board-heroc* segments as needed to match what is in the source. I also set up some of the more complicated structures/arrays to make them easier to identify.
I found several differences between the stock heroc ROM, and the make-shift hero-turned-heroc source code, and fixed most of what I came across, or just left notes for things to investigate later. What I have now is a hybrid GSM/CDMA kernel that will likely not boot on either device But I figure since I've put as much time into as I have, and I'm sure there are people more familiar with IDA and ARM than I am, I'm putting my IDA file out there for people to start from. If you're not familiar with ARM assembly, this is absolutely useless to you, so you probably shouldn't bother.
I've spent 2 sleepless nights on it already, and still can't get anything to boot. I also tried to get htc_fb_console working so that I could at least see where and why it was dying, but that hasn't worked out well either.
So, by all means, have fun: http://madcoder.binti.ehpg.net/~madcoder/stock_kernel_heroc.i64
It was created using IDA 5.2, 64-bit, but I don't know how well other versions are with compatibility. Oh yeah, it's 35MB
And if you make some breakthroughs, please post about it here. When I get some time, I'll make a patch set to go from the released GSM kernel, to what I have now, and put that up here too.
Thank you, sad but true
I just wanted to say thank you for this work and express how sad it makes me to see the necessity of reverse-engineering in an OPEN SOURCE kernel. I never thought I would see the day.
I would be very curious to hear from you about the specific differences your disassembling unearthed. Can you say with certainty that the Linux kernel code has indeed been changed to work on the CDMA Hero? I mean it's not simply a matter of some missing driver code or other userspace stuff? If so, this would be pretty damning for HTC.
Thanks again, it's amazing to watch the XDA developers' progress in spite of the barriers put in front of their work.
The majority of differences I found were in things like heroc_fixup() where it doesn't check for engineerid/skuid/etc; different camera driver (s5k3e2fx, vs cy8c); fewer checks for multiple pieces of hardware (which is weird considering the stock phone's kernel supports 4 devices) based on system_rev; wrong vreg_get() strings; etc.
The source that HTC released *does* appear to have all the support we need. With modifications to Kconfig and Makefile, and ignoring the missing board files, you *can* compile the kernel directly, using the stock /proc/config.gz, which means all the necessary drivers are already in the GSM source. It's quite obvious that they had a working kernel tree that supported the GSM phone, plus our 4 CDMA phones, and they simply yanked out the CDMA board files and Kconfig changes, before releasing the source code.
What worries me is that I can't get a console, so it's incredibly difficult to find out where it's dying at. If I could get even a serial console to work, it would make this task so much easier. I think my next step is going to be to load up my hacked kernel into ida, and see how different the two are -- that might be easier than translating asm into C and comparing that way. If I can just compare the assembly for the two, it'd probably be easier.
maejrep said:
plus our 4 CDMA phones
Click to expand...
Click to collapse
Not to derail this too much, but which 4 phones do you mean? does it name them in some way?
markachee said:
Not to derail this too much, but which 4 phones do you mean? does it name them in some way?
Click to expand...
Click to collapse
MACH_HEROC (sprint hero)
MACH_DESIREC (vzw droid eris)
MACH_HEROCT (not entirely sure, maybe bell south hero?)
MACH_NEONC (neon is supposed to be the touch dual, which afaik has never been planned as an android phone, so I'm not sure what's up with this name either)
You can see those in the /proc/config.gz on the phone (ungzip or zcat it first ), and just search for "CONFIG_MACH_".
Also in the htc_wifi.c source, you can see references to espresso, and many others.
Would it be possible to port the moment kernel over and use that since its the same processor type and then fill in the things we need?
Mr. Biggz said:
Would it be possible to port the moment kernel over and use that since its the same processor type and then fill in the things we need?
Click to expand...
Click to collapse
I was talking to zefie not too long ago and he was saying the hero kernel is so much more stable than the moments kernel... just my 2 cents.
Keep up the amazing work mad man.
travo1 said:
I was talking to zefie not too long ago and he was saying the hero kernel is so much more stable than the moments kernel... just my 2 cents.
Click to expand...
Click to collapse
Yeah, my fiance went through 2 moments, and they were so buggy she switched to the Hero. No problems since.
flipzmode said:
Keep up the amazing work mad man.
Click to expand...
Click to collapse
+1 for keeping up the good work!
:beer: (Does that emote work on this forum? I hope so...)
bumping this so it doesnt get buried 3 pages again
toastcfh said:
bumping this so it doesnt get buried 3 pages again
Click to expand...
Click to collapse
I thought you said you were going to bed
gu1dry said:
I thought you said you were going to bed
Click to expand...
Click to collapse
i was till i had to refresh again
Yeah, I basically put this on hold, due to work priorities (happens a lot unfortunately :/)
But with the news that HTC may be releasing the source soon, this is probably not worth continuing anyway
maejrep said:
Yeah, I basically put this on hold, due to work priorities (happens a lot unfortunately :/)
But with the news that HTC may be releasing the source soon, this is probably not worth continuing anyway
Click to expand...
Click to collapse
Honestly, I would continue it. Nobody's sure that HTC will release the source code (HTC said they would release the source for the "Gero"...we're hoping that was a mistype).
I have a feeling they won't release it anytime soon and you'll probably solve the entire issue with the cameras and more before that source is released.
bump.... its on the second page
Yea def keep the good work up HTC said over the weekends tht came and went so now all we got is you my good man
man we gotta get this thread stickied!!!!
toastcfh said:
man we gotta get this thread stickied!!!!
Click to expand...
Click to collapse
agreed... lol
anyhow i think this will work out before the htc hope does. bumped to the top
So, with some inspiration from NetRipper, I started trying to find a way that I could see how far it gets in the kernel booting before it stops, since I still don't have a console. Unfortunately, his suggests were LED-related (particularly gpio-enabled), and we don't have any of those. Did find one reaction that is very hard to miss, and luckily very easy to trigger: reboot via gpio
So now I'm stepping through the code, trying to find at what point in execution it stops rebooting and just hangs. So far I'm in init level 4 (of 6). I'm really hoping this leads me to something that will at least tell me "well THERE'S your problem!", and I can reverse the stock kernel asm to figure out what is different.
Okay everyone. I am working on an optimized 2.6.27 until we can get .29 ported over. But I figure, since I am fairly new to the kernel world, how can we get started porting this bad boy over? I have been looking through the source code but am somewhat lost as to where to get started. I figure if we are able get this going we can make a github account and have the progress set up for everyone. All you devs wanna join in?
chuckhriczko said:
Okay everyone. I am working on an optimized 2.6.27 until we can get .29 ported over. But I figure, since I am fairly new to the kernel world, how can we get started porting this bad boy over? I have been looking through the source code but am somewhat lost as to where to get started. I figure if we are able get this going we can make a github account and have the progress set up for everyone. All you devs wanna join in?
Click to expand...
Click to collapse
Seems like I just read someones already got a github setup. Can we branch instead of running 2 accounts if this is the case?
I am also very new to the whole kernel. I think I have actually only compilied 3 succesful linux kernels in my short life. Attempted others, but I usually get lazy or run out of time.
Kcarpenter said:
Seems like I just read someones already got a github setup. Can we branch instead of running 2 accounts if this is the case?
I am also very new to the whole kernel. I think I have actually only compilied 3 succesful linux kernels in my short life. Attempted others, but I usually get lazy or run out of time.
Click to expand...
Click to collapse
If someone has made a github project please let me know. I havent made a 2.6.29 github project yet. I am currently doing one for 2.6.27.
I created a 2.6.27 repo this morning when the source was released. And I've checked out 2.6.29, just haven't set it up in github.
Really?
What's the difference between the android kernel and the regular linux kernel? It seems their version numbers are closely related. So why not go up to the newest stable (2.6.32.5)?
lazydev said:
What's the difference between the android kernel and the regular linux kernel? It seems their version numbers are closely related. So why not go up to the newest stable (2.6.32.5)?
Click to expand...
Click to collapse
It's not that simple. For starters we have to copy over the drivers for our phone and make sure they compile correctly. On top of that HTC modified quite a bit of the kernel. Porting it over will happen but it may take some time. Like I said before I am new to the linux kernel deal but I do know it is more difficult than it seems.
I'd say a completely functional port will take roughly 2 weeks time for a hobbyist. I'm not sure though as I'm still new to messing with linux kernels. I'm looking into a port of my own. Debating 2.6.29 or porting the android specific bits to a newer linux kernel. Chances are porting the hero specific stuff to the android 2.6.29 kernel source will be much simpler. It sucks I'm on my laptop at work and it isn't running linux so no compiling, diff patching or coding for me tonight. I wish I was a bit more profficient with C programming too. I guess now I have a good reason to do just that.
lazydev said:
What's the difference between the android kernel and the regular linux kernel? It seems their version numbers are closely related. So why not go up to the newest stable (2.6.32.5)?
Click to expand...
Click to collapse
edit: didnt release chuckriczko answered your question..
obelisk79 said:
It sucks I'm on my laptop at work and it isn't running linux so no compiling, diff patching or coding for me tonight.
Click to expand...
Click to collapse
Maybe it's time to start carrying around a LiveUSB distro of Linux on a flash drive
gu1dry said:
Maybe it's time to start carrying around a LiveUSB distro of Linux on a flash drive
Click to expand...
Click to collapse
no kidding... I wasn't expecting to wake up to a new release. Of course I could just run linux on my laptop and call it a day
Yeah, the reason it's better to start with .29 than jump to .32, because a lot of the work has already been done for us in .29. In fact, if you really investigate the kernel source they released, vs the kernel on our phones, you'll notice that HTC has already backported some of the .29 changes in the android-msm-2.6.29 branch into the source they released, which was *not* initially the case in the kernel that they shipped.
What we need to do to get .29 actually working, is the opposite: forward-port the HTC changes for hero/c into the .29 source.
FYI: got an initial codebase that compiles, but does not boot yet:
http://github.com/jhansche/kernel_msm/commit/19a2d673867a8e11b98cce399ed89c94811ebf77
Started from android-msm-2.6.29 branch, with a few modifications that HTC made in our code, ported over (not all of them, mind you). If anyone has any suggestions for debugging why the kernel doesn't boot, I'm glad to hear them If I had a serial debug cable, that would be useful, cause then it would work as a serial console. But for now all I have to go on is the fact that it dies *before* ram_console can be initialized (even with early-init enabled).
I've also disabled several pieces of hardware in the interest of just getting a clean compile -- namely headset, 3.5mm audiojack, EID mddi client (lcd panel) has not been copied over yet, and some other stuff.
maejrep said:
FYI: got an initial codebase that compiles, but does not boot yet:
http://github.com/jhansche/kernel_msm/commit/19a2d673867a8e11b98cce399ed89c94811ebf77
Started from android-msm-2.6.29 branch, with a few modifications that HTC made in our code, ported over (not all of them, mind you). If anyone has any suggestions for debugging why the kernel doesn't boot, I'm glad to hear them If I had a serial debug cable, that would be useful, cause then it would work as a serial console. But for now all I have to go on is the fact that it dies *before* ram_console can be initialized (even with early-init enabled).
I've also disabled several pieces of hardware in the interest of just getting a clean compile -- namely headset, 3.5mm audiojack, EID mddi client (lcd panel) has not been copied over yet, and some other stuff.
Click to expand...
Click to collapse
Great work! As I said before I am new to this linux kernel stuff and don't think I can help but I am cloning the repo so I can take a look anyway.
Any progress with getting it to boot?
Any update on this project?
I have also been curious about this for a couple of days, just didn't want to sound pushy to the devs... hope theyre seeing progress.
theoottesen said:
I have also been curious about this for a couple of days, just didn't want to sound pushy to the devs... hope theyre seeing progress.
Click to expand...
Click to collapse
I checked the githup out. still doesn't boot
Yeah, I've been hitting a brick wall trying to get some kind of indication that something is happening... On .27 I lucked out by somehow getting it to go past the ram console, then reboot, so I could see the panic messages on /proc/last_kmsg. But in .29, I can't even write directly to the ram console memory space in a pure_init section. The problem is that there's no way to know how far it's getting in the boot process. So we're really just booting blindly.
On top of that, the android-msm-2.6.29-nexusone branch has non-QSD8k bugs (that is, if you select that it's an MSM device, not a QSD device, it won't compile without fixing stuff in their acpu code for arm11, MDP22 code paths, etc. it's like the nexusone branch was only ever tested with scorpion, not arm11 (even though it has the board files for sapphire, so you would expect it to compile for sapphire)
maejrep said:
Yeah, I've been hitting a brick wall trying to get some kind of indication that something is happening... On .27 I lucked out by somehow getting it to go past the ram console, then reboot, so I could see the panic messages on /proc/last_kmsg. But in .29, I can't even write directly to the ram console memory space in a pure_init section. The problem is that there's no way to know how far it's getting in the boot process. So we're really just booting blindly.
On top of that, the android-msm-2.6.29-nexusone branch has non-QSD8k bugs (that is, if you select that it's an MSM device, not a QSD device, it won't compile without fixing stuff in their acpu code for arm11, MDP22 code paths, etc. it's like the nexusone branch was only ever tested with scorpion, not arm11 (even though it has the board files for sapphire, so you would expect it to compile for sapphire)
Click to expand...
Click to collapse
So if I understand correctly, the devs that worked on the kernel for the Nexus One got lazy and never tried to see if it compiled on the Sapphire?
If they were developing the kernel for the nexus id hardly call them lazy for not taking the time to check it on other devices.
Any word from any one on when the devlopers will get the source code for this phone? I realize that this will help everyone developer wise get a better handle on kernels and greatly help the community.
I went back to GB for a second there but the charging issues have gotten out of control with the kernels which is why I'm starting to wonder when the sourrce will be released. We obviously need it to make further advancement with the community ROMs at this point.
I also seen where HTC said that they will unlock their bootloaders here soon.
Thanks for any one who contributes to this conversation.
Gingerbread? Or Froyo? Cuz Froyo been out...
Thunderbolt «» das BAMF Remix
Kid_Cudi said:
Gingerbread? Or Froyo? Cuz Froyo been out...
Thunderbolt «» das BAMF Remix
Click to expand...
Click to collapse
I like Kid Cudi as well first of all.
What I mean is and I'm probably not going to use the right term here but the RIL or perhaps SDK.. Bear with me here I'm good at trouble shooting stuff but not programming.
I was googling it didn't help me get the right term lol. Chime in who ever knows what the hell I'm talking about here lol.
The kernel source itself has been out for quite some time. We will never see the "source" for the RIL (Radio Interface Layer) because it is proprietary on both HTC and Qualcomm's side. That's about as simple as it gets.
ProTekk said:
The kernel source itself has been out for quite some time. We will never see the "source" for the RIL (Radio Interface Layer) because it is proprietary on both HTC and Qualcomm's side. That's about as simple as it gets.
Click to expand...
Click to collapse
Yeah I think it's RIL. It's what the Cookers keep stating they're waiting for to finish their ROMs like CM7 for instance. The developer for it states that he's waiting for RIL to be able to officially finish his work. We really need to get this released from HTC so we can fix some of the issues people are having with CM7 and the leak for GB. I went back to Froyo because of the issues the leaks having with charging etc..
thewebsiteisdown said:
Any word from any one on when the devlopers will get the source code for this phone? I realize that this will help everyone developer wise get a better handle on kernels and greatly help the community.
I went back to GB for a second there but the charging issues have gotten out of control with the kernels which is why I'm starting to wonder when the sourrce will be released. We obviously need it to make further advancement with the community ROMs at this point.
I also seen where HTC said that they will unlock their bootloaders here soon.
Thanks for any one who contributes to this conversation.
Click to expand...
Click to collapse
HTC and google do not have to release any of the android source if they don't want to because the source (NOT THE KERNEL) uses the apache license, which is very permissive like the BSD/MIT licenses. It lets you use any code additions you make to the source for commercial projects without having to give it back unless you choose to http://en.wikipedia.org/wiki/Apache_license. This is why google doesnt have to release the Honeycomb source as long as they didn't make any additions/modifications to the kernel itself.
Google went through lots of effort as well to make sure they would not be bound by the GPL by writing their own clibs based off of code from various BSD ports. See here for an interesting article on some of the low level features of android (it's a bit old, but most of it is still relevant). http://codingrelic.geekhold.com/2008/11/six-million-dollar-libc.html
The kernel (like all linux kernels) is GPL and must be released.
RIL will be released when it is finished. Slayher is working hard as hell on it. Not saying anyone is under appreciating just give the man some time and soon we will all have MIUI and CM7 running flawlessly on our devices.
miketoasty said:
RIL will be released when it is finished. Slayher is working hard as hell on it. Not saying anyone is under appreciating just give the man some time and soon we will all have MIUI and CM7 running flawlessly on our devices.
Click to expand...
Click to collapse
I think there is a misunderstanding here. The RIL from Slayher is not the same as the RIL from HTC/Qualcomm.
Slayher will merge his "source" into the public CyanogenMod repo once he deems it's ready.
On the other hand, the "source" from HTC/Qualcomm is a whole different subject. We won't be getting a drop of it from them. Not now, not ever.
miketoasty said:
RIL will be released when it is finished. Slayher is working hard as hell on it. Not saying anyone is under appreciating just give the man some time and soon we will all have MIUI and CM7 running flawlessly on our devices.
Click to expand...
Click to collapse
I deffinately appreciate all the hard work. I just thought that HTC had to release this info. I didn't know that Slayher or any other coder could just reverse engineer it.
thewebsiteisdown said:
I deffinately appreciate all the hard work. I just thought that HTC had to release this info. I didn't know that Slayher or any other coder could just reverse engineer it.
Click to expand...
Click to collapse
No the RIL source and Sense source run under the apache license which states that the software developer can use the open source code but does NOT have to repost anything he or she produces.
So it is up to our dev's to do that and make it readily available.
What goes into a fully functional ROM for an android phone like our beloved TB's? ICS for us has been an evolution of sorts. From what I understand, first we had woefully buggy ICS because we were missing something that only the manufacturer can provide (the RIL, whatever that is?). Sounded to me like the OS would work, more or less, but it was the calling and data that was missing.
Then we got our leak. The leak provided some critical component, but we still have imperfect ROMs. What did we get, and what do we still need?
I know our devs are leaner and meaner coders than the guys at HTC, and that there have been ROMs which are much improved over the initial BAMF one. But, have we gotten ICS to a sweet spot that can't be improved by an official HTC update? Or can we still benefit from it whenever the hell it comes out?
Duely blundered from my thunderdolt.
If I have to guess, you're seeing them hang back until something a little more refined than that leak comes out. The kernel source will be very helpful in getting some kinks ironed out related to the battery life problem of the leak. Also, I believe there are camera and camcorder issues that are kernel related. Kernel source never gets released until after the official update goes public.
Some of the devs may also be preparing Jelly Bean ROMs and not even paying attention to ICS anymore. I'm hoping for this, as we're still going to be one revision behind when HTC releases Ice Cream Sandwich for Thunderbolt. I've seen at least one dev state that ICS to JB is a snap, relatively speaking, so we should get some sweet 4.1 action fairly quickly one the OTA drops.
The ril was one component we were lacking but jester stumbled across something in his build that gave us 1x data and liquid figured out some of the rest. The main thing we are missing now is official ics kernel. The leak we got was a crappy test build and I think that was among their first test builds but that is just my opinion. Once we get kernel source for ics things will be much better. We also need a kernel dev too because imoseyon has moved on to other devices and won't have time for the thunderbolt.
Sent from my Thunderbolt using Tapatalk 2
Yes, I am currently being a coward. Normally I could live without a camera and camcorder, but I just had a kid. Don't want to miss those moments because daddy hacks his phone.
So we got the RIL and need the kernel. After the real release comes out (probably by the time yet another version of Android will be out), we wait a few months, and bam we have the new htc stock ICS kernel. Is the only way to get it is from them intentionally releasing it? There's no way to reverse engineer it eh?
Guess we wont see another "lean kernel" then if Imo's out of the equation. Hopefully he's not the only show in town.
Duely blundered from my thunderdolt
Kernels can be hacked and changed to your liking but I think you can get into trouble if you publish it.
Sent from my Thunderbolt using Tapatalk 2
Liquid's current ICS ROM is pretty damn good, if only with a few hiccups that can be fixed without the new kernel. I can't even imagine how good it could be with a new official ICS kernel.
Kernels can be hacked and changed to your liking but I think you can get into trouble if you publish it.
Click to expand...
Click to collapse
Wouldn't imoseyon have gotten in trouble for all the great kernels he's released if that were true?
The Linux kernel is free for anyone to modify. If you improve it, you're expected to share your work. That's the beauty of open-source software.
If HTC doesn't release their source for the kernel but you hack it is what I mean.
Sent from my Thunderbolt using Tapatalk 2
If HTC doesn't release kernel source, they will be in violation of the GPL. The only source they can legally withhold is their own software, like Sense, or proprietary driver files. They don't own the kernel, so they must release the source after they release an official ICS build, and they can't go after anyone for hacking it and publishing the source. Of course, if they never release ICS, the wouldn't have to release the kernel source, and some brave dev would have to figure it out. I hope that doesn't happen.
I suspect we're splitting hairs on this one.
Technically, HTC isnt allowed to withhold the kernel source at all. But they do. So reverse engineering / decompiling the kernel is completely legal.
I'm super excited for ICS/JB/BBQ/whatever. I'm running liquid's rom on my bolt right now. It isn't perfect, but I love the overall user experience. It's a shame these things take so long to move through the pipe, but I'm very appreciative of the efforts folks are putting in to make this happen. :good: