AFAIK tasks' stack space is allocated from the 'system' heap, not the usual 'user' malloc heap.
Is there a 'system' heap for things like this?
Malloc Information (onetime type) Start Address = 0x0016a898 End Address = 0x002f1de0 Total Size = 0x00187548 ( 1602888) Allocated Size = 0x00100f70 ( 1052528) Allocated Peak = 0x00109cb0 ( 1088688) Allocated Count = 0x000001ca ( 458) Free Size = 0x000865d8 ( 550360) Free Block Max Size = 0x0007a7a8 ( 501672) Free Block Count = 0x00000005 ( 5)System Memory Information Start Address = 0x002f9c08 End Address = 0x0034cc00 Total Size = 0x00052ff8 ( 339960) Allocated Size = 0x0003bee0 ( 245472) Allocated Peak = 0x00041f10 ( 270096) Allocated Count = 0x00000048 ( 72) Free Size = 0x00017118 ( 94488) Free Block Max Size = 0x00011470 ( 70768) Free Block Count = 0x00000005 ( 5)
sys_mem_start 0x00559c00sys_mem_max 471040user_mem_start 0x0026b310user_mem_max 3030604sys_objs_start 0x0054f15csys_objs_end 0x00559c00
On elph140sub_675B80 is the low level malloc, sub_675CD0 is the free, and 0x161A0 seems to be the system heap structure. 0x15FC8 is the normal heap structure.These are probably somewhat equivalent the memPart functions in vxworks.
That's good, no need for a dummy task.
Cameras that have sys heap malloc could load the small core, copy the modules to sys heap allocations, and mount them. Their loader will probably need to copy the modules to a temporary 'safe' place like exmem.
Yeah, this could get tricky with startup order, system malloc not available until some time after chdk has been loaded. I guess system malloc must be ready pretty early though.
Not sure about the need to bundle modules into diskboot / ps.fi2.
Quote from: reyalp on 24 / January / 2014, 23:05:35Yeah, this could get tricky with startup order, system malloc not available until some time after chdk has been loaded. I guess system malloc must be ready pretty early though.IMHO it should work by the time the first task is created.QuoteNot sure about the need to bundle modules into diskboot / ps.fi2.If it's possible to separate vital parts of CHDK (say, fonts, strings, GUI - just guessing) into modules then having these modules in files (which may be missing) may not work well.
The CHDK loader would need to include all the module relocation logic in order to move and link the modules. It would need a copy of (or a reference to) the address relocation tables. If you could statically link each piece then it might work; but then they aren't really CHDK modules.At the time the loader code runs, the firmware memory allocation systems have likely been trashed by loading diskboot.bin into memory at 0x1900. So the loader would need pre-determined addresses to put each module into - the location and size of each block would need to be determined by the developer for each port, unless it could be automated somehow with finsig.
It would probably be simpler to split the text/data/bss sections of the code into separate locations as reyalp suggested earlier, using the linker to sort out the addressing. You would still need some way to put different parts in different memory locations in the loader, and work out all the address details during the port.
I think there are still some things in the core CHDK code that might be candidates for modules:- shot histogram- auto iso- usb remote- CHDK menus (and rbf font stuff)
Moving the CHDK menus to a module would save a lot of core memory; but might cause issues for new users if the module is missing or does not match the core version. It also currently has a lot of conditionally compiled code that would need sorting out.
Quote from: philmoz on 25 / January / 2014, 15:37:39The CHDK loader would need to include all the module relocation logic in order to move and link the modules. It would need a copy of (or a reference to) the address relocation tables. If you could statically link each piece then it might work; but then they aren't really CHDK modules.At the time the loader code runs, the firmware memory allocation systems have likely been trashed by loading diskboot.bin into memory at 0x1900. So the loader would need pre-determined addresses to put each module into - the location and size of each block would need to be determined by the developer for each port, unless it could be automated somehow with finsig.I'm not sure if those addresses can be pre-determined.Since I don't know the module loader code well, I have to ask: is additional memory needed for loading a module (I mean, module size + ?) ? Is that additional memory separately allocated, or is it part of the allocated block where the module will be copied? In other words: can the memory size needed to load a module be pre-determined? If so, it could be part of the diskboot/fir, with the correct size - for cameras that are not short of memory. Downside: this would probably increase memory consumed by CHDK, compared to the current state.For cameras with small ARAM area, the loader would copy the modules to exmem, and then they would be loaded by spytask, using sys-malloc. On other cams, spytask could 'load' the modules in-place.Still pretty complicated...
QuoteIt would probably be simpler to split the text/data/bss sections of the code into separate locations as reyalp suggested earlier, using the linker to sort out the addressing. You would still need some way to put different parts in different memory locations in the loader, and work out all the address details during the port.My concern is that even if the location of the sys memory is known, we can't just put data there (for example to the top of that area) and expect it to remain untouched. If the area can be shifted (this will have to be researched, I guess), then this whole discussion is almost pointless (that would be my bad ).
QuoteI think there are still some things in the core CHDK code that might be candidates for modules:- shot histogram- auto iso- usb remote- CHDK menus (and rbf font stuff)The first three look like non-mandatory, the menus and fonts are important.
QuoteMoving the CHDK menus to a module would save a lot of core memory; but might cause issues for new users if the module is missing or does not match the core version. It also currently has a lot of conditionally compiled code that would need sorting out.One of my (distant) plans is a packed CHDK-installer diskboot/fir which includes every needed file.
Started by ledelectronics Feature Requests
Started by philmoz General Discussion and Assistance
Started by Microfunguy « 1 2 » General Discussion and Assistance
Started by BlueChip General Discussion and Assistance
Started by pigeonhill Script Writing