Messages

So main question for me now is which source branch should i use now as entry point (unified, vxworks, or ...) ?

For some reason, the most obvious candidate wasn't mentioned yet.
The 40D port is in active development. The 40D is a DIGIC III model running VxWorks, with live view. Just like the 1000D.

Assuming these questions are still unanswered, I'll try to answer some of them.

In vram.c, vram_update_luts(), which gets called indirectly from call_init_funcs(), there's a loop that initialises a cache of screen coordinates:

A disassembled version of the compiled code could give more hints. The reason of crash is not necessarily related to that piece of code, it could be that RAM gets corrupted somewhere (stack, heap, ML code/data).

Memory alignment

Should not be a problem from C (unless you try hard) and this core seems to cope with unaligned words anyway.

Could sizeof(int) be 2 due to Thumb

No. It's 32 bits, regardless of ARM/Thumb.

I was working on doing some jump hooks around that location

Is that platform/200D.101/jump_hooks.c?

Aaand, of course I managed to find a good example immediately after posting that.  In theory, I can do this:

    LDR PC,[PC,-4]
    #0x12345678

It compiles in Thumb, shall try it soon.

The offset used in that instruction depends on several factors. Your example is valid in ARM state. In thumb state, the offset is 0 if your LDR PC instruction is on a word aligned address, and 2 if it isn't word aligned. See the ARM literature about the value of PC. There's also this, although I don't think I've encountered problems with that.

edit:
Of course, you also need to use the the correct thumb bit in the destination address (bit0 is zero for an ARM target, 1 for Thumb target).

Ghidra shows no direct reference to lvGetResource, but alot of function is'nt called directly but indirectly just like lvGetResource, but in most cases I am able to find a pointer to the function, being passed as a argument to another function, but again with lvGetResource I ran out of luck.

Assuming lvGetResource is the function that references the "[LV] lvGetResource 0x%lX (0x%lX)" string, there are 4 data references pointing to it (= the function's address appears 4 times). These references are a few kBytes "above" the function. It looks like Ghidra doesn't automatically notice references like that. I found them by placing the cursor to the function's first instruction and choosing "Search" -> "For direct references" in the CodeBrowser's menu. I then had to turn those bytes into pointers (P button). The references all appear to be part of a huge struct, and that struct is referenced from a function. I'm not familiar with this style of code as PowerShots implement state machines differently.

It constantly deactivated the shutter release so I unable to start recording or taking a photograph without restarting sometimes multiple times.

That's probably the "shutter bug". You can read about it here and also search in the print view of the current thread.

I'v had troubles in the past with cache hacks on 40D

I've had similar experience on PowerShots.
I found that the firmware's (and CHDK's) cache manipulation functions counter-act cache hacks. The locked part of cache remained locked, but the content vanished from time to time.
The real solution (IMHO) would be a rewrite of all offending cache manipulation functions, so that they don't touch the locked part. A less reliable way would be re-adding the hacks at the end of each such function.
I chose an even less reliable solution: I re-added the hacks every 10ms, using a task that cycles once every 10ms. It was good enough for doing research.

As far as I know, some ML ports and modules rely on cache hacks - I have no idea how they get away without experiencing similar issues.

One more tip: If I see it correctly, lvGetResource only has data references (no b or bl targets it directly). You could get away just by patching those references using the data cache.

I would like to get that call tree.

In case qemu can't get that far, you could also try using cache hacks (src/cache_hacks.h) on the camera.

It appears to use the same file format as EOS R/RP and 250D.

Thanks. That means, reversing the new format will be mandatory before any serious development effort on these new (and future) models.

Canon has released a firmware update for the recent PowerShot G7X III. Can someone take a look at the FIR and tell whether the current decoder/decrypter can still cope with it?

http ://gdlp01.c-wss.com/gds/6/0400005076/01/psg7xm3-v110-win.zip

upon clicking next, the camera shows blank screen, and on the computer it shows "Press SET button to continue installing the firmware"

I believe that's a feature of the latest (1.3.6) firmware. It was introduced in response to this recently published "Missing authorization vulnerability". I would imagine most of the camera's buttons are blocked when an USB connection is active. Don't know whether removing the cable would allow dismissing that dialog, or cause some sort of problem.

If you start do_stuff() the first way, it will obviously execute in the same task.

If you launch it as a new task, it will run independently, in parallel. Also, you get to specify the task priority (0x1e), and the amount of stack space (0x1000).

Simple registering here (...)
gives you enough information.

Those who wish to work on ML in the future may want to read the terms & conditions, especially the section "Confidentiality". Their stuff is not open source.

last time I checked, the RBF editor required an old version of Qt. We may have to dust off some old VM just for editing the fonts, unless someone updated the editor meanwhile.

I have made another RBF editor (with its own quirks), currently available as Win32 binary (Wine compatible).

Just FYI, Canon has released firmware updates for
EOS M50 (1.0.2)
PowerShot SX740 (1.0.1)
PowerShot SX70 (1.1.0)

I guess it can't hurt if you make a ROM dump before sending it in and another after receiving it.
https://www.magiclantern.fm/forum/index.php?topic=16534.0
But that of course doesn't guarantee anyone will jump and implement any calibration related feature.

