Hacker News Reader

Comment by rwmj | Hacker News Reader

I have two (https://rwmj.wordpress.com/2021/05/27/hifive-unmatched/) so I guess ask me anything ...

Will RISCV have the same mess that ARM ecosystem has of not standardising or having a single BIOS or similar system... such that you have to compile a custom image for every board?

One thing PC has going for it, is that you can install one Linux distro into any PC board. This is not the same for ARM boards.

Well that's a very good question. At the moment the reality is something of a mess, because someone looked at Arm and though that must be a good idea. Plus the RISC-V Foundation has even less control over implementers than Arm does (which doesn't have a lot).

The good news is that the foundation is defining various platform specs. For servers it'll include a standard firmware spec plus open source firmware implementation and a few other bits. Maybe working UEFI one day. (https://lists.riscv.org/g/tech-unixplatformspec https://github.com/riscv/riscv-platform-specs https://github.com/riscv-non-isa/riscv-sbi-doc)

I'm sure this mess could be avoided if instead of a doc only there would have a test suit exercising the implementation. This should be true for many foundations and their specs.

PC BIOS and UEFI are a mess as well. They are proprietary blobs guarded by Intel and alike. At least ARM had most bootloading open with uBoot, for example. Also PC firmware code on modern platforms is often bigger than Linux kernel. Hardly a good example. I sincerely hope RISC-V will avoid relying on UEFI and opt out for something more sensible.

Not really. Arm boards only work with uBoot because of a vast behind-the-scenes effort to integrate all the crappy forks and out of tree kernel drivers into Linux distros.

GPU resizable bar requires UEFI.

It has no hard requirement to be on UEFI rather it isn't compatible with legacy BIOS.

"Hard requirement" is a vague. At this moment in time no commercially available non-UEFI hardware exists to run GPUs supporting resizable bar.

There are solid open implementations of UEFI, one has actually been ported to the Pis and can boot Windows and Linux and so on.

Many PC UEFI builds from mega manufacturers are heavily customized, but a lot of them are also just based on TianoCore, including the modern RPi UEFI firmware builds. Nothing very strange about it. More specifically, the distinguishing thing here for RISC-V is the standardization of SBI, which will be a requirement for either UEFI or U-Boot to target it. U-Boot works on the million ARM devices it does today thanks to absurd effort from many people, not because ARM made it especially easy; with SBI in theory that can be made easier.

Aside from that people can argue whether UEFI is bloated and how their favorite is the perfect alternative, but as a user who would want to boot a RISC-V based desktop platform (and someone who has supported RISC-V, implemented their own designs, etc) I don't care and it doesn't matter; it actually does the job, and is a known quantity to aim for i.e. familiar and at least nominally understood by developers, users, and manufacturers. And I say that as someone who actually likes U-Boot and has patched it on a few occasions myself for my own targets.

> I don't care and it doesn't matter

you can not care, but it does matter

The complete lack of standardization of which ISA "extensions" each chip has means you will want a build targeting the chip you have, anyway.

This isn't true. The required extensions are specified in the Unix platform spec, and any additional extensions are detected and used at runtime (exactly how things work on x86 in fact).

There are Profiles specs and Platforms specs, that will be regularly updated. This means software has a fixed target on which it can depend.

Unpopular opinion: it will be much worse.

RISC-V is meant to be flexible and you can create CPUs that look very very different. Furthermore, some early chips used own solutions in some areas as a standard way of doing things was yet not available (e.g. memory protection).

So we have a hardware landscape with extreme fragmentation. If people cannot agree on the hardware, I have hard time seeing them agreeing on the firmware.

I don't think that's an unpopular opinion. It's more of an unfortunate truth.

I'm not worried about the "early designs used their own solutions." Expecting standards compliance before the existence of standards requires the Time Travel extensions to the architecture. :)

The problem is that you need a moment where the market switches from "hardware drives software advancement" to "software drives hardware standardization."

