yashsingh1/xdaforums huggingface dataset:
[Nook HD, HD+ Android Development] fitzy73:
So installed, but have a few issues.

I downloaed the latest TWRP from Flashify, rebooted to it, and updated to the latest TWRP. All good.

Fact reset device using TWRP, and installed ROM + Banks GAPPS. Room booted, but no GApps! The Play store is there, but just flashes up and then disappears when I try to load.

Ok, I thought, maybe I don't flash it properly, so I'll reflash.. Enabled defeloper mode, advanded reboot, and tried to reboot to recovery.

But nothing happened. Just rebooted to ROM.

I've sideloaded Flashify, but no matter what recovery I use (CWM, TWRP, CM Recovery) I can't get it to reboot into recovery.

Not sure what I can do from here! Any help greatly appreciated.
[Nook HD, HD+ Android Development] dbrickg:
Not sure, but I think that's a well-known issue. You should be able to get to recovery by powering on while holding both the power nook keys. You have to release them at just the right time, and it always takes me a couple tries. If you don't hold them long enough, it just reboots to the OS, and if you hold them too long, it just powers off.
[Nook HD, HD+ Android Development] TBueno:
I release power button when "cyanoboot" flash splash screen comes up, it usually works right away for me.
[Nook HD, HD+ Android Development] dbrickg:
Thanks! That's perfect. I knew it was something like that. But I always panic at the last -- and most crucial -- moment :)
[Nook HD, HD+ Android Development] fitzy73:
Thanks. I'm assuming that's the power + N button?
[Nook HD, HD+ Android Development] dbrickg:
Yup, that'd be the ones
[Nook HD, HD+ Android Development] sephiroth2k:
How would I disable zRAM? Swapoff /dev/block/zram0?
[Nook HD, HD+ Android Development] swaaye:
Trickster Mod app can do it.
[Nook HD, HD+ Android Development] twiztid_:
It's been a few days of using it and 8/29 doesn't feel like it has the same high level of fluidity of 8/16 and 8/19. I don't mean its slow by any means, it's still faster than anything prior to the 8/16 build, but I can notice the drop in performance in the transitions/loading in Hearthstone. I don't think the battery feels any less hot, but I really haven't felt it was an issue in the past.

Do what you will with this information, and keep up the great work. As always, thanks! :DD

Edit: I've also noticed that the game disconnects a lot more frequently now, before if my screen went off I would have about a minute to turn it back on and be fine. Now it disconnects me even if I turn the screen off manually. Previous versions (5.0, and I think early 5.1, or everything pre-5.1.1 maybe?) did the same, but it had been "fixed" for a long while now.
[Nook HD, HD+ Android Development] sephiroth2k:
When I use trickster the switch just flips back on when I toggle it, and cat /proc/swaps still shows /dev/block/zram0 .
[Nook HD, HD+ Android Development] swaaye:
I think I've seen that. But it usually works for me. I've verified swap is disabled at the terminal.

I'm not much of a believer in ZRAM. It have not noticed any benefit, certainly not in multitasking.
[Nook HD, HD+ Android Development] amaces:
Can you try the boot-hummingbird-mpu.img in experimental, and report the output of grep -r . /sys/devices/system/cpu/cpu0/cpufreq/? P.S. Did official CM11 have 1.5 GHz enabled, or you meant an older custom build by verygreen?

As you discovered yourself, VPN is finicky in CM12, and until recently, in AOSP Lollipop as well. A few months ago, my IPSec profile wouldn't even connect on either CM12, or stock LP. Now, I see that native IPSec/PSK connects on both, but only works properly on my stock N5. If you can switch to PPTP (simplest), L2TP, or IPSec, can you test the native VPN stack? Sounds like both endpoints are under your control, so you should check if native fails as well. In the meantime, I'll look through my logs; it does sound like routing with VPN is somehow broken…

You could run swapoff /dev/block/zram0 in a shell, then check that swap is zero with free. Or, make it stick across reboots with this /data/local/userinit.sh:

#!/system/bin/sh

swapoff /dev/block/zram0
echo 1 > /sys/block/zram0/reset

That's odd since there were no changes that would impact fluidity after 08/19 (a few happened just after 08/16). You're talking about gaming though, so OpenGL stuff. I will reenable some of the larger cache settings before 08/19; memory may suffer a bit, but gaming will benefit, and the HW composer should still be OK.

P.S. What do you mean by disconnects? There was a massive rush over the past couple of weeks, to finish what they call CM12.1 stable (YOG4P), so it's possible regressions sneaked in.

Big problem right here: official TWRP doesn't (yet) support CM12 builds after August 19th, so the recovery image that Flashify downloaded for you is not very useful with these builds. Not sure which build you flashed, but it'll definitely spit out errors with the current ZIPs (see recent posts about these changes imposed by upstream CM12). Anyway, you should download my TWRP builds (tagged >=2.8.7.3), and either flash them as ZIPs in another recovery, or extract the raw recovery.img, and follow the rescue instructions in the OP.
[Nook HD, HD+ Android Development] twiztid_:
Given the game requires an online connection to the Blizzard servers, I would guess that the recent build(s) are more aggressive with closing connections when the screen goes off/in the background. Though I don't think I've had a problem with other things like TeamViewer, or ES File Manager, but that could be better resuming, or not needing to be always-connected, on their parts.

Edit: II used your userinit.sh script to disable ZRAM, was kind of curious to see what it would do, and I have had the smoothest experience in my game ever. Still not sure on the specifics of ZRAM and such, but so far I'm happy without it.

Edit2: I tried removing the script to make sure it wasn't just because I rebooted, I had rebooted two days ago but just wanted to be sure, and the lag and lockups were back. Put the script back in, and lag was all but gone, just some slight slowdowns at the end of a match.

Not sure if this helps to explain things, but it fixes my speed/smoothness issue.
[Nook HD, HD+ Android Development] sephiroth2k:
I've experimented with zram extensively with the Evita, mild gains in multitasking aren't worth the performance hit in my experience. I'll check the methods for disabling suggested when I get back home. Thanks!
[Nook HD, HD+ Android Development] snoozer854:
Got everything working using the twrp that Flashify flashed which is v 2.8,7.0, but what is the best way now to flash the newer version from the op?

Do I just flash it when in recovery?

Thank you your help is greatly appreciated

Mark
[Nook HD, HD+ Android Development] swaaye:
It is a verygreen build. In his CM11 thread there is a list of his early builds and the Hummingbird build runs at 1500 MHz. Specifically:

cm-11-20140117-UNOFFICIAL-hummingbird-emmc.zip

It looks like you've successfully achieved 1500 MHz. No problems so far.

u0_a65@hummingbird:/ $ grep -r . /sys/devices/system/cpu/cpu0/cpufreq
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq:396800
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq:1500000
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency:300000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq:396800
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq:1500000
/sys/devices/system/cpu/cpu0/cpufreq/affected_cpus:0 1
/sys/devices/system/cpu/cpu0/cpufreq/related_cpus:0 1
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:interactive
/sys/devices/system/cpu/cpu0/cpufreq/scaling_driver:omap2plus
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors:conservative ondemand powersave interactive performance
/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed:<unsupported>
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies:396800 800000 1100000 1300000 1500000
grep: /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq: Permission denied
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq:800000
/sys/devices/system/cpu/cpu0/cpufreq/stats/total_trans:385
/sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state:396800 5040
/sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state:800000 3225
/sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state:1100000 433
/sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state:1300000 194
/sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state:1500000 4891
/sys/devices/system/cpu/cpu0/cpufreq/stats/trans_table: From : To
/sys/devices/system/cpu/cpu0/cpufreq/stats/trans_table: : 396800 800000 1100000 1300000 1500000
/sys/devices/system/cpu/cpu0/cpufreq/stats/trans_table: 396800: 0 130 0 0 10
/sys/devices/system/cpu/cpu0/cpufreq/stats/trans_table: 800000: 127 0 26 0 3
/sys/devices/system/cpu/cpu0/cpufreq/stats/trans_table: 1100000: 4 9 0 18 3
/sys/devices/system/cpu/cpu0/cpufreq/stats/trans_table: 1300000: 0 7 2 0 15
/sys/devices/system/cpu/cpu0/cpufreq/stats/trans_table: 1500000: 9 10 6 6 0
u0_a65@hummingbird:/ $
[Nook HD, HD+ Android Development] mmnspeed:
Yes,flash it from twrp...
[Nook HD, HD+ Android Development] Shadowpain:
Has anyone experimented with trickster mod ?

