RscMgr memory (60D, todo:7D, maybe also 50D and 700D)

#731 Open

Bitbucket cannot automatically merge this request.

The commits that make up this pull request have been removed.

Bitbucket cannot automatically merge this request due to conflicts.

Review the conflicts on the Overview tab. You can then either decline the request or merge it manually on your local system using the following commands:

hg update 7a3b5fa3f4c6
# Note: This will create a new head!
hg merge a2001c9d8eca
hg commit -m 'Merged in RscMgr_memory (pull request #731)'
  1. Alex

60D and 7D have about 7-8 MB that appears to be unused by RscMgr (source). Currently, autoexec.bin is loaded there, but this doesn't fully use this memory.

With this PR, I've changed the 60D boot method to the one used on 550D/1100D (autoexec in AllocateMemory, with init_task patched on the fly), and I've used Canon's low-level allocation functions from AllocateMemory to manage the new 7MB buffer. Now, even under heavy load, ML will not have to allocate general-purpose memory from shoot_malloc (which can't be kept allocated forever) or from Canon's memory pools (which, on 60D, are nearly full).

Example: loaded Lua with a bunch of scripts, without umm_malloc, and a few other modules: RscMgr_mem_60D.png

Some extra advantages of this change:

  • QEMU loads the vanilla 60D autoexec.bin (without compiling it with CONFIG_QEMU). Not much works this way though, but Canon GUI boots, alongside with flexinfo over it, and Lua startup scripts, if you have any.
  • dm-spy-experiments can now be used on 60D without having to disable 90% of the features so it can fit in RAM.


Comments (10)

        1. Alex author


          Commenting out CONFIG_RSCMGR_UNUSED_SPACE helps; maybe some parts of this buffer are actually used in LiveView?

          edit: yes, 5FE00000 is used...

          However, even after excluding the used areas, it still crashes. Commented out hiprio/loprio tasks (the overlays) and still crashes. This is probably going to be hard to track down...

          Interesting that it didn't crash after all those reallocs from Lua...

          edit: I think it's reloc_liveviewapp_install (another out-of-range jump); will try tomorrow.

  1. Walter Schulz

    Compiled for 7D and running. Did some selftests without problems so far. Benchmark seems to perform about 2 percent better. About 92 MByte/s with Komputerbay 128 GB 1066x.

    Anything in particular to test?

  2. Daniel Fort

    This worked wonders for getting the 7D working with 10/12-bit raw video when merged into the raw_video_10bit_12bit_LVState. However, it looks like pretty much every other platform won’t compile:

    [ CC       ]   lv-img-engio.o
    ../../src/lv-img-engio.c: In function 'digic_iso_step':
    ../../src/lv-img-engio.c:899:33: error: implicit declaration of function '_raw_lv_get_iso_post_gain' [-Werror=implicit-function-declaration]
                 total_movie_gain *= _raw_lv_get_iso_post_gain();
    ../../src/lv-img-engio.c: At top level:
    ../../src/lv-img-engio.c:1012:30: error: 'EM_SHOW_LIVEVIEW' undeclared here (not in a function)
                     .edit_mode = EM_SHOW_LIVEVIEW,
    cc1: some warnings being treated as errors
    make: *** [lv-img-engio.o] Error 1
    make: *** Waiting for unfinished jobs....

    BTW – Could this possibly work on the 500D/550D like it did with the 7D? I took a closer look at what was done on the 7D and 60D and see that there are several stubs that need to be found and a few other changes to get it working properly.

    1. Alex author

      The 550D and 500D are already using the classic boot method, so… no, it won’t help at all with 10/12-bit recording.

      On 550D, this might help a tiny bit under heavy Lua workloads (if at all), but that’s pretty much the only benefit there. IIRC this camera doesn’t have much trouble with general-purpose memory. 500D is even better in this regard.