Preventing Canon settings (properties) from being saved into ROM

[a1ex]

Some early notes (5D3 1.2.3).

PROP_REBOOT (software reboot):

Code: [Select]

    int reboot = 0;
    prop_request_change(PROP_REBOOT, &reboot, 4);

0x80010001 PROP_TERMINATE_SHUT_REQ (0=request, 3=execute, 4=cancel)

Code: [Select]

08F1E>    PropMgr:000aecf0:00:00: *** mpu_send(06 04 04 07 00), from ff12298c
09101> **INT-36h*:000aed58:00:00: *** mpu_recv(06 05 02 0b 00 00), from ff2e87f8
09388>    PropMgr:ff0cdc60:8c:03: terminateChangeCBR : SHUTDOWN (0)
093AA>    PropMgr:ff0cde2c:8c:16: SHUTDOWN_REQUEST

Opening battery door:
0x80010002 PROP_ABORT

Code: [Select]

786D6> **INT-36h*:000aed88:00:00: *** mpu_recv(06 05 06 26 01 00), from ff2e87f8
78821> **INT-36h*:000aed88:00:00: *** mpu_recv(06 05 06 13 01 00), from ff2e87f8
7915B> **INT-36h*:000aed88:00:00: *** mpu_recv(06 05 04 0d 00 00), from ff2e87f8
86E81> **INT-36h*:000aed88:00:00: *** mpu_recv(06 04 02 0c 01), from ff2e87f8
8A249>    PropMgr:ff0f8f74:00:03: [SEQ] CreateSequencer (Terminate, Num = 2)
8A2CB>    PropMgr:000aeb2c:00:00: *** task_create("Terminate", 0x11, 0x1000, 0xff0f8e40, &"Sequencer"), from ff0f8ffc
...
8A1F8>  Terminate:000aeb0c:00:00: *** terminateAbort(0x200000, 0x0, 0x0, 0x200000), from ff0f8edc
8A5D7>  Terminate:000aeb0c:00:00: *** terminateAbort(0x10, 0x0, 0x0, 0x10), from ff0f8edc

Saving settings to ROM at shutdown:

Code: [Select]

8A16A>    PropMgr:ff1282a4:02:03: Compare FROMAddress (0) 0x40710e00 0xff060000 Size 2424


Code: [Select]

      RAM_DebugMsg(140, 22, "Write to FROM");
      prop_erase(0x5000000);
      prop_write(0x5000000);
      ...

When opening the battery door, I've identified prop_erase/prop_write calls to 0x3000000 (0xff21c8bc, triggered from PROP_ABORT), 0x5000000 and 0x2000000 (0xff0ce424, Terminate task).

On normal shutdown (power button or card door), terminateShutdown is used instead of terminateAbort.

Canon settings are organized like this (see PROPAD_CreateFROMPropertyHandle):

Code: [Select]

name   ROM addr   N * sector_size?  block_size?   prop_class
TUNE   0xF8B20000   23 * 0x20000      0x2E0000    0x1000000
TUNE2  0xF0020000   42 * 0x10000      0x2A0000    0x1000000
FIX    0xF8E60000    4 * 0x20000       0x80000    0
RING   0xF8F40000    2 * 0x20000        0x1000    0x2000000
RASEN  0xF8EE0000    3 * 0x20000       0x20000    0x4000000, 0x5000000, 0xE000000
LENS   0xF8E00000    3 * 0x20000       0x20000    0xB000000
CUSTOM 0xF8060000    2 * 0x20000        0x1000    0x3000000

The prop_class fields is the "category" of properties stored in each block. Examples:
- RING: 0x02040002 PROP_LANGUAGE, 0x02040003 PROP_VIDEO_SYSTEM, 0x02040005 PROP_DATE_FORMAT
- FIX: 0x2 PROP_CAM_MODEL, 0x5 PROP_DCIM_DIR_SUFFIX
- LENS: 0x0B000000 PROP_OPTICAL_CORRECT_PARAM
- TUNE: 0x1010022/25...37 vertical stripe correction parameters
- TUNE2: 0x10500d1...d4 (see above)
- RASEN: unknown (0x5010002 contains '192.168.1.20', 0x5010003 contains 'Wft-canon')
- CUSTOM: some of them look like picture style parameters (probably settings for C modes)

See also http://www.magiclantern.fm/forum/index.php?topic=4729.0

[a1ex]

I'm trying to find a way to prevent Canon code from saving their settings at shutdown.

Some settings are saved on the MPU's EEPROM, when opening the card or battery door; also triggered by timeout (about 2 seconds after settings settle).

