<ball>
Tenkawa: What does the firmware (and boot process) look like on RISC-V boards?
<Tenkawa>
ball: Once you get the hang of SBI... its a normal u-boot and load process
<ball>
What's SBI?
<Tenkawa>
(looking up the acronym)
<Tenkawa>
Supervisor Binary Interface
<Tenkawa>
SBI (Supervisor Binary Interface) is an interface between the Supervisor Execution Environment (SEE) and the supervisor. It allows the supervisor to execute some privileged operations by using the ecall instruction.
<Tenkawa>
I like this quote:
<Tenkawa>
Examples of SEE and supervisor are: M-Mode and S-Mode on Unix-class platforms, where SBI is the only interface between them, as well as the Hypervisor extended-Supervisor (HS) and Virtualized Supervisor (VS).
<Tenkawa>
I haven't quite figured out how the BPI has implemented theirs (their codebase isn't as open and documented)
<ball>
Is SBI how U-boot interacts with the firmware?
<Tenkawa>
Yep
<Tenkawa>
The RISC-V Supervisor Binary Interface (SBI) is the recommended interface between: A platform-specific firmware running in M-mode and a bootloader, a hypervisor or a general-purpose OS executing in S-mode or HS-mode.
<Tenkawa>
It sounds overcomplex on paper.... but its not too bad once you start building it
<Tenkawa>
It does allow for a lot of flexibility though if you want/need it
<ball>
We've come a long way since the PC/AT, that's for sure.
<Tenkawa>
Indeed.
zjason``` is now known as zjason
<mps>
Tenkawa: BPI have u-boot and opensbi repos on github, I've built locally both from source
<ball>
There your code had more or less unfettered access to all the hardware (and the firmware, if you chose to use it) from the moment your boot sector loaded.
<Tenkawa>
BSD is still a ways off I think in most varients/platforms.... jrtc27 and others could give a better status on that
<Tenkawa>
mps: yes I know but its very poorly documented and it has issues.. we use it in our image builder already.
<ball>
Tenkawa: I've been watching blastwave stand up FreeBSD on a (larger, more capable) RISC-V board.
<Tenkawa>
mps: we have "several" patches already we've made for it locally
<mps>
well, "use source, Luke"
<ball>
...so I learned a little bit there but I would need some more detailed notes, I think.
<mps>
I didn't tested beacuse can't even boot my BPI-F3
<Tenkawa>
mps: we are using source.. ouch... whats up?
<Tenkawa>
why wont it boot?
<mps>
Tenkawa: just funny saying, nothing more
<Tenkawa>
My biggest issue
<Tenkawa>
er
<Tenkawa>
lack of a SPI chip soldered on to the board atm
<mps>
Tenkawa: it have 2GB RAM and this version can't boot from mmc
<Tenkawa>
OH... thats you
<Tenkawa>
I remember that now
<mps>
:)
<Tenkawa>
yeah something is weird about that
<Tenkawa>
I really want SPI on mine but soldering isn't happening "by me"
<Tenkawa>
(not by the one handed man)
<mps>
but I've got new toy - loongarch64 machine so I'm not bored :)
<Tenkawa>
oh that sounds fun
<Tenkawa>
mps: what board is it?
<Tenkawa>
anything widely avail?
<mps>
3A6000 SoC, desktop machine
<mps>
ITX package
<Tenkawa>
Ahh
<mps>
nice one, 32GB RAM 256GB nvme
<Tenkawa>
the Morefine?
<mps>
TBH IDK exact model name
<Tenkawa>
nod
<mps>
it is written in Chinese
<Tenkawa>
does look interesting
mlw has joined #riscv
<mps>
compiling kernel on it is easy work compared to riscv
<mps>
but I prefer to work with riscv
<Tenkawa>
Morefine M700S is probably the unit
<Tenkawa>
and its a really nice looking unit
<mps>
looks similar but it is not this one
<mps>
I may ask loongson exact model next week
<Tenkawa>
Interesting... I wondered why loongarch64 was still so active in the kernel
<mps>
well, there are other things to improve or add
* ball
is so confused
<Tenkawa>
ball: oh why?
<ball>
Loongson confuse me with their winding pathway from MIPS32 -> Loong64 (mips64?) -> LoongArch (proprietarish?) -> RISC-V
<Tenkawa>
Ah
<ball>
...unless LoongArch is RISC-V based and I just missed the memo.
<ball>
(which is entirely possible)
<mps>
no, it is still mips
psydroid has joined #riscv
<ball>
I'm being told different things by different people then.
<ball>
mps: Is yours LoongArch or Loong64?
<ball>
mps: ...or something else?
<ball>
I could easily have missed a memo on LoongV, for example.
<mps>
ball: loongarch64
<mps>
though mips is somewhat RISC like so it share some design feature with riscv but ISA is different
<mps>
except if all stole (copies) from each other
<mps>
and IMO it is ok to do this
Isaac_S has joined #riscv
Isaac_S has quit [Client Quit]
coldfeet has joined #riscv
Tenkawa has quit [Ping timeout: 260 seconds]
Tenkawa has joined #riscv
Isaac_S has joined #riscv
<ball>
MIPS is RISC but it's not RISC-V.
<ball>
...and Loong64 isn't LoongArch.
<ball>
(I'm told)
Isaac_S has quit [Client Quit]
jfsimon1981_b has quit [Remote host closed the connection]
jfsimon1981_b has joined #riscv
jfsimon1981_c has joined #riscv
jfsimon1981_b has quit [Remote host closed the connection]
jfsimon1981_c has quit [Remote host closed the connection]
impomatic has quit [Ping timeout: 256 seconds]
<sorear>
I'm pretty sure loongson never touched riscv and went directly from mips64 to loongarch64
<mps>
I was not interested much in loongarch64 but someone offered to send me one machine to work on it and I accepted
<sorear>
I mostly only hear "Loong64" from people who are confused about what they're talking about. This isn't evidence it doesn
<sorear>
't exist
<mps>
I plan to improve alpine linux on it, nothing more