On the back of the VisionFive 2 board, there prominently exist two SPI chips.
One is the GD25LQ128E 16MB QSPI flash, where SPL (at the start) and OpenSBI+U-boot (at 1MB) reside.
But there’s also a W25X10CL 128KB serial flash. What is the purpose of this chip?
But I can’t find the 4K bit I2C EEPROM GT24C04A anymore. I have not yet looked into the PMIC AXP15060, but if it is possible to read all registers sequentially and write them back, the EEPROM could have been used to save the settings.
Possibly, the EEPROM was not available and was replaced by a QSPI flash.
VisionFive 2 Product Design Schematics - Page 1 and 19
Reading through the 1.2A schematic (Super Early Bird board with 1 Gbit and 100 Mbit/sec NIC’s) - there is no public 1.3B schematic (Early Bird board with two 1 Gbit NIC’s) - yet.
Part label: U15
Part number: W25X10CLSNIG (128 KiB SPI NOR Flash) 2.3-3.6V 104MHz 1Mbit SPI NOR FLASH
Data bus: From the schematic it appears like a dedicated SPI bus between U15 and U16 only.
It is on the same page of the schematic for “PCIE TO USB”, so my guess would be that it contains a binary blob firmware and possibly settings for the CPU (ARM at a guess) inside the VIA Labs quad port USB 3.0 to PCIe host controller VL805-Q6 U16.
Good job finding it on the schematic… I skimmed it to no avail, and yet it is right there in sheet 16.
As the SPI is only connected to the VL805, the next task would be to read the VL805 datasheet to figure out what it is for.
And I really want to dump its contents… which I’ll realistically need a clip for. What a pain.
Since it can never be updated my guess would be that it is probably signed and encrypted as well to prevent anyone from dumping and backward engineering the firmware by de-soldering the chip. And at a guess covered by an NDA to get a peek at the documentation.
Non-public datasheets is scummy.
Somebody was nice enough to leak a version of the datasheet they got their hands on: PCIe to 4 USB ports use vl805 chipset on jetson nano custom carrier board - Jetson Nano - NVIDIA Developer Forums
Disgusting if true. They shouldn’t have anything to hide.
To be fair is it any worse than the RPi4B which uploads the VL805 MCU firmware blob (which I’m guessing is encrypted) via a mailbox request to the Videocore OS in the event of a reset, using non public firmware load logic. (ref: Open-Source Status of VisionFive 2 - #7 by mzs )
The problem is that there are no PCIe to multi port USB 3.0 host controllers that are opensource (high quality and cheap), as far as I know.
Raspberry Pi was the first mass-market sbc, but it always had flaws like this, not to mention the pointlessly bespoke boot process.
Fortunately, the SBC community has progressed 
The way that the RPi 4B can upload a firmware directly to the VL805 MCU RAM using the Videocore OS means that there is possibly some non public way to upgrade the firmware for the VL805 in the configuration used by the VF2.
Some vendors use an opensource tool to upgrade closed source firmware blobs in hardware running most major Linux distributions (ref: https://fwupd.org/ and https://github.com/fwupd/fwupd ). So I did a quick search, after wondering if “fwupd” could possibly be used to upgrade the firmware blob. And although some VIA USB HUB chips are listed ( https://fwupd.org/lvfs/vendors/prodcerts ), VL805 is not one that is supported by their open source firmware blob upgrade plugin. All the ones supported have a USB bus and not a PCIe bus.
EDIT: The listed VIA chips do not implement cryptographically valid strong signing (ref: third link above). It does not mean that they are not encrypted, but …
Found some, ~94 to 97 KiB in size (so would fit on a 128KiB W25X10CL):
https://github.com/raspberrypi/rpi-eeprom/tree/master/firmware/stable (at bottom)
https://github.com/jpmorrison/VL805/tree/main/firmware
The one on the VF2 will probably be a different, but I would expect it to be similar in a lot of ways.
Edit: current version is 00013726, seems much lower than fixed version.
user@starfive:~$ sudo lspci -d 1106:3483 -xxx | awk '/^50:/ { print "VL805 FW version: " $5 $4 $3 $2 }'
VL805 FW version: 00013726
Seems VL805 firmware has a bug on USB2 implementation, is vf2’s intergrated firmware fixed? @Michael.Zhu
That is from December, and they have added a new VL805 firmware (138C0) to fix the problem in January.
(Back in 2019 it looks like RPi4B actually had a SPI flash on the board for the firmware and used a utility for from VLI on ARM to update the firmware, which suggests that at least in theory that it should be possible to update the 128KiB flash from the RISC-V using something similar)
Look at my edit, not fixed 
The new firmeware can be download it from the link above.
Not sure if that firmware is compatible, since they have different quantity of ports
You are totally right, sorry. Thought the command you ran was on a pi, not a VF2 - well spotted. And it can not be installed on a VF2 without an appropriate tool anyhow. And that has not been made available even with the current firmware blob.
It’s good that there is a tool that we can download at all, even if for the rpi4b.
That’s something to look into. I’d assume that, like in the vf2, the spi flash is only accessible from the controller, so it will access some feature in the controller to read/write the spi flash.
qemu-user to the rescue:
[rvalles@starfive vl805]$ sudo qemu-arm vl805 -r dump.rom
VL805 FW version: 00013726
[rvalles@starfive vl805]$ ls -l dump.rom
-rw-r--r-- 1 root root 96984 Feb 19 07:29 dump.rom
[rvalles@starfive vl805]$ sha512sum dump.rom
138f21e53a804c27cece2a2ca466bb5a8935be3ead23cbcfc294971711b60a836ca12f1939ed71854a93b00380f53d2f49d893b17f43a4a08f5db46b55fc2d26 dump.rom
But unfortunately, in this archive of roms:
There was no version 13726 dump, thus we cannot confirm they’re identical.
I can, however, do this much:
[rvalles@starfive vl805]$ cmp dump.rom ~/git/VL805/firmware/vl805_fw_013704.bin
dump.rom /home/rvalles/git/VL805/firmware/vl805_fw_013704.bin differ: byte 14344, line 30
I could flash one of the new firmware versions, but as I don’t have a clip, I’d rather not take the risk right now.
I generated 8-bit png greyscale image files 256x512 pixels one for each of the nine publicly available firmware files and assembled them into a single image file (I effectively zero padded all firmware to be exactly 131072 pixels in size, left to right is oldest to newest). So if the byte value was 0x00 the pixel is black and if it was 0xFF the pixel is white. To me this indicates that there are three main sections to the firmware. And the middle section, which is growing larger, is where most changes happen.
I also used a really efficient and very clever platform-agnostic executable binary difference tool called bsdiff (ref: pdf paper about how bsdiff works under the hood) to generate patches from one version of firmware to the next latest. I suspect that the changes in bsdiff file sizes would very strongly correlate to the amount of source code that was changed between releases.
patch
size
bytes output filename
----- ---------------------------
2991 00013400-to-00013600.bsdiff
2861 00013600-to-00013701.bsdiff
782 00013701-to-00013703.bsdiff
170 00013703-to-00013704.bsdiff
2964 00013704-to-000137ab.bsdiff
3451 000137ab-to-000137ad.bsdiff
2788 000137ad-to-000138a1.bsdiff
854 000138a1-to-000138c0.bsdiff
And I think that is me done, I’m not going to attempt to proceed any further.