experimental alternate memory allocation

bdasmith

117

Re: experimental alternate memory allocation

« Reply #100 on: 15 / April / 2011, 00:35:01 »

Advertisements

Quote from: f_m_b on 10 / April / 2011, 14:08:13

Quote from: philmoz on 08 / April / 2011, 20:19:47
On the G12 and SX30 OPT_CHDK_IN_EXMEM works for both manual boot (PS.FI2) and auto boot (DISKBOOT.BIN).

Thanks a lot. I've forgotten to change the boot.c file.
Now its work with OPT_CHDK_IN_EXMEM.

If you want to, you can write this info in your 7-point-instructions. ;-)

Next steps are more testing and find out the addresses for sx20 1.02d and 1.00f. :-)

fmb, are you having any problems with the video on your sx20 with the opt_chdk_in_exmem enabled?

Logged

sx20is 1.02d

f_m_b

71

Re: experimental alternate memory allocation

« Reply #101 on: 15 / April / 2011, 18:43:27 »

Quote from: bdasmith on 15 / April / 2011, 00:35:01

fmb, are you having any problems with the video on your sx20 with the opt_chdk_in_exmem enabled?

Hello bdasmith

at the moment i don't have found problems with video and exmem. But if you want to test my local version, i posted on Link

Logged

Greetings Frank
SX20 (1.02b)

bdasmith

117

Re: experimental alternate memory allocation

« Reply #102 on: 15 / April / 2011, 21:35:08 »

Quote from: f_m_b on 15 / April / 2011, 18:43:27

Quote from: bdasmith on 15 / April / 2011, 00:35:01
fmb, are you having any problems with the video on your sx20 with the opt_chdk_in_exmem enabled?

Hello bdasmith

at the moment i don't have found problems with video and exmem. But if you want to test my local version, i posted on Link

i can't use the version you linked since my cam is sx20 1.02d

Logged

sx20is 1.02d

philmoz

3450

Re: experimental alternate memory allocation

« Reply #103 on: 16 / April / 2011, 04:05:15 »

Some new findings with EXMEM.

Discovered some interesting things on the G12 and SX30 while looking through the EXMEM code in the firmware (trying to understand it to work out why the SX20 video doesn't work when it's enabled).

- Most of the firmware calls to allocate exmem use ExMem.AllocUncacheable not ExMem.AllocCacheable.
- ExMem.AllocUncacheable does not allocate the extra 64 bytes that ExMem.AllocCacheable does, it just gives the size asked for.
- The function exmem_alloc_uncacheable can be found by following ExMem.AllocUncacheable the same way exmem_alloc was found.
- Using exmem_alloc_uncacheable in CHDK works on the G12 and SX30 (I cleared the 'uncached' bit from the value returned so there is no performance hit).
- Using exmem_alloc_uncacheable and moving the call to exmem_malloc_init to be after the call to drv_self_unhide in core_spytask fixes the problem of the allocated memory overlapping the video buffer memory on the G12 and SX30. This means there is no need for the EXMEM_HEAP_SKIP hack on these cameras (yay!).

Spoke too soon - only gets it right if starting in playback mode. Starting in record mode and the address is still wrong.

Hope this helps anyone else trying to understand EXMEM.

Phil.

« Last Edit: 16 / April / 2011, 06:14:38 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)
g5x (1.00c, 1.01a, 1.01b)
g7x2 (1.01a, 1.01b, 1.10b)

rudi

129
A590IS_101B, SX260HS_100B

Re: experimental alternate memory allocation

« Reply #104 on: 19 / May / 2011, 15:57:44 »

Thanks to all for your good work and description.

Here is the tested exmem-patch for A590_101b.
MAXRAMADDR I found only with region size on ROM:FFC00048 (value=0x10000031->b11000->32MB). Buffer size is 4MB.

Result on CHDK_IN_EXMEM:
free memory: 3.895.336; chdk size: 298.048; loaded at: 0x1BFFFD0

rudi

trunk668_exmem_A590_101b_patch.diff (2.24 kB - downloaded 64 times.)

Logged

reyalp

14080

Re: experimental alternate memory allocation

« Reply #105 on: 19 / May / 2011, 16:05:29 »

Thanks Rudi.

FWIW, I added exmem_alloc to stubs_entry.S for all vxworks cameras back in http://tools.assembla.com/chdk/changeset/1179

I also confirmed the D10 exmem is corrupted by video recording and needs a similar workaround to other dryos cameras. I have not confirmed whether this is needed in vxworks.

