yashsingh1/xdaforums huggingface dataset:
[Nook Color Android Development] KnowledgeBroker:
See, to you that may not sound amazing, but even getting that much functionality out of a totally unsupported device that has no 3.0 source blows me away..

Trust me, I have a total respect for how fattire not only has handled things, but he has gotten other people to work at a level of professionalism I've yet to see anywhere else on XDA.. and I am no fan of bounties - I just know we have an awesome device that has been plagued by either immature developers(in the past), or a lack of development.. but just like the nook, the device has so much potential I'm doing everything I can to make sure it rocks like my nook has!

I'll stop posting my non-sense in the thread.. thanks to fattire and others for taking the time to reply :)
[Nook Color Android Development] fattire:
The problem with bounties is that they encourage people to work in secret- to avoid collaboration, etc. No one wants to be 99% of the way there, perfecting some last detail then have some yahoo swoop in with their not-polished code to claim a bounty when they didn't do anything at all. So suddenly, the second a bounty is announced, all the repositories go closed and everyone is reluctant to talk to anyone else. A single team focused on solving issues can fracture into 5 teams. And any lone ninja-level developer dropping by who might easily be able to fix an issue doesn't even know what the issues are.

Bounties are a terrible idea, and those who have tried the bounty incentive have ended up delaying what would have been a release months earlier.

I guess if for some reason you want to delay or stop a project, a huge bounty might work, but otherwise it's not useful IMO.
[Nook Color Android Development] krylon360:
I can def confirm the issues that fattire has stated. Touch is VERY sluggish. I'm surprised I haven't broke my screen yet. lol.

I may have figured out wifi though. gotta rebuild to test that out. Had to fix some stuff in the kernel source and device tree just to get it to build the 1st time.
[Nook Color Android Development] bcvictory:
Sorry to bug you but any release on AOKP?
[Nook Color Android Development] krylon360:
I know there's a lot of people waiting on it, and I can give you guys a test build, but thats all it is...a test build. I already know what bugs are in it, and I'm working them off.

http://dl.dropbox.com/u/9978865/aokp_encore-ota-eng.krylon.zip
[Nook Color Android Development] speedfreak007:
Wow, do you have a working 3.x kernel? What kind of improvements can that bring to the nook? (HW acceleration? or do we need to wait for updated drivers from TI?)
[Nook Color Android Development] krylon360:
that link is not a 3.x kernel. Ive got a build with 3.x but it's buggy! and thats an understatement.

I've talked with TI about merging in the open gerrit requests that would fix a lot of the bugs (HD, Flash, video decoding) but they came back with a canned response telling me to talk to B&N about it.

TI took out all of the OMAP_ENHANCEMENT flags out of the ICS framework and replaced them with Samsung and QCOM flags. So everything has to be ported over for OMAP3 Enhancements.
[Nook Color Android Development] speedfreak007:
That's a bummer, i was given hope by the posts about a month ago about TI developing omap3 ICS support. So we shouldn't hope for any hw acceleration soon?
[Nook Color Android Development] afzalarsalan:
Well I created a petition for our device if that helps.
[Nook Color Android Development] Dj-Gutz:
It will defiantly be quite soon ( although I predicted it would be in march :\ )

- Lenovo A1 is getting ready for OTA - Let's hope they'll release their sources soon , probably with their adjustments cuz afaik h/w acceleration is solid there

- I9003 devs soon will start working on a 3.4 kernel with UART - Maybe they will get there before any official release :)

- TI will review & get everything straight up eventually , if you look at omapzoon gerrit you will find a-whole-lot of commits submitted waiting to be reviewed - a lot of them are related to h/w acceleration - I asked fattire a while back to try to compile with those being reviewed commits but I guess he probably already tried that and it didn't bare fruit :\

- Hell , Defy devs might surprise with a 2.6.32 back-ported full h/w acceleration

Almost any release of 3.x kernel omap3 device will help us , It's only a matter of time till someone manage to get this thing straighten out - we will just have to wait a little bit longer :)
[Nook Color Android Development] fattire:
A place for kernel chat...

Moved the 3.0 kernel discussion to its own thread.
[Nook Color Android Development] fattire:
So for fun I did a fresh build using:

The 3.0 kernel (in progress)

The not-yet-committed linaro patches

ondemand

1000 top

The UI not-responding to touches issue still exists (as expected). This is a really screwy thing that could easily affect the results, so I invite you to try this yourself.

Anyway, 1384 & 1323 quadrant scores, which doesn't represent a significant increase or anything.

Your mileage may vary... and it is quadrant, which isn't too reliable. Maybe I missed a flag or something. I dunno. Just sayin'.

Update: Also tried the linero bionic string changes here.

Quadrant: 1524 & 1500

I do feel like the graphics were going faster, but it's subjective so I can't be sure... I wonder if this is done on an already overclocked 2.6.32 how fast it could get.

On performance governor:

Quadrant: 1653 & 1598

Hmm. that's not terrible. I invite you to try yourself in case I screwed something up. Again, this test really should be done w/the 2.6.32 kernel, not this weird 3.0 one. Although skitz tried it with cm7 and it bootlooped, so i'm guessing ics only.

Here's a prebuilt lib to try at your own risk-- Again, don't assume I did anything right here:

linerolibc.zip

Update: eyeballer noticed the bionic changes are now in an easy-to-try cm commit
[Nook Color Android Development] twa_priv:
Hey fattire,

Try replacing /system/lib/libjpeg.so with one of a working build. This fixed the netd issue for me.
[Nook Color Android Development] twa_priv:
To fix your build do that - add the following to your local_manifest.xml (or change default.xml):

<remote fetch="git://git.linaro.org/" name="linaro" />
<remove-project name="CyanogenMod/android_external_jpeg" />
<project path="external/jpeg" name="people/tomgall/libjpeg-turbo/libjpeg-turbo" remote="linaro" revision="android" />

Worked like a charm for me:)
[Nook Color Android Development] fattire:
Heheh Yeah I figured it out last night thanks to strace :)

Will try using linaro's tho..

Another tip:

If you want your kernel modules to load, add this to the section that builds them in BoardConfig.mk:

EXTRA_CFLAGS=-fno-pic.

This lets them load, but they're still not exactly working for me (yet).

E/wpa_supplicant( 1374): Could not read interface wlan0 flags: No such device

everyone else seeing the same thing?

Update: I'm an idiot-- I forgot that device/ti/proprietary-open/wl1271-nvs_127x.bin needed to be renamed to wl1271-nvs.bin .. I have wifi again. Incidentally, I noticed that there was a new 512-friendly sgx binary posted 3 hours ago... if someone is so inclined to try it.

Quadrant scores (multiple runs)

gov performance: 1409, 1372

gov interactive: 1200

Dunno. Keep in mind this still has the "sensitivity" issue...
[Nook Color Android Development] fattire:
Gcc 4.7 & cm

FWIW Cyanogen chimed in and I can't say I disagree, given some issues i've had with -O3 optimizations.

I guess it can't hurt to check the minor changes into the 3.0 kernel that let it build with 4.7 just in case anyone wants to do it, but I think it might be a good idea to let upstream deal with the bulk of this- if eyeballer or whoever wants to incorporate the frameworks/base & bionic fixes, he can. Although I'm guessing AOSP will probably adopt them as well, if not CM9 proper.

For what it's worth, I'm really not seeing the advertised doubling of performance really, at least not in omap3 w/the 3.0 kernel. Your mileage may vary, however. I will say that at least in quadrant (which is suspect always), the fps for stuff that had been 20fps seemed to jump to 30fps, but I dunno.

So for now I'm going to consider this 3-4 day linaro experiment over. I posted patches for 2.6.32 to build. I think maybe 3.0 too but if not, I'll do so in the 3.0 thread. But I think I did... damn I should check.
[Nook Color Android Development] meteorrock:
Still working on recovery audio.

Still working on the audio recovery sideproject. Here is the latest link up in TI.

Basically he is telling us to go **** ourselves. Will keep reposting unless you are up and going with it on ICS 3.0

Here is the link on this. http://e2e.ti.com/support/data_converters/audio_converters/f/64/t/196942.aspx

Here is his love note.

Hi Jerry, ( Jerry is my *ahem* troll name :) )

At this point in time, we have only ever integrated this driver onto OMAP4-based platforms. I'm afraid you're going to have to learn about how an ALSA ASoC driver works if you are keen on making your project work. You need to make modifications to the machine and platform drivers, as well as any other changes related to differing kernel versions, in order to be able to use the package you have. Start with a working audio driver for your platform (for the OMAP3621 that should be the twl4030 driver unless I'm mistaken), learn how it works and replace the codec portion alone (stuff under sound/soc/codecs) from the package you have.

Regards,

hari

~~~~~~~~~~~~

LOL that other bro from here is spamming him too. Great job guys. :)
[Nook Color Android Development] fattire:
Okay thanks, that's actually helpful info... but let's go easy on the TI people, shall we? No need to hound them really. Let's see how far we can get with this info before bothering 'em again...