Not sure where to post this as it's both DIGIC 7 and 8 related.
I've noticed that D7 and D8 ports still have

Code Select Expand

-march=armv7-r
in platform/(cam)/Makefile.platform.default
"armv7-r" means ARM Cortex R. The Cortex R supports integer divide instructions in Thumb mode, whereas the Cortex A9 does not. To avoid getting undefined instruction exceptions in the future, I'd suggest using

Code Select Expand

-march=armv7-a
instead.

Theory:
- there is a frame buffer in the main RAM (like before, just with a different image format: uyvy; previous models were palette-based)

On D6 PowerShots, the overlay uses two buffers at the same time: one uyvy plus one "opacity" (1 byte per pixel). The opacity buffers are usually located close to the uyvy ones. If these cameras have the same display config, and you're planning to write to the uyvy buffers, you'll need to write the opacity buffers too.

- the frame buffer address only changes when the GUI subsystem goes into some different mode (e.g. from shooting mode to Canon menu)

On newer D6 Powershots, buffers are switched continuously when there are animations on screen.

Try recover_mp4. It's a Windows command-line utility, also runs on Linux with Wine.

I know what it is, but not spoiling the game.
@a1ex Can it save files yet?

sorry, but I didnt have success on my M50, I prepared the Card with EOSCard after true formating in the M50
(but with my M50 I also did not have success with the dumper scripts)

Thanks for trying. I guess we'll know more when emulation of the M50 becomes possible.

EOScard?
Is there a bootflag enabler for the real (not emulated) M50 body?
Wondering if I missed something ...

EOSCard can also set PowerShot-related flags, in this case the SCRIPT signature.

[I can't say for sure whether using a prepared script card is enough to run scripts]

After exploring the D8 disassembly I have (I was given a reconstructed M50 dump) I decided to publish my findings here.

- The camera does appear to have the scripting language we (@CHDK) refer to as Canon Basic.
- I have the impression that the card setup is the same as described here: http://chdk.wikia.com/wiki/Canon_Basic/Card_Setup
- Event procedures (short: eventproc) do exist, the eventproc handling firmware routines seem to be the same as on PowerShots.
- There seems to be support for extend.m and autotest.m scripts, but their invocation may differ from what's described here: http://chdk.wikia.com/wiki/Canon_Basic#Starting_the_script

- Now, the differences:
- Most event procedures that appear in CHDK related scripts do not exist. That means, CHDK scripts will not work on D8 cams.
- Many event procedures seem to be pre-registered, so registration functions such as System.Create() are not necessarily needed.
- In file names, the card root is B:/
- I have not yet found an eventproc to write binary files from script, or, to write text on screen.

Problem is, I can't say for sure whether using a prepared script card is enough to run scripts. So, everything below is speculation.

Script support seems to be enabled when the cam is in factory mode - the factory mode flag is at 0xE1FF802C.
I think it is also enabled when there's a script named "AutoTest.m" in the root of the card. The code I found loads "AutoTest.m" automatically at the end of the startup procedure.

The following minimal script should make a hex dump of the first 0x40000 bytes of ROM. I'm not certain that my WriteFileString interpretation is correct.
For a first try, name the script "AutoTest.m".

Code Select Expand

dim startadr=0xe0000000
dim romsize=0x40000
dim fname="B:/ROM.TXT"

private sub Initialize()
    p = startadr
    f = OpenFileCREAT(fname)
    do while p < (startadr+romsize)
        WriteFileString(f,"%08X: %08x %08x %08x %08x\n",p,*p,*(p+4),*(p+8),*(p+12))
        p = p + 16
    loop
    CloseFile(f)
end sub

This script is not camera specific, so it can be tried on any D8 cameras (assuming that all D8 cams share the same codebase):
EOS M50, R; PowerShot SX740, SX70

To make sure the card is correctly prepared for scripting, get any older PowerShot (2005...2017) and use the universal dumper script (http://chdk.wikia.com/wiki/Canon_Basic/Scripts/Dumper) to check.

I can't guarantee success, but I think it's worth to try this route.

I read that some ports (EOS M) experience a shortage of tasks. If this is related to the hardcoded limit of DryOS tasks, the following might help. Quoting an old post of mine:

Looking at the output of 'extask' (extended task information for DryOS), I noticed that a task named EvShel (event shell) has unusually large stack space (0x8000 bytes aka 32kB). This task is only used for debugging over the UART, but it's sitting idle in all cameras used by ordinary people - waste of RAM.
As an experiment, I have prevented this task from starting (on the a470) - it's usually started from the last BL in the 'CommonDrivers' task. Side effect is that this prevents two other tasks from being started (ConsoleSvr, LowConsole) - these would be started by EvShel itself.

That was a PowerShot cam. If cameras on the EOS codebase also survive if those 3 tasks are missing, ML could start 3 tasks more.
I only verified that the above task names are present in the 550d dump. Somebody will have to check if Evshel task's creation can indeed be removed from the boot process, without penalties.

Just an idea.

Some site content is available from archive.org: https://web.archive.org/web/*/19lights.com
Last captured content
Downloads