Think of the x86 architecture-- in 1979, if you were designing a new 8086 computer, you'd want to design the best disc controller, memory map, and graphics modes you could, and build software to show them off. By 1986, you wanted to design ones that looked exactly like an IBM 5150 so that Lotus 1-2-3 and Flight Simulator would run out of the box.

What specifically would be the comparable trigger for ARM or RISC-V?

You need killer apps that sit close to the hardware, and are closed-source. It can't just be something that runs on top of Linux/BSD/Android/etc. because then vendors will cheat by building an unsupportable hairball of custom bootcode and drivers to get you to an ABI-compatible OS and say "that's compatible enough." It can't be open-source because vendors will cheat by hacking it to fit into their custom hardware and firmware designs.

I'm not sure it's feasible today. Today's killer apps are not built with the 70s/80s mindset of writing directly to device registers for 1% more speed.

RISCV could end up being even worse if we ended up with a high performance fork of RV64

Why would that be worse?

All the issues ARM has but now with added ISA differences which may or may not be actually compliant with any standard let alone the one on the RISC-V website.

I don't believe the ISA dictates the implementation, so theoretically someone could implement the D extension to get 64-bit precision floating point in a more performant way than other implementations. If someone altered the ISA in order to get performance, I don't think you could accurately call it RISC-V anymore.

Sometimes ISAs restrict possible implementations so you can't implement faster designs.

There’s some plan for a common bootstrap and firmware interface. Personally though I think they should standardize on IEEE 1275 Open Firmware. It’s a standard, there are multiple good open source implementations with reasonable licenses, it’s lightweight, and it’s extremely flexible. Who needs the complexity of UEFI?

I've been thinking about getting one, but ultimately decided the price was not worth it, considering I'd probably hit a brick wall when trying to bring it up.

What convinced you to get not one but two of them? What do you run on it, was it hard to bring up the system?

hat convinced you to buy not one

I work some of the time on RISC-V and the hardware was paid for.

OT, but I just wanted to say that your RedHat interview was interesting:

https://news.ycombinator.com/item?id=28484534

Does it have proprietary firmware?

The boot sequence is described in section 2.2 of this document: https://starfivetech.com/uploads/hifive-unmatched-sw-referen... And some more detail here: https://u-boot.readthedocs.io/en/stable/board/sifive/unleash...

The flow is something like: ZSPL -> uBoot SPL -> OpenSBI -> uBoot -> kernel

Everything is open source except (maybe?) ZSPL which I think is stored in ROM and just loads the SPL off the MMC card.

Thanks -- good to know. I think I'd seen that on the boot process but didn't know about what's involved.

cryptsetup benchmark output :)

The output was quite large so I linked it here: https://gist.github.com/rwmjones/29b63bf20b10371ca9f1a56dac2...

The numbers are of course terrible because these chips don't perform very well and I guess also no one has tried to optimize this benchmark for RV.

Any sense how fast this chip is when running software optimized for it?

These are not fast at all, but it certainly helps to have an NVMe drive and 16G of RAM (a huge improvement over the older HiFive Unleashed boards). They're fine for packaging and general development work. I don't think we'll see software optimized for RISC-V until more extensions become available in hardware, especially the vector extension.

Indeed those are very low. However it might be related to lack of hardware acceleration extensions for encryption. I was hoping this machine had those.

Thank you.

RISC-V crypto extensions have just been opened up for public review: https://riscv.org/blog/2021/09/risc-v-cryptography-extension...

Yeah I was sort of expecting to have accelerated crypto, given the EAR export declaratioj I had to sign in order.l to buy this. If the CPU doesn't have any crypto implemented, what does? Some signature checking in the firmware?

The export agreement was a bit weird. No one will be using these to simulate their nuclear bombs on. As far as I'm aware there's no crypto hardware anywhere on them (no TPM etc.)

Reply on news.ycombinator.com