Hi, Aren't the MMU/Caches enabled by default for RPi [1]?
[1] https://github.com/RTEMS/rtems/blob/master/c/src/lib/libbsp/arm/shared/mminit.c On Tue, Jun 2, 2015 at 12:18 PM, Joel Sherrill <joel.sherr...@oarcorp.com> wrote: > > > On June 2, 2015 7:01:21 AM EDT, Rohini Kulkarni <krohini1...@gmail.com> wrote: >>Dr. Joel, >> >>So we can't say something solely on the basis of this result? > > I don't think so. If Linux performs the same, then what you did is as good as > it gets. > > However, if Linux is faster then some setting still isn't right. > > You need a reference measurement to have any confidence. It is possible you > did something but didn't actually turn the cache (or all the cache) on. > >>On 2 Jun 2015 16:28, "Rohini Kulkarni" <krohini1...@gmail.com> wrote: >> >>I have not run it under linux on pi2 yet. Will have to run and check >>the result. >> >>On 2 Jun 2015 16:16, "Joel Sherrill" <joel.sherr...@oarcorp.com> wrote: >> >> >> >>On June 2, 2015 5:58:33 AM EDT, Rohini Kulkarni <krohini1...@gmail.com> >>wrote: >>>HI, >>> >>>I tried running the dhrystone benchmark with some changes for >>cache/mmu >>>set up. >>> >>>However, the output shows a reduction in performance. >>>The time to run through the dhrystone has increased from 12 to 13 and >>>dhrystones run per second decreased. >>> >>>According to this result, things were better with caches disabled. >>> >>> >>>I have been working on this since two days and could not figure out an >>>improvement. Any pointers? >> >>How did it do under Linux on the Pi2? >> >> >>>Thanks. >>> >>> >>> >>>On Thu, May 28, 2015 at 8:41 PM, Rohini Kulkarni >>><krohini1...@gmail.com> wrote: >>> >>>Hi All, >>> >>>I have to implement the cache coherency support for Cortex A7. But for >>>A7 MPCore, unlike for A9, I am not able to find any register >>>description for the Snoop Control Unit from the TRM. >>> >>>I need help here on how to proceed. >>> >>>Additionally for A9 there is a single bit for A9 in the Auxiliary >>>Control Register which enables cache broadcast operations. The >>register >>>format is different for A7 and again I am unable to find how to >>achieve >>>the same for A7. >>> >>>Thanks! >>> >>> >>> >>> >>> >>>On Tue, May 5, 2015 at 10:42 PM, Joel Sherrill >>><joel.sherr...@oarcorp.com> wrote: >>> >>> >>> >>>On 5/5/2015 11:11 AM, Rohini Kulkarni wrote: >>> >>>Hi, >>> >>>I am working with the code for bsp hooks. I am referring to existing >>>ARM multicore bsp codes, zync mainly. >>> >>>1. There are existing hooks for the raspberry pi. Where should the >>code >>>for the Pi2 hooks be added? >>> >>>The Pi and Pi2 are remarkably similar so Pi2 should be placed inside >>>the Pi BSP directory. >>>There is already a Pi2 variant of that code built. But we know >>specific >>>places where there >>>are variances. Depending on the scope of what is different, it can be >>>as simple as >>>a cpp conditional in a .h to select a value or two implementations of >>a >>>single method >>>and the Makefile.am picking the right file to build based on the board >>>variant. >>> >>>The big question to always ask is: Is this specific to the Pi2 and >>>incompatible with the Pi? >>> >>>Since the Pi BSP is still missing capabilities, it is likely code >>>common to both will >>>be added this summer. For example, did the mailbox interface change? I >>>don't know >>>but would guess that it didn't. Each new capability added needs that >>>added. >>> >>>And any differences need to be analyzed to pick the least intrusive >>way >>>to provide >>>alternate implementations. Or enable special code like the Pi2 SMP >>>support which >>>is dependent on --enable-smp and being a Pi2. >>> >>>2. Am I right in understanding that I will have to implement A7 >>>specific functions as have been for A9? I am referring specifically to >>>the arm-a9mpcore-start.h >>> >>>Yes. >>> >>>If the code is very similar between the a7 and a9, then a discussion >>>on devel@ should occur to decide the best way to minimize duplication. >>> >>>If you end up with a7 specific code, you should follow the location >>and >>> >>>naming patterns already established. That places it in >>>libbsp/arm/shared/... >>>so it can be used by any BSP with the right SMP core. >>> >>> >>>I am referring to existing codes to locate and get hold of what needs >>>to be done in the hooks. However, being new to such implementations, I >>>am taking longer to understand the details. Any suggestions that might >>>help here are welcome >>> >>>The answer will depend on the factors listed above. When code can >>>be shared, we want to share it across as many BSPs as makes sense. >>>When it is unique to a specific BSP **variant** (e.g. Pi vs Pi2), then >>>you want to find the way to account for the variation in the least >>>intrusive code way possible. >>> >>>Thanks! >>> >>>On 1 May 2015 12:45, "Rohini Kulkarni" <krohini1...@gmail.com> wrote: >>> >>> >>>Hi, >>> >>>Excited to be a part of this edition of GSoC! Thanks to everybody for >>>helping me get here and congratulations to all the participating >>>students! >>> >>>So, now getting to work, firstly I wish to know, specifically from my >>>mentors, any changes that must be made to my proposed project or >>>schedule. >>> >>>Secondly, are there any specifics for the development blog that we >>need >>>to create for the project? Over time what is the blog expected to >>>convey. >>> >>>Also, I have to create a new wiki page for my project as none exists. >>I >>>want to know how to add one. >>> >>>-- >>> >>>Rohini Kulkarni >>> >>> >>>-- Joel Sherrill, Ph.D. Director of Research & Development >>>joel.sherr...@oarcorp.com On-Line Applications Research Ask me about >>>RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) >>722-9985 >>> >>> >>> >>> >>> >>>-- >>> >>>Rohini Kulkarni >>> >>> >>> >>> >>>-- >>> >>>Rohini Kulkarni >> >>--joel > > --joel > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel -- Hesham _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel