yashsingh1/xdaforums huggingface dataset:
[Nook Color Android Development] leapinlar:
I'm not particularly well qualified to write that code. If you could give me some code to replace that check, I would be glad to include it in a revision of the image file.

But I do control the kernel for the first install and after the first install it gets moved to uRecImg for use with uRecRam, so maybe it would be best to just skip the test and hard code. Since I am using the kernel that you helped modify so that it has better SD write tolerances, I'm sure it sets emmc as mmc0.

Also I'm not convinced the stock ROM looks for p8 and aborts if it cannot find it. It may so it can store some media files there, but I doubt it. I have not heard back from polymath257 whether the p2 repair helped. All I modified for running stock off SD is change the ramdisk to point /system and /data to SD, keep pointing /rom to p2 on emmc, and set vold.fstab to SD p4. And vold.fstab still points to internal p8 for emmc media. This is why I doubt that stock is really looking for p8 other than vold.fstab, which I am sure would not cause an abort.

Also if I am reading your's and fattire's posts correctly, it looks like you are hoping to abandon the existing SD installer in favor of a smart app that will make it so ordinary ROMs will run without relying on the SD installer script to modify it. Is this right?
[Nook Color Android Development] steven676:
Something like

if [ x"`cat /sys/class/mmc_host/mmc0/slot_name`" = x"external" ]; then
SDCARD=mmcblk0
else
SDCARD=mmcblk1
fi

That's also an option -- just skip the checks and set SDCARD=mmcblk1.

Yeah, that does seem strange, though not entirely beyond the realm of possibility. The original point stands, though -- stock installs on eMMC are not going to be supported with the new layout. (If someone gets it to work, more power to them.)

