Re: Small doubt in RTEMS testsuite codes

[Richi Dubey]

Hii ,

Thanks for the help. I am going through the docs you referred and have
submitted a patch for the scheduler's doc, please have a look.

Could you please tell me how do I set up a test environment with GDB
support? Does it just mean running the applications with rtems5-gdb?

On Tue, May 12, 2020 at 1:35 PM Sebastian Huber
 wrote:
>
> On 12/05/2020 09:48, Richi Dubey wrote:
>
> > Heyy Everyone,
> >
> > When I am opening testsuites/sptests/sp01/init.c , I can see the
> > following function definition:
> >
> > rtems_task Init(  rtems_task_argument argument )
> >
> > and when I open testsuites/sptests/sp01/task1.c ( which is
> > compiled(linked) together with init.c in the makefile in build of
> > bsp), I can see the following function:
> >
> > rtems_task Task_1_through_3(  rtems_task_argument index).
> >
> > Can someone please tell me how do the sp01 testsuite run without a int
> > main? If Init() is the start point then where does it gets it argument
> > 'argument' from?
>
> You may have a look at:
>
> https://docs.rtems.org/branches/master/c-user/initialization.html
>
> https://docs.rtems.org/branches/master/c-user/config/index.html
>
> I think your question is not really well answered by our current
> documentation set. While you read the documentation please always try to
> improve it. I you think something is missing or could be better
> explained, then just send patches.
>
> Independent of the documentation you should set up a test environment
> with GDB support. You can set a break point to Init(). This points you
> to the code which determines the argument value.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Small doubt in RTEMS testsuite codes

[Gedare Bloom]

On Fri, May 15, 2020 at 4:22 PM Richi Dubey  wrote:
>
> Hii ,
>
> Thanks for the help. I am going through the docs you referred and have
> submitted a patch for the scheduler's doc, please have a look.
>
> Could you please tell me how do I set up a test environment with GDB
> support? Does it just mean running the applications with rtems5-gdb?
>

It means running a BSP that you are able to debug using gdb. The erc32
running on sis can be debugged using gdb.  Couple of other simulated
targets can also.



> On Tue, May 12, 2020 at 1:35 PM Sebastian Huber
>  wrote:
> >
> > On 12/05/2020 09:48, Richi Dubey wrote:
> >
> > > Heyy Everyone,
> > >
> > > When I am opening testsuites/sptests/sp01/init.c , I can see the
> > > following function definition:
> > >
> > > rtems_task Init(  rtems_task_argument argument )
> > >
> > > and when I open testsuites/sptests/sp01/task1.c ( which is
> > > compiled(linked) together with init.c in the makefile in build of
> > > bsp), I can see the following function:
> > >
> > > rtems_task Task_1_through_3(  rtems_task_argument index).
> > >
> > > Can someone please tell me how do the sp01 testsuite run without a int
> > > main? If Init() is the start point then where does it gets it argument
> > > 'argument' from?
> >
> > You may have a look at:
> >
> > https://docs.rtems.org/branches/master/c-user/initialization.html
> >
> > https://docs.rtems.org/branches/master/c-user/config/index.html
> >
> > I think your question is not really well answered by our current
> > documentation set. While you read the documentation please always try to
> > improve it. I you think something is missing or could be better
> > explained, then just send patches.
> >
> > Independent of the documentation you should set up a test environment
> > with GDB support. You can set a break point to Init(). This points you
> > to the code which determines the argument value.
> >
> ___
> 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

most straightforward linux host development machine for RTEMS

[jmillard]

I'm a linux newbie and picked Centos, somewhat at random. I encounter a
continuing list of mostly small differences and incompatibilities.
Everything builds now. The last and most serious is that qemu is now a
full-featured vm manager and the manual for using it is far beyond what
RTEMS needs. I am sorting through this, but .

 

What linux is middle of the road for RTEMS? Using CygWin and MinGW has its
own issues and I would much rather work on linux.

 

Thanks,

John

 

Where there are tools, a will, and a will to build tools there is a way.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] posix: Get real priority in pthread_getattr_np()

[Sebastian Huber]

On 12/05/2020 07:28, Sebastian Huber wrote:


This is in line with pthread_setschedparam() and
pthread_getschedparam().

Update #2514.

It should be in RTEMS 5 from my point of view.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC: RTEMS directory for FreeBSD imports

[Christian Mauderer]

