yashsingh1/xdaforums huggingface dataset:
[Nook Color Android Development] bytte:
I take it that the following is not normal

logcat

[ 08-27 18:18:24.242 29002:29002 I/SurfaceFlinger ] SurfaceFlinger is starting

[ 08-27 18:18:24.242 29002:29002 I/SurfaceFlinger ] use dithering

[ 08-27 18:18:24.242 29002:29003 I/SurfaceFlinger ] SurfaceFlinger's main thread ready to run. Initializing graphics H/W...

[ 08-27 18:18:24.242 29002:29003 E/FramebufferNativeWindow ] couldn't open framebuffer HAL (No such device)

[ 08-27 18:18:24.242 29002:29003 E/SurfaceFlinger ] Display subsystem failed to initialize. check logs. exiting...

This repeated 150 times over 12 mins.

Any ideas what is wrong - I've been following Fattire's guide and last synced last Thursday.

This is my local_manifest:

<remote name = "gh"

fetch="git://github.com/" />

<remove-project name="CyanogenMod/android_hardware_ti_omap3" />

<remove-project name="CyanogenMod/android_hardware_ti_wlan" />

<project name="fat-tire/android_hardware_ti_wlan" path="hardware/ti/wlan" remote="gh" revision="jellybean" />

<project name="fat-tire/android_device_bn_encore" path="device/bn/encore" remote="gh" revision="jellybean" />

<project name="fat-tire/android_hardware_ti_omap3" path="hardware/ti/omap3" remote="gh" revision="jellybean" />

<project name="keyodi/ti-omap-encore-kernel3" path="kernel/bn/encore" remote="gh" revision="encore-omap3-3" />

Thanks
[Nook Color Android Development] riverzhou:
Your sgx vendor file and your kernel is now match.

check your libEGL_POWERVR_SGX530_125.so libGLESv1_CM_POWERVR_SGX530_125.so libGLESv2_POWERVR_SGX530_125.so version and your kernel pvr version.
[Nook Color Android Development] fattire:
What's Where In the CM10 Source?

Dunno if anyone's interested, but I ported the build instructions to the Nexus 7, and someone asked about what's in the directories in the source code. I posted a quick description of some of the more important ones that may be of interest...

What's Up With The Directories In the Android Source...
[Nook Color Android Development] riverzhou:
Finally, I find hwc.omap3 is no useful at all.

Omap3's dsscomp do not has full feature to support hwc .

In IT's hwc code , it also use sgx to render, as same as default hwc (eglSwapBuffers((EGLDisplay)dpy, (EGLSurface)sur)).

The main function of hwc.omap3 is mirror display, such as hdmi output.

So we can just use hwc.default in hardware/libhardware/modules/hwcomposer by adding hwcomposer.default to device.mk

In another way, I don't think hardware renderer is a good choice for omap3, software renderer should be better.
[Nook Color Android Development] biohazrd51:
Thanks much for the write up! I've spent a lot of time poking around in these files but my time available has me limited to when I can be at my desk. So this will help a ton.

I know you are really helping the community with all this. Have you thought about doing something like a weekly screencast to overview things with the android system (customization, porting, etc) or Q&A session?

Edit: Ustream. Couldn't remember the name of it :P
[Nook Color Android Development] bytte:
While trying to workout why my video doesn't work, I managed to checkout the charging issue.

Bottom line my CM10 kernel doesn't charge like it is meant to. I'm using a stock cable and charger together with a power monitor.

CM7 will currently charge at 10 watts (max is 13 watts when battery is drained).

CM10 currently charges at 4 watts.

Kernel messges are:

<4>MAX8903: USB_EVENT_VBUS: Charger=-1067812504

<4>MAX8903: Charging is now enabled!

<4>MAX8903: USB Charging at 500 mA

== more diags (added later)

<4>MAX8903: (tw16030) USB_EVENT_VBUS: Charger=-1067813592

<4>MAX8903: current_val 500 // on entry to max8903_charger_enable()

<4>MAX8903: Charging is now enabled!

