<![CDATA[PINE64 - All Forums]]> https://forum.pine64.org/ Fri, 03 Jul 2026 13:05:29 +0000 MyBB <![CDATA[PineNote v1.2 - Charges Never Enter "Charging" State (Factory OS, RK817 Below Minimum]]> https://forum.pine64.org/showthread.php?tid=20311 Thu, 02 Jul 2026 08:52:51 +0000 ttsp]]> https://forum.pine64.org/showthread.php?tid=20311 Hardware
  • PineNote v1.2 (Community Edition)
  • Original factory-installed OS (never replaced or reinstalled)
  • Current kernel:
    Code:
    6.12.11-pinenote-202501281646-00249-g211ba27556cc
  • Installed kernel package:
    Code:
    linux-image-pinenote-stable 1.7
Timeline
The device arrived with approximately 40% battery.
I never installed an alternate operating system. The charging problem occurred on the factory-installed OS within the first day after unboxing.
The device operated normally from its initial battery charge but never successfully charged from any charger.
Eventually the battery discharged to 0%.
The interesting part is that the PineNote still boots and runs normally when external USB power is connected. I can SSH into it and run diagnostics. The only failure appears to be that the battery never actually charges.
Chargers Tested
I tested all of the following:
  • OEM USB-A ↔ USB-C cable
  • USB-A wall charger
  • USB-A laptop port
  • 65 W USB-C PD laptop charger
Behavior is identical with every charger.
When powered off and connected to power, the charging animation appears on the display.
I also left it connected overnight while powered off.
Battery level remained at 0%.
USB Issue
Initially the device was affected by the USB issue described in PNDeb Issue #106.
After applying the recommended fix:
Code:
lsusb
works normally.
USB connectivity appears completely functional now.
Charging behavior did not change.
This makes me think the USB problem and the charging problem are unrelated.
Diagnostics
Battery state:
Code:
cat /sys/class/power_supply/rk-bat/uevent
Relevant output:
Code:
POWER_SUPPLY_STATUS=Discharging
POWER_SUPPLY_CAPACITY=0
POWER_SUPPLY_CURRENT_AVG=-168560
POWER_SUPPLY_VOLTAGE_AVG=346xxxx
The important point is that the battery never transitions to:
Code:
POWER_SUPPLY_STATUS=Charging
even while external power is connected.
Charger state:
Code:
cat /sys/class/power_supply/usb/uevent
Relevant output:
Code:
POWER_SUPPLY_ONLINE=1
POWER_SUPPLY_USB_TYPE=Unknown [DCP]
POWER_SUPPLY_VOLTAGE_AVG=452xxxx
So Linux clearly detects external power.
Kernel messages:
Code:
dmesg | grep -i rk817
produces repeated messages similar to:
Code:
rk817-charger: Battery voltage 3465880 below minimum voltage 3500000
rk817-charger: Battery voltage 3477640 below minimum voltage 3500000
rk817-charger: Battery voltage 3483240 below minimum voltage 3500000
I do not see any other charger-related or battery-related errors.
Package Status
Kernel package is already current:
Code:
apt update
apt list --upgradable
apt policy linux-image-pinenote-stable
No newer PineNote kernel is available.
What Seems to Be Happening
From everything I've observed:
  • USB is functioning.
  • External power is detected.
  • Charger is detected (
    Code:
    ONLINE=1
    ).
  • Battery is detected.
  • The device boots and runs on external power.
  • The battery never enters the
    Code:
    Charging
    state.
  • Battery voltage remains below the RK817 minimum threshold (~3.5 V).
  • The battery never recovers, even after being connected overnight.
Questions
  1. Has anyone seen the RK817 refuse to perform pre-charge when the battery falls below approximately 3.5 V?
  2. Is there a known device-tree or kernel configuration issue that could prevent pre-charging?
  3. Is there a way to determine from software whether the battery protection circuit has tripped?
  4. Are there any additional diagnostics I should collect (debugfs, I2C register dumps, RK817 register reads, etc.)?
  5. Does this behavior point more toward a failed battery or charging hardware than a software problem?
Any guidance from people familiar with the RK817 charger implementation or PineNote power management would be greatly appreciated.


Here are various diagnostic commands and their return values:

===== DATE =====
$ date
Thu Jul  2 08:50:52 UTC 2026

===== KERNEL =====
$ uname -a
Linux pinenote 6.12.11-pinenote-202501281646-00249-g211ba27556cc #1 SMP Tue Jan 28 17:04:28 CST 2025 aarch64 GNU/Linux

