Related
11-5-13 -- See here for the start of the CM 11.0 (based on Android 4.4 KitKat) discussion.
7-27-13 --- See here for my build instructions for CyanogenMod 10.2 (based on AOSP 4.3)...
Hey all,
So I've ported my "Build CyanogenMod" instructions (Nook Color, Nook Tablet, and HP Touchpad) to the Nexus 7.
The doc basically covers unlocking the N7, getting the build environment ready, downloading source, building, installing, and updating the source. The walkthrough is for Linux, but you should be able to do it via a virtual machine running on OS X and Windows such as Virtualbox (free).
The idea is that building Android from scratch should be possible for almost anyone to learn. So this guide walks you through it.
If you're running into difficulties, this thread is a place to exchange info, tips, questions, etc.
It's also a good place to proclaim loud and clear to the world...
"I'm running an OS I built myself from source!"
Thanks to eyeballer for reviewing.
CyberCitizen said:
Sorry for my ignorance, but besides bragging rights, what is the whole point of self compiling stock cm10 for your device?
Click to expand...
Click to collapse
Off the top of my head...
You never, ever have to wait for a nightly
You can add or remove as-yet uncommitted features with ease.
You learn how Android works under the hood
You learn how to use Linux
You'll learn how to use git
You may, even accidentally, pick up a little C, Java, C++, and learn about the build system.
You can personalize Android-- make your own tweaks, replace kernels, modules, graphics, add or remove projects, overclock, underclock etc. In other words, you have control over every aspect of your device's functionality. Your build is custom to you.
You can audit the code for potential security issues such as back doors or trojans (as opposed to just trusting a random person who posts a build). Since CM10 source is open, you can examine every commit, and there are many eyes looking at the code. (does not apply to proprietary blobs, but these are pulled from your device, so you have and are using them already)
You can contribute features/fixes back upstream
You can start ports to other as-yet-unsupported devices (start by copying folders from similar devices to devices/manufacturer/model)
You come to really understand that Android phones and tablets are full-fledged general-purpose computers just like laptops and desktops.
AAAAND....you get huge bragging rights
The extent to which you delve into the above is entirely up to you. The walkthrough is just an introduction to that world. If N7 is anything like the NookColor/NookTablet/TouchPad, some people will build once and never do it again... but others will start to tinker and make changes to their own build and want to share them with others, and soon some will start making contributions back to official CM10 upstream... or port to new devices... and by fixing bugs and all this... everyone benefits.
Plus...
It's fun.
ALSO: Here are some little bits that resulted from this thread:
Dealing with build errors
What's where in the CyanogenMod source folder
A little about make clean and make clobber
Update: A lot of the above info, as well as much more original articles, can now be found on the CyanogenMod wiki. So check there, especially the dev center.
That's it! Happy building!
How to Build CM10.1 Instructions for the Nexus 7 (CM Wiki version)
Addendum for CyanogenMod 10.2
Highly recommend fattires walkthrough. I was a total noob when I had the nook color and he initially made a build from source guide but now I know the basics and can make personal builds for my nexus 7 and epic 4g touch
Sent from my Nexus 7 using Tapatalk 2
Totally forgot I reserved this spot lol. Anyways great guide fattire. For those of u that want to learn how to build from source whether its cm, aokp, bamf, aosp or whatever u want to build this guide is a great start. While this guide is strictly for CM it will give u an understanding of the steps of building from source. Great work again fattire.
Highly highly highly recommend for anyone that loves to flash ROMs, but never built one before. fattire is one of several who have done absolute wonders for the Nook Color community. Not just developing for the device, but pulling people together to get this stuff running. :good:
I am one of the obsessives who almost didn't buy this machine when I saw they yanked the sdcard. But when fat-tire said he was getting one, I immediately went to the Play store.
His walk-thru for encore ICS was how I first learned to build. I have been building CM10 for my grouper for several weeks, although the repo sync was incomplete. I ended up having to write m own cm.mk files as well as several other weird little changes in order to make it boot. Glad those changes are finally checked I, I am going to delete my home-baked files so I can get any changes from upstream.
I have an issue I am hoping you can shed some light one, fat-tire. Inconsistencies in the ContentResolver file between my builds and those in Official Cyanogen night lies. I haven't seen any commits that change those files.
I have asked eyeballer about it, but he isn't sure either. I am building a clobber right now, but if I still have the issue, I will post particulars.
I am real glad to see you here...it has been a pretty wild and wooly forum thus far...
Whoa. How come this thread got moved from Nexus 7 Android Development to Nexus 7 General? I can't think of anything more Develop-y than building Android.
In any event- thanks all for the kind words. Mateorod, not sure from your description what issue you're having. I'll def. need more specifics.
Glad you got the N7? I am-- I use it for hours daily...
mateorod said:
I am one of the obsessives who almost didn't buy this machine when I saw they yanked the sdcard. But when fat-tire said he was getting one, I immediately went to the Play store.
His walk-thru for encore ICS was how I first learned to build. I have been building CM10 for my grouper for several weeks, although the repo sync was incomplete. I ended up having to write m own cm.mk files as well as several other weird little changes in order to make it boot. Glad those changes are finally checked I, I am going to delete my home-baked files so I can get any changes from upstream.
I have an issue I am hoping you can shed some light one, fat-tire. Inconsistencies in the ContentResolver file between my builds and those in Official Cyanogen night lies. I haven't seen any commits that change those files.
I have asked eyeballer about it, but he isn't sure either. I am building a clobber right now, but if I still have the issue, I will post particulars.
I am real glad to see you here...it has been a pretty wild and wooly forum thus far...
Click to expand...
Click to collapse
Hey, n00b builder here. First off big thanks for posting the guide I'm afraid I'm having a problem though. Once I've sync'd the cyanogenmod repo I don't seem to have "asus/grouper" in my device folder. Any idea what I could've done wrong?
Try this...
h00py said:
Hey, n00b builder here. First off big thanks for posting the guide I'm afraid I'm having a problem though. Once I've sync'd the cyanogenmod repo I don't seem to have "asus/grouper" in my device folder. Any idea what I could've done wrong?
Click to expand...
Click to collapse
Did you try the "lunch grouper" command? (you have to do . build/envsetup.sh first as described in the documents)
If this command doesn't work, you may need to add these directories to the repository manifest (a list of all the different projects that make up CM10). To add it to the list, try creating a file called local_manifest.xml in the .repo directory (it is a hidden directory as it starts with a period) and put this in the file:
<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<remote fetch="git://github.com/" name="gh" review="review.cyanogenmod.com" />
<project name="CyanogenMod/android_kernel_asus_grouper" path="kernel/asus/grouper" remote="github" revision="jellybean" />
<project name="CyanogenMod/android_device_asus_grouper" path="device/asus/grouper" remote="github" revision="jellybean" />
</manifest>
Alternately, you can do it this way from your root (~/android/system or wherever you put the source)
Code:
curl https://raw.github.com/gist/dcef0eadc4c8d31ae46d/d27a0cc718607b1a6e4958f9d0e57887b2eb4eb3/gistfile1.xml > .repo/local_manifest.xml
This local_manifest.xml file will add the needed grouper repos to the manifest. So then just repo sync again and see if they show up. If so, let me know and I'll add it to the instructions.
Update: I added it to the instructions. Let me know if it works. At some point these will be added to the official manifest so the local_manifest.xml won't be needed.
Deleted my whole source folder and started again following the updated instructions. Everything worked fine this time. It's building now and I'll report back if/when it finishes.
Thanks again for the help
h00py said:
Deleted my whole source folder and started again following the updated instructions. Everything worked fine this time. It's building now and I'll report back if/when it finishes.
Thanks again for the help
Click to expand...
Click to collapse
Heh np. Thought you didn't need to delete the folder-- the nice thing about repo sync is that it will update everything automatically, even if you change the manifest
As a linux nerd, I thank you.
TWRP2 instead of CWM
So we're back in the Android Development forum.
Update: I hear there's a non-N7-specific permissions issue (the build sets perm 0600 on /tmp) when building TWRP2 in jellybean source. Until this is resolved, consider the below purely informational. In other words, don't try it yet until the code is updated. (Thanks, eyeballer for letting me know)
-----
Here's another quick tip-- if you want to build TWRP2 recovery instead of ClockworkMod recovery for the Nexus 7, add the following two lines to the local_manifest.xml file (where the similar-looking lines are):
<remove-project name="CyanogenMod/android_bootable_recovery" />
<project path="bootable/recovery" name="TeamWin/Team-Win-Recovery-Project" remote="github" revision="master"/>
Assuming I typed that right, when you repo sync, this will replace the cwm source with the twrp source. When you then do your next build, your recovery.img in $OUT will be TWRP2. It can then be flashed with fastboot per the instructions.
Build competed & flashed with no problems. :victory:
/proud
Welcome to the club!
h00py said:
Build competed & flashed with no problems. :victory:
/proud
Click to expand...
Click to collapse
Woo! Congrats! :cyclops:
Now that you have your build going, you can try out some of the experimental commits that are sitting on CyanogenMod's code review site. These are commits with new features and bugfixes that may be experimental but need people to try them and report back if they work or not.
If you're interested in risking everything, first go to review.cyanogenmod.com AKA Gerrett and find a proposed commit that looks interesting. Read any comments or caveats that may apply, and have a look at the code itself to make sure it looks okay. Each proposed commit is part of a specific git project, listed under "Project", that correspond to directories in your source code. For example, CyanogenMod/android_frameworks_base corresponds to the repository in frameworks/base.
To try one, click on the little brown icon halfway down the web page under Downloads, on the right. This will copy the instructions to the left to the copy buffer. Then, cd to the appropriate repository directory in your source code and paste the command. It should download and commit the patch. You can check it by typing "git log" and looking for the commit at the top of the list.
If all went well, you can rebuild and hopefully will see your change in the new build. The next time you repo sync, the commit you made will be lost (unless the proposed commit actually was merged into mainstream), so if you want it again, you'll need to re-download it using the method described above.
That's it! Way to stay bleeding edge!
Hello, I have never built a rom from source before but I will use this guide and try it out. Specially since I want to use linaro.
Do you think you could link me or help me get this working? As far as I understand instead of using g++ or so I woudl use the linaro tools to compile and so. How much different would this be from your instructions?
How can I get linaro?
I'll be researching into this but I hope you can provide an answer.
Rafase282 said:
Hello, I have never built a rom from source before but I will use this guide and try it out. Specially since I want to use linaro.
Do you think you could link me or help me get this working? As far as I understand instead of using g++ or so I woudl use the linaro tools to compile and so. How much different would this be from your instructions?
How can I get linaro?
I'll be researching into this but I hope you can provide an answer.
Click to expand...
Click to collapse
I built linaro optimized cm9 for nookcolor (OMAP3) a few months back (thread starts around here). Some of the linaro optimizations to libc and the frameworks already have been added to the ICS source and I assume the Jellybean source has it already too for CM10 (and they have been adopted upstream by Google I believe as well). I haven't tried to build the grouper kernel using 4.7-- the 2.6.32 kernel and 3.0.8 kernels for NT and NC required a few minor changes-- the grouper kernel may or may not need them... but I know what to do if someone wants to try it.
Before trying linaro stuff, I would focus first on getting the build to work normally. Familiarize yourself with the process, and then investigate linaro. The system is so ridiculously fast IMO... I guess even faster is better, but I don't have any complaints
fattire said:
I built linaro optimized cm9 for nookcolor (OMAP3) a few months back (thread starts around here). Some of the linaro optimizations to libc and the frameworks already have been added to the ICS source and I assume the Jellybean source has it already too for CM10 (and they have been adopted upstream by Google I believe as well). I haven't tried to build the grouper kernel using 4.7-- the 2.6.32 kernel and 3.0.8 kernels for NT and NC required a few minor changes-- the grouper kernel may or may not need them... but I know what to do if someone wants to try it.
Before trying linaro stuff, I would focus first on getting the build to work normally. Familiarize yourself with the process, and then investigate linaro. The system is so ridiculously fast IMO... I guess even faster is better, but I don't have any complaints
Click to expand...
Click to collapse
I'm currently downloading source. It is taking its sweet time. ... nvm it just finished.
But I'm going to try to build and if everything goes well I will check into "cherry picking" and make my own personal custom build. I want to use linaro for the rom and kernel.
---------- Post added at 06:08 AM ---------- Previous post was at 05:10 AM ----------
fattire said:
So we're back in the Android Development forum.
Update: I hear there's a non-N7-specific permissions issue (the build sets perm 0600 on /tmp) when building TWRP2 in jellybean source. Until this is resolved, consider the below purely informational. In other words, don't try it yet until the code is updated. (Thanks, eyeballer for letting me know)
-----
Here's another quick tip-- if you want to build TWRP2 recovery instead of ClockworkMod recovery for the Nexus 7, add the following two lines to the local_manifest.xml file (where the similar-looking lines are):
<remove-project name="CyanogenMod/android_bootable_recovery" />
<project path="bootable/recovery" name="TeamWin/Team-Win-Recovery-Project" remote="github" revision="master"/>
Assuming I typed that right, when you repo sync, this will replace the cwm source with the twrp source. When you then do your next build, your recovery.img in $OUT will be TWRP2. It can then be flashed with fastboot per the instructions.
Click to expand...
Click to collapse
mkdir -p out/target/product/grouper/recovery/root/res/
host C: libz <= external/zlib/zutil.c
cp -fr bootable/recovery/gui/devices/common/res/* out/target/product/grouper/recovery/root/res/
cp -fr bootable/recovery/gui/devices//res/* out/target/product/grouper/recovery/root/res/
cp: cannot stat `bootable/recovery/gui/devices//res/*': No such file or directory
make: *** [out/target/product/grouper/obj/STATIC_LIBRARIES/libgui_intermediates/twrp] Error 1
make: *** Waiting for unfinished jobs....
[email protected]:~/android/system$
yup I should have read the whole post
---------- Post added at 06:30 AM ---------- Previous post was at 06:08 AM ----------
I reverted back but im still having problem building.
fattire said:
Whoa. How come this thread got moved from Nexus 7 Android Development to Nexus 7 General? I can't think of anything more Develop-y than building Android.
In any event- thanks all for the kind words. Mateorod, not sure from your description what issue you're having. I'll def. need more specifics.
Glad you got the N7? I am-- I use it for hours daily...
Click to expand...
Click to collapse
Ha, I lost the thread. They shouldn't play like that.
Yeah, I am glad. I have a project that requires java on-device, and the Nook just couldn't quite make it. But this thing can crunch through it, been though the temp spikes almost 20 degrees in the process!
I don't really want to derail all these first time Android ninjas coming out efforts. I have fund a workaround of sorts. It is just that I port some software to end users by decompiling system apps from patched builds, creating patches and applying them to end-user ROMs. Kind of a way fr people who don't or can't build to have access to certain software.
This process works like a charm on unofficial builds from any source. I pretty much could guarantee successful patching on CM9 night lies. But whenever an official RC or Final would come out, the patches would never work for those builds, while continuing to work for unofficials of the same day as well as the surrounding.
The same thing has just happened for official JB nightlies. We have tried matching the builds commit for commit, the whole thing.
I went into greater depth than I intended. If you know, awesome, if not, I will go start a thread somewhere and take it up there. This thread has a grander purpose.
Thanks!
definitely gonna give this a go on my next day off.
I started over, fresh ubuntu install and everything, I follow the steps and while it is building the computer just shutdown.
I turn it back one and try again and then I get errors.
I'm going to try again redoing the steps to see if that will fix anything.
When getting the blobs from my device I get this.
Pulling /system/vendor/lib/libwvm.so to ../../../vendor/asus/grouper/proprietary
remote object '/system/vendor/lib/libwvm.so' does not exist
Edit: got it from a stock rom I guess this is cause I'm using EOS build.
Whenever I build AOSP from source, it sticks on the "Google" screen (the actual bootloader logo, not the ROM bootanimation) and won't go further. This has happened on several build systems too (source redownloaded from the repo each time). Is it more likely to be a kernel or rom issue?
abtekk said:
Whenever I build AOSP from source, it sticks on the "Google" screen (the actual bootloader logo, not the ROM bootanimation) and won't go further. This has happened on several build systems too (source redownloaded from the repo each time). Is it more likely to be a kernel or rom issue?
Click to expand...
Click to collapse
It could be kernel. Easiest way to ascertain that is to flash a known working kernel immediately afterwards and see what happens.
rootSU said:
It could be kernel. Easiest way to ascertain that is to flash a known working kernel immediately afterwards and see what happens.
Click to expand...
Click to collapse
I left the system "booting" for a little while and I managed to get a logcat. Some major services are dying. I'll attach them.
It's probably not worth looking at logcats until you identify if the issue is ROM or kernel related. Logcats only tell you what Android is doing, not what kernels are doing. You'd need a dmesg for Kernel.
Try and flash a kernel first and see what happens. The closest to stock AOSP the better.
You should also reverse this test by taking a known working ROM and flash your kernel to it... It could be the error in your build is affecting both.
How are you installing the AOSP build? I can't remember what I did wrong, but at one point in my AOSP build attempts, I got the permissions wrong on my build.prop and what you describe is exactly what I experienced. Google screen but no boot animation, but did have logcat with multiple random looking failures. This line in your logcat is a clue:
Code:
I/DEBUG ( 168): Build fingerprint: 'unknown'
It should be mode 644:
Code:
-rw-r--r-- 1 root root 3341 Feb 24 08:53 build.prop
Did you add the vendor proprietary files? You can find these on TheMuppets github.
Sent from my HTC Desire using xda app-developers app
Chromium_ said:
Did you add the vendor proprietary files? You can find these on TheMuppets github.
Sent from my HTC Desire using xda app-developers app
Click to expand...
Click to collapse
I've never built AOSP for the Nexus, but I when I was building for the HTC deesire, I was under the impression that the google repo contained (and was designed for) everything for the Nexus one... was this not the case?
rootSU said:
I've never built AOSP for the Nexus, but I when I was building for the HTC deesire, I was under the impression that the google repo contained (and was designed for) everything for the Nexus one... was this not the case?
Click to expand...
Click to collapse
Dont believe so. When I last built for the nexus 5 using purely what was in AOSP, I encountered the same issue that this guy is having. The build will successfully compile, but wont actually boot. The solution for me atleast was to clone TheMuppets proprietary vendor repo for lg, add it to my source tree, run "make clobber", and build again.
Also on the official android building page, they instruct you to obtain the proprietary binaries prior to building, so it probably is indeed a necessary step.
Chromium_ said:
Dont believe so. When I last built for the nexus 5 using purely what was in AOSP, I encountered the same issue that this guy is having. The build will successfully compile, but wont actually boot. The solution for me atleast was to clone TheMuppets proprietary vendor repo for lg, add it to my source tree, run "make clobber", and build again.
Also on the official android building page, they instruct you to obtain the proprietary binaries prior to building, so it probably is indeed a necessary step.
Click to expand...
Click to collapse
Super, Thanks for the info.
local_manifest or roomservice
Can anyone PM me or just post his correct "local_manifest.xml" (or it called "roomservice.xml"?)
I'm failing to properly build AOSP, any of my builds result in no Broadnand service. No 3G/Data...
Thanks
I've been waiting for agrabren to drop his cm code for several months now. Guess that kid really did swallow him whole. Well, I got tired of waiting and decided to see if I could get cm to build myself. Heh, not so much. I can't even get cwm to build and boot correctly. So, I'm here to see if someone can point out what I'm doing wrong.
Here's what I did to build. Pulled CM 11.0 and set up the build directories. Copied device/nvidia and vendor/nvidia from the most recent shield tree. Copied the kernel from the shield tree into device/nvidia/roth and modified the configs to build from there. I modified some of the configs and made cm.mk based off the tf701t port which also uses a tegra 4. A lunch and a couple makes later, I got a recovery.img, but it's too big. 8.2MB won't fit in a 8 MB partition. The kernel came out at 5.9 MB and the ramdisk-recovery.img is 2.3 MB. In an official shield build, the ramdisk-recovery.img is 777KB. I know cwm has a lot more in it, but I seem to be missing something to shave 200KB off it. BoardConfig.mk has the recovery partition size set to 8MB, but that doesn't seem to make a difference. Is there something somewhere that can be used to strip less useful stuff out the recovery image?
Thanks for any help,
Steel01
Steel01 said:
I've been waiting for agrabren to drop his cm code for several months now. Guess that kid really did swallow him whole. Well, I got tired of waiting and decided to see if I could get cm to build myself. Heh, not so much. I can't even get cwm to build and boot correctly. So, I'm here to see if someone can point out what I'm doing wrong.
Here's what I did to build. Pulled CM 11.0 and set up the build directories. Copied device/nvidia and vendor/nvidia from the most recent shield tree. Copied the kernel from the shield tree into device/nvidia/roth and modified the configs to build from there. I modified some of the configs and made cm.mk based off the tf701t port which also uses a tegra 4. A lunch and a couple makes later, I got a recovery.img, but it's too big. 8.2MB won't fit in a 8 MB partition. The kernel came out at 5.9 MB and the ramdisk-recovery.img is 2.3 MB. In an official shield build, the ramdisk-recovery.img is 777KB. I know cwm has a lot more in it, but I seem to be missing something to shave 200KB off it. BoardConfig.mk has the recovery partition size set to 8MB, but that doesn't seem to make a difference. Is there something somewhere that can be used to strip less useful stuff out the recovery image?
Thanks for any help,
Steel01
Click to expand...
Click to collapse
I was previously working on cm but failed as I don't have the device. I suggest building the aosp 4.3 for the shield then work your way up to cm
http://nv-tegra.nvidia.com/gitweb/?...;a=blob_plain;f=README;hb=rel-roth-r3-partner
My idea was to see what's needed and not needed as a lot won't be used in cm.
Unjustified Dev said:
I was previously working on cm but failed as I don't have the device. I suggest building the aosp 4.3 for the shield then work your way up to cm
http://nv-tegra.nvidia.com/gitweb/?...;a=blob_plain;f=README;hb=rel-roth-r3-partner
My idea was to see what's needed and not needed as a lot won't be used in cm.
Click to expand...
Click to collapse
I've got the device and some development knowledge, but a complete lack of android build system knowledge.
I've got the nvidia 4.3 recovery to build (on a VM since it's less tolerant of JDKs than cm), the rest should compile easily enough. So if I was to build up from there, what kind of process would I be looking at? I would presume start with replacing the recovery with cwm. If so, where am I looking to replace stuff at?
Do you still have any of the work you had started?
Steel01
Steel01 said:
I've got the device and some development knowledge, but a complete lack of android build system knowledge.
I've got the nvidia 4.3 recovery to build (on a VM since it's less tolerant of JDKs than cm), the rest should compile easily enough. So if I was to build up from there, what kind of process would I be looking at? I would presume start with replacing the recovery with cwm. If so, where am I looking to replace stuff at?
Do you still have any of the work you had started?
Steel01
Click to expand...
Click to collapse
Yes, getting the recovery booting is the first thing.I can't really help right now but in a few hours or so I will pm you here's the github i'm going to be working at (removed) as you see there's not really anything there. I'm working on making the device tree work in a cm tree. It will probably be a while before my aosp build finishes. If you wish to chat on hangouts pm your email address .
Unjustified Dev said:
Yes, getting the recovery booting is the first thing.I can't really help right now but in a few hours or so I will pm you here's the github i'm going to be working at https://github.com/CM-Shield as you see there's not really anything there. I'm working on making the device tree work in a cm tree. It will probably be a while before my aosp build finishes. If you wish to chat on hangouts pm your email address .
Click to expand...
Click to collapse
Thanks, pm sent. Guess I'll fire off a full aosp build so we'll have the same trees available at that time.
Steel01
Edit: Today's just not my day. None of my builds from nvidia's aosp 4.3 r3 tree boot. A normal boot hangs at the shield logo. The recovery gives me the red triangle (not terribly surprised since nvidia's official gives me that too, only agrabren's cwm recovery works for me). I didn't think too much of it when I built off of openjdk 1.6, but now that I pulled sun's 1.6-41 and it still doesn't boot, I'm a bit miffed. Shouldn't be a reason why I can't build off CentOS. Maybe I'll load up a Debian or Mint VM and try building off that. I really don't want to touch Ubuntu which all the android docs are written for...
Okay, so I don't feel so bad anymore. The kernel boots fine. But the system image generated from the official shield tree doesn't. It starts the boot animation and hangs. But I have adb and complete shell access. Wipes don't help. Which if I was to guess means I have a java problem on the build VM. The C only kernel is fine, but nothing else works right. Big surprise there. That or something like the graphics blob didn't get packaged in. I'll play with it some more and might be able to build a working system by the time Unjustified Dev pushes some code up...
Steel01
Edit: And according to a logcat, I'm missing some so's. Don't know if I missed a build failure or if the official tree is broken.
Steel01 said:
Okay, so I don't feel so bad anymore. The kernel boots fine. But the system image generated from the official shield tree doesn't. It starts the boot animation and hangs. But I have adb and complete shell access. Wipes don't help. Which if I was to guess means I have a java problem on the build VM. The C only kernel is fine, but nothing else works right. Big surprise there. That or something like the graphics blob didn't get packaged in. I'll play with it some more and might be able to build a working system by the time Unjustified Dev pushes some code up...
Steel01
Edit: And according to a logcat, I'm missing some so's. Don't know if I missed a build failure or if the official tree is broken.
Click to expand...
Click to collapse
Did you get the closed source binaries extracted?
Unjustified Dev said:
Did you get the closed source binaries extracted?
Click to expand...
Click to collapse
Yeah I did. I'm running another build and capturing the output this time to see if there's a build failure. The files the log was complaining about are in a vendor prebuilt folder, but didn't get copied to out like most of the other files in that directory did. If this build does the same, I'll hand copy the files into the out directory and hope the command to build the system image just globs that directory.
Steel01
Steel01 said:
Yeah I did. I'm running another build and capturing the output this time to see if there's a build failure. The files the log was complaining about are in a vendor prebuilt folder, but didn't get copied to out like most of the other files in that directory did. If this build does the same, I'll hand copy the files into the out directory and hope the command to build the system image just globs that directory.
Steel01
Click to expand...
Click to collapse
I suggest creating a better call to vendor blobs you can clearly find which ones are needed create an extract-files.sh script as so. I've began partially haven't had time to work on it. I chose a nvidia device because some of the blobs are the same naming less time.
https://github.com/CyanogenMod/android_device_asus_tf700t/blob/cm-11.0/extract-files.sh
https://github.com/CyanogenMod/android_device_asus_tf700t/blob/cm-11.0/proprietary-files.txt
https://github.com/CyanogenMod/android_device_asus_tf700t/blob/cm-11.0/setup-makefiles.sh
Unjustified Dev said:
I suggest creating a better call to vendor blobs you can clearly find which ones are needed create an extract-files.sh script as so. I've began partially haven't had time to work on it. I chose a nvidia device because some of the blobs are the same naming less time.
https://github.com/CyanogenMod/android_device_asus_tf700t/blob/cm-11.0/extract-files.sh
https://github.com/CyanogenMod/android_device_asus_tf700t/blob/cm-11.0/proprietary-files.txt
https://github.com/CyanogenMod/android_device_asus_tf700t/blob/cm-11.0/setup-makefiles.sh
Click to expand...
Click to collapse
Ah, okay. It would be better to base off the tf701t, though. It's a tegra 4 device whereas the tf700t is a tegra 3. I'll see what I come up with after I flash stock back.
Steel01
Steel01 said:
Ah, okay. It would be better to base off the tf701t, though. It's a tegra 4 device whereas the tf700t is a tegra 3. I'll see what I come up with after I flash stock back.
Steel01
Click to expand...
Click to collapse
Actually I was just looking at it. We have an advantage we already have a device tree and I like their layout so I'm going to copy that when I have time and build from it.
Still some unsolved things I will discuss later
Unjustified Dev said:
Actually I was just looking at it. We have an advantage we already have a device tree and I like their layout so I'm going to copy that when I have time and build from it.
Still some unsolved things I will discuss later
Click to expand...
Click to collapse
Yeah, that would make it much simpler. I had that device tree building inside the cm11 repo a couple days ago, but I broke the kernel build somewhere along the way and haven't figured out what I did yet.
I'm currently working on getting the blob list together. Skimming the tf701t down to what exists on the shield, then building up from there. Will probably take a couple days with my schedule though, so you might beat me through it.
Steel01
Steel01 said:
Yeah, that would make it much simpler. I had that device tree building inside the cm11 repo a couple days ago, but I broke the kernel build somewhere along the way and haven't figured out what I did yet.
I'm currently working on getting the blob list together. Skimming the tf701t down to what exists on the shield, then building up from there. Will probably take a couple days with my schedule though, so you might beat me through it.
Steel01
Click to expand...
Click to collapse
I got latest ota image from nvidia and extracted the system.img will be tomorrow when I finish gathering all blobs and I will send you a pm. once we get cwm working we can move forward wish the guy who compiled it got a change to upload his source so I can see how to do the dtb stuff . I know someone who can help I will contact them tomorrow
Unjustified Dev said:
I got latest ota image from nvidia and extracted the system.img will be tomorrow when I finish gathering all blobs and I will send you a pm. once we get cwm working we can move forward wish the guy who compiled it got a change to upload his source so I can see how to do the dtb stuff . I know someone who can help I will contact them tomorrow
Click to expand...
Click to collapse
Okay, great. I Got a hack of cm build together using the attached proprietary-files.txt and a prebuilt kernel from the shield tree. Ended up missing a couple so's, but I'm done for the night. Once you get the device tree to compile, can you push that to the github org and give me access to it?
On the dtb issues, doesn't the normal kernel compile output the dtb?
The official BoardConfig sets:
TARGET_USE_DTB := true
TARGET_KERNEL_DT_NAME := tegra114-roth
BOOTLOADER_SUPPORTS_DTB := true
Then kernel.mk sets:
KERNEL_DTS_PATH := $(KERNEL_PATH)/arch/$(TARGET_ARCH)/boot/dts/$(TARGET_KERNEL_DT_NAME).dts
BUILT_KERNEL_DTB := $(NV_KERNEL_INTERMEDIATES_DIR)/arch/$(TARGET_ARCH)/boot/$(TARGET_KERNEL_DT_NAME).dtb
and further down calls
+$(hide) $(kernel-make) $(TARGET_KERNEL_DT_NAME).dtb
That correctly gives me the dtb file. Though, chances are there are other lines I missed that affect it.
Steel01
Steel01 said:
Okay, great. I Got a hack of cm build together using the attached proprietary-files.txt and a prebuilt kernel from the shield tree. Ended up missing a couple so's, but I'm done for the night. Once you get the device tree to compile, can you push that to the github org and give me access to it?
On the dtb issues, doesn't the normal kernel compile output the dtb?
The official BoardConfig sets:
TARGET_USE_DTB := true
TARGET_KERNEL_DT_NAME := tegra114-roth
BOOTLOADER_SUPPORTS_DTB := true
Then kernel.mk sets:
KERNEL_DTS_PATH := $(KERNEL_PATH)/arch/$(TARGET_ARCH)/boot/dts/$(TARGET_KERNEL_DT_NAME).dts
BUILT_KERNEL_DTB := $(NV_KERNEL_INTERMEDIATES_DIR)/arch/$(TARGET_ARCH)/boot/$(TARGET_KERNEL_DT_NAME).dtb
and further down calls
+$(hide) $(kernel-make) $(TARGET_KERNEL_DT_NAME).dtb
That correctly gives me the dtb file. Though, chances are there are other lines I missed that affect it.
Steel01
Click to expand...
Click to collapse
I read that from the OC kernel thread and it's 1am here so I'm done for the night as well. I am giving you permission to CM-Shield right now. I already cloned tf701 device tree and renamed it. I was working on adding in the files from nvidia tree some are going to go prebuilt might need some patches from nvidia git as well not so sure right now. I really need to get this device. Blindly working isn't much fun. As far as I know you use fastboot flash dtb that dtb is never updated and might not be needed not sure yet I have never had to deal with dtb.
Unjustified Dev said:
I read that from the OC kernel thread and it's 1am here so I'm done for the night as well. I am giving you permission to CM-Shield right now. I already cloned tf701 device tree and renamed it. I was working on adding in the files from nvidia tree some are going to go prebuilt might need some patches from nvidia git as well not so sure right now. I really need to get this device. Blindly working isn't much fun. As far as I know you use fastboot flash dtb that dtb is never updated and might not be needed not sure yet I have never had to deal with dtb.
Click to expand...
Click to collapse
Alright. If you haven't got the dtb stuff straightened out by the time I get back to my dev machine tomorrow night, I'll tackle that. I've had some hobbyist experience with that on some embedded dev boards. In general, I wouldn't think the dtb would ever change. Definitely not within a kernel version. Definitely needed, though. But in the spirit of open source and building as much as possible from source, it will be good to make that build. Shouldn't be too difficult. And yes, 1:30 AM does bad things to cognizance. *passes out*
Steel01
Edit: I took a look at the tf701t kernel tree this morning. The dtb part may already be done if we base from there. A dts file already exists for roth (arch/arm/boot/dts) and the make file a dir up appears to glob the dts directory and build dtb's for each. I don't have access to a build tree to verify that atm, though. Bit if that's true, the kernel should be as simple as cloning tf701t, renaming its defconfig and modifying what little differences there are if any, then copying the dtb to the out directory.
Edit 2: A bit of googling turned up http://www.armadeus.com/wiki/index.php?title=Kernel-with-device-tree which says a config flag handles building dtb's. The tf701t config already sets CONFIG_MACH_ROTH=y, so I'm wondering if that kernel won't boot on the shield out of the box. Something I'll try once I get back to my dev machine tonight.
Well, I did get the dtb to build using the CM-Shield device tree and the kernel from tf701t. Haven't been able to test yet, though. And it was kind of a hack, but I don't know a better place to plug it than modules. In BoardConfig.mk after the two target kernel lines:
KERNEL_DTB:
*tab* make -C $(KERNEL_OUT) ARCH="arm" CROSS_COMPILE="arm-eabi-" tegra114-roth.dtb
*tab* mv $(KERNEL_OUT)/arch/arm/boot/tegra114-roth.dtb $(OUT)
TARGET_KERNEL_MODULES := KERNEL_DTB
That should probably pull arch and compiler prefix from cm env cars, but I don't know what they are. The dtb name should also be set as a const. Once I see if the kernel boots in a couple hours, I'll push my device branch up. Only kernel change was renaming the defconfig.
Steel01
Steel01 said:
Well, I did get the dtb to build using the CM-Shield device tree and the kernel from tf701t. Haven't been able to test yet, though. And it was kind of a hack, but I don't know a better place to plug it than modules. In BoardConfig.mk after the two target kernel lines:
KERNEL_DTB:
*tab* make -C $(KERNEL_OUT) ARCH="arm" CROSS_COMPILE="arm-eabi-" tegra114-roth.dtb
*tab* mv $(KERNEL_OUT)/arch/arm/boot/tegra114-roth.dtb $(OUT)
TARGET_KERNEL_MODULES := KERNEL_DTB
That should probably pull arch and compiler prefix from cm env cars, but I don't know what they are. The dtb name should also be set as a const. Once I see if the kernel boots in a couple hours, I'll push my device branch up. Only kernel change was renaming the defconfig.
Steel01
Click to expand...
Click to collapse
So far going to push unmodified kernel now https://github.com/CM-Shield/android_device_nvidia_roth
Progress finally. Got a cwm recovery that boots and looks like it works plus fits in the partition. Most of the buttons aren't mapped yet and the screen is rotated, but that should be the east part to fix.
Steel01
Getting closer. But still no dice. Logcat of current iteration.
Steel01
Haii guys!
So, i'm young "kernel developer".. I am actually not a coder, i just try to learn by making kernels and if they are stable enough i test them. So, till now i was working with Mako source - i had phone lg optimus g which i really close to mako and i based everything on Mako source.
Now i bought a new phone, Nexus 5. I am really satisfied by this phone on stock, but even more on custom ROM & Kernel.. But hey, it's me, i'm curious and i have to try to make stuff myself, so i choose to make my own kernel for Nexus 5.. More to learn than anything.
So, i started.. I forked this to my github and do some basic changes for me.. Just to start. I added graphite support and option to build with Linaro 4.9.4.. And i started to build. And it had some errors, so i also fixed them - fs/namespace.c error with 4.9 toolchains, so, i fixed it and it built with no trouble.
So, i was coming from world of Mako and took zImage, made a flashable zip with AnyKernel and flashed it.. And i was stuck at google logo with unlock icon. I restored twrp backup of previous kernel and started over and it booted normally...
Then i did some research and found out that i should use zImage-dtb because Nexus 5 uses something named device tree blob.. So, i did everything from scratch.
I forked same source as before, and did my changes over it.. Renamed kernel, added kernel build script, made my slightly modified defconfig, this time i used toolchain LinaroMod 4.9 from here and some other stuff.. I built with no trouble, used zImage-dtb as zImage in flashable zip as i saw in other kernels and flashed.. I was sure it will boot this time, none of those modifications was supposed to break anything.. But again, I am stuck at Google logo.
Have any of you guys any idea where i missed? Maybe wrong source? Wrong toolchain?
Here are some maybe useful links:
My source: https://github.com/Matthew-333/BlueMoon
My Changes: https://github.com/Matthew-333/BlueMoon/commits/master
Toolchain: https://github.com/hyper-toolchains/LinaroMod-arm-eabi-4.9
AnyKernel Template: https://github.com/koush/AnyKernel
I am using xUbuntu 15.04 64 bit..
Thank you if anybody manage to help me with this...
Matthew_333 said:
Haii guys!
So, i'm young "kernel developer".. I am actually not a coder, i just try to learn by making kernels and if they are stable enough i test them. So, till now i was working with Mako source - i had phone lg optimus g which i really close to mako and i based everything on Mako source.
Now i bought a new phone, Nexus 5. I am really satisfied by this phone on stock, but even more on custom ROM & Kernel.. But hey, it's me, i'm curious and i have to try to make stuff myself, so i choose to make my own kernel for Nexus 5.. More to learn than anything.
So, i started.. I forked this to my github and do some basic changes for me.. Just to start. I added graphite support and option to build with Linaro 4.9.4.. And i started to build. And it had some errors, so i also fixed them - fs/namespace.c error with 4.9 toolchains, so, i fixed it and it built with no trouble.
So, i was coming from world of Mako and took zImage, made a flashable zip with AnyKernel and flashed it.. And i was stuck at google logo with unlock icon. I restored twrp backup of previous kernel and started over and it booted normally...
Then i did some research and found out that i should use zImage-dtb because Nexus 5 uses something named device tree blob.. So, i did everything from scratch.
I forked same source as before, and did my changes over it.. Renamed kernel, added kernel build script, made my slightly modified defconfig, this time i used toolchain LinaroMod 4.9 from here and some other stuff.. I built with no trouble, used zImage-dtb as zImage in flashable zip as i saw in other kernels and flashed.. I was sure it will boot this time, none of those modifications was supposed to break anything.. But again, I am stuck at Google logo.
Have any of you guys any idea where i missed? Maybe wrong source? Wrong toolchain?
Here are some maybe useful links:
My source: https://github.com/Matthew-333/BlueMoon
My Changes: https://github.com/Matthew-333/BlueMoon/commits/master
Toolchain: https://github.com/hyper-toolchains/LinaroMod-arm-eabi-4.9
AnyKernel Template: https://github.com/koush/AnyKernel
I am using xUbuntu 15.04 64 bit..
Thank you if anybody manage to help me with this...
Click to expand...
Click to collapse
Hi, thanks for using XDA assist!
Please have a look here for some useful information:
http://forum.xda-developers.com/android/software/ultimate-guide-compile-android-kernel-t2871276
Good luck!
Quick Camera Fix #1
Installation:
1. Download CM13 based ROM made by transi1
2. Open and replace files from temp_camera_fix_from_BEANSTALK_6.20.zip to the ROM of your choice respectively (flashing doesn't work)
3. Flash ROM, GApps etc.
4. After installation of ROM, install Open Camera or other 3rd party camera app
DOWNLOAD #1
temp_camera_fix_from_BEANSTALK_6.20.zip
Description:
This is basically a 3.0.72+ kernel from BeanStalk 6.20
IT WAS TESTED ON: RR 5.7.3, Bliss ROM
USING TWRP 3.0.2-1 WITHOUT TEMP_TOUCH_FIX
DOWNLOAD #2
temp_camera_fix_from_RR_5.6.5.zip
Description:
This is basically a 3.0.72+ kernel from RR 5.6.5
DOWNLOAD #3
temp_camera_fix_from_AICP_11.0.zip
Description:
This is basically a 3.0.72+ kernel from AICP 11.0
Want to support development? You can consider donating, my email is [email protected]. I spent countless of hours with this
NOTE: Fix from BeanStalk 6.20 is updated (deep sleep issue fixed).
-------------------------------------------------------------------------------------------------------------------------------------------------
Quick Camera Fix #2
FLASHABLE ZIP
-------------------------------------------------------------------------------------------------------------------------------------------------
NOUGAT EMOJI FLASHABLE ZIP
-------------------------------------------------------------------------------------------------------------------------------------------------
OMNISWITCH FLASHABLE ZIP
-------------------------------------------------------------------------------------------------------------------------------------------------
THREAD CLOSED
Interesting workaround. If it works, it's even more evident that we're dealing with the 3.0.101+ kernel. I'm still planning on going through with that kernel backtracking to see which version or commit started this mess, and once I find it, report it so we can hopefully work through this. IIRC, those files were compiled against the 3.0.72+ kernel, so they might be a little old. Can someone try out the patch and see how it affects stability?
monster1612 said:
Interesting workaround. If it works, it's even more evident that we're dealing with the 3.0.101+ kernel. I'm still planning on going through with that kernel backtracking to see which version or commit started this mess, and once I find it, report it so we can hopefully work through this. IIRC, those files were compiled against the 3.0.72+ kernel, so they might be a little old. Can someone try out the patch and see how it affects stability?
Click to expand...
Click to collapse
2016/02/20 is the date of creation of last AICP. So, we need to find commits since that date and before.
alexander_32 said:
2016/02/20 is the date of creation of last AICP. So, we need to find commits since that date and before.
Click to expand...
Click to collapse
I already forked the repos prior to the post-3.0.72+ commits. I'll link in the manifest file I created if you're interested in building against them.
monster1612 said:
I already forked the repos prior to the post-3.0.72+ commits. I'll link in the manifest file I created if you're interested in building against them.
Click to expand...
Click to collapse
Yes, bring it, please.
alexander_32 said:
Yes, bring it, please.
Click to expand...
Click to collapse
Here's the manifest file for building against those repos. I'm going to backtrack through the commits by forking the original repos at different points in time. Obviously, the old repos I forked before the 3.0.101+ commits are going to stay as they are for the time being until the issue is pinpointed and fixed once and for all. After that, I plan on deleting the manifest file and repos. Make sure that you run repo sync --force-sync on your build tree after replacing the manifest file and make clean to revert the kernel, or you'll still have remnants of 3.0.101+ lurking in the builds.
monster1612 said:
Here's the manifest file for building against those repos. I'm going to backtrack through the commits by forking the original repos at different points in time. Obviously, the old repos I forked before the 3.0.101+ commits are going to stay as they are for the time being until the issue is pinpointed and fixed once and for all. After that, I plan on deleting the manifest file and repos. Make sure that you run repo sync --force-sync on your build tree after replacing the manifest file and make clean to revert the kernel, or you'll still have remnants of 3.0.101+ lurking in the builds.
Click to expand...
Click to collapse
Thanks.
Like I said to @alexander_32, I tried reverting the u-boot.bin commits that Transi made a couple months back for the aicp build. It booted, ran really slow, and OpenCamera still saw the camera module as being in use. Using the current boot binary things run nice and fast again. The build I ran off last night testing a couple more things also did not have any effect on camera...
electrikjesus said:
Like I said to @alexander_32, I tried reverting the u-boot.bin commits that Transi made a couple months back for the aicp build. It booted, ran really slow, and OpenCamera still saw the camera module as being in use. Using the current boot binary things run nice and fast again. The build I ran off last night testing a couple more things also did not have any effect on camera...
Click to expand...
Click to collapse
Probably it something else. Did you check my method by the way?
electrikjesus said:
Like I said to @alexander_32, I tried reverting the u-boot.bin commits that Transi made a couple months back for the aicp build. It booted, ran really slow, and OpenCamera still saw the camera module as being in use. Using the current boot binary things run nice and fast again. The build I ran off last night testing a couple more things also did not have any effect on camera...
Click to expand...
Click to collapse
What'd you happen to test with last night's build? Also, was it my u-boot commit that caused the problems or before that?
monster1612 said:
What'd you happen to test with last night's build? Also, was it my u-boot commit that caused the problems or before that?
Click to expand...
Click to collapse
I tested a couple of camera specific build tags in bowser common and tate. They didn't work. When I get a chance later on, I plan on diving into it again.
@alexander_32: Not sure why, but I can't boot using this with the rom you posted here. It stays on the boot logo indefinitely. After a clean install and making sure it boots fine once, I'm manually flashing the boot.img in the zip and copying the contents of the modules dir while fixing permissions afterwards. Is that all there is to it or am I missing something?
r3t3ch said:
@alexander_32: Not sure why, but I can't boot using this with the rom you posted here. It stays on the boot logo indefinitely. After a clean install and making sure it boots fine once, I'm manually flashing the boot.img in the zip and copying the contents of the modules dir while fixing permissions afterwards. Is that all there is to it or am I missing something?
Click to expand...
Click to collapse
You just extracting all files from camera fix, then update cm13.0 flashable zip with files from camera fix and flash flashable zip. It worked on Temasek's CM13. I'll do more researches and inform about results.
alexander_32 said:
You just extracting all files from camera fix, then update cm13.0 flashable zip with files from camera fix and flash flashable zip. It worked on Temasek's CM13. I'll do more researches and inform about results.
Click to expand...
Click to collapse
Ah, I read the OP wrong and wasn't merging into the rom zip but manually into existing installation. Though even now, I still can't boot after trying it with plain cm13, beanstalk, or temasek. I'm using twrp 2.8.7.0 with cache and data both f2fs if that makes any difference.
Has anyone else had success so far and if so with which roms?
r3t3ch said:
Ah, I read the OP wrong and wasn't merging into the rom zip but manually into existing installation. Though even now, I still can't boot after trying it with plain cm13, beanstalk, or temasek. I'm using twrp 2.8.7.0 with cache and data both f2fs if that makes any difference.
Has anyone else had success so far and if so with which roms?
Click to expand...
Click to collapse
I guess now I understand what happened. I flashed my fix first, then did factory reset and flashed changed zip. I'll test it and inform what happened
CONFIRMED: It's 3.0.72+ kernel.
http://i66.tinypic.com/33mwkyw.png
http://i64.tinypic.com/33u8qow.png
CONFIRMED: PAC ROM MM works!
http://i66.tinypic.com/2n8v5uf.png
CONFIRMED: Cyanogenmod works!
http://i64.tinypic.com/2eunbz9.png
CONFIRMED: BeanStalk works! (Solution was a kernel from RR 5.6.5 with blue logo)
http://i67.tinypic.com/107rwx2.png
alexander_32 said:
UNBELIEVABLE! It works on Temasek only! But I'm not done yet. Need some time to think.
Confirmed: It's 3.0.72+ kernel.
http://i66.tinypic.com/33mwkyw.png
http://i64.tinypic.com/33u8qow.png
I'll update this thread with more information.
Click to expand...
Click to collapse
I'm thinking it doesn't work on transi's RR or CM13 builds because he disabled the camera with some commits that he hasn't pushed to GitHub. Either way, those builds are built with 3.0.101+, and the patches you brought in are from 3.0.72+. It would make sense if they didn't boot after patching (especially if you flash the boot.img). What happens if you just replace the files in /system and leave the boot image intact?
monster1612 said:
I'm thinking it doesn't work on transi's RR or CM13 builds because he disabled the camera with some commits that he hasn't pushed to GitHub. Either way, those builds are built with 3.0.101+, and the patches you brought in are from 3.0.72+. It would make sense if they didn't boot after patching (especially if you flash the boot.img). What happens if you just replace the files in /system and leave the boot image intact?
Click to expand...
Click to collapse
My builds work with 3.0.101+ as well, but Temasek's works and BeanStalk doesn't (with 3.0.72+). Yes, I'll try it.
monster1612 said:
I'm thinking it doesn't work on transi's RR or CM13 builds because he disabled the camera with some commits that he hasn't pushed to GitHub. Either way, those builds are built with 3.0.101+, and the patches you brought in are from 3.0.72+. It would make sense if they didn't boot after patching (especially if you flash the boot.img). What happens if you just replace the files in /system and leave the boot image intact?
Click to expand...
Click to collapse
I tried that yesterday, and it results in never getting to the boot animation, so the kernel never loads.
5 from 7 for today. A new link https://www.androidfilehost.com/?fid=24591000424949408