I'm making progress on getting firmware upgrades working for me. 1)
A few weeks ago whilst using the Windows software, I was prompted to install new firmware, so I did. This download was: 4.4.2 (20071220_190125) Now, when I follow the firmware link on the website, I end up downloading: 4.0.13 (20050504_165503) Who knows why. Perhaps Logitech found a bug in 4.4.2 and rolled it back? Anyway, I now have 2 sets of firmware bits to play with. They both seem to work for me! 2) Both sets of downloaded firmware files start with 6 FF's. When the Logitech software upgrades the firmware, it does this: Sets bytes 0,1 to some firmware-specific value (checksum???) 0xD8 0xF8 for 4.4.2 0xFB 0x85 for 4.0.13 Leaves bytes 2, 3 as FF Sets bytes 4, 5 to constant 0x48, 0x47 3) If I read back the firmware using concordance after an upgrade using Logitech's software, I see that the in-flash firmware has had a minor modification during the upgrade process in the remote. Specifically, byte 2 has been cleared from 0xFF to 0x00. My (complete) guess would be some kind of successful-boot flag to prevent a broken firmware update from crashing the remote; maybe the bootloader validates this gets set on the first boot of a new firmware, and forces safe-mode next time if it didn't get set. Who knows; it probably doesn't really matter to us, except to imply that we shouldn't read existing flash content to set the first 6 bytes of firmware programmed, since it gets changed inside the remote. 4) I modified libconcordance to do the following: a) Log all USB reads/writes for debugging. b) Hard-code the first 6 bytes of firmware, instead of getting them from existing flash c) Read back the firmware from firmware_upgrade_base immediately after writing the flash inside write_firmware_to_remote. With the above modifications, I can successfully update my remote using either firmware file I have (hard-coded bytes in (b) above modified to match the firmware I'm loading) 5) I believe this means the next steps are: a) Investigate which specific libconcord change made things work for me. b) Need to find the (checksum?) algorithm that generates the first 2 bytes of firmware data to write. c) libconcord should hard-code/calculate the first bytes 0..5 of firmware, not read them from flash. d) Work out how this all works for remotes other than the 880. As I mentioned before, the other firmware files in Kevin's harmony_usb_logs.zip file don't all have 6 bytes of FFs at the beginning - at least some only have 4. I need to compare the EZHex and XML files for those other remotes to check, but I'm pretty convinced at this point that the number of bytes to overwrite, and the values to use (perhaps even checksum algorithm), will be at least partially be arch-dependent. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
