Google just moved out the 2.6.32 kernel from the experimental git repo to the msm repo. This means that google thinks they are stable now.
There are currently two 32 branches:
android-msm-2.6.32-nexusonec
http://android.git.kernel.org/?p=kernel/msm.git;a=shortlog;h=refs/heads/android-msm-2.6.32-nexusonec
android-msm-2.6.32
http://android.git.kernel.org/?p=kernel/msm.git;a=shortlog;h=refs/heads/android-msm-2.6.32
I've compiled both and I'm finding the nexusonec branch more stable than the 32 branch. The 32 branch causes issues with the gallery and camera app not recognizing the sd card. Everything seems to work fine in the nexusonec branch (sdcard, wifi, BT, camera, etc). Speed is definitely faster than 29.
For those who are interesting in flashing the 32 zimage, they can d/l it here:
http://drop.io/xdp6104#
Right now the kernel is just a stock config, meaning no tethering or anything else. Only change I've made from stock is to use the deadline I/O scheduler. I'm sure cyanogen will add those other goodies when he releases a new version.
Very nice: cant wait for a Enomther rom with this new Kernel
nice....
ive compiled a nice cyanogen kernel 2.6.32 already
just need to get the wifi module compiled correctly and we are gtg!
Does this mean that they've fixed some of the power saving regressions people were seeing with 2.6.32 before?
Installed on my Nexus with enomther 1.61: works nicely
Tot mem 395448K, Free 265916K
Does this still have the charging issue that blocks the battery to charge when it goes under 90%...???
eug89 said:
Does this still have the charging issue that blocks the battery to charge when it goes under 90%...???
Click to expand...
Click to collapse
86% now and charging..
eug89 said:
Does this still have the charging issue that blocks the battery to charge when it goes under 90%...???
Click to expand...
Click to collapse
It wasn't an issue per-se it was a 'feature'
The problem was caused by downgrading to older kernels after using 2.6.32. Certain hardware states that were set by the new kernel telling the battery not to charge weren't being un-set by the new kernel, and the older kernel didn't even know about them. They patched the newer kernel pretty quickly after getting feedback so that it removes the hardware state when shutting down, I believe. So, yes, it's 'fixed'
FettsVett said:
It wasn't an issue per-se it was a 'feature'
The problem was caused by downgrading to older kernels after using 2.6.32. Certain hardware states that were set by the new kernel telling the battery not to charge weren't being un-set by the new kernel, and the older kernel didn't even know about them. They patched the newer kernel pretty quickly after getting feedback so that it removes the hardware state when shutting down, I believe. So, yes, it's 'fixed'
Click to expand...
Click to collapse
Thanks, i called it issue because i didn't know how to call it but i knew that it was meant to be a sort of new feature of the 2..6.32 kernel and I wanted to write above 90% and not under 90%... did a bit of a mess
woahhh its way faster
thanks dwang
will do some thorough testing and post back soon.
edit: Hmmm having some trouble with fastboot... unable to push wifi via adb?
anyone else encountering this?
Are you trying to push the ko module on fastboot mode?
This kernel is FAST and SNAPPY! HIGHLY RECOMMENDED!
boqonx said:
Are you trying to push the ko module on fastboot mode?
This kernel is FAST and SNAPPY! HIGHLY RECOMMENDED!
Click to expand...
Click to collapse
yeah. iirc thats where you do it right?
Let the OS run, then push through adb. Can't do it when it's on recovery either because the /system/lib is not mounted. Wifi should work even without a restart.
yep just did that
i think i was just confused on where to use adb
it still works so all good. this kernel is zippy.
Damn right This thing flies now! Scrolling through messages is MUCH smoother. Seen a lot of tearing when scrolling on CM's kernel.
I released my undervolted version of CM's in the other thread. He changed the scheduler from anticipatory to deadline as well.
Will try! Had any reports on instabilities yet?
Dwang: great job on the deadline scheduler suggestion. It really does make the whole experience smoother.
Can someone write the exact adb command to push it?
Code:
adb remount
adb push ./bcm4329.ko /system/lib/modules
himmatwala said:
Can someone write the exact adb command to push it?
Click to expand...
Click to collapse
My buttons won't work when i press them not exactly sure whats wrong but this began happening within the past few days. I've been running WTSB 3.5 latest update of 2.4 and Olympus Prime both of which use's a chad kernel which i'm not sure may or may not be the source of the problem. Can anyone offer any suggestions?
Selebrity said:
My buttons won't work when i press them not exactly sure whats wrong but this began happening within the past few days. I've been running WTSB 3.5 latest update of 2.4 and Olympus Prime both of which use's a chad kernel which i'm not sure may or may not be the source of the problem. Can anyone offer any suggestions?
Click to expand...
Click to collapse
By LED buttons I'm going to assume you're referring to the 4 capacitive buttons across the bottom, Home, Menu, Back and Search.
Never really heard of any software disabling these buttons, either intentionally or accidently but doesn't mean it couldn't happen!
Quick shorter term and temporary approach: boot into the custom recovery and see if their lights flash or they work at all in the custom recovery. I remember at one point during TWRP development we had the lights flashing on them. Not sure what kinda support ended up but you should be able to get some type of response to at least indicate the hardware is working.
Long but thorough approach:
Since you are running a custom ROM and kernel, I would suggest first reverting back to Stock and wipe /data and /cache.
If everything works on a Stock ROM and kernel, then you know it has something to do with either the custom ROM, custom kernel or a custom setting configuration. From a known working stock configuration, you can customize one piece at a time checking after each customization step to make sure the buttons work.
Ideally, the buttons will break after a specific customization step and you'll be able to narrow it down to that step and approach the appropriate developer with your results who will then be able to dig into their code and look at the issue.
Hope that helps!
Hi all,
Since i'm unable to start a thread in the android development forum I try here. Hopefully Arrrrgh won't get Arrrrgh'd at me for posting this..
I have a problem which I hopefully get support for. I have tried all Android roms for the touch pro2 which none will boot or get past the ACL bootlogo.
I've tried every imaginable way to get it working but all are resulting in a kernel panic. I tried the NAND versions and the SD versions but both options results in the same kernel panic.
First I thought it was the SD formatting problem but after trying 4 different sizes and brands I excluded this as a possible cause.
It seems after looking at it a bit more thoroughly I got a Vario V version of the TP2 - Rhodium 100 (please correct me if i'm wrong)
I'm able to pull logs i'm ready and willing to pass the logs for supporting this device. I've found a similar thread by Z!nk / Z1nk but he gave up on the device before the developers could get to it.
So hopefully there is a developer willing to add this version to the android roms.
Thanks for reading and hope to hear from anyone soon.
Cheers,
Alchedin
[edit] The device has security unlocked and is HSPL'd [/edit]
Alchedin said:
It seems after looking at it a bit more thoroughly I got a Vario V version of the TP2 - Rhodium 100 (please correct me if i'm wrong)
Click to expand...
Click to collapse
How can we correct you if you're wrong - you need to tell us what phone variant you have. There's a surefire way to know as well...
It's kind of the first question in the FAQ...
Either way, the fact that you can't boot either makes me think you have a clone. There was another fellow with a clone (perhaps the one you mentioned?) that was unable to boot XDAndroid because he didn't have the same hardware. If you run HaRET.exe with no startup.txt, what does it say?
Edit - Regardless, I would focus on one build and try to get that to work. FRX07.1 is probably the "simplest" from that perspective.
Edit2 - Also, you seem to indicate it's a kernel panic. Why no logs?
Dear Arrrghhh,
Thanks for replying.
Ok, looking at the faq it states my phone should be a Rhod100 (complete: NM8RHOD100) which seems, when googeling, to be some kind of T-Mobile version. At the moment i'm running a deepshining
I ran the rom without a startup.txt and it gave me the following message: Found machine Rhodium. Hope this is the info you needed?
Placed in the Rhodium100 startup.txt a started haret again, which resulted in a kernel panic.
Will keep you informed since I'm not at home.
Alchedin said:
Placed in the Rhodium100 startup.txt a started haret again, which resulted in a kernel panic.
Click to expand...
Click to collapse
Logs? How do you know it's a kernel panic? What kernels have you tried?
arrrghhh said:
Logs? How do you know it's a kernel panic? What kernels have you tried?
Click to expand...
Click to collapse
Hi Arrrghhh,
Attached are the adb logs, which I hope is the info you need. This is what I get when using FRX07.1 like you advised.
But I have three questions if i'm not too bold:
1. Did you advise this version because it's more thoroughly when it comes to finding a issue?
2. When looking at the logs, is there something wrong with sound or something?
3. I'm able to pull logs of NAND builds if you like? They seem to be more complete when it comes to information on boot.
Cheers,
Alchedin
Today I tried the GBX0C version of XDandroid and this is the first working android on my phone. Boot-animation started and it just worked! Still can't believe it.
Any idea how this rom differs from the FRX07.1?
Cheers
Alchedin said:
Today I tried the GBX0C version of XDandroid and this is the first working android on my phone. Boot-animation started and it just worked! Still can't believe it.
Any idea how this rom differs from the FRX07.1?
Cheers
Click to expand...
Click to collapse
Well there's a few things, besides the whole FroYo vs. Gingerbread. The acoustic code/routing is the 'main' one. Not sure what else off the top of my head, but there's changelogs in the GBX0C thread. There's not a huge difference since some of it was backported to FRX...
Either way, glad GBX is working.
Edit - the logs you posted from the FRX failures don't really give me much to go off of either, unfortunately.
arrrghhh said:
Well there's a few things, besides the whole FroYo vs. Gingerbread. The acoustic code/routing is the 'main' one. Not sure what else off the top of my head, but there's changelogs in the GBX0C thread. There's not a huge difference since some of it was backported to FRX...
Either way, glad GBX is working.
Edit - the logs you posted from the FRX failures don't really give me much to go off of either, unfortunately.
Click to expand...
Click to collapse
Today I tested different kernels using GBX0C and found out the following:
2.6.27.46(original GBX0C) - boots up
2.6.39.3 - boots up - Buttons / keyboard not functioning correctly
3.0.18 - boots up - buttons / keyboard not functioning correctly
3.3.8 - Not booting - Stuck on calibration (message: X & Y the same)
3.4.3 - Not booting - Stuck on calibration (message: X & Y the same)
Hope I did it right, replaced the zimage and module with every kernel switch. Also created a new data.img every time.
Cheers,
Alchedin
Alchedin said:
Today I tested different kernels using GBX0C and found out the following:
2.6.27.46(original GBX0C) - boots up
2.6.39.3 - boots up - Buttons / keyboard not functioning correctly
3.0.18 - boots up - buttons / keyboard not functioning correctly
3.3.8 - Not booting - Stuck on calibration (message: X & Y the same)
3.4.3 - Not booting - Stuck on calibration (message: X & Y the same)
Hope I did it right, replaced the zimage and module with every kernel switch. Also created a new data.img every time.
Cheers,
Alchedin
Click to expand...
Click to collapse
Sounds like for one reason or another, your device is different from all other RHOD's. There seems to be an infinite number of RHOD100 variants, and supporting all of them equally is impossible.
Unfortunately you're going to have to troubleshoot these issues. We don't have a lot of devs left, and without having the device in hand, it makes such development 1,000x harder. Good luck.
arrrghhh said:
Sounds like for one reason or another, your device is different from all other RHOD's. There seems to be an infinite number of RHOD100 variants, and supporting all of them equally is impossible.
Unfortunately you're going to have to troubleshoot these issues. We don't have a lot of devs left, and without having the device in hand, it makes such development 1,000x harder. Good luck.
Click to expand...
Click to collapse
If I supply you with the information you need through video, logs, dmesg, logcat etc. you can implement it correct? Too bad you're in the USA so shipping it will be costly.
Walter79 lives in Germany which country is next to where I live, maybe he can/is willing to extract the required info from the phone? I'm willing to go the extra mile if it helps the whole TP2 community.
Thanks a lot anyway :good:
Cheers,
Alchedin
Alchedin said:
Today I tested different kernels using GBX0C and found out the following:
2.6.27.46(original GBX0C) - boots up
2.6.39.3 - boots up - Buttons / keyboard not functioning correctly
3.0.18 - boots up - buttons / keyboard not functioning correctly
3.3.8 - Not booting - Stuck on calibration (message: X & Y the same)
3.4.3 - Not booting - Stuck on calibration (message: X & Y the same)
Hope I did it right, replaced the zimage and module with every kernel switch. Also created a new data.img every time.
Cheers,
Alchedin
Click to expand...
Click to collapse
Have you tried plugging a known working calibration file into the rom and using the kernels that are giving a calibration error?
Alchedin said:
If I supply you with the information you need through video, logs, dmesg, logcat etc. you can implement it correct? Too bad you're in the USA so shipping it will be costly.
Walter79 lives in Germany which country is next to where I live, maybe he can/is willing to extract the required info from the phone? I'm willing to go the extra mile if it helps the whole TP2 community.
Thanks a lot anyway :good:
Cheers,
Alchedin
Click to expand...
Click to collapse
I would not be a good candidate as I am far from a developer. As I stated previously, we don't really have any devs actively working on the project. walter79 just created the CM build, unfortunately he was not part of the original XDAndroid development team.
Again, your phone seems like it is a one-off, and development efforts for a one-off device are always difficult. I'd say you're going to have to pick up the effort yourself, or be happy with where the development is left at.
wizardknight said:
Have you tried plugging a known working calibration file into the rom and using the kernels that are giving a calibration error?
Click to expand...
Click to collapse
I used the same ts-calibration file that was created during the first boot of gbx0c. Like I stated earlier, I only replaced/removed the zimage, module and data.img file every time I switched kernel.
Should I also re-calibrate every time when switching kernels?
arrrghhh said:
I would not be a good candidate as I am far from a developer. As I stated previously, we don't really have any devs actively working on the project. walter79 just created the CM build, unfortunately he was not part of the original XDAndroid development team.
Again, your phone seems like it is a one-off, and development efforts for a one-off device are always difficult. I'd say you're going to have to pick up the effort yourself, or be happy with where the development is left at.
Click to expand...
Click to collapse
Many thanks for your interest and pointers arrrghhh, I will look into kernel stuff and such, maybe i'll get some of it working :fingers-crossed:
I have little to no development/linux/android skills but I can at least try to learn it.
Cheers
P.S: In a earlier stage playing around with NAND builds I managed to use the boot.img of the CM9-ICS_X1_testbuild1 in combination with the CM7.2 of walter79 and got it running in landscape mode, if this worked for me I can go from there.
Bit by bit i'm getting a hang of it.
Alchedin said:
Should I also re-calibrate every time when switching kernels?
Click to expand...
Click to collapse
No, as I state in all my threads about calibration - once you get a good calibration file, save 15,000 copies of it and re-use it constantly. There's no need to constantly recalibrate.
Ok here we go, sorry for the big read..
I hope I can be as precise as possible. This is about the NAND builds i've tested.
I installed ICS like in my last post again and made a CWM backup of the whole phone.
After this I did a new task29 and reflashed everything till I got back into CWM.
This time I installed the OMGB stable release with the kernelpatch + gapps.(seems the most advised build) Factory reset/data/cache/etc just to be sure.
Rebooted the device and let OMGB do it's thing, thus resulting in a kernel panic - can not sync issue. This is clearly a default message on this phone which I am in peace with. (log1)
Now for the fun part, I had this ICS testbuild backup up earlier and only did a restore of the boot part. Cleared the data/cache/etc again and rebooted.
This time it just boots fine into OMGB... (log2) previous attempts resulted in a landscape layout which i wasn't able to adjust myself, but this time I got the portrait mode correct! The only part which isn't working is the keyboard and hardware buttons.
Seems the "default" startup process is hanging in the part of the AudioFlinger? I compared the 2 logs but I can't see anything really which normally would result in a kernel panic.
Attached are the logs for the default OMGB boot (log1.txt) and the ICS modified boot + OMGB system (log2.txt)
Is this still different from any other Rhod100 or just a small adjustment? If this is really unknown I will break the phone to pieces and give up on it :silly:
I'll keep this config on the phone a bit longer since data and phone is working.
Thanks for reading
Cheers
-No sound
[Update]
Made a finding myself, the problem for my phone lies within the libhtc_acoustic.so removing this file made NAND boot up for the first time on this phone. Now looking for a compatible acoustic replacement which generates sound.
Going to try copying/pushing the file from FRX0.7 to NAND CM7.2 and see what it does. Including replacing my csv's from WinMo in the /system/etc folder.
[Update2]
Installed CM7.2 2.6.27 version today and used the FRX0.7 aucoustic.so, which resulted in a perfectly working android without sound...
now going after the csv's, which I hope gets me sound.
arrrghhh said:
[snip]...
Again, your phone seems like it is a one-off, and development efforts for a one-off device are always difficult. I'd say you're going to have to pick up the effort yourself, or be happy with where the development is left at.
Click to expand...
Click to collapse
I did a bit myself yesterday and today, the problem lies in the libhtc_acoustic.so, removing only this file made nand boot for me finally. See above post.
Alchedin said:
I did a bit myself yesterday and today, the problem lies in the libhtc_acoustic.so, removing only this file made nand boot for me finally. See above post.
Click to expand...
Click to collapse
Hrm, perhaps the new acoustic code jb started and detule 'finished' if you will isn't compatible with your device.
I don't know 'why'... on GBX0C did you copy the CSV's from your phone? I don't know how that build worked for you, because OMGB uses the same acoustic code.
arrrghhh said:
Hrm, perhaps the new acoustic code jb started and detule 'finished' if you will isn't compatible with your device.
I don't know 'why'... on GBX0C did you copy the CSV's from your phone? I don't know how that build worked for you, because OMGB uses the same acoustic code.
Click to expand...
Click to collapse
The interesting parts were the updates I posted. I did copy the csv's from the WinMo earlier, which were instructed by you (using total commander and such), but can't remember if it did produced sound.
But then...
I switched over to NAND CM7.2 by Walter79 and replaced the csv's in the CM7.2 zip file at location /system/etc (audioparatable.csv etc.)
Also I used the libhtc_acoustic.so from here
And ADB pushed the .so into the /system/lib folder.
When running logcat I see that the csv's are used and the audio routing is ok, but still didn't produce sound. Thought there were some other locations were the csv's are stored which I will also replace with mine. But didn't get to that yet.
Just tinkering with files really.. that's as far as I can go since I'm no developer.
What you mean by "perhaps the new acoustic code jb started and detule 'finished' if you will isn't compatible with your device" ?
Alchedin said:
What you mean by "perhaps the new acoustic code jb started and detule 'finished' if you will isn't compatible with your device" ?
Click to expand...
Click to collapse
I don't know how else to phrase that...
Although, I might have misread your statement. I thought you said you replaced a lib from FRX07.1 - which wouldn't boot for you. GBX0C did boot, so it seems the new acoustic code actually helps your phone.
So now I'm not sure what the deal is. I know OMGB uses the new acoustic, and I was under the impression that the CM ROM did as well. Did you try GBX0*? Basically the NAND version of GBX0C.
Right so here's the deal:
As of now, flashing a galaxy s rom boots up fine and gets me to the lockscreen...however, touchscreen doesn't work and so I can't test any of the other features (wifi, bluetooth, camera, etc.).
The aim of this thread/project is to create a "flash-pack" that will allow us to flash ICS Galaxy S AOSP/CM9 based roms (much like Hanthesolo's pack for GB roms)
Sooo, let's get to work:
Touchscreen
i know that files in /system/lib/hw and /system/usr/idc are necessary for it to work, but replacing them makes no difference. Ideas?
reserved just in case
theraf said:
Right so here's the deal:
As of now, flashing a galaxy s rom boots up fine and gets me to the lockscreen...however, touchscreen doesn't work and so I can't test any of the other features (wifi, bluetooth, camera, etc.).
The aim of this thread/project is to create a "flash-pack" that will allow us to use ICS Galaxy S AOSP roms (much like Hanthesolo's pack for GB roms)
Sooo, let's get to work:
Touchscreen
i know that files in /system/lib/hw and /system/usr/idc are necessary for it to work, but replacing them makes no difference. Ideas?
Click to expand...
Click to collapse
So it could only be a matter of finding how to get the touchscreen working to get all the galaxy s roms working if I understand? This is if every other thing work indeed. I've always aksed myself wath was so different between them that prevent us to be using their rom. Hope you get the touchscreen working so you can test if evrething works fine.
theraf said:
Right so here's the deal:
As of now, flashing a galaxy s rom boots up fine and gets me to the lockscreen...however, touchscreen doesn't work and so I can't test any of the other features (wifi, bluetooth, camera, etc.).
The aim of this thread/project is to create a "flash-pack" that will allow us to flash ICS Galaxy S AOSP/CM9 based roms (much like Hanthesolo's pack for GB roms)
Sooo, let's get to work:
Touchscreen
i know that files in /system/lib/hw and /system/usr/idc are necessary for it to work, but replacing them makes no difference. Ideas?
Click to expand...
Click to collapse
The touchscreen mostly don't work because the I9000 uses a different touchscreen drivers than us. The i9000 uses the mxt224 drivers and we use the qt600xxx (I don't remember the digits) drivers. We do however use the same touchscreen but only with a different driver. And I think the changes between those drivers can fix the US home button problem in the US players.
zaclimon said:
The touchscreen mostly don't work because the I9000 uses a different touchscreen drivers than us. The i9000 uses the mxt224 drivers and we use the qt600xxx (I don't remember the digits) drivers. We do however use the same touchscreen but only with a different driver. And I think the changes between those drivers can fix the US home button problem in the US players.
Click to expand...
Click to collapse
the drivers are in /system/usr/idc right?
theraf said:
the drivers are in /system/usr/idc right?
Click to expand...
Click to collapse
Not exactly. The drivers itself are in the kernel. the file in /system/usr/idc is the calibration file for the touchscreen. I think it indicates the kernel where the touchscreen should calibrate. The thing is I think the I9000 took the mxt224 drivers from crespo because I tried one day from our kernel source and it didin't work. (Maybe I didin't have the right calibration tool too.)
zaclimon said:
Not exactly. The drivers itself are in the kernel. the file in /system/usr/idc is the calibration file for the touchscreen. I think it indicates the kernel where the touchscreen should calibrate. The thing is I think the I9000 took the mxt224 drivers from crespo because I tried one day from our kernel source and it didin't work. (Maybe I didin't have the right calibration tool too.)
Click to expand...
Click to collapse
ok, but since i'm using the ypg1 kernel, all i need to do is swap the correct files from the galaxy s /system folder