There's a reason I started the RISC-V port, a year ago.
background: I wrote the first SBI after the berkeley one, in 2014. I
put a lot of work into making it small, in every sense: space, time,
complexity.
The current standard, OpenSBI, is big in every sense: space, time, complexity.
So I intend to show an alternate path, starting with this port.
As part of main(), the kernel will do 3 things:
1) wipe out the opensbi firmware from RAM
2) replace it with a minimal, simple, version which does not even have
its own memory.
This version will hark back to an earlier day, when all sbi did
was fiddle bits in registers,
at the direction of the kernel
3) all higher level functions will be done in the kernel or even a server
I am fairly sure I can do this, having done something like it before.
I intend to show that risc-v does not need OpenSBI, UEFI, or ACPI.
I do think there's a way out of the firmware mess we're in; I don't
expect it to ever happen on x86 or ARM.
Even though I did do an experiment, years ago, with moving SMM to
kernel space:
https://docs.google.com/presentation/d/1ECTPzrt4hT37Ef729GAXh0o9lMvx4MJrkJxN88-k9Ps/edit?usp=sharing
I've fought and lost this SMM battle for 27 years. Why do vendors like
it? Because UEFI/ACPI/SMM are a way to implement vendor lockin. I'm
too old for this nonsense. RISC-V offers a way out and I'm going to
try to take it before things get much worse.
Anyway, there are three of us now working on the port, we've gotten to
the point of 'root is from' working over 9p, and we're going to rebase
on 9front tip in the next week or so. At that point, I hope to start
working on the simple SBI.
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T0ca6c03d6fda29a7-M9d5519dc64b322b50e212956
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
