Canon EOS 1300D / Rebel T6

Started by the12354, October 03, 2016, 11:51:34 AM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

DeinGott

Sorry did not copy the 1300D changes to compile the HELLO World. But i see you already found the code. i only copied it from other cameras.

i am working on that hello world. some offsets seam broken. i narrowed the problem down to the is_dir function and there the FIO_FindFirstEx function call, the stub should point to the correct place (0xFE2A51FC, if someone can verify). But it looks as if we cannot execute that function i always get an exception at pc ff1f94d8. I added some debug print output to the beginning of the functions. But Ida does not stop in FIO_FindFirstEx. I am investigating that.


start MY BIG INIT
start _find_ml_card
start is_dir
Searching for A:/ML
< Error Exception>
TYPE        : 4
ISR         : 0
TASK IDSR   : 50135115
TASK Name   : ml_init
R 0         : 2fa9874
R 1         : 1ff
R 2         : 10aadc
R 3         : 1a9874
R 4         : 11de24
R 5         : 10ab88
R 6         : 10ab11
R 7         : 212
R 8         : 108506
R 9         : 19980198
R10         : 19980218
R11         : ff
R12         : 19980218
R13         : 1a9860
R14         : d157c
PC          : ff1f94d8
CPSR        : 13
  1406:   736.000 [STARTUP] ###exceptionhandlercbr 0xff1f94d8 0
  1407:   737.280 [STARTUP] #####exceptionhandlercbr 0xff1f94d8
  1430:   737.536 [STARTUP] Exception : Time 2017/9/30 13:15:0


adamnock

If you identified FIO_FindFirstEx from the BL call just before the debug message *"[DM] ERROR : FIO_FindFirstEx fail"
at ROM dump position

0xf842435c -> 0xf8424368

Then I would concur that it seems the likely candidate.

DeinGott

ok .. i got the hello world to run, but it does not show anything on the screen .. the last output on the serial:

[DM] FROM Write Complete!!!
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 354
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 314
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 354
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 314
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 354
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 314
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 354
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 314
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 354
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 314
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 354
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 314
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 354
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 314
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 354
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 314
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 354
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 314
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 354
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 314
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 354
HELLO WORLD
firmware signature = 0xCD13B11F
firmware signature = 0xCD13B11F


(i patched it to print to serial, can check that code in as well, but it is only 1300 so not sure if it only clutters the source)

DeinGott

a1ex what stubs do i need to set for the printing (hello worls) how do i find the offsets for the fonts for example? i think there is the problem still. other question does the hello world draw in front of other stuff or do i have to diable the screen somehow? right now it shows the configuration screen. not the menu.

adamnock

Maybe either create a new branch for 1300D-experimental code (regarding your serial patch) or wrap it in a new define check?
CONFIG_QEMU_SERIAL_DEBUG or something?

DeinGott

it is not QEMU special .. but i will make it include it and make it save for the other cameras .. :)

regarding the FONTS .. i found them, but still no output on the screen :/ .. i start to question the memory buffers and stuff .. do you or anyone else have an inside into this? a1ex what do we need to have the output right. The disp_direct.c works in restart.c. Is it possible, that i have to disable the "default" screen first?


DeinGott

so.. i pushed the print_serial. i made it a macro, which will just be nulled, if CONFIG_HAS_PRINT_SERIAL is not set. it will print to serial (even on the real camera it would).

I added some more stubs. But still the gui does not show anything. i think that there is still some things in const.h missing/wrong. will look into this tomorrow.

DeinGott


adamnock

Well Three Cheers for DeinGott!

As I understand it, the next step is to get one of the primary Dev's to generate a boot-flag enabler (the installer?) the then effectively try this on real hardware.

Im a willing test dummy here. Im comfortable with the risk inherent :)

DeinGott

ok .. i first have to fix the malloc call. This still gets an assert triggered. Which should not happen, as i guess. But otherwise this looks prommising..

OK .. narrowed it down to mem.c and the __mem_malloc function .. the problem is, that the memory is somehow not initialized (mem_init). i have to investigate why this is so, but calling the mem_init when the mem_sem is not set, fixed the exception.

adamnock

Could it be timing? I note in QEMU we reach the GUI a good 10-12 seconds before anything else runs. And even vanilla we see a pause then further startup occur just after the GUI presents

DeinGott

that is because the ml_gui_initialized is not called for some reason. this causes a timeout .. (see boot-hack.c function my_init_task at the bottom)

