[GSoC] Defining Memory for MMU page tables at CSB337

[Hesham Moustafa]

The problem is that the page table itself must be aligned to 1KB address. I
do not know how malloc is implemented to allocate memory, i hope malloc
allocates memory that its address is multiple of 1KB, otherwise i think i
will have to statically allocate memory for page tables at linker script.

On Mon, Aug 6, 2012 at 11:57 PM, Joel Sherrill <joel.sherrill at oarcorp.com>wrote:

> 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@**
>>> oarcorp.com <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<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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20120807/7b7177e0/attachment.html>