<davidlt[m]>
There was some work at it for 1 or 2 years already.
<davidlt[m]>
Mainly my Alibaba and PLCT Labs in China.
<davidlt[m]>
Smartphones with RISC-V are coming too :)
nirik has quit [Ping timeout: 268 seconds]
nirik has joined #fedora-riscv
davidlt has quit [Ping timeout: 260 seconds]
davidlt has joined #fedora-riscv
jcajka has joined #fedora-riscv
Esmil[m]1 has quit [Quit: You have been kicked for being idle]
<davidlt[m]>
In general RISC-V will be going in all directions as a direct replacement for ARMv9.
<davidlt[m]>
Well, it's 10 years already, but it's still considered "early days". Things continue to accelerate. There is already RISC-V in a lot of products and most folks don't even know that they have it. Highly embedded is in a lot of places, incl. NVIDIA GPUs.
<davidlt[m]>
The next major market is "OS-A" stuff. In general storage, compute, routing, accelerators, etc.
<davidlt[m]>
Smartphones probably will take a bit of time, but I don't really follow that area. I think it's moving at constant speed or slowly accelerating, but I might be wrong here.
<davidlt[m]>
There are videos from RISC-V Summit 2022, and you can watch Android related presentations already.
<davidlt[m]>
I think they listed next major milestones still required for Android.
<davidlt[m]>
Like missing thing incl. better atomics (I think, that's incoming), setting minimal requirements for Android word ISA wise (a profile?), numerics, bitmanip, J extensions, TLSDEC psABI stuff.
<davidlt[m]>
I think they also want virtualization working in HW.
<davidlt[m]>
I think Zjpm (pointer masking) and Zjid (instruction data consistency) were presented in the summit.
<davidlt[m]>
I don't think they were listed as optional for RVA23 profile (which is not yet set in stone, open discussions).
<davidlt[m]>
Zjpm probably would increase performance in Golang, OpenJDK and others that use bits in addresses to store information.
<davidlt[m]>
TL;DR I consider RVA23 to be a proper starting point for RISC-V. Most likely there will be RVA22 for a short time, but most of that should be short lived or some of them might be compatible with RVA23 too.
<davidlt[m]>
(and RISC-V is going directly against ARM; you want it or not)
<davidlt[m]>
and we should have a new psABI too, next year.
<davidlt[m]>
It took some time for this to picked up by wider audience.
<davidlt[m]>
Folks should stop using single letter extensions, those are kinda useless (at least for me).
<davidlt[m]>
What does B mean? There are 4 extensions under bitmanip.
<davidlt[m]>
Someone mentioned J, there are even more extension there and two seems to going forward.
<davidlt[m]>
Instead of waiting for years for some "full extension" to be good enough for everyone, there will be a lot of smaller ones.
<davidlt[m]>
Like a bunch of vector stuff (IIRC) got also separate extensions to be defined in the future or something like that.
<davidlt[m]>
Basically things are ready as soon as they are ready. All the engineers can continue to work on smaller things in parallel. We will get some new extension every year or so.
<davidlt[m]>
Within few years we will definitely get some Android phones with RISC-V on the main CPU cores. Most likely that will come from China.
<davidlt[m]>
IIRC the main contributors there are Alibaba and PLCT Labs (most likely there are more).
<davidlt[m]>
Alibaba even build Android dev kit like 1-2 years ago.
<davidlt[m]>
IIRC Alibaba uses Vivante GC8000UL. There was no upstream support initially, but the signals from community indicated that it was relatively easy to support.
<davidlt[m]>
This stuff was/is available on Aliexpress.
<varlad[m]>
varlad[m]: Feels weird that Huawei already has a consumer device running on RISCV out there!
<davidlt[m]>
Not really.
<davidlt[m]>
All NVIDIA GPUs incl. RISC-V cores. So are other devices too.
<davidlt[m]>
You might not know, but some devices you have already have tiny RISC-V cores in them.
<varlad[m]>
davidlt[m]: But thats... aghhh, debatable I guess, since NVIDIA is not even giving CPUs, and the CPUs they use are all ARM. xD
<varlad[m]>
Huawei's TV chips are full on RISC-V chips running an entire OS compiled to RISC-V :O
<davidlt[m]>
I think only Alibaba (T-HEAD), Allwinner (T-HEAD), Nuclei (their own stuff), StarFive (SiFive IP, but next one is their own) are all Linux capable.
<davidlt[m]>
Ah, also bouffalolab is also Linux capable IIRC.
<varlad[m]>
davidlt[m]: But no one's releasing an SBC into the market yet I guess....
<varlad[m]>
Any idea if someone is going for a RISC-V server?
<davidlt[m]>
So majority publicly known silicon capable of Linux is coming from Chinese vendors right now.
<davidlt[m]>
Oh yeah. Ventana announced their monster server chip.
<davidlt[m]>
There are more companies going for servers too.
<varlad[m]>
davidlt[m]: That but, there's also a LOT of new/not established yet names.
<davidlt[m]>
Ventana is CPUs can have up to 192 cores of OoO cores, high-perf, 3.6GHz.
<davidlt[m]>
Incl. PCI Gen 5, DDR5, etc.
<varlad[m]>
davidlt[m]: Having a RISCV cloud server would be nice.
<varlad[m]>
Do tell if someone is providing subscription access to capable enough RISC-V cloud servers. I can probably try :D
<davidlt[m]>
I believe only Alibaba Cloud is providing something like that.
<varlad[m]>
davidlt[m]: Are they even? Do you have a link?
<davidlt[m]>
Ventana is sampling mid' 23.
<davidlt[m]>
No idea. Never looked directly in what Alibaba Cloud offers, just remember their slides.
<varlad[m]>
Is anyone exploring the V extension for ML workload servers?
<varlad[m]>
davidlt[m]: You know, it'd be exciting if the CPUs they use actually got V extension 1.0 support. xD
<varlad[m]>
I remember Google but, its a locked ecosystem...
<davidlt[m]>
VT-1 doesn't have vectors, but VT-2 will have them (should follow soon).
<davidlt[m]>
Their CPUs also incl. CXL 2.0 IIRC.
<varlad[m]>
:O
<varlad[m]>
davidlt[m]: That'd be really awesome. One year of wait huh.
<varlad[m]>
It'll be available for general public right? Not corpos only? xD
<davidlt[m]>
It's chiplet design, each chiplet with 16-cores. I think VT-2 or Veyron V2 will increase that to 32-cores.
<davidlt[m]>
I bet most of us will not be able to afford this :)
<davidlt[m]>
There will be a development platform with 16-cores (single chiplet?) but that is probably few Ks.
<davidlt[m]>
The 1st arm64 dev kit was like 3K USD IIRC.
<davidlt[m]>
It took quite some time (up to 2 years IIRC) for it to be few 100s of USD.
<davidlt[m]>
Basically below <1K USD.
<davidlt[m]>
Based on the specs this one probably be way more expensive.
<davidlt[m]>
(unless they plan to subsidise them)
<davidlt[m]>
It's TSMC N5 too. That's not a cheap node, especially for a startup.
<varlad[m]>
Ah well. It'll still be cool nevertheless.
<varlad[m]>
I'll try looking into what Alibaba offers.
<davidlt[m]>
For now StarFive new SoC will probably dominate SBCs. Good value option here.
<davidlt[m]>
Forget about the GPU and upstream support :) That's probably years away :)
<omac777_2022>
Wei Fu mentioned SophGo is making a Data Center RISC-V SOC as well. I was surprised to see it not presented the recent Risc-V summit considering it is a higher-end Data Center Risc-V offering.
<davidlt[m]>
Yes, it's T-HEAD too :)
<davidlt[m]>
It's 1520 IIRC.
<varlad[m]>
@davidlt#1951 Any idea if there's any alternative to esperanto et-soc-1?
<varlad[m]>
They're not using V extension there right?
<davidlt[m]>
Well, not 1520, it's T-HEAD C910 stuff.
<davidlt[m]>
Don't know.
<davidlt[m]>
I would suggest to not be too excited about HW that you cannot buy, or easily run.
<davidlt[m]>
JH7110 is almost here (seems it's shipping now). The company is upstreaming it. That's a lot easier to trust, and spend money on.
<davidlt[m]>
Same applies to Intel/SiFive and HiFive Pro P550.
<davidlt[m]>
Historically all SiFive boards got upstream support.
<davidlt[m]>
Sipeed might be a bit more difficult. There are a few individuals that are upstreaming, and even VRULL seems to be involved (hired by T-HEAD?).
<davidlt[m]>
SoC support is probably not a problem (at least to boot), but TBD.
<varlad[m]>
I wanted a board with good V extension support.
<varlad[m]>
Somewhat like the the C908? They're targetting AIoT applications if I remember correctly
<davidlt[m]>
C908 claims Vector 1.0 support.
<davidlt[m]>
It's one of two RVA22 compliant designs so far.
zsun has quit [Quit: Leaving.]
<omac777_2022>
I wish there was one consolidated place where we could go and discuss the different riscv hardware, distro issues, riscv images and instructions to install them/run them on hardware/run them on qemu. At the moment I'm only aware of some riscv fedora images, but the instructions for running them on qemu are only available for older fedora and not the later 37. For fedora riscv there's this
<davidlt[m]>
There is riscv channel on Libera.Chat, which is a great place for general discussions.
<omac777_2022>
Thanks davidlt. I'm very recent here. I did peruse through the entire history logs since September and yes there's traffic in here for sure. I do enjoy fedora discussion website, but it currently has less traffic with respect to riscv. I also go to that website for fedora silverblue stuff. I'm a silverblue fan and hope it will land on riscv as well.
<davidlt[m]>
This is most likely because there are no hardware to buy, especially at a decent price point. That basically leads to a very minimal user base.
<davidlt[m]>
JH7110 and TH1520 will probably increase user base and thus discussions should get more lively.
<davidlt[m]>
HiFive Pro P550 too, but that's probably a bit more expensive board.
jcajka has quit [Quit: Leaving]
<omac777_2022>
I'm right here if anybody wants me as a user to test building something and provide feedback.
omac777_2022 has quit [Quit: Leaving]
<neil>
davidlt[m]: in case I missed anything; has starfive said anything recently about shipping for the jh7110s?
<davidlt[m]>
neil: nope, but it seems some might be shipping.
<neil>
that's encouraging
<davidlt[m]>
neil: it seems the boards have been arriving for the last ~7 days or so.
* neil
checks his PO box furiously
<davidlt[m]>
Did you order the early or super early one?
<neil>
i did one super early and two early
<neil>
i'm allergic to FastEthernet :P
dtometzki has joined #fedora-riscv
<dtometzki>
hello together
<dtometzki>
Is it planned to support visionfive 2 ?
<davidlt[m]>
dtometzki: yes
<davidlt[m]>
dtometzki: StarFive Tech. has been upstreaming kernel, OpenSBI and U-Boot for some weeks already.
omac777_2022 has joined #fedora-riscv
<dtometzki>
great do you know when the first fedora image will be available ?
<davidlt[m]>
dtometzki: unknown, will depend on how upstreaming efforts go.
<davidlt[m]>
Right now we don't even have DT bindings approved, and those are still changing.
<davidlt[m]>
Once things start getting a bit more stable that's then I plan to start looking into it.
<omac777_2022>
"DT bindings"?
<omac777_2022>
Do you mean device tree (dtb)?
<davidlt[m]>
device tree bindings, kinda like ACPI tables that describe how HW works.
<omac777_2022>
thank you.
<davidlt[m]>
no, but related to that.
<omac777_2022>
From what I understand, they do have that in place. They have an image build with buildroot that you can install/run with. I can repeat their build steps successfully though.
<davidlt[m]>
Once these are approved we have a agreed "bindings" on how to describe that part of HW while writing DTS.
<davidlt[m]>
This is important considering that DTB (compiled DTS) is usually stored in the SPI-NOR Flash part of the firmware. Typically it does not get updated.
<davidlt[m]>
You still want to boot modern kernel even if firmware is a decade old. That works because there is an agreement on DT bindings.
<davidlt[m]>
The current DTB provided by StarFive Tech in their repos will not work with upstream kernel once things land upstream.
<davidlt[m]>
At least not all DT bindings are the same IIRC.
<dtometzki>
you will find all the files in the linux source under arch/riscv/boot/dts/starfive
<davidlt[m]>
Once we have these bindings / schemas defined a stable DTS will be committed into the kernel. That (with some modifications/overlays) will also be available in U-Boot.
<davidlt[m]>
Those are semi-regularly synced.
<dtometzki>
and in the u-boot source under arch/riscv/dts
<davidlt[m]>
For example, once we shipped SiFive HiFive Unmatched we kept SPI-NOR flash empty (i.e. no built-in DTB in some firmware). We knew that things wouldn't be stable for ~1 year.
<davidlt[m]>
Back with Unleashed DTB was shipped in the firmware, the problem was that community had to constantly try to support that old, not a proper DTB. That was done by patching it in OpenSBI in early days. Not a great thing.
<davidlt[m]>
TL;DR stable DT bindings are important for long-term support (especially if you want to upgrade kernel and reboot successfully).
<davidlt[m]>
On a OS-A Server platform that information is in ACPI, also in SMBIOS.
<davidlt[m]>
There are custom tables for RISC-V defined a few years ago, still being tweaked IIRC.
<dtometzki>
yes
<omac777_2022>
ok I found the stuff you are mentioning: root@carouselYOW:/visionfive2prep/VisionFive2# find . -name "jh7110.dts*" -print
<davidlt[m]>
IIRC none of StarFive DT bindings were approved yet (I might be wrong, 1 or 2 might have ACK already).
<davidlt[m]>
Most stuff is published that are needed to boot, but will take weeks if not months to land. Depends on how fast StarFive Tech can incorporate all the feedback.
<davidlt[m]>
PCIe was not yet posted, but it's WIP.
<davidlt[m]>
I suggested them to post a KS update, have some form of table (e.g. in their wiki) to point to these and incl. status.
<davidlt[m]>
Hopefully folks would direct all feedback directly to the patches instead of GitHub.
<omac777_2022>
I searched for bindings within what I fetched as part of the buildroot build steps: https://pastebin.com/Yd6KpTzD
<davidlt[m]>
Note, not all bindings will start with "starfive". Some of IP blocks are generic enough.
<omac777_2022>
Why are these files specifying JH7100 instead of JH7110? root@carouselYOW:/visionfive2prep/VisionFive2# cat ./work/buildroot_initramfs/build/linux-headers-JH7110_VisionFive2_devel/Documentation/devicetree/bindings/riscv/starfive.yaml
<omac777_2022>
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)