Logged

Don't forget what the H stands for.

rudi

129
A590IS_101B, SX260HS_100B

Re: experimental alternate memory allocation

« Reply #106 on: 19 / May / 2011, 16:30:37 »

Quote from: reyalp on 19 / May / 2011, 16:05:29

I also confirmed the D10 exmem is corrupted by video recording and needs a similar workaround to other dryos cameras. I have not confirmed whether this is needed in vxworks.

I don't found any fails with video recording on A590.
VxWorks: I think the exmem patch from CHDKLover for his A610 works fine.

rudi

Logged

sh1981

169

Re: experimental alternate memory allocation

« Reply #107 on: 24 / May / 2011, 03:17:56 »

Hi,

Probably not relevant here since I dont know if SDM implements experimental alternate memory allocation which is the title of this thread. But I just wanted to let you know that with extended memory in SDM I have no difference in edge overlay, RAW, zebra, and everything else that I've tried so far, except that the Menu image sometimes remains plastered on screen with the extended memory version and it does not happen in the normal version. My conclusion is that extended memory does not make things better, infact in case of the menu, it makes things worse. Just my conclusion so far, still testing.

I have an ixus 105 / SD 1300.

Logged

A proud owner of Canon IXUS 105

reyalp

14080

Re: experimental alternate memory allocation

« Reply #108 on: 24 / May / 2011, 13:37:49 »

Quote from: sh1981 on 24 / May / 2011, 03:17:56

Hi,

Probably not relevant here since I dont know if SDM implements experimental alternate memory allocation which is the title of this thread. But I just wanted to let you know that with extended memory in SDM I have no difference in edge overlay, RAW, zebra, and everything else that I've tried so far, except that the Menu image sometimes remains plastered on screen with the extended memory version and it does not happen in the normal version. My conclusion is that extended memory does not make things better, infact in case of the menu, it makes things worse. Just my conclusion so far, still testing.

I have an ixus 105 / SD 1300.

Your post is very confusing. If you don't even know whether SDM uses this function why are you posting about it here ?

What "extended memory" are you referring to ? How are you enabling/disabling it ?

The only reason to use exmem is to avoid running out of memory. If you aren't running out of memory, there's no reason to use it. It will not make any thing faster or better or change the behavior in any other way, except for not crashing or shutting down because it's out of memory. SDM should be less prone to running out of memory, since it doesn't include lua and some other bloat that appears in normal CHDK builds...

If your menu problem is actually triggered by using exmem, that would indicate that it isn't implemented correctly on your camera. However, it is far more likely that your menu problem is just intermittent and the association with whatever you were changing was coincidental...

Logged

Don't forget what the H stands for.

sh1981

169

Re: experimental alternate memory allocation

« Reply #109 on: 24 / May / 2011, 16:49:15 »

Quote from: reyalp on 24 / May / 2011, 13:37:49

Quote from: sh1981 on 24 / May / 2011, 03:17:56
Hi,

Probably not relevant here since I dont know if SDM implements experimental alternate memory allocation which is the title of this thread. But I just wanted to let you know that with extended memory in SDM I have no difference in edge overlay, RAW, zebra, and everything else that I've tried so far, except that the Menu image sometimes remains plastered on screen with the extended memory version and it does not happen in the normal version. My conclusion is that extended memory does not make things better, infact in case of the menu, it makes things worse. Just my conclusion so far, still testing.

I have an ixus 105 / SD 1300.
Your post is very confusing. If you don't even know whether SDM uses this function why are you posting about it here ?

What "extended memory" are you referring to ? How are you enabling/disabling it ?

The only reason to use exmem is to avoid running out of memory. If you aren't running out of memory, there's no reason to use it. It will not make any thing faster or better or change the behavior in any other way, except for not crashing or shutting down because it's out of memory. SDM should be less prone to running out of memory, since it doesn't include lua and some other bloat that appears in normal CHDK builds...

If your menu problem is actually triggered by using exmem, that would indicate that it isn't implemented correctly on your camera. However, it is far more likely that your menu problem is just intermittent and the association with whatever you were changing was coincidental...

I'm afriad an experienced developer would have to find out for you what kind of extended memory SDM is using, I cannot help you there, sorry. However the menu problem is not intermittent and coincidencial, its very much there and can be reproduced every single time with the extended memory build.

Logged

A proud owner of Canon IXUS 105