===== OS RELEASE =====
$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux trixie/sid"
NAME="Debian GNU/Linux"
VERSION_CODENAME=trixie
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

===== KERNEL PACKAGE =====
$ dpkg -l | grep linux-image-pinenote || true
ii  linux-image-pinenote-stable                                    1.7                            all          Linux for the PineNote (meta-package)

===== POWER SUPPLY DEVICES =====
$ ls -l /sys/class/power_supply/
total 0
lrwxrwxrwx 1 root root 0 Jul 12  2026 rk817-battery -> ../../devices/platform/fdd40000.i2c/i2c-0/0-0020/rk817-charger.7.auto/power_supply/rk817-battery
lrwxrwxrwx 1 root root 0 Jul 12  2026 rk817-charger -> ../../devices/platform/fdd40000.i2c/i2c-0/0-0020/rk817-charger.7.auto/power_supply/rk817-charger

===== BATTERY SUMMARY =====
$ grep -E 'POWER_SUPPLY_(PRESENT|STATUS|CAPACITY|VOLTAGE_AVG|CURRENT_AVG|VOLTAGE_MIN_DESIGN|VOLTAGE_MAX_DESIGN|CHARGE_NOW|CHARGE_FULL|CHARGE_TYPE)' /sys/class/power_supply/rk817-battery/uevent
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_STATUS=Discharging
POWER_SUPPLY_CHARGE_TYPE=Standard
POWER_SUPPLY_CHARGE_FULL=4000000
POWER_SUPPLY_CHARGE_FULL_DESIGN=4000000
POWER_SUPPLY_CHARGE_NOW=1237024
POWER_SUPPLY_VOLTAGE_AVG=3750360
POWER_SUPPLY_CURRENT_AVG=-179912
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=3500000
POWER_SUPPLY_CAPACITY=31
POWER_SUPPLY_VOLTAGE_MAX_DESIGN=4200000

===== CHARGER SUMMARY =====
$ grep -E 'POWER_SUPPLY_(ONLINE|USB_TYPE|VOLTAGE_AVG|VOLTAGE_MIN_DESIGN|VOLTAGE_MAX_DESIGN)' /sys/class/power_supply/rk817-charger/uevent
POWER_SUPPLY_ONLINE=1
POWER_SUPPLY_USB_TYPE=Unknown [DCP]
POWER_SUPPLY_VOLTAGE_MAX_DESIGN=5500000
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=3800000
POWER_SUPPLY_VOLTAGE_AVG=4516000

===== FULL BATTERY UEVENT =====
$ cat /sys/class/power_supply/rk817-battery/uevent
DEVTYPE=power_supply
OF_NAME=charger
OF_FULLNAME=/i2c@fdd40000/pmic@20/charger
OF_COMPATIBLE_N=0
POWER_SUPPLY_NAME=rk817-battery
POWER_SUPPLY_TYPE=Battery
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_STATUS=Discharging
POWER_SUPPLY_CHARGE_TYPE=Standard
POWER_SUPPLY_CHARGE_FULL=4000000
POWER_SUPPLY_CHARGE_FULL_DESIGN=4000000
POWER_SUPPLY_CHARGE_EMPTY_DESIGN=0
POWER_SUPPLY_CHARGE_NOW=1237024
POWER_SUPPLY_CONSTANT_CHARGE_VOLTAGE_MAX=4200000
POWER_SUPPLY_VOLTAGE_AVG=3750360
POWER_SUPPLY_CONSTANT_CHARGE_CURRENT_MAX=2000000
POWER_SUPPLY_CURRENT_AVG=-179912
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=3500000
POWER_SUPPLY_CAPACITY=31
POWER_SUPPLY_VOLTAGE_MAX_DESIGN=4200000
POWER_SUPPLY_CHARGE_TERM_CURRENT=300000

===== FULL CHARGER UEVENT =====
$ cat /sys/class/power_supply/rk817-charger/uevent
DEVTYPE=power_supply
OF_NAME=charger
OF_FULLNAME=/i2c@fdd40000/pmic@20/charger
OF_COMPATIBLE_N=0
POWER_SUPPLY_NAME=rk817-charger
POWER_SUPPLY_TYPE=USB
POWER_SUPPLY_ONLINE=1
POWER_SUPPLY_USB_TYPE=Unknown [DCP]
POWER_SUPPLY_VOLTAGE_MAX_DESIGN=5500000
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=3800000
POWER_SUPPLY_VOLTAGE_AVG=4516000

