TIL #FreeBSD does not support GPU device on #arm64. At least, not on my #ROCKPro64 card. Unless the web pages I found are wrong.
That just impacts transcoding here so no big deal. But it might be a bit more troublesome for ones who wanted to build a desktop out of it.
But... it has Linux emulation support.
Which means I can drop penguins farts in ARM jails.
Parts for #RunBSD on the #pine64 #ROCKPro64 board - episode 2 have all been received.
If you missed it, episode 1 was: https://www.tumfatig.net/2026/bsd-discovery-on-the-pine64-rockpro64/
@occvlt please, which versions of FreeBSD have you tested?
<https://www.reddit.com/r/freebsd/comments/1ncisfh/error_bootlualoaderlua511_attempt_to_call_a_nil/> recently described an issue with a minor upgrade from 14.2-RELEASE to 14.3-RELEASE.
Since I started to use the #debian kernel instead of an #armbian legacy kernel on my #RockPro64 I had a few crashes. Most of them seemed to have been related to #sata, because they stopped after I exchanged the sata pcie with another one of the same type.
I had another #oops afterwards and decided I should look for a #watchdog to reboot the system in case of trouble.
After reading a bit about watchdogd the most simple solution I found is:
El Blog de Lázaro 
𝙹𝚘𝚎𝚕 𝙲𝚊𝚛𝚗𝚊𝚝 ♑ 🤪
Graham Perrin
FrankM
Chris Vogel
root@TEST:~# cat /etc/cron.d/watchdog
@reboot root wdctl -s 180
* * * * * root echo "1" > /dev/watchdog
I'm testing it on a non-productive board and it seems to be good. It works for a forced oops echo c > /dev/sysrq-trigger and if I stop cron.
But it doesn't work in the state after a simple halt: the system tries to start and hangs after showing the first line of u-boot output.
Follow-up to this note.
Dragan had asked me to do repeated power-cycle tests with different kernel versions using the patched dtb for #RockPro64 to make sure the kernel #oops wouldn't still be an issue.
I learned that cutting the power of the device could kill the #LPDDR4 #RAM. This is documented in the specification referenced on the RockPro64 wiki page for Micron LPDDR4 Mobile LPDDR4 Datasheet as stated on page 37 in Uncontrolled Power-Off:
An uncontrolled power-off sequence can occur a maximum of 400 times over the life of the device.
I never had heard about this before! Cutting power without shutdown can kill my RAM?
show dmesg and shutdown
To get all the debugging information I needed I wanted the system after booting to print dmesg to the serial console, wait a short time and then actually shutdown.
root:~# cat /root/bin/dmesg_and_shutdown.sh
#!/bin/bash
# a small script that outputs dmesg to serial
# console, waits 20 seconds and shuts down
dmesg > /dev/ttyS2
# show a message how to stop this script and wait 20 seconds
echo "Will shutdown in 20 seconds - to stop me call 'pkill dmesg_and_shut'" > /dev/ttyS2
sleep 20
echo "shutdown -h" > /dev/ttyS2
shutdown -h now
# a cronjob that runs after each boot
root:~# crontab -l
@reboot /root/bin/dmesg_and_shutdown.sh
powercycle the board
I took the time needed for a complete cycle of booting, showing dmesg, waiting and shutting down: well below 2 minutes.
To automate the power cycle I used an #esp8266 based power switch made by #Sonoff (Powr2) running ESP Easy (mega-20210503).
#ESPeasy offers a simple scripting language I used to powercycle after 120 seconds of being switched on:
On System#Boot do
gpio,12,0
gpio,13,1
endon
On button#button_state do
if [blue_led#blue_led_state]=1
gpio,13,0
timerSet,1,2
else
gpio,13,1
gpio,12,1
timerSet,1,0
timerSet,2,0
endif
endon
On Rules#Timer=1 do
gpio,12,0
timerSet,2,1
endon
On Rules#Timer=2 do
gpio,12,1
timerSet,1,2
endon
Pressing the button on the Sonoff device toggles between:
logging
minicom logged the serial output to a file.
Further down the #RabbitHole I went when looking at the resulting logfile…
