djurny

Hi @ff255,
There is an effort to add this calculation in the U-Boot bootscript. I'll have a look at doing this during updates to initramfs or kernel, good suggestion!
Groetjes,

Hi @ff255,
Next time, you can indeed try to calculate the load addresses using the following method:
kernel_load_addr_r = (trunc( (fdt_load_addr_r + fdt_size + 1 + 64KiB) / align_to) + 1) * align_to ramdisk_load_addr_r = (trunc( (kernel_load_addr_r + kernel_size + 1) / align_to) + 1) * align_to With align_to being the alignment boundary - 2MiB for ARM64 and for other platforms it depends on their architecture, 4KiB is a safe and sane boundary to align to.
 
edit (again):
The +1 is to prevent an OBOE in U-Boot; if the next load_addr starts immediately after with no padding, the logic in U-Boot wrongly accuses the images to overlap
The +64KiB is the "fdt_extrasize" which should allow for any possible addition to the DT by any of the (DT fixup) scripts.
 
Groetjes,

Hi @ff255,
Can you try with the following changes/additions to armbianEnv.txt:
# previous load addresses # fdt_addr_r=0x01f00000 # kernel_addr_r=0x02000000 # ramdisk_addr_r=0x04000000 # new load addresses fdt_addr_r=0x01f00000 kernel_addr_r=0x02000000 ramdisk_addr_r=0x04400000 # new kernel_addr_r is aligned to 2MiB boundary # new ramdisk_addr_r is aligned to 2MiB boundary - not really neccessary afaik but "why not both?"  
Quick calculation below:
 
 
edit: updated the sheet and put the correct numbers here
 
Groetjes,

Testing on Nanopi R2S revealed that U-Boot there does not have setexpr built-in. I expect it will be the same on the 'Rock64' board you have?
To make sure - as I do not have your hardware here - can you check if the following commands work on your U-Boot monitor commandline:
setenv b setenv c setenv a "a/b" setexpr b sub "a/" "" a echo ${b} setexpr c 1 + 1 echo ${c} fdt  
Also, to give a workaround (hopefully), the output of the following on the U-Boot monitor commandline:
echo ${fdtfile} echo ${fdt_addr_r} echo ${kernel_addr_r} echo ${ramdisk_addr_r} ver  
Thx,
Groetjes,

Hi @wolf7250,
The $PWD is an environment variable that represents the current working directory. The lone period "." also represents the current working directory. $PWD has nothing to do with your password - unless your folder names are the same as your password and/or vice versa.
 
As to your question, yes, I would think a fresh reinstall from scratch is going to be the best way forward. But I have no idea how easy that will be with transferring OMV settings from old to new etc. OMV is unbeknownst to me.
 
On the other hand, if the workaround with the new load addresses in `armbianEnv.txt` work (and they seem to work just fine) it's more of a matter of how "correct" you want your situation to be. Things seems to be working.
 
Groetjes,

Hi @wolf7250,
You can download the package without installing as follows:
cd /tmp/ mkdir fliepeltje cd /tmp/fliepeltje/ apt-get download armbian-bsp-cli-helios4-current dpkg -x armbian-bsp-cli-helios4_*.deb ${PWD:?}  
Then backup the current bootscript as follows:
cd /boot/ sudo cp boot.cmd boot.cmd~org sudo cp boot.scr boot.scr~org  
Then copy the new bootscript and convert it to U-Boot script format as follows:
cd /boot/ sudo cp /tmp/fliepeltje/usr/share/armbian/boot.cmd ${PWD:?} sudo mkimage -C none -A arm -T script -d boot.cmd boot.scr  
Then reboot to check if all went well.
Gr,
 
PS syntax is on purpose, of course you can replace ${PWD:?} with . but that might be easy to miss when reading the instruction.

Hi there,
U-Boot was updated. Can you share the contents of `/boot/boot.cmd`? Just to be sure 🙂
Groetjes,

Hi @wolf7250,
I'm not familiar with OMV, so not sure what that update/upgrade process looks like. If it will update/upgrade the armbian packages to the latest release 25.11, then the correct version of armbian-bsp-cli will be installed. The installation of that package should update /boot/boot.scr and make a new U-Boot image available that you would have to install with nand-sata-install.
Gr,

Hi @wolf7250,
That does not look like the new bootscript. Did you update already? 
 
To get it working again, you can try the quick workaround as you pointed to earlier, which should allow more room for U-Boot loading kernel, initrd and the rest.
Gr,

Hi @wolf7250,
The correct U-Boot and bootscript is for sure in the newest release. I built recently and all is there and working without issue on my helios4.
Let's unravel what is happening for you and get that sorted out.
Gr,

Hi @wolf7250,
When you upgrade, one of the packages will update the bootscript (/boot/boot.scr), that will prevent a load address conflict - this should be armbian-bsp-cli iirc. The new bootscript will either calculate the load addresses or use new defaults to avoid the image overlap/"corruption" issue.
The U-Boot for the helios4 has been updated as well to enable load address calculation, instead of using hardcoded values. To update U-Boot, run nand-sata-install and select to "install/update the bootloader on SD/MMC" (see here).
Groetjes,

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,

I also have some oom issues when doing an aptitude upgrade in my opizero w/256 MiB ram. Guess even more on a 128MiB board like yours.
Best to add a swap file to make sure upgrades go without issue.
Grt,

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

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.