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.
2 Likes
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.
2 Likes
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.
1 Like
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.
1 Like
That’d make the ARM binary from VIA unnecessary. Indeed a good thing.
1 Like
Is it possible for a official firmware update tool? Since we don’t have recovery tool if it fails.
1 Like
Seems vl805 support is ready to be merged in flashrom.
https://review.coreboot.org/c/flashrom/+/72057
1 Like
After testing, seems rpi’s firmware cannot be used on vf2, can you get a proper firmware for vl805? I tried rpi’s closed source tool and flashrom, both works, but new firmware doesn’t work properly. lsusb hangs, and dmesg shows no device detection info.
2 Likes
I blame VIA here for not openly publishing documentation, firmwares and tools in their website.
Changing the firmware without backporting the matching and probably needed driver changes for the kernel to match that exact firmware might do that ?
e.g.
RPi from firmware 000138a1 to 000138c0 required these changes: https://github.com/raspberrypi/linux/pull/5262/files
I thought that the VIA quirks would be in the mainline kernel (6.2) driver, but it only has 2 quirks, whereas the RPi kernel driver handles 6 quirks. Even the next linux kernel still only handles 2 quirks. And the VF2 kernel driver handles the same 2 quirks as the mainline and next kernel.
They had to add a quirk? You’d expect firmware updates to actually fix bugs, not the other way around.
Well, I only tested newest version of rpi firmware… You could try more version. Easiest way to update/backup existing firmware is to use qemu-user-static+rpi’s close source tool.
Also, I think those quirks are temporary solution for this problem when firmware solution not implemented. But you can also apply those quirks to vf2 kernel to see if it works.
1 Like
Extracted firmware: Microsoft OneDrive - Access files anywhere. Create docs with free Office Online.
1 Like
From left to right the ten firmware versions in the png image are 00013400, 00013600, 00013701, 00013703, 00013704, 00013726, 000137ab, 000137ad, 000138a1, and 000138c0. I did not zero padded 00013726 to help make it easier to identify the VF2 VL805 firmware.
The output from a bsdiff between versions did not increase beyond what would probably be expected when looking at 00013704 to 00013726 (336 bytes) and 00013726 to 000137ab (2963 bytes) when compared with 00013704 to 000137ab (2964 bytes). They are not the same, but they are close enough to strongly suggest that the same baseline source code is common to all firmware versions.
patch
size
bytes output filename
----- ---------------------------
...
170 00013703-to-00013704.bsdiff
336 00013704-to-00013726.bsdiff
2963 00013726-to-000137ab.bsdiff
3451 000137ab-to-000137ad.bsdiff
...
To me, visually and from the bsdiffs it looks like a normal incremental change to one firmware source code, and that there is no encryption (the firmware could in theory be obscured by something like a basic substitution cipher). If there was encryption bsdiff, how it works to generate binary patch files for executables, would not be working as efficiently as it is.
EDIT: updated bsdiff information using FW013726.bin below. The first 96984 bytes, the size of FW013726.bin (96984 bytes) and vl805-00013726.bin (131072 bytes) were exactly the same in each file as you would expect from an unmodified error free firmware dump.
2 Likes
FW013726.bin (94.7 KB)
attached firmware we get it from chip vendor. no any update from them
4 Likes
Poking the vendor as a customer might yield results.
Notably, rpi4 firmware release notes mention not just bugfixes, but also power savings from pcie aspm improvements deployed in VL805 firmware versions newer than 13726. We are missing out of these.
2 Likes
Did you power cycle after the firmware change ?
Of course yes. I power off the board, wait about 10 seconds, then plug connector back.
1 Like
Digging through the firmwares on github, this is all I could piece together. And that each later firmware version includes all previous fixes.
vl805-000138C0.bin (2023-01-11 commit to github)
- Fix for handling of split transactions
vl805-000138a1.bin (2020-01-10 commit to github)
- User settings of the ASPM (Active-state power management) bits in the PCI configuration space link control register are now maintained
- Better full-speed Isochronous endpoint support.
vl805-000137ad.bin (2020-01-10 commit to github)
- Fixes for USB webcams.
vl805-000137ab.bin (2019-10-22 commit to github)
- Better power saving.
FW013726.bin (?2019?)
- Default VisionFive 2 firmware.
vl805-00013701.bin (2019-10-22 commit to github)
- ? unknown ?
4 Likes