yashsingh1/xdaforums huggingface dataset:
[Nook Color Android Development] steven676:
A couple of new kernel branches

More details on the couple of new kernel branches in my tree:

The stable-3.0 branch is in effect a continuation of the kernel.org stable-3.0 series maintained by Greg Kroah-Hartman for several years and consists of backports from the currently-maintained kernel.org -stable trees; it's not device-specific (or even architecture-specific, though if you're not stuck on 3.0 because of your vendor kernel I'd strongly suggest moving to one of the upstream-maintained series) and should be suitable to merge into any 3.0.101-based device kernel. Going forward, I intend to take the most "important" patches from the kernel.org -stable kernels into the stable-3.0 branch; if you want to nominate a patch for this branch, please ensure it meets the criteria outlined in http://git.kernel.org/cgit/linux/ke...it/tree/Documentation/stable_kernel_rules.txt .

Meanwhile, the backports-arm-3.0 branch contains backported patches from past and present upstream ARM development which should improve performance and/or correctness; again, this tree is not device-specific and should be suitable to merge into any 3.0.101-based device kernel. It's going to be impossible to fully track the firehose that is upstream development, so if you see a patch you think might be useful, please bring it to my attention (for this branch, the stable kernel rules do not apply).

Both of these branches come from a desire to work in a more cross-device manner in the wake of the recent security hole debacle; hopefully, with time, this will be used by more devices (and hopefully maintainers for those devices will pitch in to help with maintenance!).
[Nook Color Android Development] pastordl:
From what I understand the problem is the app tries to use a player that our old Nooks don't "play" with. If you try the option #2 Workaround in the link for Netflix in my signature below it fools the app into believing its running on gingerbread, uses the old player and runs great.
[Nook Color Android Development] polymath257:
I may well be getting in over my head, but where could I start for any of these? For example, to look for the differences between the LGE P970 kernel and ours, should I download the other kernel? or is it more efficient to look at github? What should I do when/if I find a difference?

What is bisection and how is it i done? What is considered to be a 'fast' build box?

More importantly, are there good resources to learn this stuff?
[Nook Color Android Development] moocow1452:
It ain't the speed so much as it is tenacity, built Ubuntu Touch for the nook on a C7 chromebook, took a day, but it worked. Although putting down some cash for a premium cloud instance for a little while seems to be good as well if it you're in a hurry, but don't experiment if you are paying by the hour. Far as ports and builds, find devs, follow instructions, report what breaks, and repeat until you have enough of an idea of what to do to really break stuff.

^^ Strange. Netflix didn't work the first time i tried it, now it does. Had to ask in order to get it to work I guess.
[Nook Color Android Development] snives:
Bisection is splitting something in half. It is also a reference to a surgical procedure where you split a tissue (liver is a common example) in half to remove damaged/dangerous portions. A more accurate term is a resection, but bisection is used often even though it is technically wrong in most cases (not even portions = not in half = not technically a bisection). What Steven was refering to was removing the bad part of the code and leaving the good behind, which with a massive number of changes merged simultaneously is potentially very difficult and time consuming to due.
[Nook Color Android Development] polymath257:
Thank you. So, in this context, the merged code has to be cut in half, approximately, with part of it included in the build and the other part not? Seems not just time consuming, but risky: what basic units are kept together? How is this done in the context of repo and git?
[Nook Color Android Development] snives:
No more risky than merging a giant patch that broke things already. :p It's no more dangerous than you make it, which boils down to how much time gets put into development, test builds, and testing prior to final release.

And more clearly, in this context it would be the portion of the commit that broke things is removed and everything else is kept (like removing a cancerous tumor but leaving the head or taking off a Tap Out brand shirt ).
[Nook Color Android Development] polymath257:
OK, that makies a lot more sense than what I was envisioning. I have a couple of days of spring break left and would be happy to do what I can. What is the latest known good-commit? And what aspects of BT do you want tested each time? file transfer?
[Nook Color Android Development] steven676:
external/bluetooth/bluedroid: c36014295ac1e400664900be3eb26331f9f8d266