===== POWER-RELATED DMESG =====
$ dmesg | grep -Ei 'rk817|battery|charger|charge|power_supply' || true]]> Hardware
  • PineNote v1.2 (Community Edition)
  • Original factory-installed OS (never replaced or reinstalled)
  • Current kernel:
    Code:
    6.12.11-pinenote-202501281646-00249-g211ba27556cc
  • Installed kernel package:
    Code:
    linux-image-pinenote-stable 1.7
Timeline
The device arrived with approximately 40% battery.
I never installed an alternate operating system. The charging problem occurred on the factory-installed OS within the first day after unboxing.
The device operated normally from its initial battery charge but never successfully charged from any charger.
Eventually the battery discharged to 0%.
The interesting part is that the PineNote still boots and runs normally when external USB power is connected. I can SSH into it and run diagnostics. The only failure appears to be that the battery never actually charges.
Chargers Tested
I tested all of the following:
  • OEM USB-A ↔ USB-C cable
  • USB-A wall charger
  • USB-A laptop port
  • 65 W USB-C PD laptop charger
Behavior is identical with every charger.
When powered off and connected to power, the charging animation appears on the display.
I also left it connected overnight while powered off.
Battery level remained at 0%.
USB Issue
Initially the device was affected by the USB issue described in PNDeb Issue #106.
After applying the recommended fix:
Code:
lsusb
works normally.
USB connectivity appears completely functional now.
Charging behavior did not change.
This makes me think the USB problem and the charging problem are unrelated.
Diagnostics
Battery state:
Code:
cat /sys/class/power_supply/rk-bat/uevent
Relevant output:
Code:
POWER_SUPPLY_STATUS=Discharging
POWER_SUPPLY_CAPACITY=0
POWER_SUPPLY_CURRENT_AVG=-168560
POWER_SUPPLY_VOLTAGE_AVG=346xxxx
The important point is that the battery never transitions to:
Code:
POWER_SUPPLY_STATUS=Charging
even while external power is connected.
Charger state:
Code:
cat /sys/class/power_supply/usb/uevent
Relevant output:
Code:
POWER_SUPPLY_ONLINE=1
POWER_SUPPLY_USB_TYPE=Unknown [DCP]
POWER_SUPPLY_VOLTAGE_AVG=452xxxx
So Linux clearly detects external power.
Kernel messages:
Code:
dmesg | grep -i rk817
produces repeated messages similar to:
Code:
rk817-charger: Battery voltage 3465880 below minimum voltage 3500000
rk817-charger: Battery voltage 3477640 below minimum voltage 3500000
rk817-charger: Battery voltage 3483240 below minimum voltage 3500000
I do not see any other charger-related or battery-related errors.
Package Status
Kernel package is already current:
Code:
apt update
apt list --upgradable
apt policy linux-image-pinenote-stable
No newer PineNote kernel is available.
What Seems to Be Happening
From everything I've observed:
  • USB is functioning.
  • External power is detected.
  • Charger is detected (
    Code:
    ONLINE=1
    ).
  • Battery is detected.
  • The device boots and runs on external power.
  • The battery never enters the
    Code:
    Charging
    state.
  • Battery voltage remains below the RK817 minimum threshold (~3.5 V).
  • The battery never recovers, even after being connected overnight.
Questions
  1. Has anyone seen the RK817 refuse to perform pre-charge when the battery falls below approximately 3.5 V?
  2. Is there a known device-tree or kernel configuration issue that could prevent pre-charging?
  3. Is there a way to determine from software whether the battery protection circuit has tripped?
  4. Are there any additional diagnostics I should collect (debugfs, I2C register dumps, RK817 register reads, etc.)?
  5. Does this behavior point more toward a failed battery or charging hardware than a software problem?
Any guidance from people familiar with the RK817 charger implementation or PineNote power management would be greatly appreciated.


Here are various diagnostic commands and their return values:

===== DATE =====
$ date
Thu Jul  2 08:50:52 UTC 2026

===== KERNEL =====
$ uname -a
Linux pinenote 6.12.11-pinenote-202501281646-00249-g211ba27556cc #1 SMP Tue Jan 28 17:04:28 CST 2025 aarch64 GNU/Linux

===== OS RELEASE =====
$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux trixie/sid"
NAME="Debian GNU/Linux"
VERSION_CODENAME=trixie
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

