<![CDATA[PINE64 - PinePhone Pro Software]]> https://forum.pine64.org/ Mon, 18 May 2026 07:21:59 +0000 MyBB <![CDATA[Upgrading from Trixie to Forky in late 2025(proposal)(tested works for me)]]> https://forum.pine64.org/showthread.php?tid=20047 Mon, 20 Oct 2025 08:39:13 +0000 biketool]]> https://forum.pine64.org/showthread.php?tid=20047 This is a proposal for a guide to upgrade to Forky(Mobian testing) from Trixie(the previous testing release)
This has now been tested!!! it worked for me on my PPpro.
https://blog.mobian.org/posts/2025/10/ne...ting-keys/
It seems there are errors but we can fix these.

I will first recommend everyone with disk space use the tow-boot blue light special bulk storage mode and save the / of your PP or PPp to your computer, this will take a while to do but even if encryptde is pretty easy, in my ubuntu derivitave OS the GUI asked if I wanted to decrypt the volume, entered password, and I had access to my root.  A alternative is to use a USB mass storage device over an adapter or a big SD card to save your root or at least your /home.

below is form the guide linked above with some lined out do-not instructions and my edits in green 
_______________________________________________________________

  1. keep your device plugged to a power source: such an upgrade can be a rather long process, you don’t want to run out of battery half-way there!
  2. backup all your personal data
  3. really, we mean it: backup all your personal data!
  4. install
    Code:
    sudo apt install openssh-server
    and execute the entire upgrade process over SSH (and preferrably using
    Code:
    sudo apt install screen
    or a similar tool, so the upgrade can carry on even if the network connection is lost)
  5. ensure your Trixie installation is fully up-to-date; as the GPG key we use for signing the package repository has expired since the Bookworm release, you’ll probably need to run
    Code:
    sudo apt update && sudo apt dist-upgrade
    at least twice: the first time it will update the Mobian keyring package, the second invocation will pull in the latest updates for Mobian-specific packages
    reboot,
  6. then edit both 
    Code:
    sudo vi /etc/apt/sources.list.d/debian.sources
    and
    Code:
    sudo vi /etc/apt/sources.list.d/mobian.sources
    , replacing all occurences of trixie with forky in both files; forky
  7. (not sure this step is required in trixie to forky)you should then stop the
    Code:
    sudo service greetd stop
    service (this will stop all running graphical applications, and is why SSH is needed!) and run
    Code:
    sudo apt update && sudo apt dist-upgrade
    once again
  8. (trixie to forky I didn't need this as only 2 packages were removed non-mobian both)write down the list of packages removed by
    Code:
    sudo apt dist-upgrade
    which start with
    Code:
    mobian-
    as those will have to be reinstalled later on to restore full functionality of your device; please note that some packages have been renamed/replaced in Trixie, so it can be expected to see e.g.
    Code:
    phog
    or
    Code:
    pinephonepro-tweaks
    in the list of removed packages
  9. reinstall all
    Code:
    mobian-*
    packages removed in the previous step; this will remove
    Code:
    pulseaudio
    from the system, which is to be expected as Mobian now relies on (and mandates the use of) PipeWire(already done in the trixie upgrade form bookworm)
  10. run
    Code:
    sudo apt autoremove
    to clean up unneeded packages


________________________________________________

I have tested this now, but everyone have a look, does this look correct, did I miss something obvious?  it seems that an apt update && apt upgrade will update the signing crypto keys so we dont need to dl that for a trixie to forky upgrade which is far cleaner than bookworm to trixie.]]> This is a proposal for a guide to upgrade to Forky(Mobian testing) from Trixie(the previous testing release)
This has now been tested!!! it worked for me on my PPpro.
https://blog.mobian.org/posts/2025/10/ne...ting-keys/
It seems there are errors but we can fix these.

I will first recommend everyone with disk space use the tow-boot blue light special bulk storage mode and save the / of your PP or PPp to your computer, this will take a while to do but even if encryptde is pretty easy, in my ubuntu derivitave OS the GUI asked if I wanted to decrypt the volume, entered password, and I had access to my root.  A alternative is to use a USB mass storage device over an adapter or a big SD card to save your root or at least your /home.

