Related
Hey guyz, you should look at this, f*** u se ¬¬
best reply from page 2 of the thread linked above:
kernelzilla said:
It's entirely far fetched, as OP is trying to correlate something that isn't the cause.
The only thing he's proven is someone typed make oldconfig or make menuconfig, there is usually no indication of source code changes in the .config, outside of new kernel config options that may be in the running kernel vs provided defconfig (did you even check? no). The fact that you didn't even mention looking at the actual kernel build timestamp in /proc/version tells me you don't really know what you're doing, it's not in the .config...
Are there any modules that exist on stock but aren't available for compilation from source? Are there any kernel modules that are exporting tainted symbols? (i.e. is /proc/sys/kernel/tainted 0?) That would rule out any use of proprietary or missing modules. Do any of the stock modules export newer versions or kmsg info that isn't in the source? I highly doubt you looked through the source this extensively.
Most production kernel development cycles I've been a part of involve a period of code freeze before the final release. Usually during this period only absolutely show-stopping bugs are fixed and things like debugging and factory/test hardware modules are removed. It is likely that this is what happens at SE.
Do you really think they put relatively untested code in the kernel during that 5 day period from source finalization and production build? Any changes, especially the security measure you speculate were put in, would require extensive testing. Judging by the contributions that SE has provided in AOSP, they test their software and hardware for compliance more than the average vendor. It's illogical to me to assume they've snuck some code in when they spend countless man-hours doing testing and QA.
This type of speculative witch-hunt makes the community look bad, not SE. You need to provide factual evidence of a license violation, not .config file changes.
Click to expand...
Click to collapse
Good morning all!
I haven't received my viewpad 7 yet (it'll arrive tomorrow), but knowing my luck it will be hardware version 107 (I'm in Canada). So I've been doing a little research. I know the tj_styles' overclock kernel will not work with the ITE hardware, but how about something like this:
http://code.google.com/p/milestone-overclock/wiki/KernelModule
The link points to a motorola omap kernel module that sets the cpu frequencies at runtime. This means there is no need to have the kernel sources (or in this case the ITE driver sources). To quote from the wiki...
"The module has an interface in /proc/overclock/ that allows enabling and disabling of overclock in runtime without rebooting. It works by changing several parameters directly in kernel memory to fool both CPUfreq and its lowlevel OMAP driver."
Anyways... it has been a long time since I dev'd anything (think Commodore 64 and GEOS)... But I thought it interesting enough to point out. And maybe there is a dev out there able to tackle this. Or better yet, maybe there is a dev out there who can warn me off this. I'm gonna' give it a try... but I'm back to school next week (teacher, not student). We'll see how it goes.
any news on this?
This might be usefull. Only just now saw this post. I'll look into it, but it looks like there should be little risk in trying this yourself, as long as you have an idea of what you're doing.
NEW OC/UV Kernel
Hi!
There's a new kernel in the developement forum. But no ITE-Hardware support.
I have tried it but it doesn't work for me. What can we do next?
Any more news on this? anything to encourage ITE rom building would be great!
Anyone put any thought into working on tweaking/refreshing a gingerbread/CM compatible kernel for the Optimus V?
Seems like most of the Gingerbread work people have been doing is based on modifying ROM packages by rebranding someone else's work. I'd feel more satisfied actually helping said ROM developers by delving into uncharted territory of the kernel in lieu of ROM work. I'm sure I'm skipping steps and should be tinkering with a ROM first and leave out kernel work but it seems like most people are focused on repackaging the ROM with their own branding. Don't get me wrong- I think it's great- but aosp and now blarf are the Optimus V un(official) ROM developers and I think it'd be interesting to work on potential kernel tweaks for the gingerbread ROMs.
Is this over my head? Yes. It'd definitely be baby steps. I'd be starting from scratch on understanding git version control, merging changes from other sources into the LG sources, the life of a patch, working with others. If anything I'd be proud if I could understand kernel structure, compiling, git management, working with others on it, and eventually if I could make a single improvement to the kernel I'd be more than satisfied.
Anyone have thoughts, interest, expertise or willing to work on such an endeavor? I figure it'd be a lot of dumb questions and trial and error but in the end I feel I'd be making some good, geeky online friends.
I think I had my first successes by simply compiling the thunderc kernel from blarf's github project android_kernel_thunderc.
links:
android_kernel_thunderc github page hosted by Inferior Human Organs based on LG kernel
Code Aurora - source for Qualcomm specific kernel changes. Our phone has a Qualcomm 7627 chipset
LG-P500-2.6.35-re-write - github page of the freakish kernel tinkerer FrancisoFranco. I wouldn't know where to begin but he's bent on inking out performance and battery on the Optimus P500. The P500 uses a different Qualcomm chipset but his work is a good reference for the potential of what can be done to the kernel (if we could figure out what he's doing and if anything could do anything for us)
Building Kernel from source- cyanogenmod wiki
A howto for setting up the build environment and getting through a compile from Android Central
I'd figure it could start with a step by step of getting a build environment set up, then working with git, compiling your 1st kernel from Optimus V sources, and then from there who knows. In the end we could shave a millisecond off of some random thing in the phone, save 5 minutes of battery life or simply end up with a pile of dung. Or it could turn out to have a few mind blowing tweaks that make our lil phones do something awesome.
If anything you can tell me I'm retarded. That's an acceptable answer as well
a suggestion.
nand flash memory in the phone has a limited lifespan.
testing kernels happens over and over and over and etc...
fastboot is really cool.
you can use it to boot a kernel+ramdisk or a complete boot.img without flashing into nand.
Code:
fastboot -c "command line" boot zImage ramdisk.cpio.gz
or
Code:
fastboot boot boot.img
substitute the appropriate command line into the quotes (pretty sure the quotes are required) and change the other filenames as needed.
a nifty side effect is that a reboot, battery pull, or crash boots back into your regular boot.img
The recent changes on that github page are a no go. Only stuff up to "Smartass2: improved code" are good to use. Other than that small remark I think it's a good idea and it will give you a lot of knowledge.
You can post here any questions you have about git, compiling, errors etc, I'll be more than happy to share my acquired knowledge for your project to succeed
Francisco- first simple question. What real world gains are you seeing with your mods on the P500 kernel? I can't really visualize much going from people's linpack scores and whatnot on your kernel threads.
another ignorant question: In your opinion what would be the best approach to porting over your kernel to the Optimus V. Can some be a matter of replacing our stock files with your files? I'd assume some would be digging into lines of code. It sounds like it'd be just as difficult trying to brute force taking the Franco kernel and trying to get it to compile for our phone's chipset.
question:
when I build the optimus s 2.6.35 kernel (same board hardware as the optimus v,) and try to use it with any rom (it even works with the stock froyo rom, but has the same issues as with cm7) the suspend/resume (early suspend/late resume) shows up in dmesg, but the screen on doesn't show up in the dmesg after the resume 90% or more of the time when I press a key to wake the device.... the backlight comes on but the screen stays off. with working older 2.6.32 kernel, dmesg shows device turns screen and touch on with resume.
display works fine until sleep. then it tends to stay turned off; but logcat, dmesg, and adb all show device is still working other than screen turned off. the backlight and button lights work as expected on suspend/resume.
any suggestions for trying to track this down?
I looked at:
kernel/power/main.c (added asynchronous suspend)
kernel/power/earlysuspend.c (no changes)
kernel/power/wakelock.c (no changes)
arch/arm/mach-msm/pm.c (changed NR_CLKS to MAX_NR_CLKS)
and didn't see anything that looked like it drifted too far from 2.6.32
perhaps I just wasn't aware of what I was looking for and need to look at something else, like the video drivers?
<edit>
nevermind, the screen does come on sometimes and definitely turns off, so the kernel functions are probably ok and it's just getting bad input from the rom.
Well I'm officially lost on what the best approach would be to get the Franco kernel on the Optimus V or if it even offers much gains.
Hi there,
I'm a programmer and formerly worked for one of the major Android handset developers as a platform engineer. When we developed the devices, we had separate build configurations and tools for kernel and platform, and built them separately... I rarely had any issue in building a new kernel for a platform, or building a new platform and using it with an old kernel.
That being said, what is the present difficulty that is being run into with using what should be a fully-functional GB kernel (incl. graphics drivers) with the ICS or JB platform? I am genuinely curious on this mark - if you are using the original kernel and drivers, I would imagine you should have full functionality (as they expose at least OpenGL ES in a consistent manner).
If you reply, please don't water down your comments - I'm a kernel developer myself (though not for Linux), so I appreciate and look forward to technical jargon.
"GPU Acceleration" (Hardware Acceleration) I'd imagine would be handled via the OpenGL interface libraries that come with the driver... that's what I'm asking: why can't the Gingerbread ones be used? What specifically prevents it from working? What's preventing you from modifying the ICS/GB platform to be compatible with "less-featureful" drivers?
As I said, I used to do this professionally, and am a professional programmer, so I'm looking for specifics.
AmeiseMike said:
What's preventing you from modifying the ICS/GB platform to be compatible with "less-featureful" drivers?
Click to expand...
Click to collapse
Nothing. And that's exactly what the devs have been doing so far. The result is well known to everyone - an almost perfect system that's lacking true HW acceleration in certain areas. Modifying and adapting can only get you so far.
I'm no expert so I won't pretend to be one, but as far as I know it has something to do with the newer nvidia drivers (that support proper HWA) which are proprietary binary blobs and have only been released for kernels newer than what we have. So we have a working kernel with semi-working adapted drivers, or true proper drivers with no kernel to use them on. And that's exactly where all the current porting efforts are directed - making a working kernel for the Atrix that's recent enough to make video drivers useful. In fact, since you say you have quite some experience with kernel development, you might consider joining the team, I'm sure they can always use any help they can get.
You could theoretically use existing drivers from kernel space, but they are not compatible with ICS.
Another option would be to ask nVidia nicely for drivers then build a new kernel, not forgetting two dozen other neccessary drivers, too.
OR, you could use a newer kernel with drivers that are compatible with ICS and which includes better handling of resources.
Option one will be adequate for Honeycomb. Hardware acceleration was first introduced in API level 11 (Honeycomb) and the XOOM was horribly buggy and slow with the old kernel.
Option two will never happen for various (obvious) reasons. For hardware acceleration to work properly you need nVidia drivers which require a 3.0 kernel.
Option 3 is something that a few in the Atrix community are working on.
My question, though, is why are said drivers incompatible with ICS/JB? What has changed that has rendered the platform incompatible with the previous drivers? If 3d Hardware Acceleration worked in GB, why can it not be used within ICS/JB (which should only care about GL ES, which hasn't changed)? If a feature of some sort has been added in ICS/JB that has caused the incompatibility, why not disable it? Features that had worked shouldn't be rendered inoperable unless a binary-level incompatibility exists, and I can't fathom why one would when you have platform source (via AOSP).
That is a question i'm afraid no one other than nVidia can answer. Why do their HA drivers require a 3.0 kernel is the question to ask.
---------- Post added at 10:37 PM ---------- Previous post was at 10:34 PM ----------
What existing HA in GB are you referring to?
integraletotale said:
That is a question i'm afraid no one other than nVidia can answer. Why do their HA drivers require a 3.0 kernel is the question to ask.
---------- Post added at 10:37 PM ---------- Previous post was at 10:34 PM ----------
What existing HA in GB are you referring to?
Click to expand...
Click to collapse
OpenGL ES 1 and 2 fully function on Gingerbread (and are accelerated, that is, not rasterized by something like Mesa). These are components of the GPU driver, more specifically the GLES interface libraries. I don't see why those are rendered incompatible.
That stretches beyond my knowledge of what is made available by the driver, so, I really don't know. I'd greatly appreciate you taking a minute to review progress being made on github. Links in the development section of this forum in the thread mentioned earlier.
To put it into a different context (approaching it a different way), have any other OSen such as Ubuntu been ported to the Atrix, using the kernel, and having 3d HWA?
Not sure if it's useful information or..... but from what I've read even the GB kernel used by Motorola for the Atrix was just a cobbled up rush job based on a Froyo kernel..
So the ROM developers here have a steeper hill to climb than you thought.... Making ICS/JB ROM's operational from basically a patched Froyo kernel
I once got Honeycomb working on a Froyo device (don't ask), including HWA... without any kernel changes.
My suspicion is that maybe people are unwilling to hack up the platform to work with the drivers as they are? So long as there are drivers that have supported HWA, there's no reason that they shouldn't be able to continue to do so, you have to alter the platform so that it can. ICS/JB internally will look a bit more like GB afterwards, but many of ICS/JB's improvements were in the realm of expanding what used HWA (which already existed) and improvements in their multithreading code, neither of which should require anything that's not already there.
EDIT: I'd point out that I'm speaking hypothetically. I don't know what the actual issue is, hence why I'm probing for specifics .
Are there any developers around who might be able to shed light upon this for me?
Hi,
What eaxctly do you need this information for? Are you working on porting Ubuntu Touch on the Atrix?
AmeiseMike said:
Are there any developers around who might be able to shed light upon this for me?
Click to expand...
Click to collapse
here's a link http://forum.xda-developers.com/showthread.php?t=2016837 , maybe you'll get your answer there
I'm not sure what that link has to do with my original question? I'm aware that attempts for porting other kernels are being undertaken, what I am wondering is why it's necessary (and not a vague 'because x and Y require a new kernel, but specifics).
AmeiseMike said:
I'm not sure what that link has to do with my original question? I'm aware that attempts for porting other kernels are being undertaken, what I am wondering is why it's necessary (and not a vague 'because x and Y require a new kernel, but specifics).
Click to expand...
Click to collapse
You asked are there any developers around who might 'shed some light' on your question. There's only a handful of developers left and the link takes you to some of the most current ones. You can also check out the others in the Development section.
What exactly do you need this information for?
To see if there's an alternate route towards porting newer versions of the platform to the phone (as I said, I've ported platforms to older kernels before when I was employed by one of the manufacturers), and as a hobbyist forking Android and porting it to my phone (which is an Atrix).
I'm just very confused as to what the problem is that necessitates a new kernel; I didn't have any issues like this when porting platforms before - I merely altered the platform so that it would work with the older drivers (sometimes that required disabling newer functionality, but functionality that worked beforehand was still there).
AmeiseMike said:
To see if there's an alternate route towards porting newer versions of the platform to the phone (as I said, I've ported platforms to older kernels before when I was employed by one of the manufacturers), and as a hobbyist forking Android and porting it to my phone (which is an Atrix).
I'm just very confused as to what the problem is that necessitates a new kernel; I didn't have any issues like this when porting platforms before - I merely altered the platform so that it would work with the older drivers (sometimes that required disabling newer functionality, but functionality that worked beforehand was still there).
Click to expand...
Click to collapse
Instead of asking, why not try and do it and see for yourself.:good:
Because I'm not interested in potentially bricking / rendering unusable my phone if there's a known good reason why it can't be done.
just a odd idea I thought I would share
I wonder if its possible to patch a kernel on load using safestrap
I am wondering if maby we can hex-patch the DVFS table at execute to at least gain some overclocking
I read the kexec thread but the consensus there is that development is stalled waiting for a breakthrough
thoughts :fingers-crossed:
Legitsu said:
just a odd idea I thought I would share
I wonder if its possible to patch a kernel on load using safestrap
I am wondering if maby we can hex-patch the DVFS table at execute to at least gain some overclocking
I read the kexec thread but the consensus there is that development is stalled waiting for a breakthrough
thoughts :fingers-crossed:
Click to expand...
Click to collapse
You can overclock via module sure, hex patch prob not needed.
Surge1223 said:
You can overclock via module sure, hex patch prob not needed.
Click to expand...
Click to collapse
hrmmm.... you talking about patching the dvfs kernel module or writing a custom module ...
if so I am surprised nobody has done that yet ..
is hex-patching from safestrap at all feasible ... it would grant you the 'keys' to all manner of "doors"
I used to fiddle with it on my cheap mk808 tv stick before we had kernel sources
I am surprised nobody has used kmodule's as a "attack vector" people seem to be chipping away and the Mountain that is kexec instead of just focusing on patching the issues we have with the stock kernel .. . a few years ago somebody was doing hex patches to implement kernel changes on the first generation of rockchip powered "tv sticks" the same logic should apply here
then again maby I have just been out of the game for way to long ....
*continues pondering*
Legitsu said:
hrmmm.... you talking about patching the dvfs kernel module or writing a custom module ...
if so I am surprised nobody has done that yet ..
is hex-patching from safestrap at all feasible ... it would grant you the 'keys' to all manner of door if it was
I used to fiddle with it on my cheap mk808 tv stick before we had kernel sources
I am surprised nobody has used kmodule's as a "attack vector" people seem to be chipping away and the Mountain that is kexec instead of just focusing on patching the issues we have with the stock kernel .. . a few years ago somebody was doing hex patches to implement kernel changes on the first generation of rockchip powered "tv sticks" the same logic should apply here
Click to expand...
Click to collapse
I have dabbled with this, using a custom module based on the 8660 overclock module I found source for somewhere. The reason kexec is so much more desired then fixing the current kernel is because patching the current kernel might give us more io schedulers, overclock, custom governors etc, but at the end of the day all that crap isn't worth much on the poor excuse for android ui known as touchwiz.
Idk about you but I can tell you I for sure would not want to post a thread on overclocking or modifying cpu via modules in this day and age of 'the entitled xda user'. Maybe that's why you don't see any threads.
You bring up a good point about how people don't understand the various uses kernel modules can provide including but not limited to being attack vectors (though to some degree this is being done with kexec).
Surge1223 said:
I have dabbled with this, using a custom module based on the 8660 overclock module I found source for somewhere. The reason kexec is so much more desired then fixing the current kernel is because patching the current kernel might give us more io schedulers, overclock, custom governors etc, but at the end of the day all that crap isn't worth much on the poor excuse for android ui known as touchwiz.
Idk about you but I can tell you I for sure would not want to post a thread on overclocking or modifying cpu via modules in this day and age of 'the entitled xda user'. Maybe that's why you don't see any threads.
You bring up a good point about how people don't understand the various uses kernel modules can provide including but not limited to being attack vectors (though to some degree this is being done with kexec).
Click to expand...
Click to collapse
ill be the first one to admit I haven't keept up on this stuff simply because the effort started outweighing the gain
it just seems to me that people are chasing clouds ... with kexec the possibility of getting it working is basically nill due to lack of debugging information so why not attack something you can debug such as a kernel module hell in theory it should be possible to add io schedulers and governors via a module hell with a properly 'crafted' module we may even get kexec(kgraft?) as a result if you could create a exploit you could use to the proper effect ..
I agree that touchwizz is utter poo and should be stabbed with white hot knives and buried under 12ft of cement but the phrase "if life gives you lemons ... make lemonade" rings to mind ...
I am sure somebody will give me the usual speech about "if you are so smart do it your self" but sometimes people just need to step back and look at it another way .. + I am fighting insomnia and am on my third shot of jack ...
wow did I really write all that jesus ... no more jack for me at 12 am...
Legitsu said:
wow did I really write all that jesus ... no more jack for me at 12 am...
Click to expand...
Click to collapse
Lol. At least your question is a good topic of debate. Most questions and posts in our forum are boring to me but this isn't, so there's that I guess.
Surge1223 said:
Lol. At least your question is a good topic of debate. Most questions and posts in our forum are boring to me but this isn't, so there's that I guess.
Click to expand...
Click to collapse
realistically you probably could't alter to much but adding overclocking a variety of minor tweaks could be done in hex
on a personal note I would be content with figuring out how to get some overclocking/undervolting done
Legitsu said:
realistically you probably could't alter to much but adding overclocking a variety of minor tweaks could be done in hex
on a personal note I would be content with figuring out how to get some overclocking/undervolting done
Click to expand...
Click to collapse
When you reply to me, you realize you are actually continuing your thoughts and not actually replying to me right?
Surge1223 said:
When you reply to me, you realize you are actually continuing your thoughts and not actually replying to me right?
Click to expand...
Click to collapse
Lol I am just rambling feel free to ignore me lol
board software here is a bit odd
*deleted tired*