DryOS task hooks for newer cameras (6D, 70D, 100D)

#672 Open
Repository
Branch
new-dryos-task-hooks
Repository
Branch
unified

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 94a19d94813f
hg commit -m 'Merged in new-dryos-task-hooks (pull request #672)'
Author
  1. Alex
Reviewers
Description

Some DryOS internals changed since 6D - in particular, the task hooks. I took a closer look at 6D, and it turns out, the change was not that big, but it wasn't obvious where to look for.

With this change, we no longer have two pieces of code for old and new cameras, so the code becomes more portable (and with fewer camera-specific exceptions).

For the 6D, I've also changed the memory allocation method to classic AllocateMemory (similar to 550D and 1100D). I've re-checked the old boot constants, and noticed we were taking away from Canon memory heap 0xD3C000 - 0xC1C100 = 1151.75K of RAM, even if, for ML, we reserved 640K. With the new method, we took 640K away from Canon memory, from which 624K are available for autoexec.bin, and there should be an extra 512K for regular use.

For 6D, I would like to see a screenshot of the Free Memory dialog, before and after this change, to make sure the memory was reserved properly for ML.

The CPU usage feature should also be working. I'm not sure what was its status - I guess it was in the menu, but not working, correct?

@nikfreak: can you try this method on 70D and 100D?


update: confirmed on 6D, 100D, 70D, 1300D, EOSM2, 80D (likely all DIGIC 6), possibly also on DIGIC 7 (untested, but the task hooks are called in the same way).

Ready to merge after QEMU.

  • Issues #16: Unchipped battery support on hold

