Stephen Warren wrote: > I'm making progress on getting firmware upgrades working for me. <SNIP> > 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!
This is really fortunate for us!
> 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
This is consistent with what I found. Oh, damn, looks like I never put that
in an email.
Anyway, from dumping the staging area I found that bytes 2 and 3 were
untouched as well. Bytes 4 and 5 I knew were "set", but I didn't know from
what (I guessed from existing firmware), and clearly you know my theory on 0
and 1.
Now that you have TWO firmwares, that's awesome, and clears up a lot about
bytes 0, 1, 4, and 5. Come to think about it, I don't know why I left the
code updating bytes 2 and 3 since I saw the official code wasn't doing that.
Hmm. Odd.
> b) Need to find the (checksum?) algorithm that generates the first 2
> bytes of firmware data to write.
This is the important bit. Annoyingly there's not even a nice way to pull
the version number from the XML file. It's THERE, but it's burried in text:
<PHASE>
<NAME>Upgrading 880 Application firmware to version 4.0.13
(20050504_165503)</NAME>
It would suck to rely on pulling NAME and then parsing it and hoping for the
best. If there was a better way I'd say that as an interim solution we could
have a table of version->magicnumber...
Anyway - one thing to keep in mind is that the magic number is either IN the
firmware data somewhere or the remote is calculating it - because it
*displays* the magic numbers when you boot into safemode.
> c) libconcord should hard-code/calculate the first bytes 0..5 of
> firmware, not read them from flash.
Indeed. I'm going to change this code now to something more sensible. OK,
well, after the checkin that's coming in a minute.
> 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 has been a huge help, thanks! Sorry I didn't post about bytes 2 and 3 -
I could have sworn I did. Ah well.
--
Phil Dibowitz [EMAIL PROTECTED]
Open Source software and tech docs Insanity Palace of Metallica
http://www.phildev.net/ http://www.ipom.com/
"Never write it in C if you can do it in 'awk';
Never do it in 'awk' if 'sed' can handle it;
Never use 'sed' when 'tr' can do the job;
Never invoke 'tr' when 'cat' is sufficient;
Avoid using 'cat' whenever possible" -- Taylor's Laws of Programming
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- 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
