djurny

Hi,
If you want to know which kernel is used for your build, just run:
./compile.sh inventory-boards This will take some time.
Open the resulting .csv file, which will contain all combinations possible.
Groetjes,

Hi @Werner,
Not to pick nits, but 7 is the highest level (lowest priority) you can give a printk() statement. To make them appear however, the loglevel of the printk() needs to be smaller than the loglevel of the console, meaning the [console] loglevel needs to be 7+1:
loglevel= [KNL,EARLY] All Kernel Messages with a loglevel **smaller** than the console loglevel will be printed to the console. It can also be changed with klogd or other programs. The loglevels are defined as follows: Also, the following text also steers into the direction of using 8 instead of 7 to show all printk() messages:
To change the current console_loglevel simply write the desired level to ``/proc/sys/kernel/printk``. For example, to print all messages to the console:: # echo 8 > /proc/sys/kernel/printk (Taken from https://www.kernel.org/doc/Documentation/core-api/printk-basics.rst.)
Grt,

Hi @Vodalex,
Write down the MAC address of the interface you want to use to wake up the Helios4.
ip link show You would need to put the Helios4 in suspend, by either:
sudo pm-suspend or:
echo 'suspend' | sudo tee /sys/power/state  
To wake it up, from another system, make sure that wakeonlan is installed. Then:
wakeonlan ${HARDWARE_ADDRESS} That should be it.
Groetjes,

Hi,
wake-on-lan should be working now due to https://github.com/armbian/build/pull/8235.
Groetjes,

fixed

I made this simple dts file for my GPS NTP server running on Zero2/3 and Zero2w 
 
On Zero2, use PC9 as PPS in , and on Zero2W use PI5 .
 
It should be configured in /boot/armbianEnv.txt, but I unsuccess on zero2w, so you must comment out two lines and compile it by yourself.
 
Maybe help someone.
sun50i-h616-pps-gpio.dtso

Hi all, @Igor @0r31
I managed to come up with a more structural solution that should work for future increased sizes of the kernel/inital ramdisk as well.
 
Let me know if you are interested in testing this out before I attempt to make a pull request, as some instructions are required to test this out.
 
Changes are all in `boot.cmd` so no rebuilding or updating of U-Boot required.
Based on the load addresses in U-Boot, reshuffled the loading of DT, kernel and initial ramdisk last. After loading the DT it will calculate the kernel load address based on the DT `totalsize`. After loading the kernel it will calcuiate the initial ramdisk load address based on the kernel filesize. Some other minor changes are also incorporated; `fdt resize <extrasize>` adter re-loading original DT when applying the overlays has failed. Skip the `fdt apply` and `fdt resize` for the SPI-SATA workaround.  
Results on my Helios4 with an old U-Boot 2018.11 below:
 
Comments are welcome,
Groetjes,
boot-mvebu.cmd

@Igor
Fans working great with fancontrol. I have 92 MM Noctua Fan attached and it is working perfectly. I can adjust the configuration as described here https://wiki.kobol.io/helios4/pwm/
@all
I also edited the default 2.5 inch drives case provided from helios4  (replaced fan mounts from default 70 mm fan to 92 mm fan) and added holes to mount ssds horizontally as well using 3.5 to 2.5 metal adapter from aliexpress .. It looks like this.. Very quiet and the drives stay cool.

Hi there,
Now two pull requests are awaiting review:
- https://github.com/armbian/build/pull/8166#issuecomment-2867147049
   Update the boot.scr script to calculate load addresses in case `setexpr` is available on the U-Boot monitor.
- https://github.com/armbian/build/pull/8170#issuecomment-2867915659
   Enable the `setexpr` command on the U-Boot monitor, to unlock load address calculation in combination with the boot.scr update.
 
Both are now tested OK using a built armbian 'minimal' image based on Bookworm.
 
Groetjes,

Hi @Igor, all,
Made some updates, see here (including some minor corrections).
 
