Helios4 can boot directly from the sata disk nr 1, without the need to switch from the SD or the eMMC.
I personally tried setting SW1 to 11100 and using u-boot-sata for Clearfog, which shares the same uSOM and the system booted regularly, obviously the system didn't recognize many devices being u-boot for another board.

 

I tried to compile a version of u-boot for sata trying to integrate the changes present in https://solidrun.atlassian.net/wiki/spaces/developer/pages/287212134/A38X+U-Boot in the U-boot build instruction and sources for Helios4 present in the Kobol Wiki but my skills are not sufficient for such a job.

 

In the binaries available for Helios4 at  https://imola.armbian.com/beta/pool/main/l/linux-u-boot-helios4-current/ there are only u-boots for uart, flash and mmc. 

Would it be possible to have the sata version in future releases?

Thanks in advance and for all the work done.

Yeah that should be no problem. Just compare these two files:

 

(Clearfog configuration)
https://github.com/armbian/build/blob/master/config/sources/families/include/mvebu-clearfog.inc 

 

(Helios4 configuration)

https://github.com/armbian/build/blob/master/config/sources/families/include/mvebu-helios4.inc

 

Just provide a PR with added targets here https://github.com/armbian/build/blob/master/config/sources/families/include/mvebu-helios4.inc#L11
Test it by building locally and we'll have sata uboot on the next release.

Thanks, I'll give it a try as soon as possible.
I will let you know.

I tried to modify configuration but unlucky it's not sufficient and I got error that I'm unable to fix.

 

  LD      spl/u-boot-spl
  OBJCOPY spl/u-boot-spl-nodtb.bin
  CAT     spl/u-boot-spl-dtb.bin
  COPY    spl/u-boot-spl.bin
  MKIMAGE u-boot-spl.kwb
  CFGCHK  u-boot.cfg
[ error ] ERROR in function compile_uboot [ functions/cli/cli-entrypoint.sh:108 -> functions/main/default-build.sh:55 -> functions/compilation/uboot.sh:145 -> functions/logging/traps.sh:0 ]
[ error ] U-boot file not found [ u-boot-sata.kwb ]
[ o.k. ] Process terminated

 

Ok I'll look into it this afternoon. 

Ok I checked this and there is no uboot config for 2019 uboot helios4 which has SATA support enabled. Not sure how to best go forth here.

I am curious why upstream UBoot is not used. It has support or the Helios 4. Plus a bugfix for that RAM timing issue that shows up on boot.

4 hours ago, Mangix said:

I am curious why

 

Because nobody volunteered to try, check for possible regressions and submit changes? From project perspective, if @Heisathdon't have much time and interest, there is nothing we can do as project is way way too small to follow endless users & HW needs. We don't have a backup. 

 

@Mangix because u-boot was maintained by the kobol team, which have given up supporting both their boards. I do not currently have the time to switch to another u-boot and test / fix upgrade and new image scenarios. But there are only a few patches https://github.com/armbian/build/tree/master/patch/u-boot/legacy/u-boot-helios4 and so it might be possible to go upstream. You are welcome to try and send a patch. 

 

I might also try, once I find time + motivation for it.

Upstream u-boot (in its next branch) has now lot of 32-bit armada / mvebu patches related to SD/eMMC, SATA and UART booting. Also on mailing list are waiting some Clearfog eMMC patches.

Likely you should take Helios patches and put then on top of the u-boot next.

As I mentioned, OpenWrt maintains upstream u-boot with a build for the helios4. Necessary patches can be taken from there.

On 6/6/2023 at 4:10 PM, Mangix said:

As I mentioned, OpenWrt maintains upstream u-boot with a build for the helios4. Necessary patches can be taken from there.

 

Mangix, are you still around?  Where is the code you are referring to in openwrt?  I see exactly one commit in 2020 about the Helios4 and then nothing after that.  I also don't see any specific patches applied.

@laibsch

 

https://u-boot.org/

 

edit: as I said earlier, it would be better to switch to upstream to get rid of patches and get some nice bugfixes in the process, but I assume this thing is mostly abandoned. A bunch of my containers no longer offer ARM32 support. Home Assistant too at the end of this year.

Edited November 16, 2025Nov 16 by Mangix

should be fixed with https://github.com/armbian/build/pull/8980

Wonderful.

@laibschcoud you take a look at

https://github.com/u-boot/u-boot/commit/cae6e8993c8eaed7c520b1046766b658e0f97b90
https://github.com/u-boot/u-boot/commit/aec83261b98eec3a2ca2e9a5a2debea31fcd9d65

https://github.com/u-boot/u-boot/commit/529d24002b6cefb88cd00cef307b8752dbeebfc4

 

Maybe relevant for the first patch.

Thank you, @Mangix.  We bumped u-boot to v2025.10 for Helios, so I would assume those commits are already incorporated, aren't they?  I have only looked at commit dates, not actual code.

Correct. But the old Marvell code needs different KConfig symbols.

Hi there,

I also tried to see what happens when I set the DIP to SATA0, but to my surprise, the serial console does not give any indication of a boot attempt from SATA:

BootROM - 1.73
Booting from SPI flash
BootROM: Bad header at offset D4000000
BootROM: Bad header at offset D4200000
BootROM: Bad header at offset D4400000
BootROM: Bad header at offset D4600000
BootROM: Bad header at offset D4800000
BootROM: Bad header at offset D4A00000
BootROM: Bad header at offset D4C00000
BootROM: Bad header at offset D4E00000

Trying Uart 

And yes, DIP was set to SATA0.

 

To note: there was a blinking red LED prior to the output on the serial console.

 

When I re-set the DIP to SPI, it boots up without issue:

Booting from SPI flash

U-Boot SPL 2025.10_armbian-2025.10-Se50b-Pee16-H9530-V9a59-Bbf55-R448a (Nov 23 2025 - 08:27:54 +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 2025.10_armbian-2025.10-Se50b-Pee16-H9530-V9a59-Bbf55-R448a (Nov 23 2025 - 08:27:54 +0000)

SoC:   MV88F6828-A0 at 1600 MHz
DRAM:  2 GiB (800 MHz, 32-bit, ECC enabled)
Core:  32 devices, 21 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
OK
Model: Helios4
Board: Helios4
...

 

It almost appears that the DIP is not read out properly?

 

What does your console say when you set the DIP to SATA0?

Groetjes,

 

2 hours ago, djurny said:

I also tried to see what happens when I set the DIP to SATA0

 

Thank you for testing!