packages/apps/Bluetooth: f5fc3d7bf94581a06007913a3cf39476ee865c5c

If you want to work from the "first known bad" commits I marked instead of the current tip of those trees, I have those too, but be aware that those don't reflect the current state of play (which include a handful of fixes for the non-Bluetooth-LE cases):

external/bluetooth/bluedroid: f65bb9c4e8a55a33af5dd83cbc4de3954deba082

packages/apps/Bluetooth: 1872dee7d2cc869d4e0053ee2dd96237d75bfdd9

I also have trees which "flatten out" the merges and squash in build fixes for non-BLE devices to make it easier to bisect: https://github.com/steven676/android_external_bluetooth_bluedroid/tree/cm-11.0-btbisect and https://github.com/steven676/android_packages_apps_Bluetooth/tree/cm-11.0-btbisect. (The tips of those trees represent the "known bad" commits.)

You will also have to deal with changes to hardware/libhardware and frameworks/base to get the older variants of these repositories to build, but there are other unrelated changes intermingled as well -- it's probably easiest to look at the Bluetooth-specific code and revert the specific patches causing you problems, instead of trying to rewind those two repositories to a point matching whatever you're bisecting in the other repositories.

File transfer's an easy test, but if you have an HID or A2DP device to test I'd test those too.
[Nook Color Android Development] volpo222:
HI guys I just tried to use bluetooth on my NT to connect to my "Oontz" bluetooth speaker. It took a while but works well. You cannot really use the NT for anything else while streaming the audio, skips etc. but it works.

I'm using the cm-11-20140314-NIGHTLY and update almost daily. Never had a problem with any of the builds. Audio skips are attributed to low power (older) processor of the NT. There are some range issues as well but it works well enough if the devices are close by each other.

V
[Nook Color Android Development] polymath257:
One thing I have noticed: if I use the official snapshot CM and do a dirty flash over it with a build from steven's repo, the result will still do BT well. I am not quite sure what that means in terms of what is going wrong, though.

As for the bisecting, when I go to either directory (or both) and bisect, the result doesn't build at all. I'm not quite sure what strategy I should follow with this: how do I determine what needs to be fixed and fix it? Do I bisect on directory at a time? go back and forth in some way?
[Nook Color Android Development] fattire:
The "divide in half" method

Computer trivia: This is going back, but on Mac OS 8-9 circa 1999 or so there was a program called "Conflict Catcher" that used this method to suss out bad system extensions that may freeze the computer or whatever. You've got 50 extensions, and you think 1 of them is causing the problem. When you remove all the extensions in "safe mode" the computer runs fine... so you'd use the divide in half, try, divide in half again, try again... method to fairly quickly figure out which extension was giving you the problem.

[YOUTUBE]v3rhQc666Sg[/YOUTUBE]
[Nook Color Android Development] bowguy:
Going a little further, it is a simplified version of Newton's method that goes back to Babylonian times... :)
[Nook Color Android Development] derekr:
Actually it's the bisection method not Newton's method... Continually divide in half (bisect) to isolate.

Derek
[Nook Color Android Development] polymath257:
Let's work through an example to see the differences and see what bowguy was talking about.

Suppose we want to find the square root of 7. We can easily see that it is somewhere between 2 and 3. A strict bisection method would then test

(2+3)/2=2.5, find it is too small, and update the approximation interval to say that the square root is somewhere between 2.5 and 3. At the next stage, we test (2.5 +3)/2=2.75, find it is too large and the new interval will be from 2.5 to 2.75.

Newton's method is a bit more sophisticated. For extraction of square roots, it takes an approximation, say x, realizes the actual square root is between x and 7/x and bisects that interval to get the new approximation. So, if we start with an approximation of x=2, then the next approximation will be (2+ 7/2)/2=11/4=2.75. The next approximation would then be ( (11/4) +7/(11/4) )/2 =233/88=2.6477

To compare:

1. The strict bisection method is guranteed to work for a wide variety of problems. If you are selecting fome 'n' things in order, the expected number of iterations is about log_2 (n).

