Hey folks,
i'm trying to get a "vanilla" aka unmodified device tree for the Shield Tablet K1. I know that you can sync over from nvidia's gitweb, tough the device tree is looking weird.
When i look at let's say cm's android_device_nvidia_shieldtablet it looks different. So i wonder how i would go from nvidias mutated tree to cm's layout without actually just forking it from cm.
Reason is, i want to port another custom rom over to the shield tablet, but i can't neither figure out how i'd do that with nvidias sources, nor how i would create a device tree similar to cm's, without any modifications.
I googled around for about 2-3 months now and still have no clue, so if anyone could give me a hint, i'd be very grateful!
What's wrong with the cm tree?
Unjustified Dev did the initial port of everything by hand. I've done maintainance manually since then. And to my knowledge, there's only been one other person to do a manual conversion (vartom). All custom ROMs derive from my tree. Should work in aosp as well. If there's something you need different from the cm tree, you can just add it on top. Or if something is broke in general, I need to know and fix it.
There's nothing "wrong", just not " clean", if you catch my drift. It's just a matter of reverting inwanted things, but yeah.. feels dirty.
Anyways, thanks for the info, man.
*shrugs* Okay, if you want to set up a new tree, nothing's stopping you. I wouldn't mind someone else knowing how to do it (pretty sure I'm the only active dev that has experience there), but it's a lot of parsing and research. I'll say that CMs trees are 95% unmodified from Nvidia's upstream, though. It's just rearranged into an aosp style tree. The kernel is a merge of the console and tablet since they were 98% identical anyways. I do my best to keep everything as clean as possible since I don't want to do through the work of making a lot of modifications every time a new release comes out... Engineers are lazy like that. I think the only things that aren't pure identical copies are the LTE init files and the unified device stuff (making the wifi only and lte models work in one ROM).
Nah, don't get me wrong there, i don't want to discredit you there.
I'm more talking about cm specific things like gello browser and stuff. Like i said, just a matter of a few changes to not include these. I'm just a beginner in any way, i can just follow instructions at best, i don't know c, and almost no java at all. So what you do is an astounishing task - it's just a personal preference coming and starting with nexus devices to tinker around, i have had the luxury of an AOSP tree, that's pretty much "my dilemma". I'm unexperienced and thus this might take a while for me. I've started to modify your device tree the day before yesterday, but i have something done wrong, as when i start compiling it'll ask if it should use " full_eng" config. (6.0.1 is used)
Again, thanks for putting me in the right direction, also for your efforts in maintaining our device.
What ROM are you trying to build? You could look at Carbonrom or Blissrom to see the rename changes needed to use the tree in a different ROM. Those should be similar across the board. I think the only CM specific package references would be gello and snap. Those commits could be reverted easily enough. Or if the ROM doesn't have them, I think they'd be ignored even if left as is.
Hi,
you can take a look at here
the base was the official cm tree, this is not vanilla but it s a K1 only tree.
Steel01 said:
What ROM are you trying to build? You could look at Carbonrom or Blissrom to see the rename changes needed to use the tree in a different ROM. Those should be similar across the board. I think the only CM specific package references would be gello and snap. Those commits could be reverted easily enough. Or if the ROM doesn't have them, I think they'd be ignored even if left as is.
Click to expand...
Click to collapse
I'm trying to port OmniROM https://docs.omnirom.org/Porting_Omni_To_Your_Device
Shouldn't be that difficult, i'm just doing something wrong.
kylon said:
Hi,
you can take a look at here
the base was the official cm tree, this is not vanilla but it s a K1 only tree.
Click to expand...
Click to collapse
Thank you, man.
I've forked it and will use it as a base.
Oh, omni. I build TWRP from omni. Take a look at the following two commits.
https://github.com/TeamWin/android_...mmit/c8e564a5ea44d963ab8d0e7829d9becd2ad5b0c0
https://github.com/TeamWin/android_...mmit/9b8772627795492f3380d2bf86680c09aada92c9
I haven't built the full ROM, but that should work. If you're using a K1 specific tree, the only difference should be in omni_shieldtablet.mk, instead of gsm.mk, use whatever omni has for tablet wifi only.
Steel01 said:
Oh, omni. I build TWRP from omni. Take a look at the following two commits.
https://github.com/TeamWin/android_...mmit/c8e564a5ea44d963ab8d0e7829d9becd2ad5b0c0
https://github.com/TeamWin/android_...mmit/9b8772627795492f3380d2bf86680c09aada92c9
I haven't built the full ROM, but that should work. If you're using a K1 specific tree, the only difference should be in omni_shieldtablet.mk, instead of gsm.mk, use whatever omni has for tablet wifi only.
Click to expand...
Click to collapse
Thank you, man. In fact i heavily orientaded on TWRP sources in this case. Also took a look at zombipop's repo.
Still whatever i do all i get is
[[email protected] omni]$ brunch shieldtablet
build/core/product_config.mk:241: *** No matches for product "omni_shieldtablet". Stop.
WARNING: Trying to fetch a device that's already there
Traceback (most recent call last):
File "build/tools/roomservice.py", line 352, in <module>
fetch_device(device)
File "build/tools/roomservice.py", line 320, in fetch_device
git_data = search_gerrit_for_device(device)
File "build/tools/roomservice.py", line 81, in search_gerrit_for_device
device_data = check_repo_exists(git_data, device)
File "build/tools/roomservice.py", line 58, in check_repo_exists
"exiting roomservice".format(device=device))
Exception: shieldtablet not found,exiting roomservice
build/core/product_config.mk:241: *** No matches for product "omni_shieldtablet". Stop.
** Don't have a product spec for: 'omni_shieldtablet'
** Do you have the right repo manifest?
No such item in brunch menu. Try 'breakfast'
Click to expand...
Click to collapse
Oh, brunch won't work because it wants to sync from the upstream server. Use lunch instead. Then run make to build.
Steel01 said:
Oh, brunch won't work because it wants to sync from the upstream server. Use lunch instead. Then run make to build.
Click to expand...
Click to collapse
Looks like a derp moment, i just had to modify the devicetree in another directory which is the actual working dir, instead on androidsrc/device/nvidia/shieldtablet directly. Like i said i just did something wrong.
It' compiling now, thank you for all the support!
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.
Sometime in the next few days (maybe this weekend), we will be merging https://gerrit.omnirom.org/#/c/1169/
This will allow TWRP to build properly on userdebug builds. As a warning, it WILL break anyone who doesn't have TWRP config in their device tree when it is merged! (You will get errors about missing files in bootable/recovery/res if I recall correctly)
See http://forum.xda-developers.com/showthread.php?t=1943625 for info on various TWRP device tree configurations. At an absolute minimum I believe you will need the device resolution added to avoid breaking your build.
For additional details, see:
Find5:
https://gerrit.omnirom.org/#/c/1633/
Yuga:
https://gerrit.omnirom.org/#/c/1682/ (Depends on fusion3-common changes)
pollux-common (pollux_windy and pollux don't have specific items and just inherit common):
https://gerrit.omnirom.org/#/c/1155/ (Depends on fusion3-common changes)
fusion3-common:
https://gerrit.omnirom.org/#/c/1152/
flo:
https://gerrit.omnirom.org/#/c/1634/
mako:
https://gerrit.omnirom.org/#/c/1635/
@Entropy512
Hey there!
Add me on hangouts sir:
[email protected]
What about this TWRP configuration for honami?
https://github.com/Omni-Xperia/android_device_sony_rhine-common/commits/cm-10.2
i have built one for pollux and it works
Just wondering, does this recovery actually get flashed when installing? I.e. do all the parameters need to be set properly to build the ROM, or just enough to not break the build? I'm already using TWRP and I'm not sure of the right BoardConfig.mk settings but if I'm just trying to port it to my device that shouldn't matter right? Though I noticed there are device trees on the TeamWin GitHub for building TWRP, for my device (n8013) it seems out of date.
Edit: well cool, turned out not to matter and it seems like my build actually booted, I'm pleasantly surprised .
iofthestorm said:
Just wondering, does this recovery actually get flashed when installing? I.e. do all the parameters need to be set properly to build the ROM, or just enough to not break the build? I'm already using TWRP and I'm not sure of the right BoardConfig.mk settings but if I'm just trying to port it to my device that shouldn't matter right? Though I noticed there are device trees on the TeamWin GitHub for building TWRP, for my device (n8013) it seems out of date.
Edit: well cool, turned out not to matter and it seems like my build actually booted, I'm pleasantly surprised .
Click to expand...
Click to collapse
Pretty much what happens is, TeamWin will get a device tree, modify it to be compatible with TWRP, and use that to build for that device. The actual core source for TWRP itself is in a separate repository that is constantly updated. So pretty much its like this : once your device tree is modified to build TWRP for your device during a build, it will build using TWRP source , which is android_bootable_recovery, for omnirom specifically.
Think of it like this: you setup a device tree to say "build TWRP using this source code" . once the device tree is looking for that source code, it'll always build twrp without issues (for the most part). Now the location your device tree looks to is the twrp source itself, which is updated and improved all the time, so if you're device tree is setup properly for tarp, you will have a recovery.img in your out directory after a build that is as up-to-date build of twrp to when you last did a repo sync
Sent from my SGH-I337 using Tapatalk
jakew02 said:
Pretty much what happens is, TeamWin will get a device tree, modify it to be compatible with TWRP, and use that to build for that device. The actual core source for TWRP itself is in a separate repository that is constantly updated. So pretty much its like this : once your device tree is modified to build TWRP for your device during a build, it will build using TWRP source , which is android_bootable_recovery, for omnirom specifically.
Think of it like this: you setup a device tree to say "build TWRP using this source code" . once the device tree is looking for that source code, it'll always build twrp without issues (for the most part). Now the location your device tree looks to is the twrp source itself, which is updated and improved all the time, so if you're device tree is setup properly for tarp, you will have a recovery.img in your out directory after a build that is as up-to-date build of twrp to when you last did a repo sync
Sent from my SGH-I337 using Tapatalk
Click to expand...
Click to collapse
Ah thanks, that's useful, but not really what I was asking about. I got that part, I just wanted to know if flashing the ROM actually flashes the recovery that was built in tree as well, and it seems like the answer is no (at least for me my recovery didn't change). As such it seems like the main point that Entropy512 was making is that if you don't add the resolution to your BoardConfig.mk the build won't complete, but otherwise it doesn't really matter if you set the other parameters correctly.
The paths I was referring to were the mount points for the internal and external SD, I thought they had changed since ICS but I think they might still have symlinks to the old paths for compatibility's sake.
iofthestorm said:
Ah thanks, that's useful, but not really what I was asking about. I got that part, I just wanted to know if flashing the ROM actually flashes the recovery that was built in tree as well, and it seems like the answer is no (at least for me my recovery didn't change). As such it seems like the main point that Entropy512 was making is that if you don't add the resolution to your BoardConfig.mk the build won't complete, but otherwise it doesn't really matter if you set the other parameters correctly.
The paths I was referring to were the mount points for the internal and external SD, I thought they had changed since ICS but I think they might still have symlinks to the old paths for compatibility's sake.
Click to expand...
Click to collapse
You mention mount points for the SD, I have been building for the HTC One S and while all the mount points in the my ville/rootdir are correct for example in the fstab.qcom file
# SD card
/devices/platform/msm_sdcc.1/mmc_host/mmc0 /storage/sdcard0 auto defaults voldmanaged=sdcard:36
The rom shows it as unavailable/missing and asks me to format the SD card, I tried and the message keeps popping up.
Basically my question is, will building twrp recovery for the device sort out the missing SD card.
iofthestorm said:
Ah thanks, that's useful, but not really what I was asking about. I got that part, I just wanted to know if flashing the ROM actually flashes the recovery that was built in tree as well, and it seems like the answer is no (at least for me my recovery didn't change). As such it seems like the main point that Entropy512 was making is that if you don't add the resolution to your BoardConfig.mk the build won't complete, but otherwise it doesn't really matter if you set the other parameters correctly.
The paths I was referring to were the mount points for the internal and external SD, I thought they had changed since ICS but I think they might still have symlinks to the old paths for compatibility's sake.
Click to expand...
Click to collapse
flashing a ROM will never flash a recovery, but some devices have the recovery as part of the boot.img, so when you flash a new kernel, for example, you will be flashing a new recovery as well
iofthestorm said:
Just wondering, does this recovery actually get flashed when installing? I.e. do all the parameters need to be set properly to build the ROM, or just enough to not break the build? I'm already using TWRP and I'm not sure of the right BoardConfig.mk settings but if I'm just trying to port it to my device that shouldn't matter right? Though I noticed there are device trees on the TeamWin GitHub for building TWRP, for my device (n8013) it seems out of date.
Edit: well cool, turned out not to matter and it seems like my build actually booted, I'm pleasantly surprised .
Click to expand...
Click to collapse
Ideally you should have a goal of building a fully functional recovery.
However, with the exception of older Samsungs (galaxys2 family and older for the most part) and Sonys, you don't NEED the recovery to be fully functional. With the galaxys2 family and Sonys - yeah you need it. (Actually Sonys do have a workaround, but the GS2 family does not.)
That said, leaving a partially configured recovery configuration is bad practice.
jakew02 said:
flashing a ROM will never flash a recovery, but some devices have the recovery as part of the boot.img, so when you flash a new kernel, for example, you will be flashing a new recovery as well
Click to expand...
Click to collapse
Yeah, that'd be what I was thinking of. My first Android phone, the Samsung Fascinate, had a weird setup like that.
Entropy512 said:
Ideally you should have a goal of building a fully functional recovery.
However, with the exception of older Samsungs (galaxys2 family and older for the most part) and Sonys, you don't NEED the recovery to be fully functional. With the galaxys2 family and Sonys - yeah you need it. (Actually Sonys do have a workaround, but the GS2 family does not.)
That said, leaving a partially configured recovery configuration is bad practice.
Click to expand...
Click to collapse
Alright, that's what I figured. Yeah, I'll fix it later for sure, I just didn't have the time this weekend and I didn't plan on submitting a patch to make it officially supported anyway, as I just wanted to try it out for myself at this point. And I figured since it's the n8013 you'd be the best person to support that anyway, I only know enough to get myself in trouble.
(do you still have your N8013 by the way?)
iofthestorm said:
Yeah, that'd be what I was thinking of. My first Android phone, the Samsung Fascinate, had a weird setup like that.
Alright, that's what I figured. Yeah, I'll fix it later for sure, I just didn't have the time this weekend and I didn't plan on submitting a patch to make it officially supported anyway, as I just wanted to try it out for myself at this point. And I figured since it's the n8013 you'd be the best person to support that anyway, I only know enough to get myself in trouble.
(do you still have your N8013 by the way?)
Click to expand...
Click to collapse
I do, but it mostly collects dust these days. At some point I'll try to get Omni up on it, I've just had too much else to do lately.
So another question, what is the mechanism by which twrp.fstab is used? I decided to flash my recovery for the heck of it (sidenote: on the 4.4 branch it still has the AOSP recovery in the manifest, but I just added omnirom/android_bootable_recovery to my local_manifests.xml) and it actually runs but nothing appears to be mounted. I notice that some TWRPify commits have a twrp.fstab but they don't do a PRODUCT_COPY_FILES for that file so I'm wondering how it even gets used? I see for example that your commit for flo is doing it: https://gerrit.omnirom.org/#/c/1523/ but then this guy didn't actually add it to PRODUCT_COPY_FILES for hammerhead: https://gerrit.omnirom.org/#/c/1588/ . Is that just a mistake on Mithun's part, or am I misunderstanding how this fstab is used? Is there any reason for it to be any different than the fstab.smdk4x12 in the device tree? Just trying to figure out how things work here.
Also, is it preferable to use the by-name symlinks over the raw /dev/block/mmcblk0p9 type device identifiers? Should I open another thread for this?
My hackjob device trees are https://github.com/ibrahima/android_device_samsung_n80xx-common and https://github.com/ibrahima/android_device_samsung_n8013 .
Edit: I guess my main question is, how is that twrp.fstab different from TARGET_RECOVERY_FSTAB? Some of the device trees with it (eg. your flo changeset that I linked above) don't seem to set this unless I'm looking in the wrong place, and I've seen at least one that sets TARGET_RECOVERY_FSTAB to /etc/twrp.fstab. Found this quote from @Dees_Troy:
You can create a twrp.fstab file and then use PRODUCT_COPY_FILES += device/oem/codename/twrp.fstab:recovery/root/etc/twrp.fstab to get the twrp.fstab into the recovery ramdisk
Click to expand...
Click to collapse
from http://forum.xda-developers.com/showthread.php?p=45164117 . If I already have an /etc/recovery.fstab it should work without the twrp.fstab right?
Edit2: Oh, derp, the twrp.fstab explanation is in the "How to Compile TWRP" thread. Filing away for later reading... (this is fun and all, but my professors aren't going to accept an Android 4.4 build in place of my homework )
Edit3: My god, this is basically me: http://xkcd.com/356/ and the truck is my homework/midterms... welp, at least I got a recovery with proper fstab, so for anyone else trying to TWRPify yes, you do need a twrp.fstab because the new fstab format in Android 4.3+ is not used by TWRP yet so you need one in the older format for it to mount your stuff. Haven't actually tried flashing anything with my recovery yet, but I feel like it should probably work, but again... trucks and all that
If it's not in PRODUCT_COPY_FILES - yes, that is a mistake.
(hopefully that commit isn't merged - accessing omni's gerrit is problematic for me from some locations. If the TWRP FSTAB is added to the device tree but isn't being copied that's grounds for a -1)
Yeah, he -1ed it himself for other reasons I suppose. Cool cool, looks like I'm learning stuff
By the way, after the hard drive meltdown and subsequent loss of two weeks of gerrit data, a lot of the links in your OP are broken in that they go to different tickets which have now subsumed those ticket numbers that were lost. For those who are curious and have been foiled by Gerrit's somewhat obtuse search box, if you type message:TWRP in the search box (to search commit messages) you'll find examples.
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
Since development for the Sidekick 4G has stopped I decided to try and port the CM11 M10 snapshot from the Galaxy S 4G using this guide. I used the Galaxy S 4G as port ROM since most of the specs are the same as the SK4G. The base ROM I used is ayoteddy"s KJ2 Deodexed & rooted ROM. I followed the guide and flashed the ROM I made but the phone didn't boot. It stays stuck at the tmobile startup screen and then bootloops. I took a logcat and see a lot of errors but idk how to correct them. I tried uploading the ROMs I used and the one I created but it only let me upload the logcat.
Hey,
Its awesome to see some more effort in this phone but when porting a ROM one of the main prerequisites is the base being the same android version.
So to port cm11 over you would need a kitkat kernel and ROM for the sk4g already.
What would be real helpful is to get the gingerbread kernel fully functional then any GB ROM could be ported fairly easily.
Or start with a kitkat kernel but both require a bit of work. If you want to take it on a can link a bunch of guides that may help
Thanks for that info. I don't have experience coding but I would like to be able to learn how to cook and port roms so I would really appreciate some guides. As I understand it, since there is no KitKat ROM available for the sk4g I would first need to make my own KitKat kernel and ROM before I would be able to port cm11? And how long do you think it would take to learn everything needed to be able to port and cook roms?
Hey,
On mobile right now so can't post a bunch of links but xda is filled with them
The best place to start would be http://www.xda-university.com
And be sure to check out the forum links as well!
For a quick set of links see the seventh post in this thread
http://forum.xda-developers.com/showthread.php?t=2348266
For a different device but those are all great places to start learning to develop for android
Keep me posted on your progress!
Took me a while to find some useful guides since I was searching with the term "port" and not "build/compile from source" since that is essentially what I'm doing. I used wiki.cyanogenmod.org/w/Doc:_porting_intro and wiki.cyanogenmod.org/w/Build_for_galaxysmtd (can't post links yet). I forked the galaxys4g repo and modified the files to be suited for the sidekick4g. Now I'm onto the building step, a couple of things already broke and I managed to fix them, but I ran into this error and haven't been able to fix it.
brunch sidekick4"ebtables is disabled on this build"
find: `src': No such file or directory
build/core/base_rules.mk:134: *** system/extras/ext4_utils: MODULE.TARGET.EXECUTABLES.setup_fs already defined by device/samsung/sidekick4g. Stop.
I researched the MODULE.TARGET.EXECUTABLES.setup_fs already defined by device/samsung/sidekick4g issue and suggestions were to delete the setup_fs file within device/samsung/sidekick4g folder. However the setup_fs file wasn't in there, I did find a setup_fs.c file and deleted that one. Then I proceeded to try the build again and ran into the same error. Another suggestion was to use grep -R setup_fs *. This command pointed to these files,
Android.mk:LOCAL_SRC_FILES := setup_fs.c
Android.mk:LOCAL_MODULE := setup_fs
Android.mk~:LOCAL_SRC_FILES := setup_fs.c
Android.mk~:LOCAL_MODULE := setup_fs
initramfs/init.herring.rc:service setup_fs /system/bin/setup_fs /dev/block/platform/s3c-sdhci.0/by-name/userdata
sidekick4g.mk: setup_fs
But I don't know what exactly I'm supposed to delete. The device repo is located at github.com/SK4G/android_device_samsung_sidekick4g.git It is a pre-build attempt version before I made suggested changes to the local repo. I tried "git push origin master", the command went through and said everything is up to date but the remote repo still wasn't changed so I haven't been able to update it.
What are you using for the device tree? The relay is a completely different device and none of the drivers would work, did you at least pull blobs and proprietary files from a sk4g?
There is a ton of setup to be done in order to build from source, you can use the cm11 source but need to make a specific device tree for the sidekick to get a working build, not to mention a ton of kernel work will be needed
For the device tree I forked the galaxys4g repo (not the galaxy s relay 4g) and then modified the files to build the sidekick4g specific device tree. When pulling the blobs and proprietary files the guide said " Your device should already be running a build of CyanogenMod for the branch you wish to build for the extract-files.sh script to function properly". Not sure if that's relevant to the errors but I was still able to pull the blobs towards the correct ~/android/system/vendor/samsung directory. As far as the kernel I downloaded the stock kernel from the samsung source website and then put it in the kernel/samsung/sidekick4g directory. The guide said that the kernel and kernel modules would be built automatically as long as I made appropritate changes to the BoardConfig.mk and I did so. I have done every step in the guide and now I'm into building but I can't get past the previously mentioned error. Should I delete the whole part of the files mentioned by the grep -R setup_fs * command or just the red part or is there another solution?
Well the blobs that were pulled and the kernel that was used was for froyo, that won't work for kitkat without a weeks worth of modification
Also the s4 is even more different than the relay and would be much harder to use anything from there
What you need at this point is to create your own device tree on github and add this to your local manifest, then the hard part is to adapt the sk4g kernel into something that will work with kitkat, once this steps are complete you can build and then fix the errors that come up, fixing any errors at this point won't help much as the files used are incompatible from the start
I should have been more specific, I used the T-Mobile Galaxy S 4G which is one the first galaxy phones. It has the same hummingbird chipset, architecture, ram/rom size, resolution, and both originally ran froyo. The guide states that the cm buildbots build a compatible kernel for me. I didn't just fork the galaxys4g repo and leave it as is. I went through the files and substituted anything that was galaxys4g device specific to fit the sidekick4g.
No problem, should have read more clearly, yes the galaxy s is very similar minus the keyboard but you can look at the work that was done to get a GB ROM booting here
http://forum.xda-developers.com/showthread.php?t=2323617
This was done on the exhibit, another very similar phone,
Even after the kernel was adapted the keyboard never worked, you check the link to his github to see what was put into it to work
The kernel built by the bot won't adapt it to work between different versions of android so you need to build this manually first then you can use it, but even then there will be a lot to do in order to get the keyboard working
Now I'm beginning to understand what you have been trying to tell me. It was hard to grasp at fist because I never really looked into building a kernel since I usually just use the stock kernel or the cm built in kernel on my devices. Now I shall redirect my efforts into building a kernel
Hi I just wanted to know if you're still building port for the sidekick 4G I still have mine and I would like to use if you have kitkat to work. I miss my sidekick 4G
Sent from my Nexus 6 using XDA Free mobile app