DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)

Started by feedrail, June 12, 2017, 07:05:50 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

tekrevz


a1ex

M50 moved over here, alongside with other DIGIC 8 PowerShots.

Short recap for DIGIC 7:
- source code: digic6-dumper branch ( actually covering DIGIC 6, 7 and 8 )
- bootloader experiments: recovery branch ( portable code, running on DIGIC 2...8 )
- emulation: qemu branch (README.rst, HACKING.rst, no GUI yet, but file I/O is working)
- CPU info (Cortex A9 dual core), MMU configuration (mostly flat mapping), ROM layout (32MB at 0xE0000000, 16MB at 0xF0000000)
- see also Initial firmware analysis in QEMU docs
- 200D: proof of concept code available; I'm ready to enable the boot flag, too. Or, to capture DNGs from LiveView or other simple tasks.
- 800D, 77D, 6D2: find a couple of stubs (tutorial) to run the 200D PoC. Once you do that, I'm ready to enable the boot flag on these models, too.
- image sensor on all these models appears to run at 27 MHz x 12 channels (hypothesis), i.e. fast enough for 4K video.
- I have no plans to get any of these cameras; it's up to the user community to push the development further.

Have fun!

DeafEyeJedi

Sounds fabulous in regards to these updates. Thanks for reporting them @a1ex and definitely feels encouraging!
5D3.113 | 5D3.123 | EOSM.203 | 7D.203 | 70D.112 | 100D.101 | EOSM2.* | 50D.109

turtius

Quote from: a1ex on January 08, 2019, 10:58:30 PM
M50 moved over here, alongside with other DIGIC 8 PowerShots.

Short recap for DIGIC 7:
- source code: digic6-dumper branch ( actually covering DIGIC 6, 7 and 8 )
- bootloader experiments: recovery branch ( portable code, running on DIGIC 2...8 )
- emulation: qemu branch (README.rst, HACKING.rst, no GUI yet, but file I/O is working)
- CPU info (Cortex A9 dual core), MMU configuration (mostly flat mapping), ROM layout (32MB at 0xE0000000, 16MB at 0xF0000000)
- see also Initial firmware analysis in QEMU docs
- 200D: proof of concept code available; I'm ready to enable the boot flag, too. Or, to capture DNGs from LiveView or other simple tasks.
- 800D, 77D, 6D2: find a couple of stubs (tutorial) to run the 200D PoC. Once you do that, I'm ready to enable the boot flag on these models, too.
- image sensor on all these models appears to run at 27 MHz x 12 channels (hypothesis), i.e. fast enough for 4K video.
- I have no plans to get any of these cameras; it's up to the user community to push the development further.

Have fun!
What is the main reason for limited support for the dual core camera's anyways?

Sayfog

Where is the 200D proof of concept code stored? I've got one and want to help develop, I've also got an oscilloscope if stuff needs probing to help out development.

a1ex

Quote from: jack001214 on January 14, 2019, 07:29:58 AM
What is the main reason for limited support for the dual core camera's anyways?

For DIGIC 7/8:
- There's very little reason for ML to run on both cores, on these models. They both can access nearly the entire memory space (except for a small private page).
- This does not apply to earlier dual core models. On 7D, ML running only on a single core means reduced functionality (or much harder to implement certain features).
- Emulation-wise, it's important, but one has to understand the low-level interfaces between the two cores. Likely doable with io_trace (after updating it to run on the newer CPUs).

Quote from: Sayfog on January 15, 2019, 05:38:28 AM
Where is the 200D proof of concept code stored? I've got one and want to help develop, I've also got an oscilloscope if stuff needs probing to help out development.

We've been in touch on IRC. Short summary, for those who didn't follow the conversation:

Where to find stuff: see my recap post above.

Electronics probing: I see very little need for this in order to port ML. I'm pretty sure such low-level investigation is going to reveal very interesting stuff about camera internals, but first we need to get the basics working (i.e. bringing up the ML menu). I won't refuse a few high-res pictures of the circuit boards, though :D

In other words, an important task is figuring out how to print things on the screen (i.e. a software-only task). Then, there comes the easy stuff - identifying button codes, adapting the display routines for the new image format (likely this), figuring out ARM-Thumb calling quirks, enabling and testing ML features...




CPU info from 200D (same as 6D2):


CHDK CPU info for 0x417 200D
------------------------------
ID         0x414FC091
  Revision             0x1 1
  Part                 0xC09 3081
  ARM Arch             0xF 15
  Variant              0x4 4
  Implementor          0x41 65
