<davidlt[m]>
I never used this before, but I think they have cross-compile support for testing or something.
<davidlt[m]>
I was expecting to get VisionFive V2 today, but that's probably no so realistic. UPS changed their estimate to unknown.
fuwei has quit [Quit: Konversation terminated!]
<javierm>
somlo: what I do is to cross compile locally with ccache
iooi has quit [Read error: Connection reset by peer]
iooi has joined #fedora-riscv
davidlt has quit [Ping timeout: 268 seconds]
<somlo>
davidlt[m], javierm: thanks! I haven't tried anything yet, but I'm fairly confident I can cross-compile and get useful kernel and module files out of that
<somlo>
the `make install` part though, where the local (to the riscv fedora VM) dracut initrd image generation is done, I don't have a good idea about how to "accelerate" that on an intel host :)
<somlo>
and it's not even the 5-10 minutes spent running dracut on the riscv64 VM -- it's all the tar.gz-ing and/or rsync-ing between the intel host that did the compilation and the VM of the cross-compiled kernel and modules that's going to take 30+ minutes :)
iooi has quit [Read error: Connection reset by peer]
<javierm>
somlo: so what I do for aarch64 is basically the following: export ARCH=arm64 CROSS_COMPILE="ccache aarch64-linux-gnu-" && make -j16 Image modules && make modules_install INSTALL_MOD_PATH=/foo/bar
<javierm>
somlo: then you can rsync lib/modules/$kernel-version dir to your board and only run there kenrel-install add $kernel-version /lib/modules/$kenrel-version/vmlinuz
<javierm>
somlo: if is only a module, you can also do make M=drivers/foo/bar/ and just rsync that single foo-bar.ko to /lib/modules/$kernel-version/kernel/drivers/foo/bar/foo-bar.ko
iooi has quit [Read error: Connection reset by peer]
iooi has joined #fedora-riscv
fuwei has joined #fedora-riscv
iooi has quit [Read error: Connection reset by peer]
iooi has joined #fedora-riscv
fuwei has quit [Ping timeout: 260 seconds]
fuwei has joined #fedora-riscv
<somlo>
javierm: ok, that is what I had in mind too -- guess there's no way around rsync-ing it all over to the target (riscv, in my case) VM :)
<somlo>
but that's still going to be MUCH faster than building the kernel natively on the riscv qemu VM, so -- progress! :)
<somlo>
javierm: the context, in case you missed it a few days ago, is that a bunch of CONFIG_* options newly enabled in the stock fedora-riscv64 kernel cause it to crash during early boot, in weird ways, on my "exotic" litex+rocket based "computer"
<somlo>
and I need to build the kernel *many times* with various subsets of these options turned on/off to even figure out *which one* is the culprit, before I can try to understand *why* :)
davidlt has joined #fedora-riscv
fuwei has quit [Remote host closed the connection]
fuwei has joined #fedora-riscv
fuwei has quit [Ping timeout: 246 seconds]
fuwei has joined #fedora-riscv
fuwei has quit [Remote host closed the connection]
<davidlt[m]>
Do you know what's next? What else is blocking from things moving forward?
<Eighth_Doctor>
well, we have to backport it :)
<Eighth_Doctor>
so someone needs to make BZes for it in RHEL and Fedora
<davidlt[m]>
I wonder how do we get, for example, some subset of packages built for x86_64-v{2,3,4} and ready for glibc-hwcaps
<Eighth_Doctor>
Koji needs to be configured to let you build for those
<davidlt[m]>
One thing. glibc-hwcaps vs just having x86_64-v{2,3,4} repos.
<davidlt[m]>
Because glibc-hwcaps require to have libraries installed in a different location.
<davidlt[m]>
So the thing is that if all packages for f38 tag (just an example) are built for all x86_64-v{2,3,4} I can assemble a full Fedora for particular x86_64-v3 which is great for me (maybe 10% boost on average) :)
<davidlt[m]>
But if you only build 200-300 packages, or want to run x86_64 and just install x86_64-v3 openssl, gnutls, etc. these libraries need to go under subdir.
<davidlt[m]>
Subdirectories of glibc-hwcaps directories, in priority order:
<davidlt[m]>
x86-64-v3 (supported, searched)
<davidlt[m]>
x86-64-v4
<davidlt[m]>
x86-64-v2 (supported, searched)
<davidlt[m]>
Thus i wonder if we could have both worlds working, or it's just about having Fedora for multiple x86_64 variants (just different repos).
<davidlt[m]>
Conan Kudo: Is there an overall plan written somewhere?
<Eighth_Doctor>
nope
<Eighth_Doctor>
mostly because there's no plan :)
<davidlt[m]>
I guess RPM doesn't have a way to know where libraries will be installed too.
<davidlt[m]>
Traditional directory or glibc-hwcaps subdir.
<davidlt[m]>
I guess some post-install scripts would get broken too if they don't take that into consideration.
<davidlt[m]>
So this was kinda building it 4 times within the rpmbuild
<Eighth_Doctor>
yeah openSUSE has been doing this
<davidlt[m]>
So that would have worked
<davidlt[m]>
Somehow I would expect in Koji to do 4 separate builds instead.
<Eighth_Doctor>
openSUSE has an... interesting approach to rpm macros
<davidlt[m]>
OpenSUSE stuff also focused on glibc-hwcaps only.
<Eighth_Doctor>
they do tons of package generation stuff for Python, Ruby, etc. too
<davidlt[m]>
Well wait, technically glibc-hwcaps capable packages could also be used to assemble full distro. It's just that /usr/lib64 would be empty (most likely) expect some dirs
<Eighth_Doctor>
yep
<Eighth_Doctor>
it's basically multilib all over again
<davidlt[m]>
I would love to have both worlds (if possible). glibc-hwcaps optimized libraries (if the user wants) + full distro.
<davidlt[m]>
Conan Kudo: I would expect this to map with RISCV Profiles, and performance difference here would probably be higher compared to x86_64 stuff.
<davidlt[m]>
x86_64 -> x86_64-v3 boost vs. RVA20 -> RVA23 boost in perf.
<Eighth_Doctor>
I think RISC-V is going to necessitate us to have a multilib strategy
<davidlt[m]>
The thing is that HPC (i.e. enterprise) will loose quite a lot of perf (most likely, don't have numbers to share) if it stays on RVA20.
<davidlt[m]>
Yet we don't do multi-lib, and we don't do CONFIG_COMPAT too.
<davidlt[m]>
Once we have standards, a lot of folks will be stuck with cheap SBCs that will be on RVA20.
<davidlt[m]>
We end up with two different worlds.
<Eighth_Doctor>
IMO, one of the biggest mistakes we made with ARM was not figuring out how to unify all the worlds
<Eighth_Doctor>
and it seems like RISC-V is making this mistake even worse
<davidlt[m]>
It's growing pains :) There is no way to properly avoid this.
<davidlt[m]>
Standards only arrive once there are a good amount of companies that are interested in markets that require standards ;)
<davidlt[m]>
So yeah, standards are/will be 10-12 years late after RISCV happened.
<davidlt[m]>
RISCV Profiles just locks ISA stuff for us. We still don't have RISCV Platforms (which goes beyond ISA).
<davidlt[m]>
It's years (if at all) before SBCs will comply will all what's expected.
fuwei has quit [Ping timeout: 255 seconds]
<davidlt[m]>
Yet-to-be-released SiFive/Intel HiFive Pro P550 is sometime in summer 2023.
<davidlt[m]>
That's P550. There is already P650, now P670 (RVA22 compatible if ratified as-is).
fuwei has joined #fedora-riscv
<davidlt[m]>
By the time HiFive Pro P550 is available we are probably 3 generations away from latest core IP.
<davidlt[m]>
Simply put hardware lags behind by years. Combine that with standards and things take a really long time.
<davidlt[m]>
There are too many individual extensions. So that's no go. RISCV Profiles at least narrows that down, and gives us minor and major profiles.
<davidlt[m]>
We could technically skip minor ones (but not now).
<davidlt[m]>
Conan Kudo: I could make a mailing list thread, but I doubt it would go anywhere. Somehow I expected some kind of existing plan.
* Eighth_Doctor
shrugs
<javierm>
davidlt[m]: armv7 SBC never did comply with any SystemReady spec, not even SystemReady-IR
<javierm>
so I guess the cheap SBCs with RVA20 won't ever do it either
<davidlt[m]>
javierm: that's "fine" as long as we can support both worlds, and not to take a large portion of performance from enterprise hardware (and in general newer hardware).
<javierm>
davidlt[m]: yeah, my guess is that both RVA20 and RVA22 + lowest common denominator for extensions would be kind like we had for armv7 and armv8
<javierm>
even though both are riscv64
<davidlt[m]>
RVA22 is minor, stop gap, RVA23 is major.
<davidlt[m]>
The original plan was to have these profiles every 2 years, but industry moves in a different speed :)
<javierm>
davidlt[m]: right, I meant RVA20 and RVA23 then :)
<davidlt[m]>
Each profiles has optional extension (just a few(
<davidlt[m]>
s/(/)/
<davidlt[m]>
Like some (well, many) RVA optional bits become mandatory in RVA23.
<davidlt[m]>
Most likely vector, vector crypto, etc. becomes mandatory in RVA23.
fuwei has quit [Ping timeout: 268 seconds]
fuwei has joined #fedora-riscv
iooi has quit [Read error: Connection reset by peer]
iooi has joined #fedora-riscv
fuwei has quit [Ping timeout: 268 seconds]
fuwei has joined #fedora-riscv
iooi has quit [Read error: Connection reset by peer]
iooi has joined #fedora-riscv
iooi has quit [Read error: Connection reset by peer]
iooi has joined #fedora-riscv
<somlo>
davidlt[m]: what's a (the?) "canonical" link for "Fedora on risc-v"? Like, if one were to name-drop Fedora in a presentation or document and wanted to add a URL as "citation" ? :)