adamnock

Then if im following the startup properly (im pretty raw at this sorry) then given that

ml_gui_initialised
flag is set via function
handle_common_events_startup
in
gui-common.c,
which is called from
handle_buttons
in
gui.c

which is part of the ML gui_main_task, it would follow that said task is either not being started, or is faulting.

Which could be a incorrect stub for the dryos gui_main_task

I might check that out.

adamnock

Or not. I see you're on top of it. #standsback

DeinGott

ok .. one problem was an old RESTARTSTART address.

check on that later. :) one error is gone now :)

DeinGott

ok .. problem might be, hello_world does not overwrite this task :) I will try without the strings attached :)

a1ex

Great progress!

Imported the 1300D branch in the main repo. Also merged a couple of experimental branches: lua_fix (which has the memory init fix and many other backend changes waiting to be tested), qemu (useful for qprintf), 1200D (so you can reuse any tweaks from there) and new-dryos-task-hooks. I expect these to land into mainline before 1300D, so they should not cause any trouble. You should be able to sync with:


hg pull -r 1300D https://bitbucket.org/hudson/magic-lantern


Regarding the latter: there are old-style DryOS task hooks (DIGIC 4 and older DIGIC 5), new-style (6D, 70D, 100D, EOSM2) and there's 1300D (which is clearly not using old-style task hooks, but doesn't work out of the box with the new style ones either) - edit: sorted out! fixed task_dispatch_hook and 1300D is in the same group as the newer D5 models.

You can now see DryOS tasks switching if you compile with CONFIG_QEMU=y and you enable DEBUG_TASK_HOOK in boot-hack.c. Without the latter, only new tasks will be displayed.

Without CONFIG_HELLO_WORLD, it also reacts to the delete button (Av) and attempts to open ML menu :D

In any case, you've now got a bunch of additional debug info to work with, and hopefully a slightly cleaner codebase. GDB symbols too.

a1ex

Please find a (very hackish) patch for QEMU that allows you to log the calls made by ML into Canon firmware:

qemu-log-stubs.patch

Using this patch, I've checked the calls made by ML (with CONFIG_HELLO_WORLD). Full log:  1300D-hello-world.txt

To see only the function calls:

cat 1300D-hello-world.txt | grep "call\|return\| -> 0x"
cat 1300D-hello-world.txt | grep "call\| -> 0x" | grep -o "0x[^(]*" | sort | uniq


This gives the minimal number of stubs required for Hello World, and a small number of stubs for me to double-check before running the first test on the camera.

Memory allocation check (GetMemoryInformation):

Without ML: 0xa30000 0x1df8a4 (total and free)
With ML: 0x9b0000   0x15f898 (ok)
ml_reserved_mem 524288 (ok)
MemSiz 0x6f134 (ok)

Let's try: HELO1300.FIR (md5 265b704a50875e9293cf5a1b00e8fd03)

DeinGott

thx for the fir. i am not home at the weekend. will test it on monday. (if anybody else wants, please post picture :) )

I found some more offsets i had to change :) .. you merged the stuff to the unifi branch? or only pulled the branches into the main repo?

a1ex

Only pulled the branch; you may sync and continue from the current state. If you've already committed any local changes, you can add --rebase to the hg pull command (so you no longer need to merge afterwards).

adamnock





Results from HELO1300.FIR

Looks like it might say out of bound, but im guessing it would make sense to you :)

a1ex

Right - the error handler tripped over a null pointer, so the camera must have locked up (but things were fine on the normal execution path). Updated the FIR with a workaround (#define DISPLAY_IS_ON 0):

HELO1302.FIR (md5 c42c305883eb9f2914096f474233ea8d)

For troubleshooting:

cat 1300D-hello-world.txt | grep FIO


We should wait a little more before enabling the boot flag...

adamnock





Nice. Is the different firmware signature on hardware vs emulation expected?

a1ex

It must be modified by the cache hacks; let's try to disable them after booting (unable to test this one in QEMU):

HELO1303.FIR (md5 656baf799707e574b71d66b4670cd001)

Please upload a screenshot without error and with correct fonts, so I can announce it on Twitter.

adamnock

OK, HELO1303.FIR plus a base compile of ML so we have fonts and other artifacts





GUI stuck around this time. Did reset and try again just in case.
FW Sig changes again but still different from QEMU result (which both DeinGott and I matched on, hopefully ruling out a bad ROM on any side)
Should I be seeing debug/output logs into a file on the SD card?