Abhinav, Attempt to reproduce the reported problem, try out the patch and see if it works. I see this was reported for 4.10. See if the problem also affects 4.11, master, and if the fix works for them too.
Gedare On Mon, Feb 12, 2018 at 11:55 AM, Abhinav Jain <jainab.2...@gmail.com> wrote: > Sir, > > I have gone through the projects available in the link provided by you and I > am interested in an issue (RSB can sometimes change the wrong local git > repository (includes a fix).) listed there. > Link: https://devel.rtems.org/ticket/2522#no1 > I request you to please provide some more information regarding this so that > I can proceed with the coding part. > > Thanks and Regards > Abhinav Jain > > On Wed, Feb 7, 2018 at 9:12 AM, Abhinav Jain <jainab.2...@gmail.com> wrote: >> >> Sir, >> >> Thanks a lot for the guidance. I will start with contributing to an >> existing project. >> >> Thanks and Regards >> Abhinav jain >> >> On Feb 6, 2018 10:55 PM, "Gedare Bloom" <ged...@rtems.org> wrote: >>> >>> Hello Abhinav Jain, >>> >>> It is good that you are studying. Now, you should pursue two paths: >>> 1. Produce some code for RTEMS, perhaps by fixing a bug. A good place >>> to start is the tickets on the open releases: >>> >>> https://devel.rtems.org/query?status=assigned&status=accepted&status=reopened&group=status&milestone=4.11.3 >>> >>> https://devel.rtems.org/query?status=accepted&status=assigned&status=new&status=reopened&milestone=4.10.3&group=status&order=priority >>> >>> 2. Prepare your project idea. You will want to convert your learning >>> into a concrete, achievable plan for code that can be implemented in >>> RTEMS and will be beneficial to someone. >>> >>> Gedare >>> >>> On Tue, Feb 6, 2018 at 10:23 AM, Abhinav Jain <jainab.2...@gmail.com> >>> wrote: >>> > Sir, >>> > >>> > I have studied about SASOS. It's really a great approach to make the >>> > process >>> > faster by avoiding multiple copies of the data. I read about two SASOS >>> > namely Angel system(developed at City University, London) and Mungi >>> > system(developed by University of New South Wales, Australia). I also >>> > studied about Memory Protection in SASOS, where the concept of address >>> > protection is replaced by protection domain. I studied about >>> > Multithreading, >>> > POSIX, Race condition and Synchronization to avoid the Race condition. >>> > Please guide me, am I on the right path and what all do I need to >>> > learn >>> > further? >>> > >>> > Thanks and Regards >>> > Abhinav Jain >>> > >>> > On Wed, Jan 31, 2018 at 11:17 PM, Abhinav Jain <jainab.2...@gmail.com> >>> > wrote: >>> >> >>> >> Sir, >>> >> >>> >> Thanks for the guidance. The mail is very informative and I will >>> >> follow >>> >> the way suggested by you. >>> >> >>> >> Thanks and regards >>> >> Abhinav Jain >>> >> >>> >> On Jan 31, 2018 5:41 PM, "Sebastian Huber" >>> >> <sebastian.hu...@embedded-brains.de> wrote: >>> >>> >>> >>> The MMU support is a very challenging project. The scope of the >>> >>> project >>> >>> and potential use cases must be determined. You need a lot of >>> >>> experience to >>> >>> design good APIs and it helps if you know the APIs for this kind of >>> >>> stuff on >>> >>> other systems like QNX, Linux, FreeBSD, etc. For the architecture >>> >>> support a >>> >>> lot of background knowledge is required at least on PowerPC, >>> >>> ARMv5..8, >>> >>> SPARC, Nios2, MIPS, etc. For example, changing the TLB1 based MMU >>> >>> during >>> >>> application run-time on PowerPC (including SMP support, cache >>> >>> consistency) >>> >>> is not easy. There are some optimization problems involved if you >>> >>> want to >>> >>> determine a good cover with memory areas (alignment restrictions, >>> >>> limited >>> >>> number of areas in the MMU/MPU if not page based, e.g. 16). >>> >>> >>> >>> -- >>> >>> Sebastian Huber, embedded brains GmbH >>> >>> >>> >>> Address : Dornierstr. 4, D-82178 Puchheim, Germany >>> >>> Phone : +49 89 189 47 41-16 >>> >>> Fax : +49 89 189 47 41-09 >>> >>> E-Mail : sebastian.hu...@embedded-brains.de >>> >>> PGP : Public key available on request. >>> >>> >>> >>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. >>> >>> >>> > > > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