<4>MAX8903: DC USB Charging at 500 mA

Keyodi - I've looked in your git repository and don't understand the origin of most of the code in max8903_charger.c committed on 30 Apr 2012 (I was expecting it to be based on the CM7max8903_charger.c ). Could you enlighten please?

The Charger = value passed in with the USB EVENT is 'rubbish' (see above)

As I see it, it is never going to charge at 1900mA.(because current_val = 500). What is the intended purpose of current_val?

---------- Post added at 06:02 PM ---------- Previous post was at 05:11 PM ----------

I don't know how to check the kernel pvr version (I don't have adb - but I could do a printk if I knew where to put it)

-rw-r--r-- 1 root root 35 Aug 28 17:44 egl.cfg

-rw-r--r-- 1 root root 8122 Aug 28 17:44 libEGL_POWERVR_SGX530_125.so

-rw-r--r-- 1 root root 109936 Aug 28 17:44 libGLES_android.so

-rw-r--r-- 1 root root 470275 Aug 28 17:44 libGLESv1_CM_POWERVR_SGX530_125.so

-rw-r--r-- 1 root root 358774 Aug 28 17:44 libGLESv2_POWERVR_SGX530_125.so

root@win2k3:/mnt2/lib/egl# cat egl.cfg

0 0 android

0 1 POWERVR_SGX530_125

FB diagnostics

<7>OMAPFB: omapfb_init

<7>OMAPFB: omapfb_probe

<7>OMAPFB: create 1 framebuffers

<7>OMAPFB: fb_infos allocated

<7>OMAPFB: allocating 8388608 bytes for fb 0

<4>mmc2: card claims to support voltages below the defined range. These will be ignored.

<4>mmc2: queuing unknown CIS tuple 0x91 (3 bytes)

<6>mmc2: new SDIO card at address 0001

<7>OMAPFB: allocated VRAM paddr 9ce00000, vaddr e2000000

<7>OMAPFB: region0 phys 9ce00000 virt e2000000 size=8388608

<7>OMAPFB: fbmems allocated

<7>OMAPFB: check_fb_var 0

<7>OMAPFB: max frame size 8388608, line size 4096

<7>OMAPFB: xres = 1024, yres = 600, vxres = 1024, vyres = 600

<7>OMAPFB: set_fb_fix

<7>OMAPFB: fb_infos initialized

<7>OMAPFB: framebuffers registered

<7>OMAPFB: apply_changes, fb 0, ovl 0

<7>OMAPFB: setup_overlay 0, posx 0, posy 0, outw 1024, outh 600

<7>OMAPFB: paddr 9ce00000, vaddr e2000000

<7>OMAPFB: create_framebuffers done

<6>cannot apply mgr(tv) on inactive device

<4>omapfb omapfb: --- failed to apply dispc config

<7>OMAPFB: mgr->apply'ed

<3>omapdss DSI error: Requested pixel clock not possible with the current OMAP2_DSS_MIN_FCK_PER_PCK setting. Turning the constraint off.

<7>OMAPFB: create sysfs for fbs

<7>OMAPFB: create sysfs for fbs

Suggestions on where to go next would be appreciated.

Thanks
[Nook Color Android Development] bitstra:
Hi bytte,

good shot to the charging issue!!!

So I went to the max8903_charger.c - file in /andbot/android/system/kernel/bn/encore/drivers/power/max8903_charger.c and

looked into code:

found in line 171 - this

if (current_val >= AC_CURRENT_LIMIT){

int dok = gpio_get_value(charger->max8903_gpio_chg_dok);

gpio_direction_output(charger->max8903_gpio_chg_usus, 0);

charger->adapter_online = 1;

charger->adapter_active = 1;

...}

this I changed to - this

if (current_val >= USB_CURRENT_LIMIT_HIGH)

than:

-removed /andbot/home/andbot/android/system/out/target/product/encore/kernel

-compiled the package without clobber...

-flashed the new ROM.zip

AND(!):

My NoName Wallcharger (1500 mA) with orig. b&n USB-cable is now recognised as AC charger - and charges as usual !

