[GSoC] Defining Memory for MMU page tables at CSB337

[Joel Sherrill]

On 08/06/2012 10:31 AM, Gedare Bloom wrote:
> Whether defined statically or allocated dynamically the access time
> should not differ. The main issue would be whether you would need the
> memory available before bringing up the RTEMS Workspace. I don't think
> this is the case, so you could allocate the region from
> Workspace_Allocate.
If you do it via Workspace_Allocate, then it has to be accounted
for in confdefs.h.

I would recommend simply using malloc().
> All targets support dynamic allocation via malloc. The setting of
> HeapSize=0 is misleading; probably the actual size is determined
> during boot by the BSP's 'get workspace' function. Usually the BSP is
> given the 'rest' of the memory after static sizes for code and data
> are determined, and some BSPs will split this remainder between Heap
> and Workspace (RTEMS kernel internal heap), or will provide a shared
> (unified) heap and workspace that satisfies allocations to each. RTEMS
> Workspace size is bounded based on how the user application configures
> the kernel, so at runtime the BSP can determine how much space to
> reserve for the workspace and give the rest to the C program heap
> (malloc).
0 is defined to mean give all available memory to the C Program Heap.

>
> -Gedare
>
> On Sat, Aug 4, 2012 at 5:14 PM, Hesham Moustafa
> <heshamelmatary at gmail.com>  wrote:
>> I intended to dynamically allocate memory for it, but i thought it would be
>> faster to define an area for lvl2 page tables to access/allocate them
>> faster. I just want to be sure that CSB337 implement malloc. I noticed that
>> line at linker script for CSB337
>>
>> HeapSize = 0;
>>
>> that why i am inquiring about that issue.
>>
>> thanks,
>> Hesham
>>
>>
>> On Sat, Aug 4, 2012 at 11:02 PM, Joel Sherrill<Joel.Sherrill at oarcorp.com>
>> wrote:
>>> Does it have to be placed in the linker script?
>>>
>>> Can you dynamically allocate it as the properly needed size?
>>> ________________________________________
>>> From: rtems-devel-bounces at rtems.org [rtems-devel-bounces at rtems.org] On
>>> Behalf Of Hesham Moustafa [heshamelmatary at gmail.com]
>>> Sent: Saturday, August 04, 2012 7:52 AM
>>> To: rtems-devel at rtems.org
>>> Subject: [GSoC] Defining Memory for MMU page tables at CSB337
>>>
>>> Hi,
>>>
>>> I want to define memory for page tables at CSB337 BSP.
>>>
>>> The following is quoted from lincmds.csb337
>>>
>>> MEMORY {
>>> SDRAM_MMU : ORIGIN = 0x20100000, LENGTH = 16k
>>> SDRAM : ORIGIN = 0x20104000, LENGTH = 15M - 16k
>>> SRAM : ORIGIN = 0x00200000, LENGTH = 16k
>>> NIRVANA : ORIGIN = 0, LENGTH = 0
>>> }
>>>
>>> That only allocate page table for level 1 page table which is 16 k ( each
>>> entry represents 1M page of memory). I'd like to add level 2 page tables to
>>> represent 4k pages. A level-2 page table consists of 256 entry and consumes
>>> 1K of memory and its base address is installed at level-1 page table entry.
>>>
>>> The question is what's the proper size of level-2 page tables to reserve
>>> from memory and what should be its base address (ORIGIN) to be written at
>>> that linker script ?
>>>
>>> Thanks,
>>> Hesham
>>
>>
>> _______________________________________________
>> rtems-devel mailing list
>> rtems-devel at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-devel
>>


-- 
Joel Sherrill, Ph.D.             Director of Research&   Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
     Support Available             (256) 722-9985