Tested it with a built image (bookworm-minimal) and it seems to work:
 
I will see how i can change U-Boot configuration to allow for `setexpr` to work, as using `setexpr` will make sure this does not need constant changing whenever kernel grows in size.
 
As this is  my first pull request, not sure what to do next?
 
Please have a look-see,
Groetjes,

Hi all, @Igor @0r31
I managed to come up with a more structural solution that should work for future increased sizes of the kernel/inital ramdisk as well.
 
Let me know if you are interested in testing this out before I attempt to make a pull request, as some instructions are required to test this out.
 
Changes are all in `boot.cmd` so no rebuilding or updating of U-Boot required.
Based on the load addresses in U-Boot, reshuffled the loading of DT, kernel and initial ramdisk last. After loading the DT it will calculate the kernel load address based on the DT `totalsize`. After loading the kernel it will calcuiate the initial ramdisk load address based on the kernel filesize. Some other minor changes are also incorporated; `fdt resize <extrasize>` adter re-loading original DT when applying the overlays has failed. Skip the `fdt apply` and `fdt resize` for the SPI-SATA workaround.  
Results on my Helios4 with an old U-Boot 2018.11 below:
 
Comments are welcome,
Groetjes,
boot-mvebu.cmd

So I decided to modify the armbianEnv.txt with the values you provided and it has moved to "Starting kernel..."
 
It is taking quite a while to boot. The older version seemed to take quite a while as well but this seems to be hanging possibly. I tried changing the armbianEnv.txt verbosity to 7 but it is still stuck on Starting kernel...
 
U-Boot 2024.01-armbian-2024.01-S866c-P7738-Ha5c2-V1f00-Bb703-R448a (Mar 16 2025 - 04:03:33 +0000) Allwinner Technology CPU: Allwinner V3s (SUN8I 1681) Model: PineCube IP Camera DRAM: 128 MiB Core: 47 devices, 20 uclasses, devicetree: separate WDT: Not starting watchdog@1c20ca0 MMC: mmc@1c0f000: 0, mmc@1c10000: 1 Loading Environment from FAT... Unable to use mmc 0:1... In: serial@1c28800 Out: serial@1c28800 Err: serial@1c28800 Autoboot in 1 seconds, press <Space> to stop switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 5475 bytes read in 2 ms (2.6 MiB/s) ## Executing script at 41900000 U-boot loaded from SD 227 bytes read in 1 ms (221.7 KiB/s) Load fdt: /boot/dtb/sun8i-s3-pinecube.dtb 12286995 bytes read in 509 ms (23 MiB/s) 11013984 bytes read in 456 ms (23 MiB/s) Found mainline kernel configuration 19691 bytes read in 4 ms (4.7 MiB/s) Working FDT set to 41000000 Kernel image @ 0x41080000 [ 0x000000 - 0xa80f60 ] ## Loading init Ramdisk from Legacy Image at 42080000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 12286931 Bytes = 11.7 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 41000000 Booting using the fdt blob at 0x41000000 Working FDT set to 41000000 Loading Ramdisk to 42248000, end 42dffbd3 ... OK Loading Device Tree to 421da000, end 42247fff ... OK Working FDT set to 421da000 Starting kernel ...  

Many thanks for fixing this!

I also tested on my side, works now. We can eventually put this board back to supported list. (board config .csc -> .conf)

There are few other things that would be nice to get working - I notice WOL service erroring out, fan support is unknown. I only have PCB without anything attached to it, for testing.
 
Merging both patches shortly.

Hi there,
Now two pull requests are awaiting review:
- https://github.com/armbian/build/pull/8166#issuecomment-2867147049
   Update the boot.scr script to calculate load addresses in case `setexpr` is available on the U-Boot monitor.
- https://github.com/armbian/build/pull/8170#issuecomment-2867915659
   Enable the `setexpr` command on the U-Boot monitor, to unlock load address calculation in combination with the boot.scr update.
 
