Messages

There is lots of information. Start here https://mobile.twitter.com/autoexec_bin
and here https://www.magiclantern.fm/forum/index.php?topic=11108.0
and here https://www.magiclantern.fm/forum/index.php?topic=991.0

IANAP? "I Am Not A Programmer"? 

Is this a chance to learn more about stubs that can be used with low risk since it is official API? I would expect the http communication is handled by the main processor, not by the MPU.

So far it seems ony the RP supports it amongst the DSLR/DSLMs.

Screenshot of the "broken line". Already visible with a break-point at 0x00800000, so after AUTOEXEC.BIN is loaded but before it is relocated.

I'm pretty sure now this is the AUTOEXEC.BIN which is loaded by the boot loader. After the function at 0x00104DA4, which I believe does the loading, the line appears.

Since Canon boot loader code is doing this it should be fine. I guess Qemu just happens to pick this RAM area as a screen buffer because it is not adapted to the 77D yet?

It's updated in commit 0264f84. I hadn't time to replicate any of these tests yet that Alex did with File I/O.

Screenshot of the "broken line". Already visible with a break-point at 0x00800000, so after AUTOEXEC.BIN is loaded but before it is relocated.

I'm experimenting with minimal-d78.c.

dump_task is started, I can blink the LED in different ways, qprint messages are printed.

But I can't get anything saved to the SD image. Neither dumpf, nor backup_region or dump_file is doing anything.

Also when I start the firmware with boot=0 and type dumpf in the event shell nothing is written to the SD card.

I couldn't find uart_printf stub so far, only many low-level UART related functions to write a byte or a string. Nothing that takes a format.

Many thanks, aprofiti. I double checked the stubs and found two that I had to change:

Code Select Expand

NSTUB(0xe04d7317, _FIO_WriteFile) //!
NSTUB(0xe04d8895,  FIO_SeekSkipFile) //!


Your FIO_SeekSkipFile stub I think referred to _FIO_WriteFile.
_FIO_WriteFile was the same as _FIO_CloseFile. (copy&paste error?)

All the stubs you posted have a difference of 0x1AF60 to the 200D. So I did the same for _FIO_SeekSkipFile. I could match it with some error messages, but it looks very different from all the other FIO functions. Especially I couldn't find it calling the function at 0xe04d70e8, which seems to be a kind of debug function for the FIO functions.

Also I'm not so sure about these three:

Code Select Expand

NSTUB(0xe04d80db, _FIO_FindFirstEx) /* 0xe04d7fc1 is FIO_FindFirst */
NSTUB(0xe04d8173,  FIO_FindNextEx) /* 0xe04d804f is FIO_FindNext */
NSTUB(0xe04d80bb,  FIO_FindClose) /* 0xe04d81de is FIO_FincCloseEx(!) */


FindFirst/FindNext/FindClose seem to come in two flavors: With or without "Ex".
The difference seems to be that FindFirstEx does a FIO_Flush before it does whatever it does.
I think FindNext/FindNextEx and FindClose/FindCloseEx are functionally identical.

I changed the stubs to match the names, but I am not sure if this is correct.
If correct, than perhaps the same change applies to the 200D as well? Because these would not match with the same address offset of 0x1AF60 to the 200D.

I like both flowcharts. Walter's is useful from a user and noob developer (read: my) perspective. Users can be educated about the high-level steps and can better understand what is going possibly wrong.

Alex's is great for developers to gain an understanding of the boot process. I already followed boot and reboot. I do not yet understand how the my_big_init_task is launched.

Both should be in documentation. Perhaps in README (Walter's chart) and HACKING (Alex's chart)?

Many thanks for the replies. The experts are here!

Yes, 400plus can be a bit weird if modes dial is turned too quickly, but never anything bad happened.

I don't know what the issue with the remapped video mode were. The links are dead.

In this case i would limit it to the fixed scene modes. The 77D has a special SCN mode where additional scene modes (group picture, kids, food, portrait without flash at night, also multiple exposures at night and HDR) are available and can be selected through menu. I could imagine that analyzing this would help to understand how the software can set shooting parameters. Not sure if any of the ML supported models have this SCN mode already.

Thank you! I worked on your comments and I think I found the memory stubs.
Next I would work on the File I/O stubs.

