tparys

If it's a TV box, you might get better results in the TV box forum.
 
But some systems have the DTB embedded in the kernel image. If you can get to a shell, you can dump it from a running system sorta like:
 
dtc -I fs -o devicetree.dts /sys/firmware/devicetree/base  
Keep in mind that there are periodic changes to the DT format over time, and some vendors put in nonstandard hacks. Keeping these DTB files current is a major issue for Armbian devs. If it's for an unsupported box, it'll almost certainly require changes for everything to work properly.

Ever since I read through THIS POST a while back, I started digging through the cpufrequtils init script, and was a more or less disappointed with what I found. It's largely a product of the CPUs that were available around that time (eg - Pentium 3). Namely that all cores in the system are the same, and there's should be only one master policy that controls everything.
 
Of course ARM big.LITTLE totally breaks these assumptions, and leaves the script with no viable way to specify different schedulers or frequency ranges for each CPU cluster. It still runs, but not really correctly. For example, you can't set the RK3399 little cores above 1.4 GHz, but that's basically what it attempts to do on every boot.
 
Also it needs use "cpufreq-set" to do it's job, which seems too hard when the sysfs interface is already pretty simple. Really, that extra complexity isn't buying you a single thing. Maybe it made more sense 10-15 years ago.
 
So I took a crack at doing a far simpler, stupid version of that script (on perhaps smarter depending on perspective). It can generate it's own config, and I think that it comes across much more readable and accessible.
 
### # CPUFreq policy for CPUs: 0 1 2 3 # # CPU Frequency Governor # Avail: conservative ondemand userspace powersave performance schedutil POLICY0_GOVERNOR=ondemand # Min/Max Frequency Selection # Avail: 408000 600000 816000 1008000 1200000 1416000 POLICY0_MIN_FREQ=408000 POLICY0_MAX_FREQ=1416000 ### # CPUFreq policy for CPUs: 4 5 # # CPU Frequency Governor # Avail: conservative ondemand userspace powersave performance schedutil POLICY4_GOVERNOR=conservative # Min/Max Frequency Selection # Avail: 408000 600000 816000 1008000 1200000 1416000 1608000 1800000 POLICY4_MIN_FREQ=408000 POLICY4_MAX_FREQ=1800000  
And using it isn't too hard ...
 
cp cpufrequtils-bl /etc/init.d/ sudo /etc/init.d/cpufrequtils-bl save sudo vi /etc/default/cpufrequtils-bl sudo systemctl disable cpufrequtils sudo systemctl enable cpufrequtils-bl  
I know that this is probably pretty far down on the list of priorities, but does anyone thing that this would be useful to others?
 
cpufrequtils-bl

The pps_gpio module does not take parameters. Definitions of a PPS device must be in the DTB, or overlay: https://mjmwired.net/kernel/Documentation/devicetree/bindings/pps/pps-gpio.txt
 
 
That's because you're missing parts of the DTB overlay. Notably, you need to specify that:
It's an overlay Where it applies ("target" or "target-path") What you're doing there (overlay or fixup) And in this case, what you're adding ... You probably meant to do something like this instead. Note that I don't have your setup, nor your board, so can't test this. But probably a better start than where you are.
 
