07:42 <warren> I have a sifive unleashed. is this thing usable for anything?

07:42 <davidlt[m]> Not really (?).

07:43 <davidlt[m]> We have stopped running it, but it has upstream support which is great if you want to use riscv64.

07:45 <warren> this is the one that's not really usable without the expansion board, but the expansion board was super expensive?

07:46 <davidlt[m]> If you want PCIe and thus high speed IO you need it or an FPGA.

07:51 <warren> the hifive unmatched how was its CPU cores comparable to relative to ARM cores?

07:52 <davidlt[m]> terrible :) It's the super low cost smartphone level. ~A53 stuff.

07:52 <davidlt[m]> And then it depends on what you want. Cache and memory latency is exceptionally terrible.

07:52 <davidlt[m]> Memory bandwidth basically doesn't exist.

07:53 <warren> wow

07:53 <davidlt[m]> PCIe Gen 4 SSD on a traditional desktop system probably can move more data then FU740 to it's memory.

07:53 <davidlt[m]> Remember that it was never designed to be in any real product. It exist explicitly to help software ecosystem.

07:54 <davidlt[m]> Majority of SoC today don't really have a market, and it's more of test thingie.

07:54 <warren> does there exist a general purpose board suitable for real people yet?

07:55 <davidlt[m]> JH7110, JH8100-series, TH1520. These are designed like a more proper SoC, but JH7110 doesn't really exist outside SBC market.

07:55 <davidlt[m]> That's JH7110-based stuff (VisionFive V2, PINE64 Star64) and soon to be launched TH1520 products (e.g. from Sipeed).

07:55 <PrathamPatel[m]> warren: Define "people". End users like console gamers? End users who build their won PCs? End users who have a dedicated, fool-proof arch install script?

07:56 <davidlt[m]> Those probably will go for 80-200 USD (but exact prices depend on your region).

07:57 <davidlt[m]> Then there are large thing incoming, those are most likely in 1Ks of USD.

07:57 <PrathamPatel[m]> If you mean a "usable laptop", quite sometime. No one has the balls to launch a hardware product that doesn't have enough software support. Heck, you see this even on x86. How many vendors offer any linux distro compared to vendors that offer windows?

07:57 <warren> star64 for example has only pcie 2.0 x 1 lane =(

07:57 <davidlt[m]> Software is not really a problem. Hardware is what stopping us. And lack of some standards (incl. ratification) is slowing down hardware.

07:57 <davidlt[m]> That's plenty enough for that SoC.

07:58 <davidlt[m]> You could add PCie Gen 4 x8, x16 (whatever), but SoC would not have enough horse power to process that.

07:58 <warren> the market for sbc's is killed for arm too right now

07:58 <warren> the used market is flooded with liquidations of dirt cheap x86_64 gear

07:58 <davidlt[m]> Not really. There are multiple ARM server SoC implementation, and it's quite easy and fast to get access to one.

07:59 <davidlt[m]> Also Apple M chips solved the problems for developers.

07:59 <PrathamPatel[m]> The context of consumer defines the depth and width of software. For us foss folks, almost everything in the software side is ready. But for wider adoption, things like EDK2 are still WIP. I guess EDK2 recently got support for RISC-V in the virtualization side.

07:59 <davidlt[m]> I own non-Apple AArch64 laptop and it's waste of money.

07:59 <warren> Thinkpad X13s?

07:59 <davidlt[m]> If you can get Apple M1 MacBook Air on sale and run Asahi, that's the way to go.

07:59 <PrathamPatel[m]> davidlt[m]: T2? 😢

08:00 <davidlt[m]> Significantly better value for the money and significant community momentum.

08:00 <warren> Asahi did great work reverse engineering the hardware, and the GPU driver

08:00 <davidlt[m]> Pratham Patel: EDK2 worked on riscv64 on FPGAs and FU540. The basics were done by HPE many years ago (in upstream).

08:01 <PrathamPatel[m]> I meant it in terms of in-tree support

08:01 <davidlt[m]> Now companies are working on finishing it up and bringing up software and standards to the required levels.

08:01 <PrathamPatel[m]> AFAIK, EDK2 only has "official support" for a riscv vm

08:01 <PrathamPatel[m]> But yes, i am aware of EDK2 on actual hw :)

08:02 <davidlt[m]> Realistically the fun begins once RVA23 is ratified and Platform specification follow.

08:02 <davidlt[m]> Right now we have what will be called RVA20 with no platform specific standards, and it basically makes SBCs an e-waste.

08:03 <PrathamPatel[m]> Yep, I agree

08:03 <PrathamPatel[m]> I am not an expert, but the only problem I have with this specification is that something is optional. When anything is optional, it creates confusion for end-users/developers.

08:04 <davidlt[m]> Non-ISA specifications that are still to land (needed for platforms) would be things like IOMMU, new interrupt controller, etc.

