Updating the openSBI on R-01?

DevTerm
1

There’s a whole backstory about me trying to cross-compile stuff for the R01 here, but the relevant part is: the T-Head C906 that the Allwinner D1 is based on has a hardware bug that causes program crashes whenever something tries to use the fence.tso instruction.

GCC 14 added -mno-fence-tso as a workaround for this bug, but then I need to get all the stuff I want to build to play nice with gcc14, which is not as straightforward as I would like it to be.

In the meantime, though, there’s another option: the RISC-V openSBI was updated a few years ago with a trap handler that falls back to plain fence, which works fine, rather than forwarding a SIGILL to the program and killing it. This version even appears to be included in the apt repositories for the DT! Unfortunately, as far as I can tell, the openSBI is actually part of the bootloader, and needs to be combined with u-boot and written to the correct location on the sd card to actually function. And apt upgrade doesn’t do this automatically.

So – has anyone else updated the bootloader on this machine, and the openSBI image specifically? Any hints, tips, or documentation I should be looking at before I attempt this myself?

2

Hi @ToxicFrog I believe this could help Building boot software and Debian with HDMI support from sources for a RISC-V board (Sipeed Lichee RV with D1 processor) - Andreas' website

3

Yeah, go get some UART breakout because without it youll be blind :stuck_out_tongue:
And if you already have some and can recommend i’d be interested :smiley:

4

@ToxicFrog About UART please notice is have a problem DevTerm R-01 Ext Board UART is read only? in my case I decided to solder wires and use an external FTDI USB-UART adapter.

5

Hello,
I think you are using GCC 14 with -mno-fence-tso to avoid crashes, but be prepared for compatibility adjustments.You may update the RISC-V openSBI, available in apt repositories, which includes a workaround for fence.tso issues. Specific documentation or seek community advice for safely updating the bootloader and integrating openSBI with u-boot on your device.

6

Actually i did and i can provide some tips.
Apparently you don’t need UART for this job, at least not in the best case scenario, but to the point.

Your idea with patch for C906’s fence issue was right way to go.
Also @ylyamin’s resource was a goldmine. Upgrading openSBI isn’t that scary :wink:

You indeed have to acquire u-boot’s sources as well as openSBI’s and do some mambo-jumbo, but it all works well, at least my µConsole R-01 is happy with this update. Well, sort of.

You need to obtain GitHub - tekkamanninja/u-boot: "Das U-Boot" Source Tree, build it with

git clone https://github.com/tekkamanninja/u-boot -b allwinner_d1
cd u-boot; make CROSS_COMPILE=riscv64-linux-gnu- ARCH=riscv nezha_defconfig
echo "CONFIG_MMC_BROKEN_CD=y" >> .config
make CROSS_COMPILE=riscv64-linux-gnu- ARCH=riscv oldconfig
make CROSS_COMPILE=riscv64-linux-gnu- ARCH=riscv u-boot.bin u-boot.dtb

For some reason GitHub - smaeul/opensbi: RISC-V Open Source Supervisor Binary Interface will cause R01 to bootloop. I guess more details would come over UART but i can’t check it right now.
Instead, go with this approach

git clone https://github.com/tekkamanninja/opensbi -b allwinner_d1
cd opensbi/lib/sbi

Apply patch from [PATCH 2/2] lib: sbi_illegal_insn: Add emulation for fence.tso
this is - to add one include, one Errata workaround and supersede true_illegal_inst with misc_mem_opcode.
With these changes, openSBI compiles just fine.

CROSS_COMPILE=riscv64-linux-gnu- PLATFORM=generic FW_PIC=y BUILD_INFO=y make

Then proceed with u-boot TOC1 creation, mkimage’s image generation and dd’ing resulting blob directly to µSD’s 32800 512-byte block.

This is, however, a partial win. I have to do more tests but my bootstraped Debian without openSBI’s patch( this is: regular one which comes with Ubuntu) raises a SIGILL when doing apt-get update. Probably the fence instruction.
After patching, no more illegal instructions, instead apt-get update waits for God knows what on 0% [Working] mark consuming 99% of cpu.

Would love to hear from you about your progress. I’ll try now to upgrade default ubuntu image with this new opensbi+uboot image but i guess ubuntu will work without any noticeable changes.

7

So, I was searching around and came across this post. Haiku automates a lot of this stuff (including the openSBI on u-boot) since we need a wide selection of u-boot blobs for various devices.

I’d love to add the uConsole R01 to our selection of binaries, however without the D1 / R-01 support being in upstream u-boot, we generally don’t bother. (licensing get weird and complex, and we generally want to encourage folks to upstream their work for long-term support… ARM implementation partners are bad about messily ham-fisting support for their SoC into branches that never get updated or touched again after minimum viable is reached)

tldr; Y’all get D1 / R-01 merged upstream, we can provide binaries updated semi-regularly. I’ve been thinking of making some github actions to make this happen automatically :wink:

Example specification injecting openSBI into the u-boot loader: