supplierdeeply
« previous next »
Pages: 1 [2] 3 4 5 6 7   Go Down

1.5 development planning thread

  • 61 Replies
  • 20859 Views
*

Offline srsa_4c

  • ******
  • 3784
Re: 1.5 development planning thread
« Reply #10 on: 12 / December / 2015, 21:08:10 »
Advertisements
We could reduce core size by more than 1kB if we could find a way to exclude unneeded language strings (such as GPS strings on GPS-less cams).

edit (no need to bump the thread, just a note to myself):

A special module could be created to make on-the-fly 'cache hack' experiments possible (such as: modify constant in ROM, logging access to arbitrary routines, etc.), with Lua scripting interface. An HP timer could be used to re-apply the hacks (this method is still not 100% reliable, but should be good enough for research purposes).
« Last Edit: 23 / January / 2016, 12:43:19 by srsa_4c »
Logged
*

Offline msl

  • *****
  • 1251
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: 1.5 development planning thread
« Reply #11 on: 03 / February / 2016, 05:55:45 »
@Phil

Thanks for the commit of the 'OSD rotate patch'.

I have some questions for the documentation. How is the situation with touch screen cameras? Is the rotate option suitable for this cameras? Are the virtual keys also rotated?

msl
Logged
CHDK-DE:  CHDK-DE links
*

Offline philmoz

  • *****
  • 3071
    • Photos
Re: 1.5 development planning thread
« Reply #12 on: 03 / February / 2016, 17:54:44 »
Quote from: msl on 03 / February / 2016, 05:55:45
@Phil

Thanks for the commit of the 'OSD rotate patch'.

I have some questions for the documentation. How is the situation with touch screen cameras? Is the rotate option suitable for this cameras? Are the virtual keys also rotated?

msl

No, the touchscreen co-ordinates are not adjusted so the UI does not work properly if the OSD is rotated.
Tested on IXUS 310; but I assume all touch screen cameras will be affected.

This may need to be fixed in the camera specific code individually for each camera.

Phil.

Edit: I've fixed the IXUS 310 in revision 4413. The IXUS 240 and N cameras will need similar changes in kbd.c.
« Last Edit: 03 / February / 2016, 18:25:31 by philmoz »
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
*

Offline srsa_4c

  • ******
  • 3784
Re: 1.5 development planning thread
« Reply #13 on: 13 / February / 2016, 18:26:06 »
I'm putting this here only because I'm not sure if the subject deserves an own thread.