below is form the guide linked above with some lined out do-not instructions and my edits in green 
_______________________________________________________________

  1. keep your device plugged to a power source: such an upgrade can be a rather long process, you don’t want to run out of battery half-way there!
  2. backup all your personal data
  3. really, we mean it: backup all your personal data!
  4. install
    Code:
    sudo apt install openssh-server
    and execute the entire upgrade process over SSH (and preferrably using
    Code:
    sudo apt install screen
    or a similar tool, so the upgrade can carry on even if the network connection is lost)
  5. ensure your Trixie installation is fully up-to-date; as the GPG key we use for signing the package repository has expired since the Bookworm release, you’ll probably need to run
    Code:
    sudo apt update && sudo apt dist-upgrade
    at least twice: the first time it will update the Mobian keyring package, the second invocation will pull in the latest updates for Mobian-specific packages
    reboot,
  6. then edit both 
    Code:
    sudo vi /etc/apt/sources.list.d/debian.sources
    and
    Code:
    sudo vi /etc/apt/sources.list.d/mobian.sources
    , replacing all occurences of trixie with forky in both files; forky
  7. (not sure this step is required in trixie to forky)you should then stop the
    Code:
    sudo service greetd stop
    service (this will stop all running graphical applications, and is why SSH is needed!) and run
    Code:
    sudo apt update && sudo apt dist-upgrade
    once again
  8. (trixie to forky I didn't need this as only 2 packages were removed non-mobian both)write down the list of packages removed by
    Code:
    sudo apt dist-upgrade
    which start with
    Code:
    mobian-
    as those will have to be reinstalled later on to restore full functionality of your device; please note that some packages have been renamed/replaced in Trixie, so it can be expected to see e.g.
    Code:
    phog
    or
    Code:
    pinephonepro-tweaks
    in the list of removed packages
  9. reinstall all
    Code:
    mobian-*
    packages removed in the previous step; this will remove
    Code:
    pulseaudio
    from the system, which is to be expected as Mobian now relies on (and mandates the use of) PipeWire(already done in the trixie upgrade form bookworm)
  10. run
    Code:
    sudo apt autoremove
    to clean up unneeded packages


________________________________________________

I have tested this now, but everyone have a look, does this look correct, did I miss something obvious?  it seems that an apt update && apt upgrade will update the signing crypto keys so we dont need to dl that for a trixie to forky upgrade which is far cleaner than bookworm to trixie.]]> <![CDATA[Diagnosing and fixing failure to wake from suspend(Diagnosed HW issue)]]> https://forum.pine64.org/showthread.php?tid=20046 Mon, 20 Oct 2025 08:05:36 +0000 biketool]]> https://forum.pine64.org/showthread.php?tid=20046 https://forum.pine64.org/showthread.php?tid=19940

My issue is that unless I run the caffeine toggled on my phone falls into a suspend coma nad no charge cable, phone call, or wake button brings it back.  If the indicator LED was blinking it will continue,it might have even been one case where an audiobook was running and I couldnt get it back thoug that might be the intermittent non function of the wake/sleep button in the OS(holding still triggers a shutdown).

I do NOT have a serial cable to get the logs right at the fall into suspend coma.]]> https://forum.pine64.org/showthread.php?tid=19940

My issue is that unless I run the caffeine toggled on my phone falls into a suspend coma nad no charge cable, phone call, or wake button brings it back.  If the indicator LED was blinking it will continue,it might have even been one case where an audiobook was running and I couldnt get it back thoug that might be the intermittent non function of the wake/sleep button in the OS(holding still triggers a shutdown).

I do NOT have a serial cable to get the logs right at the fall into suspend coma.]]> <![CDATA[Bare metal on Pinephone Pro]]> https://forum.pine64.org/showthread.php?tid=19956 Tue, 19 Aug 2025 13:58:12 +0000 alain]]> https://forum.pine64.org/showthread.php?tid=19956
I would like to boot a bare metal program (that just starts and enters in an infinite loop) (asm+c) on my ppp thank to U-Boot, but U-Boot don't boot my program and blinks the multicolor led in red, and then shut down. What's wrong in my code ? 

start.S
Code:
    .global start
start:
    msr        DAIFSet, #7

    bl        main

spin:    b        spin

spl.lds
Code:
ENTRY(start)

SECTIONS
{
    . = 0x02000000;

    . = ALIGN(4);
    .text :
    {
        *(.text)
    }

    . = ALIGN(4);
    .rodata : { *(.rodata*) }

    . = ALIGN(4);
    .data : { *(.data*) }

    . = ALIGN(4);
    .got : { *(.got) }

    _end = .;

    . = ALIGN(8);
    __bss_start__ = .;
    .bss_start (OVERLAY) : {
        KEEP(*(.__bss_start));
        __bss_base = .;
    }
    .bss __bss_base (OVERLAY) : {
        *(.bss*)
        . = ALIGN(4);
        __bss_limit = .;
    }
    .bss_end __bss_limit (OVERLAY) : {
        KEEP(*(.__bss_end));
    }
    __bss_end__ = .;
}

main.c
Code:
/*
*
* Tom Trebisky  12-31-2021
*/

typedef volatile unsigned int vu32;
typedef unsigned int u32;

struct gpio {
    vu32 data;
    vu32 dir;
    u32 _pad0[2];

    u32 _pad1[8];

    vu32 ie;
    vu32 im;
    vu32 il;
    vu32 ip;

    vu32 is;
    vu32 ris;
    vu32 debounce;
    vu32 eoi;

    vu32 ext;
    u32 _pad2[3];

    vu32 sync;
};

#define GPIO0_BASE ((struct gpio *) 0xff720000)
#define GPIO1_BASE ((struct gpio *) 0xff730000)

#define GPIO2_BASE ((struct gpio *) 0xff780000)
#define GPIO3_BASE ((struct gpio *) 0xff788000)
#define GPIO4_BASE ((struct gpio *) 0xff790000)

#define GPIO_BASE GPIO0_BASE

#define LED_BIT        (8+3)
#define LED_PIN 24
#define LED_MASK 1<<LED_PIN

