40D Firmware assembly

[rufustfirefly]

I've been trying to build the .FIR file loader for a 40D running v1.1.1 (in-line with the version required in the Mercurial repository). I had followed the instructions on http://magiclantern.wikia.com/wiki/Packing_FIR_Files and had done the following to build a firmware loader:

• Compile an autoexec.bin file for the 40D.
  make 40D
  • Download a copy of the firmware for the 40D (v1.1.1) from Canon's website, and extract the original .FIR file from the archive
  • Compiled and run dissect_fw3 to extract the pieces of the loader.
    ./dissect_fw3 40d00111.fir 40D 40D
  • Attempt to assemble using assemble_fw.
    ./assemble_fw --header 40D_0_header.bin --flasher 40D_1_flasher.bin --user autoexec.bin --id 0x80000190 --output 40d00111-ML.fir
  • Copy the new firmware and ML files from the distribution to a CF card.
  
  Flashing this gives me working nav controls, but a blank LCD screen, even when pressing "play", "del", or "menu". Is this a deficit in my FIR file construction, or a ML issue?
  
  (I'd actually be perfectly fine with trying to compile a "bootflag" firmware update, so that I don't necessarily have to reassemble a FIR file every time I want to update from the Mercurial repository.)

[jplxpto]

I've been trying to build the .FIR file loader for a 40D running v1.1.1 (in-line with the version required in the Mercurial repository). I had followed the instructions on http://magiclantern.wikia.com/wiki/Packing_FIR_Files and had done the following to build a firmware loader:

• Compile an autoexec.bin file for the 40D.
  make 40D
  • Download a copy of the firmware for the 40D (v1.1.1) from Canon's website, and extract the original .FIR file from the archive
  • Compiled and run dissect_fw3 to extract the pieces of the loader.
    ./dissect_fw3 40d00111.fir 40D 40D
  • Attempt to assemble using assemble_fw.
    ./assemble_fw --header 40D_0_header.bin --flasher 40D_1_flasher.bin --user autoexec.bin --id 0x80000190 --output 40d00111-ML.fir
  • Copy the new firmware and ML files from the distribution to a CF card.
  
  Flashing this gives me working nav controls, but a blank LCD screen, even when pressing "play", "del", or "menu". Is this a deficit in my FIR file construction, or a ML issue?
  
  (I'd actually be perfectly fine with trying to compile a "bootflag" firmware update, so that I don't necessarily have to reassemble a FIR file every time I want to update from the Mercurial repository.)
  

I think that you need my help...

If I have time in the next week-end I do a dump for you.
I need to review my source code and add some additional validations.
I started by performing these steps ... is doing one year

Why --id 0x80000190  [/list]

[rufustfirefly]

I think that you need my help...

If I have time in the next week-end I do a dump for you.
I need to review my source code and add some additional validations.
I started by performing these steps ... is doing one year

Why --id 0x80000190 

The original camera id in the assemble_fw script was "0x80000254", which maps to the 1000D camera body. Using fir_tool2.py, I got:

Code: [Select]

$ ./fir_tool2.py 40d00111.fir
Fir_tool 0.5 (20Mar2010)

fileLen = 0x7d06fc
---.fir header---
0x000: modelId = 0x80000190, (40D, VxWorks)
0x010: version = 1.1.1
0x020: checksum = 0xc1be4dd8
0x024: updater1 header = 0xb0
0x028: updater1 offset = 0x120
0x02c: updater2 offset = 0xffffffff
0x030: firmware offset = 0x19dc80
0x034: 0xffffffff
0x038: embedded file size = 0x7d06fc
0x03c: 0x0
0x040: sha1 seed = 0x9b1bf2fb
0x044: 0x00000004 0x00000000 0x00000020 0x00000024 0x00000044 0x000000b0 0x0019dbd0
0x060: 0x19dc80
0x064: firmware length = 0x632a7c
0x068: updater1 hmac-sha1 = 5edae41600de8549c060cc69ed85b38579abf5fe
0x088: firmware hmac-sha1 = 1ddd1f063c617b0109ec10914ce75c900bbf8461
---updater1 header---
0x0b0: updater1 length = 0x19db60. starts at 0x120
0x0b4: 0x19db60
0x0b8: 0x0
0x0bc: xor seed value = 0xee742c27
0x120: --- updater1 (ciphered) ---
---firmware header---
0x19dc80: (+0x000), offset to decryption data = 0xc
0x19dc84: (+0x004), offset to encrypted data = 0x7c. starts at 0x19dc80
0x19dc88: (+0x008), total firmware length (including header) = 0x632a7c. starts at 0x19dc80
-
0x19dc8c: (+0x00c), firmware length (encrypted part) = 0x632a00. starts at 0x19dcfc
0x19dc90: (+0x010), 0x006329f4
0x19dc94: (+0x014), 0x0
0x19dc98: (+0x018), 0x80ad7597
0x19dc9c: (+0x01c), 4860ffc49830f18619a4f1e289bc6248
0x19dcac: (+0x02c), d9856011172a94389484254df3ae7401f26b4fafff2f3140da923a63ae43ed49
0x19dccc: (+0x04c), c47d161d7498f24e6be84357b477f403
0x19dcdc: (+0x05c), f93377c9d24622a4e931aa3c675938603d67befa43b33d55d4e6f7942a2adf58
---firmware (encrypted)---
0x19dcfc: (+0x07c)
This produced 0x000: modelId = 0x80000190, (40D, VxWorks) from the header, which I used to identify the camera.

[rufustfirefly]

Also, somehow in the last day, 40D builds broke.

Code: [Select]

[ LD       ]   magiclantern
dietlibc.a(vsscanf.o): In function `vsscanf':
vsscanf.c:(.text+0x5c): warning: warning: the scanf functions add several kilobytes of bloat.
dietlibc.a(sprintf.o): In function `sprintf':
sprintf.c:(.text+0x14): warning: warning: Avoid *sprintf; use *snprintf. It is more secure.
stdio.o: In function `FIO_CreateFileOrAppend':
stdio.c:(.text+0x35c): undefined reference to `FIO_SeekFile'
collect2: error: ld returned 1 exit status
make[1]: *** [magiclantern] Error 1

The odd part is that FIO_SeekFile should have been declared in dryos.h, which is theoretically included by stdio.c on line 11 unconditionally ; so I'm not sure why that would cause the build to break, since it worked yesterday. (It's an external function definition, so it probably references an issue somewhere else in the codebase, but I'm not horribly familiar with where to look.)

[rufustfirefly]

I'll try to help out as much as I can with the 40D body that I have now. My primary interest with that body is being able to use focus peaking in LV mode (since it allows me to use my collection of manual focus lenses with more ease), but the additional features would be great, as well.

[a1ex]

FIO_SeekFile is not really essential, especially for a very early port, so you can just ifdef it out for now.

[rufustfirefly]

FIO_SeekFile is not really essential, especially for a very early port, so you can just ifdef it out for now.

Sure. I had opened up an issue on it, just in case:

https://bitbucket.org/hudson/magic-lantern/issue/1616/40d-build-broken

[rufustfirefly]

I also posted the temporary build patch in the bug, but here it is for completeness:

Code: [Select]

diff -r 53fbc6b53da5 src/stdio.c
--- a/src/stdio.c Fri Aug 30 15:48:29 2013 +0300
+++ b/src/stdio.c Fri Aug 30 09:14:00 2013 -0400
@@ -148,7 +148,9 @@
     }
     else
     {
+#ifndef CONFIG_40D
         FIO_SeekFile(f,0,SEEK_END);
+#endif /* !CONFIG_40D */
     }
     return f;
 }


[rwl408]

• Attempt to assemble using assemble_fw.
  ./assemble_fw --header 40D_0_header.bin --flasher 40D_1_flasher.bin --user autoexec.bin --id 0x80000190 --output 40d00111-ML.fir

assemble_fw essentially replaces the flasher file with the user file, with some necessary adjustment, to get the output file. The one I know about requires "injecting" your code into the right place into Canon's flasher code (40D_1_flasher.bin) to produces the user file. Please note that the flasher file as one of inputs to assemble_fw is the original unmodified Canon flasher code. In this case autoexec.bin is your code and I doubt it can be run without this step first in Canon's firmware update environment. However I don't know much about the file autoexec.bin from ML that I could be wrong.

[rufustfirefly]

assemble_fw essentially replaces the flasher file with the user file, with some necessary adjustment, to get the output file. The one I know about requires "injecting" your code into the right place into Canon's flasher code (40D_1_flasher.bin) to produces the user file. Please note that the flasher file as one of inputs to assemble_fw is the original unmodified Canon flasher code. In this case autoexec.bin is your code and I doubt it can be run without this step first in Canon's firmware update environment. However I don't know much about the file autoexec.bin from ML that I could be wrong.

I was following http://magiclantern.wikia.com/wiki/Packing_FIR_Files to attempt to get the autoexec.bin file generated by the ML build process to run.

[rwl408]

It doesn't say anything about being able to run AUTOEXEC.BIN from ML that way. I had used the method to dump firmware but as I said, I had to "inject" my AUTOEXEC.BIN somewhere in the flasher before assemble_fw.