There was a deleted thread today where I posted some crypto-currency services I have seen requested, let's contribute wish list items, I will try to edit every request into this top post.
The old(unfortunately deleted) Mobian app status/catalog pages on showed usable Bitcoin-Electrum and Monero official clients from flatpak( https://flathub.org/setup/Debian ). It would be useful for you all to post your use cases and what is working for you on any and all platforms mobile and desktop so the community can also suggest solutions. If you are looking to interact with online services for research or where your crypto is held in an account for you by some company(custodial wallet) it is usually easy enough to make a webapp for that sort of thing.
Between here, Reddit, and other forums I recall people wanting more non-custodial wallets and zero-trust p2p exchange services ie: litecoin-electrum, electrum-doge, WoWnero wowlet client, btc-xmr UnstoppableSwap, Havano-Reto XMR market, BTC Bisq market, Etherium, among other FOSS apps preferably with tweaked UIs for mobile though the Mobile Settings - Compositor can probably fix the scale to be useful.
It is useful to know is how we imagine we and other future users will want to actually use crypto on their PP; are we talking about buying coffee and pizza directly, through the gift card bridge, or bridging through bitpay, using a crypto wallet as a savings account, managing a mining farm, buying a used laptop on moneromarket.io, trading and investing on Kracken or robinhood, or... other? (I am not sure how I feel about the mentioned commercial services vs zero-trust FOSS solutions they are just possible usage examples)
I am running Mobian but all PP distros including libhybris such as Ubuntu-Touch are included.
When I flip the second kill switch on the pinephone I cannot get the WiFi or the bluetooth to turn off. Is this normal behaviour? Am I missing something?
it seems that by default only the internal I2C-controller of the DesignWare HDMI controller is enabled. However, it is known that this is sufficient to retrieve the EDID, but the internal I2C controller of the HDMI module is not suitable for full DDC support, see the discussion here:
it shows that the I2C-5 pins are even connected to the HDMI plug (search for HDMITX). So things are correctly setup in hardware, what is missing are the proper settings in the device tree. This can be cured by the attached device-tree overlay. The overlay
enables the controller for i2c-5 with the m1 pin configuration (see schematics for the board)
removes the respective pins from the pin-control entry of the HDMI controller to resolve conflicts
adds "ddc-i2c-bus = <&i2c5>;" to the hdmi controller section
Afterwards DDC just works, on Linux "ddcutil detect" will succeed and, e.g., "ddcui" can be used to control the settings with a GUI.
In an attempt to troubleshoot failing to get generic alpine linux to run on PA64-2G-LTS, I've tried to reduce the problem to the smallest steps that are legible to me.
When booting the kernel, I get "Bad ARM64 Image Magic" I can't figure out what this means, and why it is happening. Sources I have searched seem to be board specific, and found nothing on this board. I've arrived at a point where I cannot find a way to reason further about it, so thus I am reaching out.
I am currently loading the kernel and dtb manually at the uboot prompt:
- linux 5.14 from mainline (git:7d2a07b769330c34b4deabeed939325c77a7ec2f)
- u-boot v2024.10 from https://source.denx.de/u-boot/u-boot (git:f919c3a889f0ec7d63a48b5d0ed064386b0980bd)
- dtb from the u-boot build
- bl31.bin from PLAT=sun50i_a64 https://git.trustedfirmware.org/TF-A/tru...ware-a.git lts-v2.10.6 (git:f2aebf361050d69176d60016170291efa9e08a68)
- scp.bin from https://github.com/crust-firmware/crust 0.6 (git:ffe9f1ac9c675e6e67db9084bd19fbdeffd8e162)
- u-boot-sunxi-with-spl.bin written to offset 8k
- tried sd and emmc vfat single partition (whole disk) with
* boot/vmlinux
* boot/u-boot.dtb
Hello, I am rather new to sdc's. I have used Pi's for kipper but that is about it.
Got a second hand Rock64 yesterday. As far as I have been able to tell I need to jump pins 20 and 21 to bypass SPI-flash to boot from SD. Was not able to boot into debian. I ended up flashing the SD card with Armbian to try and install u-boot. I was able to boot onto the sd card with armbian. So I know the rock64 isn't bricked.
The dilema I currently see myself in is that I only have 1 sd card and I do not see how I would install an OS without having a second sd card and a usb sd card reader. Am I wrong? I am hoping to not have to go out and buy an extra sd card and reader I don't really want to buy an emmc module either.
I was planning to run the rock64 off the sd card. Would it be possible to achieve what I want with the serial console?
Hi there,
Been a quiet PBP user since july 2021, really love my pinebook and enjoy it (using manjaro).
Lately I have an issue with the power button.
Symptoms:
It seemed that it won't boot properly, despite no recent OS/FW updates and topped-up battery.
It would boot into a certain state where the LCD is lit up and a flashing '_' is flashing at top left corner, as expected.
Then, the flashing is halted, then continues until shutdown. The PBP reboots, ad infinitum.
From time to time it did load GUI to show the mouse pointer before resetting, rarely loading the login screen.
Another thing is that shutting down resulted in reboot. Long press on power button did shut it down for good though.
Lately otherwise it ususally make it into login without turning off.
Making a long story short, in the rare cases I managed to log in I got constant power-off dialogs popping at me.
That's a typical journal log I get on the machine (reverse order):
Code:
Oct 12 18:08:27 PinebookPro systemd-logind[520]: Power key pressed short.
Oct 12 18:07:44 PinebookPro root[4904]: PowerButton pressed
Oct 12 18:07:44 PinebookPro systemd-logind[520]: Power key pressed short.
Oct 12 18:07:28 PinebookPro root[4902]: PowerButton pressed
Oct 12 18:07:28 PinebookPro systemd-logind[520]: Power key pressed short.
Oct 12 18:07:17 PinebookPro root[4897]: PowerButton pressed
Oct 12 18:07:17 PinebookPro systemd-logind[520]: Power key pressed short.
Oct 12 18:06:44 PinebookPro root[4892]: PowerButton pressed
Oct 12 18:06:44 PinebookPro systemd-logind[520]: Power key pressed short.
Oct 12 18:05:58 PinebookPro root[4879]: PowerButton pressed
Oct 12 18:05:58 PinebookPro systemd-logind[520]: Power key pressed short.
Oct 12 18:05:26 PinebookPro root[4876]: PowerButton pressed
Oct 12 18:05:26 PinebookPro systemd-logind[520]: Power key pressed short.
Oct 12 18:04:36 PinebookPro root[4873]: PowerButton pressed
Oct 12 18:04:36 PinebookPro systemd-logind[520]: Power key pressed short.
Oct 12 18:03:28 PinebookPro root[4862]: PowerButton pressed
Oct 12 18:03:28 PinebookPro systemd-logind[520]: Power key pressed short.
Oct 12 18:03:10 PinebookPro root[4859]: PowerButton pressed
Oct 12 18:03:10 PinebookPro systemd-logind[520]: Power key pressed short.
Oct 12 18:02:56 PinebookPro root[4857]: PowerButton pressed
Oct 12 18:02:56 PinebookPro systemd-logind[520]: Power key pressed short.
Oct 12 18:02:31 PinebookPro root[4855]: PowerButton pressed
Oct 12 18:02:31 PinebookPro systemd-logind[520]: Power key pressed short.
Oct 12 18:02:07 PinebookPro root[4851]: PowerButton pressed
Oct 12 18:02:06 PinebookPro systemd-logind[520]: Power key pressed short.
Oct 12 18:01:35 PinebookPro root[4844]: PowerButton pressed
Oct 12 18:01:35 PinebookPro systemd-logind[520]: Power key pressed short.
Oct 12 18:00:57 PinebookPro root[4831]: PowerButton pressed
Oct 12 18:00:57 PinebookPro systemd-logind[520]: Power key pressed short.
Well you get the idea. That's really annoying.
I could probably remap the power button? But I do fear that the underlying condition will kill the power button altogether one day, and I wont be able to properly power the device on.
I took a look at the schematics. I guess that something is pulling the CPU power line, but not the PMIC one? Or is the PMIC less sensitive to that signal?
If it's the first issue that it's not a keyboard issue, and I have no clue what issue it is.
I might be able to sense the proper test points later, but I'd rather ask here first if anyone had such an issue or have any insight into this issue (I couldn't find such thing in the forum or elsewhere).
I own a pinephone. Mobian is installed in some outdeated version. I want to flash a new version of mobian but none of my computers recognizes the phone when booted with jumpdrive. tow boot seems to be installed. Booting while pressing the volume up button also does not show the devoce as mass storage. Any idea is appreciated.
(10-11-2024, 05:47 AM)sfb Wrote: As descriebed in the headline.
I own a pinephone. Mobian is installed in some outdeated version. I want to flash a new version of mobian but none of my computers recognizes the phone when booted with jumpdrive. tow boot seems to be installed. Booting while pressing the volume up button also does not show the devoce as mass storage. Any idea is appreciated.
edit: I put the image on SD and installed from there. But still I wonder why the pp isn't recognized as mass storage?
Bought a pinephone and the keyboard a few years ago, havent really used it in the past year and would like to get some money for it. UK Based and am probably going to list on ebay for auction soon but thought id post here first if anyone is looking for one. Thanks!
<This is currently partly broken on my Mobian trixie Pinephone pro the VNC viewer shows a grey screen but input is usable>
Do you wish there was an easy hands-free way to interact with your PP's touch GUI while sitting in front of your desktop system?
Would you like to compose, read, and send SMSs and IMs using your full size keyboard? Interact with your mobile apps using your desktop's mouse, and screen?
Is there a way to cut and paste between your phone and Desktop?
Maybe you would like to initiate and end hands-free or speakerphone calls without touching your phone?
These and more are all possible using VNC to remotely interact with the GUI of your Pinephone.
Let's start with your Pinephone; mine is running Mobian but the instructions should work for other distros; use your system's package installer. (this is for systems running Weyland for video, x11(and mir/surfaceflinger) uses a different VNC server)
Code:
sudo apt install wayvnc
once wayvnc is installed the way I run it is with a launch script I keep in my home directory, I named my script V (the 0.0.0.0 allows incoming connections from outside localhost)
Code:
#! /bin/bash
wayvnc 0.0.0.0
make our script V executable
Code:
chmod +x V
launch manually on the pinephone's shell console like this
Code:
./V
The VNC server on your phone is now waiting for a client to connect, as configured is not secured and is unencrypted.
This setup when run on your Weyland video server Pinephone will let your login when the VNC server is running on your PP without any security or password config on either side. The VNC server script above is launched and killed manually so it is not running all of the time in this config, you save precious battery when mobile. If you wanted you could make a desktop entry to give you a GUI launcher for the sell script, just kill that shell window to kill the server.
Now install the VNC viewer GUI on your desktop Linux machine(other OSs also have VNC client software)
Code:
sudo apt instal tigervnc-viewer
Now in this insecure home LAN setup just run ./V on your Pinephone, then set the phone's LAN IP address in the tigervnc-viewer GUI running on your desktop system and click connect; a window with your PP's interactive GUI will appear on your desktop machine.
In options I recommend reviewing the cut/paste options in tigervnc-viewer Input tab, clicking the 'show dot when no cursor' in the also in Input tab so you have a way to see your mouse in some server configs, as well as ensuring that in the Security tab the encryption and authentication options including none as in my example are to your preference.
This is all you need to remote control your phone via desktop; it is a near perfect way to interact with your Weyland Pinephone. This setup also works if you are using the PP as your wifi(or USB cable or Bluetooth) tether hotspot just be sure to update the PP's IP address. This quick tryout setup is only viable in a situation where the phone and laptop are on a private WLAN with no possibility of other users, any other situation where the VNC server is running gives all users who can scan the network for open VNC port free GUI access to your PP with no barriers. It is easy to set a user name and password as well as encryption for the connection, a secure setup requires editing a .conf file on your PP with username and password as well as generating an RSA key. see https://github.com/any1/wayvnc
If you have trouble with cut/paste showing boxes rather than text it is a font matching problem and I have solved this by using the on-phone web browser for some non-English languages rather than my desktop's; there are better ways to solve the problem though.
VIew the wayvnc git for secure setup and running instructions https://github.com/any1/wayvnc
I find that if I am doing heavy interaction with my PP while in my office VNC, an SSH session, as well as Filezilla to move files around makes everything so easy I rarely need to touch my charging PP except to wake it up if it goes into standby mode and disconnects from the WLAN.
I also notice that PS doesn't exist in the datasheet for the SC7A20, that pin is NC, although finding an English version was slightly hard, maybe there are different versions?
I used this as a reference for a custom board using it, before I was able to find an english datasheet, figuring that the pinecil is probably the most famous trusted application and whatever it does is probably right, but I'm having some issues getting it to work... Any advice?
Is this an old version of the schematic or something? I also just now noticed it says BMA223, which I apparently glossed over thinking it was a part of the package code, but actually that's a completely different accelerometer chip, so something funny seems to be occuring.
The SC7A20 needs CS pulled high, as far as I can tell from the other datasheet, and on my boards, the chip doesn't seem to be responding to an I2C scan.
