<div dir="ltr">Hi,<div>Some of the code examples may give you some clues. Like this one:</div><div><a href="https://github.com/mrvn/test/blob/master/smp.cc">https://github.com/mrvn/test/blob/master/smp.cc</a><br></div><div><br></div><div>Or this:</div><div><a href="https://github.com/PeterLemon/RaspberryPi/tree/master/SMP/SMPINIT">https://github.com/PeterLemon/RaspberryPi/tree/master/SMP/SMPINIT</a><br></div><div><br></div><div>If you still can't figure it out, you can always join the <a href="http://raspberrypi.org">raspberrypi.org</a> forums and ask on this thread:</div><div><a href="https://www.raspberrypi.org/forums/viewtopic.php?f=72&t=98904">https://www.raspberrypi.org/forums/viewtopic.php?f=72&t=98904</a><br></div><div><br></div><div>When it comes to the Pi 2 and SMP, you are our RTEMS expert :)</div><div><br></div><div>Thanks,</div><div>Alan</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jun 13, 2015 at 2:29 PM, Rohini Kulkarni <span dir="ltr"><<a href="mailto:krohini1593@gmail.com" target="_blank">krohini1593@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Hi,</p>
<p dir="ltr">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. <br></p>
<p dir="ltr">I am stuck at figuring out this address. How should I go about understanding this?</p>
<p dir="ltr">Thanks! </p><div class="HOEnZb"><div class="h5">
<div class="gmail_quote">On 3 Jun 2015 19:44, "Gedare Bloom" <<a href="mailto:gedare@gwu.edu" target="_blank">gedare@gwu.edu</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Jun 3, 2015 at 2:39 AM, Rohini Kulkarni <<a href="mailto:krohini1593@gmail.com" target="_blank">krohini1593@gmail.com</a>> wrote:<br>
> But, I can't say cache configurations have a role here.<br>
><br>
> I'll push my code to my github project soon.<br>
><br>
> P.S. The Pi2 board I possess seems to have broken down. It just isn't<br>
> turning on. Unable to test further. Will order one immediately.<br>
><br>
Ouch. Make sure you put it in a safe space for development, clear of<br>
threats like moisture, static shock, and cats.<br>
<br>
> On 3 Jun 2015 09:03, "Rohini Kulkarni" <<a href="mailto:krohini1593@gmail.com" target="_blank">krohini1593@gmail.com</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> Alan, your suggestion has resulted in much improvement<br>
>><br>
>> arm_control=0x1000<br>
>><br>
>> This has simply worked! Looks like the other cores were taking up plenty<br>
>> of time.<br>
>> I was aware from references that the other cores run a WFI, but ya, did<br>
>> not get its impact.<br>
>> Time for each dhrystone has reduced to 7 from 13 and the no of dhrystones<br>
>> per second also increased.<br>
>><br>
>> But this is a change only in the config.txt not actually in the boot code.<br>
>><br>
>> Thanks<br>
>><br>
>> Rohini<br>
>><br>
>><br>
>><br>
>> On Wed, Jun 3, 2015 at 7:12 AM, Alan Cudmore <<a href="mailto:alan.cudmore@gmail.com" target="_blank">alan.cudmore@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> The caches are being enabled on the RPI 1 BSP. The same code is being<br>
>>> executed by the RPI 2 BSP, but obviously it’s not sufficient for the cache<br>
>>> setup.<br>
>>> I have been reading through this long thread, and it is very informative:<br>
>>> <a href="https://www.raspberrypi.org/forums/viewtopic.php?f=72&t=98904" rel="noreferrer" target="_blank">https://www.raspberrypi.org/forums/viewtopic.php?f=72&t=98904</a><br>
>>><br>
>>> I am starting to understand the setup that is required to enable caches<br>
>>> on the RPI 2. For example this message near the bottom of page 3 gives a<br>
>>> good indication of the speedup available by configuring the MMU and caches<br>
>>> correctly:<br>
>>> Quote from above thread<br>
>>> ------------------------------<br>
>>> Enabling I/D caches and branch prediction, just like the julia demo uses,<br>
>>> it takes ~12 seconds, or ~21 fps. It's just one core but also a much smaller<br>
>>> loop than the julia demo has.<br>
>>><br>
>>> Enabling the MMU and mapping memory inner/outer write-back, write<br>
>>> allocate and the framebuffer inner write-through, no write allocate + outer<br>
>>> write-back, write-allocate it takes ~8 seconds, of 32 fps.<br>
>>><br>
>>> PS: 640x480x32 with MMU gets me ~256 fps. Must have a greater L2 cache<br>
>>> effect.<br>
>>> -------------------------<br>
>>> End of quote<br>
>>><br>
>>> The person who posted the above comment (mrvn) posted the code here:<br>
>>> <a href="https://github.com/mrvn/test/blob/master/mmu.cc" rel="noreferrer" target="_blank">https://github.com/mrvn/test/blob/master/mmu.cc</a><br>
>>><br>
>>><br>
>>> Also, it seems that when the Pi 2 starts up, cores 1-3 are put in a wait<br>
>>> loop always accessing the bus. By putting this option in the config.txt file<br>
>>> you can put the other cores to sleep, speeding up the code on core 1.<br>
>>>  arm_control=0x1000<br>
>>> It would be worth trying that option to see if the benchmark speeds up.<br>
>>><br>
>>><br>
>>> Alan<br>
>>><br>
>>> On Jun 2, 2015, at 8:05 AM, Hesham ALMatary <<a href="mailto:heshamelmatary@gmail.com" target="_blank">heshamelmatary@gmail.com</a>><br>
>>> wrote:<br>
>>><br>
>>> On Tue, Jun 2, 2015 at 12:41 PM, Rohini Kulkarni <<a href="mailto:krohini1593@gmail.com" target="_blank">krohini1593@gmail.com</a>><br>
>>> wrote:<br>
>>><br>
>>> From what I saw, they have to be enabled separately. Cache/mmu are<br>
>>> disabled<br>
>>> upon reset.<br>
>>><br>
>>> For the existing Raspberry BSP [1] there's a code for MMU/Cache init,<br>
>>> however I don't know about Pi2 and where its code is.<br>
>>><br>
>>> [1]<br>
>>> <a href="https://github.com/RTEMS/rtems/tree/master/c/src/lib/libbsp/arm/raspberrypi" rel="noreferrer" target="_blank">https://github.com/RTEMS/rtems/tree/master/c/src/lib/libbsp/arm/raspberrypi</a><br>
>>><br>
>>> On 2 Jun 2015 16:59, "Hesham ALMatary" <<a href="mailto:heshamelmatary@gmail.com" target="_blank">heshamelmatary@gmail.com</a>> wrote:<br>
>>><br>
>>><br>
>>> Hi,<br>
>>><br>
>>> Aren't the MMU/Caches enabled by default for RPi [1]?<br>
>>><br>
>>> [1]<br>
>>><br>
>>> <a href="https://github.com/RTEMS/rtems/blob/master/c/src/lib/libbsp/arm/shared/mminit.c" rel="noreferrer" target="_blank">https://github.com/RTEMS/rtems/blob/master/c/src/lib/libbsp/arm/shared/mminit.c</a><br>
>>><br>
>>> On Tue, Jun 2, 2015 at 12:18 PM, Joel Sherrill<br>
>>> <<a href="mailto:joel.sherrill@oarcorp.com" target="_blank">joel.sherrill@oarcorp.com</a>> wrote:<br>
>>><br>
>>><br>
>>><br>
>>> On June 2, 2015 7:01:21 AM EDT, Rohini Kulkarni <<a href="mailto:krohini1593@gmail.com" target="_blank">krohini1593@gmail.com</a>><br>
>>> wrote:<br>
>>><br>
>>> Dr. Joel,<br>
>>><br>
>>> So we can't say something solely on the basis of this result?<br>
>>><br>
>>><br>
>>> I don't think so. If Linux performs the same, then what you did is as<br>
>>> good as it gets.<br>
>>><br>
>>> However, if Linux is faster then some setting still isn't right.<br>
>>><br>
>>> You need a reference measurement to have any confidence. It is possible<br>
>>> you did something but didn't actually turn the cache (or all the cache)<br>
>>> on.<br>
>>><br>
>>> On 2 Jun 2015 16:28, "Rohini Kulkarni" <<a href="mailto:krohini1593@gmail.com" target="_blank">krohini1593@gmail.com</a>> wrote:<br>
>>><br>
>>> I have not run it under linux on pi2 yet. Will have to run and check<br>
>>> the result.<br>
>>><br>
>>> On 2 Jun 2015 16:16, "Joel Sherrill" <<a href="mailto:joel.sherrill@oarcorp.com" target="_blank">joel.sherrill@oarcorp.com</a>> wrote:<br>
>>><br>
>>><br>
>>><br>
>>> On June 2, 2015 5:58:33 AM EDT, Rohini Kulkarni <<a href="mailto:krohini1593@gmail.com" target="_blank">krohini1593@gmail.com</a>><br>
>>> wrote:<br>
>>><br>
>>> HI,<br>
>>><br>
>>> I tried running the dhrystone benchmark with some changes for<br>
>>><br>
>>> cache/mmu<br>
>>><br>
>>> set up.<br>
>>><br>
>>> However, the output shows a reduction in performance.<br>
>>> The time to run through the dhrystone has increased from 12 to 13 and<br>
>>> dhrystones run per second decreased.<br>
>>><br>
>>> According to this result, things were better with caches disabled.<br>
>>><br>
>>><br>
>>> I have been working on this since two days and could not figure out an<br>
>>> improvement. Any pointers?<br>
>>><br>
>>><br>
>>> How did it do under Linux on the Pi2?<br>
>>><br>
>>><br>
>>> Thanks.<br>
>>><br>
>>><br>
>>><br>
>>> On Thu, May 28, 2015 at 8:41 PM, Rohini Kulkarni<br>
>>> <<a href="mailto:krohini1593@gmail.com" target="_blank">krohini1593@gmail.com</a>> wrote:<br>
>>><br>
>>> Hi All,<br>
>>><br>
>>> I have to implement the cache coherency support for Cortex A7. But for<br>
>>> A7 MPCore, unlike for A9, I am not able to find any register<br>
>>> description for the Snoop Control Unit from the TRM.<br>
>>><br>
>>> I need help here on how to proceed.<br>
>>><br>
>>> Additionally for A9 there is a single bit for A9 in the Auxiliary<br>
>>> Control Register which enables cache broadcast operations. The<br>
>>><br>
>>> register<br>
>>><br>
>>> format is different for A7 and again I am unable to find how to<br>
>>><br>
>>> achieve<br>
>>><br>
>>> the same for A7.<br>
>>><br>
>>> Thanks!<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> On Tue, May 5, 2015 at 10:42 PM, Joel Sherrill<br>
>>> <<a href="mailto:joel.sherrill@oarcorp.com" target="_blank">joel.sherrill@oarcorp.com</a>> wrote:<br>
>>><br>
>>><br>
>>><br>
>>> On 5/5/2015 11:11 AM, Rohini Kulkarni wrote:<br>
>>><br>
>>> Hi,<br>
>>><br>
>>> I am working with the code for bsp hooks. I am referring to existing<br>
>>> ARM multicore bsp codes, zync mainly.<br>
>>><br>
>>> 1. There are existing hooks for the raspberry pi. Where should the<br>
>>><br>
>>> code<br>
>>><br>
>>> for the  Pi2 hooks be added?<br>
>>><br>
>>> The Pi and Pi2 are remarkably similar so Pi2 should be placed inside<br>
>>> the Pi BSP directory.<br>
>>> There is already a Pi2 variant of that code built. But we know<br>
>>><br>
>>> specific<br>
>>><br>
>>> places where there<br>
>>> are variances. Depending on the scope of what is different, it can be<br>
>>> as simple as<br>
>>> a cpp conditional in a .h to select a value or two implementations of<br>
>>><br>
>>> a<br>
>>><br>
>>> single method<br>
>>> and the Makefile.am picking the right file to build based on the board<br>
>>> variant.<br>
>>><br>
>>> The big question to always ask is: Is this specific to the Pi2 and<br>
>>> incompatible with the Pi?<br>
>>><br>
>>> Since the Pi BSP is still missing capabilities, it is likely code<br>
>>> common to both will<br>
>>> be added this summer. For example, did the mailbox interface change? I<br>
>>> don't know<br>
>>> but would guess that it didn't.  Each new capability added needs that<br>
>>> added.<br>
>>><br>
>>> And any differences need to be analyzed to pick the least intrusive<br>
>>><br>
>>> way<br>
>>><br>
>>> to provide<br>
>>> alternate implementations. Or enable special code like the Pi2 SMP<br>
>>> support which<br>
>>> is dependent on --enable-smp and being a Pi2.<br>
>>><br>
>>> 2. Am I right in understanding that I will have to implement A7<br>
>>> specific functions as have been for A9? I am referring specifically to<br>
>>> the arm-a9mpcore-start.h<br>
>>><br>
>>> Yes.<br>
>>><br>
>>> If the code is very similar between the a7 and a9, then a discussion<br>
>>> on devel@ should occur to decide the best way to minimize duplication.<br>
>>><br>
>>> If you end up with a7 specific code, you should follow the location<br>
>>><br>
>>> and<br>
>>><br>
>>><br>
>>> naming patterns already established. That places it in<br>
>>> libbsp/arm/shared/...<br>
>>> so it can be used by any BSP with the right SMP core.<br>
>>><br>
>>><br>
>>> I am referring to existing codes to locate and get hold of what needs<br>
>>> to be done in the hooks. However, being new to such implementations, I<br>
>>> am taking longer to understand the details. Any suggestions that might<br>
>>> help here are welcome<br>
>>><br>
>>> The answer will depend on the factors listed above. When code can<br>
>>> be shared, we want to share it across as many BSPs as makes sense.<br>
>>> When it is unique to a specific BSP **variant** (e.g. Pi vs Pi2), then<br>
>>> you want to find the way to account for the variation in the least<br>
>>> intrusive code way possible.<br>
>>><br>
>>> Thanks!<br>
>>><br>
>>> On 1 May 2015 12:45, "Rohini Kulkarni" <<a href="mailto:krohini1593@gmail.com" target="_blank">krohini1593@gmail.com</a>> wrote:<br>
>>><br>
>>><br>
>>> Hi,<br>
>>><br>
>>> Excited to be a part of  this edition of GSoC! Thanks to everybody for<br>
>>> helping me get here and congratulations to all the participating<br>
>>> students!<br>
>>><br>
>>> So, now getting to work, firstly I wish to know, specifically from my<br>
>>> mentors, any changes that must be made to my proposed project or<br>
>>> schedule.<br>
>>><br>
>>> Secondly, are there any specifics for the development blog that we<br>
>>><br>
>>> need<br>
>>><br>
>>> to create for the project? Over time what is the blog expected to<br>
>>> convey.<br>
>>><br>
>>> Also, I have to create a new wiki page for my project as none exists.<br>
>>><br>
>>> I<br>
>>><br>
>>> want to know how to add one.<br>
>>><br>
>>> --<br>
>>><br>
>>> Rohini Kulkarni<br>
>>><br>
>>><br>
>>> -- Joel Sherrill, Ph.D. Director of Research & Development<br>
>>> joel.sherrill@OARcorp.com On-Line Applications Research Ask me about<br>
>>> RTEMS: a free RTOS Huntsville AL 35805 Support Available (256)<br>
>>><br>
>>> 722-9985<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>><br>
>>> Rohini Kulkarni<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>><br>
>>> Rohini Kulkarni<br>
>>><br>
>>><br>
>>> --joel<br>
>>><br>
>>><br>
>>> --joel<br>
>>> _______________________________________________<br>
>>> devel mailing list<br>
>>> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>>> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Hesham<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Hesham<br>
>>> _______________________________________________<br>
>>> devel mailing list<br>
>>> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>>> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
>>><br>
>>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Rohini Kulkarni<br>
><br>
><br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div>
</div></div><br>_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br></blockquote></div><br></div></div>