This is mainly relevant for cameras without C1/C2/C3 modes.

One of the features of 400plus was to store all the settings (AV, TV, M) mode, exposure, ISO, flash, and some 400plus settings. Then you could assign these settings to a scene mode on the mode dial, e. g. Sports, Landscape, Portrait. When the mode dial was turned to that scene mode the 400plus changed all the settings to the assigned preset within a second.

This effectively gave me more custom modes on the 400D than I could ever use. I never needed more than three.

Related seem to be Exposure Presets and Config Presets.

I haven't seen the assignment of presets to the mode dial.
Another main difference to exposure presets seems to be that the mode shall be changed (AV, TV, M).

Use case: I shoot backstage at an event where lighting is known (and difficult), but in the breaks I encounter different situations (inside, outside, different light). So I quickly want to toggle between M and Tv with some other settings, flash and ISO related, as well. Since the event location is very dark I avoid to use the LCD screen as much as possible, another advantage of the mode dial!

As I own a 77D now that has no custom modes that was my motivation to check out ML. I can live without this capability, I'm no pro photographer, or else I would have bought another camera... But still it would be so nice to be able to reassign the scene modes, which are useless for me.

Here is the stubs.S I am working with right now: https://bitbucket.org/calle2010/magic-lantern/src/f387fc148a1c4c5e4c1517a42226bcc0c17ded9f/platform/77D.102/stubs.S

Alex, if you could have a look and verify? I am not very confident...

I run the Canon firmware with

./run_canon_fw.sh 77D,firmware="boot=0" -d callstack -s -S  & gdb-multiarch -x 77D/debugmsg.gdb

It is possible to open the drysh console. Memory information:

Code Select Expand

Open Console K408[1]>...

K408[1]>dryshDry[MusaPUX]> Dry[MusaPUX]> meminfo -m
Malloc Information (onetime type)
  Start Address       = 0x000e0fa8
  End Address         = 0x001f5658
  Total Size          = 0x001146b0 (  1132208)
  Allocated Size      = 0x00007608 (    30216)
  Allocated Peak      = 0x00007608 (    30216)
  Allocated Count     = 0x00000050 (       80)
  Free Size           = 0x0010d0a8 (  1101992)
  Free Block Max Size = 0x0010d0a8 (  1101992)
  Free Block Count    = 0x00000001 (        1)
Dry[MusaPUX]> memmap
e02427a0 : Exception vector
000e0fa0 : Heap start
           0x00114988(1132936)
001f5928 : Heap end
001f5928 : DRYOS system object
           0x00009478(38008)
001feda0 : DRYOS system memory
           0x000e2200(926208)
000e07a0 : Error exception stack start (PU0)
           0x00000400(1024)
000e0ba0 : Error exception stack end (PU0)
000e0ba0 : Error exception stack start (PU1)
           0x00000400(1024)
000e0fa0 : Error exception stack end (PU1)
df000000 : IRQ exception stack start (PU0)
           0x00001000(4096)
df001000 : IRQ exception stack end (PU0)
df001000 : IRQ exception stack start (PU1)
           0x00001000(4096)
df002000 : IRQ exception stack end (PU1)


Tasks:

Code Select Expand

