date:20210615

Re: [rtems-tools commit] rtems-bsp-builder: Change to waf build system

2021-06-15 Thread Chris Johns

On 15/6/21 4:50 pm, Sebastian Huber wrote:
> On 15/06/2021 08:46, Chris Johns wrote:
>> If this is pushed through and the task it left for the "demand" queue it is
>> actually being placed on my queue because I am the one releasing RTEMS and I
>> think having these sorts of things resolved at release time is not great 
>> because
>> there is never enough testing.
> 
> I don't think this would have happened. 

Thanks and I hope it does not.

> I usually fix things which I broke (in
> this case the removal of the old build system). I just don't like it to waste 
> my
> time on things which have no future and this is definitely the old build 
> system.

I also see no future holding onto the old build system and agree it is a waste
of time. I am not blocking the progress just bringing into focus what we have to
sort to out and what happens when it is not done. Also I do not have a workable
solution for building a kernel with the RSB and I would love to have the time to
work on one.

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

Re: [PATCH] part of implimenting a monotonic clock in rtems part of this is not the final patch.

2021-06-15 Thread Christian Mauderer

If you add a new functionallity you _should_ add a test that tests the 
expected behaviour. You just shouldn't replace one but add a new test or 
a new test case to an existing test.


Best regards

Christian

On 14/06/2021 22:18, zack_on_the_speed_chanel wrote:

  also i'll revert the posix test that I changed back to normal because it was 
only for testing.

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐

On Monday, June 14th, 2021 at 8:14 PM, zack_on_the_speed_chanel 
 wrote:


I've made most of the corrections to the code. I fixed up the formatting but I 
still don't know if I have to add anything for the settime and delete_timer(). 
i assume as the monotonic clock only affects the value I think it's all I have 
to do. I also can try to modify a posix test to check my theory.

Thanks

Zack

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐

On Saturday, June 12th, 2021 at 9:31 AM, Christian Mauderer o...@c-mauderer.de 
wrote:


Hello Zack,

I don't really know a lot about the timer toppic. So this is more of a

style and general suggestion review.

On 09/06/2021 20:27, zack wrote:


From: zack zack_on_the_speed_cha...@protonmail.ch

cpukit/include/rtems/posix/timer.h | 6 ++-

cpukit/posix/src/psxtimercreate.c | 5 +-

cpukit/posix/src/timergettime.c | 61 ---

testsuites/psxtests/psxtimer02/psxtimer.c | 26 +++---

4 files changed, 81 insertions(+), 17 deletions(-)

diff --git a/cpukit/include/rtems/posix/timer.h 
b/cpukit/include/rtems/posix/timer.h

index bcbf07a65a..f8cf6115b2 100644

--- a/cpukit/include/rtems/posix/timer.h

+++ b/cpukit/include/rtems/posix/timer.h

@@ -21,7 +21,7 @@

#include 

#include 
-


I think the blank line separated rtems includes from others. So please

don't remove it.


+#include 

#include 

#ifdef __cplusplus

@@ -47,7 +47,9 @@ typedef struct {

struct itimerspec timer_data; /* Timing data of the timer /

uint32_t ticks; / Number of ticks of the initialization /

uint32_t overrun; / Number of expirations of the timer */

-   struct timespec time; /* Time at which the timer was started */

-   struct timespec time; /* Time at which the timer was started */



Not sure what changed in that line. Looks like a whitespace change.

Please avoid these.


-   clockid_t clock_type;


Why a blank line?


} POSIX_Timer_Control;

/**

diff --git a/cpukit/posix/src/psxtimercreate.c 
b/cpukit/posix/src/psxtimercreate.c

index a63cf1d100..e78c359bd5 100644

--- a/cpukit/posix/src/psxtimercreate.c

+++ b/cpukit/posix/src/psxtimercreate.c

@@ -40,7 +40,7 @@ int timer_create(

{

POSIX_Timer_Control *ptimer;

-   if ( clock_id != CLOCK_REALTIME )

-   if ( clock_id != CLOCK_REALTIME || clock_id != CLOCK_MONOTONIC )



Not sure about that one. It's allways a bit difficult whith these

constructions but I think this one is allways true and therefore will

allways return an error.

Let's assume clock_id is CLOCK_MONOTONIC. In that case (clock_id !=

CLOCK_REALTIME) is true which means that the function will return with

an error. The same works for CLOCK_RREALTIME and the second condition.

If you apply De Morgan to the term you see that

(clock_id != CLOCK_REALTIME || clock_id != CLOCK_MONOTONIC)

is the same as

!(clock_id == CLOCK_REALTIME && clock_id == CLOCK_MONOTONIC)

The two inner comparisons are exclusive. So that won't work.

What you most likely want is a

!(clock_id == CLOCK_REALTIME || clock_id == CLOCK_MONOTONIC)

or with De Morgan again:

(clock_id != CLOCK_REALTIME && clock_id != CLOCK_MONOTONIC)


   rtems_set_errno_and_return_minus_one( EINVAL );

 if ( !timerid )


@@ -91,7 +91,8 @@ int timer_create(

ptimer->timer_data.it_value.tv_nsec = 0;

ptimer->timer_data.it_interval.tv_sec = 0;

ptimer->timer_data.it_interval.tv_nsec = 0;
---

-   ptimer->clock_type=clock_id;

-   _Watchdog_Preinitialize( &ptimer->Timer, _Per_CPU_Get_snapshot() );

 _Watchdog_Initialize( &ptimer->Timer, _POSIX_Timer_TSR );

 _Objects_Open_u32(&_POSIX_Timer_Information, &ptimer->Object, 0);

 diff --git a/cpukit/posix/src/timergettime.c 
b/cpukit/posix/src/timergettime.c

 index ee2a566f0e..62011cde58 100644

 --- a/cpukit/posix/src/timergettime.c

 +++ b/cpukit/posix/src/timergettime.c

 @@ -28,6 +28,7 @@

 #include 

 #include 

 #include 

 +#include 

 /*

 -  - When a timer is initialized, the value of the time in



@@ -43,21 +44,67 @@ int timer_gettime(

{

POSIX_Timer_Control *ptimer;

ISR_lock_Context lock_context;

-   uint64_t now;

 uint32_t remaining;

- Per_CPU_Control *cpu;


- struct  timespec * now; // get time now either with


- struct  timespec * expire; // expire


- struct  timespec * result;// get remaining time


 if ( !value )

-   rtems_set_errno_and_return_minus_one( EINVAL );

-   rtems_set_errno_and_return_minus_one( EINVAL );

Re: [PATCH 0/7] AMBA Plug & Play and APBUART improvements

2021-06-15 Thread Sebastian Huber


Hello,

On 10/06/2021 15:23, Sebastian Huber wrote:

Sebastian Huber (7):
   grlib: Customizable allocation in ambapp_scan()
   grlib: Add ambapp_plb()
   bsps/leon3: Auto initialization for printk()
   grlib: Remove NL -> CR in apbuart_outbyte_polled()
   grlib: Add apbuart_outbyte_wait()
   grlib: Fix apbuart_outbyte_polled()
   grlib: Simplify apbuart_inbyte_nonblocking()


if nobody objects, I will commit this on Thursday.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] score: Comment _Thread_queue_Surrender_sticky()

2021-06-15 Thread Sebastian Huber

The change also helps to avoid reports from static analysers since most
callers of _Thread_queue_Make_ready_again() check the unblock status.
---
 cpukit/score/src/threadqenqueue.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/cpukit/score/src/threadqenqueue.c 
b/cpukit/score/src/threadqenqueue.c
index 5e228b7190..d187e32fbc 100644
--- a/cpukit/score/src/threadqenqueue.c
+++ b/cpukit/score/src/threadqenqueue.c
@@ -733,7 +733,13 @@ void _Thread_queue_Surrender_sticky(
 queue_context
   );
   queue->owner = new_owner;
-  _Thread_queue_Make_ready_again( new_owner );
+
+  /*
+   * There is no need to check the unblock status, since in the corresponding
+   * _Thread_queue_Enqueue_sticky() the thread is not blocked by the scheduler.
+   * Instead, the thread busy waits for a change of its thread wait flags.
+   */
+  (void) _Thread_queue_Make_ready_again( new_owner );
 
   cpu_self = _Thread_queue_Dispatch_disable( queue_context );
   _Thread_queue_Queue_release(
-- 
2.26.2

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

Re: [PATCH v4] Update Strong APA Scheduler

2021-06-15 Thread Sebastian Huber


On 11/06/2021 11:47, Richi Dubey wrote:

diff --git a/cpukit/score/src/schedulerstrongapa.c 
b/cpukit/score/src/schedulerstrongapa.c
index dcfb55601a..5aaa8dbd1a 100644
--- a/cpukit/score/src/schedulerstrongapa.c
+++ b/cpukit/score/src/schedulerstrongapa.c
@@ -3,29 +3,35 @@
   *
   * @ingroup RTEMSScoreSchedulerStrongAPA
   *
- * @brief This source file contains the implementation of
- *   _Scheduler_strong_APA_Add_processor(),
- *   _Scheduler_strong_APA_Ask_for_help(), _Scheduler_strong_APA_Block(),
- *   _Scheduler_strong_APA_Initialize(),
- *   _Scheduler_strong_APA_Node_initialize(),
- *   _Scheduler_strong_APA_Reconsider_help_request(),
- *   _Scheduler_strong_APA_Remove_processor(), _Scheduler_strong_APA_Unblock(),
- *   _Scheduler_strong_APA_Update_priority(),
- *   _Scheduler_strong_APA_Withdraw_node(), and _Scheduler_strong_APA_Yield().
+ * @brief Strong APA Scheduler Implementation
   */


Could you please update the Doxygen comment instead of replacing it. At 
least make it a proper sentence.


  
  /*

- * Copyright (c) 2013, 2016 embedded brains GmbH.  All rights reserved.
+ * SPDX-License-Identifier: BSD-2-Clause


The SPDX-License-Identifier have to be in the first line of the file. 
Please mention the license change in the commit messages and update the 
corresponding ticket.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] score: Comment _Thread_queue_Surrender_sticky()

2021-06-15 Thread Gedare Bloom

On Tue, Jun 15, 2021 at 4:30 AM Sebastian Huber
 wrote:
>
> The change also helps to avoid reports from static analysers since most
> callers of _Thread_queue_Make_ready_again() check the unblock status.
> ---
>  cpukit/score/src/threadqenqueue.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/cpukit/score/src/threadqenqueue.c 
> b/cpukit/score/src/threadqenqueue.c
> index 5e228b7190..d187e32fbc 100644
> --- a/cpukit/score/src/threadqenqueue.c
> +++ b/cpukit/score/src/threadqenqueue.c
> @@ -733,7 +733,13 @@ void _Thread_queue_Surrender_sticky(
>  queue_context
>);
>queue->owner = new_owner;
> -  _Thread_queue_Make_ready_again( new_owner );
> +
> +  /*
> +   * There is no need to check the unblock status, since in the corresponding
> +   * _Thread_queue_Enqueue_sticky() the thread is not blocked by the 
> scheduler.
> +   * Instead, the thread busy waits for a change of its thread wait flags.
> +   */
> +  (void) _Thread_queue_Make_ready_again( new_owner );
>
ok

>cpu_self = _Thread_queue_Dispatch_disable( queue_context );
>_Thread_queue_Queue_release(
> --
> 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 0/7] AMBA Plug & Play and APBUART improvements

2021-06-15 Thread Gedare Bloom

I had no complaints but didn't read too closely, all grlib and related
(leon/griscv) bsps.

On Tue, Jun 15, 2021 at 2:27 AM Sebastian Huber
 wrote:
>
> Hello,
>
> On 10/06/2021 15:23, Sebastian Huber wrote:
> > Sebastian Huber (7):
> >grlib: Customizable allocation in ambapp_scan()
> >grlib: Add ambapp_plb()
> >bsps/leon3: Auto initialization for printk()
> >grlib: Remove NL -> CR in apbuart_outbyte_polled()
> >grlib: Add apbuart_outbyte_wait()
> >grlib: Fix apbuart_outbyte_polled()
> >grlib: Simplify apbuart_inbyte_nonblocking()
>
> if nobody objects, I will commit this on Thursday.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> ___
> 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] user: Fixed typo to build hello application

2021-06-15 Thread Gedare Bloom

pushed, thanks.

On Sat, Jun 12, 2021 at 7:28 PM Ida Delphine  wrote:
>
> ---
>  user/start/app.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/user/start/app.rst b/user/start/app.rst
> index 2bb0a9e..19ae3e1 100644
> --- a/user/start/app.rst
> +++ b/user/start/app.rst
> @@ -209,7 +209,7 @@ Run the executable:
>
>  .. code-block:: none
>
> -$HOME/quick-start/rtems/6/bin/rtems-run --rtems-bsps=erc32-sis 
> build/sparc-rtems-erc32/hello.exe
> +$HOME/quick-start/rtems/6/bin/rtems-run --rtems-bsps=erc32-sis 
> build/sparc-rtems6-erc32/hello.exe
>
>  The output will be something close to:
>
> --
> 2.25.1
>
> ___
> 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 rtems-docs 1/1] user/bsps/arm/raspberrypi: Changed the link to the Raspberry Pi Firmware to point to Firmware Version 1.20200601

2021-06-15 Thread Pranav Dangi

I tried debugging by adding printk() statements to the start-up code but
couldn't find anything conclusive. I am stuck there and am still trying to
figure out what broke the BSP after that particular version of the
firmware. If not, I will try to see if using u-boot we can fix this.
Meanwhile, this update to the docs temporarily ensures using of the older
firmware to boot the BSP.

On Mon, 14 Jun 2021, 20:23 Gedare Bloom,  wrote:

> On Mon, Jun 14, 2021 at 3:02 AM pranav  wrote:
> >
> > Updated the link to the Raspberry Pi Firmware in RTEMS 5 docs, since the
> BSP works with an older version of the firmware currently.
> > ---
> >  user/bsps/arm/raspberrypi.rst | 7 ---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/user/bsps/arm/raspberrypi.rst
> b/user/bsps/arm/raspberrypi.rst
> > index c26f4b5..84e45b9 100644
> > --- a/user/bsps/arm/raspberrypi.rst
> > +++ b/user/bsps/arm/raspberrypi.rst
> > @@ -19,9 +19,10 @@ The bootloader looks for a kernel image, by default
> the kernel images must
> >  have a name of the form ``kernel*.img`` but this can be changed by
> adding
> >  `kernel=` to ``config.txt``.
> >
> > -You must provide the required files for the GPU to proceed. These files
> > -can be downloaded from
> > -`the Raspberry Pi Firmware Repository <
> https://github.com/raspberrypi/firmware/tree/master/boot>`_.
> > +You must provide the required files for the GPU to proceed. The BSP
> > +currently boots with an older version of the official Raspberry Pi
> Firmware.
>
> Can you please expand on this sentence to explain why / that newer
> versions don't work?
>
> > +These files can be downloaded from
> > +`the Raspberry Pi Firmware Repository <
> https://github.com/raspberrypi/firmware/tree/1.20200601/boot>`_.
> >  You can remove the ``kernel*.img`` files if you want too, but don't
> touch
> >  the other files.
> >
> > --
> > 2.27.0
> >
> > ___
> > 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] bsps/i386: Update calibration of TSC to be more accurate

2021-06-15 Thread Gedare Bloom

On Fri, Jun 11, 2021 at 1:44 AM Jan Sommer  wrote:
>
> Closes #4455
> ---
>  bsps/i386/pc386/clock/ckinit.c | 72 ++
>  1 file changed, 39 insertions(+), 33 deletions(-)
>
> diff --git a/bsps/i386/pc386/clock/ckinit.c b/bsps/i386/pc386/clock/ckinit.c
> index 09afe73cde..cbd2360fde 100644
> --- a/bsps/i386/pc386/clock/ckinit.c
> +++ b/bsps/i386/pc386/clock/ckinit.c
> @@ -104,48 +104,61 @@ static uint32_t pc386_get_timecount_i8254(struct 
> timecounter *tc)
>
>  /*
>   * Calibrate CPU cycles per tick. Interrupts should be disabled.
> + * Will also set the PIT, so call this before registering the
> + * periodic timer for rtems tick generation
>   */
>  static void calibrate_tsc(void)
>  {
>uint64_t  begin_time;
> -  uint8_t   then_lsb, then_msb, now_lsb, now_msb;
> -  uint32_t  i;
> -
> -  /*
> -   * We just reset the timer, so we know we're at the beginning of a tick.
> -   */
> -
> -  /*
> -   * Count cycles. Watching the timer introduces a several microsecond
> -   * uncertaintity, so let it cook for a while and divide by the number of
> -   * ticks actually executed.
> -   */
> +  uint8_t   lsb, msb;
> +  uint32_t  max_timer_value;
> +  uint32_t  last_tick, cur_tick;
> +  int32_t   diff, remaining;
> +
> +  /* Set the timer to free running mode */
> +  outport_byte(TIMER_MODE, TIMER_SEL0|TIMER_16BIT|TIMER_INTTC);
Please add spaces between the OR'd values |.

> +  outport_byte(TIMER_CNTR0, 0);
> +  outport_byte(TIMER_CNTR0, 0);
I suppose it is needed to write two 0's, but it may be worth a comment why.

> +  /* 16 bit counter */
> +  max_timer_value = 0x;
> +  /* Calibrate for 1s */
> +  remaining = TIMER_TICK;
>
>begin_time = rdtsc();
> -
> -  for (i = rtems_clock_get_ticks_per_second() * pc386_isrs_per_tick;
> -   i != 0; --i ) {
> -/* We know we've just completed a tick when timer goes from low to high 
> */
> -then_lsb = then_msb = 0xff;
> -do {
> -  READ_8254(now_lsb, now_msb);
> -  if ((then_msb < now_msb) ||
> -  ((then_msb == now_msb) && (then_lsb < now_lsb)))
> -break;
> -  then_lsb = now_lsb;
> -  then_msb = now_msb;
> -} while (1);
> +  READ_8254(lsb,msb);
space after comma

> +  last_tick = (msb << 8) | lsb;
> +  while(remaining > 0) {
> +READ_8254(lsb,msb);
> +cur_tick = (msb << 8) | lsb;
> +/* PIT counts down, so subtract cur from last */
> +diff = last_tick - cur_tick;
> +last_tick = cur_tick;
> +if (diff < 0) {
> +diff += max_timer_value;
> +}
> +remaining -= diff;
>}
>
>pc586_tsc_frequency = rdtsc() - begin_time;
>
>  #if 0
> -  printk( "CPU clock at %u MHz\n", (uint32_t)(pc586_tsc_frequency / 
> 100));
> +  printk( "CPU clock at %u Hz\n", (uint32_t)(pc586_tsc_frequency ));
>  #endif
>  }
>
>  static void clockOn(void)
>  {
> +
> +  /*
> +   * First calibrate the TSC. Do this every time we
> +   * turn the clock on in case the CPU clock speed has changed.
> +   */
> +  for (int i = 0; i<5; ++i)
> +  {
> +  if ( x86_has_tsc() )
> +calibrate_tsc();

What's the reason to do this 5 times? I don't see any averaging, so
just the last one is being taken as "correct"

> +  }
> +
>rtems_interrupt_lock_context lock_context;
>pc386_isrs_per_tick= 1;
>pc386_microseconds_per_isr = 
> rtems_configuration_get_microseconds_per_tick();
> @@ -171,13 +184,6 @@ static void clockOn(void)
>rtems_interrupt_lock_release(&rtems_i386_i8254_access_lock, &lock_context);
>
>bsp_interrupt_vector_enable( BSP_PERIODIC_TIMER );
> -
> -  /*
> -   * Now calibrate cycles per tick. Do this every time we
> -   * turn the clock on in case the CPU clock speed has changed.
> -   */
> -  if ( x86_has_tsc() )
> -calibrate_tsc();
>  }
>
>  bool Clock_isr_enabled = false;
> --
> 2.17.1
>
> ___
> 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 rtems-docs 1/1] user/bsps/arm/raspberrypi: Changed the link to the Raspberry Pi Firmware to point to Firmware Version 1.20200601

2021-06-15 Thread Gedare Bloom

Hi Pranav,

On Tue, Jun 15, 2021 at 8:57 AM Pranav Dangi  wrote:
>
> I tried debugging by adding printk() statements to the start-up code but 
> couldn't find anything conclusive. I am stuck there and am still trying to 
> figure out what broke the BSP after that particular version of the firmware. 
> If not, I will try to see if using u-boot we can fix this. Meanwhile, this 
> update to the docs temporarily ensures using of the older firmware to boot 
> the BSP.
>

Thanks for the explanation. I meant can you please expand in the
documentation that newer firmwares are not working.

 Please reformat your commit message
https://devel.rtems.org/wiki/Developer/Git#GitCommits

The first line should be much shorter, about 60 characters long, to
concisely show what changed for email subject lines and in the
git-log.

