• Posts

  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

tparys's Achievements

  1. 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.
  2. Current thread ->
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. Those are example bits of bash script from the Armbian build system. Poke around in Search for "BOOTSOURCE="
  9. 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.
  10. 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.
  11. @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.
  12. 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.
  13. Perhaps look at /boot/armbian_first_run.txt.template ?
  14. 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
  15. 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.