hi all,
  I have a problem with my eth to USB adapter. It has been reported sometime. My device is a realtek 1853 gigabit adapter. I use 3 RockPro64. one server, one client and one for the router.

A --- <usb3> R <eth0> --- B

I use iperf to measure the transmission speed. 

R © <usb3> ---> A(s) : ~710 Mb/s
R © <eth0> ---> B (s) : ~950Mb /s
B © --> [eth0] R [usb3] --> A (s) : ~12 Mb/s !!
A © --> [usb3] R [eth0] --> B (s) : ~ 900 Mb/s !!

The arrow indicates the request direction (from the iperf client to the iperf server)

and in the last case I have in the router log :

So I have upgraded my trusty Asus Chromebook Flip C100P, now about five years old and running a hacked-together Debian system, with a PBP. After installing Armbian on it and doing some test builds, I can confirm that a build which on the C100P was taking 1m15 is now, on the PBP, taking... 1m30.

Er, oops.

The C100P has a Rockchip RK3288C 1.8GHz quad core. If I'd done my research properly, I'd have known that the Pinebook Pro has a RK3399 with 2x1.8GHz and 4x1.5GHz cores; they both have 4GB of RAM. Apparently having the extra two cores doesn't make up for not having four high-speed cores.

Any suggestions on if there's anything to do to speed things up?

- using arm32 binaries instead of arm64 binaries might help due to reducing memory bandwidth (pointers are half the size). The C100P is all arm32.
- the build uses twice the system time on the PBP than the C100P. On the PBP I'm using f2fs on the internal eMMC. On the C100P I'm using ext4... but the PBP's eMMC is way faster, so unless f2fs is vastly less efficient than ext4 that shouldn't make a difference, surely?
- I don't have accelerated graphics yet, so it could just be spending all its time updating the xterm... but building from the console produces the same numbers.
- I haven't found hard numbers for the clock speed yet. The two fast cores seem to max out at 1800MHz. Will they go faster?

Hi all,
Received my PP 64 Convergence last week and have decided on postmarketos as my OS. I installed it to the EMMC with no issues. Now, I want to add my music files to the Lollypop music player. In Linux, I formatted a 64GB SD card with a FAT file system and did a copy/paste operation to load the songs on the card. When I boot the PP with the card inserted, there is short vibration followed by blank screen, then nothing. When I boot without the SD card installed, there is a longer vibration and then PMOS boots normally. It seems the phone insists on trying to boot from SD IF there is a card inserted, otherwise it proceeds to an EMMC boot. Is there a way to change this behavior? TIA for any assistance provided.

Steve Silvi

I have a Pinecil that I used for a single session which is now dead (no LED, no heat up) apart from being able to go into DFU mode and accept flashes.  Support advised me because it does DFU, the unit is working and that I should seek support from the IronOS folks.

It gets warm to the touch even when connected to a PC in DFU mode over 5v USB.

I suspect based on how warm it gets in 5 minutes in DFU mode with no tip, that this unit has a serious problem.   Can someone advise if it's normal for the housing of the unit to reach over 50C when not turned on?   I'm hessitant to leave it connected for too long for fear that it will melt or catch fire.

Here are some images:

Unplugged (Room Temperature is ~25C)



Plugged in for less than 30 seconds


Plugged in for 5 minutes

There is a thread for official Debian support, but it's not PBP-specific, so I thought it would be appropriate to create one here.

Since linux-image-5.10.0-7-arm64, the linux-image-arm64 meta-package in Debian Sid/Unstable now supports PBP. That corresponds to the kernel version 5.10.38. Latest version is actually 5.10.40. By now linux-image-5.10.0-7-arm64 should've made its way into Debian Bullseye/Testing, which should become the next stable some time this year. I've been running it for the past almost two weeks, and below are my findings so far, primarily compared to the 5.8.5 kernel build using xmixahx's pbp-tools. Since U-boot have an effect on some of the functionality, full disclosure - I'm using BSP u-boot release 2.0 by mrfixit (https://github.com/mrfixit2001/updates_r...filesystem). I have not yet tried other versions of u-boot, neither any of the custom builds nor u-boot-rockchip package from Debian repos that since some time ago claims to support PBP.

Did not test:
* Bluetooth

What works:
* WiFi
* Built-in display at native resolution
* 3D acceleration
* Webcam
* Built-in microphone
* Sound (built-in speakers and headphones, I'm still using custom acpid event to switch output)

What doesn't work:
* Deep sleep (regression compared to xmixahx's 5.8.5)

What works differently:
* Debian's kernel defaults to schedutil scaling governor.
* big cores are now limited to 1.8GHz instead of 2.0GHz, little cores still run at up to 1.416GHz. This could potentially explain why with Debian kernel I have not yet been running into any freezes outside of my attempts at deep sleep, unlike with xmixahx's 5.8.5 kernel.

Source based Linux distribution CRUX-ARM  adhering to ideology keep it simple, has its own package system, also supports the port system.

installation README.TXT
crux-arm-3.6-aarch64-core-rockpro64-5.12.9-build-20210605.img.zst
crux-arm-3.6-aarch64-core-rockpro64-5.12.9-build-20210605.img.zst.sha256

Is the entire board dedicated to bug reporting or is there a specific area?

After updating yesterday my phones audio is super scratchy, this was not the case before the update

Hoping for a fix on that 

Hi,

(in short: USB 2.0 devices don't work on the USB-A 3.0 port and I'm asking if this is normal behavior)

I've tried to see if this question has been asked before but typing usb into the search function will tell you that the word is too short, oops.
Didn't find it in the Wiki either, so here we go:

I've been testing my new Pinebook Pro and I've noticed that USB 2.0 devices won't be properly recognized on the left USB-A 3.0 port.

I've tested two thumbdrives so far, both of which will work well on the right side USB-A 2.0 port.
So I can rule out the devices are faulty.

But connecting them on the left side will produce errors about the device not accepting he setup address and eventual unability to enumerate the device (sorry, different notebook here so I can't paste, but it's quite generic. I will provide logs later, if needed).

I've tried a USB-A 3.0 hard drive that works well (with Pinebook wall plug connected), so the USB-A 3.0 port seems to be fine for those.

My question: Is this normal behavior? Are others seeing this?

I must ask if there a version of debian for the pinebook pro that can support the gpu without having to get too deep into recompiling things?(somewhat pain free install)

So I followed along the guide to install CentOS 7 referenced on the Wiki (and noted on the thread here: https://forum.pine64.org/showthread.php?...&pid=95685 and the guide on the developer's site here: https://project31.github.io/pine64/), and decided to give upgrading to CentOS 8 and then switching to Stream a try.

I followed a few guides online (specifically here https://www.tecmint.com/upgrade-centos-7-to-centos-8/ and here https://linux.web.cern.ch/centos8/docs/migration/), and with a tad extra fiddling to handle the kernel version, I was able to get fully updated and now am booting into CentOS stream!

My question is that upgrading 7 - 8 isn't technically supported, so I would like to try making an updated image for Stream 8.

The Project31 site has some info linking to it's inspiring project, which mentions taking the AArch64 image and a booting Armbian image and swapping out the rootfs bits while preserving the the /boot, /lib/modules, and /lib/firmware (here: https://github.com/umiddelb/aarch64/wiki...ch64-board)

When I try to follow up on this, I cannot seem to figure out how to take the images available on the CentOS site and extract the rootfs.... Can anyone point me in the right direction?

Thank you for your help, and your patience!