[BUG] RK2023 and RGB30v1 battery drain while off #256
Comments
|
Just throwing my two cents in... I wonder if the device is really shutting off when you do a shutdown? My hypothesis if this turns out to be the case is a problem in the Arm Trusted Firmware. How long do you have to hold down the power button to turn it back on after a shutdown? If it's less than 2 seconds it was truly shut down, if it's more than 4 seconds the device was never really off to begin with. |
|
I do not notice any difference in time I need to hold power to boot between the rgb30v1 and RG-Arc. A fast tap to the power button doesn't boot either, slightly longer 1-2 sec maybe will boot both. |
|
Damn, okay. Might have to probe the PMIC outputs one by one when it's off to see if we can figure out the power drain. Do you know if the X55 has a similar issue? Thank you. |
|
X55 is the only PK rk3566 device I don't own, though we have several contributors that own it. And we have no reports of draining while off. The rgb10max3 and rgb20sx (with exception of wifi identical to a rgb30v2) does not have this issue. When looking at the regulator in the dts, I saw that it specifies min voltage to 0.7125 volts (I know this is from BSP), while I think it's specced to 0.76V. BSP also have something called init voltage which doesn't exist on mainline. I will test raising the min voltage an do a test, but it takes a day or two. |
|
I am somewhat optimistic, but the battery reading was wrong when I started. So it had more juice than expected. This was the rgb30v1. I am starting a test on the rk2023 which was dead now, I updated and charged it up to 7%. I will check every 24h from now on. |
|
No the min voltage on the regulator had no effect, today I tried starting both of them after ~48h. They were both drained. :( |
|
Can confirm this on my RGB30v1. |
|
I believe I'm running into this on my RG353M as well. I don't recall having issues on JELOS, which I was using up until moving to ROCKNIX's latest release two days ago. Now I've had one day of the device being too dead to turn on without being plugged in, and another day where after 8-10 hours or so I'm at 36% when I had powered off around 80 or 90%. |
|
Updated to 20240612 yesterday. |
|
The battery indicator isn't the most reliable, I usually left them on low charge 10-30% (hard to know what). Left it 2-3 days, and when I tried to start them they were dead. |
|
There several user report of this also happening on RGB10 Max 3, though I never experienced it. |
|
Just wanted to chime in and clarify - futher to my comments on the other thread - this is definitely happening with my RGB10 Max 3. Turned off with a decent charge remaining two days ago, dead and unresponsive today, had to plug in for a bit before powering on. (on 20240612) |
|
Ok, maybe a wild guess, but maybe someone could also confirm my findings: I had my RGB30 lying on my table for the last few days -> almost no battery drain when turned off. Since the device has no mechanical on/off-switch: Is it possible that the new kernel monitors all buttons (not only the on/off button) when turned off and every time a button gets pressed (which happens quite often in my bag) the device wakes up for a short time which drains the battery? |
|
I believe this is now fixed for me on the latest release with my RG353M. I updated within a half hour of 20240702 coming out. After sitting one day turned off, I didn't lose any charge. Two more days being off again it still seems fine. |
|
I never had any issues with other than rk2023 and rgb30v1, but I just started another test run on linux 6.10 (newer than the release) |
|
Can confirm that this is still happening on Powkiddy RGB10 max3 - running 20240702 Turned off device with 60-70% power left, left in one place without moving or using it at all, totally dead after a couple of days - won't turn on. |
|
After updating linux 6.10, u-boot 2024.07 and latest ATF from rockchip the issue still persists. |
|
Hello, I have the same issue on the latest 20240702 on my RK3566 Arc-D. Went from 50% to 0% in one night |
|
Unless it's dead, it's most likely just a battery reading bug. |
Is is dead! |
Is the workaround to this issue to reconnect the battery? I've done that, and it showed the correct battery level for a few days. However, today the issue has reappeared. |
|
Seeing this occur on both my RGB 10 Max 3 and RGB30. |
|
On my side rk2023, rg30v1, rgb30v2 and rgb20sx drain while off, but my rgb10max3 seems fine at least to a point where it could be off for weeks, and still powered on with 60%ish battery. |
|
Strangely enough my RGB10 Max 3 was unaffected until I opened it up to install some Hall Sticks, maybe these are draining excessively while powered down? After disconnecting the battery this issue popped up. Turned it off around 60% on the 7th and now its completely dead. |
|
This could be related. My drain problem on my rgb30v1 also started at around the same time after installing the Hall Sticks. |
|
I don't think so. I have the issue on a 100% unmodified RGB30. |
|
Did some further testing on other builds:
So it's looking like it may be related to some other change done within that date range and possibly not related to the kernel at all. |
|
We changed RK3566 build target to mainline linux just after the 0206 release. |
|
Strange, I believe the build I used still had the BSP kernel, I also tried "KOLOS" which seems to be another fork of JELOS, which seems to be using the BSP kernel but based on a later release and the issue was there as well. |
|
Here is a dev-build with power management changes to powkiddy rk2023, rgb30v1/v2, rgb10max3 and rgb20sx: I'd appreciate if you could test it and see if you get any improvements. |
|
I have the RK2023 Wifi Hardware Version 1.1 and having the same battery drain issue. Just upgraded to 20240815 and still drains. I have unplugged the battery, tried MEM, FREEZE and still drains about 5-6% per hour (guesstimate). |
|
Might be on to something here, testing the 8-17 build on my RGB30 turned off this morning at 10:30 AM with 61%, just checked now (3:24 PM) and its still reading 61%. Will leave it off for the rest of the night and check tomorrow. |
Did you mean 20250815? I don't see 817 in dev or main. |
They are there:
|
Thanks for providing the link. I installed the linked update and it still drained the same amount and was dead by morning. |
|
@cndjonno |
|
Seems like the 8-17 build resolved the drain on my rgb30, checked again this morning and its still sitting at 61%. This was on a clean flash with nothing setup, just flashed and then shut down after initially booting to ES. Dropped to 60% as I was typing this but I'd still consider that a huge success where I was previously losing around 10% per day while off. |
|
@sydarn RK2023 Wifi Hardware version 1.1. I have downloaded the full img.gz install and formatted a new card and will test that in case there was some configuration causing the issue with just the update and report back later today or tomorrow. |
RGB30v2 so far: UPD: down to 22% after 48 hours, so around 40% loss per day |
|
I went ahead and updated my old build with the 08-17 tar which had everything setup like wifi and syncthing, etc. Now the drain seems to have returned on my RGB30. In 6 hours or so its lost 10% from 75% to 65%. While my RGB10 Max 3 went from 67% to 63% over the same period so it seems improved. Might mess around with a clean flash on a separate sd and enabling things individually. |
|
I found another problem when I was using RK2023 equipment. When it was charged to 40%, it didn't seem to be recharged (and the indicator light went out). It was only when I switched to the SD card of JELOS system that I was fully charged. |
|
No this seems to have had no effect, just for reference this was the patch: |
|
@sydarn After reflashing that card with 817 build you provided it died shortly after 24 hours so probably 3+%/hour drain which was better than before but still pretty high. At some point I want to put a current meter on the battery to see if I can measure the drain under specific configs. |
|
Observations from my devices, I don't have numbers so it's just relative: My other 3 devices: rgb10max3, rg503 and Arc seemingly doesn't drain at all. Can lay unused for weeks, and still power up fine with loads of charge. |
|
Some more observations, though not 100% Rocknix-related: Turns out that battery in my rgb30v2 unit is labeled 606090 4000mAh, however it is not 606090, in reality it's more like 435590, so it's definitely not 4000mah I believe, because it is noticeably smaller. Since the label is lying I have no idea how much of the battery is there. Here's the pic of the said battery: I replaced the battery with the (supposedly) true 606090 4000mAh, though I had to desolder the battery socket and solder the battery to the board. I'm using BSP-based distro on it (ArkOS), but even on that I had steady 15% or more loss per day with the stock battery. With the new battery it is still at 100% after 24 hours, just went to 99%. It also seems to heat up less, though I'm not exactly sure about that Could it be that the "fake" stock battery is somehow discharging on its own and adding to the equation? Or is it just battery reading shenanigans? |
|
I think that disconnecting the battery has reset the device correctly, as
this is one of the steps they suggest to do.
Meanwhile I verified my battery discharges even when completely off, I also
made sure to not touch any button when off and put it in its bag,
but after a week is completely drained, doesn't turn on and needs to
recharge.
…On Tue, 3 Sept 2024 at 00:24, Sasha Soborov ***@***.***> wrote:
Some more observations, though not 100% Rocknix-related:
Turns out that battery in my *rgb30v2* unit is labeled 606090 4000mAh,
however it is not 606090, in reality it's more like 435590, so it's
definitely not 4000mah I believe, because it is noticeably smaller. Since
the label is lying I have no idea how much of the battery is there. Here's
the pic of the said battery:
image.png (view on web)
<https://github.com/user-attachments/assets/7ac453ea-bf1b-40bb-9689-d12f9082ee0f>
I replaced the battery with the (supposedly) true 606090 4000mAh, though I
had to desolder the battery socket and solder the battery to the board. I'm
using BSP-based distro on it (ArkOS), but even on that I had steady 15% or
more loss per day with the stock battery. With the new battery it is still
at 100% after 24 hours, just went to 99%. It also seems to heat up less,
though I'm not exactly sure about that
Could it be that the "fake" stock battery is somehow discharging on its
own and adding to the equation? Or is it just battery reading shenanigans?
—
Reply to this email directly, view it on GitHub
<#256 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABCZXZEAZIG2WMSDNEIIFJDZUTQSVAVCNFSM6AAAAABIVHSGWSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRVGM2DKMZVHE>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
No, the reset didn't fix the drain completely when it had the old battery. I always reset it while testing and switching OSes, and it was always ~40% loss per day on Rocknix and about 15% per day on ArkOS |
|
I was completely fed up with this device and felt like throwing it in the trash. However, in a moment of desperation, I decided to give it another shot with the JELOS version from February. And... all the problems were solved. With ROCKNIX 20240815, the battery was draining within 2-3 days. After 12 days with JELOS, the battery is still at 98%. This clearly can't be a physical issue with the battery, but rather some kind of software problem. |
|
I’m using version |
|
My RGB30 is still at the same charge as it was in my last post from October 8th. During this time, I've played a few times, totaling about 20 minutes of gameplay. Right now, the battery is at 81%. I'm satisfied with the result. In the foreseeable future, I'll stick with JELOS-RK3566.aarch64-20240206... |
Describe the bug
RK2023 and RGB30v1 drains battery while being turned off.
How to reproduce
Steps to reproduce the behavior:
Leave the devices off, preferably with low charge for quicker feedback wait a few days and it's dead.
Information
Log file
Not available
Context
Theory: RK2023 and RGB30v1 uses a different CPU voltage regulator than all other rk3566 devices.
The text was updated successfully, but these errors were encountered: