sorear[m] changed the topic of #riscv to: Matrix users: #riscv:libera.chat will be ending operation NET Jul 25; please test #riscv:catircservices.org as a replacement | RISC-V instruction set architecture | https://riscv.org | Logs: https://libera.irclog.whitequark.org/riscv
jedix has quit [Ping timeout: 245 seconds]
jedix has joined #riscv
joev1 has quit [Ping timeout: 250 seconds]
joev1 has joined #riscv
Tenkawa has quit [Quit: Was I really ever here?]
vagrantc has quit [Quit: leaving]
wingsorc has quit [Quit: Leaving]
unsigned has joined #riscv
handsome_feng has joined #riscv
jacklsw has joined #riscv
heat_ has quit [Ping timeout: 272 seconds]
EchelonX has quit [Quit: Leaving]
BootLayer has joined #riscv
crabbedhaloablut has joined #riscv
MarvelousWololo has joined #riscv
peeps[zen] has quit [Read error: Connection reset by peer]
peepsalot has joined #riscv
clemens3 has quit [Ping timeout: 245 seconds]
BootLayer has quit [Quit: Leaving]
aerkiaga has quit [Remote host closed the connection]
stolen has joined #riscv
clemens3 has joined #riscv
freakazoid332 has joined #riscv
frkzoid has quit [Ping timeout: 246 seconds]
indy has left #riscv [Leaving]
elastic_dog has quit [Ping timeout: 240 seconds]
elastic_dog has joined #riscv
JanC has quit [Ping timeout: 260 seconds]
JanC has joined #riscv
ldevulder has quit [Quit: Leaving]
ldevulder has joined #riscv
crabbedhaloablut has quit [Ping timeout: 260 seconds]
BootLayer has joined #riscv
crabbedhaloablut has joined #riscv
MarvelousWololo has quit [Read error: Connection reset by peer]
Stat_headcrabed has joined #riscv
JanC has quit [Ping timeout: 260 seconds]
Stat_headcrabed has quit [Quit: Stat_headcrabed]
danilogondolfo has joined #riscv
stolen has quit [Quit: Connection closed for inactivity]
josuah has quit [Remote host closed the connection]
josuah has joined #riscv
JanC has quit [Ping timeout: 246 seconds]
JanC has joined #riscv
JanC_ has joined #riscv
JanC is now known as Guest1579
Guest1579 has quit [Killed (cadmium.libera.chat (Nickname regained by services))]
JanC_ is now known as JanC
billchenchina has quit [Quit: Leaving]
handsome_feng has quit [Quit: Connection closed for inactivity]
meta-coder has joined #riscv
ssb has quit [Ping timeout: 240 seconds]
ssb has joined #riscv
Danidada has joined #riscv
JanC_ has joined #riscv
JanC has quit [Killed (erbium.libera.chat (Nickname regained by services))]
JanC_ is now known as JanC
heat_ has joined #riscv
awita has quit [Ping timeout: 245 seconds]
Stat_headcrabed has joined #riscv
aerkiaga has joined #riscv
motherfsck has quit [Read error: Connection reset by peer]
jacklsw has joined #riscv
handsome_feng has joined #riscv
Tenkawa has joined #riscv
JanC has quit [Ping timeout: 246 seconds]
aburgess has quit [Ping timeout: 246 seconds]
Karel has joined #riscv
Stat_headcrabed has quit [Quit: Stat_headcrabed]
<Karel>
Hey! I'm working on a toy riscv emulator for fun and to learn things. I've got the basic usermode ISA working, but I'm a bit lost on how expand from there all the way until I can run a barebone linux intall.
<Karel>
In particular, how do I add support for peripherals and their drivers? I assume IO is always going to be memory mapped? How do I figure out at which address they should be located and what their APIs are? Similary, how does the bootup process work?
<Karel>
More globally, am I overthinking this? Should I just be able to drop a random linux binary into my emulator? At _some_ point is has to iteract with the outside world through!
<Karel>
I searched online but I feel like I'm missing some steps between "toy emulator" and "full qemu"!
vagrantc has joined #riscv
JanC has joined #riscv
<gurki>
you might be interested in the concept of the spike proxykernel
<conchuod>
You should be able to drop a kernel binary in, and it'll run through some of the initial assembly, before falling over likely when it discovers you have no devicetree
<Karel>
gurki, The spike proxykernel looks interesting indeed, it seems like that would quickly let me run slightly more complex applications already!
<Karel>
conchuod, "devicetree" seems like the right keyword to continue searching, thanks.
<conchuod>
devicetree is also how you communicate the locations of peripherals and what they are to your os kernel
heat_ has quit [Remote host closed the connection]
<Karel>
Yeah, exactly what I was looking for!
heat_ has joined #riscv
<Karel>
How does that work in practise? Is there some auxiliary ROM thing that copies some hardcoded device tree into main memory on boot?
<conchuod>
You pass a the address of the dt in a1
<conchuod>
In a real system, the previous boot stage will sort that out.
MarvelousWololo has joined #riscv
<Karel>
That's pretty cool. Is there some list of what the proper state of the registers, PC and maybe other stuff should be when starting the linux boot process?
<courmisch>
that should in the Linux kernel documentation directory
<conchuod>
courmisch: Just hasn't made it there yet..
<conchuod>
palmer: infradead seems to be down? Could you ping atish and see if he knows anything?
<palmer>
conchuod: it's down from here too
<palmer>
I poked him on Slack, looks like he's not here
<courmisch>
infrastructure dead and wearing its name proudly
<palmer>
;)
<Karel>
conchuod, Great, thanks! Better than getting lost in the linux source code.
<palmer>
I assume the lists are down too, not just the web UI? that's the only way I'd notice...
<conchuod>
Yeah, the lists are dead too
<conchuod>
I don't go on the web, thats how I noticed.
<palmer>
yep, I don't either
junaid_ has joined #riscv
jacklsw has quit [Ping timeout: 260 seconds]
awita has joined #riscv
___nick___ has joined #riscv
sakman has quit [Read error: Connection reset by peer]
<Karel>
Although I'm curious, where in the linux source does it read those registers? I assume "arch/riscv/boot", but loader.S just includes "arch/riscv/boot/Image" which I doesn't seem to exist.
unsigned has quit [Quit: .]
<Karel>
I'm also curious why a0 needs to contain the hartid, can't the kernel just read that from the right CSR register?
<conchuod>
Karel: I'm not sure where all of the fiddling with the dt is, but certainly in head.S you can see it call setup_vm() with the dtb's address
<conchuod>
s/all of the fiddling/all of the pre-c fiddling/
<conchuod>
Depending on what kernel you have checked out, the line number may obviously differ, but it is at L300 or so for me.
<Karel>
conchuod, That looks like the right place, I'll have a look through it!
<palmer>
the hartid CSR is M-mode only
meta-coder has quit [Quit: leaving]
handsome_feng has quit [Quit: Connection closed for inactivity]
awita has quit [Remote host closed the connection]
<palmer>
looks like infradead should be back soon
<courmisch>
time to equip holy water to fight the undead
aburgess has joined #riscv
<Karel>
palmer, Huh, so is there literally no other way to get the hartid in U-mode than getting it as an input at the start and then making sure to remember it forever? That's interesting.
<palmer>
u-mode doesn't usually see hartid at all, it's just in s-mode (Linux CPU IDs are virtualized)
<heat_>
Karel, this is a very handwavy statement but IIRC you can also indirectly get it through the device tree
<Karel>
Ah right they have to be virtualized at some point, so it's good that the real hartid is hidden.
<Karel>
It seems like people put some thought into all of this!
<Karel>
heat_, Isn't the device tree the same for each core?
danilogondolfo has quit [Remote host closed the connection]
aerkiaga has quit [Remote host closed the connection]
jmdaemon has joined #riscv
<sorear>
it would still probably be better to read “mhartid” and have the VMM return the correct virtual hart IDs in the illegal instruction handler
EchelonX has joined #riscv
heat_ has quit [Read error: Connection reset by peer]
heat_ has joined #riscv
zBeeble42 is now known as zBeeble
JanC_ has joined #riscv
JanC has quit [Killed (mercury.libera.chat (Nickname regained by services))]
JanC_ is now known as JanC
aerkiaga has joined #riscv
___nick___ has quit [Ping timeout: 258 seconds]
BootLayer has quit [Quit: Leaving]
Danidada has quit [Quit: Leaving]
<palmer>
ya, we're super inconsistent about what is emulated via an instruction and what is an SBI call
JanC has quit [Remote host closed the connection]
JanC has joined #riscv
junaid_ has quit [Remote host closed the connection]
JanC has quit [Ping timeout: 245 seconds]
Andre_Z has quit [Quit: Leaving.]
JanC has joined #riscv
ntwk has quit [Quit: ntwk]
<conchuod>
Karel: the reg entry in the cpu nodes has the hartid
<Karel>
How does that work then? Is there a full copy of the device tree for each core except that the hartid is different? That seems wasteful.
<conchuod>
Tis so, each cpu node is repeated, even where the only difference is the reg property.
<conchuod>
The whole DT is not repeated, just the cpu node.
heat_ has quit [Remote host closed the connection]
heat_ has joined #riscv
<Karel>
Interesting!
<heat_>
actually i was wrong, there doesn't seem to be any way to check the boot hart
<heat_>
i was misremembering some sort of riscv boot hart property in chosen {
<heat_>
and AFAIK you're not ever guaranteed to be cpu0
<Tenkawa>
heat_: Here's the way they describe it that I think says it best
<Tenkawa>
RISC-V systems boot harts in an arbitrary order and at arbitrary times, while Linux expects a single hart to boot first and then wake up all other harts. We handle this with the "hart lottery," which is a very short AMO-based sequence that picks the first hart to boot.
<Tenkawa>
its a random lottery in hardware that gets assigned so the OS has something to grab on to
<Tenkawa>
It can be any of the harts
<heat_>
right
<heat_>
it's common on !x86 I think, i myself had noticed it a bunch when getting booted by OpenSBI
<Tenkawa>
Which in a way can be a bit tedious....
<heat_>
I don't know if this changes with UEFI though.
<gurki>
Tenkawa: what made people do that?
<gurki>
im curious
<Tenkawa>
gurki: not sure... I've been wondering that myself
heat_ has quit [Remote host closed the connection]
<muurkha>
it doesn't seem like the worst possible solution, and I guess in hardwareland there is always a certain irreducible nondeterminism
<gurki>
"your cores are numbered differently" is way beyond "certain irreducible nondeterminism"
<gurki>
ppl arent stupid, they must have had a "proper" reason, hence my initial question :)
<muurkha>
yeah, I got interrupted by my wife
<muurkha>
I was trying to say that this seems like a case of amplifying the nondeterminism far beyond the minimum necessary
<muurkha>
I don't share your conviction that people aren't stupid, and I think it's entirely possible they decided it was good enough to ship
<Tenkawa>
I have definitely dealt with oddities (many back in my career.. I spent years in Cobol, Assembly and X.25 so you can just imagine right?)
<muurkha>
I like assembly, but condolences on the others
<Tenkawa>
haahaa
<muurkha>
C keeps getting worse
<Tenkawa>
indeed
<muurkha>
not RVC, the language
<Tenkawa>
yeah I know what you meant
<muurkha>
nice thing about assembly is that there's very rarely UB
<gurki>
i had to write machine code for a while. that made me rethink some decisions i made in my life.
<whitequark[cis]>
like, raw machine code?
<whitequark[cis]>
not even with mnemonics
<gurki>
yes. we had some ... awkward architecture.
<whitequark[cis]>
* with mnemonics?
<whitequark[cis]>
ohhhh, like that
<gurki>
also made my brain explode, i wont ever do this again unless i get $$$$$$$
<whitequark[cis]>
I've done that but only voluntarily for architectures I designed
<Tenkawa>
gurki: heheh I was doing it too... I wrote a database to game connectot though in it for fun....
<Tenkawa>
er connector
<Tenkawa>
We wanted persistent data storage from the game environment
<Tenkawa>
Would have been nice to have ARM/RISC-V back then.... we were still doing this on X86 assembly....
<gurki>
x86 is surprisingly acceptable once youve gotten used to it imho
<gurki>
asm*
<Tenkawa>
gurki: x86 is way heavy for our needs though
<gurki>
wait 20 years, riscv will look similar
<gurki>
its already showing for arm
<Tenkawa>
good point
<muurkha>
whitequark[cis]: I've done only a small amount of it, and also mostly for architectures I designed
<muurkha>
i386 assembly is very comfortable, 8086 somewhat less so
<Tenkawa>
I'm just happy that both my boxes are working correctly now and I can continue "forward"
<muurkha>
ARM assembly is the nicest I've found so far
<gurki>
Tenkawa: well thats always nice :3
<muurkha>
though I do prefer RISC-V/MIPS conditional branches over the ARM version
<Tenkawa>
gurki: yeah the VisionFive 2 was easy... the Star64 not so much
<Tenkawa>
but now its finally booting SPI/NVMe
<muurkha>
yay!
<muurkha>
congratulations!
<Tenkawa>
thanks...
<Tenkawa>
next on the task list... kernel on the Star64... its still at 5.15
<gurki>
oh god a pine board
<Tenkawa>
indeed
<gurki>
so essentially "let the community fix it" :-\
<Tenkawa>
heh now you see the "pain" lol
<Tenkawa>
yep
<gurki>
indeed.
<Tenkawa>
need to track down a high cpu load issue too (something is spinning)
<Tenkawa>
both units are doing it consistently
<Tenkawa>
I "think" its actually the gpu
<muurkha>
I'm always amused when someone uses scare quotes in that way
<muurkha>
it's almost as if you're thinking, but not quite? ;)
<muurkha>
it's a process that someone might describe as thinking, but you aren't sure you agree?
<Tenkawa>
muurkha: in my case I'm not sure if I'm actually thinking or its being projected in my head lol
<Tenkawa>
Some days I just let random past occurences come back to see if they might work as a test
<Tenkawa>
Sometimes a fix happens
<conchuod>
heat_: starfive have some property in /chosen to do with opensbi I think, but its generally invalid.
<conchuod>
Tenkawa: you mention "hart lottery", but using HSM is the preferred mechanism, at least for Linux.
<Tenkawa>
conchuod: I just posted what was on the architecture page
<conchuod>
What architecture page?
<Tenkawa>
I would have to go find it again..
<Tenkawa>
I was just google searching when I found it
<conchuod>
I mean, was in sme kernel.org thing, RVI github etc