===== KERNEL PACKAGE =====
$ dpkg -l | grep linux-image-pinenote || true
ii  linux-image-pinenote-stable                                    1.7                            all          Linux for the PineNote (meta-package)

===== POWER SUPPLY DEVICES =====
$ ls -l /sys/class/power_supply/
total 0
lrwxrwxrwx 1 root root 0 Jul 12  2026 rk817-battery -> ../../devices/platform/fdd40000.i2c/i2c-0/0-0020/rk817-charger.7.auto/power_supply/rk817-battery
lrwxrwxrwx 1 root root 0 Jul 12  2026 rk817-charger -> ../../devices/platform/fdd40000.i2c/i2c-0/0-0020/rk817-charger.7.auto/power_supply/rk817-charger

===== BATTERY SUMMARY =====
$ grep -E 'POWER_SUPPLY_(PRESENT|STATUS|CAPACITY|VOLTAGE_AVG|CURRENT_AVG|VOLTAGE_MIN_DESIGN|VOLTAGE_MAX_DESIGN|CHARGE_NOW|CHARGE_FULL|CHARGE_TYPE)' /sys/class/power_supply/rk817-battery/uevent
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_STATUS=Discharging
POWER_SUPPLY_CHARGE_TYPE=Standard
POWER_SUPPLY_CHARGE_FULL=4000000
POWER_SUPPLY_CHARGE_FULL_DESIGN=4000000
POWER_SUPPLY_CHARGE_NOW=1237024
POWER_SUPPLY_VOLTAGE_AVG=3750360
POWER_SUPPLY_CURRENT_AVG=-179912
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=3500000
POWER_SUPPLY_CAPACITY=31
POWER_SUPPLY_VOLTAGE_MAX_DESIGN=4200000

===== CHARGER SUMMARY =====
$ grep -E 'POWER_SUPPLY_(ONLINE|USB_TYPE|VOLTAGE_AVG|VOLTAGE_MIN_DESIGN|VOLTAGE_MAX_DESIGN)' /sys/class/power_supply/rk817-charger/uevent
POWER_SUPPLY_ONLINE=1
POWER_SUPPLY_USB_TYPE=Unknown [DCP]
POWER_SUPPLY_VOLTAGE_MAX_DESIGN=5500000
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=3800000
POWER_SUPPLY_VOLTAGE_AVG=4516000

===== FULL BATTERY UEVENT =====
$ cat /sys/class/power_supply/rk817-battery/uevent
DEVTYPE=power_supply
OF_NAME=charger
OF_FULLNAME=/i2c@fdd40000/pmic@20/charger
OF_COMPATIBLE_N=0
POWER_SUPPLY_NAME=rk817-battery
POWER_SUPPLY_TYPE=Battery
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_STATUS=Discharging
POWER_SUPPLY_CHARGE_TYPE=Standard
POWER_SUPPLY_CHARGE_FULL=4000000
POWER_SUPPLY_CHARGE_FULL_DESIGN=4000000
POWER_SUPPLY_CHARGE_EMPTY_DESIGN=0
POWER_SUPPLY_CHARGE_NOW=1237024
POWER_SUPPLY_CONSTANT_CHARGE_VOLTAGE_MAX=4200000
POWER_SUPPLY_VOLTAGE_AVG=3750360
POWER_SUPPLY_CONSTANT_CHARGE_CURRENT_MAX=2000000
POWER_SUPPLY_CURRENT_AVG=-179912
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=3500000
POWER_SUPPLY_CAPACITY=31
POWER_SUPPLY_VOLTAGE_MAX_DESIGN=4200000
POWER_SUPPLY_CHARGE_TERM_CURRENT=300000

===== FULL CHARGER UEVENT =====
$ cat /sys/class/power_supply/rk817-charger/uevent
DEVTYPE=power_supply
OF_NAME=charger
OF_FULLNAME=/i2c@fdd40000/pmic@20/charger
OF_COMPATIBLE_N=0
POWER_SUPPLY_NAME=rk817-charger
POWER_SUPPLY_TYPE=USB
POWER_SUPPLY_ONLINE=1
POWER_SUPPLY_USB_TYPE=Unknown [DCP]
POWER_SUPPLY_VOLTAGE_MAX_DESIGN=5500000
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=3800000
POWER_SUPPLY_VOLTAGE_AVG=4516000

