<div dir="ltr">Great news on the Pi 2 cache configuration!<div>I am looking forward to a patch to try.</div><div><br></div><div>Alan</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jun 21, 2015 at 3:27 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">:)<br>
There is very little code that had to be added. <br>
I need to clean the code and add conditional call for Pi 2. Then I would be ready to submit a patch. <br>
</p><div class="HOEnZb"><div class="h5">
<div class="gmail_quote">On 22 Jun 2015 00:52, "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 Sun, Jun 21, 2015 at 3:04 PM, Rohini Kulkarni <<a href="mailto:krohini1593@gmail.com" target="_blank">krohini1593@gmail.com</a>> wrote:<br>
> I missed mentioning the number of dhrystones in the previous mail.<br>
><br>
> Originally it was 1 million.<br>
> The new number of dhrystones I executed is 100 million.<br>
><br>
The next thing to do is to figure out what changes are contributing to<br>
the performance improvement, and then prepare patches. :) Great work<br>
<br>
> On Mon, Jun 22, 2015 at 12:29 AM, Rohini Kulkarni <<a href="mailto:krohini1593@gmail.com" target="_blank">krohini1593@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Hi all,<br>
>><br>
>> I have managed to get a significant performance improvement with some<br>
>> changes in configurations.<br>
>><br>
>> The measured time was for dhrystones reduced from 12 to "too small to be<br>
>> measured "<br>
>><br>
>> For dhrystones the time was 0.4.<br>
>><br>
>> The number of dhrystones per second increased from approximately 83333 to<br>
>> 2500000 :)<br>
>><br>
>> Thanks!<br>
>><br>
>> On Sun, Jun 21, 2015 at 1:32 AM, Rohini Kulkarni <<a href="mailto:krohini1593@gmail.com" target="_blank">krohini1593@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> Hi,<br>
>>><br>
>>> I have added an SMP related post to my blog to define where exactly in<br>
>>> the code I need to work. Some feedback to indicate if I am identifying the<br>
>>> work area correctly would be very helpful!<br>
>>><br>
>>> Thanks!<br>
>>><br>
>>> On 18 Jun 2015 03:37, "Rohini Kulkarni" <<a href="mailto:krohini1593@gmail.com" target="_blank">krohini1593@gmail.com</a>> wrote:<br>
>>>><br>
>>>> Hi all,<br>
>>>><br>
>>>> I have updated my blog to reflect my understanding and attempts for<br>
>>>> cache performance issue.<br>
>>>><br>
>>>> Lately I have been trying around memory attributes for the<br>
>>>> mm_config_table. One set of configurations for cacheable memory (inner and<br>
>>>> outer levels)ended up reducing performance further ( which I really thought<br>
>>>> would improve). So this table set up certainly controls performance.<br>
>>>><br>
>>>> The results are not improving after turning on cache. So memory sections<br>
>>>> are perhaps not even getting cached.<br>
>>>> I get a feeling it has got to do with this mm_config_table.<br>
>>>><br>
>>>> Updates from the github code and blog might help in further discussion.<br>
>>>><br>
>>>> Link to github code:<a href="https://github.com/krohini1593/rtems/tree/rohini" rel="noreferrer" target="_blank">https://github.com/krohini1593/rtems/tree/rohini</a><br>
>>>><br>
>>>> Link to Blog<br>
>>>><br>
>>>> Thanks!<br>
>>>><br>
>>>> On Mon, Jun 15, 2015 at 8:29 PM, Alan Cudmore <<a href="mailto:alan.cudmore@gmail.com" target="_blank">alan.cudmore@gmail.com</a>><br>
>>>> wrote:<br>
>>>>><br>
>>>>> Hi,<br>
>>>>> Some of the code examples may give you some clues. Like this one:<br>
>>>>> <a href="https://github.com/mrvn/test/blob/master/smp.cc" rel="noreferrer" target="_blank">https://github.com/mrvn/test/blob/master/smp.cc</a><br>
>>>>><br>
>>>>> Or this:<br>
>>>>> <a href="https://github.com/PeterLemon/RaspberryPi/tree/master/SMP/SMPINIT" rel="noreferrer" target="_blank">https://github.com/PeterLemon/RaspberryPi/tree/master/SMP/SMPINIT</a><br>
>>>>><br>
>>>>> If you still can't figure it out, you can always join the<br>
>>>>> <a href="http://raspberrypi.org" rel="noreferrer" target="_blank">raspberrypi.org</a> forums and ask on this thread:<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>
>>>>> When it comes to the Pi 2 and SMP, you are our RTEMS expert :)<br>
>>>>><br>
>>>>> Thanks,<br>
>>>>> Alan<br>
>>>>><br>
>>>>><br>
>>>>> On Sat, Jun 13, 2015 at 2:29 PM, Rohini Kulkarni<br>
>>>>> <<a href="mailto:krohini1593@gmail.com" target="_blank">krohini1593@gmail.com</a>> wrote:<br>
>>>>>><br>
>>>>>> Hi,<br>
>>>>>><br>
>>>>>> This is regarding Pi 2 SMP support. After powering on, the secondary<br>
>>>>>> mailboxes read one of their four mailbox registers and wait for a non-zero<br>
>>>>>> content to be written. This content is to be the physical address of the<br>
>>>>>> location from where the cores are expected to start execution.<br>
>>>>>><br>
>>>>>> I am stuck at figuring out this address. How should I go about<br>
>>>>>> understanding this?<br>
>>>>>><br>
>>>>>> Thanks!<br>
>>>>>><br>
>>>>>> On 3 Jun 2015 19:44, "Gedare Bloom" <<a href="mailto:gedare@gwu.edu" target="_blank">gedare@gwu.edu</a>> wrote:<br>
>>>>>>><br>
>>>>>>> On Wed, Jun 3, 2015 at 2:39 AM, Rohini Kulkarni<br>
>>>>>>> <<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<br>
>>>>>>> > 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>><br>
>>>>>>> > 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<br>
>>>>>>> >> plenty<br>
>>>>>>> >> of time.<br>
>>>>>>> >> I was aware from references that the other cores run a WFI, but<br>
>>>>>>> >> ya, did<br>
>>>>>>> >> not get its impact.<br>
>>>>>>> >> Time for each dhrystone has reduced to 7 from 13 and the no of<br>
>>>>>>> >> dhrystones<br>
>>>>>>> >> per second also increased.<br>
>>>>>>> >><br>
>>>>>>> >> But this is a change only in the config.txt not actually in the<br>
>>>>>>> >> boot code.<br>
>>>>>>> >><br>
>>>>>>> >> Thanks<br>
>>>>>>> >><br>
>>>>>>> >> Rohini<br>
>>>>>>> >><br>
>>>>>>> >><br>
>>>>>>> >><br>
>>>>>>> >> On Wed, Jun 3, 2015 at 7:12 AM, Alan Cudmore<br>
>>>>>>> >> <<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<br>
>>>>>>> >>> being<br>
>>>>>>> >>> executed by the RPI 2 BSP, but obviously it’s not sufficient for<br>
>>>>>>> >>> the cache<br>
>>>>>>> >>> setup.<br>
>>>>>>> >>> I have been reading through this long thread, and it is very<br>
>>>>>>> >>> 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<br>
>>>>>>> >>> caches<br>
>>>>>>> >>> on the RPI 2. For example this message near the bottom of page 3<br>
>>>>>>> >>> gives a<br>
>>>>>>> >>> good indication of the speedup available by configuring the MMU<br>
>>>>>>> >>> and caches<br>
>>>>>>> >>> correctly:<br>
>>>>>>> >>> Quote from above thread<br>
>>>>>>> >>> ------------------------------<br>
>>>>>>> >>> Enabling I/D caches and branch prediction, just like the julia<br>
>>>>>>> >>> demo uses,<br>
>>>>>>> >>> it takes ~12 seconds, or ~21 fps. It's just one core but also a<br>
>>>>>>> >>> 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<br>
>>>>>>> >>> 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<br>
>>>>>>> >>> cache<br>
>>>>>>> >>> effect.<br>
>>>>>>> >>> -------------------------<br>
>>>>>>> >>> End of quote<br>
>>>>>>> >>><br>
>>>>>>> >>> The person who posted the above comment (mrvn) posted the code<br>
>>>>>>> >>> 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<br>
>>>>>>> >>> a wait<br>
>>>>>>> >>> loop always accessing the bus. By putting this option in the<br>
>>>>>>> >>> config.txt file<br>
>>>>>>> >>> you can put the other cores to sleep, speeding up the code on<br>
>>>>>>> >>> core 1.<br>
>>>>>>> >>>  arm_control=0x1000<br>
>>>>>>> >>> It would be worth trying that option to see if the benchmark<br>
>>>>>>> >>> speeds up.<br>
>>>>>>> >>><br>
>>>>>>> >>><br>
>>>>>>> >>> Alan<br>
>>>>>>> >>><br>
>>>>>>> >>> On Jun 2, 2015, at 8:05 AM, Hesham ALMatary<br>
>>>>>>> >>> <<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<br>
>>>>>>> >>> <<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<br>
>>>>>>> >>> are<br>
>>>>>>> >>> disabled<br>
>>>>>>> >>> upon reset.<br>
>>>>>>> >>><br>
>>>>>>> >>> For the existing Raspberry BSP [1] there's a code for MMU/Cache<br>
>>>>>>> >>> init,<br>
>>>>>>> >>> however I don't know about Pi2 and where its code is.<br>
>>>>>>> >>><br>
>>>>>>> >>> [1]<br>
>>>>>>> >>><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>><br>
>>>>>>> >>> wrote:<br>
>>>>>>> >>><br>
>>>>>>> >>><br>
>>>>>>> >>> Hi,<br>
>>>>>>> >>><br>
>>>>>>> >>> Aren't the MMU/Caches enabled by default for RPi [1]?<br>
>>>>>>> >>><br>
>>>>>>> >>> [1]<br>
>>>>>>> >>><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<br>
>>>>>>> >>> <<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<br>
>>>>>>> >>> 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<br>
>>>>>>> >>> possible<br>
>>>>>>> >>> you did something but didn't actually turn the cache (or all the<br>
>>>>>>> >>> 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>><br>
>>>>>>> >>> wrote:<br>
>>>>>>> >>><br>
>>>>>>> >>> I have not run it under linux on pi2 yet. Will have to run and<br>
>>>>>>> >>> 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>><br>
>>>>>>> >>> wrote:<br>
>>>>>>> >>><br>
>>>>>>> >>><br>
>>>>>>> >>><br>
>>>>>>> >>> On June 2, 2015 5:58:33 AM EDT, Rohini Kulkarni<br>
>>>>>>> >>> <<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<br>
>>>>>>> >>> and<br>
>>>>>>> >>> dhrystones run per second decreased.<br>
>>>>>>> >>><br>
>>>>>>> >>> According to this result, things were better with caches<br>
>>>>>>> >>> disabled.<br>
>>>>>>> >>><br>
>>>>>>> >>><br>
>>>>>>> >>> I have been working on this since two days and could not figure<br>
>>>>>>> >>> 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.<br>
>>>>>>> >>> 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<br>
>>>>>>> >>> existing<br>
>>>>>>> >>> ARM multicore bsp codes, zync mainly.<br>
>>>>>>> >>><br>
>>>>>>> >>> 1. There are existing hooks for the raspberry pi. Where should<br>
>>>>>>> >>> 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<br>
>>>>>>> >>> 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<br>
>>>>>>> >>> can be<br>
>>>>>>> >>> as simple as<br>
>>>>>>> >>> a cpp conditional in a .h to select a value or two<br>
>>>>>>> >>> implementations of<br>
>>>>>>> >>><br>
>>>>>>> >>> a<br>
>>>>>>> >>><br>
>>>>>>> >>> single method<br>
>>>>>>> >>> and the Makefile.am picking the right file to build based on the<br>
>>>>>>> >>> board<br>
>>>>>>> >>> variant.<br>
>>>>>>> >>><br>
>>>>>>> >>> The big question to always ask is: Is this specific to the Pi2<br>
>>>>>>> >>> 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<br>
>>>>>>> >>> change? I<br>
>>>>>>> >>> don't know<br>
>>>>>>> >>> but would guess that it didn't.  Each new capability added needs<br>
>>>>>>> >>> that<br>
>>>>>>> >>> added.<br>
>>>>>>> >>><br>
>>>>>>> >>> And any differences need to be analyzed to pick the least<br>
>>>>>>> >>> intrusive<br>
>>>>>>> >>><br>
>>>>>>> >>> way<br>
>>>>>>> >>><br>
>>>>>>> >>> to provide<br>
>>>>>>> >>> alternate implementations. Or enable special code like the Pi2<br>
>>>>>>> >>> 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<br>
>>>>>>> >>> 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<br>
>>>>>>> >>> discussion<br>
>>>>>>> >>> on devel@ should occur to decide the best way to minimize<br>
>>>>>>> >>> duplication.<br>
>>>>>>> >>><br>
>>>>>>> >>> If you end up with a7 specific code, you should follow the<br>
>>>>>>> >>> 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<br>
>>>>>>> >>> needs<br>
>>>>>>> >>> to be done in the hooks. However, being new to such<br>
>>>>>>> >>> implementations, I<br>
>>>>>>> >>> am taking longer to understand the details. Any suggestions that<br>
>>>>>>> >>> 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<br>
>>>>>>> >>> sense.<br>
>>>>>>> >>> When it is unique to a specific BSP **variant** (e.g. Pi vs Pi2),<br>
>>>>>>> >>> then<br>
>>>>>>> >>> you want to find the way to account for the variation in the<br>
>>>>>>> >>> 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>><br>
>>>>>>> >>> wrote:<br>
>>>>>>> >>><br>
>>>>>>> >>><br>
>>>>>>> >>> Hi,<br>
>>>>>>> >>><br>
>>>>>>> >>> Excited to be a part of  this edition of GSoC! Thanks to<br>
>>>>>>> >>> 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<br>
>>>>>>> >>> 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<br>
>>>>>>> >>> 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<br>
>>>>>>> >>> 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<br>
>>>>>>> >>> 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>
>>>>>><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>
>>>>><br>
>>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> --<br>
>>>> Rohini Kulkarni<br>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Rohini Kulkarni<br>
><br>
><br>
><br>
><br>
> --<br>
> Rohini Kulkarni<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>