« previous next »
Pages: [1] 2   Go Down

Changes in DryOS and the impact on CHDK

  • 10 Replies
  • 2687 Views
*

Offline srsa_4c

  • ******
  • 3761
Changes in DryOS and the impact on CHDK
« on: 20 / August / 2015, 12:51:03 »
Advertisements
The title is a bit scarier than the actual impact.

Newer DryOS versions (from r54 on) have brought a significant change in some of the kernel functions.
Previously, functions like SetEventFlag, TakeSemaphore, ReceiveMessageQueue, etc, silently ignored (returned with error) when they were passed an invalid (such as 0) ID.
For recent DryOS revisions, this condition trips an assert.

It was not previously noticed, but a number of event procedures we're using in CHDK core does use eventflags. These eventflags are only created when the InitializeAdjustmentFunction or InitializeAdjustmentSystem event procedures are executed.
Hence, just executing something like MoveFocusLensToDistance crashes the r54+ camera due to a nonexistent eventflag.

Possible solution:
- Executing InitializeAdjustmentFunction during the boot process. Pro: it's only one line of code. Cons: this does a bit more than just creating the above mentioned eventflags, for example it registers several dozen event procedures.
- Executing only the needed parts of InitializeAdjustmentFunction. Pro: only the required eventflags will be created. Con: more work (separate functions need to be called for focus, zoom, ND, etc. related event procedures).

There is an additional impact:
The event procedures which use the eventflags will wait until their job is done. This may have unforeseen consequences.

edit:
Modified title from "Kernel changes in DryOS r54 and the impact on CHDK"
« Last Edit: 27 / March / 2016, 20:46:06 by srsa_4c »
Logged
*

Offline reyalp

  • ******
  • 11671
Re: Kernel changes in DryOS r54 and the impact on CHDK
« Reply #1 on: 20 / August / 2015, 23:40:31 »
Fun  ;)

Calling InitializeAdjustmentFunction seems like the simplest short term solution. While I'm a bit wary of possible side effects, I think we have used this event proc quite a bit without any obvious problems. It would be worth checking how much ram is taken up by calling this.
On ixus140 I get
Code: [Select]
> =return get_meminfo('system').free_size,call_event_proc('FA.Create'),get_meminfo('system').free_size
5:return:1852816
5:return:0
5:return:1844568
> =return get_meminfo('system').free_size,call_event_proc('InitializeAdjustmentSystem'),get_meminfo('system').free_size
6:return:1844544
6:return:0
6:return:1817424

So ~8k for FA.Create (which can probably skipped if you call the pointer for InitializeAdjustmentSystem directly) and ~27k for InitializeAdjustmentSystem. That's a pretty significant amount on some cameras.

If there's only a handful of individual functions that need to be called, option 2 doesn't sound too bad. Especially if they can go in the sig finder. One possible side effect might be if you did want to call InitializeAdjustmentSystem for other reasons, it might break if some parts were already initialized.

Possible third solution might be to call underlying functions. On ixus160 it looks like MoveFocusLensToDistance clears the event flag, calls a function (sub_FFB7E874) to do the actual work, and waits for the event flag. The second parameter to the function is a callback that sets the event flag (sub_FFB7E478).  sub_FFB7E874 looks like handles a null callback.

If most of the functions follow this pattern closely, it might be possible to get the right functions with the sign finder. They would still need special wrappers for the extra parameters.

OTOH, having these functions not return until complete could be a good thing in many cases.
« Last Edit: 07 / March / 2016, 23:02:44 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 3761
Re: Kernel changes in DryOS r54 and the impact on CHDK
« Reply #2 on: 21 / August / 2015, 18:07:24 »
Quote from: reyalp on 20 / August / 2015, 23:40:31
If there's only a handful of individual functions that need to be called, option 2 doesn't sound too bad. Especially if they can go in the sig finder. One possible side effect might be if you did want to call InitializeAdjustmentSystem for other reasons, it might break if some parts were already initialized.
I'm currently doing this, but the longterm plan is probably the third option you're mentioning.
The weakness of option 2 is that executing the initialization event procedures from a script could - in theory - hang up the camera. This is possible because those short initialization routines are not protected against multiple execution, and will overwrite the eventflag/semaphore variable. If this happens in the middle of an operation that utilizes one of the eventflags/semaphores, then the routine will get stuck waiting for a condition that will never become true.
Quote
OTOH, having these functions not return until complete could be a good thing in many cases.
We could also utilize this feature by coding the new (for r54+) wrappers accordingly.

Now I'm wondering, what else has changed...
Logged
*

Offline reyalp

  • ******
  • 11671
Re: Kernel changes in DryOS r54 and the impact on CHDK
« Reply #3 on: 21 / August / 2015, 21:37:50 »
Quote from: srsa_4c on 21 / August / 2015, 18:07:24
If this happens in the middle of an operation that utilizes one of the eventflags/semaphores, then the routine will get stuck waiting for a condition that will never become true.
This isn't great, but it doesn't seem worse than a lot of other stuff CHDK does. Normally you'd run the initialization eventproces once at the start of a script.

Quote
We could also utilize this feature by coding the new (for r54+) wrappers accordingly.
It looks like the pre-54 code is very similar (ixus140 MoveFocusLensToDistance appears pretty much identical), it's just the behavior with uninitialized eventflags etc. that has changed.  So in theory we could use the same method on (some) older cameras too.
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 3761
Re: Changes in DryOS and the impact on CHDK
« Reply #4 on: 27 / March / 2016, 20:55:24 »
The eventproc versions of Open and Close have received a wrapper that protects against parallel execution in DryOS r58 (noticed this while working on the sigfinder).
Incidentally, this version of the functions is the most widely used throughout the firmware.
I'm wondering which version should we identify as Open and Close. I suspect that same thing happened in the sx720 firmware (haven't seen that one yet).
Logged
*

Offline reyalp

  • ******
  • 11671
Re: Changes in DryOS and the impact on CHDK
« Reply #5 on: 27 / March / 2016, 21:19:13 »
Quote from: srsa_4c on 27 / March / 2016, 20:55:24
I suspect that same thing happened in the sx720 firmware (haven't seen that one yet).
Yes, it looks like it is, so my change 4575 in still doesn't get functions equivalent to the previous dryos versions (also, the 57 in that commit message should be 58  :-[)
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 3761
Re: Changes in DryOS and the impact on CHDK
« Reply #6 on: 27 / March / 2016, 21:29:50 »
Quote from: reyalp on 27 / March / 2016, 21:19:13
Yes, it looks like it is, so my change 4575 in still doesn't get functions equivalent to the previous dryos versions (also, the 57 in that commit message should be 58  :-[)
Now the question is, should we just use the new Open_FW/Close_FW as Open/Close and disable our fileio semaphore wrapper in platform/generic/wrappers.c or ...?
I guess this will be decided in the sx720 port.
Logged
*

Offline reyalp

  • ******
  • 11671
Re: Changes in DryOS and the impact on CHDK
« Reply #7 on: 27 / March / 2016, 21:54:40 »
Quote from: srsa_4c on 27 / March / 2016, 21:29:50
Now the question is, should we just use the new Open_FW/Close_FW as Open/Close and disable our fileio semaphore wrapper in platform/generic/wrappers.c or ...?
I guess this will be decided in the sx720 port.
It's not yet clear to me how the new semaphore relates to the old fileio semaphore. They don't look the same, but if the firmware uses the new functions everywhere, maybe it would avoid the old problem. I wonder what happens when video is recording?
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 11671
Re: Changes in DryOS and the impact on CHDK
« Reply #8 on: 30 / March / 2016, 01:21:20 »
I updated finsig thumb2, so the low level open and close (only used by the utime wrapper AFAIK) use low level functions equivalent to earlier firmware. Open, Close, Write etc all use the Canon function with the new semaphore. I don't think having this in addition to the existing fileio stuff will be a problem, but I could be wrong.
Logged
Don't forget what the H stands for.
*

Offline asm1989

  • *****
  • 527
  • SX720, SX260, SX210 & SX200
Re: Changes in DryOS and the impact on CHDK
« Reply #9 on: 30 / March / 2016, 02:11:50 »
reyalp will try 4578 on Sx720, should I remove the manual stubs for close then?
Logged
Pages: [1] 2   Go Up
« previous next »
 

Related Topics