Powerstates, asm, disassembly, how to, and the whole ordeal about watchdogs - General Discussion and Assistance - CHDK Forum supplierdeeply

Powerstates, asm, disassembly, how to, and the whole ordeal about watchdogs

  • 18 Replies
  • 5481 Views
*

Offline RaduP

  • *****
  • 890
Advertisements
I was wondering, would it be more power efficient if an intervalometer was built directly in C, rather than basic?
This way, the CPU could probably be placed in a low power state, by executing a lot of NOP or HLT or whatever their equivalent is for the ARM CPUs. So most of the time the CPU would execute nop/hlt rather than read the sensor and do other things not needed for an intervalometer.

*

Offline LjL

  • ****
  • 266
  • A720IS
Unsure... I believe the main CHDK loop runs as a thread in the system anyway, so you "can't" just steal the CPU and start busy looping HLTs. The OS also runs a watchdog, I think, and if you spend too much time without returning control, the camera shuts down.

*

Offline RaduP

  • *****
  • 890
Hmm.. can the watchdog/supervisor thread be hijacked?
In fact.. I have an offtopic question, but how do you actually determine all the available functions and useful pointers in a camera?

*

Offline fudgey

  • *****
  • 1705
  • a570is
Hmm.. can the watchdog/supervisor thread be hijacked?

It's quite possibly a hardware timer that's just reset by software every now and then. It may or may not be initialized by software at boot time, and it may or may not be something we can disable or reconfigure. Certainly there should be a way to manually reset it before going into a low power mode (if such a mode can be found, that is... I remember seeing a list of clock frequencies somewhere, but even the slowest one is very fast...we'd probably want something like 32 kHz...).

In any case, the a570is firmware has some strings which smell tremendously like watchdog handling:
Code: [Select]
ffc07c40 WdtInt
ffc07c48 WdtReset
ffc07c54 WdtPrint
ffc07e1c StartWDT
ffc07e28 StopWDT
ffc07a9a  !!!WatchDog expired!!!

In fact.. I have an offtopic question, but how do you actually determine all the available functions and useful pointers in a camera?

You might want to read some of the porting related stuff in the wiki: http://chdk.wikia.com/wiki/For_Developers#Common_articles. I guess there's no one path for finding and learning how to use this stuff, but I'm sure experience with ARM assembly, embedded projects and inner workings of C compilers etc. helps a whole lot in identifying things and guessing what should be tried. Like, for watchdog code, you'd probably go looking at the dissassembly from the addresses listed above and try to figure out what code does, how the software ends up calling that part of the code etc.


*

Offline LjL

  • ****
  • 266
  • A720IS
Well, while we're already on the topic of "where the heck do those functions come from", I have a naive question too. OK, you need ARM assembly knowledge, that's for sure, but where do the names of functions and state variables locations come from? They aren't just invented, I guess. If the OS complex enough that it comes with a table of names embedded in the firmware? And how are little state variables (there's a few "extern long something" that spits out magical values in the CHDK code) figured out?

*

Offline RaduP

  • *****
  • 890
Well, now that I think about it, some compilers will include, by default, the name functions in the binary
(unless you use an option to strip the binary). They might also include the offset to those functions as well.
I have a pretty good X86 assembly knowledge, and C as well. I do not know the inner working of compilers and linkers though, and nor do I know much about ARM assembly, but I guess it can't be too different than X86 assembly (only fewer instructions and registers).
I'll be going in a two weeks vacation soon, and I'd like to do some hacking, but unfortunately there is no good article in the whole wiki explaining things on how to see what functions are natively available, where do they start, etc.

For example, there's got to be a function to put the camera in a low power mode, turn off the CCD power, maybe even change the clock speed, disable intrerupts (so we don't have to worry about the watchdog), and other nice things that can help with many things, not only an intervalometer.

*

Offline PhyrePhoX

  • *****
  • 2254
  • make RAW not WAR
    • PhyreWorX
I split the topic and moved it,hope y'all dont mind.

*

Offline RaduP

  • *****
  • 890
Ok, I looked at the "how to load the dump into IDA" thing, and downloaded IDA and the rar file, installed it and so on.
Now, the obvious question is, how do I get a dump file?


*

Offline fudgey

  • *****
  • 1705
  • a570is
Ok, I looked at the "how to load the dump into IDA" thing, and downloaded IDA and the rar file, installed it and so on.
Now, the obvious question is, how do I get a dump file?

See them sticky threads at http://chdk.setepontos.com/index.php/board,5.0.html.

*

Offline fudgey

  • *****
  • 1705
  • a570is
you need ARM assembly knowledge, that's for sure, but where do the names of functions and state variables locations come from? They aren't just invented, I guess. If the OS complex enough that it comes with a table of names embedded in the firmware? And how are little state variables (there's a few "extern long something" that spits out magical values in the CHDK code) figured out?

Well, Canon was friendly enough to include some unscrambled names, so they are there for disassembler tools to find in our firmware dumps. For example I just searched for wdt from to get that list above (from dump.strings created using Chr's instructions at http://chdk.wikia.com/wiki/Gpl_Disassembling). As for variables, I don't know. I guess some have names like functions, and many have probably been found by looking at what functions do. Take this with a grain of a salt, I'm really a rookie with this part of CHDK development. There are people who know better, if they dare to talk ;)

 

Related Topics