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

[wite_k]

Hello,

 

After upgrading helios4 I encountered this problem after rebooting:

 

U-Boot SPL 2019.04-armbian (Jul 03 2024 - 12:20:37 +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 (Jul 03 2024 - 12:20:37 +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.
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 - e2:6d:a3:83:7f:e1
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 381 ms (6.8 KiB/s)
## Executing script at 03000000
Boot script loaded from mmc
158 bytes read in 369 ms (0 Bytes/s)
28834 bytes read in 691 ms (40 KiB/s)
11165487 bytes read in 2303 ms (4.6 MiB/s)
8551104 bytes read in 1847 ms (4.4 MiB/s)
Wrong Ramdisk Image Format
Ramdisk image is corrupt or invalid
SCRIPT FAILED: continuing...
starting USB...
USB0:   MVEBU XHCI INIT controller @ 0xf10f4000
Register 2000120 NbrPorts 2
Starting the controller
USB XHCI 1.00
USB1:   MVEBU XHCI INIT controller @ 0xf10fc000
Register 2000120 NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 1 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found

Device 0: device type unknown
... is now current device

 

I guess the most important part is this:

 

Wrong Ramdisk Image Format
Ramdisk image is corrupt or invalid
SCRIPT FAILED: continuing...

 

This happened when linux-image was upgraded from 24.11.0-trunk.403 to 25.2.0-trunk.316 (25.2.0-trunk.343 doesn't work either). To get it working again I unpacked previous kernel and I'm back to 24.11.0-trunk.403. I noticed that this topic

has similar problem. I still got some ideas about how to debug this but I before that I wanted to ask if anyone has encountered this on this board? Did the initrd changed format during upgrade and I have to upgrade uboot (I noticed that FORCE_UBOOT_UPDATE is set to null so I guess installing linux-u-boot-helios4-current_25.2.0-trunk.316_armhf.deb doesn't dd bootloader onto sdcard.

 

Thanks in advance!

[Josua-SR]

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

Edited February 8 by Josua-SR

[wite_k]

Great news, thanks!

I wasn't able to download u-boot from the links that you provided so I build it myself and "dd" it to sdcard.

For some reason that particular kernel that caused this problem isn't available in apt repository, but that doesn't matter for now. At least I know that during next upgrade it'll work.

[Igor]

Thanks @Josua-SR!

 

I tried with self made and this binary - we have some troubles with kernel I guess.
 

=> 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 15 ms (194.3 KiB/s)
## Executing script at 03000000
Boot script loaded from mmc
158 bytes read in 12 ms (12.7 KiB/s)
28834 bytes read in 27 ms (1 MiB/s)
11476654 bytes read in 1086 ms (10.1 MiB/s)
8546328 bytes read in 843 ms (9.7 MiB/s)
Working FDT set to 2040000
Kernel image @ 0x2080000 [ 0x000000 - 0x826818 ]
Wrong Ramdisk Image Format
Ramdisk image is corrupt or invalid
SCRIPT FAILED: continuing...
Loading Boot0000 'mmc 0' failed
EFI boot manager: Cannot load any image

 

[Igor]

Quote

Wrong Ramdisk Image Format Ramdisk image is corrupt or invalid

What is the right Ramdisk format?

[iav]

I build fresh Armbian-unofficial_25.02.0-trunk_Helios4_plucky_edge_6.10.14 from armbian trunk (1f697206562).

Image boots successfuly.

 

Why?

[Dee2022]

Hi all,

 

Today I upgraded armbian on my Helios 4. I wish I hadn't. The system won't boot anymore. Received the "Wrong Ramdisk Image Format Ramdisk image is corrupt or invalid" message.

 

Any hints on trying to recover from this? To be honest, I'm stuck at the moment.

 

I recovered from this through the following steps:

 

• Get the 'original' image (although dated) from the Helios site (https://wiki.kobol.io/helios4/)
• Created another sd card
• Booted
• And had access again.
• The hardest part was recoving the old lukskey for opening the encrypted partitions from the raid array.

Edited February 25 by Dee2022

[FredK]

Same here: "No boot after upgrade to Armbian 25.2.2".

Same message:

Wrong Ramdisk Image Format
Ramdisk image is corrupt or invalid

 

The very "unfriendly" behaviour was the unattended-upgrade. Therefore I had no chance first to make an update of my 24.11 system with Linux 6.6.63-current-mvebu (see signature). I had to use for recovery  the backup from 24.8 immediately before 24.11 in the pipeline. The recovered system is now Armbian 24.8 with Linux 6.6.47-current-mvebu.

 

Any chance to get 24.11 again?

[FredK]

@Igor 

Is a new update to 25.2 for Helios4 planned of the kernel binaries ? If so, when can this be expected? If not, what can I do?

The post of @Josua-SR is marked as solution. But I have no idea what to do with the *.kwb files from SolidRun. In particular I never made a custom build.

[Dee2022]

@FredK Same here. I didn't know what to do with the .kwb images. 

Edited Wednesday at 04:02 PM by Dee2022

[Mangix]

This is the command to flash the bootloader onto the SD card: https://wiki.kobol.io/helios4/uboot/#on-development-pc

 

As you can tell, it's basically offset by 1 on the SD card.

 

kernel 6.6.79 boots now.

[FredK]

@Mangix 

Thank you, that was simple.

 

@Dee2022

What I did:

1. Download of the 1st SolidRun image (... sd.kwb)
2. Copy the image to SDcard containing unbootable Armbian 25.2 (on my Linux desktop using dd, SDcard available here at /dev/sdf)

   sudo dd if=u-boot-helios-4-sd.kwb of=/dev/sdf bs=512 seek=1 status=noxfer
   sudo sync

3. Boot Helios4. Voilà.

Edited Thursday at 10:41 AM by FredK

[Igor]

On 2/26/2025 at 10:29 AM, FredK said:

Is a new update to 25.2 for Helios4 planned of the kernel binaries ?

 

Nothing is planned unfortunately. It was a try if I can bring this from the dead in a couple of hours. I spent all the time I could afford to. In order to not go into the self-destruction path, we set a rules to ourselves: https://docs.armbian.com/User-Guide_Board-Support-Rules/ 

I can't maintain this board. It is one out of (perhaps 500 that are on the market, and one out of 100 that has some user base behind). If someone will help, and step up, to match the board support rules, this board can be lifted to standard support. It was dropped to community support about a year ago https://github.com/armbian/build/pull/6654 as we haven't heard it from its maintainer for a long time. We don't have any other alternative.

I hope someone will take a look and integrate those changes into the build framework. Then we will at least a device into automated testing for early problem detections. They will certainly pop up in the future as they always does  

[FredK]

@Igor

After @Mangix's post I was able to fix my installation patching the bootloader.

 

I'm aware that Helios4 is a dead-end and I plan to switch to a 64bit-SBC providing 4 or 5 SATA-ports (but I don't find a suitable board up to now).

Edited Thursday at 05:12 PM by FredK

[Igor]

1 hour ago, FredK said:

I'm aware that Helios4 is a dead-end

We have many of such boards in the system  Armbian mission is trying to keep them alive as long as possible. We invest a lot of efforts to keep them build-able, but there is just too many things that can go wrong in the u-boot / kernel area. Boards are constantly collapsing - if we want to keep them aligned with a modern kernel. The task is simply too big for our small team. We encourage people, owners of those (old) boards to step up and integrate those findings to the builds system, so this solution is available for everyone. 
 

1 hour ago, FredK said:

providing 4 or 5 SATA-ports

 

We are running one mirror on Radxa ITX with success:
https://www.armbian.com/newsflash/armbian-v24-11/
Software wise we are covering it well.

[dacmot]

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

Edited Friday at 03:32 AM by dacmot

[SymbiosisSystems]

I got bitten by this and in the end rolled back to Armbian 24.2.1 with kernel 6.6.16 which seems to work fine (with zfs and omv 7). Can anyone comment as to how much work would be required to fix this issue in the 25.x development and how much time would be required to bring this board up to be supported again ?