/dts-v1/; /plugin/; / { compatible = "rockchip,rk3328"; // Define a PPS device on GPIO Bank 1, pin 2 fragment@0 { target-path = "/"; __overlay__ { pps0: pps-gpio0 { compatible = "pps-gpio"; gpios = <&gpio1 2 0>; assert-falling-edge; }; }; }; };  

Ever since I read through THIS POST a while back, I started digging through the cpufrequtils init script, and was a more or less disappointed with what I found. It's largely a product of the CPUs that were available around that time (eg - Pentium 3). Namely that all cores in the system are the same, and there's should be only one master policy that controls everything.
 
Of course ARM big.LITTLE totally breaks these assumptions, and leaves the script with no viable way to specify different schedulers or frequency ranges for each CPU cluster. It still runs, but not really correctly. For example, you can't set the RK3399 little cores above 1.4 GHz, but that's basically what it attempts to do on every boot.
 
Also it needs use "cpufreq-set" to do it's job, which seems too hard when the sysfs interface is already pretty simple. Really, that extra complexity isn't buying you a single thing. Maybe it made more sense 10-15 years ago.
 
So I took a crack at doing a far simpler, stupid version of that script (on perhaps smarter depending on perspective). It can generate it's own config, and I think that it comes across much more readable and accessible.
 
### # CPUFreq policy for CPUs: 0 1 2 3 # # CPU Frequency Governor # Avail: conservative ondemand userspace powersave performance schedutil POLICY0_GOVERNOR=ondemand # Min/Max Frequency Selection # Avail: 408000 600000 816000 1008000 1200000 1416000 POLICY0_MIN_FREQ=408000 POLICY0_MAX_FREQ=1416000 ### # CPUFreq policy for CPUs: 4 5 # # CPU Frequency Governor # Avail: conservative ondemand userspace powersave performance schedutil POLICY4_GOVERNOR=conservative # Min/Max Frequency Selection # Avail: 408000 600000 816000 1008000 1200000 1416000 1608000 1800000 POLICY4_MIN_FREQ=408000 POLICY4_MAX_FREQ=1800000  
And using it isn't too hard ...
 
cp cpufrequtils-bl /etc/init.d/ sudo /etc/init.d/cpufrequtils-bl save sudo vi /etc/default/cpufrequtils-bl sudo systemctl disable cpufrequtils sudo systemctl enable cpufrequtils-bl  
I know that this is probably pretty far down on the list of priorities, but does anyone thing that this would be useful to others?
 
cpufrequtils-bl

Interesting. Doing some more digging into the debian postinst scripts. May be useful for you in the future if this becomes a continuing issue.
 
The resolvconf package touches this file after installation (/var/lib/dpkg/info/resolvconf.postinst), but only once (tracked via a file you can pre-place, and disable any action on its part).
 
# Linkify /etc/resolv.conf if appropriate if [ ! -e /var/lib/resolvconf/linkified ] ; then ... <snip> ... ln -nsf ../run/resolvconf/resolv.conf /etc/resolv.conf # Make a record that we have created it :> /var/lib/resolvconf/linkified fi  
Looks like network-manager does too (/var/lib/dpkg/info/network-manager.postinst), but only if it's already a link.
 
SystemD appears to poke this file on a fresh installation (/var/lib/dpkg/info/systemd.postinst), but not on upgrade.
 
Might be useful to find out what /etc/resolv.conf is pointing to, and look for that pattern in /var/lib/dpkg/info? Might tell you which package is tripped you up, and how to prevent it from doing that in the future?

First, "armbian-monitor -u". Edit your top post and add it at the top.
 
What you're seeing is initial ramfs (or initramfs), but is often written as inital ramdisk (or initrd) for historical reasons. It's singular job is to mount the root filesystem before init / SystemD takes over. It's basically a compressed archive (CPIO) of a bunch of scripts made by initramfs-tools (or dracut on systems like Redhat) that load drivers and pivot to the real filesystem before continuing.
 
In this case, it's attempting to mount the device listed as "/dev/mmcblk0p1", and it can't find it, and eventually gave up. Linux is running, but boot is stuck.
 
If the MMC interface is anything like the Ethernet subsystem, devices get enumerated based on the order they are found. So eth0 is first, eth1 is second and so forth. If two drivers load at the same time, there's a possible race condition and they can flip occasionally, and even change behavior after a software update. This is also the reason for the "persistent" Ethernet device names like "enp3s2" which are crazy looking, but deterministic.
 
I've noticed that many ARM boards get device names from the DTB aliases. But maybe it's not being used for whatever reason? Not sure.
 
In the meantime, if mmcblk0 and mmcblk1 occasionally swap position, it's probably far better to specify your root device via LABEL or even better, by UUID.
 
$ sudo blkid /dev/mmcblk0p1  
Then change your boot arguments to include "root=UUID=<WHATEVER>". Should be in /etc/armbianEnv.txt. but don't have it in front of me at the moment.
 
Also update your /etc/fstab to point to "UUID=<WHATEVER>", else you won't get much further.
 
More information on initramfs-tools, and boot arguments: https://manpages.debian.org/testing/initramfs-tools-core/initramfs-tools.7.en.html

The -c was there before. It's yelling about the extra file on the end which isn't a .sha file ...
 
https://github.com/armbian/documentation/pull/160

Depending on how different the u-boot sources are, the patches may or may not work.
 
You can always make those changes by hand to create a new set of patches, but might be some work.
 
Unfortunately, if it were simple, Armbian would not be dropping support for some boards.

The -c was there before. It's yelling about the extra file on the end which isn't a .sha file ...
 
https://github.com/armbian/documentation/pull/160

Looks like you're passing both the checksum file and the image file to " shasum -c ".
 
The checksum file looks to be loading correctly, but obviously the image file is not a text file with checksums, so it's failing.
 
Maybe just call it like this?
 
shasum -a 256 -c Armbian_21.08.1_Orangepipcplus_buster_current_5.10.60.img.xz.sha  

My understanding is that the overlayfs package is provided by the Ubuntu upstream packages, and is not part of the Debian repositories. Armbian does not provide or directly support this software package.
 
It's likely that with some minor work, it would be compatible with the base Debian image, however is out of scope of the Armbian project.

Recently we announced that we are going to drop support for bulk of boards to secure better quality for those that will remain. But which will remain? Those who will have at least one dedicated maintainer - anyone can become one. 

Check new "Armbian standard" support policy:
 
Armbian team took over what was possible while the remaining boards, which won't get a maintainer by December 1st, will loose support status and will be removed from the download pages.
https://github.com/armbian/build/pull/3148

Apply and help
 
Apply for maintainership by contacting @yang or @Werner

In that case, it looks like I misunderstood you. Apologies for that.

Offhand, probably not a great idea to mix and match Debian and Ubuntu repositories. You may want to reinstall with the Debian derived Armbian before continuing. There's a very good chance you'll end up with library versioning issues, unless you know what you're doing.
 
That said, it looks like you put "stable/updates" instead of "stable-updates" in your /etc/apt/sources.list ...
 

EspressoBin is currently in CSC support, so best to submit bugs/questions in in Peer to Peer Support.
 
Also need to submit armbianmonitor output. It seems dumb, but there's a lot of necessary information in there.
 
 
However, in this case, it tells you exactly what died. You've somehow uninstalled busybox (directly or indirectly), and initramfs-tools can't work properly without it.
 
 
Not advisable. The initramfs-tools package generates the initrd file for the kernel, which is generally a required part of the boot process. You'll want to get this fixed, and probably not reboot in the meantime until you do.

https://forum.armbian.com/topic/18583-encrypted-image-no-prompt/?tab=comments#comment-126748

Took a quick look on my system doing that.
 
Doing "systemctl status", I don't see any obvious services that were started or stopped.
 
You might learn more reading up on the options in the NetworkManager command line tool:
 
$ man nmcli  
Or check with the XFCE guys over at https://forum.xfce.org/ what exactly that network widget does.

Pssst ... If you cat the trigger file, it'll tell you the valid options, and which one is currently selected.
 
tparys@laptop:~$ cat /sys/class/leds/input4\:\:capslock/trigger none usb-gadget usb-host rfkill-any rfkill-none kbd-scrolllock kbd-numlock [kbd-capslock] kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock ACAD-online BAT0-charging-or-full BAT0-charging BAT0-full BAT0-charging-blink-full-solid disk-activity disk-read disk-write ide-disk mtd nand-disk cpu cpu0 cpu1 cpu2 cpu3 cpu4 cpu5 cpu6 cpu7 panic mmc0 rfkill0 phy0rx phy0tx phy0assoc phy0radio rfkill1 audio-mute audio-micmute  
I'd wager the correct trigger is "mmc0", unless there's a both a SD card and eMMC slot on that board?

If it's a TV box, you might get better results in the TV box forum.
 
But some systems have the DTB embedded in the kernel image. If you can get to a shell, you can dump it from a running system sorta like:
 
dtc -I fs -o devicetree.dts /sys/firmware/devicetree/base  
Keep in mind that there are periodic changes to the DT format over time, and some vendors put in nonstandard hacks. Keeping these DTB files current is a major issue for Armbian devs. If it's for an unsupported box, it'll almost certainly require changes for everything to work properly.

nanopim4v2 rc.local[3751]: /etc/rc.local: 16: echo: echo: I/O error  
That's the script error, probably line 16. Not sure why it failed. I don't see anything obviously wrong.
 
Depending, it's possible the kernel is still initializing the PWM device at the time it runs. You can add some print statements like "echo HERE" to you script to confirm where it dies. You can try to add a delay like a "sleep 30" at the start of the script, but that's just a guess. Not sure why you'd be getting an I/O error.
 
It's also possible that there's some kernel version differences between the FriendlyElec build and Armbian's kernel, so that scripting might need some changes.
 
For example, I had to do this to turn on the PWM fan on my M4V2 metal case. You may need to experiment a bit.
 
echo 0 > /sys/class/pwm/pwmchip1/export echo normal > /sys/class/pwm/pwmchip1/pwm0/polarity echo 50000 > /sys/class/pwm/pwmchip1/pwm0/period echo 40000 > /sys/class/pwm/pwmchip1/pwm0/duty_cycle echo 1 > /sys/class/pwm/pwmchip1/pwm0/enable  
 
Edit: As a note, my M4V2 had pwm0 set as inverted by default. Your settings of 90% power could be interpreted as 10% instead, and may not be enough for the fan to spin.

For what it's worth, Microsemi sells lots of stuff designed by Jackson Labs Technologies, which might open up the market options.
 
Also, if you're looking for accurate clocks you can disconnect and take indoors, the term you're looking for is GPS Holdover. Just fair warning that the more accurate the clock, the longer it might take with view of the sky before it hits full accuracy (though Microsemi won't advertise that). FYI, double oven temperature compensated oscillators can get better accuracy than the some commercial grade atomic clock options, but may take up to 3 days of warmup to get to full spec..
 
But if you're going to procure a couple and take them inside, consider a battery backup to avoid the initial training time, and make sure they get lots of sunlight before you need them.

On a local network, NTP tends to have an offset/jitter of around 20-50 ms.
 
Distributing PPS to all your computers (may require signal buffering / EMI shielding) should get it down to <10 ms.
 
You can also consider Chrony w/ PTP support, but will require all your network switches to support it to get the best performance. I don't recall offhand if it requires driver/kernel support.
 

On a local network, NTP tends to have an offset/jitter of around 20-50 ms.
 
Distributing PPS to all your computers (may require signal buffering / EMI shielding) should get it down to <10 ms.
 
You can also consider Chrony w/ PTP support, but will require all your network switches to support it to get the best performance. I don't recall offhand if it requires driver/kernel support.
 

When using an encrypted root, it needs to be unlocked and prepared for mount in the kernel initramfs. This part runs after u-boot, but before SystemD takes over. It also have slightly different rules on where kernel output goes, where it only goes to one "console", which is specified in the kernel arguments (visible after boot in /proc/cmdline).
 
If memory serves, the last "console=" argument takes priority during initramfs (though its hazy sometimes and it might be the first). You may need to adjust the order of the kernel arguments to make your password prompt appear on VGA or serial console (whichever you expect).
 
I don't have a rockpro64 to test with, but you should verify that it's not doing something silly like going to a serial port with a different baud rate than your uboot. FYI, RK3399's use an odd baud rate of 1.5 megabaud.

I've not tried this, but you might start looking at the 485 specific device tree bindings. If it's possible, you'll almost certainly need to write your own overlay.
 
Also, USB to 485 adapters are only around ~$15 USD on amazon. Unless you need to to use an onboard UART, or want to do it as a project, it may not be worth the time investment.