Trifton has quit [Remote host closed the connection]
Trifton has joined #riscv
Leopold has joined #riscv
vagrantc has joined #riscv
jmdaemon has joined #riscv
m5zs7k has quit [Ping timeout: 268 seconds]
m5zs7k has joined #riscv
m5zs7k has quit [Ping timeout: 252 seconds]
m5zs7k has joined #riscv
vagrantc has quit [Quit: leaving]
BootLayer has joined #riscv
Leopold has quit [Ping timeout: 255 seconds]
rurtty has joined #riscv
bauruine has joined #riscv
Leopold has joined #riscv
<geist>
question i'm trying to figure out and can't seem to find a solid answer to: is there a way/how can a supervisor mode kernel determine the privileged spec the cpu implements?
<geist>
possible it has to just know from marchid, mimpl, and of course the ISA extensions the cpu supports is specified in the device tree/acpi/etc
<geist>
but even machine mode isn't really told what version of the privileged spec is implemented
<geist>
hmm, opensbi seems to 'know'. lemme see how it finds out
<palmer>
ya, pretty much: there's a bunch of out-of-band mechanisms that all end up as "ask the firmware", but there's nothing in the ISA spec that allows you to determine this
<geist>
and in this case the firmware doesn't even pass it down. i dont see it passed in the DTC from opensbi on qemu, for example
<palmer>
for Linux we generally probe for specific features, not the whole version
<geist>
so a question is if a kernel is intended to detect that it's dealing with something that is running on a v1.10 vs a v1.12 (ie, a xuantie C910 vs a sifive core) it's a bit difficult, aside from knowing
<geist>
so stuff like the *configptr register could just try to read and observe it failing i guess
<palmer>
yep
<geist>
lovely.
<palmer>
it gets trickier because M-mode can pretty much always trap, and there's no requirements those are handled below Linux
<geist>
yeah
<palmer>
in general RISC-V allows any state transition, so you really just need to pick a set of implementations and target those
<geist>
and i guess rely on march/mimpl for stuff where you just Have To Know
<geist>
ie all the bazillino extensions xuantie has
<palmer>
except that you can't actually look at march/mimpl/mvendor from S-mode (and even M-mode, as some vendors just set it to 0). So you're still just asking the firmware to tell you what's up, just in a different way
<geist>
yeah
<geist>
still trying to figure out how opensbi seems to know, but i suspect i'm going to eventually arrive at 'its hard coded'
<palmer>
I guess it depends on exactly what knowledge you're poking at, but it's mostly just stuck in the platform bits
<geist>
mostly just would like to know if certain features are present before trying to touch them, doubleplus so if sbi is just going to emulate it for me
<geist>
which i'd honestly rather it not, so i can do a better implementation
<geist>
but yeah, i suspect it's not as big of a problem as i think, since the features are generally what drive this stuff
<jrtc27>
versioning it was a mistake
<jrtc27>
should just be extensions
<geist>
like, for example, senvcfg seems to only show up in v1.12
vimer has quit [Quit: leaving]
<geist>
OTOH so far all the bits in it seems to be part of specific extensions, which i guess you can test for first
<geist>
and stuff like Svnapot/etc are all extensions too. so that's testable
<palmer>
in general there's both: some behavior is controlled by versions, some by extensions (and sometimes that changes)
<palmer>
in practice you just need to enumerate the implemenations you're running on, the specs don't get you compatibility
<geist>
yah, i suspect it's the usual tree of logic to deal with what you know
<palmer>
yep
<geist>
given that opensbi seems to know what version it is it *would* be nice if it'd just pass it down somehow
<geist>
but probably Good Reason to not make that load bearing
<geist>
or at least a reason
<palmer>
the problem is that you can't always trust the information from firmware, as sometimes correctly implementing some bit requires cooperation with firmware and that falls apart when there's a bug
<palmer>
so you sort of just need some ad-hoc mechanism
<geist>
yah it's the inevitable outcome of not wanting to have piles of fixed registers that just describe everything, a-la x86 and armv8
<geist>
seems that collectively riscv hasn't quite decided which way it wants to go here
<palmer>
even Arm and Intel devolve into a pile of quirks, but that's not an excuse for not even bothering to try ;)
<geist>
yah 100%
<palmer>
;)
<geist>
anyway, fun times.
<geist>
thanks, even a bad answer is still an answer
<palmer>
sorry I don't have a good answer ;)
<palmer>
we've managed to hide most of the issues from userspace so far, but once you get below that stuff is pretty broken
<geist>
yep. OTOH i guess it's no where near the nonsense that is x86. but still got 35 more years to get to that level
<palmer>
it's just different
<geist>
and though i havent checked, i *assume* the general model is that gcc and clang and oter toolchains will allow access to all of the privileged mode registers, since there's no `-mpspec=N` args or whatnot
<geist>
and thus allow the kernel code to deal with its own compatibility
<geist>
i dont see it mentioned in the C api doc
<palmer>
it's more complicated than that, but the assemblers allow CSR accesses via a numeric index and we just use that in Linux
<palmer>
we tried actually following the ISA specs for a bit, but just gave up as it's not worth the headache
<geist>
yah i expect that's the case, but for cases where the assemblers know about a particular CSR it shouldn't gate it based on the pspec it thinks its compling for, since it doesn't know
<geist>
yah, i remember grousing here a few years ago about how you can't emit floating instructions if you're not compiling with a corresponding -march for it, and i think i ended up just resorting to using a bunch of .word sequences to save the FPU context in kernel mode
<geist>
oh no i moved it to .S and set the `.attribute arch` which was acceptable
<palmer>
ya, there's better ways to do the FP stuff. That's not really an ISA spec problem, though, as that code is really trying to violate the spec
<geist>
makes sense though: new arch, try to be strict about things to keep it under control
<palmer>
yep. At least for those we'd seen the Arm/MIPS mess and knew what to do
<palmer>
there's some other stuff like fence.i and timers where we screwed up
<geist>
yah i'm already dreading having to deal with xuantie + sifive cores at the same time, since they are going in different directions
<palmer>
it's going to get way worse
<geist>
indeed. as it's pointed out at the start of the privileged spec: it's separate from unpriv for a reason, you can build a completely different implementation. curious when the first major implementation that does go in a different direction shows up
jim-wilson[m] has quit [Quit: You have been kicked for being idle]
<jrtc27>
you have fw_foo.S -> fw_foo.o and fw_foo.elf
<drmpeg>
I don't think make clean works.
<drmpeg>
Try deleting the build directory.
<drmpeg>
or re-clone.
<drmpeg>
It builds fine here.
jmdaemon has joined #riscv
<bjdooks>
yeah, make clean doesn't clean it either
<rneese>
if one of you has a unmatched that can boot and get a printenv and post it later let me know
<rneese>
thanks ahead of time
<drewfustini>
Whose coming to fosdem?
<drewfustini>
I get in on Thursday afternoon. I think RISC-V isn't until Sunday so it would be fun if anyone wants to meetup sometime on Friday or Saturday.
<bjdooks>
drewfustini: i'll be there friday afternoon
<bjdooks>
I just printed my plane tickets
<another|>
printing! I knew I forgot something
<drewfustini>
Cool. I'll ping you
<rneese>
?
<rneese>
what am I missing
<rneese>
Hey Drew
<drewfustini>
Fosdem is in Brussels this weekend and there is RISC-V devroom with presentations
<bjoto>
Oh, I'll be there as well (->Fri ~20.00, <-Sun ~20.00)
<drewfustini>
Great!
<rneese>
will it be avaible online ? I want to hear and see the riscv part
<drewfustini>
I think it will all be streamed live
<drewfustini>
I will drop a link when I see it
<rneese>
ok
<drewfustini>
It's not convenient for the Americas to get there physically but the neat thing is the conference is free of cost for attendees. It's hosted at a university
<rneese>
ahh ok
<bjdooks>
that reminds me to check if EOSS is open yet
<rneese>
yeah <. poor american dev
<drewfustini>
The downside is that it would get pretty crowded but it is nice that there is no financial barrier
<rneese>
I just wish my vf2 would get here and the unmatched
<drewfustini>
CFP is open for EOSS
<drewfustini>
(Embedded Open Source Summit in Prague in June)
prabhakarlad has joined #riscv
BootLayer has quit [Quit: Leaving]
jmdaemon has quit [Ping timeout: 260 seconds]
billchenchina has quit [Quit: Leaving]
billchenchina has joined #riscv
motherfsck has joined #riscv
Stat_headcrabed has joined #riscv
Stat_headcrabed has quit [Client Quit]
Forty-Bot has quit [Ping timeout: 268 seconds]
jones-drew has joined #riscv
jones-drew is now known as drewj
pedja has joined #riscv
<drewj>
Looks like libera.chat's irc webui is pretty good, so I've opened another tab (next to the slack tab I already have). Hopefully if/when you ping, I'll see it!
<rneese>
slack
<rneese>
is riscv on slax=ck
<rneese>
or just other channels
<rneese>
I do wish you all would join the discord if your on slack
<jedix>
I'm more of a lerker than an active contributor anyways. I just make nommu worse from time to time
Marco has joined #riscv
<muurkha>
heh
<bjdooks>
jrtc27: thanks
<Marco>
Hi, while checking the kernel Kconfig I stumbled above the KBUILD_CFLAG/AFLAG handling. Is there a reason for not having the "fd" extension within the cflags?
<Marco>
By Kconfig I mean the Makefile ^^
<conchuod>
drewj: I've been doing my head in looking for this dependancy detection code. Maybe it isn't in b4 after all, and is somewhere else, but I'll find it
<conchuod>
Marco: from the commit that added that line:"Note that the CFLAGS should not contain "fd" before we have mechnisms like kernel_fpu_begin/end in other architectures."
<Marco>
conchuod: That was to easy, just followed the diff.. Thanks a lot.
<conchuod>
I was thinking of something simple like the "relaxed" thing there that pulls a message-id, and shouldn't be too hard to cram in a `b4 shazam` type call
<conchuod>
Alternatively, make it be depends on: <patchwork series link> and I can just do call "git pw series apply" on that
<drewj>
conchuod: yeah, starting with patchwork links would probably be easiest and then it should be possible to add a message-id -> patchwork series helper too in order to give more flexibility
<bjdooks>
could patchwork auto aplly a series to a branch and push it somewhere?
<conchuod>
Not as things are, but I figure you can hack it to do something like that
<conchuod>
Not really sure what the benefit of that is though
<drewj>
conchuod: need to make sure that patchwork links that point to older versions are still valid though. If a new version supersedes and old version, then CI may still fail to apply the patches
<conchuod>
Which of course b4 & a message-id would handle more neatly than
<conchuod>
patchwork *message* links, lore links and message-ids would all be valid then
drewj has quit [Quit: Client closed]
<conchuod>
drewj: I have an idea of how this would be done, but will probably be the other side of the bank holiday weekend that I actually anything about it
EchelonX has quit [Quit: Leaving]
<conchuod>
actually do anything*
vgtw has joined #riscv
enoq has quit [Quit: enoq]
<rneese>
ok ummatched people
<rneese>
do most of you put the uboot in spi or on the sd card