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
jmd_ has quit [Ping timeout: 252 seconds]
Tenkawa has quit [Ping timeout: 246 seconds]
Esmil has quit [Ping timeout: 246 seconds]
mps has quit [Ping timeout: 246 seconds]
mps has joined #riscv
Esmil has joined #riscv
Tenkawa has joined #riscv
unsigned has quit [Quit: .]
unsigned has joined #riscv
vagrantc has quit [Ping timeout: 240 seconds]
jmdaemon has joined #riscv
jacklsw has joined #riscv
Tenkawa has quit [Quit: Was I really ever here?]
esv has quit [Remote host closed the connection]
esv has joined #riscv
MarvelousWololo has joined #riscv
EchelonX has quit [Quit: Leaving]
<muurkha>
whitequark[cis]: I really appreciate your work for so many reasons
<muurkha>
the bridge is one, whitelogger is another
<whitequark[cis]>
ah yeah. I was thinking of giving the logger an upgrade sometime soonish
<whitequark[cis]>
it's an extraordinarily dated codebase that i wrote in like... 2010? in about three days while heartbroken in a cafe and which has survived essentially unmodified since
<whitequark[cis]>
it has many moving parts and most of them are bad. also you should see the database schema :<
<muurkha>
<3
<whitequark[cis]>
most importantly though it really need to run on something that's not my *personal infrastructure(
<whitequark[cis]>
s/*/\*/, s/(/*/
<muurkha>
invalid regexp
<whitequark[cis]>
the matrix bridge is trying to be clever
<whitequark[cis]>
it is bad at many things, but especially being clever
<muurkha>
me too
<whitequark[cis]>
(logger) the databases grew to be gigabyte-sized, the logger itself can cause considerable strain on resources sometimes including when a single search query can bring down the entire logger frontend
<whitequark[cis]>
i don't have alerting for that except for "someone on twitter asks"
<whitequark[cis]>
it did serve fantastically considering how much resources it required and for how long it exists essentially uninterrupted
<muurkha>
heh
<whitequark[cis]>
easily one of my highest leverage projects
BootLayer has joined #riscv
unsigned has quit [Ping timeout: 245 seconds]
Trifton2 has joined #riscv
Trifton_ has quit [Ping timeout: 245 seconds]
troglodito has quit [Ping timeout: 252 seconds]
troglodito has joined #riscv
vagrantc has joined #riscv
Armand has quit [Quit: Leaving]
bauruine has joined #riscv
unsigned has joined #riscv
pecastro has joined #riscv
MarvelousWololo has quit [Read error: Connection reset by peer]
flip214 has joined #riscv
<flip214>
Hi. Is there a list of companies selling (modern) Risc-V servers (ie. at least 64 cores) in Europe? Google doesn't help.
vagrantc has quit [Quit: leaving]
<davidlt[m]>
flip214: no, such don't exist yet.
<davidlt[m]>
We don't even have finalized standards for the server platform.
<davidlt[m]>
Every existing board (Single Board Computer) pretty much requires a custom solution.
<davidlt[m]>
sorear: so it sounds that this will split into separate Matrix and IRC channels.
<davidlt[m]>
I do use Matrix these days for all IRC activities as I got tired of running IRC bouncer, but I do sometimes come back with plain old IRC client.
<davidlt[m]>
Just not as often thus cannot read up the chat history.
<davidlt[m]>
I wonder how hard is to run a personal bridge...
<whitequark[cis]>
davidlt[m]: there is a replacement bridge already
<sorear>
the only company I've seen an announcement for 64-core linux-capable risc-v machines from is milk-v's pioneer board using the SG2042 (no mainline support yet but it's the same core as the LP4A which people are working on)
<whitequark[cis]>
(see topic)
<davidlt[m]>
Ah, I see. Thanks whitequark[cis]
<flip214>
davidlt[m]: sorear: thanks!
<sorear>
this is of course nowhere near compliant with anything proposed for the server platform / RVA23 / BRS-I / etc but it is literally possible to serve things on it
<sorear>
i don't have one but expect it to be closer to a ThunderX2 than a Threadripper
<sorear>
(octeon?)
danilogondolfo has joined #riscv
<\dev\ice>
5
billchenchina has joined #riscv
jacklsw has quit [Ping timeout: 246 seconds]
<Esmil>
sorear: (*same core family. C910 vs C920 in the SG2042)
<gurki>
why is literally every interesting part not compliant in one way or another ^^
elastic_dog has quit [Quit: elastic_dog]
elastic_dog has joined #riscv
awita has joined #riscv
jacklsw has joined #riscv
wingsorc has quit [Ping timeout: 246 seconds]
bauruine has quit [Ping timeout: 260 seconds]
bauruine has joined #riscv
esv has quit [Ping timeout: 246 seconds]
elastic_dog has quit [Ping timeout: 246 seconds]
elastic_dog has joined #riscv
elastic_dog has quit [Quit: elastic_dog]
elastic_dog has joined #riscv
jacklsw has quit [Ping timeout: 245 seconds]
Tenkawa has joined #riscv
aerkiaga has joined #riscv
aerkiaga has quit [Remote host closed the connection]
billchenchina- has joined #riscv
billchenchina has quit [Ping timeout: 245 seconds]
billchenchina- has quit [Remote host closed the connection]
bauruine has quit [Remote host closed the connection]
Andre_Z has joined #riscv
esv has joined #riscv
awita has quit [Remote host closed the connection]
<conchuod>
C908 having 1.0 was something I had read, I just did not think any SoC actually has that
matoro has joined #riscv
<conchuod>
drewfustini: it's the lack of the "errata" for the page table bits etc that surprises me
<drewfustini>
:)
<drewfustini>
No more alternatives
<sorear>
eh
<sorear>
Svpbmt is almost exactly the same as XMAE, and both of them have M-mode enable bitflags, so supporting both depending on which of the flags is set is easy
<sorear>
if anything I'm more surprised by V 1.0, since (a) that's a hard compat break for all of the V 0.7.1 software they've shipped to customers (b) several features get changed in ways that could have cross-cutting effects on the vector datapath
MarvelousWololo has joined #riscv
<conchuod>
It is not _exactly_ the same, and as Guo knows, the errata handling uses those archid/impid numbers
<conchuod>
However, on a second reading, I do see XMAE and Svpbmt in the xrvm link, so I'm not sure what to believe now.
<conchuod>
Is it going to support both?
<conchuod>
I didn't expect to see a change there, since that doesn't prevent running a common userspace etc, which obviously the vector stuff does.
<sorear>
I don't see any reason it couldn't support Svpbmt if menvcfg.PBMTE=1 and XMAE if mxstatus.MAEE=1
<sorear>
just needs a handful more gates in the PTE decoder to handle both representations
<conchuod>
It seems like a nice thing to do for compat w/ their existing sw stacks
<sorear>
they represent the same conceptual data using bits from the same source, it's far less invasive than V 1.0's changes to vector load/store handling etc
<conchuod>
I wonder how OS kernels will deal with the differentiation. I'm a bit ignorant on this front, but it can't be probed for, right?
<conchuod>
Which I guess means get m-mode to put xtheadxmae in your DT/ACPI tables if in that mode
<sorear>
maybe there'll be a SBI call to enable PBMTE and the definition of svpbmt in the kernel will be changed to "call the SBI if available, then you can use it"
<sorear>
something similar will have to be done for Svadu because for some reason they decided to make "Svadu functionality is disabled" a hard requirement in RVA20 (despite being allowed by the ratified priv spec, default behavior in qemu, and supported by every kernel), so Svadu in RVA23 has to be off at kernel entry for compatibility
jacklsw has joined #riscv
terminalpusher has joined #riscv
<conchuod>
I'd rather not have to have SBI calls if it can be determined without requiring updates to firmware
iooi has quit [Read error: Connection reset by peer]
iooi has joined #riscv
<conchuod>
Whatever the vendors ship probably won't have them & it'd have to be retrofited when someone has a problem
terminalpusher has quit [Remote host closed the connection]
jmdaemon has joined #riscv
pabs3 has quit [Ping timeout: 260 seconds]
iooi has quit [Read error: Connection reset by peer]
iooi has joined #riscv
pabs3 has joined #riscv
vagrantc has joined #riscv
vagrantc has quit [Ping timeout: 246 seconds]
danilogondolfo has quit [Remote host closed the connection]
jacklsw has quit [Ping timeout: 245 seconds]
Stat_headcrabed has joined #riscv
<Stat_headcrabed>
conchuod: K230 is using c908
<Stat_headcrabed>
I think I already said about this here
<conchuod>
I know, but that's whatever if noone has one.
<Stat_headcrabed>
Seems some developers already got that
<Stat_headcrabed>
But maybe only in China
<conchuod>
If only people at the relevant vendors have it, then I don't really care.
<Stat_headcrabed>
I remember that guy is not from vendors but PLCT
<Stat_headcrabed>
(Maybe I am wrong)
<conchuod>
I have no idea either :)
<Stat_headcrabed>
Hope that means we could see k230 publicly available soon
<conchuod>
I've been trying to get info from Guo.
<Stat_headcrabed>
But only one of 2cores has vector support
<conchuod>
Pretty much, I don't really care about disturbing internal engineering sample stuff, only what gets shipped?
<conchuod>
But I think it is all kinda moot now anyway, since it doesn't use zero archid/impid anymore :)
<Stat_headcrabed>
🤔
<courmisch>
Stat_headcrabed: seems it's only "EVB" boards, so not surprising if you can't buy them
<Stat_headcrabed>
Kendryte sells EVB to public
<Stat_headcrabed>
For example, k510
<courmisch>
well looks like they don't this time? or them it's not EVB, but that contradicts what was said on the ML
<Stat_headcrabed>
Maybe just because software not ready yet
<Stat_headcrabed>
They would begin selling EVB to public when software is almost finished
<Stat_headcrabed>
(I mean downstream SDK
<Stat_headcrabed>
😶
<conchuod>
Stat_headcrabed: What I was saying above about not caring if nothing has shipped was w.r.t. what has v0.7.1 versus the ratified version. The second conversation about how they intend handling Svpbmt/XMAE (assuming the thing can actually do both, which it may well) would be good to sort out prior to things shipping.
<conchuod>
I should just ask Guo...
<Stat_headcrabed>
Sorry I messed about this 😔
<conchuod>
You didn't mess anything?
<conchuod>
(unless I misunderstood)
<Stat_headcrabed>
I completely forgot the second conversation (
<Stat_headcrabed>
Btw
<Stat_headcrabed>
They already released c908 trm
<Stat_headcrabed>
And datasheet
<conchuod>
Anything in english?
<Stat_headcrabed>
Let me check...
Stat_headcrabed has quit [Read error: Connection reset by peer]
Stat_headcrabed has joined #riscv
<Stat_headcrabed>
Datasheet only
<Stat_headcrabed>
Trm only Chinese version yet
<Stat_headcrabed>
Better go for online translator
Stat_headcrabed has quit [Read error: Connection reset by peer]
<Stat_headcrabed>
(If you have difficulty downloading it
<conchuod>
👍
<Stat_headcrabed>
I remember they said it is compatible with rva22 while releasing c908
<courmisch>
I don't understand the talk of using vendor and chip ID to determine vector version
<Stat_headcrabed>
What?
<courmisch>
why don't they just check the version at run-time instead of trying to second guess
<Stat_headcrabed>
Who did that? Downstream SDK?
<courmisch>
Stat_headcrabed: the "RISC-V: Don't trust V from the riscv,isa DT property on T-Head CPUs" on kernel ML
<conchuod>
I, at least, do not want to do that. I just want to be told what it is by the DT.
<conchuod>
What I wanted to do was block "v" in riscv,isa since there are a load of incorrect devicetrees floating around.
<courmisch>
conchuod: insofar as devices with "broken" DTs also have "broken" kernels, there is indeed a valid argument that the DT should just be fixed
<Stat_headcrabed>
Since downstream dt mostly not compatible with mainline, I think we could just modify all existing dt
<courmisch>
or just ignore V in the old string regardless of vendor and chip, and require the new format?
Stat_headcrabed has quit [Read error: Connection reset by peer]
<conchuod>
Which I did not want to do either, as it is disruptive to QEMU etc.
Stat_headcrabed has joined #riscv
Stat_headcrabed has quit [Read error: Connection reset by peer]
<courmisch>
well then there are only two options: runtime check or fixing DT on devices with draft V
wingsorc has joined #riscv
<courmisch>
either way, I don't understand the insistence on using vendor and chip ID
Stat_headcrabed has joined #riscv
Stat_headcrabed has quit [Read error: Connection reset by peer]
<conchuod>
So you think do runtime probe, or let the thing run into problems with incorrect devicetrees?
<courmisch>
I don't have much opinion on that particular choice, and if I did, I don't have any influence. I'm just thinking that in the first case, there are better options than vendor and chip ID.
<courmisch>
but maybe I missed something
Stat_headcrabed has joined #riscv
Stat_headcrabed has quit [Read error: Connection reset by peer]
Stat_headcrabed has joined #riscv
<Stat_headcrabed>
Seems there's still tons of T-head extensions on c908
Stat_headcrabed has quit [Remote host closed the connection]
BootLayer has quit [Quit: Leaving]
<courmisch>
well, no reasons for them to drop all the stuff under CUSTOM opcodes, are there?
<courmisch>
only RVV 0.7.1 conflicts with RVV 1.0.0
<courmisch>
I wouldn't be surprised if the CPU had both Zb{a,b} and XTheadb{a,b}
<courmisch>
for instance
Stat_headcrabed has joined #riscv
<Stat_headcrabed>
conchuod: seems c908 has a non-zero marchid
<Stat_headcrabed>
But mimpid is still 0
<conchuod>
That's fine.
<Stat_headcrabed>
(not sure since they didn't told us the marchid value
<Stat_headcrabed>
Only says marchid is set with a T-head internal id
Stat_headcrabed has quit [Read error: Connection reset by peer]
FL4SHK has quit [Ping timeout: 246 seconds]
Stat_headcrabed has joined #riscv
Stat_headcrabed has quit [Read error: Connection reset by peer]
Stat_headcrabed has joined #riscv
<Stat_headcrabed>
Also seems xmae not exist in this trm, svpbmt exists.
Stat_headcrabed has quit [Read error: Connection reset by peer]
FL4SHK has joined #riscv
<sorear>
look for MAEE in MXSTATUS, that finds it in the openc906 repo
Stat_headcrabed has joined #riscv
<Stat_headcrabed>
We are talking to c908,not 906
Stat_headcrabed has quit [Remote host closed the connection]
Leopold has quit [Ping timeout: 250 seconds]
Leopold has joined #riscv
<sorear>
the only reason for c908 to provide xmae is compatibility with c906, so it should work in the same way if at all
zjason has quit [Read error: Connection reset by peer]
zjason has joined #riscv
<courmisch>
what xmae? an undocumented vendorextension?
heat has quit [Remote host closed the connection]
heat has joined #riscv
<jrtc27>
XuanTie Memory Attributes Extension
<courmisch>
page table thingamagic?
<courmisch>
well if it's in the PTEs, I can guess that it can't cohabitate with another page table extension
<meowray>
replies will get moderated if you don't subscribe to binutils, but you can ignore the bounce, as long as Jan Beulich is in To:/Cc:
<meowray>
(even with a lot of rants about gas, i suspect its expression evaluation and linker relaxation relocation handling is better than LLVM integrated assembler's)
Forty-Bot has quit [Ping timeout: 260 seconds]
heat has quit [Read error: Connection reset by peer]