yashsingh1/xdaforums huggingface dataset:
[Nook Color Android Development] steven676:
Another test bootloader

Here's an updated bootloader packaged as a flashable ZIP. I don't anticipate any trouble, but please test and report any boot failures or other problems (note that if it completely fails to boot, it's possible holding the power button down won't successfully turn off the device, and you'll have to wait for the battery to drain).

There's one change compared to the last bootloader, to avoid passing a BN-specific form of the "wipe data" command to the recovery whenever recovery boot is selected from the menu. (We're very lucky that non-BN recoveries ignore this command!)

Source: https://github.com/steven676/encore_cyanoboot/tree/502626ef520e46a05a78f69116b3f9f74fbd1617. Note that if you try to build this with GCC 4.7 as shipped in the Android prebuilt tree, the result doesn't boot -- for extra credit, figure out why. (The binary I'm including was built with Emdebian's gcc 4.6.3-14 armel cross compiler on amd64.)
[Nook Color Android Development] hwong96:
Tested bootloader zip on cm11 snapshot m9. Works fine.
[Nook Color Android Development] pastordl:
Tested with M9, rebooted to emmc, four separate recoveries, (2 emmc, 2 Sdcard). Only change noted was date 7-4 and time. No problems so far.
[Nook Color Android Development] steven676:
About repartitioning ...

No, this didn't disappear from my agenda, but ...

That turned out to be a rather incorrect estimate. While detecting the different partition layouts is easy, changing the storage configuration (specifically, going between traditional storage backed by a FAT partition and FUSE-emulated storage backed by /data/media) requires changing a setting in framework resources, which is something that can't currently be done at runtime.

In other words, doing this is going to require changes to the Android framework (specifically MountService). I have a small patch against frameworks/base with a proposed solution -- allowing system properties under ro.mnt. to override specific settings in framework resources (storage_list.xml) -- but while this has potential applications on other devices as well (notably any other devices bootable from SD card), it may or may not be accepted upstream. With that change in place, the detection and setup code then looks like this (EDIT: revised version here for changes requested by upstream to the framework patch).

I'd appreciate it if those of you building yourselves could test out this patch and my device/bn/encore tree, to see if any problems come up. (If you feel particularly ambitious, you could even try repartitioning your own device to eliminate the media partition.)
[Nook Color Android Development] drmarble:
I tried out the new bootloader and found it works fine. But then, it worked fine before.

I also tried homebrewing with your device tree and the frameworks/base patch. It also works fine. I had tried building without that patch and got the error:

device/bn/encore/overlay/frameworks/base/core/res/res/xml/storage_list.xml:37: error: No resource identifier found for attribute 'runtimeConfigurable' in package 'android'

It just needed your patch to define it. I guess I should remove the media partition (or is it emmc?) and see if I have data/media like the big boys have nowadays. I'm not entirely clear on how to reformat the memory. In the past I just flashed some nifty data resize zips and reinitialize partition zips without really understanding how they worked and what they did.

