<davidlt[m]>
Is there are COPR repo with QEMU RC versions?
<davidlt[m]>
virt-preview does not deliver RC versions for 7.2.0
davidlt_ is now known as davidlt
<davidlt[m]>
Ah, the final 7.2.0 might happen today.
<varlad[m]>
@davidlt#1901 Any idea when riscv64 will be available in COPR as an architecture?
<davidlt[m]>
varlad: no idea, but I don't expect it to happen anytime soon. Mostly due to lack of proper hardware.
<varlad[m]>
davidlt[m]: I guess the SBCs available currently are not good enough?
<davidlt[m]>
Yes, those are not a proper server thus are not plug & play.
<davidlt[m]>
and again there are no standards based hardware in general, because the standards don't exist yet too.
<varlad[m]>
Ah, standards?
<davidlt[m]>
Yeah. psABI just got ratified. RISC-V Profiles are frozen. OS-A SEE, Platforms, etc.
<davidlt[m]>
None of existing (or near future) hardware is compliant to what we want.
<varlad[m]>
Ah darn...
<varlad[m]>
I thought just having a powerful enough device would cut it xD
<davidlt[m]>
There are a bunch of standards being worked on and ratified that are required for software/firmware/distros/etc. There are also the other set needed for distros, but are bit targeting HW like IOMMU.
<davidlt[m]>
Yes, and no.
<davidlt[m]>
If that hardware is in a form of SBC it's not enough.
<varlad[m]>
davidlt[m]: So whats the target?
<varlad[m]>
Fedora does target other SBCs right? Like ARM based ones
<davidlt[m]>
Yeah, but infrastructure doesn't run on them.
<davidlt[m]>
Those are true certified powerful servers with BMC, etc.
<varlad[m]>
Ah true...
<varlad[m]>
So I guess Fedora for RISCV when it sees server use or desktop use?
<varlad[m]>
* it sees popular server use
<davidlt[m]>
We target everything. I have been running RISC-V desktop for years now.
<davidlt[m]>
But future is not defined, but at some point we will go towards standards based systems I would assume.
<davidlt[m]>
I am not even sure that Fedora will run on current SBCs in the future.
<davidlt[m]>
riscv64 today is RV64GC (or probably RVA20U64 profile; once ratified).
<davidlt[m]>
This month we probably gonna get RVA22U64, but that's a minor change.
<davidlt[m]>
RVA23U64 (to be defined in early 2023 [I wonder if that will happen]) is the next "major" one.
<davidlt[m]>
Think about it like ARMv8 -> ARMv9.
<varlad[m]>
davidlt[m]: But that mostly depends on mainline support right?
<varlad[m]>
Fedora can provide a RISCV64GC iso and it'll run wherever mainline support exists or something right?
<davidlt[m]>
So the thing is that majority of standards based hardware will be based on RVA22 (or/and RVA23).
<davidlt[m]>
Two companies already announced core IP with compatibility with RVA22.
<varlad[m]>
Oh?
<varlad[m]>
SiFive's cores and Xuantie's new one?
<davidlt[m]>
So we could do two arches, or switch to the most recent one because there aren't a large user base yet.
<davidlt[m]>
Yes, like SiFive P670.
<davidlt[m]>
armv7 was a mess, aarch64 is somewhat better, but still a mess.
<varlad[m]>
Ah, by the way, they both rock proper support for V extension 1.0
<varlad[m]>
Any idea about an SBC which uses them? xD
<davidlt[m]>
riscv64 is a mess too right now, but there aren't too much users, etc. Thus we might want enforce standards when moving towards a primary arch status.
<davidlt[m]>
Nope. I don't think there is any.
<davidlt[m]>
It typically takes 1-3 years after announcement.
<varlad[m]>
:(
<davidlt[m]>
For example, Intel/SIFive Horse Creek (not yet announced/released) is already quite old.
<davidlt[m]>
It's P550. We already had P650, P670, and probably something else will come by the time folks get P550 in their hands.
<varlad[m]>
But isn't VisionFive 2 P650?
<davidlt[m]>
So this train from IP announcement to a product (especially SBC) takes years.
<davidlt[m]>
No, that's U74MC. Similar to Unmatched/FU740 just few years newer IP.
<davidlt[m]>
So new features, new performance/area/etc. optimizations, errata fixes, etc.
<varlad[m]>
Ah :<
<varlad[m]>
(Although all everyone announces is new cores for some reason...) :<
<varlad[m]>
On the other hand, there's always a good chance that a new player will announce something put of nowhere right? :P
<varlad[m]>
Still got nothing on Dubhe xD
<varlad[m]>
s/put/new/
<davidlt[m]>
Yeah, there are loads of companies working on various things.
<davidlt[m]>
Remember that SBCs are making money. You are not gonna invest money to design IP and chips just for SBCs.
<davidlt[m]>
So there must be a larger market and some chips trickle down to SBC market.
<davidlt[m]>
rsync 0, rclone 1
<davidlt[m]>
managed to hit 95+MB/s with rclone
davidlt has quit [Ping timeout: 256 seconds]
davidlt has joined #fedora-riscv
jcajka has quit [Quit: Leaving]
jim-wilson[m] has joined #fedora-riscv
davidlt has quit [Ping timeout: 248 seconds]
<somlo>
davidlt[m]: on the rawhide-20220726 (f33) image, if I try and run mock using the provided `fedora-33-riscv64.cfg` configuration, I get a bunch of errors about `mirrors.fedoraproject.org/metalink/...` related to the riscv64 arch
Kevinsadminaccou has joined #fedora-riscv
<somlo>
which is not surprising
<somlo>
but then I wonder, is there a good way to build a srpm using mock on fedora-riscv64?