2. For extraction of square roots (or general solving an equation of the form f(x)=0 ), bisection takes a bit over 3 iterations for each decimal place desired.

3. Newton's method has a bisection in it, but it is not a strict bisection method.

4. For square roots, Newton's method approximately *doubles* the number of decimal place accuracy for each iteration. This makes it incredibly fast. But it doesn't work for searches.

5. For more general problems, Newton's method is not guaranteed to work, sometimes leading to interesting fractal behavior. But when it does work, it is very fast.

6. For more general problems (say, extracting cube roots), Newton's method is not a bisection method in any real sense.
[Nook Color Android Development] derekr:
This discussion is way off-topic because neither Newton nor bisection is really relevant to the suggestion by fattire, which really is a search strategy to find a guilty app.

This is neither the time nor place to get into a p***ing match over such a trivial definition, BUT Newton's (Newton-Raphson) method is not the same as bisection. Newton uses the local gradient (tangent line) to extrapolate a straight line to the next iteration in the search for the roots f(x) =0:

x(n+1) = x(n) - f(x(n))/f'(x(n))

Bisection does not need the derivative. It just bisects (halves) the interval each time and checks the signs to determine which sub-interval contains a root. All you can say is that both are iterative numerical methods, but they are not the same thing...

Let's quit while we're ahead and get back on-topic. I'm sorry I replied in the first place :)

Let me just say that CM11 has made my little old Nook Color into a real useful device once again. Many thanks to all the devs for all their efforts.

Derek
[Nook Color Android Development] douginoz:
Just in case devs haven't read the nightlies thread, the more recent versions of this ROM that have true hardware reporting are causing a few issues. The biggest seems to be that the device doesn't have GPS any more, so you can't install any apps that require GPS and some installed apps stop working. Most/all social networking apps expect GPS, and there are an increasing number of apps out there that use GPS for analytics reporting even though the main function of that app doesn't require GPS. In other words, there are an increasing number of apps that exist/require GPS, and without it, they simply don't show up in Google Play to install.

As a workaround for currently installed apps, 'Fakegps' allows them to run - but that only works for installed apps - you can't find or install apps from Google Play with this workaround.

Can some consideration be put into restoring the fake hardware reporting (at least the GPS capability)? While I admire the purity of having the NC report correctly, it is degrading the NC's usefulness significantly for those that use social networking apps, and over time, as the trend rises, less and less apps are going to run on the NC because of this missing capability.

Alternatively, if someone could identify the most recent old version of this ROM that still has fake hardware reporting, users can go back to that version and stay on it.
[Nook Color Android Development] steven676:
About updating the bootloader and early-boot sequence ...

All merged -- I'm assuming the lack of complaints means no one's had problems (which isn't always wise ...)

I'm thinking of merging this stuff soon -- comments?

Also, in an effort to try to increase test coverage, I'm going to attach the updated bootloader as a flashable ZIP here. (It should work fine with your existing eMMC and/or SD installs). 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).

If you're feeling curious after installing the new bootloader, look at /proc/cmdline -- you should now have an androidboot.bootdevice= argument there with the value reflecting whether you booted off eMMC or SD. Android's init should also have copied this value to the system property ro.boot.bootdevice.

Source: https://github.com/steven676/encore_cyanoboot/tree/54951a274d28f5d21f6fe9a951852264aab32172. 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:
Confirmed working on emmc installation of CM11.
[Nook Color Android Development] bowguy:
Also working on SD install but no entry for ro.boot.bootdevice at all.

My bad. That command returns SD

Thanks
[Nook Color Android Development] steven676:
To clarify: /proc/cmdline has the androidboot.bootdevice= entry, but "getprop ro.boot.bootdevice" doesn't return anything? (It's not going to show up in a file.)
[Nook Color Android Development] bowguy:
ALSA library prebuilt

Just randomly tracking down errors..

I am seeing this error in the logcat of a nightly build.

E/ALSALib ( 1292): external/alsa-lib/src/pcm/pcm_hw.c:1400:(_snd_pcm_hw_open) Invalid value for card

In trying to track this down, the file listed is not in the CM-11-0 tree but is part of a pre-built library.