Dry[MusaPUX]> extask
Name            ID   State Pri         Wait(ID)      Stack  % StackTop StackEnd       SP Bound(ID)
init1      000d0004   READY   0         -------   0008/1000 00 001fffc8 00200fc8 00200fc8    BND(1)
DbgMgr     00260006   READY  13         -------   02a0/1000 16 002013d8 002023d8 002022f0    BND(1)
EventMgr   0038000d    WAIT  14  RCVMQ(00370005)  01a8/1000 10 00207408 00208408 00208340    BND(0)
RTCMgr     004e0011    WAIT  14  RCVMQ(004d000c)  0330/0400 79 00209418 00209818 00209750    BND(0)
ShootCaptu 00af001f SUSPEND  14         -------   01f0/1000 12 00215c88 00216c88 000e0b28    BND(0)
EFLensComT 0040000e    WAIT  16  RCVMQ(003e0008)  00b8/0400 17 00204be8 00204fe8 00204f60    BND(0)
MainCtrl   00840017    WAIT  16  RCVMQ(00830013)  0190/1000 09 0020e848 0020f848 0020f7c0    BND(0)
RscMgr     005e0014    WAIT  18  RCVMQ(005d000e)  03f0/1000 24 0020b830 0020c830 0020c768    BND(0)
Panning    00c40022    WAIT  18  RCVMQ(00c3001f)  0170/0c00 11 0021cca0 0021d8a0 0021d7d8    BND(0)
PropMgr    0032000b    WAIT  20  RCVMQ(00310003)  0428/1000 25 001fefc0 001fffc0 001ffef8    BND(0)
MainSubTas 0043000f    WAIT  20  RCVMQ(00410009)  00b0/0400 17 00204ff0 002053f0 00205370    BND(0)
FileCache  005b0013    WAIT  20  RCVMQ(005a000d)  00f8/1000 06 0020a828 0020b828 0020b760    BND(0)
ShootBlack 00bd0020    WAIT  21  RCVMQ(00bc001d)  0138/2000 03 00216c90 00218c90 00218bc8    BND(0)
ShootPreDe 00c10021    WAIT  22  RCVMQ(00c0001e)  00f8/4000 01 00218c98 0021cc98 0021cbd0    BND(0)
GuiLockTas 007e0015    WAIT  23  RCVMQ(007d0011)  00b0/1000 04 0020c838 0020d838 0020d7b8    BND(0)
EvShel     00c60023 RUNNING  24         -------   0358/8000 02 0021d8a8 002258a8 --------    BND(0)
ConsoleSvr 00ce0025    WAIT  24  RCVMQ(00c90020)  01f8/0800 24 002260b8 002268b8 00226820    BND(0)
Startup    002a0007    WAIT  25  RCVMQ(00290002)  0398/2800 08 002023e0 00204be0 00204b50    BND(0)
FileMgr    00470010    WAIT  25  RCVMQ(0046000b)  0820/1000 50 00208410 00209410 00209348    BND(0)
Fstorage   00820016    WAIT  25  RCVMQ(00810012)  00f8/1000 06 0020d840 0020e840 0020e778    BND(0)
Ta10Mgr    00880019    WAIT  25  RCVMQ(00870014)  00f8/1000 06 0020fc58 00210c58 00210b90    BND(0)
HDRMgr     008b001a    WAIT  25  RCVMQ(008a0015)  00f8/1000 06 00210c60 00211c60 00211b98    BND(0)
HDRStage   008d001b    WAIT  25  RCVMQ(008c0016)  00f8/1000 06 00211c68 00212c68 00212ba0    BND(0)
GISMgr     0091001c    WAIT  25  RCVMQ(00900017)  00f8/1000 06 00212c70 00213c70 00213ba8    BND(0)
GISStage   0093001d    WAIT  25  RCVMQ(00920018)  00f8/1000 06 00213c78 00214c78 00214bb0    BND(0)
LowConsole 00cd0024 SUSPEND  25         -------   00d0/0800 10 002258b0 002260b0 00226040    BND(0)
NFCMgr     0035000c    WAIT  26  RCVMQ(00340004)  01e8/1000 11 00206400 00207400 00207338    BND(0)
DOSDriver  00590012    WAIT  26  EVENT(0058000c)  00d8/1000 05 00209820 0020a820 0020a778    BND(0)
AEmodeJudg 00860018    WAIT  26    SEM(0085004d)  0088/0400 13 0020f850 0020fc50 0020fc00    BND(0)
CSMgrTask  0099001e    WAIT  28  RCVMQ(00970019)  0530/1000 32 00214c80 00215c80 00215bd8    BND(0)
PowerMgr   00240005   READY  32         -------   0080/0400 12 00200fd0 002013d0 002013b8    BND(0)
idle       00010001   READY  33         -------   0060/0100 37 001fedb0 001feeb0 001fee80    BND(0)
idle       00020002   READY  33         -------   0008/0100 03 001feeb8 001fefb8 001fefb8    BND(1)


What I don't understand: Why can't GDB read the memory at addresses 0x000-0xFFF? Initially that works, but when I set a breakpoint later in the boot process, e. g. at 0xe04108b2, GDB says it can't access these addresses. Does it have to do with the MMU? I think I read elsewhere in the forum that this address range is separate for the two processors?

I think I understand now:
#112 and #43 from EOS R/RP: This area is unavailable, perhaps to catch null pointer exceptions, if I understand correctly.

