Hi, Some of the code examples may give you some clues. Like this one: https://github.com/mrvn/test/blob/master/smp.cc
Or this: https://github.com/PeterLemon/RaspberryPi/tree/master/SMP/SMPINIT If you still can't figure it out, you can always join the raspberrypi.org forums and ask on this thread: https://www.raspberrypi.org/forums/viewtopic.php?f=72&t=98904 When it comes to the Pi 2 and SMP, you are our RTEMS expert :) Thanks, Alan On Sat, Jun 13, 2015 at 2:29 PM, Rohini Kulkarni <krohini1...@gmail.com> wrote: > 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 >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
