ESPRESSObin Firmware/Bootloader

[bschnei]

Hi all, I came upon a few threads in this forum while working on the bootloader for my ESPRESSObin Ultra. I noticed all of the warnings here about CPU frequency (https://www.armbian.com/espressobin/#), and I think this community might be interested in the work I'm doing.

 

I've have an ESPRESSObin Ultra which ships from Globalscale with old, buggy, and unmaintained firmware. I think the old firmware could explain a lot of the issues users have reported here with the V7. I forked the old factory firmware build script from Globalscale and moved it all to up-to-date, upstream projects: https://github.com/bschnei/ebu-bootloader

I believe with some small modifications, it is possible to also build an up-to-date bootloader for other Globalscale devices that also use the Armada 37XX SoC, for example the ESPRESSObin V7.

 

I currently use Arch Linux ARM on my device and have notified their community as well: https://archlinuxarm.org/forum/viewtopic.php?f=67&t=16746

One of the issues I can confirm has been fixed is EFI booting from U-Boot. Fixing this means we can use U-Boot Standard Boot (bootflow scan) to load user-friendly EFI apps like systemd-boot, GRUB, etc. This significantly streamlines the boot process eliminating the need for u-boot to load separate kernel, initramfs, and device tree files. This also makes packaging it a lot easier too.

 

It also means your bootloader becomes configurable from the OS which is really nice because it means your distro of choice can configure the bootloader instead of requiring users to configure U-Boot manually. I'm not familiar with Armbian, but I think it ships with systemd-boot (?) which has an EFI application that gives you a user friendly way to control device booting. GRUB has a similar capability.

 

Please send me a note if you are interested in testing firmware for the ESPRESSObin V7 or Ultra.

[Pali]

cc: @ManoftheSea @y52 you can be interested in this.

[y52]

Hi! Thanks for mentioning me. I've just noticed your message accidentally.
It is indeed an interesting u-boot development. My both ESPRESSObin V5 and V7 are in production now. I can make some testing once I program their replacement. But no schedule has been fixed as yet pending acquiring a new board.

[bschnei]

Hi @y52, I've been using the bootloader builds from my repo above on my ESPRESSObin Ultra for quite some time now. Not only do they have up-to-date U-boot, but frequency scaling works perfectly. I'm not very familiar with the V5 and V7 variants, but I think the V7 has the same CPU (possibly different memory).

 

> hostnamectl
 Static hostname: espressobin-ultra
       Icon name: computer-embedded
         Chassis: embedded
      Machine ID: 2ba0ba22c6164c
         Boot ID: 514bc8387b7847
Operating System: Arch Linux
          Kernel: Linux 6.17.3-1-a3700
    Architecture: arm64
 Hardware Vendor: globalscale
  Hardware Model: Globalscale Marvell ESPRESSOBin Ultra Board
Firmware Version: 2025.10-ge50b1e871501
   Firmware Date: Wed 2025-10-01
    Firmware Age: 1month

 

Edited October 31, 2025 by bschnei

[y52]

I believe you have managed to overcome the majour Espressobin culprits, i.e. frequency scaling resulting in instability. It was a deadlock for me in the kernel choice and uboot frequency build version. At some moment I was compelled flashing uboot with frequency downgraded to 1GHz and 800 MHz in order to get stable setup for production. Good catch!
Your use of Arch Linux is also interesting. Which flavor have you installed ? Is it from 
https://archlinuxarm.org/platforms/armv8/marvell/espressobin ?
I routinely out of curiosity try alternative builds for testing and comparison when making new setups despite that Armbian remains a preferred one so far with general score of usability.

Edited November 1, 2025 by y52

[y52]

I've recently encountered when generating rsa keys low entropy available to OS on espressobin.
You mention that "The hardware random number generator contained in the Cortex-M3 coprocessor was not available to the OS."
It may explain the reason. Which entropy numbers do you reach now with the fixed u-boot ? 

[bschnei]

DVFS has been working well for me on two devices for over a year now. Linux accepted my patch to re-enable 1.2Ghz in 6.15.

 

I build my own Arch packages, but I started with ALARM. I didn't like the way they packaged the kernel and it wasn't being maintained. There are a few of us working on bringing Arch to aarch64. You'll find us on IRC. Libera.chat #archlinux-ports The ALARM project is a completely independent project of Arch Linux (despite the confusing name).

 

I have no issues with random number generation. It was actually fixed by this project: https://gitlab.nic.cz/turris/mox-boot-builder which builds one component of the bootloader. So I use that project (instead of Marvell) for that part of the bootloader.

Edited November 1, 2025 by bschnei

[y52]

It sounds very promising for Espressobin usage and further kernels upgrades.
It is yet to discover how could your u-boot port be built and which changes to code should be made for espressobin v5 and v7. I believe, they use the same chip. 
As you have a working build environment already, it would be worth sharing your pre-built binaries for testing in the 1st run. It could be a big step forward.
Probably Armbian could offer them for downloads as well as alternatives in parallel with their own builds. 

[bschnei]

To build for other devices, you need to figure out the correct configuration and adjust these values accordingly:

 

https://github.com/bschnei/ebu-bootloader/blob/main/Makefile#L15-L19

 

Reference for configuration options is here: https://trustedfirmware-a.readthedocs.io/en/latest/plat/marvell/armada/build.html

 

So for V7 you probably want DDR_TOPOLOGY of 5 or 6 depending on RAM size; for V5 a value of 2. You'll have to look up your defconfig in u-boot. It's probably this one: https://github.com/u-boot/u-boot/blob/master/configs/mvebu_espressobin-88f3720_defconfig but note that I have added an ultra variant here: https://github.com/u-boot/u-boot/blob/master/configs/mvebu_espressobin_ultra-88f3720_defconfig which has settings required to provide HWRNG to the kernel at boot. So you may way want to start with the default if it is known to work and experiment with your own configuration file.

 

You know how to test an image without flashing it to SPINOR, right? I have a guide at my repo above.

 

Regarding Armbian and device support in general, there is another thread here where I had some back and forth a while back:

 

 

Edited November 2, 2025 by bschnei

[KV1]

Hi @bschnei - i'm late to the party, tried using the standard instructions from GTI... Thanks for putting all this together!  I'm running into an issue building the A3700, with an error about relocation.  
   dangerous relocation: unsupported relocation
Could be related to having LSB set to 1 for safely identifying the relocation target?... based on searches  Any hints what I'm missing?

 

 

--

Built /srv/development/espressobin-ultra/2026-03-bschnei/ebu-bootloader/trusted-firmware-a/build/a3700/release/boot-image.bin successfully

make -C wtmi LOCAL_VERSION_STRING=-devel-18.12.1
cp -f ../../mox-boot-builder/wtmi_app.bin build/wtmi_app_pad.bin
truncate -s %16 build/wtmi_app_pad.bin
make -C sys_init LOAD_OFFSET=15360 COMMON_PATH=/srv/development/espressobin-ultra/2026-03-bschnei/ebu-bootloader/A3700-utils-marvell/wtmi/common CROSS_CM3=arm-linux-gnueabi-
  CHK     autoconf.h
  UPD     autoconf.h
  AS    start.S
  CC    apctl.c
  CC    avs.c
  CC    clock.c
  CC    main.c
  CC    printf.c
  CC    uart.c
  CC    ddr/ddr.c
  CC    ddr/ddrcore.c
  CC    ddr/ddr_support.c
  CC    ddr/dll_tuning.c
  CC    ddr/new_qs_gating.c
  CC    ddr/vref_training.c
  CC    /srv/development/espressobin-ultra/2026-03-bschnei/ebu-bootloader/A3700-utils-marvell/wtmi/common/delay.c
  CC    -nostdlib -T sys_init.ld -Xlinker --build-id=none  start.o  apctl.o avs.o clock.o main.o printf.o uart.o ddr/ddr.o ddr/ddrcore.o ddr/ddr_support.o ddr/dll_tuning.o ddr/new_qs_gating.o ddr/vref_training.o /srv/development/espressobin-ultra/2026-03-bschnei/ebu-bootloader/A3700-utils-marvell/wtmi/common/delay.o -o build/sys_init.elf
/usr/lib/gcc-cross/arm-linux-gnueabi/14/../../../../arm-linux-gnueabi/bin/ld: warning: build/sys_init.elf has a LOAD segment with RWX permissions
/usr/lib/gcc-cross/arm-linux-gnueabi/14/../../../../arm-linux-gnueabi/bin/ld: (*ABS*0x1fff0000): Unknown destination type (ARM/Thumb) in main.o
main.o: in function `main':
/srv/development/espressobin-ultra/2026-03-bschnei/ebu-bootloader/A3700-utils-marvell/wtmi/sys_init/main.c:349:(.text.startup+0x38): dangerous relocation: unsupported relocation
collect2: error: ld returned 1 exit status
make[4]: *** [Makefile:149: build/sys_init.elf] Error 1
make[3]: *** [Makefile:42: sys_init/build/sys_init.bin] Error 2
make[2]: *** [Makefile:36: WTMI] Error 2
make[1]: *** [plat/marvell/armada/a3k/common/a3700_common.mk:158: /srv/development/espressobin-ultra/2026-03-bschnei/ebu-bootloader/./A3700-utils-marvell/wtmi/build/wtmi.bin] Error 2
make[1]: Leaving directory '/srv/development/espressobin-ultra/2026-03-bschnei/ebu-bootloader/trusted-firmware-a'
make: *** [Makefile:28: /srv/development/espressobin-ultra/2026-03-bschnei/ebu-bootloader/./trusted-firmware-a/build/a3700/release/flash-image.bin] Error 2
 

[bschnei]

Hi @KV1 looks like you are hitting this issue: https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell/issues/35

 

As you can see, Marvell is not very active in these repos. So you have two choices: 1) use older binutils/gcc (probably the easiest option), or 2) fix the issue with the source code. The fixes I'm seeing look simple enough to implement, and I will likely need to include them in the future when/if I update the github runners used to build releases.

 

See also: 

https://community.arm.com/support-forums/f/compilers-and-libraries-forum/57077/binutils-2-44-and-gcc-15-1-0---dangerous-relocation-unsupported-relocation-error-when-trying-to-build-u-boot

https://lists.denx.de/pipermail/u-boot/2025-May/589102.html

[KV1]

Thanks @bschnei.  I tried for a while to  figure out what to do, but couldn't really understand.. not sure if i should be trying to set it to thumb or arm mode at that point, even.  I did fallback to earlier binutils, and the build went fine. 

 

However, trying to boot from the flash-image.bin with mox-imager results in incomplete load and reset back to mmc/spinor ... any ideas?

 

--

 

/mox-imager/mox-imager -D /dev/ttyUSB0  -t -E  /srv/development/espressobin-ultra/2026-03-bschnei/built-on-old-bb/flash-image-20260401-bb.bin
TIM version 3.6.00, issue date 2026-04-01, non-trusted, 3 images, 0 keys, boot flash sign SPI NOR
Reserved area packages:
  CRV2 (size 20)
  CIDP (size 32)
    Consumer TBRI, packages: GPP1 GPP2 DDR3
  GPP1 (size 852)
    Ignore timeouts in instructions: 0
  GPP2 (size 456)
    Ignore timeouts in instructions: 0
  DDR3 (size 2024)
    Initialize DDR memory: 1
  Term (size 8)
Found TIMH, hash sha-256, encryption none, size 3780, load 0x20006000, flash 0x00000000
Found WTMI, hash sha-256, encryption none, size 24336, load 0x1fff0000, flash 0x00004000
Found OBMI, hash sha-256, encryption none, size 1140712, load 0x64100000, flash 0x00015000

Going to send images to the device
Sending escape sequence, please power up the device
Received sync reply
Sending escape sequence with delay
Detected BootROM command prompt
Sending wtp sequence
Received ack reply
Sending clearbuf sequence
Initialized UART download mode

GetVersion response: version 3.4.01, date 2016-05-15, CPU ARMA
Sending image type TIMH
100% sent in 00:00  

TIM-1.0

mv_ddr-devel-g7bcb9dc DDR4 16b 1GB 1CS

Sending image type WTMI
100% sent in 00:02  
Sending image type OBMI
100% sent in 01:40  

[Type Ctrl-\ + c to quit]

WTMI-devel-18.12.1-a3e1c67
WTMI: system early-init
SVC REV: 5, CPU VDD voltage: 1.213V
Setting clocks: CPU 1200 MHz, DDR 750 MHz
CZ.NIC's Armada 3720 Secure Firmware v2024.04.15-6-gd6d9646 (Apr  1 2026 16:32:36)
Running on ESPRESSObin Ultra
NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v2.14.0(release):sandbox/v2.14-774-g8dae0862c
NOTICE:  BL1: Built : 16:32:41, Apr  1 2026
NOTICE:  BL1: Booting BL2
NOTICE:  BL2: v2.14.0(release):sandbox/v2.14-774-g8dae0862c
NOTICE:  BL2: Built : 16:32:51, Apr  1 2026
NOTICE:  BL1: Booting BL31
NOTICE:  BL31: v2.14.0(release):sandbox/v2.14-774-g8dae0862c
NOTICE:  BL31: Built : 16:32:56, Apr  1 2026

U-Boot 2026.04-rc5-00019-gc704af3c8b0f (Apr 01 2026 - 17:08:14 -0400)

DRAM:  1 GiB
"Synchronous Abort" handler, esr 0x96000044, far 0xd5380000aa1e03fd
elr: 0000000000036a08 lr : 0000000000036a64 (reloc)
elr: 000000003ff4aa08 lr : 000000003ff4aa64
x0 : 0000000000000098 x1 : d5380000aa1e03fd
x2 : 0000000000000000 x3 : 000000003fb07b00
x4 : 0000000000000000 x5 : 0000000000000000
x6 : 0000000000000000 x7 : 000000003fb07b20
x8 : 000000003faff64c x9 : 000000003fb00034
x10: 0000000000000000 x11: 0000000000000600
x12: 000000003faff70c x13: 000000003faff9b0
x14: 000000003faff9b0 x15: 0000000000000000
x16: 0000000000000000 x17: 0000000000000000
x18: 000000003fb03e10 x19: 0000000000000000
x20: 000000003fb07780 x21: 000000003fb077a0
x22: 0000000000000000 x23: 0000000000000000
x24: 0000000000000000 x25: 0000000000000000
x26: 0000000000000000 x27: 0000000000000000
x28: 0000000000000000 x29: 000000003faff7a0

Code: f9405261 f9005274 f81e02a0 f9000681 (f9000034) 
Resetting CPU ...

resetting ...
TIM-1.0
WTMI-devel-18.12.1-1a13f2f
WTMI: system early-init
SVC REV: 5, CPU VDD voltage: 1.213V
NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v1.5(release):e65dc63 (Marvell-devel-18.12.2)
NOTICE:  BL1: Built : 22:43:22, Mar  4 2026
NOTICE:  BL1: Booting BL2
NOTICE:  BL2: v1.5(release):e65dc63 (Marvell-devel-18.12.2)
NOTICE:  BL2: Built : 22:43:25, Mar  4 2026
NOTICE:  BL1: Booting BL31
NOTICE:  BL31: v1.5(release):e65dc63 (Marvell-devel-18.12.2)
NOTICE:  BL31: Built : 22

U-Boot 2020.10-6.0.0-g29a6ea5c-dirty (Mar 28 2026 - 21:49:54 -0400)

Model: gti cellular cpe board
DRAM:  1 GiB
Comphy chip #0:
Comphy-0: USB3_HOST0   
Comphy-1: PEX0          2.5 Gbps  
Comphy-2: SATA0         6 Gbps    
Target spinup took 0 ms.
AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode
flags: ncq led only pmp fbss pio slum part sxs 
PCIE-0: Link up
MMC:   sdhci@d8000: 0
Loading Environment from SPIFlash... unrecognized JEDEC id bytes: 61, 12, 9b
*** Warning - spi_flash_probe_bus_cs() failed, using default environment

Net:   
Error: neta@30000 address not set.
mdio_register: non unique device name 'neta@30000'
No ethernet found.

starting USB...
Bus usb@58000: Register 2000104 NbrPorts 2
Starting the controller
USB XHCI 1.00
Bus usb@5e000: USB EHCI 1.00
scanning bus usb@58000 for devices... 1 USB Device(s) found
scanning bus usb@5e000 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0 
Marvell>> 
 

[bschnei]

@KV1 nice work! Looks like it made it to U-Boot before it died. Instead of building your own, have you tried to see if it boots using a release image built with a github runner here: https://github.com/bschnei/ebu-bootloader/releases/tag/2026.02.24. Even if you want to eventually build it yourself, you could just test to see if the image built at github works. If it does, and you know the source code is the same (it looks like you are building an -rc of U-Boot) then you can narrow it down to the compiler tools you are using. Just to confirm: this is for an EspressoBIN Ultra right? Not the V7/V5 or some other variant?