Related
this is my 2.6.27 source for eclair builds of android. this has been a long time project with lots of help from some great friends. i consider this a community kernel so all are welcomed to it, to use in their builds or what not. all thats asked is for all who use it, to give credit for using this source. just as u would for using anyone elses work. thats just to be fair to those who help maintain this kernel.
thanx:
maejrep
flipz
quietblongs
phhusson
MrPippy
tmzt
bzo
and if i forgot u ill add u later
current commits:
-msm_hw3d support for Donut and Eclair builds (ported patches made by phhusson and MrPippy)
-synaptics touch driver (backported from .29)
-msm_camera (backported from .29 by maejrep)not yet working
-compcache sources
-overclocking and the ability to scale all current freqs (major thanx to phhuddson, bzo, and maejrep for all the help)
-backported ext4 support
-fixed freq tables to show correct clock speeds
-backported BFS (Brain **** Scheduler) version 316
new commits and patches are welcomed. please submit them for review.
http://github.com/toastcfh/htc-2.6.27-heroc
Enjoy
reserved
...........................................
Good job Hopefully these fixes make it into all the awesome ROMs out there (yours included)
So this is the much anticipated OpenGL and Multitouch?
I actually grabbed the source from github /jhansche/htc-2.6.27-heroc last night. Got it compiled and running and I have to say it works nicely. Loving the OpenGL, but especially the multi-touch!
You guys are awesome. Thank you for all your hard work!
PRGUY85 said:
So this is the much anticipated OpenGL and Multitouch?
Click to expand...
Click to collapse
Sure is. This is the code base that got me the highest-on-Hero-so-far 29.9fps bench on neocore that I posted a screenshot of in his thread.
Amazing work guys
damn it I really need to get a linux setup so I can compile the kernels. I WANT THIS!!!!!! AAAAAAAAAAAAAAAAAAAARRRRRRRRRRRRRRRRRRRRRRRGGGGGGGGGGGGGGGG!
Hope this gets incorporated soon into the latest 2.0.1/2.1 AOSP ROMs...also is this compatible with Gumbo's Kernel?
PRGUY85 said:
Hope this gets incorporated soon into the latest 2.0.1/2.1 AOSP ROMs...also is this compatible with Gumbo's Kernel?
Click to expand...
Click to collapse
this is a kernel it is not a rom.
PRGUY85 said:
Hope this gets incorporated soon into the latest 2.0.1/2.1 AOSP ROMs...also is this compatible with Gumbo's Kernel?
Click to expand...
Click to collapse
i'm pretty sure that this is a kernel, so your question's a bit confusing. maybe i'm just delirious?
I know its a kernel dude....still it can get incorporated into those ROMs builds like everyone has been waiting to do so...
What I'm saying is that with this now the ROM makers can get OpenGL and Multitouch on their ROM releases, something everyone has been waiting for.
soooo who wants to be so nice as to compile this to zip so people can flash it
PRGUY85 said:
I know its a kernel dude....still it can get incorporated into those ROMs builds like everyone has been waiting to do so...
What I'm saying is that with this now the ROM makers can get OpenGL and Multitouch on their ROM releases, something everyone has been waiting for.
Click to expand...
Click to collapse
yes that is true but you also asked if it was compatable with gbhils kernel that is why it was a little confusing.
Avalaunchmods said:
soooo who wants to be so nice as to compile this to zip so people can flash it
Click to expand...
Click to collapse
lol I wanst going to be the one to ask but I was kinda hoping someone would.
PRGUY85 said:
I know its a kernel dude....still it can get incorporated into those ROMs builds like everyone has been waiting to do so...
What I'm saying is that with this now the ROM makers can get OpenGL and Multitouch on their ROM releases, something everyone has been waiting for.
Click to expand...
Click to collapse
Yes, this codebase (the last few days' commits at least) will enable hw3d and multitouch, and can be applied to any .27 kernel that is based on the htc-heroc-2.6.27 code that HTC released (which I should hope is all of them )
And yes, any kernel can be integrated into a ROM, as long as the ROM doesn't rely on custom kernel changes (e.g., squashfs is not enabled in this codebase, but if the developer already has squashfs in his own kernel codebase, he can apply these latest commits to his code, and compile a new kernel with both squashfs and gl+multutouch support, if that's what his ROM requires)
wtphoto said:
yes that is true but you also asked if it was compatable with gbhils kernel that is why it was a little confusing.
Click to expand...
Click to collapse
Yea I'm no tech guy/developer...just asking if on a ROM a dev could include this as well as the ability to setcpu which is available by way of Gumbo's kernel.
wtphoto said:
lol I wanst going to be the one to ask but I was kinda hoping someone would.
Click to expand...
Click to collapse
im excited so i had to go for it
wtphoto said:
lol I wanst going to be the one to ask but I was kinda hoping someone would.
Click to expand...
Click to collapse
You can't add just a kernel to an update.zip and flash it -- kernel gets combined into the boot.img, which is included in the update.zip for every ROM. boot.img also has the stuff that goes into / (like init.rc scripts), and so not every ROM will be compatible with the same boot.img, and you can't just flash a boot.img by itself via zip (you can via flash_image in recovery, but still, some ROMs require the boot.img that it was designed for, due to init ramdisk )
So, this is more something for the ROM developers and the not-so-faint of heart. In reality, it's not that hard to build the boot.img, and you can actually unzip your favorite ROM's zip, unpack the boot.img, then rebuild a new boot.img using that ROM's initrd and your own custom kernel, then flash just the boot.img using flash_image, and it won't even require a wipe. That's again assuming the ROM doesn't rely on anything custom in the kernel it was released with.
PRGUY85 said:
Yea I'm no tech guy/developer...just asking if on a ROM a dev could include this as well as the ability to setcpu which is available by way of Gumbo's kernel.
Click to expand...
Click to collapse
ok I see what you where asking now majrep already answered most of it but yeah I belive that they could get the setcpu thing going in this kernel.
Hi,
I am trying to extract the kernel from mmcblk0p20 using unpack-bootimg.pl
from this post: http://forum.xda-developers.com/showpost.php?p=2885020&postcount=1
I can get a valid ramdisk out of it but the kernel is not a gz file as it should be.
Any hint?
Etn40ff said:
Hi,
I am trying to extract the kernel from mmcblk0p20 using unpack-bootimg.pl
from this post: http://forum.xda-developers.com/showpost.php?p=2885020&postcount=1
I can get a valid ramdisk out of it but the kernel is not a gz file as it should be.
Any hint?
Click to expand...
Click to collapse
The kernel is not exactly a "gzipped" file because the first part of it has bootloader code that provides a mechanism to uncompress the remaining part of the kernel (which uses a form of gzip provided by a micro zlib).
More importantly, what are you trying to accomplish? The "kernel" image that comes from split_bootimg.pl (or such) is the actual file you use to re-pack, etc. Unless of course you're trying to decompile the kernel for reverse engineering purposes, but that would be pointless and you wouldn't be asking this question if that were the case.
If you're trying to get the kernel config, use extract-ikconfig from the 'scripts' directory in the Linux source tree. You have to invoke it by cd'ing into the Linux source directory and doing:
Code:
./scripts/extract-ikconfig /path/to/your/kernel-file &> /where/you/want/the/resulting-config
(you can't cd into 'scripts' and have it work).
Enjoy.
As you say unpacking the kernel to get the configuration is pointless: I could get it on htcdev without any effort.
I just had a boring night and I tried to kill it repacking my own flavour of android.
I was not able to make it boot so I started guessing which problem I was having; the kernel seemed a reasonable candidate (I was convinced that I was stripping the header away from it when unpacking)
how could you acquire that kernel? last time I checked there was no source?
You need the kernel source before a kernel can be made. Thats the sucky part.
Sent from my myTouch_4G_Slide using xda premium
Undeadk9 said:
You need the kernel source before a kernel can be made. Thats the sucky part.
Click to expand...
Click to collapse
Eh? No. A kernel exists, just in binary form. HTC has yet to release the source code, but unless you plan to modify parts of it, there's not much point.
nbetcher said:
Eh? No. A kernel exists, just in binary form. HTC has yet to release the source code, but unless you plan to modify parts of it, there's not much point.
Click to expand...
Click to collapse
A kernel source is no problem, I got it from android github.
The issue is the mods htc made and added, and the tools around it they used to compile.
I would like to compile my own, to optimize (did it on linux too).
If anyone can explain me simple how to use the binary kernel, I am happy too for now, if that makes me able to compile CM7
Anyone? Can't be too hard since a lot of folks pulled it of?
I have a lot of technical experience, just need some android specific info
I know nothing bout kernels. They scare me. I'll stick to ROM making.
Sent from my MyTouch 4G Slide using xda premium
OpenMinded said:
A kernel source is no problem, I got it from android github.
The issue is the mods htc made and added, and the tools around it they used to compile.
I would like to compile my own, to optimize (did it on linux too).
If anyone can explain me simple how to use the binary kernel, I am happy too for now, if that makes me able to compile CM7
Click to expand...
Click to collapse
It's not quite that simple. They don't just 'mod' the kernel, they add device support to it. The upstream Linux kernel does not support the latest and greatest Qualcomm-based devices, so HTC uses their own repository based on Codeaurora (http://www.codeaurora.org) which is downstream from Qualcomm. Confused yet?
Point being: Linux will not run properly on our device until we have either the HTC Sensation source, Doubleshot source, or someone sifts through and pieces together all of the various sources needed from Codeaurora.
To use the binary form, just use boot.img from our device's HBOOT image.
nbetcher said:
It's not quite that simple. They don't just 'mod' the kernel, they add device support to it. The upstream Linux kernel does not support the latest and greatest Qualcomm-based devices, so HTC uses their own repository based on Codeaurora (http://www.codeaurora.org) which is downstream from Qualcomm. Confused yet?
Point being: Linux will not run properly on our device until we have either the HTC Sensation source, Doubleshot source, or someone sifts through and pieces together all of the various sources needed from Codeaurora.
To use the binary form, just use boot.img from our device's HBOOT image.
Click to expand...
Click to collapse
Thank you for the explanation.
I have been compiling kernels on linux, I know we need drivers and that HTC patches the kernel. I did not know about codeaurora, thanks .
The HTC Sensation kernel source is on the HTC website:
http://developer.htc.com
I was wondering undead, how do you compile other ROMS? You just strip what is not needed? I thought you know how tot strip just the kernel, since you made a senseless rom.
I will try using the boot.img, thanks.
Does that mean porting a Sense rom would only require swapping the boot.img from another Sense 2.0/3.0 rom?
Thanks for the info
LOL. No its still the sense base and uses the stock boot.img from the stock ROM. It's still HTC at its core. Like I said I know 0 'zero' about kernels.
Sent from my MyTouch 4G Slide using xda premium
Undeadk9 said:
LOL. No its still the sense base and uses the stock boot.img from the stock ROM. It's still HTC at its core. Like I said I know 0 'zero' about kernels.
Sent from my MyTouch 4G Slide using xda premium
Click to expand...
Click to collapse
point taken . I think I just made a working zip containing only the stock kernel.
If I have time, I will try to put that kernel in a AOSP rom for the Sensation and see what that does. may take some time...
does any1 know how to mod the device checking of a rom?
i get an error 7, found it is because of the device check.
I modded the update script and binary from the Senation Alpha cm7 and got that error, which seems to point to a different model of phone.
I would like to work around it and see if the kernel works with cm7
All,
Since we are working as a DEV team now I wanted to share a PM I had with another DEV on the board about our Kernel. I hope this can assist some others that have more experience with the Kernel like b_randon
g60madman said:
subpsyke,
I would love to upgrade our kernel for the Motorola Triumph. How did you go about figuring which Code Aurora vanilla kernel to start with? I took over development for CM7 from Whyzor and would be interested in your methodology.
Thanks in advance,
g60
Click to expand...
Click to collapse
subpsyke said:
1. I unpacked the original Huawei source to one directory, and downloaded the CodeAurora kernel to another.
2. I used the release tags as a reference: https://www.codeaurora.org/xwiki/bin/QAEP/froyo_almond
https://www.codeaurora.org/xwiki/bin/QAEP/froyo
https://www.codeaurora.org/gitweb/quic/la/?p=kernel/msm.git;a=tags
3. I reverted the codeaurora repository to tag releases (e.g.: git reset --hard M76XXTSNCJNLYA6010) and compared the result via "diff urN" and meld. I knew I was getting closer when you get a smaller diff in the patch size, and used meld to see if the differences were likely to be Huawei's additions vs. CodeAurora's changes. It was only after going forward and backwards between tags was I sure of the proper baseline.
I performed the same discovery process with the Samsung kernel for my GT-I5500, which used M76XXTSNCJNLYA6040 as a baseline.
Click to expand...
Click to collapse
g60madman said:
Sweet thanks! I will check it out and see what I can do
Click to expand...
Click to collapse
subpsyke said:
No problem
I forgot to mention the last steps:
4. Once you establish the baseline, create a new branch: git checkout -b newbranch
5. Overlay the changes from the vendor to a new commit*:
cp ~/blah/vendorkernel/ . ; git add . ; git commit -m "Initial import of vendor changes".
6. Once you've commited the vendor changes, you can use "git merge origin/froyo_almond" to move from the baseline to a newer revision. The froyo_almond branch is most suitable, as it's locked at 2.6.32, and the development focus seems to be on the msm7k chipset series. You could try updating to the android-msm-2.6.32 kernel, but it has more significant changes that will require adaptations of the board file, and may not be worthwhile, as development focus seems to be on newer chipsets.
7. Inevitably you'll get merge conflicts, as more than likely some vendor commits may interfere with upstream changes. For this, you'll need to use your own discretion in fixing up the code. I use the "git mergetool", with meld configured as my default editor, and manually checked all the conflicts.
Good luck!
*You may also want to fix up permissions etc., if your vendor source comes from a zip tarball. But it's purely cosmetic.
Click to expand...
Click to collapse
g60madman said:
So is almond the best flavor to start with. I have been using MSM/QSD for a while and in when TickerGuy originally created our device files for cm7 he listed in the readme
CAF information:
Branch: froyo_pumpkin
Tag: M7630AABBQMLZA2030
Didn't know if I should start with pumpkin or use almond. Let me know what you think?
Thanks again for the info!
Click to expand...
Click to collapse
subpsyke said:
Hmm... if your phone really has a msm7630 chipset, then yes, you should probably go for the froyo_pumpkin branch. The froyo_almond branch is only for the msm7627 and qsd8650 chipsets.
Click to expand...
Click to collapse
g60madman said:
Well thats the stupid thing, since the beginning we have used always used msm7x30 for our board config, But our stock ROM from Virgin Mobile the config was msm7k in the build.prop. However if you hit the Motorola Dev our pone clearly states Qualcomm MSM8655. I am leaning towards using the almond branch would that be correct?
Click to expand...
Click to collapse
subpsyke said:
According to wikipedia, it's MSM8655.
Look at the table here: https://www.codeaurora.org/xwiki/bin/QAEP/
The froyo_almond supports qsd8650, and froyo_pumpkin supports qsd8650a_st1x. I honestly have no idea what the difference is, but it's within the realm of possibility that your phone's chipset is that odd revision on the pumpkin branch.
If your kernel is using a pumpkin baseline, then you should continue along the same branch.
Click to expand...
Click to collapse
g60madman said:
I will download pumpkin and compare the kernel. I am not sure why TickerGuy started with pumpkin. That maybe what our build is based off of but I am not 100%.
Click to expand...
Click to collapse
subpsyke said:
Ok. When you clone the codeaurora git repository, you'll have all the branches included anyway.
Click to expand...
Click to collapse
....sympathy post...
Sent from my SPH-D700 using xda premium
(The froyo_almond supports qsd8650, and froyo_pumpkin supports qsd8650a_st1x.) Is this the difference between the Photon 4G which has a WiMax radio in it, and the Triumph which does not include a 4G radio? <--- nvm when they came out I had heard they were the same phone except 4G, apparently the Photon is a Tegra 2 device.
Okay so after looking into code Aurora more, as soon as I get my Ubuntu back up I am going to work on a vanilla froyo 2.6.32.9 kernel by using the froyo_pumpkin branch on the tag Karl gave us. Once I do that and have a commit that adds in Motorola changes, I am going to use the gingerbread_rel branch to try to get a 2.6.35 kernel booting on the phone, then use the ics_chocolate_rb7 branch to hopefully get the 3.x kernel.booting. those branches all seem to have the best support for msm7630 chipsets which I believe is the closest to the msm8655 chip only that it is clocked at 800mhz instead of 1ghz. If anyone else can lend any advice or help it would be swell!!
Sent from my Triumph using Tapatalk
b_randon14 said:
Okay so after looking into code Aurora more, as soon as I get my Ubuntu back up I am going to work on a vanilla froyo 2.6.32.9 kernel by using the froyo_pumpkin branch on the tag Karl gave us. Once I do that and have a commit that adds in Motorola changes, I am going to use the gingerbread_rel branch to try to get a 2.6.35 kernel booting on the phone, then use the ics_chocolate_rb7 branch to hopefully get the 3.x kernel.booting. those branches all seem to have the best support for msm7630 chipsets which I believe is the closest to the msm8655 chip only that it is clocked at 800mhz instead of 1ghz. If anyone else can lend any advice or help it would be swell!!
Sent from my Triumph using Tapatalk
Click to expand...
Click to collapse
Swell, I love that word. Here is an email I got from TickerGuy on the Kernel a fe months back
g60madman said:
TickerGuy,
I know you have moved on from the MT. Currently I have taken over development for CM7 from Whyzor and had a question for you.
When you designed the original device files you listed in the readme:
Branch: froyo_pumpkin
Tag: M7630AABBQMLZA2030
Is that really our branch from MSM/QSD? I know the phone has the MSM8655 chip. So I'm just trying to figure out why we use msm7x30 for the board configuration and not say msm7k or qsd8k?
Thanks in advance for any help you can offer
Click to expand...
Click to collapse
TickerGuy said:
I think the reason had to do with some of the peripheral chips -- it was a lot of fun getting this phone to work as it has a number of very odd things about it, especially in the GPS area.
Click to expand...
Click to collapse
So I think it's safe to say the route you are taking the right route. Also when building the Kernel do not forget to merge in the Wyzor fixes for the Video as I am using the new Andreno drivers. Just an FYI.
Yeah I will on the cm7 kernel. As of right now I'm gonna try to get a stock froyo kernel booting off code Aurora sources then go ffrom there.
Sent from my Triumph using Tapatalk
I've got my Linux mint 13 up and running so I'm going to try to get my build environment setup to build kernels either tonight or tomorrow and start pulling in source.
By the way, Linux mint 13 is pretty nice distro so far. I like it alot better than Ubuntu!
Sent from my Triumph using Tapatalk
b_randon14 said:
I've got my Linux mint 13 up and running so I'm going to try to get my build environment setup to build kernels either tonight or tomorrow and start pulling in source.
By the way, Linux mint 13 is pretty nice distro so far. I like it alot better than Ubuntu!
Sent from my Triumph using Tapatalk
Click to expand...
Click to collapse
Also you don't need to download the pumpkin branch simple download the kernel
git clone git://codeaurora.org/kernel/msm.git
git reset --hard M7630AABBQMLZA2030
The M7630AABBQMLZA2030 is the pumpkin branch and that should take us back to the vanilla kernel
Here is the pastebin link for the warning I was getting from the linker during the build of the code Aurora kernel.
http://pastebin.com/GLMBSz26
You can look at the kernel source on my github. Its the froyo pumpkin kernel repo.
The warnings cone from the gcc linker saying that it's trying to link a non executible section in built-in.o
I'm not sure where to start looking for the issue at. If anyone can lend any insight I would be grateful!
Sent from my Triumph using Tapatalk
I switched to the gcc 4.3.1 toolchain included with the cm7 source and it booted up. Worked just as good as the stock kernel. I'm gonna have to see why the newer toolchains are not compiling it right. I use linaro 4.6 on bKernel froyo which is based off motos source. So I don't see why it wont build this code right. But at least I got one to boot! !!
Sent from my Triumph using Tapatalk
b_randon14 said:
I switched to the gcc 4.3.1 toolchain included with the cm7 source and it booted up. Worked just as good as the stock kernel. I'm gonna have to see why the newer toolchains are not compiling it right. I use linaro 4.6 on bKernel froyo which is based off motos source. So I don't see why it wont build this code right. But at least I got one to boot! !!
Sent from my Triumph using Tapatalk
Click to expand...
Click to collapse
Good work brother!
Thanks. Now lets try to move on up to 2.6.35. My idea is to make a different patch between 2.6.32.9 and 2.6.35.7 and maybe that will simplify updating it. I'm not sure which gingerbread branch I'm gonna use for the 2.6.35 kernel!
Sent from my Triumph using Tapatalk
I would think the gingerbread branch, and use the M7630AABBQMLZA404025I.xml version. That is where I snagged the keyboard updates.
g60madman said:
I would think the gingerbread branch, and use the M7630AABBQMLZA404025I.xml version.
Click to expand...
Click to collapse
you can use source kernal .35 for device fih-fbo..we are the same drive only need to change touch driver..
Yeah I would use the fih kernels but we has issues with them rebooting on us.
Sent from my Triumph using Tapatalk
b_randon14 said:
Yeah I would use the fih kernels but we has issues with them rebooting on us.
Sent from my Triumph using Tapatalk
Click to expand...
Click to collapse
yes you need get a logcat and new baseband for this kernal...I have a file to solve the rendom reboot..but I can't help to get you for the baseband...
The kernel shouldn't have nothing to do with the baseband. Which file is it?
Sent from my Triumph using Tapatalk
b_randon14 said:
The kernel shouldn't have nothing to do with the baseband. Which file is it?
Sent from my Triumph using Tapatalk
Click to expand...
Click to collapse
yes I know,I mean in rom library need these file,I will give you file when I go back home
Anyone got any ideas to fix the issues with newer toolchains when building from the code Aurora source?
Sent from my Triumph using Tapatalk 2
Have you tried downloading one of the gingerbread repo's from code Aurora? I am not sure if they have a different version of the tool chain or not?
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...
sooooo my mum bought new phone and her old gt-s7500 is lying around not used. i want to play with it and probably compile custom kernel. so anyone wants custom gb kernel?
mdfzhi said:
sooooo my mum bought new phone and her old gt-s7500 is lying around not used. i want to play with it and probably compile custom kernel. so anyone wants custom gb kernel?
Click to expand...
Click to collapse
I think that it would appreciated :good:
anyone wants the gb custom kernel can pm me.
i'm using mb-14 source as base, overclockable upto 1,2ghz, i've backported interactive governor from kernel 3.4, added custom gpu table, added dynamic fsync, added logger control, compiled using gcc 4.4.3 with correct arm cortex-a5 for ace plus. 50mb zram. tested and running fine for two days now, stable and no reboot.
Could you give me a link to mb-14's sources? I can't seem to find traces of any GB kernel anywhere, even in Samsung's site. This could help me in building a new stable 3.4 kernel.
Thanks!
Liam D. said:
Could you give me a link to mb-14's sources? I can't seem to find traces of any GB kernel anywhere, even in Samsung's site. This could help me in building a new stable 3.4 kernel.
Thanks!
Click to expand...
Click to collapse
Are these?
AndroidVin said:
Are these?
Click to expand...
Click to collapse
Specifically, this, but thanks for the direction!
Liam D. said:
Specifically, this, but thanks for the direction!
Click to expand...
Click to collapse
glad to help a great developer like you ......good work, I will wait your next build, hoping that the kernel panic bug will be solved :fingers-crossed: