dgilmore changed the topic of #fedora-riscv to: Fedora on RISC-V https://fedoraproject.org/wiki/Architectures/RISC-V || Logs: https://libera.irclog.whitequark.org/fedora-riscv || Alt Arch discussions are welcome in #fedora-alt-arches
<PrathamPatel[m]> Most of the basic components are now merged in -next for 6.4
<PrathamPatel[m]> Mainline build in a few weeks! :D
<davidlt[m]> Yeah, new patchset was sent yesterday too for DVFS
<davidlt[m]> StarFive is gaining a lot of experience with upstream right now before JH8100-series arrive.
<davidlt[m]> Hopefully that one will go a lot faster (as a number of IP blocks probably will be re-used).
jednorozec has quit [*.net *.split]
skip77 has quit [*.net *.split]
javierm has quit [*.net *.split]
skip77 has joined #fedora-riscv
skip77 has quit [Changing host]
skip77 has joined #fedora-riscv
javierm has joined #fedora-riscv
jednorozec has joined #fedora-riscv
iooi has joined #fedora-riscv
jcajka has joined #fedora-riscv
<PrathamPatel[m]> In the recent Tenstorrent event in Bengaluru, they mentioned an 8-wide RISC-V core with big gains in int perf
<PrathamPatel[m]> That should be a great candidate for a build machine
<davidlt[m]> Oh yeah, that would be perfect, but it's most likely years away.
<PrathamPatel[m]> And that's Jim Keller, the guy who worked on AMD Zen and Apple M
<PrathamPatel[m]> Hold on, I clicked a few pictures
<davidlt[m]> It takes 3-5 years for a new thing from zero to silicon in your hands.
<PrathamPatel[m]> Should be in hands of consumers by 2024
<PrathamPatel[m]> At least the initial iteration
<PrathamPatel[m]> PrathamPatel[m]: Sorry, by consumers, I meant Tenstorrent's partners
<davidlt[m]> That's the one targeting 2025?
<davidlt[m]> Anyways, IIRC they are going for multiple-market chiplet design.
<davidlt[m]> That means they aren't making SoC directly and selling them.
<davidlt[m]> Thus basically it's up to some company X to order a specific design and bring it to the market (or just use internally for their own product(s))
<davidlt[m]> Like Intel and SIFive doing P550 Horse Creek thing using Intel process node.
<davidlt[m]> Or 64-core SOPGHO server SoC. That's Alibaba T-HEAD IP, but they aren't designing the SoC (or bringing it to market).
<davidlt[m]> SiFive has P650. P670 core IP, but no one is bringing that to public market.
<davidlt[m]> X280 is somewhat old, vector oriented design (e.g. for AI). Seems to have many design wins now, but still nothing on public front.
<davidlt[m]> Basically until you have it your hands it doesn't exist :)
<davidlt[m]> JH7110 exist now, upstreaming continue. JH8100-series is also incoming.
<davidlt[m]> TH1520 boards by Sipeed are close to be released. Pictures from the factory floor already exist. Those have C910 (from T-HEAD) which is OoO core.
<davidlt[m]> PINE64 is making a tablet with JH7110 too.
<javierm> davidlt[m]: problem with pine64 is that they just do the HW and expect the community to do the SW
<davidlt[m]> True, but we have StarFive working on JH7110 upstreaming, and PINE64 will not be way too different.
<davidlt[m]> I think T-HEAD situation is worse.
<davidlt[m]> It's fully community stuff. Just look what happened with D1.
<davidlt[m]> T-HEAD didn't upstream that. Allwinner did nothing too. Sipeed did nothing too just point you to the SDK/BSP.
<javierm> davidlt[m]: that's just for the SoC though, I've a fully functional rk3399 SBC but there are still a lot of stuff missing in my rk3399 phone, even when are 90% the same :)
<davidlt[m]> Alibaba has tons of engineers that are working on various kernel features for riscv. They are also actively working on other larger projects like OpenJDK, but not 3rd party SoC upstreaming which uses their IP.
<javierm> since the StarFive and the pine64 tablet have a different form factor, I expect that proper support will take a little bit
<davidlt[m]> It will depend mostly on how PINE64 implemented that.
<davidlt[m]> Most manufacturers would re-use a lot from a reference design (which probably is VF2 board).
<davidlt[m]> (or previous PINE64 products)
<davidlt[m]> Thus most of the work is probably just writing a proper DT.
<davidlt[m]> I still very proud of StarFive Tech. They decided to take this challenge and it took them 5-6 months to get the initial support.
<javierm> davidlt[m]: besides DT usually the problem are the peripherals that are not in an SBC but are in a tablet (e.g: display panel, camera sensors, ISP, radio modem, wifi, etc)
<davidlt[m]> But it landed for 6.4 kernel.
<davidlt[m]> As long as those parts have been used before all will be good.
<javierm> davidlt[m]: yeah, but are they? That was not the case for neither the allwinner based PinePhone nor the rockchip based PinePhone Pro
<davidlt[m]> Most of the things on my "RISCV PC" is working out-of-the-box, and I can watch 4K content on it even if it's a potato.
<davidlt[m]> Well that I don't know.
<javierm> what I'm tried to say is that people should be cautious about pre-ordering any pine64 product, in a way they want to leverage from the riscv momentum and make people buy a vey expensive paper weight :)
<davidlt[m]> Most of the stuff we have is e-waste anyway :)
<javierm> because booting to a serial console may be useful for a SBC but not that much for a tablet
<javierm> davidlt[m]: yeah, I learned my lesson with the sipeed D1 board. Although that support landed in v6.3 (or expecte for v6.4) after all :)
<davidlt[m]> Yeah, because of single person effort :)
<javierm> indeed
<davidlt[m]> The standards aren't ready yet for verified/certified platforms.
<davidlt[m]> RVA23 is to be ratified later this year.
<davidlt[m]> That will be a true start for RISCV.
<javierm> davidlt[m]: yeah, that's why I'm waiting to get another riscv board. Until I'm sure about what Fedora is going to support
<davidlt[m]> OS-A SEE, Platforms, are not yet ready too.
<javierm> is is RVA23 and nothing earlier, then I would know what to buy
<davidlt[m]> RVA23 itself it not enough. ISA wise that will be a new major base (and a true start for RISCV).
<davidlt[m]> But it's a component for Platforms.
<davidlt[m]> Platforms spec will combine a bunch of other specifications and define us a target Platform (e.g. OS-A Server).
<javierm> yeah I know, but even if is not something that I could just throw a Fedora riscv EFI image but at least the binaries would work because it has all the extensions, then it works for me
<davidlt[m]> OS-A SSE defines how we talk to the firmware, runtime services, etc.
<javierm> that is, I didn't mind to use armv7 boards even when I had to hack on the bootloader as long as the binaries would work
<davidlt[m]> In that case RVA23 is what you are looking.
<javierm> yeah
<davidlt[m]> Well depends. We probably will support RVA20 (RVA64GC) and RVA23, but that's something to be discussed.
<davidlt[m]> You really don't want to run RVA20 on top of RVA23.
<davidlt[m]> It's not like running x86_64 baseline on x86_64-v3 or v4 hardware where some things a slightly faster.
<javierm> of course is nicer to have SystemReady-IR compliant aarch64 boards but it took 10+ years to get there :)
<davidlt[m]> This would be a major performance loss.
<javierm> davidlt[m]: yeah, you basically target the common minimum right ?
<davidlt[m]> Yeah, RVI is very late here. We expected to have these problems, but without large companies it's hard to define the standards.
<davidlt[m]> Right now we target "RV64GC" (i.e. RVA20 profile), which is 10+ years old now.
<javierm> kind of how the distros used to support soft float armv7 binaries even when HW already supported hard float
<davidlt[m]> I don't think folks would like if I would suggest to change the baseline.
<davidlt[m]> Thus I don't want to change it. I would prefer to starts RVA23 as a separate arch.
<davidlt[m]> RV will have a train model, where every 1-2 years there will be a new profile. Some of these will be "major" profiles (e.g. RVA23).
<davidlt[m]> RVA22 is stop-gap solution, and we probably not gonna get a lot of SoCs with it.
<davidlt[m]> Only two companies announced RVA22 compliant core IP (one of them is SiFive with P670).
<davidlt[m]> That doesn't incl. non ISA specs too, like new interrupt controller, IOMMU, etc.
<davidlt[m]> For example Android will officially support riscv (that was already announced), but I doubt they will got for anything lower than RVA23 (they might require something even newer).
<davidlt[m]> Basically we have enough companies (and large companies) working on RISCV SoCs + momentum that we finally can agree on standards.
<javierm> davidlt[m]: cool
<davidlt[m]> I am not gonna lie, geopolitics and all the mess with ARM really helps a lot 😄
<davidlt[m]> It's crazy town and such companies as Intel and ARM are loosing longer-term.
<davidlt[m]> It's what Jim Keller said in one of this recent interviews. They went to ARM and asked for things, and ARM said no. They went to SiFive and they said "we can do it".
<davidlt[m]> AI (and other type accelerators) most likely will be a large driver for RISCV adoption.
<davidlt[m]> There are some things that didn't land in the initial vector spec, for example, matrix computations, graphics related stuff, etc.
<davidlt[m]> And I keep asking companies to focus on RVA23 stuff for a long time now.
<davidlt[m]> If you are working on some new core IP related to RISCV make sure you implement RVA23 profile.
somlo_ is now known as somlo
zsun has joined #fedora-riscv
alangm has joined #fedora-riscv
zsun has quit [Quit: Leaving.]
jcajka has quit [Quit: Leaving]
zsun has joined #fedora-riscv
zsun has quit [Client Quit]
alangm has quit [Quit: Leaving]
cyberpear has quit [Quit: Connection closed for inactivity]
iooi has quit [Quit: iooi]