That is the goal, yes. We still do need an initial install procedure, but the hope is to have some ROM (say, a milestone build or an RC/stable) already installed on the card image, so that the only thing that has to happen on first boot is partitioning the rest of the SD card. (The initial SD partitioner would probably be based on the Android recovery and work very similarly to the eMMC partitioner that we've been talking about.)

That said, we're some ways off from that, so the SD card installer still needs maintaining for now (thanks for your work on that, by the way!).
[Nook Color Android Development] polymath257:
My stock is currently defunct (I accidentally wrote over it). I know I forgot to format p8, so that could be the reason stock refused to boot. I will attempt to make a new SDcard install of stock and see what happens after p8 is formatted.

I am sorry for any confusion regarding this.
[Nook Color Android Development] polymath257:
I've been having some significant problems here.

I realized that I hadn't formatted p8 before testing the stock sdcard install. So I did that. But when I went back to the sdcard, I mistakenly went into recovery. Since there was a zip file on the card, it flashed that over my stock install (stupid of me, I know).

Then I decided to do a fresh sdcard install of CM11. I used leapinjar's 'largest-Rev8b' image. When I booted up, the screen went black. Nothing. Thinking it may have been a problem with the partitioning, I attempted to do the install from my other nook. Its screen also went black.

At this point, both of my NCs were completely unresponsive. Black screens, absolutely no glow, no response from PC attachment, no sign of life at all.

Fortunately, I had run into this before. I opened up both NCs, disconnected the power cable for a minute or two, reconnected, and they both booted up. Whew!

I was able to do the sdcard install from 'larger-Rev8', but I know I had previously used 'Rev8b', so I am guessing I had a bad dd of the image before. With the small p8 partition, this worked well.

Now I am running into linux problems with mtp: when I try to put the sdcard version of the stock zip file on internal storage, it complains about the inability to write cache and fails.

So at this point I am putting stock aside for a while and concentrating on other things.

---------- Post added at 10:49 AM ---------- Previous post was at 10:41 AM ----------

Something should be provided for going back to the old layout in case someone wants to. Perhaps just another re-partitioner.
[Nook Color Android Development] leapinlar:
If you want to go back to the stock partition layout, you can flash my repair partitions145678 zip from my NC partition repair thread. It puts it back to the 1GB data, 5GB media scheme. If you want it back to the 5GB data, 1GB media layout use the zip from Dean Gibson's repartition thread.
[Nook Color Android Development] polymath257:
Fair enough! I'm going to stick with my current layout and not worry about stock. If I need to go back, I can always do it by hand :) But it is good for people to have the resource.
[Nook Color Android Development] retire01022004:
Volume

Went from 10.1 in EMMC to CM11 in SD. Running great! Only issue is volume low. Was much higher with 10.1 for some reason without using any volume enhansors. Tried couple of enhansors w/CM11 - no louder. Any suggestions?
[Nook Color Android Development] pastordl:
Try speaker boost. I run it at 50%,but be careful above 40%
[Nook Color Android Development] retire01022004:
Pastordl

Thanks - that worked very nice.
[Nook Color Android Development] steven676:
Heads-up: another local root hole ...

A heads-up: I've landed a patch in our kernel for a security bug in the core kernel. The bug in question (CVE-2013-6282) allows users to read and write arbitrary kernel memory on machines with ARMv6k and ARMv7 CPUs, and is therefore exploitable for privilege escalation (root) by a local attacker on any device with those CPUs.

The CVE entry notes that this bug has been exploited in the wild since October, so it's important that you take this fix as soon as possible if you build your own kernels. CM11 nightly releases should be patched starting February 19, and I've posted updated kernels for CM10.1 and CM10.2. (I apologize for this -- this is the sort of thing that I should have picked up much, much earlier than I actually did.)

As noted above, this bug covers ARMv6k and ARMv7 CPUs, which is just about every device released in the past three years. Upstream kernel versions known to be affected include 3.0.x, 3.1.x, 3.2.x (x < 54), 3.4.x (x < 12), and 3.5.x (x < 5), though some vendors will already have patched this bug (Google slipped this fix into the 3.1.x kernel for grouper on Android 4.4, for instance). (Based on the description and the commit history, I strongly suspect this bug affects all unpatched kernels from 2.6.38 up through the 3.5.x series, but I haven't verified this.) If you're not sure your other devices are fixed, check the kernel source (or bug your friendly local device kernel maintainer to do so).

<RANT>This bug has been known since at least September 2012, and it's been fixed in the 3.4-stable series since October of that year. The problem description should scream "THIS IS A ROOT SECURITY HOLE" to anyone with half a brain. So why, oh why, did this not get picked up as a security-relevant patch by vendors until it was exploited in the wild a year later??!? (Of course, that only covers publicly known exploits -- your unfriendly local targeted hacking group/unnamed government agency was certainly perfectly capable of reading the kernel commit stream and realizing the exploitability of this bug much earlier than that ...) Also, the response even after the security advisory was issued has been unconscionably slow and quiet -- 3.2.x-stable didn't pick up a fix until January 2014, and I shudder to think of all the various exploitable device kernels whose maintainers haven't even heard of this bug yet ...

Bottom line: thanks to the ubiquity of Android, Linux kernel holes have suddenly become much more valuable to attackers. If we plan on keeping users safe, we need to be far more aggressive about identifying security fixes -- and pushing those fixes downstream to the zillions of different device kernel branches, and pushing builds based on those fixed kernel trees down to end-user devices -- than we have been so far.</RANT>
[Nook Color Android Development] fattire:
Quick heads up-- there's some weirdness in the patch wherethe kernel won't boot at -O2 (optimization level two in the compiler). So tonight's build I think may not work. Steven pulled the patch until it can be looked at to see what's up wid dat. And he's also taking a well-deserved vacay, so everyone wish him a good time :) Tomorrow's build should be better...
[Nook Color Android Development] tdm:
Why? Because forks and vendors and patents.

This is but one of the prices we pay for having a heavily forked kernel that is brimming with vendor code written by people who have no business writing C code at all, let alone kernel code.

If the android kernel was even remotely well managed by vendors, we would have one kernel source (preferably from Linus). Or at most one kernel source per soc. Not one per device.
[Nook Color Android Development] volpo222:
Sorry, wrong thread.
[Nook Color Android Development] pmgnet:
ART?

I wanted to try ART, and tried to install pa gapps, which supports ART, but that failed due to insufficient storage. Is there a gapps we can use for ART?
[Nook Color Android Development] pastordl:
About half way down in post three of the nightly post link below you will find that art is not currently supported in CM11 for Nook Color. So your answer would be there are no gapps you can use. From what I have read of the ROMs that do have art enabled, little or no improvement shows in our limited memory NookColors. That is why they are looking into changing the partitions. See prior posts.

http://xdaforums.com/showpost.php?p=49883170&postcount=3
[Nook Color Android Development] polymath257:
You need to either disable the boot animation or repartition emmc in order to get ART to work on the NC. Either way, the benefit is minimal.
[Nook Color Android Development] polymath257:
Lately, when I have attempted to build from either cyanogen source or from steven's source, I have obtained the following error message:

target SharedLib: libc (/home/daniel/android/cm11/out/target/product/encore/obj/SHARED_LIBRARIES/libc_intermediates/LINKED/libc.so)

/home/daniel/android/cm11/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7/bin/../lib/gcc/arm-linux-androideabi/4.7/../../../../arm-linux-androideabi/bin/ld: error: /home/daniel/android/cm11/out/target/product/encore/obj/STATIC_LIBRARIES/libc_common_intermediates/libc_common.a(memchr.o): multiple definition of 'memchr'

/home/daniel/android/cm11/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7/bin/../lib/gcc/arm-linux-androideabi/4.7/../../../../arm-linux-androideabi/bin/ld: /home/daniel/android/cm11/out/target/product/encore/obj/STATIC_LIBRARIES/libc_common_intermediates/libc_common.a(memchr.o): previous definition here

collect2: error: ld returned 1 exit status

make: *** [/home/daniel/android/cm11/out/target/product/encore/obj/SHARED_LIBRARIES/libc_intermediates/LINKED/libc.so] Error 1

Any recommendations?
[Nook Color Android Development] pmgnet:
I just needed to flash the mini PA gapps. It booted fine into ART, but the kindle app went from 40 seconds in dalvik to over 2 minutes in ART. Oh well, at least I tried it!

Now, I do have twrp and that might be causing issues with ART.
[Nook Color Android Development] polymath257:
The kindle app seems to always take a long time for me also. I have found that clearing its cache (settings>>apps>>all>>kindle>>clear cache)

will sometimes speed up the initialization. It is possible the 2 minutes with ART was simply compiling it..see what happens the next time you run it.
[Nook Color Android Development] drmarble:
That problem was caused by commit #:http://review.cyanogenmod.org/#/c/60046/ memchr.c was included twice for some arm processors.

I commented on our building problem on gerrit. They (Steve Kondit) fixed it in http://review.cyanogenmod.org/#/c/60675/

The build is fixed now.

You missed the compile problems with bluedroid back on the 26th. I am proud to say that I fixed that problem that prevented building for many legacy devices. Sometimes building bugs get introduced. If you can figure out which commit caused it, comment on in on Gerrit, even though it has already been merged. The appropriate people will see it. If you can figure out how to fix the problem, even better. Submit a patch to gerrit.

enjoy building.
[Nook Color Android Development] andtron:
When I was doing the "repo sync", I am getting this error:

fatal: duplicate path kernel/bn/encore in /home/xxxx/android/system/.repo/manifest.xml

I check the file and there is no reference to this location, any one know the problem is?

This fatal error aborted my build.

TIA.

P.S. Earlier, the error is about the duplication of the hardware/ti/ompa3, I removed it, and now this

Edited:

I have fixed the issue, replacing the following on my roomservice.xml file:

<project name="steven676/android_device_bn_encore" path="device/bn/encore" remote="github" revision="cm-11.0" />

<project name="steven676/ti-omap-encore-kernel3" path="kernel/bn/encore" remote="github" revision="encore-omap3-3.0.y" />

<project name="steven676/android_hardware_ti_omap3" path="hardware/ti/omap3" remote="github" revision="cm-11.0" />

with

<project name="NookieDevs/android_device_bn_encore" path="device/bn/encore" remote="github" revision="cm-11.0" />

<project name="CyanogenMod/android_kernel_bn_encore" path="kernel/bn/encore" remote="github" revision="encore-omap3-3.0.y" />
[Nook Color Android Development] andtron:
Could anyone be kind enough to tell me the name value to the "hardware/ti/omap3 path in the manifest.xml or default.xml file (in the android/system/.repo/manifests folder)?

TIA

Update: never mind, I figured out the string, but now runs into another error, not sure if it has something to do with Steven's update below.
[Nook Color Android Development] steven676:
Experimental memory management changes (testing requested)

I've pushed some changes to my kernel and device/bn/encore repositories on which I'm looking for feedback.

Enable Kernel Samepage Merging (KSM) by default: I've personally been running with KSM enabled for ages now with no ill effects. This usually results in 10-20 MB memory savings after just a few hours. Background CPU usage increases slightly, which seems to hurt battery life more than it does performance; we can explore ways of controlling this later.

Kernel: update LZO compressor code to latest upstream version (1, 2): this is reported to result in 2x speedups in both compression and decompression.

Kernel: improve code generation for unaligned memory accesses and indicate support for efficient unaligned access: this should further speed up LZO, and might also result in some improvement in other areas, particularly networking performance.

Kernel: enable memory cgroups: this results in 2 MB memory overhead, but we want this for ...

Enable swap to zRAM by default. This effectively means compressing infrequently used memory (using the LZO algorithm -- hence the sudden interest in LZO performance), which should increase the amount of memory available for the working set. The selected parameters (96 MB of swap, foreground swappiness of 20) can be tuned based on experience.

The net result should be more memory available for things you care about, hopefully without too much impact on performance and battery life -- but of course, real life may have different ideas. To that end, when testing these changes:

Do you notice less memory pressure (killed background apps and launcher restarts are some possible effects of memory pressure, though there are others)?

Do you see increased lag, and if so, how much? (Swapping pages back into memory takes time, so using swap can introduce additional lag. If there's lots of it, particularly while interacting with a foreground process, that suggests we need to tune the swap parameters, or abandon use of swap if we're not seeing enough benefit elsewhere.)

How is battery life affected? (I expect KSM, in particular, to be a net negative for battery life, but it'd be nice to get a baseline value so that we know whether any potential measures to reduce the impact are effective.)

As usual, we're also interested in reports of crashes or instability created by these changes. (I don't anticipate any, but there's always a possibility I've overlooked something.)

(It occurs to me now that all of these changes are confined to the kernel and initramfs, so it'd be easy to package a test kernel with just these changes -- I'll probably do this in a bit to increase test coverage beyond self-builders.)
[Nook Color Android Development] drmarble:
The commit that causes problems is: 2637cb97c5ae2d27f185b4a6ffecdb9726648fad

ARM: 7928/1: kconfig: select HAVE_EFFICIENT_UNALIGNED_ACCESS for CPUv6+ && MMU

Reverting this makes it boot up just fine.

It looks so innocuous.

Sorry to hear about the death of your NookColor. I hope that it can be resurrected. I can understand if you don't decide to buy a replacement, they are a bit outdated. Without your work, this device would have been outdated long ago.
[Nook Color Android Development] polymath257:
I am still learning a lot about repo and git, so how do I revert a particular commit? Or will that be done naturally when I sync?
[Nook Color Android Development] drmarble:
You need to revert the commit.

cd device/bn/encore

git revert --no-edit 2637cb97c5ae2d27f185b4a6ffecdb9726648fad

cd ../../..

the long 2637... is the commit number. You can just use the first 8 or so digits usually. Just enough digits for it to be unique.

the --no-edit flag prevents an edit window from appearing asking for why you made the changes.

If you do a git log from your encore directory you will see what commits are present in reverse chronological order. It shows what was done and the commit #. After you do the git revert command, git log will show that the commit has been reverted.

You will have to re-revert it whenever you repo sync. Syncing gets it back to the state on the github server (synced).

Hope this helps. Enjoy building.
[Nook Color Android Development] polymath257:
One more question. This is more of an anoyance than anything else.

I have been using steven's repos to do my buiilds. Whenever I brunch encore, a line is added to my roomservice file for a CyanogenMod kernel repository. One the next repo sync, that causes an issue with a duplicate target directory.

How do I prevent this duplicate (other than simply erasing the line in roomservice each time)?

---------- Post added at 05:56 PM ---------- Previous post was at 05:53 PM ----------

When I tried this, I got the message

fatal: bad object 2637cb97c5ae2d27f185b4a6ffecdb9726648fad

----------------------------------------------------------------------------------------------------

The directory for this revert should be kernel/bn/encore, not device/bn/encore
[Nook Color Android Development] steven676:
A couple days off the charger and some, erm, "percussive maintenance" have the device running again ... for now.

Ah, the perils of backporting patches ...

With this in mind, I went looking through the kernel source looking for instances of CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS to see what this change might have affected. (I'd done this earlier, but remembered only a handful of sites under drivers/net and and in the kernel tracing code.) That turned up https://github.com/steven676/ti-oma...e-omap3-3.0.y/lib/zlib_inflate/inffast.c#L278 ... which is relevant because our kernel is gzip-compressed and therefore has to be inflated with zlib before being booted. That, in turn, jogged my memory regarding a patch I saw while backporting a bunch of other ARM patches (more on that later), without which unaligned access in the decompressor would cause a fault.

A boot test would have caught this, but they're difficult to perform when your hardware doesn't boot at all. Meanwhile, I was using the unaligned patches successfully on other 3.0-kernel ARM devices, so I figured they should be okay ... of course, those kernels also happened to include the other backported ARM patches, so they wouldn't be affected by the boot failure.

Anyway ... with that patch included, my kernel tree should actually boot again.
[Nook Color Android Development] polymath257:
I've had to disconnect the battery a couple of times to get my devices running again. The first time I tried, I ruined the connector, so I had to replace the battery completely. The connector lifts *up* not over. Anyway, I was able to go from no response whatsoever to being alive and well.

I'm glad yours is working once again! Any word on where the percussive maintenance should be applied to work optimally?
[Nook Color Android Development] steven676:
Various things ...

A handful of things that might be coming up over the next few weeks:

I'm considering dropping hwcomposer from the CM11 builds due to persistent problems with video playback (some videos jitter when played; weird things happen when you try to play widescreen video in portrait). I suspect the bugs are in our kernel (and probably related to the DSS subsystem, possibly the scaler), but don't have time to track them down. (If you're feeling ambitious, have a look in drivers/video/omap2 on the LGE P970 kernel and look for differences to our kernel.)

Bluetooth has been broken for long enough now that I suspect that no help is coming from outside. Unfortunately, the merge from Qualcomm that probably introduced these problems is massive and linked to changes in other projects as well (packages/apps/Bluetooth, hardware/libhardware, and the Bluetooth code in frameworks/base); this makes bisection a challenge (one which I can't really take on because it requires too much build time on my hardware). If someone has a fast build box and wants to take on the challenge of sorting out what happened here, I can provide last-known-good commits for these projects to give you a baseline to work from.

There are a couple of new branches in my kernel tree, which I intend to merge into the encore kernel at some point in the not-too-distant future; I'll talk more about these in a separate post.
[Nook Color Android Development] moocow1452:
I had an issue with my USB port breaking pins, so I needed an entirely new device. If you or anyone want to have a go at the replacement parts, I can send the disassembled bag of parts out, beats the $5 I'd get on eBay.

Regarding video, is that the reason that current gen Netflix app has video in the upper right corner with pink and green stripes forming a weird American flag pattern on the device. Cause using the current Netflix app would be awesome with profiles and jazz.