<davidlt[m]>
Conan Kudo: Ventana is just one player. There will be more. RISC-V server race started some years ago with the first fruits slowly showing up.
<davidlt[m]>
If things will go as with arm64 I would expect 2nd or 3rd generation to be the one that could be interesting to customers. Again, based on personal experiece.
<davidlt[m]>
Any 1st gen hardware deployments are typically just to play, measure, benchmark, port, etc. Nothing serious.
<davidlt[m]>
Once the company/vendor shows that they can keep delivering on roadmap that's then this becomes interesting.
zsun has joined #fedora-riscv
<davidlt[m]>
Regarding Sipeed T-HEAD C910 stuff. I highly like it, especially with a cluster board (which should have BMC on it too). There is always a question of software support, which I doubt will come from the vendor.
<davidlt[m]>
VRULL and other have been working on upstream stuff thus in general it should be OK.
<davidlt[m]>
Ventana should be an easy buy based on software support. That's my expectation.
<davidlt[m]>
And Sipeed is still an e-wasted as it's pre-standards (which are not finished).
<javierm>
davidlt[m]: that's so sad since the sipeed lichee rv form factor is great
<davidlt[m]>
Yeah, it's really nice.
<davidlt[m]>
Well, TBD. Let's be real, we will only know after some time it ships ;)
<javierm>
davidlt[m]: what do you mean? Once the standards are finished ?
<javierm>
or if upstream linux would be willing to support it even when not standard?
<davidlt[m]>
Well RISC-V Profiles are not ratified that. Platforms are not finished. OS-A SEE (Supervisor Execution Environment). There are a few more.
<davidlt[m]>
CPU vendors will build SoCs/CPUs based on what profiles and other specs.
<davidlt[m]>
What do you expect in the silicon. How do you talk to the firmware. What are the interfaces. Similar stuff.
<davidlt[m]>
All of that has not yet been ratified.
<javierm>
davidlt[m]: so it may be that the D1 could be retrofitted to meet a profile?
<davidlt[m]>
There will be compliance and majority of existing hardware probably will not go through that.
<javierm>
kind like SystemReady-IR allowed to support machines that didn't have proper EFI support
<davidlt[m]>
Well, D1 already has stuff that's not based on RVI standards ;)
<davidlt[m]>
So RVA20U64 is basically today's profile. D1 would meet those requirements.
<davidlt[m]>
But platforms wise probably not.
<davidlt[m]>
The main profile that most folks worked on for maybe 2 years is server.
<davidlt[m]>
That means UEFI, ACPI, SMBIOS, etc.
<javierm>
davidlt[m]: I see. But then again probably the profiles would be for OS vendors to support, upstream though could choose to be more flexible and support it anyways
<davidlt[m]>
D1 will not have that.
<davidlt[m]>
Yeah, but in that case we have armv7/armv8 SBC mess.
<javierm>
kind like let's say RHEL only supports SystemReady-SR for aarch64 but Fedora and mainline Linux could support SystemReady-IR
<javierm>
or even whatever + DTB
<davidlt[m]>
At some point there will be a platform definition to embedded stuff (that work definitely started IIRC), but most focus is on server.
<javierm>
IOW, probably you would never ship RHEL or SUSE Enterprise Server in D1 but could run Fedora or OpenSUSE
<davidlt[m]>
We don't really want to have different Fedora or CentOS or whatever for each vendor.
<davidlt[m]>
So technically nothing really stops that as today (and probably in the future) there will be no proper profile check within kernel or/and glibc (not 100% guaranteed thing).
<davidlt[m]>
But thing like optimized binaries via glibc hwcaps would most likely work based on profiles, same as x86_64-{v2,v3,v4} stuff.
<davidlt[m]>
And most exciting stuff beings with RVA23U64.
<javierm>
makes sense. I guess that if a platform is popular enough, upstream would support it. e.g: rpi or the Apple M1
<davidlt[m]>
Running RVA20 on a modern hardware would be a significant performance loss.
<javierm>
I see... reminds me of the hard-float soft-float days of armv7
<davidlt[m]>
Like two companies already announced new core IP that will comply with RVA22 (and maybe RVA23 in the future, I guess).
<davidlt[m]>
RVA22 requires bitmanip (which alone is huge bump in perf in some workloads). Scalar rypto (functions, random number stuff, etc.). Hypervisors.
<davidlt[m]>
RVA23 is the next "major" ISA revision.
<davidlt[m]>
Or in other words a good starting point for RISC-V to get into "advanced" markets (smartphones, cars, tablets, computers, routers, storage, etc.)
<davidlt[m]>
Not just a tiny core acting as a co-processor somewhere on NVIDIA GPU :)
<javierm>
davidlt[m]: thanks for all this info. Do you know of a site where all this is described so that I can learn more?
<davidlt[m]>
Intel/SiFive Horse Creek is RVA20 + bitmanip, JH7110 from StarFive also incl. bitmanip (not actively advertised, needs some testing for sure too).
<davidlt[m]>
RVI mailing lists that are public. Also mostly RISC-V Summit 2022 videos once those are on YouTube.
<javierm>
davidlt[m]: awesome. Thanks!
<davidlt[m]>
Another important spec is IOMMU that is WIP.
<davidlt[m]>
So I wouldn't be surprised that Ventana VT2 (which will incl. vector stuff) will claim specific profile implementation (RVA22 + optional or RVA23).
<davidlt[m]>
They do have Tianocore UEFI on existing stuff thus platform stuff shouldn't be too hard once that is ratifed.
<davidlt[m]>
Yeah, Drew has a bunch of these that are good intro guide and kinda "what's cooking" too.
<davidlt[m]>
Note, that Platforms stalled right now. I wouldn't be surprised if that gets rebooted.
<javierm>
davidlt[m]: platforms is stalled. But SBI is still on-going ?
<davidlt[m]>
Yeah
<davidlt[m]>
Well, SBI is ratified (still evolving).
<javierm>
I see
<davidlt[m]>
Like some things were forked off to OS-A SEE.
<davidlt[m]>
At least some time ago there was rules that working group is required to produce the specification within X months otherwise it's disbanded, and process starts again.
<davidlt[m]>
Not sure how things work today.
<davidlt[m]>
Also Platforms in general depend on a number of other internal or/and external specifications, thus it will be the last bit to happen.
<javierm>
risc-v is not boring for sure then :)
<davidlt[m]>
Yeah, the goal is that everything will be standardised. Embedded or Server, etc.
<davidlt[m]>
Thus the software (e.g. OS) would know what to target, what to expect, what are the interfaces, etc.
<davidlt[m]>
And thus multiple Linux distributions will be able to boot and work on multiple RISC-V systems, like servers.
<javierm>
but maybe everything from drivers POV is there and can be booted using a firmware provided DTB ?
<davidlt[m]>
Once you can buy a hardware that has some platform sticker, and it passed compliance tested you have a proper RISC-V system based on standards :)
<davidlt[m]>
I think there is a patchset with a bunch of D1 based SBCs. Probably didn't land yet.
<javierm>
davidlt[m]: I see. I'm currently booting using smaeul tree
<davidlt[m]>
That one has just /boot and / (no firmware partitions)
<somlo>
thanks! Let's see if I can side-load any of that into qemu (once I figure out how to do that, I can also load it on LiteX+Rocket
nirik has quit [Ping timeout: 268 seconds]
nirik has joined #fedora-riscv
<somlo>
davidlt[m]: any idea why f37 would get stuck on "Failed to start [...] Accounts Service." ? https://imgur.com/a/KiYTBc4
<somlo>
got it to boot in qemu, but it's refusing to move past that error...
khrbt_ has joined #fedora-riscv
khrbt has quit [Ping timeout: 256 seconds]
<somlo>
(it's `accounts-daemon.service`, and somewhere a bit earlier it says "See 'systemctl status accounts-daemon.service' for details" :) I would, if I could, but it never allows me to actually log in and poke around...
<somlo>
might have something to do with graphics mode (a.k.a. runlevel 5)? Maybe I should figure out how to get it to default to text-mode (runlevel 3 equivalent)
<somlo>
wondering how one can brute-force `systemctl set-default muli-user.target` with access to only the mounted "/" partition (i.e., what symlinks are created/deleted modified where) :)
<somlo>
\o/ -- got f37 to boot in qemu (fixed accounts-daemon issue by adding "systemd.unit=multi-user.target" to the kernel command line)