| Welcome, Guest |
You have to register before you can post on our site.
|
| Forum Statistics |
» Members: 29,473
» Latest member: Samliams
» Forum threads: 16,196
» Forum posts: 116,879
Full Statistics
|
|
|
Manjaro unlock code out of the box |
|
Posted by: Red10Para - 11-29-2021, 06:02 AM - Forum: General Discussion on PinePhone
- Replies (3)
|
 |
Hi all,
I am a beginner with all this, so please, excuse the lack of knowledge. Just opening the books up as I'm fed up with google and the stalking.
I have my pinephone, went through the set up, but it wont unlock?
Used the 123456 and loads of other combinations. Read a post that 147147 worked tried it and it failed.
Any one got any thoughts?
Or any suggested literature in getting started?
I just got booked on Jason Cannons linux course as a starter to get started.
|
|
|
|
| SMCCC_ARCH_SOC_ID returns invalid values |
|
Posted by: bexcran - 11-28-2021, 08:48 PM - Forum: General Discussion on Quartz64
- No Replies
|
|
I'm working on SMBIOS support for the Quartz64, and the CPU reports that it supports the Arm64SocID SMC call.
But it's returning invalid values:
Jep106 code: 0xFFFFFAE0
SoC revision: 0xFFFFFB18
According to the SMC Calling Convention, the top bit of both should be zero:
SoC_ID_type == 0
JEP-106 code for the SiP
Bit[31] must be zero
Bits [30:24] JEP-106 bank index for
the SiP (see [9.])7
Bits [23:16] JEP-106 identification
code with parity bit for the SiP (see
[9.])7
Bits [15:0] Implementation defined
SoC ID
Bit[31] must be zero
Bits [30:0] SoC revision
How would I go about reporting this problem to Rockchip? I don't know if this is a problem they can fix in their rkbin repo, or if it's a hardware bug.
|
|
|
|
| Pinephone not booting, always vibrating |
|
Posted by: alexander12 - 11-28-2021, 01:03 PM - Forum: General Discussion on PinePhone
- Replies (8)
|
|
My pinephone (postmarketOS edition) was on, and working normally when it immediately turned off. It can be that the battery is flat.
When plugging in the power, the red light turns on, and the phone immediately starts vibrating without stopping. Screen remains black.
Same behavior without battery.
What can I try to resolve the issue?
|
|
|
|
| Android remote control using SSH/ADB/scrcpy |
|
Posted by: pauloliver - 11-28-2021, 09:15 AM - Forum: General Discussion on PinePhone
- Replies (1)
|
 |