> On Mon, 14 Jun 2021, 20:23 Gedare Bloom,  wrote:
>>
>> On Mon, Jun 14, 2021 at 3:02 AM pranav  wrote:
>> >
>> > Updated the link to the Raspberry Pi Firmware in RTEMS 5 docs, since the 
>> > BSP works with an older version of the firmware currently.
>> > ---
>> >  user/bsps/arm/raspberrypi.rst | 7 ---
>> >  1 file changed, 4 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/user/bsps/arm/raspberrypi.rst b/user/bsps/arm/raspberrypi.rst
>> > index c26f4b5..84e45b9 100644
>> > --- a/user/bsps/arm/raspberrypi.rst
>> > +++ b/user/bsps/arm/raspberrypi.rst
>> > @@ -19,9 +19,10 @@ The bootloader looks for a kernel image, by default the 
>> > kernel images must
>> >  have a name of the form ``kernel*.img`` but this can be changed by adding
>> >  `kernel=` to ``config.txt``.
>> >
>> > -You must provide the required files for the GPU to proceed. These files
>> > -can be downloaded from
>> > -`the Raspberry Pi Firmware Repository 
>> > `_.
>> > +You must provide the required files for the GPU to proceed. The BSP
>> > +currently boots with an older version of the official Raspberry Pi 
>> > Firmware.
>>
>> Can you please expand on this sentence to explain why / that newer
>> versions don't work?
>>
>> > +These files can be downloaded from
>> > +`the Raspberry Pi Firmware Repository 
>> > `_.
>> >  You can remove the ``kernel*.img`` files if you want too, but don't touch
>> >  the other files.
>> >
>> > --
>> > 2.27.0
>> >
>> > ___
>> > 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: [libbsd] EPOCH(9): Fix epoch call and drain

2021-06-15 Thread Gedare Bloom

Does this add a constraint in libbsd that it only works with SMP for
schedulers that support thread pinning? Is that a problem at all? Last
I checked, not all the SMP schedulers have pinning. Actually, I think
only the EDF SMP scheduler supports pinning.

On Fri, Jun 11, 2021 at 12:46 AM Sebastian Huber
 wrote:
>
> Since the epoch call callbacks may lock/unlock a mutex the callbacks must be
> called from within thread context with thread dispatching enabled.  Use thread
> pinning to ensure that the calling thread stays on the right processor.  Use
> the interrupt server to ensure the thread context for the epoch drain.
> ---
>  rtemsbsd/rtems/rtems-kernel-epoch.c | 39 ++---
>  1 file changed, 35 insertions(+), 4 deletions(-)
>
> diff --git a/rtemsbsd/rtems/rtems-kernel-epoch.c 
> b/rtemsbsd/rtems/rtems-kernel-epoch.c
> index 0c070bd8..642b5854 100644
> --- a/rtemsbsd/rtems/rtems-kernel-epoch.c
> +++ b/rtemsbsd/rtems/rtems-kernel-epoch.c
> @@ -349,15 +349,29 @@ epoch_call(epoch_t epoch, epoch_context_t ctx,
>  void (*callback) (epoch_context_t))
>  {
> Per_CPU_Control *cpu_self;
> -   struct epoch_record *er;
> struct epoch_pcpu *epcpu;
> +   struct epoch_record *er;
> +#ifdef RTEMS_SMP
> +   ISR_Level level;
> +   Thread_Control *executing;
> +
> +   _ISR_Local_disable(level);
> +   cpu_self = _Per_CPU_Get();
> +   executing = _Per_CPU_Get_executing(cpu_self);
> +   _Thread_Pin(executing);
> +   _ISR_Local_enable(level);
> +#endif
>
> -   cpu_self = _Thread_Dispatch_disable();
> epcpu = PER_CPU_DATA_GET(cpu_self, struct epoch_pcpu, epoch);
> epcpu->cb_count += 1;
> er = EPOCH_GET_RECORD(cpu_self, epoch);
> ck_epoch_call(&er->er_record, ctx, callback);
> +
> +#ifdef RTEMS_SMP
> +   cpu_self = _Thread_Dispatch_disable();
> +   _Thread_Unpin(executing, cpu_self);
> _Thread_Dispatch_enable(cpu_self);
> +#endif
>  }
>
>  #ifdef INVARIANTS
> @@ -411,7 +425,7 @@ epoch_call_drain_cb(void *arg)
> struct epoch_record *er;
>
> epoch = arg;
> -   cpu = _Per_CPU_Get();
> +   cpu = _Per_CPU_Get_snapshot();
> er = EPOCH_GET_RECORD(cpu, epoch);
> epoch_call(epoch, &er->er_drain_ctx, epoch_drain_cb);
>  }
> @@ -425,6 +439,7 @@ epoch_drain_callbacks(epoch_t epoch)
> uint32_t cpu_max;
> rtems_id id;
> rtems_status_code sc;
> +   rtems_interrupt_server_request req[CPU_MAXIMUM_PROCESSORS];
>  #else
> struct epoch_record *er;
>  #endif
> @@ -433,6 +448,7 @@ epoch_drain_callbacks(epoch_t epoch)
> mtx_lock(&epoch->e_drain_mtx);
>
>  #ifdef RTEMS_SMP
> +   memset(&req, 0, sizeof(req));
> cpu_max = rtems_scheduler_get_processor_maximum();
>
> for (cpu_index = 0; cpu_index <= cpu_max; ++cpu_index) {
> @@ -445,8 +461,15 @@ epoch_drain_callbacks(epoch_t epoch)
> for (cpu_index = 0; cpu_index <= cpu_max; ++cpu_index) {
> sc = rtems_scheduler_ident_by_processor(cpu_index, &id);
> if (sc == RTEMS_SUCCESSFUL) {
> -   _SMP_Unicast_action(cpu_index, epoch_call_drain_cb,
> +   sc = rtems_interrupt_server_request_initialize(
> +   cpu_index, &req[cpu_index], epoch_call_drain_cb,
> epoch);
> +   if (sc == RTEMS_SUCCESSFUL) {
> +   rtems_interrupt_server_request_submit(
> +   &req[cpu_index]);
> +   } else {
> +   panic("no interrupt server for epoch drain");
> +   }
> }
> }
>  #else
> @@ -461,4 +484,12 @@ epoch_drain_callbacks(epoch_t epoch)
>
> mtx_unlock(&epoch->e_drain_mtx);
> sx_xunlock(&epoch->e_drain_sx);
> +
> +#ifdef RTEMS_SMP
> +   for (cpu_index = 0; cpu_index <= cpu_max; ++cpu_index) {
> +   if (req[cpu_index].action.handler != NULL) {
> +   
> rtems_interrupt_server_request_destroy(&req[cpu_index]);
> +   }
> +   }
> +#endif
>  }
> --
> 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 rtems-libbsd 2/2] builder.py: Only disable tests if they are there

2021-06-15 Thread Gedare Bloom

ok

On Fri, Jun 11, 2021 at 6:20 AM Christian Mauderer  wrote:
>
> For checking the dependencies, the tests are removed. But if the tests
> are not enabled at all, that triggers a python exception.
> ---
>  builder.py | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/builder.py b/builder.py
> index cbe5dc59..a34a1518 100755
> --- a/builder.py
> +++ b/builder.py
> @@ -1062,7 +1062,8 @@ class ModuleManager(object):
>
>  def _checkDependencies(self):
>  enabled_modules = self.getEnabledModules()
> -enabled_modules.remove('tests')
> +if 'tests' in enabled_modules:
> +enabled_modules.remove('tests')
>  for mod in enabled_modules:
>  if mod not in self.modules:
>  raise KeyError('enabled module not found: %s' % (mod))
> --
> 2.32.0
>
> ___
> 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: [libbsd] EPOCH(9): Fix epoch call and drain

2021-06-15 Thread Sebastian Huber


On 15/06/2021 17:10, Gedare Bloom wrote:

Does this add a constraint in libbsd that it only works with SMP for
schedulers that support thread pinning? Is that a problem at all? Last
I checked, not all the SMP schedulers have pinning. Actually, I think
only the EDF SMP scheduler supports pinning.


In SMP configurations, a scheduler with thread pinning support is 
required by libbsd. This is not a new constraint. The thread pinning 
support was specifically implemented to support EPOCH(9).


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-libbsd v2 3/4] rtemsbsd: Made TTCP command build for RTEMS

2021-06-15 Thread Gedare Bloom

On Fri, Jun 11, 2021 at 11:19 AM Stephen Clark
 wrote:
