SteveAR
Full Member
Karma: +4/-1
 Offline
Posts: 103
|
 |
« Reply #15 on: November 15, 2016, 07:21:18 PM »
|
|
|
So I rolled the dice with P6.3 and it worked first time. Read/saved/closed. Haven't gone to look at the file yet though. Anyways, thanks so much for your help! I definitely wouldn't have figured that out on my own, I would have just gave up and started monkeying around with my chip clip etc. Doing it in the car is way easier. So is this all tribal knowledge or is there some guide/document which outlines this stuff? EG what P6.3 is and how you knew that was correct. In my world, P6 would be the reference designator for the IC on the PCB and 3 would be the pin. However I am looking at my ECM's and they don't have silkscreened reference designators.....
Onward and upward!
|
|
|
|
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #16 on: November 15, 2016, 09:47:38 PM »
|
|
|
So is this all tribal knowledge or is there some guide/document which outlines this stuff?
This is EXACTLY the problem; I wish there was a central db to keep track of this crap. |
|
|
|
|
Logged
|
|
|
|
SteveAR
Full Member
Karma: +4/-1
Offline
Posts: 103
|
|
« Reply #17 on: November 16, 2016, 08:24:53 AM »
|
|
|
So might as well ask one more question. Or maybe 10. I understand that when using the ME7 flash tool (the one for flashing the main memory/tunes etc.) that the checksum will change. And on power up, the ECM compares a stored checksum value to the real-time value it reads. And if they don't match it won't start. Hence the need for updating the stored checksums.
Does the ECM also go through this process for the IMMO IC I've been working with? EG if I were to change the memory blocks where the VIN is stored, the IMMO IC would then technically have a different checksum. Is there a check process for this IC as well or only the main memory area where the ECM's tune/engine management code is stored?
|
|
|
|
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #18 on: November 16, 2016, 11:04:04 AM »
|
|
|
Yes, the eeprom has it's own checksums.
|
|
|
|
|
Logged
|
|
|
|
SteveAR
Full Member
Karma: +4/-1
Offline
Posts: 103
|
|
« Reply #19 on: February 20, 2017, 06:22:27 PM »
|
|
|
OK well back at this project again. I've been re-familiarizing myself with everything in this post. I was able to again use the ME795040.exe program to do a EEPROM dump of my ECM. I then used the 95040tool to change the VIN of that dump BIN. My understanding of that tool is that it also corrects checksums unless otherwise specified. I then wanted to run another program just to do a double-check of the checksum. I've downloaded a few of the other programs off this site and here are the results I get when I run them on a few of my eeprom dumps:
Checksum85040.exe - Seems to work on a 2.7T stock EEPROM dump I have. (512K) Doesn't report any errors, doesn't report anything. When I run it on the BIN above, I get an error stating it expects to see 512K and it finds 1024K. Seems it's not happy with the chip used for my 4.2's EEPROM.
ME7sum.exe - Tried on 2.7T dump and 4.2L dump. Reports "odd size" for both. I'm guessing this is a tool for the main firmware CS check?
ME7Check.exe - Same as ME7sum except slightly different errors. Both errors indicate expected size vs. actual size.
(note, someone else responded in another post that these tools are for firmware only)
ME9sum.exe - This tool runs on both my experimental BINs. Except my 2.7T .BIN is stock, no mods, but this tool reports that it changed 76 checksums. Nothing should have had to been changed. This tool does the same thing with my 4.2 BIN's, both the stock dump and the VIN-modified version. I don't think this tool is working right since it's reporting it has updated checksum's for BIN files that have not been modified.
SO, big question, what tool(s) can I use to check/correct the checksums of my EEPROM(s)? I like that the 95040tool (supposedly) corrected the checksums after the VIN modification, but I need to change the SKC over as well. I didn't see a option to update the SKC in the tools documentation, so I figured I'd have to go into the BIN and change the two hex values accordingly; then correct the CS's after.
Help appreciated, I'm probably missing something simple.
It's worth noting that my EEPROM on my 4.2L is a SP08C3 and is 1024 bytes. When I look at the BIN in a hex editor, 513-1024 is just all FF's. There's no data in that section of memory. Once I get this all sorted out and working as-is, I'd like to try putting a more common 512 IC in there to see what happens.
ME7.1.1
4.2L V8
4D0907560BE
EEPROM SP08C3
|
|
|
|
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #20 on: February 20, 2017, 06:47:17 PM »
|
|
|
ME9sum.exe - This tool runs on both my experimental BINs. Except my 2.7T .BIN is stock, no mods, but this tool reports that it changed 76 checksums. Nothing should have had to been changed. This makes no sense. Please post the bin and/or the output of me7sum This tool does the same thing with my 4.2 BIN's, both the stock dump and the VIN-modified version. I don't think this tool is working right since it's reporting it has updated checksum's for BIN files that have not been modified. 4.2 support is not fully tested. Please post the bin and/or the output of me7sum As a future note, do not use "CS" to mean "checksum", it means "chip select", especially in the context of eeproms. |
|
|
|
|
Logged
|
|
|
|
SteveAR
Full Member
Karma: +4/-1
Offline
Posts: 103
|
|
« Reply #21 on: February 20, 2017, 07:03:57 PM »
|
|
|
Attached is a fresh dump from my Daily Driver. 2004 Allroad 2.7T/6MT. (file 27T.BIN)
I've also attached a fresh dump of my 4.2L ECM EEPROM. (42.BIN)
Not sure how to get what's in my Command window into this forum other than doing a screen shot. Did you want the ME7sum info or the ME9sum info?
Here's what they all say/do:
c:\ME7SUM 27t.bin
Attempting to open firmware file 27t.bin
File is an odd size (512 bytes). Are you sure this is a firmware dump?
warning! 1/1 uncorrected error(s) in 27t.bin!
C:\ME7SUM 42.bin
Attempting to open firmware file 42.bin
File is an odd size (1024 bytes). Are you sure this is a firmware dump?
warning! 1/1 uncorrected error(s) in 42.bin!
C:\ME9SUM 27T.bin
runs and reports 76 checksums corrected
C:\ME9SUM 42.bin
runs and reports 76 checksums corrected
Thanks for the tip on CS/checksum. What a unfortunate coincidence....
|
|
|
|
|
Logged
|
|
|
|
SteveAR
Full Member
Karma: +4/-1
Offline
Posts: 103
|
|
« Reply #22 on: February 20, 2017, 07:15:25 PM »
|
|
|
ECM PN's:
27T.BIN came from a 4Z7907551S
42.BIN came from a 4D0907560BE
|
|
|
|
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #23 on: February 20, 2017, 09:10:50 PM »
|
|
|
You did NOT provide the output of your command, nor did you provide the bin. Furthermore, unless you specified an output file, no correction would be done at all, so "runs and reports 76 checksums corrected" makes zero sense. $ ./me7sum bins/4Z7907551S.bin
ME7Sum (v1.0.3-5-g2aec-dirty) [Management tool for Bosch ME7.x firmwares]
Inspiration from Andy Whittaker's tools and information.
Written by 360trev and nyet [BSD License Open Source].
Attempting to open firmware file 'bins/4Z7907551S.bin'
Step #1: Reading ROM info ..
Searching for EPK signature...OK
Searching for ECUID table...10: '1037368391'
12: '4Z7907551S '
4: '0020'
15: '2.7L V6/5VT '
OK
EPK : '42/1/ME7.1.1/5/6030.03//25A/Dst48o/030603//'
Part Number : '4Z7907551S '
Engine ID : '2.7L V6/5VT '
SW Version : '0020'
HW Number : '0261208288'
SW Number : '1037368391'
Step #2: Reading ROMSYS ..
Startup section: word[0x008000]+word[0x00FFFE]
@008038 Add=0x012DE5 CalcAdd=0x012DE5 ADD OK
Program pages: 8k page first+last in 0x0000-0xFFFF and 0x20000-0xFFFFF
@00803c Add=0x92634D CalcAdd=0x92634D ADD OK
All param page: word[0x010000]+word[0x01FFFE]
@01e198 Add=0x00971D CalcAdd=0x00971D ADD OK
Step #3: Reading RSA signatures ..
Searching for RSA offset #0...OK
Searching for RSA offset #1...OK
Signature: @a9c28-a9ca8
Modulus: @16a8a-16b0a
Exponent: @16b0a = 3
Searching for MD5 ranges...OK
MD5 Block Offset Table @16a66 [32 bytes]:
1) 0x00010002-0x00013FFE
2) 0x00014382-0x00017F4E
3) 0x00018192-0x0001FBDC
4) 0x00026A00-0x0002FFFC
EncrMD5: 7f be 56 1f 8f 23 26 a3 1f 6b 63 5a 95 8d ae a9
CalcMD5: 7f be 56 1f 8f 23 26 a3 1f 6b 63 5a 95 8d ae a9
OK
Step #4: Finding CRC table(s) ..
Searching for CRC table(s)...OK
CRC table(s) OK
Step #5: Reading Main Data Checksums ..
Searching for main data CRC pre block...missing
Searching for main data CRC/csum blocks...OK
Searching for main data CRC offsets...missing
Searching for main data checksum offsets...OK
Main Checksums:
1) 0x010002-0x013FFE CalcCSM: 00128CEA
2) 0x014382-0x017F4E CalcCSM: 0029E5A4
3) 0x018192-0x01FBDC CalcCSM: 00478B9E
4) 0x026A00-0x02FFFC CalcCSM: 00A676D2
@aa46e CSM: 00A676D2 CalcCSM: 00A676D2 OK
Step #6: Reading Main Program Checksums ..
Searching for main program checksum..OK
ROM Checksum Block Offset Table @27fa4 [16 bytes]:
1) 0x000000-0x00FBFF CalcChk: 4754B0AC
0x00FC00-0x01FFFF CalcChk: 23D7E11A CalcCRC: AC9B1E66 SKIPPED
2) 0x020000-0x0FFFFF CalcChk: B242A57F
@fffe0 Chk: B242A57F CalcChk: B242A57F OK (i)
Step #7: Reading Multipoint Checksum Blocks ..
Searching for multipoint block descriptor #1...missing
Searching for multipoint block descriptor #2...OK
1) <1fbde> 0x000000-0x003FFF Chk: 0E59D5C8 Boot: (whitelisted) OK
2) <1fbee> 0x004000-0x007FFF Chk: 1077FB35 Boot: (whitelisted) OK
3) <1fbfe> 0x000000-0x003FFF Chk: 0E59D5C8 CalcChk: 0E59D5C8 OK
4) <1fc0e> 0x004000-0x007FFF Chk: 1077FB35 CalcChk: 1077FB35 OK
Multipoint #2: [66 blocks x <16> = 1056 bytes]
*** Found 70 checksums in bins/4Z7907551S.bin
*** DONE! 0 error(s) in bins/4Z7907551S.bin! ***
md5: $ md5sum bins/4Z7907551S.bin
f298f584b27898d95d959b233619c8ba *bins/4Z7907551S.bin
|
|
|
|
« Last Edit: February 20, 2017, 09:13:19 PM by nyet »
|
Logged
|
|
|
|
SteveAR
Full Member
Karma: +4/-1
Offline
Posts: 103
|
|
« Reply #24 on: February 21, 2017, 06:12:46 AM »
|
|
|
Thank you, I will try specifying the output .BIN tonight when I get home. The MED9sum tool creates it's own output file if none is specified so I incorrectly assumed that ME7sum does the same thing.
"Usage is the same as ME7sum, and 95040sum:
MED9sum [input.bin] [output.bin]
Failure to specify output will result in the file being named [input]-CHKOK"
I am getting all these programs mixed up.....
As far as this comment:
"Furthermore, unless you specified an output file, no correction would be done at all, so "runs and reports 76 checksums corrected" makes zero sense."
This was the message I received when running my .BINs with MED9sum, not ME7sum. So I hope that makes more sense now? If not I can send you screen shots of me running my BIN's through MED9sum so you can see what it reports.
C:\MED9SUM 27T.bin
runs and reports 76 checksums corrected
C:\MED9SUM 42.bin
runs and reports 76 checksums corrected
|
|
|
|
|
Logged
|
|
|
|
SteveAR
Full Member
Karma: +4/-1
Offline
Posts: 103
|
|
« Reply #25 on: February 21, 2017, 06:14:54 AM »
|
|
|
I don't know why I used med9sum, I just wanted to try it to see if it was backwards compatible to ME7.......
|
|
|
|
|
Logged
|
|
|
|
SteveAR
Full Member
Karma: +4/-1
Offline
Posts: 103
|
|
« Reply #26 on: February 21, 2017, 10:28:57 AM »
|
|
|
Still missing something here and I don't know what. Are these tools for EEPROM bins, FIRMWARE bins or both? Here are the instructions I found: http://nefariousmotorsports.com/forum/index.php?topic=3347.0title=To check image.bin:
ME7Check image.bin
me7sum image.bin
To output corrected checksums you must specify an output file:
me7sum image.bin out.bin
So I did: me7sum.exe 27T.bin output.bin Result: Attempting to open firmware file 27t.bin File is an odd size (512 bytes). Are you sure this is a firmware dump? Then I did: me7Check.exe 27T.bin output.bin Result: Just provides usage instructions. Then I did: me7Check.exe 27T.bin Result: me7check: binary file 27t.bin has not correct length (is 0x200 bytes long, 0x80000 or 0x100000 bytes expected) I scrolled to the very top of what you posted and I only see you calling "me7sum bins/4Z7907551S.bin" Did you re-name my 27t.bin to 4Z7907551S.bin or are you opening a 4Z907551S.bin file you already had on hand? $ ./me7sum bins/4Z7907551S.bin
ME7Sum (v1.0.3-5-g2aec-dirty) [Management tool for Bosch ME7.x firmwares]
Inspiration from Andy Whittaker's tools and information.
Written by 360trev and nyet [BSD License Open Source].
Attempting to open firmware file 'bins/4Z7907551S.bin'
Step #1: Reading ROM info ..
Searching for EPK signature...OK
Searching for ECUID table...10: '1037368391'
12: '4Z7907551S '
4: '0020'
15: '2.7L V6/5VT '
OK
etc.... I do not get all this info. |
|
|
|
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #27 on: February 21, 2017, 11:53:29 AM »
|
|
|
Still missing something here and I don't know what. Are these tools for EEPROM bins, FIRMWARE bins or both? Here are the instructions I found:
SIGH
So I did:
me7sum.exe 27T.bin output.bin
Result:
Attempting to open firmware file 27t.bin
File is an odd size (512 bytes). Are you sure this is a firmware dump?
This doesn't answer your question? me7Check.exe 27T.bin
Result:
me7check: binary file 27t.bin has not correct length (is 0x200 bytes long, 0x80000 or 0x100000 bytes expected)
Or this? I scrolled to the very top of what you posted and I only see you calling "me7sum bins/4Z7907551S.bin" Did you re-name my 27t.bin to 4Z7907551S.bin or are you opening a 4Z907551S.bin file you already had on hand?
Why would I rename your bin, which isn't flash image? |
|
|
|
|
Logged
|
|
|
|
SteveAR
Full Member
Karma: +4/-1
Offline
Posts: 103
|
|
« Reply #28 on: February 21, 2017, 01:32:00 PM »
|
|
|
It's my understanding of vernacular that a EEPROM dump is that of the 8 PIN IC on the back of the ECM which holds the VIN/SKC etc and the firmware is the main flash/tune of the ECM. In my post yesterday I was asking for direction to the best tool to check/correct the checksums for my EEPROM. If you or anyone else can direct me toward that I would appreciate it.
From Yesterday:
SO, big question, what tool(s) can I use to check/correct the checksums of my EEPROM(s)? I like that the 95040tool (supposedly) corrected the checksums after the VIN modification, but I need to change the SKC over as well. I didn't see a option to update the SKC in the tools documentation, so I figured I'd have to go into the BIN and change the two hex values accordingly; then correct the CS's after.
Help appreciated, I'm probably missing something simple.
It's worth noting that my EEPROM on my 4.2L is a SP08C3 and is 1024 bytes. When I look at the BIN in a hex editor, 513-1024 is just all FF's. There's no data in that section of memory. Once I get this all sorted out and working as-is, I'd like to try putting a more common 512 IC in there to see what happens
|
|
|
|
|
Logged
|
|
|
|
SteveAR
Full Member
Karma: +4/-1
Offline
Posts: 103
|
|
« Reply #29 on: February 22, 2017, 01:27:10 PM »
|
|
|
For the interest of anyone else reading/following this thread, I found a tool to check/correct my EEPROM BIN/checksums. It's 95040sum.exe. I ran this on my stock 2.7T EEPROM dump (512 bytes and likely a 95040 IC) and it reported no corrections needed. (expected result) I then ran it on my 4.2 EEPROM dump (1024 bytes) and unfortunately the program only works on 512 sized EEPROMS. It reported "file must be 512 bytes."
I'm going to try and figure out if there's a different version of this tool available or figure out who wrote it.
|
|
|
|
|
Logged
|
|
|
|
|