Newer DryOS firmwares have a function that can scan a memory heap for corruption (of course the chance of detecting something is not very high as only areas surrounding the malloc'd blocks are checked). The function that checks the malloc heap can be identified by the "refusing to print malloc information" string. The lower level function can be used for other heaps, such as the system heap. I have written identification for the higher level function (malloc), but not yet for the lower level one.

Now, the question: if having something like this in CHDK is considered useful, what kind of interface should it have? The code I have is only called when displaying the CHDK memory information dialog. But I figured it might be useful to make this information available to scripts. But, how?
My other concern is that we have no equivalent for suba (the allocator we're using).
Note: this fw function is not something that should be continuously called because lower level semaphores likely prevent the allocator from working for the time of scan.
Logged
*

Offline reyalp

  • ******
  • 11707
Re: 1.5 development planning thread
« Reply #14 on: 13 / February / 2016, 19:14:43 »
Quote from: srsa_4c on 13 / February / 2016, 18:26:06
Now, the question: if having something like this in CHDK is considered useful, what kind of interface should it have? The code I have is only called when displaying the CHDK memory information dialog. But I figured it might be useful to make this information available to scripts. But, how?
My other concern is that we have no equivalent for suba (the allocator we're using).
This definitely seems like it would be useful for debugging. Even if it's restricted to the canon malloc heap, that could catch a lot of cases. Many ports have enough canon heap to use it for CHDK.

Are there other canon heaps we would want to check? UI memory? Anything else?

For the now, we could have a script function like check_heap_corruption

If we add more heaps later we could use names like get_meminfo, or raw pointers (or allow both).

Quote
Note: this fw function is not something that should be continuously called because lower level semaphores likely prevent the allocator from working for the time of scan.
Assuming it just blocks any allocations until it's done, a define to call it every Nth spytask or kbd_task iteration might be useful. Not on by default but as something you can turn on for test builds. I guess we should also check how long it keeps things locked for.
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 3784
Re: 1.5 development planning thread
« Reply #15 on: 13 / February / 2016, 21:25:02 »
Quote from: reyalp on 13 / February / 2016, 19:14:43
Are there other canon heaps we would want to check? UI memory? Anything else?
The one that could be important is the sys heap (which is where stacks etc. are located).
Some older DryOS revisions had a separate higher level function for that heap too.
Logged
*

Offline srsa_4c

  • ******
  • 3784
Re: 1.5 development planning thread
« Reply #16 on: 20 / February / 2016, 20:30:24 »
I have created an updated, generic version of the E32 fix patch.
I'm not sure if this is something that should be in the official source, mainly because it comes with an 8 byte penalty even when not enabled (the 8 bytes are added due to a required stub, DisableISDriveError).

I have done some experiments and considered adding support for conditional stubs, something like this:
CNHSTUB(DisableISDriveError, 0xffe19918, OPT_DISABLE_CAM_ERROR)
where OPT_DISABLE_CAM_ERROR has the value of 0 or 1, depending on the same named define in buildconf.inc. This line would be emitted by the sigfinder.
The current patch, however, only uses normal NHSTUBs.

Can someone explain the meaning of N and H in NHSTUB? N probably means 'named', but I have no clue about H...

Logged
*

Offline reyalp

  • ******
  • 11707
Re: 1.5 development planning thread
« Reply #17 on: 20 / February / 2016, 21:12:35 »
Quote from: srsa_4c on 20 / February / 2016, 20:30:24
I have created an updated, generic version of the E32 fix patch.
I'm not sure if this is something that should be in the official source, mainly because it comes with an 8 byte penalty even when not enabled (the 8 bytes are added due to a required stub, DisableISDriveError).
I wouldn't worry about that, or about making the stub conditional. If it were a few hundred, maybe.
Quote
Can someone explain the meaning of N and H in NHSTUB? N probably means 'named', but I have no clue about H...
AFAIK H is for "hard". Before the philmoz "new" sigfinder, stubs_entry2.S wasn't parsed, finsig just generated weak NSTUB, and if they were wrong, you overrode them with NHSTUB. This had a size penalty, because the weak ones are still there.
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 3784
Re: 1.5 development planning thread
« Reply #18 on: 21 / February / 2016, 17:21:04 »
Quote from: reyalp on 20 / February / 2016, 21:12:35
I wouldn't worry about that, or about making the stub conditional. If it were a few hundred, maybe.
OK, in that case I'll check in this feature in a few days - it will make creating those "special" builds easier (there are not a lot of those requests, but one had to work on it each occasion).

Quote
AFAIK H is for "hard". Before the philmoz "new" sigfinder, stubs_entry2.S wasn't parsed, finsig just generated weak NSTUB, and if they were wrong, you overrode them with NHSTUB. This had a size penalty, because the weak ones are still there.
I see, thanks. It was confusing for me because NHSTUBs are weak references currently.

A related question: would it be a good idea to put NHSTUB(special_function, NULL_SUB) in stubs_entry.S when special_function is not found?
For example, the previously mentioned (heap corruption check) function does not exist in a number of DryOS firmwares. I can't use a weak, empty function as a replacement because it may override the NHSTUB (I've experienced this while working on the e32 patch).
I could of course put a #define in a number of platform_camera.h files, but I'd prefer to avoid that.
Logged
*

Offline philmoz

  • *****
  • 3071
    • Photos
Re: 1.5 development planning thread
« Reply #19 on: 21 / February / 2016, 17:41:28 »
Quote from: srsa_4c on 21 / February / 2016, 17:21:04
It was confusing for me because NHSTUBs are weak references currently.

Needed to allow them to be overridden - e.g. GetBatteryTemperature crashes on some cameras so it is replaced with a dummy routine in lib.c.

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
Pages: 1 [2] 3 4 5 6 7   Go Up
« previous next »
 

Related Topics