experimental alternate memory allocation

reyalp

14110

Re: experimental alternate memory allocation

« Reply #20 on: 03 / January / 2011, 12:10:19 »

Advertisements

Quote from: Bernd R on 03 / January / 2011, 10:42:08

I add the code but i get linker error, suba_init suba_free suba_alloc is not find.I see not code in changesets for this functions

Added file core/suba.c. The assemble link doesn't show adds very clearly.

Also need makefile changes to link it if option is set.

Logged

Don't forget what the H stands for.

reyalp

14110

Re: experimental alternate memory allocation

« Reply #21 on: 03 / January / 2011, 12:13:37 »

Quote from: philmoz on 03 / January / 2011, 02:36:12

Not sure how to do this. If I try and run the exmeminf.lua script while the movie is recording the camera stops responding to any buttons (the recording keeps going; but I have to pull the battery to shutdown).

Even if you aren't using the exmem heap ?

You could try calling the eventprocs directly from C code (in response to a button), but maybe there's some semaphore or something that keeps the calls from working when in movie mode.

Logged

Don't forget what the H stands for.

Bernd R

430

Re: experimental alternate memory allocation

« Reply #22 on: 03 / January / 2011, 13:37:59 »

I get that code booting on IX1000 HS, i get 1.4 megabyte (1482000 bytes) of free ram when i use your define #define EXMEM_HEAP_SIZE (1024*1024*2)

I get boot crash, when last viewed was a videofile.
also i get random crash in camera mode, when i want call canon menu, and crash when i press record button.

i get also crash after longer use in play mode.

I have disable in boot.c always

//if(!_strcmp(tcb->name, "MovieRecord")) tcb->entry = (void*)movie_record_task; //JHARP - Verified name - Sept 5, 2010

@philmoz
>I modified the code to allocate 4MB (exmem_alloc actually gives you 32 bytes more); but not call >suba_init so that CHDK grabs the memory but doesn't use it.
>I then filled this memory (starting @ 0x07BFFFE0) with the 0xDEADBEEF value as suggested.
>I added a check at the start of gui_draw_debug_vals_osd to check all the memory and display the first >value that was not set to 0xDEADBEEF.

can you please upload this testcode ?
then i can add it and look what my camera do.

Edit:

I use 32 megabyte RAM and have 32939280 bytes free

here it work better

here video recording work 2* test, menu do no crash, but on shooting it crash

« Last Edit: 03 / January / 2011, 13:54:20 by Bernd R »

Logged

Ixus 1000 HS

philmoz

3450

Re: experimental alternate memory allocation

« Reply #23 on: 03 / January / 2011, 13:54:04 »

Quote from: Bernd R on 03 / January / 2011, 13:37:59

can you please upload this testcode ?
then i can add it and look what my camera do.

In platform\generic\wrappers.c

Code: [Select]

...
#define EXMEM_HEAP_SIZE (1024*1024*4) //allocate 4MB
...
void exmem_malloc_init() {
	// pool zero is EXMEM_RAMDISK on d10
	void *mem = _exmem_alloc(0,EXMEM_HEAP_SIZE,0);
	if(mem) {
		// allocate but don't use mem, fill with test value
		unsigned long *p = (unsigned long*)mem;
		int i;
		for (i=0; i<EXMEM_HEAP_SIZE/4+8; i++) p[i] = 0xDEADBEEF;
		exmem_heap = 0;
		//exmem_heap = suba_init(mem,EXMEM_HEAP_SIZE-EXMEM_HEAP_SKIP,1,1024);
	}
}
...

In core\gui.c

Code: [Select]

...
void gui_draw_debug_vals_osd() {
#ifdef OPT_DEBUGGING
	// check exmem allocated memory for corruption (assumes 4MB allocated)
	unsigned long* p = (unsigned long*)0x07BFFFE0;
	strcpy(osd_buf,"OK");
	unsigned long *f = 0;
	long cnt = 0;
	while (p <= (unsigned long*)0x07FFFFFC)
	{
		if (p[0] != 0xDEADBEEF)
		{
			if (f == 0) f = p;
			cnt++;
		}
		p++;
	}
	if (cnt != 0) sprintf(osd_buf, "%8x %8x %d", &f[0], f[0], cnt);
	draw_txt_string(2, 10, osd_buf, conf.osd_color);
	// end of check	
	if (conf.debug_misc_vals_show) {
...

This allocates 4MB but doesn't use it then fills it with the test value.
In gui.c it will show either OK if no values have changed or the first altered address, its content, and the count of altered addresses.

Regards,
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)

Bernd R

430

Re: experimental alternate memory allocation

« Reply #24 on: 03 / January / 2011, 14:02:27 »

ok, thanks for info i test that tomorrow.

BTW: I test now with 64 megabytes and get 66493712 bytes free.

if the camera have really so much RAM that can use.....

Logged

Ixus 1000 HS

philmoz

3450

Re: experimental alternate memory allocation

« Reply #25 on: 03 / January / 2011, 16:05:09 »

Quote from: Bernd R on 03 / January / 2011, 14:02:27

ok, thanks for info i test that tomorrow.

Forgot to mention you should double check the allocated memory address matches what I have hard wired into gui.c for my test. The addresses in the code I posted earlier work for the SX30 and G12; but may be different on other cameras.

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)

