Attendees: Jeff, Greg, Darren, Paul Sherman, Lance, Heinrich, Bo Gan, Carl, Emil, Yu Bo, Andreas, Daniel, Axel
Board Updates:
None
Program Updates:
Debian
Munin for debci riscv64 workers will be available soon.
Fedora
SUSE
Looking to add native workers to OBS ( https://build.opensuse.org/monitor )
Investigating Milk-V Pioneer.
Reminder from Emil: Also note that the C930 cores in the Pioneer like the other "1st gen" T-Head cores (C910 on TH1520 and C906 on the D1) suffer from a broken floating point rounding bug. So if your package test suites are very thorough they might fail :/
Working with Sophgo on upstreaming their support.
Canonical
U-Boot Milk-V Mars support has gone upstream. Patches for Milk-V Mars CM sent upstream.
Linux Upstream kernel Mars board support improving: patches for PCI and device-tree are under review.
R9
Made first steps with recursive page tables 🥳 https://github.com/orangecms/r9/tree/riscv64-paging
oreboot
PoC for mixed AMP+SMP platform and boot flow design is WIP
Firmware
coreboot and oreboot now have their own SBI implementation IDs https://github.com/riscv-non-isa/riscv-sbi-doc/blob/master/src/ext-base.adoc#sbi-implementation-ids \o/
RISC-V
Kendryte boards submitted to vendor and expect to ship soon
Status requested on Pioneer shipments. No update yet.
Huashan Pi projects acceptance/rejection underway.
Rocky Linux has received their VF2 boards.
LicheePi Cluster shipping to OSU.
Still building future plans. Envision 2 boards – developer board (Raspberry Pi form factor) and server board (miniITX). Strongest candidates at this time Banana Pi and Milk-V Oasis, but may change due to availability.
What’s cool?:
https://www.tomshardware.com/pc-components/cpus/former-silicon-valley-vets-create-risc-v-microprocessor-that-can-run-cpu-gpu-and-npu-workloads-simultaneously - X-Silicon’s new core
https://www.techspot.com/news/102413-latest-risc-v-controller-provides-14gbs-transfers-without.html - The RISC V-based YRS820 controller for SSDs which is fanless.
https://www.design-reuse.com/news/56036/sifive-out-of-order-risc-v-development-board.html - Premier P550 board from SiFive expected to be available through Arrow Electronics in July 2024.
https://www.achronix.com/press-releases/achronix-fpgas-add-support-bluespecs-linux-capable-risc-v-soft-processors-enable - RISC-V IP from Bluespec
https://www.amazon.in/dp/B0CZ8NBQD1?ref_=cm_sw_r_cp_ud_dp_14ASW174X1BYRGJWD2DE - VSDSquadron Mini from Amazon India for ~$15 USD (Could not find in Amazon U.S.)
https://youtu.be/f6mPK3QCrBo - Explaining Computers RISC-V 2024 update
https://www.quintauris.eu/ - New company (collaboration of Qualcomm, Bosch, Infineon Technology, Nordic Semiconductor, and NXP Semiconductors) developing and selling RISC-V IP for automotive, IoT, mobile, and more.
More details on the SG2036 which will be used in the Milk-V Oasis: https://github.com/rv2036/slides-and-docs (source: RVI Slack #general)
Next meetup in Munich tomorrow https://www.meetup.com/munich-risc-v-meetup-group/events/299154376/
Running older kernels have problems where loading a GPU can cause errors around “soft hangs” which are related to the ELF relocation code. Example: AMDGPU does not load in less than 15min and the kernel will kill the thread first. This was fixed in 6.8, may be worth vendors backporting this patch to their kernels when loading larger modules (like GPU) are expected: https://github.com/torvalds/linux/commit/080c4324fa5e81ff3780206a138223abfb57a68e
Open Source Firmware Conference Call for Participation is open https://www.osfc.io/
Will be held in Bochum / Germany, September 3-5
Miscellaneous discussions:
How might we build a “program” in advance of having actual hardware?
Should we poll our Distro and “Core Projects” about their needs for pending hardware? If so, what are key questions?
Is there value in building a virtual project for external program? We could assume “Raspberry Pi” form factor.
GPU Driver Support on RISC-V Platforms
How do we tackle this ecosystem?
Carl’s update: Bug with drivers helped alot (see above github.com/torvalds item in What’s Cool)
Ubuntu 23.10 on Unmatched with an old Radeon HD6450 card “worked”, but took 5+ min to boot with a lot of errors. Newer GPUs that required larger drivers did not work.
Testing the Linux 6.8 kernel on Arch worked perfectly with both the HD6450 and an RX460 card, haven’t had a chance to test the 6.8 kernel on a Ubuntu 23.10 userspace
Imagination (IMG) is what most RISC-V Boards are using
The cores used by every board we are tracking are using IMG’s “Rogue Architecture” which is brand new IP and they have committed to Open Source driver support. These are also Vulkan first, Vulkan native. So the expectation is that Mesa and thus Zink (module of Mesa) will be providing legacy OpenGL/GL-ES/GLX calls and “wrap” them via Vulkan to the hardware
Carl reached out to the devs, and learned a lot: https://gitlab.freedesktop.org/frankbinns/powervr/-/issues/7
The development has moved from individual contributor’s repos on freedesktop.org to a unified one: https://gitlab.freedesktop.org/imagination
The current upstream drivers from Imagination are gated with an Aarch64 Kconfig but they were fairly confident that all the code was portable and was receptive to enabling RV64 gating as well
I had also asked for support for a series of boards, here are the requests, the GPU blocks (as far as I can tell) and their status:
TH1520 (Lichee Pi4A) using BMX-4-64, partial support in place
JH7100 (VisionFive 2, Milk-V Mars, etc) using BXE-4-32, partial support but no firmware yet. Should be an easy lift
Spacemit K2 (BPI-F3) using BXE-2-32, partial support but no firmware. Should be an easy lift to support.
SG3260 (Oasis) using AXT-16-512, no support yet and will be a rather heavy lift since this is a completely different IP track.
This may not be a major problem in the short term, because the Oasis specifically has a wide aperture PCI-express implementation, so using an off the shelf GPU should “just work” (much like SiFive Unmatched)
Also working on GPU support for U-Boot which is quite old for several boards.
StarFive’s downstream U-Boot has support for enough of the Framebuffer on the JH7110 to give a splash screen. May be possible to leverage that for U-Boot’s framebuffer console
It may be possible to then leverage that code to get some form of framebuffer running on the TH1520 as well. Need to do lots of porting to get to that point (the TH1520 vendor U-Boot tree is even older than the JH7110)
My goal is something akin to Tow-Boot - which gives a much more user friendly experience. Even if the kernel DRM/KMS doesn’t work, this will at least make it easier for users to change operating systems due to UEFI support
Heinrich suggested that U-Boot enabling a console may allow Linux to access it, but I will need to investigate that: https://docs.kernel.org/fb/efifb.html I’m not sure if U-Boot implements the EFI UGA architecture
RISC-V GPU SIG
The SIG is working with various Universities to make a GPU core using exclusively RISC-V IP
During Summit 2023 there were discussions around how to support legacy APIs like GL, and we agreed that skipping that and going straight to Vulkan (in the same footsteps of IMG Rogue and Intel Xe) would make life much easier, and Mesa/Zink can be leveraged to provide legacy support.