08:04 <davidlt[m]> So RVA20, 22, 23 gives us some restriction (well, a lot of them) on what will be on SoC ISA wise.

08:05 <davidlt[m]> There are a few optional extensions, but not too much.

08:06 <davidlt[m]> RVA23U64 (draft) has 7 optional extensions.

08:06 <davidlt[m]> LIke FP16 (scalar), then vector FP16 support, BF16 FP conversion, and two vector crypto (NIST and ShangMi) algorithms.

08:07 <davidlt[m]> That's look good enough for user-side stuff. Not all vendor will need FP16 and not everything needs all vector crypto algos.

08:08 <davidlt[m]> For example ShangMi is for Chinese market.

08:09 <davidlt[m]> Now for the supervisor: RVA23S64

08:09 <davidlt[m]> It's basically Sv48, Sv57, Svadu, Zkr, Sscofpmf.

08:10 <davidlt[m]> Then there are a bit more if SoC implements hypervisor.

08:10 <davidlt[m]> Now RISC-V Platform spec basically stalled (depends on RISC-V Profiles to land).

08:11 <davidlt[m]> Some bits were separated into a separate specification, OS-A SEE: https://github.com/riscv-non-isa/riscv-os-a-see

08:11 <davidlt[m]> Basically how to talk to the firmware, etc.

08:12 <davidlt[m]> Platform itself is most likely blocked by other work, again like a new interrupt controller, IOMMU, etc.

08:12 <davidlt[m]> So. Slowly we are approaching toward RISC-V Platforms specifications (and compliance testing).

08:13 <davidlt[m]> Once we have that you basically will be able to install your RISC-V system with a generic Fedora disk image via USB drive :)

08:13 <davidlt[m]> I remember when this happened in AArch64 land, and it was epic ;)

08:14 <davidlt[m]> Then new problem happened :) No company built SBCs that would match those standards :D

08:14 <davidlt[m]> Thus you had to buy a server system, or continue to use SBCs that don't comply.

08:14 <warren> is there a fedora image that boots on hifive unleashed?

08:15 <davidlt[m]> I don't produce those anymore as I no longer have Unleashed available to me.

08:16 <davidlt[m]> Well technically I could probably produce it using QEMU ans sifive_u machine was designed to match SiFive Unleashed.

08:16 <warren> qemu is normally painfully slow, but would that be faster than the unleashed? =)

08:17 <davidlt[m]> Realistically the next platform that I plan to support is JH7110-based PINE64 Star64 and VisionFive V2. Then TH1520 Sipeed stuff (hopefully) and Intel/SiFive HiFive Pro P550.

08:17 <warren> I'm considering who to best give this board to, but from what I'm hearing it doesn't sound useful to anyone.

08:17 <davidlt[m]> You can outperform Unmatched and Unleashed with QEMU, but not in all cases.

08:17 <warren> hah

08:17 <davidlt[m]> I think rwmjones still has 2 of them, but we aren't using them for 1-2 years now (?).

08:18 <warren> I found it in a pile of junk at our office. we thought we gave it away years ago. oops.

08:18 <davidlt[m]> Here is my personal suggestion:

08:19 <davidlt[m]> If you need a good value product and upstream support, buy VisionFive V2 or PINE64 Sar64 (in this specific order).

08:19 <davidlt[m]> 6.4 kernel most likely will boot out of the box on JH7110.

08:19 <davidlt[m]> Star64 is still not on sale thus DTS for it will show up later on.

08:20 <davidlt[m]> If you need a higher performance, epic value product, but you don't care about upstream support being almost ready then look at Sipeed TH1520.

08:20 <davidlt[m]> https://sipeed.com/licheepi4a

08:21 <davidlt[m]> This will be the 1st SoC with OoO cores. Vendor suggest it will be 2x (or more) performance. Most likely in a very specific workloads it will be way faster.

08:21 <davidlt[m]> Intel/SiFive Horse Creek in HiFive Pro P550 is also OoO implementation. In some specific workloads (i think) they claimed 20x improvement. I think it was libquadmath.

08:22 <davidlt[m]> Also TH1520 has a lot of extension (most have now a matching RVI standard), that could in the future improve performance.

08:23 <davidlt[m]> I think T-HEAD claims ~40% if you are running software compiled with their extensions. Have no idea how that number was produced.

08:23 <davidlt[m]> Things like bit manipulation extensions are definitely a huge improvement in some workloads.

08:24 <davidlt[m]> VRULL has been working on some kernel stuff, LLVM, GCC, binutils, etc.

08:24 <davidlt[m]> We don't have an interface for HW probing then and just don't have any IFUNCs in glibc.

08:25 <warren> I'm overloaded with current work, I'll check this out later this year

08:25 <davidlt[m]> You will definitely have some good options to pick from later this year.