Cache type 0x83338003
  Icache min words/line 0x3 3 [8]
  (zero)               0x0 0
  L1 Icache policy     0x2 2
  Dcache min words/line 0x3 3 [8]
  Exclusives Reservation Granule 0x3 3 [8]
  Cache Writeback Granule 0x3 3 [8]
  (zero)               0x0 0
  (register format)    0x4 4
TCM type   0x00000000
  (raw value)          0x0 0
MPU type   0x414FC091
  S                    0x1 1
  -                    0x48 72
  Num of MPU regions   0xC0 192
Multiprocessor ID 0x80000000
  (raw value)          0x80000000 -2147483648
Processor feature 0 0x00001231
  ARM inst set         0x1 1
  Thumb inst set       0x3 3
  Jazelle inst set     0x2 2
  ThumbEE inst set     0x1 1
  -                    0x0 0
Processor feature 1 0x00000011
  Programmers' model   0x1 1
  Security extensions  0x1 1
  Microcontr. prog model 0x0 0
  -                    0x0 0
Debug feature 0x00010444
  (raw value)          0x10444 66628
Aux feature 0x00000000
  (raw value)          0x0 0
Mem model feature 0 0x00100103
  VMSA support         0x3 3
  PMSA support         0x0 0
  Cache coherence      0x1 1
  Outer shareable      0x0 0
  TCM support          0x0 0
  Auxiliary registers  0x1 1
  FCSE support         0x0 0
  -                    0x0 0
Mem model feature 1 0x20000000
  L1 Harvard cache VA  0x0 0
  L1 unified cache VA  0x0 0
  L1 Harvard cache s/w 0x0 0
  L1 unified cache s/w 0x0 0
  L1 Harvard cache     0x0 0
  L1 unified cache     0x0 0
  L1 cache test & clean 0x0 0
  Branch predictor     0x2 2
Mem model feature 2 0x01230000
  L1 Harvard fg prefetch 0x0 0
  L1 Harvard bg prefetch 0x0 0
  L1 Harvard range     0x0 0
  Harvard TLB          0x0 0
  Unified TLB          0x3 3
  Mem barrier          0x2 2
  WFI stall            0x1 1
  HW access flag       0x0 0
Mem model feature 3 0x00102111
  Cache maintain MVA   0x1 1
  Cache maintain s/w   0x1 1
  BP maintain          0x1 1
  -                    0x102 258
  Supersection support 0x0 0
ISA feature 0 0x00101111
  Swap instrs          0x1 1
  Bitcount instrs      0x1 1
  Bitfield instrs      0x1 1
  CmpBranch instrs     0x1 1
  Coproc instrs        0x0 0
  Debug instrs         0x1 1
  Divide instrs        0x0 0
  -                    0x0 0
ISA feature 1 0x13112111
  Endian instrs        0x1 1
  Exception instrs     0x1 1
  Exception AR instrs  0x1 1
  Extend instrs        0x2 2
  IfThen instrs        0x1 1
  Immediate instrs     0x1 1
  Interwork instrs     0x3 3
  Jazelle instrs       0x1 1
ISA feature 2 0x21232041
  LoadStore instrs     0x1 1
  Memhint instrs       0x4 4
  MultiAccess Interruptible instructions 0x0 0
  Mult instrs          0x2 2
  MultS instrs         0x3 3
  MultU instrs         0x2 2
  PSR AR instrs        0x1 1
  Reversal instrs      0x2 2
ISA feature 3 0x11112131
  Saturate instrs      0x1 1
  SIMD instrs          0x3 3
  SVC instrs           0x1 1
  SynchPrim instrs     0x2 2
  TabBranch instrs     0x1 1
  ThumbCopy instrs     0x1 1
  TrueNOP instrs       0x1 1
  T2 Exec Env instrs   0x1 1
ISA feature 4 0x00011142
  Unprivileged instrs  0x2 2
  WithShifts instrs    0x4 4
  Writeback instrs     0x1 1
  SMC instrs           0x1 1
  Barrier instrs       0x1 1
  SynchPrim_instrs_frac 0x0 0
  PSR_M instrs         0x0 0
  -                    0x0 0
ISA feature 5 0x00000000
  -                    0x0 0
