Inspired by supercurio creating a master git repo for SGH-I997R development, I'm in the process of uploading today's source release from Samsung of the Gingerbread kernel for the Rogers Infuse 4G. (I'm surprised none of the other kernel hackers here have already done it... )
See supercurio's post http://forum.xda-developers.com/showthread.php?t=1054738 for more info on why git is good, and superior to kernel devs using tarballs directly from Samsung. This method is already unofficially how the kernel devs have been working - nearly every kernel here is forked from gtg465x's github repo.
I don't plan on directly doing development on this repo - It's just here as a starting point for everyone else to fork from. Some of us have slow upstream, so it's easier to pull a fork than it is to push a tarball import. However I might consider pulling in basic fixes to this repo (.gitignore, Makefile fixes - basically the same things supercurio has fixed in his unified git repos). (Edit: I'm starting to consider doing things a bit differently in order to allow this to stay as a relevant reference - After all there are certain "core" features like Voodoo Lagfix/Sound that have no known detrimental effects and are basically expected from any kernel used by the community.)
One thing is that most of the other ref repos are on a github "team" account - mine is on a personal account. I'm going to look into whether I can change this without breaking the fork relationships.
The repo is located at https://github.com/Entropy512/linux_kernel_sgh-i997r
Initramfs from Wednesday's dump is at https://github.com/Entropy512/initramfs_sgh-i997r
Note: If someone creates a better "master" repo for everyone to track, I'll happily edit this post to point there.
Update: Merged a pull request from LinuxBozo that has a bunch of .gitignore fixes and Makefile fixes.
Good work! Looking now.
Entropy512 said:
Inspired by supercurio creating a master git repo for SGH-I997R development, I'm in the process of uploading today's source release from Samsung of the Gingerbread kernel for the Rogers Infuse 4G. (I'm surprised none of the other kernel hackers here have already done it... )
See supercurio's post http://forum.xda-developers.com/showthread.php?t=1054738 for more info on why git is good, and superior to kernel devs using tarballs directly from Samsung. This method is already unofficially how the kernel devs have been working - nearly every kernel here is forked from gtg465x's github repo.
I don't plan on directly doing development on this repo - It's just here as a starting point for everyone else to fork from. Some of us have slow upstream, so it's easier to pull a fork than it is to push a tarball import. However I might consider pulling in basic fixes to this repo (.gitignore, Makefile fixes - basically the same things supercurio has fixed in his unified git repos)
The repo is located at https://github.com/Entropy512/linux_kernel_sgh-i997r - There is nothing visible there yet as the push is still in progress. It should be done within 30 minutes or so.
I don't have an initramfs repo yet - we need an initramfs dump from a device first.
Note: If someone creates a better "master" repo for everyone to track, I'll happily edit this post to point there.
Click to expand...
Click to collapse
Absolutely awesome news :-D
Sent from my SAMSUNG-SGH-I997 using XDA Premium App
Oh blast, hadn't even seen that kernel code was available... thanks Entropy!
A personal favor I'd like to ask of people forking - try to keep things to one feature per commit. An example being LinuxBozo's ext4 backport to the Froyo kernels - it was simple and easy to apply to other kernels. As opposed to someone had a massive supercommit that added a whole bunch of stuff at once, making it hard to either pick-and-choose or hard to apply if they had already applied a single-feature commit for one of the features. (One example being a commit that combined something like TinyRCU, jhash3, and BFQ all in one. I don't remember exactly what it was.)
Entropy512 said:
A personal favor I'd like to ask of people forking - try to keep things to one feature per commit. An example being LinuxBozo's ext4 backport to the Froyo kernels - it was simple and easy to apply to other kernels. As opposed to someone had a massive supercommit that added a whole bunch of stuff at once, making it hard to either pick-and-choose or hard to apply if they had already applied a single-feature commit for one of the features. (One example being a commit that combined something like TinyRCU, jhash3, and BFQ all in one. I don't remember exactly what it was.)
Click to expand...
Click to collapse
Defuse kernel
Sent from my SAMSUNG-SGH-I997 using XDA Premium App
Is that all we needed for gb roms or is there still more needed?
Sent from my SAMSUNG-SGH-I997 using XDA Premium App
nelomen said:
Is that all we needed for gb roms or is there still more needed?
Sent from my SAMSUNG-SGH-I997 using XDA Premium App
Click to expand...
Click to collapse
Initramfs, radio firmware dump, proper /system dump. Ours is incomplete.
Updates:
Merged LinuxBozo's pull request with build fixes
Merged LinuxBozo's pull request with the rainbow fix
Added initramfs repo
Entropy512 said:
Updates:
Merged LinuxBozo's pull request with build fixes
Merged LinuxBozo's pull request with the rainbow fix
Added initramfs repo
Click to expand...
Click to collapse
Nice!! Anything buildable yet?
ookba said:
Nice!! Anything buildable yet?
Click to expand...
Click to collapse
should be buildable since initramfs is available, tomorrow gtg's voodoo commit should be available too. this is all very exciting.
ookba said:
Nice!! Anything buildable yet?
Click to expand...
Click to collapse
A few more things got pulled in last night.
Kernel - not much
Initramfs - Working CWM - or at least it comes up, it hasn't been fully tested functionally yet
As of last night a few people have custom kernels running including myself, although some people still can't boot them. CWM wasn't working until past midnight...
Next up is voodoo - Not sure if I'll include that in the main initramfs repo or not. Maybe as a branch. It is a fairly standard mod, so it should be in a readily accessible repo
Bad news - as I said before CWM hadn't been fully tested.
Apparently, after further testing, it still does indeed have some pretty severe issues.
Sadface
10c
P1 Wookie said:
Sadface
10c
Click to expand...
Click to collapse
We have what seems to be working CWM and Voodoo thanks to gtg - in testing now.
The trolls in IRC aren't helping. Not a good time for the ops to be AFK.
trolls suck.
GL guys.
Entropy512 said:
We have what seems to be working CWM and Voodoo thanks to gtg - in testing now.
The trolls in IRC aren't helping. Not a good time for the ops to be AFK.
Click to expand...
Click to collapse
Gotta love the trolls.
Good luck guys. I know you all will figure it out
Well, thanks to the blasted trolls and the unfortunate circumstance of my only internet being my phone, I'm borked from being able to participate in the main infuse4g room as webchat is banned (for a good reason) and I can't get past the SASL issue otherwise.... oh well.
bedwa said:
Well, thanks to the blasted trolls and the unfortunate circumstance of my only internet being my phone, I'm borked from being able to participate in the main infuse4g room as webchat is banned (for a good reason) and I can't get past the SASL issue otherwise.... oh well.
Click to expand...
Click to collapse
why no use of a client?
drowningchild said:
why no use of a client?
Click to expand...
Click to collapse
Finally got it to work, had to hack a command line client.... urg.
Related
11/22/11 Update: Added "reboot bml8 recovery" patch for ROM Manager suppport.
11/8/11 Update: Updated keyfix kernel with the EI22 initramfs. Also, Samsung has placed the previous official (and now labeled EI22) source tarball on their opensource site.
10/24/11 Update: It appears that Samsung has removed the "official" Epic GB source tarball from their website. I've mirrored it for anyone interested in the original release. For anyone actually looking to build with the sources, you're probably better off using Rodderik's GitHub
10/19/11 Update: As everyone's found out by now, Samsung released official Epic GB sources last night. There's not that many changes to our device in the official source tree compared to the previous, but a few appear to be subtlely important (see abbreviated deltas). It still needs some work to get into a buildable state, but it does appear to work great on EH17!
I've updated most of my patches for GB, conveniently packaged together. I've also uploaded a new EH17 kernel that works on stock (rfs) EH17 ROMs and includes the keyboard fixes with optimized values, along with userdebug and kexec support. Feel free to give it a try.
Meanwhile Rodderik is updating his GitHub repo to include all these patches for folks to clone from, stay tuned.
Happy hacking!
So apparently when Samsung released the kernel sources to the Mesmerize's Gingerbread update a month-and-a-half ago, that source tree contained almost-buildable kernel sources for our device as well.
I've patched the sources (removed modemctl definition, added tfsr driver, compile right camera driver) to build for the Epic. I've also built a custom EH17 kernel combining these sources with the EH17 initramfs. It's essentially stock EH17 with ro.debugging=1, adbd always-spawning during recovery, and testkey signature verification. I'll get to porting over some other patches (like the dropped key fix) soon.
As for compatibility with EH17, the source tree itself appears to have been checked out on 8/30 and looks to include everything EH17 does. I ran "strings Image | sort -u" on both kernels to make sure there weren't any obvious strings/symbol differences between them. The ones that remain appear to be minor, but legitimate fixes.
Thanks to jt1134 & Rodderik for pointing out that the Mesmerize source released contained Epic code, and Tortel & ugothakd for testing.
GitHub repo, thanks Rodderik!
To build:
Grab SCH-I500_USCC_Opensource_Update3.zip SPH-D700_GB_Opensource.zip from opensource.samsung.com, extract.
Run "make mrproper" to get rid of atlas (Mesmerize) config junk.
Patch to complete Epic support.
Build with EH17 initramfs as usual, use victory_8G_defconfig for kernel configuration.
Mirror links:
Official GB sources: SPH-D700_GB_Opensource.zip (originally posted on opensource.samsung.com, since removed.)
Epic GB source patches: kernel-GB-3a-patches.tar.gz
Source-compiled, keyboard fix EI22 kernel: kernel-GB-3a.tar.md5
(URLs for Mesmerize tree patches removed, although they're still valid.)
Flashed this yesterday(11/13). Working good so far.
Edit: Oh, and first! Sorry iSaint
Sent from my SPH-D700 using Tapatalk
HAHAHAHA! Epic. I love you guys!
Yeah, um, I love you. <3 lol.
No. I was first. I tested it lol
[edit] actually, tortel was first. but that was before i got on board.
Hmmmm...who would of known part of our kernel source was right under our noses
Sent from my SPH-D700 using xda premium
It just occurred to me that, with this finding a lot of good can happen, as well as ICS tomorrow. Depending on timezone I should say.
Sweet. Hopefully this'll help cm7
Heart just stopped beating LOL!
What about stratosphere then?
Oh well nice work!
Sent from my SPH-D700
winning
bet samsung was just watching and waiting to see how long it took one of you/us to figure it out, lol.
this is wonderful news
Ceelos09 said:
Hmmmm...who would of known part of our kernel source was right under our noses
Click to expand...
Click to collapse
Ideally there would be one Samsung Android kernel source tree that would contain code for our device as well as all their others. However, I've been checking somewhat recently and code for Epic never appered in the GT-I9000 sources (which have been updated recently) nor in the Stratosphere ones.
It didn't occur to me to check the Mesmerize sources sooner, but as the only US device with an official GB release (still?) it shouldn't have been much of a surprise. It's also worth nothing that there appears to be GB sources for the Indulge in there as well. I'm not sure of their buildability though.
GREAT work mkasick.... everyone be SURE to thank him!
SWEET !!!
Exciting! Do the cm7 guys know about this, or is already used in the build we have?
Neckberg said:
Exciting! Do the cm7 guys know about this, or is already used in the build we have?
Click to expand...
Click to collapse
I'm not sure, JT helped Decad3nce with CM 7 though and they both hacked the EH17 kernel to work for this. So hopefully it's something Decad3nce can use.
He said he was moving so he probably won't be back until tomorrow.
Neckberg said:
Exciting! Do the cm7 guys know about this, or is already used in the build we have?
Click to expand...
Click to collapse
The main CM7 people are Decad3nce and jt and they haven't been on irc today.
this is exactly what we been needing...THANK YOU VERY MUCH mkasick!! You rock my friend!
Downloading now - going to see if I can compile a bootable kernel
Sent from my CyanogenMODed Epic
Neckberg said:
Do the cm7 guys know about this, or is already used in the build we have?
Click to expand...
Click to collapse
I believe JT was the one who discovered the Mesmerize sources were pertinent to us. He might've been able to compile something, but at least Rodderik was stuck on the missing tfsr driver without the right debugging bits.
I discovered this worked somewhat haphazardly when Rodderik mentioned the Mesmerize sources to me. They booted the first time with EH17 on SD, but wouldn't boot from flash. Since I was able to get it to boot off SD, debugging was a good deal easier.
In any event, it's a drop-in replacement for the current kernel used by the Epic CM7 build, so I'm sure they'll make good use of it sooner or later.
Actually what I'm curious about is if the reboot problems still persist with this. I haven't had one yet, but they haven't been a problem with stock EH17 on my device either.
This thread is no longer active. Jomeister plans to continue work on Evervolv. He will open a new thread for that purpose.
Introduction
The purpose of this thread is to coordinate work on the AOSP-based Evervolv 2.2 ROM for Skyrocket (and its sister, T989).
Skyrocket is not an officially supported ROM by Evervolv, but we have fully integrated device and vendor directories in their tree. Therefore we get fixes from the main tree and also have the ability to push fixes to Evervolv's tree. This is something we could never do when we worked directly off the Code Aurora source.
Our desire is to give the dev community a single codebase to coalesce around. Hopefully, with more devs working on the same project, we can progress faster towards AOSP.
To build, follow the instructions here (choose ev_skyrocket-eng at the lunch menu):
https://github.com/Evervolv/android
Or, the short, short version:
Run "repo status" and make sure you have no local mods.
Run "repo sync" and make sure it completes without error.
Run "rm -rf out" to remove any old compiled stuff
Run ". build/envsetup.sh" to set up your environment
Run "lunch ev_skyrocket-eng" to select the target
Run "make -j4 otapackage" (adjust -j option to match your # of processors)
What works:
2D/3D graphics, hw accel of gui, bluetooth, gps, nfc, wifi, sdcard (int+ext), MTP/PTP over USB
What doesn't work:
audio, calls, camera, cell data, sms, anything else you can think of
Issues are being managed on Github:
https://github.com/Evervolv/android_device_samsung_skyrocket/issues
Want a ROM link?
Then follow the instructions to build a ROM! The point, at this time, is to get devs involved in the process. The ROM is not ready for anyone to try out or use at this point. There are many problems left to solve.
Want to help?
Are you a dev with a Skyrocket and a burning desire to get AOSP for your phone? Please, check out Evervolv and start debugging! The Github Issues link above is a great starting point.
Jomeister and RaverX3X graciously agreed to join forces here. We hope other devs join too!
Current Dev Contributors:
jomeister15
RaverX3X
topprospect
Credit and Thanks:
Xboarder56 for the original Evervolv Skyrocket device tree
romracer for the unsecure mods to the ICS kernel
Changes Log:
04/11/12: Posted succint build instructions
04/11/12: Fixed unstable-ness of GUI (link)
04/06/12: Build now boots on its own boot.img (link)
this is on 4.0.4 now?
Sent from my GT-P7510 using XDA Premium HD app
BaconStep said:
this is on 4.0.4 now?
Sent from my GT-P7510 using XDA Premium HD app
Click to expand...
Click to collapse
yes because google has released 4.0.4 sources and ota updates to nexus.
wali01x said:
yes because google has released 4.0.4 sources and ota updates to nexus.
Click to expand...
Click to collapse
Sweet!
Sent from my GT-P7510 using XDA Premium HD app
Looks great, will try building/debugging when I get my Ubuntu box up again!
Sent from my SAMSUNG-SGH-I727 using XDA
I'll be helping out as well, just got me a T989. I was working on cm9, but I'll switch to this. Hope I can help.
This is obviously a stupid question, and probably not the place to be asking it, but it is going to be asked anyway so.. I understand what the device tree is, but why is it not possible to pull one from the existing ICS leak?
giant420 said:
This is obviously a stupid question, and probably not the place to be asking it, but it is going to be asked anyway so.. I understand what the device tree is, but why is it not possible to pull one from the existing ICS leak?
Click to expand...
Click to collapse
No stupid questions here. A fully compiled ROM like the ICS leak obscures a lot of the details about how to build the ROM from scratch. You have to reverse engineer a lot of what Samsung did to compile AOSP, plus how to avoid pulling in too much Samsung bloat code. Hope that helps.
more or less were going to keep as much samsung out of it as we possibly can . Yes u can kang in stuff from the leak but then that actually causes more issues in the long run then doing it right the first time ;P.
bsbachert said:
I'll be helping out as well, just got me a T989. I was working on cm9, but I'll switch to this. Hope I can help.
Click to expand...
Click to collapse
I think we as a community should still continue working on things such as CM9 and AOKP in addition to Evervolv, just to give people as many options as possible. The good thing that Evervolv device trees are very similar to those required by CM9 and AOKP, so with a few hacks here and there I'm sure we can get those building as well. I don't know about the other devs, but I definitely have enough time to collaborate on multiple projects, as long as I'm not the sole carrier.
ur killing me. I finally managed to get media server to stay up for msm8660 audio pulled from the leak with jos isotope a4 with some other libs and bins. acdb pulling audio policy was still a problem though.
This is definitely for the better though. I was uncomfortable with all those Samsung libs bins and blobs, especially after staring at them under IDA. like raver said it woulda been a nightmare later on.
This is great though, everyone on the same pile should make this go a lot faster.
im very excited for this.
What's IDA?
Sent from my SGH-T989 using XDA
Wow. This build is going to b epic! Can't wait guys. Nice work so far
LawStud3nt said:
What's IDA?
Click to expand...
Click to collapse
http://en.m.wikipedia.org/wiki/Interactive_Disassembler
crazy what u can find in those blobs. helps a lot for debugging though
all I know is I love evervolv on my nexus one its super baller... Thanks to all 3 of you guys
Sent from my SAMSUNG-SGH-I727 using xda premium
Any updates? Got ants in my pants waiting for this one!
softballjunkee13 said:
Any updates? Got ants in my pants waiting for this one!
Click to expand...
Click to collapse
Thanks for the interest.
We will post updates as they happen. Right now we are just trying to organize and get everyone on the same page.
Sent from my SAMSUNG-SGH-I727 using Tapatalk
topprospect said:
Thanks for the interest.
We will post updates as they happen. Right now we are just trying to organize and get everyone on the same page.
Sent from my SAMSUNG-SGH-I727 using Tapatalk
Click to expand...
Click to collapse
OK...enjoy the holiday as well!
This is a development thread. If you want a conversation thread, please open one in the general forum!
I've released the source a little early of completion, so I can get others on teamacid to help out. So until we get on the android-samsung-2.6.35-gingerbread branch and changes added, tested, pushed, and tested by a more general audience, I would NOT SUGGEST FLASHING THIS. Don't expect any wiz-bang features added or anything like that. This is a port. After the port is done, we can do all sorts of stuff.
Milestones to complete:
Scrub existing code that does not relate to Galaxy S 4G (SGH-T959V/VibrantPlus) from arch/arm/...
Move architecture specific code to mach-herring.c (as it should be) and make the changes diff cleanly with the aosp samsung android-samsung-2.6.35-gingerbread branch
Scrub and import needed drivers to new android-samsung-2.6.35-galaxys4g branch with herring conversion stuff imported.
Try to get rid of dvfs stuff and move to stock cpufreq (for easier future porting to Linus's mainline, which is the goal of this kernel, amongst other modifications that will open up...)
Get all components working (wifi/bt/gps/etc. It may not be possible to use bml/fsr/rfs/ext4, because of the symbol table changing, but lets try to see if we can get it working before making the kernel compatible with cm/aosp)
investigate BML<->MTD rom conversion kernel
I have currently completed Milestone 1. I am currently running stability tests with unnamed rc2. The binary should be the same as the minimal changes to stock source to make it boot and work with a standard bml rom, but without the other board code for dempsy, kepler, vibrant, vibrantplustelus, flemming, aries ntt, and others. All code is cleaned up and specific for VibrantPlus/SGH-T959V.
I've put together a new initramfs/recovery based on v5.0.2.8 to work on BML. This does not contain the voodoo lagfix support.
You WILL have to use an updater-script that forces conversion to ext4.
GitHub:
Kernel - https://github.com/bhundven/android_kernel_samsung_galaxys4g
Initramfs - https://github.com/bhundven/android_initramfs_samsung_galaxys4g
Stay tuned... I will update with progress.
post for uploads
OP updated. Using new initramfs (gingerbread branch), some kernel and build.sh fixes.
Just a note, I've made a little progress on m2.
Looking at possibly having something releasable here in the next week or two.
I've been out of work now since may 1st and its been hard to motivate myself on anything phone related.
Much thanks to the members of teamacid and teamkickass for keeping this stuff going!
Sent from my SAMSUNG-SGH-I717 using xda premium
So these are BML kernels converted to MTD?
Sent from my SGH-T959V using XDA
smontero said:
So these are BML kernels converted to MTD?
Sent from my SGH-T959V using XDA
Click to expand...
Click to collapse
You missed the point entirely.
EDIT
Look under "Milestones to complete"
I see but I don't completely understand. I just found out the difference between BML and MTD but I was asking cause I'm using the miui MTD and i wanted to know if these kernels would work
Sent from my SGH-T959V using XDA
He hasn't posted download links to them yet.
FBis251 said:
He hasn't posted download links to them yet.
Click to expand...
Click to collapse
Right. If you know how to compile the kernel, you could. If you did, you would currently have a BML kernel. (note there is also no mtd support in the current initramfs either)
I'm not sure if Milestone 2 will be able to support RFS. I may pull in the FSR code from supercurio's repository so that we can still have BML+ext4, but that code was for a froyo kernel.
If I can't get that to work, then this kernel will be MTD only. I'm still having some problems where my current Milestone2 changes (not checked in) is not booting correctly.
As I said, I'll have an update soon.
More information is listed at the site below
http://androidforums.com/triumph-al...-files-7-09-2012-5-30-pm-mst.html#post4641932
Just love the fact that we're basically redoing this whole phone. Lol.
Yeah I am slowly getting there with the device files. I will be updating the post each time I push back up to github and what works and doesn't.
I am stopping work on this with the gingerbread branch and now going to use the new gb-branch-7.2 branch as it was finally released on June 16th I forgot to check back.
http://www.cyanogenmod.com/category/blog
I will be updating the WX435 github during the day.
Edit: Update is done!
I believe this is the best way to go about doing this! If we can get by on base cm7 code then staying updated with the latest from cm7 shouldn't be a problem. Also it in therory should make cm9/ aokp etc easier to iron out all the bugs!
Whenever I get my laptop set back up to build, I'm going to work on picking out the best suited branch to start with from Code Aurora and try to get a vanilla froyo kernel based off the code Aurora sources working. Then from there try and apply those changes to the newer kernels off code Aurora.
It maybe a good idea to try to contact Motorola and see if they wont give us the branch and possibly even commit tag where they forked there kernel from cause I'm pretty sure they started making cchanges to a code Aurora branch on there kernel source. Just which one and where they forked it from is the question. That way we can apply the Motorola source over top that and get the exact changes moto made to the kernel!
If anyone else has anything to add to this or any insights pleas let us know!!
Sent from my Triumph using Tapatalk
Hey g60 if you cab get some logcats on some of the stuff that ain't working right ill look at em and see what I can find!
Sent from my Triumph using Tapatalk
b_randon14 said:
Hey g60 if you cab get some logcats on some of the stuff that ain't working right ill look at em and see what I can find!
Sent from my Triumph using Tapatalk
Click to expand...
Click to collapse
The stuff that is not working has not been added into the device files yet. There is a lot of missing code and lib files. Once I implement more of the changes and stuff isn't working I will holler at you, I have been really focused on fixing the video drivers. I want them playing all formats as perfect as possible before I start adding more stuff. :good:
Hey on the default.xml under the github remote you just have .. so it causes problems when trying to repo sync. Didn't know if you knew it was like that or not!
It should work fine, I just did a repo sync. Make sure you are running the right branch as CM7 changed it from "gingerbread"
repo init -u git://github.com/WX435/android.git -b gb-release-7.2
I just went back in and deleted my folder, then ran repo init again, copying directly from here and it still did the same thing when I tried to run repo sync.
Hop on IRC
b_randon14 said:
I just went back in and deleted my folder, then ran repo init again, copying directly from here and it still did the same thing when I tried to run repo sync.
Click to expand...
Click to collapse
I just looked at it myself. Under remote it shows "..", shouldn't it be git://github.com/
dsmryder said:
I just looked at it myself. Under remote it shows "..", shouldn't it be git://github.com/
Click to expand...
Click to collapse
Nope this is correct it works fine. There are changes CM Team did.
https://github.com/CyanogenMod/android/blob/gb-release-7.2/default.xml
g60madman said:
Nope this is correct it works fine. There are changes CM Team did.
https://github.com/CyanogenMod/android/blob/gb-release-7.2/default.xml
Click to expand...
Click to collapse
So with that, would you have to setup all of your own remotes?
I thought that was to have a Pre-entry for "git remote"?
If you're having issues with the .. in the manifest, see the comments on this commit from cm/android/ where this was originally introduced. The solution is in there:
https://github.com/CyanogenMod/android/commit/89acec784fd50305cc55d05ecb3416fcd7c3eb0e
Yeah i fixed mine by deleting the .repo folder, curling the latest repo into myh ~/bin folder, then pulling the repo in again.
Man I was surprised. I finally got my cm7-bROM repo setup on my new Linux mint install and finally got everything updated from upstream and added some more open commits from gerrit and built it and to my surprise, it built fine with no errors a d I flashed it and it worked great! I figured it would blow up where it had been over a month or two since I had synced and built my ROM and with all the 7.2 release stuff I thought for sure it wouldn't build and add I was building on Linux mind that I had never built on!
Hey g60 you need any help with the device files? I noticed you ain't even got the triumph device repo in the manifest anymore. If you need me to help with anything my box is up and running great! I built my rom in like 47 minutes first time and I was using ccache so hopefully the next build will be faster!
I am digging into my stock code Aurora kernel nor booting. I thought it built fine but I noticed there were some warning spit out by the linker during the build and I tried with linaro and the included 4.4.3 with aosp and it did the sane thing so I'm gonna try to get the bottom of those warnings because I think that may have something to do with it!
Ill post the pastebin of the warning up in the kernel thread later!
Sent from my Triumph using Tapatalk
No updates for a while, still nothing works?
I have been really busy and have had maybe had 1-2 hours to work on the device files in the last 6 days. I should have some more time this week so will see what I can get out.
headset does not register on boot if plugged in
Click to expand...
Click to collapse
Pretty sure this bug was in all CM7 builds before. I also experiences the same thing with MIUI rom.
I would like this to be a joint developer effort for porting CM10 and AOSP Roms to the LTE versions of the Note 2. I have a device tree right now intended for the T-Mobile variant on github: https://github.com/SirWellington/android_device_samsung_t0lt3tmo
It is a fork of the n7100 device tree. There are a couple of things that need to be get a working build.
I am currently having issues compiling. There may be some binaries that I'm missing in properietary-files.sh
Anyone willing to help?
I don't have my build machine available right now, but perhaps if you post what kind of build errors (or more details on the issues) you are getting, some of us can give suggestions.
take care
Gary
Well I got past the build issues I was having. I had to fork the SMDK4412-common tree and make some changes.
It does some filtering on device models (naturally). I basically had to add the t0ltetmo as an approved device.
I am still having build issues elsewhere now:
firmware/SlimISP_ZK.bin.gen.S:5: Error: file not found: firmware/SlimISP_ZK.bin
It really shouldn't be looking for that file since it isn't a proprietary one.
DarthPiggie said:
firmware/SlimISP_ZK.bin.gen.S:5: Error: file not found: firmware/SlimISP_ZK.bin
It really shouldn't be looking for that file since it isn't a proprietary one.
Click to expand...
Click to collapse
That is a proprietary from the i9300...
/proprietary_vendor_samsung/tree/ics/i9300/proprietary/system/vendor/firmware/SlimISP_ZK.bin
https://github.com/TheMuppets/propr.../ics/i9300/proprietary/system/vendor/firmware
Check my github. I've been messing with the t889 and AOKP. It's almost ready. Hopefully tonight I'll get time to finish it up.
A few of us have been trying to get this up and running. I still ccan't figure out why the build is looking for the binary when I removed it from the proprietary files list. I'd be willing to push and pull repos as necessary.
Sent from my SGH-T889 using xda app-developers app
DarthPiggie said:
A few of us have been trying to get this up and running. I still ccan't figure out why the build is looking for the binary when I removed it from the proprietary files list. I'd be willing to push and pull repos as necessary.
Sent from my SGH-T889 using xda app-developers app
Click to expand...
Click to collapse
Try grepping through the -common device and vendor trees, along with (just to be sure) the smdk4412 kernel tree to see what is trying to pull in that file.
Entropy512 said:
Try grepping through the -common device and vendor trees, along with (just to be sure) the smdk4412 kernel tree to see what is trying to pull in that file.
Click to expand...
Click to collapse
Just run through grep -R "<search string>" .
That way you can check every file in your source tree for a specific string. Hopefully you'll be able to track this one down mate!
You guys are correct. I wish we could grep through github sometimes.
Anyway it turns out that the binary is referenced in the Kernel's firmware/Makefile. When I get home I'll do a diff of that one and the stock Samsung one. Correct me if I'm wrong but the N7105 variants do not carry this binary do they?
Sent from my SGH-T889 using xda app-developers app
DarthPiggie said:
You guys are correct. I wish we could grep through github sometimes.
Anyway it turns out that the binary is referenced in the Kernel's firmware/Makefile. When I get home I'll do a diff of that one and the stock Samsung one. Correct me if I'm wrong but the N7105 variants do not carry this binary do they?
Sent from my SGH-T889 using xda app-developers app
Click to expand...
Click to collapse
Where did you fork the kernel from? You can use the smdk4412 kernel on nebkat's github or grab it from my github. I think that will help with a bunch of your problems.
cmenard said:
Where did you fork the kernel from? You can use the smdk4412 kernel on nebkat's github or grab it from my github. I think that will help with a bunch of your problems.
Click to expand...
Click to collapse
I forked it from TeamHacksung. I'll take a look at yours. Did you fork it from anywhere?
Sent from my SGH-T889 using xda app-developers app
The problem I'm running into is RIL related I believe. I can watch the logs and the modem fires up and goes through all it's processes like it should, even does a transmit and recieve... However it's not being recognized within the OS.
This has to do with the kernel configuration when you build it. I'm going to upload my defconfig and you can give it a try. I modified the one from the stock samsung kernel config.
Sent from my SGH-T889 using xda app-developers app
Cmenard have you made any progress? I mamaged to get a successfuo build using your kernel. Thanks for that.
What do you think about pulling the .rc scripts from the stock phone and using those untouched?
Sent from my SGH-T889 using xda app-developers app
DarthPiggie said:
I forked it from TeamHacksung. I'll take a look at yours. Did you fork it from anywhere?
Sent from my SGH-T889 using xda app-developers app
Click to expand...
Click to collapse
Anything on teamhacksung github related to 4412 devices is old. I know there were some kernel patches related to some sort of firmware stuff...
Teamhacksung github is only used for early bringups/bleeding edge work on large repositories. Once a bringup is complete, repos get forked over to the main CM repos.
Anything related to 4412 devices currently (Nov 30, 2012) is in CM's main repos (other than of course themuppets for prop blobs) and managed via gerrit.
Edit: General rule, if a device is receiving nightlies, and you're looking anywhere other than CM's github repo and TheMuppets for props, you're looking in the wrong place.
SOMETIMES when bringing up a new Android version, things get forked to THS then merged back, such as with 4.1 (due to us doing a lot of repo reorganization and such), but all 4.2 work is currently in gerrit. (And, right now, it's a total ****ing mess...)
Seems like the big difference for LTE devices in the kernel is replacement of CONFIG_SEC_MODEM with CONFIG_QC_MODEM and some related items. (I've seen 3-4 different defconfig variants with different stuff turned on/off...)
the RIL blobs will of course be different
The RIL Java interface in frameworks/base might be different.
Thanks I did not know that. I will definitely take a look. That explains why the build was so broken. Ugh.
DarthPiggie said:
Cmenard have you made any progress? I mamaged to get a successfuo build using your kernel. Thanks for that.
What do you think about pulling the .rc scripts from the stock phone and using those untouched?
Sent from my SGH-T889 using xda app-developers app
Click to expand...
Click to collapse
Havent had a chance to mess with again. Just make sure you change gps, add all the mdm stuff, tombstones mount, and all the binaries are in bin and called in the .rc. My modem is working just need to figure the ril out.
Entropy512 said:
Anything on teamhacksung github related to 4412 devices is old. I know there were some kernel patches related to some sort of firmware stuff...
Teamhacksung github is only used for early bringups/bleeding edge work on large repositories. Once a bringup is complete, repos get forked over to the main CM repos.
Anything related to 4412 devices currently (Nov 30, 2012) is in CM's main repos (other than of course themuppets for prop blobs) and managed via gerrit.
Edit: General rule, if a device is receiving nightlies, and you're looking anywhere other than CM's github repo and TheMuppets for props, you're looking in the wrong place.
SOMETIMES when bringing up a new Android version, things get forked to THS then merged back, such as with 4.1 (due to us doing a lot of repo reorganization and such), but all 4.2 work is currently in gerrit. (And, right now, it's a total ****ing mess...)
Seems like the big difference for LTE devices in the kernel is replacement of CONFIG_SEC_MODEM with CONFIG_QC_MODEM and some related items. (I've seen 3-4 different defconfig variants with different stuff turned on/off...)
the RIL blobs will of course be different
The RIL Java interface in frameworks/base might be different.
Click to expand...
Click to collapse
I did a diff on all the kernel configs and you're definitely right about that. I think one of the main things is figuring out the proper partitions for things.
Sent from my SGH-T889 using xda app-developers app
Flashing is still blowing up my IMEI amd signal. I feel that I may need to update my device tree to use the one you suggested (not just the kernel). I'll try that tomorrow thougj. It's so hard to dev on your daily phone though, ugh. Wish I had it as an aside.
Sent from my SGH-T889 using xda app-developers app
Was there any updates on this? I did manage to get as far as getting the latest n7100 nightlies running on the N7105 and ported over the libs and binaries from TW ROM for rild, etc. I also had a tweaked kernel imilka kindly built for the QC radio. Unfortunately I was just getting:
Diag_LSM_Init: Failed to open handle to diag driver, error = 2
Would be interested to hear what is happening for you guys with your real build instead of my 'hacky' attempt at a modified n7100 build.