<davidlt[m]>
rwmjones djdelorie did you ever get to play with PiKVM?
<rwmjones>
davidlt[m]: re vectors, probably not?
<davidlt[m]>
rwmjones: why not?
<davidlt[m]>
Ah, my question was formed as "disabled by default" :) So that's OK.
<rwmjones>
I mean, "by default"
<rwmjones>
we should definitely encourage them
<davidlt[m]>
There is a constant discussion about this for 1+ year now. Some thing vector will use a lot of power thus should be enabled explicitly (or by dynamic loader, or something) via a syscall per process, per task, or something.
<davidlt[m]>
There are some ideas to have CONFIG_* option.
<rwmjones>
the trouble with vectors is I guess a lot of "raspberry pi"-style SOCs are not going to have them for a long time
<rwmjones>
and that's an important target for Fedora
<davidlt[m]>
Again, with RVA23 and optimized str* and mem* function within libc (glibc) I expect almost all processes to be V enabled. Might not be all the tasks, but all the processes for sure.
<davidlt[m]>
It should work on those, but dealing with extra register states is what we are talking about.
<davidlt[m]>
Like SVE (arm64) has per task (within the kernel) a flag if task is actively using SVE/SVE2.
<rwmjones>
won't it just segfault everywhere on a SoC without V extension?
<davidlt[m]>
You can gain/loose that flag. The task gets the flag is it trapped on SVE instruction.
<davidlt[m]>
No, if we continue to be RVA20 or RVA22 + optional. It's all ifunc stuff.
<davidlt[m]>
So it works the same way as on x86_64. Again some suggest to do it like Intel AMX. The process has to use syscall to enable usage for it.
<davidlt[m]>
Our future/bigger issues is what do with "riscv64" regarding profiles.
<davidlt[m]>
RVA20 (the current stuff), RVA22 (T-HEAD and SiFive announced core IP with it), and RVA23 -- the next major ISA revision.
<rwmjones>
ok
<davidlt[m]>
Ventana VT1 is not RVA23 compatible (or will not be [most likely]), but VT2 will follow soon with vectors.
<rwmjones>
VF2 is RVA20?
<rwmjones>
Vision Five 2 I mean
<davidlt[m]>
Yes + bitmanip. Zba and Zbb IIRC.
<davidlt[m]>
So the next major thing is RVA23. Somehow I would love that to become default.
<davidlt[m]>
Remember RISC-V Profiles are not ratified yet. Platforms are not, so a lot of HW is e-waste.
<davidlt[m]>
If we want Fedora/RISC-V to require Platform OS-A compliance we will need to do something.
<davidlt[m]>
Like having a second RISC-V arch string to support some devices or something, I don't know.
<rwmjones>
what do debian think about all this?
<rwmjones>
personally I hate the whole armv7 subarchitecture thing
<davidlt[m]>
Don't know. Didn't ask too.
<davidlt[m]>
The thing is that RVA20 is just a toy, not gonna have a great perf on those enterprise HW.
<davidlt[m]>
ifunc and optimized function will help, BLAS, OpenSSL, etc. probably will have optimized *.so libraries and do dlopen().
<davidlt[m]>
RVA22 is a lot better, but it's a minor edition.
<davidlt[m]>
RVA23 is major one, and here to stay for a lot longer.
<rwmjones>
sure, but enterprise chips are a few years off yet and to get adoption we need to work on slow SBCs with minimal effort
<davidlt[m]>
True. Well Ventana is sampling this year IIRC.
<davidlt[m]>
I personally want to have a path for "future" and "legacy".
<davidlt[m]>
It's like saying Fedora will only support ARMv9 64-bit :)
<davidlt[m]>
I mean we don't exactly know how much we are loosing perf running RVA20 stuff on RVA22 or/and RVA23 hardware yet. Even if we have some optimized binaries, functions, etc.
<davidlt[m]>
IIRC bitmanip alone is a large enough impact (all 4 extensions are required in RVA22).
<rwmjones>
I don't know, but I think sticking with what people can buy easily now is the best plan
<davidlt[m]>
Today we don't have yet an agreed way to communicate to userspace all HW capabilties (HWCAP will not scale). There are no optimized functions, but there are optimized libraries already!
<davidlt[m]>
True. I don't want to alienate folks that have the hardware, but I do want to have a plan how to get the most perf in the future.
<davidlt[m]>
One way would be glibc-hwcaps, but Fedora is not ready even for x86_64-{v2,v3,v4} binary distribution.
<davidlt[m]>
So you cannot ask dnf to install OpenSSL compiled for x86_64-v4 to get best perf.
<davidlt[m]>
There are tickets opened for RPM to properly understand this, which is probably blocking everything.
<davidlt[m]>
rwmjones: will you be travelling to the FOSDEM?
<davidlt[m]>
I would expect a new RISC-V Profile every 1-2 (probably at the beginning every year). With every 2-3 years having a new major profile.
<davidlt[m]>
There is no expectation that distributions will support all profiles. I bet that's way there is major profiles. Those are like "LTS" stuff.
<rwmjones>
davidlt[m]: I've not really decided yet; I think kashyap is going however
<rwmjones>
it'll probably depend on how busy or not I am in the next few weeks
davidlt has quit [Ping timeout: 268 seconds]
davidlt has joined #fedora-riscv
<davidlt[m]>
Andrew Jones [OpenSBI mailing-list]: [RFC PATCH 00/11] SBI system suspend (SUSP) extension
<davidlt[m]>
It switched from org.freedesktop.portal.IBus interface to the "limited" org.freedesktop.IBus.Portal.
<davidlt[m]>
Maybe this will help someone too.
<davidlt[m]>
I think the only thing that was updated is ibus-typing-booster
<somlo>
I managed to boot f37 on my nexys_video board (4-core rocket @50MHz); on a single-core rocket (ecpix5 lattice based board), the serial-getty@.service times out on /dev/ttyLXU0 and I get no login prompt
<somlo>
I can ping the machine over the network, but ssh-ing in as `riscv` doesn't work either -- authentication happens, but I get kicked out immediately after that
<somlo>
I'm trying again with `TimeoutSec=infinity` added to serial-getty@.service, maybe if I make it try harder it will give me a console login prompt after all :)
<somlo>
... and it still timed out -- trying again with `TimeoutSec=0` (apparently different versions of systemd disagree on "infinity" vs. "0" for the "don't timeout" option) :)
<somlo>
actually it doesn't matter either way, it's "timeout waiting for device /dev/ttyLXU0", then "dependency failed for service serial-getty..."
<somlo>
probably a udev timeout issue *before* it gets to the systemd serial-getty service...
<davidlt[m]>
Oh, yeah, those systemd issues are epic to work on :)
<davidlt[m]>
somlo: most likely it's some form of systemd not liking slow system and single core.
<davidlt[m]>
You could try to mask out tty and see what happens.
<davidlt[m]>
Also SSH might not work if there is not enough entropy.
<davidlt[m]>
Like if you boot Unmatched or Unleashed you cannot login in as soon as boot happens.
<davidlt[m]>
In Fedora/RISCV we do have haveged enabled, which solves the problem.
davidlt has quit [Ping timeout: 272 seconds]
davidlt has joined #fedora-riscv
<djdelorie>
davidlt[m]: I have not played with PiKVM. I used a PI on the original sifive board but it was a hack; for the new board I just walk over to the keyboard/monitor :-)