void main ( void ) {
    volatile int count = 100000000;

    while ( count-- )
        ;
}

Makefile
Code:
BOARD = rk3399
CROSS_COMPILE = aarch64-linux-gnu-

# -------------------------------------

OBJS = start.o main.o

TARGET = $(BOARD).bin

# CFLAGS        :=    -g -Wall -Wextra -ffreestanding -fno-builtin -mlittle-endian
CFLAGS        :=    -g -Wall -ffreestanding -fno-builtin -mlittle-endian
CFLAGS        += -march=armv8-a+crc
CFLAGS        += -mtune=cortex-a53
CFLAGS        += -I.

LDFLAGS        :=    -Bstatic \
            -Tspl.lds \
            -Wl,--start-group \
            -Wl,--end-group \
            -Wl,--build-id=none \
            -nostdlib

CC            =    $(CROSS_COMPILE)gcc $(CFLAGS)
LD             =    $(CROSS_COMPILE)gcc $(LDFLAGS)
OBJCOPY            =    $(CROSS_COMPILE)objcopy
DUMP            =    $(CROSS_COMPILE)objdump

LOAD            =    tools/loader -h64

# This gives us dependencies in .d files.
# CFLAGS        += -MMD
# This gives us a map file.
# CFLAGS        += -Wl,-Map=$(BOARD).map,--cref \

.c.o:
    @echo " [CC]   $<"
    @$(CC) $< -c -o $@

.S.o:
    @echo " [CC]   $<"
    @$(CC) $< -c -o $@

# -------------------------------------

all: install
#all: $(TARGET)

install: $(TARGET)
#     cp $(TARGET) /var/lib/tftpboot


$(BOARD).elf: $(OBJS)
    @echo " [LD]   $(BOARD).elf"
    @$(LD) $(OBJS) -o $(BOARD).elf

$(TARGET): $(BOARD).elf
    @#echo " [IMG]  $(TARGET)
    @$(OBJCOPY) -O binary $(BOARD).elf $(TARGET)

dis: $(BOARD).elf
    $(DUMP) -d $(BOARD).elf -z >$(BOARD).dis

fetch:
    cp ../USB_loader/loader tools

usb:  $(TARGET)
    $(LOAD) $(TARGET)

sdcard:  $(TARGET)
    $(LOAD) -o $(TARGET) | dd of=/dev/sdf seek=1 conv=fdatasync

.PHONY: clean
clean:
    rm -f *.o
    rm -f *.img
    rm -f *.elf
    rm -f *.bin
    rm -f *.map
    rm -f *.dis
]]>
I would like to boot a bare metal program (that just starts and enters in an infinite loop) (asm+c) on my ppp thank to U-Boot, but U-Boot don't boot my program and blinks the multicolor led in red, and then shut down. What's wrong in my code ? 

start.S
Code:
    .global start
start:
    msr        DAIFSet, #7

    bl        main

spin:    b        spin

spl.lds
Code:
ENTRY(start)

SECTIONS
{
    . = 0x02000000;

    . = ALIGN(4);
    .text :
    {
        *(.text)
    }

    . = ALIGN(4);
    .rodata : { *(.rodata*) }

    . = ALIGN(4);
    .data : { *(.data*) }

    . = ALIGN(4);
    .got : { *(.got) }

    _end = .;

    . = ALIGN(8);
    __bss_start__ = .;
    .bss_start (OVERLAY) : {
        KEEP(*(.__bss_start));
        __bss_base = .;
    }
    .bss __bss_base (OVERLAY) : {
        *(.bss*)
        . = ALIGN(4);
        __bss_limit = .;
    }
    .bss_end __bss_limit (OVERLAY) : {
        KEEP(*(.__bss_end));
    }
    __bss_end__ = .;
}

main.c
Code:
/*
*
* Tom Trebisky  12-31-2021
*/

typedef volatile unsigned int vu32;
typedef unsigned int u32;

struct gpio {
    vu32 data;
    vu32 dir;
    u32 _pad0[2];

    u32 _pad1[8];

    vu32 ie;
    vu32 im;
    vu32 il;
    vu32 ip;

    vu32 is;
    vu32 ris;
    vu32 debounce;
    vu32 eoi;

    vu32 ext;
    u32 _pad2[3];

    vu32 sync;
};

#define GPIO0_BASE ((struct gpio *) 0xff720000)
#define GPIO1_BASE ((struct gpio *) 0xff730000)

#define GPIO2_BASE ((struct gpio *) 0xff780000)
#define GPIO3_BASE ((struct gpio *) 0xff788000)
#define GPIO4_BASE ((struct gpio *) 0xff790000)

#define GPIO_BASE GPIO0_BASE

#define LED_BIT        (8+3)
#define LED_PIN 24
#define LED_MASK 1<<LED_PIN

void main ( void ) {
    volatile int count = 100000000;

    while ( count-- )
        ;
}

Makefile
Code:
BOARD = rk3399
CROSS_COMPILE = aarch64-linux-gnu-

# -------------------------------------

OBJS = start.o main.o

TARGET = $(BOARD).bin

