I need 4 UARTs, to use board as controller for home automatization: 1 - ZeegBee, 1 - GSM, 1 - RS485, 1 - M-bus. But in documentation, there are only 2 gpio uarts enabled for user. I wouldn't like to use external usb converters, this interfaces should be located on my expansion board, connected to the rock64 by GPIOs. Is there any solutions to solve my problem?

This is just my experience and opinion. I uninstalled Dolphin file manager and I am using a manger called "Files" and my computer is running faster and is much more stable. The reasons of course could be many including operator error. Peace all.

Apparently Manjaro ARM 20.10 was released recently, but how do I update to this version?
There are no available updates in the add software app, and Manjaro is providing the images, so do I need to reinstall the OS on the eMMC?
What's the fastest way to proceed with the update?

Thank you

It's been released recently and with it an official image for raspberry pi 4 which is an arm device. Unfortunately I lack the knowledge to try and port/build myself but curious on opinions on how hard it would be to make a build for the pbp? Would this be useless at all https://launchpad.net/cubic

I'm sure the answer is no!

Sent from my OnePlus 7 Pro using Tapatalk

Hi, I need 4 Uarts from GPIO headers. Is there any solutions to solve my problem?

Recently I've been having a problem with the rubber feet coming off the bottom.

The worst ones are the ones on the back side (nearer to the screen). They have the habit of sliding around on the underside if the laptop is pushed. Or even worse, coming off in the bag and getting potentially lost. And if the feet are not in the proper place the laptop will wobble around and of course the glue is sticky as well.

I'm asking if anyone else has had the same issue and what did you do? I'm thinking that there could be replacement feet or some adhesive that can glue them back more securely.

Were you guys able to setup full disk encryption on the default Manjaro OS?
I've seen a couple of tutorials requiring super involved procedure with some external drives etc.
https://forum.pine64.org/showthread.php?...encryption

Is anyone aware of a simpler approach? Or if not encryption the whole drive then at least creating a veracrypt style repo of one partition?

Thanks

I got my pinebook pro and I am quite happy with it, but there is one problem with my device:

when it arrived the LCD panel was shifted a bit.

Is there a way to fix the display assembly?


[img] https://www.imgload.org/images/IMG_20201...33165a.jpg[/img]

I have the need to record audio from my 1970s HiFi.  The most convenient way to do that at the moment is to use my Pinebook Pro.  I run NetBSD.

I bought two devices from Newegg, hoping that one of them would work.  This turned out to be very fortuitous. The first is a StarTech ICUSBAUDIO7D.  The second is a Toshiba PA3390U-1MPM.

First off, connecting or disconnecting either of these whilst the system is booted risks locking up the PBP. I am using Audacity to record, which also occasionally locks the machine. Since I am running NetBSD-current, this is not totally unexpected.

First the StarTech:
I was able to record audio via /dev/audio1, but this does not source the audio from Line In.  It sources it from the microphone jacks, which there are two and they are mono.  The audio level is about 10db too low.  There is a periodic tschk-stck noise in the recorded audio which I cannot figure out how to avoid.  I can play back audio, also via /dev/audio1.  This routes audio to the front speaker jacks.  The output audio seems to be an adequate level, and seems to be clear and acceptable.  Despite that these are labeled as speaker jacks, they seem to be line level.

Next the Toshiba:
I was able to record audio via /dev/audio1, and this sources audio from Line In.  The audio level again is about 10db too low.  The record audio seems to be clear and sufficient, albeit a low level.  I cannot get audio to play back from the device.  There is a mute button with indicator light on the front of the device, and this indicator is always on.  I assume that I would need the Windows software that comes with the device to turn the mute function off.

So, you can see I have one device that records well and one that plays back well.  I was able to daisy-chain them; the Toshiba device has an inbuilt USB hub.  In this case, the StarTech device becomes /dev/audio2.

The low record audio may have something to do with "line level" standards changing over the years.  The only other computer I've used with this stereo system is an Amiga with a Delfina audio card, and I don't recall ever having issues with low level audio on that.  (In fact, I'm pretty certain that there was plenty of headroom in the audio level; I did a lot of recording with that).  But that was over twenty years ago.  Things may have changed in the industry since; I have no idea.

This was my first experience ever using a "USB sound card".  So perhaps there are other things I could have done better and I am not aware.  But at least this is a workable solution, and I was able to record the audio that I needed.

Many Pinephone users have ssh access open. Result being their Pinephone's ssh server shows up/is by default accessible on the open internet. This can be dangerous (especially given many undoubtedly use weak number passwords (ie: guessable numbers doubling for screen unlock pin)),

So I thought fellow Pinephone users may find this video helpful.

A quick (5min), easy video walkthrough/guide. A simple to implement security enhancement (using Mobian Pinephone as example in the video but will work on any Linux).
Make your Pinephone ssh server only accessible as a Tor .onion address (Blocking access/portscans/shodan for users on standard internet).

https://youtu.be/syKZNMVxTM4

After following the video, edit  /etc/ssh/sshd_config and uncomment/edit the line to match:

ListenAddress 127.0.0.1

Optionally (in case anything in ssh config goes wrong) block using iptables issue the following afterwards: