Author Topic: ML on EOS-M2  (Read 23770 times)

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 9943
  • 5D Mark Free
Re: ML on EOS-M2
« Reply #75 on: June 21, 2017, 09:35:37 PM »
However, the MD5 values from the "original" ROM1 and the new QEMU dump don't match. Is this expected?

"boot=1" works by patching the ROM. If you do the same change in a hex editor, you'll get the second MD5.

dfort

  • Hero Member
  • *****
  • Posts: 1664
Re: ML on EOS-M2
« Reply #76 on: June 24, 2017, 03:43:22 AM »
Wow--big progress! Did you already try it on your M2?

Not yet. Still in QEMU. Trying to run Hello World but my MacBook doesn't look like an EOSM2:



I found everything in stubs.S but then I started going through consts.h and yikes! Looks like finding stubs was the easy part. I did read the part about firmware signature failing in QEMU so I made a new branch, merged QEMU and EOSM2 but found out that if there is no value for "#define SIG_EOSM2_103" then I get a blank QEMU screen. Is this a Catch-22?

Oh well, at least I've got a good stubs.S file -- uh, I think.
EOSM.202 EOSM.203 EOSM2.103 700D.115 5D3.*

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 9943
  • 5D Mark Free
Re: ML on EOS-M2
« Reply #77 on: June 24, 2017, 10:17:13 AM »
Time to learn some debugging tricks :)

Look at recent QEMU updates - one of them is compiling ML with debug information. So far I have only used it for translating code addresses from ML code into source code lines (addr2line). Let's see if we can enable source code debugging in GDB, so we can run the code step by step, as we would with a PC program.

