Hacker News Reader

Comment by unusual-name | Hacker News Reader

Apparently the CPU in this SBC violates the RISC-V ISA pretty badly. [1]

[1] https://lore.kernel.org/all/CA++6G0Do001Bo+kxhUNz5T937TYU-K5...

Keep in mind the spec being violated is the privileged spec, not the core instruction set (which is what people think of when they think of an ISA violation). Personally, I think the privileged spec is a little too overzealous about the implementation-specific details that it specifies, and a little more should have been left to chip vendors.

For the uninitiated, what kind of things? I mean are these things that are necessary for desktop operating systems, but overkill when used as a DSP or something like that? I mean these aren't dumb people working on this so I wonder what this trade-off is.

Exactly that - they specify things that you need for an OS on a desktop/server system but complete overkill for embedded applications. I think the goal was to have one version of "RISC-V Linux" without vendor-specific extensions, but the chip vendors are used to their extensions, and there are good reasons to allow them to have some more customization (to allow design tradeoffs).

Also, in the ARM ecosystem, some of the things that the RISC-V spec specifies (like MMU details) are vendor-specific, leading to a minor headache for OS writers, but give chip manufacturers more freedom. Renesas may have assumed they had the same freedom.

The Arm ecosystem is a shitshow for this reason, with massive efforts required to port to each new SBC. We hope to standardize RISC-V enough to avoid at least the worst of this (Linux drivers will still be a problem, but you should be able to boot a standard single image on most boards even if some of the hardware won't always work at the start).

So this sounds like a deliberate design choice. Like when Intel went from pins to balls shifting the complexity to the motherboard. There are always trade-offs. I guess the idea is that the overhead is worth the benefit to the ecosystem and if the vendor really needs to they can create a chip that is only conformant at a user level but not at a priveledged level and still better than starting a custom ISA from scratch.

On the other hand, it sounds from the thread like the result of the deviation from the spec is "you can't run userspace binaries unless you built them with a binutils that's working around this", so it's not just a "weirdness the kernel has to deal with" kind of thing.

If everyone is understanding it correctly then that appears to be the case. Apparently user-space addresses from 0x20000 to 0x3ffff are not mapped by the MMU in the expected way, but are directly mapped to the same SRAM for every program.

A statically linked "HelloWorld" on my VisionFive 2 starts from 0x10000 and runs up to 0x4ea8e, so smack through that whole memory region.

The only way to make programs compiled with a standard binutils (or on another RISC-V machine, or a standard OS running in a VM) work would be for the kernel to memcpy() that 128k region in and out on every address space switch.

It's really an awful bug (or design decision) if you want to run standard OSes and standard code on it.

On the other hand, the privileged spec is also designed to provide process isolation and other security features. It may not seem as drastic as if a core instruction were misinterpreted, but this is IMO not the layer you want unexpected deviations from spec in.

Why does the ISA spec define the starting adress of the text segment anyway? Struggling to find a good reason.

It doesn't. Effectively the architecture spec defines behaviour so that it shouldn't matter what you choose for the text segment starting address, but this implementation's non-standard behaviour means it does matter, because there's a weirdly behaving address range you have to avoid.

It doesn't.

This implementation has a very incompatible (and problematic) deviation from the privileged ISA spec.

It seems to act as if there was a hardcoded, stuck, TLB entry that cannot be removed, so the whole system has to work around it. And to add insult to injury, it affects a virtual memory address range that happens to be used in most Linux programs.

IMHO ASUS is doing a disservice to RISC-V by releasing a board with such a chip. They should have used something else or skipped this generation.

Reply on news.ycombinator.com