Both are now tested OK using a built armbian 'minimal' image based on Bookworm.
 
Groetjes,

Slightly off topic, but a very similar problem (if not exactly this problem) is a current issue for clearfog base and pro as they're based on the same SoC and use the same kernels. I had been running on an older kernel with some packages (including the kernel) held by dpkg. I also had never installed u-boot to SPI before (running it off my boot media instead). This morning I installed a newer u-boot to SPI (maybe not necessary), included the same offsets to armbianEnv.txt, unheld all packages, upgraded everything and rebooted - and everything worked. Thanks to everyone that contributed information here. Hopefully we can keep these systems running for a bit more now!

Hi there,
Some other solution that I have not been able to make "permanent" yet.
 
Thanks @FredK@Josua-SR and @Igor for allowing me to have some fun building U-Boot once more (have not built a U-Boot since i think 2006!), it for sure did bring back some good memories 🙂
 
Unfortunately the built U-Boot (with SDHCI_SDMA disabled) did not solve my issue.
 
Then i decided to revert back to the previous release (*-6.6.87-current-mvebu => *-6.6.43-current-mvebu) by moving the symlinks in /boot around, which at least allowed the kernel and some userspace to boot. But due to lacking kernel modules (the 6.6.43 were removed during upgrade to 6.6.87) the box itself did not really work.
 
After some inspection, based on the remarks from @Josua-SR about memory corruption, i decided to check if this might not be just a simple overlapping issue with the images, e.g. kernel image partially occupying where the initrd is loaded.
 
Kernel image Size Size (hex) vmlinuz-6.6.43-current-mvebu 7170736 0x6d6ab0 vmlinuz-6.6.87-current-mvebu 8858728 0x872c68  
Loading of files is done as follows:
fdt (dtb) 0x2040000 (0x840000 max size) ramdisk (uInit) 0x2880000   kernel (vmlinuz) 0x2080000 (0x7fffff max size)  
You can already spot that the kernel image will not fit into the area that U-Boot has designated for it: 0x872c68 > 0x7fffff. whereas the 6.6.43 kernel should fit fine: 0x6d6ab0 < 0x7fffff.
 
Some testing showed that when setting ramdisk_addr_r to a higher value - which should fit the bigger kernel image - things started to boot again:
=> setenv ramdisk_addr_r 2980000 => boot switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 2996 bytes read in 210 ms (13.7 KiB/s) ## Executing script at 03000000 Boot script loaded from mmc 176 bytes read in 201 ms (0 Bytes/s) 28834 bytes read in 424 ms (66.4 KiB/s) 11504908 bytes read in 2562 ms (4.3 MiB/s) 8858728 bytes read in 2218 ms (3.8 MiB/s) ## Loading init Ramdisk from Legacy Image at 02980000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 11504844 Bytes = 11 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 02040000 Booting using the fdt blob at 0x2040000 Loading Ramdisk to 0f507000, end 0ffffccc ... OK reserving fdt memory region: addr=2040000 size=6d000 Loading Device Tree to 0f497000, end 0f506fff ... OK Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0  
Next is to try and figure out how I could change ramdisk_addr_r (the initial spot where U-Boot wants to load the ramdisk into), as I prefer not to have to type this at the U-Boot prompt every single time i reboot the box.
 
Hope this helps someone out there with similar issue.
 