===== POWER-RELATED DMESG =====
$ dmesg | grep -Ei 'rk817|battery|charger|charge|power_supply' || true]]> <![CDATA[How to change the PineNote's default sleep image?]]> https://forum.pine64.org/showthread.php?tid=20310 Wed, 01 Jul 2026 18:22:19 +0000 cameronharring]]> https://forum.pine64.org/showthread.php?tid=20310 While don't get me wrong, the image of the little flower pot is pretty, I would like to be able to do some more unique customizations. Thank you for any help in advance!]]> While don't get me wrong, the image of the little flower pot is pretty, I would like to be able to do some more unique customizations. Thank you for any help in advance!]]> <![CDATA[Manjaro affected by Arch supply chain rootkit]]> https://forum.pine64.org/showthread.php?tid=20308 Sun, 28 Jun 2026 16:45:42 +0000 tantamount]]> https://forum.pine64.org/showthread.php?tid=20308
https://threat-modeling.com/arch-linux-a...june-2026/]]>
https://threat-modeling.com/arch-linux-a...june-2026/]]> <![CDATA[Fix Bricked SPI Flash, Pinephone Pro]]> https://forum.pine64.org/showthread.php?tid=20305 Sat, 27 Jun 2026 23:00:41 +0000 FR_IV]]> https://forum.pine64.org/showthread.php?tid=20305 A couple weeks ago I was trying to write Tow-Boot to my Pinephone Pro's SPI Flash. It worked once, so I know that the SPI device is connected and functional. However, (unrelated to the Tow-Boot install) I messed up the Manjaro-Phosh installation I had previously installed on the Pinephone pro, so I reinstalled Manjaro-Phosh which removed Tow-Boot from the SPI flash. I tried to rewrite Tow-Boot in the same way as before, but it got stuck and I forced the Pinephone Pro to power-off. I then tried to write Tow-Boot again and I got the following error:

Code:
Checks failed... [ret = 4]
Nothing was done.

Details:
Error: /dev/mtdblock0 not found

$ dmesg | grep -i spi
---
[   1.176820] spi-nor spi0.0: unrecognized JEDEC id bytes: ff ff ff ff ff ff
[   1.184548] spi-nor: probe of spi0.0 failed with error -2
---

I booted the Pinephone Pro to the Manjaro-Phosh installation I put on it and I used fdisk -l and ls /dev/ but I did not find the SPI Flash nor any mtd or mtdblock devices.
I have reinstalled Manjaro to the Pinephone Pro through booting on an SD card and through connecting my Pinephone Pro to my computer as an external drive using the Tow-Boot installer booted on an SD card.
I have tried to write the Tow-Boot.spi.bin binary to the SPI through putting my phone in MaskRom mode and using the rkdeveloptool through the command line on my linux laptop.
I have tried to zero everything out with rkdeveloptool by writing zeros.
I booted the factory android image with the hardware test app on an SD card and the SPI Flash failed its test.
I tried all of these at least twice each and they have all returned no errors, but I still get the same error from the Tow-Boot installer and I still cannot find the SPI Flash device or any mtd or mtdblock devices.

Is there any way to revive the SPI device? Would it require wiring to it directly since nothing has been able to read it?
Thank you in advance!

I should note, that my Pinephone Pro boots to the internal emmc and to SD cards without a problem, so fixing the SPI is not vital to using my pinephone pro, but I don't like to loose available hardware and it would be nice to install Tow-Boot.]]> A couple weeks ago I was trying to write Tow-Boot to my Pinephone Pro's SPI Flash. It worked once, so I know that the SPI device is connected and functional. However, (unrelated to the Tow-Boot install) I messed up the Manjaro-Phosh installation I had previously installed on the Pinephone pro, so I reinstalled Manjaro-Phosh which removed Tow-Boot from the SPI flash. I tried to rewrite Tow-Boot in the same way as before, but it got stuck and I forced the Pinephone Pro to power-off. I then tried to write Tow-Boot again and I got the following error:

Code:
Checks failed... [ret = 4]
Nothing was done.

Details:
Error: /dev/mtdblock0 not found

$ dmesg | grep -i spi
---
[   1.176820] spi-nor spi0.0: unrecognized JEDEC id bytes: ff ff ff ff ff ff
[   1.184548] spi-nor: probe of spi0.0 failed with error -2
---

