Current instructions for the freedom-u-sdk suggest changing the jumpers on the SiFIve Unleashed board so that FSBL is read from the MMC instead of SPI NAND. A new version is built as part of the process.
e.g. https://github.com/sifive/freedom-u-sdk#running-on-hardware
I haven’t really dared do this yet (since Fedora’s opensbi u-boot image seems to work without). But I’m just curious, what has changed since that makes this necessary?
Our meta-sifive layer includes the freedom-u540-c000-bootloader repo which puts the ZSBL/FSBL on the SDCard. I don’t know if it is actually necessary to do this. It is probably friendly to free/open source types that don’t like running hidden bootloader software. This way all of the code you are running is on the SDcard.
Yes it is, and in the longer run I’m going to do this anyhow, for that reason. But I wondered if there was some immediate necessity (e.g. subtle changes in HW/SW interface that were going to bite me). Thanks for the info.
I’ve successfully changed my board to FSBL-from-SD mode, it worked first time
Built FSBL from the freedom-u540-c000-bootloader repository, using Fedora RISC-V’s native gcc 9.2.1. I needed one patch on top: https://github.com/sifive/freedom-u540-c000-bootloader/commit/068041f77c63dd1878376ba54d29c9f227a8a2d4 to fix a missing symbol issue.
I put the FSBL on a partition of the SD, marking it with the correct UUID
Changed the dipswitch according to the ASCII-art in the freedom-u-sdk README, and rebooted
And it worked.
The only difference I’ve noticed yet is that the FSBL now prints dots to the UART while loading the next payload (OpenSBI+u-boot), which is convenient.