Vodalex

@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.

@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.

@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

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!

As seen in some other threads for mvebu-based boards (helios4, etc), the current images for clearfog base (and I assume) pro are broken in that it appears the initrd can't be loaded. I also haven't been able to use the u-boot for SATA booting in a while. I have been hitting both of these issues for a while and as I showed above in the past you can still flash old images, use an even older u-boot binary for SATA and get up and running - but now (and I'm not sure when it started) any upgrade to current packages renders the system unbootable. It's unfortunate, but it seems these boards are old enough that their support is rotting (and to be clear, I'm not blaming Armbian for this). While this hardware is old it's plenty performant as my home firewall to the Internet and so I don't want to replace it - but it's maybe time to start looking for a replacement anyways.
 
Just a few nights ago, I installed updates for the first time in a few months and when I rebooted it, it failed to come back up. Considering this is my router, that really cramped my style! But I got another box in place in this role and since then I've poked at this a bit. It's easy to reproduce:
Flash a copy of Armbian_23.11.1_Clearfogbase_bookworm_current_6.1.63.img to an m.2 SATA drive (if this isn't available any more, ping me and I can post it somewhere). Write a copy of the old u-boot for SATA support to the beginning of the drive (dd if=u-boot.sata of=/dev/foobarbaz bs=512 seek=1) Put the m.2 SATA drive into your clearfog and configure the jumpers to boot off SATA - see here. Plug in ethernet and micro USB to another system and attach to it for console (picocom -b 115200 /dev/ttyUSBFOOBARBAZ) Power it on and hopefully observe it boot - then go through the initial setup Update and upgrade packages (apt update && apt upgrade) Reboot - and watch it stall before it gets anywhere The trick then is to put a "hold" on the kernel and firmware packages before doing #6. The latest kernel I've been able to get running stable is 6.6.63-current-mvebu (installed via armbian-config).
for pkg in armbian-bsp-cli-clearfogbase-current armbian-firmware linux-dtb-current-mvebu linux-image-current-mvebu linux-u-boot-clearfogbase-current; do   echo "$pkg hold" | dpkg --set-selections done  
Then you should be able to upgrade everything else and reboot and have it not break. That list of packages is likely larger than it really needs to be, but after rebuilding my drive a couple of times I decided to not take any chances. The rest is either pure Debian or at least things that shouldn't break due to bit rot.
 
If I have more time I'll try to actually dig in and figure out what's wrong with the ramdisk (or whatever it is that causes this) and submit a fix, but this is better than nothing for 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

@FredK thank you so much for the instructions. They allowed me to boot up my helios4 again.
 
If I may, don't buy anything ARM-based if you don't want e-waste in 5 years because there's no software support. When my helios4 finally gives up I'll get an odroid-h4+ (https://www.hardkernel.com/shop/odroid-h4-plus/) or whatever equivalent they have at that time.

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

Nothing strange. All software has bugs  and I don't fully exclude there is a problem with Armbian, just for this, I would say its probably on their side ... things are complex and is difficult to be sure without a research.

This means that OMV, which anyway completely changes OS, somehow breaks networking.
 
OMV was working well for many years, Armbian was even official partner ... As we didn't change anything in this regard, I would assume they changed something so try also to find this answer on their forums.