What are some recommended tweaks ?
[Nook HD, HD+ Android Development] swaaye:
My home router has OpenVPN and PPTP servers so I have now tried PPTP as you suggested. It doesn't work either. The VPN connects but there is no connectivity once the VPN finishes negotiating. Not to the internet nor to the home LAN.
[Nook HD, HD+ Android Development] amaces:
We actually have have a pretty good zRAM driver, and was surprised about sudden issues given that nothing had been changed till this weekend. Anyway, this was incentive to look at things again. Some of the device settings (mainly swappiness) were tuned for the second zRAM iteration a few months back, but we gained a new version, plus a few other features (i.e., zcache/frontswap). With these latter features, swappiness can be brought back to 10, so much less memory gets swapped through zRAM under normal conditions. I think the new builds are a better compromise, where launcher or Chrome don't get killed as often. Obviously, to test these changes, you'd need to remove your modifications (e.g., rename userinit.sh, disable whatever persistent tweaks, etc). I'm the opposite of a gamer, so zRAM will remain enabled by default, but you can easily disable it if these changes are still not sufficient.

Yeah, but I still haven't found a good way to keep default at 1.3 GHz, so regular hummingbird builds are not overclocked. I looked through the code, and this max frequency is not chosen arbitrarily; it checks the type of silicon to decide whether 1.5 GHz is enabled. So, although both chips are 4470s, there must be some sort of binning involved, and although it works OK on your device, it may be unstable on other HDs… For now, I will keep an overclocked kernel in experimental, which you can install on top of regular ROMs, should you feel that it makes a noticeable difference on your device.

I feared that, and did more testing by checking every kernel requirement (we already had everything necessary enabled), but still no luck flowing data with the VPN connection. CM12.1 just went stable, so we should find out soon enough whether it's a purely upstream problem (hopefully, since AOSP works fine), or there's something weird in our kernel/device trees (less likely, since the connection does happen).
[Nook HD, HD+ Android Development] twiztid_:
For a while there wasn't a problem with having the zRAM on. And maybe it wasn't as fast as it is in the 8/29 with zRAM off, but that could also be due to improvements since 8/16. Does your 9/06 build have the zRAM fixes/tweaks/tuning? I'd love to try it and report back if I get the smoothness with zRAM enabled.
[Nook HD, HD+ Android Development] belfastraven:
[MENTION=4473900]amaces[/MENTION],

am running 9/06 humminbird with 1.5G experimental kernel. All is good for me. Niotice that the read-ahead-buffer is back to 512. Is that part of ZRAM changes?

I do believe that boot to recovery problems with Enforcing are probably caused by a race condition. i.e. getting the permission to write necessary code to register and actual writing to register is not completed before reboot command looks for it. There is no denial involved-- In permissive, it make just be writing before check is completed.

Do these problems happen on other OMAP4470 devices with our types of eMMC?

Thanks again.
[Nook HD, HD+ Android Development] amaces:
Yep, those are the new builds ;)

Not part of zRAM, but goes hand in hand with the block scheduler changes; ROW is not made default kernel-wide anymore, but only on mmcblk0 (eMMC) for now (regular CFQ on the SD card, OTG, etc).

Yeah, and it's frustrating with the current debug information… No idea about the interplay with the MMC driver, but will keep working on it; current builds are permissive till we solve this issue.
[Nook HD, HD+ Android Development] sephiroth2k:
Running 9/6 with zram enabled and it's very smooth, thanks for your hard work!:D
[Nook HD, HD+ Android Development] twiztid_:
The Good:

Feels just as fast with zRAM, maybe slightly slower but I'd need benchmarking tools to say for sure.. It felt a little sluggish on first boot after install, but a reboot and its feeling fine.

Battery seems a a lot cooler when not charging, but see The Bad.

The Bad:

Battery feels hotter while charging, but not as hot as it had been in the past. Overall not bad.

Battery got SUPER hot during install while charging. I got a bit scared, but it cooled down quickly.

Initial boot and optimizing(?) Apps took abnormally long, next boot was fine.

The Ugly:

Yo mama. Oooooooooooooooooooo! Just kidding, thanks as always [MENTION=4473900]amaces[/MENTION] :D
[Nook HD, HD+ Android Development] TBueno:
My subjective impressions on ovation-0809 so far:

