CHDK Forum
CHDK Development => General Discussion and Assistance => Topic started by: barberofcivil on 31 / October / 2009, 10:27:03
-
I'm looking for assistance on trying to hook into some functions. Is it only possible to hook into 'registered, named' tasks? Using the SX10 103A as my example, when looking at the currently hooked tasks (CaptSeqTask, ExpDrvTask, etc), they appear to get 'registered' at the subroutine at address FF827D10. Indeed, every call to this function can be traced back to carrying the R0 and R3 registers which hold the task name and task start address respectively, and I have been able to find and list off all functions registered in this manner. I have tried and been able to hook into any of these tasks (DvlpSeqTask, IrisEvent, etc) successfully.
However, my problem is that there are some functions that I would like to explore that I can't get to directly or indirectly through any of these named tasks. They trace back to dead ends: they reach a point where they are not called directly. For exaple, one function in particular gets traced back to an entry point at FF852B60 which isn't branched to or called directly, it's only reference is:
ff852d9c: sub r0, pc, #580 ; ff852b60: (e92d4010)
As far as can tracer back, I can't get directly into one of the named tasks that I know I can hook. Is there a way that I can hook other functions such as this? Or am I limited to the realm of named tasks and wherever they can lead me?
-
Probably not, but what you can try to do is search the RAM for the address of that function, and if you find it, you might be able to replace it with your modified code.
-
I'm looking for assistance on trying to hook into some functions. Is it only possible to hook into 'registered, named' tasks? Using the SX10 103A as my example, when looking at the currently hooked tasks (CaptSeqTask, ExpDrvTask, etc), they appear to get 'registered' at the subroutine at address FF827D10.
These are tasks, which are somewhere similar to a thread or process in a traditional OS. If you hook the beginning of the task, you modify it's entire behavior, but you might end up having to duplicate lots of the original code. Multiple tasks frequently use the same functions, so it's quite possible to replace the functionality in one task, yet have the old function used in other tasks.
As far as can tracer back, I can't get directly into one of the named tasks that I know I can hook. Is there a way that I can hook other functions such as this? Or am I limited to the realm of named tasks and wherever they can lead me?
Not entirely, but this is how CHDK currently accesses almost everything.
Other options:
Some functions are accessed from pointers, e.g. a filesystem driver will have the read and write functions stuffed into a structure, and access them by that structure later. Many of the function pointers are in the canon initialized data segment, which is copied from ROM to RAM in the very first loop of the firmware code. You should be able to find/replace these quite easily. Others are set up by code elsewhere. Of course, a function might be called both via a pointer and via directly by it's ROM address.
Some functions are accessed as event procedures: see http://chdk.setepontos.com/index.php/topic,4417.0.html (http://chdk.setepontos.com/index.php/topic,4417.0.html)
The event procedure API allows you to have a hook run before every eventproc call. Part of ExecuteEventProcedure looks something like this (taking a610 sig_ref_vxworks_1 as an example, dryos does the same thing but is slightly less clear because the eventproc hook comes from a struct):
loc_FFC06864
LDR R3, =0x102BC ; parameter for event hook
LDR R1, [SP,#0x10] ; event proc name
LDR R0, [R3]
LDR R2, =0x1E1C ; event proc hook variable
MOV LR, PC
LDR PC, [R2] ; call hook
LDR R3, [SP]
MOV R0, R5
LDR R1, [R3]
MOV LR, PC
LDR PC, [R3,#4] ; call eventproc
...
There exists functions to set and remove this hooks, and at least one example which logs the event names.
Note that this doesn't allow you to modify the behavior of the event procs, but it should allow you to see which ones are called.
If you want to modify the behavior, you should be able to unregister an existing eventproc and register your own. Be warned however that just because a function is available as an eventproc doesn't mean it is always called as one. Many are normally called directly by address, and only called as eventprocs in the debug code.
One other idea I've had is abusing the ARM MPU. There are a couple of memory regions that are not used in the default configuration, so you could install your own exception handler, and protect the region of interest against reading. When the stock firmware tries to jump there, your exception handler gets invoked, and you set it up to return to your own modified code instead. Unfortunately, the minimum size you trap this way is 4k. So you'd probably have to copy/relocate the entire 4k block, and you'd only get 1 or 2 at the most (unless you move them around.)
-
Would it be possible to set up a hardware breakpoint on execution, in the ROM memory?
-
My understanding (based on a limited reading of DDI0201D ARM946E-S Technical Reference Manual: Chapter 9 Debug Support) is that the hardware debug interface requires external hardware, which is at least inaccessible and possibly not present on production cameras.
-
I was reading that too and it is confusing.
I am not sure if you are familiar with the 386 CPUs, but on them you can set hardware breakpoints in the protected mode, and when a memory location is read, modified or executed it will pass the control to your code. I wonder if the ARMs have something similar..
-
I wonder if the ARMs have something similar..
I'm confident that 946E-S does not. It would be reference manual if it was there. This makes sense for embedded systems, the developers will have access to the hardware interface, and won't run their debugger on the target.
Possibly if you open up your camera, you can access the JTAG interface ;)
-
I guess you are right about it, I tried to find ways to enable the debugging without jtag and it doesn't seem to work.
Although your MPU idea made me rethink again of my moving the ROM to RAM idea. This way, the non relative jumps do not have to be converted, and if the program jumps into the ROM, or tries to read data from there, the MPU exception handle could correct this behavior by pointing to the new location in RAM (simple math). But this could be slow at times..
-
Thanks guys. Looks like this is likely beyond my current capabilities. I've learned how to hook the tasks by emulating what has already been done, so Iguess I'll just have to stick to exploring the hookable tasks at the moment.
What I'm currently looking for is how the controlling of the highspeed photo capture works (the ISO3200 function). The CHDK overrides work for changing the ISO (and shutter/aperture), so that this mode can be used with standard ISOs. However, the image size overrides have no effect, they remain at the 1200x1600 size. I would like to see if it is possible or not to override this and use larger image sizes or if it's inherent to the whole mode itself.
-
On many cameras, ISO 1600 is not different in what the sensor gets than ISO 800. The only difference is that the camera is brightening it in software. So don't waste your time with ISO 3200, just shoot raw an adjust the exposure in your raw processing program.
-
However, the image size overrides have no effect, they remain at the 1200x1600 size. I would like to see if it is possible or not to override this and use larger image sizes or if it's inherent to the whole mode itself.
I believe the high ISO mode on newer cameras is accomplished with something like pixel binning http://www.ccd.com/ccd103.html (http://www.ccd.com/ccd103.html) (how exactly they do this with a bayer pattern is unclear, but that's sure what it looks like)
-
On many cameras, ISO 1600 is not different in what the sensor gets than ISO 800. The only difference is that the camera is brightening it in software. So don't waste your time with ISO 3200, just shoot raw an adjust the exposure in your raw processing program.
It's not so much the ISO3200, it's the high speed capture. In ISO 3200 mode it's something like 4fps, whereas in other modes it's much slower. In ISO3200 mode, the image size is limited to M3 (1200x1600). I would like to find out if I can harness the speed but use a full image size or if M3 size is part of the high speed function for some reason. As I said, the ISO speed is overridable (as well as aperture and shutter) however, trying to override the image size at the same point as the other overrides has no effect. I wanted to see if I could find out where in the mode it sets the image size to use.
-
I believe the high speed is a directly result of the lower resolution. That's why I assume it is something like binning, that reduces the resolution very early in the process.
Note that other lower resolution settings are generally not much faster than full size. Not coincidentally, their raws are full sized. If you set 640x480 in the menu, a CHDK raw is still full sensor resolution, and maximum shooting rate isn't dramatically faster than shooting at much higher res. AFAIK, some of the lower resolutions are actually slower on some cameras.
-
I believe the high speed is a directly result of the lower resolution. That's why I assume it is something like binning, that reduces the resolution very early in the process.
Note that other lower resolution settings are generally not much faster than full size. Not coincidentally, their raws are full sized. If you set 640x480 in the menu, a CHDK raw is still full sensor resolution, and maximum shooting rate isn't dramatically faster than shooting at much higher res. AFAIK, some of the lower resolutions are actually slower on some cameras.
Reading about it, that seems likely. Was hoping that there was some potential to add a bit of speed to larger images, at least CHDK allows the other overrides to work, I'm just stuck with smaller images for now.
-
Keep in mind that pixel binning on most sensors will dramatically degrade the quality. In theory, it sounds all good, but in practice there are issues with it.
So a pixel binned photo will not look as good as a downsampled full sensor photo.
-
Reading about it, that seems likely. Was hoping that there was some potential to add a bit of speed to larger images, at least CHDK allows the other overrides to work, I'm just stuck with smaller images for now.
Shot to shot delay is a major point of comparison in reviews. If canon could dramatically decrease decrease it, on their existing hardware, without loss of quality, they would.
Even if you buy the idea that canon deliberately cripples their low end cameras performance in software (which isn't really born out by the evidence) they wouldn't do it on their mid to upper segment cameras like the SX10.
-
Hej,
Yeah I don't think it can happen in that department.
The limited fastest shutter speeds is something I don't get, it is limited deliberatly by canon (like 1/1250s at F2.6 on our A540, can't see a reason to not be able to use 1/2000s).
Morevover they explain the lack of HD video with the speed of the sensor, not only canon, so I guess original burst mode is just the best one can have out of the cam for the same reason.
-
FWIW - on the SX10 the RAW buffer size in ISO3200 mode is much lower...
However the very strong iso3200 noise reduction appears to be applied anyway, which gives a picture almost as bad as real iso3200. am i doing something wrong?
BTW, RAW resolution in ISO3200 mode is only 1248x938 (1.1MP), but it still 12-bit :D.
Maybe Canon's 1600x1200 is interpolated.