As far as I understand, they are not all using exactly the same GPU, therefore I am not convinced they all get working GPU drivers at the same time (or at all).
I don’t know what other options are on the market, but Imagination has not the best reputation when it comes to drivers, back in the day, when Intel used their GPUs in their first Atoms, the reputation of those CPUs suffered primarily due to the bad driver support both on Windows and Linux.
And, voila, just before I hit the send button comes the bad news via phoronix:
"The following hardware is unsupported and not under active development:
========= =========== ==============
Product Series B.V.N.C
========= =========== ==============
GX6250 Series 6XT 4.45.2.58
GX6650 Series 6XT 4.46.6.62
G6110 Series 6XE 5.9.1.46
GE8300 Series 8XE 22.68.54.30
GE8300 Series 8XE 22.102.54.38
BXE-2-32 B-Series 36.29.52.182
BXE-4-32 B-Series 36.50.54.182
========= =========== ==============
Device info and firmware_ have been made available for these devices, typically due to community requests or interest, but no support is guaranteed beyond this."
So I said：Regarding the GPU driver updates for VF2 and Lite, please wait patiently.
Choosing Imagination may be because it has been acquired by Chinese capital (this news is what I heard, not necessarily accurate), and Riscv is dominated by China.
Too advanced technology, I don’t understand, I’m just an ordinary end user. I chose VF2 because three years ago, it was cheaper than Raspberry Pi 4B and it was made in China. I am Chinese.I also have Raspberry Pi 4b.
I have two RISCV embedded development boards. VF2_8GB_nvme + debian2409pro + labwc(wayland); lpi4A_16GB_eMMC + revyOS + xfce4.18(xorg)。
In terms of hardware, lpi4A is much stronger than VF2. But when I use them in a graphical environment, VF2 is much smoother than LPi4A, so I guess Wayland may be better than Xorg.
If you look at the VF2L circuit schematic (page 15), it is a one or the other situation, but not both at the same time. In the original non-lite VF2 there are two SDIO buses one dedicated to eMMc and one dedicated to the micro SD card (because there were two bus interfaces both could operate at the same time). In the VF2L one SDIO bus is now used for WiFi+BT (SD_SDIO1_D0 to SD_SDIO1_D3) and the other SDIO bus for eMMc (SDMMC_DATA0 to SDMMC_DATA7) OR MicroSD (SDMMC_DATA0 to SDMMC_DATA3). But since both eMMc and MicroSD share the exact same SDIO bus they can never be used at the same time. If StarFive added an SD slot the only way it could ever function is if the eMMc was de-soldered.
P.S. I really love schematics, they answer a lot of questions.
It is not “if” for a SSD, it is always “when”. Every SSD has a limited number of erase/write cycles full stop. But to be fair no storage lasts forever.
I would guess you need to use another storage medium to run the system, either NVMe (would be my preferred choice anyway, unless you need that m.2 slot for something different) or USB.
At the beginning I thought the MMC version had a TF slot, so I could use it for multiboot, or even use the MMC for storage and the SD card for the OS.
But since it doesn’t have a TF slot, I’m a bit concerned about the MMC especially because they probably won’t use a high-quality chip in a budget board like this.
I suffered from the same wrong assumption. I suggest to get an SSD in M.2 form factor, you get a lot more performance in IOPS than typical TF cards.
Maybe I underestimate the performance and endurance of eMMC, but I don’t consider it to be the mass storage of choice and primarily see it as a nice add-on or toy.
Are there performance characteristics (IOPS, red/write-speed) for the eMMC soldered onto the board?
That is where you consult the schematic, or ideally the Bill of Materials, in the VF2L documentation and see what was planned. On page 15 of the schematic the part that was NC (not to be connected) to the eMMc pad U25A was originally meant to a 32 GB eMMc without any part number listed
Usually part numbers are given, was worth a look anyhow.
With the part number I hopefully could have found out more information about endurance.
EDIT: I looked at scaled up images of eMMc in photos of the VF2L board from the documentation I can not make out the part number but it appears to be a “rayson eMMc”. The logo matches exactly. I’m going to assume that it is a 64GB consumer grade eMMc (TLC part number R570B64G4516G or R570B64G4M08G) instead of an industrial/automotive grade (TLC part number AT70B64G3Y05G).
Either way TLC not bad (original TLC NAND was typically 1,000 erase/program cycles per 4KB block ; modern 3D TLC NAND is typically 1,500–5,000 erase/program cycles per 4KB block), considering that there are about 16 million 4KB blocks in the 64GB eMMc, a good wear leveling algorithm would make these last long enough under typical usage.
EDIT2: Just thinking about it a bit more, there is always the possibility that StarFive went with a different eMMc part number from a different vendor for the final design of the VF2L boards. That the part used in the photos is not the part that ships/will ship/has shipped
