Related
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
I was compiling n8000 source with Linaro TC 4.7 and encountered this issue. http://pastebin.com/3KUkvruj
Has anyone solved this issue for n8000? Help would be very much appreciated!
What's your defconfig file? Are you using "p4notepq-3g_00_defconfig"?
kcrudup said:
What's your defconfig file? Are you using "p4notepq-3g_00_defconfig"?
Click to expand...
Click to collapse
Hey! Nope, im using my old defconfig. It didn't happen last time, not sure where went wrong.
Well, it's not a Linaro error per se; I've been building with a Linaro GCC since forever.
It looks like you'll need to remove an extraneous #include somewhere; the real mystery is why it's suddenly required.
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...
Sabermod has amazing performance and better battery life.
DEV Threads already has PA sabermod and Slim sabermod but CM.
Is there anyone wants to do a CM SaberMod ROM?
Not the dev but here's one. http://forum.xda-developers.com/oneplus-one/development/rom-kernel-sabermod-cm-11-0-t2880407