Not really a technical question but I was wondering what we "noobs" and devs that aren't working on the 3.0.8 kernel can do to speed up or help in the development (we're all in this together right!?) Donations may help but are there any builds we can test with alogcats or just repetitive labor that manpower can aid in? If so feel free to put it here. One tip, guides to non intuitive stuff would help because like I said there are a quite a few noobs lurking (me included). Hopefully this is in the right thread I was contemplating putting it on the general but I wasn't sure.
I'm sure if they needed our help they would ask as they know many of us want to help. Best thing to do is just be patient and not bug them.
I guess you can help by flashing the build posted in the cm9 thread and reporting any bugs that haven't already been reported.
Sent from my SGH-T959V using xda app-developers app
This is a terrible way to get on the good book. Just fork bhundvens github repo. Make changes that work or look good, then push a pull request, then you'll be good.
Also, its called Aries not aires
Sent from my SGH-T959V using xda premium
Sit tight, let Bryan do his thing, and enjoy it when it gets here.
Sent from my SGH-T959V using xda premium
gregcapps said:
Sit tight, let Bryan do his thing, and enjoy it when it gets here.
Sent from my SGH-T959V using xda premium
Click to expand...
Click to collapse
A passive approach works too
Educate me what is Aries?
Bitcloud30 said:
Educate me what is Aries?
Click to expand...
Click to collapse
It is the proper Kernel for ICS which is more stable and offers better battery life. More specifically it is the machine type of the phone. Currently all builds are herring.
it's not a "Proper Kernel" per se.
Just the team hacksung people created a generic kernel to work with for all the Galaxy S 1 devices. Well, there are alot more devs over there and that's what's officially supported by CM. So now we are trying to merge into the official Galaxy S CM kernel.
Correct me if I'm wrong but Aries is the processor that our phone runs on it is hardware not software meaning it is a physical component that can't be changed by flashing any files
Sent from my SGH-T959V using xda app-developers app
anoymonos said:
Correct me if I'm wrong but Aries is the processor that our phone runs on it is hardware not software meaning it is a physical component that can't be changed by flashing any files
Sent from my SGH-T959V using xda app-developers app
Click to expand...
Click to collapse
nope, the processor is hummingbird. too many codenames. :silly:
also known as Exynos which is what anoymonos was getting confused with.
One of the big reasons to get on a kernel based on the Aries source is that it makes it a lot easier to move forward with AOSP releases. Right now, "our" kernel is a bit of AOSP, a bit of Samsung stock, a bit of TeamAcid work, a bit of TeamHacksung, a bit of..., so every time something comes up, it is a "custom job" to add it. I won't say that getting closer to mainline code will make JB a slam dunk, but without it, it would likely be lipstick on the pig.
Aries and Herring are Board Names (think motherboard).
Exynos and s5pc110 are Processor Names (both are SoC with the RAM in a PoP configuration).
Herring is the board name used for the nexus one and nexus s in Google's AOSP Samsung source.
The main board definition file for herring is: mach-herring.c
When Samsung worked with t-mobile, at&t, verizon, etc... to make Galaxy S phones, they basically reused the AOSP Samsung kernel for multiple devices. For instance, if you look at our UVKJ6 kernel drop, you will notice ifdefs in there for VIBRANTPLUS (Galaxy S 4G), KEPLER (Captivate), DEMPSEY (Infuse 4G), and a few others.
Aries is the main board definition file for the stock kernel is: mach-aries.c
Even though the board name is still herring. Ger.
They basically copied mach-herring.c to mach-aries.c and made their changes in mach-aries.c.
The Aries kernel, like jeffsf mentioned, is a kernel made by teamhacksung to be a combined kernel for galaxy s devices, and they use mach-aries.c and the aries board name.
If you get the stock kernel drop for any of these other devices in the same kernel drop from their respective drop, there will be subtle differences between each kernel drop. (crazy huh?)
And every file that samsung touches gains tens of lines of ifdefs, sometimes conflicting, as well as code that was '#if 0'ed out because they didn't code it right and left some other variable definitions without also '#if 0'ing them as well leaving nasty build warnings.
If you don't know anything about embedded devices, linux kernel development, or kernel debugging, just lay back and chill. We're getting close, just some nasty rough edges to clean up.
If you do have one or more of those skills, join us in #teamacid.
As it stands right now, most of the problems are GPIO issues. I am having a rough go at figuring out our GPIO configuration for this phone. Everytime I think I figure out something I find that I am wrong.
Also, to make things harder and more confusing, unlike the stock kernels, the aries kernel puts the GPIO pin configuration right in mach-aries.c, where as stock kernels put them in include/mach/gpio-settings-<devicename>.h... :sigh:
Hopefully m4xm4n and jeffsf can give me a hand with this stuff.
It would be nice if some teamhacksung members could give a hand and some guidance.
bhundven said:
Aries and Herring are Board Names (think motherboard).
Exynos and s5pc110 are Processor Names (both are SoC with the RAM in a PoP configuration).
Herring is the board name used for the nexus one and nexus s in Google's AOSP Samsung source.
The main board definition file for herring is: mach-herring.c
When Samsung worked with t-mobile, at&t, verizon, etc... to make Galaxy S phones, they basically reused the AOSP Samsung kernel for multiple devices. For instance, if you look at our UVKJ6 kernel drop, you will notice ifdefs in there for VIBRANTPLUS (Galaxy S 4G), KEPLER (Captivate), DEMPSEY (Infuse 4G), and a few others.
Aries is the main board definition file for the stock kernel is: mach-aries.c
Even though the board name is still herring. Ger.
They basically copied mach-herring.c to mach-aries.c and made their changes in mach-aries.c.
The Aries kernel, like jeffsf mentioned, is a kernel made by teamhacksung to be a combined kernel for galaxy s devices, and they use mach-aries.c and the aries board name.
If you get the stock kernel drop for any of these other devices in the same kernel drop from their respective drop, there will be subtle differences between each kernel drop. (crazy huh?)
And every file that samsung touches gains tens of lines of ifdefs, sometimes conflicting, as well as code that was '#if 0'ed out because they didn't code it right and left some other variable definitions without also '#if 0'ing them as well leaving nasty build warnings.
If you don't know anything about embedded devices, linux kernel development, or kernel debugging, just lay back and chill. We're getting close, just some nasty rough edges to clean up.
If you do have one or more of those skills, join us in #teamacid.
As it stands right now, most of the problems are GPIO issues. I am having a rough go at figuring out our GPIO configuration for this phone. Everytime I think I figure out something I find that I am wrong.
Also, to make things harder and more confusing, unlike the stock kernels, the aries kernel puts the GPIO pin configuration right in mach-aries.c, where as stock kernels put them in include/mach/gpio-settings-<devicename>.h... :sigh:
Hopefully m4xm4n and jeffsf can give me a hand with this stuff.
It would be nice if some teamhacksung members could give a hand and some guidance.
Click to expand...
Click to collapse
Hopefully you get the help you need. Hey here's a dumb question, could you not call the manufacturers of the phone and ask them what the gpio config is?
IIRC the gpio functions are part of a proprietary code source. So no Samsung will not tell you.
eollie said:
IIRC the gpio functions are part of a proprietary code source. So no Samsung will not tell you.
Click to expand...
Click to collapse
The GPIO pins are signal pins on the SoC that allow you to connect external devices to the main cpu.
It is actually specific to the board because each phone have different connected devices (such as lcd panel, wifi, touch screen, etc...).
The GPIO pins and interrupt signals are all documented in the S5PC110 User Manual, but the pin layout in that manual is specific to the reference board it is describing. Each phone/device has its own GPIO layout and it is specific to the schematic.
Sure wish we had a vibrantplus schematic.
airfluip1 said:
it's not a "Proper Kernel" per se.
Just the team hacksung people created a generic kernel to work with for all the Galaxy S 1 devices. Well, there are alot more devs over there and that's what's officially supported by CM. So now we are trying to merge into the official Galaxy S CM kernel.
Click to expand...
Click to collapse
OK...maybe not a "proper" kernel technically , but certainly a whole lot closer to what to we need to have a better experience with the newer versions of android os.
Sent from my SGH-T959V using xda premium
you aren't wrong. I just explained it a bit.
@othern00bs
Here is a simple way to put it for the others who are confused
CyanogenMod Team made kernel = aries = more polished = newer kernel version = we can get regular kernel/version updates because the team acid members won't have to manually port them = potentially Jellybean in the long run (as soon as ICS is polished)
TeamAcidMTD kernel = herring = older version ported to work with ICS = needed to port again for JB = buggier = degraded bat life = manually having to port each change and CM version
bhundven said:
Sure wish we had a vibrantplus schematic.
Click to expand...
Click to collapse
What, the 2426 pages of S5PC110 manual aren't enough bedtime reading for you?
(No, the page count is not a joke.)
Well, I agree that getting Some Hacksung member on IRC should help you.
Related
So, since HTC is now almost 3 months past due releasing the kernel sources, I've been trying to adapt the GSM kernel to compile and work with our devices, by disassembling the stock kernel and going through line-by-line of the source to see what needs changing.
I started by copying all the '*hero*' files to be '*heroc*', and renamed all the symbols to be heroc as well. Then pulled /proc/config.gz to use as a base config. Also had to fix up the Kconfig's and Makefile's, as needed, to be able to support HEROC-specific stuff. That more or less gets it to a point where you can compile the kernel successfully, although it's still just a GSM kernel with the name and mtype of heroc.
Then I imported the stock kernel (extracted from boot.img, then decompressed) into IDA as a ROM, setup the CONST segment of string data, imported the symbols from /proc/kallsyms using an ida .idc script, and analyzed the remaining areas of the ROM. At that point, I had a virtually fully analyzed binary ROM in ida, complete with symbols. Then went through and renamed the important symbols from the board-heroc* segments as needed to match what is in the source. I also set up some of the more complicated structures/arrays to make them easier to identify.
I found several differences between the stock heroc ROM, and the make-shift hero-turned-heroc source code, and fixed most of what I came across, or just left notes for things to investigate later. What I have now is a hybrid GSM/CDMA kernel that will likely not boot on either device But I figure since I've put as much time into as I have, and I'm sure there are people more familiar with IDA and ARM than I am, I'm putting my IDA file out there for people to start from. If you're not familiar with ARM assembly, this is absolutely useless to you, so you probably shouldn't bother.
I've spent 2 sleepless nights on it already, and still can't get anything to boot. I also tried to get htc_fb_console working so that I could at least see where and why it was dying, but that hasn't worked out well either.
So, by all means, have fun: http://madcoder.binti.ehpg.net/~madcoder/stock_kernel_heroc.i64
It was created using IDA 5.2, 64-bit, but I don't know how well other versions are with compatibility. Oh yeah, it's 35MB
And if you make some breakthroughs, please post about it here. When I get some time, I'll make a patch set to go from the released GSM kernel, to what I have now, and put that up here too.
Thank you, sad but true
I just wanted to say thank you for this work and express how sad it makes me to see the necessity of reverse-engineering in an OPEN SOURCE kernel. I never thought I would see the day.
I would be very curious to hear from you about the specific differences your disassembling unearthed. Can you say with certainty that the Linux kernel code has indeed been changed to work on the CDMA Hero? I mean it's not simply a matter of some missing driver code or other userspace stuff? If so, this would be pretty damning for HTC.
Thanks again, it's amazing to watch the XDA developers' progress in spite of the barriers put in front of their work.
The majority of differences I found were in things like heroc_fixup() where it doesn't check for engineerid/skuid/etc; different camera driver (s5k3e2fx, vs cy8c); fewer checks for multiple pieces of hardware (which is weird considering the stock phone's kernel supports 4 devices) based on system_rev; wrong vreg_get() strings; etc.
The source that HTC released *does* appear to have all the support we need. With modifications to Kconfig and Makefile, and ignoring the missing board files, you *can* compile the kernel directly, using the stock /proc/config.gz, which means all the necessary drivers are already in the GSM source. It's quite obvious that they had a working kernel tree that supported the GSM phone, plus our 4 CDMA phones, and they simply yanked out the CDMA board files and Kconfig changes, before releasing the source code.
What worries me is that I can't get a console, so it's incredibly difficult to find out where it's dying at. If I could get even a serial console to work, it would make this task so much easier. I think my next step is going to be to load up my hacked kernel into ida, and see how different the two are -- that might be easier than translating asm into C and comparing that way. If I can just compare the assembly for the two, it'd probably be easier.
maejrep said:
plus our 4 CDMA phones
Click to expand...
Click to collapse
Not to derail this too much, but which 4 phones do you mean? does it name them in some way?
markachee said:
Not to derail this too much, but which 4 phones do you mean? does it name them in some way?
Click to expand...
Click to collapse
MACH_HEROC (sprint hero)
MACH_DESIREC (vzw droid eris)
MACH_HEROCT (not entirely sure, maybe bell south hero?)
MACH_NEONC (neon is supposed to be the touch dual, which afaik has never been planned as an android phone, so I'm not sure what's up with this name either)
You can see those in the /proc/config.gz on the phone (ungzip or zcat it first ), and just search for "CONFIG_MACH_".
Also in the htc_wifi.c source, you can see references to espresso, and many others.
Would it be possible to port the moment kernel over and use that since its the same processor type and then fill in the things we need?
Mr. Biggz said:
Would it be possible to port the moment kernel over and use that since its the same processor type and then fill in the things we need?
Click to expand...
Click to collapse
I was talking to zefie not too long ago and he was saying the hero kernel is so much more stable than the moments kernel... just my 2 cents.
Keep up the amazing work mad man.
travo1 said:
I was talking to zefie not too long ago and he was saying the hero kernel is so much more stable than the moments kernel... just my 2 cents.
Click to expand...
Click to collapse
Yeah, my fiance went through 2 moments, and they were so buggy she switched to the Hero. No problems since.
flipzmode said:
Keep up the amazing work mad man.
Click to expand...
Click to collapse
+1 for keeping up the good work!
:beer: (Does that emote work on this forum? I hope so...)
bumping this so it doesnt get buried 3 pages again
toastcfh said:
bumping this so it doesnt get buried 3 pages again
Click to expand...
Click to collapse
I thought you said you were going to bed
gu1dry said:
I thought you said you were going to bed
Click to expand...
Click to collapse
i was till i had to refresh again
Yeah, I basically put this on hold, due to work priorities (happens a lot unfortunately :/)
But with the news that HTC may be releasing the source soon, this is probably not worth continuing anyway
maejrep said:
Yeah, I basically put this on hold, due to work priorities (happens a lot unfortunately :/)
But with the news that HTC may be releasing the source soon, this is probably not worth continuing anyway
Click to expand...
Click to collapse
Honestly, I would continue it. Nobody's sure that HTC will release the source code (HTC said they would release the source for the "Gero"...we're hoping that was a mistype).
I have a feeling they won't release it anytime soon and you'll probably solve the entire issue with the cameras and more before that source is released.
bump.... its on the second page
Yea def keep the good work up HTC said over the weekends tht came and went so now all we got is you my good man
man we gotta get this thread stickied!!!!
toastcfh said:
man we gotta get this thread stickied!!!!
Click to expand...
Click to collapse
agreed... lol
anyhow i think this will work out before the htc hope does. bumped to the top
So, with some inspiration from NetRipper, I started trying to find a way that I could see how far it gets in the kernel booting before it stops, since I still don't have a console. Unfortunately, his suggests were LED-related (particularly gpio-enabled), and we don't have any of those. Did find one reaction that is very hard to miss, and luckily very easy to trigger: reboot via gpio
So now I'm stepping through the code, trying to find at what point in execution it stops rebooting and just hangs. So far I'm in init level 4 (of 6). I'm really hoping this leads me to something that will at least tell me "well THERE'S your problem!", and I can reverse the stock kernel asm to figure out what is different.
Okay everyone. I am working on an optimized 2.6.27 until we can get .29 ported over. But I figure, since I am fairly new to the kernel world, how can we get started porting this bad boy over? I have been looking through the source code but am somewhat lost as to where to get started. I figure if we are able get this going we can make a github account and have the progress set up for everyone. All you devs wanna join in?
chuckhriczko said:
Okay everyone. I am working on an optimized 2.6.27 until we can get .29 ported over. But I figure, since I am fairly new to the kernel world, how can we get started porting this bad boy over? I have been looking through the source code but am somewhat lost as to where to get started. I figure if we are able get this going we can make a github account and have the progress set up for everyone. All you devs wanna join in?
Click to expand...
Click to collapse
Seems like I just read someones already got a github setup. Can we branch instead of running 2 accounts if this is the case?
I am also very new to the whole kernel. I think I have actually only compilied 3 succesful linux kernels in my short life. Attempted others, but I usually get lazy or run out of time.
Kcarpenter said:
Seems like I just read someones already got a github setup. Can we branch instead of running 2 accounts if this is the case?
I am also very new to the whole kernel. I think I have actually only compilied 3 succesful linux kernels in my short life. Attempted others, but I usually get lazy or run out of time.
Click to expand...
Click to collapse
If someone has made a github project please let me know. I havent made a 2.6.29 github project yet. I am currently doing one for 2.6.27.
I created a 2.6.27 repo this morning when the source was released. And I've checked out 2.6.29, just haven't set it up in github.
Really?
What's the difference between the android kernel and the regular linux kernel? It seems their version numbers are closely related. So why not go up to the newest stable (2.6.32.5)?
lazydev said:
What's the difference between the android kernel and the regular linux kernel? It seems their version numbers are closely related. So why not go up to the newest stable (2.6.32.5)?
Click to expand...
Click to collapse
It's not that simple. For starters we have to copy over the drivers for our phone and make sure they compile correctly. On top of that HTC modified quite a bit of the kernel. Porting it over will happen but it may take some time. Like I said before I am new to the linux kernel deal but I do know it is more difficult than it seems.
I'd say a completely functional port will take roughly 2 weeks time for a hobbyist. I'm not sure though as I'm still new to messing with linux kernels. I'm looking into a port of my own. Debating 2.6.29 or porting the android specific bits to a newer linux kernel. Chances are porting the hero specific stuff to the android 2.6.29 kernel source will be much simpler. It sucks I'm on my laptop at work and it isn't running linux so no compiling, diff patching or coding for me tonight. I wish I was a bit more profficient with C programming too. I guess now I have a good reason to do just that.
lazydev said:
What's the difference between the android kernel and the regular linux kernel? It seems their version numbers are closely related. So why not go up to the newest stable (2.6.32.5)?
Click to expand...
Click to collapse
edit: didnt release chuckriczko answered your question..
obelisk79 said:
It sucks I'm on my laptop at work and it isn't running linux so no compiling, diff patching or coding for me tonight.
Click to expand...
Click to collapse
Maybe it's time to start carrying around a LiveUSB distro of Linux on a flash drive
gu1dry said:
Maybe it's time to start carrying around a LiveUSB distro of Linux on a flash drive
Click to expand...
Click to collapse
no kidding... I wasn't expecting to wake up to a new release. Of course I could just run linux on my laptop and call it a day
Yeah, the reason it's better to start with .29 than jump to .32, because a lot of the work has already been done for us in .29. In fact, if you really investigate the kernel source they released, vs the kernel on our phones, you'll notice that HTC has already backported some of the .29 changes in the android-msm-2.6.29 branch into the source they released, which was *not* initially the case in the kernel that they shipped.
What we need to do to get .29 actually working, is the opposite: forward-port the HTC changes for hero/c into the .29 source.
FYI: got an initial codebase that compiles, but does not boot yet:
http://github.com/jhansche/kernel_msm/commit/19a2d673867a8e11b98cce399ed89c94811ebf77
Started from android-msm-2.6.29 branch, with a few modifications that HTC made in our code, ported over (not all of them, mind you). If anyone has any suggestions for debugging why the kernel doesn't boot, I'm glad to hear them If I had a serial debug cable, that would be useful, cause then it would work as a serial console. But for now all I have to go on is the fact that it dies *before* ram_console can be initialized (even with early-init enabled).
I've also disabled several pieces of hardware in the interest of just getting a clean compile -- namely headset, 3.5mm audiojack, EID mddi client (lcd panel) has not been copied over yet, and some other stuff.
maejrep said:
FYI: got an initial codebase that compiles, but does not boot yet:
http://github.com/jhansche/kernel_msm/commit/19a2d673867a8e11b98cce399ed89c94811ebf77
Started from android-msm-2.6.29 branch, with a few modifications that HTC made in our code, ported over (not all of them, mind you). If anyone has any suggestions for debugging why the kernel doesn't boot, I'm glad to hear them If I had a serial debug cable, that would be useful, cause then it would work as a serial console. But for now all I have to go on is the fact that it dies *before* ram_console can be initialized (even with early-init enabled).
I've also disabled several pieces of hardware in the interest of just getting a clean compile -- namely headset, 3.5mm audiojack, EID mddi client (lcd panel) has not been copied over yet, and some other stuff.
Click to expand...
Click to collapse
Great work! As I said before I am new to this linux kernel stuff and don't think I can help but I am cloning the repo so I can take a look anyway.
Any progress with getting it to boot?
Any update on this project?
I have also been curious about this for a couple of days, just didn't want to sound pushy to the devs... hope theyre seeing progress.
theoottesen said:
I have also been curious about this for a couple of days, just didn't want to sound pushy to the devs... hope theyre seeing progress.
Click to expand...
Click to collapse
I checked the githup out. still doesn't boot
Yeah, I've been hitting a brick wall trying to get some kind of indication that something is happening... On .27 I lucked out by somehow getting it to go past the ram console, then reboot, so I could see the panic messages on /proc/last_kmsg. But in .29, I can't even write directly to the ram console memory space in a pure_init section. The problem is that there's no way to know how far it's getting in the boot process. So we're really just booting blindly.
On top of that, the android-msm-2.6.29-nexusone branch has non-QSD8k bugs (that is, if you select that it's an MSM device, not a QSD device, it won't compile without fixing stuff in their acpu code for arm11, MDP22 code paths, etc. it's like the nexusone branch was only ever tested with scorpion, not arm11 (even though it has the board files for sapphire, so you would expect it to compile for sapphire)
maejrep said:
Yeah, I've been hitting a brick wall trying to get some kind of indication that something is happening... On .27 I lucked out by somehow getting it to go past the ram console, then reboot, so I could see the panic messages on /proc/last_kmsg. But in .29, I can't even write directly to the ram console memory space in a pure_init section. The problem is that there's no way to know how far it's getting in the boot process. So we're really just booting blindly.
On top of that, the android-msm-2.6.29-nexusone branch has non-QSD8k bugs (that is, if you select that it's an MSM device, not a QSD device, it won't compile without fixing stuff in their acpu code for arm11, MDP22 code paths, etc. it's like the nexusone branch was only ever tested with scorpion, not arm11 (even though it has the board files for sapphire, so you would expect it to compile for sapphire)
Click to expand...
Click to collapse
So if I understand correctly, the devs that worked on the kernel for the Nexus One got lazy and never tried to see if it compiled on the Sapphire?
If they were developing the kernel for the nexus id hardly call them lazy for not taking the time to check it on other devices.
As far as kernels for ICS if Samsung releases source code for kernel does it have to be solely for our device or can it be (ported so to speak) from another device as long as it's a samsung
Sent from my SGH-T959V using XDA
anoymonos said:
As far as kernels for ICS if Samsung releases source code for kernel does it have to be solely for our device or can it be (ported so to speak) from another device as long as it's a samsung
Sent from my SGH-T959V using XDA
Click to expand...
Click to collapse
Team kick ass is working on it (mostly Erik)... Be patient...
Sent from my BAMF SGH-T959V!
Well I just read that samsung has released source for ICS kernel for the new Note just wondering if this can be used for our device. Also I read this from engagement.com source was from Open Source Market
Sent from my SGH-T959V using XDA
Ok I am personally going to start a new trend of not talking about ICS, CM9, or heck even Jelly Bean. If I can see that the Devs are starting to get annoyed with the constant onslaught of ICS, CM9, and CM7 questions and soon next month if it is released Jelly Bean. I guess if you can't help Develop, then you really have absolutely no place to complain about how long things are taking this is not a "customer Service" situation. Devs are here because they want to improve their own phones, or this is their hobby. They are not here to develop you a product. That's what Samsung is for in our case. If you are honestly angry about how long it is taking for us to get ICS then write T-mobile and Samsung not the Devs here that are spending their free time in order to eventually bring these awesome ROMS to our phones. Since I joined a year ago I watched Devs and entire teams leave (when is the last time you saw a Team Whiskey ROM?)So I for one am going to Back off on all the ICS business and let the Devs do their thing Without Having to stop constantly and answer the same questions over and over again. We have limited Devs that can at any sell off their SGS4g's and say "screw this" and move on to another phone. Guys seriously instead of constantly asking the Devs lets try something new ( or old to some of us) and ask Google, Yahoo, Ask.com, and or any other search engine you so choose and let the Devs concentrate on Developing.
One day people will learn how to ignore annoying posts. One day..........
i say "TEAM WHISKEY ROM" haha. lol
airfluip1 said:
i say "TEAM WHISKEY ROM" haha. lol
Click to expand...
Click to collapse
LOL thanx I didn't even see the typo, fixed it
thomas.raines said:
Team kick ass is working on it (mostly Erik)... Be patient...
Sent from my BAMF SGH-T959V!
Click to expand...
Click to collapse
Lol thanks thomas
thomas.raines said:
Team kick ass is working on it (mostly Erik)... Be patient...
Click to expand...
Click to collapse
I go away for a few days and now we're working on an ICS kernel. I should go away more often. lol
hechoen said:
I go away for a few days and now we're working on an ICS kernel. I should go away more often. lol
Click to expand...
Click to collapse
now that's comedy! !
My question had still not been answered a
Sent from my SGH-T959V using XDA
The answer( as I have come to understand, but I maybe wrong) is well parts can but for the most part the linux kernel is the part of the OS that houses all the device, and processor specific drivers. To make matters worse is some of those drivers are also OS specific. meaning Froyo versions won't work with a Ginger bread distro and so on. To port an Android distro you have one of two choices to make it work. Recompile some or all of the libs to work with the older kernel. Or create a kernel from scratch by finding other devices the have the same hardware that have been upgraded to ICS. Often many devices have pieces of the same hardware as your phone. Sometimes it takes scouring different phones to find phones that share pieces of your hardware.
Sent from my SGH-T959V
@ bot42
You are precisely correct. We at Team Kick Ass have found a way to do just that. Unfortunately, it is a very time consuming process as we have to pull many of the information, files, and things from source. I said this once and I will say it agian. Everything is in the process of being worked on. Please be patient.
Thanks sorry if I sounded rude but all the comments that were posted were way off topic that's all I'm in no hurry for ics just seen that Samsung released source for it was trying to be helpful
Sent from my SGH-T959V using XDA
it's taking me forever to properly port voodoo sound into CM7. Precisely as thomas and bot said. If it takes so long to properly port a little thing, think about how long it's gonna take to port a whole kernel.
airfluip1 said:
it's taking me forever to properly port voodoo sound into CM7. Precisely as thomas and bot said. If it takes so long to properly port a little thing, think about how long it's gonna take to port a whole kernel.
Click to expand...
Click to collapse
Yep to port a feature from one device to the next is hard a kernel/whole rom requires a lot of time and that is where my free time is being spent between reading and trying a lot of stuff
So, there are two efforts going on.
The first is what TeamKickAss is working on. I haven't seen what they are doing or any plans posted.
The second is what I'm working on over in the aosp port thread.
This port is a little more ambitious to port to three different versions.
first port sgs4g specific parts to android-samsung-2.6.35-gingerbread
then port that set of changes to android-samsung-3.0-ics branch (both branches originate from the upstream aosp samsung kernel)
the last port I will do will be to Linus's tree at whatever version it is when I get to this step.
So in the end, we'll have:
a stock kj6 kernel
the various kernels that forked from my bml and mtd kernels
aosp gb port
a couple ics kernel ports (one by teamacid, and one by teamkickass)
3.6 kernel port(or maybe 3.7)?
So, there is a peek in the crystal ball I have.
The future's so bright, gotta wear shades
Hi Bryan
Wassup?
I have a friend with SGS i9000, (which didn't get official ICS) nevertheless he installed an ICS 4.04 AOSP ROM on it, working flawlessly.
So my question is, once kernel port will reach its purpose, will we be able to successfully port such ROM ? (PS. I downloaded that ROM and saw some MTD_over_BML stuff inside)
Sent from my SGH-T959V using xda premium
i bet kickass can port it within a few days of an ICS kernel, but ports aren't always the most reliable/stable/fast. It'd be easier just to build from source. That way, we'd have a stable rom, and easier bug fixing.
itzik2sh said:
Hi Bryan
Wassup?
I have a friend with SGS i9000, (which didn't get official ICS) nevertheless he installed an ICS 4.04 AOSP ROM on it, working flawlessly.
So my question is, once kernel port will reach its purpose, will we be able to successfully port such ROM ? (PS. I downloaded that ROM and saw some MTD_over_BML stuff inside)
Sent from my SGH-T959V using xda premium
Click to expand...
Click to collapse
Yea, with so many developers on teamhacksung... they can WORK TOGETHER and port their Aries kernel to any Aries phone. Our phone is kinda funky and we have very few developers.
Sent from my SAMSUNG-SGH-I717 using xda premium
Hey, I'm a noob, let's get that out of the way first.
Alright, so I'd like to know, why is it so hard to get special ROMs working on certain devices?
For example, I have an Evo 3D (HTC Evo V 4G, whatever), so why is it so hard to get, say, stock ICS running on it?
Inthe end, isn't the hardware all the same, other than say processors and screen size? To get a stock ICS ROM working, couldn't you just pull it off of a similar phone with an S3 processor and a 4.3 inch screen?
Or is it not that simple? Are different codes baked into the hardware that make it impossible to just modify the pixel density, size of the screen and have the ROM work with the processors?
I understand the cameras are different, hence cameras not working on early builds of CM9... but considering many phones run the same processors, couldn't they just all work?
Please explain... thanks, thebeastglasser.
thebeastglasser said:
Hey, I'm a noob, let's get that out of the way first.
Alright, so I'd like to know, why is it so hard to get special ROMs working on certain devices?
For example, I have an Evo 3D (HTC Evo V 4G, whatever), so why is it so hard to get, say, stock ICS running on it?
Inthe end, isn't the hardware all the same, other than say processors and screen size? To get a stock ICS ROM working, couldn't you just pull it off of a similar phone with an S3 processor and a 4.3 inch screen?
Or is it not that simple? Are different codes baked into the hardware that make it impossible to just modify the pixel density, size of the screen and have the ROM work with the processors?
I understand the cameras are different, hence cameras not working on early builds of CM9... but considering many phones run the same processors, couldn't they just all work?
Please explain... thanks, thebeastglasser.
Click to expand...
Click to collapse
Is not that easy! I'm an EVO user/rom porter and I hear this alot where users such as yourself think is an easy process BUT is not. Same processor, same screen size maybe the same BUT at times the kernel is not there. Either the kernel for the device doesn't support ROM A or ROM B and therefore it can't be ported to whatever device or the libs keep it from running half way decent.....i.e WiFi doesn't work, sound is **** up or whatever the case maybe...just not functional to say the least.
Take for example Sense 4.0 on the One V....it was ported to the EVO4g and the ROM barely works! Both the One V and the EVO4g have similar hardware but one runs Sense 4.0 like a dream and the other one struggles with simple things like WiFi and Sound.
Now I'm sure someone else with a bit more knowledge on this can get into the specifics and the why's and what's of WHY this can't happen BUT that's it in a nut shell.....the kernel and 9/10 times libs
See ya around dude!
Hey first off, thanks! Second...
Another question then. If they all have relatively similar hardware, why isn't it that a universal kernel for similar phones can't be created?
Or better explained, what about the phone, makes it so that the kernel doesn't work? Or why couldn't you just take the kernel from device A and shove it on device B?
Sorry if I'm overloading you with questions, but hey I'm curious. Ya know?
EDIT: Or if they're practically both the same phones, why is it that you can't just take the ROM AND the kernel from phone A and put it onto phone B?
thebeastglasser said:
Hey first off, thanks! Second...
Another question then. If they all have relatively similar hardware, why isn't it that a universal kernel for similar phones can't be created?
Or better explained, what about the phone, makes it so that the kernel doesn't work? Or why couldn't you just take the kernel from device A and shove it on device B?
Sorry if I'm overloading you with questions, but hey I'm curious. Ya know?
EDIT: Or if they're practically both the same phones, why is it that you can't just take the ROM AND the kernel from phone A and put it onto phone B?
Click to expand...
Click to collapse
It's the manufacturer of the device who would need to release the kernel sources for the certain firmware version which they won't do continuously. In other words, device A may get ICS, hence the kernel sources may be released, but device B may be stuck with gingerbread and may not have a kernel which supports ICS. Back-porting can be done, but in many cases it is very difficult and in the end there still could be a lot of bugs.
You can't just take a kernel and "shove" it in another device. If you did this, it's quite likely nothing would work. The device would not even boot. Remember, the kernel is the center of android (Linux), so everything needs to be "linked" and correspond with each other exactly for it to work (I'm trying to make it as simple as possible ).
If they are the same devices, that would not be necessary. They would use the same roms/kernels. If they are just very similar (e.g. the a100 and a500) you may have some luck with the roms, but not the kernel. Some a500 roms can be flashed onto an a100 and work flawlessly BUT the device's original kernel must be restored for the device to boot.
Theonew said:
It's the manufacturer of the device who would need to release the kernel sources for the certain firmware version which they won't do continuously. In other words, device A may get ICS, hence the kernel sources may be released, but device B may be stuck with gingerbread and may not have a kernel which supports ICS. Back-porting can be done, but in many cases it is very difficult and in the end there still could be a lot of bugs.
You can't just take a kernel and "shove" it in another device. If you did this, it's quite likely nothing would work. The device would not even boot. Remember, the kernel is the center of android (Linux), so everything needs to be "linked" and correspond with each other exactly for it to work (I'm trying to make it as simple as possible ).
If they are the same devices, that would not be necessary. They would use the same roms/kernels. If they are just very similar (e.g. the a100 and a500) you may have some luck with the roms, but not the kernel. Some a500 roms can be flashed onto an a100 and work flawlessly BUT the device's original kernel must be restored for the device to boot.
Click to expand...
Click to collapse
I have the strangest feeling I just tried to jump into the shallow end of the swimming pool, and yet instead was shot out of a cannon into the middle of the sea without a scuba diver's suit... If only I could understand this more!
thebeastglasser said:
I have the strangest feeling I just tried to jump into the shallow end of the swimming pool, and yet instead was shot out of a cannon into the middle of the sea without a scuba diver's suit... If only I could understand this more!
Click to expand...
Click to collapse
Think about it this way. The Android OS could be run on a number of different devices that run slightly different hardware such as cameras, touchscreens, processors, etc...but the OS has to be able to communicate properly to that hardware using device drivers. Just like Windows from a 30000 foot view. It can run on a Dell or Acer computer, but must have the proper drivers.
If the manufacturer's of those devices do not write ICS drivers or preferably furnish their source code, then it is incredibly difficult if not impossible for someone without the internal company documentation to write such a driver.
mf2112 said:
Think about it this way. The Android OS could be run on a number of different devices that run slightly different hardware such as cameras, touchscreens, processors, etc...but the OS has to be able to communicate properly to that hardware using device drivers. Just like Windows from a 30000 foot view. It can run on a Dell or Acer computer, but must have the proper drivers.
If the manufacturer's of those devices do not write ICS drivers or preferably furnish their source code, then it is incredibly difficult if not impossible for someone without the internal company documentation to write such a driver.
Click to expand...
Click to collapse
Ohhh... so say you decided to put your own little phone together according to your own prerequisites, it'd be simple for you to do something on it, but not so much for someone who only has the hardware to look at... correct?
Another question, why is it so easy to port things onto Nexus Devices? Are they just more compatible with all drivers? As I've heard from one of my friends that he has a fully working Sense 4 ROM on his Nexus S... and yet it's tough to find one for my Evo V.
EDIT: I'm out of "thanks" I'll give you one as soon as I get some more...
thebeastglasser said:
Ohhh... so say you decided to put your own little phone together according to your own prerequisites, it'd be simple for you to do something on it, but not so much for someone who only has the hardware to look at... correct?
Another question, why is it so easy to port things onto Nexus Devices? Are they just more compatible with all drivers? As I've heard from one of my friends that he has a fully working Sense 4 ROM on his Nexus S... and yet it's tough to find one for my Evo V.
EDIT: I'm out of "thanks" I'll give you one as soon as I get some more...
Click to expand...
Click to collapse
Hmmm, I am not as familiar with the Nexus devices, but I suspect that Google has released the hardware spec details and the source code for the drivers for Nexus phones, so the source code can be modified and included for the ports. HTC unfortunately has not been as open with some of their phones.
If you were to put a phone together, you would need to use hardware in it that you had access to the specs and source code for. This is not a great analogy, but I think it will serve. The camera app tells the OS, "take a picture", then the OS tells the driver, "make the camera take a picture", and the camera device driver controls the hardware parts like the shutter, the focus, and zoom to cause the picture to be taken and handed back to the OS to be saved and then the OS notifies the app, "here is your picture, awaiting next command".
If you do not have access to the camera driver source code and camera hardware specs to create a driver, or an actual driver from the camera manufacturer, then you are missing the crucial third part and you cannot make the camera take a picture even if you get an OS loaded and an app installed there.
Check out The Tricorder Project for an excellent example. Create your own Star Trek "tricorder" with various sensors and a touchscreen that runs on Linux for around $200 and some work putting it together.
thebeastglasser said:
Ohhh... so say you decided to put your own little phone together according to your own prerequisites, it'd be simple for you to do something on it, but not so much for someone who only has the hardware to look at... correct?
Another question, why is it so easy to port things onto Nexus Devices? Are they just more compatible with all drivers? As I've heard from one of my friends that he has a fully working Sense 4 ROM on his Nexus S... and yet it's tough to find one for my Evo V.
EDIT: I'm out of "thanks" I'll give you one as soon as I get some more...
Click to expand...
Click to collapse
Its easy to develop for nexus devices since Google always releases their sources and those devices are easily unlockable (the bootloader). This is one reason why they are usually referred to as development/developer devices.
So in other words, the software communicates with the hardware, but without the proper code embedded in the hardware, it's not possible for the software to communicate with it? And without source code given from the developer of the hardware, you're making software that hypothetically should work, but because of the different device hardware it may or may not work...?
And that's also big because some guy on the portal recently found out that all of the eight mega pixel cameras on HTC devices are the same, so it should now be easy to use working cameras on ported and newly created ROMs...
Am I getting anywhere with this?
thebeastglasser said:
So in other words, the software communicates with the hardware, but without the proper code embedded in the hardware, it's not possible for the software to communicate with it? And without source code given from the developer of the hardware, you're making software that hypothetically should work, but because of the different device hardware it may or may not work...?
And that's also big because some guy on the portal recently found out that all of the eight mega pixel cameras on HTC devices are the same, so it should now be easy to use working cameras on ported and newly created ROMs...
Am I getting anywhere with this?
Click to expand...
Click to collapse
Yes, you got it a bit better now. The software needs to have the same codes embedded in the hardware to correspond with it. The source code is not from the hardware but of the software (kernel source).
Yes if the ROM was ported to other HTC devices with the same/similar camera (some libs will still need to be changed though).
Theonew said:
Yes, you got it a bit better now. The software needs to have the same codes embedded in the hardware to correspond with it. The source code is not from the hardware but of the software (kernel source).
Yes if the ROM was ported to other HTC devices with the same/similar camera (some libs will still need to be changed though).
Click to expand...
Click to collapse
Alright that makes a bit more sense. Thanks for your help guys!
The Nexus S has the same CPU as our phones, same storage, same screen and they get OTA updates right to jellybean. What is the difference between that phone and ours that would make using their ROM's to help with our phones?
One of the reasons the x86 platform has been so successful is that there are thousands of pages of requirements that make most versions of computers running with an x86 CPU "look the same" to an operating system. For example, the video card always has to implement the same set of instructions and the same way to draw things on the screen.
Unfortunately, phones aren't as generous.
While other phones use the same CPU, they often use different chips to handle things like the keyboard, screen, audio, GPS, phone radio, WiFi, Bluetooth, USB,... Each of these requires a different driver (the code that lets the kernel "talk" to the chip in a standard way). Remember Windows 9x when every time you bought a new mouse, video card, or whatever you had to search for the right driver?
Worse than that, there are hundreds of pins on the CPU and no "wiring diagram" for the devs to work from. Some of the big puzzles the devs are working with are figuring out which pin goes where when making these drivers connect up right. Not only is it knowing which pin goes where, but is it rising edge means "1" or falling edge, should the pin be inactive high, or low. How fast can the device take data?
Then are the "proprietary bits" -- this is the biggest "lie" about devices claiming to be "open source." Even though parts of the device may use Linux or have source available for the dev to look at, some things are just "binary blobs" that the manufacturer wrote themselves, or obtained from the chip vendor and added to their device. No source is available. In some cases, they can be re-used with a later kernel version. In others, they are just "too old" and you're stuck because they don't implement certain instructions that a newer kernel needs, or implement it in the "wrong" way -- think trying to use a Windows 95 driver with Windows 7 -- It just isn't going to work.
For the SGS4G, some of the proprietary bits we are stuck with include:
Boot loaders -- the code that runs when the phone starts up that knows how to read the flash and start the kernel
RIL -- The code that runs the "phone" radio
GPS
TV Out
WiFi Calling
I know I've got all three of the Samsung source drops for our phone on my machine, as well as two versions of kernels from AOSP (semi-official Google source), two versions of Linaro, mainline Linux, CyanogenMod, Team Hacksung, and a few more, all of which include drivers for several phones similar to ours. It chews of a bit of disk space, but sometimes can provide insight.
We can't "just build JellyBean" as there have been some very significant changes in the kernel between the 2.6.35 version we have now, and the 3.x line that JellyBean needs to run. For example, how "events" are handled by the kernel has changed. These are things like pressing a key, so they are sort of important to get right.
Thanks. I was just cruising around looking at Sammy phones and saw that and it looked similar specs. I know all about drivers/pcs/different devices/chips used in things, run a repair shop fixing electronics/pc's, I do reflowing, reballing, etc. Just didn't realize they made the Nexus so different. That's fine, I'm happy with the Remi ICS for now.
So... you can remove and replace bga chips?
Sent from my SGH-T959V using xda premium
Once someone tries and screws it up, please send the remains to bhundven so he can trace out the circuit board
(Joking on trying it, not joking on Team Acid being able to benefit from a destroy-able SGS4G.)
There's a galaxy s 4g main board on eBay right now ending in like 20 min currently at about 5 bucks
Sent from my SGH-T959V using xda premium