Fandom

Magic Lantern Firmware Wiki

Update records

328pages on
this wiki
Add New Page
Talk0 Share

Ad blocker interference detected!


Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.

See Fir fileformat first

Update payload formatEdit

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 formatEdit

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)

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 filesEdit

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 scriptsEdit

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‚̍ēǂݍž‚ݏˆ—II ƒRƒƒ“ƒgƒAƒEƒgŽž‚Í—vŠm”FII
UPD_AdjustWB

;‚±‚êˆÈ~‚É‹Lq‹ÖŽ~Biƒ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‚̍ēǂݍž‚ݏˆ—II ƒRƒƒ“ƒgƒAƒEƒgŽž‚Í—vŠm”FII
UPD_AdjustWB
; ¡“ú‚̃ŠƒŠ[ƒX‚Å‚Í–³Œø‚É‚·‚遫
; ResetCalendar
;‚±‚êˆÈ~‚É‹Lq‹ÖŽ~Biƒ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 typesEdit

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
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.

See alsoEdit

Also on Fandom

Random Wiki