Cache level ID 0x09200003
  Cache type, level1   0x3 3 [Separate Icache, Dcache]
  Cache type, level2   0x0 0 [no cache]
  Cache type, level3   0x0 0 [no cache]
  Cache type, level4   0x0 0 [no cache]
  Cache type, level5   0x0 0 [no cache]
  Cache type, level6   0x0 0 [no cache]
  Cache type, level7   0x0 0 [no cache]
  Cache type, level8   0x1 1 [Icache only]
  Level of coherency   0x1 1
  Level of unification 0x1 1
  (zero)               0x0 0
Cache size ID reg (data, level0) 0x700FE019
  Line size in words   0x1 1 [8]
  Associativity        0x3 3 [4]
  Number of sets       0x7F 127 [128]
  Write allocation     0x1 1
  Read allocation      0x1 1
  Write back           0x1 1
  Write through        0x0 0
Cache size ID reg (inst, level0) 0x200FE019
  Line size in words   0x1 1 [8]
  Associativity        0x3 3 [4]
  Number of sets       0x7F 127 [128]
  Write allocation     0x0 0
  Read allocation      0x1 1
  Write back           0x0 0
  Write through        0x0 0
SCTLR      0x48C5187D
  MPU Enable           0x1 1
  Strict Align         0x0 0
  L1 DCache Enable     0x1 1
  - (SBO)              0xF 15
  - (SBZ)              0x0 0
  Branch Pred Enable   0x1 1
  L1 ICache Enable     0x1 1
  High Vectors         0x0 0
  Round Robin          0x0 0
  - (SBZ)              0x0 0
  - (SBO)              0x1 1
  MPU background reg   0x0 0
  - (SBO)              0x1 1
  Div0 exception       0x0 0
  - (SBZ)              0x0 0
  FIQ Enable           0x0 0
  - (SBO)              0x3 3
  VIC                  0x0 0
  CPSR E bit           0x0 0
  - (SBZ)              0x0 0
  NMFI                 0x1 1
  TRE                  0x0 0
  AFE                  0x0 0
  Thumb exceptions     0x1 1
  Big endian           0x0 0
ACTLR      0x00000045
  (raw value)          0x45 69
ACTLR2     0x00000201
  (raw value)          0x201 513
CPACR      0xC0000000
  (raw value)          0xC0000000 -1073741824
DBGDIDR    0x35137041
  Revision             0x1 1
  Variant              0x4 4
  - (RAZ)              0x70 112
  Version              0x3 3 [v7 full]
  Context              0x1 1 [2]
  BRP                  0x5 5 [6]
  WRP                  0x3 3 [4]
DBGDRAR    0x00000000
  Valid                0x0 0
  - (UNK)              0x0 0
  Address              0x0 0 [0x00000000]
DBGDSAR    0x00030000
  Valid                0x0 0
  - (UNK)              0x0 0
  Address              0x30 48 [0x00030000]
DBGDSCR    0x03000002
  HALTED               0x0 0
  RESTARTED            0x1 1
  MOE                  0x0 0
  SDABORT_l            0x0 0
  ADABORT_l            0x0 0
  UND_l                0x0 0
  FS                   0x0 0
  DBGack               0x0 0
  INTdis               0x0 0
  UDCCdis              0x0 0
  ITRen                0x0 0
  HDBGen               0x0 0
  MDBGen               0x0 0
  SPIDdis              0x0 0
  SPNIDdis             0x0 0
  NS                   0x0 0
  ADAdiscard           0x0 0
  ExtDCCmode           0x0 0
  - (SBZ)              0x0 0
  InstrCompl_l         0x1 1
  PipeAdv              0x1 1
  TXfull_l             0x0 0
  RXfull_l             0x0 0
  - (SBZ)              0x0 0
  TXfull               0x0 0
  RXfull               0x0 0
  - (SBZ)              0x0 0





Updated ROM dumpers to the latest codebase (no more restrictions on card/filesystem size, it just has to be FAT12/16/32):
Quote from: a1ex on January 16, 2019, 09:06:18 AM
DIGIC 7:  200D  6D2  77D  800D

And CPUINFO with log file support (same output expected on all models, but...):
Quote from: a1ex on January 16, 2019, 09:19:19 AM
DIGIC 7:  200D  6D2  77D  800D

turtius

Quotefiguring out how to print things on the screen (i.e. a software-only task)
How were able to achieve that with the ROM dumpers?


Quote- 200D: proof of concept code available;
Is it from the digic6-dumper branch? The same one which you gave me few months back?

Sayfog

Quote from: jack001214 on January 17, 2019, 06:07:44 AM
How were able to achieve that with the ROM dumpers?