On 14/05/2020 18:59, Niteesh G. S. wrote:
> On Thu, May 14, 2020 at 4:30 PM Christian Mauderer
>  > wrote:
> 
> On 13/05/2020 20:15, Niteesh G. S. wrote:
> > Hello,
> >
> > This mail is to regain attention for this topic and also to discuss a
> > few details
> > regarding the porting process.
> >
> > In the previous thread, Sebastian mentioned that we will be hard
> wiring
> > the OF
> > functions with the FDT implementation. For reasons please have a
> look at
> > previous thread.
> > https://lists.rtems.org/pipermail/devel/2020-May/059762.html
> > This will be achieved by inlining the functions in openfirm.h with
> functions
> > defined in ofw_fdt.c. This approach is valid for most functions
> but not all.
> > Since not all functions have a one to one mapping.
> >
> > For example,
> >    The OF_peer can be directly mapped to ofw_fdt_peer.
> >    But for OF_getencprop it calls ofw_fdt_getprop after few
> manipulations.
> > Inlining these functions doesn't seem like a good practice for me.
> >
> > One way to approach this would be to add the implementation for these
> > functions in
> > ofw_fdt.c but this would cause code redundancy if we plan to import
> > openfirm.c
> > in future since these functions are already defined in openfirm.c.
> 
> Are the functions exact clones of the the ones in openfirm.c? In that
> case I would suggest to import openfirm.c and put #ifndef __rtems__
> around everything you don't need. Eveni if it means that you only use
> 10% of the file.
> 
> 
> Yes, implementation of the mentioned
> functions(OF_getencprop, OF_getencprop_alloc etc)
> will be a copy of the ones in openfirm.c.
>  
> 
> >
> > Another approach will be to import openfirm.c also and redefine
> the OFW_*
> > macro to directly call the respective functions.
> 
> That sounds like a better aproach.
> 
> 
> We can also call the respective functions directly from the functions in
> openfirm.c
> instead of redefining the OFW_* macro. Which one do you prefer?

I would suggest to use the method that is less invasive. For calling the
functions directly you most likely have to do something like that:

#ifndef __rtems__
OFW_DO_SOMETHING(x, y);
#else /* __rtems__ */
direct_call_to_function(x, y);
#endif

If someone changes the OFW_DO_SOMETHING line and (for example) add
another condition around it that will trigger a conflict on upgrade.

If you add

#ifdef __rtems__
#define OFW_DO_SOMETHING direct_call_to_function
#endif

that will apply fine on an upgrade. So I would use that one.

> 
> I will wait for a couple for everyone to participate in the discussion
> and then start
> implementing it.
> 
> >
> > I don't really know if there is any other better way to approach this.
> > Any suggestion on
> > how to proceed. 
> >
> > Once this is resolved I will proceed with the porting even if we
> haven't
> > finalized the
> > directory since it is just a matter of moving files once we are
> finalized.
> >
> > If you think this is too early to start with coding for GSoC please
> > understand that my
> > university exams haven't been conducted yet. And due to the COVID
> > pandemic, the
> > dates are quite uncertain. But it is mostly expected to happen during
> > the coding period (july/aug)
> > and this would eat up quite a lot of time. So just to be one the safe
> > side I started
> > quite early.
> >
> > Thank,
> > Niteesh.
> >
> > On Mon, May 11, 2020 at 12:48 PM Christian Mauderer
> >  
> >  >> wrote:
> >
> >     On 11/05/2020 09:11, Chris Johns wrote:
> >     > On 11/5/20 4:55 pm, Christian Mauderer wrote:
> >     >> On 11/05/2020 06:57, Chris Johns wrote:
> >     >>>
> >     >>>
> >     >>> On 11/5/20 2:03 pm, Niteesh G. S. wrote:
> >      On Mon, May 11, 2020 at 4:34 AM Chris Johns
> mailto:chr...@rtems.org>
> >     >
> >      
>  >     
> >       On 10/5/20 6:17 pm, Niteesh G. S. wrote:
> >        > This thread is a continuation of "GSoC 2020:
> Implementation
> >      of OFW
> >        > functions".
> >        >
> >        > A summary of points discussed in that thread is given
> >     below.
> >        >
> >        > Below is a short description of my GSoC project.
> For more
> >       information please
> >        >

Re: most straightforward linux host development machine for RTEMS

[Gedare Bloom]

Hi John,

I prefer Ubuntu. I use an LTS release, and they offer upgrade paths
directly from LTS->LTS that seems to work so far. I haven't too much
experience with other distros besides Centos and Fedora. Centos lags a
bit far behind sometimes, with its long release cycles, and can be
challenging to configure as a development environment. Fedora moves
too quick for my taste.

Gedare

On Fri, May 15, 2020 at 4:45 PM  wrote:
>
> I’m a linux newbie and picked Centos, somewhat at random. I encounter a 
> continuing list of mostly small differences and incompatibilities. Everything 
> builds now. The last and most serious is that qemu is now a full-featured vm 
> manager and the manual for using it is far beyond what RTEMS needs. I am 
> sorting through this, but …
>
>
>
> What linux is middle of the road for RTEMS? Using CygWin and MinGW has its 
> own issues and I would much rather work on linux.
>
>
>
> Thanks,
>
> John
>
>
>
> Where there are tools, a will, and a will to build tools there is a way.
>
> ___
> 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

Re: [PATCH] posix: Get real priority in pthread_getattr_np()

[Gedare Bloom]

Yes, please do push this in RTEMS 5. We want this to be consistent.

