ExFat for bump'd devices? - AT&T LG G3

On my old LGOG there was a file I could flash that allowed SlimKat to access my exfat sdcard. Can we get such a thing for our G3's?

Just a lil bump...hoping for a solid answer.

Question is a bit cryptic. Maybe SDfix is what you need?

Negative. Sdfix changes permissions to allow for RW permissions on an external sd card.
The issue I'm asking about is related to the file system. ExFat vs Fat32
Those that have bumpd their devices have reported that their ExFat formatted sdcards don't play nice...once reformatted to Fat32, they work again. This same issue existed in my LGOG. But there was a file that I would flash along with a new rom that would fix the issue.
I'm asking if that file or something similar would work for our G3's.

facing same challenge
Yea I'm not sure how preferences are towards stock/aosp/cm roms but I found myself with the same challenge. I guess I would be best characterized as a noob but I have found some information and noticed some things in addressing this. First you are looking for exfat-nofuse support, I've found this is present within stock/stock based roms seemingly since kitkat versions, also I cannot say for kitkat but for lollipop aosp based roms had implemented this fs access in there lollipop roms. As for cm based roms I noticed they added this feature around the 5th or 6th of this month and likely will see this feature in those roms only in cm13 releases. Now I have tried quite a few roms on my d850 but I will not feign I've tried all roms so there could be some exception to what I've noticed in experiencing this exfat fs challenge too. As for addressing this with your current running rom I wish I could be more helpful there are some files I've collected that seem to look at addressing this but absent direction through how others have addressed this I've just gone to an aosp rom for now. I would like to work through this too though as there is a cm based rom I really enjoy and the lack of exfat fs capability is really the deciding factor now with cm13 roms only just being released for our device. Thank you for your attention to trying to resolve this issue too. Currently I cannot remember specifically where I downloaded the files with the work that would seem to address our issue but the files names are exfat-nofuse-master.zip and fuse-exfat-exfat-utils-0.9.5-static-binaries.zip. I will be spending some time in this area today and thinking of flashing the binaries package on a cm based rom see if that has any effect. As for where I found those files I will look to add that info here later on this afternoon. Is also a little tough for me posting links when I'm not certain the files those links lead to really should be used in addressing our issue or if they are the appropriate files how to use them correctly to not cause device damage. Again thank you for your time and efforts here, hgd.
Added Note: Yea I had about pulled out my hair on this as those files I mentioned seem to be source files for compiling exfat kernel drivers for different setups. It would seem that the way around this outside of installing roms with it already implemented is to cross-compile the source on linux for our phones architecture at the same time as where I said I'm a noob I really cannot say that is the complete resolution as it seems this code needs to be set as a kernel module which seems above my learning curve today. I've also tried various kernel's on different roms as some kernel releases say that installing them on your rom will solve this issue but that experience was troublesome to say the least. Good luck friend.

Related

[Q] PAC-Man ROM v22.3.0 ~AOSPA + AOKP + CM10.1~ - OTA updates (5/19/2013)

