See Fir fileformat first
Update payload format[]
When decrypted, the update payload looks like this (here version 1.0.6 of 550D/T2i, which model_id is 0x80000270) :
$ python dump_fir.py -v 0270_106_firmware.bin
Dump_fir 0.3 (01Jan2011)
fileLen = 0x82afc0
0x000: checksum = 0xcea52d1b
0x004: 0x00000000
0x008: 0x00000002
0x00c: 0x00000000
0x010: nb_record = 0xa
0x014: table_offset = 0x20
0x018: nb_record = 0x18
0x01c: size_after = 0x82aea2
0x020: ---patches table---
+ tag + foffset + size + moffset
---------------------------------------------
0x01: 0x0200 0x00000110 0x00001914 0x00000000 <-- srecords (k270_eep.mot)
0x02: 0x0200 0x00001a24 0x000b0d02 0x00000000 <-- srecords (k176_mpu, k270_mpu)
0x03: 0x0100 0x000b2726 0x0003fc2c 0xf8fc0000 <-- bind, cipher, boot
0x04: 0x0100 0x000f2352 0x00034a40 0xf8910000 <-- fix data
0x05: 0x0100 0x00126d92 0x0001045c 0xf8970000 <-- rasen data
0x06: 0x0100 0x001371ee 0x00008ddc 0xf8eb0000 <-- lens data
0x07: 0x0100 0x0013ffca 0x00000c24 0xf88f0000 <-- ring data
0x08: 0x0100 0x00140bee 0x0018cafc 0xf85b0000 <-- GUI resources
0x09: 0x0100 0x002cd6ea 0x0055ce08 0xf8010000 <-- main firmware
0x0a: 0x0102 0x0082a4f2 0x00000abf 0x00000000 <-- update script
0x110: ---patch#1---
Tags of type #100 contains code or data written to the main flash memory. Here record#9 is flashed at 0xf8010000 (and can be found also at 0xff010000). This is ARM code.
Do not ask me, what are Fix, Rasen and Ring, I do not know...but firmware functions can be write these area to the SD/CF card, see Camera Settings properties. And yes, Canon can also update the bootcode.
Canon SRec format[]
Jollyrogerxp found that tags of type #0x200 are in a format very similar to SREC format. I wrote a tool to dump the content of these records:
Here the 0270_106_01.bin is record#1 of the payload above, of size 0x1914.
(summary mode)
$ python dump_srec.py 0270_106_01.bin Dump Canon SRec (0x200) k270_eep.mot 4765 bytes, 0x0-0x37f0
(verbose mode)
0x000000: 00 0f 0000 k270_eep.mot d5 d5 0x000011: 01 13 0000 = ffffffffffffffffffffffffffffffff fc OK 0x000026: 01 05 03ce = ffff 2b OK 0x00002d: 01 13 03d0 = ffffffffffffffffffffffffffffffff 29 OK 0x000042: 01 13 03e0 = ffffffffffffffffffffffffffffffff 19 OK 0x000057: 01 13 03f0 = ffffffffffffffffffffffffffffffff 09 OK 0x00006c: 01 13 0400 = ffffffffffffffffffffffffffffffff f8 OK 0x000081: 01 13 0410 = ffffffffffffffffffffffffffffffff e8 OK 0x000096: 01 13 0420 = ffffffffffffffffffffffffffffffff d8 OK 0x0000ab: 01 13 0430 = ffffffffffffffffffffffffffffffff c8 OK 0x0000c0: 01 13 0440 = 016400d30682836b80ffffffffffffff 81 OK 0x0000d5: 01 13 0450 = ffffffffffffffffffffffffffffffff a8 OK 0x0000ea: 01 13 0480 = 05f6053dffff0000146496c820405010 97 OK 0x0000ff: 01 0d 0490 = 30400480050004800500 dc OK 0x0001a1: 01 13 06a0 = 1060201002033c0a41484b096c2e14d5 fb OK 0x0001b6: 01 05 06b4 = 64c8 14 OK 0x0001bd: 01 04 06bd = 07 31 OK 0x0001c3: 01 04 06cf = eb 3b OK 0x0001c9: 01 13 06d0 = f50201000000b028408001ffffffffff 8a OK ... 0x0018d0: 01 13 37d0 = ffffffffffffffffffffffffffffffff f5 OK 0x0018e5: 01 13 37e0 = ffffffffffffffffffffffffffffffff e5 OK 0x0018fa: 01 13 37f0 = ffffffffffffffffffffffffffffffff d5 OK 0x00190f: 09 03 = 0000 fc OK 4765 bytes, 0x0-0x37f0
The first column is the offset, the 2nd one is srecord type, 3rd len of data.
record format is: type(1byte), len(1byte), address(depending on type), data (0 to 16 bytes), checksum(1 byte) length is including fields [len, address if present, data] checksum is computed on same fields as length record types are: 00, len, 0000, filename, checksum 01, len, address(2bytes), data, checksum 03, len, address(4bytes), data, checksum 07, 5, 00000000, checksum (end of block) 09, 3, 0000, checksum (end of block)
there is another structure for type #0x200 (seen in M50, M6m2 updaters): 00, ??, 0020, ??, ...
In this example, it means that 0xff bytes 10 times, will be written in address 0x0000. then 0xffff at address 0x3ce, and so on... srecord of type 9 is to end the file.
Let's see with record#2 of the update
$ python dump_srec.py 0270_106_02.bin Dump Canon SRec (0x200) k176_mpu.mot 4580 bytes, 0xffff8000-0xffff9470 <-- updater k270_mpu.mot 499204 bytes, 0x0-0x7fdf0 <-- main code?
This time, we have 2 SRecords, one written at address 0xffff8000 and another one at 0x0. 0x80000176 is the model_id of 450D / Rebel XSi.
Jollyroger also confirmed it is TX19A code (Toshiba MIPS16e), like on the HV30. The small SRecord seems to be an updater, and biggest one (499204 bytes) the code to update...
SRecord files[]
So "mpu" data is for TX19A (See Datasheets). We have also "eep" and "fpu", like here on 7D 1.2.5, records #3 to #5 :
$ python dump_srec.py 0250_125_03.bin Dump Canon SRec (0x200) k250_eep.mot 933 bytes, 0x140-0x2370 $ python dump_srec.py 0250_125_04.bin Dump Canon SRec (0x200) k250_fpu 692 bytes, 0x3e000-0x3e2a0 k250_fpu 102884 bytes, 0x80000-0xffff0 $ python dump_srec.py 0250_125_05.bin Dump Canon SRec (0x200) k250_mpu.mot 4228 bytes, 0xffff8000-0xffff9470 k250_mpu.mot 393220 bytes, 0x20000-0x7fff0
on 60D 1.1.0 we have:
$ python dump_srec.py 0287_110_02.bin Dump Canon SRec (0x200) k250_mpu.mot 4612 bytes, 0xffff8000-0xffff95f0 k287_mpu.mot 393220 bytes, 0x20000-0x7fff0 $ python dump_srec.py 0287_110_01.bin Dump Canon SRec (0x200) k287_eep.mot 8860 bytes, 0x0-0x2370
60D (k287) is using 7D (k250) updater code for TX19A. 550D (k270) is using updater code from 450D (k176).
On 5D Mark II 2.0.9:
$ python dump_srec.py 0218_209_01.bin Dump Canon SRec (0x200) k218_eep.mot 487 bytes, 0x2000-0x2370 k218_eep.mot 325 bytes, 0x20c-0x7f0 k218_eep.mot 2 bytes, 0x7f0-0x7f0 k218_eep.mot 211 bytes, 0x1204-0x1a10 $ python dump_srec.py 0218_209_02.bin Dump Canon SRec (0x200) k218_mpu.mot 4228 bytes, 0xffff8000-0xffff9470 k218_mpu.mot 393220 bytes, 0x20000-0x7fff0
Update scripts[]
Content of 7D update 2.0.0 are:
0x020: ---patches table---
+ tag + foffset + size + moffset
---------------------------------------------
0x01: 0x0101 0x00000128 0x00035074 0xf8300000 <-- master properties?
0x02: 0x0101 0x0003519c 0x0001aedc 0xf8700000
0x03: 0x0101 0x00050078 0x002a0000 0xf8010000 <-- K250M ICU Firmware
0x04: 0x0200 0x002f0078 0x0000052c 0x00000000 \
0x05: 0x0200 0x002f05a4 0x000245bf 0x00000000 |-- TX19A
0x06: 0x0200 0x00314b64 0x0008b7e8 0x00000000 /
0x07: 0x0100 0x003a034c 0x00035074 0xf8910000 <-- slave properties? content is identical to record #1
0x08: 0x0100 0x003d53c0 0x00228e34 0xf8cc0000 <-- GUI resources.
0x09: 0x0100 0x005fe1f4 0x00890000 0xf8010000 <-- K250S ICU Firmware
0x0a: 0x0103 0x00e8e1f4 0x00000458 0x00000000 <-- UPD_* script
0x0b: 0x0102 0x00e8e64c 0x000000d0 0x00000000 <-- UPD_* script
Tthe following is record #10 (0x0a) of 7D update 2.0.0 :
; ˜^‰¹ƒŒƒxƒ‹
UPD_AddPropertyDataIfNotExist 0x2050017 4 "2F002F00"
; ƒ^ƒCƒ€ƒ][ƒ“
UPD_AddPropertyDataIfNotExist 0x205001F 4 "14000000"
; ƒTƒ}[ƒ^ƒCƒ€Ý’è
UPD_AddPropertyDataIfNotExist 0x2050020 4 "00000000"
; FŽû·•â³
UPD_AddPropertyDataIfNotExist 0x2050024 4 "00000000"
; ƒŒ[ƒeƒBƒ“ƒOƒWƒƒƒ“ƒvÝ’è
UPD_AddPropertyDataIfNotExist 0x2070009 4 "00000000"
; Žž
UPD_DeletePropertyData 0x2070016
UPD_AddPropertyData 0x2070016 48 "0000000000000000000000000100000000000000D0070000060000000000000000000000000000000000000000000000"
UPD_EraseFROMPropertySectorByDataType 0x02000000
UPD_WriteFROMPropertyByDataType 0x02000000
; ƒJƒXƒ^ƒ€Ý’è‚̒ljÁ
; ˜^‰¹ƒŒƒxƒ‹
UPD_AddPropertyDataIfNotExist 0x03000031 4 "2F002F00"
UPD_AddPropertyDataIfNotExist 0x03010031 4 "2F002F00"
UPD_AddPropertyDataIfNotExist 0x03020031 4 "2F002F00"
UPD_EraseFROMPropertySectorByDataType 0x03000000
UPD_WriteFROMPropertyByDataType 0x03000000
EVP_ResetCalendar
; WB’²®’lÄŒvŽZ & Tune‚ÌÄ“Ç‚Ýž‚݈—II ƒRƒƒ“ƒgƒAƒEƒgŽž‚Í—vŠm”FII
UPD_AdjustWB
;‚±‚êˆÈ~‚É‹Lq‹ÖŽ~BiƒCƒxƒ“ƒgƒvƒƒV[ƒWƒƒ‚ÌÅŒã‚͉üs•K{‚Ì‚½‚ßj
It seems this is to manipulate the properties in Flash ROM (FROM). Lines starting with ; looks like comments. Tag type is 0x103, like every odd tag (0x101), we can suppose it is fot the Master Digic.
Record #11 (0x0b) is :
; WB’²®’lÄŒvŽZ & Tune‚ÌÄ“Ç‚Ýž‚݈—II ƒRƒƒ“ƒgƒAƒEƒgŽž‚Í—vŠm”FII
UPD_AdjustWB
; ¡“ú‚̃ŠƒŠ[ƒX‚Å‚Í–³Œø‚É‚·‚é«
; ResetCalendar
;‚±‚êˆÈ~‚É‹Lq‹ÖŽ~BiƒCƒxƒ“ƒgƒvƒƒV[ƒWƒƒ‚ÌÅŒã‚͉üs•K{‚Ì‚½‚ßj
These kind of update record do also exist for other model, like the 550D. Here is the content of record #10 for update 1.0.6:
; TuneData’ljÁ PROP_H_SHADING_NR UPD_AddPropertyDataIfNotExist 0x010100f8 0x00000020 "0002000000020000000200000002000000020000000200000002000000020000" UPD_AddPropertyDataIfNotExist 0x010100f9 0x00000020 "0002000000020000000200000002000000020000000200000002000000020000" UPD_AddPropertyDataIfNotExist 0x010100fa 0x00000020 "0002000000020000000200000002000000020000000200000002000000020000" UPD_AddPropertyDataIfNotExist 0x010100fb 0x00000020 "0002000000020000000200000002000000020000000200000002000000020000" UPD_AddPropertyDataIfNotExist 0x010100fc 0x00000020 "0002000000020000000200000002000000020000000200000002000000020000" UPD_AddPropertyDataIfNotExist 0x010100fd 0x00000020 "0002000000020000000200000002000000020000000200000002000000020000" UPD_AddPropertyDataIfNotExist 0x010100fe 0x00000020 "0002000000020000000200000002000000020000000200000002000000020000" UPD_AddPropertyDataIfNotExist 0x010100ff 0x00000020 "0002000000020000000200000002000000020000000200000002000000020000" UPD_AddPropertyDataIfNotExist 0x01010100 0x00000020 "0002000000020000000200000002000000020000000200000002000000020000" UPD_AddPropertyDataIfNotExist 0x01010101 0x00000020 "0002000000020000000200000002000000020000000200000002000000020000" UPD_AddPropertyDataIfNotExist 0x01010102 0x00000020 "0002000000020000000200000002000000020000000200000002000000020000" UPD_AddPropertyDataIfNotExist 0x01010103 0x00000020 "0002000000020000000200000002000000020000000200000002000000020000" UPD_AddPropertyDataIfNotExist 0x01010104 0x00000020 "0002000000020000000200000002000000020000000200000002000000020000" UPD_AddPropertyDataIfNotExist 0x01010105 0x00000020 "0002000000020000000200000002000000020000000200000002000000020000" UPD_AddPropertyDataIfNotExist 0x01010106 0x00000020 "0002000000020000000200000002000000020000000200000002000000020000" UPD_AddPropertyDataIfNotExist 0x01010107 0x00000020 "0002000000020000000200000002000000020000000200000002000000020000" UPD_AddPropertyDataIfNotExist 0x01010108 0x00000020 "0002000000020000000200000002000000020000000200000002000000020000" UPD_AddPropertyDataIfNotExist 0x01010109 0x00000020 "0002000000020000000200000002000000020000000200000002000000020000" UPD_AddPropertyDataIfNotExist 0x0101010a 0x00000020 "0002000000020000000200000002000000020000000200000002000000020000" UPD_AddPropertyDataIfNotExist 0x0101010d 0x00000020 "0002000000020000000200000002000000020000000200000002000000020000" UPD_AddPropertyDataIfNotExist 0x01010110 0x00000020 "0002000000020000000200000002000000020000000200000002000000020000" ; TuneData’ljÁ PROP_RT_DEFCORRE UPD_AddPropertyDataIfNotExist 0x01010113 0x00000004 "00000000" UPD_EraseFROMPropertySectorByDataType 0x01000000 UPD_WriteFROMPropertyByDataType 0x01000000
It seems these keywords are used by the 550D 1.0.6 updater code:
UPD_AddPropertyUINT32Data UPD_SetPropertyUINT32Data UPD_AddPropertyData UPD_DeletePropertyData UPD_GetPropertyData UPD_SetPropertyData UPD_SavePropertyDataToTextFile UPD_EraseFROMPropertySectorByDataType UPD_WriteFROMPropertyByDataType UPD_CopyCurrentFROMPropertyByDataType UPD_AddPropertyUINT32DataIfNotExist UPD_AddPropertyDataIfNotExist UPD_WriteFROMPropertyPartly
EVP_ResetCalendar can only be found in the Master updater code of 7D (update 2.0.0)
Tag types[]
0x100: for main digic (ICU) or Slave digic 0x101: for Master digic. Only for dual digic camera 0x102: (post?) update script for main or slave digic. ICU_M with the 5Dm3 0x103: (post?) update script for master digic 0x104: for LUGH (WFT adapter). Seen in 5Dm3 updater 0x105: for PTP? Seen in 80D, 750D, 760D updaters 0x106: ??? Seen in 1DXm2, 7D2 updaters 0x108: ??? Seen in 7D2, 750D, 760D updaters 0x10a: bitmap+gui data? Seen in 1DXm2, 5D4 updaters 0x10c: ??? Seen in 1DXm2 updaters 0x10e: ??? Seen in 77D, 200D, 800D updaters 0x200: for MPU (TX19A) 0x201: for AECU (Digic4 in 5Dm3). transfered via IPC like Master firmware of 7D
Update 1.0.6 of 1Dx is the first to use record type 0x104 (WFT adapter) and (0x201) AECU = Digic4
$ python dump_fir.py -v 0269_106_firmware.bin
Dump_fir 0.4 (30apr2012)
fileLen = 0x1cfacc0
0x000: checksum = 0x4034d263
0x004: 0x00000000
0x008: 0x00000002
0x00c: 0x00000000
0x010: nb_record = 0xc
0x014: table_offset = 0x20
0x018: record_size = 0x18
0x01c: size_after = 0x1cfab74
0x020: ---patches table---
+ tag + foffset + size + moffset
---------------------------------------------
0x01: 0x0201 0x00000140 0x0042d6dc 0x00000000 <-- Digic4. AECU. Fix #1 and #5
0x02: 0x0200 0x0042d81c 0x00000813 0x00000000
0x03: 0x0200 0x0042e030 0x0008d816 0x00000000
0x04: 0x0200 0x004bb848 0x0003e184 0x00000000
0x05: 0x0200 0x004f99cc 0x00142aa7 0x00000000
0x06: 0x0101 0x0063c474 0x0005c614 0xf8e00000
0x07: 0x0101 0x00698a88 0x002b2fa8 0xf8080000
0x08: 0x0100 0x0094ba30 0x0005c614 0xf06e0000
0x09: 0x0100 0x009a8044 0x00387038 0xf0020000
0x0a: 0x0100 0x00d2f07c 0x0017ac1c 0xf0800000
0x0b: 0x0100 0x00ea9c98 0x00929190 0xf8080000
0x0c: 0x0104 0x017d2e28 0x00527e8c 0x00000000 <-- WFT adapter. Fix #6
0x140: ---patch#1---
Changes
Firmware Version 1.0.6 incorporates the following fixes.
1. Fixes a phenomenon in which the AF Microadjustment cannot be correctly carried out.
2. Fixes a phenomenon such that when using the camera with combinations of certain lens*1) and extender*2), the images captured become back-focused.
- 1) EF 70-200mm f/2.8L IS II USM or EF200mm f/2L IS USM
When used with
- 2) Extender EF 1.4x III or Extender EF 2x III
3. Fixes a phenomenon in which, when the camera is powered on in very dark environments (including instances when the lens cap or the body cap is attached), Error 80 appears on the camera.
4. Fixes the following phenomenon: if two CF cards are inserted into the camera and the "Standard" or "Auto switch card" setting is selected for the recording method for [Record func+card/folder sel.], and then one of the CF cards is removed and then reinserted into the card slot, the card selected for recording and playing back images may be switched to the other CF Card.
5. Fixes a phenomenon in which the AF microadjustment value is not correctly displayed in the EXIF information of the images captured.
6. Displays a "O" or "X" result to indicate whether images have been successfully transferred through the FTP protocol when using the WFT-E6 Wireless File Transmitter.