On Fri, May 15, 2020 at 4:50 PM Sebastian Huber
 wrote:
>
> On 12/05/2020 07:28, Sebastian Huber wrote:
>
> > This is in line with pthread_setschedparam() and
> > pthread_getschedparam().
> >
> > Update #2514.
> It should be in RTEMS 5 from my point of view.
> ___
> 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

Re: Adding fenv support for ARM

[Eshan Dhawan]

On Fri, May 15, 2020 at 2:22 AM Eshan Dhawan 
wrote:

>
>
> On Wed, May 13, 2020 at 7:40 PM Joel Sherrill  wrote:
>
>> National free hint day!!!
>>
>> Look above the line that is reported. You will see __BEGIN_DECL. It isn't
>> defined. It is intended to expand to the __cplusplus wrapper.
>>
>> After you fix this, you will sequentially find 2 other things to change
>> in this file.
>>
>> I have made those changes when a new error occurs from the assembler in
> arm thumb mode
> There is no support for vfp instructions in arm thumb.
>
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0471c/BABGHDBB.html
> So in which file will the compiler instructions given in the page
> 
> added?
>
FreeBSD has added file and architecture-specific flags in their
makefile.inc
https://github.com/freebsd/freebsd/blob/master/lib/msun/arm/Makefile.inc
How will it be added in newlib
I tried adding the flags -mfpu=vfp -mfloat-abi=softfp (used in FreeBSD) to
makefile.in but no effect.

thanks
-Eshan

> Errors :
>
> make[9]: Entering directory
> '/home/eshan/development/newlib/c-arm-rtems5-newlib/arm-rtems5/thumb/newlib/libm/machine/arm'
> arm-rtems5-gcc
> -B/home/eshan/development/newlib/c-arm-rtems5-newlib/arm-rtems5/thumb/newlib/
> -isystem
> /home/eshan/development/newlib/c-arm-rtems5-newlib/arm-rtems5/thumb/newlib/targ-include
> -isystem /home/eshan/development/newlib/newlib-cygwin/newlib/libc/include
>  -mthumb -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
> -DPACKAGE_VERSION=\"3.3.0\" -DPACKAGE_STRING=\"newlib\ 3.3.0\"
> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I.
> -I../../../../../../../newlib-cygwin/newlib/libm/machine/arm -I
> ../../../../../../../newlib-cygwin/newlib/libm/machine/arm/../../../../newlib/libm/common
> -fno-builtin -mfpu=vfpv2 -ffunction-sections -fdata-sections
>  -D_COMPILING_NEWLIB -DCLOCK_PROVIDED -DMALLOC_PROVIDED -DEXIT_PROVIDED
> -DSIGNAL_PROVIDED -DGETREENT_PROVIDED -DREENTRANT_SYSCALLS_PROVIDED
> -DHAVE_NANOSLEEP -DHAVE_BLKSIZE -DHAVE_FCNTL -DHAVE_ASSERT_FUNC
> -D_NO_GETLOGIN -D_NO_GETPWENT -D_NO_GETUT -D_NO_GETPASS -D_NO_SIGSET
> -D_NO_WORDEXP -D_NO_POPEN -D_NO_POSIX_SPAWN -DHAVE_INIT_FINI  -g -O2
>  -mthumb -c -o lib_a-fenv-vfp.o `test -f 'fenv-vfp.c' || echo
> '../../../../../../../newlib-cygwin/newlib/libm/machine/arm/'`fenv-vfp.c
> /tmp/ccEHiFws.s: Assembler messages:
> /tmp/ccEHiFws.s:37: Error: selected processor does not support `vmrs
> r3,fpscr' in Thumb mode
> /tmp/ccEHiFws.s:48: Error: selected processor does not support `vmsr
> fpscr,r3' in Thumb mode
> /tmp/ccEHiFws.s:81: Error: selected processor does not support `vmrs
> r3,fpscr' in Thumb mode
> /tmp/ccEHiFws.s:119: Error: selected processor does not support `vmrs
> r3,fpscr' in Thumb mode
> /tmp/ccEHiFws.s:134: Error: selected processor does not support `vmsr
> fpscr,r3' in Thumb mode
> /tmp/ccEHiFws.s:169: Error: selected processor does not support `vmrs
> r3,fpscr' in Thumb mode
> /tmp/ccEHiFws.s:182: Error: selected processor does not support `vmsr
> fpscr,r3' in Thumb mode
> /tmp/ccEHiFws.s:217: Error: selected processor does not support `vmrs
> r3,fpscr' in Thumb mode
> /tmp/ccEHiFws.s:251: Error: selected processor does not support `vmrs
> r0,fpscr' in Thumb mode
> /tmp/ccEHiFws.s:288: Error: selected processor does not support `vmrs
> r3,fpscr' in Thumb mode
> /tmp/ccEHiFws.s:303: Error: selected processor does not support `vmsr
> fpscr,r0' in Thumb mode
> /tmp/ccEHiFws.s:340: Error: selected processor does not support `vmrs
> r3,fpscr' in Thumb mode
> /tmp/ccEHiFws.s:374: Error: selected processor does not support `vmrs
> r3,fpscr' in Thumb mode
> /tmp/ccEHiFws.s:390: Error: selected processor does not support `vmsr
> fpscr,r3' in Thumb mode
> /tmp/ccEHiFws.s:424: Error: selected processor does not support `vmsr
> fpscr,r3' in Thumb mode
> /tmp/ccEHiFws.s:457: Error: selected processor does not support `vmrs
> r1,fpscr' in Thumb mode
> /tmp/ccEHiFws.s:466: Error: selected processor does not support `vmsr
> fpscr,r3' in Thumb mode
> /tmp/ccEHiFws.s:478: Error: selected processor does not support `vmrs
> r2,fpscr' in Thumb mode
> /tmp/ccEHiFws.s:503: Error: selected processor does not support `vmsr
> fpscr,r3' in Thumb mode
> /tmp/ccEHiFws.s:543: Error: selected processor does not support `vmrs
> r0,fpscr' in Thumb mode
> /tmp/ccEHiFws.s:559: Error: selected processor does not support `vmsr
> fpscr,r3' in Thumb mode
> /tmp/ccEHiFws.s:595: Error: selected processor does not support `vmrs
> r3,fpscr' in Thumb mode
> /tmp/ccEHiFws.s:612: Error: selected processor does not support `vmsr
> fpscr,r2' in Thumb mode
> /tmp/ccEHiFws.s:647: Error: selected processor does not support `vmrs
> r3,fpscr' in Thumb mode
> Makefile:476: recipe for target 'lib_a-fenv-vfp.o' failed
> make[9]: *** [lib_a-fenv-vfp.o] Error 1
> make[9]: Leaving directory
> '/home/eshan/development/newlib/c-arm-rtems5-newlib/arm-rtems5/thumb/newlib/lib

