Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Milk-V Mars: RISC-V credit card size SBC

milkv.io

Post reply on HN
Print view View original

71–79 of 79 posts

Re: Milk-V Mars: RISC-V credit card size SBC

#71

Post by mort96 »

jchw wrote: post #70
mort96 wrote: post #68

Earlier quoted context omitted.

UEFI has also been ported to ARM, yet we still have all kinds of issues booting ARM boards with generic images.

Yep, it's not the full story. For ARM, the standard for that is SystemReady. UEFI is nice, but it realistically only defines the boot process. Once the OS has taken over there's a ton of other stuff that it has to do that will be defined by not the ISA of the CPU but by the platform, like enumerate devices or coordinate interrupts. For those two things in particular, it looks like a form of ACPI may be supported by s…

That seems correct to my understanding. So the question is, will RISC-C SBCs standardise on some set of technologies which makes it possible to make generic RV64 images which work across a host of machines? Or will those technologies stay niche, like SystemReady has in the ARM world?

Re: Milk-V Mars: RISC-V credit card size SBC

#72

Post by jchw »

mort96 wrote: post #71
jchw wrote: post #70

Earlier quoted context omitted.

Yep, it's not the full story. For ARM, the standard for that is SystemReady. UEFI is nice, but it realistically only defines the boot process. Once the OS has taken over there's a ton of other stuff that it has to do that will be defined by not the ISA of the CPU but by the platform, like enumerate devices or coordinate interrupts. For those two things in particular, it looks like a form of ACPI may be supported by s…

That seems correct to my understanding. So the question is, will RISC-C SBCs standardise on some set of technologies which makes it possible to make generic RV64 images which work across a host of machines? Or will those technologies stay niche, like SystemReady has in the ARM world?

Good question; I hope they choose the path of standards early on, but it's not clear yet. I wonder if there's a genuine cost-cutting reason to not implement standards like ACPI. I believe SiFive was involved in the ACPI-on-RISC-V work, so that's probably a good sign. But honestly? I think we'll just have to wait and see.

Re: Milk-V Mars: RISC-V credit card size SBC

#73

Post by snvzz »

mort96 wrote: post #71
jchw wrote: post #70

Earlier quoted context omitted.

Yep, it's not the full story. For ARM, the standard for that is SystemReady. UEFI is nice, but it realistically only defines the boot process. Once the OS has taken over there's a ton of other stuff that it has to do that will be defined by not the ISA of the CPU but by the platform, like enumerate devices or coordinate interrupts. For those two things in particular, it looks like a form of ACPI may be supported by s…

That seems correct to my understanding. So the question is, will RISC-C SBCs standardise on some set of technologies which makes it possible to make generic RV64 images which work across a host of machines? Or will those technologies stay niche, like SystemReady has in the ARM world?

Yes, and already done. For UEFI specifically, there's a relevant spec[0].

0. https://github.com/riscv-non-isa/riscv-uefi/releases

Re: Milk-V Mars: RISC-V credit card size SBC

#74

Post by snvzz »

KerrAvon wrote: post #2

has video, usb & ethernet. missing price & benchmarks, though

Isn't it JH7110 like VisionFive2?

That board shipped in February. There's plenty about it.

I have one. On release a few benchmarks were made, but be careful that driver improvements and newer GCC versions (it shipped with a Debian built with a really old GCC) have improved performance dramatically since then.

Firefox and Chrome have also gained JS JIT, which makes web browsing fast.

Re: Milk-V Mars: RISC-V credit card size SBC

#75

Post by snvzz »

numpad0 wrote: post #62
snvzz wrote: post #44

Earlier quoted context omitted.

>is RISC-V going to follow the same problems as the ARM SBC system where each board has an obscure and unique boot process meaning images need to be carefully pre-built with who knows what installed for each board. No. Instead, RISC-V standardized the boot process early on, avoiding that situation.

How did they handle implementation differences between SoCs? Do all RISC-V SoC have exact same memory maps and SFR behaviors?

For the higher end "Application" cores that do e.g. run Linux, there's a platform standardization effort. Refer to OS-A platform[0].

0. https://github.com/riscv/riscv-platform-specs/blob/main/risc...

Re: Milk-V Mars: RISC-V credit card size SBC

#76

Post by snvzz »

rsaxvc wrote: post #67
numpad0 wrote: post #62

Earlier quoted context omitted.

How did they handle implementation differences between SoCs? Do all RISC-V SoC have exact same memory maps and SFR behaviors?

There are memory map and SFR differences. I bet it's similar to how Linux on Arm/PowerPC/MIPS handle it with device trees.

Device trees indeed.

Note that newer SBCs have efforts implementing UEFI spec[0], and RISC-V is working on OS-A Platform spec[1], which further reduces basic peripheral and memory map differences.

0. https://github.com/riscv-non-isa/riscv-uefi/releases

1. https://github.com/riscv/riscv-platform-specs/blob/main/risc...

Re: Milk-V Mars: RISC-V credit card size SBC

#77

Post by mort96 »

snvzz wrote: post #73
mort96 wrote: post #71

Earlier quoted context omitted.

That seems correct to my understanding. So the question is, will RISC-C SBCs standardise on some set of technologies which makes it possible to make generic RV64 images which work across a host of machines? Or will those technologies stay niche, like SystemReady has in the ARM world?

Yes, and already done. For UEFI specifically, there's a relevant spec[0]. 0. https://github.com/riscv-non-isa/riscv-uefi/releases

Oh, those technologies have already become non-niche? So if I survey the world of RISC-V SBCs, I will find that they can all pretty much just boot the same generic RV64 Linux distro images?

No?

Re: Milk-V Mars: RISC-V credit card size SBC

#78

Post by snvzz »

mort96 wrote: post #77
snvzz wrote: post #73

Earlier quoted context omitted.

Yes, and already done. For UEFI specifically, there's a relevant spec[0]. 0. https://github.com/riscv-non-isa/riscv-uefi/releases

Oh, those technologies have already become non-niche? So if I survey the world of RISC-V SBCs, I will find that they can all pretty much just boot the same generic RV64 Linux distro images? No?

AIUI Sifive's most recent board and VisionFive2 have working EDK2 UEFI.

VF2's is early (boots Linux, but only from mmc. No NVMe, USB or display yet), but being worked on by StarFive themselves.

In the future, with OS-A Platform spec, you can expect RISC-V computers to be no different than PCs from a user perspective.

Under the hood, the platform is modern, and carries none of the legacy x86 PCs do. The scope of standardization is also broader: It's not just interrupts, timers or memory map, but also things like the interfaces for Watchdogs, GPIOs are being standardized.

Re: Milk-V Mars: RISC-V credit card size SBC

#79

Post by brucehoult »

krilovsky wrote: post #69
brucehoult wrote: post #56

Earlier quoted context omitted.

If you want to talk about customers actually receiving stuff, rather than announcements or taking preorders, then the timing is: - Nezha: late June / early July 2021 - VisionFive 2: February 2023 - Star64: May 2023 The PineTab-V also uses the JH7110. It was supposed to ship late May at the same time as the (very similar) A55-based PineTab2, but according to the company they found something they wanted to fix before s…

No argument there, though I'm not sure why you feel that the delivery date is the relevant metric in the context of the Milk-V Mars which has only been announced and isn't even available for preorder yet.

Because the delay between announcement or order-taking and receiving the thing can be highly variable, and having it in my hands and being able to use it is what is important to me.

The biggest delays are usually with a new SoC. Once the SoC is available, building yet one more circuit board is usually a pretty straightforward exercise, at least for the competent.

Post reply on HN