ARCHIVED: [Kernel] Picasticks OC kernel built from LG source

[picasticks]

Mainly my toolchain by whatever means (buildroot) allows me to force the vfp to use hardware acceleration opposed to software emulation wherever possible. The standard Android Compiler says this is impossible, whereas the buildroot toolchain (and possibly others) accept this flag and there is a noticeable increase in responsiveness.

The VFP is similar to the FPU in a PC. It accelerates Vector Floating Point operations.

I had seen the hardware VFP enabled in the kernel config but hadn't traced it to see what happened during compilation. I'll give it another look. Thanks!

I recompiled my kernel yesterday with the CodeSourcery G++ toolchain (GCC 4.5.1), and didn't have to do anything but change the CROSS_COMPILE env var to point to the new toolchain. Resulting binary has been running fine on my phone. It's a bit smaller (I'm still compiling with -Os like LG) and benchmarks a tiny bit faster.

 

[sfhub]

Your battery problem is stranger, maybe somebody else has run into this?

It's possible the battery charging problem I think I'm seeing is actually a battery notification problem, where the battery is actually 100% charged, but the notification isn't getting there.

 

[sfhub]

Can you still connect via adb when the USB and debug USB connected notifications are gone? In my case, the fact that they were gone made no difference -- my connected shells stayed connected and I was able to make new connections via adb with no problem or delay despite what the phone's status bar said.

Thinking back I believe my adb shell session may actually have stayed connected (which would make my comment about adb dying not make sense), but I was busy in a chat session at the time, so didn't pay especially close attention, just kept hearing some notification sounds on the phone and quickly looked to see what was causing them. My adb shell session window was behind some other windows and I never looked to see what was happening there due to being distracted. My guess is it is as you described.

If I have some time, I'll try and narrow things down further.

 

[picasticks]

Thinking back I believe my adb shell session may actually have stayed connected (which would make my comment about adb dying not make sense), but I was busy in a chat session at the time, so didn't pay especially close attention, just kept hearing some notification sounds on the phone and quickly looked to see what was causing them. My adb shell session window was behind some other windows and I never looked to see what was happening there due to being distracted. My guess is it is as you described.

If I have some time, I'll try and narrow things down further.

Yesterday for 6-8 hours (while doing other stuff) I tried to reproduce what I remembered from before about the USB notification going in and out.

This time though, couldn't get it to happen. Tried at various clock speeds and with both ondemand and interactive.

Left an adb shell open the whole time and it stayed connected, and there was no problem with the USB or USB debugging notifications going away.

On the battery, the charging indicator would go away shortly after I plug the phone in, with the battery at 100%. Charge would stay at 100% and change from "charging" to "discharging" in the settings/status screen. My assumption is that this is normal, that once the battery is charged it just intermittently trickle-charges to stay at 100%. I never saw it drop below 100%.

So, for now I would say "no issues" on my end. I guess that's good for me but I would rather have found something to fix. :-\

It sounds too easy to blame the previous USB cable (which was definitely a little loosey on the micro-USB end), but that's most likely it in my case, or your phone not liking OC or hitting a particular battery temp (my battery has stayed cool, never seen it above 21 C). I have noticed with my phone if the RAM is totally used (as reported by "free" via shell) it hits performance and SetCPU benchmarks are about 16% slower ... i.e. the long bench goes from 7300 to 8500, so just having RAM in that state is going to keep CPU at the high end longer and add more heat (I have to kill/force stop the bg processes to solve this). So a combo of things could have been making more heat maybe?

Normally with Linux you *want* all your RAM used (just not wired) but in my case Android/Linux aren't automatically freeing RAM when needed which is disappointing. There are apps in bg that I would have thought Android would know to kill. Not specific to my kernel though. (I'm not an embedded guy so this is my first time tuning Linux w/ so little ram and no swap, so maybe what I'm describing is actually normal for hardware like ours.)

Interactive definitely keeps the processor at the high end for longer than ondemand. I'd have to collect some data to see how much the average clock speed is actually affected over time, so that's just anecdotal but it seems to be the case.

FYI (and I can't see how this would matter, but you never know) all my tests were with the kernel recompiled with the Code Sourcery toolchain and gcc instead of Google's. After a couple of days that kernel seems good, if you want to try it I could upload it.

 

[sfhub]

Thanks for looking into it. If you post the one built with the alternate toolchains, I'll try it out when I have some time. Don't have the phone around to try at the moment.

 

[picasticks]

OK, here it is: picasticks-05-cs2.zip. It has been running fine for me for the last 37 hours.

Everybody, this is the same as 05, just a different compiler (and I swapped in 7zip for gzip -9 but that doesn't affect the loaded kernel).

 

[sfhub]

I'll run it overnight and see how it goes. So far haven't had any USB notifications go off.

 

[DoesItMatter]

Running it here too - no issues so far, been about an hour.

No issues on original Pica 05 either

Seems to boot REALLY quick now?

 

[antipunk]

Same here, been smooth as butter.

Sent from my LS670 using Tapatalk

 

[sfhub]

Ok, no USB notifications going off and it appears to charge fine.

 

[picasticks]

Seems to boot REALLY quick now?

Well the zImage is down to 2.2M in size vs 2.4M for 05 so that probably shaves a few ms off of boot time. Since this is the smallest kernel I would guess that it boots the fastest. With the debug stuff gone from the LG kernel it's less to copy into memory.

Sounds like this new kernel is a winner. I guess I will rebuild it as 06 unless anything pops up.

 

[picasticks]

Ok, no USB notifications going off and it appears to charge fine.

That's good. Still weird that we both had USB notification issues and then they mysteriously went away but I'm not losing any sleep over it.

 

[zefie]

Hmm, alternate toolchain.. now you are becoming less like LG kernel and more like competition kernel

just kidding lol

 

[sfhub]

That's good. Still weird that we both had USB notification issues and then they mysteriously went away but I'm not losing any sleep over it.

With more info, I'm of the opinion the USB notification was not directly related to pica. I swapped back to the stock kernel using a nandroid restore and upon first boot had the USB notifications popping up (in my case, adb shell did get disconnected) I thought it might be the cable, but when I jiggled the cable it really didn't elicit a direct response. Once in a while it might disconnect, but it usually wasn't related to the jiggling. Most of the time it was just disconnecting on its own with no pressure on the cable.

Then I rebooted the phone and the problem just went away all by itself.

So I think when switching kernels something is slightly off with the USB and that gets fixed with a reboot.

 

[jstntp]

Hmm, alternate toolchain.. now you are becoming less like LG kernel and more like competition kernel

just kidding lol

Ahhh!! A good old fashion kernal battle. LOL!!!!

Sent by Tapatalk ----- Optimus s

 

[picasticks]

Hmm, alternate toolchain.. now you are becoming less like LG kernel and more like competition kernel

just kidding lol

Haha! Well since no one is reporting any issues with current version I am ready to put a bow on it and rest until LG upgrades its VD to STD or whatever.

The CodeSourcery G++ Lite turned out to be just a drop-in replacement for the Froyo platform NDK one. Literally all I did was untar and point to gnu-eabi- to the new dir ... if compile had failed or phone had gone wonky not sure I would have bothered to debug.

Actually there a bunch of assembler errors that worried me, but the relevant code all looked fine and in the end no problems with the kernel.

zefie, I am curious if you are doing anything with compile flags specifically for the VFP? I did a compile with -ftree-vectorize to do auto-vectorization and there was no problem, but did not do fast-math or anything FPU specific. Our chip has limited SIMD support from what I understand but no NEON. Sorry if that's kind of a vague question but it's been a week since I was playing with this.

 

[zefie]

Haha! Well since no one is reporting any issues with current version I am ready to put a bow on it and rest until LG upgrades its VD to STD or whatever.

The CodeSourcery G++ Lite turned out to be just a drop-in replacement for the Froyo platform NDK one. Literally all I did was untar and point to gnu-eabi- to the new dir ... if compile had failed or phone had gone wonky not sure I would have bothered to debug.

Actually there a bunch of assembler errors that worried me, but the relevant code all looked fine and in the end no problems with the kernel.

zefie, I am curious if you are doing anything with compile flags specifically for the VFP? I did a compile with -ftree-vectorize to do auto-vectorization and there was no problem, but did not do fast-math or anything FPU specific. Our chip has limited SIMD support from what I understand but no NEON. Sorry if that's kind of a vague question but it's been a week since I was playing with this.

check the Makefile in my git both in the root and in arch/arm/

 

[picasticks]

check the Makefile in my git both in the root and in arch/arm/

Will do, thanks!

 

[picasticks]

posted 06

I updated the top post with picasticks-06.zip.

If you are using the 05-cs2 test kernel, it is identical. So, sorry if I've wasted your time and gotten you call excited about a new kernel!

I just thought that since 05-cs2 had no reports of any bugs, and since it's what I've actually been running for the last 4-5 days, I might as well declare it "stable" so that if any new bug reports come in I'll be able to reproduce them on my phone.

Original version 05 has had no reproducible bugs that I know of (sfhub and I tried reproducing USB notification bugs we thought we had, but they mysteriously disappeared) so hopefully this version is in good shape as well.

 

[dgreenmann]

Hey all!! I was reading through this thread and noticed that majority of the users of this kernel have thunderom in their signature, so is this comnpatible with aosp or scott pilgrim rom