I wanted to look at the interrupt vector table as you did in the M2 porting tutorial. But I never see anything valid there.

Alex, thank you for all the information, I find a new piece everyday. But I think I'm stuck here. May try to use IRC when I have the time, never used that before. :-)

The TotalSheets and EstimatedSize errors are likely caused by wrong / incomplete MPU messages (these will have to be logged from a real camera);

I spent the evening trying to find the cause for the ASSERT EstimatedSize.c Task = RscMgr Line=1483 error.
Finally I figured out that a wrong value is passed from GetEstimatedSizeOfMovie or similar and when I wanted to use gdb to put a breakpoint I found that Alex did this already, including the workaround, in a20c79b.

So that means this assertion doesn't happen anymore when running with GDB debugmsg.gdb.
At least I learned a lot so far.

Next is an exception:

Code Select Expand

< Error Exception>
CORE        : 0
TYPE        : 16
ISR         : 0
TASK IDSR   : 11534368
TASK Name   : ShootCapture
R 0         : e018a2cd
R 1         : 0
R 2         : 0
R 3         : 1
R 4         : a1bb0
R 5         : 0
R 6         : 10000
R 7         : e0042c9f
R 8         : 40b65600
R 9         : 19980218
R10         : 19980218
R11         : 19980218
R12         : 48
R13         : 1ffebc
R14         : e018a315
PC          : e04108b2
CPSR        : 73

The code at this PC is

Code Select Expand

e04108b2:       f845 0022       str.w   r0, [r5, r2, lsl #2]
If I understand it right, it tries to store the value in r0 to the address r5+r2, which happens to be 0.

Is this also a known problem and perhaps solved already?

Mostly I added 1 for the function calls. I will clean up a bit and then create a fork on Bitbucket with the update. It may take some days but I hope to get it done on the weekend.

I use Ubuntu bionic64 in MacOS through VirtualBox and Vagrant. Basically Vagrant allows you to discard and create the dev environment anytime. All files will be mirrored to the MacOS host.
Have a look here https://github.com/calle2010/magic-lantern-77d-vagrant

But I don't think the issues are caused by MacOS. Your output is very similar to mine.

I made some progress. I changed the create_task stub to

NSTUB(0xDF008CD3,  task_create)            /* used to start TaskMain, GuiMainTask etc */

Now the assertion message in serial console "SystemIF:KerTask.c, Task = init, Line 684" is gone.

Also I got a DEBUGMSG.LOG on the sd.img: https://gist.github.com/calle2010/f6a90f9973cf7d5e191190b45ab3f430

I have not verified all the other stubs yet.

I followed the work from aprofiti and fixed the thumb bits in stubs.S.

I basically see the same results, including the strange broken line in the emulator. But the red light is on after boot for about a second and then turns off.

Unfortunately I get no log file on sd.img, neither with reboot-dumper nor with the changed makefile for minimal-d678.

Running the minimal-d678 in Qemu with "-d debugmsg,int,io" I get a lot of messages like this:

[CPU0] [      RscMgr:001b61ff ] (00:0f) >>> INT-01Bh dryos_timer 54535F4D(5F545241)
[CPU0] 001B7958: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[HPTimer] Firing HPTimer #13
[EOS] trigger int 0x28
[CPU0] 001B6202: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [GICC]    at RscMgr:E029D558:001B6203 [0xC1000110] <- 0x20      :
E04D45A4: Taking exception 5 [IRQ]
[CPU0] [GICC]    at RscMgr:E029D4D4:E0242919 [0xC100010C] -> 0x20      : GICC_IAR
[CPU0] [INT]     at RscMgr:E029D4FA:E0242919 [0xD4011000] -> 0x28      : Requested int reason a0 (INT 28h)
[CPU0] [      RscMgr:001b61ff ] (00:0f) >>> INT-028h HPTimer 0(696C4370)
[CPU0] 001B7958: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] 001B6202: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [GICC]    at RscMgr:E029D558:001B6203 [0xC1000110] <- 0x20      :
[CPU0] [HPTimer] at RscMgr:E02B80CA:E05AA835 [0xC0243300] -> 0x40000   : Which timer(s) triggered
[CPU0] [HPTimer] at RscMgr:E02B8070:E05AA901 [0xC02432D4] <- 0x0       : HPTimer #13: reset trigger?
[CPU0] [HPTimer] at RscMgr:E02B8074:E05AA901 [0xC02432D4] -> 0x0       : HPTimer #13:
[CPU0] [HPTimer] at RscMgr:E02B80CA:E05AA99B [0xC0243300] -> 0x0       : Which timer(s) triggered
[CPU0] [      RscMgr:001b62cb ] (00:0f) <<< INT-028h HPTimer
[CPU0] 001B7958: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [INT]     at RscMgr:E029D5A2:001B62CF [0xD4011010] <- 0x28      : Enabled interrupt 28h
[CPU0] [      RscMgr:001b62cb ] (00:0f) <<< INT-01Bh dryos_timer
[CPU0] 001B7958: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
000350FC: Taking exception 5 [IRQ]
[CPU0] [GICC]    at RscMgr:E029D4D4:E02428C9 [0xC100010C] -> 0x20      : GICC_IAR
[CPU0] [      RscMgr:001b61ff ] (00:0f) >>> INT-01Bh dryos_timer 54535F4D(5F545241)
[CPU0] 001B7958: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] 001B6202: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [GICC]    at RscMgr:E029D558:001B6203 [0xC1000110] <- 0x20      :
[CPU0] [      RscMgr:001b62cb ] (00:0f) <<< INT-01Bh dryos_timer
[CPU0] 001B7958: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
000350F6: Taking exception 5 [IRQ]
[CPU0] [GICC]    at RscMgr:E029D4D4:E02428C9 [0xC100010C] -> 0x20      : GICC_IAR
[CPU0] [      RscMgr:001b61ff ] (00:0f) >>> INT-01Bh dryos_timer 54535F4D(5F545241)
[CPU0] 001B7958: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] 001B6202: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [GICC]    at RscMgr:E029D558:001B6203 [0xC1000110] <- 0x20      :
[CPU0] [      RscMgr:001b62cb ] (00:0f) <<< INT-01Bh dryos_timer
[CPU0] 001B7958: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000