>
> Updated ttcp.c to build for RTEMS 6, in addition to the machines
> it originally built for. Also fixed ttcp.c to close network sockets
> after completion. Defined a shell command for TTCP in
> rtems-bsd-shell-ttcp.c. Added TTCP to the list of RTEMS network
> commands in netcmds-config.h. Added declaration of the TTCP shell
> command to rtems-bsd-commands.h. Modified libbsd.py to make waf
> build TTCP and its shell command.
> ---
>  libbsd.py |   2 +
>  rtemsbsd/include/machine/rtems-bsd-commands.h |   2 +
>  rtemsbsd/include/rtems/netcmds-config.h   |   2 +
>  rtemsbsd/rtems/rtems-bsd-shell-ttcp.c |  39 +++
>  rtemsbsd/ttcp/README  |  11 +-
>  rtemsbsd/ttcp/ttcp.c  | 266 ++
>  6 files changed, 262 insertions(+), 60 deletions(-)
>  create mode 100644 rtemsbsd/rtems/rtems-bsd-shell-ttcp.c
>
> diff --git a/libbsd.py b/libbsd.py
> index b367d94e..2badfdee 100644
> --- a/libbsd.py
> +++ b/libbsd.py
> @@ -269,6 +269,7 @@ class rtems(builder.Module):
>  'rtems/rtems-bsd-shell-tcpdump.c',
>  'rtems/rtems-bsd-shell-vmstat.c',
>  'rtems/rtems-bsd-shell-wlanstats.c',
> +'rtems/rtems-bsd-shell-ttcp.c',
>  'rtems/rtems-kvm.c',
>  'rtems/rtems-program.c',
>  'rtems/rtems-program-socket.c',
> @@ -292,6 +293,7 @@ class rtems(builder.Module):
>  'pppd/upap.c',
>  'pppd/utils.c',
>  'telnetd/telnetd-service.c',
> +'ttcp/ttcp.c',
>  ],
>  mm.generator['source']()
>  )
> diff --git a/rtemsbsd/include/machine/rtems-bsd-commands.h 
> b/rtemsbsd/include/machine/rtems-bsd-commands.h
> index d314471f..d82c274c 100644
> --- a/rtemsbsd/include/machine/rtems-bsd-commands.h
> +++ b/rtemsbsd/include/machine/rtems-bsd-commands.h
> @@ -84,6 +84,8 @@ int rtems_bsd_command_setkey(int argc, char **argv);
>
>  int rtems_bsd_command_openssl(int argc, char **argv);
>
> +int rtems_shell_main_ttcp(int argc, char **argv);
> +
>  __END_DECLS
>
>  #endif /* _RTEMS_BSD_MACHINE_RTEMS_BSD_COMMANDS_H_ */
> diff --git a/rtemsbsd/include/rtems/netcmds-config.h 
> b/rtemsbsd/include/rtems/netcmds-config.h
> index bc493af4..c1d56eb3 100644
> --- a/rtemsbsd/include/rtems/netcmds-config.h
> +++ b/rtemsbsd/include/rtems/netcmds-config.h
> @@ -29,6 +29,8 @@ extern rtems_shell_cmd_t rtems_shell_PFCTL_Command;
>  extern rtems_shell_cmd_t rtems_shell_PING_Command;
>  extern rtems_shell_cmd_t rtems_shell_PING6_Command;
>
> +extern rtems_shell_cmd_t rtems_shell_TTCP_Command;
> +
>  extern rtems_shell_cmd_t rtems_shell_IFCONFIG_Command;
>
>  extern rtems_shell_cmd_t rtems_shell_IFMCSTAT_Command;
> diff --git a/rtemsbsd/rtems/rtems-bsd-shell-ttcp.c 
> b/rtemsbsd/rtems/rtems-bsd-shell-ttcp.c
> new file mode 100644
> index ..babaa011
> --- /dev/null
> +++ b/rtemsbsd/rtems/rtems-bsd-shell-ttcp.c
> @@ -0,0 +1,39 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/*
> + * COPYRIGHT (c) 2021. On-Line Applications Research Corporation (OAR).
> + * 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.
> + */
> +
> +#include 
> +#include 
> +
> +rtems_shell_cmd_t rtems_shell_TTCP_Command = {
> +  "ttcp",   /* name */
> +  "ttcp -h # to get help",  /* usage */
> +  "net",/* topic */
> +  rtems_shell_main_ttcp,/* command */
> +  NULL,

Re: [libbsd] EPOCH(9): Fix epoch call and drain

2021-06-15 Thread Gedare Bloom

On Tue, Jun 15, 2021 at 9:12 AM Sebastian Huber
 wrote:
>
> On 15/06/2021 17:10, Gedare Bloom wrote:
> > Does this add a constraint in libbsd that it only works with SMP for
> > schedulers that support thread pinning? Is that a problem at all? Last
> > I checked, not all the SMP schedulers have pinning. Actually, I think
> > only the EDF SMP scheduler supports pinning.
>
> In SMP configurations, a scheduler with thread pinning support is
> required by libbsd. This is not a new constraint. The thread pinning
> support was specifically implemented to support EPOCH(9).
>
Is this documented for users to understand they need to use EDF SMP
(or add thread pinning support) to use libbsd with SMP?

> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GSOC POSIX Compliance: Stuck trying to build Newlib

2021-06-15 Thread Matthew Joyce

Hello Dr. Joel and Eshan,

I have a patch ready to send to Newlib for the sig function prototypes
and STR2SIG_MAX.

But to do that, I think I need to have Newlib built, which I must
still be doing wrong. The error that I am getting is attached below.

I’ve been trying to follow the steps here:
https://medium.com/my-gsoc-2019-journey/apply-newlib-patch-to-rtems-source-builder-6873b0fb31b8
and 
https://medium.com/my-gsoc-2019-journey/build-newlib-for-sparc-and-arm-architecture-6b3287d4c6f2

I even had rebuilt everything from scratch to see if that would help,
but I still get the same error. Maybe I cloned the newlib source into
the wrong directory?

I was hoping to get the patch off to Newlib for review as a first step
while I work on writing the actual methods. When you get a moment,
could you please advise? Thank you very much!

Sincerely,

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

[libbsd] README: Mention SMP requirements

2021-06-15 Thread Sebastian Huber

---
 README.md | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/README.md b/README.md
index 19c9023e..0438653d 100644
--- a/README.md
+++ b/README.md
@@ -293,3 +293,10 @@ Escape character is '^]'.
 RTEMS Shell on /dev/pty4. Use 'help' to list commands.
 TLNT [/] #
 ```
+
+SMP Requirements
+
+
+In order to support EPOCH(9) a scheduler with thread pinning support is
+required.  This is the case if you use the default scheduler configuration.
+EPOCH(9) is a central synchronization mechanism of the network stack.
-- 
2.26.2

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

Re: GSOC POSIX Compliance: Stuck trying to build Newlib

2021-06-15 Thread Joel Sherrill

On Tue, Jun 15, 2021 at 10:42 AM Matthew Joyce 
wrote:

> Hello Dr. Joel and Eshan,
>
> I have a patch ready to send to Newlib for the sig function prototypes
> and STR2SIG_MAX.
>
> But to do that, I think I need to have Newlib built, which I must
> still be doing wrong. The error that I am getting is attached below.
>
> I’ve been trying to follow the steps here:
>
> https://medium.com/my-gsoc-2019-journey/apply-newlib-patch-to-rtems-source-builder-6873b0fb31b8
> and
> https://medium.com/my-gsoc-2019-journey/build-newlib-for-sparc-and-arm-architecture-6b3287d4c6f2
>
> I even had rebuilt everything from scratch to see if that would help,
> but I still get the same error. Maybe I cloned the newlib source into
> the wrong directory?
>

No. I suspect your PATH should have the autoconf version you want to
use at the head of your PATH. I tried this with the RTEMS autoconf at
the front of my PATH and it worked.

export PATH=@RTEMS_TOOLS_BIN@:${PATH}

It was changing way too many files. I would toss any changes that are
outside the directory you are working on.

If you are not adding or deleting a file, you don't have to do this. This
is only needed when the set of files and/or directories changes.

>
> I was hoping to get the patch off to Newlib for review as a first step
> while I work on writing the actual methods. When you get a moment,
> could you please advise? Thank you very much!
>
> Sincerely,
>
> Matt
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSOC POSIX Compliance: Stuck trying to build Newlib

2021-06-15 Thread Eshan Dhawan

Hi Matt,
Try running the command with autoconf version 2.69 that's shipped with
RTEMS in the rtems bin
That works as well.

Also From a quick google search this is what I found :
https://superuser.com/questions/617872/cant-locate-autom4te-channeldefs-pm-in-inc-when-it-definitely-is-there

On Tue, Jun 15, 2021 at 9:12 PM Matthew Joyce  wrote:

> Hello Dr. Joel and Eshan,
>
> I have a patch ready to send to Newlib for the sig function prototypes
> and STR2SIG_MAX.
>
> But to do that, I think I need to have Newlib built, which I must
> still be doing wrong. The error that I am getting is attached below.
>
> I’ve been trying to follow the steps here:
>
> https://medium.com/my-gsoc-2019-journey/apply-newlib-patch-to-rtems-source-builder-6873b0fb31b8
> and
> https://medium.com/my-gsoc-2019-journey/build-newlib-for-sparc-and-arm-architecture-6b3287d4c6f2
>
> I even had rebuilt everything from scratch to see if that would help,
> but I still get the same error. Maybe I cloned the newlib source into
> the wrong directory?
>
> I was hoping to get the patch off to Newlib for review as a first step
> while I work on writing the actual methods. When you get a moment,
> could you please advise? Thank you very much!
>
> Sincerely,
>
> Matt
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSOC POSIX Compliance: Stuck trying to build Newlib

2021-06-15 Thread Matthew Joyce

Hi Gentlemen,

Thanks very much for your quick replies!

I just tried both, but perhaps I'm misinterpreting your suggestions.
(Could you please see the attached commands / errors!)

Eshan,

I did see that link, but it wasn't clear to me what the solution was...Sorry!

Sincerely,

Matt

On Tue, Jun 15, 2021 at 6:52 PM Eshan Dhawan  wrote:
>
> Hi Matt,
> Try running the command with autoconf version 2.69 that's shipped with RTEMS 
> in the rtems bin
> That works as well.
>
> Also From a quick google search this is what I found : 
> https://superuser.com/questions/617872/cant-locate-autom4te-channeldefs-pm-in-inc-when-it-definitely-is-there
>
> On Tue, Jun 15, 2021 at 9:12 PM Matthew Joyce  wrote:
>>
>> Hello Dr. Joel and Eshan,
>>
>> I have a patch ready to send to Newlib for the sig function prototypes
>> and STR2SIG_MAX.
>>
>> But to do that, I think I need to have Newlib built, which I must
>> still be doing wrong. The error that I am getting is attached below.
>>
>> I’ve been trying to follow the steps here:
>> https://medium.com/my-gsoc-2019-journey/apply-newlib-patch-to-rtems-source-builder-6873b0fb31b8
>> and 
>> https://medium.com/my-gsoc-2019-journey/build-newlib-for-sparc-and-arm-architecture-6b3287d4c6f2
>>
>> I even had rebuilt everything from scratch to see if that would help,
>> but I still get the same error. Maybe I cloned the newlib source into
>> the wrong directory?
>>
>> I was hoping to get the patch off to Newlib for review as a first step
>> while I work on writing the actual methods. When you get a moment,
>> could you please advise? Thank you very much!
>>
>> Sincerely,
>>
>> Matt
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [libbsd] README: Mention SMP requirements

2021-06-15 Thread Gedare Bloom

Thanks.

On Tue, Jun 15, 2021 at 10:45 AM Sebastian Huber
 wrote:
>
> ---
>  README.md | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/README.md b/README.md
> index 19c9023e..0438653d 100644
> --- a/README.md
> +++ b/README.md
> @@ -293,3 +293,10 @@ Escape character is '^]'.
>  RTEMS Shell on /dev/pty4. Use 'help' to list commands.
>  TLNT [/] #
>  ```
> +
> +SMP Requirements
> +
> +
> +In order to support EPOCH(9) a scheduler with thread pinning support is
> +required.  This is the case if you use the default scheduler configuration.
> +EPOCH(9) is a central synchronization mechanism of the network stack.
> --
> 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: GSOC POSIX Compliance: Stuck trying to build Newlib

2021-06-15 Thread Gedare Bloom

Just a note, it's more efficient to capture your terminal dump into a
text file and attach that, rather than put a screenshot up.

On Tue, Jun 15, 2021 at 11:14 AM Matthew Joyce  wrote:
>
> Hi Gentlemen,
>
> Thanks very much for your quick replies!
>
> I just tried both, but perhaps I'm misinterpreting your suggestions.
> (Could you please see the attached commands / errors!)
>
> Eshan,
>
> I did see that link, but it wasn't clear to me what the solution was...Sorry!
>
> Sincerely,
>
> Matt
>
> On Tue, Jun 15, 2021 at 6:52 PM Eshan Dhawan  wrote:
> >
> > Hi Matt,
> > Try running the command with autoconf version 2.69 that's shipped with 
> > RTEMS in the rtems bin
> > That works as well.
> >
> > Also From a quick google search this is what I found : 
> > https://superuser.com/questions/617872/cant-locate-autom4te-channeldefs-pm-in-inc-when-it-definitely-is-there
> >
> > On Tue, Jun 15, 2021 at 9:12 PM Matthew Joyce  wrote:
> >>
> >> Hello Dr. Joel and Eshan,
> >>
> >> I have a patch ready to send to Newlib for the sig function prototypes
> >> and STR2SIG_MAX.
> >>
> >> But to do that, I think I need to have Newlib built, which I must
> >> still be doing wrong. The error that I am getting is attached below.
> >>
> >> I’ve been trying to follow the steps here:
> >> https://medium.com/my-gsoc-2019-journey/apply-newlib-patch-to-rtems-source-builder-6873b0fb31b8
> >> and 
> >> https://medium.com/my-gsoc-2019-journey/build-newlib-for-sparc-and-arm-architecture-6b3287d4c6f2
> >>
> >> I even had rebuilt everything from scratch to see if that would help,
> >> but I still get the same error. Maybe I cloned the newlib source into
> >> the wrong directory?
> >>
> >> I was hoping to get the patch off to Newlib for review as a first step
> >> while I work on writing the actual methods. When you get a moment,
> >> could you please advise? Thank you very much!
> >>
> >> Sincerely,
> >>
> >> Matt
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSOC POSIX Compliance: Stuck trying to build Newlib

2021-06-15 Thread Matthew Joyce

Ah, ok will do! Thank you for the tip.

On Tue, Jun 15, 2021 at 7:17 PM Gedare Bloom  wrote:
>
> Just a note, it's more efficient to capture your terminal dump into a
> text file and attach that, rather than put a screenshot up.
>
> On Tue, Jun 15, 2021 at 11:14 AM Matthew Joyce  wrote:
> >
> > Hi Gentlemen,
> >
> > Thanks very much for your quick replies!
> >
> > I just tried both, but perhaps I'm misinterpreting your suggestions.
> > (Could you please see the attached commands / errors!)
> >
> > Eshan,
> >
> > I did see that link, but it wasn't clear to me what the solution 
> > was...Sorry!
> >
> > Sincerely,
> >
> > Matt
> >
> > On Tue, Jun 15, 2021 at 6:52 PM Eshan Dhawan  
> > wrote:
> > >
> > > Hi Matt,
> > > Try running the command with autoconf version 2.69 that's shipped with 
> > > RTEMS in the rtems bin
> > > That works as well.
> > >
> > > Also From a quick google search this is what I found : 
> > > https://superuser.com/questions/617872/cant-locate-autom4te-channeldefs-pm-in-inc-when-it-definitely-is-there
> > >
> > > On Tue, Jun 15, 2021 at 9:12 PM Matthew Joyce  
> > > wrote:
> > >>
> > >> Hello Dr. Joel and Eshan,
> > >>
> > >> I have a patch ready to send to Newlib for the sig function prototypes
> > >> and STR2SIG_MAX.
> > >>
> > >> But to do that, I think I need to have Newlib built, which I must
> > >> still be doing wrong. The error that I am getting is attached below.
> > >>
> > >> I’ve been trying to follow the steps here:
> > >> https://medium.com/my-gsoc-2019-journey/apply-newlib-patch-to-rtems-source-builder-6873b0fb31b8
> > >> and 
> > >> https://medium.com/my-gsoc-2019-journey/build-newlib-for-sparc-and-arm-architecture-6b3287d4c6f2
> > >>
> > >> I even had rebuilt everything from scratch to see if that would help,
> > >> but I still get the same error. Maybe I cloned the newlib source into
> > >> the wrong directory?
> > >>
> > >> I was hoping to get the patch off to Newlib for review as a first step
> > >> while I work on writing the actual methods. When you get a moment,
> > >> could you please advise? Thank you very much!
> > >>
> > >> Sincerely,
> > >>
> > >> Matt
> > ___
> > 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 rtems-libbsd v2 3/4] rtemsbsd: Made TTCP command build for RTEMS

