There have been three different firmware revisions that I’ve seen so far (I could have missed some). So my guess would be that they are not interchangeable, each firmware is matched to an exact version of the driver and only that version. And the older the firmware the smaller the filesize, which would suggest that bugs have been squashed with patches which adds code.
Source of firmware: https://github.com/eswincomputing/eswin_6600u/blob/7ac33f9aae710568ee4666c0996d40ac364a15ce/firmware/ECR6600U_transport.bin
File: ECR6600U_transport-00147316.bin
Released: 2023-02-24 at 14:07:17
Size: 149980 bytes
CRC-32: 563217f8
MD5: c27b5e344f8075a31165463b6c02d7e8
SHA-1: c4b63351a7ebc831d9f90fe030318e12858e58da
SHA-256: 8a7e96a030906987ce4a41e095e4eb7837bade72bf3ff603c7523778db080d7d
SHA-512: 06f8d53709d4bf191fb21004ad57309df9e8b4531e8a7429a4b22bf71d6cac63641e6e8664fb886b8cb1d23d5efc725b80e67d57e241fce678fc56b5cdc06417
SHA3-256: ed3f4a299b842101e882b1e77d1f879827c6cf5a0f8708200726e67d4a92aba1
SHA3-512: 9b7e64d6953a86c37cc12962d0bb1f036878b5fc164b79808ec5b59fc7a542f7c9fcac45626673fa1c8c69b5cdd6b75ffa01d6e651c3f6a1082f562b0db30487
Source of firmware: https://github.com/eswincomputing/eswin_6600u/blob/4a5b1c93ff9e72bef731a919a1744c638527af0a/firmware/ECR6600U_transport.bin
File: ECR6600U_transport-00130676.bin
Released: 2022-12-01 at 18:50:35
size: 146952 bytes
CRC-32: f3678c93
MD5: 2bf61a105fcd53e0a340141ecd2ffcb0
SHA-1: 2675a3596bf9f4204ff39ed2df4043b69d5256c5
SHA-256: 7892a49c8732a5ab1a9e96dedcc8c56e7a55b898d184472ec19d1720d6679eb4
SHA-512: 07eb842d3b36f99d507ce15ff0b17e26d07c00431738f1a856215be253bb5926cf1fb54dfccef10273da74ff0702db062fd98be1d6fc9ccd4659faec52a45821
SHA3-256: b6378a326088227e5adaba911e744df8bb05604c5dc31cbb1920679a3a8dc3db
SHA3-512: df8d51669c7d1eed2ecbd29106b89f27b491206ec4003463ef595d86673f3a62d7a4c91a8f3772302678cbc0aeb5ed992efcd8383ed83f2587a73abccddc9c61
Source of firmware: starfive-jh7110-202302-SD-minimal-desktop.img in the /lib/firmware folder. Also available from buildroot, commit has a timestamp of 2022-10-31.
File: ECR6600U_transport-00130452.bin
Released: unknown, but probably sometime before 2022-10-31
size: 147084 bytes
CRC-32: e7d57365
MD5: 02f67eb1fcb6a549d49f29e277feec36
SHA-1: 9ac6f0906bf44d4636c28525bf899f657de96cae
SHA-256: 8589fc9147450a807ca2c3843a3a181af9f238f5a95db48bc6cd9adcf9debe96
SHA-512: a43948289a506964db9756ff8c55266efa72f54cf5072cd9544d38b774521c64ca02b48e5e6529c9576064d190b8a7e76a63ec3019c3a84507792814c28cdec9
SHA3-256: 43372968495f67068eb9184231ef90093fed5ab0cb5d52d1776903da9d5fe4cf
SHA3-512: dbe033ac797685053294c4d957773c8034932a96a1605999e03ca8766e27fdbaa38206918b8f55876cea912277048de51f010ab5861d3b88a9db5c943a74ece6
EDIT: Looks like I am wrong, with my timeline, after a few “strings firmware.bin | less”
I get the following information from the three firmware files:
ECR6600U_ECR6600U_V1.1.0B05P06
00147316H
14:07:17 Feb 23 2023
ECR6600U_V1.1.0B05P02
00130676H
18:50:35 Dec 1 2022
ECR6600U_V1.1.0B04P05T01
00130452H
The firmware naming almost appears chaotic, so I’m going to rename the files with that H number, because my dates from commits and file timestamps are definitely wrong.
$ mv ECR6600U_transport-2023-02-23.bin ECR6600U_transport-00147316.bin
$ mv ECR6600U_transport-2022-12-07.bin ECR6600U_transport-00130676.bin
$ mv ECR6600U_transport-2022-10-31.bin ECR6600U_transport-00130452.bin
And I changed the order above to what I now suspect is the newest to oldest. What is slightly surprising it that the very oldest firmware is the one that is in use on the very latest VF2 image.
Here is a grayscale image of the three firmware files from the oldest to newest (left to right). Looks like the latest firmware is in a slightly different format to the older two. A bit of zero padding and part of the firmware looks to be flipped around in reverse order.
EDIT2: I did a quick bsdiff of the firmware and about 14% of the binary (~20KiB of a ~147KiB file) changed between versions.
21994 bytes ECR6600U_transport-00130452-to-ECR6600U_transport-00130676.bsdiff
19179 bytes ECR6600U_transport-00130676-to-ECR6600U_transport-00147316.bsdiff
That typically does not happen with bsdiff unless there actually is about a 14% change in the source code (In the real world that rarely happens, and twice in a row between two different versions of the firmware the odds are pretty much negligible) or part of the firmware is encrypted. For FCC compliance, 4 Watt (+36dBm) EIRP limit on maximum transmit power from the antenna and, FCC part 15.247(i), 1 Watt (+30dBm) limit transmit power delivered to antennas, encryption is probably how compliance is being achieved.
There was nothing obvious in the unencrypted parts of the firmware that would indicate if it is supported or not. But I did find that ESWIN licensed their IP for the chip from CEVA Inc. but that did not help it could still be 2.4GHz or Wi-Fi 6 (2.4 and 5GHz) but not Wi-Fi 6E (6GHz).
I did eventually find an answer here, and the answer is currently no.
But it may still be possible that the hardware might be able to support 5GHz with a new driver and firmware but that would depend on exactly what IP was licensed by ESWIN from CEVA. IEEE 802.11ax, is officially marketed as Wi-Fi 6 (technically should support 2.4 GHz and 5 GHz bands). And Wi-Fi 6E is on the 6GHz band only, so it is definitely not Wi-Fi 6E.
EDIT3: Actually thinking about it even more, it is not the IP licensed from CEVA that matters, it is who they licensed the RF radio section from that would dictate which band was used for transmitting (and receiving). So the (modem) IP from CEVA would probably support the 5GHz band (for compliance with the WiFi 6 standard), because it is only sending samples to an DAC (or receiving samples from an ADC - more licensed IP) which would be a baseband signal, but if the RF frontend section (local oscillator, mixer and bandpass filters) did not support the 5GHz band then that band could never be used.