Notes:
- This is the first time I'm trying this trick. I have used source code debugging in IDA + QEMU before, but that was based on decompiled code (and the free version can't do debugging if I'm not mistaken). Here I want to run ML step by step, on the original source code.
- I want the QEMU updates in the mainline, as there are some APIs for debugging ML as well (there's a PR open), which means you can merge "qemu" in your EOSM2 branch. Or, simply experiment there, and once the debugging session is over, move the changes to the "clean" branch (this is what I usually do if I need the dm-spy-experiments branch).

Enough chit-chat, let's try it:
Code: [Select]
# from ML directory
hg update qemu -C
cd platform/EOSM2.103
make clean; make
# mount the SD image
make install

Next, we have to set up a breakpoint in our code (autoexec.bin); we can do that from debugmsg.gdb.

Without debugging symbols, we would do it like this and debug the assembly code (which is not very easy):
Code: [Select]
# breakpoint on autoexec.bin
b *0x800000

To use debugging symbols in gdb, we'll have to use symbol-file (to load the symbols from an elf file). The .o files that appear when compiling ML are elf files. Also, the files without extension, "autoexec" and "magiclantern", are elf files. The first one refers to reboot.c (look it up in Makefile.src) and gets loaded where Canon's bootloader loads autoexec.bin (at AUTOEXEC_BASE = 0x800000), while the second refers to the regular ML code (starting in boot-hack.c), that gets loaded into its final location (RESTARTSTART).

Why all this trouble? Because our binary can't stay at 0x800000. How comes? Well, autoexec.bin (which is a file loaded in Canon code, probably for debugging or development purposes) wasn't meant (read: designed by Canon) to be a program to run alongside Canon's main firmware; therefore DryOS is free to use the addresses near 0x800000 (where we are loaded). So, we have to move somewhere else. More on that later.

Back to our debugging session: the issue is in reboot.c (that's where this message is printed from), so we are going to run "autoexec.bin" as a plain binary (machine code), and use "autoexec" (elf) for the debugging symbols. Add this to debugmsg.gdb:

Code: [Select]
# breakpoint on autoexec.bin (cstart)
symbol-file ../magic-lantern/platform/EOSM2.103/autoexec
b cstart

You can keep both breakpoints, as there are some other things that execute before cstart (such as checking the integrity of the binary file, to avoid executing random code when loading from a corrupted filesystem). Without further ado, let's dive in:

Code: [Select]
# from QEMU directory (assuming default paths and bash)
. ./export_ml_syms.sh EOSM2.103
./run_canon_fw.sh EOSM2,firmware="boot=1" -s -S & arm-none-eabi-gdb -x EOSM2/debugmsg.gdb

We'll hit the first breakpoint first:
Code: [Select]
Now jump to AUTOEXEC.BIN!!
...
Breakpoint 3, 0x00800000 in _start ()
=> 0x00800000 <_start+0>: 0c 40 8f e2 add r4, pc, #12

Type "continue" ("c") to reach cstart:
Code: [Select]
Breakpoint 4, cstart () at ../../src/reboot.c:215
215     int s = compute_signature((int*)SIG_START, SIG_LEN);

Type "layout src". Now you are debugging on the original source code.

Tip: you can set breakpoints like this:
Code: [Select]
b reboot.c:216
Refer to GDB manual for the stepping commands, or use a GDB GUI.

Let's try nemiver:
Code: [Select]
. ./export_ml_syms.sh EOSM2.103
./run_canon_fw.sh EOSM2,firmware="boot=1" -s -S & nemiver --gdb-binary=$(which arm-none-eabi-gdb) --remote="localhost:1234" ../magic-lantern/platform/EOSM2.103/autoexec



For some reason, I'm unable to step. Too bad, as it seems to be working for these guys. Maybe someone else can figure it out?

Let's try gdbgui:
Code: [Select]
. ./export_ml_syms.sh EOSM2.103
./run_canon_fw.sh EOSM2,firmware="boot=1" -s -S & gdbgui -g "arm-none-eabi-gdb"

Make sure you view its GUI with Google Chrome and enter this at the gdb prompt:
Code: [Select]
source EOSM2/debugmsg.gdb



This one appears to work a little better, you can run the program step by step using the GUI, but still gives a bunch of errors. Go figure.

cgdb is a terminal-based GUI, but doesn't like QEMU printing debug messages on the same window. Fortunately, nkls provided a script to split the terminal window in two - splitgdb.sh. Replace its contents with something like this:
Code: [Select]
#!/usr/bin/env bash

. ./export_ml_syms.sh $1.$2
tmux new-session -d "./run_canon_fw.sh $1,firmware='boot=1' -s -S"
tmux split-window -h "cgdb -d arm-none-eabi-gdb -x $1/debugmsg.gdb"
tmux attach-session -d

Code: [Select]
./splitgdb.sh EOSM2 103




The user interface seems to be very rough though, and it doesn't like our colored debug messages either...

Let's try the "classic" ddd:
Code: [Select]
. ./export_ml_syms.sh EOSM2.103
./run_canon_fw.sh EOSM2,firmware="boot=1" -s -S & ddd --debugger "arm-none-eabi-gdb -x EOSM2/debugmsg.gdb"

This works. The interface is not pretty, but at least it works.

(I've ran EOSM ML on EOSM2 ROM, in case you are wondering)



Other suggestions?

dfort

  • Hero Member
  • *****
  • Posts: 1664
Re: ML on EOS-M2
« Reply #78 on: June 25, 2017, 08:43:42 AM »
Code: [Select]
# from ML directory
hg update qemu -C
cd platform/EOSM2.103

Oh I wish. For now I'm having to merge EOSM2.103_wip, qemu-EOSM2-wip_1, qemu-build-tweaks-2 and of course qemu into a qemu-wip branch in order to get all of the pieces working with EOSM2 on a Mac. I'm keeping these separate branches to keep a couple of my pull requests in order. The build tweaks for the Mac are working nicely as is the EOSM2 QEMU setup. It will be a happy day for me when these get merged into the qemu branch.  :D

Code: [Select]
Now jump to AUTOEXEC.BIN!!
...
Breakpoint 3, 0x00800000 in _start ()
=> 0x00800000 <_start+0>: 0c 40 8f e2 add r4, pc, #12

Type "continue" ("c") to reach cstart:
Code: [Select]
Breakpoint 4, cstart () at ../../src/reboot.c:215
215     int s = compute_signature((int*)SIG_START, SIG_LEN);

I'm seeing something slightly different probably because I'm working on a different autoexec.bin.

Code: [Select]
Breakpoint 1 at 0x4398
Breakpoint 2 at 0x7360
Breakpoint 3 at 0xff0c5144
Breakpoint 4 at 0x800000
Breakpoint 5 at 0x8646ec: file ../../src/fw-signature.h, line 47.
(gdb) c
Continuing.
...
Now jump to AUTOEXEC.BIN!!
0010E5F4: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0xC005107D
0010E5F4: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0xC005107D

Breakpoint 4, 0x00800000 in _start ()
(gdb) c
Continuing.

Breakpoint 5, cstart () at ../../src/reboot.c:215
215     int s = compute_signature((int*)SIG_START, SIG_LEN);
(gdb)


Type "layout src". Now you are debugging on the original source code.

Nice! Got the breakpoints tip working too.



Let's try nemiver:

Spent too many hours trying to get nemiver working on Mac (building from the source code) but never succeeded.

Moving on to gdbgui. It this one is coded in python and is easy to install on Mac:

Code: [Select]
pip install gdbgui --upgrade
Yeah, easy but it took me a while because the instructions on the project page didn't work for me. Maybe because I'm using the Homebrew python that doesn't need root access to install packages? So if you're on a Mac and followed my ML tutorial, don't do this:

Code: [Select]
sudo pip install gdbgui --upgrade --user
Now we're on the same page--sort of.



It is getting late so I'll skip to ddd:

Code: [Select]
brew tap homebrew/core
brew install ddd

And...
Code: [Select]
Setting BOOTDISK flag to FFFFFFFF
Error: Unresolved inheritance operation

Xt error (Unresolved inheritance operation).

Oops!  You have found a bug in DDD.

If you can reproduce this bug, please send a bug report
to <[email protected]>, giving a subject like

    DDD 3.3.12 (i386-apple-darwin16.3.0) gets Xt error

To enable us to fix the bug, you should include the following information:
* What you were doing to get this message.  Report all the facts.
* The contents of the `~/.ddd/log' file as generated by this session.
Please read also the section "Reporting Bugs" in the DDD manual.

We thank you for your support.

ddd: Cannot save options
[1]   Done                    ./run_canon_fw.sh EOSM2,firmware="boot=1" -s -S

Ugh!

I'll try cgdb tomorrow.
EOSM.202 EOSM.203 EOSM2.103 700D.115 5D3.*

dfort

  • Hero Member
  • *****
  • Posts: 1664
Re: ML on EOS-M2
« Reply #79 on: June 25, 2017, 04:46:14 PM »
Ok--trying out cgdb. The splitgdb.sh script uses tmux which I already had on my system, don't when I installed it but it is also available from brew as is cgdb:
 
Code: [Select]
brew install cgdb
Wow, this is one is impressive when run in full screen mode.



A couple of questions:
  • Why isn't this version of splitgdb.sh by nkls in the qemu branch? I tried the current script and it skipped most of the breaks we put in debugmsg.gdb, missed the jump to autoexec.bin and launched the Canon GUI.
  • Is the firmware signature it displayed to be trusted?

Code: [Select]
│Breakpoint 2 at 0x7360     
│Breakpoint 3 at 0xff0c5144 
│Breakpoint 4 at 0x800000   
│Breakpoint 5 at 0x8646ec: file ../../src/fw-signature.h, line 47. 
│(gdb) c                     
│Continuing.                 

│Breakpoint 4, 0x00800000 in _start ()                   
│(gdb) c                     
│Continuing.                 

│Breakpoint 5, cstart () at ../../src/reboot.c:215       
│(gdb) print s               
│$1 = 0xceeeeeec             
│(gdb) print _signature     
│$2 = 0x2d7c6dcf             
│(gdb)   

[EDIT] Never mind, it is showing the EOSM_202 signature I'm using as a temp. Still find myself in a Catch 22 and can't get "hello world" working much less find the firmware signature. That has to be done in camera, right?

Code: [Select]
│Breakpoint 5, cstart () at ../../src/reboot.c:211         
│(gdb) print s               
│No symbol "s" in current context.                         
│(gdb) print _signature       
│No symbol "_signature" in current context.                 
│(gdb)

Continuing from there:

Code: [Select]
DRYOS PANIC: Module Code = 1, Panic Code = 2
Catch 22 -- Need to run "hello world" to get the firmware signature but QEMU doesn't run "hello world" because it can't get the firmware signature. If we could get the firmware signature maybe "hello world" will run on QEMU but then, what's the point?

Is it too early to turn on the camera bootflag? (Not that I have a clue how to do that.)
EOSM.202 EOSM.203 EOSM2.103 700D.115 5D3.*

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 9943
  • 5D Mark Free
Re: ML on EOS-M2
« Reply #80 on: June 25, 2017, 05:16:06 PM »
Why isn't this version of splitgdb.sh by nkls in the qemu branch?

The version from nkls is there. What I wrote above was something I came up with at the time of writing; I didn't use this approach before.

Would be nice to improve it to accept any number of command-line options (and pass all of them to QEMU).

Quote
Is the firmware signature it displayed to be trusted?

Yes, but only after compute_signature() returns. Not before.

The value from my screenshots should be valid, although I have not set up an EOSM2 platform directory yet (so it's untested).

Quote
Oops!  You have found a bug in DDD.

That's too bad - a very powerful piece of software apparently unmaintained for about 8 years...

Quote
DRYOS PANIC: Module Code = 1, Panic Code = 2

That's a good sign - this message can only appear from the main firmware, so we are no longer in bootloader context. Still, probably something went wrong when patching the startup process.

Time to debug what happens between loading autoexec.bin and this message. Some useful tools:
Code: [Select]
-d calls or callstack
-d ramw (RAM writes)
-d autoexec (to avoid verbose messages from the bootloader)

For example, -d autoexec,ramw,calls,io,v should give some very good insights into how the startup code is patched, and why it doesn't work. The log will be huge though, and it will miss the call to copy_and_restart from boot-hack.c (because it's not actually a call, but a direct jump), but will catch the next call (from copy_and_restart to reloc_entry), which looks like this (500D, since that's the binary I happened to have on the virtual card):

Code: [Select]
       (big bunch of zeroing out some RAM - zero_bss)
       (big bunch of copying from ROM to RAM - blob_memcpy)
       [ram] at 0x0004D4D4:000B8818 [0x000BB300] <- 0xE12FFF1E: was 0xEBFFF769;
       [ram] at 0x0004D4DC:000B8818 [0x000B9154] <- 0xCB400   : was 0x4C5C4;
       [ram] at 0x0004D4E4:000B8818 [0x000B8704] <- 0x7E400   : was 0x0;
       [ram] at 0x0004D4FC:000B8818 [0x000B90BC] <- 0xEBCCCAFD: was 0xEB0F6D03;
       [ram] at 0x0004D514:000B8818 [0x000B9144] <- 0xEBBD78E5: was 0xEB001AEB;
       [ram] at 0x0004D51C:000B8818 [0x000B9160] <- 0x4D010   : was 0xFF011DBC;
       call 0xB8824(0, c00003e0, 400, b8824)                                     at [4d560:86ba30] (copy_and_restart)
        [FlashIF] at 0x000B882C:0004D564 [0xC0000010] <- 0xD9C5D9C5: 'Write enable' enabled
        [*unk*] at 0x000B8838:0004D564 [0xC020010C] <- 0x1       : ???
        ...
        (more startup activity follows)

Right before this call, you'll see the patching process (those "hijack" macros - where they go). I can use this log to check if that went well.

Tip: in the qemu branch, in boot-hack.c (but not in minimal.c), there are some startup messages (qprint*). These are useful - to see them on the QEMU console, compile with CONFIG_QEMU=y from the regular target (not minimal). Binaries compiled in this way will not run on the camera. More about this on the 1300D thread.

dfort

  • Hero Member
  • *****
  • Posts: 1664
Re: ML on EOS-M2
« Reply #81 on: June 25, 2017, 05:30:03 PM »
The version from nkls is there. What I wrote above was something I came up with at the time of writing; I didn't use this approach before.

Would be nice to improve it to accept any number of command-line options (and pass all of them to QEMU).

Yes, but your latest version of splitgdb.sh seems to be working more better.  :D

...I have not set up an EOSM2 platform directory yet (so it's untested).

I have. It obviously isn't finished but it compiles.

https://bitbucket.org/daniel_fort/magic-lantern/branch/EOSM2.103_wip
EOSM.202 EOSM.203 EOSM2.103 700D.115 5D3.*

dfort

  • Hero Member
  • *****
  • Posts: 1664
Re: ML on EOS-M2
« Reply #82 on: June 26, 2017, 07:55:05 AM »
I'm still inching my way through consts.h and hit another speed bump. Got to YUV422_LV_BUFFER_1,2,3 and looked up the link to the wiki that's in the source code:

Quote
// http://magiclantern.wikia.com/wiki/VRAM_ADDR_from_code
// stateobj_disp[1]

Not sure what stateobj_disp[1] referrers to but determined that the wiki page wants me to run this code on the EOSM2.103:

Code: [Select]
int i;
unsigned int *bmp_ram_addr = bmp_vram_info;
for (i=0; i<2; i++)
  DebugMsg( DM_MAGIC, 3, "bmp_vram[]=0x%08x, 0x%08x, 0x%08x",
    bmp_ram_addr[3*i+0],  bmp_ram_addr[3*i+1], bmp_ram_addr[3*i+2] );
unsigned int *vram_info_addr = vram_info;
for (i=0; i<3; i++)
  DebugMsg( DM_MAGIC, 3, "vram_info[]=0x%08x, w=%4d, h=%4d, p=%4d, n=%4d",
      vram_info_addr[5*i+0],  vram_info_addr[5*i+1],
      vram_info_addr[5*i+2], vram_info_addr[5*i+3], vram_info_addr[5*i+4] );
unsigned int *stateobj_disp = 0x90494+0x128; // see ff137acc SetBitmapVramAddress
DebugMsg( DM_MAGIC, 3, "stateobj_disp+0xb0[]=0x%08x,0x%08x,0x%08x,",
  stateobj_disp[0], stateobj_disp[1], stateobj_disp[2]);

I was able to figure out the changes to the code but not sure where to run it--probably in "Don't click me?" (run_test in src/debug.c) However, that seems to be something that needs to be run in the camera, or can it be done in QEMU? Also not having much luck getting the firmware signature in QEMU, seems like I'm at the point of being able to run "Hello world" on the camera but can't seem to be able to get it working in QEMU. (I also tend to use "seem" way too much.)

The unexpected  benefactor of this port is the original EOSM as I keep finding blips in the code for that platform.
EOSM.202 EOSM.203 EOSM2.103 700D.115 5D3.*

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 9943
  • 5D Mark Free
Re: ML on EOS-M2
« Reply #83 on: June 26, 2017, 11:00:55 AM »
60D in QEMU (from don't click me):

Code: [Select]
. ./export_ml_syms.sh 60D.111 # needed for DebugMsg
./run_canon_fw.sh 60D,firmware="boot=1" -d debugmsg
...
[    run_test:1fe0bc9c ] (32:03) bmp_vram[]=0xc0f140d0, 0x00000000, 0x03f87100
[    run_test:1fe0bcc0 ] (32:03) bmp_vram[]=0xc0f140d4, 0x00000000, 0x03f87100
[    run_test:1fe0bce8 ] (32:03) stateobj_disp+0xbc[]=0x43f80008,0x5c307800,0x40a8e470,

From real camera (the easiest way was to use printf):
Code: [Select]
# 60D 1.1.1, 0x2458+0xBC
bmp_vram[]=0xc0f140d0, 0x00000000, 0x03f87100
bmp_vram[]=0xc0f140d4, 0x00000000, 0x03f87100
stateobj_disp+0xbc[]=0x43f80008,0x41b07800,0x48a902c4

In both cases, stateobj_disp[1] shows a valid address for the image buffer. It's not always the same; on this model there are 3 possible addresses; they are not fixed (as we thought in early days) but allocated dynamically. In many cases (but not always), this dynamic allocation gives the same results every time, so hardcoding the image buffer addresses usually works. This area really needs some cleanup (wip here).

However, D5 models don't seem to work that well in QEMU:

Code: [Select]
# 5D3 1.1.3, 0x246A4+0x118, regular photo mode
[    run_test:000753ec ] (32:03) bmp_vram[]=0xc0f140d0, 0x00000000, 0x00dc3100
[    run_test:00075410 ] (32:03) bmp_vram[]=0xc0f140d4, 0x00000000, 0x00dc3100
[    run_test:00075438 ] (32:03) stateobj_disp+0x118[]=0x40dbc008,0x00000000,0x40881520,

# 5D3 1.1.3, 0x246A4+0x118, playback mode (not exactly working well in QEMU)
[    run_test:000753ec ] (32:03) bmp_vram[]=0xc0f140d0, 0x00000000, 0x00d43100
[    run_test:00075410 ] (32:03) bmp_vram[]=0xc0f140d4, 0x00000000, 0x00d43100
[    run_test:00075438 ] (32:03) stateobj_disp+0x118[]=0x00000000,0x40881414,0x00000000,

# 700D 1.1.4, 0x23C20+0x118 (in QEMU it starts in movie mode and asks for a lens)
[     ml_init:0007f1d0 ] (32:03) bmp_vram[]=0xc0f140d0, 0x00000000, 0x01307100
[     ml_init:0007f1f4 ] (32:03) bmp_vram[]=0xc0f140d4, 0x00000000, 0x01307100
[     ml_init:0007f21c ] (32:03) stateobj_disp+0x118[]=0x41300008,0x00000000,0x4092e400,

# 700D 1.1.4, 0x23C20+0x118, playback mode
[     ml_init:0007f1ec ] (32:03) bmp_vram[]=0xc0f140d0, 0x00000000, 0x01387100
[     ml_init:0007f210 ] (32:03) bmp_vram[]=0xc0f140d4, 0x00000000, 0x01387100
[     ml_init:0007f238 ] (32:03) stateobj_disp+0x118[]=0x41380008,0x00000000,0x4092e3a8

# EOSM 2.0.2, 0x3E650+0x114 (no GUI in QEMU)
[     ml_init:0009e70c ] (32:03) bmp_vram[]=0xc0f140d0, 0x00000001, 0x01387100
[     ml_init:0009e730 ] (32:03) bmp_vram[]=0xc0f140d4, 0x00000001, 0x01387100
[     ml_init:0009e758 ] (32:03) stateobj_disp+0x114[]=0x41380008,0x00000000,0x00000000,

In 5D3 1.1.3 playback, there is some nonzero value, but I don't recognize it as a display buffer address (it might be correct), while on 700D and EOSM I've only got 0 in QEMU. Probably that's the current state of the emulation.

In any case, this test does not reveal any new addresses, so you don't really need to run it; matching the stub with other models should be enough.

dfort

  • Hero Member
  • *****
  • Posts: 1664
Re: ML on EOS-M2
« Reply #84 on: June 27, 2017, 11:31:31 PM »
In any case, this test does not reveal any new addresses, so you don't really need to run it; matching the stub with other models should be enough.

This is proving to be a devilishly difficult stub to ferret out of the disassembly. I found only one match in one of my EOSM.202 disassemblies:

Code: [Select]
"[LVEVF] evVdInterrupt LastRamClear Start!![4f1d7800]":
That matches the first of the three buffers I'm searching for:

Code: [Select]
#define YUV422_LV_BUFFER_1 0x4F1D7800
#define YUV422_LV_BUFFER_2 0x4F5E7800
#define YUV422_LV_BUFFER_3 0x4F9F7800

Though it is sort of a dead end because all the other models, including the EOSM2 shows this:

Code: [Select]
"evVdInterrupt LastRamClear Start!![%lx]":
There's a lot of "0x40000000" all over the disassemblies and maybe that's a clue?

I'm probably on the wrong path but I searched through the forum and wiki and came up empty handed. Also don't know if I should be pressing forward finding stubs or if I should try to get "Hello world" working in QEMU in order to find the firmware signature.

In any case, I'll keep searching.
EOSM.202 EOSM.203 EOSM2.103 700D.115 5D3.*

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 9943
  • 5D Mark Free
Re: ML on EOS-M2
« Reply #85 on: Yesterday at 12:16:01 AM »
Couldn't find it from LastRamClear Start, but this does apply to both M and M2.

dfort

  • Hero Member
  • *****
  • Posts: 1664
Re: ML on EOS-M2
« Reply #86 on: Yesterday at 05:23:37 AM »
I can see the hint near ImageEffect that shows the values for YUV422_LV_BUFFER_DISPLAY_ADDR but I'm still clueless where to find YUV422_LV_BUFFER_1,2,3.

I'll keep going and get back to this later, maybe it will become obvious the second time around.
EOSM.202 EOSM.203 EOSM2.103 700D.115 5D3.*

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 9943
  • 5D Mark Free
Re: ML on EOS-M2
« Reply #87 on: Yesterday at 08:26:05 AM »
Ah, right. I've found one in QEMU - 0x4f3d7800. You could use that value for all of them, as a workaround.

I've found it by pressing P to go to play mode, then printing the contents of 0x90494+0x12C in gdb. I was lucky, as this didn't work on the other D5 models I've tried before (double-checked today, still no luck there).

I've deleted the YUV422_(LV|HD)* constants locally, but there are some bits of code that had to be updated (on the yuv_buffers branch mentioned before, merged with new-lv-buffer-detection - which attempts to autodetect these addresses at runtime, rather than using hardcoded values). Unfortunately, the current state is "compiles, but doesn't work" (after more than half a day of fiddling with it), and I doubt I'll be able to fix it today.