Re: GSoC: RTEMS directory for FreeBSD imports

[Niteesh G. S.]

On Thu, May 14, 2020 at 4:30 PM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> On 13/05/2020 20:15, Niteesh G. S. wrote:
> > Hello,
> >
> > This mail is to regain attention for this topic and also to discuss a
> > few details
> > regarding the porting process.
> >
> > In the previous thread, Sebastian mentioned that we will be hard wiring
> > the OF
> > functions with the FDT implementation. For reasons please have a look at
> > previous thread.
> > https://lists.rtems.org/pipermail/devel/2020-May/059762.html
> > This will be achieved by inlining the functions in openfirm.h with
> functions
> > defined in ofw_fdt.c. This approach is valid for most functions but not
> all.
> > Since not all functions have a one to one mapping.
> >
> > For example,
> >The OF_peer can be directly mapped to ofw_fdt_peer.
> >But for OF_getencprop it calls ofw_fdt_getprop after few
> manipulations.
> > Inlining these functions doesn't seem like a good practice for me.
> >
> > One way to approach this would be to add the implementation for these
> > functions in
> > ofw_fdt.c but this would cause code redundancy if we plan to import
> > openfirm.c
> > in future since these functions are already defined in openfirm.c.
>
> Are the functions exact clones of the the ones in openfirm.c? In that
> case I would suggest to import openfirm.c and put #ifndef __rtems__
> around everything you don't need. Eveni if it means that you only use
> 10% of the file.
>

Yes, implementation of the mentioned
functions(OF_getencprop, OF_getencprop_alloc etc)
will be a copy of the ones in openfirm.c.


> >
> > Another approach will be to import openfirm.c also and redefine the OFW_*
> > macro to directly call the respective functions.
>
> That sounds like a better aproach.
>

We can also call the respective functions directly from the functions in
openfirm.c
instead of redefining the OFW_* macro. Which one do you prefer?

I will wait for a couple for everyone to participate in the discussion and
then start
implementing it.

