Author Topic: Canon 80D (Read 522586 times)

a1ex · « **Reply #125 on:** June 12, 2017, 12:08:52 AM »

Quote from: Spakes on June 11, 2017, 06:15:51 AM

What caching issues and babysteps you are talking about?

Answered a few posts above yours.

emklap · « **Reply #126 on:** June 14, 2017, 05:59:47 PM »

, fresh install of Ubuntu 17 (64 BIT), toolchain 4.8.4 and qemu 2.5.0 did the trick

Code: [Select]

./run_canon_fw.sh 80D,firmware=\"boot=1\" -s -S & arm-none-eabi-gdb -x 80D/debugmsg.gdb
gives this display I wanted

ddelreal · « **Reply #127 on:** June 15, 2017, 01:11:44 AM »

Nice!

leonarka · « **Reply #128 on:** June 15, 2017, 08:04:46 PM »

Very much looking forward to 80d can use magic lantern

aSoG_ · « **Reply #129 on:** June 16, 2017, 06:37:51 PM »

Hi, I do not have experience with this programming language.

But is there anything I can do? I have a 80d.

fazorni · « **Reply #130 on:** July 10, 2017, 04:34:11 PM »

any news?

Walter Schulz · « **Reply #131 on:** July 12, 2017, 03:03:29 PM »

Sure!

garry23 · « **Reply #132 on:** July 12, 2017, 06:15:18 PM »

ariznaf · « **Reply #133 on:** July 13, 2017, 11:20:40 AM »

I post just to thank emkap efforts and a1ex support.

As the author of the original post, I am following all your steps.

As I cannot help in this phase of development, I am not posting often here.
I don't want to make the impression that I am trying to put preassure over developers.

Thanks again I hope you could get it working.

a1ex · « **Reply #134 on:** July 14, 2017, 01:48:37 PM »

Just a heads up - QEMU is updated often with DIGIC 6 stuff.

For example, latest update is able to track direct jumps to functions, which are used all over the place in Thumb-2 code.

sombree · « **Reply #135 on:** July 18, 2017, 08:42:23 PM »

I've built autoexec.bin from latest digic6-dumper branch and run it in QEMU: https://hastebin.com/oyitotuyon.hs

I assume this means that our code did actually run:

Code: [Select]

[ init:001cc438 ] task_create(dump, prio=1e, stack=1000, entry=1cc6c0, arg=0)
By the look of minimal.c from unified branch I guess that to print "Hello, World!" in QEMU we need few more stubs (like bmp_vram_info, LCD_Palette) - am I right?

Also I've tried running this:

Code: [Select]

python find_fnt.py ROM1.BIN 0xF0000000but this is the only output I'm getting:

Code: [Select]

Find bitmap fonts in Canon DSLR firmwares
Arm.Indy. based on work by Pel, Trammel Hudson and A1ex

a1ex · « **Reply #136 on:** July 18, 2017, 09:56:31 PM »

The display backend changed significantly on DIGIC 6 - look it up on CHDK. I'm not sure of the pixel format used outside bootloader - first we need to run something on the camera alongside the main firmware (e.g. LED blinking).

Then we need to figure out how to print things on the screen; it will be probably similar to CHDK, but I'm not sure yet.

Only after doing this step we can see whether we need bmp_vram_info and LCD_Palette, or maybe some replacement.

The CanonGothic string is not present in the 80D ROM. No big deal - Canon fonts are not used in many places in our code.

BTW, the pixel format used in the bootloader is 8 BPP, palette-based; the palette is specified as YUV, but the U/V components are unsigned now (they were signed on previous cameras). See QEMU source and disp_direct.c on the recovery branch.

sombree · « **Reply #137 on:** July 18, 2017, 10:34:47 PM »

Ok. Is it possible to test cache-related issues in QEMU? Or is it safe enough to test on real camera?

a1ex · « **Reply #138 on:** July 18, 2017, 11:17:22 PM »

QEMU does not emulate cache behavior, other than a few status registers.

It's probably safe to perform these tests on the camera. However, at this point, you'll need some help from us to sign the binaries you want to run (currently the binaries can be run either as autoexec.bin or as FIR; the former needs a boot flag set in the ROM and the latter must be signed). To my knowledge, CHDK had trouble running the Canon firmware from a firmware update on most (if not all) digic 6 models, so we might have to enable the boot flag from the bootloader context, in order to run autoexec.bin. Traditionally, we enable the boot flag from main firmware, but we did enable it from bootloader on VxWorks models. It's probably best to try on a less expensive D6 model first; if anyone is willing to take the risk, I can prepare a FIR for enabling the boot flag in this way.

Having some other ARMv7 device to test things could be helpful, too.

Walter Schulz · « **Reply #139 on:** July 19, 2017, 12:06:44 AM »

Cheapest option for Digic 6 today (Powershot derivates excluded): 750D, used. Listed at about 415 Euro (Germany).