2021-06-15 Thread Joel Sherrill

On Tue, Jun 15, 2021 at 10:25 AM Gedare Bloom  wrote:

> On Fri, Jun 11, 2021 at 11:19 AM Stephen Clark
>  wrote:
> >
> > Updated ttcp.c to build for RTEMS 6, in addition to the machines
> > it originally built for. Also fixed ttcp.c to close network sockets
> > after completion. Defined a shell command for TTCP in
> > rtems-bsd-shell-ttcp.c. Added TTCP to the list of RTEMS network
> > commands in netcmds-config.h. Added declaration of the TTCP shell
> > command to rtems-bsd-commands.h. Modified libbsd.py to make waf
> > build TTCP and its shell command.
> > ---
> >  libbsd.py |   2 +
> >  rtemsbsd/include/machine/rtems-bsd-commands.h |   2 +
> >  rtemsbsd/include/rtems/netcmds-config.h   |   2 +
> >  rtemsbsd/rtems/rtems-bsd-shell-ttcp.c |  39 +++
> >  rtemsbsd/ttcp/README  |  11 +-
> >  rtemsbsd/ttcp/ttcp.c  | 266 ++
> >  6 files changed, 262 insertions(+), 60 deletions(-)
> >  create mode 100644 rtemsbsd/rtems/rtems-bsd-shell-ttcp.c
> >
> > diff --git a/libbsd.py b/libbsd.py
> > index b367d94e..2badfdee 100644
> > --- a/libbsd.py
> > +++ b/libbsd.py
> > @@ -269,6 +269,7 @@ class rtems(builder.Module):
> >  'rtems/rtems-bsd-shell-tcpdump.c',
> >  'rtems/rtems-bsd-shell-vmstat.c',
> >  'rtems/rtems-bsd-shell-wlanstats.c',
> > +'rtems/rtems-bsd-shell-ttcp.c',
> >  'rtems/rtems-kvm.c',
> >  'rtems/rtems-program.c',
> >  'rtems/rtems-program-socket.c',
> > @@ -292,6 +293,7 @@ class rtems(builder.Module):
> >  'pppd/upap.c',
> >  'pppd/utils.c',
> >  'telnetd/telnetd-service.c',
> > +'ttcp/ttcp.c',
> >  ],
> >  mm.generator['source']()
> >  )
> > diff --git a/rtemsbsd/include/machine/rtems-bsd-commands.h
> b/rtemsbsd/include/machine/rtems-bsd-commands.h
> > index d314471f..d82c274c 100644
> > --- a/rtemsbsd/include/machine/rtems-bsd-commands.h
> > +++ b/rtemsbsd/include/machine/rtems-bsd-commands.h
> > @@ -84,6 +84,8 @@ int rtems_bsd_command_setkey(int argc, char **argv);
> >
> >  int rtems_bsd_command_openssl(int argc, char **argv);
> >
> > +int rtems_shell_main_ttcp(int argc, char **argv);
> > +
> >  __END_DECLS
> >
> >  #endif /* _RTEMS_BSD_MACHINE_RTEMS_BSD_COMMANDS_H_ */
> > diff --git a/rtemsbsd/include/rtems/netcmds-config.h
> b/rtemsbsd/include/rtems/netcmds-config.h
> > index bc493af4..c1d56eb3 100644
> > --- a/rtemsbsd/include/rtems/netcmds-config.h
> > +++ b/rtemsbsd/include/rtems/netcmds-config.h
> > @@ -29,6 +29,8 @@ extern rtems_shell_cmd_t rtems_shell_PFCTL_Command;
> >  extern rtems_shell_cmd_t rtems_shell_PING_Command;
> >  extern rtems_shell_cmd_t rtems_shell_PING6_Command;
> >
> > +extern rtems_shell_cmd_t rtems_shell_TTCP_Command;
> > +
> >  extern rtems_shell_cmd_t rtems_shell_IFCONFIG_Command;
> >
> >  extern rtems_shell_cmd_t rtems_shell_IFMCSTAT_Command;
> > diff --git a/rtemsbsd/rtems/rtems-bsd-shell-ttcp.c
> b/rtemsbsd/rtems/rtems-bsd-shell-ttcp.c
> > new file mode 100644
> > index ..babaa011
> > --- /dev/null
> > +++ b/rtemsbsd/rtems/rtems-bsd-shell-ttcp.c
> > @@ -0,0 +1,39 @@
> > +/* SPDX-License-Identifier: BSD-2-Clause */
> > +
> > +/*
> > + * COPYRIGHT (c) 2021. On-Line Applications Research Corporation (OAR).
> > + * 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.
> > + */
> > +
> > +#include 
> > +#include 
> > +
> > +rtems_shell_cmd_t rtems_shell_TTCP_Command = {
> > +  "ttcp",

Re: GSOC POSIX Compliance: Stuck trying to build Newlib

2021-06-15 Thread Eshan Dhawan

Hi matt
It would work if run inside newlib instead of newlib-cygwin
run command inside of ../newlib-cygwin/newlib
instead of ../newlib-cygwin


On Tue, Jun 15, 2021 at 10:59 PM Matthew Joyce 
wrote:

> Ah, ok will do! Thank you for the tip.
>
> On Tue, Jun 15, 2021 at 7:17 PM Gedare Bloom  wrote:
> >
> > Just a note, it's more efficient to capture your terminal dump into a
> > text file and attach that, rather than put a screenshot up.
> >
> > On Tue, Jun 15, 2021 at 11:14 AM Matthew Joyce 
> wrote:
> > >
> > > Hi Gentlemen,
> > >
> > > Thanks very much for your quick replies!
> > >
> > > I just tried both, but perhaps I'm misinterpreting your suggestions.
> > > (Could you please see the attached commands / errors!)
> > >
> > > Eshan,
> > >
> > > I did see that link, but it wasn't clear to me what the solution
> was...Sorry!
> > >
> > > Sincerely,
> > >
> > > Matt
> > >
> > > On Tue, Jun 15, 2021 at 6:52 PM Eshan Dhawan 
> wrote:
> > > >
> > > > Hi Matt,
> > > > Try running the command with autoconf version 2.69 that's shipped
> with RTEMS in the rtems bin
> > > > That works as well.
> > > >
> > > > Also From a quick google search this is what I found :
> https://superuser.com/questions/617872/cant-locate-autom4te-channeldefs-pm-in-inc-when-it-definitely-is-there
> > > >
> > > > On Tue, Jun 15, 2021 at 9:12 PM Matthew Joyce 
> wrote:
> > > >>
> > > >> Hello Dr. Joel and Eshan,
> > > >>
> > > >> I have a patch ready to send to Newlib for the sig function
> prototypes
> > > >> and STR2SIG_MAX.
> > > >>
> > > >> But to do that, I think I need to have Newlib built, which I must
> > > >> still be doing wrong. The error that I am getting is attached below.
> > > >>
> > > >> I’ve been trying to follow the steps here:
> > > >>
> https://medium.com/my-gsoc-2019-journey/apply-newlib-patch-to-rtems-source-builder-6873b0fb31b8
> > > >> and
> https://medium.com/my-gsoc-2019-journey/build-newlib-for-sparc-and-arm-architecture-6b3287d4c6f2
> > > >>
> > > >> I even had rebuilt everything from scratch to see if that would
> help,
> > > >> but I still get the same error. Maybe I cloned the newlib source
> into
> > > >> the wrong directory?
> > > >>
> > > >> I was hoping to get the patch off to Newlib for review as a first
> step
> > > >> while I work on writing the actual methods. When you get a moment,
> > > >> could you please advise? Thank you very much!
> > > >>
> > > >> Sincerely,
> > > >>
> > > >> Matt
> > > ___
> > > devel mailing list
> > > devel@rtems.org
> > > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSOC POSIX Compliance: Stuck trying to build Newlib

2021-06-15 Thread Joel Sherrill

@RTEMS_TOOLS_BIN@ should have been replaced with the real directory where
your RTEMS tools are located. Something like this:

$ export PATH=${HOME}/rtems-work/tools/6/bin:$PATH

And to check you have the PATH right, do something like this:

$ type sparc-rtems6-gcc
sparc-rtems6-gcc is /home/joel/rtems-work/tools/6/bin/sparc-rtems6-gcc

On Tue, Jun 15, 2021 at 1:23 PM Eshan Dhawan 
wrote:

> Hi matt
> It would work if run inside newlib instead of newlib-cygwin
> run command inside of ../newlib-cygwin/newlib
> instead of ../newlib-cygwin
>
>
> On Tue, Jun 15, 2021 at 10:59 PM Matthew Joyce 
> wrote:
>
>> Ah, ok will do! Thank you for the tip.
>>
>> On Tue, Jun 15, 2021 at 7:17 PM Gedare Bloom  wrote:
>> >
>> > Just a note, it's more efficient to capture your terminal dump into a
>> > text file and attach that, rather than put a screenshot up.
>> >
>> > On Tue, Jun 15, 2021 at 11:14 AM Matthew Joyce 
>> wrote:
>> > >
>> > > Hi Gentlemen,
>> > >
>> > > Thanks very much for your quick replies!
>> > >
>> > > I just tried both, but perhaps I'm misinterpreting your suggestions.
>> > > (Could you please see the attached commands / errors!)
>> > >
>> > > Eshan,
>> > >
>> > > I did see that link, but it wasn't clear to me what the solution
>> was...Sorry!
>> > >
>> > > Sincerely,
>> > >
>> > > Matt
>> > >
>> > > On Tue, Jun 15, 2021 at 6:52 PM Eshan Dhawan 
>> wrote:
>> > > >
>> > > > Hi Matt,
>> > > > Try running the command with autoconf version 2.69 that's shipped
>> with RTEMS in the rtems bin
>> > > > That works as well.
>> > > >
>> > > > Also From a quick google search this is what I found :
>> https://superuser.com/questions/617872/cant-locate-autom4te-channeldefs-pm-in-inc-when-it-definitely-is-there
>> > > >
>> > > > On Tue, Jun 15, 2021 at 9:12 PM Matthew Joyce <
>> mfjoyce2...@gmail.com> wrote:
>> > > >>
>> > > >> Hello Dr. Joel and Eshan,
>> > > >>
>> > > >> I have a patch ready to send to Newlib for the sig function
>> prototypes
>> > > >> and STR2SIG_MAX.
>> > > >>
>> > > >> But to do that, I think I need to have Newlib built, which I must
>> > > >> still be doing wrong. The error that I am getting is attached
>> below.
>> > > >>
>> > > >> I’ve been trying to follow the steps here:
>> > > >>
>> https://medium.com/my-gsoc-2019-journey/apply-newlib-patch-to-rtems-source-builder-6873b0fb31b8
>> > > >> and
>> https://medium.com/my-gsoc-2019-journey/build-newlib-for-sparc-and-arm-architecture-6b3287d4c6f2
>> > > >>
>> > > >> I even had rebuilt everything from scratch to see if that would
>> help,
>> > > >> but I still get the same error. Maybe I cloned the newlib source
>> into
>> > > >> the wrong directory?
>> > > >>
>> > > >> I was hoping to get the patch off to Newlib for review as a first
>> step
>> > > >> while I work on writing the actual methods. When you get a moment,
>> > > >> could you please advise? Thank you very much!
>> > > >>
>> > > >> Sincerely,
>> > > >>
>> > > >> Matt
>> > > ___
>> > > devel mailing list
>> > > devel@rtems.org
>> > > http://lists.rtems.org/mailman/listinfo/devel
>>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-libbsd v2 3/4] rtemsbsd: Made TTCP command build for RTEMS

