Related
http://groups.google.com/group/android-building/msg/c0e01b4619a1455a?pli=1
Hi! We just released a bit of code we thought this group might be interested in.
Over at our Android Open-Source Project git servers, the source code
for Android version 4.0 (Ice Cream Sandwich) is now available.
Here's how to get it:Follow the instructions at
http://source.android.com/source/downloading.htmlCheck out the
'ics-release' branch:repo init -u
https://android.googlesource.com/platform/manifest -b android-4.0.1_r1
That's it! However since this is a large push, please be aware that it
will take some time to complete. If you sync before it's done, you'll
get an incomplete copy that you won't be able to use, so please wait
for us to give the all-clear before you sync.
This is actually the source code for version 4.0.1 of Android, which
is the specific version that will ship on the Galaxy Nexus, the first
Android 4.0 device. In the source tree, you will find a device build
target named "full_maguro" that you can use to build a system image
for Galaxy Nexus. Build configurations for other devices will come
later.
Unfortunately we still don't have our Gerrit code review servers back
online. That remains our top priority though, and we hope to have them
back soon.
This release includes the full history of the Android source code
tree, which naturally includes all the source code for the Honeycomb
releases. However, since Honeycomb was a little incomplete, we want
everyone to focus on Ice Cream Sandwich. So, we haven't created any
tags that correspond to the Honeycomb releases (even though the
changes are present in the history.)
Click to expand...
Click to collapse
http://source.android.com/source/downloading.html
hy all
this is an project starter for android 3.4 kernel development for all msm7x30 mogami devices
sources are hosted on
https://github.com/freexperia/android_kernel_semc_msm7x30
br
J
Project Status
- we got initial branch after diffing lost of branches
M7630AABBQMLZA203029A
https://www.codeaurora.org/gitweb/q...it;h=4b2b84c6a0b6d29864e982a7aecc223acfd2eaa1
forked to our git and with mogami patches aplied
https://github.com/freexperia/android_kernel_semc_msm7x30/tree/M7630AABBQMLZA203029A
latest CAF tag for 7630 not usefull for now
https://www.codeaurora.org/xwiki/bin/QAEP/release
"November 16, 2012 M7630AABBQMLZA40701070 - msm7630 - M7630AABBQMLZA40701070.xml - 04.01.02" android 4.1
ETA
depending on problems and developers that will join
from 6 months to NEVER
This is a bold task. Perhaps you could look at the developments of irii-soft (and some others), they have replaced some crap Sony-specific code with generic wrappers. Main obstacle if I remember is memory maps now, there was an issue with partition maps but ATAG can be easily over-ridden via kernel command-line.
Getting it to boot should be trivial, sound and video will be difficult, and RIL may be never working due to lack of sources. Regardless, all the best. When I have more time I plan to help irii with his work on a "generic" 2.x kernel newer than what we have (because 3.x seems outrageous at this point).
Is there a wiki, a forum or something like that lists all the non-standard things that have already been found ? (some base of work to do)
Boudin said:
Is there a wiki, a forum or something like that lists all the non-standard things that have already been found ? (some base of work to do)
Click to expand...
Click to collapse
Easy to do yourself - download official SEMC kernel source and diff it with the same version of the linux baseline kernel. So to port to newer kernel you can isolate or "extract" the specific code that has been added and changed, and merge or "inject" that into a newer kernel. Easier said than done though, there are massive changes even in linux kernel revisions (0.0.x.0) - let alone alone new majors and minors (x.x.0.0).
There wouldn't be a wiki or anything of this research, because documenting it all would take an unrealistic amount of labor. Considering there are only a small handful of developers capable of it, there's no point. Besides, that's what GitHub and commit logs are for.
To FXP team,
I don't know if you know or not or even got this far in the development stage but I just wanted to point out a couple of things which may or may not help you...
So with the 3.4 kernel brings newer WiFi drivers which will give a better connection signal on wpa2 security but you might find that devices won't be able to connect to open security networks and WiFi hotspot will probably be broken. I'm posting this as on my gnex using custom kernel (FrancoFransico) he incorporated the 3.4 WiFi drivers a few times and broken hotspot and not being able to use open security WiFi networks were repeatedly reported problems.
I think it may be something hardware specific which allows these features to work on the 3.4 WiFi drivers specific to the nexus 4? You may have more luck trying the 3.0.xx WiFi drivers and getting those to work fully.
Best of luck to you guys!
Sent from my Galaxy Nexus
I'm pretty sure wifi is way down on the priority list, not to be rude but really - who cares about that now. Priority list would be like this:
(1) Get it to boot
(2) Fix primary/critical hardware-specific code for msm7k and qcom platform (display, audio)
(3) Fix RIL
(4) Fix secondary hardware (sensors, bluetooth, wifi)
One step at a time. Getting wifi will probably be trivial because bcm sources are part of the mainline kernel.
With that said, I'm unsubscribing from this thread now. There is massive work to be done and I can see this thread is just going to be filled with posts that have nothing to do with actual development.
All non-dev related posts, and especially "Thank You" posts, will be deleted without further notice. If I have to delete 5 pages of useless posts again, this thread will be locked.
Thank you!
We have tried for a long time already (as you may already know).
https://github.com/adridu59/semc-msm-3.4/commits/master
https://github.com/adridu59/semc-msm-2.6.35
https://github.com/adridu59/android-msm-2.6.35
https://github.com/ExPeacer/CAF_android-msm-3.0/commits/master
https://github.com/ExPeacer/CAF_android-msm-2.6.32
Have fun with it anyways.
adridu59 said:
We have tried for a long time already (as you may already know).
https://github.com/adridu59/semc-msm-3.4/commits/master
https://github.com/adridu59/semc-msm-2.6.35
https://github.com/adridu59/android-msm-2.6.35
https://github.com/ExPeacer/CAF_android-msm-3.0/commits/master
https://github.com/ExPeacer/CAF_android-msm-2.6.32
Have fun with it anyways.
Click to expand...
Click to collapse
Whats the progress so far on this? Bootable already?
CosmicDan said:
Easy to do yourself - download official SEMC kernel source and diff it with the same version of the linux baseline kernel. So to port to newer kernel you can isolate or "extract" the specific code that has been added and changed, and merge or "inject" that into a newer kernel. Easier said than done though, there are massive changes even in linux kernel revisions (0.0.x.0) - let alone alone new majors and minors (x.x.0.0).
There wouldn't be a wiki or anything of this research, because documenting it all would take an unrealistic amount of labor. Considering there are only a small handful of developers capable of it, there's no point. Besides, that's what GitHub and commit logs are for.
Click to expand...
Click to collapse
I was asked by some user of this forum to give some kernel porting guidelines in this thread, so let me introduce myself first. I'm the developer of 3.0.x kernel for Samsung Galaxy Spica (also several other projects for Spica and Galaxy Apollo/Galaxy 3) and currently also Linux kernel developer at Samsung Poland R&D Center. Porting the kernel for Spica was a difficult task, because of poor quality of original kernel code, which required rewriting from scratch most of it, but it was very educational.
It's not easy to give advice, but I'd say that taking all the differences from clean kernel and applying all of that on top of newer version is what should be avoided. Of course those differences should be collected to see what was changed by the manufacturer, but this should be only used for further analysis, not as a ready code.
Another thing, rather than using the mainline Linux kernel to compare your phone sources with, it should be better to use Android kernel from Google's kernel/common tree (see https://www.codeaurora.org/gitweb/quic/la/?p=kernel/common.git;a=summary for older version archive) bumped to the same minor version using minor patches (found on kernel.org) or, possibly even better way, by pulling appropriate version tag from kernel.org git on top of proper branch of Android kernel tree. This will elminate Google's changes (that would be already available in your new base - android-3.4 branch of kernel/common) from the diff.
For getting the diff, I would personally also use Git. If you create a branch in your working tree which contains Android kernel in the version corresponding to your device kernel (using the way I described in previous paragraph), then copying your device kernel sources onto your working tree (remember to make distclean both trees to remove any compiled/generated files) will allow you to see the differences using git status and git diff. (See http://gitimmersion.com/ if you want to learn more about Git.)
Now it's important to split the changes into logically separate parts, for example core changes in arch/arm/mach-whatever_suitable_for_your_device, adding of particular drivers in drivers/, sound/ and include/, modifications to core kernel code in any other directories. It's essential to check whether all the changes are really required or not and why, because minimalizing the set of changes required to be replayed on top of your new base kernel sources will simplify your work.
After collecting all the changes, it's the time to apply them on top of your new kernel sources. All the changes should be applied one by one, checking how much the component that is being touched has changed since your old kernel and adjusting the changes properly. After applying each change, it should be verified that the kernel at least compiles, although it would be even better if you could get the kernel without any (or almost any) modification to boot to some state, e.g. showing something on the console (any chance to get access to serial console on your device?), and then check if it still boots after applying each next change.
Some links that might be useful:
- Linux cross reference, for comfortable reading of kernel code - http://lxr.linux.no/+trees
- Linux Device Drivers, a book about kernel programming - http://lwn.net/Kernel/LDD3/
- Git Immersion, a great Git tutorial - http://gitimmersion.com/
- Android kernel/common repository with full archive - https://www.codeaurora.org/gitweb/quic/la/?p=kernel/common.git;a=summary
- Linux stable repository, with all version tags - http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
Hopefully what I wrote will be helpful in your project. Good luck and best regards.
Hey tom3q,
thanks a lot for leaving some useful statements here!
tom3q said:
Another thing, rather than using the mainline Linux kernel to compare your phone sources with, it should be better to use Android kernel from Google's kernel/common tree (see https://www.codeaurora.org/gitweb/quic/la/?p=kernel/common.git;a=summary for older version archive) bumped to the same minor version using minor patches (found on kernel.org) or, possibly even better way, by pulling appropriate version tag from kernel.org git on top of proper branch of Android kernel tree.
Click to expand...
Click to collapse
I digged for some base kernel for a while.
Found a chromium msm kernel 2.6.32.9 at codeaurora (i know this is not Android).
Anyway, the diff against stock was ~30MB... quite too much.
Like i assumed many basic things are missing as well, so too much to start from.
I guess, i'll step through the other projects... might try 2.6.32-rc8 from the msm tree... just for fun of course :angel:
tom3q said:
After applying each change, it should be verified that the kernel at least compiles, although it would be even better if you could get the kernel without any (or almost any) modification to boot to some state, e.g. showing something on the console (any chance to get access to serial console on your device?), and then check if it still boots after applying each next change.
Click to expand...
Click to collapse
Nice point... i like these hardware hacks and asked about testpoints for UART3 on the Pro mainboard a few days ago.
It's mentioned and so far i got it, initialized in stock kernel as well. Unfortunately no-one seems to know anything about these testpoints.
Anyway i don't want to spam this thread, so thanks for your attention
Regards,
scholbert
hy
scuse my ignorance
but
HOW do you compile an kernel ?
and maybe someone can explain what is the difference between bring-up and port
scholbert said:
Hey tom3q,
thanks a lot for leaving some useful statements here!
I digged for some base kernel for a while.
Found a chromium msm kernel 2.6.32.9 at codeaurora (i know this is not Android).
Anyway, the diff against stock was ~30MB... quite too much.
Like i assumed many basic things are missing as well, so too much to start from.
I guess, i'll step through the other projects... might try 2.6.32-rc8 from the msm tree... just for fun of course :angel:
Nice point... i like these hardware hacks and asked about testpoints for UART3 on the Pro mainboard a few days ago.
It's mentioned and so far i got it, initialized in stock kernel as well. Unfortunately no-one seems to know anything about these testpoints.
Anyway i don't want to spam this thread, so thanks for your attention
Regards,
scholbert
Click to expand...
Click to collapse
FXP said:
hy
scuse my ignorance
but
HOW do you compile an kernel ?
and maybe someone can explain what is the difference between bring-up and port
Click to expand...
Click to collapse
I would say that porting is moving and correcting sources from 2.6.32 kernel in our case into 3.x. And bring up is writing particular drivers from scratch?
Sent from my Nexus 7
voyteckst said:
I would say that porting is moving and correcting sources from 2.6.32 kernel in our case into 3.x. And bring up is writing particular drivers from scratch?
Sent from my Nexus 7
Click to expand...
Click to collapse
ok
nice explanation
look on first page
diff is 5mb on proper tag
pushed on github
nice to see so many developers trying to help
FXP said:
diff is 5mb on proper tag
pushed on github
Click to expand...
Click to collapse
Sorry to throw my 3 cents again, but seeing the repository on github, I'd recommend you to use some time to go through Git Immersion. Even if it takes some time, it will simplify your further work, as Git used properly can really make many things easier.
Otherwise, the diff itself looks mostly fine as a starting point, although some of the differences can be probably eliminated.
tom3q said:
Sorry to throw my 3 cents again, but seeing the repository on github, I'd recommend you to use some time to go through Git Immersion. Even if it takes some time, it will simplify your further work, as Git used properly can really make many things easier.
Otherwise, the diff itself looks mostly fine as a starting point, although some of the differences can be probably eliminated.
Click to expand...
Click to collapse
sony added too many changes to be usefull
since there are several api changes on 32->3.x diff is no good
we have to start from clean board-7x30 and populate devices porting drivers 1 by 1
we have to try an device bringup based on sony changes
as you know, time laws are renewed constantly, some territories change their timezones etc
the packet tzdata is responsible for such things in linux -> in android
one of the noticeable changes is last week's timezone update for Russia (mentioned in 2014f+)
why does omni still have tzdata2014e bundled?
i used to update it manuallly to 2014i with TimeZoneFixer each nightly
now i'm thinking 'bout flashable zip for flashafterupdate folder
any ideas why don't they push the commit to development tree?
If it is important for you create a gerrit commit
Hi,
I get an increasing amount of pms asking me how to build for chagalllte. If I would answer all that questinons en detail I could stop developing, and just answer emails. So I decided to publish some of the most basic and detailed answers I gave here in this forum.
I also hope, that people trying to build for chagalllte can find each other and build up a team for the task of getting cm to chagalllte. TEAM: together everybody achieves more...
Hope, this helps:
Hello,
Devices are said to be equal... As t700 and t800 are being equal but screen size. That's NOT true. They differ verry subtile. (t700 vs. t800 i.e. differ in sound and touchscreen drivers...).
That being said I would start like this:
learn git - not github, but git on the command line
get both: most current sammy rom for t800 and t805 and put them both untared side by side to you disc
compare them thoroughly - learn the differences
from opensource.samsung.com get kernel sources for both devices: again - learn the differences
start from my gits (device, vendor, kernel) - fork them on github, clone locally
put the differences to the three gits: step by step - commit every change with long comments (wil save your as)
before flashing your first build take a look at /system/etc/wifi of running device with sammy rom, take a look at updater-script of flashable sammy-rom zip, take a look at my git repackrom.sh and use it on your flashable zip.
don't be frutrated, iron out my errors, sammy errors and your errors - build next time...
Good morning,
to get this straight: driver refers to kernel code (statically build in or build as module), blobs (or prorietary binaries) refers to already build binaries from sammy rom: these are libs (i.e. libGLES_mali.so), compiled executables (i.e. gpsd, sswap), loadable firmware for hardware (i.e. /system/etc/wifi/*), some ascii files (some keymaps if I remember right) and all that I forgot...
Of course the mali drive (kernel) interacts ditectly and closly with some of the blobs (in this case libGLES_mali.so, and some people refer to leb_GLES_mail.so as mali driver. This doesn't matter for most people - for you IT DOES MATTER to know of which part I'm speaking...
I recommend usimg the kernel sour8ce from opensource.samsung.com fot T805, but cherry-pick at least the commits from my git or crpalmers picassowifi to make it build inline cm (so if you haven't learned git you are lost here the first time).
For the versions: yeah, you make with sammy's 4.4.2 blobs a cm-11.0 (aka 4.4.4) build. We have to take what we we get - we have no 4.4.4 blobs and propably nver wil get... Sorry.
For cm-12.0 I build at the moment with a mix of sammy 4.4.2, widevine 5.0 (taken from manta) and a hexedit patched libGLRS_mali.so from picassowifi - thats fun, mage. But relax, for cm-11.0 you will come along with the blobs from sammy 4.4.2 rom. You have to find out which blobs you need in addition to the ones I have taken from 800 rom to get modem running.
For the build environment: there are several setup guides for cm. Use google. I use gentoo amd64 build from scratch - but I think you won't want that... *lol*
Add this
Code:
[alias]
lg1 = log --graph --all --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(bold white) %an%C(reset)%C(bold yellow)%d%C(reset)' --abbrev-commit --date=relative
lg2 = log --graph --all --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n'' %C(white)%s%C(reset) %C(bold white) %an%C(reset)' --abbrev-commit
lg = !"git lg1"
to the end of /etc/gitconfig, clone my three gits, cd to them (one after the other) and type each time "git lg1"... "git show [hash]" will show you a single commit. I know it must be boring and anoying for you, but: learn git.
May the source be with you, Nvertigo
thanks so much for posting this, i just hope someone with skills can pick this up
TheLoverMan said:
thanks so much for posting this, i just hope someone with skills can pick this up
Click to expand...
Click to collapse
Just did a quick count: got 27 pms from 8 different people regarding this subject. So if we calculate that only half of this are really interested in giving up their sparetime, partnerships and all other activities, there could be a team of 4 people...
Code long and prosper, Nvertigo
Im also going to try cm forums see if anyone has come up with something
I will try to build and see if i can use your help, if needed. Thanks for the tutorial though.
I would be so grateful for CM12 on LTE model. I don't have knowledge myself, but I thouht maybe we all users of T805 could donate for NVertigo to collect money for him to buy LTE variant? What do you guys think?
Introduction
Hello everyone, this is a thread to introduce both users and kernel developers to the concept of linux-stable as well as give developers some tips and a tree to either merge into their own, use as a base, or just as a reference. Feel free to ask questions and enjoy!
What is it?
linux-stable is, as the name implies, the stable branch of the Linux kernel, the base of Android. The phone could not run without the Linux kernel (at least not without reworking a lot of stuff). The Android kernels are based on the longterm stable trees:
Longterm
There are usually several "longterm maintenance" kernel releases provided for the purposes of backporting bugfixes for older kernel trees. Only important bugfixes are applied to such kernels and they don't usually see very frequent releases, especially for older trees.
Click to expand...
Click to collapse
Source: https://www.kernel.org/category/releases.html
All Linux development happens on the master branch, which is governed by Linus Torvalds. When issues are discovered there, the fixes are applied then backported to these various stable trees for consumption. It is not uncommon for a fix to need to go back a few years.
There is a LOT more information available in the notes repo in the android-linux-stable organization if you care to learn more in-depth: https://github.com/android-linux-stable/notes
What does this mean for me?
If you are a developer, this means you should be merging these changes into your own tree. These are vetted, stable fixes to real world problems and they are being handed out for free. It does not take long to get up to date (as you can just merge this tree directly into your own or do it yourself using the tree as a reference) and once you are up to date, there is usually a release once every two weeks, give or take. I provide a rebuttal to a lot of various complaints here. If you still feel like there is a good reason not to do this, please let me know, I'll be happy to try and debate on it!
If you are a user, it means that you should be looking for and using kernels that have these fixes, as it shows the developers care for your security and stability. The current version for this device is 3.18.100 and the current version upstream is 3.18.124 so all you need to do is go into Settings > About phone and look at the kernel version to know if you are up to date.
How do I use?
If you are a developer, the reference tree is located in the android-linux-stable organization: https://github.com/android-linux-stable/marlin
This can either be merged into your existing kernel tree if you have one or be used as a fresh base. You do not need my permission to use it nor do you need to give me credit (although it would be appreciated).
If you are a user, use a kernel that has the changes added in!
Getting notified about updates
There are a few ways to get notified of linux-stable updates:
The linux-kernel-announce mailing list: http://vger.kernel.org/vger-lists.html#linux-kernel-announce
The android-linux-stable Telegram channel: https://t.me/alsupdates
Subscribe to this thread
Follow me on Google+ or Twitter
Getting help
If you have any issues with getting these changes into your tree or want to ask a question, there are a few different ways to do it:
Post in this thread
Join the linux-stable support chat on Telegram: https://t.me/joinchat/C1UAJ1EMSX31PCFdwLnOSg
File an issue either in the android-linux-stable notes repo or the android-linux-stable repo for this device
When requesting help, please give some solid details as to what you are struggling with, as I am happy to provide assistant and clarity but not to do something for you (unless I screwed up).
3.18.88 has been merged in.
3.18.89 has been merged in.
3.18.90 has been merged in.
3.18.91 has been merged in (conflict notes).
Hi Nathan, thanks for the code - built the kernel and flashed (wasn't easy at first). All working well, will use it at a later stage when I build the ROM. BTW, I am running the factory image. Credit also to Anykernel for the zip file
GeyerA said:
Hi Nathan, thanks for the code - built the kernel and flashed (wasn't easy at first). All working well, will use it at a later stage when I build the ROM. BTW, I am running the factory image. Credit also to Anykernel for the zip file
Click to expand...
Click to collapse
Not a Dev, but totally would like to give this a try if you have a zip. On the factory image + twrp 3.2.1
Sent from my [device_name] using XDA-Developers Legacy app
Hi, No problem. There you go... Just flash in TWRP and feedback if all went ok
3.18.92 has been merged in.
Hi, thanks for the code, compiled it against linaro 6.4 (built the cross-compiler following your thread). Tested for one day. All smooth. Sharing the job for those who might be interested. BTW, flashed it directly from fastboot....
Code:
fastboot flash kernel Image.lz4-dtb
Hi, added WireGuard support.
@ nathanchance, sorry, do not mean to hijack your thread...
GeyerA said:
Hi, added WireGuard support.
@ nathanchance, sorry, do not mean to hijack your thread...
Click to expand...
Click to collapse
No worries lol, gives it some life :silly:
Sent from my Pixel 2 XL using XDA Labs
GeyerA said:
Hi, added WireGuard support.
@ nathanchance, sorry, do not mean to hijack your thread...
Click to expand...
Click to collapse
Running this now, so far so good! Thanks!
Definitely interested in wire guard, but currently use WindScribe and am not sure how to properly configure it.
Will try and Frankenstein a config file together tonight and report back [emoji106]
Thanks again
Sent from my [device_name] using XDA-Developers Legacy app
Hi, question. Added DSPManager to my ROM and see that it always gets killed. Can you support the idea to build the kernel with
Code:
CONFIG_SECURITY_SELINUX=n
. Will this get me the kernel permissive and any disadvantages with this? I also see that Viper4android needs a permissive kernel.
3.18.93 has been merged in.
Somebody willing to do a build of the update to flash with fastboot?
I would if I could (still learning how to build myself)
Thnx in advance.
Cheers
Sent from my Google Pixel using XDA Labs
Sgace said:
Somebody willing to do a build of the update to flash with fastboot?
I would if I could
Thnx in advance.
Cheers
Sent from my Google Pixel using XDA Labs
Click to expand...
Click to collapse
Was just going to ask if someone could point me to a good resource on how to do so. Will post anything I manage to do [emoji106]
Sent from my [device_name] using XDA-Developers Legacy app
jimbub said:
Was just going to ask if someone could point me to a good resource on how to do so. Will post anything I manage to do [emoji106]
Click to expand...
Click to collapse
Hi,
I used this for the most part: https://forum.xda-developers.com/yureka/help/guide-compiling-64-bit-android-kernel-t3352728
And this:
https://forum.xda-developers.com/an...-how-to-compile-android-kernel-t3627297/page1
Was very helpful and am building right now
Credits to those guys offcourse.
Sent from my Google Pixel using XDA Labs
Sgace said:
Hi,
I used this for the most part: https://forum.xda-developers.com/yureka/help/guide-compiling-64-bit-android-kernel-t3352728
And this:
https://forum.xda-developers.com/an...-how-to-compile-android-kernel-t3627297/page1
Was very helpful and am building right now
Credits to those guys offcourse.
Sent from my Google Pixel using XDA Labs
Click to expand...
Click to collapse
If it's ok, here is my personal first ever self built kernel from source. It's 3.18.93 and flashable in fastboot (unzip the zip and then: fastboot flash kernel Image.lz4-dtb)
Offcourse thnx to @nathanchance for the source and all the work!
Cheers
Sgace said:
If it's ok, here is my personal first ever self built kernel from source. It's 3.18.93 and flashable in fastboot (unzip the zip and then: fastboot flash kernel Image.lz4-dtb)
Offcourse thnx to @nathanchance for the source and all the work!
Cheers
Click to expand...
Click to collapse
Thanks for doing this, very much appreciate it! For some reason though, this prevented my phone from booting. Ended up restoring my boot partition and things are well now!