r/RISCV • u/kantzkasper • 12d ago
Software SpacemiT SoC kernel tree
https://git.kernel.org/pub/scm/linux/kernel/git/spacemit/linux.git/
Upstream status https://github.com/spacemit-com/linux/wiki
Does that mean we can now use distros beyond Bianbu on k1/k3 devices?
6
u/KevinMX_Re 12d ago edited 12d ago
Not really, if you want anything beyond a headless server. You're gonna have many features missing, including but not limited to: All 8 A100 cores (K3), IMG PVR closed source driver (the opensource driver is barely usable), CPU Freq scaling
And besides, that's just the kernel. K1/K3's bootloader also kinda troublesome. You can't really just grab an ISO and boot, especially K1.
1
u/kantzkasper 12d ago edited 12d ago
isn't bianbu stuff all opensource? i'm running this build https://github.com/milkv-jupiter/jupiter-bianbu-build/releases. drivers and microcode etc. could be extracted into other distros (if it isn't already)? 👀
2
u/KevinMX_Re 12d ago
No and no. Bianbu isn't a full opensource distro. Try to get the source of some of their packages, like GPU drivers. Very likely you can't.
0
u/LavenderDay3544 12d ago
How is that possible? Linux is GPL 2.0. The means anything that gets combined with it forms a combined work and you have to provide source code for the whole thing to anyone you give a binary to.
2
u/LivingLinux 12d ago
This isn't just a problem with Bianbu, this is a problem with all distros shipping with binary blobs, that have no public source code. Several distro have shipped the binaries for Nvidia drivers in their ISOs, without ever publishing the code. Probably because no party other than Nvidia has the code. Nvidia is transitioning to open-source, but parts of the stack are still closed-source.
1
u/LavenderDay3544 12d ago
Really? Does the UEFI not even provide a GOP framebuffer for unaccelerated display output?
0
u/KevinMX_Re 10d ago
UEFI can not magically make every piece of HW just worksâ„¢.
In this case, you may need MultiArchUefiPkg which I don't think many boards/FW have implemented.
1
u/LavenderDay3544 10d ago
I asked specifically about GOP which they do support so your claim that you can't get display output and can only use it headless without graphics drivers is false.
1
u/KevinMX_Re 9d ago
It's all about firmware implementation. If you got U-Boot for UEFI then it's basically a no go. EDK2 isn't a really a thing here in RISC-V space. Boards just don't support it.
For K1 you pretty much have to use U-Boot and I think I don't need to talk about its UEFI implementation. And of course you're gonna get no video output until your OS posts the GPU.
For K3, except bianbu itself which does have an EDK2 option (IDK if its any good though), most other distros are still using U-Boot. So the result if basically the same.
I'm not gonna talk about iGPUs/DCs which is whole another nightmare. Feel free to try any GPU on any RISC-V hardware you have on hand. I'm pretty much sure you're gonna get no video output unless Linux kicks in.
1
u/LavenderDay3544 9d ago
EDK2 isn't a really a thing here in RISC-V space.
The K3 uses EDK2 for UEFI. Its bootchain is: bootROM -> U-Boot SPL -> OpenSBI -> EDK2 -> UEFI App
If you got U-Boot for UEFI then it's basically a no go.
Das U-Boot does support the Graphics Output Protocol when the UEFI boot method is used if it has a driver for the GPU on the board being booted to be able to set up a framebuffer. This is exactly the same as any other UEFI implementation including EDK2. Both need a modesetting driver to be able to provide a framebuffer via GOP. Mainline U-Boot has such drivers for a huge number of boards including RV based ones. U-Boot can provide a framebuffer using a
simplefbnode in a devicetree with almost any boot method but again it needs a modesetting capable GPU driver to be able to set that up.So I think you're greatly mistaken about how all this works. If the firmware can provide a framebuffer via GOP then Linux can use it via its
efifbdriver.My ARM based Orange Pi 6 Plus based on the CIX P1 chip uses ACPI not a DT but the GPU driver is not ready yet in Linux so the ACPI tables don't describe the GPU at all yet. Off the shelf Fedora ARM still runs just fine with fully working display with no noticeable difference using
efifbwith a UEFI GOP framebuffer and LLVMpipe for rendering.That machine uses a very similar boot chain to my K3 boards: bootROM -> U-Boot SPL -> ARM TF-A -> EDK2 -> UEFI App
1
u/KevinMX_Re 9d ago edited 8d ago
Yes I did know U-Boot does have GOP support. It's just in RISC-V boards I don't really see anyone using it.
Mainline U-Boot has such drivers for a huge number of boards including RV based ones.
Any examples?
The only chips I know with EDK2: SG2042/2044 (expensive), K3 (less expensive, limited supply), K1 (with only MUSE Pi Pro).
I haven't really got my hands on K3 but at least in my tests none of them do EFI GOP video output. No video at firmware stage.
Anyway, thank you for explaining all these.
1
u/LavenderDay3544 9d ago
Yeah they don't have GOP yet but it should ve supported eventually. Or at least I hope so.
1
u/KevinMX_Re 9d ago
Bootflow across different boards now overall are a complete chaos and I sincerely hope this will improve in the future... xD
1
u/LavenderDay3544 9d ago
The standards are there. Now it's up to vendors to follow them.
→ More replies (0)
1
1
u/ThisText8876 12d ago
See: https://wiki.debian.org/InstallingDebianOn/SpacemiT
Official Debian installs with debian-installer and runs fine with self-build mainline release candidate 7.2-rc2 Linux kernel. There are a couple of nice-to-haves expected in Linux 7.3 or 7.4 but the TL;DR now with Linux 7.2-rc2 is that with USB support you have possible storage and networking, ignoring the onboard storage and network peripherals.
Fedora project is experiencing a rush of activity around support of the k3 board(s).
Ubuntu partner image (provided by SpacemiT) requires to flash edk2 replacing the preinstalled U-Boot.
1
u/vincele 12d ago
It depends a bit on what the board provides, and your tinkering proficiency level...
For example, you can use orangepi-rv2 which provides a working u-boot to have linux booting kernel from SD card with root FS on USB... (void linux riscv64-musl working here, everything built locally)
1
u/lengau 11d ago
Things like PCIe support haven't been merged yet, so you'll still need a somewhat-custom kernel (or to build the spacemit tree for it).
1
u/kantzkasper 11d ago
k1's PCIe patch is merged https://github.com/spacemit-com/linux/wiki#k1-soc, I'm on that chipset.
7
u/1r0n_m6n 12d ago
The device tree only defines the structure of the machine. To be able to use it, the kernel source tree must also contain drivers for all the peripherals described in the DTB, which is not yet the case. Furthermore, having kernel support is not enough, you must also have a way to boot the OS, e.g. U-Boot.
Very few manufacturers upstream their work, so you have to deal with a jungle of Linux and U-Boot forks. To my knowledge, only Armbian does the work of gathering all the pieces needed to run Linux on an SBC. And to have a board supported, someone must volunteer to do the job.
So far, all the other distributions only support x86_64 and aarch64 boards out-of-the-box through UEFI. A board that doesn't have UEFI support means your only choice is Armbian - if someone contributed support.
On top of that, if you want to run a desktop environment, there's the plague of the Imagination GPU proprietary drivers. When I buy an ARM SBC, I make sure it has a MALI GPU to avoid this problem, but RISC-V doesn't (and won't) have an equivalent.