SBBR or GTFO
Me.
Yeah, right. But world is not so nice and there are many cheap SBC on market which are not SBBR compliant and probably never will. And with small amount of work they can do EBBR (Embedded Base Boot Requirements).
NOTE: I have similar post about EBBR on RockPro64 board.
WTH is EBBR?
It is specification for devices which are not servers and do not pretend to be such. U-Boot is all they have and with properly configured one they have some subset of EFI Boot/Runtime Services to load distribution bootloader (grub-efi usually) like it is done on servers.
ACPI is not required but may be present. DeviceTree is perfectly fine. You may provide both or one of them.
Firmware can be stored wherever you wish. Even MBR partitioning is available if really needed.
Few words about board itself
EspressoBin has 4MB of SPI flash on board. Less than on RockPro64 but still enough for storing firmware (U-Boot takes less than 1MB).
This SBC is nothing new — first version was released in 2016. There were several revisions with different memory type, amount of ram chips, type of them (ddr3 or ddr4), CPU speed and some more changes.
I got EspressoBin revision 5 with 1GB ram of ddr3 in 2 chips. And 1GHz processor.
It may sound silly that I repeat that information but it matters when you start building firmware for that board.
So let us build fresh firmware
This is Marvell so abandon all hope for sanity.
Thanks to Arm Trusted Firmware authors there is good documentation on how to
build firmware for EspressoBin
which guides step by step and explains all arguments you need. For me it was
several git clone calls and then two make calls:
make -C u-boot CROSS_COMPILE=aarch64-linux-gnu- \
mvebu_espressobin-88f3720_defconfig u-boot.bin -j12
make -C trusted-firmware-a CROSS_COMPILE=aarch64-linux-gnu- \
CROSS_CM3=arm-none-linux-gnueabihf- PLAT=a3700 \
CLOCKSPRESET=CPU_1000_DDR_800 DDR_TOPOLOGY=2 \
MV_DDR_PATH=$PWD/marvell/mv-ddr-marvell/ \
WTP=$PWD/marvell/A3700-utils-marvell/ \
CRYPTOPP_PATH=$PWD/marvell/cryptopp/ \
BL33=$PWD/u-boot/u-boot.bin \
mrvl_flash -j12
And I had to install cross toolchain for 32-bit arm because the one I had was for building kernels/bootloaders only.
Is your U-Boot friendly or not?
First you need to check which version of U-Boot and hardware you have. Then check does it recognize SPI flash or not:
Marvell>> sf probe
SF: unrecognized JEDEC id bytes: 9d, 70, 16
Failed to initialize SPI flash at 0:0 (error -2)
I had bad luck as my board used SPI chip not recognized by any official U-Boot build…
Armbian to the rescue
I asked in few places did anyone had some experiences with this board. One of them was #debian-arm IRC channel where I got hint from Xogium that Armbian may have U-Boot builds.
And they have whole page about EspressoBin. With information how to choose firmware files etc.
So I downloaded archive with proper files for UART recovery. The important thing to remember is that once you move jumpers and load all firmware files over serial they are not written in SPI flash so reset of board means you start over.
Quick check is SPI flash detected:
Marvell>> sf probe
SF: Detected is25wp032 with page size 256 Bytes, erase size 4 KiB, total 4 MiB
Yeah! Now can start USB and flash own firmware build:
Marvell>> bubt flash-image.bin spi usb
Burning U-Boot image "flash-image.bin" from "usb" to "spi"
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
Image checksum...OK!
SF: Detected is25wp032 with page size 256 Bytes, erase size 4 KiB, total 4 MiB
Erasing 991232 bytes (242 blocks) at offset 0 ...Done!
Writing 990944 bytes from 0x6000000 to offset 0 ...Done!
Quick reset and board boots to fresh, mainline U-Boot:
TIM-1.0
WTMI-devel-18.12.1-1a13f2f
WTMI: system early-init
SVC REV: 5, CPU VDD voltage: 1.108V
NOTICE: Booting Trusted Firmware
NOTICE: BL1: v2.4(release):v2.4-345-g04c122310 (Marvell-devel-18.12.2)
NOTICE: BL1: Built : 17:11:19, Feb 15 2021
NOTICE: BL1: Booting BL2
NOTICE: BL2: v2.4(release):v2.4-345-g04c122310 (Marvell-devel-18.12.2)
NOTICE: BL2: Built : 17:11:20, Feb 15 2021
NOTICE: BL1: Booting BL31
NOTICE: BL31: v2.4(release):v2.4-345-g04c122310 (Marvell-devel-18.12.2)
NOTICE: BL31: Built : 18:07:02, Feb 15 2021
U-Boot 2021.01 (Feb 15 2021 - 19:25:41 +0100)
DRAM: 1 GiB
Comphy-0: USB3_HOST0 5 Gbps
Comphy-1: PEX0 2.5 Gbps
Comphy-2: SATA0 5 Gbps
SATA link 0 timeout.
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 down
MMC: sdhci@d0000: 0, sdhci@d8000: 1
Loading Environment from SPIFlash... SF: Detected is25wp032 with page size 256 Bytes, erase size 4 KiB, total 4 MiB
OK
Model: Globalscale Marvell ESPRESSOBin Board
Card did not respond to voltage select! : -110
Net: eth0: neta@30000
Hit any key to stop autoboot: 0
Final steps
OK, so SBC has fresh, mainline firmware. Nice. But still some stuff needs to be done.
First note MAC addresses of Ethernet ports. Use printenv command to check
stored environment and note few variables:
eth1addr=f0:ad:4b:aa:97:01
eth2addr=f0:ad:4b:aa:97:02
eth3addr=f0:ad:4b:aa:97:03
ethaddr=f0:ad:4e:72:10:ef
Of course you may also skip that step and rely on random ones or choose own ones (I had router with C0:FF:EE:C0:FF:EE in past).
Then reset environment to default values stored in U-Boot binary and set those MAC addresses by hand:
=> env default -a -f
=> setenv eth1addr f0:ad:4b:aa:97:01
=> setenv eth2addr f0:ad:4b:aa:97:02
=> setenv eth3addr f0:ad:4b:aa:97:03
=> setenv ethaddr f0:ad:4e:72:10:ef
=> saveenv
Saving Environment to SPIFlash... Erasing SPI flash...Writing to SPI flash...done
OK
=>
What EBBR brings?
Now your board is ready to boot Debian, Fedora and several other distribution install media with two commands:
=> set boot_targets usb0
=> boot
It will find EFI bootloader and start it. Just like on any other boring SBBR/EBBR system.
Distributions with old style ‘boot.scr’ script (like OpenWRT for example) will also work so no functionality loss.