I booted the Pinephone Pro to the Manjaro-Phosh installation I put on it and I used fdisk -l and ls /dev/ but I did not find the SPI Flash nor any mtd or mtdblock devices.
I have reinstalled Manjaro to the Pinephone Pro through booting on an SD card and through connecting my Pinephone Pro to my computer as an external drive using the Tow-Boot installer booted on an SD card.
I have tried to write the Tow-Boot.spi.bin binary to the SPI through putting my phone in MaskRom mode and using the rkdeveloptool through the command line on my linux laptop.
I have tried to zero everything out with rkdeveloptool by writing zeros.
I booted the factory android image with the hardware test app on an SD card and the SPI Flash failed its test.
I tried all of these at least twice each and they have all returned no errors, but I still get the same error from the Tow-Boot installer and I still cannot find the SPI Flash device or any mtd or mtdblock devices.

Is there any way to revive the SPI device? Would it require wiring to it directly since nothing has been able to read it?
Thank you in advance!

I should note, that my Pinephone Pro boots to the internal emmc and to SD cards without a problem, so fixing the SPI is not vital to using my pinephone pro, but I don't like to loose available hardware and it would be nice to install Tow-Boot.]]> <![CDATA[Big thanks for the documentation!]]> https://forum.pine64.org/showthread.php?tid=20304 Thu, 25 Jun 2026 18:58:59 +0000 alchemist]]> https://forum.pine64.org/showthread.php?tid=20304
I am a happy and daily Pinebook Pro user since may 2021. The last years, I broke the USB-C port, then the keyboard panel at the left hinge.
I decided to replace the motherboard and keyboard panel, ordered the pieces and received them3 days after.

Then I had some free hours yesterday to fix my loved laptop. And I was really pleased by the well written documentation. I followed the section describing the different steps with very clear illustrations.
And in some minutes, I have a almost new shiny laptop.

Everything was immediately working except wifi and bluetooth, because the chips changed (BCM43456 to BCm43455) the new chip is supported by official linux firnware and same for bluetooth.

Very happy user  Cool]]>
I am a happy and daily Pinebook Pro user since may 2021. The last years, I broke the USB-C port, then the keyboard panel at the left hinge.
I decided to replace the motherboard and keyboard panel, ordered the pieces and received them3 days after.

Then I had some free hours yesterday to fix my loved laptop. And I was really pleased by the well written documentation. I followed the section describing the different steps with very clear illustrations.
And in some minutes, I have a almost new shiny laptop.

Everything was immediately working except wifi and bluetooth, because the chips changed (BCM43456 to BCm43455) the new chip is supported by official linux firnware and same for bluetooth.

Very happy user  Cool]]> <![CDATA[Pinecil low temp mods?]]> https://forum.pine64.org/showthread.php?tid=20301 Sun, 21 Jun 2026 08:53:32 +0000 davidcoley]]> https://forum.pine64.org/showthread.php?tid=20301 I'm a complete beginner to this area, but I'm interested in using a Pinecil V2 with wax for jewellery modelling. Before I buy one, I'm wondering whether it's possible to modify it to operate at around 60°C or lower while still maintaining accurate temperature control.

Has anyone tried this, or does anyone have experience using a Pinecil for wax work? I'd be interested to hear your thoughts, recommendations, or any potential limitations before I make a purchase.]]> I'm a complete beginner to this area, but I'm interested in using a Pinecil V2 with wax for jewellery modelling. Before I buy one, I'm wondering whether it's possible to modify it to operate at around 60°C or lower while still maintaining accurate temperature control.

Has anyone tried this, or does anyone have experience using a Pinecil for wax work? I'd be interested to hear your thoughts, recommendations, or any potential limitations before I make a purchase.]]> <![CDATA[can't find pam library]]> https://forum.pine64.org/showthread.php?tid=20300 Sun, 21 Jun 2026 00:04:58 +0000 fxkl47BF]]> https://forum.pine64.org/showthread.php?tid=20300
what package has this for postmarketos]]>
what package has this for postmarketos]]> <![CDATA[pmos firewall]]> https://forum.pine64.org/showthread.php?tid=20299 Sat, 20 Jun 2026 14:40:14 +0000 fxkl47BF]]> https://forum.pine64.org/showthread.php?tid=20299 using sudo nft list ruleset shows

tcp dport 24727 accept comment "accept connections for BundID AusweisApp2"

i think i have no use for this
not sure why it's automatically included]]> using sudo nft list ruleset shows

tcp dport 24727 accept comment "accept connections for BundID AusweisApp2"

