No, some devices are initialized on demand. Some cameras do some sort of bad pixel calibration at startup, but from what I could tell, that doesn't trigger any image capture; maybe it's just loading saved correction data into the image processor, or something like that. But image capture is powered on when entering LiveView or when taking a photo, and powered off when finished. Complete configuration happens after powering on, i.e. it's visible in adtg_gui.
However, some registers are configured with different values at different stages; for example, before capturing a photo, most cameras also capture a partial dark frame, apparently for figuring out the vertical stripe pattern. The 500D and 1100D don't do this, but most other cameras do. The calibration frame has different vertical size, so FPS timer B is set to different values. Currently, adtg_gui doesn't handle this very well, so it's hard to override values just at one stage of the image capture sequence; by default, it overrides a register in all places where it's modified by Canon code.
Look at this screenshot:
FPS register B was set a couple of times during the image capture process, to different values. By default, adtg_gui shows just the last value for each register. If you change the "unique key" option (caveat: you need to do that before enabling the main ADTG menu entry!), you can see, to some extent, the different values
as long as they were changed from different parts of Canon code. You can't just see the entire sequence in the menu yet; that's a bit more difficult to solve, especially if you will want to override things.
You can log the complete communication between the ARM CPU and its peripherals - remember
these thousands of registers?
You should find every single register read/write in
those huge logs.
You can see everything the firmware does, before ML is loaded, in QEMU (-d io). It's not touching the image capture stuff.
