[rtems commit] Shared MMU initialization for ARM BSPs and RaspberryPi MMU support
Gedare Bloom
gedare at rtems.org
Fri Oct 4 12:57:44 UTC 2013
On Fri, Oct 4, 2013 at 5:58 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> On 2013-10-04 11:07, Hesham Moustafa wrote:
>>
>> On Fri, Oct 4, 2013 at 9:50 AM, Sebastian Huber
>> <sebastian.huber at embedded-brains.de
>> <mailto:sebastian.huber at embedded-brains.de>> wrote:
>>
>> On 2013-10-03 14:49, Gedare Bloom wrote:
>>
>> @@ -87,9 +90,9 @@
>>
>> arm_cp15_start_setup___translation_table_and_enable___mmu_and_cache(
>> arm_cp15_set_domain_access___control(dac);
>> arm_cp15_set_translation___table_base(ttb);
>>
>>
>> - /* Initialize translation table with invalid entries */
>> + /* Initialize translation table with fixed-map read-write
>> entries */
>> for (i = 0; i < ARM_MMU_TRANSLATION_TABLE___ENTRY_COUNT; ++i)
>> {
>>
>> - ttb [i] = 0;
>> + ttb [i] = (i << ARM_MMU_SECT_BASE_SHIFT) |
>> ARMV7_MMU_DATA_READ_WRITE;
>> }
>>
>>
>> What is the reason for this change? I don't think that unconditional
>> read-write access is a good idea.
>>
>> I made this change when I was trying to get RaspberryPi MMU initialization
>> to
>> work.
>
>
> Then it is probably better to fix the memory map description of this
> particular BSP.
>
>
>> Also I thought
>> the default behavior for RTEMS is the unprotected mode, and the new
>> protection
>> (limitation) attributes
>> are new and should be applied when needed (by configuration table at
>> startup or
>> dynamically).
>
>
> Allow everything with explicit deny is very bad design. It should be always
> deny everything with explicit allow.
>
Thanks Sebastian, I agree with everything you say here Hesham, please
revert this to initializing to 0 attributes and fix the raspberrypi
BSP accordingly.
-Gedare
>
> --
> 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
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
More information about the devel
mailing list