chdk in the DIGIC6 world - page 4 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 2 3 [4] 5 6 7 8 9 ... 18   Go Down

chdk in the DIGIC6 world

  • 171 Replies
  • 76313 Views
*

Offline ahull

  • *****
  • 634
Re: chdk in the DIGIC6 world
« Reply #30 on: 07 / November / 2014, 10:17:40 »
Advertisements
Not sure if this is of any interest to everyone, nor if you can make use of it, but if for no other reason than the great visuals involved I thought it worth posting here..

https://www.youtube.com/watch?v=4bM3Gut1hIk

Whether it can be easily applied to Canon Digic 6 firmware or not, I don't know.
Logged
*

Offline srsa_4c

  • ******
  • 4060
Re: chdk in the DIGIC6 world
« Reply #31 on: 28 / December / 2014, 19:14:36 »
Quote from: ahull on 07 / November / 2014, 10:17:40
Whether it can be easily applied to Canon Digic 6 firmware or not, I don't know.
Nice presentation, but I think I'll stick with my stone-age methods :)

I have finally found the third firmware image inside the sx280 102b ROM.
The image starts in ROM @ 0xfc4d350c, it is 0x50ce4 bytes long, it's copied to RAM starting at 0x600000. Its variables are placed after the image, so they are separated from everything else. I haven't been able to find out when and how the image is copied The code that does copying and initing that core is called from the main core's Startup task.. An obviously related, much smaller data block (from 0xfc481208, length 0x1610, seems to be ARM/thumb startup code) is copied to 0xdff00000.
(edited from here on, after some research)
There seems to be larger areas reserved for use by this core (above 0x800000, above 0x900000). The core is probably active but I suspect that its clock is reduced when not doing ... face recognition. The user tasks are: "FaceRecogTask" and "DetRecogT". There are interfacing tasks running on the main core. I don't know how the cores are communicating, it could be through shared memory. This core also has a "ClockSave" task, very likely power management.
The address range that the main core sees as 0xdff00000 seems to be the zero address of this core (and it's probably TCM). This core has no bootloader (of course, would not make any sense), the startup code starts in that TCM.
« Last Edit: 30 / December / 2014, 15:39:30 by srsa_4c »
Logged
*

Offline srsa_4c

  • ******
  • 4060
Re: chdk in the DIGIC6 world
« Reply #32 on: 02 / January / 2015, 22:07:20 »
Integrating DIGIC 6 support into CHDK

I'll try to come up with subjects I need help with.

This ASIC has (2) ARMv7 cores - our current concern is the "main" core that hosts the majority of firmware code including diskboot support, etc.

1) Modules
The ARM cores don't appear to have an FPU, but they do support integer division. Division by zero causes an exception (this can - in theory - be disabled).
This does matter when it comes to module compatibility.
We could probably decide to make modules compatible on all platforms. In this case, we could make integer division functions in DIGIC 6 CHDK core for use by modules. This would enable us to filter out 0 dividers and would cause only little performance hit.

Now, I'm not sure if running code meant to be run on ARMv5 is all the times safe to run on this new core. I used to see some glitches when early versions of the port included arm-elf modules with eabi core (gcc internal functions were present in those modules). Those glitches were probably caused by ABI incompatibility though.

The easiest way is to drop compatibility between DIGIC 6 modules and modules for the old architecture. I'm currently doing this in current versions of the port.

2) Compilation
The port currently relies on some hacky modifications of the build system to make compilation possible. Batch compilation is not supported.
I'm not sure how to do this properly. Should we add another csv file for DIGIC 6 models? Or, should we just add a column to the existing one?
ARMv7 and v5 common core parts have to be compiled separately - should we use a single batch run or separate ones for DIGIC 6 and everything else?
I'm currently using at least 2 #define'd values to switch between arm-elf compilation and arm-none-eabi (the latter means DIGIC 6 support in my current code). This isn't ideal. There should be a single master "switch" somewhere that decides which architecture to compile for.

It's important to note that my current port is compiled as thumb-2 (all parts of CHDK) and the stubs have addresses appropriate to the corresponding fw function (bit0 is 1 for thumb functions).

I appreciate any suggestions.
« Last Edit: 02 / January / 2015, 22:18:21 by srsa_4c »
Logged
*

Offline reyalp

  • ******
  • 12218
Re: chdk in the DIGIC6 world
« Reply #33 on: 03 / January / 2015, 01:55:30 »
Quote from: srsa_4c on 02 / January / 2015, 22:07:20
1) Modules
The ARM cores don't appear to have an FPU, but they do support integer division. Division by zero causes an exception (this can - in theory - be disabled).
This does matter when it comes to module compatibility.
We could probably decide to make modules compatible on all platforms. In this case, we could make integer division functions in DIGIC 6 CHDK core for use by modules. This would enable us to filter out 0 dividers and would cause only little performance hit.
I think if we have code that divides by zero, we should fix it, so unless I'm missing something, getting exceptions is good.

Quote
The easiest way is to drop compatibility between DIGIC 6 modules and modules for the old architecture. I'm currently doing this in current versions of the port.
This seem like the right thing to me, I don't see a really strong reason to try to keep module binaries compatible. I'd expect there to be size and performance advantages to having them in thumb2

Quote
I'm not sure how to do this properly. Should we add another csv file for DIGIC 6 models? Or, should we just add a column to the existing one?
I'm fine with whichever is most convenient. That probably depends on how the questions below are resolved.
Quote
ARMv7 and v5 common core parts have to be compiled separately - should we use a single batch run or separate ones for DIGIC 6 and everything else?
For autobuilds, there should be some target that builds everything, but that could invoke two different batch builds.

