Related
Based on the posts I've read, is there really no official stable version of Gingerbread released for the Epic 4G, and are all the GB ROMs buggy?
And I thought that we would be working towards ICS for the Epic 4G...
I'm new at this, but I thought that Android being open-source means that it would be easier to hack and modify and less reliant on the carriers to release new OS updates. Have I gotten it wrong?
AndroAsc said:
Based on the posts I've read, is there really no official stable version of Gingerbread released for the Epic 4G, and are all the GB ROMs buggy?
And I thought that we would be working towards ICS for the Epic 4G...
I'm new at this, but I thought that Android being open-source means that it would be easier to hack and modify and less reliant on the carriers to release new OS updates. Have I gotten it wrong?
Click to expand...
Click to collapse
Android is by far the best medium for end users. But the major hold up is that the source code has been held out by samsung. There was a leak of the source code recently. The rom to look for is Cyanogen. These guys build it from the ground up with no source code. If you really want to try a gingerbread leak . This is a good one. He also has a 2.2 android that is complete no bugs. here is the link to gingerbread http://forum.xda-developers.com/showthread.php?t=1190337
And the link to his 2.2 http://forum.xda-developers.com/showthread.php?t=1146630
At the moment I am using the beta cyanogen very close to completion. It is 2.3.7 and it runs smooth and fast. There are a few minor bugs like no 4g. The 4g was not a big deal for me as it only covered a small area for me.
Cyanogen link http://forum.xda-developers.com/showthread.php?t=1299621
Let us know if you need more help
Can tell you are new. Gingerbread is still only a leak. However kernel source was released for 2 days. If you look in Development and read the OPs on the ROMs find one based on the released source like the one with Heimdall in the title. They are stable with no reboots.
Sent from my SPH-D700 using XDA App
AndroAsc said:
I'm new at this, but I thought that Android being open-source means that it would be easier to hack and modify and less reliant on the carriers to release new OS updates. Have I gotten it wrong?
Click to expand...
Click to collapse
Yes... You've got it wrong. Hacking can only get you so far... Major version updates require source from the manufacturers.
If you want timely updates switch to iOS. With Android it's not *when* you're getting updates but *if* you're getting updates.
http://theunderstatement.com/post/11982112928/android-orphans-visualizing-a-sad-history-of-support
AndroAsc said:
Based on the posts I've read, is there really no official stable version of Gingerbread released for the Epic 4G, and are all the GB ROMs buggy?
And I thought that we would be working towards ICS for the Epic 4G...
I'm new at this, but I thought that Android being open-source means that it would be easier to hack and modify and less reliant on the carriers to release new OS updates. Have I gotten it wrong?
Click to expand...
Click to collapse
I'm currently running ACS' ICS beta rom. The ICS is just a launcher but its nifty. If you want a pretty stable eh17 rom w/o the ICS I used titanium to uninstall the launcher (and the other 2 launchers [beats me]) and used launcher pro plus. Makes for a stable gingy rom. I've also flashed the eh17 honeycomb explosion theme. Looks great and run awesome.
Supposedly nubernal fixes reboots... ill see as soon as I find time to flash
Lord Syrics Jr.
EPIC 4G
ACS ICS BETA v6
Eh17+ (soon nubernal)
There's always going to be bugs... Especially when devs start modifying what was most times just crap to begin with.
I strive to put out a stable ROM, but when you want to update something, something else may not always act as it did.
I'm in the midst of getting a second test version out of my ROM... Come back tonight and check it out. If you're into something semi-stock, then you'll like what i have to offer. =)
AndroAsc said:
I'm new at this, but I thought that Android being open-source means that it would be easier to hack and modify and less reliant on the carriers to release new OS updates. Have I gotten it wrong?
Click to expand...
Click to collapse
For the most part, "Android is open source" only applies to device manufacturers, and owners of Google-branded Nexus devices. The latter of which have (nearly) all platform source code available in Git repositories, including instructions for building a source-based ROM for them.
Third-party manufacturers do not release the majority of Android platform code for their devices. Some of this, like custom UI code, is not particularly relevant to us. But other of this, including proprietary kernel modules and userspace drivers for peripherals, is very much relevant. Not having the source to this makes getting full functionality out of source-based ROMs rather difficult. It doesn't help that Samsung's devices are "uniquely different" from HTC and others which makes porting source-based ROMs to them painful to begin with.
Ok... so in other words, to have a stable usable and relatively bug-free release of Android OS, we will need the carriers to release some official version for it?
Not necessarily. However it is often easier to support a new version of Android if the manufactuer provides an update to it.
AndroAsc said:
Ok... so in other words, to have a stable usable and relatively bug-free release of Android OS, we will need the carriers to release some official version for it?
Click to expand...
Click to collapse
No. I've been running GB forever now. Most of the issues were temp slip ups with roms or themes. The only pervasive one in all the leaked based roms is the reboots, which frankly I never found to be as big of a deal as many made it out to be. Our best guess is that it is sleep related, so in other words, it only happens when your phone is sitting untouched.
I had them quite a bit, but really not a big deal.
Install ACS ICS v6, and the nubernel kernel, and the reboots aren't an issue either.
At this point I couldn't care less if the official ever drops. (Not that I think it wont, it's just, also, IMHO, not nearly as large of a concern as some are making it.) To the extent I DO care, it's only because it will probably consolidate the efforts of the devs. Lots of work still being done on Froyo roms, and there's probably some hesitation on getting involved in any particular leak, because you never know when another leak will drop and make everything you're doing outdated.
Edit: This is anecdotal, but most of the "problems" people report are from people who seem to give gingerbread a shot for about 5 seconds. I'm willing to bet most of them restore data, or a titanium backup, from their froyo rom, then attribute any problems to gingerbread being buggy. It's not. It's fine. If anything a lot of the real not-just-whining outrage is over how GOOD it is. (AKA, the leaks are so solid, what's the hold up exactly)
I have a general IT background of 10+ years with basic scripting skills so understand on a general level about drivers but I have been reading for several months trying to understand the EXACT nature of the problem for why i still don't see a ICS rom for the evo4g with working (or semi-working) wimaxx.
Can someone please educate me? Here is my version....
Sprint has retired the evo4g via end of life decision process and so does not have a formal team working on an ICS build of any kind for my phone. I don't agree with this decision, but i understand why Sprint is not providing me with one.
Because Sprint has retired the phone, HTC is not doing any development for the phone and so THEY aren't providing me with any drivers. I'm not sure who of these two made the business decision, Sprint or HTC, probably HTC. Either way, no formal support from either of them. I don't agree, but accept that.
As for developers coming up with their own, this is where I'm expecting magic and so instead of just crying "where are my drivers, where is my rom" i am attempting to learn why they aren't here and am requesting an education on the subject.
From my understanding, AOSP is Googles contribution for free to the world. This is a great operating system for running phones for a variety of reasons. From there, manufacturers take the basic kernel and modify it to work with their equipment. This is where it gets a bit confusing for me.
I think that the manufacturers do two things. One, is that they work with chip manufacturers to obtain proprietary drivers for specific chipsets that integrate into the basic kernel. Two is that phone manufacturers ALSO modify the kernel so as to make a proprietary version of the kernel. So HTC made a propritary version of the kernel and incorporated SENSE (among other things) into that proprietary kernel, and hooked up proprietary drivers that may or may not work with the AOSP kernel to provide services such as video and wimax and sound etc.
I know teamwin some how reverse engineered or manufactured a wimax driver for gingerbread such that the wimax driver was available for the AOSP Gingerbread kernel, but teamwin or nobody else has done that such that a wimax driver is available for the AOSP ICS kernel
I know that HTC has wimax working on some of its phones that have ICS via threads that talk about it being leaked (i.e Nexxus 4g).
So here are some questions... I suspect none of them are accurately asked.
Version1
Does AOSP ICS kernel have the ability to have a wimaxx driver built/interfaced into it?
If so, is it HTC that technically owns this driver or another specific company?
Version2
If AOSP ICS kernel does not, does that mean we currently need both a specific evo4g ICS kernel AND the wimax driver built?
Or are either of these easy to build and we just need one part of them built...meaning the wimax driver is out in the world for developers now and all that needs to happens is for someone to put some "hooks" into a new evo4g kernel such that they would work with the driver.
I apologize in advance if i broke some posting rules. I can't post in developement section yet so i placed in q/a where it says "any question". I did some basic research on the subject so i'm not just whining i don't have my driver. I am trying to get at the specific thing that needs to happen for my evo4g rom to have wimax working on ICS.
My theory is "HTC owns the wimax driver for ICS but won't release the source code as they only want to bring certain wimax devices into the ICS generation. It is proprietary to a specific kernel so if it was released, it would not instantly work with the AOSP kernel and other kernels. It would still need further development (but on which end???). It is illegal and difficult for someone to reverse engineer this ICS WIMAXX driver. It is legal, but still difficult for someone to create a generic ICS WIMAXX driver. Since both are difficult they will not happen soon."
Thanks for your thoughts in advance.
*DISCLAIMER - everything I say below is based on belief and may be wrong.
Believe that the majority of what you said is correct.
Slight thing - nexxus 4g (I believe this is sammy/goog, no?)
While kernel may have specific customizations for sense, believe sense is built on top of OS (ICS) and not IN the kernel itself per se.
(MOST LIKELY SCENARIO): Believe that HTC has to release an update where ICS and Sense crap all play nicely together and sprint has to test it and release it and then xda devs need to fix it to remove bloat, optimize, and ensure no more CIQ-ish kind of crap or htc spy crap or root removal...can't trust any of these bastards. The update will have ICS + Sense + Kernel (including the proprietary or binary blob drivers for things like wimax, camera, screen).
(IDEAL SCENARIO): HTC quit being little Apple-tards, realize that their differentiator is that they ARE NOT a walled garden - that customer enthusiasm is a good thing. They get off their asses and send a working kernel source for ICS AOSP (just the kernel) to team douche/team win/team kang... somebody cool (officially or unofficially) and BAM - everything works great in the AOSP/AOKP world. I mean really - if we are going to be in a walled garden, is not Apple's the best? Why not just buy iphones if HTC's gonna be a giant douche? Turd sandwich or Samsung would be better options.
Please correct me if I'm wrong. This is a learning experience for me too!
Wondering about this as well. It would be nice if the source code for the nexus 4g(wimax) would help us on the EVO front.
One of the biggest problems for the ics rom is its not based on the kernel its supposed to be running. The kernel has been frankenkerneled from tiamats gb kernel with the correct settings to run as ics. While I know that the kernel has been updated to somewhat but its not the true ics kernel some of these other phones are running and also while team douche or team win got the wimax working on aosp gb back in the day...they are no longer working on the evo and also wimax back then wasn't a quick fix. It was on the back burner for the longest time. I commend you on wanting to work on the drivers and learn. I would start by contacting prelude drew via twitter and or atyoung the current dev for the mason ics kernel that hes had great success with. Those two could point you in the right direction or bring on board with them on getting everything working especially with your strong IT background it will come in handy.
Forgive my fading memory, but wikipedia reports Android supports wimax directly.
I thought I read elsewhere that 2.3 GB or 3 and on was supposed to support wimax natively - thereby obviating team win's wimax "fix."
?So ICS doesn't support wimax (or it does?) but we need a driver from the mfg? Is this a broadcom/qualcomm thing? Proprietary driver? Supplied to HTC as a binary blob rather than source?
Will we likely have a first breakthrough when HTC releases the source to ANY ICS kernel?
Will we similarly have a closer breakthrough when HTC releases source to a phone with wimax by same mfg?
What happened to the leaks? Ninja911? Fxck it seems dev has stagnated on these devices. So much hardware and we can't use any of it! GRRRR Why is anyone still buying HTC when they are cxckblocking us so entirely?
Surely if HTC wanted to they could release an ICS AOSP kernel source with little to no effort that works with AOSP roms right? They don't have to do any of their purported excuse for the delay (i.e. get ICS and Sense to play nice, right?)
As it is ICS AOSP can't use 4G, Netflix, Front Camera, HWA...?
On the E3d there's no 4G, no 3D camera, no 3d display, ...
HDMI/MHI surely won't work, will they?
Basically anything that makes the Evo special above a free android type phone?
Along with other issues.
GOD I'd LOVE a 4G working MIUI ICS, CM9, ... but it will never happen - just HTC's corporate culture? I think we have to vote with our $ and support Samsung or a hungry underdog (like HTC used to be) such as Huawei, LG?
Sorry for the vent. Please correct if I've miss-stated above. Learning experience.
My sentiments exactly...
I've been curious about this for the past couple months, I just assumed it was because Sprint felt the Evo4G had run its course, had a good life, etc, and it was time to retire it.
And then since Sprint was no longer supporting HTC followed suit by deciding since Sprint was cutting support for it, HTC realized it was kinda pointless for them to upgrade it. It IS almost 2 years old, so I'm not too irked by it, but I'd like to echo the OP's concern about them not just releasing some ICS compatible drivers for those of us with tinkering hands to play with.
*sigh* Guess I'll just have to wait until the LTEVO is released...
The evo was classified EOL(end of life) before ICS source was even released by Google, therefore HTC has no ICS drivers for them to release because a) they never built anything ICS for the evo and b) alot of the hardware drivers are proprietary and come from the individual hardware manufacturers and not HTC. HTC simply compiles the drivers into a final build to make each specific device function
Sent from my SPH-D710 using xda premium
-EViL-KoNCEPTz- said:
The evo was classified EOL(end of life) before ICS source was even released by Google, therefore HTC has no ICS drivers for them to release because a) they never built anything ICS for the evo and b) alot of the hardware drivers are proprietary and come from the individual hardware manufacturers and not HTC. HTC simply compiles the drivers into a final build to make each specific device function
Sent from my SPH-D710 using xda premium
Click to expand...
Click to collapse
Ok, so i understand that HTC and Sprint are out of it, but WHO is the manufacturer of my wimax antenna and is this antenna in any device that has ICS running on it? If so, I'm sensing from this post that even if they release this driver, it still won't help cuz the EVO 4g ICS rom's are actually frankensteined gingerbread code? That seems even weirder. Why wouldn't the EVO 4g ICS roms be frankensteined ICS code massaged for the evo from ICS?
Thanks for the term BLOB. I'll research how that interplays with kernel and OS version and driver and see if i can get a better handle on it. It just annoys me that i'm paying for wimax but in order to use it i have to be on older OS. This phone is totally fine for my basic needs and still has plenty of life left in it. They are accellerating the "planned obselecense" way to fast. Sorry for the typos...its late for me. Thanks everyone.
ittsmith said:
Ok, so i understand that HTC and Sprint are out of it, but WHO is the manufacturer of my wimax antenna and is this antenna in any device that has ICS running on it? If so, I'm sensing from this post that even if they release this driver, it still won't help cuz the EVO 4g ICS rom's are actually frankensteined gingerbread code? That seems even weirder. Why wouldn't the EVO 4g ICS roms be frankensteined ICS code massaged for the evo from ICS?
Thanks for the term BLOB. I'll research how that interplays with kernel and OS version and driver and see if i can get a better handle on it. It just annoys me that i'm paying for wimax but in order to use it i have to be on older OS. This phone is totally fine for my basic needs and still has plenty of life left in it. They are accellerating the "planned obselecense" way to fast. Sorry for the typos...its late for me. Thanks everyone.
Click to expand...
Click to collapse
Its Frankenstein gb code with ics code intertwined cause there are no drivers for ics that'll run the evo so the other kernel was modified to work for ics
I'm no expert on Android but I do understand operating systems pretty well, so here is my best guess as to what is going on:
1) A kernel is pretty hardware generic (maybe architecture dependent only) and provides various functions to the software that runs on top of it (e.g. the Dalvik VM that runs most Android apps and Android/Sense UI) and it is provided by Google. Each kernel will need to have certain features/capabilities that are specific to a given Android release (i.e. you can't just use a GB kernel with ICS since it will be missing some features expected by the ICS UI and Dalvik VM).
2) Individual manufacturers need to add drivers (kernel modules) in with the generic kernel from Google to support the specific chips on a given phone. So, for our Evo 4g there need to be drivers for the WiMax chip, camera, bluetooth, etc.. These drivers need to be updated for each new Android release kernel. Depending on how a release kernel changes, this could be just a re-compile or it might require somebody to rework the code. If the WiMax code needs more than just a recompile, then it is either a lot of work for an amateur dev team to try and refactor the GB WiMax code to work for an ICS kernel OR HTC needs to do the work and release it for us. Since the latter is unlikely to happen, getting WiMax working would require a lot of work from an amateur developer.
3) It is also possible that some drivers are just released as binary blobs that are loaded by the kernel. In this case, a binary driver that was compatible with a GB kernel may no longer be compatible with the ICS kernel. In this case if HTC doesn't release it, it would require a ground up write of an ICS driver for WiMax, which is unlikely to happen.
The above is my best guess as to what is going on as a general field expert on kernels/drivers. Since I'm not as familiar with Android specifically, I could be off on what is happening here. We'd need somebody who has played around with Android kernel development for the Evo 4g to say for sure.
bjohanso said:
I'm no expert on Android but I do understand operating systems pretty well, so here is my best guess as to what is going on:
1) A kernel is pretty hardware generic (maybe architecture dependent only) and provides various functions to the software that runs on top of it (e.g. the Dalvik VM that runs most Android apps and Android/Sense UI) and it is provided by Google. Each kernel will need to have certain features/capabilities that are specific to a given Android release (i.e. you can't just use a GB kernel with ICS since it will be missing some features expected by the ICS UI and Dalvik VM).
2) Individual manufacturers need to add drivers (kernel modules) in with the generic kernel from Google to support the specific chips on a given phone. So, for our Evo 4g there need to be drivers for the WiMax chip, camera, bluetooth, etc.. These drivers need to be updated for each new Android release kernel. Depending on how a release kernel changes, this could be just a re-compile or it might require somebody to rework the code. If the WiMax code needs more than just a recompile, then it is either a lot of work for an amateur dev team to try and refactor the GB WiMax code to work for an ICS kernel OR HTC needs to do the work and release it for us. Since the latter is unlikely to happen, getting WiMax working would require a lot of work from an amateur developer.
3) It is also possible that some drivers are just released as binary blobs that are loaded by the kernel. In this case, a binary driver that was compatible with a GB kernel may no longer be compatible with the ICS kernel. In this case if HTC doesn't release it, it would require a ground up write of an ICS driver for WiMax, which is unlikely to happen.
The above is my best guess as to what is going on as a general field expert on kernels/drivers. Since I'm not as familiar with Android specifically, I could be off on what is happening here. We'd need somebody who has played around with Android kernel development for the Evo 4g to say for sure.
Click to expand...
Click to collapse
You're fairly close, the android kernel is essentially the Linux kernel, HTC doesn't build the wimax driver I believe its qualcomm that makes the radios in our devices but I'm not sure they make the wimax radio or just the cdma radio. They make a good amount of the hardware in the evo from radios to gpu to audio control components. Building the drivers isn't an easy task for any single dev without existing source to modify, even someone who does it for a living would have a long, difficult road to building a driver from the ground up with no preexisting source to use as a map I've been working on drivers for ics for a cpl months and its not easy starting with a blank page and starting code from scratch. Even with the existing aosp wimax drivers available for the evo, so much has changed in ics modifying the drivers is basically like starting from scratch cuz so much code needs to be reworked. It will probably be one of the last things to be added just like it was on gb
Sent from my SPH-D710 using xda premium
What about when they update the EVO3D? Will either the ics update for the 3d or when they release the kernel source for 3d ics help?
sinnedone said:
What about when they update the EVO3D? Will either the ics update for the 3d or when they release the kernel source for 3d ics help?
Click to expand...
Click to collapse
Probably not since the 3d uses a different chipset and the insides look nothing like the evo
sinnedone said:
What about when they update the EVO3D? Will either the ics update for the 3d or when they release the kernel source for 3d ics help?
Click to expand...
Click to collapse
The Evo Design 4G update would help us more than the EVO 3D would since the specs are similar to ours
Sent from my PC36100 using Tapatalk 2 Beta-6
Papa Smurf151 said:
Probably not since the 3d uses a different chipset and the insides look nothing like the evo
Click to expand...
Click to collapse
I was going on the assumption that the only roms with newer versions of sense that have working 4g are ports from the Evo3d.
you guys are nerds and i envy you all...
There is so much awesome going on.. our best bet, would be to grab the EVO design 4g update. That would be as close as we can get.
then someone can port it here
Hopefully HTC will release a source code for the kernel & or RUU. Then we can go from there...
Sent from my PC36100 using xda premium
Thank you, i am learning alot.
Is there a page that discusses the evo 4g specifically and shows what parts are frankensteined and what are not. Ideally, something like
Radio
- wimax - unavailable
- cmda - Use ICS wrapper on Gingerbread kernel driver 2.2. wrapper created by developer abc. Gingerbread kernel driver - HTC Android 2.3 patch - version 12341
Graphics
- something - blob - developer xzy
- something else - blob - developer def
- something else - kernel driver - Standard Android 4.0 patch - version 5.6
Camera
- front - ICS blob - developer pdq
- back - unavailable
Microphone
- standard - ICS Kernel Driver - Standard Android 4.0 patch - version 3.3
etc
I would think that each phone has a "map" of what is available and I would think developers would share. Obviously the first thing I would look at on this map is what did Teamwin do? I can't imagine they created a BLOB, but instead did they use a wrapper on a Froyo wimaxx driver or a wrapper on a gingerbread sense patch or did they write it themselves.
Doing some research I've gotten this data...am I on the right track to build my map of the EVO 4g for ICS. Why isn't this public knowledge somewhere. I am trying and not being lazy...well, not super lazy...
I got this from the cm9 thread for evo, thanks people in there for posting details
mason v14sbc ics kernel (Nonfso nonsbc, hwa kernel)
back camera - system/lib/hw/1sd8k.so
Camcorder
libmediaplayerservice.so
libOmxCore.so
libOmxVdec.so
libOmxVidEnc.so
libstagefright.so
libstagefrighthw.so
@ittsmith, sounds like you are aiming to be the next kernel genius. With this type of info you will be able to develop on kernels for far more devices than just evo...
Anyhow, I am no developer by any means just getting into programming, but I wanted to lay out my train of thought and see if it stands up or has any insight.
Any manufacturer has to start with AOSP source, and then build for their specific device. So, if theoretically HTC was building an ICS kernel they would begin there, with the latest source from Google. Then they would add in the device tree, much like building a ROM from source only here we are talking core drivers and such for proprietary hardware, and finally build a custom kernel for that device.
Now of course these guys have full access to source and drivers and the like of which we may not have... Though htcdev does have kernel source on their site. So, like you said initially why not take the ICS kernel and make it compatible to EVO? That is exactly what HTC would do, and does for the other devices that are receiving updates...
I remember running gingerbread long before there was an update to the evo, and there were gingerbread kernels... So I am just thinking we don't have the tools and know how to get the job done but all the pieces may be there. I would say petition either toastcfh or even Adam Outler, as these two are pretty damn magical when it comes to Android devices and the linux kernel.
Guys, I’m sorry if this comes across as being a bit terse, but I’ve been very disappointed with my Epic Touch. While it packs a lot of great specs, coming from the HTC Evo nearly 9 months ago, I’m very disappointed with the overall stability of the roms available.
Please understand, this is in no way a complaint about the devs. I’ve been here long enough to fully understand and appreciate the amount of time and effort they put into these roms, and I’ve made a few donations along the way.
I’m hoping someone more knowledgeable might be able to explain some of the obsticles in developing for the E4GT. Most of the roms I’ve flashed have looked fantastic and offered great features, but I’m constantly seeing issues with kernels relating to battery life, LOS, GPS, bricking, etc. Are we not getting the kernel soruce from Samsung? The phone has been out for about a year now, and we still don’t have official CM9 builds. Heck, we were even the last (In the SII family) to get the official ICS updated. Again, I’m not complaining about the developers. It just feels like they may not have access to the resources they need in order to build more stable roms.
tl;dr Can anyone familiar with ROM development on the E4GT please explain why we see so many kernel related issues? I would greatly appreciate your input. Thanks!
The et4g is one of the only devices if not the only one that contains the recovery partition inside the kernel. That makes the kernel very different from other devices kernels and is one of the main reasons we aren't officially supported by CyanogenMod. We have the kernel source but for ICS its only been available for around a month, and came loaded with bugs that take time for the devs to locate and fix. GB had alot of bugs in the kernel source as well but 90% of the custom kernels for GB are relatively bug free, I say relatively cuz no software is ever 100% bug free it just the nature of the beast. Give it some more time and the ICS kernels will be just as stable as the GB kernels, the devs just need time to iron out the kinks Samsung was nice enough to pass along in the source
We are legion, for we are many.
Sent from the DarkSide of the GalaXy with a MEK device
Are device may not be the newest kid on the block but we just got ICS w/ source. For how long the source has been out the devs have been doing a great job and the word on the street is that we are going to be an official CM10 device which is better than just being a CM9 device if you ask me.
-EViL-KoNCEPTz- said:
The et4g is one of the only devices if not the only one that contains the recovery partition inside the kernel. That makes the kernel very different from other devices kernels and is one of the main reasons we aren't officially supported by CyanogenMod. We have the kernel source but for ICS its only been available for around a month, and came loaded with bugs that take time for the devs to locate and fix. GB had alot of bugs in the kernel source as well but 90% of the custom kernels for GB are relatively bug free, I say relatively cuz no software is ever 100% bug free it just the nature of the beast. Give it some more time and the ICS kernels will be just as stable as the GB kernels, the devs just need time to iron out the kinks Samsung was nice enough to pass along in the source
We are legion, for we are many.
Sent from the DarkSide of the GalaXy with a MEK device
Click to expand...
Click to collapse
That's exactly the type of info I was looking for, EViL! Thanks! Any idea why they designed the phone that way?
thaprinze said:
That's exactly the type of info I was looking for, EViL! Thanks! Any idea why they designed the phone that way?
Click to expand...
Click to collapse
Not a clue, I'm not sure if it has to do with hardware configuration forcing the software to be modified to function, if it was poor software engineering, or if they just wanted to try something new. I know it makes working with the kernel extremely difficult compared to other devices whose recovery partition is separate. Another major problem is the bugs included with source, they take time for our devs to find and fix in order for the builds to become more stable, I feel the major issue with that is Samsung made too many devices in the same family, gs2, all with different hardware configurations which require modifications to the kernel, making it hard for their developers to maintain the devics since they have to build a separate kernel for each device in the same family instead of one kernel that works on all gs2 variants with the exception of having to make minor changes for cdma, wimax, Lte, and GSM which would just require some driver changes and a little bit of minor code work. Instead they have to rewrite the entire kernel for CPU/gpu, network, display, ram, emmc, SoC etc for each variant of the gs2.
We are legion, for we are many.
Sent from the DarkSide of the GalaXy with a MEK device
Howdy,
I'm new here, so go easy on me.
So I just upgraded my stock Galaxy Nexus to CyanogenMod 10.1 and I noticed that the kernel was still at version 3.0.x. At the same time, I see that there are newer Android kernels, and my understanding is that Texas Instruments had some folks working on that 3.0 kernel that made it work well on the OMAP chip in the GNex, but TI has given up on phones, leaving the Galaxy Nexus' OMAP architecture somewhat abandoned when it comes to phones. Everyone keeps saying that TI abandoned OMAP and that the Galaxy Nexus is stuck at 3.0 forever.
In particular, support for SSD 'TRIM' on dm-crypt volumes was added in kernel 3.1. That's a big deal if you encrypt your phone and it starts crawling sooner than it should because your slack can't be trimmed.
So, being not a stranger to Google and git trees, I went searching around. I have a few questions:
1. It appears that the OMAP magic lives on and gets updates in the form of Linaro's offerings. Could their kernel be brought into CyanogenMod (or any other modded ROM)?
2. Are the Linaro Galaxy Nexus builds actually usable on its own? Can I just follow their instructions and have a working usable system in a few hours?
3. Assuming that the Linaro builds are mostly development or barebones, and that their kernel works on the Galaxy Nexus, are there any fully-polished ROMs out there that run Linaro-based kernels?
4. Assuming 'no' to 3 and 4, can I pop ONLY a new kernel into an existing CM install, or will that Break Things Horribly?
I've learned from your question that The makers of our chipset has stopped supporting it ,and for me ,this news would make me upgrade to another phone
Thanks
tarekh020 said:
...The makers of our chipset has stopped supporting it ,and for me ,this news would make me upgrade to another phone
Click to expand...
Click to collapse
But why should that matter? If the source for the 3.0.31 kernel with the 'tuna'-specific stuff is out in the open, and Linaro is keeping the ball running witht he overall OMAP subarchitecture, then shouldn't it be relatively simple to keep pushing the customizations from 3.0.31-tuna up into newer kernel versions?
There are also some binary bits and pieces available from Google for this phone, but I think it would be worthwhile to see 'how far they go' as far as kernel versions.
I mean, normally I'd understand leaving the Galaxy Nexus at 3.0.x, but there's a BIG BUG with regards to the dm-crypt layer not passing TRIM commands to the flash that turns the phone into a slug after a while, and the bug is fixed in kernel 3.1 and up.
mangeek said:
But why should that matter? If the source for the 3.0.31 kernel with the 'tuna'-specific stuff is out in the open, and Linaro is keeping the ball running witht he overall OMAP subarchitecture, then shouldn't it be relatively simple to keep pushing the customizations from 3.0.31-tuna up into newer kernel versions?
There are also some binary bits and pieces available from Google for this phone, but I think it would be worthwhile to see 'how far they go' as far as kernel versions.
I mean, normally I'd understand leaving the Galaxy Nexus at 3.0.x, but there's a BIG BUG with regards to the dm-crypt layer not passing TRIM commands to the flash that turns the phone into a slug after a while, and the bug is fixed in kernel 3.1 and up.
Click to expand...
Click to collapse
Most kernels out right now like ASKP, Franco etc...are based on 3.0.8X. The Gnex isn't stuck on 3.0 either. One of the kernel devs has gotten 3.4 working but a kernel was never released, and there are also apps and scripts that force TRIM so I don't think it's much of an issue but I don't know much about kernels and stuff anyways...
Sent from my Galaxy Nexus using Tapatalk 4 Beta
bmg1001 said:
Most kernels out right now... are based on 3.0.8X. The Gnex isn't stuck on 3.0 either. One of the kernel devs has gotten 3.4 working but a kernel was never released, and there are also apps and scripts that force TRIM so I don't think it's much of an issue but I don't know much about kernels and stuff anyways...
Click to expand...
Click to collapse
It's simple to overlay 3.0.31+ on top of 3.0.x to get 3.0.85, etc., but those only provide minor bug fixes. The part that needs to get into the Galaxy Nexus is from 3.1 or newer, where dm-crypt has a 'discards' option that allows encrypted volumes to TRIM.
As it stands now, encrypted volumes can't TRIM, not even with third-party utilities. TRIM exists to free-up large contiguous blocks of zeroed writeable space, and the dm-crypt in 3.0.x writes encrypted gobbledygook to the entire volume, even empty space. That means that write performance on an encrypted Galaxy Nexus is -always- bad and can't be trimmed.
As for the 3.4... There are Google experimental 3.4 and 3.8 kernels, but they're for newer devices and don't seem to include the various bits-and-pieces that the TI OMAP team added to get the Galaxy Nexus running.
Someone needs to either backport newer versions of dm-crypt to 3.0.x and enable discards by default, or they need to move the Galaxy Nexus-specific code up to newer (3.1+, not 3.0.31+) revisions of the kernel. I prefer the latter, as it would yield many other benefits as well.
Hi everyone. I have been googling around for a way to extend my G Pad's battery life. On the way, I stumbled upon the Franco Kernel who many people consider the magical kernel to extend the device's battery life (some claiming even if you don't undervolt the CPU).
However, it appears that it is not working on the G Pad, atleast when I tried the franco installer on the playstore. I am using slimkat (which I believe is an AOSP... I have read somewhere that it works on AOSP devices, but though they didn't say which device, im leaning toward nexus only devices but im not sure).
Anyone tried and successfully installed this custom kernel? and on which ROM? Thanks
I thought Franco Kernel was exclusive to Nexus devices only? Where are you seeing that he has one for the G-Pad?
stevessvt said:
I thought Franco Kernel was exclusive to Nexus devices only? Where are you seeing that he has one for the G-Pad?
Click to expand...
Click to collapse
Not really. Actually on his installer application on google play the list of compatible devices are only the ones in the nexus line. But I do see in some threads for speeding up the android, franco often pops out. And since franco is compatible with AOSP custom ROMs, just figured, perhaps there might be a way to install this custom kernel on non-nexus devices with AOSP-based Custom ROM (i.e. Slimkat, or Pac-man ROM). But at the moment, im too scared to try it out on my own device because I just recently had it serviced for screwing up my partition table
Though I don't think custom kernels touch the existing partition table.
You need someone on here to port francos kernel over for our device.
But you can still use his app to alter certain settings, if his app is similar to fauxs and Trinitys.
Sent from my LG-V500 using XDA Premium HD app
whoamigriffiths said:
You need someone on here to port francos kernel over for our device.
But you can still use his app to alter certain settings, if his app is similar to fauxs and Trinitys.
Sent from my LG-V500 using XDA Premium HD app
Click to expand...
Click to collapse
I have heard of Faux's (his installer app in the playstore indicates that it unofficially supports other devices or something along those lines) but I had a keen interest in Franco's kernel because many has attested to its usefulness and that it saves quite a bit of battery life which the tablet could use.
Since there was a GPE version of the tablet, I was hoping they might port it aswell.
I guess kernels aren't like servers in the sense that, say for example in Linux, as it is based on x86, regardless of the CPU as long as its using the same x86 architecture, the kernel should be compatible. Following the same logic with Android which is essentially Linux which uses predominantly the ARM architecture, I was hoping that theoretically, the kernel will be compatible as they are using the same architecture... Although I can be wrong.
I would test it myself, but im afraid of bricking my device as I just hard-bricked it and lost quite a bit of my 9 lives... Dunno how many I have remaining
Hehe, it's not worth trying, as it wouldn't work. I'm not sure what would happen tbh. I don't think it would brick, I think it would just bootloop, but honestly it's not worth trying.
Have you looked at greenify?
It's great at what it does, but it is only saving battery during sleep. Mine is great in sleep, but it's not a vast saving of resources. Once you boot the tablet up you can literally watch the battery percentage ticking down
Sent from my LG-V500 using XDA Premium HD app
whoamigriffiths said:
Hehe, it's not worth trying, as it wouldn't work. I'm not sure what would happen tbh. I don't think it would brick, I think it would just bootloop, but honestly it's not worth trying.
Have you looked at greenify?
It's great at what it does, but it is only saving battery during sleep. Mine is great in sleep, but it's not a vast saving of resources. Once you boot the tablet up you can literally watch the battery percentage ticking down
Sent from my LG-V500 using XDA Premium HD app
Click to expand...
Click to collapse
hmm boot loop I can live with. I might just give it a try when I have the time and summoned enough courage. Yep I do have greenify and didn't do much in improving the battery life. But atleast I think it did something.
jarod004 said:
hmm boot loop I can live with. I might just give it a try when I have the time and summoned enough courage. Yep I do have greenify and didn't do much in improving the battery life. But atleast I think it did something.
Click to expand...
Click to collapse
in contrast to Linux distribution, our kernels are device specific as there are different drivers for different devices by different makers. On top of that, the ramdisk itself which is associated with the kernel to make a complete boot image, can have different mount points depending on the device.
You would think that all of this would be standard but of course with different makers of different phones, tablets, excetera, this just isn't the case.
Neither Franco's kernel, nor Faux kernel will work with the G pad. While I have done some work to port over different items from different kernels, I own the Google Play edition and not the stock LG tablet. Maybe one of the other kernel developers for the stock LG tablet would be open to porting over some of their work.
if you would like, you may also look in my signature for a guide on how to roll your own kernel for the G pad, and a couple of the other kernel developers have used it with success for your device. It is a complete guide start to finish, copy and paste style for anyone running Debian. check it out!
sleekmason said:
in contrast to Linux distribution, our kernels are device specific as there are different drivers for different devices by different makers. On top of that, the ramdisk itself which is associated with the kernel to make a complete boot image, can have different mount points depending on the device.
You would think that all of this would be standard but of course with different makers of different phones, tablets, excetera, this just isn't the case.
Neither Franco's kernel, nor Faux kernel will work with the G pad. While I have done some work to port over different items from different kernels, I own the Google Play edition and not the stock LG tablet. Maybe one of the other kernel developers for the stock LG tablet would be open to porting over some of their work.
if you would like, you may also look in my signature for a guide on how to roll your own kernel for the G pad, and a couple of the other kernel developers have used it with success for your device. It is a complete guide start to finish, copy and paste style for anyone running Debian. check it out!
Click to expand...
Click to collapse
Interesting stuff. Only little problem is I don't have a debian based machine currently (only using redhat based Linux ATM). Ill install Ubuntu on my "virtual lab" and see if I can try it when I have the time. Thanks a lot for your input.
jarod004 said:
Interesting stuff. Only little problem is I don't have a debian based machine currently (only using redhat based Linux ATM). Ill install Ubuntu on my "virtual lab" and see if I can try it when I have the time. Thanks a lot for your input.
Click to expand...
Click to collapse
No problem. I use AntiX, a Debian derivative and highly recommended it. You will find it far lighter, and with some really neat tools. Ubuntu is not all its cracked up to be...
sleekmason said:
No problem. I use AntiX, a Debian derivative and highly recommended it. You will find it far lighter, and with some really neat tools. Ubuntu is not all its cracked up to be...
Click to expand...
Click to collapse
its more like, its the debian distro I have lying around so I don't need to download anything else. fits the bill. Although I will take note of that AntiX
jarod004 said:
its more like, its the debian distro I have lying around so I don't need to download anything else. fits the bill. Although I will take note of that AntiX
Click to expand...
Click to collapse
If you use Ubuntu, you will have to adjust some of the dependencies, as they use their own packages. Unbuntu is a Debian derivative but is not compatible with the apt database. Let me know how it goes if you decide to do it!
sleekmason said:
If you use Ubuntu, you will have to adjust some of the dependencies, as they use their own packages. Unbuntu is a Debian derivative but is not compatible with the apt database. Let me know how it goes if you decide to do it!
Click to expand...
Click to collapse
I see. guess theres no harm in creating a new vm for this. Lemme google around for the installer and try it out when I get the time. Though I am quite loaded for this week and probably the next too