This is what the serial console shows:



free image upload


Not sure if this is normal or what to do next. I can't compare with another camera since I don't have other ROM dumps available.

Between all the messages above there are some more interesting logs for MPU as well:

[MPU] FIXME: using generic MPU spells for 77D.
[MPU] FIXME: no MPU button codes for 77D.
[MPU] Received: 06 04 02 00 00 00  (Init - spell #1)
[MPU] Sending : 2c 2a 02 00 03 03 03 04 03 00 00 48 00 00 00 14 50 00 00 00 00 81 06 00 00 04 06 00 00 04 06 00 00 04 01 01 00 00 00 00 4d 4b 01 00  (Init group)
[MPU] Sending : 06 05 01 21 01 00  (PROP_CARD2_EXISTS)
[MPU] Received: 22 20 0e 39 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  (unknown - unnamed)
[MPU] Received: 08 06 01 a7 00 01 00 00  (unknown - unnamed)
[MPU] Received: 08 06 00 00 02 00 00 00  (unknown - Complete WaitID)
[MPU] Received: 0a 08 03 06 00 00 00 00 00 00  (unknown - PROP_AVAIL_SHOT)
[MPU] Received: 06 04 03 10 00 00  (unknown - PROP 80030008)
[MPU] Received: 06 05 03 07 ff 00  (unknown - PROP_BURST_COUNT)
[MPU] Received: 06 05 01 2e 01 00  (unknown - PROP_SAVE_MODE)
[MPU] Received: 0a 08 03 0b 00 00 00 00 00 00  (unknown - PROP 80030007)
[MPU] Received: 06 05 03 19 01 00  (PROP_TFT_STATUS - spell #11)
[MPU] Received: 06 05 01 56 00 00  (unknown - unnamed)
[MPU] Received: 06 05 04 0e 01 00  (unknown - PROP 8002000D)
[MPU] Received: 06 05 03 40 00 00  (unknown - PROP 80030040)
[MPU] Received: 0a 09 01 55 00 00 02 00 01 00  (unknown - PROP_MULTIPLE_EXPOSURE_SETTING)
[MPU] Received: 0c 0b 03 53 02 00 48 81 81 00 00 00  (unknown - PROP 80030058)
[MPU] Received: 0c 0b 03 53 02 00 48 81 81 00 00 00  (unknown - PROP 80030058)
[MPU] Received: 06 05 03 8a 00 00  (unknown - unnamed)
[MPU] Received: 06 04 02 14 00 00  (unknown - unnamed)
[MPU] Received: 08 06 01 24 00 01 00 00  (PROP_CARD2_STATUS - spell #7)
[MPU] Sending : 08 06 01 24 00 01 00 00  (PROP_CARD2_STATUS)
[MPU] Received: 08 06 01 27 00 64 00 00  (unknown - PROP_CARD2_FOLDER_NUMBER)
[MPU] Received: 08 06 01 2a 04 e6 00 00  (unknown - PROP_CARD2_FILE_NUMBER)
[MPU] Received: 08 06 03 03 65 01 00 00  (unknown - unnamed)
[MPU] Received: 08 07 03 6a 00 02 00 00  (unknown - unnamed)

I can confirm that the latest 77D.FIR works. Checksums displayed (and in RESCUE.LOG) of ROM0.BIN and ROM1.BIN match the values calculated on the saved files. ROM1.BIN dumping and checksum calculation is very slow.

Magic Lantern Rescue
----------------------------
- Model ID: 0x408 77D
- Camera model: Canon EOS 77D / 9000D
- Firmware version: 1.0.2 / 7.3.6 6E(44)
- IMG naming: 100CANON/IMG_2067.JPG
- Boot flags: FIR=0 BOOT=0 RAM=-1 UPD=-1
- ROMBASEADDR: 0xE0040000
- boot_read/write_sector 106f85 107081
- 10190B Card init => 2
- Dumping ROM0... 100%
- MD5: a12fc3b5b380e81352f8e5d4ae5c3983
- Dumping ROM1... 100%
- MD5: ee61883e763361f9f8374960a219088b
- No serial flash.
- Saving RESCUE.LOG ...

I have no experience with the commercial IDA tool or generally ARM assembler but wanted to support the porting efforts for the 77D model.

So far I have little results but at least a stable build environment. I used it to toy around with Ghidra. Here are my first steps so far:
https://github.com/calle2010/magic-lantern-77d-vagrant/blob/master/ghidra.md

At least I could make sense of some of the bootloader code. Also Ghidra finds functions, strings, embedded JPEG images and other data. It can be scripted with Java or Python, but I haven't tried this yet.

If anybody has tipps and hints on how to use Ghidra effectively I would be happy about replies.

Perhaps it is obvious but not mentioned here yet: Running qemu with "-d romcpy" creates a file "romcpy.sh" which is helpful to create the additional blobs.

Very nice! Not familiar with vagrant, but if it makes easier to setup a build environment, it might be an interesting option.

I do only my first steps with Vagrant. I want to automate all the manual steps and setting up the build environment on my MacOS created too much clutter for my taste.

Moving qemu.monitor into /tmp sounds interesting.

This was just the first place that came to my mind. The working directory in this setup is on the VirtualBox filesystem mounted with nodev, so creation of the socket fails with "no permission" error message.

I didn't double-check them yet, only noticed the Thumb bit was not set in most of the stubs (and it should be; refer to 200D for details).

I will check the 200D code and see if I can find the same stubs for 77D. My assembler experience is very limited, though. Also I do not yet quite understand how to test the stubs without the GUI emulation.

Hi,

I've dumped the ROMs of my 77D and created a build environment that brings me up to this point:





I also did the test with changing reboot.c to disable the boot flag. Is the output of this still relevant for anybody?

I have a few questions now:
- I unterstand the next step is to collect the stubs. Is there already a more complete list than aprofiti posted on October 1st?
- Has anybody already done the steps described here? https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst?fileviewer=file-view-default#rst-header-adding-support-for-a-new-camera-model
- In branch "digic6-dumper" I see directory "platform/77D.100". Shouldn't this be "77D.102" since the current firmware version is 1.0.2?
- Is there a repository where people work together on porting to the 77D?

Thanks you so far for the good documentation. I hope I can help to get some steps further to a working port of ML for the 77D.

Cheers,
Christian.

PS: If you are interested on how I created my environment have a look at https://github.com/calle2010/magic-lantern-77d-vagrant. I use Vagrant and VirtualBox hosted on MacOs.