>
> > I don't really know if there is any other better way to approach this.
> > Any suggestion on
> > how to proceed.
> >
> > Once this is resolved I will proceed with the porting even if we haven't
> > finalized the
> > directory since it is just a matter of moving files once we are
> finalized.
> >
> > If you think this is too early to start with coding for GSoC please
> > understand that my
> > university exams haven't been conducted yet. And due to the COVID
> > pandemic, the
> > dates are quite uncertain. But it is mostly expected to happen during
> > the coding period (july/aug)
> > and this would eat up quite a lot of time. So just to be one the safe
> > side I started
> > quite early.
> >
> > Thank,
> > Niteesh.
> >
> > On Mon, May 11, 2020 at 12:48 PM Christian Mauderer
> >  > > wrote:
> >
> > On 11/05/2020 09:11, Chris Johns wrote:
> > > On 11/5/20 4:55 pm, Christian Mauderer wrote:
> > >> On 11/05/2020 06:57, Chris Johns wrote:
> > >>>
> > >>>
> > >>> On 11/5/20 2:03 pm, Niteesh G. S. wrote:
> >  On Mon, May 11, 2020 at 4:34 AM Chris Johns  > 
> >  >> wrote:
> > 
> >   On 10/5/20 6:17 pm, Niteesh G. S. wrote:
> >    > This thread is a continuation of "GSoC 2020:
> Implementation
> >  of OFW
> >    > functions".
> >    >
> >    > A summary of points discussed in that thread is given
> > below.
> >    >
> >    > Below is a short description of my GSoC project. For
> more
> >   information please
> >    > refer to the wiki.
> >    >
> > 
> https://devel.rtems.org/wiki/GSoC/2020/Beagle_FDT_initialization
> >    > My GSoC project deals with refactoring the Beagle BSP
> > to add
> >   support for FDT
> >    > based initialization. As part of this process, I will
> > have to
> >   import the
> >    > pin mux driver
> >    > into RTEMS which currently is present in libBSD.
> >    > This would require having support for OFW functions
> > which are
> >   currently
> >    > not implemented
> >    > in RTEMS. Some drivers(eg: imx_iomux.c) which require
> these
> >   functions
> >    > provide
> >    > a local implementation using libFDT.
> > 
> >   I hope you do not mind if I wind back a couple of steps...
> > 
> >   OFW? Is this http://wiki.laptop.org/go/Open_Firmware?
> >   How does OFW related to FDT?
> > 
> > 
> >  We are only interested in the device tree interface provided by
> > the OF.
> >  Functions like OF_getprop, OF_parent, etc.
> > 

Re: Help on how to configure for user-defined memory protection support (GSoC 2020)

[Utkarsh Rai]

On Thu, May 14, 2020 at 10:23 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Utkarsh Rai,
>
> On 13/05/2020 14:30, Utkarsh Rai wrote:
> > Hello,
> > My GSoC project,  providing thread stack protection support, has to be
> > a user-configurable feature.
> > My question is,  what would be the best way to implement this, my idea
> > was to model it based on the existing system configuration
> > , but
> > Dr. Gedare pointed out that configuration is undergoing heavy changes
> > and may look completely different in future releases. Kindly advise me
> > as to what would be the best way to proceed.
> before we start with an implementation. It would be good to define what
> a thread stack protection support is supposed to do.


The thread stack protection mechanism will protect against stack overflow
errors and will completely isolate the thread stacks from each other.
Sharing of thread stack will be possible only when the user makes explicit
calls to do so. More details about this can be found in this thread
.

> Then there should
> be a concept for systems with a Memory Protection Unit (MPU) and a
> concept for systems with a Memory Management Unit (MMU). MMUs may
> provide normal 4KiB Pages, large Pages (for example 1MiB) or something
> more flexible. We should identify BSPs which should have support for
> this. For each BSP should be a concept. Then we should think about how a
> user can configure this feature.

For memory protection will have a 1:1 VA-PA address translation that means
> a 4KiB page size will be set for both the MPU and MMU, a 1:1 mapping will
> ensure we will have to do lesser page table walks.This would although mean
> that we would have page tables of  1MB. I will be first providing the
> support for Armv7 based BSPs (RPi , BBB, etc. have MMU support) then when I
> have a working example I will move on to provide the support for RISC-V.
> which has MPU support.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 2/2] Spelling/Grammar Mistakes

[Richi Dubey]

---
 c-user/scheduling_concepts.rst | 50 +-
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/c-user/scheduling_concepts.rst b/c-user/scheduling_concepts.rst
index dac39a8..d329bc4 100644
--- a/c-user/scheduling_concepts.rst
+++ b/c-user/scheduling_concepts.rst
@@ -16,7 +16,7 @@ Introduction
 
 
 The concept of scheduling in real-time systems dictates the ability to provide
-immediate response to specific external events, particularly the necessity of
+an immediate response to specific external events, particularly the necessity 
of
 scheduling tasks to run within a specified time limit after the occurrence of
 an event.  For example, software embedded in life-support systems used to
 monitor hospital patients must take instant action if a change in the patient's
@@ -38,7 +38,7 @@ The directives provided by the scheduler manager are:
 - rtems_scheduler_get_maximum_priority_ - Get maximum task priority of a 
scheduler
 
 - rtems_scheduler_map_priority_to_posix_ - Map task priority to POSIX thread
-  prority
+  priority
 
 - rtems_scheduler_map_priority_from_posix_ - Map POSIX thread priority to task
   prority
@@ -58,8 +58,8 @@ The directives provided by the scheduler manager are:
 Scheduling Algorithms
 -
 
-RTEMS provides a plugin framework which allows it to support multiple
-scheduling algorithms. RTEMS includes multiple scheduling algorithms and the
+RTEMS provides a plugin framework that allows it to support multiple
+scheduling algorithms. RTEMS includes multiple scheduling algorithms, and the
 user can select which of these they wish to use in their application at
 link-time.  In addition, the user can implement their own scheduling algorithm
 and configure RTEMS to use it.
