THIS IS NO LONGER NEEDED AS IT HAS BEEN INCORPORATED INTO THE CMSOURCE. USING KERNELS IN THIS THREAD WILL MOST LIKELY DOWNGRADE YOUR KERNEL UNLESS YOU ARE STILL RUNNING ONE OF THE EARLY TEST BUILDS OF 5.0.8.
IF YOU ARE LOOKING FOR THE NEWER OVERCLOCKED KERNELS TRY HERE...
kernel corner
This is a boot.img with an experimental kernel which enables multitasking for those that have some form of swap enabled on cm-5.0.7. This is probably not the best way to achieve the results, but it does work. If someone has a better way of doing this feel free to post it or whatnot.
I myself was becoming frustrated with webpages having to reload everytime I answered a text or did something else. Not to mention Gmote restarting a show if I came back to it after backgrounding it for similar reasons. So I did this...
The patch:
Code:
diff --git a/drivers/staging/android/lowmemorykiller.c b/drivers/staging/android/lowmemorykiller.c
index 50d5f91..7e083f5 100644
--- a/drivers/staging/android/lowmemorykiller.c
+++ b/drivers/staging/android/lowmemorykiller.c
@@ -90,7 +90,7 @@ static int lowmem_shrink(int nr_to_scan, gfp_t gfp_mask)
int selected_oom_adj;
int array_size = ARRAY_SIZE(lowmem_adj);
int other_free = global_page_state(NR_FREE_PAGES);
- int other_file = global_page_state(NR_ACTIVE_FILE) + global_page_state(NR_INACTIVE_FILE);
+ int other_file = global_page_state(NR_ACTIVE_FILE) + global_page_state(NR_INACTIVE_FILE) + 1536;
/*
* If we already have a death outstanding, then
The value was obtained experimentally. Too High of a value caused kernel panics when having a lot of apps backgrounded and switching between them. Too low caused webpage refreshes when switching between a few apps. 1536 seems to allow moderate multitasking without causing the kernel panics. If too many apps are backgrounded then they will still need to be refreshed when reopened.
I have tested this with a basic linux swap partition as well as with compcache w/ backing swap. It does not work however if no swapping technique is employed.
The overclocked version was originally posted in the overclock thread. This one is the same as the second one I posted. Figured some people don't like overclocking so I made a non overclocked one as well. Of course just use fastboot to apply. If your not comfortable flashing random boot.imgs then you should definitely not flash this.
Without overclocking:
cm-5.0.7-ds-mt-boot.img (you don't want this)
koush's anykernel update zip format
cm-2.6.33.4-mt.zip (you want version 7)
With overclocking (as usual this doesn't boot without advanced tweaking):
oc825-5.0.7-ds-mt-test2-boot.img (nope not this one either)
koush's anykernel update zip format
oc825-cm-2.6.33.4-mt.zip (nor this one)
VERSION 7: (this would be the one you want)
This is the overclocked version with farmatito's patch (as per post #131).
for cm-5.0.7-stable/cm-5.0.8-test1
oc825-cm-2.6.33.4-mt-v7-signed.zip remember this boots at 825mhz so set your desired frequency/settings in your userinit.sh or init files if you want it to boot.
cm-2.6.33.34-mt-v7-signed.zip (this the kernel from farmatito's boot.img from post #131 repacked into an anykernel so it can be used in either/any rom)
A non overclocked boot.img is available here(cm-5.0.7-stable only).
for cm-5.0.8-test2
oc825-cm-2.6.34-mt-v7-signed.zip
cm-2.6.34-mt-v7-signed.zip
And the diff on this version is...
Code:
diff --git a/drivers/staging/android/lowmemorykiller.c b/drivers/staging/android/lowmemorykiller.c
index 50d5f91..8cfbb6e 100644
--- a/drivers/staging/android/lowmemorykiller.c
+++ b/drivers/staging/android/lowmemorykiller.c
@@ -35,6 +35,8 @@
#include <linux/oom.h>
#include <linux/sched.h>
#include <linux/notifier.h>
+#include <linux/swap.h>
+
static uint32_t lowmem_debug_level = 2;
static int lowmem_adj[6] = {
@@ -82,6 +84,7 @@ static int lowmem_shrink(int nr_to_scan, gfp_t gfp_mask)
{
struct task_struct *p;
struct task_struct *selected = NULL;
+ struct sysinfo si;
int rem = 0;
int tasksize;
int i;
@@ -91,6 +94,9 @@ static int lowmem_shrink(int nr_to_scan, gfp_t gfp_mask)
int array_size = ARRAY_SIZE(lowmem_adj);
int other_free = global_page_state(NR_FREE_PAGES);
int other_file = global_page_state(NR_ACTIVE_FILE) + global_page_state(NR_INACTIVE_FILE);
+ si_swapinfo(&si);
+ lowmem_print(3, "OF %ld FREESWPAGES %ld NEWOF %ld\n", other_free, si.freeswap, other_free + si.freeswap);
+ other_free+=si.freeswap;
/*
* If we already have a death outstanding, then
Much thanks to everybody and all who helped, most notably farmatito, phhussen, and cyanogen.
nice! i've wanted this for a while.
Time to go back to CM now!
Hi.
Just flashed Kernel w/OC on my Vodafone Magic(aka MT3G 32B) with CM 5.0.7.
Now Wifi is broken and won´t start.
If you could fix this, it would be great. Seems to run very smooth with 256MB Swap.
seems interesting, will wait for better improvements,
zerocoolriddler said:
Hi.
Just flashed Kernel w/OC on my Vodafone Magic(aka MT3G 32B) with CM 5.0.7.
Now Wifi is broken and won´t start.
If you could fix this, it would be great. Seems to run very smooth with 256MB Swap.
Click to expand...
Click to collapse
I added some packed in koush's anykernel update script. These will give you the modules as well.
Perfectly working now. Thanks
all I gotta say is... WOW, eclair overall is running much better. Right now im using CaNNoN's mod'd CM5 rom with a class 4 sd @ 96 mb swap via FireRat's patch, running at 480/576 overclock, getting a steady 2.5 mflops and everything is much more responsive and less loading time. I am very happy since everyime before this the browser reloaded. I think mod's to improve multitasking should get priority.
dumfuq is your oc kernel uv? I saw in the nexus forum that they have further undervolted the kernel to save even more battery life
Waiting for input from pershoot, Cyanogen or zinx before I flash this
xaueious said:
Waiting for input from pershoot, Cyanogen or zinx before I flash this
Click to expand...
Click to collapse
I'm waiting for my mommy to tell me everything's ok before I do anything.
About where should swappiness be set for this to be optimum? I really only want background apps to fall into the swap, and not system processes.
haha, I was thinking the same thing when I saw that, you beat me to it.
* I got another idea for a possible spare parts mod: the Ability to lock selected app's in memory, like the dialer, messaging, and home screen because sometimes you recieve a message or call within the browser or a memory intensive app and you miss a call because of the loading time
alongenemylines said:
About where should swappiness be set for this to be optimum? I really only want background apps to fall into the swap, and not system processes.
Click to expand...
Click to collapse
im set at the default 60, I think 20-60 is a good amount, mess around with the settings until you find an optimal setting
overground said:
I'm waiting for my mommy to tell me everything's ok before I do anything.
Click to expand...
Click to collapse
Or instead of asking your Mom about everything, you could look at lowmemorykiller.c and tell me further effects this has on the memory system. Because I don't know AOSP well enough to get at it.
I haven't been on Github much, but there were issues with lowmemorykiller.c before and it's kind of a finicky ***** from what I understand. So I am a little cautious here.
Swap implementation is supposedly screwed up a little on CM5 as well.
But there are people who are going to flash this thing regardless of the effects.
Thanks dumfuq! This makes CM5 multi-task significantly better. So far, no problems to report. Totally digging of the changes, stock CM5 was starting to bug me with it's single-task bias. Obviously you have to kill tasks so you don't get so many the swap thrashes, but I'd like to keep a few around.
xaueious said:
Or instead of asking your Mom about everything, you could look at lowmemorykiller.c and tell me further effects this has on the memory system. Because I don't know AOSP well enough to get at it.
I haven't been on Github much, but there were issues with lowmemorykiller.c before and it's kind of a finicky ***** from what I understand. So I am a little cautious here.
Swap implementation is supposedly screwed up a little on CM5 as well.
But there are people who are going to flash this thing regardless of the effects.
Click to expand...
Click to collapse
Good sport. Thanks for playing. Dumfuq can tell you all that...My G1's kinda been retired into the hands of my momm....I mean my girlfriend.
one thing that people dont think about is that if we get better memory usage the cpu wont need to constantly reload apps into memory therefore saving battery life. Lets see if we can further improve memory usage since it is the biggest recurring issue within android devices
Some tips for speed w/this, use CaNNoN's or SuperE, apply dumfuq's kernel, enjoy, this brought back life to my g1, it flies
so far, with keeping default swappiness, this is working excellent! chompSMS, facebook, dolphin browser, etc etc almost instantly come back to exactly where i last left them.
good job on this dumfuq!
alongenemylines said:
so far, with keeping default swappiness, this is working excellent! chompSMS, facebook, dolphin browser, etc etc almost instantly come back to exactly where i last left them.
good job on this dumfuq!
Click to expand...
Click to collapse
I agree Thanks dude
will give it a shot...
Finally i can run now 4-3 app same time
but i am stilling waiting for cyan to fix this......
thanks man
Related
I shared my user.conf a while back with the guys on the xROM thread. I got really positive feedback from them so I decided to share it in a few other threads. JAC is included a lot of my ideas in xROM 1.4 and is going to include more in 1.5 It has grown and become more popular so I decided to start a thread at the request of a few people who use my config.
I didn't think it deserved the space until now to make a thread so I never started one. I'm not trying to make this thread all about me. I've said more than once, I would love for someone to come up with a config that is better than mine because I will be the first one to use it. I just don't want to keep derailing other conversations in other threads anymore. And while I appreciate all of the emails that I get, I think a separate thread will be an easier place to discuss this and help people out.
So I will start by posting giving a general outline of how I came up with my settings. If you want to give me feedback, I appreciate it. Even if you have emailed me in the past or posted something on one of the threads I would appreciate a post in this thread. If only the people who have problems post here I won't know how many people it is helping or not.
That is only part of the thread though. If you have a configuration that you have seriously tested and you want other people to try it, post your method and how to set it up and let's see what we can come up with. Please don't just post random configs hoping someone else will test them for you. I don't want the thread to turn into a confusing mess that doesn't help anyone. My goal is to have this thread spawn some new ideas that will make everyone's phone faster. If you've done your homework and you think you have something good, let's share it. I never thought that my config would be used by so many people. I was just trying to make my phone faster. Maybe you can do better.
Testing Method:
I generally use two apps to benchmark the performance of my phone. They are Benchmark Pi and Benchmark. Both are available on the market. I use Benchmark Pi for a rough comparison because it is faster and focuses mostly on how fast the CPU is running. When I get down to fine tuning I use Benchmark. It takes longer to run but it measure graphics, CPU, memory, and filesystem performance. For Benchmark Pi I usually will run it 10 times and use the average response. With Benchmark I set it to run each bench 5 times each and it automatically averages the values. Then I export that to a csv file and compare them that way.
I think I am a pretty heavy user of my phone so I took what I normally use and added a little bit to it. Here is what I used:
- All testing was done on xROM
- Over 120 apps installed
- 5 home screens
- 18 widgest and 8 shortcuts to apps (I can post specifics if anyone cares)
- I run the phone until it is definitely swapping. I play music, open large web pages, run CPU intesive apps, etc.
- ask me if you want more details
I use Advanced Task Manager, which I highly recommend, to keep an eye on what is running and kill any apps that are not being used by me or my desktop. I try to simulate heavy usage of my phone with only the things running that should be. I also use cat /proc/swaps, free, and sh /system/bin/swap -s (sh /system/sd/userinit.sh -s for othe ROMs).
I started out comparing Compcache and Linux Swap since those are the biggest choices. Compcache came out slightly better with the recommended configs that I could find at the time. Then I benchmarked and tested each of the Compcache settings. I found huge improvements made from tuning Compcache, especially adding backing swap. I know it got a bad rap in earlier builds because, well, it probably wasn't very good. But 0.6 is good and it has a bright future. Read this article http://lwn.net/Articles/334649/
Then I tuned swapiness, CPU, and tried on VM. It was mostly just painstaking, tedious testing of one setting to the next. I can honestly say that I have tuned every setting in the User.conf. If I change any of them the benchmarks go down. So when people tell me they tweaked this or that I don't want to say anything because I have probably tested that exact scenario and I got worse performance. But maybe it is working for them, I haven't seen any benchmark numbers. I tried on the VM but nothing seemed to help very much and I didn't want to cause problems so I stuck with the default settings there. Maybe someone can come up with better settings for the VM if that is their area of expertise.
Results:
I'm not going to post some grand report like I would at work. I'm not getting paid for this. Plus not very many people would look at it and I don't know how much it would mean in the long run.
The easiest comparision I can make is using Benchmark Pi. The average of all of the users who have ever tested using that app is around 15 seconds to calculate pi. Stock G1's will calcluate it in about 16 or 17 seconds depending on how loaded they are. xROM stock was getting a result of about 13.5 seconds with just scaling the CPU up to 528 MHz. After tweaking all of the other settings I got down to sub 12 seconds. My best time is about 11.6 seconds. I saw someone with 11.5 who used xROM 1.4. When I loaded CM 4.0.4 last night I was getting just under 13 seconds with my best times. Still a very good time considering everything that I have running.
I did a lot of other testing with Benchmark to monitor the filesystem and memory. I monitored /proc/swaps to see how much memory Compcache was using and how much was being swapped.
I learned a lot about the phone doing all of this. For instance, when you set the CPU max threshold really low, it is going to keep bumping up the CPU really fast until you get to the max. So you have a pretty good delay until you get to the max CPU frequency because the fequency keeps changing and pauses when that happnes. But then it is good until it drops again. If you make it too high, it will overwork the processor and you will see delays again. The key is to find the best setting that allows the processor to be exercised but not overworked. I don't have the time to write down everything I learned from it and you probably don't want to read it. But if you ask a specific question I will be happy to answer it.
I'd like to thank Huanyu for his thread (http://forum.xda-developers.com/showthread.php?t=542899). I wouldn't have been able to tune any of this without it and for JAC and Manup for helping me so much with xROM.
I hope this thread is helpful. Let me know what you think of my work and post your ideas too.
I have links to installing my User.conf in my signature. This post is long enough without putting that in here too. And this is more about discussion than pushing my settins on people. I don't know if mhy config will work at all with Hero. I haven't done much testing on it. I plan to do the same project for Hero when I have time. JAC has volunteered to help me out with that. If anyone wants to try it, go for it. But I don't want to confuse this thread too much by discussing Hero and the AOSP ROMs. Maybe I will start another thread for just Hero.
I look forward to seeing where this thread goes.
Ok, I decided to add more now that I have some extra time. I'm working to get backing swap working with a swap file instead of using a swap partition. A lot of people don't have or want a third partition on their phone and backing swap helps out a lot. Compcache 0.6 supports this but it wouldn't work on the G1 (or any ARM processor). I opened an issue with the compcache development team. They gave me a fix which allowed me to enable it but it ended up trashing my ext3 partition. I had to wipe my phone because the data became so corrupted. The issue is still open and the compcache developer is working on resolving it. When it is resovled, I will post an updated user.conf file that uses swap file instead of swap partition.
Many thanks for your test.
Just one question, why you don't turn the linux swap on in Cyanogen's ROM?
I found you turn on the compcache and backingswap in user.conf.
Is it better than compcache with linux-swap?
min scaling frequency 192000?
I applied the settings from your user.conf in the Cyan thread you linked to except the min scaling frequency because it seems to be set to a non-existent step (192000). Is that a typo or...? Is that user.conf the latest one you tested with CM 4.0.4?
Thanks for doing all this testing and sharing your settings!
fengwuyu said:
Many thanks for your test.
Just one question, why you don't turn the linux swap on in Cyanogen's ROM?
I found you turn on the compcache and backingswap in user.conf.
Is it better than compcache with linux-swap?
Click to expand...
Click to collapse
Compcache with backing swap uses the linux swap partition but it lets compcache manage both the compressed and non compressed storage. When a file can't or shouldn't be compressed it doesn't have to pass it back to the OS to deal with. It just moves it directly to swap. That is why it shows 100% good compression with backing swap turned on. All of my testing has shown that compcache + linux swap is much slower and more cpu intensive thand compcache + backing swap.
my experiences are non-scientific and completely anecdotal, but I like the way my phone behaves w/ a 92 meg linux swap partition enabled w/o compcache. I'm giving up a bit of responsiveness across the board (once it starts swapping) for more virtual memory. Since I have a class 6 card, the lag is bearable (i can't imagine it would be on a slower one).
I like to have my browser still be in memory after loading terminal, gmail, or a couple of other apps. but that's just me & how i use my phone. it's not a perfect config by any means, but it works best for me
ei8htohms said:
I applied the settings from your user.conf in the Cyan thread you linked to except the min scaling frequency because it seems to be set to a non-existent step (192000). Is that a typo or...? Is that user.conf the latest one you tested with CM 4.0.4?
Thanks for doing all this testing and sharing your settings!
Click to expand...
Click to collapse
It's not a typo. Some of the overclocking apps use it as an option. I've used it for a long time and so have other peole. If you want to change it, that is fine. I used 245760 for a while because of some apps I was running. The CPU frequency is one area that you can play with to meet your needs without changing much. I wouldn't suggest going below 192. You can try it but it makes the phone slow to wake up for some people.
alapapa said:
my experiences are non-scientific and completely anecdotal, but I like the way my phone behaves w/ a 92 meg linux swap partition enabled w/o compcache. I'm giving up a bit of responsiveness across the board (once it starts swapping) for more virtual memory. Since I have a class 6 card, the lag is bearable (i can't imagine it would be on a slower one).
I like to have my browser still be in memory after loading terminal, gmail, or a couple of other apps. but that's just me & how i use my phone. it's not a perfect config by any means, but it works best for me
Click to expand...
Click to collapse
That is a pretty good configuration. You will probably see better performance at a slightly higher swapiness with 92MB of swap. I think around 40 is a good setting.
You are right with a Class 6 card the performance is not that bad. You won't see a lot of lag until the file grows to the point that the OS needs to clean it up to make room for more memory. Then it will slow down. If you reboot every day it's not as much of an issue.
I've tried to come up with a configuration that works well for everyone. I helped a guy with a Class 2, 1GB card last night. He thought that my config was slowing him down on CM 4.0.4. We reparititoned and gave him a smaller ext (256 MB) to free up more memory on his FAT32 partition. I have a lot on my phone and my dalvik-cache is on my ext partition and I am using about 215MB so he should be fine with that setting. He got all of his apps installed and setup everything. Then he tested his it out with the stock settings. After he had an idea of how it was running he switched to mine and saw a noticable improvement. Using Benchmark Pi he had the same score I had with a Class 6 8GB card running on CM 4.0.4 the other day. Now my card will beat him out in other tests. Anything that requires swapping to the linux swap partition or a lot of I/O on the SD card will be better on my phone. But because he was using Compcache his performance was still pretty good.
Also, if you enable backing swap your browser should still be in memory after loading other apps. One of the biggest things people notice is that after they have been using the browser or something else that takes a lot of memory and they hit the home button they don't have to wait for it to reload. It's just there waiting for them.
Yes, he speaks the truth. After updating to a recent Cyanogen ROM, my phone just got super clunky and annoying to use, so I set out to do a completely fresh install: resizing, reformatting, wiping, fresh ROM flash, and fresh app dls. I thought since I was stuck using the stock 1GB SD card (for now at least) that is inherently Class 2, it was causing me a major bottleneck since CC and BackingSwap both employ fair usage of your SD card. Well after updating to Cyanogen's 4.1.2.1 and installing all my apps, Benchmark Pi clocked in at about 15.5ms - 16.5ms using Cyano's stock CC settings built into his ROM. Next I pushed Taylor00's user.conf with the 0.1.4.1 userinit.sh. After rebooting, my phone clocked in at 12.6ms - 13.2ms on Benchmark Pi, a definite improvement.
-Maleko48
miketaylor00 said:
That is a pretty good configuration. You will probably see better performance at a slightly higher swapiness with 92MB of swap. I think around 40 is a good setting.
You are right with a Class 6 card the performance is not that bad. You won't see a lot of lag until the file grows to the point that the OS needs to clean it up to make room for more memory. Then it will slow down. If you reboot every day it's not as much of an issue.
I've tried to come up with a configuration that works well for everyone. I helped a guy with a Class 2, 1GB card last night. He thought that my config was slowing him down on CM 4.0.4. We reparititoned and gave him a smaller ext (256 MB) to free up more memory on his FAT32 partition. I have a lot on my phone and my dalvik-cache is on my ext partition and I am using about 215MB so he should be fine with that setting. He got all of his apps installed and setup everything. Then he tested his it out with the stock settings. After he had an idea of how it was running he switched to mine and saw a noticable improvement. Using Benchmark Pi he had the same score I had with a Class 6 8GB card running on CM 4.0.4 the other day. Now my card will beat him out in other tests. Anything that requires swapping to the linux swap partition or a lot of I/O on the SD card will be better on my phone. But because he was using Compcache his performance was still pretty good.
Also, if you enable backing swap your browser should still be in memory after loading other apps. One of the biggest things people notice is that after they have been using the browser or something else that takes a lot of memory and they hit the home button they don't have to wait for it to reload. It's just there waiting for them.
Click to expand...
Click to collapse
if i notice it being laggy, i just swapoff & swapon and it's like i'm fresh off a reboot.
what would be epic is if someone ported anacron / atd to android -- i could set it to do this at 4am.
alapapa said:
if i notice it being laggy, i just swapoff & swapon and it's like i'm fresh off a reboot.
what would be epic is if someone ported anacron / atd to android -- i could set it to do this at 4am.
Click to expand...
Click to collapse
I believe that crontab is a part of busybox. You can use that.
I'm still not following
miketaylor00 said:
It's not a typo. Some of the overclocking apps use it as an option. I've used it for a long time and so have other peole. If you want to change it, that is fine. I used 245760 for a while because of some apps I was running. The CPU frequency is one area that you can play with to meet your needs without changing much. I wouldn't suggest going below 192. You can try it but it makes the phone slow to wake up for some people.
Click to expand...
Click to collapse
What I'm confused about is the significance of choosing 192000 as a scaling frequency at all. My understanding is that the CPU can only run at certain frequencies and 192000 is not one of them. If you set 192000 as your minimum scaling frequency, doesn't that have exactly the same effect as setting it for 245760? Since there are no frequencies available between 122880 and 245760, any setting (for minimum scaling frequency) between those would default to the higher frequency, in this case 245760. Am I missing something here?
The reason I thought it might be a typo is because there is a 19200 frrequency available, but from all reports anything near that low will just lock up the phone.
ei8htohms said:
I applied the settings from your user.conf in the Cyan thread you linked to except the min scaling frequency because it seems to be set to a non-existent step (192000). Is that a typo or...? Is that user.conf the latest one you tested with CM 4.0.4?
Thanks for doing all this testing and sharing your settings!
Click to expand...
Click to collapse
Here is a copy/paste of that section of the latest user.conf set with MT00's settings:
Code:
#cpu clock
proc_cpu{
proc_cpu_en=1 # enable(1) or disable(0) user cpu configurations
# freqency options
# 19200
# 122880
# 128000
# 245760
# 384000
# 528000
scaling_min_freq=192000 # default 245760
scaling_max_freq=528000 # default 528000
sampling_rate=2000000 # default 2000000 depending on kernel version
powersave_bias=0 # default 0, (200 since CM3.9.6+ )
up_threshold=45 # default 40, percent cpu usage before going up a speed step
While 192000 is not an option listed, here is the output of my userinit.sh:
Code:
C:\Documents and Settings\user>adb remount
remount succeeded
C:\Documents and Settings\user>adb shell
sh-3.2# sh /system/sd/userinit.sh -s
sh /system/sd/userinit.sh -s
=== user.conf ===
*** general ***
apps2sd=0
media2sd=0
*** CompCache ***
compcache_en=1
cc_memlimit=18
cc_disksize=32
cc_backingswap_en=1
cc_backingswap=/dev/block/mmcblk0p3
swappiness=28
*** Swap File ***
swap_file_en=0
linux_swap_file_size=32
linux_swap_file=/system/sd/swap.file
*** Linux Swap ***
linux_swap_en=0
linux_swap_partition=/dev/block/mmcblk0p3
*** VM ***
sys_vm_en=1
page_cluster=3
laptop_mode=0
dirty_expire_centisecs=3000
dirty_writeback_centisecs=500
dirty_background_ratio=5
dirty_ratio=10
*** CPU ***
proc_cpu_en=1
scaling_min_freq=192000
scaling_max_freq=528000
sampling_rate=2000000
powersave_bias=0
up_threshold=45
=== CompCache status ===
CompCache version 0.6+
Compcache enabled
CompCache: MemLimit 18432(system) 18432(user)
CompCache: BackingSwap /dev/block/mmcblk0p3(system) /dev/block/mmcblk0p3(user)
CompCache: cc_swappiness - 28(system) 28(user)
=== CompCache status output ===
BackingSwap: /dev/block/mmcblk0p3
DiskSize: 32130 kB
MemLimit: 18432 kB
NumReads: 8048
NumWrites: 10222
FailedReads: 0
FailedWrites: 0
InvalidIO: 0
NotifyFree: 3870
PagesDiscard: 0
ZeroPages: 177
GoodCompress: 100 %
NoCompress: 0 %
PagesStored: 4340
PagesUsed: 1060
OrigDataSize: 17360 kB
ComprDataSize: 4078 kB
MemUsedTotal: 4240 kB
BDevNumReads: 1233
BDevNumWrites: 1731
=== VM status ===
Set VM: page-cluster - 3(system) 3(user)
Set VM: laptop_mode - 0(system) 0(user)
Set VM: dirty_expire_centisecs - 3000(system) 3000(user)
Set VM: dirty_writeback_centisecs - 500(system) 500(user)
Set VM: dirty_background_ratio - 5(system) 5(user)
Set VM: dirty_ratio - 10(system) 10(user)
=== CPU status ===
Set CPU: scaling_min_freq - 192000(system) 192000(user)
Set CPU: scaling_max_freq - 528000(system) 528000(user)
Set CPU: sampling_rate - 2000000(system) 2000000(user)
Set CPU: powersave_bias - 0(system) 0(user)
Set CPU: up_threshold - 45(system) 45(user)
That setting seems to take.
You can set the frequncy to 1234 if you want to. I wouldn't recommend it but you can. I don't know why it isn't listed as an option. It should be. It is a valid setting.
miketaylor00 said:
You can set the frequncy to 1234 if you want to. I wouldn't recommend it but you can. I don't know why it isn't listed as an option. It should be. It is a valid setting.
Click to expand...
Click to collapse
You actually cant set the frequencies to any arbitrary number. There are a set of defined frequencies in the arch/arm/mach-msm/clock.c file. So you can't try to clock your CPU at let's say 523.12 or 99.8 mHz atm. Unless that frequency table is expanded to include every single frequency. Where's coolbho3000 he might be able to explain it better. lol
After the phone has rebooted you can use the following command to see if everything is running properly:
Code:
su
sh /system/sd/userinit.sh -s
Everything seems to work right for me on the install but after I reboot and enter this code. I get "sh: Can't open /system/sd/userinit.sh".
Does this mean it did not work?
bigragu said:
After the phone has rebooted you can use the following command to see if everything is running properly:
Code:
su
sh /system/sd/userinit.sh -s
Everything seems to work right for me on the install but after I reboot and enter this code. I get "sh: Can't open /system/sd/userinit.sh".
Does this mean it did not work?
Click to expand...
Click to collapse
Which ROM are you on? Different builds require the userinit in different places.
Have you done this?
Code:
su
cd /system/sd
chmod 755 userinit.sh
chmod 755 user.conf
reboot
overground said:
Which ROM are you on? Different builds require the userinit in different places.
Have you done this?
Code:
su
cd /system/sd
chmod 755 userinit.sh
chmod 755 user.conf
reboot
Click to expand...
Click to collapse
I'm on CyanogenMod v4.0.4. I clicked the link from this post which lead me to the code he had posted in another thread. I followed the instructions there. I don't believe the code was exactly what you have here. Will try. Thanks.
andonnguyen said:
You actually cant set the frequencies to any arbitrary number. There are a set of defined frequencies in the arch/arm/mach-msm/clock.c file. So you can't try to clock your CPU at let's say 523.12 or 99.8 mHz atm. Unless that frequency table is expanded to include every single frequency. Where's coolbho3000 he might be able to explain it better. lol
Click to expand...
Click to collapse
That is not true at all I just set mine to 192123. Are you telling me that is in the clock.c file?
Code:
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq;
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq;
192123
bigragu said:
After the phone has rebooted you can use the following command to see if everything is running properly:
Code:
su
sh /system/sd/userinit.sh -s
Everything seems to work right for me on the install but after I reboot and enter this code. I get "sh: Can't open /system/sd/userinit.sh".
Does this mean it did not work?
Click to expand...
Click to collapse
Most likely you don't have a userninit.sh. If you are on CM 4.x it doesn't come by default. Follow the steps in this thread:
http://forum.xda-developers.com/showthread.php?t=542899
ok its simple we all know the benefits of more ram. we all know that android slices up the ram into static addresses within the kernel. i would like to change that as we are in 2009 almost 2010 and we still rely on static ram allocation for the camera, gpu, sensors, radio. the g1 has 192mb of ram. yet we only get 97 for programs to use. i would like to place the camera, gpu, etc into dynamic addresses that we can change within the os without flashing a new kernel. a service, kernel code, module, or any other method could do this. we just have to make it happen. we could do it three ways i see.
1. a system managed ram allocation using a service to detect the percentage used and increase ram on the go.
2. a kernel script or service that only activates and allocates ram when needed. such as once a 3d program is loaded the 8mb magically comes back.
3. a virtual device ram allocation service that makes the device think it has the ram all along, but only actually gets it when it needs it. kinda like the way apps2sd works.
4.(by IConrad01) run perl scripts through ase and use ksplice to patch the gpu1 memory in kernel. one script on and one for off.
any other methods to implement this proper are very welcome and encouraged.
the idea behind this is a proper way to get back more ram for our programs. the idea is simple when 3d is not in use we can used the 8mb it would have used for something else. this applys to everything that has its own ram. camera, etc. say we did this and only got 120 free. thats almost 25% more ram. plus we could go the extra step and let the user choose how much each thing gets(gpu settings 4mb,8mb,12mb. camera on, off. etc) so when it needs it thats what it gets. great if you like/dislike 3d games.
on another note this is the kind of work that gets you noticed. the kind that gets you hired or gets you respect. google would be proud and might implement it and you and i know it. i hope we are successful and google uses it mainstream.
so lets debate a way/ways to do this
provide alpha tests of different ways to do this
and finally lets post a beta so everyone can enjoy.
atm ksplice with perl scripts is where we are going will update as this progresses.
Doesnt Jacs update to his hero rom have this, im probably mistaken
jad011 said:
Doesnt Jacs update to his hero rom have this, im probably mistaken
Click to expand...
Click to collapse
No. The current implementation of this basically cuts the graphics memory in half.
This would dynamically allocate the memory as needed. Much more efficient way of doing it.
he has a static change that takes the ram away from the gpu by a kernel edit. this is to have both more ram but still give the gpu what it needs to perform properly but only when it needs it or you chose to give it.
Are you referring to RAM or storage space? You say RAM in the title but then it sounds like you're talking about storage space before making me think it's RAM again later on. I'm confused :/ I'd really like additional free RAM, anything that helps reduce swapping to SD card is good but storage space I have plenty of.
all of this would apply to ram only. swap and compcache could use the same idea to dynamically allocate swap but that is still a cache for programs. sorry if its confusing. simple way to explain. i want all the ram i can get but still use everything the phone has properly, like games and the camera.
Gotcha and understood. I see so many people say RAM and memory when they're referring to storage space sometimes that I want to scream but extra RAM on the G1 would be more than welcome. Hopefully others with the brains to make it happen can do it
actually anyone with a basic knowledge can help. mostly there are a couple things to developing a good idea.
first the concept.
then ideas on how to do it.
next a map or guide to what does what.
coding different parts
putting them together
debug and test
even if all you do is photoshop the ui or provide ideas it helps. once some different people get aboard this should be working sooner than you think.
Of the three options listed, the kernel script (via ksplice) seems like it would be the shortest route to functionality, but frankly it also seems a bit... well, hackish -- when compared to the virtual device allocation scheme. It would take a hefty re-write of the kernel, I suspect, to accomplish; but being able to resize various devices on the fly would be a good thing. Shrinking CompCache based on real RAM usage for example would probably speed up the phone under light loads.
Just thinking in text here.
personal i think its going to start simple(script or root app) and go straight to gpu shared on or off. choose and reboot. however i do not want to stop there like winmo did. someone could create a short kernel patch that checks for a service or script and gets value or defaults to standard method. then we would have to come up with how to manage the switch(realtime vs. reboot) ideally we would remap the memory from scratch and rebuild the memory management services to dynamically allocate the ram for all devices(128+ ram) as needed. we have a start, we know where and how to turn the gpu1 shared on or off. now lets make it more than a hack and work on how to make our phones better. btw this is not a waste of time. this extends to other phones and the future way to set up our phones from default.
jokersax11 said:
personal i think its going to start simple(script or root app) and go straight to gpu shared on or off. choose and reboot. however i do not want to stop there like winmo did. someone could create a short kernel patch that checks for a service or script and gets value or defaults to standard method. then we would have to come up with how to manage the switch(realtime vs. reboot) ideally we would remap the memory from scratch and rebuild the memory management services to dynamically allocate the ram for all devices(128+ ram) as needed. we have a start, we know where and how to turn the gpu1 shared on or off. now lets make it more than a hack and work on how to make our phones better. btw this is not a waste of time. this extends to other phones and the future way to set up our phones from default.
Click to expand...
Click to collapse
The only problem with this is when the ram is divided, everything in it is cleared, thats why it is set at boot in the kernel. Think of it like repartitioning your SD. Now it would probably be possible have everything mapped to ONE big RAM table & then build something similar to a scheduler like BFS for RAM that would allocate it as necessary. This is messy though.
Just my $.02
well yes but it is possible to create shared memory through c++ http://www.go4expert.com/forums/showthread.php?t=8461
however i think the vm heaps has either a 6 or 16mb limit. anyways the service would basically do a memory patch over the kernel in realtime(like overclock) telling the gpu the memory is there all the time. meanwhile it allocates dynamic shared memory from the application memory for the gpu to read and write. meanwhile an app tied to a script would set the parameters and settings.
Okay -- I know ksplice works with perl; and I know that we can run perl scripts using the ASE .apk.
So... it seems to me that it /should/ be possible to use a patch that reverts the patched kernel back to the previous state, and a patch that switches the original state to the GPU1=0 MB state. From there, we could set up two scripts; one for GPU1-off and one for GPU0-on. Each would simply be an invocation of ksplice to input the specific patch (which would have to be stored on the sd card. [it would be safer if in the ext partition]).
We'd have to set up a secondary RAM device, rather than just adding it to the standard RAM pool... something like establishing it as a /dev/block/shm.
The point of all the above is that when you click on the GPU1-off script, it "reclaims" that RAM and gives you a device that's standard RAM. When you click on the GPU1-on script, it disables that device (forcing the reload of all programs using that RAM) and re-enables the GPU1 device.
Even better yet, the Android Scripting Environment program, much like GScript, supports desktop icons.
So -- very initially speaking, assuming we can get ksplice working on Android (which just requires a static binary, IIRC), we can get a simple pair of icons; one of which frees up the GPU1's RAM; and the other of which re-enables the GPU1.
Since the only times it's going to be "called up" are when a game is actively being played, or something similar, this should be a mostly-satisfactory route to begin with, before we can get into the whole scheduled/scaled script running as a daemon in the background.
Once we get /there/, then we can start looking at true virtual device allocations and shared memory and the like.
Although, I do have to say that I'm not entirely sure how comfortable I am constantly repatching the kernel. Definitely, we're going to want to recommend that people back up their original, unpatched, boot.img files!
IConrad01 i added your method to first post as it was a great start to this project. if you want me to rephrase just post what you want and ill change it. the only issue i might see is what geniusdog254 said it might unallocate the wrong thing and create a reboot. but some clever coding should prevent this.
Nah, that's all good.
There's an easy way to prevent it from becoming a reboot-able issue. Enable the GPU-space device as "swap". This could be done one of two ways; tell the phone that the new 8 MB RAM "device" is to be considered the /first/ swap device to be used, and just leave it "as is". The r/w times would be for true RAM. The other option assumes we have the latest CompCache (0.6+) -- as it allows for multiple instances of CompCache. The theme here should be obvious.
Either way, the result is that only swappable pagefiles would be lost when the device is turned back into GPU memory. No system-vital memory would get tossed. Seems simple enough to accomplish, perhaps. But then again, I Am Not A Programmer.
ok so what are the alternatives to ksplice for the swap device change. since we could make it swap/compcache anyways is it possible to change on the fly like the way overclocking widget does?
Ksplice allows you to make kernel updates and have them implement themselves without having to reboot the device. The swap device stuff would have to be implemented on a script-level. Two different things: I.e.; the script invokes ksplice to install a specific patch, which causes the kernel to recognize the newly freed-up RAM as a specific device (I.e.; such as /dev/ram1 as opposed to /dev/ram0). I am not sure I'm saying/thinking of this properly here: I'm operating on the edge of what I know about Linux.
Anyhow -- the trick is, when we get the kernel to disable the GPU's memory, we enable a new RAM-disc swap partition with its swappiness set to the maximum rating so it picks up everything first. Since it is /actually RAM/, it'll perform like real RAM. We're only 'declaring' it as swap in order to prevent forced reboots when turning it off.
The above wouldn't just be a ksplice thing; ksplice is just to implement daproy's kernel patch and thus free up the devoted memory to the GPU1. This memory would then be allocated to a new device (thus preventing the RAM-dump forced reboot) and /that/ would be set to swap status to ensure no "mission-critical" files go on it.
Then, once we get that built up, we just build it in "reverse" -- turn off swap (dumping its info back to the system, where CompCache / linux-swap would pick up the load) and re-enabling the GPU1.
Once we get /those/ built, we can then create a daemon script, include an invocation of it into the latest userinit.sh, and have that script basically monitor GPU0's load levels. If they go above a certain threshold (scaling, just like with the CPU), it would invoke the second script above, patching the kernel and re-enabling GPU1. This would then monitor the GPU, and once //its// memory load falls back down to where GPU0 can handle it all, turns GPU1 off and frees that RAM back up for individual use.
I can already foresee a complication where turning GPU1 off "on the fly" would cause a reload of all graphics, but... considering how rare it is to even pull a load above what GPU0 can handle in ordinary use, this isn't much of an issue. It'd take some tweaking and beta-testing (which I'm pretty much set to be a tester of at this point, apparently ) but that would be about it.
Now, //ideally// we could create an alternative solution which wouldn't rely on constantly patching the kernel. As I said; that can get... well, "messy".
I just don't know enough to know what that alternative path would be. Virtual shared memory space seems like it would be a good idea. An alternative solution could be something along the lines of enabling GPU1 at all times and simply having it call to a swapfile which is located in /tmp (I.e.; a non-compressing swap-file which is actually located in RAM). Said swapfile could be resized freely according to need and would thus be no issue at all.
Frankly, I can already see one reason why that would be a superior solution to all the ksplice shenanigans above: said swapfile could be made to be /larger/ than 8 MB, and thus actually provide for an increased performance due to higher available memory for the graphics side of things. We'd want some way to make sure that the swapfile itself wouldn't get pages dumped onto an actual swap partition. This seems like a much more elegant solution than the ksplice routine. I simply have no idea if it's even feasible. The swapfile would have to be mounted into /tmp (or it's Android equivalent) //at the time the GPU1 was enabled//. Is that even /possible/ at boot? Could we simply enable the device very late in the boot stage?
Quickly! Someone with /actual programming expertise/, rescue me from my aimless mental tinkering!
Since it seems there's little activity in this thread, I thought I'd share:
There is a debian armel package for ksplice.
( http://packages.debian.org/squeeze/ksplice )
This is ARM-compiled. We would simply need to cobble together a script which invokes ksplice properly. I myself know nothing of how this would be done.
Usage example of ksplice here:
http://www.ksplice.com/example-update
Looks pretty simple. You just need a working kernel build environment. Anyone got one of those laying around? I have wanted to do that for awhile but am too lazy to set up a linux VM, lol.
Hell yeah!!
Im not much good for this project other then willingness to try betas and give feedback, but I'm excited to see where this goes.. It would be great to reclaim the ram being used from the system when you aren't using anything that needs it and use it for what you are using. Has anyone contacted one of the devs that have been modifying the kernels and ask them if they could try building it with the ksplice functionality?? I would think one of them would be happy to build it so you can start playing with it. Wish I could help more on it, but this is a little above my head, but I will be following this thread and learning what I can as i go.. Good Luck!!
Hey everyone,
With the intro of BFS302 and Cyan's almost stable rom, I figured it is time to do some testing w/ user.conf files on CM 4.1.99. I feel this is necessary because I notice that after ~12 hours or so, the phone really starts to lag and I have a suspicion it has something to do w/ compcache.
I WAS using the stock CM 4.1.99 setting (24mb compcache), and now I am trying a user.conf that uses 64mb compcache w/o backing swap.
Anyone have any good settings\configs that have worked well for them AFTER SEVERAL HOURS OF USE?
The phone always seems to be quick after bootup and a taskkill, but after a few hours (possibly when compcache gets full) it starts to act sluggish
EDIT: Now that 4.1.999 is out, what is everyone using for user.conf settings?
EDIT2: Now that 4.1.9999 (and possibly more to come) is out, what is everyone using? I have added the corrected userinit.sh and my current conf file for reference if anyone wants.
zimphishmonger said:
Hey everyone,
With the intro of BFS302 and Cyan's almost stable rom, I figured it is time to do some testing w/ user.conf files on CM 4.1.99. I feel this is necessary because I notice that after ~12 hours or so, the phone really starts to lag and I have a suspicious it has something to do w/ compcache.
Click to expand...
Click to collapse
You are starting this testing thread on a ROM that has broken BFS and Compcache. This has been reportedly fixed by Cyanogen for the next update. Maybe it would be best to wait to try this when compcache is working efficiently again.
Oh, well thats good to hear. Hadnt heard anything about BFS or compcache issues yet. Anyway, guess we can continue testing once the new update comes out today.
Well to answer your question though, miketaylor00's user.def script has been working really well for me since I started using it...
http://forum.xda-developers.com/showthread.php?p=4334135#post4334135
Here's mine (Unix formatted, open in Notepad++). Running great on CM 4.1.99 for almost 2 days now w/o rebooting. Everything's still smooth and responsive.
Here are the highlights:
...
# 32MB cc with 24MB backing swap on Linux-swap partition
compcache_en=1
cc_disksize=32
cc_memlimit=24
cc_backingswap_en=1
cc_backingswap=/dev/block/mmcblk0p3
cc_swappiness=60
...
# swapfile off
swap_file_en=0
...
# swap partition off
linux_swap_en=0
...
# Defaults here
proc_cpu_en=1
scaling_min_freq=245760
scaling_max_freq=528000
sampling_rate=2000000
powersave_bias=200
up_threshold=40
...
I've also had good results with up_threshold set at 32. I'm also running the "extra memory" kernel hack, so that might be a contributing factor.
After messing with user.conf last night and all day yesterday, it seems the best solution is to just disable CC and enable linux swap or nothing at all until the update is released.
Thanks for your opinions and experiences. I have had 2 kernel panics\reboots today using stock settings, switched to a user.conf file I was using before to see if there is any difference. Lookin forward to the new release tonite though
bump because of new update
zimphishmonger said:
bump because of new update
Click to expand...
Click to collapse
Send me the default file and I'll send you my recommendation. I don't have time to load Cyanogen but I've been testing similar ROMs and I am testing the same BFS patch right now. I've found that BFS performs about the same with the same settings whether it is on Hero or Donut or Cupcake. I may not get you the optimal settings but it will be close and you can build from there.
The stock doesnt have a user.conf file, it just enables compcache 24mb by default (I believe). I usually use a slightly modified version of your user.conf file. I changed the cpu to 254760, and the swappiness to 60 (Just changed for testing).
I have a 64mb swap parition on a class 4 SD that is being used as a backing swap. I cant figure out if a backing swap is helping or not, as the lag happens after being booted for 8+ hours (usually overnight)
zimphishmonger said:
The stock doesnt have a user.conf file, it just enables compcache 24mb by default (I believe). I usually use a slightly modified version of your user.conf file. I changed the cpu to 254760, and the swappiness to 60 (Just changed for testing).
I have a 64mb swap parition on a class 4 SD that is being used as a backing swap. I cant figure out if a backing swap is helping or not, as the lag happens after being booted for 8+ hours (usually overnight)
Click to expand...
Click to collapse
Keep the 64MB swap and try the settings from JacHeroSki. See how that runs for a while. What are you using for your CC memlimit? Are you still having problems on the 999 build?
miketaylor00 said:
Keep the 64MB swap and try the settings from JacHeroSki. See how that runs for a while. What are you using for your CC memlimit? Are you still having problems on the 999 build?
Click to expand...
Click to collapse
Havent seen any issues on 999 build yet, but as I said, it happens after a while (when the compcache gets full and uses the backing swap, I assume). Anyway you can post the user.conf for jacherski? Is it different then xROM1.5r4 or r3?
Regarding CC_memlimit, I am currently using 24. Recommended?
zimphishmonger said:
Havent seen any issues on 999 build yet, but as I said, it happens after a while (when the compcache gets full and uses the backing swap, I assume). Anyway you can post the user.conf for jacherski? Is it different then xROM1.5r4 or r3?
Regarding CC_memlimit, I am currently using 24. Recommended?
Click to expand...
Click to collapse
Yes, BFS completely changes the game with the user.conf. Try this one out. The format might not be right so you will probably need to just copy the settings over. That's why I was going to have you send the original. I'm too lazy/busy to download and extract the CM file. But here is my BFS user.conf. I'm betting the upped CC Memlimit will probably help you out quite a bit.
Much appreciated, will 'convert' it and let ya know how it works out over the next day or so. Lookin forward to playing w/ the new xROM whenever that comes out
Zim, did you see my post in the Compcache vs. Linux vs. Stock thread? If not, check it out. It explains it a little better. I should start another thread on tuning BFS ROMs and post what I know. JacHeroSki is so fast that I'm using it as my daily ROM now. We just need to make it more stable and it will be perfect.
miketaylor00 said:
Zim, did you see my post in the Compcache vs. Linux vs. Stock thread? If not, check it out. It explains it a little better. I should start another thread on tuning BFS ROMs and post what I know. JacHeroSki is so fast that I'm using it as my daily ROM now. We just need to make it more stable and it will be perfect.
Click to expand...
Click to collapse
I agree, BFS really has given Android a whole new lease on life. So snappy. I would love to use JacHeroSki full-time, but I rely on a Bluetooth headset occasionally, so thats a deal killer....but I do have a switchrom image that I continually update to see whats new
Will check out that post, but you should start another thread about tweaking specifically w/ BFS. Seems to be gaining universal acceptance in the community, and it def changes the game around.
zimphishmonger said:
I agree, BFS really has given Android a whole new lease on life. So snappy. I would love to use JacHeroSki full-time, but I rely on a Bluetooth headset occasionally, so thats a deal killer....but I do have a switchrom image that I continually update to see what you new
Will check out that post, but you should start another thread about tweaking specifically w/ BFS. Seems to be gaining universal acceptance in the community, and it def changes the game around.
Click to expand...
Click to collapse
I'm really interested to see how those settings run on the latest Cyan. I have been wanting to tune it but I haven't had the time. That ROM is a lower priority for me because only a handful of people seem to want me to offer my suggestions on it. Cyanogen seems to want to stick to compcache only so I've left it alone for the most part.
copied and updated my user.conf file. Seems a lil more snappy right off the bat now. Will report back w/ long term results.
I currently use Cyanogen full-time, but I do occasionally have a habit of switching back and forth to xROM.
zimphishmonger said:
copied and updated my user.conf file. Seems a lil more snappy right off the bat now. Will report back w/ long term results.
I currently use Cyanogen full-time, but I do occasionally have a habit of switching back and forth to xROM.
Click to expand...
Click to collapse
Could you upload your updated user.conf file?
sacredsoul said:
Could you upload your updated user.conf file?
Click to expand...
Click to collapse
I am messing around w/ some Hero stuff at the moment, so I cant access my user.conf. Its pretty easy to modify miketaylor's previously released .conf, however. Ill attach my previous user.conf and you can just take the setting from miketaylor's attached one (above)
Hi everyone!
As a desire user myself, some of us are already familiar of what I'm talking about: the famous problem of Desire shutting itself down while it was showing a percentage of 15 (or sometimes even higher) percentages!
This problem is a troublemaker, because it's causing the battery to deplete deeply - which is a bad thing for a Li-Ion battery - and also causing you unguarded: you think that you have enough battery to make it home, but hey; your device is dead!
The reason?
The cause of the problem is battery aging. Even though Li-Ion batteries don't have memory effect problems, they are batteries after all and like every battery they get older and lose their capacity.
Ideally (old or new) the battery shows 3200 mV when empty and 4180 (sometimes 4200) mV when it's full. This never changes unlike NiMH batteries - it's why Li-Ion batteries are told "never to suffer from memory effect". The thing is, cells get older in time and even though they always yield the same voltages, they might not last the same (mAh value gets lower). This is called "aging" in batteries.
In HTC Desire device, there is a Battery Controller chip (it's Maxim DS2784 Chip) that is responsible with the battery capacity, percentage estimation; as well as aging compensation. However, during my examinations (since I did have this 15% shut down problem myself) I've noticed something major in the HTC Desire Sense Kernel sources:
A small code piece in ds2784 battery driver which is written with a false assumption is causing your Desire to think it has full "brand new" capacity, which is not the case if you're owner of an aged one! Due to this, your device thinks it has more capacity, when it's actually empty (which occurs at 15-20% depending on the battery) and shutting down at weird percentages.
Solution?
Well, it's something called "Battery Calibration" which more info can be found on this thread (especially check post #3 for the instructions) : http://forum.xda-developers.com/showthread.php?t=765609
(It's Nexus One dev. forum, but don't mind it - the process is exactly the same for us)
The thing about this calibration is; you have to do it under CM or Oxygen ROM's, because it requires a modified AOSP kernel. During my checks, I've seen that this is actually simply because the Sense kernel lacks some sysfs entries - other than that, Sense driver is also capable of doing this calibration - with the help of Jon Richard's "Battery Calibrator" (available at the Play Store (Market) ).
Also, the calibration data normally (I don't really know why) gets erased when you charge your device while off - the way to fix this is available in here: http://forum.xda-developers.com/showpost.php?p=23317695&postcount=2112
OK.. Is this all?
No. Actually this part is more important.
While I'm including this piece to the Sense Kernel, I've seen the following buggy code piece, which is resetting your battery capacity to 1392 mA - which is wrong (too much) if your battery is aged one:
Code:
if ((htc_batt_info.rep.level != 100) &&
(htc_batt_info.rep.guage_status_reg & 0x80) &&
(htc_batt_info.rep.batt_current <= 80) &&
(htc_batt_info.rep.full_acr == 0)) {
acr[0] = 0x0d;
acr[1] = 0x87;
w1_ds2784_write(di->w1_dev, acr, DS2784_REG_ACCUMULATE_CURR_MSB, 2);
htc_batt_info.rep.full_acr = 1;
pr_info("[HTC_BATT] Current Full ACR = %x %x\n", acr[0], acr[1]);
pr_info("[HTC_BATT] Recharging should set ACR to 100 percent\n");
}
Noticed the "acr" part? That's the part where the driver wrongly assigning 1393 mAh to the DS2784 chip.
If you're to read DS2784 battery specification, under "ACR Housekeeping" part, the following is written ;(ACR - Accumulated Capacity register - the register which shows your current capacity of battery as mAh):
ACR Housekeeping
The ACR value is adjusted occasionally to maintain the coulomb count within the model curve boundaries. When
the battery is charged to full (CHGTF set), the ACR is set equal to the age scaled full lookup value at the present
temperature.
Click to expand...
Click to collapse
It clearly states that the ACR value, by chip itself, is already updated to the Full value available in ROM chip! The driver doesn't need to do that (and doesn't need to do that WRONG AT ALL!).
This is the problem, because we calibrate our batteries, and then simply because of a buggy assignment of the driver, we lose all the calibration we made!
Cut the story.. Can you fix this?
Well, already did. Attached to the end of this post, there is a "ds2784_battery.c" file which all the stuff I mentioned in this post is applied to. In the kernel source, change in the kernel source dir drivers/power/ds2784_battery.c file with the one I provided and recompile the kernel - voila, you can now calibrate your battery and it no longer will screw your calibration.
Diff patch?
Available below.
Do I have to compile kernel myself? I'm not a geek like you, man!
Flashable recovery zip for kernel is added to the post (named ahmet-exp4_*.zip)!
And here is what completes the circle: The Battery Calibrator App, modified to work with our kernel!
Can be downloaded here
------------
EDIT: I've added the patch file, and also changed the source file itself - I mistakenly forgot to uncomment the parts which include the sysfs interface, sorry
-----
ADDENDUM (11.03.12): CFS Version is included to the post. Soon, I shall include the Droidzone's battfix into it for high capacity batteries as well, but I kinda think that Droidzone's fix is "not complete" so I'll rewrite it from scratch and thus it does take some time. I guess I can put it next weekend.
-----
ADDENDUM (13.03.12): An improved (?) version of Droidzone's Extended Battery fix has been enabled into the battery driver. Also, HAVS and SVS versions are added for those who prefer (version string does keep these info too, if you forget in the future ). Diff patch is updated with the changes.
About extended batt-fix: Please note that I couldn't test the driver with an Extended battery, but I changed the register parts, so it should run with any battery now since it reads all the data from the Chip's EEPROM instead of using "hardcoded" values.
I also lowered the RSSI values in iw_wl.h file -> now your wifi should not drop so easily as it was in the past (it was -91; I made it -110 ). Diff and edited file are added.
NOTE: My kernels do include nearly all I/O schedulers inside, so that you can change them as you like. If you think your device doesn't perform well with the read/write operations to sd-card or MTD partitions, you can change your I/O scheduler following way:
first, query the modes. You can google-search them to learn what they mean :
--> cat /sys/block/mmcblk0/queue/scheduler (for mmc card)
--> cat /sys/block/mtdblockX/queue/scheduler (for internal memory. X becomes partition number: you can query it with "cat /proc/mtd")
After this, you can pick one and apply that - for instance, say, you picked BFQ (I like it ):
--> echo "bfq" > /sys/block/mmcblk0/queue/scheduler (for mmc card - same applies to MTD too, if you need)
WHY BFQ? Because since SD-cards are Solid State Disks, so they don't have a mechanical head thus V(R) or such schedulers which are optimised for access times are not so optimised for us I think. Instead, we should aim towards the schedulers which takes "load" into consideration. BFQ is one of such schedulers.
I just checked it with my device, I tell you: the results are really amazing How much a scheduler matters is exemplified really
-----
ADDENDUM (15 March 2012): CFS_SVS Version is updated to EXP5; because of some freeze up problems. This version doesn't add anything else, so the old files still stay at EXP4 version
NOTE: I don't have 2Way Call recording sources, so my kernels don't have that feature (I cannot do everything, can I )
---------------
Thank you very much for the donations of Sally Mack
I really appreciate it You really save my life with your donations
F A Q
1- I open the app, but all the values look empty!
It's because you are not using a compatible kernel. As far as I know, only mine and Droidzone's latest kernels do have the necessary patches, so switch to one of them.
2-I cannot drop to 3201 mV!
Some batteries cannot drop into that level, it's true. If your device turns off at higher voltages - like 3400 mV - you can use this value for your registers instead. Please read the following pages or DS2784 chip spec.to use your own value here (key registers are 62 and 63)
3- I drop to 3201 mV, it says "plug the charger" and I plugged. Still device turns off!
This is due to Sense kernels using a different power supply drivers than AOSP kernels; and due to Sense kernels being "less sensitive" to the changes in battery status, thus not sensing the charger plugged it. In order to overcome this, you must decrease your battery usage to a minimum so that your battery can last a little more - just enough for Power Supply driver to sense it. To achive this:
1- At about 3350 mV values, turn on the Airplane mode; decrease the screen brightness to a very low value.
2- Once the program tells you to plug in, plug in right away and then turn your screen off with the power button.
If your device is not turned off within 2 minutes, your learning phase should have begun.
4- Still the phone turns off at 3201 mV!
It's very much likely those solutions above will work; but in case they don't and you want an "easier" calibration - try calibration at some AOSP ROM like Cyanogen Mode ROM or Oxygen ROM (i.e. you have to change your ROM at least temporarily) . AOSP kernels are more "open" to calibration.
5- Do I need "ahmet" kernels for AOSP?
No. All current AOSP Roms come with a modified kernel that's already supporting the calibration - and they are also free of the Sense kernel bug mentioned above since they're completely written from scratch!
6- Can I change ROMs or Kernels after the calibration?
Changing ROMs are OK as long as you use ahmet or Droidzone's latest kernels (i.e. kernels that support calibration) with your new ROM. You should flash the ROM prior to booting your device for the first time.
NOTE HERE: If you're to flash AOSP ROM, don't use ahmet-exp kernels with them since ahmet-exp kernels are Sense kernels. All AOSP ROMs are calibration friendly anyway.
Changing kernels is a tad more tricky: you can change into the kernels that support calibration only: that is either into ahmet-exp or Droidzone kernels.
Good work, I'm glad that somebody found a solution for this problem.
I'm waiting for the fix, can't wait to test it and see how it goes after that, if it'll help my batt and increases it's life.
What else to say, thumbs up and keep up the good work.
So is needed one battery calibration after change the kernel?
Tapatalking
ironjon said:
So is needed one battery calibration after change the kernel?
Tapatalking
Click to expand...
Click to collapse
After every flash/ROM change it is advised to wipe battery stats and calibrate it if you flashed while your phone was plugged in to USB or charger.
This is logic, new ROM, new stats.a battery stats wipe is advised as I said but calibration...I don't think so, you need to do that just once (as I saw on other threads).
What I do after flashing a new ROM/kernel is just to let the phone discharge untill it shuts down, charge till it's full and wipe battery stats.
nomatterbv said:
After every flash/ROM change it is advised to wipe battery stats and calibrate it if you flashed while your phone was plugged in to USB or charger.
This is logic, new ROM, new stats.a battery stats wipe is advised as I said but calibration...I don't think so, you need to do that just once (as I saw on other threads).
What I do after flashing a new ROM/kernel is just to let the phone discharge untill it shuts down, charge till it's full and wipe battery stats.
Click to expand...
Click to collapse
I' ve done that many times and my phone still shutdown at 15% aprox
Tapatalking
ironjon said:
I' ve done that many times and my phone still shutdown at 15% aprox
Tapatalking
Click to expand...
Click to collapse
I flashed the ROM which is in my signature, optimised it and I don't have that problem any more (it shuts down at 2-3%, when it reaches that % it drops down to 0 instantly).
Try to flash other ROM and change kernel, also use the latest RIL and Radio, it might help you. for me it worked.
Just wait untill theGanymedes posts the fix, flash it and see if it'll help you out, it'll need some tests but anyway, I think it will help.
nomatterbv said:
I flashed the ROM which is in my signature, optimised it and I don't have that problem any more (it shuts down at 2-3%, when it reaches that % it drops down to 0 instantly).
Try to flash other ROM and change kernel, also use the latest RIL and Radio, it might help you. for me it worked.
Just wait untill theGanymedes posts the fix, flash it and see if it'll help you out, it'll need some tests but anyway, I think it will help.
Click to expand...
Click to collapse
Thx
I'm trying to fix it with the latest bananacakes' sources but I got some errors:
[email protected]:~/android/kernel/bananacakes-bravo_2.6.35_gb-mr-f42e76d$ make ARCH=arm CROSS_COMPILE=arm-linux-androideabi- -j10
CHK include/linux/version.h
CHK include/generated/utsrelease.h
make[1]: `include/generated/mach-types.h' is up to date.
CALL scripts/checksyscalls.sh
CHK include/generated/compile.h
GEN .version
CHK include/generated/compile.h
UPD include/generated/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
mm/built-in.o: In function `frontswap_curr_pages':
/home/jon/android/kernel/bananacakes-bravo_2.6.35_gb-mr-f42e76d/mm/frontswap.c:235: undefined reference to `swap_list'
/home/jon/android/kernel/bananacakes-bravo_2.6.35_gb-mr-f42e76d/mm/frontswap.c:235: undefined reference to `swap_info'
mm/built-in.o: In function `frontswap_shrink':
/home/jon/android/kernel/bananacakes-bravo_2.6.35_gb-mr-f42e76d/mm/frontswap.c:207: undefined reference to `try_to_unuse'
/home/jon/android/kernel/bananacakes-bravo_2.6.35_gb-mr-f42e76d/mm/frontswap.c:214: undefined reference to `swap_info'
/home/jon/android/kernel/bananacakes-bravo_2.6.35_gb-mr-f42e76d/mm/frontswap.c:214: undefined reference to `swap_list'
mm/built-in.o: In function `__frontswap_flush_area':
/home/jon/android/kernel/bananacakes-bravo_2.6.35_gb-mr-f42e76d/mm/frontswap.c:153: undefined reference to `swap_info'
mm/built-in.o: In function `__frontswap_flush_page':
/home/jon/android/kernel/bananacakes-bravo_2.6.35_gb-mr-f42e76d/mm/frontswap.c:139: undefined reference to `swap_info'
mm/built-in.o: In function `__frontswap_get_page':
/home/jon/android/kernel/bananacakes-bravo_2.6.35_gb-mr-f42e76d/mm/frontswap.c:125: undefined reference to `swap_info'
mm/built-in.o: In function `__frontswap_put_page':
/home/jon/android/kernel/bananacakes-bravo_2.6.35_gb-mr-f42e76d/mm/frontswap.c:104: undefined reference to `swap_info'
make: *** [.tmp_vmlinux1] Error 1
Better to wait the patch
great work this is something I'm really glad to see as I get caught out by this bug a lot, the question is now are there any pro compiled kernel flashes available that use this.
Im using Runnymede AIO v6.0.7 SE so would need a sense based kernel that works well with that.
Drefsab said:
great work this is something I'm really glad to see as I get caught out by this bug a lot, the question is now are there any pro compiled kernel flashes available that use this.
Im using Runnymede AIO v6.0.7 SE so would need a sense based kernel that works well with that.
Click to expand...
Click to collapse
You'll find here everything you need, including sense kernels
nice work, thank you for sharing with us.
i will wait for kernal
Sent from my HTC Desire using Tapatalk
wow...nice thing...good work... thx for this...
but i hope we can get a diff patch...as i think if i use your file the batt charge fix is gone or...did you use droidzone patch also..?
with kind regards
Alex-V said:
wow...nice thing...good work... thx for this...
but i hope we can get a diff patch...as i think if i use your file the batt charge fix is gone or...did you use droidzone patch also..?
with kind regards
Click to expand...
Click to collapse
You can use this.
Thanks, theGanymedes. This was on my todo list for a long time.
Droidzone said:
You can use this.
Thanks, theGanymedes. This was on my todo list for a long time.
Click to expand...
Click to collapse
and i thank you...as always...lol
with kind regards
So can it be also implemented to snq kernel ?
pavel54 said:
So can it be also implemented to snq kernel ?
Click to expand...
Click to collapse
No...as snq never released his source
Sent from my HTC Desire using XDA Premium App
dont want to sound noob but is there any chance of implementing this fix in ICS kernels like: Tiamat 2.6.28 ICS?
as my ICS rom also shuts down at above than 15%.
thank you
or implement it in manus kernel
Yeah, SNQ didn't release his sources, alas.
And thank you Droidzone! I don't know what would we do without you However, your patch is faulty - for some reason, it messes all the file. I've included the patch that'll do it correctly to the first post
About the battery fix - I didn't touch that part but know that bananacakes's sources do have them.
Compiled kernel is delaying a little bit - because my toolchain is faulty, for some reason producing unbootable kernels - going to upload it to the first post when it's ready.
Also another thing: since the sysfs interface placement is different than AOSP kernels, the battery calibrator app on the Market doesn't work with our patch - the files necessary for the program to work is in somewhere else in our system. So, I'll try to find a way to "create symbolical links" or if I can't, I'll rewrite the app - apparently Jon Richards didn't publish his sources for the app :/
Fire are so cheap, that's great,but it's so slow even for normal task.
Long time ago,I have found the performance Bottleneck
Of fire is RAM,not CPU,at least for daily normal use like browser web.when I open more than 3 app like chrome videos music play store,the fire become so slow even get stuck, that's really bad.so the problem is It run out of RAM.it only has 1.7G ram for hd 10 and 1.4g for hd 7 or 8. That's really small today.here is solution I found , it's amazing efficient,really make your fire usable even you run many many apps simultaneously.
One word is "swap".
Swap can make you disk storage to be used as RAM,we know disk is slower than RAM,but as I have test, it's OK,you can do it. : )
First get your fire rooted
Next download a terminal I recommend termux,a powerful tool.
Open temux,now you can run many Linux command on you ,run following command:
su
dd if=/dev/zero of=swap bs=200m count=20
mkswap swap
swapon swap
you will creat 200m*20 about 3.5G ram,also,it takes up the same amount storage,but it worth.
to check if you turn on swap run follow command:
exit
free -m
You'll see you ram status include swap
if you dont ru su before,you dont need exit command beacause you are normal user
swap make big diff experience on you fire, now try it
i can run firefox snd chrome and many app at same time at a acceptable speed.amazing!!!
you will
This is my first share on XDA,I think it's really useful, hope help you too : )
iuyals said:
Fire are so cheap, that's great,but it's so slow even for normal task.
Long time ago,I have found the performance Bottleneck
Of fire is RAM,not CPU,at least for daily normal use like browser web.when I open more than 3 app like chrome videos music play store,the fire become so slow even get stuck, that's really bad.so the problem is It run out of RAM.it only has 1.7G ram for hd 10 and 1.4g for hd 7 or 8. That's really small today.here is solution I found , it's amazing efficient,really make your fire usable even you run many many apps simultaneously.
One word is "swap".
Swap can make you disk storage to be used as RAM,we know disk is slower than RAM,but as I have test, it's OK,you can do it. : )
First get your fire rooted
Next download a terminal I recommend termux,a powerful tool.
Open temux,now you can run many Linux command on you ,run following command:
su
dd if=/dev/zero of=swap bs=200m count=20
mkswap swap
swapon swap
you will creat 200m*20 about 3.5G ram,also,it takes up the same amount storage,but it worth.
to check if you turn on swap run follow command:
exit
free -m
You'll see you ram status include swap
if you dont ru su before,you dont need exit command beacause you are normal user
swap make big diff experience on you fire, now try it
i can run firefox snd chrome and many app at same time at a acceptable speed.amazing!!!
you will
Click to expand...
Click to collapse
Yes, adding a static swap file and adjusting 'swappiness' can make a huge difference in responsiveness, especially when multitasking and after wake from extended sleep when many apps attempt to resync. The file does not need to be large and can be placed in the cache partition if desired.
My recommendations:
- 256MB static swap file
- set swappiness to 10
- leave ZRAM swap intact if present
- (optional) set ZRAM priority higher than static file to favor ZRAM storage
Also no need to use obsecure terminal commands. The free app Apps2SD easily handed swap file creation and management.
Davey126 said:
Yes, adding a static swap file and adjusting 'swappiness' can make a huge difference in responsiveness, ...
My recommendations:
- 256MB static swap file
- set swappiness to 10
- leave ZRAM swap intact if present
- (optional) set ZRAM priority higher than static file to favor ZRAM storage
Also no need to use obsecure terminal commands. The free app Apps2SD easily handed swap file creation and management.
Click to expand...
Click to collapse
Which "Apps2SD" does one download? There are quite a few apps with similar name "App2SD".
Is this the one ?
https://www.apps2sd.info/features
https://play.google.com/store/apps/...rce=Website&utm_medium=Home&utm_campaign=Home
Thank you.
Dan_firehd said:
Which "Apps2SD" does one download? There are quite a few apps with similar name "App2SD".
Is this the one ?
https://www.apps2sd.info/features
https://play.google.com/store/apps/...rce=Website&utm_medium=Home&utm_campaign=Home
Thank you.
Click to expand...
Click to collapse
Yep - that's the pup.
{interesting: name varies depending on entry point; author calls it "Apps2SD" but is posted as "App2SD" in the Play Store}
Oh, thanks so much,you introduce me zram, which a More amazing concept,as I have test,it has better performance than swap,now I change to zram,thx,it's better to my disk
its so good to share,bc i get a better one : )
Does anyone know the PROS and CONS, as far as ZRAM is concerned, between Apps2SD and RAMExpander?
See the following post about RAMExpander:
https://forum.xda-developers.com/hd8-hd10/general/best-optimization-hack-experience-t3730239
Thanks.
Dan_firehd said:
Does anyone know the PROS and CONS, as far as ZRAM is concerned, between Apps2SD and RAMExpander?
See the following post about RAMExpander:
https://forum.xda-developers.com/hd8-hd10/general/best-optimization-hack-experience-t3730239
Thanks.
Click to expand...
Click to collapse
Apples and oranges. Apps2SD is simply a tool that provides GUI for defining and managing static swap files. RAMExpander appears to do the same thing with predefined (and excessive IMO) values. ZRAM is a seperate beast that is best left alone unless one is familiar with Virtual Memory Management and the various interactions that take place between tuneables.
-- I accidentally posted in the wrong thread, sry --
Davey126 said:
Yes, adding a static swap file and adjusting 'swappiness' can make a huge difference in responsiveness, especially when multitasking and after wake from extended sleep when many apps attempt to resync. The file does not need to be large and can be placed in the cache partition if desired.
My recommendations:
- 256MB static swap file
- set swappiness to 10
- leave ZRAM swap intact if present
- (optional) set ZRAM priority higher than static file to favor ZRAM storage
Also no need to use obsecure terminal commands. The free app Apps2SD easily handed swap file creation and management.
Click to expand...
Click to collapse
Is this (attachment) ok?
Oco said:
Is this (attachment) ok?
Click to expand...
Click to collapse
That works! Don't expect miracles. Still a low resource gizmo; reading/writting to static swap is magnitudes slower than memory based zram. But it does allow the OS to swap when needed without thrashing. Setting swappiness to 10 encourages the retention of processes in memory while reducing the chance of exhusting available swap space. If that happens the device will become a complete dog due to thrashing on slow file based swap; a reboot will fix things up.
Davey126 said:
That works! Don't expect miracles. Still a low resource gizmo; reading/writting to static swap is magnitudes slower than memory based zram. But it does allow the OS to swap when needed without thrashing. Setting swappiness to 10 encourages the retention of processes in memory while reducing the chance of exhusting available swap space. If that happens the device will become a complete dog due to thrashing on slow file based swap; a reboot will fix things up.
Click to expand...
Click to collapse
Thanks, is this the same for fire 8 and fire 7?
Oco said:
Thanks, is this the same for fire 8 and fire 7?
Click to expand...
Click to collapse
Yep with caveats. Haven't messed with Fire 8 (2018) virtual memory as stock settings/performance are adequate for my current needs. Wake lag on the HD 8 is non-existent with my app portfolio which was the driver for adding a static swap file on the Fire 7. As a general rule I avoid turning knobs and dials unless there is a benefit that offsets the effort and potential side-effects.
Davey126 said:
Yep with caveats. Haven't messed with Fire 8 (2018) virtual memory as stock settings/performance are adequate for my current needs. Wake lag on the HD 8 is non-existent with my app portfolio which was the driver for adding a static swap file on the Fire 7. As a general rule I avoid turning knobs and dials unless there is a benefit that offsets the effort and potential side-effects.
Click to expand...
Click to collapse
Agreed. While I have no experience with other Fire tabs, the Fire 8 HD 2018 is way better than I expected after reading some of the threads in this forum. I have now disabled the major bloats but find no big difference in either speed or battery drain.
Hi guys. I am late to this thread, of course.
Can anyone tell me how to root the fire 7 9th gen which runs on version 7.3.1.8?
I see that the fire 7 can run way faster because of the methods above but my device can't be rooted because it seems it can't be rooted by where I looked to root it.
All Fire tablets are entry-level that aren't intended for multitasking.
AmznUser444 Dev said:
All Fire tablets are entry-level that aren't intended for multitasking.
Click to expand...
Click to collapse
I see. So you are saying that they can't be rooted? Like the version I have right now? Just wanting to change the swap.
Animate Blade said:
Hi guys. I am late to this thread, of course.
Can anyone tell me how to root the fire 7 9th gen which runs on version 7.3.1.8?
I see that the fire 7 can run way faster because of the methods above but my device can't be rooted because it seems it can't be rooted by where I looked to root it.
Click to expand...
Click to collapse
Try kingroot.
kwanbis said:
Try kingroot.
Click to expand...
Click to collapse
Does it work? Did you have experience of it? I'll see though and come back With some info on it.
Animate Blade said:
Does it work? Did you have experience of it? I'll see though and come back With some info on it.
Click to expand...
Click to collapse
I just flashed LineageOS 12.1 on my two FireHD10. The first one I had blocked the OTA updates so I was able to install TWRP following this guide:
[UNLOCK][ROOT][TWRP][UNBRICK] Fire HD 10 2017 (suez)
Read this whole guide before starting. This is for the 7th gen Fire HD10 (suez). Current version: amonet-suez-v1.1.2.zip NOTE: This process does not require you to open your device, but should something go horribly wrong, be prepared to do...
forum.xda-developers.com
But for the second one, I had forgotten to block the OTA updates so the first step which requires root was not working. I used kingroot to root it first and then followed the guide I posted above.
I did the soft brick to downgrade and then I installed LineageOS 12.1
[discontinued][ROM][unlocked][suez] Lineage-12.1 [05 MAY 2020]
Disclaimer /* * I am not responsible for bricked devices, dead SD cards, thermonuclear war, * or you getting fired because the alarm app failed. * Please do some research if you have any concerns about features included * in the products...
forum.xda-developers.com
I did it 2 or 3 days ago.