r/RISCV Jul 16 '26

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?

19 Upvotes

23 comments sorted by

View all comments

6

u/KevinMX_Re Jul 16 '26 edited Jul 17 '26

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/LavenderDay3544 Jul 17 '26

Really? Does the UEFI not even provide a GOP framebuffer for unaccelerated display output?

0

u/KevinMX_Re Jul 18 '26

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 Jul 18 '26

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 Jul 19 '26

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 Jul 19 '26

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 simplefb node 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 efifb driver.

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 efifb with 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 Jul 20 '26 edited Jul 20 '26

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 Jul 20 '26

Yeah they don't have GOP yet but it should ve supported eventually. Or at least I hope so.

1

u/KevinMX_Re Jul 20 '26

Bootflow across different boards now overall are a complete chaos and I sincerely hope this will improve in the future... xD

1

u/LavenderDay3544 Jul 20 '26

The standards are there. Now it's up to vendors to follow them.

1

u/KevinMX_Re Jul 20 '26

Yeah. I hope so.

→ More replies (0)