@gamelaster 

Quote:There isn't much information about SOEdge, because developers receiving prototypes only now, and it will take some time, but step by step, the wiki will be filled with information, so also I expect more information published on next community blog. About USB SDK and normal SDK, I tried to compare it without unpacking, there isn't much differences on first sight, need to unpack it and make some bigger comparison. I will write here with results.

When I bumped into this symbols, I guessed they are resistors.
(the blue mesh-like symbols have 100 ohm value.)
(I've already asked this question on stackexchange but no answers yet.)






But they don't have have names, so they are not going to mounted in a PCB assembly.
Can anyone tell about this?
Thanks in advance!

Hi,

I received my RockPro64 yesterday and want to build a NAS with it, using the official Pine64 PCIe controller and two SATA drives in RAID1. Pretty standard I thought.

But even after spending the whole morning trying all the different images I could find, still no success.

Mainly, Ayufan's image compatibility list shows that e.g. the 0.9.14 image (I'm using stretch openmediavault or bionic/buster minimal, either arm64 or armhf) should support the PCIe controller.

However, lspci shows nothing, ever. Always blank.

Also, dmesg | grep pci only ever shows:

Hi there,

I have begun the process of a buildroot external repo for the quartz64a :
https://github.com/flatmax/buildroot.rockchip

Currently, the kernel and uboot are building. The operating system is building.
TODO : work out why loaderimage isn't generating uboot.img as expected - the file is zero in size.

While I have been advocating for fresh new mobile apps and a community contributions repo specific for mobile there is a second way to populate mobian with useful apps, it also is a nice quick shortcut.  We need the working app ecosystem which have made Debian a useful daily OS for decades now.  Daily driver app ecosystem = more everyday users = exposure = even more users = more diverse devices(and i2c addons) designed with FOSS drivers in mind = a wider choice on pricepoint and HW features.

Reskinning desktop apps is a major contribution to making Mobian and pinephones(as well as other compatible devices) daily driver useful.

Resizing desktop apps optimized for HD desktops is not enough.

Most of the desktop apps in the Mobian and Debian universe are already in the repos but are nearly useless even with a stylus as the capacitive touch interface is designed for fat human fingers so between 8-12 mm is the smallest a 'touch' to the touchscreen can be, even the resistive screen seen on very old phones and devices required a stylus and good eyesight to navigate chrooted desktop apps.
Almost all of the apps in the FOSS Linux/Unix universe are modular, they can have a second mobile friendly skin contributed to the git and once approved pushed to unstable and then onward.
I look forward to a day when most Debian(and most FOSS distros who follow) packages in the repos has an easy option in the UI or a trigger in the .deb to switch to a small touchscreen skin making those apps usable on mobile and small embedded devices.

Debian has taken a big step in fostering Mobian as an official fork, let the Mobian leak into Debian and standardize inclusion of a mobile friendly alternative GUI.  there will be more use cases than we think and it will place Debian as the best and most flexible choice for mobile and embedded systems, hopefully displacing the current non-free option of putting Android on every refrigerator, phone, treadmill, and TV, or at least taking over the DIY space and diverting those person-hour hacking and customizing resources to the FOSS cause.
This is what I had hoped for years ago with Ubuntu Touch and convergence, we have full native x11 now, no wonky unfamiliar libhybris hacked interfaces for drivers or surfaceflinger.  The real apps you are used to using on desktop with a mobile skin on debian repos.

There is still a need for users writing mobile specific apps and web apps, as is an easy path to entry contribs repo solution to host these; but  we have thousands of excellent apps which only need a useful mobile skin!

With the librem phones, the hardware kill switches are placed around the edges of the phone, but with pinephones, it is placed inside the case. It kinda defeats the purpose of placing it inside the phone the switches, as placing the switches inside the phone (behind the back cover) makes it hard to enable certain hardware.

For exmaple if I am getting a call and I have my microphone switched off, I would have to enable it before talking to the person. On the librem phone this can easily be achieved, but on the pinephones I would have to open the back cover and enable it and then I can talk to the person which is inconvenient.

