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

[Richi Dubey]

>
>
> >   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?

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 <
> sebastian.hu...@embedded-brains.de> 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.
> >
> > ___
> > 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: Need help in understanding some of the existing code in RTEMS

[Richi Dubey]

>
> During system startup the application configuration defines which
> processor is available to RTEMS. Every configured and present processor
> gets an idle thread assigned which is managed by a scheduler. This is
> the starting point of the system. If someone calls
> rtems_scheduler_remove_processor(), then a processor gets removed from a
> scheduler instance. This processor still has to execute code. For this a
> idle thread is used. This idle thread is not managed by a scheduler. If
> someone uses rtems_scheduler_add_processor() this idle thread is again
> controlled by a scheduler.

This makes sense. Thanks.

On Thu, Jul 16, 2020 at 9:17 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 15/07/2020 14:55, Richi Dubey wrote:
>
> > 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?
> >
> During system startup the application configuration defines which
> processor is available to RTEMS. Every configured and present processor
> gets an idle thread assigned which is managed by a scheduler. This is
> the starting point of the system. If someone calls
> rtems_scheduler_remove_processor(), then a processor gets removed from a
> scheduler instance. This processor still has to execute code. For this a
> idle thread is used. This idle thread is not managed by a scheduler. If
> someone uses rtems_scheduler_add_processor() this idle thread is again
> controlled by a scheduler.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] removed SOFTFP fenv support from ARM

[Eshan Dhawan]

> On 17-Jul-2020, at 10:40 AM, Sebastian Huber 
>  wrote:
> 
> On 17/07/2020 01:23, Eshan dhawan wrote:
> 
>>  int fegetexcept(void)
>>  {
>> -int __unmasked;
>>  -__unmasked = 0;
>>  #ifndef SOFTFP_ABI
> 
> Do we need this extra define, can't we use
> 
> #ifndef __SOFTFP__
> 
> like in glibc?

“Paradoxically,the -mfloat-abi=softfp does not set the __SOFTFP___ macro, since 
it selects real floating point instructions using the soft-float ABI at 
function-call interfaces.” 

So SOFTFP_ABI is defined. :)
You can read more here : 
https://wiki.debian.org/ArmEabiPort#:~:text=__VFP_FP__%20means%20that,and%20is%20always%20little%2Dendian
Under “ GCC preprocessor macros for floating point ”

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

Thread 2: Need help in understanding exisiting RTEMS code

[Richi Dubey]

Hi,

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?

How is the priority of a node different from the priority of its
thread? How do these two priorities relate to each other?

Please let me know.
Thanks,
Richi.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] removed SOFTFP fenv support from ARM

[Sebastian Huber]

On 17/07/2020 14:15, Eshan Dhawan wrote:



On 17-Jul-2020, at 10:40 AM, Sebastian Huber 
 wrote:


On 17/07/2020 01:23, Eshan dhawan wrote:


 int fegetexcept(void)
 {
-    int __unmasked;
 -    __unmasked = 0;
 #ifndef SOFTFP_ABI


Do we need this extra define, can't we use

#ifndef __SOFTFP__

like in glibc?


“Paradoxically,the -mfloat-abi=softfp does not set the 
__SOFTFP___ macro, since it selects real floating point instructions 
using the soft-float ABI at function-call interfaces.”

Yes, this is right and in this case we need the VFP implementation.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Sebastian Huber]

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 rtems 3/3] bsps/fdt: Make sure data is cache aligned.

[Gedare Bloom]

The other 2 BSP-specific patches look fine. I didn't look too closely
at the imx-specific part.

On Thu, Jul 16, 2020 at 11:55 PM Christian Mauderer
 wrote:
>
> The cache of the fdt blob is flushed after copy. Therefore it should be
> aligned.
> ---
>  bsps/shared/start/bsp-fdt.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/bsps/shared/start/bsp-fdt.c b/bsps/shared/start/bsp-fdt.c
> index 7e8d8922a8..f55273e4ca 100644
> --- a/bsps/shared/start/bsp-fdt.c
> +++ b/bsps/shared/start/bsp-fdt.c
> @@ -28,10 +28,10 @@
>  #endif
>
>  #ifdef BSP_FDT_BLOB_READ_ONLY
> -static const uint32_t
> +static const uint32_t CPU_STRUCTURE_ALIGNMENT

Typically seen the alignment after the variable decl. Maybe it is
flexible, but we might consider a rule for consistency if both
placements work.

>  bsp_fdt_blob[BSP_FDT_BLOB_SIZE_MAX / sizeof(uint32_t)] = { 0xdeadbeef };
>  #else
> -static uint32_t
> +static uint32_t CPU_STRUCTURE_ALIGNMENT
>  bsp_fdt_blob[BSP_FDT_BLOB_SIZE_MAX / sizeof(uint32_t)];
>  #endif
>
> @@ -48,6 +48,7 @@ void bsp_fdt_copy(const void *src)
>
>if (s != d) {
>  size_t m = MIN(sizeof(bsp_fdt_blob), fdt_totalsize(src));
> +size_t aligned_size = ((m-1) | (CPU_CACHE_LINE_BYTES-1)) + 1;

This is a little bit of magic, I guess it works with cache line bytes
a power of 2. Do we have a macro for this?

>  size_t n = (m + sizeof(*d) - 1) / sizeof(*d);
>  size_t i;
>
> @@ -55,7 +56,7 @@ void bsp_fdt_copy(const void *src)
>d[i] = s[i];
>  }
>
> -rtems_cache_flush_multiple_data_lines(d, m);
> +rtems_cache_flush_multiple_data_lines(d, aligned_size);
>}
>  }
>
> --
> 2.26.2
>
> ___
> 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 v2] Strict thread-stack isolation

[Utkarsh Rai]

On Fri, Jul 17, 2020 at 11:08 AM Gedare Bloom  wrote:

> Is this code working? how do you test it?
>
> There are several points buried below that you might need to bring out
> to separate threads for discussion, while you work on the code.
>
> On Thu, Jul 16, 2020 at 5:34 AM Utkarsh Rai 
> wrote:
> >
> > - This is the complete set of changes for strict isolation of thread
> stacks.
> > - There needs to be a confiuration operation,(#if
> defined(USE_THREAD_STACK_PROTECTION) for simple configuration can be used)
> > - The stack attributes are allocated through malloc, this needs to be
> done through score unlimited objects.
> >
> > Mechanism for thread-stack isolation
> > - Whenever a stack is allocated we assign READ_WRITE  memory attributes
> to the memory region, the stack attribute structure is appended to a chain
> for tracking
> > - On each context switch, the executing stack is marked as 'not-current'
> and we unset its memory attributes. The heir stack is marked as 'current'
> > - On context restore we set the memory attributes of the heir stack and
> iterate thorugh the chain to check for any other 'current' stack and unset
> its memory
> >   attribute (This requires some refinement, so that we don't have to
> iterate over the chain).
>
> Commit formatting:
> https://docs.rtems.org/branches/master/eng/vc-users.html#creating-a-patch
> points to: https://devel.rtems.org/wiki/Developer/Git#GitCommits
> -- that should probably get merged to the docs.
>
> It may not say in our docs, but wrap your commit messages to 80 chars.
> The first line looks best at about 60 characters when it gets used as
> a 'summary'. The way you've written a set of bullets is more like
> paragraphs. You might just aim to write paragraphs. Bullets are nice
> when you want to format a list of related items. In that case, you
> should provide a list heading for some structure/organization.
>
>
> > ---
> >  .../include/bsp/arm-cp15-set-ttb-entries.h|   0
> >  bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c   |  79 
> >  bsps/shared/start/stackalloc.c|  16 ++
> >  c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am  |   5 +-
> >  cpukit/Makefile.am|   1 +
> >  cpukit/headers.am |   2 +
> >  cpukit/include/rtems/score/memorymanagement.h |  89 +
> >  cpukit/include/rtems/score/stackprotection.h  | 149 ++
> >  cpukit/score/cpu/arm/cpu.c|   4 +
> >  cpukit/score/cpu/arm/cpu_asm.S|  43 +++-
> >  .../score/cpu/arm/include/rtems/score/cpu.h   |  18 ++
> >  cpukit/score/src/stackprotection.c| 185 ++
> >  12 files changed, 589 insertions(+), 2 deletions(-)
> >  create mode 100644 bsps/arm/include/bsp/arm-cp15-set-ttb-entries.h
> >  create mode 100644 bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c
> >  create mode 100644 cpukit/include/rtems/score/memorymanagement.h
> >  create mode 100644 cpukit/include/rtems/score/stackprotection.h
> >  create mode 100644 cpukit/score/src/stackprotection.c
> >
> > diff --git a/bsps/arm/include/bsp/arm-cp15-set-ttb-entries.h
> b/bsps/arm/include/bsp/arm-cp15-set-ttb-entries.h
> > new file mode 100644
> > index 00..e69de29bb2
> > diff --git a/bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c
> b/bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c
> > new file mode 100644
> > index 00..0c82f113a9
> > --- /dev/null
> > +++ b/bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c
> > @@ -0,0 +1,79 @@
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
>
> This could use a comment why it is necessary. And also a note about
> converting to a configuration option
> > +#ifdef USE_THREAD_STACK_PROTECTION
> > +  #define ARM_MMU_USE_SMALL_PAGES
> > +#endif
> > +
>
> Although it is not strictly required to have doxygen in the BSPs, I
> would like to see some function documentation of this new interface.
> > +void Memorymanagement_Set_entries(uintptr_t begin, size_t size,
> Memorymanagement_flags flags)
>
> I don't like the namespace choice. Did you discuss this with anyone?
>
> The naming rules are in
> https://docs.rtems.org/branches/master/eng/coding-naming.html
>
> I guess we haven't codified the BSP interface rules. You might inquire
> in a separate thread for some discussion. From what I recall, we have
> bsp_* for some generic kind of functions that should be implemented by
> bsp. So if this is meant to be a BSP implemented interface, you might
> like "bsp_memory_management" or some such.


