<Stat_headcrabed>
esmil: Are your ccache management series ready for upstreaming? Better to be faster or stf would put more shit on their driver....
Stat_headcrabed has quit [Read error: Connection reset by peer]
elastic_dog has quit [Ping timeout: 255 seconds]
elastic_dog has joined #riscv
Andre_Z has quit [Quit: Leaving.]
ldevulder_ is now known as ldevulder
Guest91 has joined #riscv
MaxGanzII has joined #riscv
MaxGanzII has quit [Remote host closed the connection]
MaxGanzII has joined #riscv
prabhakarlad has joined #riscv
ezulian has joined #riscv
ezulian has quit [Client Quit]
ezulian has joined #riscv
MaxGanzII has quit [Remote host closed the connection]
MaxGanzII has joined #riscv
danilogondolfo has joined #riscv
frkzoid has quit [Read error: Connection reset by peer]
frkzoid has joined #riscv
stolen has joined #riscv
Guest91 has quit [Quit: Client closed]
jacklsw has quit [Ping timeout: 240 seconds]
MaxGanzII has quit [Remote host closed the connection]
navnavnav has joined #riscv
<navnavnav>
Hi all! I'm quite new to RISC-V. Does anyone know of any debug tools/probes for programming and debugging RISC-V micros, and has an open protocol (a documented protocol for PC -> debug tool communication)?
agentcasey has quit [Ping timeout: 240 seconds]
<sorear>
that's going to depend on the micro, it's not an ISA function
<navnavnav>
Thanks both, that document is helpful. So what's the most popular RISC-V micro available today? Just want to get an idea of what most are using nowadays
<Esmil>
probably the ESP32-C3, but there are also the CH32V and GD32VF series
<Esmil>
(and many others i imagine)
<navnavnav>
Nice! Thanks Esmil!
Tenkawa has joined #riscv
grumbler has joined #riscv
ntwk has quit [Quit: ntwk]
BootLayer has quit [Quit: Leaving]
jmdaemon has quit [Ping timeout: 260 seconds]
robfree has joined #riscv
jmdaemon has joined #riscv
Danidada has joined #riscv
lagash has quit [Ping timeout: 252 seconds]
prabhakarlad has quit [Quit: Client closed]
BootLayer has joined #riscv
jacklsw has joined #riscv
Stat_headcrabed has joined #riscv
MaxGanzII has joined #riscv
vagrantc has joined #riscv
heat has quit [Ping timeout: 245 seconds]
Danidada has quit [Ping timeout: 258 seconds]
MaxGanzII has quit [Ping timeout: 252 seconds]
GenTooMan has quit [Ping timeout: 240 seconds]
GenTooMan has joined #riscv
sympt has quit [Quit: Ping timeout (120 seconds)]
sympt has joined #riscv
Danidada has joined #riscv
junaid_ has joined #riscv
lagash has joined #riscv
robfree has quit [Ping timeout: 264 seconds]
junaid_ has quit [Remote host closed the connection]
<sorear>
someone let me know if I'm being ridiculous with my expectation that future hardware+firmware should conform to RVA20 as well as RVA23 because we're designing a 50-year ISA here not a 3-year one
<jrtc27>
that is how a sensible, mature ecosystem would function, yes
<geist>
that being said i think RVA22 may be a better reasonable starting point, but then again 50 year ISA...
jacklsw has quit [Ping timeout: 260 seconds]
<courmisch>
sorear: not holding my breath for Debian to require Zba support
<sorear>
zba isn't part of rva20 so it's not relevant here
<courmisch>
it's in the next RVA release IIRC though
<sorear>
that doesn't stop hardware vendors from supporting both rva20 and rva23
<sorear>
as far as rva20 is concerned, zba is just a custom extension and harmless
<courmisch>
well, yes but with that same logic, you could drop F, D and even M from requirements, and emulate them all in software
<sorear>
what i'm concerned with is sptead being required by rva20 but (probably, can't get a straight answer) forbidden by rva23
<sorear>
imagine if rva23 decided to reuse the F and D opcodes for entirely different instructions
<courmisch>
sptead?
<sorear>
svade now
<sorear>
it's in riscv-profiles
<courmisch>
Svade sounds like something that the kernel should be able to enable at runtime
<courmisch>
I haven't read that spec, but isn't it basically equivalenet to Armv8-HAFDBS ?
<courmisch>
the kernel is actually in a uniquely good position to select different instructions at runtime (or rather boot time) efficiently
<sorear>
Svadu allows M-mode to enable and disable dirty bit management using the menvcfg register, but there's absolutely no specification for what the menvcfg value at boot time should be or any way for the kernel to ask for it to be changed
<sorear>
Svade means that dirty bit management is not supported, and is the same thing as forcing HADE = 0
<courmisch>
not familiar with the details here, TBH
<sorear>
ask, then
<sorear>
^ self contained explanation
<courmisch>
at least Linux arm64 is written with the assumption that the access and dirty bits may be hardware-updated always
<courmisch>
if the hardware can't do it, then it's just managed in the traps
<courmisch>
can't the kernel just assume that hardware updates *may* happen as it updates PTEs, and fix the dirty bit manually if necessary (because the hardware won't do it)?
<sorear>
there's no written specification to the effect that kernels must be prepared to handle automatic updates, and it's too late to add one since rva20 is ratified
<sorear>
if you're trying to argue that the lack of a specification doesn't matter because linux works, i'll let you take that up with jrtc27
<courmisch>
so your concern is that the feature could be enabled even though an old kernel is running?
<sorear>
s/old kernel/kernel assuming rva20/
<courmisch>
on Arm, S (well, EL1) hardware updates can only be enabled by EL1, so that's a nonissue...
<sorear>
a strict reading of rva20 is that page table entries have two valid bits and two writable bits, and there are many ways to use that, only some of which are compatible with hade=1
<courmisch>
I suppose that the people writing the RV spec didn't care to support "new" bootloader with "old" kernel?
<sorear>
stop thinking about "bootloader" and "kernel", the only relevant concepts are the privilege levels
<jrtc27>
conchuod: "can't the kernel just" - that is exactly what kernels have been doing for years on RISC-V until the powers that be decreed what was in ratified specs as no longer desirable and outlawed it in RVA20
<jrtc27>
uh courmisch
<jrtc27>
(tab complete...)
<jrtc27>
behaviour that QEMU implemented
<jrtc27>
the privileged spec used to just be "hardware will either always trap for A/D or will always atomically set them as needed"
<sorear>
«on Arm, S (well, EL1) hardware updates can only be enabled by EL1, so that's a nonissue...» that would be a reasonable hardware design, but we made menvcfg affect S/U-mode while only being accessible from M-mode for some reason
<courmisch>
the other approach is to require M mode not to enable the feature until/unless the kernel signals support for it, yes
<jrtc27>
the sane approach is to have it mirrored in senvcfg
<jrtc27>
though questions about how you mirror things for vs-mode
<sorear>
it would have to be a different register, the senvcfg name is already taken for "state bits that affect U-mode only"
<courmisch>
mirroring sounds iffy to me, and not only because of H
<jrtc27>
... sigh
<sorear>
[i have seen an unfortunate number of both hardware and software implementations that _non-atomically_ set A/D on access]
<courmisch>
non-atomic updates are plain broken, no matter how you look at it
<jrtc27>
anyway, TL;DR, Svadu is a total waste of time
<jrtc27>
and nobody has applied any critical thought to what problem it solves
<courmisch>
it looks to me like typical (poor) copy-pasting Arm specs
<courmisch>
while Arm probably copied it from x86 in this case
<jrtc27>
I assume nothing useful given responses to sorear's earlier issue
<courmisch>
"M-mode itself does not care, because it is subject to translation. " ...
<sorear>
stimecmp is a bad analogy since changing ADUE is not a hot path
<courmisch>
did you mean "is not subject" ? otherwise I don't understand
<jrtc27>
uh yes, thanks
<sorear>
at this stage in the standardization process getting a new CSR defined is ridiculously uphill; I'd file an issue to define a SBI call but _there's no repo for that_
<jrtc27>
sorear: agreed, but it's still gratuitous
<jrtc27>
S-mode config belongs in S-mode
<sorear>
can't file the issue I want on -svadu because it's strictly a hardware spec, can't file it on -sbi because svadu isn't ratified, ideally I'd wait for said ratification but they're really rushing things on the linux and device-tree side
<courmisch>
will it piss people off if you FYI that Arm has the HA and HD bits in TCR_EL1 ?
<courmisch>
ah, I really meant to ask if it would do the bug report a service or a disservice
<sorear>
the analogy doesn't work very well because riscv lacks any equivalent to ISB
<sorear>
menvcfg is defined the way it is because there is no privilege mode at which it can be both implicitly and explicitly accessed, so as long as mret is a full barrier there is no synchronization requirement
<courmisch>
implying that the rationale for the current problem is pipeline synchronisation?
<courmisch>
in that case, making an explicit call to M may be the compromise, but that's only viable because it's a one-time boot thing, rather than hot stuff as you wrote already
<jrtc27>
sfence.vma would be ok here
<jrtc27>
it's not the best fit but it kinda is the sensible thing
<courmisch>
*but* there should be a way to synch with PTE updates anyway
<courmisch>
seems I keep getting toasted today :$
junaid_ has quit [Read error: Connection reset by peer]
frkzoid has quit [Ping timeout: 255 seconds]
frkazoid333 has joined #riscv
frkzoid has joined #riscv
danilogondolfo has quit [Quit: Leaving]
chripo has quit [Quit: ""]
chripo has joined #riscv
frkazoid333 has quit [Ping timeout: 258 seconds]
jmdaemon has quit [Ping timeout: 260 seconds]
jmdaemon has joined #riscv
jmdaemon has quit [Ping timeout: 258 seconds]
BootLayer has quit [Quit: Leaving]
ldevulder_ has joined #riscv
ldevulder has quit [Ping timeout: 245 seconds]
ntwk has joined #riscv
crabbedhaloablut has quit []
jmdaemon has joined #riscv
MaxGanzII has quit [Remote host closed the connection]
mlw has joined #riscv
jmdaemon has quit [Ping timeout: 260 seconds]
panzeroceania_ has quit [Ping timeout: 252 seconds]
jmdaemon has joined #riscv
gatecat has quit [Ping timeout: 252 seconds]
ldevulder_ has quit [Quit: Leaving]
gatecat has joined #riscv
panzeroceania_ has joined #riscv
mlw has quit [Ping timeout: 260 seconds]
unnick has quit [Ping timeout: 258 seconds]
Jackneill has quit [Ping timeout: 260 seconds]
unnick has joined #riscv
brazuca has joined #riscv
robfree has joined #riscv
grumbler has left #riscv [It's time]
grumbler has joined #riscv
grumbler is now known as admiral_frost
brazuca has quit [Quit: Client closed]
navnavnav has quit [Quit: Konversation terminated!]
ntwk has quit [Ping timeout: 260 seconds]
Danidada has quit [Quit: Leaving]
jmdaemon has quit [Ping timeout: 240 seconds]
ntwk has joined #riscv
grumbler_ has joined #riscv
admiral_frost has quit [Killed (NickServ (GHOST command used by grumbler_!~grumbler@193.138.218.214))]