dgilmore changed the topic of #fedora-riscv to: Fedora on RISC-V https://fedoraproject.org/wiki/Architectures/RISC-V || Logs: https://libera.irclog.whitequark.org/fedora-riscv || Alt Arch discussions are welcome in #fedora-alt-arches
omac777_2022 has joined #fedora-riscv
omac777_2022 has quit [Quit: Leaving]
davidlt has joined #fedora-riscv
<davidlt[m]> FOSDEM talks: https://fosdem.org/2023/schedule/events/
jcajka has joined #fedora-riscv
<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.
<rwmjones> davidlt[m]: re https://src.fedoraproject.org/rpms/ocaml/c/6fbb4db452cad948a903b0124d1c75f6b06a6833?branch=rawhide .. I'm not sure what I'm supposed to be looking for in that link?
<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]> SUSP extension proposal: https://lists.riscv.org/g/tech-prs/message/75
davidlt has quit [Ping timeout: 264 seconds]
dtometzki has joined #fedora-riscv
davidlt has joined #fedora-riscv
<rwmjones> nice, can't see drew's email address there, does it say he works at ventana?
<rwmjones> oh actually it's in the patch
<rwmjones> guess it's not a secret then :-)
<davidlt[m]> Oh no, that's not a secret for months now.
<davidlt[m]> He has been actively contributing for months now IIRC.
<rwmjones> it was certainly the worst kept secret if it ever was one :-)
* davidlt rebooting, new kernel!
davidlt has quit [Quit: Leaving]
davidlt has joined #fedora-riscv
jcajka has quit [Quit: Leaving]
<davidlt[m]> I was hit by the same issue but with Slack on Fedora: https://github.com/standardnotes/forum/issues/1105
<davidlt[m]> IBUS_USE_PORTAL=1 works
<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 :-)
<ol> <davidlt[m]> "rwmjones djdelorie did you..." <- I have Pi-KVM packages for Fedora and RHEL 9: https://obs.infoserver.lv/project/monitor/pikvm
<ol> I use Pi-KVM to manage my server/desktop computer using Raspberry Pi 4, Rocky Linux 9 and my packages.
davidlt has quit [Ping timeout: 246 seconds]
kalev has quit [Ping timeout: 264 seconds]
kalev has joined #fedora-riscv
kalev has quit [Ping timeout: 272 seconds]
dtometzki has quit [Remote host closed the connection]
dtometzki has joined #fedora-riscv
kalev has joined #fedora-riscv