tparys

As mentioned earlier in this thread. Easiest is to add script lines to /etc/rc.local and enable rc-local service via systemctl. I also set this up via thermal management in the linux via DTB overlay. I found it nicer as it kicked in almost as soon as the system turned on. https://forum.armbian.com/topic/17022-automatic-kernel-control-of-nanopi-m4-m4v2-metal-case-fan/

Glad you got it working. Though I am curious if there's a kernel or configuration difference between the current RK3399 kernel vs the older one you found to work. FYI. You may want to try and freeze your kernel, or be careful about what updates you pull. You fan may stop working one day, and you might just be putting this issue off until then.

Current thread -> https://forum.armbian.com/topic/18714-how-to-make-the-ubutu-scripts-useful-in-armbian-to-make-the-fan-of-nanopi-m4v2-sata-hat-always-running/

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.

So, Armbian's M4V2 images base off both Debian and Ubuntu. Sounds like you're using the Debian version. The good news is that what you're trying to do should be compatible with both, but it might be easier to not use their stuff as-is. The easiest way is to add that bit of bash script to /etc/rc.local and make sure the rc-local service is enabled. That should turn your fan on and leave it going on every boot. $ sudo systemctl enable rc-local $ sudo systemctl start rc-local The rc-local service exists at least on the Ubuntu version. It should exist on Debian as well. But even if it doesn't it's pretty easy to add it. FYI, that little bit of shell script is enabling the PWM channel to loop every 50000 clocks, remaining high 45000 of those clocks (45000/50000 = 90% power). Note that you shouldn't have to enable the PWM more than once.

Werner is right that this probably should have gone in peer to peer support or general chat. This forum is for bug reports with supporting debug information (armbianmonitor). Maybe he'll move this for you. In the meantime, maybe this would be worth a read. https://forum.armbian.com/topic/17022-automatic-kernel-control-of-nanopi-m4-m4v2-metal-case-fan/

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.

Those are example bits of bash script from the Armbian build system. Poke around in https://github.com/armbian/build Search for "BOOTSOURCE="

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.

That makes more sense. But if you had built a LUKS v1 volume on that system, it should have worked, just without some of the newer features that LUKS v2 gives you. Though that probably would have been needed if you wanted to use the 4k block size, Argon password hash, or an external drive you set up on a different system. Unfortunately, probably nothing that helps with the posted question.

@djurny, the console log was from my system, which appears to be working fine. And strictly speaking, LUKS is only an on-disk format, so there's really nothing that you can recompile. You can recompile the kernel (for missing features / ciphers), or cryptsetup (which is generally provided from upstream). But I'd be curious to hear exactly what your problems were and what you had to do. @a5s397, "cryptsetup luksDump /path/to/volume" should identify whether LUKS 1 or 2 is in use, as well as any other chosen parameters. If you still need help, you'll need to provide some more information. Otherwise, there's not enough here to go on.

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.

Perhaps look at /boot/armbian_first_run.txt.template ?

Interesting. Just remembered that my NanoPi M4V2 also uses the same RK3399 as your Rock Pi 4, and using the rockchip64 kernel. Offhand it seems to be working as expected with a test volume using default parameters. Kernel 5.10.43-rockchip64. I hate to suggest it, but is your MicroSD / SSD failing? If so you'd see lots of lost errors about lost DMA pages in the output of dmesg. You can also try to mount that volume on a separate PC, to verify the problem is with the board and not the card/disk. console.txt

I think @lanefu was referring to doing a diff between the configs of the rockchip64 kernel which does not work, and the sunxi kernel which does. Based on the error, I'd wager the keyslot open is failing because you're missing a hash function. Believe the default is SHA1, unless you specified something different. Running "cryptsetup luksDump /dev/sda1" or whatever, should tell you for sure. If your system has AF_ALG compiled in, you can also run "cryptsetup benchmark", which runs typical hash and cipher algorithms used by LUKS. If it fails on something, that could be a clue.

Adding to armbian-config is certainly a possibility, but as the tool is pending a massive rewrite, and the desired tool for the redesign (Ansible) is not in my bag o tricks, I'll probably hold off on doing that. I almost feel like it might fit better in the Armbian BSP generated from the build system, but am open to opinions.

Not that this won't work, but is a dangerous way to go about it. If the new image doesn't boot for some reason, you can't recover remotely. The sectors used by u-boot / ATF / etc vary by board. This will also destroy the MBR partition table if it exists. Unless the board uses GPT, you'll likely nuke all your data too.

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

It has been my experience, that enumeration order of USB to serial devices is largely consistent boot-to-boot. At, least if they're all the same device / driver, and you're not moving cables between connectors. If that's not working, there's some udev examples HERE. You can also have udev dump everything that's worth looking at, and grep'ing for the devices you're looking for. udevadm info -e | less If they're all the same device and you need unique names, I'd probably separate them via DEVPATH, which basically works out to the appropriate position in the bus hierarchy. I'd also suggest giving them descriptive symlinks instead of renaming the devices, and address your devices that way.

1.5.1-1 is current as of Ubuntu Focal. Perhaps a version difference in Debian, or an outdated install? The output of "armbianmonitor -u" might help.

ifupdown

Works on both my laptop (amd64) and my NanoPi M4V2 (arm64). Both are 1.5.1-1. Perhaps you're not trying to compile the file you think you are.

The snippet you posted compiles fine for me.

linux,code = <KEY_POWER>; gpios = <&pio 0 20 GPIO_ACTIVE_LOW>; These two lines. When compiling outside of the kernel source, constants like GPIO_ACTIVE_LOW don't get resolved because they don't have the kernel headers included in the compilation path. If you have the linux kernel sources downloaded, a simple grep will tell you what they're supposed to be. tparys@wander:linux/include/dt-bindings$ grep -r GPIO_ACTIVE_LOW . ./gpio/gpio.h:#define GPIO_ACTIVE_LOW 1 I'd also check that KEY_POWER is correct. That's not part of the 5.10 mainline, as far as I see. In the future, just comment out parts of your dtc overlay until it compiles, and add parts back in until it breaks. Should narrow your problems down pretty quick.