Re: GSoC: Correct placement and naming of memory protection APIs

[Hesham Almatary]

We have already discussed and done that during my 2013 GSoC. Have a
look at [1, 2] and their calls.

[1] 
https://github.com/heshamelmatary/rtems-gsoc2013/blob/low-level-libmm/cpukit/score/include/rtems/score/mmimpl.h
[2] 
https://github.com/heshamelmatary/rtems-gsoc2013/blob/low-level-libmm/cpukit/score/include/rtems/score/mm.h

On Fri, 17 Jul 2020 at 21:33, Utkarsh Rai  wrote:
>
> Hello,
> In RTEMS each set of BSP has its own MMU implementation, for utilizing this 
> for high-level operations such as thread-stack protection we need a common 
> interface that is implemented for each BSP but is available for high-level 
> operations ( Something along the lines of the cache manager ), my current 
> implementation can be viewed here and here  My question is, what should be 
> the correct placement of these APIs and hence there naming? Can we model it 
> based on the cache-manager (rtems_memory_protection_xx_xx)?
>
> ___
> 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: GSoC: Correct placement and naming of memory protection APIs

[Utkarsh Rai]

On Sat, Jul 18, 2020 at 1:21 PM Hesham Almatary <
hesham.almat...@cl.cam.ac.uk> wrote:

> We have already discussed and done that during my 2013 GSoC. Have a
> look at [1, 2] and their calls.
>
> [1]
> https://github.com/heshamelmatary/rtems-gsoc2013/blob/low-level-libmm/cpukit/score/include/rtems/score/mmimpl.h
> [2]
> https://github.com/heshamelmatary/rtems-gsoc2013/blob/low-level-libmm/cpukit/score/include/rtems/score/mm.h


While designing my interface I went through this and my model is almost
similar to yours :). My doubt is, what are the rationales for placing this
in the score? (If you look into my commit history, I have fiddled with the
placement quite a bit without any resolution).


>
>
> On Fri, 17 Jul 2020 at 21:33, Utkarsh Rai  wrote:
> >
> > Hello,
> > In RTEMS each set of BSP has its own MMU implementation, for utilizing
> this for high-level operations such as thread-stack protection we need a
> common interface that is implemented for each BSP but is available for
> high-level operations ( Something along the lines of the cache manager ),
> my current implementation can be viewed here and here  My question is, what
> should be the correct placement of these APIs and hence there naming? Can
> we model it based on the cache-manager (rtems_memory_protection_xx_xx)?
> >
> > ___
> > 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 v3] Changed ARM fenv support similar to X86_64

[Sebastian Huber]

Hello Eshan,

you produce a lot of extra work for me. Your patch applies now. But it 
didn't build:


make[9]: *** No rule to make target 'fenv-vfp.c', needed by 
'lib_a-fenv-vfp.o'.  Stop.

make[9]: *** Waiting for unfinished jobs
make[9]: Leaving directory 
'/build/git-build/b-gcc-10.1.0-arm-rtems5/arm-rtems5/thumb/newlib/libm/machine/arm'


Why is x86_64 mentioned in the commit message? On the mailing list it 
was discussed to use RISC-V as the model. Please improve the commit 
message in general. It should reflect all the problems discussed on the 
mailing list and how the commit addresses the issues.


Attached is a patch which fixes a couple of obvious things. Please apply 
it, review it, test it, and make a v4 patch out of it with an improved 
commit message.


>From 3398b5cb51ddc711a439e53df537b9d7bfe6e39c Mon Sep 17 00:00:00 2001
From: Sebastian Huber 
Date: Sat, 18 Jul 2020 10:33:35 +0200
Subject: [PATCH] arm/fenv.c: Fix use of defines and format

Fix the build.  Remove superfluous code.  Remove parameter names in
the header file.  Move implementation details out of the header file.
---
 newlib/libc/machine/arm/sys/fenv.h  |  47 
 newlib/libm/machine/arm/Makefile.in |  19 +
 newlib/libm/machine/arm/fenv.c  | 114 ++--
 3 files changed, 55 insertions(+), 125 deletions(-)

diff --git a/newlib/libc/machine/arm/sys/fenv.h b/newlib/libc/machine/arm/sys/fenv.h
index 0224da38b..70bd57be4 100644
--- a/newlib/libc/machine/arm/sys/fenv.h
+++ b/newlib/libc/machine/arm/sys/fenv.h
@@ -38,10 +38,6 @@
 extern "C" {
 #endif
 
-#ifndef	__fenv_static
-#define	__fenv_static static
-#endif
-
 typedef int fenv_t;
 typedef int fexcept_t;
 
@@ -51,7 +47,7 @@ typedef int fexcept_t;
 #define	FE_OVERFLOW	0x0004
 #define	FE_UNDERFLOW	0x0008
 #define	FE_INEXACT	0x0010
-#ifdef __ARM_PCS_VFP
+#ifndef __SOFTFP__
 #define	FE_DENORMAL	0x0080
 #define	FE_ALL_EXCEPT	(FE_DIVBYZERO | FE_INEXACT | \
 			 FE_INVALID | FE_OVERFLOW | FE_UNDERFLOW | FE_DENORMAL)
@@ -60,50 +56,33 @@ typedef int fexcept_t;
 			 FE_INVALID | FE_OVERFLOW | FE_UNDERFLOW)
 #endif
 
-
-
 /* Rounding modes */
 #define	FE_TONEAREST		0x
 #define	FE_UPWARD		0x0040
 #define	FE_DOWNWARD		0x0080
 #define	FE_TOWARDZERO		0x00c0
 
-#define	_ROUND_MASK	(FE_TONEAREST | FE_DOWNWARD | \
-			 FE_UPWARD | FE_TOWARDZERO)
-
-
 /* Default floating-point environment */
-
 extern const fenv_t	*_fe_dfl_env;
 #define	FE_DFL_ENV	(_fe_dfl_env)
 
-/* We need to be able to map status flag positions to mask flag positions */
-#ifndef __ARM_PCS_VFP
-#define	_FPUSW_SHIFT	16
-#define	_ENABLE_MASK	(FE_ALL_EXCEPT << _FPUSW_SHIFT)
-#endif
-
-
-
-int feclearexcept(int excepts);
-int fegetexceptflag(fexcept_t *flagp, int excepts);
-int fesetexceptflag(const fexcept_t *flagp, int excepts);
-int feraiseexcept(int excepts);
-int fetestexcept(int excepts);
+int feclearexcept(int);
+int fegetexceptflag(fexcept_t *, int);
+int fesetexceptflag(const fexcept_t *, int);
+int feraiseexcept(int);
+int fetestexcept(int);
 int fegetround(void);
-int fesetround(int round);
-int fegetenv(fenv_t *envp);
-int feholdexcept(fenv_t *envp);
-int fesetenv(const fenv_t *envp);
-int feupdateenv(const fenv_t *envp);
+int fesetround(int);
+int fegetenv(fenv_t *);
+int feholdexcept(fenv_t *);
+int fesetenv(const fenv_t *);
+int feupdateenv(const fenv_t *);
 #if __BSD_VISIBLE
-int feenableexcept(int __mask);
-int fedisableexcept(int __mask);
+int feenableexcept(int);
+int fedisableexcept(int);
 int fegetexcept(void);
 #endif /* __BSD_VISIBLE */
 
