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:

• in case of problems I'd need to know my way back to boot the old kernel: u-boot recap and learning
• test suspected problems with the #sata #pcie ctrl beforehand (get a second Pine64 sata ctrl for the test system)

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…

unobtrusive good, mild, low on acid

Good to drink black without sugar.

#espressi by @QuijoteKaffee@mastodon.social

Inevitability rhetoric is a cunning fraud designed to render us helpless and passive in the face of implacable forces that are and must always be indifferent to the merely human

The Age of Surveillance Capitalism: The Fight for a Human Future at the New Frontier of Power
by Shoshana Zuboff

#SurveillanceCapitalism #privacy

A led light bulb (230V~) went dark in a room. By dark I mean that it dimmed down to very low light. No, I do not have a dimmer nor is it a light bulb with some fancy build-in iot stuff.

Two classic halogen bulbs didn't work in that socket. Testing the led bulb in a different socket it worked. I looked for contact problems and cleaned the contacts and the lamp seemed to work again using the led light bulb.

Then it went dark again and I decided to exchange the socket in the lamp. Opening the socket I found that in-between one of the cables and the socket an electronic part had been placed by soldering it to the end of the power line and fastening it to the socket.

I took out that part having never seen a stupid simple lamp coming with some small electric part build in. The lamp worked again with the all the bulbs I had tried.

Looking at for the specs I found this datasheet. It seems to be a resettable fuse or polymeric positive temperature coefficient device. I didn't know about these, but obviously the one I took out of the circuit seemed to have broken in a way that it switches too fast to a high resistance that only allows the led light bulb to glow dimly and isn't sufficient to drive a classic light bulb.

I guess the pptc has been put into the plastic lamp to protect it from heat: If a certain amount of power would be exceeded the light bulb used probably would emit too much heat for the lamp case. Still the lamp came with the usual label saying what light sources are allowed, but not stating any hint that it would not work with non-spec light sources or would contain active electronic parts.

The solutions once concocted by scholars of elk herds, sea turtles, and geese have been refurbished by surveillance capitalists and presented as an inevitable feature of twenty-first-century life on Earth. All that has changed is that now we are the animals

The Age of Surveillance Capitalism: The Fight for a Human Future at the New Frontier of Power
by Shoshana Zuboff

#SurveillanceCapitalism #privacy

but the surest way to predict behavior is to intervene at its source and shape it

The Age of Surveillance Capitalism: The Fight for a Human Future at the New Frontier of Power
by Shoshana Zuboff

#SurveillanceCapitalism #privacy

Marese Bio Espresso

60% Arabica - 40% Robusta. Intense, low acid, dark, strong. Just ordered another batch and am waiting to open the first bag. #favorites: I bought it again and again after trying others.

We grow numb to these incursions and the ways in which they deform our lives. We succumb to the drumbeat of inevitability, but nothing here is inevitable. Astonishment is lost but can be found again

The Age of Surveillance Capitalism: The Fight for a Human Future at the New Frontier of Power
by Shoshana Zuboff

#SurveillanceCapitalism #privacy

moccafair Espresso El Rubio Bio

It's one of my #favorites. Sometimes it tasted just a tid too bitter, but usually very balanced.

#espressi

People habituate to the incursion with some combination of agreement, helplessness, and resignation. The sense of astonishment and outrage dissipates. The incursion itself, once unthinkable, slowly worms its way into the ordinary. Worse still, it gradually comes to seem inevitable

The Age of Surveillance Capitalism: The Fight for a Human Future at the New Frontier of Power
by Shoshana Zuboff

#SurveillanceCapitalism #privacy