SMP/MMU updating page tables on realview BSP

[Hesham Moustafa]

On Fri, Jul 5, 2013 at 6:42 PM, Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> On 05/07/13 18:30, Gedare Bloom wrote:
>
>> On Fri, Jul 5, 2013 at 12:11 PM, Hesham Moustafa
>> <heshamelmatary at gmail.com>  wrote:
>>
>>> >Hi,
>>> >
>>> >I am working on a use case for cortex-a9/realview BSP that deals with
>>> page
>>> >tables and MMU. I need your help in gathering the required API and
>>> calls and
>>> >any other details to implement the following case (if applicable) :
>>> >
>>> >1- A thread running on a core that updates the page table.
>>> >2- On another core another thread is running and trying to update the
>>> page
>>> >table.
>>> >
>>> >Is that use case possible, or disabling dispatches, MMU, and interrupts
>>> >avoids that situation ?
>>> >
>>>
>> I think this is a possible situation. I suppose right now the page
>> tables are statically initialized by a boot processor, but if you
>> enable dynamically modifying the page table, then you need to protect
>> that memory somehow. Probably with a spin lock.
>>
>>
> Currently the cache and MMU support on the Cortex-A9 BSPs is broken, e.g.
> it doesn't work on real hardware.  We work on this issue, but it will take
> a couple of weeks to get it fixed.
>
> The MMU management on SMP will be hard.  Please read the ARMv7 reference
> manual carefully.
>
> I am reading it currently and trying and try to merge your code into libmm
as part of my GSoC project. This
is my repo that contains the changes [1]. It would be great if you have
sometime to review it.

[1] https://github.com/heshamelmatary/rtems-gsoc2013/tree/low-level-libmm

> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-**brains.de<sebastian.huber at embedded-brains.de>
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20130705/02359d03/attachment-0001.html>