ASUS Unveils The Tinker V As Their First RISC-V Board

[jacob]

I hope this eventually leads toward standard RISC-V mATX, ITX, and eventually ATX boards with a Coreboot/etc OSS bios from the factory.

A fully open source friendly architecture with ATX boards and most importantly competitive performance already exists in the form of POWER9/10. I'm not sure what would RISC-V bring to the table that POWER doesn't offer already.

[ayumu]

another way might be if rpi made a switch from broadcom / arm to riscv platform. for example for the rpi5. then that would be able to get the cost down... only problem is: it would then end up being slower than the rpi4. lol

Look into CH32V.

https://m.youtube.com/watch?v=L9Wrv7nW-S8

[coder]

stormcrow the part about side channel attacks also applies to A53 and A55 cores, since those are in-order aswell.

Don't get too complacent about in-order eliminating the possibility of side-channel attacks. Most modern in-order cores, including the A53, have both branch-prediction and even a limited form of speculative execution to hide branch latency.

[coder]

A fully open source friendly architecture with ATX boards and most importantly competitive performance already exists in the form of POWER9/10. I'm not sure what would RISC-V bring to the table that POWER doesn't offer already.

RISC-V has a composable ISA that scales down extremely well. That gives it a permanent foothold from which it can creep into other market segments.

In the server realm, I think the main advantage RISC-V has is simply mindshare. That, and a lot more players developing RISC-V IP, who are continually searching for ways to differentiate themselves and grow beyond their core market.

Although RISC-V might not be a technically superior ISA for server computing, we've seen POWER get edged out by worse (i.e. x86).

[Paradigm Shifter]

Tempting. Needs a good price. Please note, Asus; "good" and "cheap" are not the same thing - I can live with a moderately high price if it's more than just a two-day-play-and-then-ignore-it board, and if Asus actually gives it some support instead of releasing it and then shrugging their shoulders and saying, "Not our problem any more."

Great - now hopefully a good price

"Some people say I'm a dreamer, but I'm not the only one..."

For some reason I feel like that might be an unattainable dream.

[jrtc27]

Unfortunately the SoC on this board violates the RISC-V privileged spec with its address translation (see https://lore.kernel.org/all/CA++6G0D...ail.gmail.com/). The core has Instruction and Data Local Memory regions, with virtual address ranges that match the ranges chosen for the memory regions (baked into the hardware) bypassing normal translation, not physical addresses (which would be completely legal). Supporting this therefore requires the OS to have special handling to know that parts of the virtual address space can never be allocated, which is not a normal thing, and a bit intrusive. Moreover, these virtual address ranges overlap the default base address for position dependent binaries on RISC-V (whether using GNU ld or LLVM LLD), so no position dependent binaries linked in the past however many years will work on this, instead they must be rebuilt with a different base address. It's therefore pretty dubious for them to claim that Debian is supported; not only does it need a vendor kernel (for now) as is usually the case for new Arm and RISC-V hardware, but it also requires some subset of the packages to be rebuilt with a modified toolchain or build flags.

[ayumu]

Although RISC-V might not be a technically superior ISA for server computing.

RISC-V is inferior to none.

The server chips are coming, as early as H2 this year (Ventana). Next year, there'll be several.

[miskol]

I did hope that ASUS will release board with RK3588.

[Old Grouch]

Unfortunately the SoC on this board violates the RISC-V privileged spec with its address translation (see https://lore.kernel.org/all/CA++6G0D...ail.gmail.com/). The core has Instruction and Data Local Memory regions, with virtual address ranges that match the ranges chosen for the memory regions (baked into the hardware) bypassing normal translation, not physical addresses (which would be completely legal). Supporting this therefore requires the OS to have special handling to know that parts of the virtual address space can never be allocated, which is not a normal thing, and a bit intrusive. Moreover, these virtual address ranges overlap the default base address for position dependent binaries on RISC-V (whether using GNU ld or LLVM LLD), so no position dependent binaries linked in the past however many years will work on this, instead they must be rebuilt with a different base address. It's therefore pretty dubious for them to claim that Debian is supported; not only does it need a vendor kernel (for now) as is usually the case for new Arm and RISC-V hardware, but it also requires some subset of the packages to be rebuilt with a modified toolchain or build flags.

That's...unhelpful. Goes with the territory of the RISC-V wild west, though. The discussion the linked message is embedded in is interesting. I wonder what the commercial, or other, pressures are that push manufacturers to go in such directions.

[Old Grouch]

A fully open source friendly architecture with ATX boards and most importantly competitive performance already exists in the form of POWER9/10. I'm not sure what would RISC-V bring to the table that POWER doesn't offer already.

POWER10 systems currently require non-free blobs to initialise the modular memory. Not everyone is happy with this. The hope of some is that RISC-V will enable the production of 'blob-free' systems, which is important to some people.

Phoronix: Binary Blobs Continue To Prove Challenging For POWER10 Plus Very Expensive Motherboards