reyalp

14110

Re: experimental alternate memory allocation

« Reply #26 on: 03 / January / 2011, 16:23:33 »

Quote from: Bernd R on 03 / January / 2011, 14:02:27

ok, thanks for info i test that tomorrow.

BTW: I test now with 64 megabytes and get 66493712 bytes free.

if the camera have really so much RAM that can use.....

It doesn't, I'm quite sure. Even if it seems to "work" it's impossible that you would actually be able to take that much memory away from the camera and still have things function normally IMO. Canon would spec less RAM if it wasn't needed.

Logged

Don't forget what the H stands for.

fudgey

1705
a570is

Re: experimental alternate memory allocation

« Reply #27 on: 03 / January / 2011, 16:36:23 »

Quote

Everything that I tried, unrelated to movies, leaves this memory alone.
As soon as I started recording a movie the memory changes from 0x07D08A00, and 748,800 words were changed (2,995,200 bytes).

I also found that if I start the camera in playback mode and select a movie on the card then it alters 345,600 words (1,382,400 bytes) starting at 0x07E5A200.

Working RAM space for the h264 video codec? It could very well need more memory for encoding than for decoding. And h264 certainly requires more frames to be stored in RAM compared to MJPEG, which may make use of the photo JPEG encoder and its memory area (except maybe for the few cameras that can take stills during video).

Do these figures change with video resolution?

Does what's written there look like a bunch of RAW images or does the size appear to be approximately divisible by a suitable number having something to do with video live view, video or sensor readout resolution * bits/pixel * I-frame interval?

Logged

philmoz

3450

Re: experimental alternate memory allocation

« Reply #28 on: 03 / January / 2011, 17:18:49 »

In case anyone's interested here's a memory map I made for myself to help me understand how the address space is organised on the SX30.

Based on this the exmem_alloc available memory would be in the 0x058a0140 - 0x07d089ff block and would have to be < 36.4MB.

The code I posted earlier could be used to find the lowest unused address in this block, I'll experiment with this later.

Phil.

Code: [Select]

=====================================
SX30 memory map (00000000 - ffffffff)
-------------------------------------
00000000
  ...			6,400			6.25K	?
000018ff
00001900
  ...			61,368			59.93K	Initialised data
000108b7
000108b8
  ...			1,509,780		1.44M	Unitialised data
0018124b
0018124c
  ...			2,616,756		2.5M	Heap / stack ? (if have this much why so little reported free (<300K))
  ...									CHDK loads here
003fffff								? Does heap / stack extend all the way to this address ?
00400000
  ...			130,023,424		124M	Buffers (expanded below)
07ffffff
08000000
  ...									Empty ?
3fffffff
40000000
  ...			134,217,728		128M	Uncached copy of 00000000 - 07ffffff
47ffffff
48000000
  ...									Empty ?
bfffffff
c0000000
  ...			?						I/O
????????
????????
  ...									Empty ?
ff80ffff
ff810000
  ...			8,323,072		7.9M	Firmware
ffffffff
=====================================
SX30 memory map (00400000 - 07ffffff) [Buffers]
-------------------------------------
00400000
  ...			32,896,688		31.4M	Buffers
0235f6af
0235f6B0
  ...			21,936,096		20.9M	RAW buffer 1
0384AE8f
0384AE90
  ...			11,967,184		11.4M	Buffers
043b495f
043b4960
  ..			21,936,096		20.9M	RAW buffer 2
058A013f
058A0140
  ...			38,176,960		36.4M	Buffers
07d089ff
07d08a00
  ...			3,110,400		2.96M	Video buffers ?
07ffffff
=====================================

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)

philmoz

3450

Re: experimental alternate memory allocation

« Reply #29 on: 03 / January / 2011, 17:49:25 »

A thought - if we can safely use all this 'exmem' memory why not load CHDK itself into this address space?
That way there would be more memory available to add features and the default camera heap would be left untouched.

Regards,
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)