yashsingh1/xdaforums huggingface dataset:
[Nook Color Android Development] bytte:
I have sent you a PM containing a link to the uImage file I created.

I tried various kernels that I had compiled without success. In the end I used tools including repack-zImage.v6.zip to pull apart the original uImage into its component parts, reverse engineer the expanded kernel binary to locate where dto was being conditionally set to 14, binary edited the binary to make that opcode unconditional, and then repackaged uImage. Not something I would want to do for a more complex change.

We (you) really ought to have the source code.
[Nook Color Android Development] leapinlar:
Wow, that was a lot of work. Thank you for providing it. I will use that one to test on a really crappy SD that I have that I could never get to work. If things go well, I will update the image zip to include it.

EDIT: I have two bad cards, both SanDisk Class 4 that turned out to be factory culls that I was ripped off as new. Anyway, one was too far gone and your kernel could not make it work. But the other one seems to be working great. Between your kernel to let it install and steven676's kernel in the new CM10 ROM, it is working great.

So I have made a new rev6 of the SD installer with your revised kernel and attached it to my SD installer thread. Thank you and Steven for working this out.

Sent from my Nook HD+ running CM10 on Hybrid SD
[Nook Color Android Development] moocow1452:
So, trying to roll my own build of Nook Ubuntu Touch, and it needs a mkimage.bk, at least according to this here. http://paste.ubuntu.com/5714772/

Do I go into the original source, fish one of those out and put it into the workspace?
[Nook Color Android Development] steven676:
Wow!

That said, "really ought to" isn't strong enough a statement here -- under GPLv2, the distributor is legally obligated to provide the source code corresponding to the distributed binary to anyone who asks.

If the kernel shipped in the image reports its version as 2.6.32.9, I'd guess it's a CM7 or early CM9 kernel -- you could try building something like https://github.com/dalingrin/nook_kernel and seeing if that works with the installer.
[Nook Color Android Development] leapinlar:
I suspect that verygreen did not build this kernel. He probably just took it from CM7. Or if he did build it, it was built from the CM or dalingrin source. He does have a github for an encore kernel, but it is for a 2.6.35 version.

Sent from my Nook HD+ running CM10 on Hybrid SD
[Nook Color Android Development] bytte:
Strings gives me

Linux version 2.6.32.9 (green@fatbox1.localnet) (gcc version 4.4.0 (GCC) ) #19 PREEMPT Sat May 14 14:46:55 EDT 2011

which unless I'm mistaken is verygreen. The extracted config differs significantly from the my CM7.1 config and contains

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.32.9
# Sat May 14 14:46:50 2011
#
...
CONFIG_CMDLINE="root=/dev/nfs nfsroot=192.168.0.1:/home/user/buildroot ip=192.168.0.2:192.168.0.1:192.168.0.1:255.255.255.0:tgt:eth0:off rw console=ttyS2,115200n8"
# CONFIG_IGNORE_BOOT_ARGS is not set
...

