<conchuod>
Revy[m]: Thanks. Is that really all we printed out back in 5.10? No uarch/mvendorid etc?
<Revy[m]>
5.10.4 vendor kernel only has these contents
<conchuod>
unfortunate, but thanks :0
bjoto has quit [Quit: WeeChat 4.0.5]
<conchuod>
Revy[m]: I wish they'd move to 6.6 for the c908
<Revy[m]>
canaan won't do it, they just want to come up with a complete solution in SDK.
<conchuod>
I meant thead, not really canaan. I don't expect the board vendor to do anyhting other than use what they were given.
<conchuod>
Do you know if they set that mae bit on the k230? Guo Ren told me that the mae stuff is optional on the c908 and that it also supports Svpbmt. I suspect that given the 5.10 vendor kernel it means that they do still use the non-standard stuff.
<Revy[m]>
As far as I know THead does not plan to produce the c908 chip itself.
<conchuod>
I'm a little surprised we've heard so little about the k230, given what the c908 supports.
<Tenkawa>
Well my plans today just completely got derailed so I guess I'll try some more testing today
<conchuod>
YangyuChen[m]: Also, I didn't ping you on that github issue because of lkml, I pinged you cos Revy[m] linked #48 here and I was not sure if you had maybe missed the PR.
<YangyuChen[m]>
I see. Revy told me that.
shamoe has joined #riscv
<conchuod>
I'll reply on the PR, I think you might misunderstood what I was saying - I was agreeing with your proposal re: maee
<conchuod>
YangyuChen[m]: I notice you dont have svpbmt in that isa string - are you using the maee stuff in that build?
<YangyuChen[m]>
conchuod: No. I just port some drivers from vendor kernel to the mainline and correct some dt bindings.
<conchuod>
I should really get myself a k230 if things seem to be messy, as they do appear to be.
<YangyuChen[m]>
The kernel uses svpbmt to work. However any device depends on DMA does not work now. I am not sure what is missing in the kernel.
<YangyuChen[m]>
I have usb and sdhci drivers ported, both needs dma to work. But now I can only see some error message on dmesg. So I'm not sure can k230 works without MAEE.
* felixonmars
has one but not sure how to play :P
<conchuod>
From just the info in that cpuinfo, I don't think you are actually using Svpbmt.
<YangyuChen[m]>
felixonmars uses vendor kernel
<conchuod>
It should show up there if detected (but you'll need to enable RISCV_ISA_SVPBMT to use it)
<YangyuChen[m]>
conchuod: How can I check that? I have kernel source on my pc and the k230 evb on my table now.
<felixonmars>
"<YangyuChen[m]> @felixonmars uses vendor..." <- yes, still waiting for your excellent work xD
<YangyuChen[m]>
➜ linux git:(k230-mainline) ✗ cat .config| grep RISCV_ISA_SVPBMT
<conchuod>
Looks like you got a bunch of peripherals running then. I might send a patch that can turn that erratum on via DT. I dont wanna have to keep adding stuff to that c file.
<YangyuChen[m]>
turn on erratum on via DT sounds like a good idea.
<conchuod>
It'd just be something as simple as xtheadcmo, that's what they call it in the thead docs, so alignment would be good.
<YangyuChen[m]>
If you did this I can help you to have the test on the k230_evb.
<conchuod>
I think I should be able to test it on a d1, but I'll CC you on it.
dramforever[m] has joined #riscv
<dramforever[m]>
huh, reading the manual it seems that the c908 has standard cmo?
<YangyuChen[m]>
let me try to disable thead cmo
<conchuod>
It would not surprise me if it had both dramforever[m]
<conchuod>
Did they produce a c908 manual in English? Last time I looked it was only in Chinese.
<dramforever[m]>
so probably dma-noncoherent but no xtheadcmo
<Revy[m]>
dramforever[m]: right, I'm still confused as to why use xtheadcmo
<conchuod>
You'd need to do s/xtheadcmo/zicbom/ though, you need something for it to work as by default there's CMOs
<dramforever[m]>
huh, the chinese manual doesn't explicit list the cbo instructions but has [ms]envcfg.CB* and mentions cbo instructions
<conchuod>
dramforever[m]: check out "1.4 Version compatibiliy"
<conchuod>
"• RISC-V Base Cache Management Operation ISA Extensions Version 1.0-rc2-2c97b28, 2021-11-05: Frozen"
<dramforever[m]>
there you go
<conchuod>
I think we just showed that the xtheadcmo stuff is there.
<YangyuChen[m]>
I tried mainline kernel to disable thead errata
<conchuod>
We could also undo the hack to the erratum and put "_zicbom" in riscv,isa and populate riscv,cbom-block-size for shits and giggles, and see if that works too
<conchuod>
Looks like you're still missing something. You need _zicbom in the isa string + riscv,cbom-block-size = <something> (that goes in the cpu node) before Zicbom will work.
<conchuod>
dramforever[m]: That English one is dated November 2023 - do you think it might previously have documented Zicbom but no longer does and they just forgot to remove it from section 1.4?
<YangyuChen[m]>
Can we patch a small enough cache block size to the kernel?
<YangyuChen[m]>
I think a small size will fit for most platforms but a more performance overhead since it needs to execute cmo insturction more times to clear the same cacheline
<conchuod>
You're supposed to put whatever is the block size for the hardware in question.
<conchuod>
I'd suggest that you use Zicbom if it is available, rather than xtheadcmo.
<YangyuChen[m]>
I agree.
<conchuod>
That's super interesting though. SoC supports both Svpbmt and MAEE and both the T-Head CMOs and Zicbom.
mlw has joined #riscv
billchenchina has joined #riscv
sajattack has quit [Read error: Connection reset by peer]
sajattack has joined #riscv
davidlt has quit [Ping timeout: 264 seconds]
junaid_ has joined #riscv
ezulian has joined #riscv
junaid_ has quit [Remote host closed the connection]
<courmisch>
conchuod: cpuinfo just echoes whatever the dts says
<courmisch>
conchuod: c908 has Zvfh and that's not showing in cpuinfo, FWIW
<conchuod>
courmisch: that's not quite true, its not a 1:1. linux adds things and refuses to show others depending on circumstance.
<conchuod>
I was mostly interested in m*id, not the enabled extensions ;)
ezulian has quit [Ping timeout: 260 seconds]
<drewfustini>
Esmil: what is the most recent pinctrl th1520 patch series? thanks
SpaceCoaster has quit [Quit: Bye]
<courmisch>
YangyuChen[m]: I don't even know how you get your hands on an EVB. I think everybody else has a CanMV variant
SpaceCoaster has joined #riscv
test924 has joined #riscv
hightower4 has joined #riscv
hightower3 has quit [Ping timeout: 252 seconds]
hightower4 has quit [Remote host closed the connection]
hightower3 has joined #riscv
ntwk has quit [Read error: Connection reset by peer]
<jrtc27>
sorear: yes
<jrtc27>
pointer to data member is an integer offset
<jrtc27>
pointer to function member is a pair
<jrtc27>
that's just looking at normal amd64
<sorear>
jrtc27: i am talking about > Recommendation for new platforms: consider using a different representation for data member pointers, such as left-shifting the offset by one and using a non-zero low bit to indicate a non-null value.
hightower4 has joined #riscv
hightower3 has quit [Ping timeout: 268 seconds]
Stat_headcrabed has joined #riscv
davidlt has joined #riscv
junaid_ has joined #riscv
vagrantc has joined #riscv
Stat_headcrabed has quit [Quit: Stat_headcrabed]
Narrat has joined #riscv
<dramforever[m]>
conchuod: still there? i have a Nov 2023 one and Feb 2024 one, both showing cbo.* existing
<dramforever[m]>
oh y'all already figured that out
<Tenkawa>
Since I'm back today afterall (due to unfortunate plans)...
<conchuod>
dramforever[m]: Does it go through the instructions for cbo, like it does for C, F, etc?
<Tenkawa>
Esmil: following up on our talk yesterday.. Is that Mars board in a state where I could combine all the patches together and run a kernel or do I need to wait?
<Tenkawa>
conchuod: chime in if you know if you don't mind.
<dramforever[m]>
conchuod: no but it has a line explicitly in appendix A saying for B, V, CMO see the standard specs
<dramforever[m]>
Note: For B extension, V extension and CMO extension, please refer to the corresponding RISC-V Spec
Stat_headcrabed has joined #riscv
Stat_headcrabed has quit [Client Quit]
<conchuod>
I didn't see something like that, but maybe I didn't look hard enough.
<dramforever[m]>
oh huh
<dramforever[m]>
it's only in the chinese version
<conchuod>
It'd be nice if they described their cpu as being something other than "rv64gbvc" since it does support other stuff too!
<conchuod>
Guo Ren told me previously that the c908 supports the whole rva2022 profile fwiw
<dramforever[m]>
shhh don't talk about the vector mmio thing
<conchuod>
rva2022 would mean they also support the other cbo stuff too
<conchuod>
Tenkawa: I think the mars board should boot mainline with the patches that Jisheng posted. If it doesn't, he shoulda tested his patches better!
crossdev has quit [Remote host closed the connection]
<palmer>
conchuod: IDK how well that's going to pan out in practice, a bunch of vendors were claiming rva22 before the specs were even finished. I bet we're going to have a bunch of stuff that claims to be compatible with a profile, but just isn't
<Tenkawa>
conchuod: just to be thorough (I'm overthorough) that will cover the base and CM right?
heat has quit [Remote host closed the connection]
heat has joined #riscv
<Tenkawa>
I have seen a few rare gotcha cases so I don't want to be caught off guard
<Tenkawa>
I have the CM
jmdaemon has joined #riscv
crossdev has joined #riscv
<unlord>
hi folks, is there any good documentation on the differences between VLA and VLS code with RVV?
<palmer>
unlord: I'm not quite sure what you're trying to ask. Documentation on what the compiler generates in the different modes, or some sort of best practices for writing assembly?
davidlt has quit [Ping timeout: 272 seconds]
<unlord>
palmer: that second one, or even just how to use those two terms when describing a piece of RVV assembly
<sorear>
vector mmio should be fixable in opensbi, it doesn't affect rva2022 since that doesn't include vectors
<dramforever[m]>
oh huh well that settles it
<sorear>
vector length agnostic (always write this), vector length specific (only appropriate for JITs or machine-specific firmware images)
<unlord>
For example, if I have code that works on all VLEN >= 128b does that make it VLA?
<sorear>
yes
<sorear>
a VLEN _lower_ bound is VLA with a dependency on ZvlNNNb, but "V" includes Zvl128b by definition
<palmer>
ya, it'd just require Zve128b (or whatever it's called, the one for minimum vlenb)
<palmer>
yep. Looks like we didn't get around to putting the Zvl extensions in hwprobe, though, so we probably should add them
<unlord>
palmer: Can't you just directly read vlen out of a csr?
<unlord>
csrr a0, vlenb
<palmer>
ya, I guess you need to turn V on? that's not so bad, though
<unlord>
I would only execute this after detecting V
<palmer>
makes sense
<palmer>
I guess it's just "turn on V" -> "check VLENB" -> "run"
<palmer>
vs "hwprobe Zvl" -> "turn on V" -> "run"
hightower3 has joined #riscv
<palmer>
so the same when the HW has the right V flavor, and presumably that's going to be true on everything you guys care about
<unlord>
is there something more needed to turn V on than checking getauxval(AT_HWCAP) & (1 << ('v' -'a'))
<palmer>
there's a prctl and sysctl, though IIRC we set the default to enabled (there's technically a uABI break from adding V, but the theory is nobody will notice it)
<unlord>
Alright, I'm probably OK for now
frkzoid has quit [Ping timeout: 268 seconds]
hightower4 has quit [Ping timeout: 260 seconds]
<sorear>
we should add all of the ratified extensions to hwprobe
<unlord>
so one thing I noticed writing VLA code for dav1d is that setting the right LMUL based on the current VLEN gets you better throughput when your vectors are not full
<sorear>
very possible
EchelonX has joined #riscv
<sorear>
especially the more decoupled implementations will have a hard time making a decision about how many registers to use based on vl
<unlord>
I don't understand "how many registers to use" ?
unnick has quit [Ping timeout: 260 seconds]
frkazoid333 has joined #riscv
KREYREN has joined #riscv
unnick has joined #riscv
<conchuod>
Tenkawa: I don't know the specifics of board versus CM. I just apply patches for that stuff and make general review comments, I don't know anyhting about the hardware other than what I google etc.
<conchuod>
palmer: I don't really care about the profile stuff tbh. People just can put the extensions they support into the dt and we can sort it out from there.
<palmer>
ya, that's basically my theory. I'm pretty much just considering the profiles to be marketing material
<unlord>
Doesn't that mean the OS is basically least common denominator?
<Tenkawa>
Ah. Well I'm putting it all together now so I'll know later..
<jrtc27>
profiles are (a) for marketing so in 2030 you don't have to decipher a 5000 character string to figure out what the hell the hardware you just bought is (b) RVI's attempt to signpost what vendors should be doing if they want to do sensible and useful things (ha)
<jrtc27>
and I guess (c) so developers don't have to type those 5000 character strings when setting their baseline to something sensible
<jrtc27>
c.f. x86-64-v<N>
<dramforever[m]>
oh yeah -march=rva22 would be quite nice
foton has quit [Remote host closed the connection]
pbsds has quit [Ping timeout: 264 seconds]
mlw has quit [Ping timeout: 260 seconds]
davidlt has joined #riscv
mlw has joined #riscv
pbsds has joined #riscv
davidlt has quit [Ping timeout: 264 seconds]
foton has joined #riscv
mahk has quit [Ping timeout: 264 seconds]
sevan has quit [Ping timeout: 255 seconds]
foton has quit [Remote host closed the connection]
foton has joined #riscv
test924 has quit [Quit: Client closed]
BootLayer has quit [Quit: Leaving]
unlord has quit [Changing host]
unlord has joined #riscv
ldevulder_ has joined #riscv
mahk has joined #riscv
ldevulder has quit [Ping timeout: 260 seconds]
vagrantc has quit [Ping timeout: 255 seconds]
Stat_headcrabed has joined #riscv
mahk has quit [Ping timeout: 260 seconds]
sevan has joined #riscv
sevan has quit [Changing host]
sevan has joined #riscv
Stat_headcrabed has quit [Quit: Stat_headcrabed]
vagrantc has joined #riscv
englishm has quit [Ping timeout: 252 seconds]
patersonc has quit [Ping timeout: 252 seconds]
englishm has joined #riscv
patersonc has joined #riscv
elms has quit [Ping timeout: 252 seconds]
elms has joined #riscv
test924 has joined #riscv
ntwk has joined #riscv
mahk has joined #riscv
vagrantc has quit [Ping timeout: 255 seconds]
mahk has quit [Ping timeout: 256 seconds]
jfsimon1981 has quit [Ping timeout: 260 seconds]
jfsimon1981 has joined #riscv
KREYREN_ has joined #riscv
ardb has quit [Ping timeout: 252 seconds]
KREYREN has quit [Remote host closed the connection]
palmer has quit [Ping timeout: 252 seconds]
puranjaymohan has quit [Ping timeout: 252 seconds]
ardb has joined #riscv
arnd has quit [Ping timeout: 252 seconds]
vagrantc has joined #riscv
puranjaymohan has joined #riscv
palmer has joined #riscv
arnd has joined #riscv
junaid_ has quit [Remote host closed the connection]
mobius has quit [Ping timeout: 252 seconds]
drewfustini has quit [Ping timeout: 252 seconds]
drewfustini has joined #riscv
mobius has joined #riscv
mithro has quit [Ping timeout: 252 seconds]
SanchayanMaity has quit [Ping timeout: 252 seconds]
mlw has quit [Ping timeout: 264 seconds]
khilman has quit [Ping timeout: 252 seconds]
mithro has joined #riscv
mahk has joined #riscv
SanchayanMaity has joined #riscv
khilman has joined #riscv
mahk has quit [Ping timeout: 264 seconds]
jfsimon1981 has quit [Remote host closed the connection]
danilogondolfo has quit [Remote host closed the connection]