freezes on rockpro64

Yeah, the screen will be black for about 30 seconds before starts showing anything.
These 30 seconds is a silent uboot starting and a silent kernel load.

I swear this used to boot faster. Maybe I'm just imagining things. Its a server anyway, so boot time isn't that important.

If you aren't busy, spin up an 5.3.rc3 KDE image. I'll set that up and beat on it for a while to see if I can crash it.

It might have on 5.1. Some changes in the kernel and the rk3399 device tree has happened over 5.1, 5.2 and now 5.3.

Sure, I'll do that during the day. Will be ready for you next time you wake up.
File is ready here.
Let me know how that turns out.

Ive had freezes before but usually in our tests when I was really hounding the board with processes. Im not running a heat sink on it so I figured it was thermal overload causing it to sort of crap out. In recent tests (5.2/5.3) I havent really seen any but I will also take any new images and put them through some stress to help determine if it is hardware vs software issue.

Cooling is certainly not the issue. I have a huge fan and huge heatsink on it.

It's got to be software.

I can't flash it. Balenaetcher complains it might be corrupted. I've fetched it twice, tried each both in the archive and after manually decompressing it. Same issue. Attempted on a fresh manjaro install on my macbook.

Don't respin that image. Apparently, etcher doesn't work in Manjaro. I can still flash from ubuntu though. testing...

Black screen 45 seconds. 1:05 to login.
Ooooh, pretty login!
Zippy. Panfrost is loaded, but the renderer is still showing llvm.
Mesa is 19.1.4. I'll have it run through the AUR to test the new hardware acceleration and beat on the processor for a bit.

Network connections are unstable. I can only resolve local addresses. Anything outside only works for a little while. Current uptime is 38 minutes.

Also, mesa 19.2dev isn't in the damn AUR.

PCIe works. I dont know if it's stable but it can see and access the drives behind the SATA card.

We have mesa-git in the repo, that's 19.2-dev.

This is very good news.

This could be a DNS issue. Try turning of ipv6.

I have the big heatsink with a fan blasting but the rockpro64 I got yesterday always freezes at the exact same point in the pacman -Syu

Don't think its heat but the big heat sink with a 40mm fan epoxied on has this thing as chilled as a dope smoking penguin.

I edited /etc/pacman.conf

guessed at packages

IgnorePkg = linux-aarch* linux-firmware
IgnoreGroup = plasma qt5 kdeutils kdenetwork kdemultimedia kdegraphics kdebindings kdebase kde-applications

IgnorePkg = linux-aarch* linux-firmware is there as 5.2.7 does seem to kill graphics
But if you pacman -Syu now
It will work the whole way through
I have been rebooting then just commenting out
#IgnoreGroup = plasma qt5 kdeutils kdenetwork kdemultimedia kdegraphics kdebindings kdebase kde-applications
pacman -Syu finishes with no freeaze and all installed apart from 5.2.7

Its prob plasma or qt5 me tinks but haven't really pinned it down as from a fresh image its a lot of packages that now get updated with pacman -Syu

There are 2 probs 5.2.7 does kill graphics but also somewhere along the line from a fresh img of the 19.06 img preview there is some sort of clash of all those packages and installing qt5/plasma after seems to fix.

Also I don't think the network is unstable I think in the update a new ssh crypto is assigned but yeah ssh via hostname.lan drops and have been using console.
Something breaks connection during update though
I think my router id full of rockpi4 (still using rockpi4 on auto pilot) hosts names and need to do some cleaning and pruning but will continue with

Linux rockpi4 5.1.11-1-MANJARO-ARM #1 SMP Tue Jun 18 13:46:04 UTC 2019 aarch64 GNU/Linux

But got this script running for a while now


while true
iperf3 -c
iperf3 -c -R

with this in another terminal

while true
        sudo stress --cpu 4 --io 3 --vm 2 --vm-bytes 256M --timeout 10s
        sleep 11
