<Stat_headcrabed>
Do we have an api in hwprobe for reading mtime frequency?
<Stat_headcrabed>
we could read device tree, but what about acpi?
knedl1k has quit [Quit: knedl1k]
<palmer>
Stat_headcrabed: just propose adding one
<palmer>
should be pretty easy, just a key and a lookup from the DT
<palmer>
it might be better done via some perf hook, but someone will probably tell us ;)
handsome_feng has joined #riscv
jacklsw has joined #riscv
esv_ has joined #riscv
esv has quit [Ping timeout: 255 seconds]
cousteau has quit [Quit: ♫ I can't forget the day I shot that network down ♫]
esv_ has quit [Ping timeout: 255 seconds]
<bbyoume>
How long til western hw matches or beats visionfive2, with an oshw/opensource cpu at least? Wouldnt others here be interested in buying such a device? or is there too much software dev work remaining still?
heat_ has quit [Ping timeout: 260 seconds]
<Stat_headcrabed>
palmer: I’m not familiar with this… :(
<Stat_headcrabed>
also, maybe we need other methods to deal with uefi+acpi while implementing this?
<pabs3>
bbyoume: usually every new device means additional software dev work; in the bootloaders, kernel, userspace drivers etc. I assume probably most generic riscv software dev is done now, apart from porting the long tail and optimising existing code.
* pabs3
has no idea about OSHW CPUs though, would assume most of them wouldn't get ASICs produced
shamoe has quit [Quit: Connection closed for inactivity]
shamoe has joined #riscv
davidlt has joined #riscv
mlw has joined #riscv
Stat_headcrabed has quit [Quit: Connection closed for inactivity]
BootLayer has joined #riscv
mlw has quit [Ping timeout: 255 seconds]
mlw has joined #riscv
davidlt has quit [Ping timeout: 264 seconds]
shamoe has quit [Quit: Connection closed for inactivity]
shamoe has quit [Quit: Connection closed for inactivity]
Stat_headcrabed has quit [Client Quit]
handsome_feng has quit [Quit: Connection closed for inactivity]
prabhakarlad has quit [Quit: Client closed]
heat_ has joined #riscv
shamoe has joined #riscv
heat has joined #riscv
heat_ has quit [Read error: Connection reset by peer]
<courmisch>
received my K230 CanMV, but now the not so fun part starts
Andre_Z has joined #riscv
<palmer>
courmisch: ya, I think you're the first one I've seen with it. Have fun ;)
<muurkha>
courmisch: fantastic!
<courmisch>
no clue how to put Linux on the big core though :(
<palmer>
courmisch: IIRC there's some discussion of errata already? or maybe it was just that there's none for this new chip yet? should be on LKML somewhere...
<courmisch>
palmer: I have not flashed anything yet, but it seems Linux runs only on the little management core
<courmisch>
which means I have no clue how to get to RVV
vagrantc has joined #riscv
<palmer>
that's wacky, I'd expect Linux to default to the big core
<palmer>
I guess it's time to dig around the boot flow?
<courmisch>
palmer: you may be overestimating my bottom feeder self
dogukan has joined #riscv
<courmisch>
I'd really rather have Linux on the big core and nothing on the small core, so I don't have to worry about feature support asymmetry, but that seems like a pipe dream for now
technoid_ has quit [Ping timeout: 252 seconds]
technoid_ has joined #riscv
<courmisch>
processor : 0
<courmisch>
isa : rv64imafdcvxthead
<courmisch>
mmu : sv39
<courmisch>
hart : 0
<courmisch>
hmm, maybe I was being too pessimistic
<courmisch>
or maybe the DT is just wrong
technoid_ has quit [Changing host]
technoid_ has joined #riscv
<unlord>
this is the small core?
<courmisch>
I suppose it's the big one since it says v but?
<courmisch>
there is only one core under Linux. whichever is which the other one is not visible
<unlord>
huh
<courmisch>
yeah so this is the small core and V is a lie
<courmisch>
or the kernel does not have V support
<muurkha>
shame
<courmisch>
HWCAP reports ACDFIMV but vlenb returns SIGILL
<courmisch>
not sure how the kernel is not crashing if it thinks there is V and there is not
<bjdooks>
does hwcap get truncated if the kernel doesn't have the vector support enabled?
<bjdooks>
vector is very recent
<courmisch>
the kernel wouldn't know to set the 'V' bit if it didn't understand vectors
<courmisch>
of course, who knows what hacks the vendor kernel has
<courmisch>
this is ehavily patched 5.10 afterall, from way before upstream V support
cwittlut has joined #riscv
cwittlut has quit [Remote host closed the connection]
ntwk has quit [Quit: ntwk]
<palmer>
courmisch: also LKML discussions about that, pretty sure T-Head is just claiming V is there in their kernels even for the non-1.0 stuff
<courmisch>
palmer: that it definitely does (based on my LPi4a)
<courmisch>
palmer: but that core has no V, 0.7.1 or 1.0
<palmer>
eek
<palmer>
IDK, then ;)
<courmisch>
it's even in the product spec: little core no V, big core V 1.0
<courmisch>
and apparently somebody there got the notion that compute stuff was better done with a custom RTOS using an IPC than with Linux
<palmer>
ya, I was just poking around the SDK. That's pretty wacky, I'm going to go hide ;)
<courmisch>
How dare you!!! I DEMAND AN IMMEDIATE SOLUTION ONE HOUR AGO!
<palmer>
;)
<courmisch>
the big core has some RVV patches for OpenBLAS and OpenCV. The RTOS also has some RVV code
<unlord>
courmisch: drat, I was hoping you would be able to test that V1.0 code I wrote
<courmisch>
I haven't checked if it can run on the LPi4a but it will be slow there because vsseg4 is slow on C910