FORUMS
Remove All Ads from XDA

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

478 posts
Thanks Meter: 2,739
 
Post Reply Email Thread
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:
  1. It's a good idea to keep a microSD card around, with verygreen's external recovery image from here.
  2. 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
  3. 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.
  4. 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
The Following 88 Users Say Thank You to amaces For This Useful Post: [ View ] Gift amaces Ad-Free
 
 
10th April 2015, 06:41 PM |#2  
amaces's Avatar
OP Senior Member
Thanks Meter: 2,739
 
Donate to Me
More
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.
The Following 16 Users Say Thank You to amaces For This Useful Post: [ View ] Gift amaces Ad-Free
10th April 2015, 06:41 PM |#3  
amaces's Avatar
OP Senior Member
Thanks Meter: 2,739
 
Donate to Me
More
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
) &
The Following 9 Users Say Thank You to amaces For This Useful Post: [ View ] Gift amaces Ad-Free
10th April 2015, 06:45 PM |#4  
Member
Thanks Meter: 5
 
More
First!!! Great to see you start your own thread. Thanks for all the great work
The Following User Says Thank You to toplist For This Useful Post: [ View ] Gift toplist Ad-Free
10th April 2015, 07:09 PM |#5  
Junior Member
Thanks Meter: 0
 
More
Quote:
Originally Posted by ac-t660

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!

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!
10th April 2015, 07:22 PM |#6  
amaces's Avatar
OP Senior Member
Thanks Meter: 2,739
 
Donate to Me
More
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.
The Following 2 Users Say Thank You to amaces For This Useful Post: [ View ] Gift amaces Ad-Free
10th April 2015, 08:23 PM |#7  
Senior Member
Flag North Logan, UT
Thanks Meter: 50
 
More
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.
10th April 2015, 08:33 PM |#8  
Member
Thanks Meter: 10
 
More
In response to this post in the 12.0 thread.

Quote:
Originally Posted by amaces

The changelog would basically be the CM12.1 one

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.

Quote:
Originally Posted by amaces

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.

So we should use our original boot/kernel images?
10th April 2015, 08:36 PM |#9  
Junior Member
Thanks Meter: 0
 
More
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!!
10th April 2015, 09:27 PM |#10  
amaces's Avatar
OP Senior Member
Thanks Meter: 2,739
 
Donate to Me
More
Quote:
Originally Posted by shdware

Can you provide some instructions with installing TWRP on the HD+? I have Cyanoboot installed and flashed your build using CWM recovery.

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.
The Following 2 Users Say Thank You to amaces For This Useful Post: [ View ] Gift amaces Ad-Free
10th April 2015, 09:40 PM |#11  
amaces's Avatar
OP Senior Member
Thanks Meter: 2,739
 
Donate to Me
More
Quote:
Originally Posted by MossyTC

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.

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).

Quote:
Originally Posted by MossyTC

So we should use our original boot/kernel images?

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.
Post Reply Subscribe to Thread

Tags
cm12.1, hummingbird, nookhd, nookhd+, ovation

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes