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.
To have U-Boot there you need to fetch two files:
- SPL + TPL
- U-Boot itself
Their sha256 sums:
3985f2ec63c2d31dc14a08bd19ed2766b9421f6c04294265d484413c33c6dccc ...
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.
To have U-Boot there you need to fetch two files:
- SPL + TPL
- U-Boot itself
Their sha256 sums:
3985f2ec63c2d31dc14a08bd19ed2766b9421f6c04294265d484413c33c6dccc idbloader.img 35ec30c40164f00261ac058067f0a900ce749720b5772a759e66e401be336677 u-boot.itb
Store them as files on USB pen drive and plug it into any of RockPro64 USB ports. Then reboot to U-Boot as you did before (stored in SPI or on SD card or on EMMC module).
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.
My setup
My board boots to either Fedora rawhide or Debian ‘testing’ (two separate pen drives).