On Fri, Oct 4, 2013 at 5:58 AM, Sebastian Huber <sebastian.hu...@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.hu...@embedded-brains.de >> <mailto:sebastian.hu...@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.hu...@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@rtems.org > http://www.rtems.org/mailman/listinfo/rtems-devel _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
