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.
Related
I just wanted to start a discussion about kernels for our phone. Obviously the stock kernel for our phone is the .35 kernel. Before I traded in my EVO I was running the .38 kernel. I know that Linux was releasing new kernels every so often and the developers such as Toast would port them over and make them compatible with the EVO. I thought I read somewhere that Linux was not going to develop new kernels anymore, possibly someone could confirm that. So if thats the case what happens? Will android use the same kernels forever? What would be the possobility of our phones being able to use some of the newer kernel versions? As I write this Bybby323 is getting really close to having a fully functional AOSP kernel for our phones and I think development is really going to pick up. Maybe this will open the door for some different kernel versions for our phones.
All I know is that the Linux kernel isn't going to stop any time soon.
http://www.kernel.org/
Too many operating systems/devices (such as Android) use, or better yet, depend on the Linux kernel. Remember, it's an open source thing - not just one guy behind a desk. Many multi-million dollar companies use Linux for everything, from storing data to government websites and so on, they would be willing to invest if Linux needed money (this probably wouldn't happen, but you get me.)
In regards to ETAs, I have no clue. But just know that support for neither Android, or the Linux kernel isnt stopping anytime soon.
stangdriverdoug said:
I just wanted to start a discussion about kernels for our phone. Obviously the stock kernel for our phone is the .35 kernel. Before I traded in my EVO I was running the .38 kernel. I know that Linux was releasing new kernels every so often and the developers such as Toast would port them over and make them compatible with the EVO. I thought I read somewhere that Linux was not going to develop new kernels anymore, possibly someone could confirm that. So if thats the case what happens? Will android use the same kernels forever? What would be the possobility of our phones being able to use some of the newer kernel versions? As I write this Bybby323 is getting really close to having a fully functional AOSP kernel for our phones and I think development is really going to pick up. Maybe this will open the door for some different kernel versions for our phones.
Click to expand...
Click to collapse
the reason is Android 2.3 shipped with 2.6.35, similarly Android 2.1, 2.2, and 4.0 ship with 2.6.29,2.6.32,3.0 respectively.
I dont see the point in doing all of that work when ICS should ship on the GS2 soon with Linux 3.0
And no, Linux is far from dead
Sent from my SPH-D710 using xda premium
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
Just wondering why it is that the Galaxy Nexus is still using Linux Kernel 3.0.y, and if there's a way we could potentially update to a newer kernel version. 3.0.y is projected to be EOL'd in October of 2013, which is barely just over 1 month away. The other current longterm kernels are 3.2.y (EOL 2016), 3.4.y (EOL October 2014), and 3.10.y (EOL September 2015). I think the current Nexus devices are on 3.4.y, but I'm not totally sure on that.
currently many roms is backporting stuff from 3.4 and 3.1 the only reason why Galaxy Nexus hasn't advance from 3.0.x officially is because our OMAP drivers arent updated and the company is disband AFAIK
-Jesco- said:
currently many roms is backporting stuff from 3.4 and 3.1 the only reason why Galaxy Nexus hasn't advance from 3.0.x officially is because our OMAP drivers arent updated and the company is disband AFAIK
Click to expand...
Click to collapse
TI is still alive and kicking, they certainly aren't going anywhere. I don't see what could have changed so much in-between kernels to make the OMAP libs completely broken; at the very least there should be a way to revert anything that conflicts with the OMAP libs, no?
I don't think people are really backporting stuff from newer kernels, the incremental 3.0 releases should take care of that by themselves. I think there might be a few commits people have backported specific to ARM or something but other than that, I dunno.
If I remember correctly, Ubuntu has an OMAP4 kernel on version 3.4, how much that relates to hardware besides probably just PandaBoard I don't know, but it's still probably worth a look.
http://forum.xda-developers.com/showthread.php?t=2071021
I'm not the droid you are looking for
---------- Post added at 10:18 PM ---------- Previous post was at 09:56 PM ----------
http://rootzwiki.com/topic/32023-wi...-36-rc1-developers-needed-a-community-kernel/
I'm more paranoid than your android
ScardracS said:
http://forum.xda-developers.com/showthread.php?t=2071021
I'm not the droid you are looking for
---------- Post added at 10:18 PM ---------- Previous post was at 09:56 PM ----------
http://rootzwiki.com/topic/32023-wi...-36-rc1-developers-needed-a-community-kernel/
I'm more paranoid than your android
Click to expand...
Click to collapse
I'm just a noob but i think that until GNex is supported by Google (hopefully til Android 5), i don't see any need to upgrade kernel version. No big advantages for our device. Better to have a stable and working kernel.
But just for knowledge:
I read different opinion about 3.4 upgrade. is it possible or not? those 2 threads say that it is (not easy of course)...
Actually we can find OMAP4 kernels, so problems are not related to SoC, right?
Any kernel developer could answer to these questions?
Thanks you all for your work.
protowave said:
I'm just a noob but i think that until GNex is supported by Google (hopefully til Android 5), i don't see any need to upgrade kernel version. No big advantages for our device. Better to have a stable and working kernel.
But just for knowledge:
I read different opinion about 3.4 upgrade. is it possible or not? those 2 threads say that it is (not easy of course)...
Actually we can find OMAP4 kernels, so problems are not related to SoC, right?
Any kernel developer could answer to these questions?
Thanks you all for your work.
Click to expand...
Click to collapse
Our device couldn't work with kernel 3.4 because our SoC isn't optimized for this kernel.. I think it's possible to make it optimized for the gnex but it need a lot of work and not all features will work correctly
I'm more paranoid than your android
While I do agree that there would be many roadblocks for getting a 3.4-based kernel on our device, I don't think it's something that can't be overcome. There are plenty of talented developers working on kernels for our device, and it's still alive and kicking after nearly 2 years. While there are a few projects that tried to get the ball rolling on it, I don't believe they had a 3.4 kernel for the OMAP4 platform available that should just need the things necessary to move it from a PandaBoard to a Galaxy Nexus. If I remember correctly, the PandaBoard was what Android 4.0 was developed on, and the Galaxy Nexus the first device it was released for, both with extremely similar hardware. Those projects that didn't take off started from nothing, and now there is something to start with: as I like to say, 50% of something is a lot better than 100% of nothing. :good:
MWisBest said:
Just wondering why it is that the Galaxy Nexus is still using Linux Kernel 3.0.y, and if there's a way we could potentially update to a newer kernel version. 3.0.y is projected to be EOL'd in October of 2013, which is barely just over 1 month away. The other current longterm kernels are 3.2.y (EOL 2016), 3.4.y (EOL October 2014), and 3.10.y (EOL September 2015). I think the current Nexus devices are on 3.4.y, but I'm not totally sure on that.
Click to expand...
Click to collapse
Nexus One : 2.6.x
Nexus S : 3.0.x
Galaxy Nexus : 3.0.x
Nexus 4 : 3.4.x
However , due it's weird board ( TI OMAP ) That no other phone uses, getting 3.4 will only be do-able by TI itself or really good Linux kernel developers.
TheRinseM said:
Nexus One : 2.6.x
Nexus S : 3.0.x
Galaxy Nexus : 3.0.x
Nexus 4 : 3.4.x
However , due it's weird board ( TI OMAP ) That no other phone uses, getting 3.4 will only be do-able by TI itself or really good Linux kernel developers.
Click to expand...
Click to collapse
I'm fairly certain Ubuntu has a 3.10.y kernel available for at least Pandaboard, not sure about other OMAP4 platforms.
My dad's devices are a Motorola DROID RAZR and a Samsung Galaxy Tab 2 10.1, both of which are OMAP4 devices as well, so the Galaxy Nexus is certainly not the only phone with OMAP4, however I don't see any OMAP4 devices with a 3.4.y or higher kernel really. I'm maybe interested in picking up a Pandaboard for cheap and looking into this kernel stuff more.
This is a booting CAF 3.10 kernel for none other than our shiny OnePlus One. Personally, I'm satisfied with my phone as it is with a 3.4 kernel (and 3.10 is a lot of work without proper firmware), so I've given up on developing this 3.10 kernel. This thread is just a free-for-all for anyone who wants to have a crack at developing 3.10.
I threw this kernel together pretty sloppily 2 months ago, so I apologize for the lack of full git history from CAF and some messy code from me. The kernel is based off of the LA.BF.2.1_rb1.xx branch from CAF. The kernel should boot as-is on the official CM nightlies, and it is confirmed to boot on my CM12.1 builds. All it requires is updated WCNSS configuration binaries to boot (flashable zip available in the downloads tab of the thread). The kernel currently only supports JDI command-mode panels, and I compiled the kernel with Google's GCC 4.8 toolchain.
Source code: https://github.com/sultanxda/android_kernel_oneplus_bacon-3.10
What works:
It boots (woo)
Display
Touchscreen
Modem (no mobile data though)
WiFi
Charger (not from wall outlets though)
Battery percentage/health reporting
Volume keys
Sensors
USB
Assume everything else doesn't work. Here's a fun screenie: http://imgur.com/H1UERfr
Good luck with haxing 3.10!
XDA:DevDB Information
CAF Linux 3.10.40 kernel for Bacon, Kernel for the ONEPLUS ONE
Contributors
Sultanxda
Kernel Special Features: It boots
Version Information
Status: Testing
Created 2015-07-05
Last Updated 2015-07-06
@Sultanxda Awesome work bro now if only the Cyanogen.org devs supported devices like Sony
arm: qcom: Add SONY Shinano platform, msm8974pro family - https://github.com/sonyxperiadev/kernel/commit/193c3345565d0c3a202f8feac62a21842b06e347
http://developer.sonymobile.com/kno...sh-a-linux-kernel-for-aosp-supported-devices/
http://developer.sonymobile.com/kno...evices/how-to-build-and-flash-a-linux-kernel/
http://developer.sonymobile.com/201...ny-presentation-at-embedded-linux-conference/
http://developer.sonymobile.com/201...-xperia-devices-in-sonys-open-device-program/
Awsome work mate. Where can i find the original CAF branch? Somewhere at codeaurora cgit?
Sent from my A0001 using XDA Free mobile app
DerRomtester said:
Awsome work mate. Where can i find the original CAF branch? Somewhere at codeaurora cgit?
Sent from my A0001 using XDA Free mobile app
Click to expand...
Click to collapse
Yep. https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.10/tree/?h=LA.BF.2.1_rb1.39
Sultanxda said:
Yep. https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.10/tree/?h=LA.BF.2.1_rb1.39
Click to expand...
Click to collapse
Thank you. I am gonna create a full git history with that + your commits. If anyone wants access to it to push some code feel free to ask.
Gesendet von meinem A0001 mit Tapatalk
any inherent benefits of having linux 3.10 over 3.4?
_ASSASSIN_ said:
any inherent benefits of having linux 3.10 over 3.4?
Click to expand...
Click to collapse
http://kernelnewbies.org/Linux_3.10
https://github.com/sonyxperiadev/ke...UX_ANDROID_LA.BF64.1.2.1_RB1.05.00.02.019.067
_ASSASSIN_ said:
any inherent benefits of having linux 3.10 over 3.4?
Click to expand...
Click to collapse
Tons!
One I would love to mess with is Heterogeneous Multi-Processing. Also some of the other upstream scheduler commits. For one, they are what make the N6 a true quad core in that it doesn't use any hotplugging, just CPU C states while maintaining pretty decent battery life. It changes how threading works and how workloads are transferred to other cores. At least this is the main thing I would love to see and mess with. Almost makes me want to get an N6. I love my OPO though.
RenderBroken said:
Tons!
One I would love to mess with is Heterogeneous Multi-Processing. Also some of the other upstream scheduler commits. For one, they are what make the N6 a true quad core in that it doesn't use any hotplugging, just CPU C states while maintaining pretty decent battery life. It changes how threading works and how workloads are transferred to other cores. At least this is the main thing I would love to see and mess with. Almost makes me want to get an N6. I love my OPO though.
Click to expand...
Click to collapse
possibly collab with @DerRomtester?
_ASSASSIN_ said:
possibly collab with @DerRomtester?
Click to expand...
Click to collapse
man, that would be cool but it would be a massive undertaking then you would need a road map for other rom Devs to use to even use the work you have done let alone to even be accepted officially from major Roms out there like CM. This is something I have thought about alot but the work needed to put in doesn't match anything near what I would get out of it. This doesn't mean money necessarily but time, time away from family, etc.
This is still something I will take a look at. I wouldn't mind any input from @DerRomtester at all.
Added to OnePlus One index thread:
[INDEX] OnePlus One Resources Compilation Roll-Up
First I was excited then I read that this is no longer in development and I'm sad now
P.S. I'd love to see a small group of kernel devs gather around and work on this, surely at first it would be buggy, having even less performance than any kernel for our 1+1 but in the end we'll have a sweet little kernel
evronetwork said:
First I was excited then I read that this is no longer in development and I'm sad now
P.S. I'd love to see a small group of kernel devs gather around and work on this, surely at first it would be buggy, having even less performance than any kernel for our 1+1 but in the end we'll have a sweet little kernel
Click to expand...
Click to collapse
Pretty sure that most devs would use this as a base if it had the proper driver support as it would provide quite the bump for security
evronetwork said:
First I was excited then I read that this is no longer in development and I'm sad now
P.S. I'd love to see a small group of kernel devs gather around and work on this, surely at first it would be buggy, having even less performance than any kernel for our 1+1 but in the end we'll have a sweet little kernel
Click to expand...
Click to collapse
Facts. We need way more collabs man. Unity gets a lot done. I personally know nothing about developing, but I'm a great tester. I'm willing to brick my phone.. Test, bootloop and brick it again lol. Everyone can play a part in the grand scheme of things.
@Sultanxda can you share your kernel with me?
I compiled it but i don't get it booting. You have made some ramdisk changes ? You added an dtb file ?
DerRomtester said:
@Sultanxda can you share your kernel with me?
I compiled it but i don't get it booting. You have made some ramdisk changes ? You added an dtb file ?
Click to expand...
Click to collapse
No ramdisk changes, no missing dtbs. Just ran a mrproper and compiled it exactly as it is on my GitHub, and it boots. Compiled with GCC 4.8 from Google using almost the exact same script I use to compile my 3.4 kernel, with the only change being that the dtb path for the dtbtool is arch/arm/boot/dts/, not arch/arm/boot/ (though you probably already figured that out).
Sultanxda said:
No ramdisk changes, no missing dtbs. Just ran a mrproper and compiled it exactly as it is on my GitHub, and it boots. Compiled with GCC 4.8 from Google using almost the exact same script I use to compile my 3.4 kernel, with the only change being that the dtb path for the dtbtool is arch/arm/boot/dts/, not arch/arm/boot/ (though you probably already figured that out).
Click to expand...
Click to collapse
Thank you mate. I think i know the problem
_ASSASSIN_ said:
Pretty sure that most devs would use this as a base if it had the proper driver support as it would provide quite the bump for security
Click to expand...
Click to collapse
If companies released the drivers we would have 3.10.x, 3.18.x and even 4.2.x kernels(someone would try to do it even if it turned out a failure)
Released drivers also would have better optimised roms and would make a 5 year old device to live forever (new android e.g. android 7? no problem)
OmegaBlaze said:
Facts. We need way more collabs man. Unity gets a lot done. I personally know nothing about developing, but I'm a great tester. I'm willing to brick my phone.. Test, bootloop and brick it again lol. Everyone can play a part in the grand scheme of things.
Click to expand...
Click to collapse
I'm the worst kind of programmer, I mean I do own a degree but the programming language was my weakest link, so I can't help and kernel is one of the hardest parts it needs big ..knowledge to do it :silly:
Now lets not go off topic and wish for someone to work on 3.10.x I mean even if it's buggy and a bit unstable it will bring some new stuff and when it gets stable well then the fun will start
RenderBroken said:
Tons!
One I would love to mess with is Heterogeneous Multi-Processing. Also some of the other upstream scheduler commits. For one, they are what make the N6 a true quad core in that it doesn't use any hotplugging, just CPU C states while maintaining pretty decent battery life. It changes how threading works and how workloads are transferred to other cores. At least this is the main thing I would love to see and mess with. Almost makes me want to get an N6. I love my OPO though.
Click to expand...
Click to collapse
I wasn't exactly interested in 3.10 until i read yours comment. If this kernel can also make opo work like N6 i.e. running always on quad core mode and still maintain good battery lyf, man i would pray that either opo or cm releases 3.10 kernel.
Sent from OnePlus One
abhibnl said:
I wasn't exactly interested in 3.10 until i read yours comment. If this kernel can also make opo work like N6 i.e. running always on quad core mode and still maintain good battery lyf, man i would pray that either opo or cm releases 3.10 kernel.
Sent from OnePlus One
Click to expand...
Click to collapse
This will never happen. From a business perspective, it costs too much for little benefit, and only introduces the potential for more bugs.
However, here is a hint: Bacon's TrustZone firmware does not check metadata when loading firmware images, so you can technically load firmware from any device (ex: you can use Venus firmware from a totally different device).
If you know what you're doing and you have 3 months of your life to burn on this, then it should be possible to get everything working with the LA.BF.2.1_rb1.xx kernel branch.
Sent from my A0001 using XDA Free mobile app