Alright, noob here. Since I cannot post in the PACMAN development thread (http://forum.xda-developers.com/showthread.php?t=2164406) I will put this here.
- Problems installing PACMAN ROM
- After receiving "Errors Flashing", failures, downgraded recovery to TWRP 2.3.3.0
- 2.3.3.0 displayed "Error 7"
- Searching on error 7 led me down the path of the assert checks
- updater-script assert command in PACMAN ROM package is checking for model "ville".
- My HTC One S Special edition returns "villeplus" from "adb shell getprop ro.product.device"
My understanding is that the North American S4 and the Special Edition share identical hardware, only differing in drive size (16 vs. 64GB), so I am assuming any ROM designed for the ville will work on my phone.
Assuming it will I should be able to edit the "updater-script" file, but when I extract it windows is telling me that 23 files are duplicates. I'm not sure if this is because its windows vs. Linux that I'm extracting it on?? In any case, I don't seem to be able to modify the file without adversely affecting the integrity of the archive. Also would assume replacing the file will affect the MD5 hash which I believe TWRP checks when loading the ROM?
So first off, can someone confirm that this ROM will be compatible with my phone and 2, any suggestions on modifying the updater-script file within the archive?
Update
I was able to modify the updater-script file tonight using file X-Plore and text edit, so now the script is looking for "villeplus" rather than ville. My phone is S-OFF which I read means that it does not do signature checks... however, I'm not sure if that also means it bypasses MD5 checksums - I suspect not since I'm pretty sure I saw it verifying MD5 previously. So, since I tampered with the ZIP it still may not work.
My real question now that remains is even if it will work, do I want to flash a ROM built for the ville to my villeplus. The more I read about custom ROMs the more it appears that they are extremely specific to models.
I am still extremely curious to try it... rumor has it that curiosity didn't work out so well for the cat though. :-/
merovingian_a51 said:
I was able to modify the updater-script file tonight using file X-Plore and text edit, so now the script is looking for "villeplus" rather than ville. My phone is S-OFF which I read means that it does not do signature checks... however, I'm not sure if that also means it bypasses MD5 checksums - I suspect not since I'm pretty sure I saw it verifying MD5 previously. So, since I tampered with the ZIP it still may not work.
My real question now that remains is even if it will work, do I want to flash a ROM built for the ville to my villeplus. The more I read about custom ROMs the more it appears that they are extremely specific to models.
I am still extremely curious to try it... rumor has it that curiosity didn't work out so well for the cat though. :-/
Click to expand...
Click to collapse
Unfortunately, i have to fully disappoint you.
The villeplus is having the exact same hardware as the ville. Theoretically ideal. Unfortunately, HTC decided to make it a "/data/media" device unlike its brother, the ville.
Explained: the Ville has a partition for the SDCard and its mounted with its own mountpoint, /sdcard.
The Villeplus has a partition for the SDCard too, but its mounted inside the /Data partition as /data/media. This means a lot of problems from every imaginable aspect.
I spend a week together with Torxx from ViperOneS to get Viper to run on it and we found out that a.) the Kernel needs to be adjusted and b.) some libs and etc. which is real dev work and which no dev in the OneS section has time for.
Later i spent another two weeks with Philz and mdmower trying to at least get recovery to mount the sh.it thing as USB, which turned out to be impossible at this time as it is only possible through the MTP protocoll, which no recovery supports as of yet.
Since i am a n00b myself i did not entirely understand the nature of the problem, but it seems to be very complex.
At some point i suggested to actually rewrite the partitions on the phones so they would work the same way as on the ville. I even tried myself and flashed a Ville RUU to my Villeplus (it works, doesnt break anything) but with the same effect as custom roms: my SD was then in Data/media and the internal apps memory and RAM were shifted to somewhere else with not enough space so the phone kept running out of space and crashed often. Also all system components trying to access stuff on the SD failed to find their stuff and crashed.
Since we don't actually have means to change the chip controller programming so it offers the partitions differently to the ROM we cannot go that way either (Zarboz tried to explain it to me but i failed understanding it, somehow the device pathes are put into the actual chip and not part of any RUU, so to change them one would need to have some special software tool like we could have done on the HD2 back then).
The only viable way would be to adjust ROM modules and Kernel to this structure, which won't happen as no dev has this device and there are like maybe 5 active users here.
You are out of luck my friend. Sorry. I too was full of hope and gave it up when all devs i contacted signalled that there is no benefit for them and they wouldn't waste their time basically.
Sneakyghost said:
Unfortunately, i have to fully disappoint you.
The villeplus is having the exact same hardware as the ville. Theoretically ideal. Unfortunately, HTC decided to make it a "/data/media" device unlike its brother, the ville.
Explained: the Ville has a partition for the SDCard and its mounted with its own mountpoint, /sdcard.
The Villeplus has a partition for the SDCard too, but its mounted inside the /Data partition as /data/media. This means a lot of problems from every imaginable aspect.
I spend a week together with Torxx from ViperOneS to get Viper to run on it and we found out that a.) the Kernel needs to be adjusted and b.) some libs and etc. which is real dev work and which no dev in the OneS section has time for.
Later i spent another two weeks with Philz and mdmower trying to at least get recovery to mount the sh.it thing as USB, which turned out to be impossible at this time as it is only possible through the MTP protocoll, which no recovery supports as of yet.
Since i am a n00b myself i did not entirely understand the nature of the problem, but it seems to be very complex.
At some point i suggested to actually rewrite the partitions on the phones so they would work the same way as on the ville. I even tried myself and flashed a Ville RUU to my Villeplus (it works, doesnt break anything) but with the same effect as custom roms: my SD was then in Data/media and the internal apps memory and RAM were shifted to somewhere else with not enough space so the phone kept running out of space and crashed often. Also all system components trying to access stuff on the SD failed to find their stuff and crashed.
Since we don't actually have means to change the chip controller programming so it offers the partitions differently to the ROM we cannot go that way either (Zarboz tried to explain it to me but i failed understanding it, somehow the device pathes are put into the actual chip and not part of any RUU, so to change them one would need to have some special software tool like we could have done on the HD2 back then).
The only viable way would be to adjust ROM modules and Kernel to this structure, which won't happen as no dev has this device and there are like maybe 5 active users here.
You are out of luck my friend. Sorry. I too was full of hope and gave it up when all devs i contacted signalled that there is no benefit for them and they wouldn't waste their time basically.
Click to expand...
Click to collapse
Wow, Sneakyghost, I can't thank you enough for your prompt (I just PM'd him last night folks) and very thorough response.
I'm wondering why HTC did this - thinking maybe to prevent/protect users from tampering with the device - perhaps other ROMs wouldn't run on it in a stable fashion.. or they just don't want people messing with custom ROMs. Perhaps this was a new architecture for them (wondering if the One and One X followed this same design?).
In any case, looks like I'll be sticking to looking at launchers and custom widgets. I'm actually quite happy with 4.1.1 and Sense (maybe because I'm new to Android, not sure), I mainly wanted to try experiment with custom ROMs, and learn about how all this stuff works. At least till the M4 comes out anyways..
Thanks again so much for your response, it is much appreciated and well explained.
Sneakyghost said:
... Unfortunately, HTC decided to make it a "/data/media" device unlike its brother, the ville.
Click to expand...
Click to collapse
Oh the irony, the (unreleased) 4.2 update for ville actually reformats partitions for data media. I don't think the update will ever be officially available to US users, but it is funny nonetheless.
This, my friend, is indeed ironic, if not even sad.
Considering what it means, I come to understand that porting ROM's from Ville to Villeplus would have gotten much easier then. Only that it is too late.
Torxx and I gave up due to the amount of work attached to the previous system structures, but if the Ville turns into a datamedia device with that update, many ROM devs and chefs would have to deal with it plus HTC would have done the most difficult part already anyway...
What a shame that this comes so late now and doesn't even get released probably...
mobile post

Suggestion:TWRP, exfat, GT-N7000 external SD Card bug

On my Samsung GT-N7000 I'm trying Omnirom again. I've tried it in the past and also tried vanilla CM stable and nightlies. I have also tried SuperNexus and PA and some other stuff that left no impression. Basically on this device for functional hardware, reasonable user control and a coherent UI it is Samsung's Touchwiz rooted, or Omnirom.
It is a bit too hard to install Omnirom and it can be horribly tedious to go from Omnirom back to stock or to another ROM. It's OK after you have done it a few times, but it is a huge obstacle for anyone trying to discover the way via inaccurate, misleading and fragmented documentation. The install guide at omnirom.org is actually utterly useless for this particular device, a complete non-starter. XpLoDWilD your GT-N7000 specific thread at http://forum.xda-developers.com/showthread.php?t=2516933 almost guarantees a boot loop because it only mentions but doesn't identify or link to versions of CWM which are adequate. In fact unless the user by diligent searching (or more likely by blind chance) comes across a link to the specific suitable raw kernel then it is one big dead end. You could spend hours and days searching for a suitable CWM and never find it because actually you should be searching for raw_kernel_r#_j##.zip. But how is anyone meant to know this. It turns what is actually a reliable and rather trouble free 15 or 20 minute process into a some kind of waking torment. In the past the documentation on installing via CWM was so bad that I used ODIN, which is less than ideal IMO because it means that anyone switching from stock to Omni doesn't get the chance to make a full nandroid backup of the original system (so to revert means a very tedious clean install).
So assuming the end user somehow finds the right raw kernel whose recovery can install Omnirom, what should they do? Of course they should back up their current apps and also make a nandroid backup. Apps backup is easy with oandbackup or titanium or similar. How about a nandroid backup to external SD? No problem in CWM but once you have TWRP installed you can't use it to access anything on an exfat formatted external SD card! You can back up before installing Omnirom but afterwards you can't restore! This is 100% nuts. exfat has now been around for 8 years. CWM supports it brilliantly. Even my crusty old Debian stable desktop reads and writes to exfat at very high speeds even via a FUSE FS and my puny Asus EeePC netbook running XP Home handles it fine. TWRP? Nope. exfat? Wha tha? Aaaaaagh.
Sorry to rant But for these specific devices Omnirom (with an exfat SD) is really the only high quality competitor to the stock Samsung, and there surely isn't a good reason for it being so frustrating to install and also to revert? Is TWRP really such a killer facility that it is worth foregoing the ability to backup and restore to the now very common exfat microSDHC? I run plain CM 11 on another device and OTA updates work fine on that. In these days of phatter pipes is it really worth making a huge compromise in functionality simply to avoid 200MB of downloads sometimes? On this device the delta updates are going to fail for many anyway unless they use an exfat card, but if they use an exfat card they.....oooouuuurrrggg...vicious circle.
/rant over.
Loving Omnirom btw and writing as a fan.
#blamesamsung
The Exynos Galaxy S2 family are some of the only devices remaining that don't have separate recovery partitions. This has always led to various annoyances for custom firmware users since it's impossible to change recovery without changing kernel.
Probably the documentation could be updated to indicate a double-flash though. Flash once to get a working recovery, flash a second time to get a working /system
Entropy512 said:
#blamesamsung
The Exynos Galaxy S2 family are some of the only devices remaining that don't have separate recovery partitions. This has always led to various annoyances for custom firmware users since it's impossible to change recovery without changing kernel.
Probably the documentation could be updated to indicate a double-flash though. Flash once to get a working recovery, flash a second time to get a working /system
Click to expand...
Click to collapse
Thanks for responding. I do appreciate that the exynos based devices are sons-of-b...b...bad persons.
I know documentation is boring and mostly thankless but it also matters a lot, most especially for projects which invite the user to perform realtively complex and potentially hazardous tasks.
Personally I would be very happy to edit/update XpLoDWilD's guide, but of course I can't because it's a forum post, not a wiki, so he owns it and it will remain there guiding new and trusting people into disappointment and boot loop oblivion until he decides to change it.
Omnirom has some issues but on the GT-N7000 is probably the only really mature and coherent alternative UI to Samsung's Touchwiz. To me it seems simply insane to direct newcomers into an unnecessary, time consuming, badly described and potentialy hazardous obstacle course, when in fact installation can be done with only small inconvenience.
I'm currently looking for information about installing OmniROM (I'm currently running CM11 nightlies), and I can attest the information in XpLoDWilD's post is somewhat vague, and also doesn't fully correlate with the directions to install Omni at the official wiki -- I'm assuming this lack of correlation is partly due to the fact, mentioned in this thread, that the N7000 doesn't have a separate recovery partition.
Something which made me especially uncertain about the installation process is the following part:
XpLoDWilD said:
- Make sure you're running a proper working ClockworkMod-Recovery - WITH SELINUX SUPPORT!
Click to expand...
Click to collapse
My understanding is that SeLinux is a feature of the kernel -- not the recovery console -- am I wrong about this? Or should I look for SeLinux in the features of the recovery console as well? (if so, how?)
What I currently do, is run adb, or start a console from the normal operating mode (not recovery mode), run the command:
Code:
getenforce
and confirm the reply is:
Code:
Enforcing
which means I have a kernel with SeLinux. Is that good enough to ensure the requisites for the installation are provided?
I'd appreciate any input about this matter.
julian67 said:
Personally I would be very happy to edit/update XpLoDWilD's guide, but of course I can't because it's a forum post, not a wiki, so he owns it and it will remain there guiding new and trusting people into disappointment and boot loop oblivion until he decides to change it.
Click to expand...
Click to collapse
Cant you add device-specific installation guide at the official wiki?
sagie said:
Cant you add device-specific installation guide at the official wiki?
Click to expand...
Click to collapse
I'm back on rooted Samsung TouchWiz. As things stand I wouldn't encourage any normal end user with a GT-N7000 to try a ROM. Hardware support is poor and unlikely to improve, installation documentation is misleading, backup is difficult, and restoring stock Samsung successfully requires ODIN. Also you stand a real chance of bricking the device. On my B+N Nook HD CM11 nightly is, as far as I can tell, beyond criticism but on these Exynos based devices all the third party ROMs have poor hardware support, poor multimedia support, poor stability and truly terrible battery life (even with no gapps installed). I will keep trying out ROMs occasionally and if the day arrives where the hardware is truly supported I will write a guide and drink a bottle of french fizz, but at the moment I would discourage any regular end user from doing anything to their GT-N7000 except running the newest available official firmware and rooting it if required.
I'm pretty sure I can save my twrp backups to my exfat sdcard.
edit: yup. just touch "internal storage" on the twrp backup page and select your sdcard.
julian67 said:
I'm back on rooted Samsung TouchWiz. As things stand I wouldn't encourage any normal end user with a GT-N7000 to try a ROM. Hardware support is poor and unlikely to improve, installation documentation is misleading, backup is difficult, and restoring stock Samsung successfully requires ODIN. Also you stand a real chance of bricking the device. On my B+N Nook HD CM11 nightly is, as far as I can tell, beyond criticism but on these Exynos based devices all the third party ROMs have poor hardware support, poor multimedia support, poor stability and truly terrible battery life (even with no gapps installed). I will keep trying out ROMs occasionally and if the day arrives where the hardware is truly supported I will write a guide and drink a bottle of french fizz, but at the moment I would discourage any regular end user from doing anything to their GT-N7000 except running the newest available official firmware and rooting it if required.
Click to expand...
Click to collapse
i've been using omnirom as my daily driver for 2 weeks now. love kitkat and omnirom features, but its still very unstable i think. stuff that's bothering me for now:
-stock camera is really plain, can't even switch to front camera
-video playback sometimes fail
-music playback will fail the first time i launch and play a song or 2. have to reboot and it'll work all day long
-intermittent random reboots, about 3 times so far the whole week
-wifi signal range is somewhat lower compared to touchwiz rom
-stock clock app, can't manually input time via keypad when you want to add an alarm
-contacts app is very confusing, can't even add a contact with ease. well at least for me that is
other than that kit kat is sure a welcome on this legendary device. contemplating the switch back to stock touchwiz, but loathe at the idea of setting up everything again zzz
In answer to this, and if it can help.
That the second time I install a ROM on my N7000, so it was still a bit frightening for me
Based on a CM10.1, I already had an old CWM.
1) From CWM I've just installed Philz Touch
2) On Philz, i've wiped everything, formated both internal and external sd cards (well I wanted something reeeally clean)
3) Used abd for copying omnirom and Gapp zip on the root
4) installed them from Philz Touch.
And it works like a charm (... but not enough feedback yet, just 2 days).
Now the question is to know if a day Omnirom will accept CWM based recoveries for updates.
TWRP is unfortunately not available on N7000 (from what I see, only USA flavors of Galaxy Note1).
Thanks!
Polux
Polux44 said:
In answer to this, and if it can help.
That the second time I install a ROM on my N7000, so it was still a bit frightening for me
Based on a CM10.1, I already had an old CWM.
1) From CWM I've just installed Philz Touch
2) On Philz, i've wiped everything, formated both internal and external sd cards (well I wanted something reeeally clean)
3) Used abd for copying omnirom and Gapp zip on the root
4) installed them from Philz Touch.
And it works like a charm (... but not enough feedback yet, just 2 days).
Now the question is to know if a day Omnirom will accept CWM based recoveries for updates.
TWRP is unfortunately not available on N7000 (from what I see, only USA flavors of Galaxy Note1).
Thanks!
Polux
Click to expand...
Click to collapse
Per my earlier post - You cannot change kernels on the Samsung GS2 family (including N7000) without also changing recovery.
Conversely, you can't change recovery without changing kernel. It's a limitation of this device since the recovery partition is not actually used, and recovery is in the normal kernel.
Once you flash Omni, your recovery will be TWRP. The reason TWRP doesn't "officially" support any of the GS2 family is because, as I said - you can't change recoveries without changing kernels.
Entropy512 said:
Once you flash Omni, your recovery will be TWRP. The reason TWRP doesn't "officially" support any of the GS2 family is because, as I said - you can't change recoveries without changing kernels.
Click to expand...
Click to collapse
Yes thanks for the precision, i've just seen that now my recovery was TWRP. (well which is good for me since it means I can use OTA). Your details helped me to understand why recovery and kernel are linked together, for my device.
Does it mean that installing omni on a non GS2 device (let's say a more recent device) will not overwrite the existing recovery?
Thanks again!
Polux44 said:
Yes thanks for the precision, i've just seen that now my recovery was TWRP. (well which is good for me since it means I can use OTA). Your details helped me to understand why recovery and kernel are linked together, for my device.
Does it mean that installing omni on a non GS2 device (let's say a more recent device) will not overwrite the existing recovery?
Thanks again!
Click to expand...
Click to collapse
Correct. Sony devices also have this limitation, there is a semi-workaround (where the kernel pulls recovery ramdisk from another location) on those that *in theory* could be done on the old Samsungs... but so few people are working on the old Samsungs that it isn't likely to happen.
Pretty much all GS1s and Exynos GS2s had this limitation. Qualcomm GS2s (Skyrocket/Hercules) had a separate recovery, as did all GS3s and onwards.

[ROM] CARBON-KK-UNOFFICIAL_f2fs-20150526-moto_msm8960

Hi guys,
for those of us who are waiting for at least the M1 of CM12 before switching lanes, I did a build of Carbon (and a few of CM11, previously) for our Photons.
This is an odexed ("user", not "userdbg") build, running on the cm-12.1 kernel branch and using the latest available f2fs_tools. It also features a modified init which can use either f2fs or ext4 for /cache and /data - so switching to f2fs is highly recommended, but not mandatory. Superuser is included.
This is esentially for those who switched to CM12 just for f2fs; it's miles faster than cm12, and a bit more responsive that the old official cm11 nightlies.
A word of warning. TWRP's "change filesystem" function formats the partition (PhilZ does too, but at least it makes that explicit).
So what you want to do when switching from an ext4 ROM is,
before you begin: copy everything in the internal sdcard somewhere on the external sdcard; this is needed, since the "internal sdcard" is actually a folder in /data;
in TWRP, begin by creating a backup of /data (that saves everything except the "internal sdcard" and /cache - that's why you need step #1);
do the FS change for both /data and /cache
restore the /data backup, on the freshly formatted /data partition; ignore the "different filesystem" warning, it's inconsequential;
install the ROM;
once you booted the phone, copy back the old contents of the internal sdcard
You only need to do this when you change filesystems, which will be exactly once if you like my ROMs And obviously, if you don't, you have to use the exact same procedure before flashing an ext4 ROM, if you don't want to lose data.
Though, in all fairness, I'd recommend flashing this cleanly - unless you're upgrading from an ext4 Carbon build.
A note on the radio
I have included a tool called radio-tool (of my own design) that allows people to enable/disable the US GSM lock and individual network bands;
if you're having the SIM mod, and are from, or have business in, the US, you can use it to kill the CDMA and Sprint LTE bands altogether, as well as to enable US GSM bands and disable the US GSM lock;
the source code is here
Use (as superuser)
Code:
radio-tool [dbg] [{+|-}opt [...]]
where opt is one of
uslock - US GSM lockout
cdma - CDMA bands (CDMA800 / CDMA1800 / CDMA2000 1xEV-DO)
usgsm - US GSM/HSPA bands (GSM850, GSM1900, WCDMA850, WCDMA1900)
eugsm - EU GSM/HSPA bands (GSM900, GSM1800, WCDMA900, WCDMA2100)
sprlte - Sprint LTE (LTE25, 1900)
vzwlte - Verizon LTE (LTE13, 700)
Download:
ROM: CARBON-KK-UNOFFICIAL_f2fs-20150526-moto_msm8960.zip
Recoveries: TWRP-2.8.6.0-20150526-f2fs-moto_msm8960_jbbl-xt897.img, PhilZ-6.59.0-20150520-crkk_f2fs-moto_msm8960_jbbl-xt897.
You do not need to use a su app with this; but if you want to, please use the latest SuperSU. Attempting to use a different, or older, su app could result in no radio.
Changes from stock Carbon:
alternative mount points support - this enables the ROM to work with either f2fs or ext4 for /data and /cache
tuned mount settings - kickass speed with both ext4 and f2fs
256MB of lz4-compressed swap space (zram0)
built on gcc-4.8-sabermod
build.prop tweaks - this defaults to GSM/WCDMA - plus a few radio and network tweaks;
added a few goodies that are present in CM builds (Term, Apollo, Calendar, CMWallpapers, VideoEditor, plus the cmdline utils);
removed the stats and the update apps (for obvious reasons)
added Romanian (programmers) keyboard support in Asanti Keypad
built with: twrp 2.8.6.0, cm12.1 kernel, cm12.1 f2fs-tools, cm12.1 e2fsprogs, cm12.1 exfat, cm12.1 fuse.
(this will allow me to pick up any improvements in kernel, file systems, and recovery, with great ease )
Quirks:
MTP doesn't start by default in TWRP, despite the fact that it claims to be enabled; disable and re-enable MTP, and it will work
in PhilZ' mount menu, entries for cache and data are duplicated; this is cosmetic - mounting and umounting works just fine, regarless which of the two entries for each partition you choose
.
Older, CM11 vanilla builds:
Download:
cm-11-20150427-UNOFFICIAL_f2fs-moto_msm8960_jbbl.zip - repo syncs, builds with TWRP, uses branch cm-12.1 of the kernel, uses latest available f2fs-tools
Use latest SuperSU with any of the CM ROMs - older, or different, su apps might make the radio not work.
NOTE. These ROMs are actually moto_msm8960_jbbl, so they should work on all devices for which official moto_msm8960_jbbl builds did, as long as they're still on the JB bootloader (jbbl) and you have a device-specific recovery that supports f2fs. A suitable PhilZ touch for non-xt897's can be found on the AtrixHD thread, courtesy of @palmbeach05, or you could use PhilZ-6.59.0-20150506-crkk_f2fs-moto_msm8960_jbbl-mb866 (note, despite the -mb866 suffix, it should work on any moto_msm8960_jbbl device except xt897).
The current repo is available here. To use,
repo init -u https://github.com/mionica/android.git -b cr_kk_gcc-4.8
repo sync
. build/envsetup.sh
breakfast carbon_moto_msm8960_jbbl
edit the .repo/local_manifests/roomservice.xml, changing the device project for android_device_motorola_moto_msm8960_jbbl to
Code:
<project path="android" name="mionica/android_device_motorola_moto_msm8960_jbbl" remote="mionica" revision="cr_kk_xt897" />
repo sync again
finally, (cd vendor/carbon && ./get-prebuilts).
After you do that, you're good to go - (optional) configure ccache (if it's your first build), (optional) enable ccache, choosecombo, then mka carbon 2>&1 | tee BUILD.LOG.
If you're not sure how to do any of these, either just use the provided ROM, or search on youtube for "building CyanogenMod" - that should help, I know it helped me Anyway, this thread is not the right place for learning how to build Android.
Mirrored for archival purposes.
This server WILL BE SLOW. You've been warned.
http://lionspaws.net/cm-11-20150401-UNOFFICIAL_f2fs-moto_msm8960_jbbl/
98e652a97965ba5d88cb9068fe7d4dbe *cm-11-20150401-UNOFFICIAL_f2fs-moto_msm8960_jbbl.zip
Using it for the last few days, seems good so far. Thanks
taking a break
Quick one. I'll take a break from this for now - my little sister's phone broke down, so she got my Photon. I just ordered one from the States today, but between that arriving and cornholiogsm doing the SIM mod, it might take a while (US to Ireland to Czech Republic to Ireland - and Tomas is pretty busy in my experience).
Thanks much for building this!
Forgive my ignorance, I've been using CM11 a while but other than the initial installation in which I followed wiki instructions, have only ever updated thru the phone. But since there hasn't been an update in a couple months, I'm considering installing this, particularly to solve the google service problems. If it makes the phone faster with better file system and ram stuff, that's a bonus, although concerned that might cause problems in the future. I don't fully understand what you mean by messed up build and odexed user stuff means. Basically I wonder can I just install this on top of the latest CM11 nightly without issues ("dirty flash")? My "recovery" is recovery-clockwork-6.0.4.4-xt926 clock but I only used that cuz that was what the wiki said, I've never used it since the initial install.
If the answer is yes, and I understand your post right, these are the install steps:
1. Download cm-11-20150408-UNOFFICIAL_f2fs-moto_msm8960_jbbl.zip
2. Download & install TWRP-2.8.6.0-20150408-cm11_f2fs-moto_msm8960_jbbl.img
3. Change filesystem of /cache and /data to f2fs using TWRP
4. Install cm-11-20150408-UNOFFICIAL_f2fs-moto_msm8960_jbbl.zip using TWRP
You said something about flash SuperSU alongside this. I don't recall having to do that before, can you provide a little more info?
Do I need to reinstall gapps, and if so, is it the same as I used before, gapps-kk-20140606-signed.zip?
And a couple more easy questions I could probably find by searching... how do I install that twrp....img file, can I do that thru clockwork... and how do I get into clockwork anyway, I remember it was holding some volume key during power or something but last time I tried to guess weird things happened with robots getting operations and such so if you happen to know the right keys/etc that would be convenient... will twrp replace clockwork and have the same keys to get boot to it, if not, what keys?
And last but not least... when CM11 M13 finally comes out, will I be able to upgrade to that from this, or perhaps because of the stuff you've taken from CM12 (f2fs/zram/etc) maybe I can't, or maybe I can if I set the filesystem back to default with TWRP first? How bout if one day I decide to use Lollipop (which I may never do anyway as I understand it's only recommended for phones with more than 1GB memory), will I be able to upgrade to CM12 the same way as regular CM11 user? I'd always used official stuff so this unofficial is making me nervous, but I really want my google stuff working right again and my battery to last all day like it used to...
Wait what wiki told you to use CWM for xt926!? CM's wiki?
enigma9o7 said:
Thanks much for building this!
Forgive my ignorance, I've been using CM11 a while but other than the initial installation in which I followed wiki instructions, have only ever updated thru the phone. But since there hasn't been an update in a couple months, I'm considering installing this, particularly to solve the google service problems. If it makes the phone faster with better file system and ram stuff, that's a bonus, although concerned that might cause problems in the future. I don't fully understand what you mean by messed up build and odexed user stuff means. Basically I wonder can I just install this on top of the latest CM11 nightly without issues ("dirty flash")? My "recovery" is recovery-clockwork-6.0.4.4-xt926 clock but I only used that cuz that was what the wiki said, I've never used it since the initial install.
If the answer is yes, and I understand your post right, these are the install steps:
1. Download cm-11-20150408-UNOFFICIAL_f2fs-moto_msm8960_jbbl.zip
2. Download & install TWRP-2.8.6.0-20150408-cm11_f2fs-moto_msm8960_jbbl.img
3. Change filesystem of /cache and /data to f2fs using TWRP
4. Install cm-11-20150408-UNOFFICIAL_f2fs-moto_msm8960_jbbl.zip using TWRP
You said something about flash SuperSU alongside this. I don't recall having to do that before, can you provide a little more info?
Do I need to reinstall gapps, and if so, is it the same as I used before, gapps-kk-20140606-signed.zip?
And a couple more easy questions I could probably find by searching... how do I install that twrp....img file, can I do that thru clockwork... and how do I get into clockwork anyway, I remember it was holding some volume key during power or something but last time I tried to guess weird things happened with robots getting operations and such so if you happen to know the right keys/etc that would be convenient... will twrp replace clockwork and have the same keys to get boot to it, if not, what keys?
And last but not least... when CM11 M13 finally comes out, will I be able to upgrade to that from this, or perhaps because of the stuff you've taken from CM12 (f2fs/zram/etc) maybe I can't, or maybe I can if I set the filesystem back to default with TWRP first? How bout if one day I decide to use Lollipop (which I may never do anyway as I understand it's only recommended for phones with more than 1GB memory), will I be able to upgrade to CM12 the same way as regular CM11 user? I'd always used official stuff so this unofficial is making me nervous, but I really want my google stuff working right again and my battery to last all day like it used to...
Click to expand...
Click to collapse
I agree with @arrrghhh you should use what your device maintainers recommend you use. I would also recommend you looking at what bootloader you have before trying this as there are KKBL builds in a different thread on I believe the RHD section. Odexed is like what you get from the manufacturer. It has .apk and odex files in it. odex assist the apk files. 6.0.4.4 is outdated, as 6.0.5.1 is the most recent. The install method you just recited is exactly what the OP just said. Per the OP, SU was not built into the 4/8 ROM, so you need to flash it as well. Yes you should be able to flash that Gapps, you just have to update your Gapps after finishing setup via playstore. Lollipop is able to be used on your device, as it currently has official builds. 5.0 had issues, 5.1 just got its official release yesterday. As far as unofficial builds go, I refer you to epinter and krystianp who both took an older device and provided unofficial updates that were very stable, despite the neverending work on a custom kernel. Furthermore, you can go talk to Quarx about unofficial builds, since his builds has been running the Defy for years. So being nervous about an unofficial build is like saying you're nervous about using a generic brand of something vs the more publicized item. Battery life will always be an issue if you have a bad setup (wifi and bt on all the time, max bright screen, hrs of listening to music or streaming, etc.)
@enigma9o7 Personally, I can't wait to do an unofficial cm11 build based on the cm11 m13 code base - with f2fs, and I expect, by then, zram (if it proves useful on cm11 at all - this thing works unreasonably well to begin with ). So I wouldn't worry about m13, as I'm pretty sure to release a parallel build on its side.
Now, I'm a bit impaired re. testing equipment atm but I have a mind to keep building this weekly or so anyway, while I judge the commits to be low-risk, and resume the riskier stuff once I get the new toy. Was away from Dublin this week, hence from my home PC , but that gets fixed tonight...
mionica said:
@enigma9o7 Personally, I can't wait to do an unofficial cm11 build based on the cm11 m13 code base - with f2fs, and I expect, by then, zram (if it proves useful on cm11 at all - this thing works unreasonably well to begin with ). So I wouldn't worry about m13, as I'm pretty sure to release a parallel build on its side.
Now, I'm a bit impaired re. testing equipment atm but I have a mind to keep building this weekly or so anyway, while I judge the commits to be low-risk, and resume the riskier stuff once I get the new toy. Was away from Dublin this week, hence from my home PC , but that gets fixed tonight...
Click to expand...
Click to collapse
One question i did have that i was wondering, when you built the kernel, did you set it up for GSM, CDMA, or both? I know we've talked via pm about things, but i've gotten it to boot up with your kernel, but no signal and baseband unknown
Sent from my ATRIX HD using XDA Free mobile app
palmbeach05 said:
One question i did have that i was wondering, when you built the kernel, did you set it up for GSM, CDMA, or both? I know we've talked via pm about things, but i've gotten it to boot up with your kernel, but no signal and baseband unknown
Click to expand...
Click to collapse
Mmm will have to check. For me it's working in the EU using GSM/HSPA on the xt897 with the SIM mod.
I used the stock config from the cm12.1 xt897 kernel - I'll have to diff that with the cm11 one.
Another possibility is that it wouldn't work because of SElinux mismatches between kernel and userland. The following has to be in the fstab:
Code:
/dev/block/platform/msm_sdcc.1/by-name/modem /firmware ext4 ro,nosuid,nodev,noatime,nodiratime,barrier=1,[b]context=u:object_r:radio_efs_file:s0[/b] wait,check
If it doesn't, on the xt897 you get no WiFi, but I expect results might vary by device
All I'm saying is, it might or might not be a kernel config, would have to check when I get to my PC.
mionica said:
I used the stock config from the cm12.1 xt897 kernel - I'll have to diff that with the cm11 one.
Click to expand...
Click to collapse
I reviewed the entire changelog from cm-11.0 to HEAD, and couldn't find anything that looked even remotely radio-related, so I reckon it's most likely the SElinux thing. And now that I built a TWRP that has a chance of running on AHD, I guess you could tell me whether that's the case
arrrghhh said:
Wait what wiki told you to use CWM for xt926!? CM's wiki?
Click to expand...
Click to collapse
Yep, pretty sure. All started a year ago when I was looking for an android smartphone with a keyboard, this one was rated best, wikipedia itself said CM was required for kitkat, so looked into CM, found their installation wiki http://wiki.cyanogenmod.org/w/Install_CM_for_xt897 which step #2 is install clockworkmod recovery. Right now if I follow the link it leads to recovery-clockwork-6.0.1.3-asanti.img, but I'm pretty sure at the time I originally installed it lead to that version I used, which did work fine for installing CM as I do have it installed. But it's possible something else lead me to that version, I can't really remember for 100% sure, but I definitely started from CMs wiki.
---------- Post added at 10:17 AM ---------- Previous post was at 10:04 AM ----------
palmbeach05 said:
I would also recommend you looking at what bootloader you have before trying this as there are KKBL builds in a different thread on I believe the RHD section
....
The install method you just recited is exactly what the OP just said. Per the OP, SU was not built into the 4/8 ROM, so you need to flash it as well.
...
Yes you should be able to flash that Gapps, you just have to update your Gapps after finishing setup via playstore.
...
So being nervous about an unofficial build is like saying you're nervous about using a generic brand of something vs the more publicized item.
Click to expand...
Click to collapse
Thanks. My understanding is there is no KKBL for Photon Q anyway, but anyways I've always used the msm...jbbl roms.
Okay, will add installing SU to install steps.
Since I already have that version of gapps, my question is do I need to reinstall it then update everything. Shouldn't it already be good? I didn't have to reinstall gapps with the official nightlies, so want to know if I really need to for this.
My concern with unofficial is not that I dont trust it or think it's less stable, just that it may make it more difficult in future to upgrade or get back onto official path as I may not be able to follow the same steps as everyone else.
I'm still unsure if it's okay to dirty flash over CM11 nightly. I do actually use my phone for work so don't want to mess it up... but really want google stuff working again and can't keep waiting forever for official cm11.
enigma9o7 said:
Yep, pretty sure. All started a year ago when I was looking for an android smartphone with a keyboard, this one was rated best, wikipedia itself said CM was required for kitkat, so looked into CM, found their installation wiki http://wiki.cyanogenmod.org/w/Install_CM_for_xt897 which step #2 is install clockworkmod recovery. Right now if I follow the link it leads to recovery-clockwork-6.0.1.3-asanti.img, but I'm pretty sure at the time I originally installed it lead to that version I used, which did work fine for installing CM as I do have it installed. But it's possible something else lead me to that version, I can't really remember for 100% sure, but I definitely started from CMs wiki.
---------- Post added at 10:17 AM ---------- Previous post was at 10:04 AM ----------
Thanks. My understanding is there is no KKBL for Photon Q anyway, but anyways I've always used the msm...jbbl roms.
Okay, will add installing SU to install steps.
Since I already have that version of gapps, my question is do I need to reinstall it then update everything. Shouldn't it already be good? I didn't have to reinstall gapps with the official nightlies, so want to know if I really need to for this.
My concern with unofficial is not that I dont trust it or think it's less stable, just that it may make it more difficult in future to upgrade or get back onto official path as I may not be able to follow the same steps as everyone else.
I'm still unsure if it's okay to dirty flash over CM11 nightly. I do actually use my phone for work so don't want to mess it up... but really want google stuff working again and can't keep waiting forever for official cm11.
Click to expand...
Click to collapse
Yes, you can dirty flash this ontop of an existing CM11 after switching /data and /cache from ext4 to f2fs. Gapps will be fine since they install on the /system partition.
Sent from my ATRIX HD using XDA Free mobile app
Switched to Carbon, but preserved most of the goodies from CM; links in the first post.
Also added a note on how to hack your radio to disable CDMA/LTE - so you could go with this phone in the US and never register on Sprint's network (unless they have a GSM/WCDMA network in place too, which should be fine).
I decided to give it a try with your latest CM11. I installed the TWRP from your first post, was able to backup fine, but don't see how to reformat as f2fs....
enigma9o7 said:
I decided to give it a try with your latest CM11. I installed the TWRP from your first post, was able to backup fine, but don't see how to reformat as f2fs....
Click to expand...
Click to collapse
There should be an option to wipe things, go there
Sent from my ATRIX HD using XDA Free mobile app
palmbeach05 said:
There should be an option to wipe things, go there
Click to expand...
Click to collapse
Thanks, found it.
And now I'm stuck. But I bet it's an easy solution.
I changed filesystems, restored data & cache, installed cm (04/27), installed superuser (wasnt sure if needed, but figured it couldnt hurt), and I booted.
No wifi or phone service but I'm hoping the last step will fix that, restoring sdcard0. However, I can't figure out how to copy that back. I used ES File Explorer to copy it to a folder in sdcard1 before I started. But now I can't paste it back to /storage, always told copy fails. There is a 0 byte file called sdcard0 there, if I delete it, it comes back. Since it's not a directory I can't change to it and copy the contents of my previous save into it... I tried deleting it and making a folder called sdcard0 before it recreated the 0 byte file but that failed too.
I thought maybe I'd try command line, but I'm no expert there... I su'd and tried similar things as in EX but similar results.
I thought I'd try to copy it back with TWRPs file manager, but I couldn't figure out where to put it, there was no /storage directory, so I tried putting it in / and that started copying for a while but before it was done it rebooted and just hung at the TeamWin screen until I powered off...
So yeah. Dunno how to restore sdcard0. Help please....
edit: maybe superuser doesn't work? I tried to use default "file manager" and it wont let me switch to root mode. Then I noticed that while trying ES File Manager again I didnt see the popup about "root granted" or something like that that I normally see. But superuser is installed, its in the apps menu and runs and a quick look thru the settings seems okay to me, but I don't recall ever setting anything before.
edit2: I'm giving up and going to try to go back to last cm11 nightly and hope my phone starts working again. I tried reflashing multiple times, eventually tried supersu instead of superuser and that worked to get root explorer working, but I still couldn't copy over sdcard0 using ES anyway, but using default filemanager I could start (although I hate that filemanager cuz I dont know how to change directories, usually have to tap about 15 times before it opens a folder), but it would always start then reboot before it finished. So I still dunno how to copy that back.
enigma9o7 said:
No wifi or phone service but I'm hoping the last step will fix that, restoring sdcard0. However, I can't figure out how to copy that back. I used ES File Explorer to copy it to a folder in sdcard1 before I started. But now I can't paste it back to /storage, always told copy fails. There is a 0 byte file called sdcard0 there, if I delete it, it comes back. Since it's not a directory I can't change to it and copy the contents of my previous save into it... I tried deleting it and making a folder called sdcard0 before it recreated the 0 byte file but that failed too.
Click to expand...
Click to collapse
Superuser is probably not a smart choice on KK. Use SuperSU instead.
The very first boot is somehow handled differently - I discovered this when I worked on integrating SuperSU into a catch-all zip of mine (alongside Windows Mobile ringtones, Midnight Commander, patched hosts, and a few other goodies). I got no radio with my package, but if I flased SuperSU instead, it worked.
It took me a coupe of tries to find the culprit - a flag file in /etc that SuperSU created after the first boot (and I attempted to create that from my zip). Made my zip not create that, and bang! everything worked just fine. Btw, removing that file after the first boot had no effect, the phone'd be screwed until you wiped /data.
Now, the fact that SuperSU handles the first boot differently kinda makes me think that older su's might very well not work (properly) on KK - and what you're reporting seems to confirm that.
I would strongly suggest going Carbon instead; that includes a working su. It's essentially CM with a different boot logo and a good few extra customization options (which you can safely ignore if you're not into that sort of thing).
So if you didn't go back yet, try either
flashing carbon and being done with it, everything will work;
flash the cm rom alongside supersu, not any other root app,
Either way, root will work, phone will work, and you'll be able to copy stuff around to your heart's desire.
As for a FM, I strongly suggest an app called Total Commander. The UI is atrocious as of late (the author is obviously better at coding than designing icons ), but it' probably the most complete FM solution for Android, bar none. And it's free, without adds; wait til you try it in landscape
I'm sorry for you inconvenience, but I also somehow feel it's earned - the OP said SuperSU back before Carbon replaced CM; because that's what I was using, and it worked for me - no guarantees if you went your own way. I've re-added the limitation and made it bold+orange in the CM part of the post (Carbon has its own, fully working, su).
Added the 2015.05.03 build of Carbon; links to 2015.04.30 removed.
At this stage, CM users should have everything they liked about CM, already compiled in (except for WhisperPush, the point of which I don't quite see).
Changelog from 2015.04.30:
added Calendar (!!!) - why on earth would the Carbon guys build an ROM without this?!
built on gcc-4.8.x-sabermod-20150429
added CMWallpapers, Video Editor
added the previously-missed vim, unrar, zip and gdbserver
synced with upstream; in particular, there was a noteworthy GPU memory allocation improvement in the kernel
Todo:
add an app for messing with the NV settings (enable/disable bands, enable/disable US GSM lockdown)
enable zram.
Added the 2015.05.05 build of Carbon; links to 2015.05.03/04 removed.
Changelog from 2015.05.04:
set default governor to msm-dcvs - better out-of-box performance
imported the cm-12.1 init support (including swap enabling)
Changelog from 2015.05.03:
support for fstab alternatives, cm12-style (my own code in fs_mgr); now you can use the ROM with either f2fs or ext4 for /cache and /data
massively improved FS performance for both ext4 and f2fs - tuned the fstab settings for best performance;
added radio-tool to enable/disable US GSM lock and groups of radio bands (CDMAs, US GSM/HSPA, EU GSM/HSPA, Sprint LTE, Verizon LTE) - see spoiler in first post
Todo:
figure out why swapping doesn't want to start, despite the device being there and mkswap succeeding (error -16).
Updating the recovery to a 20150505 build is highly recommended.

UNOFFICIAL CM12.1 for Nook HD/HD+ [2015-12-18]

This thread is a direct continuation of @Hashcode's work for porting to Lollipop. Because of his and @verygreen's heavy lifting, porting to CM12.1 happened almost painlessly, for which I'm grateful. Their contributions compelled me to share something back. Thus, I'm uploading personal builds of CM12.1 for HD and HD+ in this shared Box folder. While I do not own a hummingbird, sister builds are generated more or less concomitantly.
Some of the important device-specific changes from KitKat/CM11 are described in Hashcode's thread. The goal is to keep as close as possible to CM upstream, and integrate whatever fixes and enhancements we find over time. More progress information will be added here gradually, as I have time. A lot of useful discussion happened on the CM12.0 thread, and the status of things is available to anyone willing to search. Hunting for possible bug fixes, understanding how to actually boot a newer kernel are some of my current priorities. I am not a developer, and the usual disclaimers apply.
Recovery Information
Up to date eMMC TWRP images are included in the respective device folders. Personally, I've had a good experience with TWRP, and do not plan on looking at other recovery distributions. Now, there have been (very) sporadic reports of broken partition tables, soft-bricked devices, etc, blamed on recovery. Although recovery is usually not the actual culprit, here are some ways you can rescue a completely unresponsive device:
It's a good idea to keep a microSD card around, with verygreen's external recovery image from here.
Once booted off the external recovery, you can easily fix whatever is broken (ADB is your friend here). There's no need to re-install CM11, as re-flashing recovery and/or boot will most likely fix your issue.
Recovery partition: dd if=<path to recovery image> of=/dev/block/platform/omap/omap_hsmmc.1/by-name/recovery
Boot partition: dd if=<path to boot/kernel image> of=/dev/block/platform/omap/omap_hsmmc.1/by-name/boot
Afterwards, you should at the very least have a working internal recovery. I don't recall any instance where /system and/or /data became corrupted because of recovery, but you can certainly fix them now.
I've never tested this part, but I believe that you may be able to install an eMMC CM12 ZIP with verygreen's external CWM, even if /data and /cache are F2FS (assuming you copied all ZIPs onto the external card). My understanding is that only /dev/block/platform/omap/omap_hsmmc.1/by-name/system (always ext4, mountable by any recovery) is touched during installation, so you may even bypass TWRP completely.
P.S. If you broke you bootloader by flashing the wrong recovery flavor, despite all images being clearly labeled as hummingbird or ovation, well, no sympathy for you… Still, you can bring your device back to life within minutes as described above.
Progress towards Official CM12 Nightlies
As of now, most things are ready for turning official nightlies on, including official TWRP images and SELinux Enforcing support, albeit with this proviso:
My HW composer changes described in post #3 and #602 are not included upstream, since the plan was to fix upstream for all devices using CyanogenMod/android_hardware_ti_omap4.
The stumbling block with SELinux Enforcing had been remounting /system upon each new install, to write the customized WLAN NVS BIN. I'm avoiding this step by modifying the scripts to store the Wi-Fi calibration data in /rom now, with the added benefit that it only needs to be generated once. These changes are also not captured upstream, and may never be. If someone figures out an upstream-approved way of writing to /system upon first boot under Enforcing, then we'll probably switch back to the old fix-mac script.
On a personal note, posting on my threads is pretty tricky business... My builds were never intended for general consumption, but rather a way to move porting and development forward, and I often debate only keeping the GitHub repositories for people to build themselves. Obviously, that would upset hundreds of people at this point, so I make an effort to upload reasonably bug-free builds, as well as help even with trivial non-problems whenever I can. Nevertheless, low quality, or badly written posts (and I don't mean bad English) are a sure way to get ignored, and my memory is pretty long term Basically, I won't police content here, but I also don't want to deal with the the kind of stupidity and entitlement so prevalent in real life.
In conclusion, no need to thank (unless you really want to), or ask about donating, etc, but do reassess the limits of your current understanding before making bold claims, as I do too. Nothing worse than having to fix a trail of misinformation... Also, comparisons to other people's work (unless constructive), complains about the state of things, or simply starting with "no offense" and such, will make your problem much less likely to be solved by me.
XDA:DevDB Information
UNOFFICIAL CM12.1, ROM for the Barnes & Noble Nook HD, HD
Contributors
amaces, Hashcode, verygreen, Jon Lee
Source Code: http://github.com/airend
ROM OS Version: 5.1.x Lollipop
ROM Kernel: Linux 3.0.x
Version Information
Status: Testing
Created 2015-04-16
Last Updated 2015-09-14
All Things Kernel
The information below (branch names, kernel progress, etc) is slowly becoming out of date (post #2 in the Marshmallow thread has more details). Although it feels pretty archaic at this point, I'm leaving this information here, mostly for historical reasons.
My primary focus has been and continues to be an even better kernel. Instead of opening a separate thread, I will be using this space for kernel updates and related information, in a sort of log format.
Since making any of the fancier OMAP-specific kernel trees work properly is a huge headache with limited benefits, I just merged the linux-3.0.101 patches, mainly for testing (the d-3.0 branch). These patches may help with the ARM core, not so much with OMAP parts, and certainly no change to any of the Nook-specific systems. Subjectively, the normal kernel still feels marginally more stable, but hey, everything still works.
It's mid May, and for the past couple of weeks, branch g-3.0 has slowly become my default kernel. It contains additional merges from the Google 3.0 OMAP kernel, the .101 commits, plus cherry-picked changes from various sources. Hopefully, all these make for a better kernel, although the holy grail remains K3.4…
I've been experimenting with improvements upon KSM; UKSM and PKSM are supposed to better recover duplicated/lost RAM (the former in the default g-3.0 branch, the latter in p-3.0). As with KSM, they need to be enabled (and optimally tuned) through the sysfs interface (echo 1 > /sys/kernel/mm/[up]ksm/run).
A significant number of patches were added for LZ4 support, and to make zram/zcache actually use it. I think it makes things snappier, but we'll have to wait and see. Also, it turns out that good old KSM is better after all; PKSM creates instability, and UKSM is a lot more CPU hungry, very much undesired on an already underpowered device.
Another exciting week for K3.0… @Hashcode uploaded a bunch of LMK/low RAM/etc optimizations for some AMZ/OMAP44xx variants, which I'm stealing for the HDs. As I'm better understanding the use of MFLAG/QOS for frame prioritization, I ported some of these changes from K3.4. The most exciting however, is the DMA-buffered K3.0 that I have working (branch dma-buf). It definitely feels better, although figuring out how to completely switch away from memory carveouts, fix the communication with OMX/Ducati for HW accelerated video, is complicated. This branch will remain an experimental project till K3.4 is up and running.
Just for testing, I'm rebasing most of my changes on top of the official CM12.1 kernel, and made the new iosched branch default for a while. This branch contains many changes to the block layer, cherry-picked from @faux123's tuna kernel. We now have newer I/O schedulers, such as FIOPS, ROW, and eventually BFQ. The current default elevator is ROW with 256 KB readahead. A few other interesting patches popped up, mainly related to unaligned access on ARM, and related optimizations.
Since July, all changes are grouped into feature branches on top of the upstream kernel, which are finally merged into the cm-12 branch, the default for the foreseeable future. This way of doing things is easier to maintain, and makes these changes easier to read, when deciding what to keep/discard for upstream.
HW Composer Issues & Fixes
The goal, and probably one of the base requirements to have these devices included in the CM12 nightlies, is to have a stable ROM with normal HW accelerated overlays. As of now, we achieved this by mostly reverting to the HW composer in CM11, although understanding why the newer code in hardware/ti/omap4 creates these underflows is equally important. Post #602 contains more information about this issue.
Starting with the July 14th builds, disabling HW overlays shouldn't be necessary any longer.
Before mid-July, we were using the upstream HWC in CyanogenMod/android_hardware_ti_omap4. As discussed ad nauseam, that combination of upstream K3.0/PVR modules/SGX DDK binaries/HWC runs into serious GFX buffer underflows. With five or more composer overlays, the panel attempts to reset constantly, which causes display flickers, followed by reboot (dumpsys SurfaceFlinger|grep -A 10 type will show how consistent this bug is).
In the meantime, a poor workaround was to disable HW overlays in Developer options. To make it stick across reboots, you could use this /data/local/userinit.sh:
Code:
#!/system/bin/sh
(while :
do
sf=$(service list | grep -c "SurfaceFlinger")
if [ $sf -eq 1 ]
then
service call SurfaceFlinger 1008 i32 1
break
else
sleep 2
fi
done
) &
First!!! Great to see you start your own thread. Thanks for all the great work
ac-t660 said:
If I have the 3/24 ROM already installed, should I dirty-flash the 4/8 version or do I need to reset and fresh install it in order to properly get the changes?
And like everybody else has said - thanks amaces and hashcode, incredible job!
Click to expand...
Click to collapse
Doh! I must have been typing my question as you were creating this new thread. Moving it since you and everyone using your builds are moving over here. Thanks again!
Based on this, I'd say that should be possible soon, if not already. However, that wasn't the case with the initial builds. I'd say no harm wiping just /system, and maybe /cache, flashing a CM12.1 ZIP, plus the proper GApps, and see how it goes.
Thanks!
I've flashed your 8 Apr build, and it (mostly) looks good. I still get the occasional forced reboots after some flickering. The flickering tends to occur when changing from portrait to landscape and pulling down the settings bar.
I very much look forward to see some progression.
Can you provide some instructions with installing TWRP on the HD+? I have Cyanoboot installed and flashed your build using CWM recovery.
Thanks.
In response to this post in the 12.0 thread.
amaces said:
The changelog would basically be the CM12.1 one
Click to expand...
Click to collapse
Great, so can you point to the latest CM12.1 commit that you've included when you make a release? Knowing the date doesn't pin it down completely.
amaces said:
About the ovation kernels, those images were for CM12.0, and while they may work with current builds (for reasons stated above), they don't provide any benefit anymore.
Click to expand...
Click to collapse
So we should use our original boot/kernel images?
Thanks!!
Hey amaces,
Thanks so much for the 12.1 builds. On the 4/4 build and will be testing out the 4/8 build over the weekend.
Thanks!!
shdware said:
Can you provide some instructions with installing TWRP on the HD+? I have Cyanoboot installed and flashed your build using CWM recovery.
Click to expand...
Click to collapse
Flashify can do that for you inside the ROM, or you could dd if=recovery.img of=/dev/block/platform/omap/omap_hsmmc.1/by-name/recovery inside adb shell or terminal. Also, current TWRP allows flashing of boot/recovery images directly.
MossyTC said:
Great, so can you point to the latest CM12.1 commit that you've included when you make a release? Knowing the date doesn't pin it down completely.
Click to expand...
Click to collapse
Sure, can do, although that kind of tagging needs to be thought out. I could simply append the CM review change number, but that's not very useful since most changes are in repositories that don't affect our devices. I'll look if anyone found a good way to do it (frankly, I don't recall seeing it done).
MossyTC said:
So we should use our original boot/kernel images?
Click to expand...
Click to collapse
The ROMs come with their own kernel. Those independent kernels were simply testing a few patches for the buffer underflow/flickering issues, and were meant for easy swapping within compatible CM12.0 builds.
Hi amaces,
I had done the 5.0 build, what do I need to do in order to pull in the 5.1?
TIA
andtron said:
Hi amaces,
I had done the 5.0 build, what do I need to do in order to pull in the 5.1?
TIA
Click to expand...
Click to collapse
I think it's better to backup your apps (I use titanium), do a full wipe and then install the 5.1 rom and gapps.
I am running the 04/08 and it is working fine except one major problem that is the bane of Android everywhere since kitkat...
It keeps telling me I have insufficient storage space to do anything, update apps or install new apps, and there are hardly any apps on the device.
When I go to Settings -> Storage it says total space 12.67GB but "Available" is only 700MB, which doesn't add up and doesn't agree with the graph.
I have:
Apps 0.92GB
Pictures, videos 5.62MB
Audio 296KB
Downloads 1.20GB
Cached data 1.24MB
Misc 1.65GB
Adding that up is just under 3.8GB total so I should have about 8.9GB free, but it only reports 700MB.
Something is wrong with the free space calculation. Any help here? This wasn't a problem on the previous CM12.
BTW I did a clean install (full system wipe) before installing the CM12.1.
Any help is appreciated. I am at my wit's end on this issue.
Thanks Tschumi.
My question is more on how to pull the sources and build the 5.1 myself.
mr72 said:
I am running the 04/08 and it is working fine except one major problem that is the bane of Android everywhere since kitkat...
It keeps telling me I have insufficient storage space to do anything, update apps or install new apps, and there are hardly any apps on the device.
When I go to Settings -> Storage it says total space 12.67GB but "Available" is only 700MB, which doesn't add up and doesn't agree with the graph.
[…] Adding that up is just under 3.8GB total so I should have about 8.9GB free, but it only reports 700MB.
Something is wrong with the free space calculation. Any help here? This wasn't a problem on the previous CM12.
BTW I did a clean install (full system wipe) before installing the CM12.1.
Any help is appreciated. I am at my wit's end on this issue.
Click to expand...
Click to collapse
That must be… frustrating. So, you're saying this happened on CM11, then CM12.0 was fine, and now the bug is back on CM12.1? There are a couple of unusual/puzzling issues that people report, including the reboot-instead-of-poweroff bug. Never having experienced these, it's hard to figure out the cause, but I'll keep it in mind.
andtron said:
My question is more on how to pull the sources and build the 5.1 myself.
Click to expand...
Click to collapse
These days, it's very easy; you simply upgrade your LP5.0/CM12.0 sources with: repo init -u git://github.com/CyanogenMod/android.git -b cm-12.1
mr72 said:
I am running the 04/08 and it is working fine except one major problem that is the bane of Android everywhere since kitkat...
It keeps telling me I have insufficient storage space to do anything, update apps or install new apps, and there are hardly any apps on the device.
BTW I did a clean install (full system wipe) before installing the CM12.1.
Any help is appreciated. I am at my wit's end on this issue.
Click to expand...
Click to collapse
I think it has something to do with updating from stock to cm. Go to 'terminal emulator' app, type 'su' then 'df'. Let us know what is the output.
Also, backup all your data. Do you mind clean install again? Which recovery are you using? If you convert your data partition to F2FS I'm sure it'll fix it. Not because F2FS will fix it, but because converting it to F2FS will format the entire /data partition (including the virtual /sdcard). There might be old files downloaded when you used stock rom.
extrem0 said:
...If you convert your data partition to F2FS...
Click to expand...
Click to collapse
Quick question, how does one go about converting the partition to f2fs on the ovation? I've done a couple searches but can't find anything definitive such as which recovery I should have installed and if it is a zip that I would need to flash.
Thanks!
J-Pod said:
Quick question, how does one go about converting the partition to f2fs on the ovation? I've done a couple searches but can't find anything definitive such as which recovery I should have installed and if it is a zip that I would need to flash.
Thanks!
Click to expand...
Click to collapse
I did it using twrp recovery 2.8.6.0 built by amaces. There's an option that allows you to convert some partitions to f2fs. Remember, it will erase all your files in your nook. Do a backup of your files before converting to f2fs.
J-Pod said:
Quick question, how does one go about converting the partition to f2fs on the ovation? I've done a couple searches but can't find anything definitive such as which recovery I should have installed and if it is a zip that I would need to flash.
Thanks!
Click to expand...
Click to collapse
Using @amaces TWRP, go to Wipe, check the data box, select "advanced wipe then it's something like " repair file system". I'm sure you can figure it from that.

[ROM][7.1.2][CR_DROID][UNOFFICIAL][OPTUS_X_SPIRIT_5044T][mt6737m_35m]

SEE 4TH POST FOR ROM LINK
DISCLAIMER
As per always im not responsible for any problems that may or may not arrise from this UNOFFICIAL build, i am in no way responsible for any flash issues using SP flash tool, What you do here you do of your own accorrd i never forced you to flash anything, now the legal part is out of the way.
______________Device_specification____________
Model : 5044T
Chip type : eMMC
Fs type : Ext4
Mtk chip type : MTK6737M
Mtk chip type : MTK6735M
Kernel version : 3.18.19+
........Welcome to CR Droid 3.8.7 UNOFFICIAL.......
** NOTE **
This firmware is for Alcatel U5/Optus x Spirit 5044T models ONLY,
NOT WORKING
• Front Camera DOES NOT work
____________________________________________
PRE REQUISITE'S
• OEM unlocked in developer options
• Flash TWRP with SP flash tool.
• Format data in wipe menu before flashing rom & Gapps
• Install Rom first then install Gapps straight after
• Wipe cache/Dalvik & reboot
___________________________________________
LINKS
TWRP 3.2.3-0
https://drive.google.com/file/d/1YMfYp4z1tgdjvlK6KRlMsGLmkW_oikZz/view?usp=drivesdk
GAPPS
https://opengapps.org
SP FLASH TOOL
https://spflashtool.com
MEDIATEK VCOM FLASH DRIVER
https://spflashtool.com/download/MediaTek_USB_VCOM_drivers.zip
Pics of build
Links been pulled temporarily due to a modem issue.
Currently rectifying the situation now link will be back up asap.
See links on first post for GAPPS, TWRP, & SP flash tool.
CR droid 3.8.7 2019-02-24
https://drive.google.com/file/d/1S78TeH-8rHXAhqmSZS_h1PyoEGhSxUE0/view?usp=drivesdk
DISCLAIMER
As per always im not responsible for any problems that may or may not arrise from this UNOFFICIAL build, i am in no way responsible for any flash issues using SP flash tool, What you do here you do of your own accorrd i never forced you to flash anything, now the legal part is out of the way.
CHANGELOG
• RIL error is now resolved
• Minor changes to UI,
• Removed substratum until i can fix
• changed to TCL fingerprint for the play store,
• Added low ram optimiastion
• Added Volte to /etc /bin /lib & boot.img
• Added Vilte to /etc /bin /lib & boot.img
• Added hd voice calling
• Added Dual mic support
• Added NFC compatabilty
• Changed some cam libs to clean the picture up, touch to focus works camera quality is on par with stock if not better.
• Ril optimisations, call quality is now same as stock
NOT WORKING
• Vilte, driver compatabilty issue trying to fix may work partially
• NFC, im working on it for now everything but the running app has been placed.
• FRONT CAMERA DOES NOT WORK
dont ask me to fix it, i will decompile the kernel when i get free time to do so to try and fix,
ive already chowned & chmod'ed init.rc & init.mt6735 with drivers from stock, switched to running through mediaserver instead of cameraserver in service_contexts as it does on stock, created an init.camera.rc to enforce the stock camera permissions, switched each lib out individually leaving only those that dont break the camera, switched camera.mt6735m out in HW aswell as the mtk_camera_clientand it still dosent work i will continue to work on this problem until resolved
Nice job with the ROM, mate. I presume you're Australian, right? Had to mention it based on the Optus reference so yeah.
And care to expound on decompiling the kernel? I presume you can deduce what's going on with it so you could build an equivalent kernel using extant sources, yes?
blakegriplingph said:
Nice job with the ROM, mate. I presume you're Australian, right? Had to mention it based on the Optus reference so yeah.
And care to expound on decompiling the kernel? I presume you can deduce what's going on with it so you could build an equivalent kernel using extant sources, yes?
Click to expand...
Click to collapse
Hey mate sorry for late reply, been finishing a ubifs cyanogenmod 11 build ive jjust released,
Cheers for the feedback yeah this one is for alcatel 5044T using kernel 3.18.19+ great rom though just havent gotten round to decompiling kernel to fix the front camera managed to interpolate the back though to be better than stock
I use a .sh file called kernel-decompile.sh usually but havent decompiled a kernel in a while i try to use stock untouched as it saves the headache of getting kernel readable to make changes,
Did you make any progress on your build yet ? Managed to take a breif look at your device tree i noticed in one of the files it was screeming at the init.environ.rc is this present in your boot.img as its stating that the paths are missing for it if you have the init.environ.rc present you just need to add the paths listed into there corresponding path being either BOOTCLASSPATH or SYSTEMCLASSPATH
I noticed you init.rc is not right at all there is no information within to run any of the /bin resources required to execute gui, post fs-data section is also missing aswell as setting up the global evironment was also wrong i beleive as there was no info for chowning or chmodding below the mkdir asserts,
Ive still not looked at alot but everything else that i have managed to look at seems to be pretty good
I should be hopefully getting my Lineage 14.1 build up for the alcatel pixi 3 using stock 3.4.67 kernel soon so you may be able to see how i made the boot.img and compare it yours if you want or i have my LineageOS 13.0 build already up for the Pixi 3 already which uses the same setup pretty much because afaik the way the fs setup is set it out in the fstab and init.rc is all the same from 5.0+ onwards as it uses encrypted footers and what not, i had to vold manage the 900Mb /custpack partition to be used as user accessible data for file transfers and general storage of photos videos etc as it would not mount any other way and would cause me infinite boot loop i had to also set the 3.6GB /internal storage as a voldmanaged user inaccessible partition reserved for system storage as the /system partition is only 512mb so ive been struggling for space to make everything work but its nearly done
Matty1993 said:
Hey mate sorry for late reply, been finishing a ubifs cyanogenmod 11 build ive jjust released,
Cheers for the feedback yeah this one is for alcatel 5044T using kernel 3.18.19+ great rom though just havent gotten round to decompiling kernel to fix the front camera managed to interpolate the back though to be better than stock
I use a .sh file called kernel-decompile.sh usually but havent decompiled a kernel in a while i try to use stock untouched as it saves the headache of getting kernel readable to make changes,
Did you make any progress on your build yet ? Managed to take a breif look at your device tree i noticed in one of the files it was screeming at the init.environ.rc is this present in your boot.img as its stating that the paths are missing for it if you have the init.environ.rc present you just need to add the paths listed into there corresponding path being either BOOTCLASSPATH or SYSTEMCLASSPATH
I noticed you init.rc is not right at all there is no information within to run any of the /bin resources required to execute gui, post fs-data section is also missing aswell as setting up the global evironment was also wrong i beleive as there was no info for chowning or chmodding below the mkdir asserts,
Ive still not looked at alot but everything else that i have managed to look at seems to be pretty good
I should be hopefully getting my Lineage 14.1 build up for the alcatel pixi 3 using stock 3.4.67 kernel soon so you may be able to see how i made the boot.img and compare it yours if you want or i have my LineageOS 13.0 build already up for the Pixi 3 already which uses the same setup pretty much because afaik the way the fs setup is set it out in the fstab and init.rc is all the same from 5.0+ onwards as it uses encrypted footers and what not, i had to vold manage the 900Mb /custpack partition to be used as user accessible data for file transfers and general storage of photos videos etc as it would not mount any other way and would cause me infinite boot loop i had to also set the 3.6GB /internal storage as a voldmanaged user inaccessible partition reserved for system storage as the /system partition is only 512mb so ive been struggling for space to make everything work but its nearly done
Click to expand...
Click to collapse
You're welcome, glad you had things sorted out on your end. I do have an init.environ.rc on my /out folder but I am not sure if it's right at all lol:
Code:
# set up the global environment
on init
export PATH /sbin:/vendor/bin:/system/sbin:/system/bin:/system/xbin
export ANDROID_BOOTLOGO 1
export ANDROID_ROOT /system
export ANDROID_ASSETS /system/app
export ANDROID_DATA /data
export ANDROID_STORAGE /storage
export ASEC_MOUNTPOINT /mnt/asec
export LOOP_MOUNTPOINT /mnt/obb
export BOOTCLASSPATH /system/framework/core-libart.jar:/system/framework/conscrypt.jar:/system/framework/okhttp.jar:/system/framework/core-junit.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/telephony-common.jar:/system/framework/voip-common.jar:/system/framework/ims-common.jar:/system/framework/mms-common.jar:/system/framework/android.policy.jar:/system/framework/apache-xml.jar
export SYSTEMSERVERCLASSPATH /system/framework/org.cyanogenmod.platform.jar:/system/framework/org.cyanogenmod.hardware.jar:/system/framework/services.jar:/system/framework/ethernet-service.jar:/system/framework/wifi-service.jar
export LD_PRELOAD libsigchain.so:libxlog.so
On the stock ramdisk it looks like this:
Code:
# set up the global environment
on init
export PATH /sbin:/vendor/bin:/system/sbin:/system/bin:/system/xbin
export LD_LIBRARY_PATH /vendor/lib:/system/lib
export ANDROID_BOOTLOGO 1
export ANDROID_ROOT /system
export ANDROID_ASSETS /system/app
export ANDROID_DATA /data
export ANDROID_STORAGE /storage
export ASEC_MOUNTPOINT /mnt/asec
export LOOP_MOUNTPOINT /mnt/obb
export BOOTCLASSPATH /system/framework/core.jar:/system/framework/conscrypt.jar:/system/framework/okhttp.jar:/system/framework/core-junit.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/framework2.jar:/system/framework/telephony-common.jar:/system/framework/voip-common.jar:/system/framework/mms-common.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/apache-xml.jar:/system/framework/webviewchromium.jar:/system/framework/mediatek-common.jar:/system/framework/mediatek-framework.jar:/system/framework/CustomProperties.jar:/system/framework/mediatek-telephony-common.jar:/system/framework/mediatek-tablet.jar
And by init.rc do you mean init.mt8127.rc? Could you tell me which parts are wrong please, as I've based this off @Stricted's MT8127 repo. I doubt that the missing "LD_LIBRARY_PATH" is at fault too. Also, I am getting a missing "__umodsi3" symbol error prior to introducing a (rather pointless imo) shim just to sort of make hwcomposer happy, even though I still end up not getting the GUI to show up.
You mind if we continue on discussing this on the LeapFrog development thread though? I don't want to stray off your original topic here anyway.
blakegriplingph said:
You're welcome, glad you had things sorted out on your end. I do have an init.environ.rc on my /out folder but I am not sure if it's right at all lol:
On the stock ramdisk it looks like this:
And by init.rc do you mean init.mt8127.rc? Could you tell me which parts are wrong please, as I've based this off @Stricted's MT8127 repo. I doubt that the missing "LD_LIBRARY_PATH" is at fault too. Also, I am getting a missing "__umodsi3" symbol error prior to introducing a (rather pointless imo) shim just to sort of make hwcomposer happy, even though I still end up not getting the GUI to show up.
You mind if we continue on discussing this on the LeapFrog development thread though? I don't want to stray off your original topic here anyway.
Click to expand...
Click to collapse
Hey mate sorry for late replty been helping a friend out building a twrp for them,
Yeah ill go through your init now on your guthub and ill type out into a notepad++ what i can visually see is wrong with it and any other files also,
LD_LIBRARY_PATH i beleive wont break a system and shouldn't stoo GUI loading up, also with HW composer could you notjust disabling it to run native 2D graphics ?
Anyhow yeah ill jump on the leapfrog forum when i get some time
user154 said:
Hey buddy, hows things going?
I was able to fix the front camera in my rom a few weeks ago,
There is no need to touch the boot image or kernel, I also experimented with changing permissions of camera drivers in the init files to no avail.
To fix we must ignore the advice of every porting guide and replace more than one lib.
In the end I looked at similar mtk kernel sources and was able to trace the error back to libcam.hal3a.v3.so however just changing this lib is not enough, we must also change some of its dependencies. Attached is a list of 12 libs that I changed to solve the problem
EDIT:
It may not be necessary to change all of these libs, you may be able to get away with just changing the hal3a libs and featureio and featureiodrv as these were the last ones I changed, I didnt try taking away any of the other libs I replaced as I found 720p recording was better and general camera quality had improved
Click to expand...
Click to collapse
Hey mate,
Yeah im not to bad sorry for late reply ahh sweet that means i dont have to decompile my kernel now that may have been one of the libs id changed that time id gotten it working and didnt even know id changed it, how did you figure tthat one out, as usually for cam the mains are camalgo, camdrv, gralloc & featureio i couldnt wrap my head round why i couldnt get it working again lol
Yeah 720p i found was the best optimal setting as SS 480p seemed to be a bit grainy and 1080p isnt device supportive so is so slow i havent released an update to CRdroid so may end up getting it done in the next few weeks 5044T users will be happy great work on figuring it out
Matty1993 said:
Hey mate sorry for late replty been helping a friend out building a twrp for them,
Yeah ill go through your init now on your guthub and ill type out into a notepad++ what i can visually see is wrong with it and any other files also,
LD_LIBRARY_PATH i beleive wont break a system and shouldn't stoo GUI loading up, also with HW composer could you notjust disabling it to run native 2D graphics ?
Anyhow yeah ill jump on the leapfrog forum when i get some time
Click to expand...
Click to collapse
I am not sure, something's keeping the loading animations from showing up, maybe I might have missed a few more blobs or whatnot. I'll have to upload an unsigned dump of the Epic for you to peruse some time. You mind if we get you a donor Epic whilst I wait for mac2612 at /r/OpenLF to get his own Epic being he's had Linux development experience before.
user154 said:
So I looked at logcat and saw that the issue was lensdrv looking in the wrong place for the lens. so I looked at some mtk kernel sources to see if I could trace lensdrv back to a specific lib. It appeared to be part of hal3a however changing this lib would make the camera app disappear, so I tried installing a different camera app which failed to install. when I looked at logcat the install failed because native libs were missing so I used a dependency viewer to see what libs were dependencies of hal3a and began changing them one by one, focussing on drv libs and then testing. Looking at logcat after I had changed a few I saw a reference to a problem with featureio so I opened featureio and featureiodrv in a hex viewer and one of them (cant remember which) had a string specifying the lens location, so I added these two and the front camera worked. This is what makes me think you could maybe get away with just changing hal3a and the 2 featureio libs to get the front camera working, however I was happy with how the camera was working so didnt try to take away any of the other depdencies I had changed
Click to expand...
Click to collapse
Dependency viewer? Which one are you using if you don't mind telling?
user154 said:
This is the one I use:
https://forum.xda-developers.com/android/software-hacking/tool-read-elf-gui-android-libs-t3717016
Click to expand...
Click to collapse
Hey bud sorry for the very late reply i feel quite rude i somehow managed to unmark my own thread just scoured my mentions section looking for a comment on it lol,
Had troubles with pc also blowing just got it fixed today so looking forward to getting camera all working well with it managed to make some progress with my rom before it did though
Ive turned my build into a vendor image as im also trying to incorporate all the test tools from the stock rom aswell as the VOLTE modem thats been attached to custpack in stock,
Managed to get most test tools working well but something wrong with the modem not engaging properly it says YES OPTUS but has no signal or service and imei is also blank not invalid but blank & gone lol yet sim still registers optus so i think im gonne be doing some debugging on it to see whats going wrong ive got a feeling i may need to reverse engineer the modem libs hoepfully not other than that ive only got a small bug when it first boots up that states "a vendor image mismatch has been detected, typically this means your vendor image is out of date please ensure your vendor image matches NJH47F"
Got me stumped a bit on it as i cant spot anything obvi wrong but ill persevere as having it as a vendor build seems to use at least 60-100mb less ram, first boot is quicker & there is virtually no lag at all compared to a traditional build and i was able to add all the SLPencryption and Fpsv files and libs without getting a bootloop as im trying to get encryption to work with it, not sure if its working though as i didnt get a chance to test yet.
Ill keep you updated on progress anyhow as i go when i get round to it i gotta help blake first though as i promised him id help him get his CM 12.1 working when i got my computer working again as hes been dying to get it working on his leapfrog epic
Hows things on your end with your rom ? Did you manage to make any progress with getting IMS, VOLTE or VILTE anywhere near working im struggling to say the least with it lol
MTK source code
Hi @Matty1993
Not sure if this will help but I have found the FULL Mediatek source code for the MT6737x.
The Android 8.1 sources can be found HERE along with some other useful things like the Android SDK source (This is the full 6.0 source code). :good:
I have downloaded the 8.1 source and it seems to be complete.
There are also full build instructions although you will need to create your own "Build Project" from what I understand or maybe you can just cherry pick what you need. :fingers-crossed:
Below are the officially maintained repository's on github.
OrangePi 4G-IOT
OrangePi 4G-IOT build on MTK6737 Soc, the officially maintained repository as follows:
kernel:
https://github.com/orangepi-xunlong/OrangePi4G-iot_kernel.git
u-boot:
https://github.com/orangepi-xunlong/OrangePi4G-iot_bootloader.git
build scripts
https://github.com/orangepi-xunlong/OrangePi4G-iot_scripts.git
external binary file
https://github.com/orangepi-xunlong/OrangePi4G-iot_external.git
toolchain
https://github.com/orangepi-xunlong/OrangePi4G-iot_toolchain.git
:fingers-crossed:
user154 said:
Hey, dont feel rude we cant all always reply straight away I've just welcomed my 2nd son into the world so not really been on here very much over the last month or so.
How is turning your build into a vendor image going? I didnt think this device had a seperate vendor partition just a sub folder of the system partition. If youve managed to give this device a vendor partition that would be quite a feat, theoretically it would mean it would be able to boot a GSI although I dont know how much mileage you would get out of this in reality.
I would imagine some of the problems you are having would be due to the system expecting files to be in one place but you have them in another, you should be able to work this out from the logs though if this is the case.
Good luck to the pair of you on the leapfrog epic front, sounds like a very fun project
I havent done much more on my ROM the only thing left to fix is IMS/VOLTE but I cannot test this so without having someone to test it and provide logs there isnt much I can do. I've been looking round for an oreo rom to port from but thanks to TCL deciding to compile the stock rom as 32 bit and not 64 this is proving rather difficult. I have looked at the possibility of porting 64 bit rom to 32 but from what I can tell the chances of ending up with a decent port rom with no major bugs is pretty slim.
At the moment my main project has been making a game for/with my eldest son, he is obsessed with kirby so made a simple platformer using sprites ripped from various kirby games.
Click to expand...
Click to collapse
Havent worked on the build in a while been in hosptial with pneumonia horrible just horrible wouldnt wish it upon anyone, before hand though yeah vendor build was going great so much more can be added and works where it dosent in /system, such as the slp encryption and cloud test suites etc would all give me bootloop when added to /bin /etc and /lib so what i did is made the system think its got an emulated /vendor partiton instead of me going to all the trouble to create a logical /vendor partitiion by editing a few things in the boot.img .rc files and slinking it in the cpiolist so that the dir is set in the rootfs with 0644 permission but still using 0755 permissions in /system/vendor took me a while to figure it out but even makes system boot and run faster and smoother dont know how thats possible though as it even uses 100mb less ram deffo works as /vendor but as the message i stated in the earlier post just wont go TF away no matter what i do lol,
Still fixing front camera trying to compile my own camera lib for the front but havent gotten round to it yet
bigrammy said:
Hi @Matty1993
Not sure if this will help but I have found the FULL Mediatek source code for the MT6737x.
The Android 8.1 sources can be found HERE along with some other useful things like the Android SDK source (This is the full 6.0 source code). :good:
I have downloaded the 8.1 source and it seems to be complete.
There are also full build instructions although you will need to create your own "Build Project" from what I understand or maybe you can just cherry pick what you need. :fingers-crossed:
Below are the officially maintained repository's on github.
OrangePi 4G-IOT
OrangePi 4G-IOT build on MTK6737 Soc, the officially maintained repository as follows:
kernel:
https://github.com/orangepi-xunlong/OrangePi4G-iot_kernel.git
u-boot:
https://github.com/orangepi-xunlong/OrangePi4G-iot_bootloader.git
build scripts
https://github.com/orangepi-xunlong/OrangePi4G-iot_scripts.git
external binary file
https://github.com/orangepi-xunlong/OrangePi4G-iot_external.git
toolchain
https://github.com/orangepi-xunlong/OrangePi4G-iot_toolchain.git
:fingers-crossed:
Click to expand...
Click to collapse
Big rammy my friend how have you been and thank you so much for linking me to some proper oreo source for these SoCs as i was trying to port lineage 15.0 32bit rom i found for Moto G4 MT6373M but just cant get it past the logo no natter what i do, being complete or near complete sources though i should be able to make something works cant thank you enough for the links again
Matty1993 said:
Big rammy my friend how have you been and thank you so much for linking me to some proper oreo source for these SoCs as i was trying to port lineage 15.0 32bit rom i found for Moto G4 MT6373M but just cant get it past the logo no natter what i do, being complete or near complete sources though i should be able to make something works cant thank you enough for the links again
Click to expand...
Click to collapse
Sorry to hear you have been seriously ill with pneumonia
I thought you had gone kind of quite on the forum, I do hope your all sorted now and feeling better. :fingers-crossed:
Yes the source is probably the best I have seen thus far and providing you have the necessary drivers and a little know how I am pretty sure you could bring up a new Project for your own device. :fingers-crossed:
Not sure about your booting issue as it could be just about anything but I am sure you will hunt down the problem. :fingers-crossed:
bigrammy said:
Sorry to hear you have been seriously ill with pneumonia
I thought you had gone kind of quite on the forum, I do hope your all sorted now and feeling better. :fingers-crossed:
Yes the source is probably the best I have seen thus far and providing you have the necessary drivers and a little know how I am pretty sure you could bring up a new Project for your own device. :fingers-crossed:
Not sure about your booting issue as it could be just about anything but I am sure you will hunt down the problem. :fingers-crossed:
Click to expand...
Click to collapse
All good dude yeah lots of nasty stuff in my lungs i got the privledge to know what a tube being stuck down your throat to make you breathe felt like yeah ill be sure to check it out as ive looked at a few but none of them were by far near complete which is probs why i couldnt get oreo to boot,
optus have finally switched to Qualcomm's snapdragon so they can run 8.1.0 on there new updated Optus x spirit 2 so they even have abandoned mtk i on the other hand prefer the overjoyable mess that mediatek is haha yeah thats what i figured about the boot issue to could be an init.xx.rc or se_contexts or even the init possibily everything else is perfect in bootimg, either that or could be one of the binaries in /bin or .jars in /framework could even be in /lib ill just keep picking away while i go through the oreo source until some magic happens :laugh:
Matty1993 said:
All good dude yeah lots of nasty stuff in my lungs i got the privledge to know what a tube being stuck down your throat to make you breathe felt like yeah ill be sure to check it out as ive looked at a few but none of them were by far near complete which is probs why i couldnt get oreo to boot,
optus have finally switched to Qualcomm's snapdragon so they can run 8.1.0 on there new updated Optus x spirit 2 so they even have abandoned mtk i on the other hand prefer the overjoyable mess that mediatek is haha yeah thats what i figured about the boot issue to could be an init.xx.rc or se_contexts or even the init possibily everything else is perfect in bootimg, either that or could be one of the binaries in /bin or .jars in /framework could even be in /lib ill just keep picking away while i go through the oreo source until some magic happens :laugh:
Click to expand...
Click to collapse
Yes most definitely not a good experience I am sure. :crying:
Hope you work out your booting issue :good:
I may need to pick your brains later on regarding the Lenovo TAB2 A10-70F/L I managed to get the KK 3.10.65 kernel source to build without any real errors but I think it maybe arm rather than arm64 IDK the old style MediaTek layout is very confusing and I am not sure how it all works eg which parts come from the actual kernel and what comes from the Mediatek project which config's it use or how to make config changes even etc etc.
I have had a lot on recently so not really had time to fully explore it Github lenovo_kernel_a10-70f
I can't seem find any good guides for working with this old style layout unless you know of any. :fingers-crossed:
bigrammy said:
Yes most definitely not a good experience I am sure. :crying:
Hope you work out your booting issue :good:
I may need to pick your brains later on regarding the Lenovo TAB2 A10-70F/L I managed to get the KK 3.10.65 kernel source to build without any real errors but I think it maybe arm rather than arm64 IDK the old style MediaTek layout is very confusing and I am not sure how it all works eg which parts come from the actual kernel and what comes from the Mediatek project which config's it use or how to make config changes even etc etc.
I have had a lot on recently so not really had time to fully explore it Github lenovo_kernel_a10-70f
I can't seem find any good guides for working with this old style layout unless you know of any. :fingers-crossed:
Click to expand...
Click to collapse
Yeah was horrible, made some minor progress on the boot issue dosent switch straight off now is sitting on logo for about 30 seconds before it switches off so getting there bit by bit haha,
Never worked on a lenovo Tab 2 what MTK specs is it running ?
your correct to also about it being confusing the word id use is uniqe experience to say the least last time i worked on older style mtk sources however i did make some notes as i got stuck a fair amount of times aswell not knowing where to put things but it varies from source to source where things go and configs etc etc so i dont know if the layouts would be the same
Matty1993 said:
Yeah was horrible, made some minor progress on the boot issue dosent switch straight off now is sitting on logo for about 30 seconds before it switches off so getting there bit by bit haha,
Never worked on a lenovo Tab 2 what MTK specs is it running ?
your correct to also about it being confusing the word id use is uniqe experience to say the least last time i worked on older style mtk sources however i did make some notes as i got stuck a fair amount of times aswell not knowing where to put things but it varies from source to source where things go and configs etc etc so i dont know if the layouts would be the same
Click to expand...
Click to collapse
The tablet is based on the mt6752/6732 chip set (Quad Core) although Lenovo's specs say HERE
WiFi: MediaTek® MT8165 64-bit 1.7 GHz Quad Core
4G LTE: MediaTek® MT8732 64-bit 1.7 GHz Quad Core
The kernel will boot on either device WiFi or 4G so clearly not much difference between them and seems to be more of a naming thing and possibly some minor tweaking.
The Lenovo K3 kernel source is called the aio (All in One) so I am thinking it may well build for this Tablet too as all the drivers seem to be present in that source. android_kernel_lenovo_aio_otfp I just need to workout the defconfig and what device specific parts I need from the tablets KK source code.
:fingers-crossed:

Categories

Resources