openwrt
openwrt copied to clipboard
openwrt
sifiveu: add new RISC-V target
This PR adds support for the SiFive U-based, Linux-capable RISC-V SoCs.
-
Supported SoCs: SiFive FU540 SiFive FU740 QEMU support is being prepared for those who don't own actual hardware, and for the StarFive JH SoC which is used on the VisionFive board.
-
Supported hardware: HiFive Unleashed (FU540)
- CPU: SiFive FU540 quad-core RISC-V (U54, RV64IMAFDC or RV64GC)
- Memory: 8Gb
- Ethernet: 1x 10/100/1000
HiFive Unmatched (FU740)
- CPU: SiFive FU740 quad-core RISC-V (U74, RV64IMAFDCB or RV64GCB)
- Memory: 16Gb
- Ethernet: 1x 10/100/1000
- USB: 4x USB 3.2
- PCIe:
- 1x PCIe Gen3 x8
- 1x M.2 key M (PCIe x4)
- 1x M.2 Key E (PCIe x1 / USB2.0)
The OpenWrt core packages and most of the external packages are built successfully with this new architecture (a buildbot was set up to test this new arch), and separate PRs are being submitted for packages which don't (i.e. samba4, perl).
Signed-off-by: Zoltan HERPAI [email protected]
I added a new target for the starfive chip here: https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=shortlog;h=refs/heads/kitchensink-202205-2
This is still based on an older version of your code, I will rebase it on this one in one or two weeks and want to add the code to create a sdcard image.
I was thing about adding the patches to this target, but I do not know if I break this target. Probably we can merge the two targets in about 2 years when the starfive chip is well supported upstream.
Why the sifiveu target name instead of using riscv as target name and then sifiveu as subtarget name? If we decide to go for sifiveu as target name, a generic subtarget should be added (see 853e4dd3062df7cb5704b15d6af6730e3194b571).
Why the sifiveu target name instead of using riscv as target name and then sifiveu as subtarget name? If we decide to go for sifiveu as target name, a generic subtarget should be added (see 853e4dd).
We should stick to sifiveu in my opinion for now, there might/will be other RISC-V SoCs / targets coming up with different feature sets like the D1 has. Fair enough for the generic subtarget - I was just about to push a rebase, let me do another spin with this added.
Why the sifiveu target name instead of using riscv as target name and then sifiveu as subtarget name? If we decide to go for sifiveu as target name, a generic subtarget should be added (see 853e4dd).
We should stick to sifiveu in my opinion for now, there might/will be other RISC-V SoCs / targets coming up with different feature sets like the D1 has. Fair enough for the generic subtarget - I was just about to push a rebase, let me do another spin with this added.
Rebased, added 'generic' subtarget, disabled DA9063 for now (MFD on the Unmatched board). Ping @stintel .
Looks like that opensbi needs updating to be able to build with newer versions of GCC and binutils:
diff --git a/package/boot/opensbi/Makefile b/package/boot/opensbi/Makefile
index 7e5287bb54..01348e50aa 100644
--- a/package/boot/opensbi/Makefile
+++ b/package/boot/opensbi/Makefile
@@ -6,13 +6,13 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=opensbi
-PKG_RELEASE:=1.0
+PKG_RELEASE:=1.2
PKG_SOURCE_PROTO:=git
PKG_SOURCE_URL=https://github.com/riscv/opensbi
-PKG_SOURCE_DATE:=2021-12-24
-PKG_SOURCE_VERSION:=48f91ee9c960f048c4a7d1da4447d31e04931e38
-PKG_MIRROR_HASH:=4911a3b977d6616787abf6bd8a2299c7552633a1caf2c2bbf39f3e57106e5e4d
+PKG_SOURCE_DATE:=2022-12-24
+PKG_SOURCE_VERSION:=6b5188ca14e59ce7bf71afe4e7d3d557c3d31bf8
+PKG_MIRROR_HASH:=edcdd99da6c62975171981c0aa2b73a27091067da11ccd49816b5ad27d000858
PKG_BUILD_DIR=$(BUILD_DIR)/$(PKG_NAME)-$(BUILD_VARIANT)/$(PKG_NAME)-$(PKG_VERSION)
Otherwise I'm seeing this:
CC lib/sbi/sbi_tlb.o
/usr/src/openwrt/build_dir/target-riscv64_riscv64_musl/opensbi-generic/opensbi-2021-12-24-48f91ee9/lib/sbi/sbi_tlb.c: Assembler messages:
/usr/src/openwrt/build_dir/target-riscv64_riscv64_musl/opensbi-generic/opensbi-2021-12-24-48f91ee9/lib/sbi/sbi_tlb.c:190: Error: unrecognized opcode `fence.i', extension `zifencei' required
make[4]: *** [Makefile:431: /usr/src/openwrt/build_dir/target-riscv64_riscv64_musl/opensbi-generic/opensbi-2021-12-24-48f91ee9/build/lib/sbi/sbi_tlb.o] Error 1
Looks like that opensbi needs updating to be able to build with newer versions of GCC and binutils:
Builds fine with gcc12+binutils2.39 - hard to test with something that's not in the tree yet :) Thanks for the heads-up, as the opensbi 1.2 upgrade is already prepped (and tested on the boards) in my staging, will push it here as well.
Builds fine with gcc12+binutils2.39
I've seen the build error quoted above with gcc12+binututils2.39. Try starting with a clean build tree, apply this series on top and realize that neither U-Boot nor OpenSBI will build with gcc12+binutils2.39 as-is, both will need updating.
In case of OpenSBI, this has been fixed upstream with https://github.com/riscv-software-src/opensbi/commit/5d53b55aa77ffeefd4012445dfa6ad3535e1ff2c which is contained in v1.1 and v1.2, but not v1.0.
Just tried building U-Boot 2023.01, that also builds flawlessly, but downstream patches will need updating.
The structure looks good to me. I also prefer to name this target sifive like you did The vision five already needs different patches and the Allwinner D1 is very different.
@aparcar Afaik development continued here https://git.openwrt.org/?p=openwrt/staging/wigyori.git;a=shortlog;h=refs/heads/riscv-upstream-202301c
@aparcar knocking on open doors, I'm refreshing it tonight and then will push the target in.
I have been out for most of the last month, will make a refresh and merge it finally.
There are a few changes in this latest re-spin, notably:
- sysupgrade support added
- use compressed image in FIT
- u-boot bumped to 2022.10 (as swig is available on the buildbots and other u-boot packages also use it)
The last patch to use binutils 2.38 is a bit of a question mark. When I first tested against the latest 5.15.106 kernel, it initially stuck after started by u-boot at "Starting kernel", and bisecting the versions between the last known-good 5.15.98 and .106 resulted in random stucks also. This initially led to the some patches backported to the previous u-boot/2021.10 release, then to the u-boot upgrade, but the issue remained. Checking the toolchain, binutils has been since defaulted to 2.40 in trunk, while the Freedom U SDK also uses an earlier binutils release. Reverting back to the known-good binutils 2.38 seems to be working, as I didn't see the issue since. The patch I've added is a conservative approach for now.
I just rebased the branch to see if it's working with latest musl update. If it does, I'd be in favour to merge it. CC @hauke @wigyori
I would also like to see this merged, I think there is a more recent version in @wigyori 's staging tree.
I do not have this hardware.
- removed the binutils 2.38 downgrade, that was a red herring
- switched to use Image instead of uImage for booting
- tested with various 5.15 kernel versions, they boot fine
- there was a gcc 12.3 upgrade in the meantime, which might have contributed to fix the issue above
- tested with the new musl release
This seems to be in a good shape to be merged.
tools build on CI is erroring for another reason, not actually known
#12700 should fix it though
sorry for the inconvenience
- image Makefile cleanup
- switch to use compressed Image to reduce boot time
Any concerns before merging? @mpratt14 ?
I don't know anything about sifiveu, I just wanted to let you know about why the CI failed earlier
@wigyori I was wondering about virtual testing options for riscv32/64. It looks like your sifiveu images might run under QEMU, based on machine support. Is that true? Are there options for riscv32? Do we need to add something similar to armvirt perhaps?
Motivation for all this is some periodic BPF subsystem testing I do, and riscv support is new...
@wigyori I was wondering about virtual testing options for riscv32/64. It looks like your sifiveu images might run under QEMU, based on machine support. Is that true? Are there options for riscv32? Do we need to add something similar to armvirt perhaps?
Motivation for all this is some periodic BPF subsystem testing I do, and riscv support is new...
It's in the plan - currently there are two issues. One is that the MMC emulation is horrendously slow (seems like ARM suffers from this as well), the other is that there is an issue with the i2c initialization.
[ 1.312390] Oops - load access fault [#1]
[ 1.312812] Modules linked in:
[ 1.313365] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.113 #0
[ 1.313960] Hardware name: SiFive HiFive Unleashed A00 (DT)
[ 1.314535] epc : oc_getreg_8+0x10/0x22
[ 1.315556] ra : ocores_i2c_probe+0xf8/0x684
[ 1.315995] epc : ffffffff803d69e2 ra : ffffffff803d7098 sp : ffffffd00400bbb0
[ 1.316541] gp : ffffffff80ecf1e8 tp : ffffffe07ff44980 t0 : ffffffd00400ba40
[ 1.317085] t1 : 000000000000ff00 t2 : 203a65726f636273 s0 : ffffffd00400bbc0
[ 1.317618] s1 : ffffffe07fee6828 a0 : ffffffd00404d008 a1 : 0000000000000008
[ 1.318291] a2 : ffffffff80a34050 a3 : 0000000000000000 a4 : ffffffff80eac086
[ 1.319354] a5 : 0000000000000002 a6 : 0000000000000020 a7 : 0000000000000003
[ 1.320056] s2 : 000000000000000d s3 : ffffffe07fee3c00 s4 : 0000000000000000
[ 1.320805] s5 : ffffffe07fee3c10 s6 : ffffffe080052ba0 s7 : ffffffffffffffea
[ 1.321560] s8 : ffffffe1ffdf1a58 s9 : ffffffff806000ac s10: 0000000000000000
[ 1.322227] s11: 0000000000000000 t3 : 0000000000ff0000 t4 : ffffffffffffffff
[ 1.322933] t5 : 000000ff00000000 t6 : ffffffe080052755
[ 1.323515] status: 0000000200000120 badaddr: ffffffd00404d008 cause: 0000000000000005
[ 1.324420] [<ffffffff803d69e2>] oc_getreg_8+0x10/0x22
[ 1.326590] ---[ end trace 6766da436af20fe0 ]---
[ 1.327200] Kernel panic - not syncing: Fatal exception
[ 1.327693] SMP: stopping secondary CPUs
[ 1.329389] Rebooting in 1 seconds..
I'll need to spend some time on the latter.
Apart from these issues, it will be quite easy to get it going, you just need the u-boot-spl.bin from the build_dir, which is not installed to bin/targets/sifiveu at this moment.
qemu-system-riscv64 -M sifive_u,msel=11 -smp 5 -m 8G -display none -serial stdio -bios build_dir/target-riscv64_riscv64_musl/u-boot-sifive_unleashed/u-boot-2022.10/spl/u-boot-spl.bin -drive file=bin/targets/sifiveu/generic/openwrt-sifiveu-generic-sifive_unleashed-ext4-sdcard.img,if=sd
(You'll need to unzip the sdcard image, and also run a qemu-img resize.)
Thanks for the update and background, and I'll keep watching for progress.