# CFLAGS        :=    -g -Wall -Wextra -ffreestanding -fno-builtin -mlittle-endian
CFLAGS        :=    -g -Wall -ffreestanding -fno-builtin -mlittle-endian
CFLAGS        += -march=armv8-a+crc
CFLAGS        += -mtune=cortex-a53
CFLAGS        += -I.

LDFLAGS        :=    -Bstatic \
            -Tspl.lds \
            -Wl,--start-group \
            -Wl,--end-group \
            -Wl,--build-id=none \
            -nostdlib

CC            =    $(CROSS_COMPILE)gcc $(CFLAGS)
LD             =    $(CROSS_COMPILE)gcc $(LDFLAGS)
OBJCOPY            =    $(CROSS_COMPILE)objcopy
DUMP            =    $(CROSS_COMPILE)objdump

LOAD            =    tools/loader -h64

# This gives us dependencies in .d files.
# CFLAGS        += -MMD
# This gives us a map file.
# CFLAGS        += -Wl,-Map=$(BOARD).map,--cref \

.c.o:
    @echo " [CC]   $<"
    @$(CC) $< -c -o $@

.S.o:
    @echo " [CC]   $<"
    @$(CC) $< -c -o $@

# -------------------------------------

all: install
#all: $(TARGET)

install: $(TARGET)
#     cp $(TARGET) /var/lib/tftpboot


$(BOARD).elf: $(OBJS)
    @echo " [LD]   $(BOARD).elf"
    @$(LD) $(OBJS) -o $(BOARD).elf

$(TARGET): $(BOARD).elf
    @#echo " [IMG]  $(TARGET)
    @$(OBJCOPY) -O binary $(BOARD).elf $(TARGET)

dis: $(BOARD).elf
    $(DUMP) -d $(BOARD).elf -z >$(BOARD).dis

fetch:
    cp ../USB_loader/loader tools

usb:  $(TARGET)
    $(LOAD) $(TARGET)

sdcard:  $(TARGET)
    $(LOAD) -o $(TARGET) | dd of=/dev/sdf seek=1 conv=fdatasync

.PHONY: clean
clean:
    rm -f *.o
    rm -f *.img
    rm -f *.elf
    rm -f *.bin
    rm -f *.map
    rm -f *.dis
]]> <![CDATA[Experimental Mobian kernel patch for extended battery life]]> https://forum.pine64.org/showthread.php?tid=19940 Wed, 06 Aug 2025 07:40:39 +0000 teekay]]> https://forum.pine64.org/showthread.php?tid=19940
Note that suspend doesn't work in this kernel, I am looking into this [UPDATE: Suspend works now]. One additional bonus with this kernel is that if you uninstall the default Camera app, then install Camera from Flathub, it should work fine with both front and back cameras, you can take photos and scan QR codes and the image is not inverted on the back camera.

Let me know if you try it out.

https://cloud.nextcloudhosting.co.za/ind...7G4X6NGY8w]]>
Note that suspend doesn't work in this kernel, I am looking into this [UPDATE: Suspend works now]. One additional bonus with this kernel is that if you uninstall the default Camera app, then install Camera from Flathub, it should work fine with both front and back cameras, you can take photos and scan QR codes and the image is not inverted on the back camera.

Let me know if you try it out.

https://cloud.nextcloudhosting.co.za/ind...7G4X6NGY8w]]> <![CDATA[many distros getting too "heavy" for the PPP hardware; which runs well for you?]]> https://forum.pine64.org/showthread.php?tid=19907 Wed, 16 Jul 2025 18:15:41 +0000 dchang0]]> https://forum.pine64.org/showthread.php?tid=19907
It's nice but man is it slow/laggy. Push a button, count out loud 1-1000, 2-1000, 3-1000 and then the action happens.

So far, the only highly-performant current-day distro I have found is PostmarketOS 24 with SXMO de Sway. That's fast, but of course that's not too surprising given that it is running a window manager and not a desktop environment.

What else out of current-day distros run decently? I'd like to try them.

Thanks!]]>
It's nice but man is it slow/laggy. Push a button, count out loud 1-1000, 2-1000, 3-1000 and then the action happens.

So far, the only highly-performant current-day distro I have found is PostmarketOS 24 with SXMO de Sway. That's fast, but of course that's not too surprising given that it is running a window manager and not a desktop environment.

What else out of current-day distros run decently? I'd like to try them.

Thanks!]]> <![CDATA[Calls on ppp]]> https://forum.pine64.org/showthread.php?tid=19833 Mon, 12 May 2025 16:34:58 +0000 chbwzxgk]]> https://forum.pine64.org/showthread.php?tid=19833 <![CDATA[FreeBSD developer build for PinePhone Pro]]> https://forum.pine64.org/showthread.php?tid=19819 Sun, 27 Apr 2025 07:29:37 +0000 teekay]]> https://forum.pine64.org/showthread.php?tid=19819 report that I am releasing a developer build that you can try out:                                                   
                                                                     
https://codeberg.org/Honeyguide/freebsd-...o#releases         
                                                                     
Please test and report back! Any feedback would be helpful.                                                     
                                                                     
If you are a FreeBSD developer, the image contains the kernel source, 
build tools, vim, and an example driver that you can use to start     
implementing or porting drivers directly on-device.]]> report that I am releasing a developer build that you can try out:                                                   
                                                                     
https://codeberg.org/Honeyguide/freebsd-...o#releases         
                                                                     
Please test and report back! Any feedback would be helpful.                                                     
                                                                     
If you are a FreeBSD developer, the image contains the kernel source, 
build tools, vim, and an example driver that you can use to start     
implementing or porting drivers directly on-device.]]> <![CDATA[the camera apps does not work on arch linux sxmo]]> https://forum.pine64.org/showthread.php?tid=19807 Mon, 21 Apr 2025 09:08:11 +0000 moriartyo]]> https://forum.pine64.org/showthread.php?tid=19807 <![CDATA[Debian vs Mobian]]> https://forum.pine64.org/showthread.php?tid=19767 Mon, 31 Mar 2025 03:52:07 +0000 henrythemouse]]> https://forum.pine64.org/showthread.php?tid=19767
Code:
apt list phosh* --installed

phosh-common/testing,now 0.45.0-1 all [installed,automatic]
phosh-core/testing,now 44 arm64 [installed,automatic]
phosh-full/testing,now 44 arm64 [installed,automatic]
phosh-games/testing,now 44 all [installed,automatic]
phosh-mobile-settings/testing,now 0.45.0-1 arm64 [installed]
phosh-mobile-tweaks/testing,now 0.45.0-1 all [installed]
phosh-osk-stub/testing,now 0.45.0-1 arm64 [installed]
phosh-pim/testing,now 44 arm64 [installed]
phosh-plugins/testing,now 0.45.0-1 arm64 [installed,automatic]
phosh-tour/testing,now 0.45.0-1 arm64 [installed]
phosh-wallpapers/testing,now 0.42.0-1 all [installed,automatic]
phosh/testing,now 0.45.0-1 arm64 [installed,automatic]

apt list mobian* --installed

mobian-archive-keyring/testing,now 20240504.0 all [installed]
mobian-base/trixie,now 0.5.1 all [installed]
mobian-multimedia/trixie,now 0.5.1 all [installed,automatic]
mobian-phone-base/trixie,now 0.5.1 all [installed]
mobian-phosh-base/trixie,now 0.5.1 all [installed]
mobian-phosh-extras/trixie,now 0.5.1 all [installed,automatic]
mobian-phosh/trixie,now 0.5.1 all [installed]
mobian-tweaks-common/trixie,now 0.6.1 all [installed,automatic]
mobian-tweaks-phosh/trixie,now 0.6.1 all [installed,automatic]

I also have this mobian pin from a year ago.

Code:
cat /etc/apt/preferences.d/00-mobian-priority
Package: *
Pin: release o=Mobian
Pin-Priority: 700

Some or all of these packages may include duplicate code. I'm wondering if I should be using the Mobian repo at all. I've done some ducking to try to get information one way or the other, but found nothing definitive. I've looked on my phone under software/repositories and it no longer lists any software repos (other than flatpak). Upon review many of these packages are meta packages with overlapping requirements.

Is anyone using pure debian?]]>
Code:
apt list phosh* --installed

phosh-common/testing,now 0.45.0-1 all [installed,automatic]
phosh-core/testing,now 44 arm64 [installed,automatic]
phosh-full/testing,now 44 arm64 [installed,automatic]
phosh-games/testing,now 44 all [installed,automatic]
phosh-mobile-settings/testing,now 0.45.0-1 arm64 [installed]
phosh-mobile-tweaks/testing,now 0.45.0-1 all [installed]
phosh-osk-stub/testing,now 0.45.0-1 arm64 [installed]
phosh-pim/testing,now 44 arm64 [installed]
phosh-plugins/testing,now 0.45.0-1 arm64 [installed,automatic]
phosh-tour/testing,now 0.45.0-1 arm64 [installed]
phosh-wallpapers/testing,now 0.42.0-1 all [installed,automatic]
phosh/testing,now 0.45.0-1 arm64 [installed,automatic]

apt list mobian* --installed

mobian-archive-keyring/testing,now 20240504.0 all [installed]
mobian-base/trixie,now 0.5.1 all [installed]
mobian-multimedia/trixie,now 0.5.1 all [installed,automatic]
mobian-phone-base/trixie,now 0.5.1 all [installed]
mobian-phosh-base/trixie,now 0.5.1 all [installed]
mobian-phosh-extras/trixie,now 0.5.1 all [installed,automatic]
mobian-phosh/trixie,now 0.5.1 all [installed]
mobian-tweaks-common/trixie,now 0.6.1 all [installed,automatic]
mobian-tweaks-phosh/trixie,now 0.6.1 all [installed,automatic]

I also have this mobian pin from a year ago.

Code:
cat /etc/apt/preferences.d/00-mobian-priority
Package: *
Pin: release o=Mobian
Pin-Priority: 700

Some or all of these packages may include duplicate code. I'm wondering if I should be using the Mobian repo at all. I've done some ducking to try to get information one way or the other, but found nothing definitive. I've looked on my phone under software/repositories and it no longer lists any software repos (other than flatpak). Upon review many of these packages are meta packages with overlapping requirements.

Is anyone using pure debian?]]> <![CDATA[Battery Management on PinePhonePro:]]> https://forum.pine64.org/showthread.php?tid=19716 Sat, 01 Mar 2025 16:42:29 +0000 d50zesl0g@mozmail.com]]> https://forum.pine64.org/showthread.php?tid=19716
Here’s how the scripts work under various conditions:
  • Standard Charging: The phone charges to a predetermined upper limit (like 90%) and then stops to prevent battery strain.

  • Continuous Power Supply: If it remains plugged in post-charge, the phone priorities drawing power directly off the charger, sparing the battery , and only use the battery if the power supply is not producing enough juice.

  • Reconnection Nuances: Unplugging and replugging doesn’t immediately resume charging. It waits until the battery drops below a set lower threshold (say, 60%), which helps in maintaining battery health by avoiding short, unnecessary charge cycles.

  • Handling Power Fluctuations: For those times when the power source is unstable or you’re frequently plugging and unplugging, the script ensures that repetitive charging doesn’t kick in unless truly needed.

  • Customization: The thresholds for both the upper and lower limits can be adjusted to fit personal usage patterns and battery longevity goals.


Project Repositories:

    For PinePhonePro: https://github.com/alivellani/manage_pinephone_bat_temp
    Librem 5: https://github.com/alivellani/manage_librem_battery

On the PinePhonePro, managing this is pretty straightforward because the driver includes a ‘charge behavior’ driver that you can manipulate directly. For the PinePhonePro, you can find the charge behaviour control at this path:

/sys/class/power_supply/{battery_type}/charge_behaviour

The Librem 5, however, threw a curveball my way. It doesn’t support modifying charge behavior through the usual driver settings. The workaround I found on the wiki, using the charge LED as a control point. Here’s how I control it:

/sys/class/leds/chg_en/brightness

This lets me toggle the charging on and off

I have attached a Anker Zolo power bank to the back of the phone which keep providing power to the pinephonepro with a velcro tape. And I just charge the power bank.

Heads-up: This setup is still very much DIY. Make sure you really dig into the scripts before deploying them. If your phone turns into Charmander that is all on you!

Cheers!]]>
Here’s how the scripts work under various conditions:
  • Standard Charging: The phone charges to a predetermined upper limit (like 90%) and then stops to prevent battery strain.

  • Continuous Power Supply: If it remains plugged in post-charge, the phone priorities drawing power directly off the charger, sparing the battery , and only use the battery if the power supply is not producing enough juice.

  • Reconnection Nuances: Unplugging and replugging doesn’t immediately resume charging. It waits until the battery drops below a set lower threshold (say, 60%), which helps in maintaining battery health by avoiding short, unnecessary charge cycles.

  • Handling Power Fluctuations: For those times when the power source is unstable or you’re frequently plugging and unplugging, the script ensures that repetitive charging doesn’t kick in unless truly needed.

  • Customization: The thresholds for both the upper and lower limits can be adjusted to fit personal usage patterns and battery longevity goals.


Project Repositories:

    For PinePhonePro: https://github.com/alivellani/manage_pinephone_bat_temp
    Librem 5: https://github.com/alivellani/manage_librem_battery

On the PinePhonePro, managing this is pretty straightforward because the driver includes a ‘charge behavior’ driver that you can manipulate directly. For the PinePhonePro, you can find the charge behaviour control at this path:

/sys/class/power_supply/{battery_type}/charge_behaviour

The Librem 5, however, threw a curveball my way. It doesn’t support modifying charge behavior through the usual driver settings. The workaround I found on the wiki, using the charge LED as a control point. Here’s how I control it:

/sys/class/leds/chg_en/brightness

This lets me toggle the charging on and off

I have attached a Anker Zolo power bank to the back of the phone which keep providing power to the pinephonepro with a velcro tape. And I just charge the power bank.

Heads-up: This setup is still very much DIY. Make sure you really dig into the scripts before deploying them. If your phone turns into Charmander that is all on you!

Cheers!]]> <![CDATA[How to Clone Kali Linux to PinePhone Pro with Terabyte IFW]]> https://forum.pine64.org/showthread.php?tid=19709 Mon, 24 Feb 2025 22:48:31 +0000 TOF]]> https://forum.pine64.org/showthread.php?tid=19709

Preparation:
1. Download the Kali Linux Image:
        Obtain the Kali Linux image file specifically designed for ARM devices (like the PinePhone Pro). Make sure you download the correct version.

2. Prepare a Spare SD Card:
        Get a spare SD card with enough storage to hold the Kali Linux image.
        Use Etcher (or a similar tool) to flash the Kali Linux image onto the spare SD card. This will create a bootable Kali Linux environment on the SD card.

Preparing the PinePhone Pro:
3. Enter USB Mode (Tow-Boot):
        Power off your PinePhone Pro.
        Boot the PinePhone Pro into USB mode (Tow-Boot). The instructions usually involve pressing and holding specific volume buttons while powering on the device. Consult your PinePhone Pro documentation if needed.
        Connect your PinePhone Pro to your computer using a USB-C cable.

