memset has quit [Remote host closed the connection]
memset has joined #riscv
libercv has joined #riscv
vagrantc has joined #riscv
ksp4 has quit [Remote host closed the connection]
cousteau has joined #riscv
ksp4 has joined #riscv
ionutc has joined #riscv
<ionutc>
can I link to libplatsbi.a (opensbi) to easily create a kernel-like program? I can't seem to get it working. I am using C. can anyone take a look? https://pastebin.com/a3btjRMq
psydroid has joined #riscv
jjido has joined #riscv
peepsalot has joined #riscv
<ionutc>
can I link to libplatsbi.a (opensbi) to easily create a kernel-like program? I can't seem to get it working. I am using C. can anyone take a look? https://pastebin.com/a3btjRMq
libercv has quit [Quit: Konversation terminated!]
dramforever[m]1 has joined #riscv
<dramforever[m]1>
ionutc: i don't think you can really do that with opensbi. the `.a` stuff *are* the entirety of opensbi
<dramforever[m]1>
you can override everything but i don't think it's meant to be that
cousteau has quit [Quit: Client closed]
<ionutc>
sbi calls are possible in assembly. so this "library" isn't really a library?
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
<dramforever[m]1>
what kind of sbi calls are you envisioning?
<dramforever[m]1>
if you mean with the ecall instruction that's not what linking with gets you
<dramforever[m]1>
look into fw_payload
<dramforever[m]1>
if you want to have one image
<ionutc>
things like sbi_debug_console_write to output things to uart
<ionutc>
ideally i would want fw_dynamic or fw_jump
<dramforever[m]1>
yeah those are more flexible but you don't end up with one combined image
<dramforever[m]1>
neither are the .a though
ldevulder has quit [Quit: Leaving]
<dramforever[m]1>
like it's unclear what context you're trying to call opensbi from
<dramforever[m]1>
but if it's a s-mode kernel then linking is not gonna help
<ionutc>
yeah it's a kernel. I'm giving myself about 13 months to write it and I has wondering if I could do all these BIOS-ey things using OpenSBI
<dramforever[m]1>
no
<dramforever[m]1>
the one thing that's a bit bios-ey is DBCN which honestly is very useful for dumping logs
<dramforever[m]1>
do not expect the sbi implementation to give you random device drivers
<ionutc>
no nothing like that, but I was expecting to be able to at least easily print things in the serial console
<ionutc>
using C, I mean
<dramforever[m]1>
you may be misunderstanding what sbi calls are
<dramforever[m]1>
they're not a library you link with that provides you with functions
<dramforever[m]1>
they're very specific things that are provided to s-mode software
<dramforever[m]1>
a bit like system calls
ksp4 has quit [Ping timeout: 244 seconds]
psydroid has quit [Ping timeout: 260 seconds]
<ionutc>
in my understanding, opensbi is the thing loaded by the zsbl at 0x8000_0000. through the fw_dynamic_info struct, execution jumps at a certain address and runs in S mode.
<ionutc>
I just thought these sbi calls had an easy to use C library to speed things up.
<dh`>
sbi calls are basically hypercalls, they run in m-mode
ksp4 has joined #riscv
<dramforever[m]1>
i don't know if there's a c library for that
<dramforever[m]1>
but the .a files from opensbi ain't that
memset has quit [Remote host closed the connection]
<dramforever[m]1>
to be honest, most kernel authors do the NIH thing because they really do not want to have to depend on an interface
<dh`>
yeah plus it's like 100 lines of asm for the whole thing, if you're writing a kernel there are many much larger things to worry about
<ionutc>
Thing is that I do own a riscv board and depending on opensbi would have been great for portability
<ionutc>
thanks anyways guys, i'll study what the guys at mit did with xv6 and probably mimic that setup
<dramforever[m]1>
an os should run on top of sbi in s-mode
<dramforever[m]1>
(i don't know why some really want to diy sbi)
<dramforever[m]1>
but it doesn't really help with portability much. you can check the list of defined sbi functions: it's like debug console, timer, booting up other harts, ipi, remote fence, and fifteen very specific things
<ionutc>
alright. it looks like I'll have to do it using inline assembly. what a load of boilerplate
guerby_ is now known as guerby
ionutc has quit [Changing host]
ionutc has joined #riscv
coldfeet has joined #riscv
<dh`>
inline assembly? why?
<dh`>
and again, it's like maybe 100 lines of asm total
<dh`>
(do the SBI calling sequences follow the C calling conventions? I can't remember, but I would think they do. if not, maybe 200 lines of asm...)
<ionutc>
someone correct me if i'm wrong but they don't
psydroid has joined #riscv
<dh`>
I thought it was like a typical syscall where the args go in the args registers and there's a call/function number that goes in some other register
mlw has quit [Ping timeout: 248 seconds]
<ionutc>
ok it's pretty much like that then :)
<dh`>
so basically you make a .S file, and in it you have one entry point for each sbi call, which loads the call number and jumps to another function, which does the hypercall and then returns
<dh`>
so two instructions per entry point plus two or three in the shared function
mlw has joined #riscv
<dh`>
so if you include lines for directives and whatnot and a couple dozen entry points, ~100 lines of code
<dh`>
and tbh if that takes much longer to write than we just spent talking about it, you maybe ought to go get some more experience before tackling a whole kernel :-)
<ionutc>
haha I'll get to it. i just thought import statements and C functions would be nicer. I'll definitely book up more. Most of my programming experience is typescript lol
<dh`>
C is almost 40 years old
<dh`>
and it's been more or less frozen for the past 30+ because of the abomination that is C++
<dh`>
so it lacks a lot of things that have been invented or popularized since
<markh>
C is 53 years old
<ionutc>
a bunch of C replacements have popped up and they too are held back somewhat if they can't interop with C
<dh`>
there are no serious C replacements, really, or at least none that have gained significant attention
<dh`>
except maybe zig
<dh`>
rust is a C++ replacement
<dh`>
~everything else is unsuitable for the core domain, namely kernels and embedded code
<la_mettrie>
what makes rust unsuitable for them?
<dh`>
it is insane, like C++? you can write kernels in C++, you can write kernels in rust, but your life will be miserable :-)
wingsorc has quit [Quit: Leaving]
<dh`>
granted it's not _as_ insane as C++ and it does have certain advantages... but it really doesn't seem suitable as a general-purpose replacement for C
<la_mettrie>
what's the main reason for that?
<dh`>
what do you mean?
ionutc has quit [Quit: Leaving]
<dh`>
oh, also, re 53 years old, C reached its modern form in the years leading up to C89; K&R C was a much different language
<dh`>
and the things that make C look knobby are mostly its 40-year-old type system
<dh`>
(there are other things but you have to get fairly deep in to notice them)
coldfeet has quit [Quit: Lost terminal]
bsFFFFFF has joined #riscv
jjido has quit [Quit: My laptop has gone to sleep. ZZZzzz…]