• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

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

Search This thread

amaces

Senior Member
Feb 2, 2012
478
2,751
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
 
Last edited:

amaces

Senior Member
Feb 2, 2012
478
2,751
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.
 
Last edited:

amaces

Senior Member
Feb 2, 2012
478
2,751
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
) &
 
Last edited:

ac-t660

Member
Feb 1, 2013
5
0
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

Senior Member
Feb 2, 2012
478
2,751
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.
 
  • Like
Reactions: Jann F and dbrickg

shdware

Senior Member
Feb 14, 2015
182
50
North Logan, UT
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

Senior Member
Oct 2, 2013
60
30
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

New member
Oct 15, 2012
0
0
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

Senior Member
Feb 2, 2012
478
2,751
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

Senior Member
Feb 2, 2012
478
2,751
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

Senior Member
Aug 14, 2011
160
23
Hi amaces,

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

TIA
 

mr72

Senior Member
Aug 2, 2010
503
126
Austin, TX
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

Senior Member
Aug 14, 2011
160
23
Thanks Tschumi.

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

amaces

Senior Member
Feb 2, 2012
478
2,751
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 ;)
 
  • Like
Reactions: andtron and ajislav

extrem0

Senior Member
Feb 7, 2012
1,198
468
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.
 
  • Like
Reactions: J-Pod

J-Pod

Senior Member
Jan 15, 2013
168
43
Wisconsin
...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

Senior Member
Feb 7, 2012
1,198
468
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.
 
  • Like
Reactions: J-Pod

Dread This Day

Senior Member
Feb 10, 2011
765
102
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.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 87
    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
    18
    Hey, @Jon Lee, I owe you an update about what I ended up doing, and about what we found about the composer history.
    1. Lacking revision information, I started with manual file-by-file diffs, and realized that pvr-source differs only with respect to build configuration. I incorporated some of what I thought are optimizations in this commit. If you send some sort of email handle, I can attribute the Git changes properly, since they do improve things ;)
    2. The HWC sources were pretty similar to CM11, as we established, so I did a partial revert (hwc & include only) to a state before switching to omap4-next; the other code (bltsville, domx, edid, etc) is pretty much unchanged. So, I changed the build configuration to overload only the composer and needed headers, planning to follow up on your other changes.
    3. In the meantime, Hashcode started looking into this as well; he used the d-jb-mr1-release branch on OMAPZoom. It turns out that the CM12.1 composer sources are newer than in CM11 after all, but in ways that are detrimental to us while using API 1.0… CM11 stopped roughly here, while hardware/ti/omap4 acquired this, which seems to be the major culprit.
    4. Looking at SurfaceFlinger logs (dumpsys SurfaceFlinger|grep -A 10 type), it looks like we avoided underflows by converting the fourth and fifth accelerated overlay to GLES (with four or fewer overlays, HWC does everything). The preparations for API 1.1 moved all five overlays into HWC, which the current PVR/DDK doesn't handle well. It would've been great if it did, since GLES is not optimal here, but thankfully this doesn't kick in very often (in my use, at least).
    5. At any rate, Hashcode will fix this in the common repository, probably by reverting c3117a24cb2c97b467032adb6e204f575414c915, so my local hack will not be needed for long.

    I notice that on the last couple of builds the readahead buffer is back at 128--I seem to remember it being 256 before, and I did have it running (TricksterMod) at 512 with no problems, but didn't really see much difference, subjectively.

    Yeah, a readahead of 256-512 KB is good, but it turns out that setting it globally is a bad idea; zRAM block devices need as little latency as possible. Maybe this newer zRAM driver ignores global readahed better, but I think it'll be sufficient to set it in init.rc only for physical mmcblk[01] devices. Not sure which value yet, probably depends whether we stick with ROW, or switch to FIOPS, or BFQ.

    I did notice that my daughters fitness band did not want to pair in Bluetooth, when it used to, but given the win with stability, I can't complain at all! We can save that little issue for later, when I am able to give note information than "my Bluetooth broke with xyz device".

    There are a couple of un-merged BT commits (see http://review.cyanogenmod.org/#/c/103111/), although for some problematic car-kits. Try the build in experimental, which has these included.

    It basically said to go to Settings --> Apps, hit the menu in the upper right, and change the Preferred Install Location. It worked. But I do not see that option anymore.

    Has it been moved? Or is there another way to change it? Or do you think it even matters?

    Based on http://review.cyanogenmod.org/#/c/102325/, it looks like they hide it now by default (too buggy, I guess). I can try to bring it back with an XML overlay in the next set of builds.

    Device got more stable and less laggy after newest build in fact

    Told ya' :)

    so the problem seems isolated to when i install a new build or upgrade for some reason. […] also will the output log show anything ? if so how do i go about providing you that

    Very odd… If the issue is underflows, they'll show up in the logs. I suggest connecting to an adb shell, replicate the conditions that trigger the issue, then extract logs just after it happens (i.e., adb shell dmesg > dmesg, and adb logcat -d > logcat).

    Also, it's good to see how's your communication in this thread with us users. People use to ask more than developers are available to provide (like when people ask for changelogs or newer builds when devs doesn't have time to do so) and you always answer very politely and accurately. I've seen developers stopping sharing their works because of this. It's really nice to see this here.

    On a softer side, thanks! Although this has started as a self-interested project, I've been on the other side for years, and I know how frustrating it is when people disappear without warning, or worse, have the emotional intelligence of a baboon ;) Obviously, you have to desensitize a lot on XDA, which is hard… There were a couple of occasions when I wanted to snap, but then it'd be a lost cause already, so I'll do subtle snide instead ;)

    I did consider keeping only the GitHub repos, and forcing people to bake their own ROMs (which some already do), but then I remembered how inconvenient it was to find a spare Linux box, and basically dedicate it to this work. My MBA would've certainly been dead by now, had I not had access to a real workstation.

    Initially, the idea was to keep the information barebones, possibly scare off folks who would break their devices… That didn't work so well, but we're now close to a very usable state, which means that I will slowly rephrase the OP, make things easier to follow.
    17
    No More Alphas ;)

    We've reached beta, I think; ovation is ready, hummingbird should be done in less than an hour. These builds are still on the experimental side, but if things work as well as they do on my Nook, no point delaying further. All the good stuff is on GitHub, but I do need to follow up with a long post soon.
    16
    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.
    11
    0714-ovation: flickering is gone, ladies and gents!
    Just checked Google Keyboard and Google Photos, can't get the device to flicker or crash.
    I'ts time to celebrate, all hail master AMaces!

    Well, let's not forget @Jon Lee's explanation that started this latest ball rolling. I tend to assume newer, shinier things are better, and glossed over the composer changes many times… At any rate, together with the scheduler changes before the weekend, plus some of the updated PVR build configuration, I think we have something that resembles a real tablet now. Certainly, my initial goal of Nexus 7 (grouper) level smoothness or better, has been achieved ;)