> Memory management might be an overloaded term that could encompass
> allocation/deallocation, sharing, protection, translation/virtual
> memory, maybe more. If allocation is not in scope, then some other
> name might be better. I guess you may be inspired by MMU.  If the
> point of this interface is to manipulate the mmu/mpu hardware then the
> name should reflect that. I know we've had these discussions in the
> past, every time a student works on this topic--did you l

Re: [GSoC 2020]: Weekly thread update

[Mritunjay Sharma]

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 reported yesterday:
>>> > >
>>> > > ```
>>> >
>>> > Why cut the compile command line used to build this file out of the
>>> message? The
>>> > compiler command is important because it lets us see what paths are
>>> being used
>>> > and I think there may be a problem with them.
>>> >
>>> > > ../posix/rtems_init.c:38:10: fatal error: rtems/bsd/bsd.h: No such
>>> file or directory
>>> > >  #include 
>>> > >   ^
>>> >
>>> > I cannot duplicate thi

Re: [PATCH v2] Strict thread-stack isolation

[Gedare Bloom]

>> > diff --git a/bsps/arm/include/bsp/arm-cp15-set-ttb-entries.h 
>> > b/bsps/arm/include/bsp/arm-cp15-set-ttb-entries.h
>> > new file mode 100644
>> > index 00..e69de29bb2
>> > diff --git a/bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c 
>> > b/bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c
>> > new file mode 100644
>> > index 00..0c82f113a9
>> > --- /dev/null
>> > +++ b/bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c
>> > @@ -0,0 +1,79 @@
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +
>>
>> This could use a comment why it is necessary. And also a note about
>> converting to a configuration option
>> > +#ifdef USE_THREAD_STACK_PROTECTION
>> > +  #define ARM_MMU_USE_SMALL_PAGES
>> > +#endif
>> > +
>>
>> Although it is not strictly required to have doxygen in the BSPs, I
>> would like to see some function documentation of this new interface.
>> > +void Memorymanagement_Set_entries(uintptr_t begin, size_t size, 
>> > Memorymanagement_flags flags)
>>
>> I don't like the namespace choice. Did you discuss this with anyone?
>>
>> The naming rules are in
>> https://docs.rtems.org/branches/master/eng/coding-naming.html
>>
>> I guess we haven't codified the BSP interface rules. You might inquire
>> in a separate thread for some discussion. From what I recall, we have
>> bsp_* for some generic kind of functions that should be implemented by
>> bsp. So if this is meant to be a BSP implemented interface, you might
>> like "bsp_memory_management" or some such.
>>
>>
>> Memory management might be an overloaded term that could encompass
>> allocation/deallocation, sharing, protection, translation/virtual
>> memory, maybe more. If allocation is not in scope, then some other
>> name might be better. I guess you may be inspired by MMU.  If the
>> point of this interface is to manipulate the mmu/mpu hardware then the
>> name should reflect that. I know we've had these discussions in the
>> past, every time a student works on this topic--did you look for/find
>> any prior discussion or interface descriptions?
>>
>
> As you suggested earlier, maybe this can be modeled along the lines of the 
> cache manager?
> Maybe 'rtems_memory_protection_xx_xx'  is a good naming pattern (This will be 
> moved to cpukit/include/rtems)?
>

It depends on whether we really need to expose a runtime interface for
this stuff to users. I'm not convinced that is necessary yet. Not if
we can make most of it work through the configuration space, and
perhaps through existing interfaces like shm and mmap.

We might consider whether runtime changes can be supported through
extending the existing interfaces for task management.

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

[PATCH] Change ARM fenv support similar to x86_64

[Eshan dhawan]

All the extra files have been removed

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|  19 +-
 newlib/libm/machine/arm/Makefile.am   |   4 +-
 newlib/libm/machine/arm/fenv-softfp.c |  32 --
 newlib/libm/machine/arm/fenv-vfp.c|  32 --
 newlib/libm/machine/arm/fenv.c| 315 +++---
 8 files changed, 127 insertions(+), 702 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, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEV

Re: [PATCH] Change ARM fenv support similar to x86_64

[Eshan Dhawan]

Hello everyone,
This is the version 2 of the previous arm fenv patch
apologies, I forgot to add the -v2 in the git send mail

-Eshan

On Sat, Jul 18, 2020 at 2:26 AM Eshan dhawan 
wrote:

> All the extra files have been removed
>
> 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|  19 +-
>  newlib/libm/machine/arm/Makefile.am   |   4 +-
>  newlib/libm/machine/arm/fenv-softfp.c |  32 --
>  newlib/libm/machine/arm/fenv-vfp.c|  32 --
>  newlib/libm/machine/arm/fenv.c| 315 +++---
>  8 files changed, 127 insertions(+), 702 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,

Re: [PATCH] Change ARM fenv support similar to x86_64

[Sebastian Huber]

On 17/07/2020 22:56, Eshan dhawan wrote:


+#ifdef __ARM_PCS_VFP


Why do you use this define an not

#ifndef __SOFTFP__

like glibc?

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

Re: [PATCH] Change ARM fenv support similar to x86_64

[Eshan Dhawan]

On Sat, Jul 18, 2020 at 2:36 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 17/07/2020 22:56, Eshan dhawan wrote:
>
> > +#ifdef __ARM_PCS_VFP
>
> Why do you use this define an not
>
> #ifndef __SOFTFP__
>
> like glibc?
>
OK :)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v3] Changed ARM fenv support similar to X86_64

[Eshan dhawan]

Removed soft float files

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|  19 +-
 newlib/libm/machine/arm/Makefile.am   |   4 +-
 newlib/libm/machine/arm/fenv-softfp.c |  32 --
 newlib/libm/machine/arm/fenv-vfp.c|  32 --
 newlib/libm/machine/arm/fenv.c| 315 +++---
 8 files changed, 127 insertions(+), 702 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, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND

GSoC: Disabling interrupts while modifying translation table entries for armv7-A MMU.

[Utkarsh Rai]

Hello,
The translation table setting code has _ARM_Data_synchronization_barrier()
before and after invalidating the instruction and data TLB entry, this
ensures synchronization of instructions for the TLB invalidation in case of
multiple cores. My question is, do we have to explicitly disable interrupts
too while modifying the translation table entries? The ARM reference manual
is not very clear on this topic.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GSoC: Correct placement and naming of memory protection APIs

[Utkarsh Rai]

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