Author |
Topic |
|
gr8fln8
1 Posts |
Posted - 06 Dec 2002 : 12:40:13
|
I understand that the bootloader loads the entire nkload.bin image into RAM and then jumps to it. Unfortunately this uses up some available RAM.
Is it possible for CE to execute-in-place from ROM? To do this would require changing, or altogether discarding, the bootloader.
I have a reference which describes how to use PlatformBuilder tools to build a bootloader. But I want to make sure I do it right for the Graphics Master.
I would like to have more RAM available on my system, this is why I want to run CE from ROM. |
|
akidder
1519 Posts |
Posted - 06 Dec 2002 : 15:55:01
|
We've looked into execute in place, but don't currently implement it on our products.
Please contact us with details about your application and we can discuss the options that will best meet your application needs. |
|
|
HBPayne
45 Posts |
Posted - 15 Aug 2006 : 18:15:23
|
We are using BitsyX 4.10.35.
This is somewhat related and I've been ask this by developer here. Is it possible to run DLLs that reside in FlashFX Disk as execute-in-place?
We are getting a lot of "Out of memory" messages even though there is plenty of RAM left. We need to get this fixed. RAM might be about 47 Mb (Program memory) and our application is running 20+ Mb. The Control Panel System Memory says about 32 Mb in use. The interest in XIP is from the theory that we are running out of DLL address space. CE version 3.0 was very bad about this. I don't know if XIP would resolve the DLL address space issue.
What does it take to support XIP? |
|
|
akidder
1519 Posts |
Posted - 15 Aug 2006 : 18:27:52
|
I can see why you came to this conclusion, though I don't know that XIP would solve the problems you're experiencing. My bet is that CE uses the same blocks of system memory whether the image executes from flash or from DRAM. Then again, I don't have any direct knowledge of how/if CE maps memory differently between the image types.
Do you have a way to regularly reproduce the "out of memory" errors? With a little more detail, our application team may have some suggestions about how to resolve these errors.
Feel free to contact us directly, as this is an application issue that might take a bit of digging through to sort out. |
|
|
ctacke
877 Posts |
Posted - 16 Aug 2006 : 09:29:13
|
If you're running out of virtual address space, one of the first things to do is to see if you can do any optimization in your project. One of the typical failure points is DLL loading. By the nature of VirtualAlloc, all blocks of virtual memory reseved are at least 64k, and every DLL that gets loaded requires a call to VirtualAlloc for it's memory space. That means that if you have 10 DLLs in your application, each of which is physically only 4k, they will take up 640k of virtual space. Merging them to one module would bring that down to a single 64k allocation. |
|
|
HBPayne
45 Posts |
Posted - 17 Aug 2006 : 12:07:21
|
Evidently, our problem is more severe than originally thought. Our application is sucking up all available RAM and needing more when doing certain activities.
Therefore, we still have interest in XIP.
|
|
|
|
Topic |
|