@@ -69,8 +69,8 @@ select the algorithm which is most appropriate to their use 
case. Most
 real-time operating systems schedule tasks using a priority based algorithm,
 possibly with preemption control.  The classic RTEMS scheduling algorithm which
 was the only algorithm available in RTEMS 4.10 and earlier, is a fixed-priority
-scheduling algorithm.  This scheduling algoritm is suitable for uniprocessor
-(e.g. non-SMP) systems and is known as the *Deterministic Priority
+scheduling algorithm.  This scheduling algorithm is suitable for uniprocessor
+(e.g., non-SMP) systems and is known as the *Deterministic Priority
 Scheduler*.  Unless the user configures another scheduling algorithm, RTEMS
 will use this on uniprocessor systems.
 
@@ -87,7 +87,7 @@ in time is the one with the highest priority among all tasks 
in the ready
 state.
 
 When a task is added to the ready chain, it is placed behind all other tasks of
-the same priority.  This rule provides a round-robin within priority group
+the same priority.  This rule provides a round-robin within a priority group
 scheduling characteristic.  This means that in a group of equal priority tasks,
 tasks will execute in the order they become ready or FIFO order.  Even though
 there are ways to manipulate and adjust task priorities, the most important
@@ -100,7 +100,7 @@ rule to remember is:
 
 Priority scheduling is the most commonly used scheduling algorithm.  It should
 be used by applications in which multiple tasks contend for CPU time or other
-resources and there is a need to ensure certain tasks are given priority over
+resources, and there is a need to ensure certain tasks are given priority over
 other tasks.
 
 There are a few common methods of accomplishing the mechanics of this
@@ -127,7 +127,7 @@ algorithm.  These ways involve a list or chain of tasks in 
the ready state.
   the ready queue.
 
 RTEMS currently includes multiple priority based scheduling algorithms as well
-as other algorithms which incorporate deadline.  Each algorithm is discussed in
+as other algorithms that incorporate deadline.  Each algorithm is discussed in
 the following sections.
 
 Uniprocessor Schedulers
@@ -142,13 +142,13 @@ Deterministic Priority Scheduler
 
 
 This is the scheduler implementation which has always been in RTEMS.  After the
-4.10 release series, it was factored into pluggable scheduler selection.  It
+4.10 release series, it was factored into a pluggable scheduler selection.  It
 schedules tasks using a priority based algorithm which takes into account
 preemption.  It is implemented using an array of FIFOs with a FIFO per
 priority.  It maintains a bitmap which is used to track which priorities have
 ready tasks.
 
-This algorithm is deterministic (e.g. predictable and fixed) in execution time.
+This algorithm is deterministic (e.g., predictable and fixed) in execution 
time.
 This comes at the cost of using slightly over three (3) kilobytes of RAM on a
 system configured to support 256 priority levels.
 
@@ -167,7 +167,7 @@ determine where to insert the newly readied task.
 This algorithm uses much less RAM than the Deterministic Priority Scheduler but
 is *O(n)* wh

Re: Adding fenv support for ARM

[Eshan Dhawan]

On Wed, May 13, 2020 at 7:40 PM Joel Sherrill  wrote:

> National free hint day!!!
>
> Look above the line that is reported. You will see __BEGIN_DECL. It isn't
> defined. It is intended to expand to the __cplusplus wrapper.
>
> After you fix this, you will sequentially find 2 other things to change in
> this file.
>
> I have made those changes when a new error occurs from the assembler in
arm thumb mode
There is no support for vfp instructions in arm thumb.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0471c/BABGHDBB.html
So in which file will the compiler instructions given in the page

added?
Errors :

make[9]: Entering directory
'/home/eshan/development/newlib/c-arm-rtems5-newlib/arm-rtems5/thumb/newlib/libm/machine/arm'
arm-rtems5-gcc
-B/home/eshan/development/newlib/c-arm-rtems5-newlib/arm-rtems5/thumb/newlib/
-isystem
/home/eshan/development/newlib/c-arm-rtems5-newlib/arm-rtems5/thumb/newlib/targ-include
-isystem /home/eshan/development/newlib/newlib-cygwin/newlib/libc/include
 -mthumb -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"3.3.0\" -DPACKAGE_STRING=\"newlib\ 3.3.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I.
-I../../../../../../../newlib-cygwin/newlib/libm/machine/arm -I
../../../../../../../newlib-cygwin/newlib/libm/machine/arm/../../../../newlib/libm/common
-fno-builtin -mfpu=vfpv2 -ffunction-sections -fdata-sections
 -D_COMPILING_NEWLIB -DCLOCK_PROVIDED -DMALLOC_PROVIDED -DEXIT_PROVIDED
