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

[amaces]

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

 

[amaces]

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.

 

[amaces]

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:

#!/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
) &

 

[toplist]

First!!! Great to see you start your own thread. Thanks for all the great work

 

[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!

 

[amaces]

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.

 

[shdware]

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.

 

[MossyTC]

In response to this post in the 12.0 thread.

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.

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?

 

[yeti140]

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!!

 

[amaces]

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.

 

[amaces]

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

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.

 

[andtron]

Hi amaces,

I had done the 5.0 build, what do I need to do in order to pull in the 5.1?

TIA

 

[Tschumi]

Hi amaces,

I had done the 5.0 build, what do I need to do in order to pull in the 5.1?

TIA

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.

 

[mr72]

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.

 

[andtron]

Thanks Tschumi.

My question is more on how to pull the sources and build the 5.1 myself.

 

[amaces]

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.

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.

My question is more on how to pull the sources and build the 5.1 myself.

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

 

[extrem0]

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.

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.

 

[J-Pod]

...If you convert your data partition to F2FS...

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!

 

[extrem0]

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!

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.

 

[Dread This Day]

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!

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.