Hello everyone, first time poster (long time lurker). 
I wanted to share a experiment I've been working on. Maybe someone can find useful, or help me improve on the ideas described below. I purchased my Pinephone BE some while ago and I've been slowly working on it with hopes that I'll be able to turn it into my main phone. I'm using Archlinux with SXMO (flashed to eMMC) and I'm really happy with the level of customization and tinkering that's possible (it feels I'm still just scratching the surface). SXMO feels light and snappy, gestures are easy to remember (once you get accustomed). Calls, SMSs, mobile data (and even the mobile hotspot functionality) work excellently. Battery drains fast while in use, but lasts about 24+ hours while in suspend mode (I think I can live with that).
Detaching from Android has been difficult due to some services (like my home alarm system) only being controllable through an Android or IOS app. This has been a huge bummer, as it has kept me needing to carry my Android phone with me whenever I leave home (to arm/unarm and check on the system). If only there was a way to control my Android phone remotely, I'd be able to leave it at home most (if not all) of the time.
I've thus been looking into ways to achieve this. Ideally, I wanted to be able to control the droid phone through SSH. I've used scrcpy before to control my phone with my PC by plugging it to an USB port. Once I realized scrcpy could be SSH-forwarded I knew I was on to something!
The scrcpy utility is not available as an ARM package on the Archlinux repositories, but I was able to build it on the Pinephone easily by following instructions here:
https://github.com/Genymobile/scrcpy/blo...r/BUILD.md
Most dependencies were already installed on Arch by default (I think only exceptions where wget and meson). I think the android utilities (android-tools package on Arch) where also needed on the Pinephone as well.
I have an old laptop running 24/7 as a home server, so I installed the android-tools package there as well. This allows launching an ADB server on the background that can run continuously. I created a simple systemd service to achieve this and started/enabled it on the home-server:
Code: [Unit]
Description=ADB server service
Requires=network.target
After=network-online.target
[Service]
User=paul
ExecStart=/usr/bin/adb -a nodaemon server
Restart=on-failure
RestartSec=5s
[Install]
WantedBy=multi-user.target
I already had debugging enabled on my Android phone, which means I can just plug it into the home-server and it gets detected by the adb daemon, nice!
As a last step I needed to be able to dynamically create a SSH connection on the Pinephone that forwards the ports used by scrcpy to connect to the adb server (5037 and 27183). SXMO allows creating userscripts that then become easily accessible through the UI. I created a simple shell script that creates the SSH connection and launches scrcpy:
Code: #!/bin/sh
SOCKET=/tmp/droid-tunnel-ctrl-socket
SCRLOG=/tmp/droid-tunnel-scrcpy-log
# Parameters
SSHCON=$1
VIDSIZE=$2
VIDFPS=$3
notify-send "DROID TUNNEL" "Launching tunnel through '$SSHCON', size:$VIDSIZE, fps:$VIDFPS"
on_exit() {
kill -9 $SCRPID
ssh -S $SOCKET -O exit $SSHCON
}
trap on_exit EXIT
ssh -M -S $SOCKET -fnNT -L5037:localhost:5037 -L27183:localhost:27183 $SSHCON
ssh -S $SOCKET -O check $SSHCON
killall -v scrcpy
scrcpy -V verbose --force-adb-forward --max-fps $VIDFPS --max-size $VIDSIZE > $SCRLOG 2>&1 &
SCRPID=$!
while sleep 0.1 ; do
grep --quiet "X connection to :0 broken" $SCRLOG && break
done
On the shell script above, the first argument (SSHCON) represents the SSH connection to the home-server. This is pre-configured on my ~/.config/ssh. VIDSIZE is the resolution of the generated video that's captured live from the Android phone (long side). VIDFPS (as you may have guessed) are the captured frames per second. The script first generates the SSH connection (using a control socket) that forwards the needed ports and then launches the in-built scrcpy binary. I found out the on_exit hook and polling for the X connection message was needed to make sure scrcpy does not hang when I close the window in SXMO (ugly but it works for now).
Result: Android on my Pinephone, yay. 
Video --> https://pauloliver.dev/files/sxmo-android-rc.mp4
I can invoke the script above using 2 different SSH connections, first a local connection on my home network, and also a remote connection (that goes through a tunnel set on a VPS I currently rent). The one that goes through the tunnel is set to a lower resolution and frame-rate, but it's completely usable, which means I can monitor/control the Android phone from anywhere. The scrcpy key-bindings even allow me to easily lock/unlock the Android phone and turn off the screen when not in use (way safer to leave the phone locked at home).
I'd like to come up with more hacky ways to control the Android apps programatically in the future (IDK if that's possible) but this will work for now. I can finally set/unset my home alarm from my Pinephone. 
|
|
|
|
| Pacman vs. Discover |
|
Posted by: jojuma - 11-28-2021, 07:34 AM - Forum: Manjaro on PinePhone
- Replies (3)
|
|
Hello,
for quite a while I used pacman and updated my system in the terminal using:
Discover often failed to update or didn't report available updates.
Then, once during an update, the wifi connection failed and from then on I got an error message after every reboot saying "Offline update failed - Unexpected system error". Neither pacman nor Discover did any updates any more.
After some research I came to the conclusion, it would be easier to completely reinstall the system than keep trying to fix that problem.
I then reinstalled the latest beta release from https://forum.manjaro.org/c/arm/releases/102.
But now it's the other way round: Discover reports and performs updates while pacman says, there's nothing to do.
I feel completely unsure if either of those methods do their job correctly.
My question is: How can I know for sure, if there are any updates and if my system is up to date or not?
Current system data:
KDE Plasma Version: 5.23.2
KDE Frameworks Version: 5.87.0
Qt Version: 5.15.2
Kernel Version: 5.14.17-1-MANJARO-ARM
Thank you!
|
|
|
|
| PinbebookPro electrically dead ... |
|
Posted by: abukolt19 - 11-28-2021, 06:48 AM - Forum: Pinebook Pro Hardware and Accessories
- Replies (3)
|
|
I have had my PBP since early May 2021 and have loved it dearly. It was perfect for experimenting with software, the battery life was great, etc.
However, a few days ago, my enjoyment of it came to a halt, with a bad software installation that crippled the system (Manjaro, updated from the original installation). I tried to re-install the OS onto the 64Gb eMMC, but I kept getting told that the file system on the eMMC was corrupt. Eventually, one of the attempts, always ending with a restart, failed to bring the computer back to life. No lights came on at all. Since then, the only sign of electrical life has been a little red light next to where the power supply cable goes in (the barrel port/jack?)
I suspect the motherboard is dead. Perhaps the eMMC, too. I admit, I am a software guy, so I need guidance on diagnosing the electronics/electricals of my PBP. I would really appreciate any suggestions. It would be a shame to have to scrap a computer after six months.
P.S.
I have written to support@pinemicrosystemsinc.zohosupport.com, but they tell me to try the forums.
There was one case I have seen in the forums that also referred to a dead PBP and the answer was "Conctact sales" [for motherboard, and other parts].
|
|
|
|
[Support Request] Modem is Failing to Be Accessible |
|
Posted by: FriendlyGecko - 11-28-2021, 03:46 AM - Forum: PinePhone Hardware
- Replies (3)
|
|
Phone does not report modem to end user making it inaccessible. Kill switch was toggled, tested on Arch Linux and Mobian, powered down and left overnight, and not sure what else to do from here. Any and all help would be greatly appreciated (and if there is a better place for this, please advise).
Output of sudo systemctl status ModemManager:
ModemManager.service - Modem Manager
Loaded: loaded (/usr/lib/systemd/system/ModemManager.service; enabled; vendor preset: disabled)
Active: active (running) since Sat 2021-11-27 22:45:08 CET; 2min 40s ago
Main PID: 3098 (ModemManager)
Tasks: 3 (limit: 3275)
Memory: 8.9M
CPU: 526ms
CGroup: /system.slice/ModemManager.service
└─3098 /usr/bin/ModemManager --test-quick-suspend-resume
Nov 27 22:45:07 arch systemd[1]: Starting Modem Manager...
Nov 27 22:45:08 arch ModemManager[3098]: <info> ModemManager (version 1.18.4) starting in system bus...
Nov 27 22:45:08 arch systemd[1]: Started Modem Manager.
Nov 27 22:45:11 arch ModemManager[3098]: <info> [base-manager] couldn't check support for device '/sys/devices/platform/soc/1c10000.mmc/mmc_host/mmc1/mmc1:0001/mmc1:0001:1': not supported by any plugin
|
|
|
|
|