https://github.com/steven676/androi...mmit/f9c92ae37f7644975b9953ef9c3c7baecc9d28ae

These don't really belong with the vendor blobs -- they're built from

source (and in fact, the copies being committed are built directly from

a CM 10.1 source tree -- they're prebuilt for now to avoid having to

re-add external/alsa-lib to the CyanogenMod project).

Does this need to be built again?
[Nook Color Android Development] steven676:
Merged this (and also pushed the corresponding bootloader source to NookieDevs). I'll push in the rest of the location-agnostic boot stuff in a few days, assuming the bootloader doesn't explode for people running nightlies and no one finds any show-stopping issues with the rest of it.

I've also modified the power HAL to disable KSM while the screen is off, which should hopefully improve battery life at idle marginally.

(As a side note, most of the remaining idle power consumption appears to be due to the packet-receive wakelock in the wireless drivers (rx_wake in the /proc/wakelocks statistics). Both the old pre-mac80211 wl1271 drivers and the Broadcom bcmdhd drivers used on other devices have a similar wakelock, but they aren't in use anywhere near as long; if someone wants to look at why that's the case, that would be an interesting project.)

The copies currently in the tree were built in January against cm-11.0, and should be fine:

https://github.com/CyanogenMod/andr...mmit/60fde85f51584178f00e2cbce1684441b9bb1e97

I think those particular errors are harmless, but if you want to interpret them, the error message gives you a file name and line number in the source to look at.
[Nook Color Android Development] steven676:
For those having trouble overclocking to 1.2 GHz on the 3.0 kernel ...

Does https://gist.github.com/steven676/10003175 help?

I went for a dive in the 2.6.32 source history tonight. (If you want a look at the results, try https://github.com/steven676/nook_kernel/commits/omapzoom+bn-kernel -- I identified what I think is the branch point for BN's kernel and rebased the BN kernel source on top of it, which should make seeing what changes BN made to its kernel easy.) I'm still combing through the results, but a couple of things jumped out at me right away that might be relevant to overclocking:

The highest MPU clock speed corresponds to a very low DSP clock (65 MHz). Presumably running both the MPU and the DSP at high clocks can exceed the power/thermal envelope.

For the OMAP3621, the L3 (memory) bus clocks are 83 and 166 MHz, instead of 100 and 200 MHz as on the OMAP3630. Lowering the L3 clock might help in reaching higher MPU clock speeds.

The patch I've posted makes the behavior of our 3.0 kernel match 2.6.32 on both these points; it's possible this might help you hit 1.2 GHz (or greater).

That said, I'm not convinced that either of these changes is a good idea in general. Clocking the DSP very low at the highest MPU OPP works only if the system is smart enough to select a lower MPU OPP when it needs to use the DSP (e.g. when decoding video). Meanwhile, clocking the L3 bus lower cuts memory bandwidth by 20% -- if you need to do that to gain an extra 9% in CPU clock speed, you're probably going to come out behind in the big picture.
[Nook Color Android Development] Arbelzapf:
Disabling KSM while the screen is off is a fantastic idea. The high battery usage when idle is the main reason I always turn it off on any device. Looking forward to the next nightly :)

With all your progress recently, I might need to get building on my own again, instead of waiting for prebuilt nightlies like a lazy bastard
[Nook Color Android Development] Mikessv:
Can anyone tell me if this build runs laggy? I have the official cm11 build installed and it runs slow.
[Nook Color Android Development] Mikessv:
Please delete this double post
[Nook Color Android Development] hwong96:
Did you clear cache?
[Nook Color Android Development] Mikessv:
Yes twice actually along with clearing data off twice. It just runs painfully slow. It's stable and runs okay but everything is extremely laggy.
[Nook Color Android Development] hwong96:
How much free ram do you have? Look in Settings, Apps, Running. Free ram shown on bottom.