Despite the focus on (Z)RAM, I've noticed an improvement in responsiveness: apps draw quicker, and animations apparently skip less frames (i.e. GNL apps drawer opening). But I have a tendency to suffer from placebo effect, so it might be just me

RAM still is still the main bottleneck: cold starting Chrome and coming straight to this forum made Spotify stop playing in seconds. Falling back to home screen required a launcher redraw, predictably

First boot and apps optimization took just as long as before

Did not notice changes in battery temperature, but I usually don't deal with heavy tasks

Not 0809-specific: it's a privilege to have CM's latest improvements ported in "real time" to this device. Audio quality has been shining in CM12.1, and the new equalizer is awesome. File manager is getting better and better, and the new app icons on toast notifications are a nice touch.

As always, thanks a lot AMaces!:good:
[Nook HD, HD+ Android Development] amaces:
This time it's not placebo ;) I did make more than casual changes to how SurfaceFlinger interacts with the kernel, plus a bit of house keeping in the device tress, etc. About zRAM/swappiness/LMK, I'm still making improvements. One major issue is that our low memory killer is uncoupled from zRAM, and did not account at all for the swapped memory needs. When memory was low/critical, zRAM would need to expand a little bit, yet LMK didn't know about that, so the whole system would more or less freeze until the issue was solved. I notice they're accounting for this in modern kernels, and I found changes that more or less backport this logic to our ancient kernel. These improvements, together with more efficient KSM scanning (turned on as well), are contained in the experimental kernels. Things need more time to settle after reboot though.

You shouldn't charge while pushing the CPU, especially during the lengthy initial optimization step. This is a good rule for all embedded devices with Li-ion batteries, and heat dissipation issues. You're barely charging the battery, but doing so at much higher temperature; charging/discharging at hight temperatures is very bad for these batteries (especially the former). The battery controller may compensate for the perceived slow charging (while the CPU is ramped up), by pushing the charging circuit, thus generating significantly more heat. I have not experienced any unusual charging issues, but will look into it if other people report similar problems. Also, didn't notice a longer optimization step, but I also didn't pay much attention to it. I usually make sure the device is charged enough, place it against a fan, and check on it after about ten minutes.

I am however, experimenting with pre-optimized ROMs, which supposedly reduce this initial downtime substantially. The downside is that ROM size goes back to 220 MB (that is, LZMA compressed), and /system loses about 100 MB of free space. Shouldn't be a problem, except for folks who stuff all the free space with GApps and whatnot.
[Nook HD, HD+ Android Development] belfastraven:
Experimental 9/08 very quick and smooth on humminbird, even shortly after boot. Mine rarely freezes, usually while NYTimes app. I'll see how many days I can go without a soft reboot.
[Nook HD, HD+ Android Development] TBueno:
Great work! It's amazing to see a device from 2012 behave like this while pushing FHD+ graphics!

About RAM: now that you mention it, I've used several 1GB devices without so many redraws and background kills, and I'd blame screen resolution for it happening on the ovation. If these changes bring HD+'s multitasking performance closer to other 1GB devices, it'll be fantastic, and well worth some extra after-reboot waiting. Can we simply flash the experimental kernel on top of 0809 and see how it goes?

Also, thanks on the tip on charging and flashing/optimizing, that's good to know.
[Nook HD, HD+ Android Development] swaaye:
[MENTION=4473900]amaces[/MENTION] the Hummingbird 1500 MHz kernel is working well. Thank you for looking into the overclock. :)

I have a question though. Why do we not implement a hotplugging governor? Is it not a powersaving benefit? Are there problems with them that I'm not aware of?
[Nook HD, HD+ Android Development] games906:
so great to see a device with cm12.1 updates a lot! How do i go about using F2FS filing system? Benefits? I'd probably lose all data, right?
[Nook HD, HD+ Android Development] swaaye:
Reformat the system, cache and data partitions within TWRP. I'm not sure if it's tangibly faster however. Yes all data will be wiped.
[Nook HD, HD+ Android Development] king200:
Assumes the rom you have installed supports f2fs.

You don't have to lose all your data.

Summary: 1) TWRP backup and rename file extensions of data and cache files ext4 to f2fs. 2) internal storage backup 3) Change file system of data and cache to f2f2. 4) Restore data and internal storage. You can use PC but can also do it all within TWRP.