-
-
 #ifdef __cplusplus
 }
 #endif
diff --git a/newlib/libm/machine/arm/Makefile.in b/newlib/libm/machine/arm/Makefile.in
index ecfa684e7..aa23dd4d5 100644
--- a/newlib/libm/machine/arm/Makefile.in
+++ b/newlib/libm/machine/arm/Makefile.in
@@ -83,8 +83,7 @@ am__objects_1 = lib_a-e_sqrt.$(OBJEXT) lib_a-ef_sqrt.$(OBJEXT) \
 	lib_a-fenv.$(OBJEXT) lib_a-feraiseexcept.$(OBJEXT) \
 	lib_a-fesetenv.$(OBJEXT) lib_a-fesetexceptflag.$(OBJEXT) \
 	lib_a-fesetround.$(OBJEXT) lib_a-fetestexcept.$(OBJEXT) \
-	lib_a-feupdateenv.$(OBJEXT) lib_a-fenv-vfp.$(OBJEXT) \
-	lib_a-fenv-softfp.$(OBJEXT)
+	lib_a-feupdateenv.$(OBJEXT)
 am_lib_a_OBJECTS = $(am__objects_1)
 lib_a_OBJECTS = $(am_lib_a_OBJECTS)
 DEFAULT_INCLUDES = -I.@am__isrc@
@@ -237,9 +236,7 @@ LIB_SOURCES = \
 	fesetexceptflag.c \
 	fesetround.c \
 	fetestexcept.c \
-	feupdateenv.c \
-	fenv-vfp.c \
-	fenv-softfp.c 
+	feupdateenv.c
 
 noinst_LIBRARIES = lib.a
 lib_a_SOURCES = $(LIB_SOURCES)
@@ -479,18 +476,6 @@ lib_a-feupdateenv.o: feupdateenv.c
 lib_a-feupdateenv.obj: feupdateenv.c
 	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(lib_a_CFLAGS) $(CFLAGS) -c -o lib_a-feupdateenv.obj `if test -f 'feupdateenv.c'; then $(CYGPATH_W) 'feupdateenv.c'; else $(CYGPATH_W) '$(srcdir)/feupdateenv.c'; fi`
 
