I want to recompile the G1 dev phone linux kernel, to make it run faster. And i need to know which kernel is recommendable? I need to know how to build it with modules and once built, where i have to put it in the phone?? do i have to make some update.zip? do i have to do somehing with test keys?
Im experienced compiling kernels for my laptop, i also cross compiled some kernels before,and i promise i will be easy to put in the right direction, but i need some advice on how to do it, so that way i wont spend hours and hours sneaking around and figuring things out.
I noticed my kernel is compiled with -s (optimized for size on disk) instead of -O2 (optimized for speed)
I know kernels compiled for size are noticeable slower, and i dont want a slower kernel just for saving 1Mb of space on the phone, i also liked to deactivate all of the "debug staff" wich also slows down the phone and i dont need it. And all of this could affect positively to converve battery. But i also like to keep JF staff, i downloaded JF build environment but i dont understand what to do with it.
I im runnning linux debian and followed the steps to set up arm compiler + android.
I did repo sync and it downloaded lots of stuff from google git, and i saw different branches, master, 1,0 1,1, cupcake, 1.43, 1,50, donut. I supose the most stable is master? what about 1,50 ?
should i get the kernel config from my G1's /proc/config.gz or just a make ARHC=arm msmconfig ?
This is all bad, all i want is a stable -O2 kernel with JF modules.
knowledge is a damn, if i didnt knew i wouldnt be wasting time with something healthy people never do.
please give me some advice
* Kernel Newbies
* LWN article on merge: the KN post says the "ashmem" part did get added after the article was published.
* Kernel 3.3 source
From the assorted news stories online over the past few weeks, it would seem that this is core functionality: but assorted drivers and power-saving stuff would still need to be added back in.
Thats a great news
Sent from my GT-S5830 using xda premium
So what are the benefits of this? Linux distros support a wide range of x86 hardware where as Android x86 has limited driver support. Would we be able to get Android out to more x86 hardware with this? Also will this make the Ubuntu on Android project easier to port since the kernel could be shared between the two.
I think the key part here is to streamline use of the kernel for future projects. Current Android kernel use is way behind mainline; with stuff having to be backported and adjusted for CPU type.
Zalitoh
This Kernel is interesting
Hi.
Anything new with the 3.3 kernel ? I mean, maybe Cyanogen will start building on the linux kernel ?
Anyone knows ?
Hello people,
after some conversation with early ICS-on the transformer developer paulburton, I have a git repository of a mostly working linux 3.1 mainline kernel with some patches from paulburton to make it actually work.
Icluded are (as of now) :
improved atmel mXT1386 touchscreen driver
tegra_v4l2 camera driver
ov5640 soc camera driver
prox_lds6202 proximity sensor driver
fm34-500 voice processor driver
asusec keyboard driver (for dock)
al3000a ambient light driver
The purpose of this is not to port things back from some linux 3.X kernel to our 2.X kernel, but to have a fully working 3.X source tree some day, from which we could port to further linux versions in the future. This can also be helpful if we want to port android 5.X in the future.
The github is at https://github.com/skirata/linux/tree/android-tegra-tf101-3.1 .
(It's my github, if someone wants to become a collaborator, please let me know, I'll add you to the collab list.
WE NEED EVERY DEVELOPER WE CAN GET.
I will spend some time on this, but I think I can hardly finish this project on my own.
Totally support this, looks promising!
Thanks for the initiative.
Are you and guever working on this together? I can test and maybe help make aokp or megatron versions.
Sent from my Transformer TF101 using Tapatalk 2
Of course I'm willing to work, you know I've helped all I could.
My kernel has much of the code updated to 3.1, so may be we can use much of it.
This can be done in two ways, by modifying the code in paul whatever it takes, or modify mine. I have nothing clear which will be easier, because over time I have made several test on my code and unfortunately, when the kernel does not boot can not be debugged, so you have to turn back.
Until wednesday I will not be able to devote almost no time, so I think the first thing would be to check the operation of the kernel of paul (if not already done) with a current rom.
It is possible that the graphics drivers (most are binary system level) may not work with that kernel.
Well, it is what I think, that first we must see is what should be changed in the kernel to function properly (or whether to change the rom).
Teamwork is how it's meant to be done.!
I will setup a working kernel konfig in the next days to push this a little forward.
at Guevor :
I'm adding you in as a collaborator so we can work together on this.
Let's improve paulburton's drivers and add new ones based on latest nvidia images.
The advantage of upstream-porting rather than downstream-porting is we can port future kernel versions more easily with own written drivers.
Also, android 5.X porting will be a lot easier, as I think it won't support 2.6.X kernels at that time. And even if it would, we can have a massive performance boost if using 3.1 mainline kernel with improvements all over the world.
Glad to count you in, guevor.
I owe you so much already.
EDIT : Just in case, be sure to use the 3.1 branch of the linux repository, as the master branch is forked from torvalds (linux 3.4.X) and will get some love when we get the 3.1 kernel to work as good as we are satisfied.
Well, the main problem I see, thinking about future versions (5.x) is that we do not have the source code for video drivers, only a small part that exists in the kernel. This added to the fact that nvidia does not provide (at least I do not know) the binary drivers for android (as they made for linux), I think that may be, we do not see tegra2 drivers for 5.x. That does not mean we can not do something, but will be less optimal and more complicated.
Hopefully I'm wrong and nvidia make things easy , but I think no manufacturer will use tegra2 for new products, and do not think they will update current products to that version ....
guevor said:
Well, the main problem I see, thinking about future versions (5.x) is that we do not have the source code for video drivers, only a small part that exists in the kernel. This added to the fact that nvidia does not provide (at least I do not know) the binary drivers for android (as they made for linux), I think that may be, we do not see tegra2 drivers for 5.x. That does not mean we can not do something, but will be less optimal and more complicated.
Hopefully I'm wrong and nvidia make things easy , but I think no manufacturer will use tegra2 for new products, and do not think they will update current products to that version ....
Click to expand...
Click to collapse
Have you tried contacting Nvidia about this?
For the record, I am not a Linux user, even with what Im going to say, keep that in mind... My history is firmly routed in WinBlows land!
This has me all sorts of excited, I remember saying it back in paul's thread before it fell off the face of the earth (read, first few pages of the forum).
As stated at the top, while NOT a Linux user, I was trying to build CM9 for one of my tablets, to do so, I had setup a Linux box (tried a few distro's), and kept having issues, so a friend of mine walked me through updating to a 3.4.x kernel (3.4.0.-5 iirc), and things definitely FELT smoother vs the 3.0 (on the distro I was using before he berated me for it and moved me to a different one) and then 3.2 kernel in use (ill note hardware issues where also at play with the actual issues, but the smooth feeling after updating was definitely something I noticed).
I have no benchmarks or performance statistics to back that up, but as I said in paul's thread, and have now experienced in a "full" Linux environment, the future with Kernel v3.1 and up has me VERY excited as to what can be done with the OG Transformer! (vs mass backports to 2.x)
On that note, Subscribed thread, and time to get an RMA for my Tablet... the top basil part is starting to come off the unit
I haven't coded a lot with linux and android source, but I do have experience with coding and especially with reading through source code and finding syntax and other errors i.e. proofreading
So if you want me on the team I'm game!
Orkeren said:
I haven't coded a lot with linux and android source, but I do have experience with coding and especially with reading through source code and finding syntax and other errors i.e. proofreading
So if you want me on the team I'm game!
Click to expand...
Click to collapse
Every help is welcome !
Please tell me your github name and I will add you as a collaborator
If my help is welcome i am willing to test your builds on my TF101G B90 with dock. So let me know if you have to do something.
ajohn117 said:
If my help is welcome i am willing to test your builds on my TF101G B90 with dock. So let me know if you have to do something.
Click to expand...
Click to collapse
Will do for sure, but it could take some time until we can push out the first build for testing.
rayman33 said:
Hello people,
after some conversation with early ICS-on the transformer developer paulburton, I have a git repository of a mostly working linux 3.1 mainline own.
Click to expand...
Click to collapse
With my git every things works but usb hotplug,cam,hdmi-audio. ( usb works fine when insert add boot ) , also i will stop dev for it as i'm selling my tab :crying: but would be nice if this got finished.
also major thanks to paul
Do you started the project?
I tried some things yesterday, but it did not boot. I will have a look into spark rom and try some other things, I think I have some ideas.
Btw, kernel compiles fine, zImage is there, perhaps some early device drivers have to be updated. I will look into the ramdisk I created and fix some things ...
Just to let you people know. Progress is being made.
First progress
I managed to make it boot on revolver 4.1.1 rom. I modified the video drivers to be compatible with the actual binary drivers.
The touch screen is not working, but I really have not looked at it, maybe even compile options I chose are not the most adequate, but just wanted to get it to boot with video graphics working.
We better get each other updated via pm in the future ..
What touchscreen driver did you define in the kernel config ?
The new mxt1386 or the old one from the 2.6.39.4 kernel?
Maybe we need to rewrite the mxt1386 drivers.
rayman33 said:
We better get each other updated via pm in the future ..
What touchscreen driver did you define in the kernel config ?
The new mxt1386 or the old one from the 2.6.39.4 kernel?
Maybe we need to rewrite the mxt1386 drivers.
Click to expand...
Click to collapse
Well, I tested whether simply boot and graphics drivers failed as expected, and I've tried to change it and make it working. I think that is the basics (make it boot) to further adjust problems.
About the drivers, yes, I used mxt1386 but not detected coordinates, just click. I used a USB mouse to verify that the graphics drivers work.
I updated the repository with my changes.
Did you get a log cat already ?
It may reveal if the mxt1386 driver fails to load.
rayman33 said:
Every help is welcome !
Please tell me your github name and I will add you as a collaborator
Click to expand...
Click to collapse
easy as pie!
Code:
orkeren
All,
As most of you are aware, I've been slowly chipping away at porting open source apps/libs to Windows RT when I can. In an effort to encourage more people to port things (and comply with licensing requirements), I've decided to put all the source code changes I've made on Codeplex.
You can find all the of the source code and binaries for the apps/libs I've worked on here:
https://windowsrtdev.codeplex.com/
Please read the notice on the front page. I hope some of you find this useful.
Keep in mind that I do this in my spare time so I haven't had a lot of time to keep things clean. So I apologize for the various quick hacks and lack of documentation. Speaking of documentation, I'm going to look at typing up some kernel driver porting notes. I've successfully ported a few drivers (not in the SVN repo yet) without requiring the WDK and I've worked out a several of the kinks in the process -- so I'll try to share that soon-ish.
As always, I'm happy to field questions and help others when I can but please do not contact me to port apps. I generally only work on the apps that _I find useful_ and I've already started or looked at many of those.
Cheers!
EDIT: I've converted the codeplex project to git and have also mirrored the effort on github ( https://github.com/bfosterjr/windowsrtdev )
Much appreciated! Your work has made the whole ecosystem better.
GoodDayToDie said:
Much appreciated! Your work has made the whole ecosystem better.
Click to expand...
Click to collapse
Likewise man! I wouldn't being doing this without the support and encouragement of people like you and the rest of the XDA community. Props to everyone who contributes and especially for those that have contributed to the jailbreak! (clrokr and netham45 in particular!)
Just a question, how do you deal with porting these libs? I'm familiar with compiling stuff with GCC but I assume those tools still aren't available for WinRT?
Actually, it looks like the VLC for Windows 8 / RT / WP8 project is or will be releasing updates to MinGW (which uses GCC on Windows) to add support for targeting Windows RT. However, at this time, all of the RT-ported desktop apps that I'm aware of were compiled using Visual Studio or other Microsoft development tools.
ausshir said:
Just a question, how do you deal with porting these libs? I'm familiar with compiling stuff with GCC but I assume those tools still aren't available for WinRT?
Click to expand...
Click to collapse
Nope, GCC building for NT_ARM isn't there yet - but its coming. I managed to port the binutils a while back, but gave up on GCC because I couldn't devote enough time to it.
Most of the smaller libs are pretty easy to convert from makefiles to VS2012 projects. Just takes patience. Best thing to do is to build it using GCC/Mingw for x86, capture all the logs, then recreate the build using VS. I've ran into a few libs that were much more difficult ..and I just gave up. Sometimes you can also find others that have shared VS2005/2008/2010 solutions/project files and then just upgrade those to VS2012.
I've got some more libs I need to commit to the SVN repo - WxWidgets (i think someone else also did this) and Qt4. They're both pretty huge and took quite a bit of fiddling. I'm only one lib away (libeffi) from having a full build of GTK+ build for Window RT as well.. which will have a domino effect on another set of open source apps I'd like to port.
Cheers!
waiting for the qt4 port.So I can try mumble(voice chat tool)http://www.mumble.com/
windowsrtc said:
waiting for the qt4 port.So I can try mumble(voice chat tool)http://www.mumble.com/
Click to expand...
Click to collapse
I'll see what I can do about getting it up soon. Its a beast of a code base
bfosterjr said:
I'll see what I can do about getting it up soon. Its a beast of a code base
Click to expand...
Click to collapse
I've got an older version of Mumble running (A 1.2.4 beta), but I lost my codebase and didn't get around to posting it.
If you're interested in getting it running the main things I had to do were disable all SSE optimizations (It assumes Win32 has SSE) and disable the hooking system.
I am fairly new to the game so this might have been solved before or maybe a project somewhere is already working on it, but I'll ask anyways...
I want to build a version of Android that runs on glibc but also has the Android specific libs to run it's framework, system services, dalvik, etc...
So I have the source for both as well as the sources for gcc 4.8.2, I am thinking I need to eleminate from bionic what exists in the gnu side of things, and then add what is left in bionic and doesn't exist in eglibc or the stdc++ library in gcc to that, or maybe the other way around. And then write an Android.mk file to build it with Cyanogenmod-10.3 in place of bionic.
Thats my game plan and I am sure there are some holes in it, maybe I need to modify the NDK as well, and I am sure I need to change some includes through-out the Android sources, or maybe write some headers that wrap around the eglibc version of the functions, methods, classes, etc.. that are named differently but are basically the same function.
Mabye someone with a bit more experience in the field can shed some light on what they think about the above.
Any guidance, references, quotes, links, articles, insight, or advice?