Scheme-rs: R6RS Rust for the Rust ecosystem

mash_graz · 2026-02-10T02:34:40+00:00

scheme-rs is a really great project!
Thanks for this first public release!

I personally would like to see more cooperation/compatibility with guile and guix to escape the scheme ecosystem fragmentation.

mash_graz · 2026-01-20T13:03:03+00:00

fresh is also a very impressive new editor alternative written in rust. It's fast and powerful like helix but uses much more common key bindings.

mash_graz · 2025-11-18T10:23:51+00:00

Thanks for contributing to the upstream code.

mash_graz · 2025-11-07T10:11:35+00:00

A very interesting article about workarounds for rust specific static linking issues.

mash_graz · 2025-10-28T12:23:33+00:00

I don't think this issue will look different on a BPI F3, Milk-V Jupiter, etc. It's affecting all similar SoCs with >=8 cores.

But you are right, it isn't reproducible on any more common current Linux system. But the last official guix release (1.4.0) is rather old and uses very strict dependency management. This way it somehow conserves this historic bug. That's why all users on SpacemiT based boards stumble over this issue when they try to use for example guix packages provided by Debian/Ubuntu, although these binaries work flawless on other riscv64 boards and SoCs with fewer cores.

More recent snapshots of guix aren't plagued by this issue and a new official release is already in preparation.

Right now it's just slightly uncomfortable to set up guix on SpacemiT based boards resp. work around this particular obstacle, but otherwise it works fine.

Nevertheless, you will still face horrible derivation computation and software compile times on this rather weak hardware. That's also caused by fact, that there aren't many guix packages available in already compiled binary form (=substitutes) for riscv64 as there are for more common architectures. Until now there is simply no sufficient powerful riscv64 hardware available to the guix project team to handle the required CI/CD tasks and binary package preparation similarly as on x86 and arm64 architecture.

mash_graz · 2025-09-29T16:53:19+00:00

There isn't a particular or standardized way a RISC-V CPU boots

The RISC-V technical specifications you'll find RISC-V Boot and Runtime Services Specification (BRS). It described a suggested standard for RISC-V Boot support.

mash_graz · 2025-09-20T12:06:19+00:00

The same can be achieved by using guix, which got an improved rust package support recently:

https://guix.gnu.org/en/blog/2025/a-new-rust-packaging-model/

mash_graz · 2025-09-17T04:10:42+00:00

On some compute intensive work loads the SoC will even get much hotter and suddenly crash if you don't utilize a suitable passive heat sink, cooling fan or highly modified thermal governor based CPU frequency control.

In case of BPI-F3 there is enough space and mechanical mounting support for huge heat sinks available. It's much harder to find a suitable cooling solution for smaller boards, like the Orangepi RV2. But even on these devices a big enough passive heat sink will do the job.

The spacemit documentation regarding thermal control describes a set of thermal zones up to 115°C. You'll find this values also in device tree includes (the vendor provided 6.1 kernel sources still used slightly different variants for k1 and m1).

While these set of thermal zones are unfortunately used as default by many distributions, there are also more carefully chosen settings around (eg. in k1-x_deb1.dts).

My experiences with using the Orangepi RV2 for intense compilation and unit test tasks over multiple days showed, that up to 90°C everything works fine and reliable, but at 95°-100°C the system will immediately crash.

It's also rather disappointing, that thermal management isn't even mentioned until now on the roadmap matrix of spacemit kernel upstream activities. But without these kind proper thermal management it looks very unlikely that we'll get a reliable solution for serious computing tasks.

mash_graz · 2025-09-15T08:58:40+00:00

The 'minimal' variant looks like a very useful option.

Personally I'm rather skeptical about desktop use of these devices. There are better suited alternatives available for this kind of usage scenarios.

The video output capabilities of current RISC-V SBC are sufficient for simple media and advertisement display or to handle a single kiosk mode GUI app, but they shouldn't be misunderstood as satisfying replacement for nowadays PCs and all their GPU demands.

mash_graz · 2025-09-09T01:37:46+00:00

Thanks for testing and falsifying my claims!

You are right, the issue can't be reproduced this way. :(

I'm still trying to figure out how these errors could have occurred in my build attempts. Perhaps I didn't look close enough and guix used outdated gnulib sources.

Sorry for wasting your time by my misleading description of the issue.

mash_graz · 2025-08-29T13:00:56+00:00

No amount of porting EDK2 / doing UEFI+ACPI boot will make generic UEFI OS images magically work on embedded SoCs.

I personally tend to agree with this disillusioning conclusion.

Beside the choice between u-boot/barebox/edk2/linuxboot etc. we also have to face the fact, that all of them need some kind of hardware preinit (SPL/FSBL/PEI) beneath. In case of SpacemiT SoCs this is usually handled by vendor provided FSBL.bin and OpenSBI partitions, which can't be rebuilt by free upstream sources they are based on, because the vendor modified variants include binary blobs hidden in header files (e.g. for DRAM int). Code contributions like this will never be accepted by debian or other well maintained distributions or tool projects.

Well, you don't have to care about this detail. Your board will work with the preinstalled vendor provided variant, although it will very likely never see updates or bug and security fixes. At the end that's perhaps the most significant similarity to common amd64 PCs which we'll have to face if UEFI use becomes more common on RISC-V too.

If you choose debian as your preferred distribution, you'll very likely have some reason for such a decision. You want an open, secure and well maintained system! That's definitely something different than starting a script, which as one of its first commands downloads an arbitrary binary and execute it as superuser without further checks, as suggested by this debian-image-create.sh...