-lib_a-fenv-vfp.o: fenv-vfp.c
-	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(lib_a_CFLAGS) $(CFLAGS) -c -o lib_a-fenv-vfp.o `t

Re: Thread 2: Need help in understanding exisiting RTEMS code

[Richi Dubey]

This information helps. Thank you.

On Fri, Jul 17, 2020 at 6:31 PM Sebastian Huber
 wrote:
>
> On 17/07/2020 14:22, Richi Dubey wrote:
>
> > I found the line in the documentation: "Since the processor assignment
> > is independent of the thread priority the processor indices may move
> > from one state to the other."
> >
> > This is true because the processor assignment is done by the scheduler
> > and it gets to choose whether to allocate the highest priority thread
> > or not. Right? So if it wants to allocate processor to the lowest
> > priority (max. priority number) thread, it can do so?
> Yes, the scheduler can use whatever criteria it wants to allocate a
> processor to the threads is manages.
> >
> > How is the priority of a node different from the priority of its
> > thread? How do these two priorities relate to each other?
> A thread has not only one priority. It has at least one priority per
> scheduler instance. With the locking protocols it may also inherit
> priorities of other threads. A thread has a list of trees of trees of
> priorities.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v3] Changed ARM fenv support similar to X86_64

[Eshan Dhawan]

> On 18-Jul-2020, at 4:52 PM, Sebastian Huber 
>  wrote:
> 
> Hello Eshan,
> 
> you produce a lot of extra work for me. Your patch applies now. But it didn't 
> build:
> 
> make[9]: *** No rule to make target 'fenv-vfp.c', needed by 
> 'lib_a-fenv-vfp.o'.  Stop.
> make[9]: *** Waiting for unfinished jobs
> make[9]: Leaving directory 
> '/build/git-build/b-gcc-10.1.0-arm-rtems5/arm-rtems5/thumb/newlib/libm/machine/arm'
Fenv-vpf.c file was deleted as well as the declarations were deleted from 
makefile.am 
So it shouldn’t be compiled 
Did you try Remaking the autoconf files after applying the patch ??? 
This patch have the autoconf files 
> 
> Why is x86_64 mentioned in the commit message? On the mailing list it was 
> discussed to use RISC-V as the model. Please improve the commit message in 
> general. It should reflect all the problems discussed on the mailing list and 
> how the commit addresses the issues.
The files follow the similar file structure as x86_64. So I added X86
> 
> Attached is a patch which fixes a couple of obvious things. Please apply it, 
> review it, test it, and make a v4 patch out of it with an improved commit 
> message.
The error isn’t supposed to occur 
I tested the code on machine 
> <0001-arm-fenv.c-Fix-use-of-defines-and-format.patch>
I will apply the patch and test it 
And resend it 
Is this patch applied over the current patch 
Or the newlib master?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: A question about rtems license

[Christian Mauderer]

Hello,

note that I'm not a lawyer. I can only provide my personal opinion
regarding that topic. Depending of the legal system of your country a
lawyer might has a different point of view. I'm also only a small part
of the project and can't speak for all persons involved.


As far as I understand your situation you basically forked RTEMS. The
fork would consist of "rtems src" and "rtems src2". These parts would be
covered by the RTEMS license. So if you provide a binary to someone, you
would have to make the "rtems src" and "rtems src2" available to this
person too if they ask.

But your application is still a separate part and would be covered by
the linking exception. That means: you can keep it private.


Please note that there is an ongoing effort to change the RTEMS license
to a BSD style license. A lot of sources are already BSD licensed. You
can see that if you have a look at the file headers.

As another note: RTEMS is always open to patches. So you might want to
think about polishing the "rtems src2" parts a bit and sending them to
the mailing list for integration into the official sources.

Best regards

Christian

On 18/07/2020 11:45, small...@aliyun.com wrote:
> Hi,
> There is a project using rtems as a real time os in an arm cortex R5
> bsp.  Primary RTEMS License says
> that RTEMS is free software; you can redistribute it and/or modify it under 
> terms of the
> GPL.
> As a special exception, including RTEMS header files in a file, instantiating 
> RTEMS generics or templates, or linking other files with RTEMS objects to 
> produce an executable application, does not by itself cause the resulting 
> executable application to be covered by the GPL.
> I draw a picture to describe this special exception:
> There are "rtems src", "rtems header" and our "application".  The "rtems
> src" will be compiled to a lib called "rtems lib".  If our "application"
> includes "rtems header" and linkes with "rtems lib", then our
> "application" does not follow GPL.
> 
> OK, here is my question: we modify some code in "rtems src" and build it
> to "rtems lib2".  If our "application" includes "rtems header" and
> linkes with "rtems lib2", whether or not our "application" should follow
> GPL? 
> (of course, rtems src2 should follow GPL)
> 
> 
> small...@aliyun.com
> 
> ___
> 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 v3] Changed ARM fenv support similar to X86_64

[Sebastian Huber]

On 18/07/2020 17:17, Eshan Dhawan wrote:


On 18-Jul-2020, at 4:52 PM, Sebastian Huber 
 wrote:

Hello Eshan,

you produce a lot of extra work for me. Your patch applies now. But it didn't 
build:

make[9]: *** No rule to make target 'fenv-vfp.c', needed by 'lib_a-fenv-vfp.o'. 
 Stop.
make[9]: *** Waiting for unfinished jobs
make[9]: Leaving directory 
'/build/git-build/b-gcc-10.1.0-arm-rtems5/arm-rtems5/thumb/newlib/libm/machine/arm'

Fenv-vpf.c file was deleted as well as the declarations were deleted from 
makefile.am
So it shouldn’t be compiled
Did you try Remaking the autoconf files after applying the patch ???
This patch have the autoconf files
I don't want to run autoconf myself to test your patches. Please include 
the build system changes in your patches.

Why is x86_64 mentioned in the commit message? On the mailing list it was 
discussed to use RISC-V as the model. Please improve the commit message in 
general. It should reflect all the problems discussed on the mailing list and 
how the commit addresses the issues.

The files follow the similar file structure as x86_64. So I added X86

Which file did you use as a template?

Attached is a patch which fixes a couple of obvious things. Please apply it, 
review it, test it, and make a v4 patch out of it with an improved commit 
message.

The error isn’t supposed to occur
I tested the code on machine

<0001-arm-fenv.c-Fix-use-of-defines-and-format.patch>

I will apply the patch and test it
And resend it
Is this patch applied over the current patch
Or the newlib master?

Over your v3 patch.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Need help in understanding some of the existing code in RTEMS

[Gedare Bloom]

On Fri, Jul 17, 2020 at 2:22 AM Richi Dubey  wrote:
>>
>>
>> >   Scheduler_Node *nodes;
>> > } Thread_Scheduler_control;
>> >
>> > Why do we have a Scheduler_Node *nodes? What does it indicate? Since the 
>> > pointer can point to a single value, why is it being called nodes?
>> >
>> See cpukit/score/src/threadinitialize.c +153
>
>
> Thank you for your help.
> /**
>* @brief The scheduler nodes of this thread.
>*
>* Each thread has a scheduler node for each scheduler instance.
>*/
>
> I went through the entire scheduler related code in threadinitialize.c and I 
> understood that the scheduler node which belongs to the scheduler that is the 
> home scheduler for a thread gets initialized with the thread's priority, 
> while other scheduler nodes gets initialized with the max priority : for an 
> idle thread case.
>
> But why do we have a scheduler node for each scheduler instance? Is it 
> because the thread might migrate to a different processor to facilitate 
> helping and would need a node belonging to the scheduler instance which owns 
> the processor it is migrating to?
>

I'm not 100% sure on this, but I believe it is because the thread's
priority needs to be considered globally when taking
scheduling/synchronization decisions.

> On Wed, Jul 15, 2020 at 10:12 PM Gedare Bloom  wrote:
>>
>> On Wed, Jul 15, 2020 at 6:55 AM Richi Dubey  wrote:
>> >
>> > Another quick question:
>> > typedef struct {
>> >
>> > #if defined(RTEMS_SMP)
>> > ...
>> >   Chain_Control Scheduler_nodes;
>> >
>> > #endif
>> > /**
>> >* @brief The scheduler nodes of this thread.
>> >*
>> >* Each thread has a scheduler node for each scheduler instance.
>> >*/
>> >   Scheduler_Node *nodes;
>> > } Thread_Scheduler_control;
>> >
>> > Why do we have a Scheduler_Node *nodes? What does it indicate? Since the 
>> > pointer can point to a single value, why is it being called nodes?
>> >
>>
>> See cpukit/score/src/threadinitialize.c +153
>>
>>
>> >
>> > On Wed, Jul 15, 2020 at 5:57 PM Richi Dubey  wrote:
>> >>
>> >> Hi,
>> >>
>> >> I had a small question. The scheduler struct inside percpu.h looks like:
>> >> --
>> >> struct {
>> >>   /**
>> >>* @brief The scheduler control of the scheduler owning this 
>> >> processor.
>> >>*
>> >>* This pointer is NULL in case this processor is currently not 
>> >> used by a
>> >>* scheduler instance.
>> >>*/
>> >>   const struct _Scheduler_Control *control;
>> >>
>> >>   /**
>> >>* @brief The scheduler context of the scheduler owning this 
>> >> processor.
>> >>*
>> >>* This pointer is NULL in case this processor is currently not 
>> >> used by a
>> >>* scheduler instance.
>> >>*/
>> >>   const struct Scheduler_Context *context;
>> >>
>> >>   /**
>> >>* @brief The idle thread for this processor in case it is online 
>> >> and
>> >>* currently not used by a scheduler instance.
>> >>*/
>> >>   struct _Thread_Control *idle_if_online_and_unused;
>> >> } Scheduler;
>> >> --
>> >> So, does this mean a CPU when active is always either executing an idle 
>> >> thread and is not being used by a scheduler (so has a thread attribute in 
>> >> the idle_if_online_and_unused), or is used by a scheduler and is 
>> >> executing a task ( which can not be an idle task)? Another equivalent 
>> >> question is do we have an idle scheduler node, like we have idle 
>> >> predefined threads that run on a CPU?
>> >>
>>
>> Not exactly. What I understand is that:
>> * When a processor is online (active), but not used by a scheduler,
>> then it executes an idle task.
>> * When a processor is online and used by a scheduler, it may be
>> executing any task including an idle task.
>>
>> You can find the relevant code in 
>> cpukit/include/rtems/score/schedulersmpimpl.h
>>
>> The idle threads are specially handled when processors are
>> added/removed from scheduler contexts. A scheduler keeps a chain of
>> its idle threads:
>> cpukit/include/rtems/score/schedulersmp.h +64
>>
>> >> Please let me know,
>> >> Thanks.
>> >>
>> >> On Tue, Jul 14, 2020 at 8:28 PM Richi Dubey  wrote:
>> >>>
>> >>> I understand. Thank you.
>> >>>
>> >>> On Tue, Jul 14, 2020 at 7:05 PM Sebastian Huber 
>> >>>  wrote:
>> 
>>  On 14/07/2020 13:37, Richi Dubey wrote:
>> 
>>  > Here we remove the affine ready queue if it
>>  > exists from the chain of affine queues since now an affine thread 
>>  > is
>>  > scheduled on a processor.
>>  >
>>  > Why are we removing the entire affine queue corresponding to a
>>  > CPU when a single node of the queue gets scheduled?
>>  Because the highest priority affine thread is now a schedule one.
>> >
>> > __

Re: [PATCH v3] Changed ARM fenv support similar to X86_64

[Eshan Dhawan]

> On 18-Jul-2020, at 8:51 PM, Sebastian Huber 
>  wrote:
> 
> On 18/07/2020 17:17, Eshan Dhawan wrote:
> 
> On 18-Jul-2020, at 4:52 PM, Sebastian Huber 
>  wrote:
 Hello Eshan,
 you produce a lot of extra work for me. Your patch applies now. But it 
 didn't build:
 make[9]: *** No rule to make target 'fenv-vfp.c', needed by 
 'lib_a-fenv-vfp.o'.  Stop.
 make[9]: *** Waiting for unfinished jobs
 make[9]: Leaving directory 
 '/build/git-build/b-gcc-10.1.0-arm-rtems5/arm-rtems5/thumb/newlib/libm/machine/arm'
>> Fenv-vpf.c file was deleted as well as the declarations were deleted from 
>> makefile.am
>> So it shouldn’t be compiled
>> Did you try Remaking the autoconf files after applying the patch ???
>> This patch have the autoconf files
> I don't want to run autoconf myself to test your patches. Please include the 
> build system changes in your patches.
Apologies, I will add the autoconf files from future patches.
>>> Why is x86_64mentioned in the commit message? On the mailing list it was 
>>> discussed to use RISC-V as the model. Please improve the commit message in 
>>> general. It should reflect all the problems discussed on the mailing list 
>>> and how the commit addresses the issues.
>> The files follow the similar file structure as x86_64. So I added X86
> Which file did you use as a template?
The softfp Implementation is taken from riscv but has stub implementation 
>>> Attached is a patch which fixes a couple of obvious things. Please apply 
>>> it, review it, test it, and make a v4 patch out of it with an improved 
>>> commit message.
>> The error isn’t supposed to occur
>> I tested the code on machine
>>> <0001-arm-fenv.c-Fix-use-of-defines-and-format.patch>
>> I will apply the patch and test it
>> And resend it
>> Is this patch applied over the current patch
>> Or the newlib master?
> Over your v3 patch.
Ok, I will apply and test them.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: A question about rtems license

[Gedare Bloom]

On Sat, Jul 18, 2020 at 9:20 AM Christian Mauderer  wrote:
>
> Hello,
>
> note that I'm not a lawyer. I can only provide my personal opinion
> regarding that topic. Depending of the legal system of your country a
> lawyer might has a different point of view. I'm also only a small part
> of the project and can't speak for all persons involved.
>
Indeed, we have no lawyers here to provide legal advice.

>
> As far as I understand your situation you basically forked RTEMS. The
> fork would consist of "rtems src" and "rtems src2". These parts would be
> covered by the RTEMS license. So if you provide a binary to someone, you
> would have to make the "rtems src" and "rtems src2" available to this
> person too if they ask.
>

Yes, if you modified "rtems src" and then distribute it, you need to
provide the source for those modifications.

> But your application is still a separate part and would be covered by
> the linking exception. That means: you can keep it private.
>

Also correct.

>
> Please note that there is an ongoing effort to change the RTEMS license
> to a BSD style license. A lot of sources are already BSD licensed. You
> can see that if you have a look at the file headers.
>

That said, we encourage users to provide us with the changes they made
to rtems. There are advantages if your changes are accepted, then you
have more confidence about their correctness (additional review) and
they may also be maintained by the community as long as they are
useful.

> As another note: RTEMS is always open to patches. So you might want to
> think about polishing the "rtems src2" parts a bit and sending them to
> the mailing list for integration into the official sources.
>
+1

> Best regards
>
> Christian
>
> On 18/07/2020 11:45, small...@aliyun.com wrote:
> > Hi,
> > There is a project using rtems as a real time os in an arm cortex R5
> > bsp.  Primary RTEMS License says
> > that RTEMS is free software; you can redistribute it and/or modify it under 
> > terms of the
> > GPL.
> > As a special exception, including RTEMS header files in a file, 
> > instantiating RTEMS generics or templates, or linking other files with 
> > RTEMS objects to produce an executable application, does not by itself 
> > cause the resulting executable application to be covered by the GPL.
> > I draw a picture to describe this special exception:
> > There are "rtems src", "rtems header" and our "application".  The "rtems
> > src" will be compiled to a lib called "rtems lib".  If our "application"
> > includes "rtems header" and linkes with "rtems lib", then our
> > "application" does not follow GPL.
> >
> > OK, here is my question: we modify some code in "rtems src" and build it
> > to "rtems lib2".  If our "application" includes "rtems header" and
> > linkes with "rtems lib2", whether or not our "application" should follow
> > GPL?
> > (of course, rtems src2 should follow GPL)
> >
> > 
> > small...@aliyun.com
> >
> > ___
> > 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

Re: [PATCH v3] Changed ARM fenv support similar to X86_64

[Sebastian Huber]

On 18/07/2020 17:39, Eshan Dhawan wrote:


Why is x86_64mentioned in the commit message? On the mailing list it was 
discussed to use RISC-V as the model. Please improve the commit message in 
general. It should reflect all the problems discussed on the mailing list and 
how the commit addresses the issues.

The files follow the similar file structure as x86_64. So I added X86

Which file did you use as a template?

The softfp Implementation is taken from riscv but has stub implementation


Ok, good and why did you mention the x86_64? The arm implementation 
looks pretty much like the riscv one except that all functions are in a 
single file.


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

Re: [PATCH v3] Changed ARM fenv support similar to X86_64

[Gedare Bloom]

On Sat, Jul 18, 2020 at 9:39 AM Eshan Dhawan  wrote:
>
>
> > On 18-Jul-2020, at 8:51 PM, Sebastian Huber 
> >  wrote:
> >
> > On 18/07/2020 17:17, Eshan Dhawan wrote:
> >
> > On 18-Jul-2020, at 4:52 PM, Sebastian Huber 
> >  wrote:
>  Hello Eshan,
>  you produce a lot of extra work for me. Your patch applies now. But it 
>  didn't build:
>  make[9]: *** No rule to make target 'fenv-vfp.c', needed by 
>  'lib_a-fenv-vfp.o'.  Stop.
>  make[9]: *** Waiting for unfinished jobs
>  make[9]: Leaving directory 
>  '/build/git-build/b-gcc-10.1.0-arm-rtems5/arm-rtems5/thumb/newlib/libm/machine/arm'
> >> Fenv-vpf.c file was deleted as well as the declarations were deleted from 
> >> makefile.am
> >> So it shouldn’t be compiled
> >> Did you try Remaking the autoconf files after applying the patch ???
> >> This patch have the autoconf files
> > I don't want to run autoconf myself to test your patches. Please include 
> > the build system changes in your patches.
> Apologies, I will add the autoconf files from future patches.

auto* generated output is included for newlib patches, but not for
rtems. We don't keep the generated files in our repo.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC: Correct placement and naming of memory protection APIs

[Gedare Bloom]

On Sat, Jul 18, 2020 at 3:55 AM Utkarsh Rai  wrote:
>
>
>
> On Sat, Jul 18, 2020 at 1:21 PM Hesham Almatary 
>  wrote:
>>
>> We have already discussed and done that during my 2013 GSoC. Have a
>> look at [1, 2] and their calls.
>>
>> [1] 
>> https://github.com/heshamelmatary/rtems-gsoc2013/blob/low-level-libmm/cpukit/score/include/rtems/score/mmimpl.h
>> [2] 
>> https://github.com/heshamelmatary/rtems-gsoc2013/blob/low-level-libmm/cpukit/score/include/rtems/score/mm.h
>
>
> While designing my interface I went through this and my model is almost 
> similar to yours :). My doubt is, what are the rationales for placing this in 
> the score? (If you look into my commit history, I have fiddled with the 
> placement quite a bit without any resolution).
>

The score is the "least common denominator" for functional
implementation in RTEMS. Any code that is shared by more than one API
must generally belong in the score. I can't seem to find where this is
described in our documentation. Although it's really outdated now, you
can get a sense of things from Section 2 of
https://gedare.github.io/pdf/bloom_scheduling_2014.pdf

Since you have something that needs to be accessible from POSIX with
some implementation in architecture/BSP-specific code, the only place
that could be implemented is in the score.

>>
>>
>>
>> On Fri, 17 Jul 2020 at 21:33, Utkarsh Rai  wrote:
>> >
>> > Hello,
>> > In RTEMS each set of BSP has its own MMU implementation, for utilizing 
>> > this for high-level operations such as thread-stack protection we need a 
>> > common interface that is implemented for each BSP but is available for 
>> > high-level operations ( Something along the lines of the cache manager ), 
>> > my current implementation can be viewed here and here  My question is, 
>> > what should be the correct placement of these APIs and hence there naming? 
>> > Can we model it based on the cache-manager (rtems_memory_protection_xx_xx)?
>> >
>> > ___
>> > 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 v3] Changed ARM fenv support similar to X86_64

[Eshan Dhawan]

On Sat, Jul 18, 2020 at 9:32 PM Gedare Bloom  wrote:

> On Sat, Jul 18, 2020 at 9:39 AM Eshan Dhawan 
> wrote:
> >
> >
> > > On 18-Jul-2020, at 8:51 PM, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> > >
> > > On 18/07/2020 17:17, Eshan Dhawan wrote:
> > >
> > > On 18-Jul-2020, at 4:52 PM, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> >  Hello Eshan,
> >  you produce a lot of extra work for me. Your patch applies now. But
> it didn't build:
> >  make[9]: *** No rule to make target 'fenv-vfp.c', needed by
> 'lib_a-fenv-vfp.o'.  Stop.
> >  make[9]: *** Waiting for unfinished jobs
> >  make[9]: Leaving directory
> '/build/git-build/b-gcc-10.1.0-arm-rtems5/arm-rtems5/thumb/newlib/libm/machine/arm'
> > >> Fenv-vpf.c file was deleted as well as the declarations were deleted
> from makefile.am
> > >> So it shouldn’t be compiled
> > >> Did you try Remaking the autoconf files after applying the patch ???
> > >> This patch have the autoconf files
> > > I don't want to run autoconf myself to test your patches. Please
> include the build system changes in your patches.
> > Apologies, I will add the autoconf files from future patches.
>
> auto* generated output is included for newlib patches, but not for
> rtems. We don't keep the generated files in our repo.
>
We don't have to send the auto generated files  in the patch sent to newlib
as well
They are generated by the maintainers there.
So ,I forgot to send in rtems version of the patch as well. Apologies.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v3] Changed ARM fenv support similar to X86_64

[Sebastian Huber]

On 18/07/2020 18:46, Eshan Dhawan wrote:




On Sat, Jul 18, 2020 at 9:32 PM Gedare Bloom > wrote:


On Sat, Jul 18, 2020 at 9:39 AM Eshan Dhawan
mailto:eshandhawa...@gmail.com>> wrote:
>
>
> > On 18-Jul-2020, at 8:51 PM, Sebastian Huber
mailto:sebastian.hu...@embedded-brains.de>> wrote:
> >
> > On 18/07/2020 17:17, Eshan Dhawan wrote:
> >
> > On 18-Jul-2020, at 4:52 PM, Sebastian Huber
mailto:sebastian.hu...@embedded-brains.de>> wrote:
>  Hello Eshan,
>  you produce a lot of extra work for me. Your patch applies
now. But it didn't build:
>  make[9]: *** No rule to make target 'fenv-vfp.c', needed by
'lib_a-fenv-vfp.o'.  Stop.
>  make[9]: *** Waiting for unfinished jobs
>  make[9]: Leaving directory

'/build/git-build/b-gcc-10.1.0-arm-rtems5/arm-rtems5/thumb/newlib/libm/machine/arm'
> >> Fenv-vpf.c file was deleted as well as the declarations were
deleted from makefile.am 
> >> So it shouldn’t be compiled
> >> Did you try Remaking the autoconf files after applying the
patch ???
> >> This patch have the autoconf files
> > I don't want to run autoconf myself to test your patches.
Please include the build system changes in your patches.
> Apologies, I will add the autoconf files from future patches.

auto* generated output is included for newlib patches, but not for
rtems. We don't keep the generated files in our repo.

We don't have to send the auto generated files  in the patch sent to 
newlib as well

They are generated by the maintainers there.
So ,I forgot to send in rtems version of the patch as well. Apologies.


Even though Jeff Johnston mentioned this, not all maintainers do this 
for you.


https://sourceware.org/pipermail/newlib/2020/017679.html

So please regenerate the build files for Newlib patches.

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

Re: [GSoC 2020]: Weekly thread update

[Heinz Junkes]

Mritunjay,
can you try to use the commit 3afec267ab08568ea454789e562450b00feea5c0
Dated 25.9. 2019

From Heinz

> On 17.07.2020, at 20:23, Mritunjay Sharma  
> wrote:
> 
> 
> 
>> On Fri, Jul 17, 2020 at 12:53 PM Heinz Junkes  
>> wrote:
>> You are right. I was not aware of that the dhcpcd stuff is already included 
>> into the source of the epicsPlayground repo. Will have a look into it. 
>> Heinz
>> 
>> FHI, Heinz Junkes
> 
> Thank you so much, Heinz! It will be kind of you to advice for now to how to 
> proceed ahead like whether we have to either 
> use and build the old legacy stack using `--enable-networking` or the libbsd 
> stack? 
> Also, should I start writing the recipe for RSB based on the existing notes 
> of how the process went for building 
> EPICS7 for RTEMS5 for pc-386? 
> 
> Also, I have written another blog on what I learnt recently (using mutt). 
> Here's the link: 
> https://medium.com/@mritunjaysharma394/how-to-set-up-mutt-text-based-mail-client-with-gmail-993ae40b0003
> 
> I also learnt about Networking Drivers from 
> https://docs.rtems.org/branches/master/bsp-howto/networking.html. 
> 
> 
> Thanks,
> Mritunjay. 
> 
> 
>> 
>>> On 15. Jul 2020, at 22:05, Mritunjay Sharma  
>>> wrote:
>>> 
>>> 
>>> Apologies as I mistakenly sent this as a private mail. 
>>> I missed to tag Chris, Gedare and RTEMS Devel and that's why sending this 
>>> again on what 
>>> I responded.
>>> 
 On Wed, Jul 15, 2020 at 10:35 PM Mritunjay Sharma 
  wrote:
 
 
> On Wed, Jul 15, 2020 at 7:48 PM Heinz Junkes  
> wrote:
> Hello, Mritunjay,
> 
> I'm afraid I've lost track of the situation. I am also still on holiday 
> in Norway for 2 weeks and 
> I don't always have perfect internet access.
 
>>>  
>>> This:->
>>>  
 I am extremely sorry to disturb you on a holiday. I will try to bring back 
 to you where we currently are: 
 As advised by you I already have Built EPICS 7 with RTEMS 4.10 and tested 
 it as well. 
 I was doing the same for EPICS7 with RTEMS5 for pc-386. I apologise that I 
 forgot to update the thread that the suggestion 
 presented by Gedare to change to  `#include ` from existing 
 `#include ` helped me 
 fixed the error mentioned in the start of the thread 
 ("../posix/rtems_init.c:38:10: fatal error: rtems/bsd/bsd.h: No such file 
 or directory
  #include ").
 
 I used the 'make' command again then inside `epics-base` (Downloaded from 
 your GitHub's playground) and then got the 
 following error:
 
 `../posix/rtems_init.c:39:10: fatal error: rtems/dhcpcd.h: No such file or 
 directory
  #include 
 `
 I discussed this with Gedare on the IRC channel and we concluded that it 
 is there because we have to either 
 use and build the old legacy stack using `--enable-networking` or the 
 libbsd stack. 
 
 I would like your advice on what should work here and how to approach 
 doing each of these builds? 
 Also, I again apologise that I am disturbing you on a holiday. Please 
 enjoy and take care! 
 
 Thanks
 Mritunjay 
  
> Where can I find your blog. I only found something from June 9th. What is 
> the current location of the blog?
>>> 
>>> This:-> 
 I have made another blog which as of now deals with building BSPs and I 
 have to update the draft of another one 
 which will further demonstrate on how to Build EPICS. 
 The link to the blog is:  
 https://medium.com/@mritunjaysharma394/installing-rtems-ecosystem-and-building-your-first-bsp-993d1cf38902
> 
> I'm afraid you've made a mess of things here.
 
>>> This:- 
 I am sorry if I have and I accept that I am a beginner but am really 
 enjoying the learning I am making this summer. 
 Thank you so much for the support everyone in helping me grow and learn. 
 
 Thanks
 Mritunjay
> 
> In the "official" epics repo, you can read
> 
> https://github.com/epics-base/epics-base/blob/7.0/modules/libcom/RTEMS/rtems_init.c
>  :
> 
> …
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> …
> Here the definition of the legacy stack will be included
> 
> #include 
> 
> 
> 
> Viele Grüße
> Heinz Junkes
> --
> Experience directly varies with equipment ruined.
> 
> 
> 
> > On 15. Jul 2020, at 05:57, Mritunjay Sharma 
> >  wrote:
> > 
> > 
> > 
> > On Wed, Jul 15, 2020 at 5:33 AM Chris Johns  wrote:
> > On 15/7/20 4:30 am, Mritunjay Sharma wrote:
> > > Hello everyone,
> > > 
> > > Pardon my mistake for that long thread. From now on the daily updates 
> > > will be
> > > given on a thread that will end every week. 
> > 
> > Thank you :)
> > 
> > > 1) I studied about https://github.com/RTEMS/rtems-libbsd
> > > 2) Tried to fix the error that 

Re: [GSoC 2020]: Weekly thread update

[Mritunjay Sharma]

Thank you so much, I am trying and reverting soon.

On Sat, Jul 18, 2020 at 10:45 PM Heinz Junkes 
wrote:

> Mritunjay,
> can you try to use the commit 3afec267ab08568ea454789e562450b00feea5c0
> Dated 25.9. 2019
>
> From Heinz
>
> On 17.07.2020, at 20:23, Mritunjay Sharma 
> wrote:
>
>
>
> On Fri, Jul 17, 2020 at 12:53 PM Heinz Junkes 
> wrote:
>
>> You are right. I was not aware of that the dhcpcd stuff is already
>> included into the source of the epicsPlayground repo. Will have a look into
>> it.
>> Heinz
>>
>> FHI, Heinz Junkes
>>
>
> Thank you so much, Heinz! It will be kind of you to advice for now to how
> to proceed ahead like whether we have to either
> use and build the old legacy stack using `--enable-networking` or the
> libbsd stack?
> Also, should I start writing the recipe for RSB based on the existing
> notes of how the process went for building
> EPICS7 for RTEMS5 for pc-386?
>
> Also, I have written another blog on what I learnt recently (using mutt).
> Here's the link:
>
> https://medium.com/@mritunjaysharma394/how-to-set-up-mutt-text-based-mail-client-with-gmail-993ae40b0003
>
> I also learnt about Networking Drivers from
> https://docs.rtems.org/branches/master/bsp-howto/networking.html.
>
>
> Thanks,
> Mritunjay.
>
>
>
>> On 15. Jul 2020, at 22:05, Mritunjay Sharma 
>> wrote:
>>
>> 
>> Apologies as I mistakenly sent this as a private mail.
>> I missed to tag Chris, Gedare and RTEMS Devel and that's why sending this
>> again on what
>> I responded.
>>
>> On Wed, Jul 15, 2020 at 10:35 PM Mritunjay Sharma <
>> mritunjaysharma...@gmail.com> wrote:
>>
>>>
>>>
>>> On Wed, Jul 15, 2020 at 7:48 PM Heinz Junkes 
>>> wrote:
>>>
 Hello, Mritunjay,

 I'm afraid I've lost track of the situation. I am also still on holiday
 in Norway for 2 weeks and
 I don't always have perfect internet access.

