Can the developers divulge where they sourced the ECR6600U_transport.bin wifi firmware ?
used in starfive-jh7110-202302-SD-minimal-desktop.img and works.
the firmware in GitHub - eswincomputing/eswin_6600u fails.
It currently supports 2.4G wifi, does the new firmware also support 5G wifi ?
Here GitHub - jakubtalich/VisionFive2Drivers: Additional drivers for the StarFive's Linux kernel are some links for the firmware leading to this forum where you will find your answers.
There is also a how-to on compiling and using the firmware source.
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.
3 Likes
When checking the ESWIN repo, there was one commit last month, which bumped the version string from V1.1.0B03P06 to V1.1.0B05P06, while the driver from StarFive declares itself as V1.1.0B04P06, i.e. in the middle. But StarFive’s sources contain a lot of commits/changes which are not present in ESWIN’s V1.1.0B05P06 (and the other way round), so both sources have diverged and never been merged back.
We also found that only the StarFive firmware works with the StarFive driver.
Would be interesting to know whether current driver compiled from + firmware taken from ESWIN repo work fine.
Good (and sad) to know that I do not need to test whether export CONFIG_ECRNX_5G=y in the driver build config do enable 5 GHz support, do I?
1 Like
Since there is an option to do so, try it ? But looking at the default config file for both chips (ECR6600U and ECR6600, for USB and SDIO respectively) they have disabled that option “CONFIG_ECRNX_5G=n”. But the fact that it is there suggests that it could work, but maybe they just copied and pasted the config file from a different chip in their product range, and did not get around to deleting that option.
I just try it. No, I still cannot see any 5GHz SSID.
2 Likes
There is still a small chance that it may work at a later date with an updated driver and firmware version.
In my mind it all depends on if the radio supports both bands or only 2.4GHz. If you think about it from a RF point of view the modem IP from CEVA for Wi-Fi 6 can support both. Since it is sending/receiving samples to/from an DAC/ADC to transmit/receive a baseband signal that is shifted in frequency to/from either the 2.4GHz or 5GHz band by a RF mixer. That fact that the option is there in the config file (“CONFIG_ECRNX_5G=n”) makes me think that the RF section might support both bands.
But at the end of the day the ESWIN ECR6600U is a USB 2.0 device, so the theoretical maximum throughput is going to be limited to at most about ~40MiB/sec (~320Mbit/sec). It does not really matter what data rates higher than that are supported by 802.11b/g/n/ax], USB 2.0 HighSpeed would be the bottleneck.
For RF dense areas like offices and apartments that is where IEEE 802.11ax shines by providing ~37% higher throughput when compared to older protocols. It would be very nice to be on the relatively empty 5GHz band, but it should still perform quite well on a congested 2.4GHz band, as long as it is talking to other devices that support IEEE 802.11ax.
Thanks for testing 
. You did assure that the Wi-Fi country code was assigned correctly, i.e. iw reg get shows the 5 GHz frequencies? On Debian Sid, with a non-Debian kernel build (like the StarFive kernel), one needs to set
update-alternatives --set regulatory.db /lib/firmware/regulatory.db-upstream
so that the kernel can use the regulatory database. CRDA is not available anymore since Debian Bookworm, and generally obsolete since Linux 4.15.
Or it is set like that because it is definitely not supported by that chip. See the product page on ESWIN website where also only 2.4 GHz is mentioned: 产品-北京奕斯伟计算技术股份有限公司-官网
This config does not contain the full chip name, so probably they use it for all their Wi-Fi drivers and set it according to what the individual chip supports.
While Wi-Fi 6 generally supports both frequencies, as far as I understand the specification, a product is not required to support both for Wi-Fi 6 branding? Still, if feels like fooled, as Wi-Fi 5 was 5 GHz only and 2.4 GHz only feels like Wi-Fi 4 
.
1 Like
There is enough information that says 2.4GHz only, but I’ve also seen lots of documentation in the past that was deliberately modified by marketing departments to better delineate product ranges (Upsell).
e.g. The the ancient CPU in the computer I’m using right now according to Intel supports a maximum of 24GiB of RAM, the motherboard documentation from ASUS says the exact same. But yet my desktop currently has 48GiB of RAM in it, all fully tested with Memtest86+ v6.
1 Like
I’m using the board with my Arch Linux, btw the command still the same.
$ iw reg get
global
country TH: DFS-FCC
(2402 - 2482 @ 40), (N/A, 20), (N/A)
(5170 - 5250 @ 80), (N/A, 17), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 24), (0 ms), DFS, AUTO-BW
(5490 - 5730 @ 160), (N/A, 24), (0 ms), DFS
(5735 - 5835 @ 80), (N/A, 30), (N/A)
1 Like
Okay, the county code is ruled out then.
I’ll keep watching these drivers, just in case they really enable 5 GHz support some time later (and the hardware is actually capable of it).
the 5G code seems to be there too,
could be the firmware has to come up to speed.
A very helpful post for the ECR6600U wifi dongle!
Thank you very much 
I was stalled by the wrong firmware version for 2 days 
It’s so sad that the docs of GitHub - eswincomputing/eswin_6600u and starfive did NOT say the ECR6600U wifi dongle driver verson and firmware version MUST match, and they did NOT provide the match relation table
2 Likes
Anyone knows why 6600U dongle heats so much and eats about 0.6W when on? This ruins both powersaving and safety (although I’m not worried about both now).
In my VF2 SBC, the ECR6600U dongle consums more power, about 0.8W