For anyone interested, the simple flat-file database -- fields.awk -- does run perfectly well on the pinephone terminal, whether it's running Manjaro or Mobian. (Have not tested others) The code can be found here:
SoureForgeLink
Make the file (fields.awk) executable, move it to /usr/local/bin, and change the name to simply "fields" or a short name of your choosing.
Run it once from the command line and it will auto create its own folders .fields/db-archive. You should see a startup display such as this:
FIELDS.AWK:
Flat-file Database Program for Linux systems
###########################################
® READ from:
(W) WRITE to:
(E) EDIT selected:
(S) SELECT a database
(T) TALLY a column in:
(N) NEW database
(F) Saved-FILES (in .fields/SEARCHES)
(X) Encrypt/Decrypt (files in .fields/db-archive)
(Q) Quit
##########################################


Typing "N" or "n" will allow you to create one new database file as you're prompted to enter the number of desired fields, and a name for each field.

Enjoy.
   

Hello all,

A couple of months ago I flashed the spi from my RockPro64. It worked and I was able to boot from USB3. Tried it a couple of times just to see how it worked but kept booting from the sd card (I've been using LibreELEC, btw).

The thing is yesterday I got a case to a ssd I had here, connected it to the USB3 and tried to boot. It didn't work. I imagined that it could be due to some lack of support from the relatively old u-boot I had flashed before, so I downloaded the newest version from here. I followed the instructions from here and things at first seemed to have worked fine.

Now the issues:

- First thing I noticed (and that had me thinking the flash proccess worked) is that now I have a verbose boot that I didn't have before. The ssd still doesn't boot from the USB3 port but I noticed it boots from the USB2 (maybe it was already booting from USB2 with the old u-boot, but I didn't do this test before reflashing). When connected to USB 3 it shows a lot of debug messages, but doesn't boot.

- If instead I use an USB flash drive it boots ok (both from USB2 and 3), which makes me think that it's maybe some compatibility issue with my case/adaptor, although it works fine with USB2.

- But the worst part is the audio... After upgrading there's no audio from HDMI, no matter if I boot a LibreELEC img from the sd card or USB2/3. I even tried to erase the spi using the img "erase_spi.img", but it didn't work (at least I think it didn't, because I still can boot from USB and the debug messages still show up).

- I also noticed that if I boot from another img I had here (this time a 'complete' Linux - Manjaro, not LibreELEC) audio works.

I'm attaching the logs I see when booting from the sd card after upgrading u-boot (no HDMI audio):

Quote:

Code:

U-Boot 2021.04-11556-g9ecacf77d2 (Jun 30 2021 - 17:48:07 +0000)

SoC: Rockchip rk3399
Reset cause: POR
Model: Pine64 RockPro64 v2.1
DRAM: 3.9GiB
PMIC: RX808
MMC: mmc0fe310000: 2, mmc0fe320000: 1, sdhci@fe330000: 0
Loading Environment from SPIFlash... SF: Detected gd25q128 with page size 256 bytes
*** Warning - bad CRC, using default environment

In: serial
Out: vidconsole
Err: vidconsole
Model: Pine64 RockPro64 v2.1
Net: eth0: ethernet@fe300000
starting USB...
Bus usb@fe300000: USB EHCI 1.00
Bus usb@fe3a0000: USB OHCI 1.0
Bus usb@fe3c0000: USB EHCI 1.00
Bus usb@fe3c0000: USB IHCI 1.0
Bus dwc3: usb maximum-speed not found
Register 2000130 MbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus usb@fe30000 for devices... 1 USB DEvice(s) found
scanning bus usb@fe3a0000 for devices... 1 USB Device(s) found
usb@fe3c0000 for devices... 1 USB Device(s) found
usb@fe3c0000 for devices... 1 USB Device(s) found
scanning dwc3 for devices... 1 USB Device(s) found
           scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot: 0
Card did not respond to voltage select!: -110
switch to partitions 0, OK
mmc1 is cuurent device
Scanning mmc 1:1...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
220 bytes read in 6 ms (37.1 KiB/s)
1:      LibreELEC
Retriving file: /KERNEL

Hi guys

I am trying to install printer drivers on my Pinebook Pro but unfortunately thee driver I have found on the AUR is not available for the ARM architecture.

I have done some digging and found this Reddit thread:

https://www.reddit.com/r/archlinux/comme...t_for_aur/

One of the comments here say you can bypass the architecture check in pacman by using the -A command and there is still a chance that it will work and I am willing to test it.

Unfortunately I am not currently at the level of being able to use pacman to install something from the AUR so I was wondering whether there was a way to bypass the architecture check on pamac instead?

Kind regards

Josh

Hi, I noticed that the cloudmedia site is down so all the links for Rockbox firmware are not working. Is there any way how to download the latest official Rockbox firmware?