I have not tried building a kernel using the config and CM7.1 source (I don't have source from May 2011).

Have you tried asking verygreen?
[Nook Color Android Development] leapinlar:
If you look at dalingrin's github referenced in Steven's link above, you will see verygreen contributed to dalingrin's kernel on May 13, 2011, one day before he built this kernel. So I am pretty sure that is the source he used to build this kernel.

No I have not asked him, he is pretty much unavailable lately.

EDIT: If you look at this post of 5/14/11, verygreen confirms he used dalingrin's .32 kernel in his image file.

http://xdaforums.com/showthread.php?p=13796273

Sent from my Nook HD+ running CM10 on Hybrid SD
[Nook Color Android Development] cybertimber2007:
(original content removed, this post needed to be in the user thread)

But from the dev side, we support HID devices right? in CM10?

Edit: Found a post from steve about it: http://xdaforums.com/showpost.php?p=39722120&postcount=187

Supposed to be working in CM10.

Support for 10.1 was merged: http://xdaforums.com/showpost.php?p=39748353&postcount=196

Edit edit:

Looking at the logs posted at: http://xdaforums.com/showpost.php?p=39749894&postcount=199

It looks like it connects using HID, it finds the keyboard profile, but then no input.

There was one interesting line (to me) before it paired fully
[Nook Color Android Development] steven676:
Various developments in the past week or so:

Our CM10.1 device tree (previously only available in the NookieDevs repository) was merged into CyanogenMod on Tuesday, so a local manifest is no longer required to build CM10.1 for encore.

If you're building CM10.1 yourself and haven't rebuilt in the past week or so, you probably want to rebuild, as there have been a handful of changes which should significantly improve graphics performance. (We should mostly match CM10 at this point, though there are some corner cases where we're still behind compared to CM10.)

Said patch was finally merged, and should be part of CM10 "nightlies" starting with 4/21. (There may or may not be any further CM10 weekly builds after 4/21 -- we'll be switching to building CM10.1 nightlies soon.)

The only thing that occurs to me is to make sure that the Input device profile is selected in the device configuration (tap on the Settings icon next to the device's entry in the list of paired devices, and you'll get a list of supported profiles and whether or not they're enabled).
[Nook Color Android Development] cybertimber2007:
Yep, the Mac keyboard shows the input profile and it's selected, but no input occurs. I did try connected my Logitech DiNovo keyboard to the nook and that work's fine (infact, I'm typing this message with it now).

I even tried a different Mac keyboard, no dice. Connects to a Nexus S 4G and Galaxy S3 just fine, but I'm not worried about it right now. I'll try CM 10.1 once we get nightlies for that and see if it works.
[Nook Color Android Development] steven676:
Interesting -- that raises the question of what distinguishes the two keyboards. Can you provide dmesg and logcat for attempting to connect to both keyboards?

The change to the autobuilder configuration was just merged, so 4/21 is indeed the final CM10 weekly, and we should have CM10.1 nightly builds starting tonight (dated 4/22 or 4/23). (As a side consequence, encore will now appear in the big lunch menu for CM10.1 source trees, but will no longer appear for CM10. "lunch encore" (and "brunch encore", and similar commands) will continue to work for both branches.)
[Nook Color Android Development] alienbiker99:
I just know from fooling around with my hackintoshes that mac bluetooth keyboards work on bluetooth and rf, and iirc it switches modes once its been connected. I know its not much help but maybe someone can use that as a start.
[Nook Color Android Development] cybertimber2007:
They are attached.

Logitech DiNovo

Mac Wireless Keyboard (A1255) (Known in the screenshot as kgl's keyboard).
[Nook Color Android Development] steven676:
Mystery solved -- it's an Apple keyboard, and Apple doesn't follow the HID input standard (of course), so we need another driver linked into the kernel (hid-apple). Reviewing Deegan87's posted logs again, I see he seems to have a cheap keyboard from some vendor which blindly cloned Apple's behavior (sigh), so that's the same problem.

I wonder which of the other HID drivers we need to link in to cover the most common cases -- I've been hoping to avoid bloating the kernel with drivers that only some people use ... (This is where Android's lack of support for kernel module autoloading really hurts.)
[Nook Color Android Development] cybertimber2007:
You'd think we'd make standards for a reason... to prevent unique/incompatible implementations of said standard! And all I bet it does is let it interpret the eject key and such :-/

Surprised though that it can't fall back to some generic HID driver though and partially work.

Could I do something like this to load hid-apple: http://silkemeyer.net/android-howto-autoload-a-kernel-module
[Nook Color Android Development] steven676:
http://xkcd.com/927/

You could, sure. But in "regular" Linux, I can just build every module under the sun, install it under /lib/modules/`uname -r`, and the kernel and/or udev will automatically load whatever module it needs when it detects the hardware being attached. That allows us to ship a boatload of "niche" drivers without forcing everyone to incur the memory penalty associated with bundling the drivers into the kernel. (Android's udev replacement uevent doesn't support module autoloading, so we can't do this on Android.)
[Nook Color Android Development] cybertimber2007:
I remember that XKCD comic :)

Thanks for the explaination of regular Linux vs Android module loading. I would have never expected that it didn't work the same way.
[Nook Color Android Development] bytte:
I have taken this kernel as a starting point and used the config from the verygreen kernel to produce https://github.com/nbytte/nook_kernel/tree/encore-SDcard-installer which incorporates Steven's recent timeout fix. Substituting this kernel into leapinlar's installer fixes the problem I saw with SanDisk 4GB Class 4 cards.
[Nook Color Android Development] steven676:
The answer to that last question is surprisingly easy -- there's only a handful of HID drivers supporting Bluetooth devices in the first place, and most of them are small (just describing one or two quirks in the device's HID implementation). Therefore, I've enabled all of those drivers (patch), which should enable full support for, among other things, Apple and Apple-clone keyboards and mice, Wacom graphics tablets, and special keys on Microsoft Presenter 8k keyboards.

Two other changes in that commit:

FUSE is now built into the kernel -- I debated building it as a module, but we'll need it if we ever decide to go to the combined data and media partition with emulated /sdcard that Google has been pushing since ICS. More immediately, this should help people playing around with NTFS-3G or exFAT filesystems.

/dev/kmem is re-disabled. If you need it for some reason, please let us know -- the only modern users of this device I'm aware of are rootkits (malware).
[Nook Color Android Development] Deegan87:
Outstanding! Thanks for your continued work on this long-outdated issue. This patch, is it specific to the nook on CM10.1, or could this be applied to other devices or nooks running CM10?
[Nook Color Android Development] steven676:
The idea applies to any Android or Linux installation, but the exact patch will only apply to our 3.0 kernel tree for encore.

As for CM10 for encore, we build the kernels out of the same tree, and I did modify the CM10 config as well. I'll probably release a binary kernel build for CM10 with these changes, since we're not doing nightly/weekly builds for CM10 anymore.
[Nook Color Android Development] Zippy Dufus:
Hello, I'm trying to build CM10.1 without a local manifest, perform the repo init for cm-10.1 and a sync but it seems to pull only the jellybean branch.

I managed to create a cm-10.1-20130511-UNOFFICIAL-encore by creating my own local manifest which pointed redundantly to the device and kernel cm-10.1 branches but this no longer works as I get a fatal error about a duplicate project. (I haven't flashed this yet because my NC is giving me troubles, possibly a dying battery.)

I've tried deleting all the local code as well as deleting ~/.repo/projects/device/bn/encore.git but it still pulls only up to the jellybean revision.

I see another post by someone with the same problems.

Any ideas?
[Nook Color Android Development] steven676:
Try removing any existing local manifests (both .repo/local_manifest.xml and anything in .repo/local_manifests) and then doing repo init/repo sync/brunch again.
[Nook Color Android Development] Zippy Dufus:
Fixed!

Yep, there is a file .repo/local_manifests/roomservice.xml which apparently caches the entries to the projects. It had the entry for the Nook Color jellybean revision and when I deleted it and the NC kernel project entry, the sync pulled the cm-10.1 revision.

Breakfast, bacon, brunch and now "roomservice" - I love this naming theme! I'm going to add this to my "enema" script which cleans up my build environment when I switch from one device to another.

Thanks for the quick reply!
[Nook Color Android Development] sark666:
I asked in a separate thread but it was recommended to me to try in a specific rom thread. I haven't used my nook color in awhile but was going to set it up for a friend and was wondering the state of the more recent roms.

I was curious how roms have come along for the nook color. Well, really the kernel. Last year I remember there were issues with hardware accelerated ui, hardware video playback etc.

Has there been development on that since last year? It's hard to determine if these are still issues in current roms looking at their long threads.
[Nook Color Android Development] AgentCherryColla:
Read the OP of the threads. HWA works. 4.1+ is nice. But personally I like CM7.2.
[Nook Color Android Development] steven676:
Fix for Flash, video thumbnailing in Gallery, and possibly other video codec issues

If you're building from source, you should try out the patch in http://review.cyanogenmod.org/#/c/44365/, which should fix Flash and other 720p-codec-related brokenness. (The patch is against cm-10.1, but should apply to jellybean as well.) Props to dhiru1602, who chased this bug down while working on another OMAP3 device.

If you're looking for a binary patch for a CM10.1 build, look here.
[Nook Color Android Development] drmarble:
CM10.2 works.

I managed to get cm10.2 to build, boot and run on the NookColor. Our ancient devices aren't dead yet. I only had to make a few changes to cm10.1 code to accomodate the new way partitions are mounted/managed in android 4.3. All the hard work was done by other developers before me, Dahlingren, eyeballer, keyodi, krylon, sluo (steven676) and others who I forgot or don't know how to spell. edit: and fattire, who also helped with an example of an fstab.grouper file. Those who want to build their own can look at my github account.

The usb mounting is a bit odd and still needs work. Play store refuses to connect, even after I stopped it and cleared cache. Benchmarks are a bit slower than cm10.1. I think we need GL3.0 to get any real advantages to cm10.2. There is no compelling reason to use it. As a comic book reader it still works about the same. I just wanted to show that we can still run Googles latest and greatest software.

Here's the obligatory screen shot:

http://i.imgur.com/GLG8yDr.png?1
[Nook Color Android Development] drmarble:
CM10.2 does work about as well as cm10.1. I found an alpha set of 4.3 gapps which make cm10.2 useable. The forum post is:

http://xdaforums.com/showthread.php?t=2012857

and his download link is:

http://tinyw.in/4NyC

I just flashed over cm10.1 (no wiping or erasing) and flashed his light gapps (it is just 17.7 MB). Everything seems to work fine. Slow, but it is a NookColor.

Get my device tree over at github.com/drmarble (or just the last few commits) and build it for yourself. Then go back to 10.0 (the fastest) or 7.2 (best battery life). Or, stay at the leading edge (most fun).
[Nook Color Android Development] steven676:
Lots of miscellaneous changes being pushed today, which should show up in CM10.1 nightly builds starting with August 3:

device/bn/encore for CM10.1:

Performance enhancements (1, 2) discovered during the course of porting for CM10.2

Reduce the size of the download and install by several MB by stripping debugging symbols from WLAN modules

Fix tethering via Bluetooth (untested)

Add a power HAL which pins the memory bus clock only when the screen is on, thus giving us the advantages of both the CM10 4/14 kernel (lower power consumption with screen off) and the later kernels (better performance).

Miscellaneous cleanups

kernel:

Fix dsscomp for use with hwcomposer (1, 2); thanks to dhiru1602 and keyodi for their work on this. Note that the userspace hwcomposer component is not enabled as of yet in our builds, as it appears to bring no performance benefit as of now.

(Hopefully) reduce/eliminate "DMA synchronization drop occurred with ..." messages in dmesg (thanks dhiru1602 and keyodi)

Kernel support for the new power HAL

Various bug fixes (hopefully not introducing any regressions)

As for CM10.2, there's a test source tree up at https://github.com/steven676/android_device_bn_encore/commits/cm-10.2 -- many thanks to drmarble for his work in helping to bring up the build. You'll also want two not-yet-merged patches in CyanogenMod: http://review.cyanogenmod.org/46671 and http://review.cyanogenmod.org/46762 . The resulting build runs quite well (at least as well as CM10.1) on the Nook Color.

In keeping with a long-standing Nook Color tradition, no public binary builds of CM10.2 for encore, please, for now. If you want to try it out, build it yourself -- there are excellent instructions up on the wiki which you can use as a starting point: http://wiki.cyanogenmod.org/w/Build_for_encore . (I don't expect the freeze on binary builds to last long -- we should be able to merge the tree into CM10.2 proper soon.)
[Nook Color Android Development] fattire:
To this point, I may add that I created a how to build 10.2 for grouper (the 2012 Nexus 7) walkthrough. The steps won't be exactly the same-- don't use the grouper 4.3 blobs for example, but it should provide some inspiration for how to proceed...
[Nook Color Android Development] deeper-blue:
Just looked through all the recent commits. Great work!

I will play around with CM10.2 a little bit tonight.
[Nook Color Android Development] alienbiker99:
just tried to tether to my galaxy nexus on cm10.2, I can pair the devices together and can enable the internet access button on the nook. My Gnex says its sharing internet connection to 1 devices, but I am unable to get on the internet on the nook. Thanks guys for keeping our device alive! those commits from a few posts up really make a difference in usability.
[Nook Color Android Development] steven676:
Reverted this, as it appears to cause a significant drop in touchscreen responsiveness. Also, merged a bunch of display-related stuff which should improve performance and perceived visual smoothness.

I'm now staging the source tree I intend to merge into CM on NookieDevs: https://github.com/NookieDevs/android_device_bn_encore/tree/cm-10.2. This tree is pretty much complete, though I need to push a couple of kernel tweaks before moving the whole thing into CM. If you're following along at home, please do build and test!
[Nook Color Android Development] steven676:
Potential eMMC hard brick bug may be triggered by CM10.2/Android 4.3

Some reports of bricked Nook HD/HD+s have turned up the fact that some Nooks may have Samsung eMMC chips affected by the infamous bricking bug. Although I believe most Nook Colors are unaffected, the fact that BN backported a workaround for this bug to the stock 1.4.3 kernel leaves me to suspect that there are at least some Nook Colors in the wild with one of the affected chips.

This issue is coming to the fore again with 4.3 because of Google's introduction of automatic trimming of free space on eMMC partitions, which may tickle this bug. Therefore, until we introduce a kernel patch to work around this issue, do not install CM10.2 or any other Android 4.3-based ROM unless you are supremely confident that your Nook Color is unaffected by this bug.
[Nook Color Android Development] pastordl:
Query

If Lagfix runs ok would that mean no problem with 10.2 - 4.3, since Lagfix runs fstrim?
[Nook Color Android Development] steven676:
Theoretically, not necessarily; in practice, if you've been running fstrim for a period of weeks and haven't bricked your device yet, it's probably not going to happen.

https://github.com/CyanogenMod/andr...mmit/92d81df4198e274858701b3771484c2617d1256e is the kernel workaround for the bricking bug; I'll issue updated binary kernels for CM10 and CM10.1 tonight. Anyone else who's building a 3.0-based kernel for encore, please apply this patch and urge your users to upgrade -- I don't think we have all that many Nook Colors out there with an affected chip, but one bricked device is too many.

By my analysis, it's not actually possible to trigger the brick bug that's been discussed on 2.6.32-based kernels (discard commands aren't supported on MMC devices in that release). That, however, would suggest that BN might be patching an unrelated eMMC corruption bug with unknown impact with its fix, so further investigation is required; if you happen to have a Nook Color where /sys/bus/mmc/devices/mmc0:0001/name reports "M8G2FA", please get in touch with us.
[Nook Color Android Development] pastordl:
Looks Like I'm safe.

The name returns in mmc0:0001/name all three: SEM08G
[Nook Color Android Development] webyrd:
Mine is also SEM08G
[Nook Color Android Development] steven676:
The eMMC saga delayed this a bit, but I merged our CM10.2 tree into CM over the weekend, so a local manifest is no longer necessary to build CM10.2 for encore.

Nightly builds for 10.2 should be rolling out starting today. As such, the ban on binary builds is now lifted, but PLEASE make sure you have https://github.com/CyanogenMod/andr...mmit/92d81df4198e274858701b3771484c2617d1256e and https://github.com/CyanogenMod/andr...mmit/ac5ed5c39360d501385e9b363cbff56df188e577 (depends on https://github.com/CyanogenMod/andr...mmit/a2a07e20cb84f071e888da7e5642c64b15f66635) merged into your kernels when building!
[Nook Color Android Development] pastordl:
If you are using Xposed for the Netflix workaround?

And if you frequently update your ROM?

There is a script file available at: http://xdaforums.com/showthread.php?p=44626173#post44626173.

This Script, "90-xposedpersist.sh", placed in /system/addon.d/ will cause the Xposed Framework to persist through ROM updates and eliminate the need to reinstall and reboot to activate the xposed modules including the Netflix workaround.

Look for "90-xposedpersist.zip" in the attached files in the above link and extract "90-xposedpersist.sh".

Saves a lot of time for frequent nightly updaters.

:highfive:
[Nook Color Android Development] steven676:
Thoughts on Android 4.4

To preempt the inevitable questions about Android 4.4:

No source yet, so we can't make any definitive judgments at this time. To be clear: nothing we say about 4.4 is definitive until we can get a look at the source.

It looks like SurfaceFlinger has been rewritten again, which may cause some trouble with our display stack. That said, our graphics blobs should support the features the new SurfaceFlinger needs, so this theoretically isn't an impediment to eventually having 4.4 on encore.

The much-ballyhooed 512 MB improvements appear to consist of modest memory footprint reduction for the framework and the exposure of lots and lots of knobs for OEMs to tune the system's memory management. We can probably make use of those knobs to improve the system's performance, but things will not magically get better the instant we put 4.4 on the device -- it's going to take work.
[Nook Color Android Development] frankusb:
Hey,

When do we get 4.4 builds? Does Netflix work on it????

Just kidding. What did this device ship with? 2.2! To even be considering 4.4 has to be some kind of record. I wonder what device has run the largest number of Android builds?

Frank
[Nook Color Android Development] runningslow:
Too lazy to look it up, but if memory serves... it shipped with 2.1 Eclair, because I remember the stock upgrade to Froyo was a big deal.
[Nook Color Android Development] Arbelzapf:
I think so as well. I'd be genuinely interested which device holds the upgrade record :)

On topic : Source is out now, isn't it? Can we start nagging yet?