Canon 6D

[blubbblubb]

So i had some time to look into the headphone stuff again and it was just the missing stub. After seeing that the stub address for SoundDevActiveIn and sounddev_active_in can be the same, as done for the 650D i just did the same.

I opened a pull request: https://bitbucket.org/hudson/magic-lantern/pull-requests/911/enabled-headphone-monitoring-for-the-6d/

Which is probably not up to the magiclantern standard at the moment (Im guessing the problems with toggling the option before attaching the cable and taking pictures would need to be adressed first)

Due to my limited knowledge of magic lantern/c/assembler right now im not able to further improve this (I'll have to look into some more documentation and try to learn more about it)
Any ideas/hints as well as other contributors/tester would be appreciated.

[a1ex]

Im guessing the problems with toggling the option before attaching the cable and taking pictures would need to be adressed first

... I didn't even know about their existence; will try to reproduce in QEMU.

[DireHavok]

I am running latest nightly 1.1.6, not sure if anyone else has experienced this. But unable to get overlays to work properly, specifically histogram. When not in liveview entering ML it shows histogram is on and overlay is set to on in all modes. But when in liveview and scroll through display using info button no histogram. I have done everything but re install ML which will be done tonight. At a loss til reload. Any ideas?

[blubbblubb]

Did reinstalling fix your issue?

All overlays work fine for me with the latest nightly.

[dfort]

Anyone able to get a 6D.118 firmware dump please PM me. Thanks!

[blubbblubb]

are there any tricks to using the portable rom dumper?

I tried it multiple times with 2 different freshly formatted SD cards and only the checksum for ROM0B.BIN stays the same

Also im not able to copy the files using Linux from the SD Card, it always shows:

Code: [Select]

Error when getting information for file “/run/media/EOS_DEVELOP/¬¬uu¬¬uu.QUU”: Input/output error.
Windows seems to read them fine, but shows wrong information about the available space on the SD Card

[Walter Schulz]

Try old-fashioned SD-card, not SDHC, SDXC. 512MByte/1GByte should be fine.

[dfort]

@blubbblubb - If you are having too many problems with the Portable Dumper try the Blind Dumper.

[blubbblubb]

Ok, so i tried the portable dumper on 2 256MB cards, where either nothing happens or the process freezes, i then tried a 1GB card which seems to complete the dump but the checksums for the ROM1*.bin do not match. (But i can still read the card from linux)

I then moved to the blind dumper, which if i understand correctly is used by entering the Play mode.
This creates a 16,8MB file called "(NULL)" which also has different checksums for each dump.

Im not sure if im doing something wrong or if the dumpers do not work with this firmware/camera

I tried formatting the cards throug linux and the camera and made them bootable via the "make_bootable.sh" script.

Edit: just sent you the dumps, i hope at least one of them works

[dfort]

First one I tried:



Thanks! I'll post 6D.116 -> 6D.118 updates on this topic.

[Danne]

Really cool dfort. I'll post you the 1100D dump tomorrow.

[dfort]

Just a progress report on the 6D.118 firmware update. We're leap frogging over the 1.1.7 update so there are more changes on this one than the other recent firmware updates I worked on. In addition, building a simple minimal autoexec.bin didn't work with the 6D. ML isn't working with 1.1.8 yet but I thought I'd check the accuracy of the firmware signature printout because other cameras were showing the wrong signature.

The signature for 1.1.6 is:

Code: [Select]

#define SIG_6D_116   0x11cb1ed2
But this is what "Hello World" printed:



In addition, the QEMU debugmsg.gdb should be updated:

Code: [Select]

# ./run_canon_fw.sh 6D -d debugmsg
# ./run_canon_fw.sh 6D -d debugmsg -s -S & arm-none-eabi-gdb -x 6D/debugmsg.gdb

source -v debug-logging.gdb

# To get debugging symbols from Magic Lantern, uncomment one of these:
#symbol-file ../magic-lantern/platform/6D.118/magiclantern
#symbol-file ../magic-lantern/platform/6D.118/autoexec
#symbol-file ../magic-lantern/platform/6D.118/stubs.o

macro define CURRENT_TASK 0x74C28
macro define CURRENT_ISR  (MEM(0x648) ? MEM(0x64C) >> 2 : 0)

# GDB hook is very slow; -d debugmsg is much faster
# ./run_canon_fw.sh will use this address, don't delete it
# b *0x67c8
# DebugMsg_log

b *0x973c
task_create_log

b *0x8FE4
register_interrupt_log

# properties
if 0
  b *0xff12fd64
  prop_request_change_log

  b *0xff30fbb4
  mpu_analyze_recv_data_log

  b *0xff30d2c0
  prop_lookup_maybe_log

  b *0xff315e58
  mpu_prop_lookup_log
end

cont


[dfort]

Just a lack of progress report on the 1.1.6 to 1.1.8 firmware update.

6D.116 in QEMU:

Code: [Select]

[BOOT] reserved 605952 bytes for ML (used 531520)
K302 READY
[SF] InstallSerialFlash 4 0xc022002c 0x0 0x800000 1

[SF] GPIO Base 0xc022002c 0xc022002c
[        init:ff149bfc ] (00:01) [SF] SetCSSerialFlash : 0xc022002c 0x46
[        init:ff146a58 ] (00:01) [PM] DisablePowerSave (Counter = 1)
[        init:ff0c32b0 ] (8b:16)
                K302 ICU Firmware Version 1.1.6 ( 5.8.4 )
[        init:ff0c32c4 ] (8b:05)
                ICU Release DateTime 2014.10.23 17:38:50
[        init:ff0fc404 ] (00:03) [SEQ] CreateSequencer (Startup, Num = 6)
[        init:ff0fc658 ] (00:02) [SEQ] NotifyComplete (Startup, Flag = 0x10000)
[        init:ff0fc6bc ] (00:03) [SEQ] NotifyComplete (Cur = 0, 0x10000, Flag = 0x10000)
[BOOT] 113B84 now contains 0, restoring 0.
...
6D.118 in QEMU

Code: [Select]

[BOOT] reserved 605952 bytes for ML (used 531520)
K302 READY
[SF] InstallSerialFlash 4 0xc022002c 0x0 0x800000 1

[SF] GPIO Base 0xc022002c 0xc022002c
[BOOT] 113B84 now contains BAAABAAA, restoring 0.
Any clues what stub, constant, whatever, I've got wrong that is causing this bug -- err, sheep?

[EDIT] Well I did find where this message is being generated.

src/boot-hack.c

Code: [Select]

#ifdef ARMLIB_OVERFLOWING_BUFFER
    // Restore the overwritten value.
    // Refuse to boot if ARMLIB_OVERFLOWING_BUFFER is incorrect.
    qprintf("[BOOT] %X now contains %X, restoring %X.\n", backup_address, *backup_address, backup_data);
    while (backup_address == 0);
    while (*backup_address == 0xbaaabaaa);
    *backup_address = backup_data;
#endif

[EDIT 2] Got past that sticking point but QEMU is telling me to give up for now. Will try again later:

Code: [Select]

[****] Starting task 44c8f4(0) ml_init
[BKT] giving up.
[****] Starting task 44c6f8(0) ml_backup
[****] Starting task 4549f0(0) menu_task
[****] Starting task 456bcc(0) menu_redraw_task
[****] Starting task 46bd4c(0) focus_task
[****] Starting task 46d050(0) notifybox_task
[****] Starting task 46fbb8(0) fps_task
[****] Starting task 4777b0(0) shoot_task
[****] Starting task 47093c(0) clock_task
[****] Starting task 47e768(0) audio_common_task
[****] Starting task 486420(0) livev_hiprio_task
[****] Starting task 484c58(0) cls_task
[****] Starting task 490c5c(0) console_task
[****] Starting task 458d7c(0) debug_task
[****] Starting task 4614f4(0) tweak_task
[****] Starting task 46cb3c(0) focus_misc_task
[****] Starting task 479afc(0) vignetting_init
[****] Starting task 496344(0) module_task
[****] Starting task 485d94(0) livev_loprio_task
[BKT] giving up.
[BKT] giving up.
[BKT] giving up.
[BKT] giving up.
[BKT] giving up.
[BKT] giving up.
[BKT] giving up.
[BKT] giving up.
[BKT] giving up.
[BKT] giving up.
...

[a1ex]

Let's find the sheep (edit: nevermind, you have already found it):

Code: [Select]

cd src
grep -nri BAAABAAA -C 3

That "giving up" message comes from the stack trace; likely an assert triggered somewhere.

Besides that, DebugMsg was not updated in the GDB script (that's why it doesn't print debug messages).

Minimal autoexec seems to work fine here (only on new-dryos-task-hooks). It prints Hello World with 1.1.6, but only blinks the LED with 1.1.8.

[dfort]

...DebugMsg was not updated in the GDB script...

Here we go:
https://bitbucket.org/daniel_fort/magic-lantern/pull-requests/20/fake-pull-request-to-see-changed-needed/diff#chg-contrib/qemu/scripts/6D/debugmsg.gdb

I made this "fake" pull request in order to easily see all the changes. Bitbucket seemed to have a mind of its own and the first attempt went to the hudson repository--sorry about that!

Not sure if I'm doing this properly but I build my QEMU environment from the qemu branch then switch over to another branch to work out the changes needed to update the firmware. I normally get all the way through on the unified branch then update other branches as needed after it is working in QEMU but on this one I switched to new-dryos-task-hooks because unified wasn't showing enough debugging messages. I tried the copy_back_to_contrib.sh script but it updated everything except the 6D/debugmsg.gdb file so I copied it manually from my qemu-eos environment.

In any case--

Minimal autoexec seems to work fine here (only on new-dryos-task-hooks)...but only blinks the LED with 1.1.8.

Got it blinking here too--Yay!

The 6D.118 firmware update fixes the same issues as the 5D3.135 update:

1.  Fixes a phenomenon in which standard exposure may not be obtained, or an irregular exposure may result, when Silent LV (Live View) shooting with the following TS-E lenses: TS-E 50mm f/2.8L MACRO, TS-E 90mm f/2.8L MACRO, or TS-E 135mm f/4L MACRO.

That doesn't seem like a big update but it did move lots of addresses that the recent firmware updates didn't touch on the other cameras. In addition, we're leap frogging over the 6D.117 update:

(Previous) Version 1.1.7 improvements:
Corrects a phenomenon in which when using the camera with the EF 70-300mm f/4-5.6 IS II USM lens, even if lens aberration correction is set to "Enable", correction will not be applied.

So this firmware update along with the 5D3.135 update are more challenging. However, we'll get there, eventually -- maybe. That's encouraging!

[dfort]

Continuing on the 6D.118 testing, I'm still getting a bunch of these messages in QEMU:

Code: [Select]

[BKT] giving up.
[BKT] giving up.
[BKT] giving up.
[BKT] giving up.
[BKT] giving up.
[BKT] giving up.
[BKT] giving up.
[BKT] giving up.
...

Searching the forum turns up only "never giving up" so -- ok, let's keep going.

Minimal autoexec.bin led flashing is fine but no "Hello World" and a full build saves these assert logs:

Code: [Select]

ML ASSERT:
streq(stateobj->type, "StateObject")
at ../../src/state-object.c:251 (stateobj_start_spy), task ml_init
lv:0 mode:3

ml_init stack: 1e3368 [1e33c8-1df3c8]
0xUNKNOWN  @ 44c944:1e33a8
0x0047A838 @ 47a8c8:1e33a0
0x0044CA54 @ 47a864:1e3398
0x0044C478 @ 44cab0:1e3368

I see where they are being generated but having a hard time trying to trace back to figure out what is blocking ml_init. Pretty sure I've got a few stubs or constants wrong but which ones?

Another issue I noticed is that the QEMU debug messages aren't always labeled:

Code: [Select]

[MPU] Received: 08 06 00 00 02 0e 00 00  (Complete WaitID = 0x80000001 Mode group - spell #2)
[            :ff14107c ] (00:07) [RTC] ChangePropertyCBR 0x0, 0x0
[     PropMgr:ff149eb0 ] register_interrupt(null, 0x34, 0xff149d04, 0x1)
[     Startup:ff149eb0 ] register_interrupt(null, 0x34, 0xff149d04, 0x1)
[RTC] RTC_Permit 0x20[            :ff14d6c8 ] (00:03) [SND] Seq LPC 5-0
[            :ff14d6f8 ] (00:03) [SND]  HARB_ARBMODE  Before:00000000 Current:00000000
[            :ff14d730 ] (00:03) [SND]  HARB_HARBCTRL Before:00000000 Current:00000000
[            :ff14d740 ] (00:03) [SND] Seq LPC 5-1
[            :ff14d768 ] (00:03) [SND] Seq LPC 5-2
[            :ff14d78c ] (00:03) [SND] Seq LPC 5-3
[     Startup:ff14d7a0 ] register_interrupt(SEQ, 0x9c, 0xff14d648, 0x0)

On the 6D.116 these are all labeled.

[dfort]

Another 6D.118 progress report.

Merged some of the experimental branches, tweaked some more constants and the "giving up" messages are gone so let's not give up! ML goes through the start up process and backs up the firmware. That's the good news, the bad news is that there is still something that I haven't been able to track down that is keeping ML from writing to the LCD and there's this scary looking crash log:

Code: [Select]

[65798245] tweak_task: NULL PTR (c0f14408,e1a00000)
pc=    ed1c lr=  4b2da0 stack=1f13e8+0x1000
entry=461b00(0)
e1a00000 e59ff014 e59ff014 e59ff014
e59ff014 e1a00000 e59ff010 e59ff010

Magic Lantern version : Nightly.2018May01.6D118
Mercurial changeset   : a94c0e275871+ (new-dryos-task-hooks_6D.118)
Built on 2018-05-01 13:10:29 UTC by [email protected]
Free Memory  : 384K + 2518K
It is also saving some assert logs which are pointing to a problem with the bitmap video ram start address:

Code: [Select]

ML ASSERT:
0
at ../../src/bmp.c:69 (BMP_VRAM_START), task console_task
lv:0 mode:3

console_task stack: 20c318 [20c448-20b448]
0x0045B7C0 @ 46a118:20c358
0x0045B6D0 @ 45b78c:20c350
0x0044C9F4 @ 45b760:20c348
0x0044C478 @ 44ca50:20c318

Magic Lantern version : Nightly.2018May01.6D118
Mercurial changeset   : a94c0e275871+ (new-dryos-task-hooks_6D.118)
Built on 2018-05-01 13:10:29 UTC by [email protected]
Free Memory  : 384K + 2518K

At the moment I'm lost trying to figure out what to look for in stubs.S, consts.h or to resolve this issue.

[dfort]

Hello 6D.118!



Looks like it is working quite nicely--in QEMU.



The problem stubs were LCD_Palette and bmp_vram_info. Don't know how I missed these before because the comments in the code were pretty obvious.

Test build on my downloads page. I merged several branches including new-dryos-task-hooks, qemu and lua_fix while I was working on this so you should be able to run the selftest module along with the lua tests with this test build. This is a very early build so no ML-SETUP.FIR yet. Make sure your camera and cards have their bootflags set.

[dfort]

I'm copying the changes made on the 6D mega merge branch back into unified and got this "interesting" error message worth sharing:

Code: [Select]

DRYOS PANIC: Module Code = 1, Panic Code = 5


I don't share all of my failures but this one is a good argument for using QEMU even if you have the camera in your hands.

[dfort]

Problem was HIJACK_TASK_ADDR, which isn't used in the experimental branches I was using.

Looks good in QEMU and I even ran the memory benchmark.



Pull request submitted and test build posted on my downloads page.

Looking for testers to try out the "Nightly" build and see if it works the same as the 6D.116 from the official downloads page. Then run the selftest module and lua module API stubs tests and report back.

Note that this is an early test build so no ML-SETUP.FIR yet. You'll have to make sure ML is installed and running before doing the firmware update so the bootflags on both camera and card are set. I put a "6D Canon Firmware for Testers" package on my downloads page so you don't have to go searching for the Canon firmware updaters.

[dfort]

Ok--something that doesn't have to do with the firmware update. There's a report of an error message coming up on the 6D on the 10bit/12bit branch and possibly the crop_rec_4k branch. Can someone with a 6D confirm this?

https://www.magiclantern.fm/forum/index.php?topic=5601.msg200990#msg200990

[blubbblubb]

i tried the 10/12 Bit branch and posted in the other topic.

Regarding the 1.18 Update, i assume it is considered "safe" to try it now? I'll try to test it in the next week or so, not sure if i have a chance before

[dfort]

Depends on how "safe" you believe an experimental build of an untested firmware update is. The QEMU tests look good but it hasn't been tried on real hardware yet. It doesn't have a ML-SETUP.FIR so make sure your card and camera bootflags are set (don't uninstall ML before doing the firmware update). The only problem we had so far was a case where the camera bootflag was not set and the battery "jumped" out in the middle of running the firmware update.

Check some of the other camera specific topics to see what tests we're running and how it is going. Generally, the firmware updates have been going quite nicely and we're even resolving some long standing issues.

[Nathanael]

Hi,

my 6D (from Simply Electronics) has this firmware: 5.7.4 78 (1f)

I do not know why but it is not official Canon Firmware. Do you know how can i flash an official firmware?

Now, i do not know if i can flash Magic Lantern on it.

Moreover, all functions with EOS Utility on my computer can not be used because the camera is not known :/


Thank you

[ArcziPL]

It seems that your camera is in factory mode. If you browse the menus, do you see a position "Factory Menu?". If you bought it that way new or was repairing at Canon service recently, they have screwed it up, not switching the camera to a normal mode and should do it on request...