:)
[Nook Color Android Development] Dj-Gutz:
REALLY OT :

Yeah not related to us directly but woot woot :D

Change Ie591b96d: SGX-BIN: DDK update

0d7410c PVR-UM/KM: Support [B]Jellybean[/B] build
f269b1f PVR-UM: Make pvrsrvinit wrapper compatible with [B]Jellybean[/B]
[Nook Color Android Development] Dj-Gutz:
@keyodi/fattire/krylon...

Have you seen this?

Locked Motorola Devices Get Full Hardware Acceleration!

[ICS] CM9 Android 4.0.4 for the Defy (Froyo kernel)

Epsylon3/tpruvot (Tanguy Pruvot) - https://github.com/tpruvot

New SGX Stack loader, thanks again to nadlabak

Small fixes to build the new SGX 1.8 (ES5.x) kernel module

hwui: Add support for a local folder with process names black list

Defy(+) HWA Black List
[Nook Color Android Development] fattire:
So yeah, the defy has a module now in .32 that enables omx and video. If we can get that in before 3.0 is ready, that may be a great workaround.

Keyodi says he has sound working as well in 3.0 now!

And krylon built jellybean.. and I'm working on cm10 and will have stuff pushed to the new "jellybean" and "jellybean-3.0" branches.

Dalingrin renamed the thread to include CM10 so please continue to post userspace (not 3.0 kernel) stuff here. The kernel thread is for the 3.0 stuff.

But ICS or JB stuff can go here..
[Nook Color Android Development] fattire:
A slow start...

So haven't finished the build exactly as lots of stuff are broken and being fixed currently, but I gotta leave for a few hours so I checked in some changes that may help build jellybean on the "jellybean" branch for anyone who's trying. This assumes the .32 kernel and the cm10 repo.

Anyone building at the moment should expect to run into numerous issues until things settle down.

Some quick notes for building (that probably by the time you read this will be OUTDATED).

at the time I built it I had some errors unless I added frameworks/base/data/sounds from ics-- probably some cm specific things that aren't in yet.

you'll need to add lzo from ics' external/lzo folder until it gets added by cyanogenmod .. then make sure it gets built.

you'll need to add some LOCAL_MODULE_TAGS := optional to Makefile.mk in /hardware/ti/*** or.. breakage

you'll need to move android/ics/build/armelf.x to the jellybean equivalent or... you guessed it

probably will need to move the vendor/bn/encore stuff as well.

Anytime you get an error about LOGE or WLOG or something, you can just replace it with ALOGE or AWLOG, respectively. You may have this in /system/netd or maybe some of the cyanogen-specific projects.

looks like some xml file are missing in frameworks/base/data/etc/ -- I just copied them over from ics to keep the build happy. Any other xml files missing? just copy 'em in from ics.

I rm -rf /external/openvpn due to some error I didn't want to deal with.

had to replace jellybean's external/busybox with one from ics since I dind't want to bother debugging it :)

that's it for now gotta run
[Nook Color Android Development] krylon360:
Found out a little bit ago that there is a change needed in bionic that allows jb busybox to build. Sorry I had to run earlier. Wife and daughter wanted some family time. I need to test the new kernel with init changes I did before I had to go. Right now my nook is sitting downstairs in recovery. Lol.

For the uim stuff, I just replaced the one in wap with the one in our dev tree. Had to change loge to aloge in the .h .

I'll let you know how things go tomorrow. I hope the omx stuff that defy did can port over to 3.0 or even better if we can get 3.4 working.

For the xml's, they are all located in frameworks/native/data/etc. So the device.mk will need to be changed to reflect that.

The live wallpaper XML is in the normal location.

Super user doesn't like the normal copy pre built command or whatever, guess it needs to use BUILD_PREBUILT now. This goes for all pre built apks. CM may have fixed this though.

My version of jb I built is pure aosp with minor cm changes for releasetools and inline kernel building.

Still some stuff that needs fixed though since I boot to a backlit black screen. Device is seen in adb, but my serial number has changed. Its now 1234567890ABCDE. LOGCAT dies after it starts to read the log.
[Nook Color Android Development] fattire:
brief update...

A bunch of the stuff is being fixed upstream by arcee as I type this... so hopefully by tomorrow we'll have something at least we can look at. If we can add that .32 module to it and have OMX too, well, that would be nifty...
[Nook Color Android Development] fattire:
Okay so the build finishes now and I get an update.zip, which when I flash, I get the excitement of a crash. And until I get a microUSB cable, I can't really test it...

-rw-rw-r-- 1 fattire fattire 145093675 Jul 11 10:26 cm-10-20120711-UNOFFICIAL-encore.zip

(the file is actually called cm-9 still but I renamed to make it easier to find on sdcard for flashing etc.)

krylon?

I'll push the changes to the build script so that the build finishes in a few moments.

Updated. Pushed build change so it should now get to the end.
[Nook Color Android Development] krylon360:
On it.

10char
[Nook Color Android Development] fattire:
Progress? Not sure.

Update---

something is very wrong with bionic.

Replacing libc.so from ics -> /system/lib/ gets it a little further.

a lot of this stack corruption detected stuff still.
[Nook Color Android Development] fattire:
good tidings

Good news comin'. :good: :good: :good: :good:
[Nook Color Android Development] krylon360:
Yes, very very good things
[Nook Color Android Development] Divine_Madcat:
You teases......

BRING THE RAIN!

:D
[Nook Color Android Development] ziggy34:
I know, not nice to tease the natives.
[Nook Color Android Development] krylon360:
Changes needed for Bionic to work:

https://gist.github.com/e7e69d9d6992627674ab

These changes are needed or libc fails to boot and causes errors during the init process.

Changes needed for the hardware/ti/omap3 source that pulls with AOSP/CM

https://gist.github.com/3101529

Without these, your build will fail.

Also see below in fattire's post for the wlan stuff that needs changed.

you will also need to pull the latest jellybean repo from fattire's git. It has needed changed for sensors and lights. for now, we are using the ICS prebuilts for it to boot.

You will also need to grab keyodi's kernel source from:

https://github.com/keyodi/nook_kernel.git

branch ics-kernel

You can just use

git clone https://github.com/keyodi/nook_kernel.git -b ics-kernel

and copy the contents into kernel/bn/encore (these will need to be created in your android source dir)

Download this file:

http://git.omapzoom.org/?p=platform...h;hb=6e0e0ab232787d14e4fbd2a75052e96f8abb3c40

save as omap_hwc.h in the following location:

$ANDROID_SRC_DIR/bionic/libc/kernel/common/video/

Download this file:

http://git.omapzoom.org/?p=platform...h;hb=1039041567227e8e580bd0de47a0f0ee74694d71

and save as omapfb.h in the following location:

$ANDROID_SRC_DIR/bionic/libc/kernel/common/linux/
[Nook Color Android Development] fattire:
Note that you MUST build the kernel..

Also: you'll get breakage unless you apply these changes to hardware/ti/wlan
[Nook Color Android Development] Divine_Madcat:
I don't totally know whats going on, but i love seeing big news and JB stuff going on. :D
[Nook Color Android Development] krylon360:
Thanks, I had most of them done; the optional tags tat is from my AOSP build, which is prob why I didnt have breakage.

added in the changes for osapi.c and will test wifi in a while.

hehe
[Nook Color Android Development] fattire:
Posted from jb!
[Nook Color Android Development] fattire:
Pics

Some pics.. The resolution is way way too high still... gotta fix that and a million other things.

I do notice a more responsive feeling. no sound yet or anything. Notice how the keyboard is smaller than the actual tablet... this resulted me having to guess where the "actual" keys were...
[Nook Color Android Development] krylon360:
finally gets JB booted, 1st thing he does....posts on xda. lol
[Nook Color Android Development] fattire:
Pics

I think I posted the pix 2x... whoops. I'll post some different ones here or something if anyone wants 'em.

(see above I posted a few more)
[Nook Color Android Development] freonchill:
not to sound ungrateful, but id rather you focus on the bugs than spend time posting pics.

we can see it ourselves when you have it working enough to release.

excellent work all
[Nook Color Android Development] fattire:
Two more, above in the first pic post.

I'm taking a break now :)
[Nook Color Android Development] krylon360:
Yeah, after all the debugging we did yesterday and today, definitely taking a break also. Need to submit my bionic changes to cm and Google for that matter.
[Nook Color Android Development] fattire:
For sho'. Gotta make sure the libc stuff doesn't hurt anyone. And why isn't TI getting this stuff in there?! :)

Thanks also to deeper-blue and sluo for helping think that libc issue through. Also thanks to eyeballer and skitz too.

the UI is very, very fast. Swiping between screens of apps is pretty quick. At least as fast as CM7 was. The stability, not as much. And no sound. And this is the .32 kernel, so no video until nemith or whomever gets that module working.