>>>
>>>
>> This:->
>>
>>
>>> I am extremely sorry to disturb you on a holiday. I will try to bring
>>> back to you where we currently are:
>>> As advised by you I already have Built EPICS 7 with RTEMS 4.10 and
>>> tested it as well.
>>> I was doing the same for EPICS7 with RTEMS5 for pc-386. I apologise that
>>> I forgot to update the thread that the suggestion
>>> presented by Gedare to change to  `#include ` from existing
>>> `#include ` helped me
>>> fixed the error mentioned in the start of the thread 
>>> ("../posix/rtems_init.c:38:10:
>>> fatal error: rtems/bsd/bsd.h: No such file or directory
>>>  #include ").
>>>
>>> I used the 'make' command again then inside `epics-base` (Downloaded
>>> from your GitHub's playground) and then got the
>>> following error:
>>>
>>> `../posix/rtems_init.c:39:10: fatal error: rtems/dhcpcd.h: No such file
>>> or directory
>>>  #include 
>>> `
>>> I discussed this with Gedare on the IRC channel and we concluded that it
>>> is there because we have to either
>>> use and build the old legacy stack using `--enable-networking` or the
>>> libbsd stack.
>>>
>>> I would like your advice on what should work here and how to approach
>>> doing each of these builds?
>>> Also, I again apologise that I am disturbing you on a holiday. Please
>>> enjoy and take care!
>>>
>>> Thanks
>>> Mritunjay
>>>
>>>
 Where can I find your blog. I only found something from June 9th. What
 is the current location of the blog?
>>>
>>>
>> This:->
>>
>>> I have made another blog which as of now deals with building BSPs and I
>>> have to update the draft of another one
>>> which will further demonstrate on how to Build EPICS.
>>> The link to the blog is:
>>> https://medium.com/@mritunjaysharma394/installing-rtems-ecosystem-and-building-your-first-bsp-993d1cf38902
>>>

 I'm afraid you've made a mess of things here.

>>>
>>> This:-
>>
>>> I am sorry if I have and I accept that I am a beginner but am really
>>> enjoying the learning I am making this summer.
>>> Thank you so much for the support everyone in helping me grow and learn.
>>>
>>> Thanks
>>> Mritunjay
>>>

 In the "official" epics repo, you can read


 https://github.com/epics-base/epics-base/blob/7.0/modules/libcom/RTEMS/rtems_init.c
 :

 …

 #include 
 #include 
 #include 
 #include 
 #include 
 …
 Here the definition of the legacy stack will be included

 #include 



 Viele Grüße
 Heinz Junkes
 --
 Experience directly varies with equipment ruined.



 > On 15. Jul 2020, at 05:57, Mritunjay Sharma <
 mritunjaysharma...@gmail.com> wrote:
 >
 >
 >
 > On Wed, Jul 15, 2020 at 5:33 AM Chris Johns  wrote:
 > On 15/7/20 4:30 am, Mritunjay Sharma wrote:
 > > Hello everyone,
 > >
 > > Pardon my mistake for that long thread. From now on the daily
 updates will be
 > > given on a thread that will end every week.
 >
 > Thank you :)
 >
 > > 1) I studied about https://github.com/RTEMS/rtems-libbsd
 > > 2) Tried to fix the error that I re

