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).
sounds good: i'll replicate it for 70D and report back
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.
Probably GuiMainTask is not overriden; I would double-check task_dispatch_hook. I'll take a look.
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
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.
btw you were right with the CPU usage feature not working (was fixed at 0.0%) before this PR
Replicated on 70D and everything works fine after a quick test:
AllocateMemory increased by ~1.2MB after merging this PR
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)
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?
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?
Yes, looks good now and it helped. AllocateMemory is back to 2.2MB with some of the modules loaded.
Unfortunately toggling AF settings to AI Focus / AI Servo crashes the cam:
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.
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).
what is missing to accept this merge req?
there is a conflict, can you solve it?
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)
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.
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:
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.