billchenchina- has quit [Remote host closed the connection]
duffolonious has quit [Remote host closed the connection]
duffolonious has joined #riscv
handsome_feng has joined #riscv
duffolonious has quit [Ping timeout: 250 seconds]
duffolonious has joined #riscv
sakman has quit [Ping timeout: 268 seconds]
sakman has joined #riscv
billchenchina has joined #riscv
billchenchina has quit [Remote host closed the connection]
duffolonious has quit [Ping timeout: 248 seconds]
duffolonious has joined #riscv
junaid_ has joined #riscv
duffolonious has quit [Ping timeout: 260 seconds]
jacklsw has quit [Ping timeout: 252 seconds]
duffolonious has joined #riscv
junaid_ has quit [Remote host closed the connection]
billchenchina has joined #riscv
billchenchina has quit [Quit: Leaving]
sh1r4s3__ has quit [Ping timeout: 268 seconds]
raym has joined #riscv
duffolonious has quit [Ping timeout: 255 seconds]
duffolonious has joined #riscv
junaid_ has joined #riscv
junaid_ has quit [Remote host closed the connection]
wingsorc__ has quit [Ping timeout: 268 seconds]
jmdaemon has quit [Ping timeout: 252 seconds]
MaxGanzII has joined #riscv
Andre_Z has joined #riscv
sh1r4s3 has joined #riscv
sh1r4s3 has quit [Ping timeout: 260 seconds]
duffolonious has quit [Ping timeout: 248 seconds]
duffolonious has joined #riscv
sh1r4s3 has joined #riscv
MaxGanzII has quit [Ping timeout: 255 seconds]
duffolonious has quit [Ping timeout: 252 seconds]
MaxGanzII has joined #riscv
duffolonious has joined #riscv
sh1r4s3 has quit [Ping timeout: 268 seconds]
Tenkawa has joined #riscv
prabhakarlad has quit [Quit: Client closed]
handsome_feng has quit [Quit: Connection closed for inactivity]
Guest36 has quit [Quit: Client closed]
sh1r4s3 has joined #riscv
<conchuod>
arnd: If rmk doesn't like this stuff, is it possible to "exempt" 32-bit arm or is it a case of him just needing a bit of convincing?
duffolonious has quit [Ping timeout: 268 seconds]
duffolonious has joined #riscv
<arnd>
we'll see. So far, it should not be hard to exclude arch/arm/ from the series, but that's still about against the idea. I'm hoping for hch to chime in
<conchuod>
Exempting an arch seems, to my naive pov!, contrary to the point of the series since if arm needs some special consideration for xyz drivers then other archs would surely need them too.
MaxGanzII has quit [Ping timeout: 255 seconds]
duffolonious has quit [Ping timeout: 260 seconds]
duffolonious has joined #riscv
jacklsw has joined #riscv
sh1r4s3_ has joined #riscv
sh1r4s3 has quit [Read error: Connection reset by peer]
<conchuod>
Yeah, it says 10/03 but I don't think it was public since 10/03
<conchuod>
10/03 being 10/Mar
<palmer>
sometimes it's in a middle ground: it's public on the website, but hasn't been announced yet
<conchuod>
Also, think something is broken on my D1 between 6.1-rc4 and for-next
<palmer>
conchuod: I guess that's not super surprising, we don't have any upstream testing. We were supposted to get someone in-house to manage a board farm, but it fell through so we're probably not going to fix that for a bit
<palmer>
Evan has a D1 and is benchmarking his hwprobe patches on it, maybe he's got a working setup?
<conchuod>
Icicle works fine upstream ;)
<palmer>
ya, but that's because it's tested ;)
<conchuod>
I'll just go bisect this
<palmer>
cool
<palmer>
IIRC he had some config/DT related issues, might just me something changing there
<conchuod>
He's not here I suppse
<palmer>
if he is it's not autocompleting...
<palmer>
I'll bug him on Slack and see
jobol has quit [Quit: Leaving]
jacklsw has quit [Read error: Connection reset by peer]
lagash has quit [Ping timeout: 252 seconds]
<palmer>
conchuod: Evan has some DT diff he needed to get his to boot
<geist>
Question that's not really obvious in the sifive manuals for their various boards
<geist>
seems that the RDTIME instruction is basically a pseudoinstruction that reads from CSR 0xc01 (time)
<conchuod>
Tell him to get on here ;)
<conchuod>
DT diff sounds very odd, should not need one
<geist>
but then it says "Generates an illegal instruction exception. The mtime register is memory mapped to the CLINT register space and can be read using a regular load instruction."
<geist>
so that smells like the intent is that opensbi traps and emulates that?
<palmer>
geist: it's just not implemented, M-mode handles the trap
<geist>
fuuu....
<palmer>
conchuod: might just be a slightly different flavor of the board
<palmer>
geist: yep, it's a mess
<geist>
i guess it's specced such that some implementations *could* implement that CSR but they just dont
duffolonious has quit [Ping timeout: 248 seconds]
<palmer>
it's RISC-V, vendors can do anything they want any time they want
<geist>
the amount of 'we'll silently emulate this in firmware' is infuriating
<palmer>
yep
<geist>
since you can't easily design around whether or not it's going to be incredibly expensive or not
duffolonious has joined #riscv
<geist>
doubleplus so since opensbi implementation doesn't seem to make an attempt to fast path anything. it does the standard 'dump all registers, call into C see what's going on' for every single exception
<conchuod>
palmer: f0bddf50586d ("riscv: entry: Convert to generic entry")
<conchuod>
:(
<conchuod>
Mounting my fedora nfs root fails after that commit
<palmer>
conchuod: that's the bisect first bad patch? that's going to be a PITA
<conchuod>
Eyup
<palmer>
presumably NFS still works in QEMU? I don't use it, and IIRC we had some other NFS-related issues
<conchuod>
I have no idea about QEMU, but I use NFS on all of my boards at home. I can try some of the others.
<palmer>
sweet. Hopefully it can at least repro somewhere else, anything D1-specific is going to be a nightmare
sh1r4s3__ has joined #riscv
duffolonious has quit [Ping timeout: 276 seconds]
duffolonious has joined #riscv
<palmer>
conchuod: also maybe post on the patch saying it's a bug? we can always revert something, but I think we'd need to drop that whole patch set and it touches a lot of stuff
<geist>
yup, just calculated about 376 cycles per rdtime instruction on this visionfive 2 (running linux)
<conchuod>
Yah, gonna try repro elsewhere first
<palmer>
conchuod: awesome, thanks
<palmer>
geist: I'm actually surprised it's that small, I'd guess well over 1k
<geist>
ageed. assuming the rdcycle instruction is giving me something valid, but it's very consistent
<geist>
also wall time seems to be about 250ns per iteration. so i guess the cpu is running at 1.5ghz or so
<palmer>
rdcycle is actually a fine proxy for rdtime on most of these boards, anything SiFive-based can't do DVFS so they're the same. You might have some issues with hopping between cores, though (depending on how the cycle counter is reset)
<geist>
yah i had to pin it to a particular core tog et consistent results
brazuca has joined #riscv
<geist>
all told it still makes sense to have user space use rdtime to get the time base but it's kinda a lie to user space, since it looks like it should be 'free'
<geist>
i have to look into the supervisor timer extension. if that's present i assume s mode gets direct access to a CSR with the time in it (stime maybe)
<conchuod>
palmer: fortunately, it reproduces.
<geist>
in which case then at least the kernel should aggressively use that
<palmer>
it's actually slower to rdtime than some of the Linux timers, those end up as read-only VDSO entries so it's just a function call
<palmer>
conchuod: awesome, can you post to the thread? I'm not opposed to reverting it if it's broken, but maybe we'll get lucky and there'll be a simple fix.
<geist>
on linux, yeah. i assume that the coarse grained 'time based on some variable i've updated' that linux has would
<conchuod>
The annoying part is that the issue is not exactly the same w/ the other board & defconfig, but yah
<palmer>
geist: if you're in some RTOS or watever, you can just load mtime directly
<palmer>
just make it readable to U-mode via PMPs
MaxGanzII has joined #riscv
lagash_ has joined #riscv
Stat_headcrabed has joined #riscv
Stat_headcrabed has quit [Client Quit]
<conchuod>
palmer: Evan's patch makes sense now that I see it, but should not be needed. The firmware shoulda filled that in...
<conchuod>
smaeul intentionally did it that way
<palmer>
ya, that's why I asked him to just post the patch
duffolonious has quit [Ping timeout: 248 seconds]
<palmer>
something's broken, maybe it's just a user error but at least it's good to know what that error is ;)
<conchuod>
I replied to him w/ the history and a suggestion.
<palmer>
thanks
duffolonious has joined #riscv
<palmer>
he's got it booting and we just need this for the hwprobe experiments so it's fine, but nice to have something searchable in case someone else hits it
<conchuod>
yah, guess he won't be the only one that hits it
<mmind00>
conchuod: thanks for tracking down that nfs issue ... did systemd actually say what was failing in your case?
<conchuod>
mmind00: I don't think so. It either says journald failed to init, or /dev/ttyS0 never appears.
rvalles has quit [Ping timeout: 255 seconds]
<conchuod>
On my D1, it was ~always ttyS0. On my Icicle, it has been the journald thing from the log snippet always
<conchuod>
mmind00: Annoying bisection since -rc1 doesn't boot
raym has quit [Quit: kernel ypdate, rebooting...]
<mmind00>
conchuod: really? ... when I started bisecting I started at v6.3-rc1 and it did boot both in qemu and the d1 ... but maybe my config was different, so I didn't trigger the issue I guess
<conchuod>
Linus broke rc1
<mmind00>
bad Linus ;-)
<conchuod>
mmind00: Perhaps if you're running !SMP it is okay?
<mmind00>
conchuod: CONFIG_SMP=y ... now I'm really puzzled, why things did boot for me :-)
<mmind00>
no wireguard in my config ;-) ... so I guess I just never tripped the issue
<conchuod>
Nor mine!
rvalles has joined #riscv
rvalles has quit [Read error: Connection reset by peer]
rvalles has joined #riscv
balrog has quit [Quit: Bye]
balrog has joined #riscv
heat has joined #riscv
jmdaemon has joined #riscv
<geist>
palmer: ah just caught the thread re: adding unaligned allowed fields to the device tree
<geist>
wasn't aware that newer versions of the spec dropped the 'unaligned must always work' requirement. that just sort of fell off newer unpriviledged specs?
<la_mettrie>
hmm, are those external PLIC interrupts of jh7100 listed somewhere (which device causes what)
<la_mettrie>
(which device is related to which irq number)
wingsorc__ has joined #riscv
Leopold_ has joined #riscv
Leopold has quit [Ping timeout: 276 seconds]
duffolonious has quit [Ping timeout: 265 seconds]
duffolonious has joined #riscv
<Esmil>
la_mettrie: unfortunately i think the devicetrees in u-boot and the kernel are the best available info. they didn't get to release documentation on the jh7100 for that before their efforts were redirected at the jh7110
sakman has quit [Remote host closed the connection]
sakman has joined #riscv
sakman has quit [Remote host closed the connection]
sakman has joined #riscv
duffolonious has quit [Ping timeout: 265 seconds]
duffolonious has joined #riscv
wingsorc__ has quit [Remote host closed the connection]
wingsorc__ has joined #riscv
sakman has quit [Remote host closed the connection]
sakman has joined #riscv
pedja has quit [Quit: Leaving]
duffolonious has quit [Remote host closed the connection]
drewfustini has quit [Excess Flood]
duffolonious has joined #riscv
drewfustini has joined #riscv
MaxGanzII has quit [Remote host closed the connection]
MaxGanzII has joined #riscv
Andre_Z has quit [Ping timeout: 255 seconds]
EchelonX has quit [Quit: Leaving]
duffolonious has quit [Ping timeout: 255 seconds]
Armand has quit [Ping timeout: 252 seconds]
Armand has joined #riscv
duffolonious has joined #riscv
duffolonious has quit [Ping timeout: 248 seconds]
duffolonious has joined #riscv
MaxGanzII has quit [Remote host closed the connection]