Re: [rpi bsp] configure fb section in mmu table and improvement for mailbox

QIAO YANG yangqiao0505 at me.com
Mon Aug 3 20:06:31 UTC 2015



On Aug 03, 2015, at 08:34 AM, QIAO YANG <yangqiao0505 at me.com> wrote:

> On Jul 29, 2015, at 02:03 PM, Chris Johns <chrisj at rtems.org> wrote:
>
>> On 29/07/2015 8:04 pm, Sebastian Huber wrote:
>>>
>>> A custom workspace initialization can be done via
>>> bsp_work_area_initialize().
>>>
>>
>> On the zynq the ethernet driver from Ric (SLAC) for the in tree
>> (existing) IP stack there is:
>>
>> uint8_t* start;
>> size_t size = 0x100000;
>> uintptr_t boundary = (uintptr_t) 0;
>> uintptr_t alignment = (uintptr_t) 0x100000;
>> start = (uint8_t*) rtems_heap_allocate_aligned_with_boundary(size,
>> alignment,
>> boundary);
>> arm_cp15_set_translation_table_entries(start,
>> @start[size],
>> ARMV7_MMU_DEVICE);
>
> The arm_cp15_set_translation_table_entries function does help me to setup MMU entry at runtime.
>
> What exactly means the "boundary"? For exemple, is it possible to allocate the memory with a given start address(memory from 0xC100000 to 0xD100000)? Because in my case, the start address and its length is given by GPU.
>
> Actually, I've got everything worked without heap allocate and I've only setup the entry. Is it normal? I know little about how the memory managed and what happened here. 
 
I couldn't tell the difference between that I add a section in arm_cp15_start_mmu_config_table, then change the start address, end address to the right value, and that I add the entry at runtime. I didn't see any allocation in both ways. Maybe I just need to setup the entry? Or maybe what I've got is an undetermined result. 

>
>
>>
>>
>> This creates an MMU entry at runtime for a 1M aligned block of memory
>> that has the cache disabled.
>>
>> Chris
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20150803/2a521053/attachment-0002.html>


More information about the devel mailing list