I did it this way. Backup with TWRP onto external microcard. Use file manager in TWRP to copy the folder, for sdcard to the MicroCard. Change the file extension name for the Cache and Data files in TWRP backup from ext4 to f2fs.

Wipe->Advanced->repair/change, change each of the data partitions to f2fs.

back to TWRP file manager, copy each of the files/folders in the sdcard folder to the internal drive. (I don't know how to copy the entire internal sdcard folder directly to the internal card).

Restore the cache and data from the TWRP backup.

Congratulations, you converted to f2fs.
[Nook HD, HD+ Android Development] robak1965:
Using 9/06 build and also still using the enforcing kernal with no issues.

Yet another data point [MENTION=4473900]amaces[/MENTION] . I have never had, and still no issue exiting or booting to recovery, and I have both HD and HD+ models.

With all the chip versions, some more buggy than others, I think you may be chasing a red herring in trying to get a one build fits all. I realize it's frustrating for a few select users. I sure do appreciate your effort though.

My HD has eMMC chip MAG4FB

My HD+ has eMMC chip MBG4GA
[Nook HD, HD+ Android Development] w1ll1m:
Can you Link to the kernel please?

Cheers
[Nook HD, HD+ Android Development] swaaye:
It's in his shared box (first post) in the experimental folder.
[Nook HD, HD+ Android Development] twiztid_:
9/06 is locking up on me after a bit... Mostly ingame, fine until it needs to load something then it locks up completely, and occasionally chrome (chromium) locks up too a bit. I tried the experimental kernel, and it helped a little, in the game mostly, but it still happens.

Both after install of 9/06 and the experimental kernel the device was fine, but as time went on got worse. Which is the opposite of what I would expect since you mentioned the device needs time to "settle" (my phone is the same way).

I'm going to try going back to 8/19 and seeing if there's an improvement. I can't get 8/19 to install, keeps giving me a com.android.phone error. Wiped system each time, and did it with and without installing gapps...
[Nook HD, HD+ Android Development] amaces:
The problem is that we have closer to 780 MB available… Lacking a modern contiguous memory allocator, the massive carveouts required by coprocessors, Ducati, etc, steal more than 20% of all available memory. So we occupy a special middle ground, between true low RAM, and 1 GB-class devices. My Nexus 7 (2012) has 1 GB of RAM and a newer kernel (3.1), and it's horribly slow, way more frustrating, despite having to push less than half of the ovation pixels… The very latest experimental kernels are better than in the last full builds, and should work on top of any (talking about ZIPped kernels, which contain the additional modules matching the raw boot image).

Do you mean CPU hotplugging, as in onlining/offlining different cores? That would make a difference if we had more cores; the two that we have are already underpowered, and the most we could do is offline one core when idle, which doesn't happen a lot during active use. Switching cores on and off, moving tasks between CPUs is very expensive, and that overhead doesn't make sense on our devices. Also, deep sleep works pretty well with both cores idling in the lowest power state (look at the battery graphs).

Governors (performance, porwersave, etc) are a different thing, and you can switch between them freely, should you decide interactive doesn't work well for you. I have not found a compelling reason to switch from default interactive; the current philosophy is ramping up fast to quickly finish whatever task in order to return to lower power states asap. P.S. Yes, there is a governor called hotplug, somewhat similar to ondemand, and that's the only one not compiled into the kernel since it requires some deeper support, and it's not worth it on OMAP4, for the above reasons.

I wish I could dismiss it so easily, and just enable Enforcing regardless, but it causes issues on more than a few select devices… No biggie though, all the SELinux plumbing is done, and ready for use; not even sure if Enforcing is truly a requirement for CM nightlies, and have yet to hear about enabling upstream builds.

Yeah, I also noticed the freezing after a bit of use, and that's why I've been working on tuning the kernel. In the rush to get the weekend builds out, I guess there wasn't enough proper testing, but I think the very latest kernels in experimental will work better overall. They should work with any build, but ideally test on top of the latest ROM.
[Nook HD, HD+ Android Development] swaaye:
Yeah that's what I was referring to. So it's not worthwhile. Makes sense. Thanks for enlightening me. :)
[Nook HD, HD+ Android Development] mattyyey:
Help... I think I may have bricked it somehow?? dont wana double post... but please take a look...

http://xdaforums.com/showpost.php?p=62760650&postcount=1378