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 Saturday at 11:48 AM 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...