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
zsun has joined #fedora-riscv
zsun has quit [Client Quit]
iooi_ has joined #fedora-riscv
iooi has quit [Ping timeout: 255 seconds]
iooi_ is now known as iooi
tg_ has quit [Quit: tg_]
<davidlt[m]> somlo: You should use this repository https://dl.fedoraproject.org/pub/alt/risc-v/repo/fedora/37/latest/ but note that technically such a large "update window" is technically not supported. Yet it usually worked with no or minimal effort.
<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]> It's more like ARMv8 -> ARMv9 stuff.
<javierm> gotcha
<davidlt[m]> RVA23 will (most likely) require vector, vector crypto, 64K page support.
<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]> This talk should provide a good picture: https://events.linuxfoundation.org/riscv-summit/program/schedule/
<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]> Here is a draft/discussions for OS-A SEE: https://docs.google.com/document/d/1X0TSbheEJjRGWhG2nzUnfIl_QcHWSuvd/edit
<davidlt[m]> psABI just got recently ratified, SBI is also ratified.
<davidlt[m]> I would expect Profiles to be the next bit.
<davidlt[m]> Cannot have Platforms spec without OS-A SEE spec too.
<davidlt[m]> SMBIOS, UEFI/ACPI stuff are external specifications, but things depend on those too.
<davidlt[m]> The old platform stuff is here: https://github.com/riscv/riscv-platform-specs
<javierm> davidlt[m]: cool, thanks again
<davidlt[m]> javierm: profiles are here: https://github.com/riscv/riscv-profiles
<davidlt[m]> Note this doesn't incl. RVA23 yet.
<davidlt[m]> But it lives in discussions and slides :)
<javierm> this talk https://www.youtube.com/watch?v=vcAVx8CV2fY&t=20s&ab_channel=hupstream seems to be quite interesting as well
<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> davidlt[m]: so many things missing still in mainline for the D1 https://linux-sunxi.org/Linux_mainlining_effort
<javierm> I wonder if even makes sense to join that effort or just consider this board an e-waste as you said...
<davidlt[m]> To my knowledge 6.0 or 6.1 should be enough to boot upstream.
<davidlt[m]> Well all the boards are e-waste, even the ones that are not yet available :)
<javierm> hehe
<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]> [PATCH v3 00/12] riscv: Allwinner D1/D1s platform support
<davidlt[m]> That's 6.3 material
<javierm> ahh, cool
<davidlt[m]> The drivers are all in AFAIK, this is just DTs.
<javierm> awesome. That page is not up-to-date then
<javierm> davidlt[m]: nice, that DTS patch series have been acked/reviewed so is just a matter of time as you said
<davidlt[m]> I might have landed in 6.2 I didn't check.
<javierm> davidlt[m]: but would had been in linux-next then
<davidlt[m]> I am not a fan of D1, but I am building distro and systemd doesn't like single core low-performance thing :)
<davidlt[m]> T-HEAD C910 is a different thing.
<javierm> davidlt[m]: with my fedora developer hat, I think that's good to have this for small IoT use cases
<davidlt[m]> Also the original D1 has a stuff that breaks RVI standards. IIRC it requires RISC-V Errata Framework to patch thing to work.
<davidlt[m]> Originally there wasn't even plan to have it supported upstream :) That's how it was.
<davidlt[m]> But HW is popular, cheap, highly available, ideas popped out how to do it.
<javierm> davidlt[m]: yeah, but as said. If it becomes a popular platform, it will make it even if is horrible :)
<javierm> which also happens on arm land
<davidlt[m]> So it requires CONFIG_ERRATA_THEAD_PBMT CONFIG_ERRATA_THEAD_CMO at least.
<davidlt[m]> Yeah, but it breaks RISC-V specs :)
<davidlt[m]> So it acts more like a test chip for some ideas :)
<javierm> davidlt[m]: what D1 (actuall T-head C906 right?) breaks is Svpbmt IIUC
<javierm> davidlt[m]: did https://lore.kernel.org/lkml/20220511192921.2223629-6-heiko@sntech.de/T/ ever land? I also can't find that in linux-next
<davidlt[m]> I think this goes via errata framework now
<javierm> I see
<davidlt[m]> That's CONFIG_ERRATA_THEAD_PBMT
<davidlt[m]> There is another 2 IIRC
<javierm> davidlt[m]: got it. That's the one you mentioned before
<javierm> everything moves so fast that a talk that's just a few months old is already obsolete :)
zsun has quit [Quit: Leaving.]
<javierm> davidlt[m]: so you are right, CONFIG_ERRATA_THEAD_PBMT and CONFIG_ERRATA_THEAD_CMO are the ones for T-head C9xx
<javierm> davidlt[m]: learned a ton today. Just what I wanted for this winter break. Thanks again!
tg has joined #fedora-riscv
esv has joined #fedora-riscv
<somlo> davidlt[m]: is there a newer disk image that matches the current https://dl.fedoraproject.org/pub/alt/risc-v/repo/fedora/37/latest/ repo? Or do you recommend simply duing a `dnf update` and hope for the best?
<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)
nirik has quit [Ping timeout: 272 seconds]
nirik has joined #fedora-riscv