stress: info: [11607] successful run completed in 10s
 09:58:03 up  2:06,  4 users,  load average: 5.03, 4.69, 4.58
 09:58:14 up  2:06,  4 users,  load average: 4.26, 4.54, 4.53

I am going to try 5.2.7 but so far mesa 19.2 doesn't seem to fix like it used to and also for some reason fbturbo obviously doesn't works as without remove panfrost and corruption is started as recognise it straight away looks just like panfrost after a fbturbo remove and reboot without the mesa 19.2-0devel compile

Yeah its a bit weird but the qt5 group seems to like a reboot and then install after the first
pcie is there though and my nvme0n1 :+1: with linux-aarch-rc

17 hours in, the networking issue hasn't come back. I rebooted and its been stable since. It's noticeably slower than the 5.1 and 5.2 kernels but that's a known issue and it'll be fixed with 5.3 is complete. It's still quite usable.

The mesa-git from the AUR doesn't compile on arm. Pacman says it can't resolve a dependency, llvm-libs=8.0.0. Trying to push it though does nothing.

I can't seem to find a way to read soc temp either.

/sys/devices/virtual/thermal/thermal_zone0 ?
zone1 i think is gpu

/1000 = temp


for i in /sys/class/thermal/thermal_zone* ; do
        type=$(cat $i/type|tr '[a-z]' '[A-Z]'|sed -e 's/-THERMAL/ Temp/')
        temp=$(cat $i/temp|awk '{printf "%.2f",$_/1000}')
        echo "$type" $temp "C"
is a decent script @mentaluproar

1 Like

That's why I said we have it in our repo.

Sorry I got the terminology mixed up. Either way, I haven't been able to get it working. Pacman says it's missing a dependency, and from what I can tell, it isn't. I tell it to install anyway and it doesn't.

Still stable, though it's been just sitting there idle while I work on another project. Seem stable so far. I'll push it harder with Plex, a few octoprint instances, homebridge, and hosting time machine backups soon.

If the graphics issue is worked out, this little board just got a LOT more useful. It's been happily sitting there as a server, but if it can transcode video in hardware, it can truly do everything I need it to do.

You guys rock.

xf86-video-fbturbo-git its been the back drop for whenever the new kernel or mesa seems to get disjointed, i have never had a dep prob.
It might be your aur attempts that may be causing the probs.
With mesa we have been running on the 19.2.0-devel version for some time but think approx 2019-09-01 the release version of 19.2 should hopefully permanently have us off the devel branch.

Prob 5.3 release maybe a week or so after.

Its has got a bit flakey again with panfrost but we are on RCs and dev offerings but for the rockpro64 & manjaro its pretty much complete.
xf86-video-fbturbo-git is a life saver but panfrost when complete should co-exist far more and provide much better performance.

My opinion on spi-nor and booting from nvme from the trouble it seems to cause is don't bother yet.
I do have one request and that is to give us a boot partition as nvme works great the kernel loads the root so for now no need to bother with uboot nvme.
When the root is loaded though the boot folder is part of another root and updates will go to the wrong place.
Guess you could fstab to a mount then symlink or bind mount it, but my request is for a separate boot partition and root as thinking pretty easy to provide and then it just becomes a clean and simple fstab entry.

From 190.06 if I do the

IgnorePkg = linux-aarch* linux-firmware
IgnoreGroup = plasma qt5 kdeutils kdenetwork kdemultimedia kdegraphics kdebindings kdebase kde-applications
pacman -Syu

Then delete the entries and finish off the pacman -Syu it works every time but fails every time if not.
Dunno what it is but the above works

Try updating from TTY instead of terminal emulator. Maybe it's just the GUI that freezes?

Been having to as for some reason network is flakey whilst upgrading, been using local console almost solely of late.
But via local console if you upgrade -Syu from 19.06 it freezes every time unless the above.

Forum kindly sponsored by Bytemark