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