Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - heder

Pages: [1] 2 3 ... 7
Camera-specific Development / Re: Canon 40D
« on: July 06, 2021, 07:20:54 PM »
I Guess I need to do a better install video next week, currently im om Mallorca  ;D

There are a couple things that I don't understand. E.g the code works if I modify ptp-chdk.c/h code replacing it with my own code in the src folder, but exactly the same code does not work as a module. I simplified the code removing all code but the version and the shooter code(3 lines of code) and the problem remains: As a module the ptp code does not work, the handler is not activated, but in src it does.


Post the mini module code please. Modules are installed runtime and called via hooks runtime. Your metadata section needs to be correct.

Share Your Videos / Re: T4i TV Spot MLV 12 BIT
« on: June 11, 2021, 05:20:56 PM »
Great work. The idea of doing commerial Ads with a T4i running ML is cool  8)

For the module context, since we control the source and are compiling it, I think using -mlong-calls is an appropriate fix.  For patching at runtime, that won't work and you might need to do what you're describing.  I guess that's the context you need to work in, so you can't use -mlong-calls?  Do modules work on 1300D?  If DryOS code is far from heap alloc region, I think they won't, and I also think that my fix will work for you.

I'd like someone with better experience with ARM to confirm -mlong-calls makes sense for where I'm using it - any volunteers?

I'm not doing any runtime patches yet on 200D, they haven't been needed.  I'm assuming I'll use MMU remapping when it gets to that (or, if I'm lucky, overwriting a thunked function, the 200D has *some* code in RWX pages).

I think the -mlong-calls trick is the way to go, the optimization gained by using relative jumps is ussless.

I dont know if modules are running on the 1300D, I just worked out a solution for hijacking firmware functions, where you patch a single instruction, and you're right about that the heap alloc region need to be close, aka within +/-32MB from canon firmware (99%). 

I'll ask citrix to read this thread

"+/-32 MB near jump issue" : This is (I guess) the problem that all new cameras will face. It's also on the 1300D. On 1300D you can not hijack any calls as the addresses (csanon firmware) are further away than +/-32MB from the magic lantern firmware. I recreated a patch function that instead of using a single near jump, uses a near jump that jumps into a long call jump. Maybe this problem is also present on DIGIC7? ... if so a *temporary* solution is present in the 1300D thread.

Camera-specific Development / Re: Canon 40D
« on: April 25, 2021, 10:55:44 PM »
Last update stops at 1.0.6.

Next update will be in 2022/2023. I ran out of luck (time), RL is taking all my time, shit happens once a while.

I'll be watching this thread and ML forum until then.

Camera-specific Development / Re: Canon 40D
« on: February 18, 2021, 07:11:22 PM »
Open beta update (1.0.6).

With the memory system nearly completed, its time for another beta release, as mlv_lite can utilize this. This improves the recording capabilites abit.

Memory system:
* SRM compatible function implemented inorder to avoid new code, I used [SBF]CreateSharedBuffer for allocation.
* malloc fully supported in fio_malloc (get free region fixed)
* Largest shoot malloc block is around 4MB, fio_malloc updated to pass allocation to SRM above 4 MB.
* Disabled memory analysis overlay (debug menu), it will crash the camera (overlay width,height incorrect?)

Bug fixes / minor changes:
* CACHEABLE() & UNCACHEABLE() changed due to incompatible between digic4 and digic3.
* edmac channels now switch automatically between 0x4 and 0x5
* console now uses FONT_MED due to low resolution display, and included more options and buffering
* FIO_SeekSkipFile interface corrected and FIO_CreateFileorAppend corrected.
* FIO_WriteFile wrapper not checking for digic4 uncacheable pointers correctly

* mlv_lite can now allocate ~208 MB, instead of ~40 MB
* srm memory allocation enabled (if set true in menu)
* pre-recording disabled - will prevent camera from recording correctly
* Starting and stopping LiveView multiple times may set preview=black, resolve this by power off and on.

Camera-specific Development / Re: Canon EOS 1300D / Rebel T6
« on: February 17, 2021, 01:50:55 PM »
"thumbs up"  ;D

Regardless what I did, copy scripts into ghidra script paths, or just running from ghidra2dwarfs directory, I get ImportError.
I ran ghidra2draw headless (on my 40D.elf) from bash prompt and got:

Traceback (most recent call last):
  File /home/heder/magic-root/ghidra/ghidra2dwarf/src/, line 1088, in <module>
  File /home/heder/magic-root/ghidra/ghidra2dwarf/src/, line 132, in add_debug_info
    add_function(cu, f, file_index)
  File /home/heder/magic-root/ghidra/ghidra2dwarf/src/, line 316, in add_function
    d = res.decompiledFunction.c
AttributeError: 'NoneType' object has no attribute 'c'
INFO  ANALYZING changes made by post scripts: /ROM1.elf (HeadlessAnalyzer)
INFO  REPORT: Post-analysis succeeded for file: /ROM1.elf (HeadlessAnalyzer)
INFO  REPORT: Save succeeded for processed file: /ROM1.elf (HeadlessAnalyzer)

I have'nt had the time to analyze the failure cause.

Was your "ordinary python issue" this?
orig_base is None because the file Ghidra is working from is not ELF.  The ROM file was never an ELF, so, we may have to create one (from within Ghidra?).

I got ... "ImportError" on, so I neded up forcing all code from into the ghidra2dwarf script, python refused to find

Here is my conversion from rom to elf
Code: [Select]

# strip the first 0x10000, entry is at 0xff810000, and remove the useless end part
cp ROM1.BIN ROM_tmp0.BIN
truncate -s 8388608 ROM_tmp0.BIN
dd if="ROM_tmp0.BIN" of="ROM_tmp1.BIN" bs=65536 skip=1
arm-none-eabi-objcopy --input-target=binary ROM_tmp1.BIN --output-target=elf32-littlearm -B ARM --change-addresses=0xff800000 --rename-section .data=.text ROM1.elf

and I tested this on my bootloader which was a success, but on the real 40D ROM/elf file it failed.

Breif update.

After fixing a ordinary python issue in the ghidra2dwarf module, then learning how to re-create ELF files the properly way (ghidra and ghidra2dwarf wants proper ELF files) it looks good.  :)