-DSIGNAL_PROVIDED -DGETREENT_PROVIDED -DREENTRANT_SYSCALLS_PROVIDED
-DHAVE_NANOSLEEP -DHAVE_BLKSIZE -DHAVE_FCNTL -DHAVE_ASSERT_FUNC
-D_NO_GETLOGIN -D_NO_GETPWENT -D_NO_GETUT -D_NO_GETPASS -D_NO_SIGSET
-D_NO_WORDEXP -D_NO_POPEN -D_NO_POSIX_SPAWN -DHAVE_INIT_FINI  -g -O2
 -mthumb -c -o lib_a-fenv-vfp.o `test -f 'fenv-vfp.c' || echo
'../../../../../../../newlib-cygwin/newlib/libm/machine/arm/'`fenv-vfp.c
/tmp/ccEHiFws.s: Assembler messages:
/tmp/ccEHiFws.s:37: Error: selected processor does not support `vmrs
r3,fpscr' in Thumb mode
/tmp/ccEHiFws.s:48: Error: selected processor does not support `vmsr
fpscr,r3' in Thumb mode
/tmp/ccEHiFws.s:81: Error: selected processor does not support `vmrs
r3,fpscr' in Thumb mode
/tmp/ccEHiFws.s:119: Error: selected processor does not support `vmrs
r3,fpscr' in Thumb mode
/tmp/ccEHiFws.s:134: Error: selected processor does not support `vmsr
fpscr,r3' in Thumb mode
/tmp/ccEHiFws.s:169: Error: selected processor does not support `vmrs
r3,fpscr' in Thumb mode
/tmp/ccEHiFws.s:182: Error: selected processor does not support `vmsr
fpscr,r3' in Thumb mode
/tmp/ccEHiFws.s:217: Error: selected processor does not support `vmrs
r3,fpscr' in Thumb mode
/tmp/ccEHiFws.s:251: Error: selected processor does not support `vmrs
r0,fpscr' in Thumb mode
/tmp/ccEHiFws.s:288: Error: selected processor does not support `vmrs
r3,fpscr' in Thumb mode
/tmp/ccEHiFws.s:303: Error: selected processor does not support `vmsr
fpscr,r0' in Thumb mode
/tmp/ccEHiFws.s:340: Error: selected processor does not support `vmrs
r3,fpscr' in Thumb mode
/tmp/ccEHiFws.s:374: Error: selected processor does not support `vmrs
r3,fpscr' in Thumb mode
/tmp/ccEHiFws.s:390: Error: selected processor does not support `vmsr
fpscr,r3' in Thumb mode
/tmp/ccEHiFws.s:424: Error: selected processor does not support `vmsr
fpscr,r3' in Thumb mode
/tmp/ccEHiFws.s:457: Error: selected processor does not support `vmrs
r1,fpscr' in Thumb mode
/tmp/ccEHiFws.s:466: Error: selected processor does not support `vmsr
fpscr,r3' in Thumb mode
/tmp/ccEHiFws.s:478: Error: selected processor does not support `vmrs
r2,fpscr' in Thumb mode
/tmp/ccEHiFws.s:503: Error: selected processor does not support `vmsr
fpscr,r3' in Thumb mode
/tmp/ccEHiFws.s:543: Error: selected processor does not support `vmrs
r0,fpscr' in Thumb mode
/tmp/ccEHiFws.s:559: Error: selected processor does not support `vmsr
fpscr,r3' in Thumb mode
/tmp/ccEHiFws.s:595: Error: selected processor does not support `vmrs
r3,fpscr' in Thumb mode
/tmp/ccEHiFws.s:612: Error: selected processor does not support `vmsr
fpscr,r2' in Thumb mode
/tmp/ccEHiFws.s:647: Error: selected processor does not support `vmrs
r3,fpscr' in Thumb mode
Makefile:476: recipe for target 'lib_a-fenv-vfp.o' failed
make[9]: *** [lib_a-fenv-vfp.o] Error 1
make[9]: Leaving directory
'/home/eshan/development/newlib/c-arm-rtems5-newlib/arm-rtems5/thumb/newlib/libm/machine/arm'
Makefile:324: recipe for target 'all-recursive' failed
make[8]: *** [all-recursive] Error 1
make[8]: Leaving directory
'/home/eshan/development/newlib/c-arm-rtems5-newlib/arm-rtems5/thumb/newlib/libm/machine'
Makefile:553: recipe for target 'all-recursive' failed
make[7]: *** [all-recursive] Error 1
make[7]: Leaving directory
'/home/eshan/development/newlib/c-arm-rtems5-newlib/arm-rtems5/thumb/newlib/libm'
Makefile:641: recipe for target 'all-recursive' failed
make[6]: *** [all-recursive] Error 1
make[6]: Leaving 

Re: Help on how to configure for user-defined memory protection support (GSoC 2020)

[Sebastian Huber]

Hello Utkarsh Rai,

On 13/05/2020 14:30, Utkarsh Rai wrote:

