sysutils/opensbi: update to v1.3

[mhorne]

Summary

As usual, bump revision of dependent u-boot ports.

Test Plan

Build + testport in poudriere, boot on HiFive Unmatched and QEMU.

[jrtc27]

LGTM if it builds and boots

OOI, should we be upstreaming the FU540 bits? The patches are small, but surely FU540 users on other OSes need them? Or maybe there are no such users these days...

[mhorne]

In D40915#931344, @jrtc27 wrote:

OOI, should we be upstreaming the FU540 bits? The patches are small, but surely FU540 users on other OSes need them? Or maybe there are no such users these days...

It's not really upstreamable. The patch can go away when I finally fix the DMAP so that it is created with L2 pages and does not cross the OpenSBI PMP boundaries. Of course this has been low priority because there is.. maybe one person with a FU540 (@fuz, I recall).

[mhorne]

Ugh, it is broken with the clang 16.0 update in main.

...
mkdir -p `dirname /wrkdirs/usr/ports/sysutils/opensbi/work/opensbi-1.3/build/platform/generic/firmware/fw_dynamic.o`; echo " AS        platform/generic/firmware/fw_dynamic.o"; clang -g -Wall -nostdlib -fno-omit-frame-pointer -fno-optimize-sibling-calls -mstrict-align -mno-save-restore -mabi=lp64 -march=rv64imafdc -mcmodel=medany -mno-relax --target=riscv64-unknown-elf -Wno-unused-command-line-argument -I/wrkdirs/usr/ports/sysutils/opensbi/work/opensbi-1.3/platform/generic/include -I/wrkdirs/usr/ports/sysutils/opensbi/work/opensbi-1.3/include -include /wrkdirs/usr/ports/sysutils/opensbi/work/opensbi-1.3/build/platform/generic/kconfig/autoconf.h -I/wrkdirs/usr/ports/sysutils/opensbi/work/opensbi-1.3/lib/utils/libfdt/  -DFW_PIC -DFW_TEXT_START=0x80000000 -DFW_JUMP_ADDR=0x80200000 -DFW_JUMP_FDT_ADDR=0x82200000  -fpic -I/wrkdirs/usr/ports/sysutils/opensbi/work/opensbi-1.3/firmware -D__OBJNAME__=fw_dynamic -c /wrkdirs/usr/ports/sysutils/opensbi/work/opensbi-1.3/firmware/fw_dynamic.S -o /wrkdirs/usr/ports/sysutils/opensbi/work/opensbi-1.3/build/platform/generic/firmware/fw_dynamic.o
 AS        platform/generic/firmware/fw_dynamic.o
/tmp/fw_dynamic-749e32.s:429:9: error: symbol '_fw_start' can not be undefined in a subtraction expression
 .dword _fw_rw_start - _fw_start
        ^
gmake[1]: *** [Makefile:580: /wrkdirs/usr/ports/sysutils/opensbi/work/opensbi-1.3/build/platform/generic/firmware/fw_dynamic.o] Error 1
gmake[1]: Leaving directory '/wrkdirs/usr/ports/sysutils/opensbi/work/opensbi-1.3'
*** Error code 2

I will update shortly with a fix.

[mhorne]

Include a patch to work around the issue with clang 16.0. Most likely this is what I will send to upstream.

[mhorne]

sysutils/opensbi/files/patch-firmware_fw__base.S

8–12

@jrtc27 this seem sensible? FYI a4 contains the address _fw_start when it is used here.

[jrtc27]

sysutils/opensbi/files/patch-firmware_fw__base.S

8–12

Yeah, this was one of my suggestions in http://lists.infradead.org/pipermail/opensbi/2023-January/004273.html. It'll probably perform better than a load, too. The constant pool is unnecessary here.

FWIW current LLVM trunk has fixed this, though I don't recall which exact patch it was, I just remember seeing things around this go past between 16 and 17.