Comments (28)

    1. nikfreak

      at least cam boots up now and overlays are visible but ran into small problem: can't open ML menu with trash button. I guess i replicated it w/o errors but only had the 6D.113 dump at hand. Can someone send me a PM on forums with a private link to it plz so I can be rest assured I got it right by comparing.

        1. nikfreak

          Ok I will check the stub. It already mismatched when comparing to 6d.113 but i was unsure and wanted to get my hands onto 6d.116 to check it the right way. Assuming it didn't change from 113 to 116 I will try now anyways again

          1. Alex author

            On 70D 111A, task_dispatch_hook is 0x7AAD4, and you also need to undefine HIJACK_TASK_ADDR from consts.h (since it's only needed for old DryOS). With these two, it appears to work fine in QEMU.

      1. Alex author

        1.2MB sounds too much, checking the math.

        Before: we changed 0xD3C000 to 0xC1C000 (the end address of Canon's memory pool), so we took 1152K from Canon firmware. After: we changed start address from 0x44C000 to 0x450000, losing 16K, and end address from 0xD3C000 to 0xCA0000, reserving 624K for ML. In this process, we took 624+16 = 640K from Canon firmware. Difference: 512K should be available with the new method.

        Were the two screenshots taken under the same load? (same modules loaded, same camera mode, etc)

        1. nikfreak

          last commits cause some issues on 70D. AllocateMemory is now 2.8MB and in addition to that I also get continuous led light while turning off / on cam.need to take out battery to get it on again. Using ofc the correct addresses in consts.h so i assume it's caused by the self-checks?

          VRAM35.jpg

          1. Alex author

            My tests in qemu:

            0a981f3d2abf: Free Memory  : 393K + 6126K
            b15cdfe8aa52: Free Memory  : 393K + 6110K
            a28ee8bebd82: Free Memory  : 393K + 6750K
            

            I couldn't emulate the old boot method, but the theory says it should be 5598K. I've got larger numbers because not all Canon tasks could complete their initialization in qemu (not relevant, I'm only looking at the differences).

            So, the latest change appears to work fine in QEMU, and the patched ASM code also looks OK.

            I've added a possible fix, does it help?

  1. nikfreak

    Unfortunately toggling AF settings to AI Focus / AI Servo crashes the cam:

    ASSERT: 0
    at ./Memory/Memory.c:575, AeWb:3db28
    lv:1 mode:0
    

    No idea why this happens with the new boot method:

    http://www.magiclantern.fm/forum/index.php?topic=14309.msg158116#msg158116

    The only things I've added to this have been the raw histogram tweaks and enabling dual iso for movie mode and I don't think both could have an impact:

    https://bitbucket.org/nikfreak/magic-lantern/commits/branch/70D-merge-dryos-hooks

  2. nikfreak

    @Alex can you take a quick look at this pic plz:

    sl1_addr.jpg

    As stated earlier I am able to boot SL1 atm w/o the hijack_cache stuff exactly like EOSM/650D/700D does but only with the boot-hack.c from this PR. Otherwise it won't boot. I also don't define CONFIG_ALLOCATE_MEMORY in my internals.h.

    Reason I bring this up is. when using hijack_cache_hack boot SL1 til now had 1.9Mb AllocateMemory Using it w/o hijack_cache_hack and the boot-hack.c from this PR I get 2.8MB AllocateMemory.

    Can't judge atm if I should make a public release like that.

    1. Alex author

      If you don't define CONFIG_ALLOCATE_MEMORY, ML will be loaded in the "malloc" pool, so you should see that one shrinking instead (but you will have to adjust RESTARTSTART with a value slightly above the BSS, found in cstart).

      How much RAM do you have for malloc? If you have enough, you can just load ML there (it's easiest).

    1. Alex author

      It causes major trouble on 70D/100D, and zero feedback on 6D (but likely to work just as "well")...

      (I need to check it with nikfreak in detail)

      1. nikfreak

        70D has problems with this PR as several people got crashes after using ML test builds. Myself was able to reproduce those and reverted back the public builds. What I can confirm is that parts of this PR are still useful, e.g. task related parts. They will enable 70D / 100D to view tasks and their real usage (before always 0.0 % and now the percentage is shown and taks list is also red / blue / yellow colored).

        In addition I don't think that 100D will need to load ML into AllocateMemory pool. I tried and couldn't boot but I am able to load 100d into malloc but the interesting part I can only bring up ML menu with the task related changes from this PR in addition with a fixed task_dispatch_hook and undefining hijack_task_addr as instructed earlier. Otherwise ML menu wouldn't come up. Still the 100D behaves a little weird (see attached image.) as malloc shows 126/127KB but 0 used. Additionally there's some issue with BMP vram allocation in LV/MV which I am not able to trace. Screenshots only work in photo mode and not LV/MV (blank/black) screen and kind of "artefacts" when Ml mneu is open. Dozens of edmac channles are red colored and show 514x514 whichever boot-method I try.

        VRAM1_100D100B.jpg

        1. nikfreak

          As stated above when applying the "task_dispatch_hook" related parts of this PR I am able to boot 100D into malloc and only then! Meanwhile also ML menu comes up and the CPU usage feature works, too. You may take a look yourself:

          https://bitbucket.org/nikfreak/magic-lantern/branch/100D-revB-single

          So at least let's merge the task related changes into unified. They are indeed useful and also 70D has broken CPU usage feature (always 0.0%) without it. I assume same counts for 6D.

  3. nikfreak

    Compiled from 67684106 and your latest changes for 100D look good to me:

    • raw slurp is ok as expected. mlv_rec records fine and playback of the recorded files is ok
    • task monitor finally shows some values
    • AllocateMemory increased from 1.8MB to 2.3MB (check screenshot)

    VRAM4.jpg

    VRAM5.jpg

    VRAM6.jpg

  4. Audionut

    6D A build from July 2016.

    07-2016.jpg

    One from this branch compiled from 67684106.

    07-2017.jpg

    The CPU usage (percentage) used to flicker on screen with value always 0. The other two CPU usage info options would display the same info as percentage.
    With this build, the display still flickers, but it shows more numbers and looks like it's working as expected.

  5. Alex author

    Confirmed the new DryOS task hooks are compatible with DIGIC 6 (without any further tweaking!) and possibly also with DIGIC 7 (not tested, but the function arguments appear to be the same).