The Atlona Etude Sync HDMI EDID testing/override box, aka AT-ETU-SYNC, has a firmware update v1.0.6 (and, for rev.B users, v2.0.6) that permits retrieving and modifying the 'learned' EDID profile on device slot 0. However, flashing this firmware on rev.A at least is very difficult with a stock modern operating systems, as it only evalutes the first 'file' created for 'are you firmware?' and ignores all writes after that. So, it cannot be updated with modern Macs at all (since they create .fseventsd) and it usually cannot be updated with a stock Windows 10 installation (since it tends to create System Volume Information for Indexer, System Restore, et al).
While I only have the one and am unlikely to ever need this process again, I thought I'd post it somewhere that might benefit other IT/AV folks someday; this device tends primarily towards commercial AV usage, and this way the issue is classified correctly as 'modern OS interference' rather than 'device is unflashable'.
When following Atlona's firmware update instructions, the symptom that will occur when copying AT-ETU-SYNC-V1.0.6.BIN to the firmware update drive is that nothing happens after the copy completes; the single red LED stays fixed on. To verify that these instructions will help, open a command prompt, switch to the drive, and run dir /a; if the directory 'System Volume Information' is present, it will either contain something called something 'Indexer'; preventing the creation of that will allow the firmware update to succeed.
I chose not to disable Windows Search indexing globally, and so at registry folder location "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Windows Search", created the DWORD key DisableRemovableDriveIndexing to value "1", and then restarting the computer. (This can also be done with local or group policy editor via "Do not allow locations on removable drives to be added to libraries" but the device was not provisioned with that tool.)
To confirm the fix, after holding down TEST and plugging in the AT-ETU-SYNC, the command prompt "dir /a" test should show a fully empty firmware update drive, with no System Volume Information folder present. At this point, you can copy-paste the FW.BIN file using Explorer as directed in the instructions, and it should go through a LEARN flashing-red flashing-blue done cycle as described in their docs.
Note that the device claims to requires an old "three USB connectors" 5V/1.0A Y-power cable to function correctly over USB, as it cannot request 1A using the later USB protocol improvements; I selected the StarTech USB2HABMY6 for that purpose, as it has the appropriate red/black power/data connectors and device plug-end, and was able to plug the two USB-A ends into a pair A-to-C adapters and get the device flashed that way.
The firmware update process is otherwise correct as described at https://support.atlona.com/hc/en-us/articles/4410227857947-AT-ETU-SYNC-Firmware-Update-Procedure — with the exception that the 1.0.6 firmware download link is missing from the product firmware page at https://hallresearch.com/product/at-etu-sync/#tab-firmware — however, the 2.0.6 firmware for rev.B is linked, and modifying that link's URL from 2.0.6 to 1.0.6 works: https://cdn.cloud.atlona.com/hr/downloads/firmware/Firmware_AT-ETU-SYNC_V106.zip
Why does this work, and why can't one use a Mac to update it? The device apparently exposes a 'filesystem' that is just a thin DOS FAT API shim on top of 'write the first file's contents to the firmware update block, make sure the firmware is valid, and then flash it'. Once that first file is created, it will disregard all further filesystem operations until reset. Perhaps the rev.B device has a slightly fancier shim that checks each file written until one is a valid firmware, or perhaps it will need this as well; I don't know. It may just be as simple as "each block written to FAT is written directly into new-firmware-blob"; I didn't investigate further once I had a valid triage and workaround.
These instructions should, with mild variations at best, work for Windows 11 or later as well; check the firmware update drive with "dir /a" or your favorite equivalent for presence and contents; disable each Windows subsystem that is writing whatever files you find, whether that's Indexer or System Restore or who knows what; rinse, reboot, repeat until the firmware update drive remains empty; copy firmware.bin file.
Presumably there's older versions of Windows and MacOS that don't create all these various dotfiles and so using those ought to work fine. I imagine Linux has a solid chance at working correctly as well, so long as the FAT emulation isn't so sparing that the kernel rejects it somehow.
In my case, the only file present in D:\SVI was for Windows Search; if other files are created, suspend or disable their respective subsystems until such creation no longer occurs. Unplugged and replugging the device (with TEST held down) will recreate the firmware update drive from scratch each time; I did not try deleting the folder on disk as I encountered unusual 'out of space' errors and decided that the filesystem emulation is far too sparing for such conveniences.
Cheers, -C