(edit) I see that I need to use fdisk and mke2fs (and maybe mkdosfs but I don't think so). I enlarge /dev/block/mmcblk0 and remove /dev/block/mmcblk0p8. I think I will wait for better instructions.

I also built tenderloin and flo using your frameworks patch and it didn't break anything. I'll go +1 it on gerrit after I test it on ovation.

Thanks for keeping this poor tired device alive. Sometimes I think about just putting 7.2 on it and using it as a bedside clock. Then you come out with more advances that I just have to try.
[Nook Color Android Development] drmarble:
I've made another successful build using your most recent changes to device/bn/encore cm-11.0. I even installed the recovery v6.0.5.0. Everything seems to be working fine. Running mount as root doesn't show anything odd. I guess I would have to enlarge data and remove media to see the changes.

root@encore:/ # mount
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
none /sys/fs/cgroup tmpfs rw,relatime,mode=750,gid=1000 0 0
none /sys/fs/cgroup/memory cgroup rw,relatime,memory 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/fuse tmpfs rw,relatime,mode=775,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/by-name/system /system ext4 ro,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
/dev/block/by-name/userdata /data ext4 rw,nosuid,nodev,noatime,user_xattr,acl,barrier=1,data=ordered,noauto_da_alloc 0 0
/dev/block/mmcblk0p7 /cache ext4 rw,nosuid,nodev,noatime,user_xattr,acl,barrier=1,data=ordered 0 0
/dev/block/mmcblk0p2 /rom vfat rw,sync,noatime,nodiratime,uid=1000,gid=1000,fmask=0117,dmask=0007,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 0
/sys/kernel/debug /sys/kernel/debug debugfs rw,relatime 0 0
/dev/block/vold/179:49 /mnt/media_rw/sdcard1 vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1023,gid=1023,fmask=0007,dmask=0007,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
/dev/block/vold/179:49 /mnt/secure/asec vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1023,gid=1023,fmask=0007,dmask=0007,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
/dev/fuse /storage/sdcard1 fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0
/dev/block/vold/179:8 /mnt/media_rw/sdcard0 vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1023,gid=1023,fmask=0007,dmask=0007,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
/dev/fuse /storage/sdcard0 fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0
/dev/block/dm-0 /mnt/asec/com.konami.DASH.frogger-1 ext4 ro,dirsync,nosuid,nodev,noatime,user_xattr,acl,barrier=1 0 0
/dev/block/dm-1 /mnt/asec/com.massivefinger.PinballRide-1 ext4 ro,dirsync,nosuid,nodev,noatime,user_xattr,acl,barrier=1 0 0
/dev/block/dm-2 /mnt/asec/com.oldtimeradio-1 ext4 ro,dirsync,nosuid,nodev,noatime,user_xattr,acl,barrier=1 0 0

I have been having problems with Google Play services stopping and needing to reinstall gapps to get it working again. This has been happening for a few months so it is unrelated to any recent changes.
[Nook Color Android Development] steven676:
Some changes to the hwcomposer

I've merged some changes into the OMAP3 hwcomposer source (https://github.com/CyanogenMod/android_hardware_ti_omap3/compare/cm-11.0@{2014-08-08}...cm-11.0) to improve correctness, particularly when scaling layers; these should be part of nightlies starting August 10. While I don't expect any problems, please report any new rendering glitches or crashes you do see. (I'm also interested in reports of trouble on other OMAP3s using the same hwcomposer source, as I believe much of this code isn't exercised on encore at the moment.)
[Nook Color Android Development] pastordl:
Tried 8/10 nightly and ran YouTube, Netflix, Crackle, browser streaming video and video from avi with no noticed problems. Didn't notice any improvement either.
[Nook Color Android Development] hwong96:
Installed 8/10 nightly. YouTube, IMDb, ESPN videos run fine. I ran catlog and saw an error for hwc. Attached for your reference.

Edit: 8-14-14 'Cannot play this video' message on the following apps:

I don't know if it is the app, but Flixter gives the message. The Flixster update now plays in HD, so I don't know if that is the cause. 1080p sure. 720p?

The Watch TNT app gives this message at starup, but I'm able to watch the show. I watched the premiere of "Legends" on the nook before it aired on primetime TNT cable.
[Nook Color Android Development] pmgnet:
Is there a flashable zip to update my recovery so I can get to latest nightlies? I'm on twrp 2.6.3 but would take cwm or twrp to get to update.

---------- Post added at 12:31 AM ---------- Previous post was at 12:30 AM ----------

Preferably cwm touch if I have to use that!
[Nook Color Android Development] pastordl:
Yes 6.0.4.8 is available on my Help post in the signature below.
[Nook Color Android Development] polymath257:
I have a zippable version of 6.0.5.0 if anyone is interested.
[Nook Color Android Development] pastordl:
I for one would be. You could attach it to a reply here for anyone else that might want it.
[Nook Color Android Development] polymath257:
Here it is. It was compiled during a CM-11 build on 8/11/2014.

This one installs to standard recovery:

http://d-h.st/ncf

And this one installs to alternate recovery:

http://d-h.st/gyL
[Nook Color Android Development] Cor-master:
nevermind
[Nook Color Android Development] deeper-blue:
So, while I haven't been actively involved in the Nook Color development for quite a while now I just read that the Moto360 watch does run based on a omap3. Also Android wear runs on a modified version of 4.4.

This makes me curious if Motorola has some more recent pvr binaries/drivers and/or how they modified android wear well.
[Nook Color Android Development] zeiss74:
is there any reason NOT to use the latest recovery you linked? i flashed CWM 6.0.4.7 in order to install the CM11 snapshot M9, but still got status 7 CM install errors, so i went with the final nightly of CM10.0 (which someone had said 10.0 was faster on the NC anyway). but if 6.0.5.0 is out there, I might as well flash it for later attempts at CM11..
[Nook Color Android Development] polymath257:
I have heard reports of difficulty flashing older ROMs (CM 7, for example) with the newer recoveries. I have not verified that myself.
[Nook Color Android Development] bigbob23:
FWIW I just installed the 20140917 nightly with CWN 6.0.5.0 with zero issues.
[Nook Color Android Development] Berryness:
I have the same problem you found some answer
[Nook Color Android Development] deeper-blue:
The Moto360 seems to run a 3.10 kernel on it's omap3.
[Nook Color Android Development] steven676:
Thanks for giving me a nudge to go and look into this further.

That 3.10 kernel has source in Google's kernel/omap tree (branch android-omap-minnow-3.10-kitkat-wear). And inside that kernel is a huge gift from Google and Motorola to us: https://android.googlesource.com/ke...at-wear/drivers/gpu/pvr/include4/pvrversion.h

Yes, that's the kernel component for a new PowerVR SGX driver -- 1.12@2917986. (The kernel component of the PVR drivers is MIT-licensed, so Google and Motorola aren't obligated to release its source to us -- indeed, I don't believe the source for Google Glass's PVR kernel modules is available.) The matching userland components can be obtained from a system dump, and a cursory look at them suggests that all the fancy new features introduced to the display stack since 4.0 are supported.

That said, you aren't going to be able to just drop that driver into our kernel and go -- it depends on infrastructure (Android's kernel sync framework) that's missing from our kernel. A backport of that infrastructure to 3.0 exists in Google's kernel/common tree, but it's big and touches a bunch of different things in the kernel. It's unclear to me whether merging that backport (and then fixing the issues it'll cause, and then bringing in whatever additional changes that driver needs to work) into our existing kernel or rebasing our board support on top of 3.10 is the way to go.

In any event, I won't have any time to look at this for several weeks, at least. If someone has time and wants a project to take on ...
[Nook Color Android Development] polymath257:
I know this is probably a bit premature, but are there any plans to attempt to port Android L to the encore?

I really enjoyed learning how to do KK, and would certainly be up for testing and some minor coding.
[Nook Color Android Development] steven676:
As I said with KitKat ... it's impossible to say anything definitive until we get a look at the source.
[Nook Color Android Development] deeper-blue:
My thoughts are going along the second approach, take the 3.10 kernel and add our board support on top of it. I've never done a bring-up of a new device and am not sure how difficult that will be - but I assume it might be less annoying and more fun to add support for the nook color board one piece at a time than trying to backport all kinds of newer kernel features back into our current kernel.
[Nook Color Android Development] fattire:
I can work a bit on it as well I think... Really want to see nook color on a stick!

Find me on irc, db.... Obviously more becomes clear once source is available...
[Nook Color Android Development] keyodi:
fattire, you wanna create a branch on nookiedev? I'll try and help out if I have some free time.
[Nook Color Android Development] fattire:
Ooo we're putting the band back together!

Has anyone looked at the Lollipop preview kernels to see if there's any new stuff needed, like the network auditing stuff was needed for ics? If not, should we try to get a lollipop build up with the current kernel first?

Any idea if this would be the cm-12 branch? Kernel-wise, we should figure out which codebase we want to start with and build on top of, and then what parts we want to bring in from the old kernel, etc.. maybe start off by like filling out something like...

Main kernel : 3.10.x from [link] as a base?

Patches : How far in do we want to patch?

Board file : move from current kernel probably..?

GL blobs : [link]

other blobs : use current?

drivers/bits to set up

* mmc

* touchscreen - 2 digitizers

* bt/wifi wilink wt1271 transport stuff

* backlight

* audio

* power management

* I'm sure there's more...

Name of defconfig : whatever

What are we moving across, what is already in the new kernel source.. we porting, are there new ones...? What if anything may we need to change or add in u-boot?

I haven't touched a kernel in a long, long time. I know a lot has changed. There's now that whole hardware-profile system thing... dunno if that applies to this...
[Nook Color Android Development] deeper-blue:
Yeah, this hardware profile thing is definitely new to me too, but I think it might make things easy for us to adapt the 3.10 kernel to the nook as much should be shared between all omap36xx devices.

One of the first board specific things we need to get up and running is I guess the UART and the display for debugging. Does anybody of you have the UART actually connected/soldered?
[Nook Color Android Development] fattire:
If I remember right with that first 3.x port we did a hail mary and somehow I/keyodi got it to start up basically blind without UART at all-I remember at some point dumping the kernel log to the framebuffer... the good thing is that you're not going to brick anything from blindly trying stuff... Keyodi, do you remember how it came together?

But to answer your question, I think I remember reading someone fairly recently had tapped UART somehow on encore but I can't remember who it was. Maybe steven676 will remember.
[Nook Color Android Development] hwong96:
I found Pokey9000's xloader here http://xdaforums.com/showpost.php?p=20416742&postcount=108

It may help. Adam Outlet's UART how-to for nook tablet may be of use here http://xdaforums.com/showthread.php?t=1423009
[Nook Color Android Development] bass0324:
This would be so awesome, never thought I'd see my nook color get updated to lollipop. If there is anything I could do to help or test let me know.
[Nook Color Android Development] fattire:
Lollipop! (POP) badumbumbum....

Now that code has dropped for lollipop, I went through grouper's changes as a sample and collected a few things that we might need for cm-12.0 encore...

here's a diff. It's VERY VERY preliminary. I probably missed a ton of stuff and you should do your own comparison with other devices, but whatevs.

sluo also took a look and didn't see any dramatic, dramatic changes to infrastructure on the order of the gingerbread->ics changes... which could be good.

For the diff above, I skipped:

* Anything SELinux policy related

* any prebuilt kernel stuff

* some recovery stuff (grouper removed custom recovery UI..) CM is going to have its own touch recovery I guess.

* driver stuff related to audio/power which shoudlnt' apply....

Somoene please look and see if I missed anything.

And now..

[youtube]9-DuC0tE7V4[/youtube]
[Nook Color Android Development] Arbelzapf:
I love all of you
[Nook Color Android Development] sagirfahmid3:
Lollipop on the Nook Color? our ancient little device?

You remind me of this article: http://www.bbspot.com/news/2008/12/linux-on-a-potato.html

(Hehhe...)
[Nook Color Android Development] Android0x7:
Hi ,

I stumbled upon ur post while searching a solution to my problem.

I am having a similar problem when I try to repo sync cm11 for device Alcatel cocktail OT 995 (device tree from bagyusz).

Can u please tell me how u eventually sorted out ur issue ?

Thnx in advance.

Ps: instead of

error.GitError: prebuilts/gcc/darwin-x86/mips/mipsel-linux-android-4.4.3 update-index: fatal: Not a git repository (or any parent up to mount parent /media)

Stopping at filesystem boundary

I get error related to this - legaCymod/android_build
[Nook Color Android Development] pmgnet:
I'm not sure I ever got it sorted out. I think I ended up rebuilding my build machine and I got further. Apologies for the lack of detail.
[Nook Color Android Development] drmarble:
You just need to remove the offending directory. cd legaCymod/android_build ; rm -rf * and then maybe cd .git ; rm -rf . Get it all cleaned out. Then rerun repo sync. You just have some corruption in the git repo for that directory. It will sync quickly since the bulk of the downloaded data is contained in your .repo/projects directory. The visible working directory is built from that. Just delete the visible directory and all it's visible and invisible contents and let repo sync rebuild it.

By the way, I hope there is a typo in your error. There shouldn't be a legaCymod /android_build directory. Maybe legaCymod is your base for your build system. Then, go to build and clean out.

Hope this helps.
[Nook Color Android Development] steven676:
Changing the L3 clock speed

I've pushed a change to my kernel repository which reduces the L3 (memory bus) clock speeds from 100/200 MHz to 83/166 MHz; hopefully, this will help users experiencing crashes or SOD with 3.0 kernels on their Nook Colors.

Some background:while comparing our 2.6.32 and 3.0 kernels a while back, I noticed that one of the changes that Barnes and Noble added to the standard OMAP 2.6.32 kernel was clamping the L3 clock speeds (warning: huge diff, may slow down or freeze browser) to those of the OMAP34xx series. We didn't originally carry over this change from 2.6.32 to 3.0 (it's easy to miss and only really stands out if you compare the standard OMAP 2.6.32 kernel to BN's kernel release). As far as I can tell, the OMAP3621 in the Nook Color is a 3630 die in a package with fewer pins; however, it's probable that some 3621s come from early production batches of chips which failed to meet spec at the 3630 clock speeds. It seems likely, therefore, that many of the unresolved SODs and crashes that have been reported with 3.0 kernels on the Nook Color are due to our running the L3 bus at a clock speed significantly higher than spec.

Unfortunately, cutting the L3 clock speed 17% is going to have the same effect on memory bandwidth, which is something the Nook Color is already somewhat starved of (the relatively large screen for the time results in high memory bandwidth requirements for the graphics subsystem). That said, in principle, performance should be no worse than BN's 2.6.32 on the same device, and we should get improved stability, reduced power consumption, and less heat from the chip. We should also be able to trade those latter three attributes for higher overclocks; as a result, I've enabled the 1200 MHz overclock on the test kernel I posted for CM11. (Note that this is likely not an even trade performance-wise: we're giving up 17% of memory bandwidth -- which affects nearly every component of the system, including the GPU -- for a 9% improvement in maximum CPU overclock.)

Bottom line: please test the new kernel, particularly if you have a device that's experiencing SOD or crashes with 3.0 kernels (CM10 and later). If you don't ... please test anyway and let me know how you get on performance-wise.
[Nook Color Android Development] drmarble:
Sluo:

I tried your new kernel source. It built and flashed fine but now I have a brick. Holding down the power and n button haven't restarted it yet. It just sits there looking black and boring. I guess I will be pulling the battery later. Maybe I should have just flashed your kernel. The changes didn't look so extreme to cause this.

I have my first dentist appointment since 1983 this afternoon. A tooh ache drove me to it. I doubt I will be in any debugging mood for a while but will let folks know what the final fate of my NC is.

A nook tablet (16Gb) should arrive today. It will be a christmas present for my eldest granddaughter. I figured it has enough power for some games. She already likes my NC but thinks it's slow. Working on that will probably take precedence over the NC.

Anyway, good luck with the new kernel. I have been trying to get cm12 built for the NC. I readded mkimage which helped but I have a wpa problem now. But before that I need to figure out why the flo cm-12.0 builds are now broken. I just have too many tablets to play with.
[Nook Color Android Development] bowguy:
I just flashed the new kernel on 11/08 nightly. Everything working fine so far. I have a newer nook and haven't had an SOD in a long time.

I over clocked to 1200 and performance seems the same or a little better. It takes my nook about a day to settle down after a flash.

Edit: Saw comments by others but works well for me. Even ran ART for a day and was good performance just the usual lack of storage. Maybe a few so and so process has stopped but I like this kernel /w over clock better.
[Nook Color Android Development] hwong96:
New kernel runs fine with the 11/9 cm11. Set at 1.2 GHz.

Update:

Spoke too soon. Upon further testing, I get screen freezes, google play has stopped errors, errors 960 and 961 while downloading apps. In fact the screen froze while I was writing this update so I finished writing on my LG G3. Reverting back to CM11 11/09 nightly.
[Nook Color Android Development] fattire:
If anyone's interested in building cm-12.0-- I started and then got distracted and stopped again, but here are some quick observations...

* use the diff I posted earlier, but you also need to remove some of the reboot-menu items from values.xml (you'll get an error when you build so you'll know what to comment out)

* mkimage needs to be added to system/extras/ particularly this https://github.com/CyanogenMod/android_system_extras/commit/78e60c6ef72a7576e740553a74b30cfcc9e16d57

* don't forget to add vendor/bn

Anyway... I got a bluetooth error at a certain point and got sidetracked, but wanted to post in case anyone's taking the initiative to build themselves.