thanx for the direction to right cause, bytte!

@Keyodi (or who ever can make changes to github - I'm not familair with github for now, sorry),

would you check my change in the max8903_charger.c ?

It would be nice if you override this in .repo... - if all goes well (see Edit1 and Edit2 below

regards and thanx to all devs who make our nook colors uptodate.

bitstra

Edit1: saw a litle mistake in my changed code !!!

it would be better to use

if (current_val > USB_CURRENT_LIMIT_HIGH)

instead of

if (current_val >= USB_CURRENT_LIMIT_HIGH)

because plugging into usb port on my MAC means now, that the nook is connected to AC - that' not really good :)

testing the second shot now

Edit2: Nope - 2snd shot dosn't make it - charges with the AC-adapter as USB!

leave if (current_val >= USB_CURRENT_LIMIT_HIGH) for me...

BTW: who ever made the bootanimation(stargate like) - it looks and behaves grat :)
[Nook Color Android Development] bytte:
Please take care and test what you are doing in multiple situations, using printk to determine the effect before going live. The risk is that you can burnout the contacts on your Nook USB socket. Doing it to your NC is bad, doing it to lots of people's NC is very bad indeed. 1900 mA is more than can be handled by a standard USB cable. The code (dok, uok) should be checking whether a charger is supplying power (data pins shorted) and whether the extra pins are present in the BN Cable. So check that your solution works correctly with a non-BN cable (limit 500mA) as well as a BN cable. Also check when connected to a non-shorted supply (eg your computer). Your computer should only supply 500mA, and should protect itself, but if it doesn't the cost of getting this wrong could increases again. If your charger doesn't have shorted data pins, there was no easy way TIKO to distinguish a charger from a device on the end of the cable (may be that is what the new code was trying to do). I use an interactive app to raise the current when I know it is connected to a non-BN charger (which automatically cancels when the charger is disconnected).

[ @Bitstra Trying to draw 1900mA from your 1500mA charger might not be good for it either - overheat - over voltage ]

I didn't propose a solution because I didn't understand why the code is radically different from NC7 (BN 1.3). I have no knowledge of the hardware changes in in the new NCs. I was hoping @Keyodi could provide the background.

Sorry to sound so negative - I just don't want people doing this without out understanding the risks. This is one area where you really could brick your nook.
[Nook Color Android Development] bitstra:
Hi bytte,

you are right! This is no userland here!

So see my posting as a hint to break down the charging issue.

But: You interprete the code in case of current limits only from the point of view in software-/driver-programming. The electronical practice says:

if a charger delivers 1500 mA at maximum, then the the max charging current over the +/mass pins can't be more than this! Even if the driver for charging is awaiting more! This is the safe side of hardware-design :)

In the code there was asked if the charger can deliver more than the standard usb-charging current (500 mA). So my changed sample charges also with a 1000mA AC-charger and also with a 900 mA-charger. in all three cases the chargers were recognised as AC-chargers.

Not so with the original code... Even when the nook charging driver is awaiting the same current conditions.

I'm an electrician for more than thirty years. So I'm a man of practice. - My borderline for experimenting with my devices is laying more higher then normal, I know. But I know, what I'm doing...

Try to understand, that the result of my testsis, that changing code in kernel can let the nook recognise an AC-charger as what it is, in difference to the original code, where they seem to be a USB-port what is purely false...

So thank you for your comment - in understanding to beware other devs or testers on demaging their nooks :).

(sorry for my bad english - I'm a native german speaker)

regards

bitstra
[Nook Color Android Development] bytte:
So you will understand the potential issue of the micro-USB pins (rated at 1000 mA - from memory), and needing to check the presence of the BN cable which uses the additional pins wired in parallel to the power pins to share the 1900mA load, and the problem that could arise with a standard cable connected between a high power charger and the NC.
[Nook Color Android Development] cybertimber2007:
You guys seem to be on the right track for a fix, but why not compare CM7 & CM9 vs CM10? There might be some good hints there as far as charging goes.
[Nook Color Android Development] bytte:
Thanks for the advice :)