I took the stripped flat binary bootloader thats is used on the 40D, recreated a ELF file, loaded it into ghidra, analysed it, and then ran the ghidra2dwarf pluging, and got a ELF file with dwarf symbols and the ghidra decompiled source code. The ghidra source code ain't that bad after all, its looks abit like the real source code. Next step is try this on 40D ROM1.BIN, and the try to get GDB to load the dwarf information so we can debug with the ghidra source code in QEMU.


From :

Ghidra2Dwarf is a ghidra plugin that allows to exports informations (such as functions, decompiled code, types) from ghidra to dwarf sections inside ELF binaries.
More specifically it exports inside a source file named ${program}.c all the decompiled functions, and create an ELF binary named ${program}_dbg that can be used to do source code level debugging.

This is much easier that I thought.

Tomorrow to install the Ghidra2Dwarf plugin, export to elf file and run the elf file in QEMU.

Hi all, I need a debugger setup for debugging QEMU.

I never liked gdb text interface, it's rubbish! I'm used to work with Microsoft debugger for windows programs and Segger's Ozone debugger with the J-Trace PRO debugger for arm development, and nothing compares to this combo, tried many others, but the last combo for embedded is really power full. Here's an long list of visual frontends for GDB is long but if you are used to working with said tools, you end up not debugging at all on QEMU, and qprintf becomes you best friend. But in 2020 (at work) we're started to use Visual GDB, a good alternative. It ain't free, but there's and 30 day free trail, and after that you'll need to pay 79€, that's cheap. It can be used with Microsofts free VS Community Edition.

How about this setup
* Microsofts free VS Community Edition.
* Visual GDB
* Ghidra (or IDA)
* QEMU (ML version)

Work flow

Ghidra (or IDA for that matter)
* Disassemble/analyze the camera ROM with Ghidra and let Ghdira auto name all function stubs & data
* Create a Ghidra script to perform advanced function renaming, auto rename function that has a DebugMsg(x,y,"[??] ...")
* Do you own renaming ...
* Use Ghidra2Dwarf to export symbol file

* convert Ghidra text file into dwarf debugging file
* convert the camera ROM into a camera elf file
* inject the newly created dwarf file into camera elf file

* run the camera elf file in QEMU

Visual GDB
* Connect to remote target
* Debug ...

Anyone tried this combo ? suggestion, ideas are welcome ..   

Camera-specific Development / Re: Canon 40D
« on: January 26, 2021, 05:45:52 PM »
Good news. Memory management on the 40D soon complete

SRM allocation is up and running in QEMU and camera :D