2021-06-15 Thread Christian Mauderer

On 15/06/2021 20:03, Joel Sherrill wrote:

On Tue, Jun 15, 2021 at 10:25 AM Gedare Bloom > wrote:

On Fri, Jun 11, 2021 at 11:19 AM Stephen Clark
mailto:stephen.cl...@oarcorp.com>> wrote:
 >
 > Updated ttcp.c to build for RTEMS 6, in addition to the machines
 > it originally built for. Also fixed ttcp.c to close network sockets
 > after completion. Defined a shell command for TTCP in
 > rtems-bsd-shell-ttcp.c. Added TTCP to the list of RTEMS network
 > commands in netcmds-config.h. Added declaration of the TTCP shell
 > command to rtems-bsd-commands.h. Modified libbsd.py to make waf
 > build TTCP and its shell command.
 > ---

[...]

 >
 >  char Usage[] = "\
 >  Usage: ttcp -t [-options] host [ < in ]\n\
 > @@ -173,16 +220,34 @@ void millisleep(long msec)
 >    nanosleep( &req, NULL );
 >  #endif
 >  }
 > +
Avoid making own changes outside of the __rtems__ guards if you're
trying to preserve compatibility with the upstream. Please read
contributing.md.

This one is a weird case. To run the ttcp benchmark, you must have two
systems running it. One is the Tx and the other is the Rx. This usually
means you are running TTCP on your RTEMS target and on your development
system. Some of these are needed to be clean on the native build. Other
parts are specific to RTEMS.

As you can tell from the date on the code it is quite old and it is 
questionable
if there is a maintained upstream.for this implementation. In answering 
this,
I found https://en.wikipedia.org/wiki/Ttcp 
 which points to nuttcp.net 
 and that
appears to be maintained since there was a release last year. But that's 
GPLv2

so we won't be using that.

Benchmarking is a quite specific use case and normally only added during 
testing and not in a final application. I think if nuttcp is an 
interesting tool, GPLv2 shouldn't be a big problem in this case. The 
only problem: It would have to be in a separate repository and not in 
libbsd. Alternatively the maintainers might accept patches that allow 
using nuttcp as a library so that we don't have to add a clone of the 
sources in RTEMS at all.

We need some changes to make it clean natively and some to make it work
on RTEMS. And I don't think there is really an active upstream for this. 
This

was a new port based on newer ways of doing things in RTEMS. What
do you think is best?

Normally I would start with the version that is provided by the FreeBSD 
ports collection (which would be from 06.04.2021 at 
https://www.freshports.org/benchmarks/ttcp/), apply the FreeBSD patches 
to it and then use the normal __rtems__ markers. With that we can use 
the FreeBSD patches for that if there are updates necessary.

Like I said: That would be my method. Don't feel forced to use that.

It occurred to me as I typed this that perhaps the native version should
be built as part of rtems-tools instead of assuming the end user would
compile this source by hand from libbsd. But then we would be duplicating
the file.

We now have two network stak repos and maybe someone adds lwip to a 
separate repository somewhen. Wouldn't it be better in that case to have 
a fork of ttcp in a separate repository anyway so that it can be used 
with all stacks and (maybe) also build as a host tool with rtems-tools?

I didn't have a look at ttcp (or nuttcp) and I'm not sure whether it 
depends heavily on the host operating system or not. If it is heavily 
adapted to the FreeBSD stack, compiling it as a stack-independent 
library won't work. Please just say so if that is the case.

Please note that I don't want to insist on that (or any of the other 
points above). It just might would be a possibility to avoid duplicating 
code to every network stack repo and the host.

Best regards

Christian

Not a good solution all around. I suspect we really cloned and owned.

--joel

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

Re: GSOC POSIX Compliance: Stuck trying to build Newlib

2021-06-15 Thread Vaibhav Gupta

Hello Matthew,

On Wed, Jun 16, 2021 at 12:58 AM Joel Sherrill  wrote:
>
> @RTEMS_TOOLS_BIN@ should have been replaced with the real directory where 
> your RTEMS tools are located. Something like this:

Exactly. I was wondering the same when I saw his output of 'echo $PATH'.
Matthew, the newlib and autoconf relationship is a bit messy. But you
can simplify it if you use $PATH carefully.
Have a look at this
https://medium.com/my-gsoc-2019-journey/how-to-handle-two-versions-of-autoconf-b1e28de8617b,
the path should expand and should point to the correct binaries.

The blog should give you an idea of how the $PATH works and how it
should be modified.


-- Vaibhav Gupta
>
> $ export PATH=${HOME}/rtems-work/tools/6/bin:$PATH
>
> And to check you have the PATH right, do something like this:
>
> $ type sparc-rtems6-gcc
> sparc-rtems6-gcc is /home/joel/rtems-work/tools/6/bin/sparc-rtems6-gcc
>
> On Tue, Jun 15, 2021 at 1:23 PM Eshan Dhawan  wrote:
>>
>> Hi matt
>> It would work if run inside newlib instead of newlib-cygwin
>> run command inside of ../newlib-cygwin/newlib
>> instead of ../newlib-cygwin
>>
>>
>> On Tue, Jun 15, 2021 at 10:59 PM Matthew Joyce  wrote:
>>>
>>> Ah, ok will do! Thank you for the tip.
>>>
>>> On Tue, Jun 15, 2021 at 7:17 PM Gedare Bloom  wrote:
>>> >
>>> > Just a note, it's more efficient to capture your terminal dump into a
>>> > text file and attach that, rather than put a screenshot up.
>>> >
>>> > On Tue, Jun 15, 2021 at 11:14 AM Matthew Joyce  
>>> > wrote:
>>> > >
>>> > > Hi Gentlemen,
>>> > >
>>> > > Thanks very much for your quick replies!
>>> > >
>>> > > I just tried both, but perhaps I'm misinterpreting your suggestions.
>>> > > (Could you please see the attached commands / errors!)
>>> > >
>>> > > Eshan,
>>> > >
>>> > > I did see that link, but it wasn't clear to me what the solution 
>>> > > was...Sorry!
>>> > >
>>> > > Sincerely,
>>> > >
>>> > > Matt
>>> > >
>>> > > On Tue, Jun 15, 2021 at 6:52 PM Eshan Dhawan  
>>> > > wrote:
>>> > > >
>>> > > > Hi Matt,
>>> > > > Try running the command with autoconf version 2.69 that's shipped 
>>> > > > with RTEMS in the rtems bin
>>> > > > That works as well.
>>> > > >
>>> > > > Also From a quick google search this is what I found : 
>>> > > > https://superuser.com/questions/617872/cant-locate-autom4te-channeldefs-pm-in-inc-when-it-definitely-is-there
>>> > > >
>>> > > > On Tue, Jun 15, 2021 at 9:12 PM Matthew Joyce  
>>> > > > wrote:
>>> > > >>
>>> > > >> Hello Dr. Joel and Eshan,
>>> > > >>
>>> > > >> I have a patch ready to send to Newlib for the sig function 
>>> > > >> prototypes
>>> > > >> and STR2SIG_MAX.
>>> > > >>
>>> > > >> But to do that, I think I need to have Newlib built, which I must
>>> > > >> still be doing wrong. The error that I am getting is attached below.
>>> > > >>
>>> > > >> I’ve been trying to follow the steps here:
>>> > > >> https://medium.com/my-gsoc-2019-journey/apply-newlib-patch-to-rtems-source-builder-6873b0fb31b8
>>> > > >> and 
>>> > > >> https://medium.com/my-gsoc-2019-journey/build-newlib-for-sparc-and-arm-architecture-6b3287d4c6f2
>>> > > >>
>>> > > >> I even had rebuilt everything from scratch to see if that would help,
>>> > > >> but I still get the same error. Maybe I cloned the newlib source into
>>> > > >> the wrong directory?
>>> > > >>
>>> > > >> I was hoping to get the patch off to Newlib for review as a first 
>>> > > >> step
>>> > > >> while I work on writing the actual methods. When you get a moment,
>>> > > >> could you please advise? Thank you very much!
>>> > > >>
>>> > > >> Sincerely,
>>> > > >>
>>> > > >> Matt
>>> > > ___
>>> > > devel mailing list
>>> > > devel@rtems.org
>>> > > http://lists.rtems.org/mailman/listinfo/devel
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v5] Update Strong APA Scheduler

