I hope that _that will lead us in this topic because he seems to know away more than I do. I am here to learn and feel free to discuss anything that you like. No restrictions so we can get all the input from other users....
What is a toolchain?
After discussion with a few users, it is a mixed of toolchain types that they use.. According to my research, androideabi is targetting ROM build and optimize for the ROMs' binaries. It is fine when you use it to compile your kernel source but it is not optimized for the kernel compilation.
For kernel compiling, you should use the gnueabi toolchain because it uses the kernel's source for a specific kernel version during the toolcchain compiling for a better compatibility, I guess... However, some users reported that it was fine to use for ROM build also...
So the question is it matter what types of toolchains we are using? What are the benefits between the two? Does anyone see any difference between the two with users' experiences?
Here I will take this spot and fill it with useful info and links about what I have found on the web .... :good:
MythBusters XDA Edition: “Optimized” Compiler Toolchains
USING THE ANDROID TOOLCHAIN AS A STANDALONE COMPILER
ELinuxToolchains
The GNU Toolchain for ARM targets
ARM
lj50036 said:
Here I will take this spot and fill it with useful info and links about what I have found on the web .... :good:
MythBusters XDA Edition: “Optimized” Compiler Toolchains
Click to expand...
Click to collapse
It is great that you are joining the discussion because I have a lot of questions and some good optimizations while I tested with these toolchains. I will give what I know a long the way when the questions come up and hope we will have a better understanding what to use and not to use...
In the olden days, I used the 4.6.2 linaro toolchains and I have heard that a lot of people swear by DoomLord's prebuilts.
Just wanted to throw that out there. I personally have not tried anything above 4.7 yet but now I am tempted to
hardslog said:
In the olden days, I used the 4.6.2 linaro toolchains and I have heard that a lot of people swear by DoomLord's prebuilts.
Just wanted to throw that out there. I personally have not tried anything above 4.7 yet but now I am tempted to
Click to expand...
Click to collapse
Adding to your comment, I do see a performance improvement with different toolchains but some users said it is just a placebo...:crying: I am one of the trials and errors users with testing so nothing is going to stop me until proving by testing and users' experiences, haha...
BTW, I could not get the gcc-4.8/4.9 to work on our tf700 chipset yet because there are some graphical problems on linux kernel v3.1.10. I hope that someone can figure it out so we can test it...
There is a PAC rom in the TF300 forums that claims they are using SaberMod 4.8 without issues. http://forum.xda-developers.com/showthread.php?t=2501869
Furthermore there is a kernel (no longer in development it seems) in the TF300 forums that claims to use linaro 4.8 toolchains http://forum.xda-developers.com/showthread.php?t=2625580
hardslog said:
There is a PAC rom in the TF300 forums that claims they are using SaberMod 4.8 without issues. http://forum.xda-developers.com/showthread.php?t=2501869
Furthermore there is a kernel (no longer in development it seems) in the TF300 forums that claims to use linaro 4.8 toolchains http://forum.xda-developers.com/showthread.php?t=2625580
Click to expand...
Click to collapse
Thanks for the information...:good: I will look more into it when I have more time..
BTW, You should try the linaro toolchain for your kernel compilation but you should use the right kernel version that you intend to run. It is running very smooth... It takes less than 10 minutes to compile and test it out..
Cross Compiler Toolchains [Linaro GCC]
Hi,
Interesting thread but in my humble opinion should be in TF700's development section. So, I just used Christopher83's Toolchain for compiling _that's that10 kernel and flash it in CROMBi-kk RC3. As we have Tegra 3 Soc I used the toolchain with arm-cortex_a9-linux-gnueabi prefix which is optimized for Cortex-A9 cpu with Neon-VFPv3. I tested all the latest versions: 4.9 doesn't work at all (the TF700 was vibrating continuously!), the 4.8 had visual glitches but with 4.7 is working with no problems at all! Finally, from the same thread krislibaeer clarifies a bit the linaro prebuilt toolchains
here a little explanation:
arm-eabi toolchain: is for kernels
arm-linux-androideabi: is for rom building
so you use the arm-eabi toolchain for your kernels and the arm-linux-androideabi for roms
hope it helps a bit
so recommend is the arm-eabi toolchain for kernels
Click to expand...
Click to collapse
Hope that helps the discussion.
Cheers.
sziggins said:
Hi,
Interesting thread but in my humble opinion should be in TF700's development section. So, I just used Christopher83's Toolchain for compiling _that's that10 kernel and flash it in CROMBi-kk RC3. As we have Tegra 3 Soc I used the toolchain with arm-cortex_a9-linux-gnueabi prefix which is optimized for Cortex-A9 cpu with Neon-VFPv3. I tested all the latest versions: 4.9 doesn't work at all (the TF700 was vibrating continuously!), the 4.8 had visual glitches but with 4.7 is working with no problems at all! Finally, from the same thread krislibaeer clarifies a bit the linaro prebuilt toolchains
Hope that helps the discussion.
Cheers.
Click to expand...
Click to collapse
There are a few things that you need to pay attention to.
1. Neon-VFPv3 is for Cortex-a8 and not for a9. You may want to flag it as neon-fp16..
2. I believed that your toolchain is targetting linux kernel version 3.4.x or something but not for version 3.1.10.
3. I have the same issues with my owm builds gcc-4.8/4.9 without any solution.
4. Try some of -Ofast flag to see the improvement on v3.1.10
Good luck....:fingers-crossed:
LetMeKnow said:
There are a few things that you need to pay attention to.
1. Neon-VFPv3 is for Cortex-a8 and not for a9. You may want to flag it as neon-fp16..
2. I believed that your toolchain is targetting linux kernel version 3.4.x or something but not for version 3.1.10.
3. I have the same issues with my owm builds gcc-4.8/4.9 without any solution.
4. Try some of -Ofast flag to see the improvement on v3.1.10
Good luck....:fingers-crossed:
Click to expand...
Click to collapse
Just an FYI
I took the plunge and tried a new toolchain. Ended up trying a 4.9 linaro one for the Grimlock Kernel. Works like a champ on my TF300t. HOWEVER for some reason it will not even boot on a TF700. I'm told it vibrates and the screen goes all white or something. So here is the question:
Why would new toolchains work fine on a TF300 but not on a TF700? One of the transformers' great mysteries :laugh:
hardslog said:
Just an FYI
I took the plunge and tried a new toolchain. Ended up trying a 4.9 linaro one for the Grimlock Kernel. Works like a champ on my TF300t. HOWEVER for some reason it will not even boot on a TF700. I'm told it vibrates and the screen goes all white or something. So here is the question:
Why would new toolchains work fine on a TF300 but not on a TF700? One of the transformers' great mysteries :laugh:
Click to expand...
Click to collapse
Thanks for the information and very good quedtion....:good:
Here is my wild guess because the chipset is using in the tf700t, cortex-a9 t33... I checked the diffs on gcc4.7 and gcc4.9 and tried to match all libraries in hope that I could narrow down the bug but it was failed. There was one time that I succeeded boot into the tf700 with my compiled gcc4.9 and thought that I found the bug but if I rebooted it, it got back to the graphical issue, flicking screen... If I rebooted a few more times then the tf700 was working again. I did all my best to figure out the bug but it was a big failure at the end. That is how far it goes as of today... I don't know enough to solve the mysteries and hope that someone else will....:fingers-crossed:
LetMeKnow said:
Thanks for the information and very good quedtion....:good:
Here is my wild guess because the chipset is using in the tf700t, cortex-a9 t33... I checked the diffs on gcc4.7 and gcc4.9 and tried to match all libraries in hope that I could narrow down the bug but it was failed. There was one time that I succeeded boot into the tf700 with my compiled gcc4.9 and thought that I found the bug but if I rebooted it, it got back to the graphical issue, flicking screen... If I rebooted a few more times then the tf700 was working again. I did all my best to figure out the bug but it was a big failure at the end. That is how far it goes as of today... I don't know enough to solve the mysteries and hope that someone else will....:fingers-crossed:
Click to expand...
Click to collapse
Have you tried to compile a stock TF700 kernel with a 4.8 or 4.9 toolchain? I'm asking because _that kernel and Grimlock kernel actually change the cpu_speedo_id of the TF700 from 5 to 12
For reference check this commit: https://github.com/Hardslog/grimlock_kernel_asus_tegra3_unified/commit/50a19d0f6d6d03e6187a8fa7273be77755d72324#diff-c8f9ec2e1535a394abdd70e576a02ed7R160
I can only go so far with testing as I don't own a TF700........
hardslog said:
Have you tried to compile a stock TF700 kernel with a 4.8 or 4.9 toolchain? I'm asking because _that kernel and Grimlock kernel actually change the cpu_speedo_id of the TF700 from 5 to 12
For reference check this commit: https://github.com/Hardslog/grimlock_kernel_asus_tegra3_unified/commit/50a19d0f6d6d03e6187a8fa7273be77755d72324#diff-c8f9ec2e1535a394abdd70e576a02ed7R160
I can only go so far with testing as I don't own a TF700........
Click to expand...
Click to collapse
No, I have not but it is a good idea to try out. I have a few more days before leaving for two weeks... I will report back before the weekend, thanks again...:highfive:
BTW, have you try some -Ofast flags, not the -Ofast itself? Some of them are working very well with tf700 kernel..
Update: I don't have time to try your recommendation because I am preparing for my business trip. I will give it a test when I am back...
Related
Since it appears there is already a 2.6.29 porting github project I made one for the 2.6.27 kernel. This one is for optimizations.
http://github.com/chuckhriczko/heroc-kernel-optimized-2.6.27
bump.
while we don't have a 29 kernel, this is pretty important too. getting compcache and other stuff is also important
please update your BFS patch
jaysonking.com/bfs-2.6.27-backport/
feld said:
please update your BFS patch
jaysonking.com/bfs-2.6.27-backport/
Click to expand...
Click to collapse
This became a big mess as I was learning more about compiling linux kernels. I plan on rebooting this project soon. Been busy with a couple freelance projects so I havent had much time. Actually, if any devs are looking at this, any idea why BFS is giving me issues? The instructions say I should be using 2.6.27.35 which I assume this is not. But trying to patch it to .35 is giving me issues.
Hello guys n gals,
This is T-Mobile G2X version of my Harsh Kernel for O2X based on 3.0.y sources.
It share same tweaks and changelog with its international brother O2X.
This is my FIRST kernel based on sources of wkpark and vadonka.
This kernel is compiled by me, and comes with more added patches by me.
If you like it hit THANKS button.
Click to expand...
Click to collapse
All credits goes to:
armcee (CM7 & CM9 GOD of LG devices)
CM Team (You guys rock)
wkpark (ported kernel 3.0.26 to our devices)
vadonka (various kernel tweaks and awesome sources)
pastime (helping at various stages, and awesome fixes)
Owain (Biggest motivation for compiling 100 times a day)
and to everybody else who participated in making this possible.
Harsh Kernel P999:
Code:
Build from 3.0.37 sources.
Compiled using tweaked CodeSourcery arm Toolchain.
Better battery.
Default SIO scheduler.
Working Data Usage ICS.
Working Data Usage Limit.
Fixed USB tethering(windows).
And many tweaks.
Changelog:
Build 0510 Stock & OC
Updated Linux version 3.0.44 now.
Stock & OC version both uploaded to goo.im.
linux version 3.0.43 and 3.0.44 brings lots of changes (150+ commits hope good)
Still works for both JB and ICS both.
build 0509 Stock & OC
Compile zram as module (Thanks Benee)
Fix zram for dual core
build 0309 Stock
Linux Version 3.0.42
JellyBean[Heckfest] supported (thanks Benee)
build 0208 Stock & OC
Linux Version 3.0.39
Reverted various fixes which were implemented in 1907
Compiled with linaro toolchain on OS X
build 1907 NO-OC
Linux Version 3.0.37
Improves SIO scheduler for flash storage.
Added V(R) I/O Scheduler. (select if from AnTuTu CPU Master)
other various fixes (thanks to vork[benee] and faux123)
build 1006 Stock & OC
Linux Version 3.0.34
Patches from NVIDIA for cpu control (power saving)
Lowmemory killer from linux 3.4 ported by vork (thanks benee)
build 0306 Stock
Some patches from Benee (vork)
And tegra OTG try update.
build 2205 Stock
Linux Version 3.0.32
Re-enabled ext3 ability (fix unsupported file system problem)
Increased XZ compression usage.
build 1505 Stock & OC
Added Force Fast Charging patch by Chad Froebel
Lots of tegra related v21 source drop fixes, thanks to faux123
New wifi code change, from v21 sources
As usual few kernel config changes (still have to find minimum config )
build 0805 Stock & OC
Linux Version 3.0.31
Battery heat protection (thanks wkpark)
And few more kernel config changes
build 0405 Stock & OC
v21y battery driver (thanks vadonka)
too many kernel config changes (100s of changes)
pmem size reduced (let me know 4 mb change can make difference or not)
build 2804 No-OC
Linux 3.0.30 sources
First attempt for CpuSpy to work
build 2704 Stock & OC
rmcc's tegra_odm_touch: More ICS-compatibility
Catalin Marinas: Kmemleak patches
build 2504 - NO-OC
Updated to Linux 3.0.29
Scheduler Tweak
Scheduler multi-core support
build 2204
OC Version of Build 1904
build 1904
ZRAM compression changed from LZO to Google's SNAPPY (~2x faster)
ZRAM disksize set to 64mb
SNAPPY KERNEL
build 1504 - OC
Build from kernel sources 3.0.28
USB Mass Storage support for both SD Cards (ROM required to make it work)
XZ Compression, so even smaller size of zips.
OC Enabled upto 1.4 GHz
zram enabled and allocated
And many small changer that are not stated here.
build 1104
Lower TouchLED Brightness
Kernel refresh, compiled with new toolchain
build 0604
SD Card IO speed fixed (thanks again wkpark)
Nothing much, just some cosmetic fixes in code
build 0504
Using AnyKernel by koush (easy flash for all ICS roms.)
Added Voodoo again
Fajarep BL values (better battery)
build ReBorn 0304
upgraded Linux kernel source version 3.0.27
various MMC tweak and safepoints
pastime .config fix for support voltage unit in uV
build ReBorn 0204-1
fixed WiFi not turning on
WiFi was not loading up before, NOW FIXED
build ReBorn 0204
ReBorn: used clean wkpark's sources
added patches handpicked (new branch).
removed voodoo sound.
better bettery & speed
build 3003
proper suspend (wkpark original work)
build 2903
latest wkpark's merge fixes (thanks)
pastime1971's fixes
build 2703-1
latest wkpark's fixes he posted. (thanks again)
Fixed reboot issue
build 2703
some more kernel config changes.
pastime kernel pull fix.
build 2503-3
some kernel config changes.
spica1234 call quality improvement patch
Compiled with more hard flags, faster compilation.
build-2503
Updated to kernel 3.0.26 (thanks vadonka)
Added Simple I/O scheduler as default
and few kernel config tweaks
build-2403-4
Removed Kernel Debugs (further cleaning)
implemented hard float in order to reduce compile time
added ramdisk tweaks
build-2403-2
Implemented cache (first try to improve performance)
improved gps (source wkpark)
build-2403-1
Fixed Internal Storage problems(thanks to wkpark)
few compiling fixes, cleaner build.
build-2303
Initial sources.
Added usb tethering
Fixed Data Usage and Limit
Added Voodoo Sound
Selfcompiled linaro toolchain
Understanding build number:
build-ddmm-n
where dd=date, mm=month & n=compile number [start from 0/none]
Known bugs:
No HW Acceleration (Nvidia and LG at fault)
Reboot/Reboot recovery work 90% of time.
Download OC 0510 Link: Goo.im
Download NO-OC 0510 Link: Goo.im
My PIZZA suppliers (Donators, thanks a lot)
Owain van Brakel
Warren (djvoleur)
Gregory Martinson
Vu Phan
John(aragorn7)
sourcecode
Looks great!
Sent from my LG-P999 using XDA
zoppp said:
Looks great!
Sent from my LG-P999 using XDA
Click to expand...
Click to collapse
Thanks you. If you are on CM9 unofficial nightly, you can try it. I am out of thanks per day
Installed. Will test drive today.
Sent from my G2x running AOKP ICS Build 28
Is it overclocked?
Sent from my LG-P999 using xda premium
flak0 said:
Is it overclocked?
Sent from my LG-P999 using xda premium
Click to expand...
Click to collapse
No, its not overclocked.
Its on stock, will add overclock patch later, but defualt will always be stock.
Just for clarification: if hardware acceleration isn't yet included, what advantages are there to install this kernel over, say, faux's? Thanks.
GenghisKhan67 said:
Just for clarification: if hardware acceleration isn't yet included, what advantages are there to install this kernel over, say, faux's? Thanks.
Click to expand...
Click to collapse
Actually this is completely different kernel than faux kernel.
This kernel is not based on CM sources, it is based on kernel version 3.0.26, one of the latest in linux-3.0.y. If you guys know, Samsung Galaxy Nexus uses, kernel 3.0.8 in stock, this is kernel 3.0.26.
Faux kernel is based on CM sources linux-2.6.xx.x .
And there are no advantages as such, but deep sleep is finally working perfectly in kernel 3.0.y versions. So maybe better battery.
Working great on AOKP..... Battery seems a little bit better.
Sent from my LG-P999 using xda premium
the stock CM9 kernel has no HW accel, right? if so, i need this kernel for the voodoo, as stock CM9 doesn't have it.
joeyxl said:
the stock CM9 kernel has no HW accel, right? if so, i need this kernel for the voodoo, as stock CM9 doesn't have it.
Click to expand...
Click to collapse
True, stock CM9 do not have HW, neither do this kernel. And tegra2 devices will not have HW accel until Nvidia releases sources, or LG/T-Mobile release office ICS Rom.
Yes this kernel do have voodoo sound.
Appreciate your work. Thank you.
If you could please, in a timely fashion, provide the source to your changes and place it in the OP before the GPL police find out.
Thanks again!
Will there be a CM7 version of this kernel at all?
overground said:
Appreciate your work. Thank you.
If you could please, in a timely fashion, provide the source to your changes and place it in the OP before the GPL police find out.
Thanks again!
Click to expand...
Click to collapse
its already in its main thread in O2x, added it here too.
thendless said:
Will there be a CM7 version of this kernel at all?
Click to expand...
Click to collapse
No, not planned at the moment.
Nice!!! You work fast
Edit: Starting to like SIO, antutu benchmarks went up.
Sent from my LG-P999 using xda premium
Been following this project for awhile on other threads. I've been very impressed with this work. I've been curious about something, though, and didn't want to post this question in one of the main development threads.
What is the feasibility of upgrading the kernel to 3.1,3.2, or 3.3 series? For all I know it's completely impossible as I'm sure they had a reason to use 3.0 as the base for the project. I do find it interesting, though, that 3.3 comes with "android support" (not that I really know what that means either ).
MWBehr said:
Been following this project for awhile on other threads. I've been very impressed with this work. I've been curious about something, though, and didn't want to post this question in one of the main development threads.
What is the feasibility of upgrading the kernel to 3.1,3.2, or 3.3 series? For all I know it's completely impossible as I'm sure they had a reason to use 3.0 as the base for the project. I do find it interesting, though, that 3.3 comes with "android support" (not that I really know what that means either ).
Click to expand...
Click to collapse
yeah they have stated that next version will come with android support, it would not be 3.3, but would be 3.4. With more android related patches.
Guys even 3.0.y was a difficult task to port to tegra2, as no source, all thanks to wkpark and his awesome talents. I think your question can be better answered by him.
But code in 3.0.y to 3.1/3.2 has changed a lot, so would be very difficult to port, specially without any other android manufacturers not having 3.1/3.2 as base make it near impossible.
Harsh said:
yeah they have stated that next version will come with android support, it would not be 3.3, but would be 3.4. With more android related patches.
Guys even 3.0.y was a difficult task to port to tegra2, as no source, all thanks to wkpark and his awesome talents. I think your question can be better answered by him.
But code in 3.0.y to 3.1/3.2 has changed a lot, so would be very difficult to port, specially without any other android manufacturers not having 3.1/3.2 as base make it near impossible.
Click to expand...
Click to collapse
Thanks for the quick response. Ya, I was just curious more about if it was a possibility. If it takes a year or more, then that's what it takes. I have complete respect for the difficulties in porting something that's never been ported before.
so far so good...tks dev
Well...I can say this gets about 500 points higher on Quadrant 2.0 than Faux SV kernel. I didn't think it was fair to compare it to the OC version.
Hi all, so I've been wanting a really nice optimized Linaro recovery and have not been able to find one. So I decided to build my own and have found it to be very nice and stable, and of course to share with all of you xda peps
First off if you don't know what TWRP recovery is the original nexus 7 thread is HERE
Please read all of the original thread before flashing this recovery.
More info on how this recovery was built
Built using Linaro gcc 4.7 toolchain. I also built the toolchain from Linaro's gcc source. The toolchain source is HERE
This toolchain source gets update almost daily from linaro sources, but I don't normally have the time to build new toolchains daily. When I have time I will update it quite frequently.
Built off my own 4.1.2 kernel source. The kernel used to build this recovery was also compiled using the Linaro 4.7 toolchain.
I've added a few linaro recovery patches for interfaces to libpng. Those changes are HERE and HERE.
Built using Linaro bionic string routines optimizations.
Installation
Download the recovery image and flash in fastboot
Initial release 2.3.1.1 touch recovery
10.28.12 release 2.3.1.1 touch recovery
Kernel changes
Removed a lot of bloat from the kernel. I disabled GPU overclocking, user voltage control, cpu overclocking, a bunch of useless debugging stuff.
A short kernel changelog is HERE
Toolchain changes
Not much here. I included a static library to be used in the toolchain libiberty
A short changelog for the toolchain is HERE
Recovery changes
Built as engineering instead of userdebug.
11.5.12 release 2.3.1.1 touch recovery
Final android 4.1.2 linaro recovery version
Kernel changes
Mainline linux kernel upstream changes from linux-3.2.y
Changed kernel compression mode to GZIP and optimization level to -Os
Toolchain changes
Updated to latest linaro changes
Recovery changes
-O3 optimization level
Linaro strict-aliasing compiler flags optimization
Android-4.1.2 (This version is a final release, no more updates)
Size: 6.95 MB
MD5: e0f46f01556156b052b3779c9ed60e01
What? A Linaro recovery? I did not know there was such thing. I am downloading this now very excitedly.
Thank you. Very very helpful and nice.
OK... Now I need more info! I sorta understand the Linaro concept but my knowledge is limited. What's the reasons to base Recovery on it at this point? Any advantages, possible concerns? Will there be any noticeable differences? Just curious & wondering cause you said "you'd been wanting to make a recovery based on linaro".
Thank!
Sent from my Nexus 7 using Tapatalk 2
Hi men!
Thanks for your recovery.
But i experience some strange visual effects like distortion of the image or some lag effects.
---------- Post added at 04:21 PM ---------- Previous post was at 04:16 PM ----------
djd338 said:
OK... Now I need more info! I sorta understand the Linaro concept but my knowledge is limited. What's the reasons to base Recovery on it at this point? Any advantages, possible concerns? Will there be any noticeable differences? Just curious & wondering cause you said "you'd been wanting to make a recovery based on linaro".
Thank!
Sent from my Nexus 7 using Tapatalk 2
Click to expand...
Click to collapse
There is a discussion on this subject regarding some tests Ezekeel (XDA developper) made with different cross-compiler toolchains and those tests prooved that none of the compilers is better than another.
We heard a lot about linaro because when ICS was released, it was very laggy and linaro and is new compiler version 4.7 made ICS much smoother than before.
But for the pur performance linaro give no improvement if you compare with another one.
EDIT: I found the link of the test for you: http://forum.xda-developers.com/showpost.php?p=19872366&postcount=1
i remember this test,and also in my home test when i tried to build kernel,i don't see improvement using linaro or others toolchains..anyway it's great to have another thing to play on and see if it's best that the ufficial!
sert00 said:
i remember this test,and also in my home test when i tried to build kernel,i don't see improvement using linaro or others toolchains..anyway it's great to have another thing to play on and see if it's best that the ufficial!
Click to expand...
Click to collapse
Agree with you.
It wasn't for discredit the work of sparksco. I'm glad to test his work.
Just answer the question for the cross-compiler.
Thanks for the work sparksco
[email protected]_OC said:
Hi men!
There is a discussion on this subject regarding some tests Ezekeel (XDA developper) made with different cross-compiler toolchains and those tests prooved that none of the compilers is better than another.
We heard a lot about linaro because when ICS was released, it was very laggy and linaro and is new compiler version 4.7 made ICS much smoother than before.
But for the pur performance linaro give no improvement if you compare with another one.
EDIT: I found the link of the test for you: http://forum.xda-developers.com/showpost.php?p=19872366&postcount=1
Click to expand...
Click to collapse
That's one test with one toolchain by one developer. As far as I can tell he tested everything with one of linaro's really old toolchaons when they first released 4.6. So by looking at the dates I would guess linaro didn't add much to the toolchain at that point. There's also the GCC version to consider. This is using 4.7 and not 4.6. And lastly there's rom patches that linaro puts out that have nothing to do with the kernel but are used in the ROM building process when building recoveries. It's all debatable. I find this to be a bit smoother and backups seems to be a little faster but maybe it's just me.
[email protected]_OC said:
Hi men!
Thanks for your recovery.
But i experience some strange visual effects like distortion of the image or some lag effects.
Click to expand...
Click to collapse
Your going to have to provide more info than that. Your method of installing, what bootloader you have ect. Thanks.
Edit: flashing zip in recovery causes issues so I removed that method of installing.
sparksco said:
That's one test with one toolchain by one developer. As far as I can tell he tested everything with one of linaro's really old toolchaons when they first released 4.6. So by looking at the dates I would guess linaro didn't add much to the toolchain at that point. There's also the GCC version to consider. This is using 4.7 and not 4.6. And lastly there's rom patches that linaro puts out that have nothing to do with the kernel but are used in the ROM building process when building recoveries. It's all debatable. I find this to be a bit smoother and backups seems to be a little faster but maybe it's just me.
Click to expand...
Click to collapse
thanks.after give a try to this recovery,i agree with you with fact of possible quickest backup time.the general use is good,don't know if it's real an improvement,but i did a backup and at first look it seemed quicker..possible placebo effect,let's see what others say..
why you pulled cwm install version...bugged?
There's a lot of factors to consider. Just the fact that this is using a kernel I built with 4.7 from my own source code could improve things as well. FYI the kernel includes GPU overclocking.
sert00 said:
why you pulled cwm install version...bugged?
Click to expand...
Click to collapse
Read one post above yours...
Sent from my Nexus 7 using Tapatalk 2
sparksco said:
There's a lot of factors to consider. Just the fact that this is using a kernel I built with 4.7 from my own source code could improve things as well. FYI the kernel includes GPU overclocking.
Read one post above yours...
Sent from my Nexus 7 using Tapatalk 2
Click to expand...
Click to collapse
oh thanks,not saw the edit in the post!
New version is up.
Sent from my Nexus 7 using Tapatalk 2
I installed last night using goomanager, so I assume I have the previous version?
Anyway, it works great, so thanks.
stonebear said:
I installed last night using goomanager, so I assume I have the previous version?
Anyway, it works great, so thanks.
Click to expand...
Click to collapse
I am pretty sure you get the Official TWRP version from goomanager not this. Please correct me if I am wrong but I think that is what the Unofficial means.
zedorda said:
I am pretty sure you get the Official TWRP version from goomanager not this. Please correct me if I am wrong but I think that is what the Unofficial means.
Click to expand...
Click to collapse
Yea, I just realised that myself when I saw there were two threads.
What's the difference between this and ClockWorkMod? Is it more stable?
Neo3D said:
What's the difference between this and ClockWorkMod? Is it more stable?
Click to expand...
Click to collapse
Some more features on TWRP I think, especially the queue to flash multiple ZIP files. Flash it and see for yourself
modstorm said:
Some more features on TWRP I think, especially the queue to flash multiple ZIP files. Flash it and see for yourself
Click to expand...
Click to collapse
That, and I like the fact that you have an option to wipe cache/dalvik after flashing something
markj338 said:
That, and I like the fact that you have an option to wipe cache/dalvik after flashing something
Click to expand...
Click to collapse
That and TWRP can also be themed however I never found any themes :/
As many of you might have already heard about it: That using the Linaro toolchain to compile a ROM increases performance. But making stock kernel sources compatible to be compiled with Linaro is no easy task. But, the steps are similar.
When it is compatible to be compiled with GCC 4.3.3, why shouldn't it compile with GCC 4.7?
The problem lies in the code. The transition from GCC 4.3.3 to GCC 4.6, lot of things changed. GCC decided that people should start writing "cleaner code". So, new errors occur when compiling with GCC 4.6+. Example: "unused-but-set-variable". This was not an error in GCC 4.3.3, but GCC 4.7 made it a big issue :crying:
As I said before, GCC 4.3 can compile it, while GCC 4.7 can't. So, I decided to use certain __attribute__'s, and #pragmas, to ignore the errors that one might encounter when trying to compile with GCC 4.7.
Mainly the lines used were:
Code:
__attribute__((__unused__))
and,
Code:
#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
Steps:
1. Download the GCC 4.7 toolchain using the following command, and place it inside your android-toolchains folder:
Code:
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7
2. Download the kernel source compatible with GCC 4.7 from here
Code:
git clone git://github.com/vineethraj49/pico_kernel_stock.git
Edit the Makefile to correspond to the path of the GCC 4.7 toolchain :fingers-crossed:
Then, its simple,
Code:
make msm7627a_defconfig
and
Code:
make -jX
The code is compatible to be compiled with GCC 4.7 AS IS! You make modifications to code, you should & you WILL run into errors. Usually you can overcome errors by editing the required code, using #pragmas and __attribute__'s. If you ain't ready to work hard, please notify in the thread with the changes that you made to "msm7627a_defconfig", and the possibly a log, with the errors I will add the necessary __attribute__'s, and #pragmas :silly:
As for: Why didn't you make it compatible with Linaro toolchain?
The answer is that @Rishik999 is already working on making it compatible with Linaro, and I don't want to steal his idea
Credits:
Rishik999 for his idea about compiling with Linaro, and expect his kernel sources compatible with Linaro toolchain soon
http://gcc.gnu.org/gcc-4.6/porting_to.html
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html
http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Diagnostic-Pragmas.html
Google
Some IBM docs, which helped.
http://web.mst.edu/~cpp/common/common_errors.html
Linus and the 2000+ people who contributed to the first Linux kernel.
Source: https://github.com/vineethraj49/pico_kernel_stock
Disclaimer: Everybody can use my work without asking permission, all my stuff comes with a "sharing is caring" xda philosophy licence... just credits would be nice
Reserved
Remember, kernel compilable without errors AS IS!
I will add some steps about how to ignore errors in this post, maybe. So that I don't have to edit a 100+ files again :silly:
Great work
Great work ! :good:
Why posted on general ?
All is well, but i doubt linaro toolchain makes a lot of difference while compiling kernels.
+ i dont think anyone uses stock kernel (2.3.5 android htc sense)
Yes
everyone is on kernel 3
Hpsgill said:
Yes
everyone is on kernel 3
Click to expand...
Click to collapse
im still on gingerbread..
ohh
a gb lover
only few users using gb
everyone is on ics,jb or sense 4
Hpsgill said:
ohh
a gb lover
only few users using gb
everyone is on ics,jb or sense 4
Click to expand...
Click to collapse
yes i love gingerbread IMO the most stable android version for our phone
how i wish cm7 will be complete and also im waiting for the sense 4.1 by cute prince to be stable enough like gb and waiting your sense ex build 6 too
Any chance we will be seeing a kernel for the shield soon? It would be great to get some of the forgotten features like OTG charging to the ST.
Spiteful Monkey said:
Any chance we will be seeing a kernel for the shield soon? It would be great to get some of the forgotten features like OTG charging to the ST.
Click to expand...
Click to collapse
Second this. Would love to see CIFS.
I would love to see ElementalX kernel. I love having it on my Nexus 5 with Paranoid Android and CM11.
daeymon said:
Second this. Would love to see CIFS.
Click to expand...
Click to collapse
Is it just a kernel module? And if so can you find the source? I did a quick search and couldn't find anything.
I dug through flar2's repo and found it in one of his kernels. I'll play around and see, I'll probably just post up something for whoever to test if I can get something built.
Looks like it was already in the kernel source used for aosp builds. Try this one I built, I added exfat and compiled with gcc 4.7 but other than that it's the same as in cm/vanir.boot.img
Keithn said:
Is it just a kernel module? And if so can you find the source? I did a quick search and couldn't find anything.
I dug through flar2's repo and found it in one of his kernels. I'll play around and see, I'll probably just post up something for whoever to test if I can get something built.
Looks like it was already in the kernel source used for aosp builds. Try this one I built, I added exfat and compiled with gcc 4.7 but other than that it's the same as in cm/vanir.boot.img
Click to expand...
Click to collapse
The modules needed for Cifs support is cifs.ko, md4.ko and nls_utf8.ko.
My efforts to get a set of these which working with the Shield Tablet have yielded no results. If I had a set of compatible modules compiled for the Nvidia Shield, then thats all I would need to get Cifs working on the pre-existing Kernel, by using the insmod option within Cifsmanager to load all three modules.
daeymon said:
The modules needed for Cifs support is cifs.ko, md4.ko and nls_utf8.ko.
My efforts to get a set of these which working with the Shield Tablet have yielded no results. If I had a set of compatible modules compiled for the Nvidia Shield, then thats all I would need to get Cifs working on the pre-existing Kernel, by using the insmod option within Cifsmanager to load all three modules.
Click to expand...
Click to collapse
Have you found the source for them?
Looking into the source I am seeing nls_utf8.o and md4.c, which I would think would be compiling them with the kernel but maybe a config/make file needs to be changed somewhere.
Keithn said:
Have you found the source for them?
Looking into the source I am seeing nls_utf8.o and md4.c, which I would think would be compiling them with the kernel but maybe a config/make file needs to be changed somewhere.
Click to expand...
Click to collapse
Only sources I know of are the ones Nvidia have provided. I don't really know much about compiling kernels and such. What I know about Cifs modules comes from my JXD S7800B when I needed to figure out how to get that to work. In the end another figured it out and provided a guide and I followed that guide. But he did the really hard part in getting the compatible versions of those modules for the JXD S7800B.
daeymon said:
Only sources I know of are the ones Nvidia have provided. I don't really know much about compiling kernels and such. What I know about Cifs modules comes from my JXD S7800B when I needed to figure out how to get that to work. In the end another figured it out and provided a guide and I followed that guide. But he did the really hard part in getting the compatible versions of those modules for the JXD S7800B.
Click to expand...
Click to collapse
If I end up making any progress while playing around I'll post it but I don't use it and I've been pretty busy lately so I can't guarantee anything. Its just odd that it looks like the necessary pieces are in the kernel source for the kernel I posted.
Sent from my SHIELD Tablet