<cwt[m]>
> Even with these big memcpy speed-ups for RISC-V, GNU's Glibc is still showing much faster RISC-V memcpy results. In some cases the Glibc memcpy performance on RISC-V is still twice as fast as the new optimized implementation with LLVM libc.
<davidlt[m]>
Yeah, I posted it some time ago.
<davidlt[m]>
I don't think anyone is using libc from LLVM.
jcajka has quit [Quit: Leaving]
<davidlt[m]>
Fail rate for builds increased as it hit KF5.
<davidlt[m]>
It seams I will have another round of this KF5 and probably KDE.
<davidlt[m]>
Koji still states 242 successful builds for 1 day.
<davidlt[m]>
rwmjones: I just check, and I probably lied, there is (or no more) "opensbI" (stable) and it's just "opensbi-unstable"
<rwmjones>
ok
<davidlt[m]>
So we probably should rename it as "opensbi", and change versioning to something more reasonable, maybe git describe, or git short commit.
<rwmjones>
and uboot-tools ..?
<rwmjones>
yup
<davidlt[m]>
You cannot do it until opensbi is in.
<davidlt[m]>
That depends on OpenSBI, but changes are trivial.
<rwmjones>
let me check the spec files of these
<davidlt[m]>
That part is probably okay as-is, or might require small modifications.
<davidlt[m]>
It's relatively trivial.
<davidlt[m]>
Just note that this will change starting JH7110 support.
<rwmjones>
ok there is a uboot-tools package in Fedora already, but we've patched it in riscv
<davidlt[m]>
As load address for OpenSBI is different from others boards and QEMU.
<rwmjones>
or not
<rwmjones>
oh I see I'm looking at the wrong branch
<rwmjones>
I'll ping you when I have set up the review bug
<davidlt[m]>
I think reviews these days are mainly for Fedora packaging policies.
<davidlt[m]>
rwmjones: you might want to check/restart your effort for QEMU OpenSBI packaging.
<davidlt[m]>
We probably should take OpenSBI which is released with QEMU and package that too, and that should be used by default on QEMU like any other firmware.
<davidlt[m]>
For hardware we cannot rely on it, it's just always too old.
* Eighth_Doctor
wishes that we could get qemu also in EPEL de-conflicted from RHEL's qemu-kvm
<rwmjones>
ok
<davidlt[m]>
So basically 3 sub-tasks :)
<davidlt[m]>
(and if you want some true porting fun I posted a couple earlier today [small ones, I think])
<davidlt[m]>
But if you want more fun, there is probably a few 100s of packages that would require upstreaming SPEC changes too ;)
<davidlt[m]>
Well some of that will go away once a GCC build with libatomic fix lands.
<davidlt[m]>
if djdelorie board survives for another ~3 days to finish the build :)
<djdelorie>
I'm not going anywhere near it, just in case ;-)
<davidlt[m]>
I didn't start multiple of those as Jakub is already working on a new version.
<davidlt[m]>
Well, at least winter is gone too :)
<davidlt[m]>
rwmjones: it would be great if you could list me somehow as co-maintainer or something. That would be nice.