On the OMAP3530 each core runs it's own OS. The ARM runs Linux.
The DSP runs a special TI OS with the horrible name BIOS. I think TIOS would have been about 1000x better, to avoid confusion for people skimming the documentation for the first (or second, or third) time) There is a special boot loader, u-boot, which tells Linux how much physical memory it is allowed to use. The rest of the memory is split between CMEM and BIOS (and or unallocated). The kernel module `cmem.ko` accesses physical memory, past the size that Linux is aware of, by its physical address with a given size at module load time. To allocate the memory in the CMEM area, I include TI's cmem C library and use their own `alloc_contig` function, which then gives direct access to physical memory which is guaranteed to be physically contiguous. Another kernel module, `dsplink.ko` allows communication between the two OSes. For example, I `contig_alloc()` on the Linux side, but then pass that address to the DSP side so that BIOS knows that both the dsp algorithm and the arm application have shared access to this memory. Otherwise, BIOS would only know about the memory that it has been allocated with (which is setup in special TI makefile-thing for DSP executables). BIOS also uses `malloc()`, but it has the caveat that in their flavor of C, any memory allocation must be done before any executable statement. AJ ONeal On Mon, Aug 23, 2010 at 11:59 AM, Michael Torrie <[email protected]> wrote: > On 08/23/2010 11:56 AM, AJ ONeal wrote: > > My educated guess is that dynamically allocated memory is subject to > > fragmentation (just like a hard drive) and that this could lead to > latency > > in cases where the CPU is spending a few clock cycles performing the > logic > > to physically address the memory 100MB away to get the next bit of > virtual > > memory. > > Unlikely. On CPUS that have virtual memory tables, *every* page access > goes through the virtual memory system. > But the question is does the virtual memory system allow fragmentation? > -------------------- > BYU Unix Users Group > http://uug.byu.edu/ > > The opinions expressed in this message are the responsibility of their > author. They are not endorsed by BYU, the BYU CS Department or BYU-UUG. > ___________________________________________________________________ > List Info (unsubscribe here): http://uug.byu.edu/mailman/listinfo/uug-list >
-------------------- BYU Unix Users Group http://uug.byu.edu/ The opinions expressed in this message are the responsibility of their author. They are not endorsed by BYU, the BYU CS Department or BYU-UUG. ___________________________________________________________________ List Info (unsubscribe here): http://uug.byu.edu/mailman/listinfo/uug-list