Hello,
My GSoC project,  providing thread stack protection support, has to be 
a user-configurable feature.
My question is,  what would be the best way to implement this, my idea 
was to model it based on the existing system configuration 
, but 
Dr. Gedare pointed out that configuration is undergoing heavy changes 
and may look completely different in future releases. Kindly advise me 
as to what would be the best way to proceed.
before we start with an implementation. It would be good to define what 
a thread stack protection support is supposed to do. Then there should 
be a concept for systems with a Memory Protection Unit (MPU) and a 
concept for systems with a Memory Management Unit (MMU). MMUs may 
provide normal 4KiB Pages, large Pages (for example 1MiB) or something 
more flexible. We should identify BSPs which should have support for 
this. For each BSP should be a concept. Then we should think about how a 
user can configure this feature.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC: RTEMS directory for FreeBSD imports

[Christian Mauderer]

On 13/05/2020 20:15, Niteesh G. S. wrote:
> Hello,
> 
> This mail is to regain attention for this topic and also to discuss a
> few details
> regarding the porting process.
> 
> In the previous thread, Sebastian mentioned that we will be hard wiring
> the OF
> functions with the FDT implementation. For reasons please have a look at
> previous thread.
> https://lists.rtems.org/pipermail/devel/2020-May/059762.html
> This will be achieved by inlining the functions in openfirm.h with functions
> defined in ofw_fdt.c. This approach is valid for most functions but not all.
> Since not all functions have a one to one mapping.
> 
> For example,
>    The OF_peer can be directly mapped to ofw_fdt_peer.
>    But for OF_getencprop it calls ofw_fdt_getprop after few manipulations.
> Inlining these functions doesn't seem like a good practice for me.
> 
> One way to approach this would be to add the implementation for these
> functions in
> ofw_fdt.c but this would cause code redundancy if we plan to import
> openfirm.c
> in future since these functions are already defined in openfirm.c.

Are the functions exact clones of the the ones in openfirm.c? In that
case I would suggest to import openfirm.c and put #ifndef __rtems__
around everything you don't need. Eveni if it means that you only use
10% of the file.

> 
> Another approach will be to import openfirm.c also and redefine the OFW_*
> macro to directly call the respective functions.

That sounds like a better aproach.

> 
> I don't really know if there is any other better way to approach this.
> Any suggestion on
> how to proceed. 
> 
> Once this is resolved I will proceed with the porting even if we haven't
> finalized the
> directory since it is just a matter of moving files once we are finalized.
> 
> If you think this is too early to start with coding for GSoC please
> understand that my
> university exams haven't been conducted yet. And due to the COVID
> pandemic, the
> dates are quite uncertain. But it is mostly expected to happen during
> the coding period (july/aug)
> and this would eat up quite a lot of time. So just to be one the safe
> side I started
> quite early.
> 
> Thank,
> Niteesh.
> 
> On Mon, May 11, 2020 at 12:48 PM Christian Mauderer
>  > wrote:
> 
> On 11/05/2020 09:11, Chris Johns wrote:
> > On 11/5/20 4:55 pm, Christian Mauderer wrote:
> >> On 11/05/2020 06:57, Chris Johns wrote:
> >>>
> >>>
> >>> On 11/5/20 2:03 pm, Niteesh G. S. wrote:
>  On Mon, May 11, 2020 at 4:34 AM Chris Johns  
>  >> wrote:
> 
>   On 10/5/20 6:17 pm, Niteesh G. S. wrote:
>    > This thread is a continuation of "GSoC 2020: Implementation
>  of OFW
>    > functions".
>    >
>    > A summary of points discussed in that thread is given
> below.
>    >
>    > Below is a short description of my GSoC project. For more
>   information please
>    > refer to the wiki.
>    >
>  https://devel.rtems.org/wiki/GSoC/2020/Beagle_FDT_initialization
>    > My GSoC project deals with refactoring the Beagle BSP
> to add
>   support for FDT
>    > based initialization. As part of this process, I will
> have to
>   import the
>    > pin mux driver
>    > into RTEMS which currently is present in libBSD.
>    > This would require having support for OFW functions
> which are
>   currently
>    > not implemented
>    > in RTEMS. Some drivers(eg: imx_iomux.c) which require these
>   functions
>    > provide
>    > a local implementation using libFDT.
> 
>   I hope you do not mind if I wind back a couple of steps...
> 
>   OFW? Is this http://wiki.laptop.org/go/Open_Firmware?
>   How does OFW related to FDT?
> 
> 
>  We are only interested in the device tree interface provided by
> the OF.
>  Functions like OF_getprop, OF_parent, etc.
> 
> >>>
> >>> Why not call libfdt functions? I am wondering what there is in
> FreeBSD
> >>> that is calling these functions? I am not questioning the need,
> it is a
> >>> case of not understanding the dependency.
> >>
> >> The use case for the OF_... and ofw_... functions is more or less a
> >> simple import from FreeBSD drivers. Beneath that there are some quite
> >> nice shortcuts in the OF_... and ofw_... functions that would
> have to be
> >> re-implemented in each driver (like ofw_bus_node_status_okay()).
> >>
> >> Some drivers already use hacked versions of the functions. For
> example:
> >>
> >> bsps/sparc64/shared/clock