Milk-V Mars CM #22
Comments
|
Just plopped this board on my Compute Module 4 IO Board, and it seems to do some sort of boot process, arriving at a flashing green LED (two flashes, then 1 second break, repeating). The network LEDs light up too, but I don't see a new device on the network. No HDMI output, and I'm not 100% sure if the GPIO pinout is the same as Pi CM4, so I don't want to plug in UART yet... I tried accessing the 'Get Started' docs page listed on the side of the box (http://milkv.io/docs/mars-cm), but that page is currently giving a 404 Page Not Found. I've opened up an issue on the MilkV Community Forum: Mars CM - Getting Started guide missing?. It would be great if this JH7110-based board could run as a drop-in replacement of the Compute Module 4... we'll see! |
|
Attaching to UART using the same pins as Mars (see Serial Console docs), I was able to monitor boot output... It looks like it does automatically boot into Debian, and it says an eth0 link is up... (this is with no microSD card attached). Trying to find it on my network now. |
|
I can't figure out the login/password. I tried Aha! It's |
|
SSH password authentication was disabled, so to enable it (without messing with vi/nano over UART), I ran the oneliners: And restarted SSH with: Now I can login via SSH! |
|
I'm in, but apt is incredibly slow (like in the single-digit-kilobytes per second range). Not sure why. Waiting for an install to complete so I can fetch some more info about the system. An |
|
The disk partition was not expanded initially, so I realized when I ran out of disk space (only about 4 GB is allocated by default), I had to run through the process documented on StarFive's website for extending the partition on the eMMC storage. Once I did that, I wound up with about 11 GB of usable disk space. Geekbench 6 preview downloaded about about 15 MB/sec, so not sure what was up with Apt... Judging by VisionFive's warning not to upgrade, maybe I shouldn't try an apt upgrade on here yet? |
|
I'm unable to install Ansible via So I'll run my Top500 benchmark through Ansible on my Mac, over SSH instead. |
|
From the image provided by MilkV, following the instructions previously reported:
Reading package lists... Done
Reading package lists... Done |
We use different images
|
|
To monitor the SoC temps, I installed (That was with a heatsink only. SoC throttle limit seems to be 85°C.) |
|
It's funny, about 10 minutes after I boot the thing, I get a system message that it will suspend. Not sure why... and it doesn't actually suspend: Looks like maybe it's a Gnome thing: https://forums.debian.net/viewtopic.php?t=156005 and https://discussion.fedoraproject.org/t/gnome-suspends-after-15-minutes-of-user-inactivity-even-on-ac-power/79801 |
|
I tried using |
|
With regard to gnome not functioning after apt upgrade of the vendor provided OS via Debian unstable package repo, |
|
A number of the Phoronix Test Suite tests failed, for example, trying to do the mp3 encode test: And then for things like the linux kernel build, it ran out of space. For now I'll leave those tests out, 16 GB isn't that much space to play with :) |
|
I still can't get WiFi to connect.
That was with my 5 GHz network. Trying two different 2.4 GHz networks (one is on an older router that works better with ancient or weird WiFi hardware), I could get nothing from either of those too (same errors). So maybe the WiFi driver's a bit flaky in the OS image I have installed? |
|
Checking on the JH7110 Linux kernel Upstreaming Status, it looks like most interfaces are upstream now, with the rest on their way. Quite nice! And happening more quickly than many of the Arm SoCs these days... |
|
Testing PCIe: |
|
I formatted the 2TB NVMe SSD, then ran my disk benchmarks, and got 150 MB/sec for fio, and 250 MB/sec for 1M sequential read/write via iozone. Not amazing, but a lot better than built-in eMMC! See full benchmark results in OP. |
|
@christiancelona - Do you know why the buildroot image for these devices is still on kernel 5.15.x? |
|
I would have preferred not to write it to you :) With Ubuntu 23.10 the onboard GPU is not supported, USB are not supported by the 6.2 kernel and the OS do not work with the 6.5 kernel. I believe that there is little point in engaging in benchmarks of this SoC, except in the case in which you want to measure the benefits brought by good software support, which has so far been absent. I'm waiting for the new integrated SMB in kernel that might make my SBC more suitable for my purposes. Up until now I have always used Raspberry Pi but the latest one is absolutely not in my purchase plans and not because of the cost. For those who wanted to use the Milk-V Mars SBC as a low-power desktop, the biggest obstacle to using the new kernels was certainly the display controller driver for Verisilicon DC8200 (for me the Chinese ideograms are a big obstacle) and an HMDI driver, now patched, check again the documentation at the line HDMI/ DC8200. I am waiting for the new images from Armbian (Armbian 23.11 Topi release, announced today) on November 1st or 2nd a Debian Topi should be ready to try, or in future DietPi too. But perhaps you have clearer ideas about the propagation time of new kernels in Linux distributions. |
|
Update: It's better not to follow my experiments, I updated everything and still lost the graphic environment. I'm starting from scratch. |
|
Milk-V Mars, sbc-bench v0.9.49 result: http://ix.io/4KoX |
|
@christiancelona - Interesting, it looks like every score besides the memcpy/memset scores was slower in your run (compared to the one I ran on the StarFive kernel). |
|
I wondered if it could depend on the software and I redid the tests with a Raspberry Pi 4B and Armbian (non the same, lunar vs jammy). RPi 4 Model B Rev 1.4, sbc-bench v0.9.49 result: http://ix.io/4Kpg Remember that we are comparing two slightly different hardware too. I couldn't boot from SD with the same image as you, my testing time is over today. |
|
@christiancelona with 6.5 it doesn't look better (memory latency and CPU clockspeeds the same but scores for whatever reason slightly lower):
|
|
Thank you. I installed the StarFive image, they are different for SD or whatever. Indeed, the difference in performance is also noticeable in use, not only from the benchmarks, the system is more responsive. I have no idea what changes between kernels, other than the version, at the moment the image provided by the SoC manufacturer is the best, despite being older. Furthermore, the SoC temperature is now lower. |
|
Hey Folks - How can I help contribute here? |
|
@geerlingguy The process for re-flashing the eMMC image has been updated to the document: |
|
In case it helps... Similar to @ThomasKaiser & @christiancelona's Armbian Lunar numbers on 5.15 & 6.5, although slightly higher. |
Had this same issue last week testing the non-CM board. Corrupt SBC config on SPI flash seemingly resulted in it looking for kernel on eMMC as default, but their image wanted SD card. I flashed both, booted, then changed /boot/extlinux/extlinux.cfg to use mmcblk0 so no SD card required, and it works a treat. Next week I'm going to try to flash OpenSBI again with correct config, see if that does it. Released eMMC image for now anyway; https://plati.ma/milk-v-mars/ (should have seen this post and enabled password-full SSH, dang it) Cheers for your RV contributions mate! |
@christiancelona Switch to |
OH this repo is live? I am so damn excited; was looking for it the other day when messing with a Mars SBC. Thank you kindly! |
Whoops, I should have tested that. Use |
You set me up, just to let me down 💔 |
/etc/apt/sources.list.d/debian.sources: /etc/apt/sources.list.d/debian-experimental.sources: There is a PCB revision needed to fix some problems and so the next batch of Mars CM is delayed until later this month (November 2023). Until I get a Mars CM in-hand I am following along with Debian riscv64 progress by a running qemu instance and the DQIB image as mentioned above. |
|
@eshattow oh super interesting to know! Can I ask what problems are being fixed if you have any insight? Ripper to see rv64 in unstable now, did not recall seeing that previously. Looks like it's got kernel 6.5 in there too; https://packages.debian.org/unstable/linux-image-6.5.0-4-riscv64 I've got a Mars SBC (not CM) I am tempted to test with. |
|
@platima I too am curious. That was the summary of a reply from the distributor customer support person. 🤷 |
|
oh, Crush? Hah
…------ Original Message ------
From "E Shattow" ***@***.***>
To "geerlingguy/sbc-reviews" ***@***.***>
Cc "platima" ***@***.***>; "Mention"
***@***.***>
Date 9/11/2023 4:40:41 PM
Subject Re: [geerlingguy/sbc-reviews] Milk-V Mars CM (Issue #22)
@platima <https://github.com/platima> I too am curious. That was the
summary of a reply from the distributor customer support person. 🤷
—
Reply to this email directly, view it on GitHub
<#22 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADIYAQF7WCT3MIAKGBY2XDTYDSJITAVCNFSM6AAAAAA6TL34OGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBTGM4DCMJSG4>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@platima I installed the linux-image-riscv64 which installs 6.5.10-1 and a few other utils. Install goes fine, but haven't figured how to get the system to boot that kernel (no grub). Happy to try any ideas you have, so you don't have to switch over for nothing. |
|
Hey if it's all setup right, should just be a matter of modifying
/boot/extlinux/extlinux.conf from memory! You can even have both kernel
options in there just in case.
Eg see how the Ox64 image has two extlinux entries depending on the
platform:
https://github.com/openbouffalo/buildroot_bouffalo/blob/main/board/pine64/ox64/rootfs-overlay/boot/extlinux/extlinux.conf
Just make sure the kernels are both present and have unique names.
…------ Original Message ------
From "rhinot" ***@***.***>
To "geerlingguy/sbc-reviews" ***@***.***>
Cc "platima" ***@***.***>; "Mention"
***@***.***>
Date 18/11/2023 6:32:57 AM
Subject Re: [geerlingguy/sbc-reviews] Milk-V Mars CM (Issue #22)
@platima <https://github.com/platima> I installed the
linux-image-riscv64
<https://packages.debian.org/unstable/linux-image-riscv64> which
installs 6.5.10-1 and a few other utils.
Install goes fine, but haven't figured how to get the system to boot
that kernel (no grub). Happy to try any ideas you have, so you don't
have to switch over for nothing.
—
Reply to this email directly, view it on GitHub
<#22 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADIYAQFUGFIDVPDP4EIKARLYE7QZTAVCNFSM6AAAAAA6TL34OGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBWGYZDKMZSGA>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Thanks, @platima! That was helpful, as I tried loading the 6.5 kernel, it failed, and this allowed me to fall back to 6.1. Do you know where I can find what failed when the system tried to boot into my 6.5 kernel? |
|
Very welcome.
And damn, that's a tough one. Not too sure TBH, I'd just watch the debug
output via serial in PuTTy, and scroll back up to read it hah.
…------ Original Message ------
From "rhinot" ***@***.***>
To "geerlingguy/sbc-reviews" ***@***.***>
Cc "platima" ***@***.***>; "Mention"
***@***.***>
Date 18/11/2023 2:14:26 PM
Subject Re: [geerlingguy/sbc-reviews] Milk-V Mars CM (Issue #22)
Thanks, @platima <https://github.com/platima>!
That was helpful, as I tried loading the 6.5 kernel, it failed, and this
allowed me to fall back to 6.1.
For other's reference, I also found this extlinux.conf sample
<https://github.com/jetsonhacks/bootFromUSB/blob/main/sample-extlinux.conf>
clarifying.
Do you know where I can find what failed when the system tried to boot
into my 6.5 kernel?
I tried journalctl, but there is nothing even with the timestamps of the
attempted boot with that kernel.
—
Reply to this email directly, view it on GitHub
<#22 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADIYAQFFVO7BVXGH4SKMBDDYFBG4FAVCNFSM6AAAAAA6TL34OGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJXGQYDSMBZGA>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Identified chip markings overall:
The eeprom here has wrong data as it indicates a 16GB eMMC (E016) and there is no eMMC (E000). Correct this by shorting the eeprom Write Protect pin at "EN" test point to ground and write new value from U-Boot:
|
|
Fun fact you can use the U-Boot 'dhcp' command to set up the network PHY ahead of loading a kernel. Otherwise MOTORCOMM_PHY in addition to defconfig is needed for mainline Linux kernel, and if you want SD Card function that will be I2C_DESIGNWARE_PLATFORM && MFD_AXP20X_I2C && REGULATOR_AXP20X. No patches needed for SDCard and it seems "good enough" to use the in-tree DTB: starfive/jh7110-starfive-visionfive-2-v1.3b.dtb (although it doesn't exactly match the Mars CM hardware). The official debian-installer can be run successfully in EFI mode: |
Build firmwareAdapted from U-Boot documentation: suggested build procedure for Milk-V Mars. Build U-Boot with patches for Mars CM and UART boot: Deliverables attached as u-boot-20240506-404590-405361-405474-405683-loaderase.zip (572KB): Note the vendor U-Boot devicetree changeset for SD Card on Milk-V Mars CM Lite is applied at runtime depending if your EEPROM indicates no eMMC (value "E000"). First production runs of Milk-V Mars CM Lite had wrong value "E016" in EEPROM data which is easily corrected. Milk-V technical support has acknowledged this concern as of 14th Apr 2024:
Note the vendor Linux devicetree changeset for SD Card on Milk-V Mars CM Lite does not appear yet in mainline Linux. Recovery and flashing firmwareSerial terminal tio is known to work with a CP2102N UART adapter and tolerates the excess NAK bug present in JH7110 MaskROM XMODEM loader implementation. Milk-V Mars CM is factory pre-loaded with firmware flashed to SPI NOR consisting of a Secondary Program Loader (SPL) and a payload image that is flashed to SPI NOR at an offset. SPL and payload are from U-Boot software which includes OpenSBI dependency. JH7110 UART recovery using U-Boot:
Flashing firmware to SPI NOR using U-Boot: Interrupt the bootcmd countdown at reset and clean the environment variable storage to complete the update process: Debian InstallerDebian installer netinst riscv64 daily builds are working unmodified as of April 2024 for SD Card or eMMC as a storage target. For installation to storage targets on PCIe host bus it will be necessary to use a custom kernel and device-tree. Installation notes here refer to TFTP method for source media but can also be done via UART (this will probably take many hours to transfer) if it is not possible to set up a local TFTP server. SD Card and PCIe attached storage devices may also be viable source media if accessible from U-Boot. USB is not yet functional on Mars CM/Lite in U-Boot. Download debian-installer and debian-installer/device-tree as local copy(Optional) Modify debian-installer with kernel modules and package from patched kernelPrepare TFTP server locallyTFTP is used to serve installer files because it's quick and you'll need network access anyways in debian-installer. We'll refer to as InstallationReset the Mars CM and command U-Boot from Standard debian-installer netinst (no PCIe host)Alternate: Custom debian-installer netinst (with PCIe host)Advice on debian-installer use:
Finish the installationAt this last step of the debian-installer To resume the installer (Extra) Using debian-installer as post-installation tool to install custom kernel packageWhen using debian-installer as a rescue environment note that the clock and network are not set up until later in the installer process.
U-Boot EFI boot manager will use Remember to also Linux Kernel, EFI stub, and DevicetreePatchwork series: Build: Attached: linux-image-6.9.0-rc7-jh7110-00036-gd479e01e625a_1_riscv64.deb.gz (14 MiB) Errata There is sometimes a race condition possible with serial console and reboot. If needed this can be avoided: How debian-installer handles creating an EFI System Partition seems to not initialize if the partition scheme matches what was already on disk for a pre-existing one, even when the erase data action is used ; workaround if you want to force formatting for correctness is to change the size slightly and then restart the install process after changes are written to disk. |
|
I'm just a Gentoo user with no knowledge in embedded whatsoever trying to get something sane onto Mars CM. @eshattow instructions working nicely. Serial is flaky, tried multiple USB ones and FT232RL sort of worked. Debian netinst hanged a few times at package installs with CPU soft lockups during untar. Power cycle / repeat. Postinst to actually boot, since dtb is absent in EFI, used tftp again : @eshattow |
Hi moroznah. Thanks for the comment but this is not the forum for such discussion - here we talk about the performance of the SBC in question and/or benchmark results, if anything. I think ideally though, there should be minimal discussion as these 'Issues' are just a way to collaboratively store result data. Your best bet may be to reach out to @eshattow directly, else perhaps the uboot forums, Reddit or have a look at the starfive_tech repos. I know I broke this guideline myself, but that's a lesson learned. Cheers! |
|
@moroznah Thanks! Further discussion is welcome on the Matrix group chat https://matrix.to/#/#milkv-mars:matrix.org part of the Milk-V Matrix Space linked at their website. |
Thanks E! Have a great week everyone |
I haven't used that in quite a while with my jh7110 stuff. @xypron shared this with me and I've used it the couple times I have changed the firmware since: https://github.com/xypron/JH71xx-tools |
That is a serial transfer tool co-dependent on (not a replacement for) the StarFive recovery.bin SPL. It says right in the README.md |
|
@eshattow I guess https://github.com/starfive-tech/bootloader_recovery is what you are looking for. It produces jh7100_recovery_boot.bin. For the VisionFive 2 I found it much easier to set the DIP switches to boot from an SD card, flash the SPI flash from U-Boot and then reset the DIP switches. |
Is jh7100_recovery_boot.bin valid for JH7110? There is no JH7100 on the MilkV Mars CM. |
|
Hi! Have anyone tried running upstream kernel? Looks like most of the patches are already there for CPU. |
|
@shanduur Just tried booting the upstream 6.7.9 kernel on a working DietPi stock install (which currently is running a patched 6.1.81). System didn't boot. Nothing even in the kernel logs that I can share to help debug. |
Basic information
Linux/system information
Benchmark results
CPU
Power
stress-ng --matrix 0): 3.8 Wtop500HPL benchmark: 3.6 WDisk
Built-in 16 GB eMMC Module
2TB Kioxia XG8 NVMe SSD (via PCIe Gen 2 x1 interface)
curl https://raw.githubusercontent.com/geerlingguy/pi-cluster/master/benchmarks/disk-benchmark.sh | sudo bashRun benchmark on any attached storage device (e.g. eMMC, microSD, NVMe, SATA) and add results under an additional heading. Download the script with
curl -o disk-benchmark.sh [URL_HERE]and runsudo DEVICE_UNDER_TEST=/dev/sda DEVICE_MOUNT_PATH=/mnt/sda1 ./disk-benchmark.sh(assuming the device issda).Also consider running PiBenchmarks.com script.
Network
iperf3results:1 Gbps Ethernet (built-in)
iperf3 -c $SERVER_IP: 920 Mbpsiperf3 --reverse -c $SERVER_IP: 879 Mbpsiperf3 --bidir -c $SERVER_IP: 941 Mbps up, 258 Mbps downWiFi (built-in)
iperf3 -c $SERVER_IP: TODO Mbpsiperf3 --reverse -c $SERVER_IP: TODO Mbpsiperf3 --bidir -c $SERVER_IP: TODO Mbps up, TODO Mbps downGPU
Memory
tinymembenchresults:Click to expand memory benchmark result
Phoronix Test Suite
Results from pi-general-benchmark.sh:
sbc-benchresultsThe text was updated successfully, but these errors were encountered: