ML on EOS-M2

[critix]

I got prop_diag working as a stand alone app and was able to parse ROM1.BIN but am stuck trying to figure out how to parse the RAM4.BIN, especially, "...around the known address..." As Sergeant Schultz would say, "I know nothing!"

Starting from https://www.magiclantern.fm/forum/index.php?topic=12177.msg117735#msg117735 I tried to unblock RAM4.BIN. The problem is I do not know what offset to use.
I tried with 0xF0000000 and with 0xE0000000. The RAM4.BIN.strings file resulted. No matter what offset I've tried, the files are the same. Still running disassemble.pl, so I still do not have a result. I will return with a result when it is ready.

[Edit]
Maybe I got the offset wrong. Looking in the source, I found that RAM4 is saved with offset 0x10000000. So I run the script with offset 0x10000000. Let's see what's coming out.

[dfort]

@critix - Are you using prop_diag from the recovery branch? It is quite easy to build. The documentation explains how to enter the offsets but I'm not sure what offset to use.

src/prop_diag.c

Code: [Select]

/**
 * Property parsing code inspired from g3gg0's Property Editor and Indy's parse_prop.py,
 * but rewritten from scratch :)
 *
 * This tool can also be built as a standalone program, from the "src" directory:
 *    gcc prop_diag.c -o prop_diag
 * or:
 *    make prop_diag
 *
 * Python version available on request.
 *
 * Data structure: in ROM, properties are organized in blocks, sub-blocks and sub-sub-blocks.
 *
 * Each nesting level uses the same structure:
 * [status_1 size_1 data_1    status_2 size_2 data_2    ...    status_n size_n data_n    terminator]
 *
 * - "size" covers the size of "status", "size" and "data" fields, so "data" has size-8 bytes
 * - "data" is either an array of sub-blocks [subblock_1 subblock_2 ... subblock_n terminator]
 *    or the property data itself.
 * - "status", "size" and "terminator" are 32-bit integers each.
 *
 * Consistency check: sum of size_i == buffer_len - 4.
 * There are 4 nesting levels: let's call them "class", "group", "subgroup" and "property".
 *
 * There are multiple copies of various setting blocks, and only one of them is marked
 * as "active" (status = 0xFFFF); this is probably (just a guess) used for wear leveling
 * and maybe also to save a "last known good" configuration (or that's just a side effect).
 *
 * New models may have different header structure for the main blocks;
 * in particular, status and size are no longer the first items.
 */


[critix]

No, I use:

Code: [Select]

/disassemble.pl 0x1000000 RAM4.BIN [Edit]
If you use prop_diag with the camera, then in prop_diag you have to put the offset. If you use offline, then you do not need offset.
That's why I'm trying with that script.

[dfort]

Found something interesting. Going back to something Danne commented on in Reply #426 - the LiveView freezing in Photo mode doesn't happen when FPS override is set like this:



There are probably other settings that work but this is something that users can experiment with using a test build from my downloads page.

Ok--so why would you use FPS override while in Photo mode?

Tip: this feature also works in photo mode, making LiveView usable in dark environments. Combine it with display gain.

So is there anything here we can use to resolve the raw LiveView freezing issue?