sorear changed the topic of #riscv to: RISC-V instruction set architecture | https://riscv.org | Logs: https://libera.irclog.whitequark.org/riscv
dramforever_ has joined #riscv
dramforever__ has quit [Read error: Connection reset by peer]
wingsorc has quit [Remote host closed the connection]
matoro has quit [Quit: ZNC 1.8.2 - https://znc.in]
matoro has joined #riscv
matoro has joined #riscv
matoro has quit [Changing host]
wingsorc has joined #riscv
jacklsw has joined #riscv
bgamari has quit [Ping timeout: 260 seconds]
bgamari has joined #riscv
tsraoien has joined #riscv
tsraoien has quit [Ping timeout: 244 seconds]
toluene has quit [Read error: Connection reset by peer]
toluene has joined #riscv
jacklsw has quit [Read error: Connection reset by peer]
jacklsw has joined #riscv
dramforever__ has joined #riscv
dramforever_ has quit [Ping timeout: 268 seconds]
dramforever__ has quit [Remote host closed the connection]
handsome_feng has joined #riscv
motherfsck has quit [Ping timeout: 268 seconds]
<muurkha> so I read Andrew Waterman's dissertation last night when I couldn't sleep, which was pretty awesome
<muurkha> it covers most of the same material as the current RISC-V unprivileged spec, but it's better written and more enjoyable
<muurkha> unfortunately it's out of date and not licensed in such a way as to be updatable
<muurkha> it goes into more detail on a few things, like compressing prologues/epilogues with millicode
<muurkha> one of the differences I noticed, in particular because I was thinking about the ridiculously bad byte-swapping code I got out of GCC, was that at the time RISC-V was specified to support unaligned access, like i386
<muurkha> and now the RISC-V spec fobs that decision off on the specification of the "EEI"
<muurkha> so I'm wondering where the riscv64-linux-gnu EEI is specified and whether it guarantees unaligned fetch support
<muurkha> because if I were a compiler emitting byte-swapping code starting from return 0 | (u32)p[0] << 24 | (u32)p[1] << 16 | (u32)p[2] << 8 | (u32)p[3]
<muurkha> I feel like it would be Extremely Bad to emit code that on some machines would cause unaligned access exceptions that kill your program
<muurkha> but only slightly bad to emit code that runs ridiculously slowly if your big-endian fetch is unaligned and your RISC-V implementation has chosen to support unaligned fetches through a trap to S-mode
<muurkha> maybe that's too Pollyannaish and that would be totally unacceptable for other uses, but generally when I have big-endian things I want to fetch they are already properly aligned
motherfsck has joined #riscv
aerkiaga has quit [Remote host closed the connection]
djdelorie has quit [Quit: Leaving]
djdelorie has joined #riscv
<jrtc27> unaligned fault emulation is only marginally less bad
<jrtc27> it works but you really do not want to use it if you can at all avoid it
<jrtc27> you either want unaligned accesses to be guaranteed fast or guaranteed to fault IMO
<jrtc27> anything in between just creates a mess
<muurkha> jrtc27: that sounds reasonable, but I don't think anything in RISC-V is guaranteed fast, is it?
<jrtc27> nope
<jrtc27> trap and emulate is a valid implementation of any instruction
<muurkha> and 16kHz is a valid clock speed
<jrtc27> as far as userspace is concerned
<jrtc27> well, fast relative to aligned accesses
<jrtc27> ie not trap and emulate
<jrtc27> (slightly slower due to cache line shenanigans is fine)
<muurkha> also on Linux it's common for any random memory access to take 10,000,000 nanoseconds because spinning rust
<muurkha> it would be great to have *aligned* accesses to be guaranteed fast, but that means you can't swap
<muurkha> even swapping from an SSD might take over 1000 ns
<jrtc27> that's different, and hopefully amortised
<muurkha> I wrote a recursive search program in C once that used longjmp() once it found a solution
<muurkha> it did a lot of searches, not just one
<muurkha> a friend reported that it ran 10 times slower on his Mac than it did on my Linux box, even though the Mac was newer
<muurkha> turned out MacOS had implemented longjmp() in some way that required a system call (maybe because they implemented it as siglongjmp()? memory is vague)
<muurkha> ideally it's different and amortized, but a lot of my most annoying experiences with Linux have been when it turned out not to be different or amortized :(
<muurkha> and even if it's amortized it only takes one 10,000,000 nanosecond delay in your mouse tracking to cause user-perceptible jankiness
dramforever has joined #riscv
dramforever_ has joined #riscv
dramforever has quit [Ping timeout: 276 seconds]
jack_lsw has joined #riscv
jacklsw has quit [Ping timeout: 244 seconds]
dramforever__ has joined #riscv
dramforever_ has quit [Ping timeout: 264 seconds]
dramforever_ has joined #riscv
dramforever__ has quit [Read error: Connection reset by peer]
dramforever__ has joined #riscv
dramforever_ has quit [Read error: Connection reset by peer]
<dh`> longjmp is traditionally siglongjmp on bsd
BootLayer has joined #riscv
dramforever_ has joined #riscv
dramforever__ has quit [Remote host closed the connection]
<la_mettrie> every visionfive device with own driver code (listed on the pastebin) requires those codes to work? https://pastebin.com/raw/nmgUnnys
dramforever__ has joined #riscv
dramforever_ has quit [Read error: Connection reset by peer]
foton has quit [Quit: %Bye, bye, ...%]
foton has joined #riscv
dor has joined #riscv
dramforever_ has joined #riscv
dramforever__ has quit [Read error: Connection reset by peer]
bauruine has joined #riscv
jmdaemon has joined #riscv
<muurkha> dh`: that would explain it
jack_lsw has quit [Quit: Back to the real world]
<Esmil> la_mettrie: you'd want the clock, reset and pinctrl driver to most things, but they're already upstream. the patches to the serial driver is not needed for a serial console. the audio clocks are not needed if you don't want to use the audio peripherals and the rest of the drivers are also for specific things
<Esmil> the stuff in drivers/dma/dw-axi-dmac-starfive/ was never used and i deleted it from the latest visionfive branch
<la_mettrie> audio clocks are needed to get some sound out for the first place?
<Esmil> yes, the pwmdac fx. needs the audio clocks
<Esmil> la_mettrie: you can look at arch/riscv/boot/dts/starfive/jh7100.dtsi and see which peripherals has a reference to &audclk
toluene has quit [Ping timeout: 272 seconds]
toluene has joined #riscv
TMM_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM_ has joined #riscv
dor has quit [Read error: Connection reset by peer]
aburgess_ has quit [Ping timeout: 268 seconds]
indy has quit [Quit: ZNC 1.8.2 - https://znc.in]
indy has joined #riscv
jmdaemon has quit [Ping timeout: 240 seconds]
dramforever__ has joined #riscv
dramforever_ has quit [Read error: Connection reset by peer]
dramforever_ has joined #riscv
dramforever__ has quit [Ping timeout: 276 seconds]
dramforever_ has quit [Ping timeout: 240 seconds]
dramforever has joined #riscv
toluene has quit [Read error: Connection reset by peer]
toluene has joined #riscv
dramforever_ has joined #riscv
dramforever has quit [Ping timeout: 240 seconds]
<ikke> conchuod: mine went up to 50C, but remains around that
<ikke> started monitoring the temp
dor has joined #riscv
dramforever__ has joined #riscv
dramforever_ has quit [Read error: Connection reset by peer]
Andre_H has joined #riscv
indy has quit [Ping timeout: 244 seconds]
indy has joined #riscv
geertu has quit [Ping timeout: 256 seconds]
geertu has joined #riscv
prabhakarlad has quit [Quit: Client closed]
memoryleak_ has joined #riscv
memoryleak has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
memoryleak has joined #riscv
memoryleak has quit [Client Quit]
amjad has joined #riscv
amjad has left #riscv [#riscv]
memoryleak_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
memoryleak has joined #riscv
BootLayer has quit [Quit: Leaving]
jobol has joined #riscv
BootLayer has joined #riscv
loggervicky has joined #riscv
handsome_feng has quit [Quit: Connection closed for inactivity]
raym has quit [Ping timeout: 268 seconds]
raym has joined #riscv
dramforever_ has joined #riscv
dramforever__ has quit [Read error: Connection reset by peer]
drmpeg has quit [Ping timeout: 244 seconds]
drmpeg has joined #riscv
prabhakarlad has joined #riscv
EchelonX has joined #riscv
dor has quit [Remote host closed the connection]
matt__ has joined #riscv
frkzoid has quit [Ping timeout: 255 seconds]
loggervicky has quit [Ping timeout: 272 seconds]
loggervicky has joined #riscv
dor has joined #riscv
loggervicky has quit [Quit: loggervicky]
motherfsck has quit [Ping timeout: 255 seconds]
raym has quit [Ping timeout: 268 seconds]
raym has joined #riscv
motherfsck has joined #riscv
kaji has quit [Quit: You have been kicked for being idle]
jacklsw has joined #riscv
Andre_H has quit [Quit: Leaving.]
___nick___ has joined #riscv
matt__ is now known as freakazoid333
pecastro has joined #riscv
dramforever_ has quit [Remote host closed the connection]
dramforever_ has joined #riscv
dramforever_ has quit [Remote host closed the connection]
dramforever_ has joined #riscv
<Esmil> palmer: you didn't include the fix for make ARCH=riscv vdso_install in your latest pull. is that on purpose?
<palmer> I probably just didn't get to it yet, can you give me a pointer?
<palmer> I get pretty buried this cycle
<Esmil> palmer: it's not in that thread, but Ben reports that it also breaks make ARCH=riscv deb-pkg when CONFIG_COMPAT=y
jacklsw has quit [Read error: Connection reset by peer]
ldevulder has quit [Quit: Leaving]
cwebber has quit [Remote host closed the connection]
___nick___ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
___nick___ has joined #riscv
___nick___ has quit [Client Quit]
___nick___ has joined #riscv
foxxesStar has quit [Remote host closed the connection]
matoro has quit [Quit: ZNC 1.8.2 - https://znc.in]
matoro has joined #riscv
matoro has joined #riscv
matoro has quit [Changing host]
BootLayer has quit [Quit: Leaving]
indy has quit [Ping timeout: 272 seconds]
<Esmil> palmer: cool, thanks!
<palmer> well, sorry for being slow -- if I miss simple stuff like this it's best to just poke it on IRC, stuff gets buried in the patch queue
<palmer> I just do things mostly in order, aside from trying to poke around and see if there's any fixes (but that doesn't catch everythingc)
indy has joined #riscv
TMM_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM_ has joined #riscv
<Esmil> cool, will do. i also forgot the fixes tag when first sending this which probably didn't help
loggervicky has joined #riscv
<palmer> Ya, I generally look for "fix" in the subject but when there's no fixes tag and I'm slammed for time I frequently don't look closer
dramforever__ has joined #riscv
___nick___ has quit [Ping timeout: 276 seconds]
dramforever_ has quit [Read error: Connection reset by peer]
dramforever__ has quit [Remote host closed the connection]
dramforever__ has joined #riscv
loggervicky has quit [Quit: loggervicky]
dramforever_ has joined #riscv
dramforever__ has quit [Ping timeout: 268 seconds]
crabbedhaloablut has joined #riscv
<drewfustini> I'm using a soc that is using PLIC with "sifive,plic-1.0.0". I'm a little confused as to why the interrupts on the PLIC chip show 'edge' in type file under /sys/kernel/irq/ Shouldn't that be level, not edge?
<palmer> drewfustini: there's a patch on the list
<drewfustini> related to Renesas?
<drewfustini> do mean that it may just be that the /sys/kernel/irq/n/type is mislabelled?
<palmer> it used to be that the PLIC didn't really define edge vs level, but that probably wasn't a good idea
<palmer> so if you're seeing either without those patches it's wrong, as it's just undefined
<drewfustini> Thanks, yes, I see one of the patches adds:
<drewfustini> .irq_set_type= plic_irq_set_type
jobol has quit [Quit: Leaving]
<drewfustini> I had never thought about it too much before but I'm on an SoC that implements the SiFive PLIC and no PLIC interrupts ever trigger a handler so I've been looking more closely at how it works on existing SoCs
<drewfustini> Good to know that the interrupt type in /sys/kernel/irq doesn't mean anything currently
Starfoxxes has joined #riscv
jmdaemon has joined #riscv
dramforever__ has joined #riscv
dramforever_ has quit [Read error: Connection reset by peer]
<conchuod> palmer: if you're still looking for applicable-to-5.19 fixes, this one is reviewed by Guo: https://lore.kernel.org/linux-riscv/20220721065820.245755-1-zouyipeng@huawei.com/
dramforever_ has joined #riscv
dramforever__ has quit [Read error: Connection reset by peer]
dramforever__ has joined #riscv
dramforever_ has quit [Read error: Connection reset by peer]
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #riscv
toluene has quit [Read error: Connection reset by peer]
toluene has joined #riscv
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #riscv
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #riscv
aerkiaga has joined #riscv
prabhakarlad has quit [Quit: Client closed]
EchelonX has quit [Quit: Leaving]
pecastro has quit [Ping timeout: 244 seconds]
vagrantc has joined #riscv
Gravis has quit [Quit: Murdered]