date:20200814

Re: Quick question: How do I get the name of the scheduler from _Scheduler_Control

2020-08-14 Thread Richi Dubey

Got it, thank you.

On Fri, Aug 14, 2020 at 1:02 AM Gedare Bloom  wrote:

> cpukit/include/rtems/rtems/support.h:RTEMS_INLINE_ROUTINE void
> rtems_name_to_characters(
>
> On Thu, Aug 13, 2020 at 1:15 PM Richi Dubey  wrote:
> >
> > Hi,
> >
> > It's hard to find this with the help of cscope and I would appreciate
> your help in this.
> >
> > Is there a way to print the 'name' in :
> > --
> > struct _Scheduler_Control {
> >   /**
> >* @brief Reference to a statically allocated scheduler context.
> >*/
> >   Scheduler_Context *context;
> >
> >   /**
> >* @brief The scheduler operations.
> >*/
> >   Scheduler_Operations Operations;
> >
> >   /**
> >* @brief The maximum priority value of this scheduler.
> >*
> >* It defines the lowest (least important) thread priority for this
> >* scheduler.  For example the idle threads have this priority.
> >*/
> >   Priority_Control maximum_priority;
> >
> >   /**
> >* @brief The scheduler name.
> >*/
> >   uint32_t name;
> > --
> >
> > as a string? Is there a function that maps this int to string?
> >
> >
> > ___
> > 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

What happens during boot time in terms of scheduling?

2020-08-14 Thread Richi Dubey

Hi,

I've been trying to debug my program and I request someone to help me learn
more about what happens when a system starts. Logically, what is the flow
of things happening? Do all the CPUs start at the same time in the
beginning? Which is the first node that gets scheduled on the CPU?

The current flow I see right now is:

bsp_start_hook_0_done -> boot_card -> rtems_initialize_executive ->
 _RTEMS_tasks_Initialize_user_task -> rtems_task_start and so on.

Is _RTEMS_tasks_Initialize_user_task responsible for starting the Init task?

Also how does the following code which is part
of rtems_initialize_executive:

  /* Invoke the registered system initialization handlers */
  RTEMS_LINKER_SET_FOREACH( _Sysinit, item ) {
( *item->handler )();
  }

call _RTEMS_tasks_Initialize_user_task?

Please let me know.

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

Need help in figuring out how a node gets its afffinity when it is created

2020-08-14 Thread Richi Dubey

Hi,

My code is failing because its logic assumed (code here
)
that it would never get a node with an empty affinity (i.e. no affinity to
any processor or a 0 affinity). This assumption proved wrong as I can see
from the gdb and the current flow of code observed is:


_Scheduler_strong_APA_Get_lowest_scheduled

_Scheduler_SMP_Enqueue

_Scheduler_strong_APA_Enqueue

_Scheduler_SMP_Unblock

_Scheduler_strong_APA_Unblock

_Scheduler_Unblock

_Thread_Clear_state_locked

_Thread_Start

rtems_task_start

_RTEMS_tasks_Initialize_user_task

rtems_initialize_executive

boot_card

bsp_start_hook_0_done


Why is this happening? The Affinity variable (defined here
)
gets set whenever the Set affinity operation corresponding to Strong_APA
scheduler (defined here
)
gets called. So, why wasn't this function called before this happened? Any
help would be appreciated.

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

Re: What happens during boot time in terms of scheduling?

2020-08-14 Thread Richi Dubey

I am looking at cpukit/include/rtems/confdefs/inittask.h right now and so,
I know the answer to:

Is _RTEMS_tasks_Initialize_user_task responsible for starting the Init task?


Still need help with other things.

Thanks.

On Fri, Aug 14, 2020 at 2:55 PM Richi Dubey  wrote:

> Hi,
>
> I've been trying to debug my program and I request someone to help me
> learn more about what happens when a system starts. Logically, what is the
> flow of things happening? Do all the CPUs start at the same time in the
> beginning? Which is the first node that gets scheduled on the CPU?
>
> The current flow I see right now is:
>
> bsp_start_hook_0_done -> boot_card -> rtems_initialize_executive ->
>  _RTEMS_tasks_Initialize_user_task -> rtems_task_start and so on.
>
> Is _RTEMS_tasks_Initialize_user_task responsible for starting the Init
> task?
>
> Also how does the following code which is part
> of rtems_initialize_executive:
>
>   /* Invoke the registered system initialization handlers */
>   RTEMS_LINKER_SET_FOREACH( _Sysinit, item ) {
> ( *item->handler )();
>   }
>
> call _RTEMS_tasks_Initialize_user_task?
>
> Please let me know.
>
> Thanks
>
>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: about FAST_IDLE in Clock_isr

2020-08-14 Thread Joel Sherrill

On Thu, Aug 13, 2020 at 9:49 PM 朱忠杰  wrote:

> Hi, everyone
>
> Is there any consideration why the FAST_IDLE is separated from normal
> path，can I change the FAST_IDLE like the following?
>

The looks reasonably clean. It evolved over time so a clean up may just have
been overdue.

Just to be clear, this is a special mode only to be used on simulators when
you know the only source of interrupts is the clock tick. At this point, I
would
tend to say it is not needed by the sparc BSPs because sis and tsim
are very fast themselves and also recognize when nothing is happening so
can quickly advance the state of the processor to the next event.

But qemu and gdb based simulators tend to need this enabled to speed
up runs of the test application.  sp01 (same as ticker) is a good judge.
It runs for 30 seconds of target time. I have seen it take over 5 minutes on
simulators without fast idle. Also this was added in the days when
development computers were much slower.

If you are looking at fast idle, which BSPs have it as an option would be
good to check also.

--joel

> #if defined(BSP_FEATURE_IRQ_EXTENSION) || \
> (CPU_SIMPLE_VECTORED_INTERRUPTS != TRUE)
> void Clock_isr(void *arg);
> void Clock_isr(void *arg)
> {
> #else
> rtems_isr Clock_isr(rtems_vector_number vector);
> rtems_isr Clock_isr(
>   rtems_vector_number vector
> )
> {
> #endif
>   /*
>*  Accurate count of ISRs
>*/
>   Clock_driver_ticks += 1;
>
>   #if CLOCK_DRIVER_ISRS_PER_TICK
> /*
>  *  The driver is multiple ISRs per clock tick.
>  */
> if ( !Clock_driver_isrs ) {
>   Clock_driver_timecounter_tick();
>
>   Clock_driver_isrs = CLOCK_DRIVER_ISRS_PER_TICK_VALUE;
> }
> Clock_driver_isrs--;
>   #else
> /*
>  *  The driver is one ISR per clock tick.
>  */
> Clock_driver_timecounter_tick();
>
> #if CLOCK_DRIVER_USE_FAST_IDLE
>   if (_SMP_Get_processor_maximum() == 1) {
> struct timecounter *tc;
> uint64_tus_per_tick;
> uint32_tinterval;
> Per_CPU_Control*cpu_self;
>
> cpu_self = _Per_CPU_Get();
> tc = _Timecounter;
> us_per_tick = rtems_configuration_get_microseconds_per_tick();
> interval = (uint32_t) ((tc->tc_frequency * us_per_tick) / 100);
>
> while (
>   cpu_self->thread_dispatch_disable_level ==
> cpu_self->isr_nest_level
> && cpu_self->heir == cpu_self->executing
> && cpu_self->executing->is_idle
> ) {
>   ISR_lock_Context lock_context;
>
>   _Timecounter_Acquire(&lock_context);
>   _Timecounter_Tick_simple(
> interval,
> (*tc->tc_get_timecount)(tc),
> &lock_context
>   );
> }
>   }
> #endif
>   #endif
> /*
>  *  Do the hardware specific per-tick action.
>  *
>  *  The counter/timer may or may not be set to automatically reload.
>  */
> Clock_driver_support_at_tick();
> }
> ___
> 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 figuring out how a node gets its afffinity when it is created

2020-08-14 Thread Richi Dubey

Hi,

Follow up of my progress to this question:

I 'stepped inside' the important functions to make the observation that the
flow of code is actually:

-

_Scheduler_strong_APA_Node_initialize

_Scheduler_Node_initialize

_Thread_Initialize

rtems_task_create

_RTEMS_tasks_Initialize_user_task

rtems_initialize_executive

boot_card

bsp_start_hook_0_done

-
(So, the thread corresponding to the Init task gets created and assigned a
scheduler node which is then initialized and the Init task is started by
calling rtems_task_start on it)


So, is it okay if I set the Affinity (defined here
)
of a node to all processors when it gets initialized (here

) because I remember Mr. Huber telling me earlier that by default a
node/task/thread is allowed to execute on all the processors?




On Fri, Aug 14, 2020 at 3:26 PM Richi Dubey  wrote:

> Hi,
>
> My code is failing because its logic assumed (code here
> )
> that it would never get a node with an empty affinity (i.e. no affinity to
> any processor or a 0 affinity). This assumption proved wrong as I can see
> from the gdb and the current flow of code observed is:
>
> 
> _Scheduler_strong_APA_Get_lowest_scheduled
>
> _Scheduler_SMP_Enqueue
>
> _Scheduler_strong_APA_Enqueue
>
> _Scheduler_SMP_Unblock
>
> _Scheduler_strong_APA_Unblock
>
> _Scheduler_Unblock
>
> _Thread_Clear_state_locked
>
> _Thread_Start
>
> rtems_task_start
>
> _RTEMS_tasks_Initialize_user_task
>
> rtems_initialize_executive
>
> boot_card
>
> bsp_start_hook_0_done
> 
>
> Why is this happening? The Affinity variable (defined here
> )
> gets set whenever the Set affinity operation corresponding to Strong_APA
> scheduler (defined here
> )
> gets called. So, why wasn't this function called before this happened? Any
> help would be appreciated.
>
> Thanks,
> Richi.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Need help in figuring out how a node gets its afffinity when it is created

2020-08-14 Thread Richi Dubey

>
> telling me earlier that by default a node/task/thread is allowed to
> execute on all the processors?

The thread's affinity is set to all processor when it gets initialized :
https://git.rtems.org/rtems/tree/cpukit/score/src/threadinitialize.c#n217

On Fri, Aug 14, 2020 at 5:58 PM Richi Dubey  wrote:

> Hi,
>
> Follow up of my progress to this question:
>
> I 'stepped inside' the important functions to make the observation that
> the flow of code is actually:
>
> -
>
> _Scheduler_strong_APA_Node_initialize
>
> _Scheduler_Node_initialize
>
> _Thread_Initialize
>
> rtems_task_create
>
> _RTEMS_tasks_Initialize_user_task
>
> rtems_initialize_executive
>
> boot_card
>
> bsp_start_hook_0_done
>
> -
> (So, the thread corresponding to the Init task gets created and assigned a
> scheduler node which is then initialized and the Init task is started by
> calling rtems_task_start on it)
>
>
> So, is it okay if I set the Affinity (defined here
> )
> of a node to all processors when it gets initialized (here
> 
> ) because I remember Mr. Huber telling me earlier that by default a
> node/task/thread is allowed to execute on all the processors?
>
>
>
>
> On Fri, Aug 14, 2020 at 3:26 PM Richi Dubey  wrote:
>
>> Hi,
>>
>> My code is failing because its logic assumed (code here
>> )
>> that it would never get a node with an empty affinity (i.e. no affinity to
>> any processor or a 0 affinity). This assumption proved wrong as I can see
>> from the gdb and the current flow of code observed is:
>>
>> 
>> _Scheduler_strong_APA_Get_lowest_scheduled
>>
>> _Scheduler_SMP_Enqueue
>>
>> _Scheduler_strong_APA_Enqueue
>>
>> _Scheduler_SMP_Unblock
>>
>> _Scheduler_strong_APA_Unblock
>>
>> _Scheduler_Unblock
>>
>> _Thread_Clear_state_locked
>>
>> _Thread_Start
>>
>> rtems_task_start
>>
>> _RTEMS_tasks_Initialize_user_task
>>
>> rtems_initialize_executive
>>
>> boot_card
>>
>> bsp_start_hook_0_done
>> 
>>
>> Why is this happening? The Affinity variable (defined here
>> )
>> gets set whenever the Set affinity operation corresponding to Strong_APA
>> scheduler (defined here
>> )
>> gets called. So, why wasn't this function called before this happened? Any
>> help would be appreciated.
>>
>> Thanks,
>> Richi.
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: What happens during boot time in terms of scheduling?

2020-08-14 Thread Sebastian Huber


On 14/08/2020 11:25, Richi Dubey wrote:

Is _RTEMS_tasks_Initialize_user_task responsible for starting the Init 
task?

Yes.


Also how does the following code which is part 
of rtems_initialize_executive:


  /* Invoke the registered system initialization handlers */
  RTEMS_LINKER_SET_FOREACH( _Sysinit, item ) {
    ( *item->handler )();
  }

call _RTEMS_tasks_Initialize_user_task?


This is done via a linker set:

https://docs.rtems.org/branches/master/c-user/linker_sets.html

You can see the entries with this host command line tool:

https://docs.rtems.org/branches/master/user/tools/exeinfo.html

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

Re: Need help in figuring out how a node gets its afffinity when it is created

2020-08-14 Thread Sebastian Huber


On 14/08/2020 14:35, Richi Dubey wrote:


telling me earlier that by default a node/task/thread is allowed
to execute on all the processors?

The thread's affinity is set to all processor when it gets initialized 
: 
https://git.rtems.org/rtems/tree/cpukit/score/src/threadinitialize.c#n217
Yes, this is the initialization value. The scheduler should initialize 
its node accordingly.

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

Re: [PATCH] Strict thread-stack isolation and thread-stack sharing.

2020-08-14 Thread Utkarsh Rai

Sorry for the late reply, I somehow missed the mail notification!

On Thu, Aug 13, 2020 at 9:35 PM Gedare Bloom  wrote:

> On Thu, Aug 13, 2020 at 9:06 AM Utkarsh Rai 
> wrote:
> >
> > -This patch provides thread-stack isolation and thread-stack sharing
> >  mechanism for a POSIX thread.
> >
> Monster patch! think to yourself whether or not it makes sense to
> split these up. The main constraint is that every patch in the series
> should compile/run as they are applied.
>

Maybe I can break this up into 3 separate patches, stack-isolation,
stack-sharing, and the configuration option?


> > -The patches are based on sebastian's build-2 branch of sebastian's repo
> https://git.rtems.org/sebh
> >
> > -Configurations options are provided by using the new-build system.
> Refer to https://ftp.rtems.org/pub/rtems/people/sebh/user.pdf,
> >  chapter 7,for basic setup and
> https://ftp.rtems.org/pub/rtems/people/sebh/eng.pdf(chapter 9) for the
> internals of the build system.
> > ---
> >  .../realview-pbx-a9/mmu/bsp-set-mmu-attr.c|  75 ++
> >  bsps/shared/start/stackalloc.c|  12 +-
> >  .../libbsp/arm/realview-pbx-a9/Makefile.am|   3 +
> >  cpukit/Makefile.am|   1 +
> >  cpukit/headers.am |   2 +
> >  cpukit/include/rtems/score/memoryprotection.h |  91 
> >  cpukit/include/rtems/score/stack.h|  49 +++
> >  cpukit/include/rtems/score/stackprotection.h  |  80 +++
> >  cpukit/include/rtems/score/thread.h   |   1 +
> >  cpukit/posix/src/mmap.c   |  41 +-
> >  cpukit/posix/src/shmwkspace.c |  46 +-
> >  cpukit/score/cpu/arm/cpu_asm.S|  94 
> >  cpukit/score/src/stackprotection.c| 103 +
> >  cpukit/score/src/threadhandler.c  |   6 +
> >  cpukit/score/src/threadinitialize.c   |   9 ++
> >  .../arm/realview-pbx-a9/bsprealviewpbxa9.yml  |   1 +
> >  spec/build/cpukit/cpuopts.yml |   2 +
> >  spec/build/cpukit/librtemscpu.yml |   3 +
> >  .../build/cpukit/optthreadstackprotection.yml |  16 +++
> >  spec/build/testsuites/samples/grp.yml |   4 +
> >  .../samples/threadstackprotection.yml |  19 +++
> >  .../testsuites/samples/threadstacksharing.yml |  19 +++
> >  testsuites/samples/Makefile.am|  16 +++
> >  testsuites/samples/configure.ac   |   2 +
> >  .../samples/thread_stack_protection/init.c| 112 +++
> >  .../thread_stack_protection.doc   |   2 +
> >  .../thread_stack_protection.scn   |  20 +++
> >  .../samples/thread_stack_sharing/init.c   | 136 ++
> >  28 files changed, 959 insertions(+), 6 deletions(-)
> >  create mode 100644 bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
> >  create mode 100644 cpukit/include/rtems/score/memoryprotection.h
> >  create mode 100644 cpukit/include/rtems/score/stackprotection.h
> >  create mode 100644 cpukit/score/src/stackprotection.c
> >  create mode 100644 spec/build/cpukit/optthreadstackprotection.yml
> >  create mode 100644
> spec/build/testsuites/samples/threadstackprotection.yml
> >  create mode 100644 spec/build/testsuites/samples/threadstacksharing.yml
> >  create mode 100644 testsuites/samples/thread_stack_protection/init.c
> >  create mode 100644
> testsuites/samples/thread_stack_protection/thread_stack_protection.doc
> >  create mode 100644
> testsuites/samples/thread_stack_protection/thread_stack_protection.scn
> >  create mode 100644 testsuites/samples/thread_stack_sharing/init.c
> >
> > diff --git a/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
> b/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
> > new file mode 100644
> > index 00..c3b469dd2a
> > --- /dev/null
> > +++ b/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
> > @@ -0,0 +1,75 @@
> file header block?
>
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +static uint32_t translate_flags(uint32_t attr_flags)
> > +{
> > +  uint32_t flags;
> > +  uint32_t memory_attribute;
> > +
> > +  switch (attr_flags)
> > +  {
> > +case RTEMS_READ_WRITE:
> > + flags = ARMV7_MMU_READ_WRITE;
> > + break;
> > +
> > +case RTEMS_READ_ONLY:
> > + flags = ARMV7_MMU_READ_ONLY;
> > + break;
> > +
> > +case RTEMS_NO_ACCESS:
> > +default:
> > + flags = 0;
> > + break;
> > +  }
>
> Does this switch statement work when the attr_flags have other fields
> defined such as RTEMS_MEMORY_CACHED?
>
>
Yes, I missed that.


> When bit flags are not mutually exclusive it makes more sense to write
> as...
>
> if ( (attr_flags & RTEMS_READ_WRITE) == RTEMS_READ_WRITE) ) {
>...
> }
> if ( ... ) {
>   ...
> }
> Maybe it makes more sense to write your helper function this way?
>
> > +
> > + /*
> > +  * Check for memory-cache operation
> > +  */
> > +  if( attr_flags & RTEMS_MEMORY_CACHED ) {
> > +flags |= ARM_MMU_

Re: What happens during boot time in terms of scheduling?

2020-08-14 Thread Richi Dubey

My god. There's so much that a bachelor's degree does not teach.

Thank you for your answer.

On Fri, Aug 14, 2020 at 6:18 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 14/08/2020 11:25, Richi Dubey wrote:
>
> > Is _RTEMS_tasks_Initialize_user_task responsible for starting the Init
> > task?
> Yes.
> >
> > Also how does the following code which is part
> > of rtems_initialize_executive:
> >
> >   /* Invoke the registered system initialization handlers */
> >   RTEMS_LINKER_SET_FOREACH( _Sysinit, item ) {
> > ( *item->handler )();
> >   }
> >
> > call _RTEMS_tasks_Initialize_user_task?
>
> This is done via a linker set:
>
> https://docs.rtems.org/branches/master/c-user/linker_sets.html
>
> You can see the entries with this host command line tool:
>
> https://docs.rtems.org/branches/master/user/tools/exeinfo.html
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: crypt and POSIX

2020-08-14 Thread Joel Sherrill

On Thu, Aug 13, 2020 at 11:49 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 13/08/2020 21:52, Chris Johns wrote:
>
> > On 13/8/20 11:47 pm, Joel Sherrill wrote:
> >> On Thu, Aug 13, 2020 at 7:52 AM Sebastian Huber
> >>  sebastian.hu...@embedded-brains.de>>
> >> wrote:
> >>
> >>  On 13/08/2020 14:49, Joel Sherrill wrote:
> >>
> >>  > Why was crypt() removed? It is in the FreeBSD version at the
> bottom of
> >>  > the file.
> >>  >
> >>  >
> https://github.com/freebsd/freebsd/blob/master/lib/libcrypt/crypt.c
> >>  It is not thread-safe.
> >>
> >> But it is standards compliant.
> > Could it be added and just return NULL or even generate an internal
> error? The
> > lack of crypt stopped me from using and it made me consider the issues.
> It is
> > easy to forget these things when adding passwords to the console or
> telnet
> > server and really hard to see an issue.
>
> If you prefer a run time error to a link time error you can add
> something like this:
>
> char *
> crypt(const char *passwd, const char *salt)
> {
>  errno = ENOSYS;
>  return NULL;
> }
>

We came to general agreement that link-time errors were preferable to
run-time ones during the SMP discussions. So no, I wouldn't want that.
It is either a functional implementation with the known reentrancy issues
or it is missing.

>
> The ready to use shell function to do a login check is:
>
> extern bool rtems_shell_login_check(
>const char *user,
>const char *passphrase
> );
>
> >
> >> And this would seem to violate the rules of source transparency in the
> >> way the code was removed. If you wanted to disable it, it should have
> >> been wrapped in ifndef __rtems__.
> > I am confused, the code in cpukit/libcrypt is not from FreeBSD?
> The file "cpukit/libcrypt/crypt.c" is not from FreeBSD, so there is no
> point of having #ifndef __rtems__ stuff in it. Other files in the
> libcrypt are from FreeBSD.
>

OK. That's why they looked familiar and I missed that crypt.c wasn't BSD.

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

Re: [PATCH] Strict thread-stack isolation and thread-stack sharing.

2020-08-14 Thread Gedare Bloom

On Fri, Aug 14, 2020 at 9:25 AM Utkarsh Rai  wrote:
>
> Sorry for the late reply, I somehow missed the mail notification!
>
> On Thu, Aug 13, 2020 at 9:35 PM Gedare Bloom  wrote:
>>
>> On Thu, Aug 13, 2020 at 9:06 AM Utkarsh Rai  wrote:
>> >
>> > -This patch provides thread-stack isolation and thread-stack sharing
>> >  mechanism for a POSIX thread.
>> >
>> Monster patch! think to yourself whether or not it makes sense to
>> split these up. The main constraint is that every patch in the series
>> should compile/run as they are applied.
>
>
> Maybe I can break this up into 3 separate patches, stack-isolation, 
> stack-sharing, and the configuration option?
>
>>
>> > -The patches are based on sebastian's build-2 branch of sebastian's repo 
>> > https://git.rtems.org/sebh
>> >
>> > -Configurations options are provided by using the new-build system. Refer 
>> > to https://ftp.rtems.org/pub/rtems/people/sebh/user.pdf,
>> >  chapter 7,for basic setup and 
>> > https://ftp.rtems.org/pub/rtems/people/sebh/eng.pdf(chapter 9) for the 
>> > internals of the build system.
>> > ---
>> >  .../realview-pbx-a9/mmu/bsp-set-mmu-attr.c|  75 ++
>> >  bsps/shared/start/stackalloc.c|  12 +-
>> >  .../libbsp/arm/realview-pbx-a9/Makefile.am|   3 +
>> >  cpukit/Makefile.am|   1 +
>> >  cpukit/headers.am |   2 +
>> >  cpukit/include/rtems/score/memoryprotection.h |  91 
>> >  cpukit/include/rtems/score/stack.h|  49 +++
>> >  cpukit/include/rtems/score/stackprotection.h  |  80 +++
>> >  cpukit/include/rtems/score/thread.h   |   1 +
>> >  cpukit/posix/src/mmap.c   |  41 +-
>> >  cpukit/posix/src/shmwkspace.c |  46 +-
>> >  cpukit/score/cpu/arm/cpu_asm.S|  94 
>> >  cpukit/score/src/stackprotection.c| 103 +
>> >  cpukit/score/src/threadhandler.c  |   6 +
>> >  cpukit/score/src/threadinitialize.c   |   9 ++
>> >  .../arm/realview-pbx-a9/bsprealviewpbxa9.yml  |   1 +
>> >  spec/build/cpukit/cpuopts.yml |   2 +
>> >  spec/build/cpukit/librtemscpu.yml |   3 +
>> >  .../build/cpukit/optthreadstackprotection.yml |  16 +++
>> >  spec/build/testsuites/samples/grp.yml |   4 +
>> >  .../samples/threadstackprotection.yml |  19 +++
>> >  .../testsuites/samples/threadstacksharing.yml |  19 +++
>> >  testsuites/samples/Makefile.am|  16 +++
>> >  testsuites/samples/configure.ac   |   2 +
>> >  .../samples/thread_stack_protection/init.c| 112 +++
>> >  .../thread_stack_protection.doc   |   2 +
>> >  .../thread_stack_protection.scn   |  20 +++
>> >  .../samples/thread_stack_sharing/init.c   | 136 ++
>> >  28 files changed, 959 insertions(+), 6 deletions(-)
>> >  create mode 100644 bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
>> >  create mode 100644 cpukit/include/rtems/score/memoryprotection.h
>> >  create mode 100644 cpukit/include/rtems/score/stackprotection.h
>> >  create mode 100644 cpukit/score/src/stackprotection.c
>> >  create mode 100644 spec/build/cpukit/optthreadstackprotection.yml
>> >  create mode 100644 spec/build/testsuites/samples/threadstackprotection.yml
>> >  create mode 100644 spec/build/testsuites/samples/threadstacksharing.yml
>> >  create mode 100644 testsuites/samples/thread_stack_protection/init.c
>> >  create mode 100644 
>> > testsuites/samples/thread_stack_protection/thread_stack_protection.doc
>> >  create mode 100644 
>> > testsuites/samples/thread_stack_protection/thread_stack_protection.scn
>> >  create mode 100644 testsuites/samples/thread_stack_sharing/init.c
>> >
>> > diff --git a/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c 
>> > b/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
>> > new file mode 100644
>> > index 00..c3b469dd2a
>> > --- /dev/null
>> > +++ b/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
>> > @@ -0,0 +1,75 @@
>> file header block?
>>
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +
>> > +static uint32_t translate_flags(uint32_t attr_flags)
>> > +{
>> > +  uint32_t flags;
>> > +  uint32_t memory_attribute;
>> > +
>> > +  switch (attr_flags)
>> > +  {
>> > +case RTEMS_READ_WRITE:
>> > + flags = ARMV7_MMU_READ_WRITE;
>> > + break;
>> > +
>> > +case RTEMS_READ_ONLY:
>> > + flags = ARMV7_MMU_READ_ONLY;
>> > + break;
>> > +
>> > +case RTEMS_NO_ACCESS:
>> > +default:
>> > + flags = 0;
>> > + break;
>> > +  }
>>
>> Does this switch statement work when the attr_flags have other fields
>> defined such as RTEMS_MEMORY_CACHED?
>>
>
> Yes, I missed that.
>
>>
>> When bit flags are not mutually exclusive it makes more sense to write as...
>>
>> if ( (attr_flags & RTEMS_READ_WRITE) == RTEMS_READ_WRITE) ) {
>>...
>> }
>> if ( ... ) {
>>   ...
>> }
>> Maybe it mak

[PATCH v1 2/6] waf: Add path-mappings feature

2020-08-14 Thread Jan Sommer

- path-mappings allow to fix autogenerated include paths for some corner
cases of target platforms without the need to change the build system
- Currently used for i386 based bsps
---
 libbsd.py |  8 
 waf_libbsd.py | 13 +++--
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/libbsd.py b/libbsd.py
index 511de7af..e02226f3 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -90,6 +90,14 @@ _defaults = {
 'cpu-include-paths': ['rtemsbsd/@CPU@/include',
   'freebsd/sys/@CPU@/include'],
 
+#
+# Map paths based on RTEMS naming to FreeBSD naming.
+#
+'path-mappings': [ # (source, targets)
+# i386
+('freebsd/sys/i386/include', ['freebsd/sys/x86/include', 
'freebsd/sys/i386/include']),
+],
+
 # The path where headers will be copied during build.
 'build-include-path': ['build-include'],
 
diff --git a/waf_libbsd.py b/waf_libbsd.py
index 9ac5bf35..14f2ae78 100644
--- a/waf_libbsd.py
+++ b/waf_libbsd.py
@@ -210,8 +210,6 @@ class Builder(builder.ModuleManager):
 buildinclude = 'build-include'
 if 'cpu-include-paths' in config:
 cpu = bld.get_env()['RTEMS_ARCH']
-if cpu == "i386":
-includes += ['freebsd/sys/x86/include']
 for i in config['cpu-include-paths']:
 includes += [i.replace('@CPU@', cpu)]
 if 'include-paths' in config:
@@ -222,6 +220,17 @@ class Builder(builder.ModuleManager):
 buildinclude = buildinclude[0]
 includes += [buildinclude]
 
+#
+# Path mappings
+#
+if 'path-mappings' in config:
+for source, target in config['path-mappings']:
+if source in includes:
+target = [target] if isinstance(target, str) else target
+i = includes.index(source)
+includes.remove(source)
+includes[i:i] = target
+
 #
 # Collect the libbsd uses
 #
-- 
2.17.1

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

[PATCH v1 0/6] [libbsd] Fix e1000 driver for i386 in master and 5

2020-08-14 Thread Jan Sommer

Hello,

I finally got around to port the e1000 driver fixes which are already
present in the 5-freebsd-12 branch of rtems-libbsd also for the master
(and 5) branch.

I created two corresponding tickets for it: 
https://devel.rtems.org/ticket/4052 and
https://devel.rtems.org/ticket/4053.

Could someone please check and push them?

Best regards,

Jan

Jan Sommer (6):
  e1000: Add missing files
  waf: Add path-mappings feature
  i386: Add missing files to build system
  Callout: Redefine callout_reset_on for rtems
  iflib.c: Deactivate use of ifc_cpus
  i386: Delete old machine dependent files

 freebsd/sys/dev/e1000/if_em.c |6 +
 freebsd/sys/i386/include/machine/bus.h|6 -
 freebsd/sys/i386/include/machine/legacyvar.h  |   63 -
 freebsd/sys/i386/include/machine/specialreg.h |6 -
 freebsd/sys/net/iflib.c   | 6827 +
 freebsd/sys/net/iflib_private.h   |   70 +
 freebsd/sys/net/mp_ring.c |  554 ++
 freebsd/sys/net/mp_ring.h |   75 +
 freebsd/sys/sys/callout.h |6 +
 freebsd/sys/x86/include/machine/specialreg.h  | 1143 +++
 freebsd/sys/x86/include/machine/x86_var.h |  145 +
 libbsd.py |   18 +-
 rtemsbsd/include/x86/x86_var.h|  146 +-
 waf_libbsd.py |   13 +-
 14 files changed, 8853 insertions(+), 225 deletions(-)
 delete mode 100644 freebsd/sys/i386/include/machine/bus.h
 delete mode 100644 freebsd/sys/i386/include/machine/legacyvar.h
 delete mode 100644 freebsd/sys/i386/include/machine/specialreg.h
 create mode 100644 freebsd/sys/net/iflib.c
 create mode 100644 freebsd/sys/net/iflib_private.h
 create mode 100644 freebsd/sys/net/mp_ring.c
 create mode 100644 freebsd/sys/net/mp_ring.h
 create mode 100644 freebsd/sys/x86/include/machine/specialreg.h
 create mode 100644 freebsd/sys/x86/include/machine/x86_var.h

-- 
2.17.1

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

[PATCH v1 4/6] Callout: Redefine callout_reset_on for rtems

2020-08-14 Thread Jan Sommer

- callout_reset_on takes a cpu which is ignored by the subsequent call
to callout_reset_sbt_on in RTEMS.
- The macro is redefined to discard the cpu argument directly which
enables uses of it with cpu-dependent variables (disabled in
RETMS) without further changes, e.g. in iflib.c.
---
 freebsd/sys/sys/callout.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/freebsd/sys/sys/callout.h b/freebsd/sys/sys/callout.h
index e5e5df85..d7b9965a 100644
--- a/freebsd/sys/sys/callout.h
+++ b/freebsd/sys/sys/callout.h
@@ -112,9 +112,15 @@ intcallout_reset_sbt_on(struct callout *, 
sbintime_t, sbintime_t,
 #definecallout_reset_sbt_curcpu(c, sbt, pr, fn, arg, flags)
\
 callout_reset_sbt_on((c), (sbt), (pr), (fn), (arg), PCPU_GET(cpuid),\
 (flags))
+#ifndef __rtems__
 #definecallout_reset_on(c, to_ticks, fn, arg, cpu) 
\
 callout_reset_sbt_on((c), tick_sbt * (to_ticks), 0, (fn), (arg),   \
 (cpu), C_HARDCLOCK)
+#else /* __rtems__ */
+#definecallout_reset_on(c, to_ticks, fn, arg, cpu) 
\
+callout_reset_sbt_on((c), tick_sbt * (to_ticks), 0, (fn), (arg),   \
+-1, C_HARDCLOCK)
+#endif /* __rtems__ */
 #definecallout_reset(c, on_tick, fn, arg)  
\
 callout_reset_on((c), (on_tick), (fn), (arg), -1)
 #definecallout_reset_curcpu(c, on_tick, fn, arg)   
\
-- 
2.17.1

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

[PATCH v1 6/6] i386: Delete old machine dependent files

2020-08-14 Thread Jan Sommer

- The files in the i386 directory have been moved to common x86 directories by 
FreeBSD:
  - freebsd/sys/i386/include/machine/bus.h
  - freebsd/sys/x86/include/machine/legacyvar.h
  - freebsd/sys/x86/include/machine/specialreg.h
- Add header files in rtemsbsd directory to direct compiler to new files
---
 freebsd/sys/i386/include/machine/bus.h|   6 -
 freebsd/sys/i386/include/machine/legacyvar.h  |  63 
 freebsd/sys/i386/include/machine/specialreg.h |   6 -
 rtemsbsd/include/x86/x86_var.h| 146 +-
 4 files changed, 1 insertion(+), 220 deletions(-)
 delete mode 100644 freebsd/sys/i386/include/machine/bus.h
 delete mode 100644 freebsd/sys/i386/include/machine/legacyvar.h
 delete mode 100644 freebsd/sys/i386/include/machine/specialreg.h

diff --git a/freebsd/sys/i386/include/machine/bus.h 
b/freebsd/sys/i386/include/machine/bus.h
deleted file mode 100644
index f1af2cf6..
--- a/freebsd/sys/i386/include/machine/bus.h
+++ /dev/null
@@ -1,6 +0,0 @@
-/*-
- * This file is in the public domain.
- */
-/* $FreeBSD$ */
-
-#include 
diff --git a/freebsd/sys/i386/include/machine/legacyvar.h 
b/freebsd/sys/i386/include/machine/legacyvar.h
deleted file mode 100644
index 14dd9e03..
--- a/freebsd/sys/i386/include/machine/legacyvar.h
+++ /dev/null
@@ -1,63 +0,0 @@
-/*-
- * Copyright (c) 2000 Peter Wemm 
- * 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$
- */
-
-#ifndef _MACHINE_LEGACYVAR_H_
-#define_MACHINE_LEGACYVAR_H_
-
-enum legacy_device_ivars {
-   LEGACY_IVAR_PCIDOMAIN,
-   LEGACY_IVAR_PCIBUS,
-   LEGACY_IVAR_PCISLOT,
-   LEGACY_IVAR_PCIFUNC
-};
-
-#define LEGACY_ACCESSOR(var, ivar, type)   \
-__BUS_ACCESSOR(legacy, var, LEGACY, ivar, type)
-
-LEGACY_ACCESSOR(pcidomain, PCIDOMAIN,  uint32_t)
-LEGACY_ACCESSOR(pcibus,PCIBUS, uint32_t)
-LEGACY_ACCESSOR(pcislot,   PCISLOT,int)
-LEGACY_ACCESSOR(pcifunc,   PCIFUNC,int)
-
-#undef LEGACY_ACCESSOR
-
-intlegacy_pcib_maxslots(device_t dev);
-uint32_t legacy_pcib_read_config(device_t dev, u_int bus, u_int slot, u_int 
func,
-u_int reg, int bytes);
-intlegacy_pcib_read_ivar(device_t dev, device_t child, int which,
-uintptr_t *result);
-void   legacy_pcib_write_config(device_t dev, u_int bus, u_int slot, u_int 
func,
-u_int reg, u_int32_t data, int bytes);
-intlegacy_pcib_write_ivar(device_t dev, device_t child, int which,
-uintptr_t value);
-struct resource *legacy_pcib_alloc_resource(device_t dev, device_t child,
-int type, int *rid, u_long start, u_long end, u_long count, u_int flags);
-intlegacy_pcib_map_msi(device_t pcib, device_t dev, int irq,
-uint64_t *addr, uint32_t *data);
-
-#endif /* !_MACHINE_LEGACYVAR_H_ */
diff --git a/freebsd/sys/i386/include/machine/specialreg.h 
b/freebsd/sys/i386/include/machine/specialreg.h
deleted file mode 100644
index aace4bfd..
--- a/freebsd/sys/i386/include/machine/specialreg.h
+++ /dev/null
@@ -1,6 +0,0 @@
-/*-
- * This file is in the public domain.
- */
-/* $FreeBSD$ */
-
-#include 
diff --git a/rtemsbsd/include/x86/x86_var.h b/rtemsbsd/include/x86/x86_var.h
index 2028d739..5819205a 100644
--- a/rtemsbsd/include/x86/x86_var.h
+++ b/rtemsbsd/include/x86/x86_var.h
@@ -1,145 +1 @@
-/*-
- * Copyright (c) 1995 Bruce D. Evans.
- * 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

[PATCH v1 5/6] iflib.c: Deactivate use of ifc_cpus

2020-08-14 Thread Jan Sommer

- cpusets and SMP are currently not supported in libbsd for RTEMS
- Disable the ifc_cpus context variable and replace its usage,
essentially hard-coding for cpu 0
---
 freebsd/sys/dev/e1000/if_em.c |  6 ++
 freebsd/sys/net/iflib.c   | 22 ++
 2 files changed, 28 insertions(+)

diff --git a/freebsd/sys/dev/e1000/if_em.c b/freebsd/sys/dev/e1000/if_em.c
index 32eb4afe..4fc6e7b6 100644
--- a/freebsd/sys/dev/e1000/if_em.c
+++ b/freebsd/sys/dev/e1000/if_em.c
@@ -1837,8 +1837,14 @@ em_if_update_admin_status(if_ctx_t ctx)
 
if (adapter->hw.mac.type < em_mac_min)
lem_smartspeed(adapter);
+#ifdef __rtems__
+   else if (hw->mac.type == e1000_82574 &&
+   adapter->intr_type == IFLIB_INTR_MSIX)
+   E1000_WRITE_REG(&adapter->hw, E1000_IMS, EM_MSIX_LINK | 
E1000_IMS_LSC);
+#else /* __rtems__ */
 
E1000_WRITE_REG(&adapter->hw, E1000_IMS, EM_MSIX_LINK | E1000_IMS_LSC);
+#endif /* __rtems__ */
 }
 
 static void
diff --git a/freebsd/sys/net/iflib.c b/freebsd/sys/net/iflib.c
index 7183e1e5..733172dc 100644
--- a/freebsd/sys/net/iflib.c
+++ b/freebsd/sys/net/iflib.c
@@ -159,7 +159,9 @@ struct iflib_ctx {
device_t ifc_dev;
if_t ifc_ifp;
 
+#ifndef __rtems__
cpuset_t ifc_cpus;
+#endif /* __rtems__ */
if_shared_ctx_t ifc_sctx;
struct if_softc_ctx ifc_softc_ctx;
 
@@ -4498,6 +4500,7 @@ get_ctx_core_offset(if_ctx_t ctx)
qc = max(scctx->isc_ntxqsets, scctx->isc_nrxqsets);
 
mtx_lock(&cpu_offset_mtx);
+#ifndef __rtems__
SLIST_FOREACH(op, &cpu_offsets, entries) {
if (CPU_CMP(&ctx->ifc_cpus, &op->set) == 0) {
ret = op->offset;
@@ -4507,6 +4510,7 @@ get_ctx_core_offset(if_ctx_t ctx)
break;
}
}
+#endif /* __rtems__ */
if (ret == CORE_OFFSET_UNSPECIFIED) {
ret = 0;
op = malloc(sizeof(struct cpu_offset), M_IFLIB,
@@ -4517,7 +4521,9 @@ get_ctx_core_offset(if_ctx_t ctx)
} else {
op->offset = qc;
op->refcount = 1;
+#ifndef __rtems__
CPU_COPY(&ctx->ifc_cpus, &op->set);
+#endif /* __rtems__ */
SLIST_INSERT_HEAD(&cpu_offsets, op, entries);
}
}
@@ -4533,7 +4539,11 @@ unref_ctx_core_offset(if_ctx_t ctx)
 
mtx_lock(&cpu_offset_mtx);
SLIST_FOREACH_SAFE(op, &cpu_offsets, entries, top) {
+#ifndef __rtems__
if (CPU_CMP(&ctx->ifc_cpus, &op->set) == 0) {
+#else /* __rtems__ */
+   {
+#endif /* __rtems__ */
MPASS(op->refcount > 0);
op->refcount--;
if (op->refcount == 0) {
@@ -4647,12 +4657,14 @@ iflib_device_register(device_t dev, void *sc, 
if_shared_ctx_t sctx, if_ctx_t *ct
taskqgroup_attach(qgroup_if_config_tqg, &ctx->ifc_admin_task, ctx,
NULL, NULL, "admin");
 
+#ifndef __rtems__
/* Set up cpu set.  If it fails, use the set of all CPUs. */
if (bus_get_cpus(dev, INTR_CPUS, sizeof(ctx->ifc_cpus), &ctx->ifc_cpus) 
!= 0) {
device_printf(dev, "Unable to fetch CPU list\n");
CPU_COPY(&all_cpus, &ctx->ifc_cpus);
}
MPASS(CPU_COUNT(&ctx->ifc_cpus) > 0);
+#endif /* __rtems__ */
 
/*
** Now set up MSI or MSI-X, should return us the number of supported
@@ -5484,7 +5496,9 @@ iflib_queues_alloc(if_ctx_t ctx)
txq->ift_br_offset = 0;
}
/* XXX fix this */
+#ifndef __rtems__
txq->ift_timer.c_cpu = cpu;
+#endif /* __rtems__ */
 
if (iflib_txsd_alloc(txq)) {
device_printf(dev, "Critical Failure setting up TX 
buffers\n");
@@ -6291,11 +6305,19 @@ iflib_msix_init(if_ctx_t ctx)
 #else
queues = queuemsgs;
 #endif
+#ifndef __rtems__
queues = imin(CPU_COUNT(&ctx->ifc_cpus), queues);
+#else /* __rtems__ */
+   queues = imin(1, queues);
+#endif /* __rtems__ */
if (bootverbose)
device_printf(dev,
"intr CPUs: %d queue msgs: %d admincnt: %d\n",
+#ifndef __rtems__
CPU_COUNT(&ctx->ifc_cpus), queuemsgs, admincnt);
+#else /* __rtems__ */
+   1, queuemsgs, admincnt);
+#endif /* __rtems__ */
 #ifdef  RSS
/* If we're doing RSS, clamp at the number of RSS buckets */
if (queues > rss_getnumbuckets())
-- 
2.17.1

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

[PATCH v1 3/6] i386: Add missing files to build system

2020-08-14 Thread Jan Sommer

- Update FreeBSD files in libbsd.py to required by i386 based BSPs
- Add missing files e1000 network driver (iflib*)
---
 libbsd.py | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/libbsd.py b/libbsd.py
index e02226f3..08931401 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -1506,10 +1506,14 @@ class dev_net(builder.Module):
 'sys/net/if_types.h',
 'sys/net/if_var.h',
 'sys/net/vnet.h',
+'sys/net/mp_ring.h',
+'sys/net/iflib_private.h',
 ]
 )
 self.addKernelSpaceSourceFiles(
 [
+'sys/net/iflib.c',
+'sys/net/mp_ring.c',
 'sys/arm/ti/cpsw/if_cpsw.c',
 'sys/dev/ffec/if_ffec.c',
 'sys/dev/mii/mii.c',
@@ -1562,12 +1566,13 @@ class dev_nic(builder.Module):
 self.addCPUDependentFreeBSDHeaderFiles(
 [
 'sys/arm/include/cpufunc.h',
-'sys/i386/include/specialreg.h',
 'sys/i386/include/md_var.h',
 'sys/i386/include/intr_machdep.h',
 'sys/x86/include/intr_machdep.h',
-'sys/x86/include/metadata.h',
 'sys/i386/include/cpufunc.h',
+'sys/x86/include/intr_machdep.h',
+'sys/x86/include/specialreg.h',
+'sys/x86/include/x86_var.h',
 'sys/mips/include/cpufunc.h',
 'sys/mips/include/cpuregs.h',
 'sys/powerpc/include/cpufunc.h',
@@ -2753,7 +2758,6 @@ class pci(builder.Module):
 self.addCPUDependentFreeBSDHeaderFiles(
 [
 'sys/i386/include/_bus.h',
-'sys/i386/include/bus.h',
 'sys/x86/include/legacyvar.h',
 'sys/x86/include/bus.h',
 'sys/x86/include/pci_cfgreg.h',
-- 
2.17.1

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

RTEMS 5.1 RC2 Available

2020-08-14 Thread Chris Johns

Hello,

RTEMS 5.1 RC2 is available for testing. You can find the release at:

  https://ftp.rtems.org/pub/rtems/releases/5/rc/5.1-rc2

Please report your successes or problems here.
You can also raise a ticket if you prefer. Please select the 5.1 milestone.

The RC is now correctly named with a 2 number version number.

The changes since RC1 are:

 
https://devel.rtems.org/query?changetime=Jun+26%2C+2020..&milestone=5.1&group=resolution&order=id

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

Re: [PATCH v1 0/6] [libbsd] Fix e1000 driver for i386 in master and 5

2020-08-14 Thread Chris Johns

On 15/8/20 5:57 am, Jan Sommer wrote:
> Hello,
> 
> I finally got around to port the e1000 driver fixes which are already
> present in the 5-freebsd-12 branch of rtems-libbsd also for the master
> (and 5) branch.

Thanks. I will push these soon.

I am not sure if the 5 branch in the rtems-libbsd.git repo is right and if it
should be made from the 5-freebsd-12 branch? I feel it is currently confusing
but either way it has issues.

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

Re: [PATCH v1 0/6] [libbsd] Fix e1000 driver for i386 in master and 5

2020-08-14 Thread Joel Sherrill

On Fri, Aug 14, 2020 at 4:42 PM Chris Johns  wrote:

> On 15/8/20 5:57 am, Jan Sommer wrote:
> > Hello,
> >
> > I finally got around to port the e1000 driver fixes which are already
> > present in the 5-freebsd-12 branch of rtems-libbsd also for the master
> > (and 5) branch.
>
> Thanks. I will push these soon.
>
> I am not sure if the 5 branch in the rtems-libbsd.git repo is right and if
> it
> should be made from the 5-freebsd-12 branch? I feel it is currently
> confusing
> but either way it has issues.
>

If I remember correctly, Sebastian told me 5 was FreeBSD master on RTEMS 5.
If that's right, it would have been better with the longer name
5-freebsd-master since
we use 5 as the name for other repos to indicate trusted "5".

--joel

>
> Chris
> ___
> 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: What happens during boot time in terms of scheduling?

2020-08-14 Thread Joel Sherrill

On Fri, Aug 14, 2020 at 10:51 AM Richi Dubey  wrote:

> My god. There's so much that a bachelor's degree does not teach.
>

This particular one definitely qualifies as an example of Arthur C.
Clarke's Third Law to me. :)

Clarke's Third Law: Any sufficiently advanced technology is
indistinguishable from magic.
Profiles of the Future (revised edition, 1973)

It really is quite simply once you see the end result. There is just an
array of
function pointers in a special section with a start and end symbol. And a
loop to go over them at init time. All built up by the linker based on
dependencies.

--joel

> Thank you for your answer.
>
> On Fri, Aug 14, 2020 at 6:18 PM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 14/08/2020 11:25, Richi Dubey wrote:
>>
>> > Is _RTEMS_tasks_Initialize_user_task responsible for starting the Init
>> > task?
>> Yes.
>> >
>> > Also how does the following code which is part
>> > of rtems_initialize_executive:
>> >
>> >   /* Invoke the registered system initialization handlers */
>> >   RTEMS_LINKER_SET_FOREACH( _Sysinit, item ) {
>> > ( *item->handler )();
>> >   }
>> >
>> > call _RTEMS_tasks_Initialize_user_task?
>>
>> This is done via a linker set:
>>
>> https://docs.rtems.org/branches/master/c-user/linker_sets.html
>>
>> You can see the entries with this host command line tool:
>>
>> https://docs.rtems.org/branches/master/user/tools/exeinfo.html
>>
>> ___
> 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 v1 0/6] [libbsd] Fix e1000 driver for i386 in master and 5

2020-08-14 Thread Chris Johns

On 15/8/20 8:31 am, Joel Sherrill wrote:
> On Fri, Aug 14, 2020 at 4:42 PM Chris Johns  > wrote:
> 
> On 15/8/20 5:57 am, Jan Sommer wrote:
> > Hello,
> >
> > I finally got around to port the e1000 driver fixes which are already
> > present in the 5-freebsd-12 branch of rtems-libbsd also for the master
> > (and 5) branch.
> 
> Thanks. I will push these soon.
> 
> I am not sure if the 5 branch in the rtems-libbsd.git repo is right and 
> if it
> should be made from the 5-freebsd-12 branch? I feel it is currently 
> confusing
> but either way it has issues.
> 
> If I remember correctly, Sebastian told me 5 was FreeBSD master on RTEMS 5.
> If that's right, it would have been better with the longer name 
> 5-freebsd-master
> since we use 5 as the name for other repos to indicate trusted "5".

Problems appear when we have variants in names because management around the
repos needs to handle special cases ...

https://git.rtems.org/rtems-release/tree/rtems-release-package-start?h=5#n109

On the other hand the difference in one repo like libbsd has created a special
case in the release scripts because 5 was being picked up and released without
error until I caught it testing. Thus the need for the mapping and that rippled
out in to other issues.

I am not sure what the answer is but any solution or change needs to be worked
through our procedures.

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

Re: [PATCH v1 0/6] [libbsd] Fix e1000 driver for i386 in master and 5

2020-08-14 Thread Joel Sherrill

On Fri, Aug 14, 2020, 7:04 PM Chris Johns  wrote:

> On 15/8/20 8:31 am, Joel Sherrill wrote:
> > On Fri, Aug 14, 2020 at 4:42 PM Chris Johns  > > wrote:
> >
> > On 15/8/20 5:57 am, Jan Sommer wrote:
> > > Hello,
> > >
> > > I finally got around to port the e1000 driver fixes which are
> already
> > > present in the 5-freebsd-12 branch of rtems-libbsd also for the
> master
> > > (and 5) branch.
> >
> > Thanks. I will push these soon.
> >
> > I am not sure if the 5 branch in the rtems-libbsd.git repo is right
> and if it
> > should be made from the 5-freebsd-12 branch? I feel it is currently
> confusing
> > but either way it has issues.
> >
> > If I remember correctly, Sebastian told me 5 was FreeBSD master on RTEMS
> 5.
> > If that's right, it would have been better with the longer name
> 5-freebsd-master
> > since we use 5 as the name for other repos to indicate trusted "5".
>
> Problems appear when we have variants in names because management around
> the
> repos needs to handle special cases ...
>
>
> https://git.rtems.org/rtems-release/tree/rtems-release-package-start?h=5#n109
>
> On the other hand the difference in one repo like libbsd has created a
> special
> case in the release scripts because 5 was being picked up and released
> without
> error until I caught it testing. Thus the need for the mapping and that
> rippled
> out in to other issues.
>
> I am not sure what the answer is but any solution or change needs to be
> worked
> through our procedures.
>

+1

I rather like the idea of combining RTEMS version with the bsd version in
the branch name. I know it is a bit of a pain in scripts..even explaining
it to people is odd. But a regular pattern would help and not having simple
numbers would help avoid mistakes.

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

Re: [PATCH] Strict thread-stack isolation and thread-stack sharing.

2020-08-14 Thread Utkarsh Rai

On Sat, Aug 15, 2020 at 12:39 AM Gedare Bloom  wrote:

> On Fri, Aug 14, 2020 at 9:25 AM Utkarsh Rai 
> wrote:
> >
> > Sorry for the late reply, I somehow missed the mail notification!
> >
> > On Thu, Aug 13, 2020 at 9:35 PM Gedare Bloom  wrote:
> >>
> >> On Thu, Aug 13, 2020 at 9:06 AM Utkarsh Rai 
> wrote:
> >> >
> >> > -This patch provides thread-stack isolation and thread-stack sharing
> >> >  mechanism for a POSIX thread.
> >> >
> >> Monster patch! think to yourself whether or not it makes sense to
> >> split these up. The main constraint is that every patch in the series
> >> should compile/run as they are applied.
> >
> >
> > Maybe I can break this up into 3 separate patches, stack-isolation,
> stack-sharing, and the configuration option?
> >
> >>
> >> > -The patches are based on sebastian's build-2 branch of sebastian's
> repo https://git.rtems.org/sebh
> >> >
> >> > -Configurations options are provided by using the new-build system.
> Refer to https://ftp.rtems.org/pub/rtems/people/sebh/user.pdf,
> >> >  chapter 7,for basic setup and
> https://ftp.rtems.org/pub/rtems/people/sebh/eng.pdf(chapter 9) for the
> internals of the build system.
> >> > ---
> >> >  .../realview-pbx-a9/mmu/bsp-set-mmu-attr.c|  75 ++
> >> >  bsps/shared/start/stackalloc.c|  12 +-
> >> >  .../libbsp/arm/realview-pbx-a9/Makefile.am|   3 +
> >> >  cpukit/Makefile.am|   1 +
> >> >  cpukit/headers.am |   2 +
> >> >  cpukit/include/rtems/score/memoryprotection.h |  91 
> >> >  cpukit/include/rtems/score/stack.h|  49 +++
> >> >  cpukit/include/rtems/score/stackprotection.h  |  80 +++
> >> >  cpukit/include/rtems/score/thread.h   |   1 +
> >> >  cpukit/posix/src/mmap.c   |  41 +-
> >> >  cpukit/posix/src/shmwkspace.c |  46 +-
> >> >  cpukit/score/cpu/arm/cpu_asm.S|  94 
> >> >  cpukit/score/src/stackprotection.c| 103 +
> >> >  cpukit/score/src/threadhandler.c  |   6 +
> >> >  cpukit/score/src/threadinitialize.c   |   9 ++
> >> >  .../arm/realview-pbx-a9/bsprealviewpbxa9.yml  |   1 +
> >> >  spec/build/cpukit/cpuopts.yml |   2 +
> >> >  spec/build/cpukit/librtemscpu.yml |   3 +
> >> >  .../build/cpukit/optthreadstackprotection.yml |  16 +++
> >> >  spec/build/testsuites/samples/grp.yml |   4 +
> >> >  .../samples/threadstackprotection.yml |  19 +++
> >> >  .../testsuites/samples/threadstacksharing.yml |  19 +++
> >> >  testsuites/samples/Makefile.am|  16 +++
> >> >  testsuites/samples/configure.ac   |   2 +
> >> >  .../samples/thread_stack_protection/init.c| 112 +++
> >> >  .../thread_stack_protection.doc   |   2 +
> >> >  .../thread_stack_protection.scn   |  20 +++
> >> >  .../samples/thread_stack_sharing/init.c   | 136
> ++
> >> >  28 files changed, 959 insertions(+), 6 deletions(-)
> >> >  create mode 100644 bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
> >> >  create mode 100644 cpukit/include/rtems/score/memoryprotection.h
> >> >  create mode 100644 cpukit/include/rtems/score/stackprotection.h
> >> >  create mode 100644 cpukit/score/src/stackprotection.c
> >> >  create mode 100644 spec/build/cpukit/optthreadstackprotection.yml
> >> >  create mode 100644
> spec/build/testsuites/samples/threadstackprotection.yml
> >> >  create mode 100644
> spec/build/testsuites/samples/threadstacksharing.yml
> >> >  create mode 100644 testsuites/samples/thread_stack_protection/init.c
> >> >  create mode 100644
> testsuites/samples/thread_stack_protection/thread_stack_protection.doc
> >> >  create mode 100644
> testsuites/samples/thread_stack_protection/thread_stack_protection.scn
> >> >  create mode 100644 testsuites/samples/thread_stack_sharing/init.c
> >> >
> >> > diff --git a/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
> b/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
> >> > new file mode 100644
> >> > index 00..c3b469dd2a
> >> > --- /dev/null
> >> > +++ b/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
> >> > @@ -0,0 +1,75 @@
> >> file header block?
> >>
> >> > +#include 
> >> > +#include 
> >> > +#include 
> >> > +#include 
> >> > +
> >> > +static uint32_t translate_flags(uint32_t attr_flags)
> >> > +{
> >> > +  uint32_t flags;
> >> > +  uint32_t memory_attribute;
> >> > +
> >> > +  switch (attr_flags)
> >> > +  {
> >> > +case RTEMS_READ_WRITE:
> >> > + flags = ARMV7_MMU_READ_WRITE;
> >> > + break;
> >> > +
> >> > +case RTEMS_READ_ONLY:
> >> > + flags = ARMV7_MMU_READ_ONLY;
> >> > + break;
> >> > +
> >> > +case RTEMS_NO_ACCESS:
> >> > +default:
> >> > + flags = 0;
> >> > + break;
> >> > +  }
> >>
> >> Does this switch statement work when the attr_flags have other fields
> >> defined such as RTEMS_MEMORY_CACHED?
>

Re: Quick question: How do I get the name of the scheduler from _Scheduler_Control

What happens during boot time in terms of scheduling?

Need help in figuring out how a node gets its afffinity when it is created

Re: What happens during boot time in terms of scheduling?

Re: about FAST_IDLE in Clock_isr

Re: Need help in figuring out how a node gets its afffinity when it is created

Re: Need help in figuring out how a node gets its afffinity when it is created

Re: What happens during boot time in terms of scheduling?

Re: Need help in figuring out how a node gets its afffinity when it is created

Re: [PATCH] Strict thread-stack isolation and thread-stack sharing.

Re: What happens during boot time in terms of scheduling?

Re: crypt and POSIX

Re: [PATCH] Strict thread-stack isolation and thread-stack sharing.

[PATCH v1 2/6] waf: Add path-mappings feature

[PATCH v1 0/6] [libbsd] Fix e1000 driver for i386 in master and 5

[PATCH v1 4/6] Callout: Redefine callout_reset_on for rtems

[PATCH v1 6/6] i386: Delete old machine dependent files

[PATCH v1 5/6] iflib.c: Deactivate use of ifc_cpus

[PATCH v1 3/6] i386: Add missing files to build system

RTEMS 5.1 RC2 Available

Re: [PATCH v1 0/6] [libbsd] Fix e1000 driver for i386 in master and 5

Re: [PATCH v1 0/6] [libbsd] Fix e1000 driver for i386 in master and 5

Re: What happens during boot time in terms of scheduling?

Re: [PATCH v1 0/6] [libbsd] Fix e1000 driver for i386 in master and 5

Re: [PATCH v1 0/6] [libbsd] Fix e1000 driver for i386 in master and 5

Re: [PATCH] Strict thread-stack isolation and thread-stack sharing.

26 matches

Site Navigation

Mail list logo

Footer information