It's commented out in the source.
Memory map is the same as on M5; here's a slightly revised version, annotated like
the one for EOS R:
00001000-00001FFF -> 00000000-00000FFF (-1000) O:NCACH I:WB,WA P:RW [ CPU0 only ]
00001000-00001FFF -> 00001000-00001FFF ( +0) O:NCACH I:WB,WA P:RW [ CPU1 only ]
00002000-3FFFFFFF -> 00002000-3FFFFFFF ( +0) O:NCACH I:WB,WA P:RW [ cacheable RAM - without private areas ]
40000000-BFFFFFFF -> 40000000-BFFFFFFF ( +0) O:NCACH I:NCACH P:RW [ uncacheable RAM; todo - what's above 80000000? ]
C0000000-C1FFFFFF -> C0000000-C1FFFFFF ( +0) Device P:RW XN
C4000000-C4FFFFFF -> C4000000-C4FFFFFF ( +0) Device P:RW XN
C8000000-CAFFFFFF -> C8000000-CAFFFFFF ( +0) Device P:RW XN
D0000000-D0FFFFFF -> D0000000-D0FFFFFF ( +0) Device P:RW XN
D2000000-D2FFFFFF -> D2000000-D2FFFFFF ( +0) Device P:RW XN
D4000000-D5FFFFFF -> D4000000-D5FFFFFF ( +0) Device P:RW XN
D8000000-D9FFFFFF -> D8000000-D9FFFFFF ( +0) Device P:RW XN
DE000000-DEFFFFFF -> DE000000-DEFFFFFF ( +0) Device P:RW XN
DF000000-DFFFFFFF -> DF000000-DFFFFFFF ( +0) O:NCACH I:WB,WA P:RW [ TCM? ]
E0000000-E7FFFFFF -> E0000000-E7FFFFFF ( +0) O:WB,WA I:WB,WA P:R [ main ROM ]
E8000000-EFFFFFFF -> E8000000-EFFFFFFF ( +0) Strongly-ordered P:R XN [ ? ]
F0000000-F7FFFFFF -> F0000000-F7FFFFFF ( +0) O:WB,WA I:WB,WA P:R [ serial flash? much slower than main ROM ]
F8000000-FFFFFFFF -> F8000000-FFFFFFFF ( +0) Strongly-ordered P:R XN [ ? ]
The entire RAM is visible as "uncacheable", i.e. from 0x40000000 to 0x7FFFFFFF. Most of that RAM (except for the two 4K pages private for each core) is visible as "cacheable" as well (i.e. after clearing 0x40000000).
There seems to be something above 0x80000000 as well (we've got some trouble on the EOS R while overwriting it by mistake, and found out the 200D is also using that area - it's shared memory for yet another secondary processor), so... let's also dump from 0x40000000 to 0xBFDFFFFF (or even until 0xBFEFFFFF / 0xBFFFFFFF if the hardware doesn't lock up).
RscMgr memory maps
here. Surprise - the 800D has no less than 1 GiB of RAM! Compare to 256 MiB on the 700D
Yesterday, we made significant progress on IRC, with the help of @names_are_hard. Noticed the digic6-dumper codebase was no longer working on 200D; last time it was confirmed to work was in August 22, 2018 (changeset e21eec1/b2e0efa), so at least we had some reference "last known good" code.
Although @names_are_hard was not familiar with the ARM architecture, we managed to narrow down the issue after "only" 3 hours of pair debugging (as in "pair programming"): him on real hardware and me in QEMU. After all of that, we came up with two tiny changesets (who said the number of lines of code is a good metric?!):
2cd1b5f and
bcfa76b: our DebugMsg, which was overwriting Canon's, and maybe also the interrupt hooks, were running on both CPU cores!
Even though we are running ML on the first core only, to avoid multitasking issues, we've got a problem: since both CPU cores on DIGIC 7/8 are sharing the entire memory (with very few exceptions), when overriding DebugMsg & co. by writing into (shared) RAM, our change took effect on both cores.
This kind of debugging would have been very hard to do with me sending precompiled binaries to a tester (he would have had to report back "it doesn't boot" a few dozen times). Did that on M50 - it took me (together with a tester who couldn't program, but otherwise tested my binaries really quickly)
an entire week for a similar issue.
Enabling the boot flagThe above means I'm now confident the current proof of concept code from the digic6-dumper branch is relatively safe to use on 200D (and other DIGIC 7 models after finding some stubs). That means, if you want to help and you are not afraid of the source code, you may now enable the boot flag on your 200D with:
BOOT200D.FIR (confirmed by both @jack001214 and @names_are_hard).
This will modify your camera.In theory, the FIR for enabling the boot flag should work on any firmware version. In practice, some cameras may refuse to downgrade (cough 5D3/5D4); should this happen, it's easy to fix.
However, the code from the digic6-dumper branch expects firmware 1.0.1, specifically 1.0.1 / 5.0.2 62(31) as printed by the
Portable ROM dumper; otherwise, it simply won't boot. IIRC this is the latest firmware available from Canon at the time of writing, but we did not double-check this yet.
To disable the boot flag:
see these notes.
WarrantyIf it breaks, you get to keep both pieces. Sorry.
800D, 77D, 6D2TBD after
you, camera owners, will:
- find the missing stubs
(tutorial)- verify them in QEMU (you *will* need it for debugging)
- are ready to run and debug the code on real hardware.
Next steps (200D)- compile the digic6-dumper branch, changeset bcfa76b (confirmed to work on 200D)
- just committed some code attempting to log debug messages and interrupts from both cores (will it work? I have no idea)
- figure out how to print things on the screen (follow my earlier notes)
- find large chunks of memory that might be unused during boot, i.e. available for logging (
CONFIG_MARK_UNUSED_MEMORY_AT_STARTUP)
- get some huge logs with all Canon's debug messages, interrupts etc, fully covering the startup process
- port io_trace on DIGIC 7/8 and log all MMIO activity (doable, but not trivial)
- fix emulation, using the info from the above huge logs
- start porting ML (once you know how to print things on the screen, there's nothing else stopping you to do so).
