SBBR or GTFO
Me.
But Arm world no longer ends on “SBBR compliant or complete mess”. For over a year there is new specification called EBBR (Embedded Base Boot Requirements).
WTH is EBBR?
In short it is kind of SBBR for devices which can not comply. So you still need to have some subset of UEFI Boot/Runtime Services but it can be provided by whatever bootloader you use. So U-Boot is fine as long it’s EFI implementation is enabled.
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.
Make it nice way
RockPro64 has 16MB of SPI flash on board. This is far more than needed for storing firmware (I remember time when it was enough for palmtop Linux).
During last month I sent a bunch of patches to U-Boot to make this board as comfortable to use as possible. Including storing of all firmware parts into on board SPI flash.
Needed files
To have U-Boot in SPI flash there you need to fetch two files:
Their sha256 sums:
3985f2ec63c2d31dc14a08bd19ed2766b9421f6c04294265d484413c33c6dccc idbloader.img 35ec30c40164f00261ac058067f0a900ce749720b5772a759e66e401be336677 u-boot.itb
Store them as files on USB pen drive.
Flashing RockPro64 board
NOTE: I assume that you already have a way to boot your board to U-Boot shell (most common is to use microSD card with U-Boot on it).
Reboot board to U-Boot shell. Plug USB pen drive into any of RockPro64 USB ports.
Next do this set of commands to update U-Boot:
Hit any key to stop autoboot: 0
=> usb start
=> ls usb 0:1
163807 idbloader.img
867908 u-boot.itb
2 file(s), 0 dir(s)
=> sf probe
SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
=> load usb 0:1 ${fdt_addr_r} idbloader.img
163807 bytes read in 16 ms (9.8 MiB/s)
=> sf update ${fdt_addr_r} 0 ${filesize}
device 0 offset 0x0, size 0x27fdf
163807 bytes written, 0 bytes skipped in 2.93s, speed 80066 B/s
=> load usb 0:1 ${fdt_addr_r} u-boot.itb
867908 bytes read in 53 ms (15.6 MiB/s)
=> sf update ${fdt_addr_r} 60000 ${filesize}
device 0 offset 0x60000, size 0xd3e44
863812 bytes written, 4096 bytes skipped in 11.476s, speed 77429 B/s
And reboot board.
After this your RockPro64 will have firmware stored in on board SPI flash. No need for wondering which offsets to use to store them on SD card etc.
Booting installation media
The nicest part of it is that no longer you need to mess with installation media. Fetch Debian/Fedora installer ISO, write it to USB pen drive, plug into port and reboot board.
Should work with any generic AArch64 installation media. Of course kernel on media needs to support RockPro64 board. I played with Debian ‘testing’ and Fedora 32 and rawhide and they booted fine.
Testing U-Boot on microSD
By default RockPro64 loads U-Boot from SPI flash. If you need/want to boot from microSD then follow instruction from official wiki:
If you mess-up your SPI and are unable to boot, jumpering pins 23 (CLK) and 25 pin (GND) on the PI-2-bus header will disable the SPI as a boot device.
You have to remove the jumper 2 seconds after having started your RP64 (before the white LED turns ON) otherwise the SPI will be missing and you won’t be able to flash it.
My setup has ‘disable SPI’ button next to ‘disconnect Tx serial line’ switch — both on small breadboard next to the board.
