<davidlt[m]>
sorear: not really, thus I can only mentioned my personal opinion.
<davidlt[m]>
The existing repositories for Fedora riscv64 would stay as-is for the next X years to support the current and yet to be released SBCs.
<davidlt[m]>
Once RVI decides on a new major profile (their "Public Name 2" thingie) and Platform specs are ratified we decide what is the new baseline, but that would be a different repository.
<sorear>
link for "Public Name 2"?
<davidlt[m]>
The current old Platforms draft says that compliant platform needs to be RVA22. RVA22 is a minor profile and thus RVI doesn't expect all the distros to support it.
<sorear>
the current platforms draft is a confusing mix of promises from a platform vendor to an OS and promises from a core/SoC vendor to a platform integrator, I hope it gets straightened out before ratification
<davidlt[m]>
I think the current Platforms specs is abandoned. We have now separate specs for ACPI, Boot and Runtime services (used to be called OS-A SEE), etc.
<sorear>
the profiles spec is also non-monotonic in some annoying ways (RVA20 MUST NOT implement Svadu, RVA23 MUST implement Svadu, you can't do both)
<davidlt[m]>
Svadu is under optional extensions for RVA23.
<davidlt[m]>
It's not mentioned for RVA20 or RVA22.
<sorear>
it's mentioned in RVA20 as "Svade"
<davidlt[m]>
Google is starting with RVA22 + Vector + Vector Crypto (which is technically not part of RVA22 profile, but profiles aren't blocking you from implementing extensions that aren't conflicting with existing stuff in profile).
<davidlt[m]>
Why it has a different name?
<sorear>
Svade means "Svadu behavior with HADE=0"
<sorear>
and doesn't allow HADE=1
<sorear>
rva23 *s* 64 having svadu as optional also doesn't make sense because HADE is a M-mode configuration bit
<davidlt[m]>
did you file an issue?
<davidlt[m]>
I would expect to see RVA22 announcement in December during RISCV Summit, or maybe early in 2024.
<davidlt[m]>
"Android Features" , which is post RVA23, well let's say RVA24 is MAJOR. RVA23 is NOT!
<davidlt[m]>
And why the hell we need more magic strings ("Public Name X") if we already have RVAXY.
<davidlt[m]>
So yeah, I want to wait a bit, and see what is next MAJOR one. What things is picked in Platforms spec. What thing is implemented by the vendors.
<davidlt[m]>
But again existing stuff stays as-is for some time to support whatever folks have, will have and are able afford.
<sorear>
[meta point: if I want a cheap sbc or a high-performance laptop, I'd get something aarch64 from an established vendor. risc-v's unique selling proposition is its low barrier to entry for new vendors and academic implementations, and my priorities revolve around making sure that selling point isn't lost while other risc-v users chase the established markets. I recognize others have different priorities]
<davidlt[m]>
rwmjones: probably, not sure. I haven't done those or heard.
<davidlt[m]>
I don't know what's cooking in openkoji.iscas.ac.cn or PLCT Lab, or what exactly is being cooked by Fu Wei.
<davidlt[m]>
He or/and PLCT Lab definitely are working on doing these custom images for the board (like MilkV Pioneer), or even porting Fedora/RISCV to 32-bit IIRC.
<davidlt[m]>
I know very little of that.
<davidlt[m]>
I think they are using fedora.riscv.rocks repo in their Koji, configured as external one.
<davidlt[m]>
I have started a sync for golang* packages. Maybe some are unblocked now.
<davidlt[m]>
I have imported 7 fixed packages from the earleir days.