Ein neuer Forumbeitrag: https://linux-nerds.org/topic/1676/rockpro64-mainline-kernel-6.13.0-1197-ayufan #rockpro64 #linux
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…
Follow-up to this note
Meanwhile Dragans changes to the dtb file helped my testing setup to boot without eMMC. So I could test booting manually from scsi devices like on my production system.
Looking for some simple instructions on how-to do this failed and I put together the following information.
u-boot on #RockPro64 uses variables written to flash. The important ones for choosing a device/kernel to boot:
# this u-boot will look for scsi devices only
boot_targets=scsi
# it will scan the devices for
bootcmd=bootflow scan
Since I have a boot.scr in my /boot the bootmeth seems to be script. There's also the source of that file boot.cmd available and from there I extracted the commands to run on the u-boot console to start any kernel/initrd/dtb I could find on disk:
# initialize pci bus
pci enum
# show devices on pci
pci
# reset bus and scan for scsi devices
scsi reset
# get partition table
scsi part
# find boot files
ls scsi 0:1 /boot
# load armbian defaults
load scsi 0:1 0x800800 /boot/armbianEnv.txt
# replace the xyz on the following line with the
# filesize output by 'load' above
env import -t 0x800800 xyz
# write uuid of partition to variable partuuid
part uuid scsi 0:1 partuuid
# arguments passed to the kernel on boot
setenv bootargs "root=${rootdev} rootwait rootfstype=${rootfstype} ${consoleargs} consoleblank=0 loglevel=${verbosity} ubootpart=${partuuid} usb-storage.quirks=${usbstoragequirks} ${extraargs} ${extraboardargs}"
# look for available images, initrds and dtbs
ls scsi 0:1 /boot
# get the dtb directory, **uInitrd** and the vmlinuz
# from the output to use with the following 'load' commands
load scsi 0:1 0x02080000 /boot/
load scsi 0:1 0x06000000 /boot/
load scsi 0:1 0x01f00000 /boot//rockchip/rk3399-rockpro64.dtb
booti 0x02080000 0x06000000 0x01f00000
At this point I only needed to wait for the Pine64 sata ctrl to arrive to test the current kernel with the same ctrl used in my production system.
So I went back to the fork in the tunnels and took the other way down the #RabbitHole…
Follow-up to this note:
At one of the times the current #Armbian #linux kernel didn't crash, but booted on my #RockPro64 I installed #GotoSocial and yes: no more strange error messages running it. The only time I remember that I updated a linux kernel to make an application work.
Preparations to get the production system running with the newer kernel:
Meanwhile Dragan had patched the device tree and asked to check on a few reboots whether this would make a difference or cause any regressions.
Further down the #RabbitHole the tunnel forks…
Follow-up to this note:
I decided to test whether #GotoSocial would work on the #RockPro64 using the current instead of the legacy #Armbian kernel before risking problems upgrading my production #yunohost.
I have a similar testing setup: old mechanical drives instead of SSDs, a different PCIe SATA controller, an additional eMMC.
The additional eMMC I need to boot from, because for some reason the PCIe SATA ctrl didn't work, when u-boot initializes the controller before the kernel.
Installing the current kernel on my testing setup I found it not working: no console on hdmi, no network. Forgot to install the newer dtb (device tree binary) as well.
With currrent kernel and dtb from #Armbian installed the system booted half of the times I switched it on. Asking around on the rock64 chat I met Dragan Simic who greatly helped me to get further down the #RabbitHole…
On my #yunohost I tried to update #gotosocial from 0.17.4~ynh1 to 0.18.1~ynh1 and the update failed.
GotoSocial just showed some cryptical error messages when started.
@dumpsterqueer@superseriousbusiness.org traced the problem back to a changed lib version used in the new GotoSocial version and the developer of the lib answered my #linux kernel would be too old.
The old #armbian legacy kernel is running, because … I don't remember.
I need a kernel update for my #rockpro64.
Down the #RabbitHole…
I used Pmbootstrap to install PostmarketOS onto my RockPro64. You pick a variety of options and settings then you choose which disk to install it to and whether you want fde or not.
wiki.postmarketos.org/wiki/Install...
#postmarketos #pine64 #rockpro64
Installation/Using pmbootstrap...
It's been a nice holiday break with relaxing #bsd projects. Final upgrade before heading back to $DAYJOB:
Upgrade to NetBSD 10.1 on my #pine64 #rockpro64
I run ZFS on this ARM64 board with an NVMe SSD attached via PCI card.
Running well. dmesg:
This thing has been a headache and a half to get up and running, but now is running so smoothly
I tried OpenSuse on my RockPro64 and it worked with one hitch. I can't choose to have full disk encryption enabled. if I do it doesn't recognize any keyboard I have plugged in and I can't type in my FDE password. If I choose to not use FDE then it boots into the user login screen by which time my keyboard works. It took a bit of getting used to OpenSuse in terms of their package manager and other bits but I could see this being my main choice of distro on my RockPro64. FDE may not work properly on it right now but many distros don't even give the option for FDE on ARM64 so it's a step in the right direction.
Can anyone just tell me in like a dozen simple steps or less how to install #Debian onto a SATA disk in a #RockPro64 without fucking hammering nails directly into my forehead or reading a 438 page forum thread please for the love of god
If your answer starts with “maybe” or “I think” or “Just
” please directly fuck off into deep space, I only want to hear from people who have actually accomplished this and not vague reply guy guesses
Even though I don't think #Pine64 is going strong currently, I have to admit that my #RockPro64 is very solid hardware and has no issues whatsoever.
So far the #RockPro64 and the #MangoPi MqPro have been a blast to tinker around with and to set up in their final forms/use case.
The #OrangePi Zero 2w has been a fine addition and has a promising future.
Both RPi zeros have steady and running well for their respective use cases (pi-hole and mini nas).
The #MilkVMars has kind of been a disappointment since day one and not much has improved since then. Maybe it needs more time, but I just get more meh as it goes on.
Beholden thy #SBC abomination of jank. A #MangoPi MqPro plugged into a #OrangePi Zero W2 that controls 2 #RaspberryPiZeros (W & 2W) and a #RockPro64.
So much janky awesomeness in one place, it’s almost too much to handle! I now “offically” feel like a SBC enthusiast
@netbsd Just upgraded my Pine RockPro64!
Finally got time to do a clean install of NetBSD10_RC5 on my #RockPro64 with an eMMC module.
Previously I had RC1 running for several months.
I have a PCIe M.2 card and a 500gb SSD; hence a breeze to backup key config files from RC1 and then restore once RC5 was up and SSD mounted.
Everything looks great 
I've been running NetBSD10_RC for months on my RockPro64 and only recently learned about using
/usr/sbin/schedctl -A 4,5
to force a process to use the faster CPUs. Hopefully this improves a daily ffmpeg job I have.
#NetBSD #RockPro64 #pine64
Ein neuer Forumbeitrag: https://linux-nerds.org/topic/1555/rockpro64-mainline-kernel-6-8-0-rc3 1555/rockpro64-mainline-kernel-6-8-0-rc3 #rockpro64 #linux #mainline
Conclusion: Linux 6.6 broke something and uboot can't deal with it
Tried 23.01, 23.07, 23.10, 24.01
All failed to boot 6.6.8
Downgraded kernel to 6.5.13 and it came up fine
Still need to test another platform (like quartz64 or rock64) but this is my result on rockpro64
I think I did it! I got #raid1 set up on the #rockpro64. I got permissions all set and should be good to go there. Now I am in the slow process of transferring over files via the network- slow but steady.