Update: I built a U-Boot from the Kobol repo (https://wiki.kobol.io/helios4/uboot/#u-boot-2018) with the SDHCI_SDMA option disabled, and different memory load addresses for the ramdisk, script and efi stuff, see attached. Note i had some issues with the scripts/dtb, some yylloc variable had to be defined as external due to some linker error.
 
in "scripts/dtc/dtc-lexer.lex.c" i had to change line 618 to:
extern YYLTYPE yylloc;  
To update the memory load addresses, in "include/configs/helios4.h":
#define KERNEL_ADDR_R __stringify(0x2080000) #define FDT_ADDR_R __stringify(0x2040000) #define RAMDISK_ADDR_R __stringify(0x3000000) #define SCRIPT_ADDR_R __stringify(0x4000000) #define PXEFILE_ADDR_R __stringify(0x4100000)  
Essentially moved RAMDISK_ADDR_R from 0x0288'0000 to 0x0300'0000 to allow for larger kernel image and moved SCRIPT_ADDR_R (a.o.) to make room for the ramdisk image, from 0x0300'0000 to 0x0400'0000.
 
Then to write the U-Boot single page loader image out to the SDcard:
sudo dd if=u-boot-spl.kwb of=/dev/mmcblk0 seek=1 bs=512  
Groetjes,
 
PS Warranty until the door for the attached U-Boot....



 
 
 
u-boot-spl.kwb

I can confirm that Armbian_community_25.5.0-trunk.4_Helios4_noble_current_6.6.75.img.xz does not boot on Helios-4 with the same error described above:
 
Wrong Ramdisk Image Format Ramdisk image is corrupt or invalid SCRIPT FAILED: continuing...  
I spent the weekend investigating a similar issue with upstream Debian and upstream u-boot that turned out to be after a certain size of mmc access data would be corrupted. Disabling the SDHCI_SDMA function in u-boot helped:
https://lore.kernel.org/r/20250208-a388-kerneladdr-v2-1-17c01313eba2@solid-run.com
 
Finally I pushed this and other changes to the SolidRun vendor fork for the Armada 388 System on Module (as used on Helios-4), and attempted booting the same armbian image again. This time boot succeeded:
 
BootROM - 1.73 Booting from SPI flash U-Boot SPL 2024.04 (Feb 08 2025 - 13:12:00 +0000) High speed PHY - Version: 2.0 Detected Device ID 6828 board SerDes lanes topology details: | Lane # | Speed | Type | -------------------------------- | 0 | 6 | SATA0 | | 1 | 5 | USB3 HOST0 | | 2 | 6 | SATA1 | | 3 | 6 | SATA3 | | 4 | 6 | SATA2 | | 5 | 5 | USB3 HOST1 | -------------------------------- High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR3 Training Sequence - Switching XBAR Window to FastPath Window DDR Training Sequence - Start scrubbing DDR3 Training Sequence - End scrubbing mv_ddr: completed successfully Trying to boot from SPI U-Boot 2024.04 (Feb 08 2025 - 13:12:00 +0000) SoC: MV88F6828-A0 at 1600 MHz DRAM: 2 GiB (800 MHz, 32-bit, ECC enabled) Core: 30 devices, 20 uclasses, devicetree: separate MMC: mv_sdh: 0 Loading Environment from SPIFlash... SF: Detected w25q32 with page size 256 Bytes, erase size 4 KiB, total 4 MiB *** Warning - bad CRC, using default environment Model: Helios4 Board: Helios4 Net: Warning: ethernet@70000 (eth1) using random MAC address - 86:69:49:e4:c6:90 eth1: ethernet@70000 Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 2996 bytes read in 17 ms (171.9 KiB/s) ## Executing script at 00200000 Boot script loaded from mmc 158 bytes read in 13 ms (11.7 KiB/s) 28834 bytes read in 32 ms (879.9 KiB/s) 8146813 bytes read in 807 ms (9.6 MiB/s) 8550096 bytes read in 850 ms (9.6 MiB/s) Working FDT set to 100000 Kernel image @ 0x800000 [ 0x000000 - 0x8276d0 ] ## Loading init Ramdisk from Legacy Image at 01800000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 8146749 Bytes = 7.8 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 00100000 Booting using the fdt blob at 0x100000 Working FDT set to 100000 Loading Ramdisk to 0f83b000, end 0fffff3d ... OK Loading Device Tree to 0f7cb000, end 0f83afff ... OK Working FDT set to f7cb000 Starting kernel ... Loading, please wait... Starting systemd-udevd version 255.4-1ubuntu8.5
Binaries for reference:
https://images.solid-run.com/A38X/U-Boot/v2024.04/2025-02-08_695f767/u-boot-helios-4-sd.kwb
https://images.solid-run.com/A38X/U-Boot/v2024.04/2025-02-08_695f767/u-boot-helios-4-spi.kwb

Try with:
 
sudo touch /root/.not_logged_in_yet  
+ reboot.

Hi,
You can try the following to get an idea of which process is modifying the file:
 
sudo apt-get install auditd sudo auditctl -w /boot/armbianEnv.txt -p wa sudo tail -F /var/log/audit/audit.log  
The output should show actions performed on the file and (IIRC) the process ID performing those actions, perhaps that might help?
 
e.g.:
type=CWD msg=audit(1624526184.097:207): cwd="/home/djurny" type=PATH msg=audit(1624526184.097:207): item=0 name="/boot/" inode=7601 dev=b3:01 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=PATH msg=audit(1624526184.097:207): item=1 name="/boot/armbianEnv.txt" inode=43198 dev=b3:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=CREATE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=PROCTITLE msg=audit(1624526184.097:207): proctitle=xx type=SYSCALL msg=audit(1624526184.109:208): arch=40000028 syscall=94 per=800000 success=yes exit=0 a0=3 a1=81a4 a2=c80eeb00 a3=81a4 items=1 ppid=9641 pid=9642 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts5 ses=2 comm="vi" exe="/usr/bin/vim.basic" subj==unconfined key=(null) type=PATH msg=audit(1624526184.109:208): item=0 name=(null) inode=43198 dev=b3:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=PROCTITLE msg=audit(1624526184.109:208): proctitle=xx type=SYSCALL msg=audit(1624526184.109:209): arch=40000028 syscall=226 per=800000 success=yes exit=0 a0=1787820 a1=b6e3e1a0 a2=1907fc0 a3=1c items=1 ppid=9641 pid=9642 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts5 ses=2 comm="vi" exe="/usr/bin/vim.basic" subj==unconfined key=(null) type=CWD msg=audit(1624526184.109:209): cwd="/home/djurny" type=PATH msg=audit(1624526184.109:209): item=0 name="/boot/armbianEnv.txt" inode=43198 dev=b3:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=PROCTITLE msg=audit(1624526184.109:209): proctitle=xx  
Source: Find which process is modifying a file [duplicate]
 
It honestly sounds a bit more like a filesystem that has lost track or a inode mixup somewhere? As someone mentioned, perhaps something else is writing to this file, thinking it is something else? Perhaps try to locate a symbolic (or hard)link to armbanEnv.txt:
## find any symbolic links to armbianEnv.txt sudo find / -xdev -type l -ls | egrep -i -- armbianEnv.txt ## find hardlinks to armbianEnv.txt - need to be on the same filesystem! sudo find / -xdev -samefile /boot/armbianEnv.txt  
Groetjes,

Hi,
You can try the following to get an idea of which process is modifying the file:
 
sudo apt-get install auditd sudo auditctl -w /boot/armbianEnv.txt -p wa sudo tail -F /var/log/audit/audit.log  
The output should show actions performed on the file and (IIRC) the process ID performing those actions, perhaps that might help?
 
e.g.:
type=CWD msg=audit(1624526184.097:207): cwd="/home/djurny" type=PATH msg=audit(1624526184.097:207): item=0 name="/boot/" inode=7601 dev=b3:01 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=PATH msg=audit(1624526184.097:207): item=1 name="/boot/armbianEnv.txt" inode=43198 dev=b3:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=CREATE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=PROCTITLE msg=audit(1624526184.097:207): proctitle=xx type=SYSCALL msg=audit(1624526184.109:208): arch=40000028 syscall=94 per=800000 success=yes exit=0 a0=3 a1=81a4 a2=c80eeb00 a3=81a4 items=1 ppid=9641 pid=9642 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts5 ses=2 comm="vi" exe="/usr/bin/vim.basic" subj==unconfined key=(null) type=PATH msg=audit(1624526184.109:208): item=0 name=(null) inode=43198 dev=b3:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=PROCTITLE msg=audit(1624526184.109:208): proctitle=xx type=SYSCALL msg=audit(1624526184.109:209): arch=40000028 syscall=226 per=800000 success=yes exit=0 a0=1787820 a1=b6e3e1a0 a2=1907fc0 a3=1c items=1 ppid=9641 pid=9642 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts5 ses=2 comm="vi" exe="/usr/bin/vim.basic" subj==unconfined key=(null) type=CWD msg=audit(1624526184.109:209): cwd="/home/djurny" type=PATH msg=audit(1624526184.109:209): item=0 name="/boot/armbianEnv.txt" inode=43198 dev=b3:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=PROCTITLE msg=audit(1624526184.109:209): proctitle=xx  
Source: Find which process is modifying a file [duplicate]
 
It honestly sounds a bit more like a filesystem that has lost track or a inode mixup somewhere? As someone mentioned, perhaps something else is writing to this file, thinking it is something else? Perhaps try to locate a symbolic (or hard)link to armbanEnv.txt:
## find any symbolic links to armbianEnv.txt sudo find / -xdev -type l -ls | egrep -i -- armbianEnv.txt ## find hardlinks to armbianEnv.txt - need to be on the same filesystem! sudo find / -xdev -samefile /boot/armbianEnv.txt  
Groetjes,

A few months back I came across something interesting on David Taylor's web site.
A shell script to control the temperature of a SBC using the heat generated by the CPU.
Of course if your clock oscillator is integrated into the CPU then this is a way to control it's temperature and theoretically get more accurate time.
I tried this and it worked really well with a few tweaks.  I liked it so scripted it as a service.
I'm getting a maximum offset of less than +-20 micro seconds

http://www.satsignal.eu/ntp/Raspberry-Pi-ntpheat.html
 
#!/usr/bin/env python # # Requires python3 # generate some heat! # # Run ntpheat in the background. # It will try to stabilize the CPU temperature at 54C by default. # Sometimes one copy of ntpheat can use 100% of one CPU and #!/usr/bin/env python # # generate some heat! # # Run ntpheat in the background. # It will try to stabilize the CPU temperature at 54C by default. # Sometimes one copy of ntpheat can use 100% of one CPU and # still not heat up your Pi as much as you want. The temptation # is to add more insulation to your Pi, but then it will overshoot # your target temperature if your load factor goes high. # # The solution is to run more than one copy of ntpheat. This is # easy to do with the -c option. # # To run 3 copies of ntpheat: ntpheat -c 3 import argparse import hashlib import os import sys import time # Work with argvars parser = argparse.ArgumentParser(description="make heat") parser.add_argument('-c', '--copies', default=[1], dest='copies', help="Number of copies to run. Default is 1", nargs=1, type=int) parser.add_argument('-t', '--temp', default=[57.0], dest='target_temp', help="Temperature to hold. Default is 57.0", nargs=1, type=float) parser.add_argument('-w', '--wait', default=[0.001], dest='wait', help="Set delay time in seconds, default is 0.1", nargs=1, type=float) args = parser.parse_args() args.copies[0] -= 1 while args.copies[0]: args.copies[0] -= 1 pid = os.fork() if pid: # I am the fork break zone0 = '/sys/class/thermal/thermal_zone0/temp' cnt = 0 m = hashlib.md5() temp = 0 max_cnt = args.wait[0] * 100000 # on a RasPi 3 the temp steps seem to be about 0.537 to 0.539C temp_gate = args.target_temp[0] while True: # on a RasPi 3, 200,000 of the m.update() can be one second delta = temp_gate - temp if 0 < delta: # heat it up my_str = "Time is an illusion. Lunchtime doubly so." my_enc = my_str.encode('utf-8') m.update(my_enc) else: cnt = max_cnt # cools off slower than it heats up. # undocumented Python 'feature', no sleep less than 1 milli Sec sleep = args.wait[0] * 10.0 * -delta if 0.001 > sleep: sleep = 0.001 time.sleep(sleep) cnt += 1 # read the temperature every max_cnt if max_cnt < cnt: cnt = 0 zone_data = open(zone0, 'r') for line in zone_data: temp = float(line) / 1000 zone_data.close() The service file: ntpheat.service - if you don't know how to set up a systemd service then go here https://wiki.debian.org/systemd/Services
[Unit] Description=ntpheat [Service] ExecStart=/usr/bin/ntpheat.sh Restart=on-failure [Install] WantedBy=multi-user.target  

 
I should add:  To make the CPU based temperature control work, there must be no CPU intensive processes at all.  This means disabling any cron jobs that load the CPU or forcing them to use less CPU over a longer period.
To do this you need cgroup-tools
 
#spread out heating caused by scheduled maintenance on NTP server #get package sudo apt-get install -y cgroup-tools #create a cpu group called cpulimit sudo cgcreate -g cpu:/cpulimit #set cpulimit group limit to 100000uS out of 1000000uS (= 10% of CPU cycles) sudo cgset -r cpu.cfs_period_us=1000000 cpulimit sudo cgset -r cpu.cfs_quota_us=100000 cpulimit #check settings sudo cgget -g cpu:cpulimit #to limit your process start it as follows - sudo cgexec -g cpu:cpulimit YOUR_COMMAND
You can use this to run CPU intensive jobs at 10%
To reconfigure some cron jobs:
 
/etc/cron.d/armbian-updates @daily root cgexec -g cpu:cpulimit /usr/lib/armbian/armbian-apt-updates
Some cron jobs run scripts:
#for some cron scripts: /etc/cron.daily/apt-show-versions cgexec -g cpu:cpulimit apt-show-versions -i /etc/cron.daily/sysstat cgexec -g cpu:cpulimit exec /usr/lib/sysstat/sa2 -A Apt xapian index is a hog...  limit it to 5%
#create a cpu group called cpulimit5 (for 5% CPU) sudo cgcreate -g cpu:/cpulimit5 #set cpulimit group limit to 25000uS out of 500000uS (= 5% of CPU cycles) for bad process. sudo cgset -r cpu.cfs_period_us=500000 cpulimit5 sudo cgset -r cpu.cfs_quota_us=25000 cpulimit5 /etc/cron.weekly/apt-xapian-index - comment out all except top line and replace with cgexec -g cpu:cpulimit5 /usr/sbin/update-apt-xapian-index
 

Hi @IgorS,
After following the how to's on this forum and the internets, would like to share some other things I did to make it work even better on my OrangePi Zero.
 
Connect DS3231 to TWI0 (PA11+PA12 and +5V/GND of course).
  Add i2c0 overlay to /boot/armbianEnv.txt (or use armbian-config to enable the i2c0 overlay). [...] overlays=usbhost2 usbhost3 uart1 pps-gpio i2c0 [...]  
Add custom overlay to add DS3231 RTC (using DS3232 module instead of DS1307). Save as rtc0-i2c0-ds3231.dts.
 
Add the custom DT overlay: sudo armbian-add-overlay rtc0-i2c0-ds3231.dts  
Add custom overlay to rename H2+ SoC RTC to rtc1. Save as rtc1-soc.dts.
 
Add the custom DT overlay: sudo armbian-add-overlay rtc1-soc.dts  
Disable fake-hwclock service: sudo systemctl stop fake-hwclock.service # stop sudo systemctl disable fake-hwclock.service # disable sudo systemctl mask fake-hwclock.service # really disable Reboot and verify that you now have 2x RTC on your OrangePi Zero: root@sinaspi:~# ls -l /dev/rtc* lrwxrwxrwx 1 root root 4 Aug 5 22:57 /dev/rtc -> rtc0 crw------- 1 root root 253, 0 Aug 5 22:57 /dev/rtc0 crw------- 1 root root 253, 1 Aug 5 22:57 /dev/rtc1 As mentioned in another post, on the H2+ the SoC supplied RTC is indeed running fast, confirm this as follows: for RTC in /dev/rtc[0-9] do hwclock --rtc="${RTC:?}" --adjust hwclock --rtc="${RTC:?}" --systohc done sleep $(( 5 * 60 )) for RTC in /dev/rtc[0-9] do echo "${RTC:-N/A}:" hwclock --rtc="${RTC:?}" --get date --rfc-3339=ns done On my OrangePi Zero the SoC RTC is dashing ahead:
 
/dev/rtc0: 2021-08-08 09:17:52.760046+08:00 2021-08-08 09:17:52.526062078+08:00 /dev/rtc1: 2021-08-08 11:59:11.150733+08:00 2021-08-08 09:17:54.392611945+08:00 (rtc0 = DS3231 and rtc1 = SoC RTC.)
 
On the same OrangePi Zero, there is also a GPS receiver connected that has PPS output. Used @Elektrický's how to, to set up GPS and ntpsec. After successfully following the how to, ntp will synchronize and adjust system clock to high(er) accuracy. Once system clock is synchronized, the kernel will also update the RTC (/dev/rtc0) every 11 minutes, giving you a system as follows:
root@sinaspi:~# timedatectl Local time: Sun 2021-08-08 09:24:01 CST Universal time: Sun 2021-08-08 01:24:01 UTC RTC time: Sun 2021-08-08 01:24:02 Time zone: Asia/Taipei (CST, +0800) System clock synchronized: yes NTP service: inactive RTC in local TZ: no root@sinaspi:~# ntpq -p remote refid st t when poll reach delay offset jitter ======================================================================================================= 0.debian.pool.ntp.org .POOL. 16 p - 256 0 0.0000 0.0000 0.0019 1.debian.pool.ntp.org .POOL. 16 p - 256 0 0.0000 0.0000 0.0019 2.debian.pool.ntp.org .POOL. 16 p - 256 0 0.0000 0.0000 0.0019 3.debian.pool.ntp.org .POOL. 16 p - 64 0 0.0000 0.0000 0.0019 oPPS(0) .PPS. 0 l 56 64 377 0.0000 -0.0072 0.0035 xSHM(0) .GPS. 0 l 21 64 377 0.0000 -15.3659 1.7862 +SHM(2) .PPS. 0 l 18 64 377 0.0000 -0.0163 0.0094 +europa.ellipse.net 209.180.247.49 2 u 40 64 377 167.9069 -0.9358 0.1437 +ntp1.time.nl .MRS. 1 u 43 64 377 210.9643 1.7869 0.1945 +promethee.boudot.one 94.198.159.10 2 u 21 64 377 220.2528 2.3322 0.0931 root@sinaspi:~# As the DS3231 is now set as rtc0, the udev rules in /lib/udev/rules.d/85-hwclock.rules will make sure to read the DS3231 clock time after a reboot, making sure your system clock has a nice starting offset after being powered off for a while.
 
Hope this helps anyone out there,
Groetjes,

Hi @Elektrický,
Nice tutorial, worked great for me. Bought a cheap GPS module:

 
And a pinheader to solder onto the OrangePi Zero board itself.

 
The only thing I had to change was to swap the RX/TX wires, as a straight connection did not work for my GPS board.


 
I did not have any success getting PPS to work through the USB connection (works as ttyACM). I had to use the GPIO dtb overlay and electrical connection as per your tut.
gpsd in action:

 
ntp[sec] in action:

 
Thanks a lot!
Groetjes,
 
p.s. I still have to figure out why I needed this

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.

Manually or by driving our test rig?