Execute Memory - General Discussion and Assistance - CHDK Forum supplierdeeply

Execute Memory

  • 2 Replies
  • 1627 Views
Execute Memory
« on: 22 / January / 2009, 07:05:13 »
Advertisements
Hiya,

I'm testing out a hacky way of external program loading (such as "elf" edition is planning to). Basically I'm compiling a self-contained function (which does nothing, at the moment) with -fPIC and dumping the contents of it to a binary file, which is read by the camera, and loaded into malloc'd memory. However when I attempt to run it, it simply shuts down the camera. Is it possible it has some sort of memory protection, such as linux does?

How would the other shared object loading libraries handle this?

~ns

*

Offline mx3

  • ****
  • 372
Re: Execute Memory
« Reply #1 on: 22 / January / 2009, 10:20:50 »
However when I attempt to run it, it simply shuts down the camera.
maybe your code generated in thumb mode but CHDK in arm ( or vise versa).

Is it possible it has some sort of memory protection, such as linux does?
I dont think so
skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler

*

Offline reyalp

  • ******
  • 13293
Re: Execute Memory
« Reply #2 on: 22 / January / 2009, 17:10:12 »
There is no MMU. There is an MPU, but all RAM is set to read/write. See http://chdk.setepontos.com/index.php/topic,2139.0.html for information about the CPU configuration.

If you are loading code, you need to ensure cache coherency. If you load your code into malloc memory, the instruction cache will not reflect this.

A simple workaround for development would be to use umalloc memory instead. This is uncached, and hence will be very slow, but good enough for testing. See the arm 946e-s reference docs for cache control instructions. You can find useful links in http://chdk.wikia.com/wiki/Developer_Technical_Documents

I suspect that just using fPIC isn't sufficient. At the very lest, you'll need to ensure the pic register is set up correctly. To determine whether this is true, examine the disassembly of your generated binary.

I would suggest you look at how loadable binaries are done in MMU-less linux environments, particularly the ARM ports.
Don't forget what the H stands for.

 

Related Topics