i think i have no use for this
not sure why it's automatically included]]> <![CDATA["USB access to SD" disappeared on a Pinephone Pro]]> https://forum.pine64.org/showthread.php?tid=20297 Sat, 20 Jun 2026 00:40:20 +0000 jebez]]> https://forum.pine64.org/showthread.php?tid=20297 https://wiki.pine64.org/wiki/PinePhone_P...der_to_SPI , replacing ppp/spinor-flash-initial-setup.sh , inside ./rk2aw/rk2aw-spi-flasher --erase-all --rk2aw rk2aw/debug.img.spi : debug by normal, I redid with debug as original but still that issue.]]> https://wiki.pine64.org/wiki/PinePhone_P...der_to_SPI , replacing ppp/spinor-flash-initial-setup.sh , inside ./rk2aw/rk2aw-spi-flasher --erase-all --rk2aw rk2aw/debug.img.spi : debug by normal, I redid with debug as original but still that issue.]]> <![CDATA[asterisk or FreePBX on pinephone?]]> https://forum.pine64.org/showthread.php?tid=20292 Tue, 16 Jun 2026 15:24:37 +0000 vanja]]> https://forum.pine64.org/showthread.php?tid=20292 In theory, could i run some pbx server software on the pinephone, considering it already has sim card slot and modem, could be a low cost solution...
Motivation? Have your local simcard calls available worldwide over vpn...]]> In theory, could i run some pbx server software on the pinephone, considering it already has sim card slot and modem, could be a low cost solution...
Motivation? Have your local simcard calls available worldwide over vpn...]]> <![CDATA[Let's get the PPP and Mobian working!]]> https://forum.pine64.org/showthread.php?tid=20289 Mon, 15 Jun 2026 06:01:27 +0000 Rsquared]]> https://forum.pine64.org/showthread.php?tid=20289 If a noob like me can do it then so can you.

What are your thoughts on Mobian? Would you recommend something else?
Aside from the latest nightly, what specific version would you recommend?
Is there a particular phone/cell service you would recommend?

How do I get these parts working:
- Font Camera
- Rear Camera
- eSIM-card
- WiFi WPA3
- Encrypted Filesystem
- GPS
- Ironman Suit

Are there any power and battery management optimizations, tips and tricks?
Are they any Bluetooth, WiFi and Cellular tips you'd recommend for stability or problematic situations?]]> If a noob like me can do it then so can you.

What are your thoughts on Mobian? Would you recommend something else?
Aside from the latest nightly, what specific version would you recommend?
Is there a particular phone/cell service you would recommend?

How do I get these parts working:
- Font Camera
- Rear Camera
- eSIM-card
- WiFi WPA3
- Encrypted Filesystem
- GPS
- Ironman Suit

Are there any power and battery management optimizations, tips and tricks?
Are they any Bluetooth, WiFi and Cellular tips you'd recommend for stability or problematic situations?]]> <![CDATA[Avaota A1 - Mainline]]> https://forum.pine64.org/showthread.php?tid=20281 Mon, 01 Jun 2026 13:16:01 +0000 sam_uk]]> https://forum.pine64.org/showthread.php?tid=20281 https://pine64.com/product/yuzuki-avaota...-4gb-32gb/

Trying to get mainline on it: https://github.com/Agroecology-Lab/build

Running into issues with it https://github.com/Agroecology-Lab/build/issues/1

If anyone wants to play along or help that would be great]]> https://pine64.com/product/yuzuki-avaota...-4gb-32gb/

Trying to get mainline on it: https://github.com/Agroecology-Lab/build

Running into issues with it https://github.com/Agroecology-Lab/build/issues/1

If anyone wants to play along or help that would be great]]> <![CDATA[Totally disabling auto-boot when charger is plugged in?]]> https://forum.pine64.org/showthread.php?tid=20279 Sat, 30 May 2026 16:28:09 +0000 A Mnesia]]> https://forum.pine64.org/showthread.php?tid=20279
Is there any way to totally and completely disable this auto-boot behavior?

Thank you very much in advance.]]>
Is there any way to totally and completely disable this auto-boot behavior?

Thank you very much in advance.]]> <![CDATA[Pine a64 lcd]]> https://forum.pine64.org/showthread.php?tid=20277 Thu, 28 May 2026 07:12:48 +0000 shinzuka]]> https://forum.pine64.org/showthread.php?tid=20277 <![CDATA[RockPro64 automatically run after power recovery - my solution]]> https://forum.pine64.org/showthread.php?tid=20274 Mon, 25 May 2026 10:57:03 +0000 g2t]]> https://forum.pine64.org/showthread.php?tid=20274 Motivation
Since some years my system (Rockpro64 V2.1 2018-07-02) is not starting properly after a power loss, with increasing occurrence. It seems after some hours of power loss (e.g. over night) it is working more reliable, but when waiting only a few minutes this is not working anymore at all. Only the power button can be used for startup my system reliable.