Just going to repeat what A1ex said on IRC the other night, that ROM Dumper screen control is done from the bootloader, not the Canon formware. I've only just got my machine setup with Radare2 and a bunch of other tools but could we trace through the memory locations accessed by the rom dumper for the screen into the Canon FW? Unless its currently hanging on some other check and GUI will just fall out when that's figured out.

Edit: word of warning, WSL works great for the development environment, all the tools - not so much.

turtius

I recompiled the digic6 branch and dumped the autoexec.bin on my 200D.
What exactly is the OSD Vram? (On Screen Display?)


These two instructions are being executed together at every 'update'.
002FD1BA>    CtrlSrv:e04a0783:04:03: DISP_SetUpdateOSDVram(0x4169ea00)(0)
002FD2E2>    CtrlSrv:e04afd6f:04:03: refresh x=728 y=442 w=84 h=60


How can i poke this function? i mean what would be minimalist code required to poke a function

arvakur

Hi there people, hope you all are doing grate, guys I have lots of questions, I have a T7i with firmware 1.0.1 and I tried to installed it and well, had no success but I want to know and learn more and to be instructed please people can you help me? I loved this ML because Im a cinematographer and worked it with a T5i...  and well I would love this ML to work on my T7I, but can you guys explain me what is all of this? what are the ROM DUMPERS? how does this work? what do they do?  have any of you make it work on a T7i? what do I need to do or to make it work on that camera model?

thanks

a1ex

Quote from: jack001214 on January 20, 2019, 11:29:30 AM
What exactly is the OSD Vram? (On Screen Display?)

Found the answer in 80D logs. It's the bitmap overlay (i.e. Canon menus and other info displayed on top of the LiveView or playback image).

Quote
CtrlSrv:e04a0783:04:03: DISP_SetUpdateOSDVram(0x4169ea00)(0)

That address is a BMP buffer descriptor (its structure appears to match the one from 80D). If you can get a RAM dump, I can decode it and identify the image buffers.

Quote
How can i poke this function? i mean what would be minimalist code required to poke a function

These functions are in ROM, so... this minimalist code might require reprogramming of the MMU. I'll take care of this - it's one of these things that's doable, well covered in ARM manuals, but complex enough to make one's head spinning.

However, assuming the display hardware on DIGIC 7 is like 80D, printing things on the screen should be much easier. If lucky, all you need to print Hello World is to modify the contents of that bitmap buffer (which will have to be identified from a RAM dump, starting from the argument of DISP_SetUpdateOSDVram).

turtius

QuoteIf lucky, all you need to print Hello World is to modify the contents of that bitmap buffer (which will have to be identified from a RAM dump, starting from the argument of DISP_SetUpdateOSDVram).
...
How would i get a RAM dump? if i cant invoke many location's then  how would i go about getting a RAM dump then?

a1ex

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 flag

The 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.

Warranty

If it breaks, you get to keep both pieces. Sorry.




800D, 77D, 6D2

TBD 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).

turtius

Awesome analysis and work through. I will try to find some stuff with my novice skills. Though you can always PM me to test some code  for the 200D.

Cheers!

turtius

So I got bored (again).To counteract that I decided to compile the latest branch and run it on actual EOS200D(it works).
The logs that the program created got me to tinker some memory location on the camera.
The first address I tinkered was the supposed 'gain control' which was noted as DispDCtrl:e055f277:42:03: GAIN R:0x0eb G:0x0ec B:0x100
[0] 1.435252
in the log. I went ahead and set the contents of the area to '0x00'(random int) and surprisingly,the camera booted and the display was working perfectly(unexpected). Right after switching the camera to record, there were two separate 'boxes' created which had the live view shifted few places to one another and settled as soon as the camera was still.
I mean this was not useful too anyone but I was inspired. So yeah.


turtius



brollnet

Hello all... I have a 77D and would love to see ML working on it. I'm not code savvy, but I'm willing to help if I can. Tell me what I can do to help...

kev

Walter Schulz

Code savvy is what is needed most now. Among the things you can do without: https://www.magiclantern.fm/forum/index.php?topic=23606 applies to 77D, too. Report back!

a1ex

I've already got a ROM dump from 77D; from the linked thread, I only need a confirmation whether the latest dumper is still working. I don't expect any surprises, as it was confirmed to work on all other D7 models.

For 77D, the next step is to check the stubs from aprofiti and debug them in QEMU. Difficulty: easy. Expected outcome: current codebase (digic6-dumper branch) should save a log file on the virtual card.