I'll fool w/it more. But actually at this screen density it's not so bad really. We need to get the back, home, etc buttons in tho.
[Nook Color Android Development] krylon360:
That's a good question why ti isn't pushing the changes. Its obvious from my aosp build that they are needed for omap3 to boot.
[Nook Color Android Development] steven676:
Audio

(This is recapping a lot of rambling I did on IRC in a more easily readable format -- I apologize if you've already seen this.)

So I went diving into the audio stack, thinking I could use some of the knowledge gained looking at Jelly Bean audio for crespo ... boy, is there a labryinth of abstraction layers involved!

So far as I can tell, device/bn/encore/audio_hal produces an alsa.encore.so (or an alsa.omap3.so, doesn't really matter). That module is used by the ALSA abstraction layer in hardware/alsa_sound, which produces a libaudio.so which isn't quite a proper legacy audio HAL module, but implements most of the interface. That's then linked by the makefile in hardware/cm/audio with the (static) libaudiohw_legacy.a from hardware/libhardware_legacy/audio and a bunch of dependencies (but no actual code contained in hardware/cm!) to create an audio.primary.encore.so.

(*deep breath*) Assuming that the foregoing analysis is correct, the audio.primary.encore.so produced by your build should implement the correct HAL API for Jelly Bean. (That said, depending on what branch of hardware/alsa_sound is being pulled in ... libaudio.so might not be being built at the moment, since the ics branch is set up to only produce output for Qualcomm platforms. Presumably that would screw up the production of audio.primary.encore.so in hardware/cm, since that needs to link against libaudio.so. I don't believe the legacy API has actually changed between Gingerbread and ICS, so I bet the gingerbread branch of hardware/alsa_sound builds and works fine.)

That leaves the audio policy component. Jelly Bean has a completely new audio policy setup too, but this one's much easier to deal with: audio_policy.default.so is built from platform/hardware/libhardware_legacy/audio, and the default implementation gets all its information from /system/etc/audio_policy.conf. Diving back into the labryinth suggests that audio policy information for ICS is currently mostly contained in the stuff that builds alsa.encore.so ... so working from that, the crespo audio_policy.conf, and a bit of common sense, I got this: https://gist.github.com/3103399

The upshot of all this is: once you manage to get an audio.primary.encore.so built from a Jelly Bean-based tree, you just need to drop that into /system/lib/hw (along with audio_policy.default.so, which should already be there) and then copy the audio_policy.conf to /system/etc to get working sound.
[Nook Color Android Development] fattire:
For anyone interested in building yourself.

For anyone trying to build cm10-- here are the changes I made-- each of these diffs can be "git apply"ed in their respective repository. There are only three that changed from the current cm10 repository:

the changes

Also, I foundI needed to use the prebuilt kernel, not the one that get builts in the build process. We have to figure out what that's about.

Also, jellybean seems to eat memory. Might be a good idea to kill the boot animation or replace it with something small.
[Nook Color Android Development] deeper-blue:
I made some progress... see attached screenshot :)
[Nook Color Android Development] steven676:
Tools for debugging the memory issues

One of the most convenient features of the standard Linux "top" utility (part of the procps package, which you can get from http://procps.sourceforge.net/ or from https://gitorious.org/procps) is the ability to sort the output by various criteria, including memory size. Sadly, the standard Android top and the Busybox top lack this feature, which I figure should be helpful in debugging the out-of-memory problems on encore, so I've built a statically linked version of the procps top which should work on ARM Android devices (actually any ARM running Linux).

Binary: procps-top.zip is attached to this post. Unpack this anywhere on your ROM. You'll get two files, the "top" wrapper script which you should run, and the actual "top.real" binary. Once you're running top, you can e.g. sort the output by memory usage (resident set size, to be precise) from high to low by pressing "O" (capital O, the case is important), then "n" and Enter. Check the docs for lots of other cool things you can do -- the procps top is a very powerful utility. (Press "q" to quit.)

Source: procps-3.2.8-build_static_for_android.tar.bz2 (attached to this post); source is GPLv2+. You will need a GNU/Linux ARM toolchain and a static ncurses library with support for termcap fallback enabled. Edit build.sh to fit your local build environment, then run it to build the procps tool suite. A copy of the wrapper script is included in the source tarball as top.wrapper. (For the very curious, this is procps 3.2.8-9squeeze1 from Debian stable, with some changes to the Makefiles to get a working statically linked build.)