Request for testers: EspressoBin mainline u-boot/atf

New patches for mainline u-boot have been posted, so that espressobin should finally work now.
That gives us a recent version of u-boot, compared to that old and unmaintained marvell fork.

I opened a PR for OpenWRT to ship mainline u-boot/atf builds. Those include distro boot:

And now we need testers :slight_smile:
openwrt/openwrt#3360 (comment)


  • All builds are currently CPU_800_DDR_800 only for stability reasons
  • There is no build for v5 with 2GiB RAM, does anyone have such a board?
  • The v5 1GiB build is 2CS, does anyone have 1GiB 1CS?

And feedback is appreciated!

Yes I have a v5 with 2 GiB RAM and 8 MB of Flash (from the original KickStarter campaign). It would likely take me a day or two to locate it as it is still in packing boxes in my garage from my move a year ago! I also have a v7 with 1 GiB RAM.

I added a PR to officially support that board here.
Once merged I can add it to the OpenWRT builds.

And do you mean 8MB NOR flash or does that come with 8MB eMMC?

PR was merged and the v2 binaries now includes builds for that board :wink:
If you get a chance, test results are very much welcome!

Sorry, I meant 4MB NOR flash. I created the wikidevi entry from my device shortly after it arrived from the original KickStarter campaign. I later acquired a V7 unit and created the corresponding wikidevi page.

Yeah, thought so (but you never know what funky hw designs ppl come up with)

@dhewg : I just made a refresh of the patch for uboot 2021.07 for EspressoBin-Ultra...

Do I understand correctly that we should better update/flash uboot before booting 21.02? and this uboot may boot openwrt as well as other distros (eg armbian)?

Also, could you please clarify about the uart image residing here? Is this the uart rescue option?
Thank you

It was cancelled and postponed... the original maintainer still works on his patchset to propose to uboot mainline... :+1:
Still waiting for beta tests ! :slight_smile:

Not a requirement, but still preferable !
It's my own and personal opinion...
Do it (the upgrade) at your own risks !

uart images are rescue by uart image.
flash-image is the standard default uboot.

A topic which can help : Is it possible to flash u-boot from OpenWrt? - #5 by erdoukki

1 Like

This seems perfect. If I understand well, I could flash the new uboot remotely and if successful, I could install remotely openwrt 21.2 on an already installed hard drive and set the boot priority to the hard drive first from the environment. This way I could dual boot remotely if needed. What I am missing is the jumpers and the environment.
Do I need to touch the jumpers?
Regarding the environment, I paste below the current env of my v5 espressobin.
I see here your environment which is really different and also what armbian is proposing.
As I have very little experience on this, which one should I follow as default environment?
Thank you


`# fw_printenv

bootargs=console=ttyMV0,115200 root=/dev/mmcblk0p2 rw rootwait
bootcmd=ext4load mmc 0:1 0x4f00000 armada-3720-espressobin.dtb; ext4load mmc 0:1 0x5000000 Image; booti 0x5000000 - 0x4f00000
console=console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000
get_images=tftpboot $kernel_addr $image_name; tftpboot $fdt_addr $fdt_name; run get_ramfs
get_ramfs=if test "${ramfs_name}" != "-"; then setenv ramfs_addr 0x8000000; tftpboot $ramfs_addr $ramfs_name; else setenv ramfs_addr -;fi
root=root=/dev/nfs rw
set_bootargs=setenv bootargs $console $root ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:none nfsroot=$serverip:$rootpath $extra_params

Dangerous !

Dangerous (also) !

No need to change... Only needed in case of "recovery mode" !

Prefer the default OpenWrt script...

Mainly, after an uboot upgrade, you only need to change/write back the ethaddr value which is your Network Ethernet Mac Address.

The GOOD procedure for UBoot upgrade will be something like ;
0. have a good bootcmd and env settings, with a backup of fw_env. and healthy OpenWrt.

  1. upgrade uboot (from OpenWrt or directly from UBoot)
  2. here normally you need to reboot to UBoot and set the default env value ! (depends of the from/to UBoot versions)
  3. restore the needed env, like ethaddr (must be sufficient, you may tweak the boot order if needed with the boot_targets env value)
  4. boot to your system (again)
  5. backup, tweaks, play...

The same procedure for OpenWrt upgrade will be explained here :

Mainly like :
0. had a backup of configs

  1. had a backup of installed packages (I recommend Opkgs extras and hotplug extras bit take care that depending of the extroot or overlay, you can "auto" broke your system !)
  2. sysupgrade with keeping, when possible, the configs
  3. if needed, reset you extroot/overlay (manually, I have some script still in development for this...)
  4. reinstall package (or let hotplug & opkg extras do it for you automatically)
  5. backup, tweaks, play...

Refs :

It is a lot of "I cross my finger" in near each steps !
In a remote way it more than this, but it can be a game to play...
Always think about needing to get a trip to the device.
Always think about needing to do a recovery of the device.

Some steps could be automated/scripted, it is done on commercials products based on OpenWrt, but I never seen any share of their methods.
I am studying some based of my own experiences, from years now, but they are still not perfect enough, and you can see topics on the forum about discussion on this particular subject !

MAY BE DANGEROUS but DO IT AT YOUR OWN RISKS ! :skull_and_crossbones:

1 Like

Thank you.
I know it is dangerous. If uboot needs the ethernet MAC (in a sense that it does not apply a random one) then remote uboot upgrade is a no-go. But I will probably test that when I will be onsite by the device.
About OpenWrt, I had in mind a clean installation of 21.02 on the hard disk (19.07 is working on the sd card now). I have access to espressobin from other local devices in case of failure and I have already done this with turris omnia and turris os and all went fine. I was even able to set the lan ip before booting into it!!

1 Like

The main problem is with an upgrade of a different version of uboot, where the env address may move...
You can do a pseudo reset of the env with the backup of another device...
We may also tweak the ethaddr reset with a uboot env which set it ?!

All is possible but mainly untested.
The difficult points are to script some steps...

If you give a try, I will be interested by your feedback !

Thanks, I did not know this feature.

Then you may only need to change the boot_targets order.

That is exactly what I was willing to do, but I am not sure how to implement this with the current uboot and my current environment.

These env have been tested with IPFire, OPNSense, Debian, ARMBian, OpenWrt...
Some works also fine in UEFI mode !
They are from the mainline DENX u-Boot...

May be they were a little modified with some personal tweak (like FDT name and ETHADDR).
OpenWrt boot.scr from the Firmware itself, will also tweak some parts.

Here boot.scr content from my 21.02.0 EBIN-Ultra

root@OpenWrt:/# mount /dev/mmcblk0p1 /boot/                                                                                                                      
[  450.444499] EXT4-fs (mmcblk0p1): mounted filesystem without journal. Opts: (null)                                                                             
root@OpenWrt:/# strings /boot/boot.scr                                                                                                                           
# Bootscript for Globalscale ESPRESSOBin Board                                                                                                                   
# Set distro variables if necessary for compability with downstream firmware                                                                                     
if test -z "${kernel_addr_r}"; then                                                                                                                              
        setenv kernel_addr_r 0x7000000                                                                                                                           
if test -z "${fdt_add_r}"; then                                                                                                                                  
        setenv fdt_addr_r 0x6f00000                                                                                                                              
if test -z "${devtype}"; then                                                                                                                                    
        setenv devtype mmc                                                                                                                                       
if test -z "${devnum}"; then                                                                                                                                     
        if mmc dev 0; then                                                                                                                                       
                setenv devnum 0                                                                                                                                  
        elif mmc dev 1; then                                                                                                                                     
                setenv devnum 1                                                                                                                                  
# figure out partition uuid to pass to the kernel as root=                                                                                                       
part uuid ${devtype} ${devnum}:2 uuid                                                                                                                            
setenv console "console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000"                                                                                           
setenv bootargs "root=PARTUUID=${uuid} rw rootwait ${console}"                                                                                                   
echo "Booting Linux from ${devtype} ${devnum} with args: ${bootargs}"                                                                                            
load ${devtype} ${devnum}:1 ${fdt_addr_r} armada-3720-espressobin-ultra.dtb                                                                                      
load ${devtype} ${devnum}:1 ${kernel_addr_r} Image                                                                                                               
booti ${kernel_addr_r} - ${fdt_addr_r}

as you can see the mmc boot is "hardcoded" in the boot.scr !
So you also need to tweak it for hard drive boot (IDE, USB, ...)

Sorry, I misread this...
If there is now ethaddr env sets in uboot, the recent u-boot now get a random one.

This can also be done from boot.scr ! :wink: