Author Topic: Canon EOS 1300D / Rebel T6  (Read 127364 times)

denizza

  • New to the forum
  • *
  • Posts: 6
Re: Canon EOS 1300D / Rebel T6
« Reply #375 on: June 05, 2020, 03:14:58 PM »
yea

Walter Schulz

  • Contributor
  • Hero Member
  • *****
  • Posts: 7299
Photogs and videographers: Assist in proof reading upcoming in-camera help!. Your input is wanted and needed!

Chris Thomas

  • Just arrived
  • *
  • Posts: 1
Re: Canon EOS 1300D / Rebel T6
« Reply #377 on: June 07, 2020, 04:06:37 AM »
Hey!
I own the 1300D and I really want to get hold of this firmware for a few upcoming projects. I have almost no idea about what's going on here and I don't think I could be of much help, but I wanna know if it's usable on the canon 1300d yet and if someone could point me in the right direction.

Thanks in advance

heder

  • Contributor
  • Member
  • *****
  • Posts: 101
  • No time for caution
Re: Canon EOS 1300D / Rebel T6
« Reply #378 on: June 11, 2020, 02:38:37 PM »
Brief update.

I promised somewere around april to look into the patch_instruction / cache_fake issue, but was delayed because I could'nt get the 40D raw module running correctly, and after critix reminded my a few times, I have started to look in this issue.

It possible to solve the general patch instruction issue for 1300D, but the problem is more general and the optimal solution is if we can get a solution that works for all cameras. I guess that is why the more simple cache_fake evolved into the patch_manager. Different cpu requires different tricks and hack to cope with our demands.

The issue that is annoying us is that normally we could change one single jump instruction into a new jumping instruction that could end up in our code, but due to the 32MB ROM layout that is not longer possible. Hijacking a complete function works fine with a1ex double patch instruction because when we hijack the complete function we have multiple instruction that we can change, but the problem is when we change a single instruction inside a function into a jump, or hijacking a jump inside a function to jump somewere else, when we fail because we can only jump +/- 32MB.

There are around two major solution to this problem, hard ones and perhaps a easy one. The hard one will allow us to use two instruction patch and thereby overwriting one additional instruction, and to avoid a crash, we would have to jump to a hook function then call the new funtion and afterward take into account (recode) the overwritten instruction. If we were hijacking a complete function fixup (recoding) would not be nessesary. Coding this => not me.

The easy solution is jumping multiple jumps, works fine, tested it. Each jump can to +/- 32MB, so two jumps and we're +/-64MB, then 1300D will work out just fine, should also work just fine with all other cameras. This one however requires that we can allocate a small ammount of memory (to store the 2nd jump instruction) within +/-32MB from ROM layout. I tried to use the ITCM area on the 500D (1300d branch) but that was a failure, because the 500D seems to uses that area, so other cameras may fail aswell. But looking at the memory layout it seems like 1300D malloc's has it first avilable memory is 0xBF408, see Reply #251. The ROM layout starts at 0xFE0C0000, which means we can jump anywere from ROM and below 0xC0000 (garanteed), and that solves the issue. Solution is to reserve a few bytes from 0xBF408 and use that as 2nd jumping table. Just need to code that.

Any comments, idea suggestions, yes, please.   
Embedded SW engineer. Current Cameras: Canon 20d, 40d, 350d

critix

  • Contributor
  • Member
  • *****
  • Posts: 149
Re: Canon EOS 1300D / Rebel T6
« Reply #379 on: June 11, 2020, 07:26:17 PM »
Congratulations. I hope you succeed
with the code.
Canon 1300D, 500D, EOS M, EOS M2

Alsenor de Paula

  • Just arrived
  • *
  • Posts: 1
Re: Canon EOS 1300D / Rebel T6
« Reply #380 on: June 17, 2020, 05:53:49 PM »
ML is not running on 1300D yet.
Boa tarde amigos!
Enquanto não sai o ML para a 1300D tem alguma forma de deixar a HDMI limpa neste equipamento?

heder

  • Contributor
  • Member
  • *****
  • Posts: 101
  • No time for caution
Re: Canon EOS 1300D / Rebel T6
« Reply #381 on: June 19, 2020, 09:15:11 AM »
Breif update.