4. Prepare the PinePhone Pro's Internal Storage:
        On your Windows computer, use Partwork for Windows (or a similar partition management tool).
        Identify the PinePhone Pro's internal storage as a drive.
        Delete all existing partitions on the PinePhone Pro's internal storage.
        Create a new EFI partition. This is very important for the phone to be able to boot.
        Once the new EFI partition is created, safely disconnect the PinePhone Pro from your computer.

Booting Kali from the SD Card:
5. Insert the Prepared SD Card:
        Insert the SD card with the flashed Kali Linux image into the PinePhone Pro.

6. Boot from the SD Card:
        Power on the PinePhone Pro.
        If needed, press and hold the specified volume buttons during boot to force it to boot from the SD card.

7. Initial Kali Setup:
        Allow Kali Linux to boot and complete its initial setup. This might take some time.
        Once the initial setup is complete, reboot the PinePhone Pro. This will allow Kali to finalize its setup on the SD card.

8. Power Off and Remove SD Card:
        Power off the PinePhone Pro.
        Remove the SD card.

Cloning Kali to the PinePhone Pro's Internal Storage:
9. Reconnect in USB Mode:
        Boot the PinePhone Pro back into USB mode (Tow-Boot) and connect it to your computer using a USB-C cable.
     
10. Insert the Kali SD Card into Your Computer:
        Insert the SD card that contains the working Kali Linux system into your computers SD card reader.
     
11. Clone with Terabyte IFW:
        Open Terabyte Image for Windows (IFW).
        Select the SD card as the source drive.
        Select the PinePhone Pro's internal storage as the destination drive.
        Use the "Copy Drive" (or similar) function to clone the entire contents of the SD card to the PinePhone Pro's internal storage.
        Ensure that you are copying the entire disk, and not just a partition.
     
12. Complete and Reboot:
        Once the cloning process is finished, safely disconnect the PinePhone Pro from your computer.
        Reboot the PinePhone Pro.

13. Update Kali:
        Once Kali has booted from the internal storage, open a terminal and run the following commands to update the system:
        sudo apt update
        sudo apt full-upgrade

That's it.  The main system on the PinePhone Pro is now Kali.  You can now use your SD card for storage or whatever you want.]]>

Preparation:
1. Download the Kali Linux Image:
        Obtain the Kali Linux image file specifically designed for ARM devices (like the PinePhone Pro). Make sure you download the correct version.

2. Prepare a Spare SD Card:
        Get a spare SD card with enough storage to hold the Kali Linux image.
        Use Etcher (or a similar tool) to flash the Kali Linux image onto the spare SD card. This will create a bootable Kali Linux environment on the SD card.

Preparing the PinePhone Pro:
3. Enter USB Mode (Tow-Boot):
        Power off your PinePhone Pro.
        Boot the PinePhone Pro into USB mode (Tow-Boot). The instructions usually involve pressing and holding specific volume buttons while powering on the device. Consult your PinePhone Pro documentation if needed.
        Connect your PinePhone Pro to your computer using a USB-C cable.

4. Prepare the PinePhone Pro's Internal Storage:
        On your Windows computer, use Partwork for Windows (or a similar partition management tool).
        Identify the PinePhone Pro's internal storage as a drive.
        Delete all existing partitions on the PinePhone Pro's internal storage.
        Create a new EFI partition. This is very important for the phone to be able to boot.
        Once the new EFI partition is created, safely disconnect the PinePhone Pro from your computer.

Booting Kali from the SD Card:
5. Insert the Prepared SD Card:
        Insert the SD card with the flashed Kali Linux image into the PinePhone Pro.

6. Boot from the SD Card:
        Power on the PinePhone Pro.
        If needed, press and hold the specified volume buttons during boot to force it to boot from the SD card.

7. Initial Kali Setup:
        Allow Kali Linux to boot and complete its initial setup. This might take some time.
        Once the initial setup is complete, reboot the PinePhone Pro. This will allow Kali to finalize its setup on the SD card.

8. Power Off and Remove SD Card:
        Power off the PinePhone Pro.
        Remove the SD card.

Cloning Kali to the PinePhone Pro's Internal Storage:
9. Reconnect in USB Mode:
        Boot the PinePhone Pro back into USB mode (Tow-Boot) and connect it to your computer using a USB-C cable.
     
10. Insert the Kali SD Card into Your Computer:
        Insert the SD card that contains the working Kali Linux system into your computers SD card reader.
     
11. Clone with Terabyte IFW:
        Open Terabyte Image for Windows (IFW).
        Select the SD card as the source drive.
        Select the PinePhone Pro's internal storage as the destination drive.
        Use the "Copy Drive" (or similar) function to clone the entire contents of the SD card to the PinePhone Pro's internal storage.
        Ensure that you are copying the entire disk, and not just a partition.
     
12. Complete and Reboot:
        Once the cloning process is finished, safely disconnect the PinePhone Pro from your computer.
        Reboot the PinePhone Pro.

13. Update Kali:
        Once Kali has booted from the internal storage, open a terminal and run the following commands to update the system:
        sudo apt update
        sudo apt full-upgrade

