Helios4 doesn't boot after upgrading to linux-6.6.71 (linux-image-current-mvebu_25.2.0-trunk.343)

[Nova]

I'll never be able to say it, but this community is the best I've ever seen.
I want to thank you because once again, I couldn't have solved the problem without it.

Thanks @djurny, all the people of this post.

[Vodalex]

After edititing the nano /boot/armbianEnv.txt via SSH with the values as suggested I could update my Helios 4 and it is running now with armbian 25.2.3 and kernel 6.6.86 Thanks for the help!

Thank you so much @djurny and all the others!

Edited May 3 by Vodalex

[helios4noob]

glad i stumbled on this  - had the same problem and i spent the weekend reconfiguring my nas and turning off all updates for now. Igor you have done great work over the years and absolutely understand the difficulty. I wish I knew programming and could assist. However the helios4 has had a great run, its def time for an upgrade. 

[Nova]

I can't understand why no one in the world has thought of releasing another 64-bit ARM motherboard with 4 SATA ports or 6 SATA ports.

And that way, we don't have to end up buying a Synology or something worse... I guess we're heading for extinction like dinosaurs.

[kratz00]

Hi @djurny

 

Great find, are you planing on upstreaming your changes?

Not sure, but I guess all it would need is to update arm-mvebu-helios4-Update-Load-address.patch which can be found here: https://github.com/armbian/build/tree/main/patch/u-boot/legacy/u-boot-helios4/board_helios4

[blood]

1 hour ago, Nova said:

I can't understand why no one in the world has thought of releasing another 64-bit ARM motherboard with 4 SATA ports or 6 SATA ports.

Take a look at Radxa Rock 5 ITX. You can definitely make a NAS out of one of them.

[djurny]

HI @kratz00.

I'm indeed trying to get myself familiiarized with the build system and making pull requests for this and some other little nitpicky things that I think might help others.

 

Hi @Nova,

There is also the Helios64, also from Kobol:

https://kobol.io/

 

There have been some issues with it though, related to the DFS function and the 2.5Gbe NIC hardware. I'm running mine for some years already, albeit still on Buster (from 2020 with kernel 5.9.13). Also I am not using the DFS function and set the CPU frequency (fixed governor either powersave or performance) explicitly before it starts backing up (it's my long term backup server). Most probably the newest armbian will run without major issues - except the 2.5Gbe NIC functionality as that was hardware related.

 

Groetjes,

 

PS I'm not affiliated with Kobol in any way whatsoever.

[djurny]

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:

Spoiler

U-Boot SPL 2018.11-00009-g9236e7e3a3-dirty (Apr 22 2025 - 17:06:02 -0700)
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: mv_ddr-armada-17.10.4 
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 MMC1


U-Boot 2018.11-00009-g9236e7e3a3-dirty (Apr 22 2025 - 17:06:02 -0700)

SoC:   MV88F6828-A0 at 1600 MHz
DRAM:  2 GiB (800 MHz, 32-bit, ECC enabled)
MMC:   mv_sdh: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment

Model: Helios4
Board: Helios4
SCSI:  MVEBU SATA INIT
Target spinup took 0 ms.
Target spinup took 0 ms.
AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
flags: 64bit ncq led only pmp fbss pio slum part sxs 

Net:   
Warning: ethernet@70000 (eth1) using random MAC address - 46:96:1f:e2:6e:e9
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
4343 bytes read in 212 ms (19.5 KiB/s)
## Executing script at 04000000
Boot script loaded from mmc
Loading environment from mmc to 0x300000 ...
176 bytes read in 203 ms (0 Bytes/s)
Loading DT from mmc to 0x2040000 ...
28834 bytes read in 427 ms (65.4 KiB/s)
magic:                  0xd00dfeed
totalsize:              0x18000 (98304)
off_dt_struct:          0x48
off_dt_strings:         0x6758
off_mem_rsvmap:         0x28
version:                17
last_comp_version:      16
boot_cpuid_phys:        0x0
size_dt_strings:        0x95a
size_dt_struct:         0x6710
number mem_rsv:         0x1

Loading kernel from mmc to 2058000 ...
8858728 bytes read in 2057 ms (4.1 MiB/s)
Loading ramdisk from mmc to 28cb000 ...
11504566 bytes read in 2567 ms (4.3 MiB/s)
Booting kernel ...
## Loading init Ramdisk from Legacy Image at 028cb000 ...
   Image Name:   uInitrd
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    11504502 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 0ffffb76 ... OK
   reserving fdt memory region: addr=2040000 size=18000
   Loading Device Tree to 0f4ec000, end 0f506fff ... OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 6.6.87-current-mvebu (build@armbian) (arm-linux-gnueabihf-gcc (Ubuntu 13.2.0-23ubuntu4) 13.2.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #1 SMP Thu Apr 10 12:37:44 UTC 2025
[    0.000000] CPU: ARMv7 Processor [414fc091] revision 1 (ARMv7), cr=50c5387d
[

 

 

Comments are welcome,

Groetjes,

boot-mvebu.cmd

[Heisath]

On 2/27/2025 at 6:03 PM, Igor said:

we haven't heard it from its maintainer for a long time

I am still here  but as we all know our time is precious and I am currently using all my time for other projects. So I am not currently maintaining this board.

On the whole I think armbian is moving too fast, for me, with new features in the build system and kernel which has somewhat discouraged me from further investing my time. ARM is IMHO not a stable platform, unfortunately.

 

@djurny solution looks good - I might test this later and try to integrate it. But everyone else, if you can, please make it a PR on github

 

It should only be necessary to adjust this file https://github.com/armbian/build/blob/main/config/bootscripts/boot-mvebu.cmd

[djurny]

Hi @Heisath,

I think i can make a pull request from here: https://github.com/armbian/build/compare/main...djurny:build:patch-1, but would like to see someone else besides me test and scrutinize change.

 

If positive results are in, I would very happy to finally contribute something!

Groetjes,

[Igor]

@Heisath Nice to have you back. I know everyone is busy ...
 

10 hours ago, Heisath said:

On the whole I think armbian is moving too fast, for me, with new features in the build system

 

I think speed of this has been brought down in past year and most of changes were on the "must be done" list. Changes generate stress, regardless of their intention.

 

10 hours ago, Heisath said:

ARM is IMHO not a stable platform, unfortunately.

 

It is getting more and more troublesome - big complexity vs. new devices keep coming out light-speed vs. limited resources for maintaining. We have little to fight this

 

10 hours ago, djurny said:

but would like to see someone else besides me test and scrutinize change.

 

Freshly build image from your patch - doesn't work for me - what I am missing here?

 

Spoiler

U-Boot 2019.04-armbian-2019.04-S3c99-P6351-H9530-V0854-Bb703-R448a (Mar 16 2025 - 04:06:02 +0000)

SoC:   MV88F6828-A0 at 1600 MHz
DRAM:  2 GiB (800 MHz, 32-bit, ECC enabled)
MMC:   mv_sdh: 0
Loading Environment from EXT4... ** File not found /boot/boot.env **

** Unable to read "/boot/boot.env" from mmc0:1 **
Model: Helios4
Board: Helios4
SCSI:  MVEBU SATA INIT
SATA link 0 timeout.
SATA link 1 timeout.
AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
flags: 64bit ncq led only pmp fbss pio slum part sxs 

Net:   
Warning: ethernet@70000 (eth1) using random MAC address - 62:8c:c7:28:59:25
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
4342 bytes read in 362 ms (10.7 KiB/s)
## Executing script at 03000000
Boot script loaded from mmc
Loading environment from mmc to 0x300000 ...
158 bytes read in 349 ms (0 Bytes/s)
Loading DT from mmc to 0x2040000 ...
28834 bytes read in 678 ms (41 KiB/s)
Unknown command 'setexpr' - try 'help'
Unknown command 'setexpr' - try 'help'
itest - return true/false on integer compare

Usage:
itest [.b, .w, .l, .s] [*]value1 <op> [*]value2
Loading kernel from mmc to  ...
load - load binary file from a filesystem

Usage:
load <interface> [<dev[:part]> [<addr> [<filename> [bytes [pos]]]]]
    - Load binary file 'filename' from partition 'part' on device
       type 'interface' instance 'dev' to address 'addr' in memory.
      'bytes' gives the size to load in bytes.
      If 'bytes' is 0 or omitted, the file is read until the end.
      'pos' gives the file byte position to start reading from.
      If 'pos' is 0 or omitted, the file is read from the start.
Unknown command 'setexpr' - try 'help'
Unknown command 'setexpr' - try 'help'
itest - return true/false on integer compare

Usage:
itest [.b, .w, .l, .s] [*]value1 <op> [*]value2
Loading ramdisk from mmc to  ...
load - load binary file from a filesystem

Usage:
load <interface> [<dev[:part]> [<addr> [<filename> [bytes [pos]]]]]
    - Load binary file 'filename' from partition 'part' on device
       type 'interface' instance 'dev' to address 'addr' in memory.
      'bytes' gives the size to load in bytes.
      If 'bytes' is 0 or omitted, the file is read until the end.
      'pos' gives the file byte position to start reading from.
      If 'pos' is 0 or omitted, the file is read from the start.
Booting kernel ...
SCRIPT FAILED: continuing...

 

 

[eselarm]

On 5/6/2025 at 4:31 PM, Nova said:

I can't understand why no one in the world has thought of releasing another 64-bit ARM motherboard with 4 SATA ports or 6 SATA ports.

And that way, we don't have to end up buying a Synology or something worse... I guess we're heading for extinction like dinosaurs.

I always liked the Marvell ARM SoCs because of their many high-speed I/O, but never bought one as the main CPU(s) were always behind w.r.t. raw computing performance, compared to RPi4 BCM2711 or Intel J1900. Ebon Upton of RPL once stated they won't do SATA. Instead they made an own I/O chip and some own ISP silicon design for the RPi5. It is because the focus on digital signage, so computing devices with screens and cameras.

For many home-users it means the struggle goes on. I only use my RPi4 with Samsung SSD for fast local I/O (VMs etc), but what a trouble with that whole VIA PCIe-USB3 chip design (you extra need external power in the end). And look at how many people still want to build a NAS with a Pi; So BCM271x-PCIe<=>PCIe_USB3chip<=cable=>USB3_SATAchip<=cable=>HDD(s)/SSD. Or some 'HAT' via yet another proprietary extra flatcable. And then not to forget the powering of such a setup, need 12V, RPi can only accept 5V.

 

I think worlds big IT companies aim for cloud, central storage, your data, your privacy, so principles and methods to store your own data locally at home seem like a relative niche. Not that non-tech people don't know what NAS and backup etc is, but automatic cloud for laptops and smartphone is so easy.

 

Then the other issue is that 4 or 6 or even 10 or 12 SATA ports mostly imply many 3.5inch HDD which need then 100W or so, so the 'low-power ARM' is irrelevant. And people seem to want RAID, many still think that is also good backup. 

 

What I also noticed as problem with older ARM SoCs it that for example the Marvell 88F6828 in Helios4 is 32-bit (dual Cortex-A9). Modern filesystems are more tailored for 64-bit native. For example, Btrfs does not support >8TiB in 32-bit, and because of its CoW fundamentals, it can also hit that limit with <8TiB after many years of usage (or lots of 'balancing'). So you want a 64-bit CPU/OS. I have a BananaPi M1 still, also same as Helios4 2x Cortex-A9, but only 1 SATA2 connector. I still like that board, it runs Armbian 6.12.x now and I use it to export raw /dev/sda (8TB Seagate SMR) via nbd-server as Linux block device. That works fine with 32-bit, the limit is mostly random I/O speed due to SMR and being a HDD. If I do LVM, LUKS, Btrfs (Zstd compression) remote on top of nbd-client on a NanoPi R6C RK3588s, it works without noticing the Gbit ethernet in between.

If I replace the BananaPi M1 with a Radxa ROCK 3A (on-chip SATA), same behavior more or less, although It can also run the whole 'NAS' stack on its own RK3568. Only disadvantage is then that on-the-fly Zstd compression is a bottleneck. So that made me order a ROCK 5B (RK3588), that has comparable I/O connectors (M.2 M-key for NVMe, M.2 E-key for a SATA passthough connector). I also ordered a ASM1166 M.2 M-key, so I can have the same functionality as old power hungry Intel PC with 6-SATA for tests/fallback. Note that for my main 24/7 NAS (the ROCK 3A system now) I keep a limit of 8TB, that means I don't buy new bigger HDD and only 1 is enough. Caching is done with LVMcache on the NVMe. If HDD is not spinning, it is about 4.5 Watt.

 

Edited Thursday at 09:26 AM by eselarm

[djurny]

Hi @Igor,

Seems that U-Boot 2019.04-armbian-2019.04-S3c99-P6351-H9530-V0854-Bb703-R448a does not have the `setexpr` command configured. I will do more testing and figure out how the change can handle `setexpr` missing and configuring U-Boot to have `setexpr` available.

Thanks!

Groetjes,

[djurny]

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:

Spoiler

U-Boot SPL 2019.04-armbian-2019.04-S3c99-P6351-H9530-V0854-Bb703-R448a (Mar 16 2025 - 04:06:02 +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: mv_ddr-armada-18.09.2 
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 MMC1


U-Boot 2019.04-armbian-2019.04-S3c99-P6351-H9530-V0854-Bb703-R448a (Mar 16 2025 - 04:06:02 +0000)

SoC:   MV88F6828-A0 at 1600 MHz
DRAM:  2 GiB (800 MHz, 32-bit, ECC enabled)
MMC:   mv_sdh: 0
Loading Environment from EXT4... ** File not found /boot/boot.env **

** Unable to read "/boot/boot.env" from mmc0:1 **
Model: Helios4
Board: Helios4
SCSI:  MVEBU SATA INIT
Target spinup took 0 ms.
Target spinup took 0 ms.
AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
flags: 64bit ncq led only pmp fbss pio slum part sxs 

Net:   
Warning: ethernet@70000 (eth1) using random MAC address - 56:24:30:73:7b:ad
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
4800 bytes read in 378 ms (11.7 KiB/s)
## Executing script at 03000000
Boot script loaded from mmc
Loading environment from mmc to 0x00300000 ...
158 bytes read in 365 ms (0 Bytes/s)
Loading DT from mmc to 0x02040000 ...
28834 bytes read in 708 ms (39.1 KiB/s)
Unknown command 'setexpr' - try 'help'
** Command `setexpr` not available - using configured load addresses
Loading kernel from mmc to 0x02060000 ...
8809072 bytes read in 1899 ms (4.4 MiB/s)
Loading ramdisk from mmc to 0x03060000 ...
10519797 bytes read in 2192 ms (4.6 MiB/s)
Booting kernel ...
## Loading init Ramdisk from Legacy Image at 03060000 ...
   Image Name:   uInitrd
   Created:      2025-05-09  16:01:07 UTC
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    10519733 Bytes = 10 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 0f5f7000, end 0ffff4b5 ... OK
   Loading Device Tree to 0f5dc000, end 0f5f6fff ... OK

Starting kernel ...

Loading, please wait...
Starting systemd-udevd version 252.36-1~deb12u1
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... done.
Begin: Will now check root file system ... fsck from util-linux 2.38.1
[/sbin/fsck.ext4 (1) -- /dev/mmcblk0p1] fsck.ext4 -a -C0 /dev/mmcblk0p1 
armbi_root: clean, 27997/65808 files, 236515/263168 blocks
done.
done.
Begin: Running /scripts/local-bottom ... done.
Begin: Running /scripts/init-bottom ... done.

 

 

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,

[djurny]

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,

[Igor]

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.

[FredK]

@Igor

 

> There are few other things that would be nice to get working - I notice WOL service erroring out, fan support is unknown.

 

Regarding "fan support":

Fan was working correctly after installing fancontrol, see
https://forum.armbian.com/topic/44379-fancontrol-bookworm-solved/#findComment-209055

 

(Thread is in Standard support->Other families->Helios 4)