When is the raw buffer memory usable for other things?

ProfHankD

20

When is the raw buffer memory usable for other things?

« on: 27 / June / 2017, 15:39:38 »

Advertisements

Is there a way (in compiled C inside CHDK) to determine when it is safe to use the raw buffer as temporary memory?

I've been doing all sorts of evil things involving adding features to CHDK modules, and the biggest problem I have is the lack of memory space. In many cameras, I've found that I can freely use the raw buffer as temporary space provided that I'm not capturing still images. For example, I can use it to buffer image data sampled from the live view feed. However, that doesn't work on all cameras; in particular, it seems like the sx530hs uses some of the raw buffer space for something else? The 115is didn't seem to use the raw buffer for anything but raw still data.

Basically, I'd like to build my own rawmalloc() and rawfree() that temporarily allocate/free raw buffer memory and has rawmalloc() fail if the raw buffer is currently in use for something else. Ideally, if the raw buffer is only partly in use, I'd like to be able to allocate stuff in the parts not being used.

Logged

reyalp

14080

Re: When is the raw buffer memory usable for other things?

« Reply #1 on: 27 / June / 2017, 21:48:59 »

Quote from: ProfHankD on 27 / June / 2017, 15:39:38

Is there a way (in compiled C inside CHDK) to determine when it is safe to use the raw buffer as temporary memory?

I don't know any other than trial and error

In general, the same address space occupied by the raw buffer is used for other things, e.g. live view buffers frequently overlap with it. We only know this happens with live view buffers because we identify those addresses, if the canon firmware uses it for other purposes that could easily go unnoticed.

On cameras that use multiple raw buffers, you might find that only one was used by other stuff.

Have you already maxed out what is available using exmem?

Logged

Don't forget what the H stands for.

ProfHankD

20

Re: When is the raw buffer memory usable for other things?

« Reply #2 on: 28 / June / 2017, 00:03:17 »

I remember using exmem several years ago, and I remember it being a pain... is it still?

On the sx530hs, I really need space for at least TWO copies of a live view frame which is 1080x480, or 518,400 bytes. So, I need about 1MB.

Logged

reyalp

14080

Re: When is the raw buffer memory usable for other things?

« Reply #3 on: 28 / June / 2017, 00:49:00 »

Quote from: ProfHankD on 28 / June / 2017, 00:03:17

I remember using exmem several years ago, and I remember it being a pain... is it still?

It should be a lot less of a pain than trying to use the raw buffer. If it's not configured in your port you have to find some values, but there are lots of exmem enabled ports as examples.

The main complication is that video recording can clobber some of the exmem area. CHDK ports with exmem enabled use EXMEM_HEAP_SKIP to avoid this (the value needs to be found), but if your project doesn't need video recording you could just ignore it.

Using exmem can also cause the super find jpeg quality to stop working.

Quote

On the sx530hs, I really need space for at least TWO copies of a live view frame which is 1080x480, or 518,400 bytes. So, I need about 1MB.

It's pretty likely you can use over a meg of exmem without problems.

Logged

Don't forget what the H stands for.

ProfHankD

20

Re: When is the raw buffer memory usable for other things?

« Reply #4 on: 28 / June / 2017, 07:24:03 »

Yick. I really want a solution that will just work for any CHDK-capable camera.

Although my primary target right now is the sx530hs, I'm also using fleets of elph 160, N, elph 115is, a4000is, and about 6 other models. I don't see exmem support on any of them. I suppose I/my students could add exmem support to all of them, but that still wouldn't take care of the model we don't have. (I believe the exmem support I added years ago was in an A620, and I don't think that the exmem mods ever made it into the regular distribution of CHDK.) The exmem stuff is also a long way to go for 1-3MB; it would be so much nicer to borrow that 24MB raw buffer... which I suppose is also why the Canon firmware does precisely that.

In any case, I definitely need to make sure the mods we're doing this Summer make it into the regular distributions this time....

Logged

philmoz

3450

Re: When is the raw buffer memory usable for other things?

« Reply #5 on: 28 / June / 2017, 07:35:53 »

Quote from: ProfHankD on 28 / June / 2017, 07:24:03

Yick. I really want a solution that will just work for any CHDK-capable camera.

Although my primary target right now is the sx530hs, I'm also using fleets of elph 160, N, elph 115is, a4000is, and about 6 other models. I don't see exmem support on any of them. I suppose I/my students could add exmem support to all of them, but that still wouldn't take care of the model we don't have. (I believe the exmem support I added years ago was in an A620, and I don't think that the exmem mods ever made it into the regular distribution of CHDK.) The exmem stuff is also a long way to go for 1-3MB; it would be so much nicer to borrow that 24MB raw buffer... which I suppose is also why the Canon firmware does precisely that.

In any case, I definitely need to make sure the mods we're doing this Summer make it into the regular distributions this time....

If the raw buffer(s) get used for other purposes then it's most likely just different parts of the firmware re-using the same memory for different buffers - I don't think there is any formal malloc/free space management associated with them.

One option would be to fill them with a known value or pattern, then use various features of the cameras that you expect to need in your application. Periodically test the buffers to see if any blocks have been overwritten. This is how the video conflicts with exmem were discovered and worked around.

Obviously you can't do any image or video capture while running these tests; but you may be able to learn enough to be able to safely use the raw buffers.

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)
g7x2 (1.01a, 1.01b, 1.10b)

ProfHankD

20

Re: When is the raw buffer memory usable for other things?

« Reply #6 on: 28 / June / 2017, 10:18:38 »

Hmm. Changing data used for unknown purposes sounds like a good way to brick a camera.... Suppose I simply checksum blocks?

While I'm at it, I don't see any reason to stop at the end of the framebuffer -- why not do this all the way through EXMEM? Actually, what value will I see for memory locations that don't exist?

I'm thinking about doing a checksum probe to make a file that specifies the usable patch(es) and then reading that to build my own extended malloc/free. That might not be a bad solution.... Could even do the check in two steps, checksum probing first and then, only where the initial probe found safe, changing values and repeating the checksum probe. This could be a very clean way to use that memory space as long as Canon isn't really putting it into their own malloc/free infrastructure....

For the meantime, I've gotten things to work with only a single 1/2MB buffer... but it's a bit messy, requiring more computation and frequent write() calls. By the way, is there any rule for how to make write() as fast as possible -- ideal size, alignment WRT start of file, etc.?

« Last Edit: 28 / June / 2017, 10:20:20 by ProfHankD »

Logged

reyalp

14080

Re: When is the raw buffer memory usable for other things?

« Reply #7 on: 28 / June / 2017, 16:00:17 »

Quote from: ProfHankD on 28 / June / 2017, 10:18:38

Hmm. Changing data used for unknown purposes sounds like a good way to brick a camera.... Suppose I simply checksum blocks?

From experience, actual (permanent) bricking is pretty unlikely. Generally, you'd have to do something that writes to flash or maybe does something bad with MMIO. Of course, there are no guarantees, but in practice a lot of people have shot DNG on ports with the raw buffers not correct, which reverses the entire contents of the buffer. As far as we know, no one in the history of CHDK has bricked a camera this way.

So I personally wouldn't worry too much about writing about 0xDEADBEEF to the entire buffer(s) and then checking it later. You could even do the write from the raw hook, which should be as safe as shooting DNG. You are only worried if it changes later (although it's quite possible jpeg processing destroys part of the buffer, which would leave you with the false impression that some of it was unusable when it was).