I have found that SRM_AllocateMemoryResource1stJob functionality is present in the Vxwork firmware, but the code is completely different from the DryOS cameras. Calling call("FA_CreateTestImage") and call("FA_GetCwRawBuf") did however still work like a charm, and I get access to a full Craw buffer = 18153360 bytes. Thus I have created compatible SRM_AllocateMemoryResource1stJob+free functions that uses the call("") functions, this should also work for 400D. SRM_AllocateMemoryResource1stJob on the 40D can actually allocate more or less all memory, outside Liveview I get 14 buffers, inside Liveciew I get 11 buffers. The camera has total 256 MB on board and most can be allocated using SRM_AllocateMemoryResource1stJob and shoot_config(0). I can allocate a total ~240 MB, Mlv_lite  will benefit from this (mjpeg recording too - when it is done). Next step is to update mlv_lite to use this memory, so we can start recording less useless formats.

Beside this I found that the largest non-temp block (malloc,AllocateMemory) on 40D that can be allocate is very small :( a little less than 4MB, but the code assumed 20 MB, and this could crash the camera, fixed.

Camera-specific Development / Re: Canon 40D
« on: January 26, 2021, 05:41:22 PM »

Yep, using the 32 bits worked, but I also needed O_SYNC removed.

Camera-specific Development / Re: Canon EOS 1300D / Rebel T6
« on: January 25, 2021, 08:31:59 AM »
Hi petabyte

Briliant idea to make a video  :), a image says more than a 1000 words.

Your console says your trying to enter ML via space key , your console = "Key event: 39 -> 0xc01"
But you should be using delete key, my console = "Key event: 59 -> 0401"

(But If you are infact using delete and QEMU translated this into key event for space, then the problem is qemu and then you should recompile and use SDL)

Camera-specific Development / Re: Canon EOS 1300D / Rebel T6
« on: January 22, 2021, 10:22:31 AM »
I repulled and recompiled, still "Memory card containing firmware is required to update." when trying to load 1.1.0-ml-nightly. Is this as expected?
The minimal hello world seems to run though.

Hi petabyte

A couple of ideas to track down your isssue, but I suspect that the issue itself is your compilation or compiler.

1. In Makefile.user set CONFIG_QEMU = y (this will keep the build more stable on QEMU)
2. What version of GCC are you using ? Personally I only old onces : gcc-4.7.4 or gcc 5.4.1. These can be found on
3. Be aware that in some rare cases the sd.img can be conterminated, but since your hello world is working this is not the issue.

Camera-specific Development / Re: Canon EOS 1300D / Rebel T6
« on: January 21, 2021, 06:59:29 PM »
Hi petabyte

just to be 100%

1. You downgraded your 1300D camera to 1.1.0 (with success)
2. You dump'ed the rom (1.1.0) to sd-card
3. You change the rom (1.1.0) using my instructions
4. You ran QEMU and got "Memory card containing firmware is required to update."

Camera-specific Development / Re: Canon EOS 1300D / Rebel T6
« on: January 21, 2021, 09:23:07 AM »
Hi petabyte

The command to execute ML booting on 1300D in QEMU is

Code: [Select]
./ 1300D,firmware="boot=1"

1. Remeber to copy your ROM files into the 1300D directory
2. Follow my instruction from (rom updating)

The console should at some point write :

Code: [Select]
Open file for read : AUTOEXEC.BIN
File size : 0x6FBA0
Now jump to AUTOEXEC.BIN!!

After booting, press delete bottom for entering ML menu.

Camera-specific Development / Re: Canon 40D
« on: January 15, 2021, 12:31:51 PM »
Finally a little progress on the port.

I finally found the missing bugs in the FIO_ system which have been annoying, I found two issues.

The interface on FIO_SeekSkipFile is wrong. The interface in magic lantern (DryOs) is specified as: int64_t FIO_SeekSkipFile(FILE *, int64_t offset, int whence); but VxWorks interface is actually: int32_t FIO_SeekSkipFile(FILE *, int32_t offset, int whence); No wonder I could'nt seek inside a file at all! (all seeks was SEEK_SET due to wrong parameter sizes)

The other bug was the O_SYNC flag screws up operations. FIO_CreateFileOrAppend would not perform correctly when seeking inside a file because if was opended with O_SYNC. It seems like O_SYNC is'nt supported (?). I tryed with both cache and uncache memory, both fails with O_SYNC. Removing O_SYNC from opening file solved the issue.

And with console.c writing console.log correctly (now) I can assume hunting the last fio_malloc() bugs ..

I wish I had the time to contribute more, but I dont, so I linger in the 40D department. But if I had the time  :)  I would start by cleaning up the Main branch code, line by line. ML is extremly complex and needs a pretty filter run over the code, more comments, and more inline documentation, more coding style, and no more ^M please. Also to many ifdefs makes the code difficult to port. But .. these changes are not valueable features, most Ppl only cares about bigger  :( resolution.

How about creating a unifed dev branch ?

Camera-specific Development / Re: Canon 40D
« on: January 04, 2021, 10:46:09 AM »
A new incomplete list of stuff todo

* edmac module fails (edmac is working, but module fails)
* beep sound not implemented
* auto exposure value not detected (I gave up on this one)
* ants mjpeg module is not recording correctly (working on this)
* get 40D branch on heptapod
* compile and test 40D with gcc 6.x compiler.
* Lua module is loading and working, but is it useable ??
* 1st memory job stub function not found.
* lots of PROP_ (properties) not aligned.
* zebras in liveview missing
* global draw (zebras,histogram) not shown in photo mode (= crash)
* Better SW1/SW2 activation
* continue to update
* Optimal Mirror lockup not implemented (as minimum the curtain is activated), disable the curtain activation

* 10/12 bits raw video,
  => Theoretical: (10 bits, 23.976 fps, 1:2.39 = 1056x432) &  (12 bits, 23.976 fps, 1:2.39 = 960x400)
  => Require merge with 10/12 bit branch

* LV state mashine
   => not re-engineered
   => VSync er performed via EngDrvOut hijack (ok for now)

* FIO_SeekSkipFile does not work at all .. why ?
   => SEEK_CUR,SEEK_END fails.
   => only SEEK_SET seems to work ..
   => could be cache ?
   => could be interface ? / parameter swapped ?

* selftest module fails
  => only a few tests runs as they should

* bench module fails
   => issue with memory allocation,
   => CF card benchmark may not be performed with buffers > 2 MB or the system halts
* memory system allocation
   => still fails on large buffers, bench module fails, selftest modules fails.
   => mlv_lite does not fail. (allocates above 20 MB)

Camera-specific Development / Re: Canon 40D
« on: January 03, 2021, 09:09:39 PM »
Managed to boot your build in qemu, now i can boot both canon firmware and your ML build. :)

Next I'll try to run it in the camera and dump the RAM.. Also.. How would one go about finding the half shutter button? Id like to try that.
Thanks for your work heder!

Hi, your qemu looks really good  8) (mine is crap)

My lastest build is here my lastest build (source code) is here The half shutter fix is included, but only lightly tested. The source that fixes the half shutter is platform/40D.111/sal-digic4/sal-gui.c (the function is called sal_GUI_E_Control). Basically i'm hijacking the GUI_E_Control function and checking for half shutter.  It's not the best solution, but because the half shutter on Digic3 is not like on the Digic4 platform, hijacking GUI_E_Control was the easy way of getting "the job done".

If you get stuck, just ask, there's no bad questions, just bad answers.

I'm still working on mjpeg, totally stuck, fighting with odd errors, I dont understand.

Camera-specific Development / Re: Canon 40D
« on: November 11, 2020, 10:16:52 AM »
I'm still working on mjpeg streaming.  Ant123's module would not run record smoothly, so I reworking Ant123's module, making it more towards mlv_lite but my reworked module is not working yet.  Also due to house renovation progress is a little slow lately, but I have not forgotten the ML project  ;)


Camera-specific Development / Re: Canon 40D
« on: October 19, 2020, 01:47:17 PM »
Hi all,

So, went through all pages here and just wanted to confirm if I maybe a bit too dumb to understand the codes used here or the LiveView "timeout" is not on the list of mods planned.

Currently my 40D times out at around 30 min and closes LiveView (I am using at work as a webcam to present stuff to the team, so EOS Camera Movie Recorder + OBS), but I could only find the LiveView mentions as being part of the video function, if I got it correctly. Do you know if there is any flag I could maybe change to remove the limit to it?


Hi ArchThor.

I didn't even know there was a 30 minute limitation, so I will look into this when I have the time. I have LUA scripting
module running (but not released yet), and perhaps I can merge with the LUA fix scripting branch, and using
the LUA module avoid/fix this limitation, but no ETA on when this is ready.

Pages: [1] 2 3 ... 7