Pretty disappointing to see the state of what could have been a flagship for RISC-V to consumer market. Especially the “don’t update” bit. I mean considering the lead time hardware takes, they could have figured out a distro, or upstreamed something. Progress is coming, but it’s not ready yet.
I have a VF2 up with the Debian image. Unless you want to reflash, apt upgrade is not an option. You have to run a provided shell script to get Firefox and a few other useabilty features.
It works, it boots, the documentation is weak, but it’s a start.
VisionFive 2 and Star64 launched earlier this year with the same SOC and there's at least 1 board with more horsepower already, so I wouldn't exactly call it "flagship" unless you somehow really needed something else with the CM4 form factor.
Feel like because both the VF2 and Star64 boards have been out already out for quite a while now, with probably some of their teething issues sorted out, this is pretty much an inexcusable product launch for Milk-V. Even more so since the VisionFive2 copied the RPi format almost exactly.
And yes, a lot of repositories for these boards are very fresh, forcing you to compile stuff and will break your board if you update. There's some stuff like device trees and patches being upstreamed, but there's also a whole bunch more that's not being upstreamed, like GPU drivers.
To me it feels about on par with expectations. Anyone buying these right now presumably expects more bleeding than edge. Which is fine for the target audience I guess
Jeff powered up the board, no HDMI output. Same vendor, same SoC (Milk-V Mars) OS image: same result. Support forum: non-existant. Finally he got if working over a serial connection - with tweaks.
Sorry... I'm kinda RISC-V fanboy, but this is no way to launch a product. To put it bluntly: Milk-V, this CM as-is is useless.
Get the docs, OS images, default configurations, quick start guides, user forum etc sorted out. Then launch product.
If you can't even connect an UART to get it up and running, then you're not the target audience. Hell, if you expect HDMI output from a CM out of factory, you definitely are not the target audience.
Get a SBC next time.
>Get the docs, OS images, default configurations, quick start guides, user forum etc sorted out. Then launch product.
Agree. Minus the user forum part, as trying to capture the community into a forum that you control is entirely optional.
(and any effort used maintaining a forum could be put elsewhere, such as customer support or improving documentation)
Raspberry Pi really reset expectations there, though—even when I had access to their alpha version of the CM4, it was booting with a full GUI, all interfaces working, and there were just a few tweaks to IO interfaces they needed to make for better speed and stability.
With many non-Pi boards, bringup via UART is typical, but the vast majority of SBC users wouldn't know what to do if you tossed them a USB to UART adapter.
>Raspberry Pi really reset expectations there, though—even when I had access to their alpha version of the CM4, it was booting with a full GUI, all interfaces working, and there were just a few tweaks to IO interfaces they needed to make for better speed and stability.
I understand these use same software throughout, and they make both the Pi and the CM board version, so you'd get the same results.
Conversely, both Mars CM and Mars seem to be under the same china-style "we shipped it but it barely boots" confusion :/
But it shouldn't take long to sort out. VisionFive 2 uses the same SoC after all, and the experience got to a pretty good point on that SBC (I own one).
>the vast majority of SBC users wouldn't know what to do if you tossed them a USB to UART adapter.
Pi specifically. Other ARM SBCs use u-boot. There documentation helps. VisionFive 2 has such documentation in place.
Rpi is unique in that it uses a bespoke boot process that doesn't even present an UART prompt on its bootloader. So the only way to get anywhere is with a ready-to-use sd image (AFAIK they now do USB too).
It can fortunately be brought back into sanity by setting up an alternative (and less supported, although definitely better and less bespoke) u-boot or uefi boot flow. OpenBSD (which I use) requires it.
If Raspberry Pi had any sense, they'd adopted UEFI for Raspberry Pi 5 (and made it compliant with ARM server platform specs), and maybe they have. I don't own one nor have I looked into it on detail; it's still using legacy ISA (i.e. ARM, IMHO a dead end), making it very uninteresting to me.
There's u-boot patches with video and USB support. There's also work in progress UEFI, which already boots Linux fine.
Once these are finalized, you won't need UART. You'll be selecting where to boot or configuring the firmware in the same manner you do on an IBM PC clone.
It will of course still be possible to use the simpler, reliable UART.
To add to that (edit no longer possible): Selecting boot from SD card via the boot DIP switches is already possible.
This ROM won't even initialize RAM. All it does is fetch next stage from SPI, eMMC, SD or UART (xmodem), into SRAM (CPU cache used as RAM) and jump to it.
What's not possible is USB, as the (non-updatable) early boot code ROM within the SoC is trivial and obviously has no USB support.
Thus UEFI or u-boot are needed for USB or NVME boot.
