Stephen Warren wrote:
> Phil Dibowitz wrote:
>> Stephen - here's what I need, if you don't mind: upgrade to the latest
>> firmware using the official software, then dump the firmware using our
>> software (CVS latest, please), and send that file to me. Let me see the
>> magic bits there, compared to the file, and I can compare that to *my*
>> firmware's magic bits compared to my firmware file itself. If I can use your
>> magic bits to make your file work, then I know I'm write and I just have to
>> figure out how to generate the magic bits. If that doesn't work, I'm wrong,
>> and I go look somewhere else. But I'm pretty sure I'm right.
> 
> Emailed off-list.
> 
> One thing I noticed; if I force the remote into safe-mode, it shows a
> couple values on the display:
> 
> A.85FB
> B.09DE
> 
> The 85FB value is bytes 1 and 2 (0-based) of the firmware dump. So, I
> guess that's a checksum of some kind. No idea what the other bytes are
> yet though.

Your first several bytes are the same as mine. In fact, your firmware dump
is identical to mine (which doesn't bode well for a simple answer) - which
is a lot different than what's in the file form the website. This is
unfortunate. As far as I can tell, they're taking 64K of data from there,
and transmogrifying it into a similar, but different 64K of data, and then
writing that. Examples below.

If you're interested in digging into this, here's a good place to start:

apply this patch:

--- libconcord/libconcord.cpp   9 Mar 2008 01:50:48 -0000       1.6
+++ libconcord/libconcord.cpp   12 Mar 2008 04:12:51 -0000
@@ -1036,6 +1036,7 @@
                string hex;
                uint8_t *ptr = *out;
                while (GetTag("DATA", tmp, &hex) == 0) {
+                       printf("DEBUG: %s\n", hex.c_str());
                        convert_to_binary(hex, ptr);
                }
        }
@@ -1047,6 +1048,7 @@
                return LC_ERROR_OS_FILE;
        }

+       exit(1);
        return 0;
 }


That does two things (this is probably obvious): prints the HEX it's reading
from a file (but without the XML), and exits as soon as it's done reading a
hex file. Now recompile and run this with -F against your dump and against
the file the site gave you (it won't write anything to your remote, but
you're remote will need to be plugged in). But when you run it, run it like
this:

  sudo concordance -F/tmp/fw | awk '/DEBUG/ {print $2}' > /tmp/just-the-hex

That will generate a file, 'just-the-hex' - do this once for each, and then
run "diff -y just-the-hex1 just-the-hex2" - that'll put the files in columns
and show you similar lines, new lines, removed lines, etc. in a way that's a
bit easier for this purpose than the usual unified format diff.

In MOST cases one or two bytes per line are different. In a few cases an
extra several lines are inserted/removed. It's quite odd.

For example, this chunk of data is removed from the middle:

FB6B72ECCEF01F0EF86EE00EF76EC10EF66EC00EF66E5D0EF56E0C000800F <
B2F2C00EF66E940EF56E0C00C10EF66EC00EF66ED10EF56E0C00C10EF66EC <
F66E200EF56E0C00C10EF66E0B0EF56E0C00C00EF66EFB0EF56E0C00C10EF <
040EF56E0C00C00EF66ECA0EF56E0C00C10EF66EF56A0C00270EF56E0C00F <
...
5C0EF56E0C00C10EF66EDDC2E8FF25EE00F0DECFF5FF0C00DECFF5FF0C00E <
69EF9FF01200C2C300F0016A00C0D6F2C1C3D7F2A00E0301D880BF550201D <
800E006E0301BF51D880005401E33AD0A00E006E0301C051D880005401E33 <
0301C3510201D880D85502E2C3C3D8F2C00EF66E750EF56E0C00C10EF66EC <
F5FF0C000C00C00EF66E150EF56E0C00C10EF66EBFC3F5FF0C009F0EF56E0 <
C00EF66E5C0EF56E0C00C10EF66ED8C2E8FFD7C2F5FF0C00D6C2F5FF0C00E <
B9EF9FF012001F0EF86EE00EF76EC10EF66EC00EF66E750EF56E0C00C10EF <

and then this (larger) chunk is added in later in the file:

FCE112005BC1C6F303011E0EC56F03010A0EC46F89EFA0F00201626B5B6B5 <
5D6B616B636B646B120065C2B1F1FBEC8FF00201B16F0F0E0201B1150201B <
0201B251070815E20201B2510A0A0DE0030A07E0010A01E00CD002010F0EB <
...
E051DD5D17E2E0C200F0016A026A0050E3270150E4230250E523DDC200F00 <
026A0050E35F0150E45B0250E55BE0C2DDF2E6D71F0EE66FDE51030A0FE00 <
0DE00D0A0BE0020A09E00B0A09E11C0EE66FDF51030B04E11D0E01D01E0EE <
E051DD5D06E1E151DE5D03E1E251DF5D22E0E6C200F0016A026A0050E3270 <
E4230250E523DDC200F0016A026A0050E35F0150E45B0250E55BDD6BDE2BD <
0B08AEE2DE6BDF2BE251D880DF55A8E2E36BE46BE56BE3C200F0E4C201F0E <
02F0800E226E510E236E010E246E00C01DF001C01EF002C01FF023ECD3F01 <

and then this chunk is removed, later in the file:

700A37E0A00A31E0200A0DE0600A08E0200A01E054D10201010E626F02014 <
0201020E02D00201040E626F65C2B2F1AFEC8FF002015D6F65C2B2F1AFEC8 <
02015C6F65C2B2F1AFEC8FF002015B6F65C2B2F1AFEC8FF002015F6F65C2B <
...
6251040A05E0010A1BE0030A19E017D0100E61275E515F1102E1626B12006 <
006E016A00505E5F01505F5B016A026A00505B2701505C2302505D2312006 <
120002012D6B2E6B0201B26B020EB25D2AE2B251050DF3CFE9FFF4CFEAFF2 <
E926020EEA22EF6AB251050DF3CFE9FFF4CFEAFF230EE926020EEA22EE52E <
B251050DF3CFE9FFF4CFEAFF230EE926020EEA22020EE926000EEA22EE6AE <
EE6AB22BD3D7120000018651040B04E18651020B01E112000201B26B020EB <
67E2B251050DF3CFE9FFF4CFEAFF230EE926020EEA22EF50010B57E0B2510 <

Then there's a huge section that's just mostly different, and then a section
of FFFF's removed.

But there's also tons of lines like this:

0201095132E10201EC6BBBCFE9F2BCCFEAF2EB6BA1A014D0A190BBCFE9F2B
vs
0201095132E10201E76BBBCFE4F2BCCFE5F2E66BA1A014D0A190BBCFE4F2B

There's only 4 bytes difference in that line - and on it goes with
almost-identical lines for about 20 lines, and that happens all over the place.


Hmm. What might be interesting is doing an upgrade with the official
software and then doing a dump of the 'scratch' space. I suspect *part* of
the transmogrification is happening in the software but part is happening on
the remote. If we can remove all of the noise from the changes the remote
makes when it copies it, that may make this vastly easier.

Maybe I'll do that tonight if I get a chance.
-- 
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


Attachment: 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

Reply via email to