Did you set your cpu to 1000 or 1100?
[Nook Color Android Development] Mikessv:
I have a 133 mb free and its set to 1100 right now.
[Nook Color Android Development] gravitysandwich:
Isn't this the developer thread? Anyways just clean flash the latest nightly (wipe system, data, cache, and dalvik cache.) Wipe Internal data/internal sdcard if you can. Also try different clock speeds, and mess around settings. But probably the reason is because this is 2010 hardware were dealing with. (800 MHz processor, 512mb of ram, in need of more partition space, crappy GPU...etc) so unless you bought the nook right when it came out for $200+ (like I did), you shouldn't be expecting much.
[Nook Color Android Development] polymath257:
Works on my eMMC install with repartitioned internal drive.
[Nook Color Android Development] Mikessv:
If you paid attention my original post asked if this build lagged, everything else was based on a question asked by someone else. I already did all those things nothing helped. It's why I asked
[Nook Color Android Development] polymath257:
Some aspects of Bluetooth

I have been playing a little bit with bluetooth and here are some observations. I don't quite know what they mean, but perhaps they can be helpful for someone.

1. I did a factory reset and installed cm-11-20140210-SNAPSHOT-M3-encore.zip from CM website.

2. I booted and attempted to start bluetooth from the settings menu. This failed: the slider went immediately back to 'off'.

3. I did another factory reset and installed a version I had compiled myself cm-11-20131215-UNOFFICIAL-encore.zip

4. Rebooted and again attempted to start bluetooth from settings menu: success

5. Did a file transfer from a phone: success

6. Did a dirty flash of cm-11-20140210-SNAPSHOT-M3-encore.zip -- no factory rest.

7. Rebooted and again attempted to start bluetooth from settings menu: success!

8. Did a file transfer from phone: success

9. Did a backup and then a factory reset.

10. Rebooted and again attempted to start bluetooth from settings menu: failed.

11. Did a restore of just the data partition from the backup

12. Rebooted and started bluetooth from settings menu: success.

So it appears that something in the data partition is missing in the SNAPSHOT version of CM. Evidently the new version of bluetooth fails to create something in the data partiton and that makes BT fail. But if that is provided from a previous version, BT is restored. I have not tracked down the specific file that is required for BT to work, but this will at least give a way to obtain BT with newer versions of CM.
[Nook Color Android Development] steven676:
Could you try this with a recent nightly (or a recent build) in place of CM-11.0-M3? Also, have you tried Bluetooth features other than file transfer? I have suspicions that more than one bug may be at work here, and that some of them (but not others) have been squished since M3.

Also, if you're looking for a file related to the Bluetooth stack in /data, there's a good chance it's in /data/misc (I'd start looking in /data/misc/bluetooth or /data/misc/bluedroid).
[Nook Color Android Development] polymath257:
I did a factory reset and installed cm-11-20140418-NIGHTLY-encore.zip.

I was able to get BT activated and a file transfer from my phone.

I do not have a BT speaker or keyboard or other such BT devices, so I cannot test such.

So it does appear that at least this bug was squished. :good:
[Nook Color Android Development] drmarble:
Some of the bluetooth problems could be a result of a (semi)recent merge (feb 26) that I used to get the Nook Color to compile. I didn't test that it let bluetooth continue to work for us. Look at the changes I made in:

http://review.cyanogenmod.org/#/c/60362/

You could also look in the external/bluetooth/bluedroid directory for BLE_INCLUDED. We don't include BLE and google expects us to. This could be causing the problems.

Sorry that I didn't test but I don't use bluetooth so I couldn't. I'm not sure that this is the problem but it is a good place to look. Just before that, lots of changes were commited to the cm bluedroid tree. We might need a more elegant solution to the build failure than the one I submitted. I just got our build working without breaking bluetooth for everyone else.
[Nook Color Android Development] drmarble:
Steven676:

I did a build using your oneboot branch. It builds and works great. I did have to add #62724 to bootable/recovery (since merged) to fix a build error. I haven't repartitioned anything before using it. Works just fine with a 1200 MHz kernel.

I am using your new one-boot-ish cwm recovery which works fine for my emmc install.

I wish they would merge your http://review.cyanogenmod.org/#/c/56882/ patch. It has no downside when I build for other devices that don't need it. Maybe I'll give it a bump.