Hi, This is regarding Pi 2 SMP support. After powering on, the secondary mailboxes read one of their four mailbox registers and wait for a non-zero content to be written. This content is to be the physical address of the location from where the cores are expected to start execution.
I am stuck at figuring out this address. How should I go about understanding this? Thanks! On 3 Jun 2015 19:44, "Gedare Bloom" <ged...@gwu.edu> wrote: > On Wed, Jun 3, 2015 at 2:39 AM, Rohini Kulkarni <krohini1...@gmail.com> > wrote: > > But, I can't say cache configurations have a role here. > > > > I'll push my code to my github project soon. > > > > P.S. The Pi2 board I possess seems to have broken down. It just isn't > > turning on. Unable to test further. Will order one immediately. > > > Ouch. Make sure you put it in a safe space for development, clear of > threats like moisture, static shock, and cats. > > > On 3 Jun 2015 09:03, "Rohini Kulkarni" <krohini1...@gmail.com> wrote: > >> > >> Hi, > >> > >> Alan, your suggestion has resulted in much improvement > >> > >> arm_control=0x1000 > >> > >> This has simply worked! Looks like the other cores were taking up plenty > >> of time. > >> I was aware from references that the other cores run a WFI, but ya, did > >> not get its impact. > >> Time for each dhrystone has reduced to 7 from 13 and the no of > dhrystones > >> per second also increased. > >> > >> But this is a change only in the config.txt not actually in the boot > code. > >> > >> Thanks > >> > >> Rohini > >> > >> > >> > >> On Wed, Jun 3, 2015 at 7:12 AM, Alan Cudmore <alan.cudm...@gmail.com> > >> wrote: > >>> > >>> The caches are being enabled on the RPI 1 BSP. The same code is being > >>> executed by the RPI 2 BSP, but obviously it’s not sufficient for the > cache > >>> setup. > >>> I have been reading through this long thread, and it is very > informative: > >>> https://www.raspberrypi.org/forums/viewtopic.php?f=72&t=98904 > >>> > >>> I am starting to understand the setup that is required to enable caches > >>> on the RPI 2. For example this message near the bottom of page 3 gives > a > >>> good indication of the speedup available by configuring the MMU and > caches > >>> correctly: > >>> Quote from above thread > >>> ------------------------------ > >>> Enabling I/D caches and branch prediction, just like the julia demo > uses, > >>> it takes ~12 seconds, or ~21 fps. It's just one core but also a much > smaller > >>> loop than the julia demo has. > >>> > >>> Enabling the MMU and mapping memory inner/outer write-back, write > >>> allocate and the framebuffer inner write-through, no write allocate + > outer > >>> write-back, write-allocate it takes ~8 seconds, of 32 fps. > >>> > >>> PS: 640x480x32 with MMU gets me ~256 fps. Must have a greater L2 cache > >>> effect. > >>> ------------------------- > >>> End of quote > >>> > >>> The person who posted the above comment (mrvn) posted the code here: > >>> https://github.com/mrvn/test/blob/master/mmu.cc > >>> > >>> > >>> Also, it seems that when the Pi 2 starts up, cores 1-3 are put in a > wait > >>> loop always accessing the bus. By putting this option in the > config.txt file > >>> you can put the other cores to sleep, speeding up the code on core 1. > >>> arm_control=0x1000 > >>> It would be worth trying that option to see if the benchmark speeds up. > >>> > >>> > >>> Alan > >>> > >>> On Jun 2, 2015, at 8:05 AM, Hesham ALMatary <heshamelmat...@gmail.com> > >>> wrote: > >>> > >>> On Tue, Jun 2, 2015 at 12:41 PM, Rohini Kulkarni < > krohini1...@gmail.com> > >>> wrote: > >>> > >>> From what I saw, they have to be enabled separately. Cache/mmu are > >>> disabled > >>> upon reset. > >>> > >>> For the existing Raspberry BSP [1] there's a code for MMU/Cache init, > >>> however I don't know about Pi2 and where its code is. > >>> > >>> [1] > >>> > https://github.com/RTEMS/rtems/tree/master/c/src/lib/libbsp/arm/raspberrypi > >>> > >>> On 2 Jun 2015 16:59, "Hesham ALMatary" <heshamelmat...@gmail.com> > wrote: > >>> > >>> > >>> 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 > >>> > >>> > >>> > >>> > >>> -- > >>> Hesham > >>> _______________________________________________ > >>> devel mailing list > >>> devel@rtems.org > >>> http://lists.rtems.org/mailman/listinfo/devel > >>> > >>> > >> > >> > >> > >> -- > >> Rohini Kulkarni > > > > > > _______________________________________________ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel