Magic Lantern Forum

I spent about 6 hours today mapping these structures in VxWorks from the 5dc v1.1.1 firmware. They should be similar if not identical in DryOS as well. These all have to do with the event system, which is ultimately what I'm trying to understand / hijack. My end goal is the ability to inject whatever event(s) needed to trigger bulb exposures on the 5dc (since it lacks PROP_REMOTE_SW2).

I'm not really too sure how well I did with the data types, but I tried to put as many notes in as I could. I'll work on this more tomorrow and slowly refine what does what. Now I see things like TaskClass and StageClass in the firmware and I'm not so lost/scared looking at it :)

Hijacking a StageClass or TaskClass will be almost identical to how we hijack state objects, so won't be hard to do at all.

[see post below for updated one]

Feel free to contribute / discuss.

good job :)

updated, analyzed some more. Please see latest commit in repository for changes:
https://bitbucket.org/hudson/magic-lantern/changeset/288809380c52

In 5dc v1.1.1:
Manager | ptr

• GenMgr | 0x1B9C
• EventMgr | 0x4EE8
• FileCache | 0x4F1C
• RscMgr | 0x4F28
• DPMGR_T | 0x504C
• DPOFMGR_T | 0x510C
• TOMgr | 0x5910
• FileMgr | 0x592C
• PropMgr | 0xF508
• DbgMgr | 0x101FC

Module | ptr
ShootCapture | 0x4E74
ShootDevelop | 0x4E78
ShootBlack | 0x4EA4
Fcreate | 0x4ED0
Fstorage | 0x4ED8
Rstorage | 0x4EE0
Fread | (seems to be initialized in 2 spots, no solid pointer for it, odd)
Fwrite | (same as above ^)
Factory | 0xD148

Whenever a StageClasss or TaskClass are created, they start a new instance of the StageClassTask or TaskClassTask, which seem to handle events. From the Module or Manager struct, we can call just about any function (like ChangeTaskPriority), or anything that needs any of the pointers / structs contained inside each Module/Manager. One thing I still do not know yet is how state changes happen. I know there is a handler function that looks at off_0x14, off_0x18, and off_0x1c in the StateObject struct, and has some algorithm to calculate what state to change to. I think Alex has this figured out though.

So, from these 2 groups, we can learn the names of every state machine, stage class, or task class in the camera. These 2 are at the top of the two "hierarchies", so this is as far back as we need to reverse-engineer. I think this is very important stuff, as it advances our knowledge of the low level event system that drives everything. I'll correct / update this as I learn more.

As a test, I added the struct definitions to dryos.h and moved the state_object / state_transition definitions from stateobject.h to dryos.h to keep them all together. I printed out the contents of the PropMgr manager struct, and it all looks to be right, cool!

Quote
        #define PropMgr (*(struct Manager **)0xF508)

        bmp_printf(FONT_LARGE, 0, 0, "PropMgr Manager Struct");
        bmp_printf(FONT_LARGE, 0, 40, "name: %s", PropMgr->name);
        bmp_printf(FONT_LARGE, 0, 70, "taskclass_ptr: 0x%x", PropMgr->taskclass_ptr);
        bmp_printf(FONT_LARGE, 0, 100, "stateobj_ptr: 0x%x", PropMgr->stateobj_ptr);
        bmp_printf(FONT_LARGE, 0, 130, "debugmsg_class: 0x%x", PropMgr->debugmsg_class);
        bmp_printf(FONT_LARGE, 0, 160, "unk_struct_ptr: 0x%x", PropMgr->unk_struct_ptr);
        bmp_printf(FONT_LARGE, 0, 190, "stateobj_ptr2: 0x%x", PropMgr->stateobj_ptr2);
        bmp_printf(FONT_LARGE, 0, 220, "mgr_semaphore: 0x%x", PropMgr->mgr_semaphore);
        bmp_printf(FONT_LARGE, 0, 250, "stateobj_ptr3: 0x%x", PropMgr->stateobj_ptr3);
        bmp_printf(FONT_LARGE, 0, 280, "off_0x20: 0x%x", PropMgr->off_0x20);
        bmp_printf(FONT_LARGE, 0, 310, "off_0x24: 0x%x", PropMgr->off_0x24);
        bmp_printf(FONT_LARGE, 0, 340, "off_0x28: 0x%x", PropMgr->off_0x28);
        bmp_printf(FONT_LARGE, 0, 370, "off_0x2c: 0x%x", PropMgr->off_0x2c);

And look, you can even keep going deeper, like the TaskClass struct:

Quote
        #define PropMgr (*(struct Manager **)0xF508)
        bmp_printf(FONT_LARGE, 0, 0, "Manager Test");
        bmp_printf(FONT_MED, 0, 70, "PropMgr->taskclass_ptr->name: %s", PropMgr->taskclass_ptr->name);
        bmp_printf(FONT_MED, 0, 100, "PropMgr->stateobj_ptr->type: %s", PropMgr->stateobj_ptr->type);
        bmp_printf(FONT_MED, 0, 130, "PropMgr->stateobj_ptr->name: %s", PropMgr->stateobj_ptr->name);

So, what now?

Edit:
I have refined and published my findings to the repo, I added the structures to state-object.h as they all belong together. To hijack one of the managers or modules, simply follow how state object hijacking works.

Good news: at first sight looks like this is identical in DryOS so it can be used on newer cameras! In 500d.111 firmware:

Quote
CreateStageClass: 0xFF1A5E80
CreateTaskClass: 0xFF1A6824

More good news: the structures are the same size in both VxWorks and DryOS!

Thumbs Up ;)

Can it help the DryOS cameras as well, in respect of development?