I have been coding a new patch_instruction_jump function specific for jumps, (jump above +/- 32 MB address range) that uses multiple jumps.  It's not complete yet, but now its holiday :) so I'm off programming the next two weeks. Still need to allocate memory correctly and I also have some troubles making my second jump into a absolute jump, LDR PC, [PC,offset] crashes for some unknown reasons. These tests does not jump above 32 MB, but so far only verifies that multiple jumps are working as intended.

Here is a output from my lastest test in QEMU (500D.111):


Code: [Select]
============================================
======== Memory before patching      =======
============================================
failure_stubs1 addr 4da4c (e92d4008)
failure_stubs2 addr 4da30 (e92d4008)
failure_stubs3 addr 4da14 (e92d4008)
failure_stubs4 addr 4d9f8 (e92d4008)
failure_stubs5 addr 4d9e0 (e92d4008)
failure_stubs6 addr 4d9c8 (e92d4008)
success_stubs  addr 4d9b0 (e92d4008)
============================================
= Testing cache_fake (QEMU ROM patching)   =
============================================
* calling failure_stub1, return value expected (1000) actual = 1000
* calling success_stub , return value expected (1) actual = 1
* patching (re-route failure stub to success stub)
* calling failure_stub1, return value expected (1) actual = 1
* Test was a success

============================================
= Testing MEM(data) (QEMU ROM patching)    =
============================================
* calling failure_stub2, return value expected (1001) actual = 1001
* calling success_stub , return value expected (1) actual = 1
* patching (re-route failure stub to success stub)
* calling failure_stub2, return value expected (1) actual = 1
* Test was a success

============================================
= Simple double jump (relative) hardcoded  =
============================================
* calling failure_stub3, return value expected (1002) actual = 1002
* calling success_stub , return value expected (1) actual = 1
* patching (re-route failure stub to success stub)
* calling failure_stub3, return value expected (1) actual = 1
* Test was a success

============================================
= Simple double jump:                      =
= patch_instruction + MEM(data) patch      =
============================================
* calling failure_stub4, return value expected (1003) actual = 1003
* calling success_stub , return value expected (1) actual = 1
* patching (re-route failure stub to success stub)
* calling failure_stub4, return value expected (1) actual = 1
* Test was a success

============================================
= patch_instruction_jump (double rel jump) =
============================================
* calling failure_stub5, return value expected (1004) actual = 1004
* calling success_stub , return value expected (1) actual = 1
* using jump_vector 0 (address 9895e4)
* patching (re-route failure stub to success stub)
* calling failure_stub5, return value expected (1) actual = 1
* Test was a success

============================================
= patch_instruction_jump (single rel jump) =
============================================
* calling failure_stub6, return value expected (1005) actual = 1004
* calling success_stub , return value expected (1) actual = 1
* patching (re-route failure stub to success stub)
* calling failure_stub6, return value expected (1) actual = 1
* Test was a success

============================================
= patch_instruction_jump (double abs jump) =
= This test is missing                     =
============================================

============================================
= malloc versus stack versus static        =
= This test is missing                     =
============================================

============================================
======== Memory after patching       =======
============================================

failure_stubs1 addr 4da4c (eaffffd7)
failure_stubs2 addr 4da30 (eaffffde)
failure_stubs3 addr 4da14 (ea01ea43)
failure_stubs4 addr 4d9f8 (ea01ea4a)
failure_stubs5 addr 4d9e0 (ea24eeff)
failure_stubs6 addr 4d9c8 (eafffff8)
success_stubs  addr 4d9b0 (e92d4008)

============================================
============ Done ==========================
============================================
Embedded SW engineer. Current Cameras: Canon 20d, 40d, 350d

cbbrowne

  • New to the forum
  • *
  • Posts: 6
Re: Canon EOS 1300D / Rebel T6
« Reply #382 on: July 08, 2020, 08:49:31 PM »
Brief update.
(Lots elided!)

Solution is to reserve a few bytes from 0xBF408 and use that as 2nd jumping table. Just need to code that.

I must say, that was NOT a "brief" update  :)

I'm very pleased to see that an understanding of the nature of the problem has emerged, as well as the general shape of a solution.  Oh, my, jump tables  :) :) :)

It is especially pleasing that this seems likely to help other cameras too.