How I've reached this conclusion?
- M mode, changed shutter speed, opened battery cover and took battery out => change saved
- used a pin to hold the battery cover switch; changed shutter speed, took battery out => change not saved
- used a pin to hold the battery cover switch; changed shutter speed, waited a few seconds, took battery out => change saved
- used a pin to hold the battery cover switch; changed shutter speed a few times every 1 second, took battery out => change not saved (initial shutter speed restored)
- used a pin to hold the battery cover switch; changed shutter speed a few times every 2 second, took battery out => change saved (some intermediate shutter speed restored)
- reinstalled battery door, changed shutter speed, locked up the main CPU (cli(); while(1) without delay, took battery out =>
change saved
- reinstalled battery door, locked up the main CPU (cli(); while(1), changed shutter speed (change visible on top screen), took battery out => change saved

So, we cannot prevent these settings from being saved into persistent. To my understanding, the MPU settings are all those properties starting with 0x8 (e.g. 0x80000005 PROP_SHUTTER, 0x80000039 PROP_VIDEO_MODE, 0x8000002f PROP_PIC_QUALITY). Some of these caused soft-bricking issues previously.

[hjfilmspeed]

Hmmm So is there a timer? Like if we open batt door and immediately pull batt it won't save? Or is there still a chance there is saving happening with a lightning fast pull?
Or is canon saving setting to ROM ever 2 seconds regardless of a batt pull.

[a1ex]

The MPU (a CPU we don't control) is saving the settings it manages - this happens at about 2 seconds after last change.

The settings managed by the main CPU are saved at shutdown (RING, CUSTOM, RASEN 0x5) or under other conditions not yet understood.

Opening the battery door is an event (detected from a micro-switch) that triggers setting saving on both processors.

[hjfilmspeed]

Ohhhhhhhhhhhh very interesting! So ML doesn't use the MPU (always saving settings)
Hmmm so then the issue is the little switch on the door. Does that have a timer? Or does it save as soon as it is activated?

[a1ex]

Hmmm so then the issue is the little switch on the door.

No, see test #3.

[hjfilmspeed]

Ohhhhhhhhhh! I think I get it now. Sorry I had to read through it again. Hmmmm.
So there is not much that can be done about certain properties being saved unless you can mod the timer in which the MPU/CPU saves those properties after a change and mod the switch? ... Right?
If I still don't understand I am sorry for wasting forum space. This is why I am a user not a programmer.

Would it be safer if ML never touched those properties (e.g. 0x80000005 PROP_SHUTTER, 0x80000039 PROP_VIDEO_MODE, 0x8000002f PROP_PIC_QUALITY)?
Or is that not possible with some features?

Also I can confirm:
- used a pin to hold the battery cover switch; changed shutter speed, took battery out (quickly) => change not saved
- used a pin to hold the battery cover switch; changed shutter speed, waited a few seconds, took battery out => change saved

Just tried this just now. So the save timer and switch are working against you.

[DeafEyeJedi]

lso I can confirm:
- used a pin to hold the battery cover switch; changed shutter speed, took battery out (quickly) => change not saved
- used a pin to hold the battery cover switch; changed shutter speed, waited a few seconds, took battery out => change saved

Same here I can confirm those as well. Enthralling finds @a1ex!

[a1ex]

Would it be safer if ML never touched those properties (e.g. 0x80000005 PROP_SHUTTER, 0x80000039 PROP_VIDEO_MODE, 0x8000002f PROP_PIC_QUALITY)?

Some of the cases I've unbricked, with bad PROP_PIC_QUALITY values, were cameras that did not have ML before the crash. One of those cases was linked in the FAQ (but looks like the original discussion is no longer available...)

What I'm trying is to prevent accidental bricks. With the current CPU and OS design (without MMU, just with a statically configured MPU), any task is allowed to write to any memory location. A programming mistake that results in overwriting Canon's code or data structures can be unlucky enough to cause persistent changes (worst case, completely bricking the device). It's not very hard to imagine a jump (by mistake) to EraseSectorOfRom...

(BTW, this weakness also allows us to patch Canon code and data structures easily - with proper memory protection in place, it would have probably been a lot harder to interact with the firmware)

(todo: take a closer look at the mem_prot module, which can reconfigure the unused part of the ARM MPU - not to be confused with the TX19A MPU)

[hjfilmspeed]

Some of the cases I've unbricked, with bad PROP_PIC_QUALITY values, were cameras that did not have ML before the crash. One of those cases was linked in the FAQ (but looks like the original discussion is no longer available...)

"were cameras that did not have ML before the crash" Does this mean the ML card wasn't in the camera at the time of the crash?

[a1ex]

Nope, it was never installed (or maybe it was installed after unbricking - didn't ask).

The PROP_PIC_QUALITY error can be fixed with gphoto2 in some cases (without having to install ML).

[a1ex]

PR posted:

https://bitbucket.org/hudson/magic-lantern/pull-requests/825/prevent-canon-settings-from-being-saved/diff