[Nook Color Android Development] steven676:
A TODO list for encore ...

Okay, so we're now running CM11 on our three-year-old Nook Colors ... now what?

Well, there's still lots of stuff that could be improved -- what follows is a (very rough, semi-prioritized) list of things that we could do to make CyanogenMod on encore even better (please note that this does not represent a promise or a guarantee to get any of this stuff done):

Fix the in-kernel USB/charger port driver. The code we're running right now is an unholy mix of stuff that was upstream in 3.0, stuff forward-ported from the official BN 2.6.32 tree, and possibly some stuff backported from other device kernels as well. It works .. or worked in 3.0.8, at least. I strongly suspect the few reports of crashes/SOD on 3.0.101 are due to bugs in this code, and while it's been a while since I've seen a new report of those problems, we haven't done anything about the reported crashes either, so I assume they haven't gone away (which is why we're going back to 3.0.8 for the CM10.2.1 stable release). (If they've resolved themselves for you, please speak up!)

Anyway, it's long past time we went back into that code and figured out what's wrong. (As a bonus, because the USB/charger transceiver chip also handles voltage regulation and distribution for the entire system, we may be able to get better stability at higher clock speeds out of this. It may turn out that we can reenable USB host mode while we're at it, too.)

Fix video playback on CM11. A lot of videos are currently playing back as jittery messes, and HD videos are much slower than they were in CM10 -- there's no reason why this has to be the case, so we should track down why and fix it.

Repartition the eMMC to a layout which makes more sense for us going forward. As our struggles to get CM11 to fit on eMMC showed, a 440 MB /system isn't really going to be enough going forward. Also, as you may know, encores were produced with two different eMMC layouts: one with 1 GB for /data and 5 GB for /emmc, the other with 5 GB for /data and 1 GB for /emmc. While each layout has its advantages and disadvantages, since Honeycomb, we've had a third possibility -- merging the two to create one 6 GB partition that can be used for both app data and media storage.

Now, if we're going to repartition, we may as well kill both birds with one stone. Hashcode, verygreen and I have been kicking around an idea to expand /system and merge /data and /emmc without requiring a data wipe (you'd need an SD card large enough to temporarily fit the existing contents of the partitions to go through with the process), which I'll write more about in a separate post. Hopefully, this would be optional for CM11 (that is, CM11 would work with both the old and new layouts), but it would likely be required in order to upgrade to the next Android release after CM11.

Improve the installation experience. Prompted by a certain company (whose name I won't mention here) yet again managing to get inordinate press coverage for releasing an exorbitantly-priced SD card image of almost-unmodified CyanogenMod for Nooks, we'd like to make it easier and more painless to put CyanogenMod on your Nook, either on eMMC or on an external SD card. This hasn't gotten out of the "brainstorm" stage, yet, but the idea likely involves creating a single installation package which works unmodified for either eMMC or SD installs, and updated bootloaders and recoveries for eMMC and SD. Once complete, we could provide an SD card image which you could just flash to a card to create an SD card install, and eMMC installs would be as easy as flashing a bootable recovery image to SD card and installing the package from recovery. I'll elaborate in (yet another) separate post.

Explore possibly moving to a newer upstream kernel version. TI has not produced an official Android kernel for the OMAP3 newer than 3.0, but that hasn't stopped the community from pushing OMAP3 code into the kernel.org trees. As I understand it, that work is now getting close to a point where real devices such as the GTA04 and BeagleBoard can use it.

Rebasing our own board support on top of a kernel.org kernel would be a major undertaking, because everything's changed from under us since 3.0: board-specific setup code has been deprecated in favor of device trees -- simple, flat textual descriptions of the hardware on a board and how it's all connected, and all of the rest of the hardware support has been moved into fully generic drivers or architecture-specific code which is configured through the device tree. (See Neil Brown's excellent LWN writeup (part 1, part 2) of the device tree for GTA04 and the challenges involved in creating it for a more detailed description of what I'm talking about here.) The big advantage, though, is that once we've done this work, moving to newer kernels in the future should be much simpler (device trees are supposed to be stable across releases, and drivers are much easier to forward-port than board setup code).

As you might have noticed, this is a long and substantial TODO list. (It's also not closed-ended -- if you see something else that we should be working on, please don't hesitate to suggest it.) There's no way I can complete more than a small part of this on my own in any reasonable amount of time, and while we may be able to combine efforts with other devices' maintainers for some of this, the reality is that this will probably happen faster if you pitch in, too! All of the items on this list can be tackled independently and concurrently -- if you see something that you can help out with, please do! If you need help or guidance, speak up and we'll do our best to assist.