[PATCH v4] Changed ARM fenv support and remodeled it similar to RISCV

[Eshan dhawan]

Removed all the Extra files
Added soft fp support similar to RISCV
Has fenv stub implementation.

Signed-off-by: Eshan dhawan 
---
 newlib/libc/machine/arm/machine/fenv-mangle.h |  53 ---
 .../libc/machine/arm/machine/fenv-softfloat.h | 187 --
 newlib/libc/machine/arm/machine/fenv-vfp.h| 187 --
 newlib/libc/machine/arm/sys/fenv.h|  66 +---
 newlib/libm/machine/arm/Makefile.am   |   4 +-
 newlib/libm/machine/arm/Makefile.in   |  19 +-
 newlib/libm/machine/arm/fenv-softfp.c |  32 --
 newlib/libm/machine/arm/fenv-vfp.c|  32 --
 newlib/libm/machine/arm/fenv.c| 319 ++
 9 files changed, 127 insertions(+), 772 deletions(-)
 delete mode 100644 newlib/libc/machine/arm/machine/fenv-mangle.h
 delete mode 100644 newlib/libc/machine/arm/machine/fenv-softfloat.h
 delete mode 100644 newlib/libc/machine/arm/machine/fenv-vfp.h
 delete mode 100644 newlib/libm/machine/arm/fenv-softfp.c
 delete mode 100644 newlib/libm/machine/arm/fenv-vfp.c