That's it.  The main system on the PinePhone Pro is now Kali.  You can now use your SD card for storage or whatever you want.]]> <![CDATA[freeBSD is booted on pinephone pro with console output]]> https://forum.pine64.org/showthread.php?tid=19611 Mon, 06 Jan 2025 09:57:50 +0000 zetabeta]]> https://forum.pine64.org/showthread.php?tid=19611
this is very initial achievement, but i welcome this move. i think pinephone models should have other operating system options than linux based ones.

https://mastodon.social/@tobykurien/113779792572310611]]>
this is very initial achievement, but i welcome this move. i think pinephone models should have other operating system options than linux based ones.

https://mastodon.social/@tobykurien/113779792572310611]]> <![CDATA[Plasma-Mobile on Mobian Trixie, task switcher issue]]> https://forum.pine64.org/showthread.php?tid=19603 Thu, 02 Jan 2025 15:21:45 +0000 pineconeuser]]> https://forum.pine64.org/showthread.php?tid=19603
I am going to file a bug report upstream with plasma-mobile.

Also wanted to report that KDE Plasma-Mobile is SUPER snappy and feels really good on the PPP. I have been daily driving it under `stable/bookworm` for the past few months, and moving to Trixie feels like I just bought a new phone Big Grin]]>
I am going to file a bug report upstream with plasma-mobile.

Also wanted to report that KDE Plasma-Mobile is SUPER snappy and feels really good on the PPP. I have been daily driving it under `stable/bookworm` for the past few months, and moving to Trixie feels like I just bought a new phone Big Grin]]> <![CDATA[Advice and experience on daily driving ppp]]> https://forum.pine64.org/showthread.php?tid=19598 Mon, 30 Dec 2024 23:48:05 +0000 JadenSki]]> https://forum.pine64.org/showthread.php?tid=19598 I've been distro hopping on my ppp for a little while now. And I am trying to figure out which os I should settle down on, to use for a daily driver. So far everything I need to work has not all worked out of the box on any os, which is to be expected obviously. And based on other's experience I am fairly confident that I can get most, if not all, of the main things I want, to work. However, this will obviously take time and effort, and the question is 'which os do I focus on getting working?' So I thought I would ask the community for advice/personal experience. If ya'll could take the time to let me know: 1. if you daily drive a ppp, 2. what os you use, 3. what desktop interface you use, 4. what do you have working (eg camera, calls, sms...) and 5 maybe just some simple tips that might be helpfull. I would be extremely grateful.
The main things I would like to work (listed in order of priority) are: sms, calls, mms, gps, camera (to some extent at least), and usb-otg. I would definitely prefer plasma mobile above posh, but if I cannot get everything working on plasma then posh is the next best. 
Thank you in advance!]]> I've been distro hopping on my ppp for a little while now. And I am trying to figure out which os I should settle down on, to use for a daily driver. So far everything I need to work has not all worked out of the box on any os, which is to be expected obviously. And based on other's experience I am fairly confident that I can get most, if not all, of the main things I want, to work. However, this will obviously take time and effort, and the question is 'which os do I focus on getting working?' So I thought I would ask the community for advice/personal experience. If ya'll could take the time to let me know: 1. if you daily drive a ppp, 2. what os you use, 3. what desktop interface you use, 4. what do you have working (eg camera, calls, sms...) and 5 maybe just some simple tips that might be helpfull. I would be extremely grateful.
The main things I would like to work (listed in order of priority) are: sms, calls, mms, gps, camera (to some extent at least), and usb-otg. I would definitely prefer plasma mobile above posh, but if I cannot get everything working on plasma then posh is the next best. 
Thank you in advance!]]> <![CDATA[Reseting the Battery Fuel Gauge]]> https://forum.pine64.org/showthread.php?tid=19591 Mon, 30 Dec 2024 07:09:21 +0000 franzthiemann]]> https://forum.pine64.org/showthread.php?tid=19591
The PinePhone pro uses Battery fuel gauging as implemented in the RK818 Chip.
Fuel gauging works ok when using one battery. Battery full and empty indications match the battery voltages within a couple of percentage points.

But the daily driving the PPP with only one battery is hard.
When using multiple batteries, however, the fuel gauging becomes really annoying, as the phone will show the percentage of the last (empty) battery until it shuts off.
After a couple of reboots, the fuel gauging seems to reset itself, but rebooting the PPP several times takes time and does not seem like an ideal solution.

Is there a possibility to reset the fuel gauge calibration on eg. each reboot to avoid unintended shutdowns after battery swapping?]]>
The PinePhone pro uses Battery fuel gauging as implemented in the RK818 Chip.
Fuel gauging works ok when using one battery. Battery full and empty indications match the battery voltages within a couple of percentage points.

But the daily driving the PPP with only one battery is hard.
When using multiple batteries, however, the fuel gauging becomes really annoying, as the phone will show the percentage of the last (empty) battery until it shuts off.
After a couple of reboots, the fuel gauging seems to reset itself, but rebooting the PPP several times takes time and does not seem like an ideal solution.

Is there a possibility to reset the fuel gauge calibration on eg. each reboot to avoid unintended shutdowns after battery swapping?]]>