But really, implementing exmem is easier.

Quote

By the way, is there any rule for how to make write() as fast as possible -- ideal size, alignment WRT start of file, etc.?

Generally speaking, bigger is better. It's likely like that matching the underlying filesystem and SD card block sizes is also better, but I'm not aware of any rigorous experimental tests under CHDK. It would be interesting to have a test like this.

You can also test the peak bandwidth using something like https://chdk.setepontos.com/index.php?topic=13089.msg132605#msg132605 and then compare what you are getting. If you are within 10% of that, it's probably not worth worrying about trying to optimize.

Quote

Actually, what value will I see for memory locations that don't exist?

IIRC, outside of areas that are mapped to other things (ROM, MMIO etc) or protected by the MPU, you tend to see contents of RAM, with the out of range address bits ignored. So if your camera has 32 megs of RAM, the contents will appear to repeat after 32 megs.

Logged

Don't forget what the H stands for.

philmoz

3450

Re: When is the raw buffer memory usable for other things?

« Reply #8 on: 28 / June / 2017, 18:03:12 »

Quote from: ProfHankD on 28 / June / 2017, 10:18:38

Hmm. Changing data used for unknown purposes sounds like a good way to brick a camera.... Suppose I simply checksum blocks?

While I'm at it, I don't see any reason to stop at the end of the framebuffer -- why not do this all the way through EXMEM? Actually, what value will I see for memory locations that don't exist?

I'm thinking about doing a checksum probe to make a file that specifies the usable patch(es) and then reading that to build my own extended malloc/free. That might not be a bad solution.... Could even do the check in two steps, checksum probing first and then, only where the initial probe found safe, changing values and repeating the checksum probe. This could be a very clean way to use that memory space as long as Canon isn't really putting it into their own malloc/free infrastructure....

For the meantime, I've gotten things to work with only a single 1/2MB buffer... but it's a bit messy, requiring more computation and frequent write() calls. By the way, is there any rule for how to make write() as fast as possible -- ideal size, alignment WRT start of file, etc.?

I've done things to my cameras that goes far beyond this without any ill effects. Messing with RAM may crash the camera; but I think the risk of bricking is low. Of course you should stay away from the memory mapped IO areas.

The initialisation is done during startup - before anything else is using the memory, so you are not overwriting anything important. The raw buffer memory does not get initialised with anything special that I am aware of.

It's the same principal as a checksum; but more efficient - you can stop checking as soon as you detect a changed value, instead of recalculating the entire checksum. You can also detect the extent of the change and find what blocks are still intact. You can see how this is done for EXMEM and ARAM testing in the core/memmgnt.c source.

Implementing EXMEM would be more beneficial for CHDK as a whole, and as reyalp said, may be simpler.

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)
g7x2 (1.01a, 1.01b, 1.10b)

srsa_4c

4451

Re: When is the raw buffer memory usable for other things?

« Reply #9 on: 28 / June / 2017, 21:09:02 »

I'd like to note that I'm planning to make dynamic exmem allocation available for CHDK at some point. (Dynamic = allocating and freeing memory as needed, during runtime, unlike it is done in the exmem hack)
It's not done yet, because some pieces are missing (identifying exmem types by the sigfinder, for example). This would not become integral part of malloc(), due to its potential issues and side effects (JPEG quality, conflicting video buffers, and more).

For now, exmem can be dynamically allocated using event procedures like Exmem.AllocCacheable, Exmem.FreeCacheable, Exmem.AllocUncacheable, Exmem.FreeUncacheable. Of course, the previously mentioned video buffers still affect (parts of) the allocated exmem - so it still needs to be tested for corruption. These event procedures allocate a certain type of exmem, and might fail on ports with permanent exmem allocation (override OPT_EXMEM_MALLOC=1).

Logged