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
Related
Hey guys i need a little guidance. I'm trying to compile a SGS4G version of the CM10.1 ROM ive been building for the grouper and running in to some issues. For now Im using airfluip1's Kernel and device tree with source from CM and my Github. To narrow down the issues I swiched back to the stock 4.6 toolchain till i can get this working. It builds fine with no errors but comparing it to airfluip1's roms zip file i only have the boot.img, system folder, and META-INF folder. When i add the missing files like ex: updater.sh, modem.bin, bml_over_mtd.sh...etc wont go past the splash screen and dosent even make it to the bootanimation :crying: and i end up loseing CWM. if i switch my boot.img out with airfluip1's it fixes everything, boots right up, CWM is working properly, and the ROM is fine other than the Known CM10.1 bugs like multiple text, network issues. I never compiled a ROM that had the recovery with the boot.img and don't know if there's someting special you have to do with it to get it to work. any help is appreciated thanks guys
It might be that the latest kernel commits cause the rom not to boot. If you look up a guide on how to do a git reset in the kernel directory you might be able to compile a bootimage that works fine.
The kernel source is under
kernel/samsung/galaxys4gmtd
If you do a git log in that directory you will see the commit history with the hashes for each commit. If you do
git reset --hard sha1_hash
You can go back to a previously working commit, which might be trial and error
To speed up your testing process, instead of compiling the whole rom again you can try doing a
mka bootimage
Instead of
mka bacon
As far as the missing files, I don't have any input on that.
I'm finally back with my build rig and I finished syncing cm10.1 last night so I'll be trying to get some builds going tonight too.
FBis251 said:
It might be that the latest kernel commits cause the rom not to boot. If you look up a guide on how to do a git reset in the kernel directory you might be able to compile a bootimage that works fine.
The kernel source is under
kernel/samsung/galaxys4gmtd
If you do a git log in that directory you will see the commit history with the hashes for each commit. If you do
git reset --hard sha1_hash
You can go back to a previously working commit, which might be trial and error
To speed up your testing process, instead of compiling the whole rom again you can try doing a
mka bootimage
Instead of
mka bacon
As far as the missing files, I don't have any input on that.
I'm finally back with my build rig and I finished syncing cm10.1 last night so I'll be trying to get some builds going tonight too.
Click to expand...
Click to collapse
Thanks for the reply ... I've been having this issue for almost a week.. I might have set it up wrong I've been just doing brunch galaxys4gmtd to start the build. I'll have to look into mka. Should the kernel source be in kernel/samsung/galaxys4gmtd? In his device/samsung/galaxys4gmtd/BoardConfig.mk its targeting the kernel source to kernel/samsung/aries so that where I put it
EDIT: Was just set up weird by me...had to re add the vendersetup.sh back that he deleted from the device tree, did a lunch full_galaxys4gmtd-userdebug, then brunch galaxys4gmtd, and it compiled fine with the files I was missing and the kernel booted :beer:
Sent from my Nexus7 using Tapatalk HD
DJLamontagneIII said:
Thanks for the reply ... I've been having this issue for almost a week.. I might have set it up wrong I've been just doing brunch galaxys4gmtd to start the build. I'll have to look into mka. Should the kernel source be in kernel/samsung/galaxys4gmtd? In his device/samsung/galaxys4gmtd/BoardConfig.mk its targeting the kernel source to kernel/samsung/aries so that where I put it
EDIT: Was just set up weird by me...had to re add the vendersetup.sh back that he deleted from the device tree, did a lunch full_galaxys4gmtd-userdebug, then brunch galaxys4gmtd, and it compiled fine with the files I was missing and the kernel booted :beer:
Sent from my Nexus7 using Tapatalk HD
Click to expand...
Click to collapse
Awesome, I'm glad you got it working. . I haven't tried an aries build yet, but yes BoardConfig.mk is correct. You should try doing:
lunch cm_galaxys4gmtd-userdebug
mka bacon
I'm not sure, but the full_ prefix might be preventing the files that help flash the rom to be included with the zip file.
good job.
Also, yes kernel should be in kernel/samsung/aries.
EDIT: it is a smart decision not to use my airfluip1 stuff, and rather those from teamuserdebug.
Why, well, my latest kernel tree was only used to pull request to anak1n, so it is not even the kernel with my changes. So FFC/Compass/latests fixes won't be there.
Also, you might be using the common aries common from cyanogenmod... FFC from device tree side will be borked, and Aries Parts won't work.
Please use teamuserdebugs repos.
---------- Post added at 10:10 PM ---------- Previous post was at 10:05 PM ----------
FBis251 said:
Awesome, I'm glad you got it working. . I haven't tried an aries build yet, but yes BoardConfig.mk is correct. You should try doing:
lunch cm_galaxys4gmtd-userdebug
mka bacon
I'm not sure, but the full_ prefix might be preventing the files that help flash the rom to be included with the zip file.
Click to expand...
Click to collapse
Or brunch cm_galaxys4gmtd-eng
which runs both commands, and the eng builds are better since you have a debuggable kernel.
Thanks for the tip i used team userdebug's repos and roms been running great haven't had time to mess with the updated toolchains yet but il have something up to play with in a day or two
Sent from my SGH-T959V using Tapatalk 4 Beta
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
[ROM][7.1][UNOFFICIAL] CM14.1 for Nexus 7 2012 (grouper)
*** Disclamer
By downloading and installing this ROM you agree that you do so at
your own risk, and that you understand that it probably voids your
warranty. (But does anyone still have an active warranty on this 2012
device?)
Introduction
@AndDiSa's AOSP 7 builds look pretty nice, but I needed something that seamlessly upgrades from CM13. @GtrCraft who provided our CM13 builds has moved on to other devices, so we need a new CM maintainer. I may not be the right person for that job... but I can at least share the build I made for myself. Perhaps someone will be motivated to join the fun or even take over.
[Images on screenshots tab.]
Installation instructions
Back up your data and previous ROM with TWRP 3.0.2.
Download from link below.
Wipe system, cache, dalvik.
Also wipe data unless you are coming from CM13.
Install the ROM.
Optionally add opengapps-pico.
With default settings it will give an error about insufficient space. To avoid that, first copy this gapps-config-grouper.txt file, perhaps edit it to your taste (instructions here), then copy to the device in the same directory as the opengapps zip. The opengapps updater-script will look for it there when you install opengapps.
Reboot.
WAIT for system to settle before you decide it is slow. Some of the app optimization which used to happen during initial boot now seems to happen in the background. When it's finished, responsiveness will improve.
Download
cm-14.1-20161226-UNOFFICIAL-grouper.zip (AndroidFileHost)
Credits / Thanks
Google / AOSP
CyanogenMod
@AndDiSa for AOSP 7.1 -- I use his kernel tree directly, and many of his device tree mods
@GtrCraft for the CM13 tree upon which mine is based
XDA:DevDB Information
Unofficial CM14.1 for Nexus 7, ROM for the Nexus 7
Contributors
aaopt, AndDiSa,GtrCraft
Source Code: https://github.com/aperomsik/cyanogenmod_android_device_asus_grouper/
ROM OS Version: 7.x Nougat
ROM Kernel: Linux 3.1.x
Based On: CyanogenMod
Version Information
Status: Testing
Created 2016-11-25
Last Updated 2016-12-31
Reserved
Changelog
Nearly all builds include CM sync -- only mentioned specifically when it was the main point of the build.
20161226 (AndroidFileHost)
LiveDisplay works (due to upstream work).
20161212 (AndroidFileHost)
NFC
20161208 (AndroidFileHost)
CM sync, including 7.1.1r4
20161130 (AndroidFileHost)
Stock camera works.
20161125 (DevHost)
Initial posting.
seems to be pretty stable so far but i cant get pico gapps to install even after installing the rom with the gapps-config.
There is a 3.4 kernel build for grouper which was helpful for cm13. Can you incorporate that into your build ?
why is this not even on development thread?
is this based on anddisa's device,vendor trees? cuz that build is super fast. i am downloading anyway.
turnert said:
seems to be pretty stable so far but i cant get pico gapps to install even after installing the rom with the gapps-config.
Click to expand...
Click to collapse
Sorry about that. I meant to say .gapps-config goes with the gapps zip, not with the ROM. Corrected, and also edited for clarity. If it still doesn't work for you, look at the log file it generates in the same folder as the zip, and make sure it says it read your config file.
abhifx said:
why is this not even on development thread?
Click to expand...
Click to collapse
I had originally put it in development, but it took me too long to fill in the devdb new project page... after it made me reload the page and reenter some things, apparently I wound up in general by mistake.
abhifx said:
is this based on anddisa's device,vendor trees? cuz that build is super fast. i am downloading anyway.
Click to expand...
Click to collapse
Yes, when I saw how fast @AndDiSa's AOSP 7 ROM was, I had to try a CM14 build. I'm using his kernel and vendor trees, and many of his recent device tree commits cherry-picked into a fork of @GtrCraft's CM13 device tree.
Requested mods to move this to development section.
Also can't install gapps with the given script. Anyone up for new gapps zip?
abhifx said:
Also can't install gapps with the given script. Anyone up for new gapps zip?
Click to expand...
Click to collapse
Please pastebin your resulting open_gapps_log.txt, and send me the link . You should find the log file on the device in the directory where you had put the gapps zip and config files. For comparison, mine is here.
aaopt said:
Please pastebin your resulting open_gapps_log.txt, and send me the link . You should find the log file on the device in the directory where you had put the gapps zip and config files. For comparison, mine is here.
Click to expand...
Click to collapse
will post it in the evening, i dont think gapps is picking up the config file, should the config file go inside the zip file? i am just pasting it outside the zip file.
Frankly the ROM is working fine, however i have yet to lock gps and test it which is my main usage.
After seeing CM booting, i would love to see other derived ROMs (AICp, RR etc)
Maybe you can post a guide others may build it too (i dont have the disk space or the bandwidth to do it anyway)
abhifx said:
will post it in the evening, i dont think gapps is picking up the config file, should the config file go inside the zip file? i am just pasting it outside the zip file.
Frankly the ROM is working fine, however i have yet to lock gps and test it.
Click to expand...
Click to collapse
Not in the zip file... Just alongside, in the same folder on the device (or usb stick if you install via OTG) where the Gapps zip is.
Sent from my MotoG3 using Tapatalk
The config files name needs to be "gapps-config.txt" or ".gapps-config". I just tried the first option an gapps installed just fine!
abhifx said:
will post it in the evening, i dont think gapps is picking up the config file, should the config file go inside the zip file? i am just pasting it outside the zip file.
Click to expand...
Click to collapse
I was having issues as well with the config file. I tried putting it in all kinds of places, but no dice.
I ended up using the Aroma Open Gapps package which worked great.
Haven't tried much on this ROM yet, but things feel snappy.
hawkshot said:
I was having issues as well with the config file. I tried putting it in all kinds of places, but no dice.
I ended up using the Aroma Open Gapps package which worked great.
Haven't tried much on this ROM yet, but things feel snappy.
Click to expand...
Click to collapse
ah yes.. Aroma Gapps, which keeps on cancelling this huge package. oh well will try renaming the text file
---------- Post added at 01:25 PM ---------- Previous post was at 12:49 PM ----------
ok this was even more weird, i copied the files in a separate directory (the config file was in txt format as suggested by @gothier) and this worked. earlier everything was in the root directory and nothing worked no matter was was the file extension, hidden or not.
Thanks OP.
I've successfully installed the ROM on my Grouper device.
Also, I've installed Opengapps via CF's Flashfire app and it worked very well.
Thank you for the rom.
I updated from CM13, install gapps with config , only rename it to ".gapps-config-grouper". I use all from USB drive via OTG for all my android devices.
All work fine.
Even in pico gapps package I had to exclude some apps so it could be installed. I've written in in gapps-config.txt this way:
GoogleTTS
calsync
A bug
When I pull down the notification/ quick settings, the device crashes and reverts to lock screen.
eNVy said:
When I pull down the notification/ quick settings, the device crashes and reverts to lock screen.
Click to expand...
Click to collapse
havent crashed on me yet.
@aaopt, it seems anddisa has a made some changes wherein camera is also working, maybe you can update the same for CM14.1?
It doesnot happen always. Sometimes only.
I'm skipping 90% of words here because if you are here I assume you know what you are doing. And you can either Google, use the search button, or ask.
This is a private work of mine, that I use normally on my spare device. Supported as is.
Disclaimer:
Not responsible for any injuries you do to yourself or your device being damaged caused by this ROM.
Known issues:
- Camera not working
INSTRUCTIONS
Clean Flash
Download The ROM & GApps (pick latest one in drive, I use opengapps)
Wipe: System, Data, Dalvik, Cache
Flash ROM + GApps (Opengapps pico)
Reboot & Enjoy
Dirty Flash
Download the ROM
Wipe: Dalvik and Cache
Flash ROM (+Magisk if rooted previously or if want root)
Reboot & Enjoy
Download Folder Link:
https://drive.google.com/open?id=1D0Od55prO_Q_e8RY6QkZ-DjO36Qb188X (Pick Grouper)
Credits to:
Unlegacy Team
Initial Release:
May Security Patch
Can't download the ROM 404 error
JT1510365 said:
Can't download the ROM 404 error
Click to expand...
Click to collapse
https://drive.google.com/open?id=1usLQT6qkg8eUe3FwOvXXHRRaBF8VxR5H
This is the direct link for latest, thanks for trying out! cheers!
KiD3991 said:
https://drive.google.com/open?id=1usLQT6qkg8eUe3FwOvXXHRRaBF8VxR5H
This is the direct link for latest, thanks for trying out! cheers!
Click to expand...
Click to collapse
Which kernel you use?
TureX said:
Which kernel you use?
Click to expand...
Click to collapse
It's stock thus far, but I am testing out other things.
So I assume F2FS can't work, right?
New update:
Direct Link: https://drive.google.com/open?id=1ObhbiIgSwxIS3fDfb2AREEx_6syQSpi_
Consider this pre-June patch build. And no F2FS doesnt work @Stylez Ray. I am too noob to implement it. (For now)
Guys, I apologize but this month's upload will be slightly delayed due to my work and studies having major setbacks. Again, I apologize.
New update:
Direct Link: https://drive.google.com/open?id=1LkbL1TEupSYUY2zA_L_NklEP-j9xWDUP
Changes are minimal in this build other than using a better build machine lol
Thank's good job !!!
All works fine magisk v19.3, dax_axon7_v1.6.1.zip
I return on Andisa rom 7.1.2 freeze and lags horrible
This is really awesome, no more random system freezes like in the first official UA builds. Thanks a lot, it really makes this ancient device useful again ?
@KiD3991 hello, maybe you would like to join Unlegacy team as Tegra 3 developer?
Slightly odd request at this stage probably but is there any chance off an unlegacy lollipop build for grouper? with a 3.4 kernel please?
actually strike that the marshmellow build will be just fine
but does anyone know if shared memory is implemented in a chroot I get -
sysctl -w kernel.shmmax=268435456
returns cannot stat /proc/sys/kernel/shmmax: No such file or directory
New build up, sorry I was really unavailable.
I tried fixing a couple of things, see if it helps, do tell me though, mention me and I will show up.
Direct link: https://drive.google.com/open?id=1g4eu0ulizZ8ZO44hRjMUnIyEYIyWQL9t
Changelog:
Minor bug fixes
July Security Patch
curioct said:
Slightly odd request at this stage probably but is there any chance off an unlegacy lollipop build for grouper? with a 3.4 kernel please?
actually strike that the marshmellow build will be just fine
but does anyone know if shared memory is implemented in a chroot I get -
sysctl -w kernel.shmmax=268435456
returns cannot stat /proc/sys/kernel/shmmax: No such file or directory
Click to expand...
Click to collapse
Interesting for the marshmellow build. Does it have to be UL?
For the bottom one you gotta dig the right directory.
KiD3991 said:
Interesting for the marshmellow build. Does it have to be UL?
For the bottom one you gotta dig the right directory.
Click to expand...
Click to collapse
Hmm I've kind of slipped off this little project for a while I'm trying to use it with the newer kali builds chroot (requiring the 3.4 kernels I believe) in the hope of having a device with WiFi monitor mode available but I was running in to that shared memory issue with services such as postgresql etc think is was causing me issues with csploit too but as I say not really looked at it in a few weeks now.
curioct said:
Hmm I've kind of slipped off this little project for a while I'm trying to use it with the newer kali builds chroot (requiring the 3.4 kernels I believe) in the hope of having a device with WiFi monitor mode available but I was running in to that shared memory issue with services such as postgresql etc think is was causing me issues with csploit too but as I say not really looked at it in a few weeks now.
Click to expand...
Click to collapse
OMG SAME! I was trying with the Kali too on my other device. It was kinda confusing no doubt
This rom is working great, thanks. Please can anyone help me with how to install browser on this rom, as the USB is not working.
did u tried to activate the debug mode , in dev settings? if that doesn't work .. you have to switch the drivers by yourself, in windows ( devices manager ) from ADB Bootloader to Storage Device .. for your Nexus 7