Great news on the Pi 2 cache configuration! I am looking forward to a patch to try.
Alan On Sun, Jun 21, 2015 at 3:27 PM, Rohini Kulkarni <krohini1...@gmail.com> wrote: > :) > There is very little code that had to be added. > I need to clean the code and add conditional call for Pi 2. Then I would > be ready to submit a patch. > On 22 Jun 2015 00:52, "Gedare Bloom" <ged...@gwu.edu> wrote: > >> On Sun, Jun 21, 2015 at 3:04 PM, Rohini Kulkarni <krohini1...@gmail.com> >> wrote: >> > I missed mentioning the number of dhrystones in the previous mail. >> > >> > Originally it was 1 million. >> > The new number of dhrystones I executed is 100 million. >> > >> The next thing to do is to figure out what changes are contributing to >> the performance improvement, and then prepare patches. :) Great work >> >> > On Mon, Jun 22, 2015 at 12:29 AM, Rohini Kulkarni < >> krohini1...@gmail.com> >> > wrote: >> >> >> >> Hi all, >> >> >> >> I have managed to get a significant performance improvement with some >> >> changes in configurations. >> >> >> >> The measured time was for dhrystones reduced from 12 to "too small to >> be >> >> measured " >> >> >> >> For dhrystones the time was 0.4. >> >> >> >> The number of dhrystones per second increased from approximately 83333 >> to >> >> 2500000 :) >> >> >> >> Thanks! >> >> >> >> On Sun, Jun 21, 2015 at 1:32 AM, Rohini Kulkarni < >> krohini1...@gmail.com> >> >> wrote: >> >>> >> >>> Hi, >> >>> >> >>> I have added an SMP related post to my blog to define where exactly in >> >>> the code I need to work. Some feedback to indicate if I am >> identifying the >> >>> work area correctly would be very helpful! >> >>> >> >>> Thanks! >> >>> >> >>> On 18 Jun 2015 03:37, "Rohini Kulkarni" <krohini1...@gmail.com> >> wrote: >> >>>> >> >>>> Hi all, >> >>>> >> >>>> I have updated my blog to reflect my understanding and attempts for >> >>>> cache performance issue. >> >>>> >> >>>> Lately I have been trying around memory attributes for the >> >>>> mm_config_table. One set of configurations for cacheable memory >> (inner and >> >>>> outer levels)ended up reducing performance further ( which I really >> thought >> >>>> would improve). So this table set up certainly controls performance. >> >>>> >> >>>> The results are not improving after turning on cache. So memory >> sections >> >>>> are perhaps not even getting cached. >> >>>> I get a feeling it has got to do with this mm_config_table. >> >>>> >> >>>> Updates from the github code and blog might help in further >> discussion. >> >>>> >> >>>> Link to github code:https://github.com/krohini1593/rtems/tree/rohini >> >>>> >> >>>> Link to Blog >> >>>> >> >>>> Thanks! >> >>>> >> >>>> On Mon, Jun 15, 2015 at 8:29 PM, Alan Cudmore < >> alan.cudm...@gmail.com> >> >>>> wrote: >> >>>>> >> >>>>> 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 >> >>>>> >> >>>>> >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Rohini Kulkarni >> >> >> >> >> >> >> >> >> >> -- >> >> Rohini Kulkarni >> > >> > >> > >> > >> > -- >> > 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