In the forum there can be find a similar thread with some general information about the schematic and some measurements with a new system. Many thanks to for his investigations on a  new board. This was the base for my investigations and I solved it finally. I will describe my work step by step now, so others can repeat it and hopefully fix there system. If someone can give me an advice how to add/upload pictures, I will add my photos, so you can see what I have done.

Repeat the same measurement
"PMIC" is measured on C205 (right side) and "VCC5V0_SYS" is measured on C2006 (left side). Both can be found on top of the circuit board. The measurement results nearly equal the results from "Nikolay_Po" (the colours yellow and blue are interchanged in my measurement). So, perhaps, not the discrete components has changed its behavior but something inside RK808 changes over time. Or, the original values of the discrete components are chosen very close to the borders of the PMIC-system. No matter what it is, we can only change the discrete components - C204 catches my attention first.

Measure around and modify C204
The capacitor C204 can be found on the bottom of the circuit board (SD card slot at bottom left), in the area between C164 and C168, left of the resistor R89 and over the resistor R88. Another description: between the both big capacitor (C164 and C168) there are 4 small components in a flipped L-shape. C204 is the one in the corner of the "L".

The measurement was done with 2 channels, connected left and right of the C204 component. This means one is "VCC5V0_SYS" and the other one is the connection between C204, R89, D5 (soldered on the top side) and R88.

Try to increase the capacitor C204
Because it was working with a brand new board, most likely some aging process has changed the timings a bit. A second capacitor will increase the peak and the time a bit and maybe this can fix the problem. I added two connectors with wires left and right besides C204 and was able to add a second capacitor in parallel with an alligator clip.

1. choose 1uF --> working 100%
2. choose 100nF --> working 100%

Fix by soldering a SMD capacitor on top of C204
I disassembled some small SMD capacitors from a old circuit board and found one with around 150nF. This part I soldered on top of the C204 capacitor and this really fixed the problem for now.]]> Motivation
Since some years my system (Rockpro64 V2.1 2018-07-02) is not starting properly after a power loss, with increasing occurrence. It seems after some hours of power loss (e.g. over night) it is working more reliable, but when waiting only a few minutes this is not working anymore at all. Only the power button can be used for startup my system reliable.

In the forum there can be find a similar thread with some general information about the schematic and some measurements with a new system. Many thanks to for his investigations on a  new board. This was the base for my investigations and I solved it finally. I will describe my work step by step now, so others can repeat it and hopefully fix there system. If someone can give me an advice how to add/upload pictures, I will add my photos, so you can see what I have done.

Repeat the same measurement
"PMIC" is measured on C205 (right side) and "VCC5V0_SYS" is measured on C2006 (left side). Both can be found on top of the circuit board. The measurement results nearly equal the results from "Nikolay_Po" (the colours yellow and blue are interchanged in my measurement). So, perhaps, not the discrete components has changed its behavior but something inside RK808 changes over time. Or, the original values of the discrete components are chosen very close to the borders of the PMIC-system. No matter what it is, we can only change the discrete components - C204 catches my attention first.

Measure around and modify C204
The capacitor C204 can be found on the bottom of the circuit board (SD card slot at bottom left), in the area between C164 and C168, left of the resistor R89 and over the resistor R88. Another description: between the both big capacitor (C164 and C168) there are 4 small components in a flipped L-shape. C204 is the one in the corner of the "L".

The measurement was done with 2 channels, connected left and right of the C204 component. This means one is "VCC5V0_SYS" and the other one is the connection between C204, R89, D5 (soldered on the top side) and R88.

Try to increase the capacitor C204
Because it was working with a brand new board, most likely some aging process has changed the timings a bit. A second capacitor will increase the peak and the time a bit and maybe this can fix the problem. I added two connectors with wires left and right besides C204 and was able to add a second capacitor in parallel with an alligator clip.

1. choose 1uF --> working 100%
2. choose 100nF --> working 100%

Fix by soldering a SMD capacitor on top of C204
I disassembled some small SMD capacitors from a old circuit board and found one with around 150nF. This part I soldered on top of the C204 capacitor and this really fixed the problem for now.]]>