We pretty much know what is wrong. We don't know why it is wrong. The code in CM7 was good. The initial commit to CM9/10 excluded the charger code. In Apr @keyodi added charger code, but it is totally different to CM7. It has bugs. I wanted to know where it came from and was hoping @keyodi would advise. I don't have a new NC to test with (and don't know whether I need one). Options we have are trying to fixing the broken code / or using the CM7 code. I would really like to understand where the new code came from, and anyway we need @keyodi on side as it's his repository and I don't have commit privileges!
[Nook Color Android Development] keyodi:
I went a head and reverted the charger driver back to the one in the .32, but i had to also backport (or is it forward port) the twl4030-usb driver in order to get it to work. The changes are up, so give it a try.
[Nook Color Android Development] bitstra:
Thank you @keyodi,

charging is working correct now! AC charging with 900 mA, 1000 mA and 1500 mA tested (all NoNames)...

MTP works as it should. so thanx for all your work.

regards

bitstra
[Nook Color Android Development] bytte:
Thanks - the code looks good and it appears to be working correctly with stock cable and charger:

root@win2k3:/mnt3/adb# grep -i max8903 syslog-2012-08-30-07-41-13.txt

<4>max8903_charger_enable: dtct_status 0x00

<4>MAX8903: Charging is already disabled!

<4>max8903_charger_enable: dtct_status 0x00

<4>MAX8903: Charging is already disabled!

<4>max8903_charger_enable: dtct_status 0x00

<4>MAX8903: Charging is already disabled!

<4>max8903_charger_enable: dtct_status 0x08

<4>max8903_charger_enable: D+/D- shorted

<4>max8903_charger_enable: B&N WALL CHARGER(2A) Detected!

<4>MAX8903: Charging is now enabled!

<4>max8903_charger_enable: dtct_status 0x00

<4>MAX8903: Charging is now disabled!

root@win2k3:/mnt3/adb#

And the NC drew 10 watts!
[Nook Color Android Development] riverzhou:
Great Job!
[Nook Color Android Development] bytte:
@riverzhou. How do I check the kernel pvr version (I don't have adb working - I'm trying to fix video first)?

I'm not sure whether the "failed to apply dispc config" is relevant as I believe it refers to TV. LCD seems to be OK.

<5>Kernel command line: console=ttyO0,115200n8 rw init=/init videoout=omap24xxvout omap_vout_mod.video1_numbuffers=6 omap_vout_mod.vid1_static_vrfb_alloc=

y omap_vout_mod.video2_numbuffers=6 omap_vout_mod.vid2_static_vrfb_alloc=y omapfb.vram=0:8M no_console_suspend backlighttype=1476AY

<7>OMAPFB: omapfb_init

<7>OMAPFB: omapfb_probe

<7>OMAPFB: create 1 framebuffers

<7>OMAPFB: fb_infos allocated

<7>OMAPFB: allocating 8388608 bytes for fb 0

<4>mmc2: card claims to support voltages below the defined range. These will be ignored.

<4>mmc2: queuing unknown CIS tuple 0x91 (3 bytes)

<6>mmc2: new SDIO card at address 0001

<7>OMAPFB: allocated VRAM paddr 9ce00000, vaddr e2000000

<7>OMAPFB: region0 phys 9ce00000 virt e2000000 size=8388608

<7>OMAPFB: fbmems allocated

<7>OMAPFB: check_fb_var 0

<7>OMAPFB: max frame size 8388608, line size 4096

<7>OMAPFB: xres = 1024, yres = 600, vxres = 1024, vyres = 600

<7>OMAPFB: set_fb_fix

<7>OMAPFB: fb_infos initialized

<7>OMAPFB: framebuffers registered

<7>OMAPFB: apply_changes, fb 0, ovl 0

<7>OMAPFB: setup_overlay 0, posx 0, posy 0, outw 1024, outh 600

<7>OMAPFB: paddr 9ce00000, vaddr e2000000

<7>OMAPFB: create_framebuffers done

<4>omap_dss_mgr_apply(lcd)

<4>mgr->apply suceeded for lcd

<4>omap_dss_mgr_apply(tv)

<6>cannot apply mgr(tv) on inactive device

<4>mgr->apply failed for tv

<4>omapfb omapfb: --- failed to apply dispc config

<7>OMAPFB: mgr->apply'ed

<4>boxer_panel_enable

<3>omapdss DSI error: Requested pixel clock not possible with the current OMAP2_DSS_MIN_FCK_PER_PCK setting. Turning the constraint off.

<4>boxer_panel_enable - started OK

<4>omapfb_init_display - OK

<7>OMAPFB: create sysfs for fbs

<7>OMAPFB: create sysfs for fbs

-- update

The problem was that I had CM7.1 proprietary files whereas you must have CM9 files. Thanks to @kfxdadev and his post http://xdaforums.com/showthread.php?p=30907530#post30907530 for his help. The files are available from https://github.com/eyeballer/proprietary_vendor_bn/tree/ics/encore/proprietary.

I have also commented accordingly on @fattire's guide so hopefully no one else will suffer this pain.
[Nook Color Android Development] roger_n:
Hey guys I haven't visited this thread for 8 months since my CM9 days. I searched the OP for a link to fattire's CM10 guide and it doesn't exist can someone help me out with a link?

Thanks

Roger :cool:
[Nook Color Android Development] bytte:
https://github.com/fat-tire/android_device_bn_encore/wiki

Follow the link in the first para. Be sure to read all the comments - they contain important info (including those exposed by pressing 'comments' at the top of the screen)!

I'd be interested to know whether wifi works for you - I get "Failed to load driver!" - and have yet to track down the problem.
[Nook Color Android Development] krylon360:
PLEASE stop saying this.

This LM is incorrect. You are removing the omap3 source, and not replacing it with anything. Therefore, you aren't building in ANY OMX stuff.
[Nook Color Android Development] riverzhou:
It's WIP.

I use a different kernel source and different vendor files.

The kernel is based on steven676's dsscomp branch and vendor files is from lenovo a107.

The OMX is only working on soft mode now . But I will research it later.

It's just a different solution. It's easy to build , no much confuse things. And it work well, faster and smooth.

It there only one solution on the world ?
[Nook Color Android Development] roger_n:
Thanks for the info and tips I let you know the status of my wifi after my build completes.

Roger
[Nook Color Android Development] eyeballer:
The problem is, it confuses people because you keep posting different repos to build from. We're trying to all work from one manifest so when people post build errors or other bug reports we know *exactly* what they're using and how to help debug them. You're also posting an incomplete manifest so it's really not going to help people.

We are not trying to discourage you from helping, in fact we'd welcome any suggestions you have, but please work on our common tree (fork fattire's device and make your changes).
[Nook Color Android Development] roger_n:
I've been away from this thread for over 8 months and starting to re-build for my nook. Is this the correct manifest to use for CM10?

http://pastebin.com/vZFKdc8m

Thanks Roger:cool:
[Nook Color Android Development] bytte:
It matches the one I am using.
[Nook Color Android Development] Divine_Madcat:
On this note - please keep all dev talk in this thread related to the same branch. You are welcomed to start a new thread for a different build (as is the common thing to do on XDA), especially as it avoids confusion.

Any further posts not related to the main branch will be removed to again, avoid confusion.
[Nook Color Android Development] krylon360:
For those wondering about the CM9 status. I started working my changes into that last night. Will build tonight to test them. These should Hardware Decoding working on CM9, and I will also be back-porting the HWA Hack we patched in for JB. This will get HWA working on ICS.

That's about all the issues we had. Doing the HWA Hack "should" let us use OpenGL without any hangs/lockups. :)

Dont worry, still working on CM10.

I just wanted to get CM9 completed. Right now everything is set up for CM9.1 (remotely merged in the CM base last night)

Once I confirm everything is working, I'll shoot Eyeballer a link to the base, so he can do a test build for the NC and Touchpad to make sure everything still works
[Nook Color Android Development] met67:
Will this eventually lead to a CM9.1 release? (OC I'm not asking an ETA :) )
[Nook Color Android Development] cybertimber2007:
Now if I'm correct (and I'm also forseeing someone else asking this 1000x times)... hardware decoding and such is what held back the 'official' CM9 encore release correct? Once tested by Eyeballer, merged into CM based and all approved, we should see a CM9.1 encore release from CM?

I wonder if we have some time to fix a bug with Cyanoboot first.
[Nook Color Android Development] krylon360:
What bug with cyanoboot. Works fine for me.
[Nook Color Android Development] cybertimber2007:
I posted it in the relevant thread ;)
[Nook Color Android Development] roger_n:
@bytte I finally got a chance to install my 0831 build and to answer your question yes my wifi worked out of the box no issues.

EDIT: I didn't have to boot into recovery and back as someone recommended a few pages back it just worked.

Roger:cool:
[Nook Color Android Development] bytte:
WiFi is now working for me. Seems that having reinstalled vendor files from @eyeballer's git, it is essential to do a make clean.
[Nook Color Android Development] lekofraggle:
AC

Hey all, I thought I would try another build over the weekend now that I survived the openning of school (using Paranoid cm9 to get me through).

First, thank you all, this is becoming much more stable. I enjoy all of the changes a lot.

I did notice on first boot, that my charging still had the same issues (when plugged in, it seemed to be charging as usb), but I decided to plug right into the wall (bypassing the power strip), and the nook recognized AC charging perfectly.

So, even though Paranoid likes my power strip, on cm10, I needed to go to the wall to get AC charging.

This is not completely abnormal. I have seen other devices do this.

I do not have any ideas as to how to fix this yet, nor am I asking anyone else too, I just wanted to share for those of you who still may be having issues.

Great work everyone.

~Leko
[Nook Color Android Development] bytte:
Syslog Stack Trace from WIFI Failure after WakeUp

In case you don't have one, here is a syslog (from boot) including wifi failing to wakeup. Interestingly there is an IRQ error first, but it doesn't contain any obvious clue as to the cause.

http://pastebin.com/TWPDczXj
[Nook Color Android Development] bytte:
WIFI Data Errors

Seems there could be an issue with wifi error checking.

I'm using @fattire's wifi.

About half (of a small number) of app downloaded reported failed CRC.

I ran a test of downloading 2 copies of gapps - both failed MD5. There were a small number of single bit errors in 87 MB.:

root@win2k3:/mnt4/Download# cmp -l /home/nigel/downloads/gapps-jb-20120726-signed.zip gapps-jb-20120726-signed.zip

3618857 210 212

7727359 334 335

48135879 16 17

54780759 276 277

root@win2k3:/mnt4/Download# cmp -l /home/nigel/downloads/gapps-jb-20120726-signed.zip gapps-jb-20120726-signed-1.zip

1691934 125 127

12597911 230 231

19536502 75 77

19572598 361 363

22548319 66 67

22681438 351 353

27029398 20 22

49154326 101 103

59408862 75 77

60148191 22 23

63447878 361 363

81336678 271 273

I have downloaded the same file twice with my laptop (from the same wifi AP) without issue.

If you wish, I will run the same test using CM7.1 to verify that it not a hardware fault.
[Nook Color Android Development] bytte:
AC

Are you saying that plugging your charger into your power strip doesn't work, or do you have some form of USB charging strip?

If the former, try again - there is no way the charger or the NC should be affected by the charger power source. ( It won't charge until it is booted / booting)
[Nook Color Android Development] krylon360:
are you getting gapps from goo.im/gapps?
[Nook Color Android Development] bytte:
Gapps

Yes, why do you ask?

I actually pulled it 3 times on to the NC. The first time I used it to install which failed during install, and got deleted so I was unable to verify what was wrong. The copy downloaded to my PC passed MD5 and installed fine.
[Nook Color Android Development] krylon360:
because I have yet to have any download issues with wifi.

could be a sign you chip is giving out. Keyodi's nook is hosed due to his chip dying.