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

61–70 of 79 posts

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

#61

Post by fellowmartian »

snvzz wrote: post #44
PlutoIsAPlanet wrote: post #20

How does it boot? Or 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.

>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.

That wasn’t actually true on the boards I’ve tried, MangoPi MQ-Pro being the most recent. Look here for more details: https://linux-sunxi.org/Allwinner_Nezha Maybe if it had a “standard” U-Boot flashed onto a SPI chip you could standardize the process, but then you can do the same with ARM (this is what TowBoot does), so RISC-V is not a benefit in this instance.

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

#62

Post by numpad0 »

snvzz wrote: post #44
PlutoIsAPlanet wrote: post #20

How does it boot? Or 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.

>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?

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

#63

Post by brucehoult »

fellowmartian wrote: post #61
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.

That wasn’t actually true on the boards I’ve tried, MangoPi MQ-Pro being the most recent. Look here for more details: https://linux-sunxi.org/Allwinner_Nezha Maybe if it had a “standard” U-Boot flashed onto a SPI chip you could standardize the process, but then you can do the same with ARM (this is what TowBoot does), so RISC-V is not a benefit in this instance.

Things are still in a rapid development phase, especially for the new boards in the last four months (VF2, Star64, LicheePi4A), figuring out what things are actually necessary. The aim is definitely to get a board-specific (but standard interface) uboot and SBI in SPI flash on each board, and then have a single kernel + root FS image (for each distro) that can run on anything.

One obstacle is that some people are resisting upstreaming support for the THead C906 and C910 cores "non standard" physical memory attributes and vector implementation into the toolchain and kernel. Both those things were 2 1/2 years away from standardisation in mid 2019 when THead designed their cores, and it takes 3 1/2 to 4 years to get a new core into cheap mass production SoCs and on to boards, so they really could not have done better (other than to simply not implement that kind of feature at all).

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

#64

Post by 2Gkashmiri »

appleflaxen wrote: post #27
2Gkashmiri wrote: post #24

Is this available in India? I'd buy but won't risk the customs dance.

What happens with customs if you buy something like this?

45% tax usually. sometimes it gets lost in the customs office or they refuse entry to the product.

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

#65

Post by nine_k »

crote wrote: post #47
synergy20 wrote: post #38

Earlier quoted context omitted.

use CM4 modules with your own carrier board makes sense when you're building 500+. I read somewhere if you're building more than 10,000 devices, it's better to design the whole PCB board on your own. Before that volume, using SOM modules for time to market could be more reasonable.

10.000 probably isn't even enough to get Broadcom to reply to your emails. Good luck getting your hands on the required documentation, let alone the actual chips!

I wonder how that compares to Expressif.

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

#67

Post by rsaxvc »

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?

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

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

#68

Post by mort96 »

jchw wrote: post #40
PlutoIsAPlanet wrote: post #20

How does it boot? Or 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.

I don't know about interrupts/device tree/etc. but at least for the boot process itself, UEFI/EDK2 was ported to RISC-V. (I actually learned this because I was looking up information about the Windows PE format and was surprised to see relocations support for RISC-V; they needed to add support for it to the PE specification since PE is the native binary format of UEFI!)

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

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

#69

Post by krilovsky »

brucehoult wrote: post #56
krilovsky wrote: post #26

This is definitely not the first RISC-V SBC at this size (the Sipeed Nezha SBC[0] launched over two years ago based on the Allwinner D1, and the ARIES FIVEBerry[1] launched almost a month ago based on the Renesas RZ/Five). It's not even the first SBC with that specific SoC, as StarFive (the company behind the JH7110 SoC used by this SBC) launched the VisionFive 2 SBC[2] on KickStarter back in September, and Pine64 ha…

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.

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

#70

Post by jchw »

mort96 wrote: post #68
jchw wrote: post #40

Earlier quoted context omitted.

I don't know about interrupts/device tree/etc. but at least for the boot process itself, UEFI/EDK2 was ported to RISC-V. (I actually learned this because I was looking up information about the Windows PE format and was surprised to see relocations support for RISC-V; they needed to add support for it to the PE specification since PE is the native binary format of UEFI!)

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 some RISC-V platforms, and there's PLIC and APLIC for interrupts. Undoubtedly there are more things that I'm not thinking of, but I think that's a good start, as those are two things that were in fact NOT standard on many ARM SBCs.

Post reply on HN