And - if the offer is still standing - there is a 750D for free: https://www.magiclantern.fm/forum/index.php?topic=17627.msg179772#msg179772

sombree · « **Reply #140 on:** July 19, 2017, 12:20:40 PM »

Are these settings correct? I know thah I have to change base architecture to ARMv7-A&R and uncheck both "delete instruction with no xfrefs" and "perform no-return analysis".

a1ex · « **Reply #141 on:** July 19, 2017, 05:12:16 PM »

No, the ROM dump loads at FE000000 and FC000000. The ROM is mirrored and code runs from both addresses, so you can either define two projects if you have a slow PC like mine, or just one (using the additional binary option in IDA) if you have a fast one like emklap's

FE0A0000 is where you will find the main firmware after loading the ROM. The initialization code starts at FC000008, and the bootloader (LILO-style, prints "BootLoder" on the UART char by char) starts at FE020000. To start the main firmware, the bootloader writes 0 to 0xD20C0084, then jumps to FE0A0000.

There are a few additional blobs copied from ROM to RAM; you can get them from QEMU if you run it with "-d romcpy" (or just look them up in the QEMU test suite log).

sombree · « **Reply #142 on:** July 19, 2017, 05:57:06 PM »

Sorry for these basic questions, but I was basing on info from this post. Anyway, this is how should I load files - am I correct?

a1ex · « **Reply #143 on:** July 19, 2017, 06:17:48 PM »

Looks mostly fine. In the second box, try Loading segment 0, Loading offset 0xFE000000, and (not sure if this is needed with latest versions) number of bytes 0x1FFFFFC.

sombree · « **Reply #144 on:** July 19, 2017, 07:11:33 PM »

Quote from: a1ex on July 19, 2017, 06:17:48 PM

Looks mostly fine. In the second box, try Loading segment 0, Loading offset 0xFE000000, and (not sure if this is needed with latest versions) number of bytes 0x1FFFFFC.

I think I'm close - for example this is what I see when I'm jumping to 0xFE2DB945 (sysmem_info stub):

Code: [Select]