diff --git a/newlib/libc/machine/arm/machine/fenv-mangle.h 
b/newlib/libc/machine/arm/machine/fenv-mangle.h
deleted file mode 100644
index 476f7b20c..0
--- a/newlib/libc/machine/arm/machine/fenv-mangle.h
+++ /dev/null
@@ -1,53 +0,0 @@
-/*-
- * Copyright (c) 2013 Andrew Turner 
- * All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *notice, this list of conditions and the following disclaimer in the
- *documentation and/or other materials provided with the distribution.
- *
- * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- *
- * $FreeBSD$
- */
-
-#ifdef _FENV_MANGLE_H_
-#error Only include fenv-mangle.h once
-#endif
-
-#define_FENV_MANGLE_H_
-
-#ifndef FENV_MANGLE
-#error FENV_MANGLE is undefined
-#endif
-
-#definefeclearexcept   FENV_MANGLE(feclearexcept)
-#definefegetexceptflag FENV_MANGLE(fegetexceptflag)
-#definefesetexceptflag FENV_MANGLE(fesetexceptflag)
-#defineferaiseexcept   FENV_MANGLE(feraiseexcept)
-#definefetestexceptFENV_MANGLE(fetestexcept)
-#definefegetround  FENV_MANGLE(fegetround)
-#definefesetround  FENV_MANGLE(fesetround)
-#definefegetenvFENV_MANGLE(fegetenv)
-#definefeholdexceptFENV_MANGLE(feholdexcept)
-#definefesetenvFENV_MANGLE(fesetenv)
-#definefeupdateenv FENV_MANGLE(feupdateenv)
-#definefeenableexcept  FENV_MANGLE(feenableexcept)
-#definefedisableexcept FENV_MANGLE(fedisableexcept)
-#definefegetexcept FENV_MANGLE(fegetexcept)
-
diff --git a/newlib/libc/machine/arm/machine/fenv-softfloat.h 
b/newlib/libc/machine/arm/machine/fenv-softfloat.h
deleted file mode 100644
index 5d33e18d0..0
--- a/newlib/libc/machine/arm/machine/fenv-softfloat.h
+++ /dev/null
@@ -1,187 +0,0 @@
- /*-
- * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
- *
- * Copyright (c) 2004-2011 David Schultz 
- * All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *notice, this list of conditions and the following disclaimer in the
- *documentation and/or other materials provided with the distribution.
- *
- * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, 

Re: [GSoC 2020]: Weekly thread update

[Mritunjay Sharma]

[UPDATE]: Thank you so much Heinz, with commit `
3afec267ab08568ea454789e562450b00feea5c0`v
I was able to successfully built EPICS7 with RTEMS5 for pc-386 and pc-386
qemu both.

As advised, should I begin writing RSB recipe now for RTEMS5?
What can be the next steps?

Please advise and also guide on what will be the best way to begin with
writing RSB recipe?

Thanks
Mritunjay

On Sat, Jul 18, 2020 at 10:48 PM Mritunjay Sharma <
mritunjaysharma...@gmail.com> wrote:

>
> Thank you so much, I am trying and reverting soon.
>
> On Sat, Jul 18, 2020 at 10:45 PM Heinz Junkes 
> wrote:
>
>> Mritunjay,
>> can you try to use the commit 3afec267ab08568ea454789e562450b00feea5c0
>> Dated 25.9. 2019
>>
>> From Heinz
>>
>> On 17.07.2020, at 20:23, Mritunjay Sharma 
>> wrote:
>>
>>
>>
>> On Fri, Jul 17, 2020 at 12:53 PM Heinz Junkes 
>> wrote:
>>
>>> You are right. I was not aware of that the dhcpcd stuff is already
>>> included into the source of the epicsPlayground repo. Will have a look into
>>> it.
>>> Heinz
>>>
>>> FHI, Heinz Junkes
>>>
>>
>> Thank you so much, Heinz! It will be kind of you to advice for now to how
>> to proceed ahead like whether we have to either
>> use and build the old legacy stack using `--enable-networking` or the
>> libbsd stack?
>> Also, should I start writing the recipe for RSB based on the existing
>> notes of how the process went for building
>> EPICS7 for RTEMS5 for pc-386?
>>
>> Also, I have written another blog on what I learnt recently (using mutt).
>> Here's the link:
>>
>> https://medium.com/@mritunjaysharma394/how-to-set-up-mutt-text-based-mail-client-with-gmail-993ae40b0003
>>
>> I also learnt about Networking Drivers from
>> https://docs.rtems.org/branches/master/bsp-howto/networking.html.
>>
>>
>> Thanks,
>> Mritunjay.
>>
>>
>>
>>> On 15. Jul 2020, at 22:05, Mritunjay Sharma <
>>> mritunjaysharma...@gmail.com> wrote:
>>>
>>> 
>>> Apologies as I mistakenly sent this as a private mail.
>>> I missed to tag Chris, Gedare and RTEMS Devel and that's why sending
>>> this again on what
>>> I responded.
>>>
>>> On Wed, Jul 15, 2020 at 10:35 PM Mritunjay Sharma <
>>> mritunjaysharma...@gmail.com> wrote:
>>>


 On Wed, Jul 15, 2020 at 7:48 PM Heinz Junkes 
 wrote:

> Hello, Mritunjay,
>
> I'm afraid I've lost track of the situation. I am also still on
> holiday in Norway for 2 weeks and
> I don't always have perfect internet access.
>


>>> This:->
>>>
>>>
 I am extremely sorry to disturb you on a holiday. I will try to bring
 back to you where we currently are:
 As advised by you I already have Built EPICS 7 with RTEMS 4.10 and
 tested it as well.
 I was doing the same for EPICS7 with RTEMS5 for pc-386. I apologise
 that I forgot to update the thread that the suggestion
 presented by Gedare to change to  `#include ` from
 existing `#include ` helped me
 fixed the error mentioned in the start of the thread 
 ("../posix/rtems_init.c:38:10:
 fatal error: rtems/bsd/bsd.h: No such file or directory
  #include ").

 I used the 'make' command again then inside `epics-base` (Downloaded
 from your GitHub's playground) and then got the
 following error:

 `../posix/rtems_init.c:39:10: fatal error: rtems/dhcpcd.h: No such file
 or directory
  #include 
 `
 I discussed this with Gedare on the IRC channel and we concluded that
 it is there because we have to either
 use and build the old legacy stack using `--enable-networking` or the
 libbsd stack.

 I would like your advice on what should work here and how to approach
 doing each of these builds?
 Also, I again apologise that I am disturbing you on a holiday. Please
 enjoy and take care!

 Thanks
 Mritunjay


> Where can I find your blog. I only found something from June 9th. What
> is the current location of the blog?


>>> This:->
>>>
 I have made another blog which as of now deals with building BSPs and I
 have to update the draft of another one
 which will further demonstrate on how to Build EPICS.
 The link to the blog is:
 https://medium.com/@mritunjaysharma394/installing-rtems-ecosystem-and-building-your-first-bsp-993d1cf38902

>
> I'm afraid you've made a mess of things here.
>

 This:-
>>>
 I am sorry if I have and I accept that I am a beginner but am really
 enjoying the learning I am making this summer.
 Thank you so much for the support everyone in helping me grow and
 learn.

 Thanks
 Mritunjay

>
> In the "official" epics repo, you can read
>
>
> https://github.com/epics-base/epics-base/blob/7.0/modules/libcom/RTEMS/rtems_init.c
> :
>
> …
>
> #include 
> #include 
> #include 
> #include 
> #include 
> …
> Here the definition of the legacy stack will be included
>
> #include 
>
>

Re: [GSoC 2020]: Weekly thread update

[Gedare Bloom]

On Sat, Jul 18, 2020 at 2:02 PM Mritunjay Sharma
 wrote:
>
> [UPDATE]: Thank you so much Heinz, with commit 
> `3afec267ab08568ea454789e562450b00feea5c0`v
> I was able to successfully built EPICS7 with RTEMS5 for pc-386 and pc-386 
> qemu both.
>

Great. Is this with --enable-networking?

Is libbsd still not yet working?

> As advised, should I begin writing RSB recipe now for RTEMS5?
> What can be the next steps?
>

I think so. You might try to write some simple script first for
yourself, to help think through the logic of automation.

> Please advise and also guide on what will be the best way to begin with 
> writing RSB recipe?
>

Now that you know how to build by hand, you want to document what you
need to do and then you can try to script it. I'm not really sure, but
I guess it would be a new kind of "rtems-package" to build, since it
is done after rtems is successfully installed? We'll eventually want
this to be a vertically integrated package with the RTEMS
configuration combined with EPICS for some BSPs that are known to
work. Get started, and ask questions as you go.

work from doco at https://docs.rtems.org/branches/master/user/rsb/index.html
and submit changes as needed to improve it

> Thanks
> Mritunjay
>
> On Sat, Jul 18, 2020 at 10:48 PM Mritunjay Sharma 
>  wrote:
>>
>>
>> Thank you so much, I am trying and reverting soon.
>>
>> On Sat, Jul 18, 2020 at 10:45 PM Heinz Junkes  
>> wrote:
>>>
>>> Mritunjay,
>>> can you try to use the commit 3afec267ab08568ea454789e562450b00feea5c0
>>> Dated 25.9. 2019
>>>
>>> From Heinz
>>>
>>> On 17.07.2020, at 20:23, Mritunjay Sharma  
>>> wrote:
>>>
>>>
>>>
>>> On Fri, Jul 17, 2020 at 12:53 PM Heinz Junkes  
>>> wrote:

 You are right. I was not aware of that the dhcpcd stuff is already 
 included into the source of the epicsPlayground repo. Will have a look 
 into it.
 Heinz

 FHI, Heinz Junkes
>>>
>>>
>>> Thank you so much, Heinz! It will be kind of you to advice for now to how 
>>> to proceed ahead like whether we have to either
>>> use and build the old legacy stack using `--enable-networking` or the 
>>> libbsd stack?
>>> Also, should I start writing the recipe for RSB based on the existing notes 
>>> of how the process went for building
>>> EPICS7 for RTEMS5 for pc-386?
>>>
>>> Also, I have written another blog on what I learnt recently (using mutt). 
>>> Here's the link:
>>> https://medium.com/@mritunjaysharma394/how-to-set-up-mutt-text-based-mail-client-with-gmail-993ae40b0003
>>>
>>> I also learnt about Networking Drivers from 
>>> https://docs.rtems.org/branches/master/bsp-howto/networking.html.
>>>
>>>
>>> Thanks,
>>> Mritunjay.
>>>
>>>

 On 15. Jul 2020, at 22:05, Mritunjay Sharma  
 wrote:

 
 Apologies as I mistakenly sent this as a private mail.
 I missed to tag Chris, Gedare and RTEMS Devel and that's why sending this 
 again on what
 I responded.

 On Wed, Jul 15, 2020 at 10:35 PM Mritunjay Sharma 
  wrote:
>
>
>
> On Wed, Jul 15, 2020 at 7:48 PM Heinz Junkes  
> wrote:
>>
>> Hello, Mritunjay,
>>
>> I'm afraid I've lost track of the situation. I am also still on holiday 
>> in Norway for 2 weeks and
>> I don't always have perfect internet access.
>
>

 This:->

>
> I am extremely sorry to disturb you on a holiday. I will try to bring 
> back to you where we currently are:
> As advised by you I already have Built EPICS 7 with RTEMS 4.10 and tested 
> it as well.
> I was doing the same for EPICS7 with RTEMS5 for pc-386. I apologise that 
> I forgot to update the thread that the suggestion
> presented by Gedare to change to  `#include ` from existing 
> `#include ` helped me
> fixed the error mentioned in the start of the thread 
> ("../posix/rtems_init.c:38:10: fatal error: rtems/bsd/bsd.h: No such file 
> or directory
>  #include ").
>
> I used the 'make' command again then inside `epics-base` (Downloaded from 
> your GitHub's playground) and then got the
> following error:
>
> `../posix/rtems_init.c:39:10: fatal error: rtems/dhcpcd.h: No such file 
> or directory
>  #include 
> `
> I discussed this with Gedare on the IRC channel and we concluded that it 
> is there because we have to either
> use and build the old legacy stack using `--enable-networking` or the 
> libbsd stack.
>
> I would like your advice on what should work here and how to approach 
> doing each of these builds?
> Also, I again apologise that I am disturbing you on a holiday. Please 
> enjoy and take care!
>
> Thanks
> Mritunjay
>
>>
>> Where can I find your blog. I only found something from June 9th. What 
>> is the current location of the blog?


 This:->
>
> I have made another blog which as of now deals with building BSPs and I 
> have to update the draft