Isolating the binaries (.o, flt etc) from each build with an extension (e.g. .o for thumb, .ot2 for thumb2) or sub-directory would probably be a good idea. This is already done for the core .o files already go in the platform subdirectory, so modules and libs would be the main concern.
Logged
Don't forget what the H stands for.
*

Offline philmoz

  • *****
  • 3138
    • Photos
Re: chdk in the DIGIC6 world
« Reply #34 on: 03 / January / 2015, 03:44:58 »
Quote from: reyalp on 03 / January / 2015, 01:55:30
Isolating the binaries (.o, flt etc) from each build with an extension (e.g. .o for thumb, .ot2 for thumb2) or sub-directory would probably be a good idea. This is already done for the core .o files already go in the platform subdirectory, so modules and libs would be the main concern.

Here is a patch of some changes I was playing with a while back - didn't put it in SVN because it did not seem to provide enough benefit then; but might be useful now.

Changes:
- All generated files for modules and libs go into a .o sub-directory (modules/.o, lib/core/.o etc). This includes object files, libraries, .elf, .flt and dump files. The .o sub-directory is set in a macro in makefile.inc - this could be overridden for Thumb2 to put these output files in a different directory.
- main.bin, main.elf, main.bin.dump moved from core to platform/$(PLATFORM)/sub/$(PLATFORMSUB)
- loader makefiles updated to get main.bin from camera directory instead of core.

Looking at this again, I think the whole build system can probably be improved and simplified; but this might help in the meantime.

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)
  g5x (1.00c, 1.01a, 1.01b)
*

Offline waterwingz

  • ******
  • 11939
    • Waterwingz
Re: chdk in the DIGIC6 world
« Reply #35 on: 03 / January / 2015, 08:54:43 »
Quote from: philmoz on 03 / January / 2015, 03:44:58
Looking at this again, I think the whole build system can probably be improved and simplified; but this might help in the meantime.
I asked this a long time ago and I think the answer was "No reason" but I'll ask again.  Why are some .h files in the /include directory and other in /core ?
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline reyalp

  • ******
  • 12218
Re: chdk in the DIGIC6 world
« Reply #36 on: 03 / January / 2015, 15:08:34 »
Phil:
I agree, there's a lot of room to improve the build system. This may be a good opportunity since the Digic 6 stuff will need reorganization, OTOH, I'm find with doing the minimum to make it work.

From your description and a very quick look, I don't see a downside to your patch. It seems like it should pretty much prevent any chance of mixing up object files for different architectures.

It may affect chdkshell since IIRC it has options to store the main.dump / main.bin files.

Quote from: waterwingz on 03 / January / 2015, 08:54:43
Quote from: philmoz on 03 / January / 2015, 03:44:58
Looking at this again, I think the whole build system can probably be improved and simplified; but this might help in the meantime.
I asked this a long time ago and I think the answer was "No reason" but I'll ask again.  Why are some .h files in the /include directory and other in /core ?
I suspect at some point there was a distinction between "private" includes that only belonged to one file (or a logical grouping) vs public interfaces, but if there was it has pretty much been lost. Don't think this matters much for the Digic 6 merge though.
Logged
Don't forget what the H stands for.
*

Offline philmoz

  • *****
  • 3138
    • Photos
Re: chdk in the DIGIC6 world
« Reply #37 on: 03 / January / 2015, 16:39:23 »
Quote from: reyalp on 03 / January / 2015, 15:08:34
It may affect chdkshell since IIRC it has options to store the main.dump / main.bin files.

This change may remove the need to do that since these files are put in the camera/firmware directory.
If you build for multiple cameras it won't overwrite the files with the last one built.

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)
  g5x (1.00c, 1.01a, 1.01b)
*

Offline srsa_4c

  • ******
  • 4060
Re: chdk in the DIGIC6 world
« Reply #38 on: 03 / January / 2015, 17:23:47 »
Quote from: reyalp on 03 / January / 2015, 01:55:30
I think if we have code that divides by zero, we should fix it, so unless I'm missing something, getting exceptions is good.
Found 2 so far. Problem is, I don't know whether fixing those problems will really prevent the condition from happening (there might be code that can still cause it under special conditions).
From user perspective, it is just another source of crashes.
Does scripting have protection against division by zero?

Quote from: reyalp on 03 / January / 2015, 15:08:34
From your description and a very quick look, I don't see a downside to your patch.
Batch builds appear to work fine with this patch.
Logged
*

Offline reyalp

  • ******
  • 12218
Re: chdk in the DIGIC6 world
« Reply #39 on: 03 / January / 2015, 17:53:48 »
Quote from: srsa_4c on 03 / January / 2015, 17:23:47
From user perspective, it is just another source of crashes.
This is true, and would make digic 6 users suffer more for generic bugs. OTOH the behavior from ignoring it probably not correct either.

I suppose it should be possible to install our own exception handler, and possibly even figure out if it happened in one of our tasks or script.
Quote
Does scripting have protection against division by zero?
Lua doesn't, not sure how hard it would be to retrofit. Normal Lua on a PC gives gives  me 1.#inf or similar.

Ubasic doesn't either, looks like it would be pretty easy to add. Terminating the script with divide by 0 would be a good thing.
Logged
Don't forget what the H stands for.
Pages: 1 2 3 [4] 5 6 7 8 9 ... 18   Go Up
« previous next »
 

Related Topics