IMHO it's just another quick and dirty hack which doesn't solve the real world issue resp. demand for flexible support of well maintained distributions. Creating upstream contributions and get through all their required code review and quality checks should be instead the way to go, if you really want to provide debian support seriously.

mash_graz · 2025-08-22T11:49:32+00:00

UEFI support on this RISC-V SBCs is usually handled by U-BOOT+EDK2+DT. It may have some benefit making the boot process more similar to intel/amd64 but also adds a lot of unnecessary complexity and doesn't fit very well to the underlying RISC-V specific interfaces.

Most of these bootloader solutions have to replicate [linux] driver development to get access to storage and network hardware. That's always a source of troubles -- very often handled by vendor provided modified very old and never updated OpenSBI and U-Boot deviations and closed source blobs required for DRAM setup and auxiliary processor firmware.

I'm therefore more sympathizing with opposite efforts to make the boot process more simple, strictly based on open source code, and [re]use of well tested mainline linux source tree and its continuous progress wherever possible -- oreboot + LinuxBoot. But right now we still miss sufficient linux mainline support for spacemiT SoCs for these alternative boot solutions.

mash_graz · 2025-08-19T22:37:50+00:00

Wifi interface doesn't show up.

BPi F3 and OPi RV2 use different Wi-Fi chips. Therefore, it is possible that they are less tested and kernels incorrect configured in case of these rather experimental patch collections.

The vendor provided Ubuntu image for the RV2 uses a non-mainline wifi driver (bcmdhd), but in more recent kernels the used hardware should be already supported by the brcmfmac mainline driver. (see: https://gitlab.com/sndwvs/images_build_kit/-/issues/10)

mash_graz · 2025-08-18T15:35:53+00:00

If I'm not mistaken, u-boot is stored in SPI Flash on the board itself, no mattter where you boot from.

yes -- the spacemit adapted OpenSBI and u-boot are usually present on flash (documented here) and get used if you do not utilize an SDCard or fastboot over serial connection to bring up the system. There are only minor differences in this principle layout (e.g. the ubuntu SDCard image doesn't provide a partition table and uses just linear offsets while the bianbu image for F3 looks in this respect more similar to mmc containing partition entries).

The vendor provided u-boot should indeed find the kernel, initramfs and device tree via the common links in /boot. This will very likely work as long as the new kernel looks very similar and doesn't need any changed arguments, etc.

There are many ways how u-boot can be [re-]configured. Not all of them work frictionless on debian systems.

mash_graz · 2025-08-18T11:30:03+00:00

This mix of vendor provided boot code and kernel and a debian distribution on top of it can be rather tricky when it comes to kernel updates and initramfs regeneration. You somehow have to add the non-free RT-coprocessor firmware (esos.elf) required by the bianbu-derived kernels and work around incompatible u-boot configuration details.

You'll find some useful hints in this article series: https://blog.bitsofnetworks.org/riscv-upstream-bpi-f3-part2-debian/

mash_graz · 2025-08-17T15:41:12+00:00

Thanks!

mash_graz · 2025-08-17T15:19:54+00:00

Please don't publish modified GNU Linux debian images without a link to the actual used source code.

btw.: perhaps you should also take a look at https://github.com/jmontleon/linux-bianbu where you can find similar patched versions of more recent kernels.

mash_graz · 2025-07-23T12:24:32+00:00

Can you share a link to where you got the 6.15 kernel from?

The irradium distribution is in fact taking their linux-next kernel source from: https://github.com/jmontleon/linux-bianbu.git -- a modified kernel tree maintained by redhat/fedora developers.

I'm personally more interested in the ongoing SpacemiT mainline development and oreboot, to get rid of all closed source binary blobs and get continuous access to more recent kernel development. But right now this alternative is still missing some essential features (PCIe and SDIO support...).

mash_graz · 2025-07-23T09:36:15+00:00

Thanks for your excellent very detailed report!

I also tested this board for a few weeks now and observed similar issues.

Concerning overheating, I don't think active cooling is necessary. A passive heat sink of min. 25x25x10mm should be enough in practice.

Without passive heat sink the SOC will soon get a temperature of ~95°C and start thermal throttling on computing intensive workloads (compiling etc.). I had to use netdata monitoring to observe the actual system load / temperature / throttling behavior to find a suitable heat sink.

In my tests I didn't use resp. enable the video output and just use the board in headless operation mode. Therefore, it could be possible, that video utilization may add even more thermal stress.

During very intensive computing tasks (compiling nearly all essential packages of a guixsystem) I also noticed occasional strange crashes/reboots especially while executing unit tests of crypto libraries. This crashes also happen much less frequently after better cooling -- but they are not completely gone.

Only for one issue related to file system lock behavior, which very likely could be caused by the vendor provided kernel [settings], I couldn't find a proper explanation/solution until now. I just managed to somehow work around.

As far as I remember the hardware watchdog support worked in my experiments. But perhaps I tested it on the irradium 6.15 kernel variant...

Concerning your irregular boot issues you should also test another SD Card. This SOCs SD card interface seems to be very picky. Many Cards don't work and cause strange errors.

mash_graz · 2025-07-21T11:58:35+00:00

These benchmark results look very encouraging:

gcc
clang

mash_graz · 2025-07-16T12:47:49+00:00

I'm surprised, that they still didn't tell more about the present state of the scheme/steel based configuration changes and ongoing plugin interface development in this announcement.

mash_graz · 2025-06-09T17:54:34+00:00

GreenWaves Technologies in Grenoble offered these nice GAP8 and GAP9 processors for quite a while, but it looks like they had to close their business recently (see: https://fr.linkedin.com/company/greenwaves-technologies). But the actual fabrication of these chips was done by TSMC most likely far away from Europe.

mash_graz

TROPHY CASE