<la_mettrie>
is jh7110's syscon dependent on the pinctrl driver? is it also dependent on the reset driver?
aerkiaga has joined #riscv
<Esmil>
la_mettrie: the syscon is just an area with assorted registers that starfive found no other place for, so should at most need a clock enabled for the bus. but jh7110 has both "sys" pins and "aon" pins, so don't be confused by that
<arnd>
Esmil: does this mean this cache controller has no way to write back a cache line without invalidating it?
<arnd>
is it a writethrough cache instead of writeback?
<Esmil>
arnd: i don't think so, but I'll re-read the documentation
<la_mettrie>
(the clock gen driver itself uses syscon)
<arnd>
Esmil: on writeback caches, you normally have at least a write-back (aka clean, sometimes named flush) and an invalidate operation, usually also a combined writeback+invalidate (usually named flush)
<Esmil>
page 192 "The flush operation performs a write-back and invalidate, meaning the contents are written to memory and L2 and L1 cache lines are then invalidated"
<arnd>
right, just saw that
<arnd>
Also, "The L1 data cache is a 32 KiB 4-way set-associative cache. It is virtually-indexed, physically-tagged with a line size of 64 bytes and is read/write-allocate with a PLRU replacement policy." means this is an aliasing dcache, right?
aerkiaga has quit [Remote host closed the connection]
<Esmil>
i'm sorry, i don't actually know what that means. i'm a bit out of my depth here. i'm surprised i even managed to get it working..
<palmer>
arnd: I'm also not quite sure what you mean by "aliasing dcache"
heat has quit [Remote host closed the connection]
<palmer>
Google seems to indicate it means you can have a physical address in there multiple times? IIUC that's how the SiFive caches work
heat has joined #riscv
<palmer>
(they have PA aliasing as well)
eroux has quit [Remote host closed the connection]
<geertu>
Esmil: thx, nice!
<geertu>
Esmil: it's been a while I managed to boot the starlight into working Ethernet and nfsroot...
<Esmil>
geertu: yeah, those patches are in my jh7100-dmapool branch which just has mmc and ethernet on top to test those dmas are working
<conchuod>
Esmil: Fuck yeah, you got it done with the dma-ranges only? :)
<Esmil>
conchuod: yeah :)
<conchuod>
Hellwig didn't explicitly write NAK this time, so maybe he is being worn down :)
<geertu>
conchuod: ;-)
<conchuod>
Esmil: Did you get chatting to Daire in Barcelona?
<Esmil>
conchuod: oh yes the whole microchip crew. it was fun :)
<conchuod>
Esmil: Cool. He said he was talking to some Canonical people, wasn't sure who.
<conchuod>
I'm more than happen to merge that jh7100 stuff, once the base stuff gets in.
billchenchina has quit [Quit: Leaving]
<Esmil>
yeah, i just need to figure out where to put those 'select DMA_GLOBAL_POOL' and 'select RISCV_NONSTANDARD_CACHE_OPS'. prabhakarlad's series puts it in Kconfig.errata, but for the JH7100 it's not really errata. it was designed before the standard CMO ops was a thing, and unlike the D1 it doesn't break any risc-v specs
<geertu>
Esmil: Well done! I merged jh7100-dmapool into my current tree, and starlight booting again straight into nfsroot userland (last time that worked was around 6.2.0-rc7)
<conchuod>
tbf, I don't think the rz/five deserves the "errata" marking for it either.
<Esmil>
yeah, that's right
<Esmil>
geertu: Cool!
<arnd>
palmer: I think if you want to support aliasing vipt caches in riscv, you need extra cache flushes during context switches, and an arch_get_unmapped_area() function that uses appropriate cache coloring to avoid aliases on file mappings
<arnd>
my memory on that is a bit vague since ARMv7 no longer does this, though there are some ARMv5 and ARMv6 based SoCs that have this problem
<arnd>
modern cores tend to avoid this problem entirely by using physically indexed caches, or using higher associativity, larger pages, or smaller caches, depending on the target application
jacklsw has joined #riscv
jacklsw has quit [Client Quit]
<arnd>
for a 32KB VIPT cache and 4KB pages, that would be 8-way set-associative, or alternatively 16KB for a 4-way cache
<palmer>
I think because of the PA aliasing we can't actually get correct behavior on the SiFive systems ;)
<arnd>
I would have expected Linux to explicitly require non-aliasing caches for riscv
<arnd>
it's certainly possible to avoid the aliases on other such CPUs, it's just really ugly and slow
<palmer>
I'd have to read to figure out the L1 VA aliasing problems, it's been a while
<palmer>
but we don't have any good way to control the PA aliasing they use for different attributes, so I think it's never going to be reliable
<arnd>
ah, I mixed up the aliasing dcache with the physical alias. I think mips and loongarch have a similar concept for the physical alias, but I have no idea how they make it work
<palmer>
the MIPS folks I've worked with said it was never reliable, IDK about Loongarch but they don't have a ton of implementations
<palmer>
for the aliasing dcache I can look if you want, is there something specific?
<palmer>
I'd need to read back through the docs, the SiFive caches have a bunch of caveats
<arnd>
they also copied all the bugs from mips, so I don't think it's any better
<arnd>
palmer, Esmil: I wonder if the L2 was meant to only be used in a coherent way, that would explain why it has a clean-and-invalidate operation but not separate clean-without-invalidate
<palmer>
nothing in the SiFive systems was designed to handle non-coherent devices
<arnd>
ok, that explains a lot
<palmer>
IIRC the L2 flushes (ie, those MMIO control registers) aren't even sufficient to ensure non-coherent devices work: they just say "get this line out of the L2", not "make sure this line is at the point of coherence". They're there to allow the L2 to be shut down, but those lines might still be bouncing around the fabric.
<palmer>
ya, all this JH7100 accidental non-coherent devices stuff is unlikely to ever work reliably, the support just isn't there in the IP
<palmer>
I don't really mind taking something to make it work-ish, but I think there's going to be an endless rabbit hole of bugs
jobol has quit [Ping timeout: 265 seconds]
courmisch has quit [Read error: Connection reset by peer]
courmisch has joined #riscv
<arnd>
does jh7110 have the same problems?
<Esmil>
palmer: interesting. for what it's worth i've seen plenty of complaints about the poor state of drivers, but i don't recall anything that looks like a problem with the non-coherency
<Esmil>
arnd: no, luckily starfive learned from the trouble with the jh7100
BootLayer has joined #riscv
jacklsw has joined #riscv
Noisytoot has quit [Remote host closed the connection]
Noisytoot has joined #riscv
<palmer>
Esmil: cool, hopefully there's few enough jh7100 users that we never have to deal with the issues ;)
<courmisch>
not much to do with those; I powered the board off once I had the VF2 up and running
jacklsw has quit [Quit: Back to the real life]
<palmer>
courmisch: that's probably a wise decision
jacklsw has joined #riscv
jacklsw has quit [Quit: Back to the real life]
KombuchaKip has quit [Ping timeout: 240 seconds]
xypron has quit [Ping timeout: 260 seconds]
jacklsw has joined #riscv
jacklsw has quit [Client Quit]
Wickram has quit [Quit: WeeChat 3.8]
jacklsw has joined #riscv
jacklsw has quit [Client Quit]
prabhakarlad has quit [Quit: Client closed]
prabhakar has quit [Quit: Connection closed]
jacklsw has joined #riscv
jacklsw has quit [Client Quit]
prabhakarlad has joined #riscv
jacklsw has joined #riscv
jacklsw has quit [Client Quit]
terminalpusher has quit [Ping timeout: 246 seconds]
jacklsw has joined #riscv
terminalpusher has joined #riscv
xypron has joined #riscv
junaid_ has joined #riscv
vagrantc has joined #riscv
pecastro has quit [Ping timeout: 260 seconds]
jacklsw has quit [Quit: Back to the real life]
jacklsw has joined #riscv
jacklsw has quit [Client Quit]
danilogondolfo has quit [Remote host closed the connection]
<courmisch>
anyone understands if RVV 0.7.1 indexed loads were supposed to be ordered or unordered? the spec does not say though it could be taken to imply ordered ??
<courmisch>
in RVV 1.0.0 there are explicit separate ordered and unordered loads
<courmisch>
(just curious, not trying to start a flame war on RVV 0.7.1)
Tenkawa has joined #riscv
<Tenkawa>
Esmil: Which of your source tree repos is the current updated one to work with for JH7110 and 6.4-rc?
aredridel4 has joined #riscv
BootLayer_ has joined #riscv
somlo__ has joined #riscv
aburgess_ has joined #riscv
peeps[zen] has joined #riscv
ldevulder has quit [Quit: Leaving]
aredridel has quit [Ping timeout: 240 seconds]
Xark has quit [Ping timeout: 240 seconds]
sjs has quit [Ping timeout: 240 seconds]
motherfsck has quit [Ping timeout: 240 seconds]
duffolonious has quit [Ping timeout: 240 seconds]
BootLayer has quit [Ping timeout: 240 seconds]
peepsalot has quit [Ping timeout: 240 seconds]
aburgess has quit [Ping timeout: 240 seconds]
somlo_ has quit [Ping timeout: 240 seconds]
zapb_ has quit [Ping timeout: 240 seconds]
aredridel4 is now known as aredridel
Xark has joined #riscv
zapb_ has joined #riscv
duffolonious has joined #riscv
sjs has joined #riscv
aerkiaga has joined #riscv
motherfsck has joined #riscv
heat has quit [Remote host closed the connection]
Galihom has quit [Server closed connection]
Galihom has joined #riscv
heat has joined #riscv
terminalpusher has quit [Remote host closed the connection]
heat has quit [Remote host closed the connection]
heat has joined #riscv
terminalpusher has joined #riscv
heat has quit [Remote host closed the connection]
<palmer>
courmisch: one of the problems with v-0.7.1 is that it wasn't really finished, so details like that aren't really going to be there. Presumably it's just up to T-Head's implementation, is there another one we have to worry about?
<courmisch>
palmer: One is more than enough; I hope not.
<palmer>
;)
<courmisch>
I don't really care about it, but is there a reason that Zbc didn't make hwprobe() ?
<palmer>
I replied to Heiko, I think we just forgot about it because it's not in this round of HW
<courmisch>
any consideration for Zicbom? or should userspace just assume it's present (since it's no-op otherwise)?
<palmer>
I think userspace doesn't need to know about Zicbom?
<courmisch>
why couldn't userspace prefetch?
<conchuod>
Isn't that zicbop?
<palmer>
I was just looking for the spec to figure out which was in each subset...
<palmer>
ya, I think Zicbop and Zicboz should be visible to userspace
<palmer>
there's a lot of extensions, though, so if you care about anything specific just send a patch ;)
<courmisch>
eh but then I need to setup softMMU QEMU or figure out how to update the kernel on my VF2
<palmer>
OK, then I guess someone else might send a patch? we'll see ;)
terminalpusher has quit [Remote host closed the connection]
<courmisch>
I see what you did there. Trying to get me to contribute to the kernel. I already have a very undeserved place in MAINTAINERS! I don't need to contribute any longer :P
<palmer>
either way it sounds like it needs a re-spin
<palmer>
I think Nick's not in here, though?
<palmer>
do you want to just reply on LKML and correct me?
<conchuod>
Nah, but I replied to the v3 once correcting him.
<conchuod>
Didn't feel like doing it again ;)
jrjsmrtn has joined #riscv
<palmer>
Ok
<palmer>
I can try and find the mail I just sent?
<conchuod>
Nah, I'll go do it..
<palmer>
thanks
Tenkawa has quit [Quit: Was I really ever here?]
enoq has joined #riscv
<conchuod>
Been trying to update my nfsroot to the latest f38 stuff from davidlt's builder, can't remember for the life of me how to properly extract the filesystem from the raw image so that it doesn't ruin file permissions.. One way fails to boot, one has a broken sudo :/
<palmer>
I think david isn't in here, maybe one of the fedora channels?
<palmer>
he's never asleep...
<conchuod>
He's usually here, maybe his matrix bridge broke
<palmer>
IDK, I poked him in #fedora-riscv to see
jobol has joined #riscv
jobol has quit [Client Quit]
tlwoerner has quit [Quit: Leaving]
tlwoerner has joined #riscv
KombuchaKip has joined #riscv
sevan has quit [Ping timeout: 240 seconds]
sevan has joined #riscv
wingsorc has joined #riscv
prabhakar has joined #riscv
enoq has quit [Quit: enoq]
Reinhilde is now known as Ellenor
sevan has quit [Changing host]
sevan has joined #riscv
vagrantc has quit [Quit: leaving]
pecastro has quit [Ping timeout: 240 seconds]
aerkiaga has quit [Remote host closed the connection]