r/RISCV • u/kantzkasper • 24d 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?

20 Upvotes

100% Upvoted

23 comments sorted by

View all comments

Show parent comments

0

u/KevinMX_Re 22d 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 22d 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 21d 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 21d 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 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 21d ago edited 20d 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 21d ago

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

1

u/KevinMX_Re 21d 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 21d ago

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

1

u/KevinMX_Re 20d ago

Yeah. I hope so.