ROM:FC2DB944                 PUSH            {LR}
ROM:FC2DB946                 SUB             SP, SP, #0x2C
ROM:FC2DB948                 ADD             R0, SP, #0x30+var_2C
ROM:FC2DB94A                 BLX             sub_FC3FBC70
ROM:FC2DB94E                 ADR             R0, aSystemMemoryIn ; "System Memory Information\n"
ROM:FC2DB950                 BL              sub_FC483CF0
ROM:FC2DB954                 LDR             R1, [SP,#0x30+var_2C]
ROM:FC2DB956                 ADR             R0, aStartAddress0x ; "  Start Address       = 0x%08lx\n"
ROM:FC2DB958                 BL              sub_FC483CF0
ROM:FC2DB95C                 LDR             R1, [SP,#0x30+var_28]
ROM:FC2DB95E                 ADR             R0, aEndAddress0x08 ; "  End Address         = 0x%08lx\n"
ROM:FC2DB960                 BL              sub_FC483CF0
ROM:FC2DB964                 LDR             R2, [SP,#0x30+var_24]
ROM:FC2DB966                 ADR             R0, aTotalSize0x08x ; "  Total Size          = 0x%08x (%9d)\n"
ROM:FC2DB968                 MOV             R1, R2
ROM:FC2DB96A                 BL              sub_FC483CF0
ROM:FC2DB96E                 LDR             R2, [SP,#0x30+var_20]
ROM:FC2DB970                 ADR             R0, aAllocatedSize0 ; "  Allocated Size      = 0x%08x (%9d)\n"
ROM:FC2DB972                 MOV             R1, R2
ROM:FC2DB974                 BL              sub_FC483CF0
ROM:FC2DB978                 LDR             R2, [SP,#0x30+var_1C]
ROM:FC2DB97A                 ADR             R0, aAllocatedPeak0 ; "  Allocated Peak      = 0x%08x (%9d)\n"
ROM:FC2DB97C                 MOV             R1, R2
ROM:FC2DB97E                 BL              sub_FC483CF0
ROM:FC2DB982                 LDR             R2, [SP,#0x30+var_18]
ROM:FC2DB984                 ADR             R0, aAllocatedCount ; "  Allocated Count     = 0x%08x (%9d)\n"
ROM:FC2DB986                 MOV             R1, R2
ROM:FC2DB988                 BL              sub_FC483CF0
ROM:FC2DB98C                 LDR             R2, [SP,#0x30+var_14]
ROM:FC2DB98E                 ADR             R0, aFreeSize0x08x9 ; "  Free Size           = 0x%08x (%9d)\n"
ROM:FC2DB990                 MOV             R1, R2
ROM:FC2DB992                 BL              sub_FC483CF0
ROM:FC2DB996                 LDR             R2, [SP,#0x30+var_10]
ROM:FC2DB998                 ADR             R0, aFreeBlockMaxSi ; "  Free Block Max Size = 0x%08x (%9d)\n"
ROM:FC2DB99A                 MOV             R1, R2
ROM:FC2DB99C                 BL              sub_FC483CF0
ROM:FC2DB9A0                 LDR             R2, [SP,#0x30+var_C]
ROM:FC2DB9A2                 ADR             R0, aFreeBlockCount ; "  Free Block Count    = 0x%08x (%9d)\n"

Though after loading additional binary file as you advised I'm getting this:

Code: [Select]

seg001:FE2DB945                 DCB 0xB5 ; Á
seg001:FE2DB946                 DCB 0x8B ; ő
seg001:FE2DB947                 DCB 0xB0 ; -
seg001:FE2DB948                 DCB    1
seg001:FE2DB949                 DCB 0xA8 ; Ę
seg001:FE2DB94A                 DCB 0x20
seg001:FE2DB94B                 DCB 0xF1 ; ˝
seg001:FE2DB94C                 DCB 0x92 ; ĺ
seg001:FE2DB94D                 DCB 0xE9 ; Ú
seg001:FE2DB94E                 DCB 0xB6 ; Â
seg001:FE2DB94F                 DCB 0xA0 ; á
seg001:FE2DB950                 DCB 0xA8 ; Ę
seg001:FE2DB951                 DCB 0xF1 ; ˝
seg001:FE2DB952                 DCB 0xCE ; +
seg001:FE2DB953                 DCB 0xF9 ; ¨
seg001:FE2DB954                 DCB    1
seg001:FE2DB955                 DCB 0x99 ; Ö
seg001:FE2DB956                 DCB 0x5C ; \
seg001:FE2DB957                 DCB 0xA0 ; á
seg001:FE2DB958                 DCB 0xA8 ; Ę
seg001:FE2DB959                 DCB 0xF1 ; ˝
seg001:FE2DB95A                 DCB 0xCA ; ¦
seg001:FE2DB95B                 DCB 0xF9 ; ¨
seg001:FE2DB95C                 DCB    2
seg001:FE2DB95D                 DCB 0x99 ; Ö
seg001:FE2DB95E                 DCB 0x63 ; c
seg001:FE2DB95F                 DCB 0xA0 ; á
seg001:FE2DB960                 DCB 0xA8 ; Ę
seg001:FE2DB961                 DCB 0xF1 ; ˝
seg001:FE2DB962                 DCB 0xC6 ; Ă
seg001:FE2DB963                 DCB 0xF9 ; ¨

I suppose it's because it wasn't analyzed though I'm not sure why.

Edit:
Oh, I didn't know that I can simply select huge chunk of code (like from 0xFE000000 to almost the end) and analyse it xD

BobMiles · « **Reply #145 on:** July 23, 2017, 01:12:59 PM »

Hi guys,

new here, too! Just ordered a 80d and i'll be happy to help wherever I can.

I have some programming knowledge but mainly perl... I'll try and get myself up to speed and in the meantime follow your progress!

Thank you for the support!!!

a1ex · « **Reply #146 on:** September 03, 2017, 09:58:32 PM »

Quote from: a1ex on July 18, 2017, 11:17:22 PM

Traditionally, we enable the boot flag from main firmware, but we did enable it from bootloader on VxWorks models. It's probably best to try on a less expensive D6 model first [...]

Last night, after a couple of hours of reversing, we (g3gg0 and I) ended up trying on a more expensive D6 model first - it worked on the first try

As we did not have a ROM dump for that model (5DS), the boot flag enabling code was written to be portable (so it could work on an unknown model, likely similar to what we knew). Before running this code on 5DS, we have tested it in QEMU on 80D, 760D and 750D, and also visually checked it for 7D2 - where we only have an incomplete ROM dump (blinked, but with errors).

In other words, we are ready to enable the boot flag on the above DIGIC 6 models

~~BOOTD80D.FIR~~ (display issue?)
BOOTE80D.FIR

The above will run in dummy mode; it will only print what it's going to do. If the screenshot looks alright, I'll upload a FIR that will modify your camera.

Source: recovery branch (with the set_bootflag call commented out).

sombree · « **Reply #147 on:** September 04, 2017, 01:47:19 AM »

I've just tried this FIR file on real camera with 1.0.2 firmware - LCD just turns blue and nothing else happens

a1ex · « **Reply #148 on:** September 04, 2017, 07:54:01 AM »

Does the previous FIR from this thread (the ROM dumper) work for you? There is a color palette issue (it won't show the same color every time - probably the same caching issue described earlier).

I've compared both FIRs in QEMU - their I/O activity - prior to writing files to the card - is almost identical, with a minor difference - the color palette had the uncacheable memory flag in the ROM dumper. Here's a FIR without this diffference:

BOOTE80D.FIR

sombree · « **Reply #149 on:** September 04, 2017, 10:09:38 AM »

Yes, ROM dumper works fine. This second FIR file (BOOTE80D.FIR) also works:

News:

Author Topic: Canon 80D (Read 522586 times)