2021-06-15 Thread Richi Dubey

This change allows for the migration of higher priority tasks on the
arrival of a lower priority task limited by affinity constraints.

Change license to BSD-2-Clause according to file history and
re-licensing agreement.
---
 cpukit/include/rtems/scheduler.h  |  10 +-
 .../include/rtems/score/schedulerstrongapa.h  | 162 ++-
 cpukit/score/src/schedulerstrongapa.c | 991 ++
 3 files changed, 929 insertions(+), 234 deletions(-)

diff --git a/cpukit/include/rtems/scheduler.h b/cpukit/include/rtems/scheduler.h
index 955a83cfb4..76d84fd787 100644
--- a/cpukit/include/rtems/scheduler.h
+++ b/cpukit/include/rtems/scheduler.h
@@ -251,22 +251,24 @@
 #ifdef CONFIGURE_SCHEDULER_STRONG_APA
   #include 
 
+  #ifndef CONFIGURE_MAXIMUM_PROCESSORS
+#error "CONFIGURE_MAXIMUM_PROCESSORS must be defined to configure the 
Strong APA scheduler"
+  #endif
+
   #define SCHEDULER_STRONG_APA_CONTEXT_NAME( name ) \
 SCHEDULER_CONTEXT_NAME( strong_APA_ ## name )
 
   #define RTEMS_SCHEDULER_STRONG_APA( name, prio_count ) \
 static struct { \
   Scheduler_strong_APA_Context Base; \
-  Chain_ControlReady[ ( prio_count ) ]; \
+  Scheduler_strong_APA_CPU CPU[ CONFIGURE_MAXIMUM_PROCESSORS ]; \
 } SCHEDULER_STRONG_APA_CONTEXT_NAME( name )
 
   #define RTEMS_SCHEDULER_TABLE_STRONG_APA( name, obj_name ) \
 { \
   &SCHEDULER_STRONG_APA_CONTEXT_NAME( name ).Base.Base.Base, \
   SCHEDULER_STRONG_APA_ENTRY_POINTS, \
-  RTEMS_ARRAY_SIZE( \
-SCHEDULER_STRONG_APA_CONTEXT_NAME( name ).Ready \
-  ) - 1, \
+  SCHEDULER_STRONG_APA_MAXIMUM_PRIORITY, \
   ( obj_name ) \
   SCHEDULER_CONTROL_IS_NON_PREEMPT_MODE_SUPPORTED( false ) \
 }
diff --git a/cpukit/include/rtems/score/schedulerstrongapa.h 
b/cpukit/include/rtems/score/schedulerstrongapa.h
index 530eadc279..acbeb7893a 100644
--- a/cpukit/include/rtems/score/schedulerstrongapa.h
+++ b/cpukit/include/rtems/score/schedulerstrongapa.h
@@ -8,30 +8,46 @@
  */
 
 /*
- * Copyright (c) 2013, 2018 embedded brains GmbH.  All rights reserved.
+ * SPDX-License-Identifier: BSD-2-Clause
  *
- *  embedded brains GmbH
- *  Dornierstr. 4
- *  82178 Puchheim
- *  Germany
- *  
+ * Copyright (C) 2020 Richi Dubey
+ * Copyright (c) 2013, 2018 embedded brains GmbH
  *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
+ * 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 COPYRIGHT HOLDERS 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 COPYRIGHT OWNER 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.
  */
 
 #ifndef _RTEMS_SCORE_SCHEDULERSTRONGAPA_H
 #define _RTEMS_SCORE_SCHEDULERSTRONGAPA_H
 
 #include 
-#include 
 #include 
 
 #ifdef __cplusplus
 extern "C" {
 #endif /* __cplusplus */
 
+/* Forward Declaration of Per_CPU_Control */
+struct Per_CPU_Control;
+
 /**
  * @defgroup RTEMSScoreSchedulerStrongAPA Strong APA Scheduler
  *
@@ -39,42 +55,95 @@ extern "C" {
  *
  * @brief This group contains the Strong APA Scheduler implementation.
  *
- * This is an implementation of the global fixed priority scheduler (G-FP).  It
- * uses one ready chain per priority to ensure constant time insert operations.
- * The scheduled chain uses linear insert operations and has at most processor
- * count entries.  Since the processor and priority count are constants all
- * scheduler operations complete in a bounded execution time.
- *
- * The the_thread preempt mode will be ignored.
+ * This is an implementation of the Strong APA scheduler defined by
+ * Cerqueira et al. in Linux's Processor Affinity API, Refined:
+ * Shifting Real-Time Tasks Towards Higher Schedulability.
  *
+ * The scheduled and ready nodes are accessed via the
+ * Scheduler_strong_APA_Context::Ready which helps in backtracking

Re: [PATCH v4] Update Strong APA Scheduler

2021-06-15 Thread Richi Dubey

Thanks for the review.

I have updated ticket 3053 and sent v5. Can you please check?

On Tue, Jun 15, 2021 at 4:06 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 11/06/2021 11:47, Richi Dubey wrote:
> > diff --git a/cpukit/score/src/schedulerstrongapa.c
> b/cpukit/score/src/schedulerstrongapa.c
> > index dcfb55601a..5aaa8dbd1a 100644
> > --- a/cpukit/score/src/schedulerstrongapa.c
> > +++ b/cpukit/score/src/schedulerstrongapa.c
> > @@ -3,29 +3,35 @@
> >*
> >* @ingroup RTEMSScoreSchedulerStrongAPA
> >*
> > - * @brief This source file contains the implementation of
> > - *   _Scheduler_strong_APA_Add_processor(),
> > - *   _Scheduler_strong_APA_Ask_for_help(),
> _Scheduler_strong_APA_Block(),
> > - *   _Scheduler_strong_APA_Initialize(),
> > - *   _Scheduler_strong_APA_Node_initialize(),
> > - *   _Scheduler_strong_APA_Reconsider_help_request(),
> > - *   _Scheduler_strong_APA_Remove_processor(),
> _Scheduler_strong_APA_Unblock(),
> > - *   _Scheduler_strong_APA_Update_priority(),
> > - *   _Scheduler_strong_APA_Withdraw_node(), and
> _Scheduler_strong_APA_Yield().
> > + * @brief Strong APA Scheduler Implementation
> >*/
>
> Could you please update the Doxygen comment instead of replacing it. At
> least make it a proper sentence.
>
> >
> >   /*
> > - * Copyright (c) 2013, 2016 embedded brains GmbH.  All rights reserved.
> > + * SPDX-License-Identifier: BSD-2-Clause
>
> The SPDX-License-Identifier have to be in the first line of the file.
> Please mention the license change in the commit messages and update the
> corresponding ticket.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v6 1/2] Update Strong APA Scheduler

2021-06-15 Thread Richi Dubey

This change allows for the migration of higher priority tasks on the
arrival of a lower priority task limited by affinity constraints.

Change license to BSD-2-Clause according to file history and
re-licensing agreement.
---
 cpukit/include/rtems/scheduler.h  |  10 +-
 .../include/rtems/score/schedulerstrongapa.h  | 162 ++-
 cpukit/score/src/schedulerstrongapa.c | 991 ++
 3 files changed, 929 insertions(+), 234 deletions(-)

diff --git a/cpukit/include/rtems/scheduler.h b/cpukit/include/rtems/scheduler.h
index 955a83cfb4..76d84fd787 100644
--- a/cpukit/include/rtems/scheduler.h
+++ b/cpukit/include/rtems/scheduler.h
@@ -251,22 +251,24 @@
 #ifdef CONFIGURE_SCHEDULER_STRONG_APA
   #include 
 
+  #ifndef CONFIGURE_MAXIMUM_PROCESSORS
+#error "CONFIGURE_MAXIMUM_PROCESSORS must be defined to configure the 
Strong APA scheduler"
+  #endif
+
   #define SCHEDULER_STRONG_APA_CONTEXT_NAME( name ) \
 SCHEDULER_CONTEXT_NAME( strong_APA_ ## name )
 
   #define RTEMS_SCHEDULER_STRONG_APA( name, prio_count ) \
 static struct { \
   Scheduler_strong_APA_Context Base; \
-  Chain_ControlReady[ ( prio_count ) ]; \
+  Scheduler_strong_APA_CPU CPU[ CONFIGURE_MAXIMUM_PROCESSORS ]; \
 } SCHEDULER_STRONG_APA_CONTEXT_NAME( name )
 
   #define RTEMS_SCHEDULER_TABLE_STRONG_APA( name, obj_name ) \
 { \
   &SCHEDULER_STRONG_APA_CONTEXT_NAME( name ).Base.Base.Base, \
   SCHEDULER_STRONG_APA_ENTRY_POINTS, \
-  RTEMS_ARRAY_SIZE( \
-SCHEDULER_STRONG_APA_CONTEXT_NAME( name ).Ready \
-  ) - 1, \
+  SCHEDULER_STRONG_APA_MAXIMUM_PRIORITY, \
   ( obj_name ) \
   SCHEDULER_CONTROL_IS_NON_PREEMPT_MODE_SUPPORTED( false ) \
 }
diff --git a/cpukit/include/rtems/score/schedulerstrongapa.h 
b/cpukit/include/rtems/score/schedulerstrongapa.h
index 530eadc279..acbeb7893a 100644
--- a/cpukit/include/rtems/score/schedulerstrongapa.h
+++ b/cpukit/include/rtems/score/schedulerstrongapa.h
@@ -8,30 +8,46 @@
  */
 
 /*
- * Copyright (c) 2013, 2018 embedded brains GmbH.  All rights reserved.
+ * SPDX-License-Identifier: BSD-2-Clause
  *
- *  embedded brains GmbH
- *  Dornierstr. 4
- *  82178 Puchheim
- *  Germany
- *  
+ * Copyright (C) 2020 Richi Dubey
+ * Copyright (c) 2013, 2018 embedded brains GmbH
  *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
+ * 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 COPYRIGHT HOLDERS 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 COPYRIGHT OWNER 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.
  */
 
 #ifndef _RTEMS_SCORE_SCHEDULERSTRONGAPA_H
 #define _RTEMS_SCORE_SCHEDULERSTRONGAPA_H
 
 #include 
-#include 
 #include 
 
 #ifdef __cplusplus
 extern "C" {
 #endif /* __cplusplus */
 
+/* Forward Declaration of Per_CPU_Control */
+struct Per_CPU_Control;
+
 /**
  * @defgroup RTEMSScoreSchedulerStrongAPA Strong APA Scheduler
  *
@@ -39,42 +55,95 @@ extern "C" {
  *
  * @brief This group contains the Strong APA Scheduler implementation.
  *
- * This is an implementation of the global fixed priority scheduler (G-FP).  It
- * uses one ready chain per priority to ensure constant time insert operations.
- * The scheduled chain uses linear insert operations and has at most processor
- * count entries.  Since the processor and priority count are constants all
- * scheduler operations complete in a bounded execution time.
- *
- * The the_thread preempt mode will be ignored.
+ * This is an implementation of the Strong APA scheduler defined by
+ * Cerqueira et al. in Linux's Processor Affinity API, Refined:
+ * Shifting Real-Time Tasks Towards Higher Schedulability.
  *
+ * The scheduled and ready nodes are accessed via the
+ * Scheduler_strong_APA_Context::Ready which helps in backtracking

[PATCH v6 2/2] Update smpstrongapa01; Add smpstrongapa02,smpstrongapa03

2021-06-15 Thread Richi Dubey

Update smpstrongapa01 to account for task shifting.
---
 spec/build/testsuites/smptests/grp.yml|   4 +
 .../testsuites/smptests/smpstrongapa02.yml|  21 +
 .../testsuites/smptests/smpstrongapa03.yml|  21 +
 testsuites/smptests/smpstrongapa01/init.c |  72 ++--
 testsuites/smptests/smpstrongapa02/init.c | 373 ++
 .../smpstrongapa02/smpstrongapa02.doc |  11 +
 .../smpstrongapa02/smpstrongapa02.scn |   2 +
 testsuites/smptests/smpstrongapa03/init.c | 358 +
 .../smpstrongapa03/smpstrongapa03.doc |  11 +
 .../smpstrongapa03/smpstrongapa03.scn |   2 +
 10 files changed, 846 insertions(+), 29 deletions(-)
 create mode 100644 spec/build/testsuites/smptests/smpstrongapa02.yml
 create mode 100644 spec/build/testsuites/smptests/smpstrongapa03.yml
 create mode 100644 testsuites/smptests/smpstrongapa02/init.c
 create mode 100644 testsuites/smptests/smpstrongapa02/smpstrongapa02.doc
 create mode 100644 testsuites/smptests/smpstrongapa02/smpstrongapa02.scn
 create mode 100644 testsuites/smptests/smpstrongapa03/init.c
 create mode 100644 testsuites/smptests/smpstrongapa03/smpstrongapa03.doc
 create mode 100644 testsuites/smptests/smpstrongapa03/smpstrongapa03.scn

diff --git a/spec/build/testsuites/smptests/grp.yml 
b/spec/build/testsuites/smptests/grp.yml
index 771708503e..14b575e058 100644
--- a/spec/build/testsuites/smptests/grp.yml
+++ b/spec/build/testsuites/smptests/grp.yml
@@ -125,6 +125,10 @@ links:
   uid: smpsignal01
 - role: build-dependency
   uid: smpstrongapa01
+- role: build-dependency
+  uid: smpstrongapa02
+- role: build-dependency
+  uid: smpstrongapa03
 - role: build-dependency
   uid: smpswitchextension01
 - role: build-dependency
diff --git a/spec/build/testsuites/smptests/smpstrongapa02.yml 
b/spec/build/testsuites/smptests/smpstrongapa02.yml
new file mode 100644
index 00..56673c1cf0
--- /dev/null
+++ b/spec/build/testsuites/smptests/smpstrongapa02.yml
@@ -0,0 +1,21 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+build-type: test-program
+cflags: []
+copyrights:
+- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+- Copyright (C) 2020 Richi Dubey (richidu...@gmail.com)
+cppflags: []
+cxxflags: []
+enabled-by:
+- RTEMS_SMP
+features: c cprogram
+includes: []
+ldflags: []
+links: []
+source:
+- testsuites/smptests/smpstrongapa02/init.c
+stlib: []
+target: testsuites/smptests/smpstrongapa02.exe
+type: build
+use-after: []
+use-before: []
diff --git a/spec/build/testsuites/smptests/smpstrongapa03.yml 
b/spec/build/testsuites/smptests/smpstrongapa03.yml
new file mode 100644
index 00..50d08216b8
--- /dev/null
+++ b/spec/build/testsuites/smptests/smpstrongapa03.yml
@@ -0,0 +1,21 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+build-type: test-program
+cflags: []
+copyrights:
+- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+- Copyright (C) 2020 Richi Dubey (richidu...@gmail.com)
+cppflags: []
+cxxflags: []
+enabled-by:
+- RTEMS_SMP
+features: c cprogram
+includes: []
+ldflags: []
+links: []
+source:
+- testsuites/smptests/smpstrongapa03/init.c
+stlib: []
+target: testsuites/smptests/smpstrongapa03.exe
+type: build
+use-after: []
+use-before: []
diff --git a/testsuites/smptests/smpstrongapa01/init.c 
b/testsuites/smptests/smpstrongapa01/init.c
index bf8bc05231..e7abacd519 100644
--- a/testsuites/smptests/smpstrongapa01/init.c
+++ b/testsuites/smptests/smpstrongapa01/init.c
@@ -1,4 +1,5 @@
 /*
+ * Copyright (c) 2020 Richi Dubey ( richidu...@gmail.com )
  * Copyright (c) 2016, 2017 embedded brains GmbH.  All rights reserved.
  *
  *  embedded brains GmbH
@@ -16,23 +17,28 @@
 #include "config.h"
 #endif
 
-#include "tmacros.h"
+#include 
 
 #include 
 
 const char rtems_test_name[] = "SMPSTRONGAPA 1";
 
-#define CPU_COUNT 4
+#define CPU_COUNT 2
 
-#define TASK_COUNT (3 * CPU_COUNT)
+#define TASK_COUNT 3
 
 #define P(i) (UINT32_C(2) + i)
 
 #define ALL ((UINT32_C(1) << CPU_COUNT) - 1)
 
-#define IDLE UINT8_C(255)
+#define A(cpu0, cpu1) ( (cpu1 << 1) | cpu0 )
 
-#define NAME rtems_build_name('S', 'A', 'P', 'A')
+typedef enum {
+  T0,
+  T1,
+  T2,
+  IDLE
+} task_index;
 
 typedef struct {
   enum {
@@ -43,7 +49,7 @@ typedef struct {
 KIND_UNBLOCK
   } kind;
 
-  size_t index;
+  task_index index;
 
   struct {
 rtems_task_priority priority;
@@ -65,54 +71,59 @@ typedef struct {
 KIND_RESET, \
 0, \
 { 0 }, \
-{ IDLE, IDLE, IDLE, IDLE } \
+{ IDLE, IDLE} \
   }
 
-#define SET_PRIORITY(index, prio, cpu0, cpu1, cpu2, cpu3) \
+#define SET_PRIORITY(index, prio, cpu0, cpu1) \
   { \
 KIND_SET_PRIORITY, \
 index, \
 { .priority = prio }, \
-{ cpu0, cpu1, cpu2, cpu3 } \
+{ cpu0, cpu1} \
   }
 
-#define SET_AFFINITY(index, aff, cpu0, cpu1, cpu2, cpu3) \
+#define SET_AFFINITY(index, aff, cpu0, cpu1) \
   { \
 KIND_SET_AFFINITY, \
 index, \
 { .cpu_set = aff }, \
-{ cpu0, cpu1, cpu2, cpu3

Re: [rtems-tools commit] rtems-bsp-builder: Change to waf build system

Re: [PATCH] part of implimenting a monotonic clock in rtems part of this is not the final patch.

Re: [PATCH 0/7] AMBA Plug & Play and APBUART improvements

[PATCH] score: Comment _Thread_queue_Surrender_sticky()

Re: [PATCH v4] Update Strong APA Scheduler

Re: [PATCH] score: Comment _Thread_queue_Surrender_sticky()

Re: [PATCH 0/7] AMBA Plug & Play and APBUART improvements

Re: [PATCH] user: Fixed typo to build hello application

Re: [PATCH rtems-docs 1/1] user/bsps/arm/raspberrypi: Changed the link to the Raspberry Pi Firmware to point to Firmware Version 1.20200601

Re: [PATCH v1] bsps/i386: Update calibration of TSC to be more accurate

Re: [PATCH rtems-docs 1/1] user/bsps/arm/raspberrypi: Changed the link to the Raspberry Pi Firmware to point to Firmware Version 1.20200601

Re: [libbsd] EPOCH(9): Fix epoch call and drain

Re: [PATCH rtems-libbsd 2/2] builder.py: Only disable tests if they are there

Re: [libbsd] EPOCH(9): Fix epoch call and drain

Re: [PATCH rtems-libbsd v2 3/4] rtemsbsd: Made TTCP command build for RTEMS

Re: [libbsd] EPOCH(9): Fix epoch call and drain

GSOC POSIX Compliance: Stuck trying to build Newlib

[libbsd] README: Mention SMP requirements

Re: GSOC POSIX Compliance: Stuck trying to build Newlib

Re: GSOC POSIX Compliance: Stuck trying to build Newlib

Re: GSOC POSIX Compliance: Stuck trying to build Newlib

Re: [libbsd] README: Mention SMP requirements

Re: GSOC POSIX Compliance: Stuck trying to build Newlib

Re: GSOC POSIX Compliance: Stuck trying to build Newlib

Re: [PATCH rtems-libbsd v2 3/4] rtemsbsd: Made TTCP command build for RTEMS

Re: GSOC POSIX Compliance: Stuck trying to build Newlib

Re: GSOC POSIX Compliance: Stuck trying to build Newlib

Re: [PATCH rtems-libbsd v2 3/4] rtemsbsd: Made TTCP command build for RTEMS

Re: GSOC POSIX Compliance: Stuck trying to build Newlib

[PATCH v5] Update Strong APA Scheduler

Re: [PATCH v4] Update Strong APA Scheduler

[PATCH v6 1/2] Update Strong APA Scheduler

[PATCH v6 2/2] Update smpstrongapa01; Add smpstrongapa02,smpstrongapa03

33 matches

Site Navigation

Mail list logo

Footer information