dramforever__ has quit [Remote host closed the connection]
dramforever__ has joined #riscv
EchelonX has joined #riscv
tsraoien has joined #riscv
matt__ has joined #riscv
BootLayer has joined #riscv
frkzoid has quit [Ping timeout: 244 seconds]
Andre_H has quit [Quit: Leaving.]
conchuod has joined #riscv
frkzoid has joined #riscv
matt__ has quit [Ping timeout: 244 seconds]
BootLayer has quit [Quit: Leaving]
dramforever_ has joined #riscv
dramforever__ has quit [Read error: Connection reset by peer]
dramforever__ has joined #riscv
dramforever_ has quit [Ping timeout: 255 seconds]
aerkiaga has quit [Remote host closed the connection]
BootLayer has joined #riscv
handsome_feng has quit [Quit: Connection closed for inactivity]
matt__ has joined #riscv
frkzoid has quit [Ping timeout: 240 seconds]
Andre_H has joined #riscv
frkzoid has joined #riscv
matt__ has quit [Ping timeout: 268 seconds]
matt__ has joined #riscv
frkzoid has quit [Ping timeout: 240 seconds]
<drewfustini>
I've been trying to understand if "normal" s-mode linux does anything with the clint compatible DT node when it is present. As far as I can tell, it looks like the corresponding driver is really just for m-mode like k210: drivers/clocksource/timer-clint.c
<drewfustini>
anyone have any insights?
<drewfustini>
in other words, I am thinking I don't need to care about the clint from the perspective of the linux kernel in s-mode on something like the FU740
<conchuod>
oh btw drew, my bbai64 came in the end :+1:
<drewfustini>
great!
<conchuod>
drewfustini: I don't think the driver is built for it in S mode. We build only timer-riscv
frkzoid has joined #riscv
matt__ has quit [Ping timeout: 240 seconds]
prabhakarlad has quit [Quit: Client closed]
<drewfustini>
ok, thanks, that makes sense
matt__ has joined #riscv
matt__ is now known as freakazoid333
frkzoid has quit [Ping timeout: 244 seconds]
dramforever_ has joined #riscv
dramforever__ has quit [Ping timeout: 255 seconds]
loggervicky has joined #riscv
Raito_Bezarius has quit [Ping timeout: 240 seconds]
<palmer>
drewfustini: the fu540 didn't have all the S-mode interrupts in the CLINT, they had to be software proxied from M-mode. So we sort of just couldn't use it. IIRC there was some vagueness as to whether they'd been added, but I forget if that was in some specification or in the FU740
loggervicky1 has joined #riscv
frkzoid has joined #riscv
<conchuod>
palmer: no need to think about this if you dont know off hte top of your head, but why does riscv not enable cpufreq stuff in kconfig?
loggervicky has quit [Ping timeout: 240 seconds]
loggervicky1 is now known as loggervicky
freakazoid333 has quit [Ping timeout: 244 seconds]
Raito_Bezarius has joined #riscv
<palmer>
conchuod: the SiFive chips don't have DVFS that actually works
<palmer>
probably a bad reason for a global decision, though
<drewfustini>
palmer: thanks, do you know if there is any S-mode interrupts from clint supported in Linux?
<drewfustini>
I don't have a problem, just trying to understand what Linux does with the clint dt node. I'm currently working with a core based on BooM but I'm curious in general.
<conchuod>
I'll send a patch to enable that menu so palmer ...
dramforever__ has joined #riscv
dramforever_ has quit [Ping timeout: 272 seconds]
<conchuod>
btw palmer did you see Heiko & I talking about riscv:/RISC-V: or is that too near the top of your inbox?
<jrtc27>
S-mode CLINT isn't a thing, the CLINT is defined to be M-mode only
<jrtc27>
ACLINT adds S-mode bits for IPIs
<jrtc27>
and Sstimecmp adds timer bits
<jrtc27>
(it's a shame the M-mode interface was memory-mapped and not a CSR like the S-mode one is now.....)
ZipCPU has quit [Ping timeout: 255 seconds]
dramforever_ has joined #riscv
dramforever__ has quit [Ping timeout: 240 seconds]
enthusi has quit [Ping timeout: 240 seconds]
oaken-source has quit [Ping timeout: 240 seconds]
tsraoien has quit [Ping timeout: 272 seconds]
ZipCPU has joined #riscv
enthusi has joined #riscv
oaken-source has joined #riscv
prabhakarlad has joined #riscv
loggervicky has quit [Quit: loggervicky]
matt__ has joined #riscv
grubman has left #riscv [WeeChat 1.9.1]
frkzoid has quit [Ping timeout: 240 seconds]
BootLayer has quit [Quit: Leaving]
matt__ is now known as freakazoid333
tsraoien has joined #riscv
frkzoid has joined #riscv
abelvesa has quit [Ping timeout: 240 seconds]
freakazoid333 has quit [Ping timeout: 244 seconds]
Andre_H has quit [Ping timeout: 264 seconds]
abelvesa has joined #riscv
___nick___ has quit [Ping timeout: 240 seconds]
<drewfustini>
jrtc27: thanks
matt__ has joined #riscv
frkzoid has quit [Ping timeout: 272 seconds]
dramforever__ has joined #riscv
dramforever_ has quit [Read error: Connection reset by peer]
grgy has joined #riscv
aerkiaga has joined #riscv
conchuod has quit [Quit: Lost terminal]
muurkha_ is now known as muurkha
ldevulder_ has joined #riscv
ldevulder has quit [Ping timeout: 276 seconds]
<muurkha>
I spent a bunch of the weekend reading assembly listings GCC 10 spits out
<muurkha>
I was disappointed with the code it emitted for byte-swapping
<muurkha>
for the code 0 | (u32)p[0] << 24 | (u32)p[1] << 16 | (u32)p[2] << 8 | (u32)p[3]
<muurkha>
for RISC-V
<muurkha>
it produced an lbu, an slliw, and in most cases an or, for each byte
<muurkha>
all using registers not among the eight that C-compressed or can access, and there is no C-compressed lbu or slliw
<muurkha>
I should say "in most cases an slliw and an or"
<muurkha>
and I should say "for RV64G"
<muurkha>
this ends up as like 10 instructions, and I feel like that's a lot of code and probably execution time for a big-endian u32 load. even a possibly unaligned one
<muurkha>
what's the right way to byte-swap a 32-bit word on RV64G?
frkzoid has joined #riscv
<smaeul>
drewfustini: jrtc27: fwiw C9xx has S-mode CLINT registers, both timecmp and swi