brollnet

Thanks... As soon as my 77D returns from the shop (focus calibration) I'll try the ROM.

Thanks for all the work you do!

kev

aprofiti

Tried to compile digic6-dumper for 77D using the partial Stubs.S, but failed when doing "make zip":

.. other failing modules...

Building module edmac...
Updated HGVERSION
[ README   ]   module_strings.h
[ CC       ]   edmac.o
[ CC       ]   edmac_util.o
[ CC       ]   edmac_test.o
[ CC       ]   md5.o
[ HGDIFF   ]   hgdiff.tmp
[ MODULE   ]   edmac.mo
[ STRIP    ]   edmac.mo
[ OBJCOPY  ]   edmac.mo
[ RM       ]   hgdiff.tmp
[ STRIP    ]   edmac.sym
[ STRIP    ]   edmac.sym
[ RM       ]   localsyms
[ EXPORTS  ]   edmac.sym
000018f0 edmac_format_size
[ DEPENDS  ]   edmac.dep
Not checked (compile ML for these cameras first):
    100D, 1100D, 200D, 500D, 50D, 550D, 5D2, 5D3.113, 5D3.123, 5D4, 5DS, 5DSR, 600D, 60D, 650D, 6D, 6D2, 700D, 760D, 77D, 7D, 7D2, 80D, EOSM, M50, R
make[5]: *** [edmac.dep] Error 1

********************************************************
WARNING: module edmac failed to build, deleting
********************************************************

[ RM       ] edmac.o edmac_util.o edmac_test.o md5.o edmac.mo edmac.sym edmac.dep edmac.zip module_strings.h hgdiff.tmp *.o *.d *.dep *.sym hgstamp
[ MKDIR    ]   ML directory structure...
cp ../modules/*/*.mo /Users/alex/Desktop/pullML/official/platform/77D.100/zip/ML/modules/
cp: ../modules/*/*.mo: No such file or directory
make[2]: *** [install] Error 1
make[1]: *** [CONFIG_MODULES_install] Error 2
make: *** [install] Error 2


Should I compile using minimal build or special commands?

Noticed I got the same for 200D... Already tried to reclone repo to get a fresh copy...

a1ex

It's not going to load any modules at this stage. The early code does not use any data files, other than autoexec.bin, so if plain "make" succeeds, that's pretty much it. For testing, I use:

make install_qemu ML_MODULES=


The "make zip" command expects some modules present; you could create an empty .mo file there to please it, or compile ML from a different camera to create some modules.

aprofiti

First try using "make install_qemu ML_MODULES=" didn't work; so copied a compiled version of arkanoid.mo (from another camera compiled in the same branch) after the second pass of module compilation, then run "make zip" and got this error:

/Library/Developer/CommandLineTools/usr/bin/make -C ../../minimal/ MODEL=77D FW_VERSION=100
/Library/Developer/CommandLineTools/usr/bin/make -C hello-world/.
[ CC       ]   reboot-dumper.o
[ CC       ]   footer.o
[ LD       ]   autoexec
[ XOR_CHK  ]   ../../build_tools/xor_chk
../../build_tools/xor_chk.c:48:88: warning: format specifies type
      'unsigned long' but the argument has type 'uint64_t' (aka
      'unsigned long long') [-Wformat]
  ...error (expected 0x%lX, got 0x%lX)\n", 0xCCCCCCCCE12FFF13, footer_magic);
                                  ~~~                          ^~~~~~~~~~~~
                                  %llX
1 warning generated.
[ OBJCOPY  ]   autoexec.bin
[ XOR_CHK  ]   autoexec.bin
[ CPP      ]   magiclantern.lds
[ AS       ]   entry.o
[ CC       ]   minimal.o
In file included from minimal.c:5:0:
../../src/dryos.h:37:17: fatal error: gui.h: No such file or directory
compilation terminated.
make[2]: *** [minimal.o] Error 1
make[1]: *** [hello-world/.] Error 2
make: *** [minimal_check] Error 2

retried with "make install_qemu ML_MODULES=" and got no errors.

Unfortunately I still have a problem with qemu I can't solve:

./run_canon_fw.sh 77D, firmware=boot=0

DebugMsg=0xDF006E6C (from GDB script)
qemu-system-arm: -M 77D,: drive with bus=0, unit=0 (index=0) exists

I get that on each try, whether camera model is specified...
I don't know if it screwed after installing/updating packages with brew some days ago, got some errors and had to reinstall some of them.