Re: [PATCH v3 2/2] bsp/raspberrypi: Mini UART driver

2020-02-15 Thread G. S. Niteesh
Hii,
This is a reminder message since this patch has been unnoticed for a while.
I have tested it on Raspberry Pi 3 and it works fine. There is also another
patch
https://lists.rtems.org/pipermail/devel/2020-February/057194.html, please
do have a look at these.

Thank you.
Niteesh
On Mon, Feb 10, 2020 at 12:52 AM G S Niteesh  wrote:

> This patch adds driver for Mini UART present in Raspberry Pi 3
> and above, this UART is currently used as the primary UART in
> these models.
> The Mini UART is similar to ns16550, this driver is built
> upon libchip/ns16550.
> ---
>  bsps/arm/raspberrypi/console/console-config.c | 118 --
>  bsps/arm/raspberrypi/include/bsp/usart.h  |   1 +
>  2 files changed, 110 insertions(+), 9 deletions(-)
>
> diff --git a/bsps/arm/raspberrypi/console/console-config.c
> b/bsps/arm/raspberrypi/console/console-config.c
> index 48c4c6a3ec..62196786dd 100644
> --- a/bsps/arm/raspberrypi/console/console-config.c
> +++ b/bsps/arm/raspberrypi/console/console-config.c
> @@ -24,6 +24,7 @@
>
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> @@ -34,35 +35,103 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>
> -
> -#define UART0 "/dev/ttyS0"
> +/**
> + * UART0 - PL011
> + * UART1 - Mini UART
> + */
> +#define PL011 "/dev/ttyAMA0"
> +#define MINIUART  "/dev/ttyS0"
>  #define FBCONS"/dev/fbcons"
>
>  arm_pl011_context pl011_context;
> +ns16550_context mini_uart_context;
>
>  rpi_fb_context fb_context;
>
> -static void output_char_serial(char c)
> +static void output_char_pl011(char c)
>  {
>arm_pl011_write_polled(_context.base, c);
>  }
>
> +static void output_char_mini_uart(char c)
> +{
> +  ns16550_polled_putchar(_uart_context.base, c);
> +}
> +
>  void output_char_fb(char c)
>  {
>fbcons_write_polled(_context.base, c);
>  }
>
> +static uint8_t mini_uart_get_reg(uintptr_t port, uint8_t index)
> +{
> +  volatile uint32_t *val = (volatile uint32_t *)port + index;
> +  return (uint8_t) *val;
> +}
> +
> +static void mini_uart_set_reg(uintptr_t port, uint8_t index, uint8_t val)
> +{
> +  volatile uint32_t *reg = (volatile uint32_t *)port + index;
> +  *reg = val;
> +}
> +
>  static void init_ctx_arm_pl011(
>const void *fdt,
>int node
>  )
>  {
>arm_pl011_context *ctx = _context;
> -  rtems_termios_device_context_initialize(>base, "UART");
> +  rtems_termios_device_context_initialize(>base, "PL011UART");
>ctx->regs = raspberrypi_get_reg_of_node(fdt, node);
>  }
>
> +static uint32_t calculate_baud_divisor(
> +  ns16550_context *ctx,
> +  uint32_t baud
> +)
> +{
> +  uint32_t baudDivisor = (ctx->clock / (8 * baud)) - 1;
> +  return baudDivisor;
> +}
> +
> +static void init_ctx_mini_uart(
> +  const void *fdt,
> +  int node
> +)
> +{
> +  const char *status;
> +  int len;
> +  ns16550_context *ctx;
> +
> +  memset(_uart_context, 0, sizeof(mini_uart_context));
> +  ctx = _uart_context;
> +
> +  rtems_termios_device_context_initialize(>base, "MiniUART");
> +
> +  status = fdt_getprop(fdt, node, "status", );
> +  if ( status == NULL || strcmp(status, "disabled" ) == 0){
> +return ;
> +  }
> +
> +  ctx->port = (uintptr_t) raspberrypi_get_reg_of_node(fdt, node);
> +  ctx->initial_baud = MINI_UART_DEFAULT_BAUD;
> +  ctx->clock = BCM2835_CLOCK_FREQ;
> +  ctx->calculate_baud_divisor = calculate_baud_divisor;
> +  ctx->get_reg = mini_uart_get_reg;
> +  ctx->set_reg = mini_uart_set_reg;
> +
> +  rtems_gpio_bsp_select_specific_io(0, 14, RPI_ALT_FUNC_5, NULL);
> +  rtems_gpio_bsp_select_specific_io(0, 15, RPI_ALT_FUNC_5, NULL);
> +  rtems_gpio_bsp_set_resistor_mode(0, 14, NO_PULL_RESISTOR);
> +  rtems_gpio_bsp_set_resistor_mode(0, 15, NO_PULL_RESISTOR);
> +
> +  BCM2835_REG(AUX_ENABLES) |= 0x1;
> +  ns16550_probe(>base);
> +}
> +
>  static void register_fb( void )
>  {
>if (fbcons_probe(_context.base) == true) {
> @@ -87,16 +156,28 @@ static void console_select( void )
>  link(FBCONS, CONSOLE_DEVICE_NAME);
>  return ;
>}
> +} else if ( strncmp( opt, MINIUART, sizeof(MINIUART) - 1 ) == 0) {
> +  BSP_output_char = output_char_mini_uart;
> +  link(MINIUART, CONSOLE_DEVICE_NAME);
> +} else if ( strncmp( opt, PL011, sizeof(PL011) - 1 ) == 0) {
> +  BSP_output_char = output_char_pl011;
> +  link(PL011, CONSOLE_DEVICE_NAME);
>  }
> +  }else {
> +/**
> + * If no command line option was given, default to PL011.
> + */
> +BSP_output_char = output_char_pl011;
> +link(PL011, CONSOLE_DEVICE_NAME);
>}
> -  BSP_output_char = output_char_serial;
> -  link(UART0, CONSOLE_DEVICE_NAME);
>  }
>
>  static void uart_probe(void)
>  {
>static bool initialized = false;
>const void *fdt;
> +  const char *console;
> +  int len;
>int node;
>
>if ( initialized ) {
> @@ -104,17 +185,29 @@ static void uart_probe(void)
>}
>
>fdt = bsp_fdt_get();
> -  node = fdt_node_offset_by_compatible(fdt, -1, "brcm,bcm2835-pl011");
>
> +  node = 

Re: [PATCH 13/18] config: Add _Thread_Idle_body

2020-02-15 Thread Sebastian Huber


On 16/02/2020 05:31, Gedare Bloom wrote:
On Sat, Feb 15, 2020 at 4:36 PM Chris Johns > wrote:


On 2020-02-15 03:02, Sebastian Huber wrote:
> Move the idle thread body configuration constant out of the
> configuration table.
>
> Provide a default definition of the idle thread body constant.

May be I am missing something simple here. How would I provide an
custom
IDLE task? Is it by providing something like ...

#include 

const Thread_Idle_body _Thread_Idle_body = My_Idle_body;


I think you do it by a configure macro that confdefs picks up by this 
line added:

+const Thread_Idle_body _Thread_Idle_body = CONFIGURE_IDLE_TASK_BODY;

It needs some doco ;)


Sorry, my problem is that I am so familiar with this stuff that I don't 
need documentation. What do you want to have documented and were should 
it be placed?


When I see a variable/function definition and want to see the Doxygen I 
just hit an editor key and get it. I don't want to duplicate 
documentation at the variable/function definition level.


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

Re: [PATCH 10/18] config: Add _Watchdog_Microseconds_per_tick

2020-02-15 Thread Sebastian Huber

On 16/02/2020 00:25, Chris Johns wrote:


On 2020-02-15 03:02, Sebastian Huber wrote:

Move the microseconds per tick configuration constant out of the
configuration table.
This is necessary to split up the confdefs.h file in easier to review 
pieces.


Add WATCHDOG_MICROSECONDS_PER_TICK_DEFAULT and use it to provide a
default definition of the watchdog ticks constants.
The benefit is that the application configuration object file will only 
include data structures which have a user-defined value. After reading 
this again, I think this part of the patch makes no sense, since most 
users define this to option to 1000.


What is the purpose and/or use for this change? 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 07/18] config: Bring back RTEMS 4.11 configuration table

2020-02-15 Thread Sebastian Huber



On 16/02/2020 00:30, Chris Johns wrote:

On 2020-02-15 03:02, Sebastian Huber wrote:

This improves API backward compatibility of RTEMS 5.1 to previous
versions.


What is the purpose of this change? How does a user wanting backward 
compatibility use this change?
There may be applications which used 
rtems_configuration_get_rtems_api_configuration() for diagnostic purposes.


How long do we maintain this interface?

As long as we have a Classic API.


We clearly document users should not create configuration tables and 
you are working to provide solid interfaces yet we have an interface 
for backwards compatibility.
We have two interfaces, one that creates the configuration, the 
documented interface for this is  and the configure 
option. The second interface is there to query the configuration. This 
is done through the rtems_configuration_*() macros/functions. This patch 
restores backward compatibility for the configuration query API.


Why in this specific case do we have to do this? Is there an app or 
user in mind that needs this?
No, I just thought it is a good idea to keep the configuration query API 
intact.

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


Re: [PATCH 13/18] config: Add _Thread_Idle_body

2020-02-15 Thread Sebastian Huber

On 16/02/2020 00:36, Chris Johns wrote:


On 2020-02-15 03:02, Sebastian Huber wrote:

Move the idle thread body configuration constant out of the
configuration table.

Provide a default definition of the idle thread body constant.


May be I am missing something simple here. How would I provide an 
custom IDLE task? Is it by providing something like ...


#include 

const Thread_Idle_body _Thread_Idle_body = My_Idle_body; 


No, definitely not. An application designer should use the documented API:

https://docs.rtems.org/branches/master/c-user/configuring_a_system.html#configure-idle-task-body

The goal of this and follow up change sets is to split this 3k LOC file 
(confdefs.h) in easier to review pieces.


The file contains also comments which should be in the Classic API 
Guide, e.g. how to configure the filesystems:


https://docs.rtems.org/branches/master/c-user/configuring_a_system.html#file-system-configuration-parameters

This is just an enumeration of the options. The user has no idea how 
things are related after reading this section.


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

Re: [PATCH 13/18] config: Add _Thread_Idle_body

2020-02-15 Thread Gedare Bloom
On Sat, Feb 15, 2020 at 4:36 PM Chris Johns  wrote:

> On 2020-02-15 03:02, Sebastian Huber wrote:
> > Move the idle thread body configuration constant out of the
> > configuration table.
> >
> > Provide a default definition of the idle thread body constant.
>
> May be I am missing something simple here. How would I provide an custom
> IDLE task? Is it by providing something like ...
>
> #include 
>
> const Thread_Idle_body _Thread_Idle_body = My_Idle_body;
>
>
I think you do it by a configure macro that confdefs picks up by this line
added:
+const Thread_Idle_body _Thread_Idle_body = CONFIGURE_IDLE_TASK_BODY;

It needs some doco ;)



> 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: [PATCH 13/18] config: Add _Thread_Idle_body

2020-02-15 Thread Chris Johns

On 2020-02-15 03:02, Sebastian Huber wrote:

Move the idle thread body configuration constant out of the
configuration table.

Provide a default definition of the idle thread body constant.


May be I am missing something simple here. How would I provide an custom 
IDLE task? Is it by providing something like ...


#include 

const Thread_Idle_body _Thread_Idle_body = My_Idle_body;

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


Re: [PATCH 07/18] config: Bring back RTEMS 4.11 configuration table

2020-02-15 Thread Chris Johns

On 2020-02-15 03:02, Sebastian Huber wrote:

This improves API backward compatibility of RTEMS 5.1 to previous
versions.


What is the purpose of this change? How does a user wanting backward 
compatibility use this change?


How long do we maintain this interface?

We clearly document users should not create configuration tables and you 
are working to provide solid interfaces yet we have an interface for 
backwards compatibility.


Why in this specific case do we have to do this? Is there an app or user 
in mind that needs this?


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


Re: [PATCH 10/18] config: Add _Watchdog_Microseconds_per_tick

2020-02-15 Thread Chris Johns

On 2020-02-15 03:02, Sebastian Huber wrote:

Move the microseconds per tick configuration constant out of the
configuration table.

Add WATCHDOG_MICROSECONDS_PER_TICK_DEFAULT and use it to provide a
default definition of the watchdog ticks constants.


What is the purpose and/or use for this change?

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


Re: [PATCH v2] config: Add

2020-02-15 Thread Gedare Bloom
Thanks looks good to me.

On Sat, Feb 15, 2020 at 10:58 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Unify handling of obsolete configuration options.  Change license to
> BSD-2-Clause.
>
> Update #3053.
> Update #3875.
> ---
>  cpukit/header-dirs.am|   2 +
>  cpukit/headers.am|   1 +
>  cpukit/include/rtems/confdefs.h  | 167 +-
>  cpukit/include/rtems/confdefs/obsolete.h | 234
> +++
>  4 files changed, 238 insertions(+), 166 deletions(-)
>  create mode 100644 cpukit/include/rtems/confdefs/obsolete.h
>
> diff --git a/cpukit/header-dirs.am b/cpukit/header-dirs.am
> index 7197f1a29f..d90271be9e 100644
> --- a/cpukit/header-dirs.am
> +++ b/cpukit/header-dirs.am
> @@ -50,6 +50,8 @@ include_rtems_bfindir = $(includedir)/rtems/bfin
>  include_rtems_bfin_HEADERS =
>  include_rtems_bsdnetdir = $(includedir)/rtems/bsdnet
>  include_rtems_bsdnet_HEADERS =
> +include_rtems_confdefsdir = $(includedir)/rtems/confdefs
> +include_rtems_confdefs_HEADERS =
>  include_rtems_debuggerdir = $(includedir)/rtems/debugger
>  include_rtems_debugger_HEADERS =
>  include_rtems_m68kdir = $(includedir)/rtems/m68k
> diff --git a/cpukit/headers.am b/cpukit/headers.am
> index 6e1ab4ccd0..f0c8319dcb 100644
> --- a/cpukit/headers.am
> +++ b/cpukit/headers.am
> @@ -183,6 +183,7 @@ include_rtems_HEADERS += include/rtems/userenv.h
>  include_rtems_HEADERS += include/rtems/version.h
>  include_rtems_HEADERS += include/rtems/vmeintr.h
>  include_rtems_HEADERS += include/rtems/watchdogdrv.h
> +include_rtems_confdefs_HEADERS += include/rtems/confdefs/obsolete.h
>  include_rtems_debugger_HEADERS +=
> include/rtems/debugger/rtems-debugger-bsp.h
>  include_rtems_debugger_HEADERS +=
> include/rtems/debugger/rtems-debugger-remote.h
>  include_rtems_debugger_HEADERS +=
> include/rtems/debugger/rtems-debugger-server.h
> diff --git a/cpukit/include/rtems/confdefs.h
> b/cpukit/include/rtems/confdefs.h
> index e0d4a77075..0b3b2af546 100644
> --- a/cpukit/include/rtems/confdefs.h
> +++ b/cpukit/include/rtems/confdefs.h
> @@ -50,6 +50,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>
> @@ -138,11 +139,6 @@ extern "C" {
>  #endif
>  #endif
>
> -#ifdef CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS
> -  #warning "CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS has been renamed to
> CONFIGURE_MAXIMUM_FILE_DESCRIPTORS since RTEMS 5.1"
> -  #define CONFIGURE_MAXIMUM_FILE_DESCRIPTORS
> CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS
> -#endif
> -
>  /**
>   * This macro defines the number of POSIX file descriptors allocated
>   * and managed by libio.  These are the "integer" file descriptors that
> @@ -167,11 +163,6 @@ extern "C" {
>const uint32_t rtems_libio_number_iops =
> RTEMS_ARRAY_SIZE(rtems_libio_iops);
>  #endif
>
> -#ifdef CONFIGURE_SMP_MAXIMUM_PROCESSORS
> -  #warning "CONFIGURE_SMP_MAXIMUM_PROCESSORS has been renamed to
> CONFIGURE_MAXIMUM_PROCESSORS since RTEMS 5.1"
> -  #define CONFIGURE_MAXIMUM_PROCESSORS CONFIGURE_SMP_MAXIMUM_PROCESSORS
> -#endif
> -
>  /* Ensure that _CONFIGURE_MAXIMUM_PROCESSORS > 1 only in SMP
> configurations */
>  #if defined(CONFIGURE_MAXIMUM_PROCESSORS) && defined(RTEMS_SMP)
>#define _CONFIGURE_MAXIMUM_PROCESSORS CONFIGURE_MAXIMUM_PROCESSORS
> @@ -191,34 +182,10 @@ extern "C" {
>#endif
>  #endif
>
> -#ifdef CONFIGURE_SMP_APPLICATION
> -  #warning "CONFIGURE_SMP_APPLICATION is obsolete since RTEMS 5.1"
> -#endif
> -
>  /*
>   * This sets up the resources for the FIFOs/pipes.
>   */
>
> -/**
> - * This is specified to configure the maximum number of POSIX FIFOs.
> - */
> -#ifdef CONFIGURE_MAXIMUM_FIFOS
> -  #warning "CONFIGURE_MAXIMUM_FIFOS is obsolete since RTEMS 5.1; use
> CONFIGURE_IMFS_ENABLE_MKFIFO instead"
> -  #if CONFIGURE_MAXIMUM_FIFOS > 0
> -#define CONFIGURE_IMFS_ENABLE_MKFIFO
> -  #endif
> -#endif
> -
> -/**
> - * This is specified to configure the maximum number of POSIX named pipes.
> - */
> -#ifdef CONFIGURE_MAXIMUM_PIPES
> -  #warning "CONFIGURE_MAXIMUM_PIPES is obsolete since RTEMS 5.1; use
> CONFIGURE_IMFS_ENABLE_MKFIFO instead"
> -  #if CONFIGURE_MAXIMUM_PIPES > 0
> -#define CONFIGURE_IMFS_ENABLE_MKFIFO
> -  #endif
> -#endif
> -
>  /**
>   *  @defgroup ConfigFilesystems Filesystems and Mount Table Configuration
>   *
> @@ -617,14 +584,6 @@ extern "C" {
>  #endif
>  /**@}*/ /* end of file system group */
>
> -/*
> - *  STACK_CHECKER_ON was still available in 4.9 so give a warning for now.
> - */
> -#if defined(STACK_CHECKER_ON)
> -  #define CONFIGURE_STACK_CHECKER_ENABLED
> -  #warning "STACK_CHECKER_ON deprecated -- use
> CONFIGURE_STACK_CHECKER_ENABLED"
> -#endif
> -
>  /**
>   * This configures the stack checker user extension.
>   */
> @@ -702,21 +661,6 @@ extern "C" {
>   *- CONFIGURE_SCHEDULER_USER_PER_THREAD
>   */
>
> -#ifdef CONFIGURE_SCHEDULER_CONTEXT
> -  #warning "CONFIGURE_SCHEDULER_CONTEXT has been renamed to
> CONFIGURE_SCHEDULER since RTEMS 5.1"

Re: [PATCH v4] doc/raspberrypi: Added instructions for raspberrypi

2020-02-15 Thread Christian Mauderer
Hello Niteesh,

thanks. I pushed it:
https://git.rtems.org/rtems-docs/commit/?id=5763454b307afae6f5feb7e6d3d3d780f05f83ab

Best regards

Christian

On 15/02/2020 15:20, G. S. Niteesh wrote:
> Another remainder.
> Can someone please push this?
> 
> Thanks,
> Niteesh
> 
> On Thu, Feb 13, 2020 at 11:19 PM G. S. Niteesh  > wrote:
> 
> On Thu, Feb 13, 2020 at 11:16 PM Alan Cudmore
> mailto:alan.cudm...@gmail.com>> wrote:
> 
> "set scheduler-locking on" in GDB works! I was able to run RPI2
> hello.exe
> 
> So I consider your instructions ready to go in the repo.
> More Pi 2 SMP debugging when I get the time..
> Thanks!
> Alan
> 
> Great. But just a caution, QEMU support raspberry pi is very
> much incomplete
> so any exception or problem may be from QEMU side and not RTEMS. So
> if any
> test goes wrong, try running it on a real board.
> 
> Thanks,
> Niteesh
> 
> On Thu, Feb 13, 2020 at 12:30 PM G. S. Niteesh
> mailto:gsnb...@gmail.com>> wrote:
> >
> > On Thu, Feb 13, 2020 at 10:57 PM Alan Cudmore
> mailto:alan.cudm...@gmail.com>> wrote:
> >>
> >> I get exceptions when trying to run hello.exe.
> >> I'm using qemu-system-arm v 2.11.1 from ubuntu. Should I try
> using the
> >> one built by RSB?
> >
> > No this should be fine. Can you post a screenshot of the output?
> >>
> >> I was trying to get this setup to try RPI 2 SMP in QEMU. I
> may want to
> >> get the latest repo and do a clean build to try this again.
> >
> > SMP doesn't work well with QEMU. Did you try set
> scheduler-locking on in GDB?
> > Running the executables directly in QEMU doesn't work.
> >>
> >> Thanks,
> >> Alan
> >>
> >> On Thu, Feb 13, 2020 at 12:12 PM G. S. Niteesh
> mailto:gsnb...@gmail.com>> wrote:
> >> >
> >> > On Thu, Feb 13, 2020 at 10:40 PM Alan Cudmore
> mailto:alan.cudm...@gmail.com>> wrote:
> >> >>
> >> >> Hi Niteesh,
> >> >> I have followed your instructions for getting RTEMS
> running on the Pi
> >> >> 1 and 2. SMP currently is not working on the 2 for me, but
> that is not
> >> >> a problem with these instructions.
> >> >> I started to try running on QEMU following your
> instructions but have
> >> >> not been able to get time to complete my tests.
> >> >
> >> > What problem are you exactly facing?
> >> >>
> >> >>
> >> >>
> >> >> But this is a vast improvement over "TODO", so I recommend
> accepting
> >> >> this change.
> >> >>
> >> >> Thanks for creating this,
> >> >> Alan
> >> >>
> >> >> On Thu, Feb 13, 2020 at 1:49 AM G. S. Niteesh
> mailto:gsnb...@gmail.com>> wrote:
> >> >> >
> >> >> > Can someone take a look at this, It has been unnoticed
> for quite a while.
> >> >> >
> >> >> > Thank you,
> >> >> > Niteesh
> >> >> >
> >> >> > On Sat, Jan 25, 2020 at 10:49 PM G S Niteesh
> mailto:gsnb...@gmail.com>> wrote:
> >> >> >>
> >> >> >> Added instructions to run examples on raspberrypi.
> >> >> >> ---
> >> >> >>  user/bsps/arm/raspberrypi.rst | 111
> +-
> >> >> >>  1 file changed, 110 insertions(+), 1 deletion(-)
> >> >> >>
> >> >> >> diff --git a/user/bsps/arm/raspberrypi.rst
> b/user/bsps/arm/raspberrypi.rst
> >> >> >> index 4ef75bd..72889a5 100644
> >> >> >> --- a/user/bsps/arm/raspberrypi.rst
> >> >> >> +++ b/user/bsps/arm/raspberrypi.rst
> >> >> >> @@ -5,4 +5,113 @@
> >> >> >>  raspberrypi
> >> >> >>  ===
> >> >> >>
> >> >> >> -TODO.
> >> >> >> +This BSP supports `Raspberry Pi 1` and `Raspberry Pi
> 2` currently.
> >> >> >> +The support for `Raspberry Pi 3` is work under progress.
> >> >> >> +The default bootloader on the Raspberry Pi which is
> used to boot Raspbian
> >> >> >> +or other OS can be also used to boot RTEMS. U-boot can
> also be used.
> >> >> >> +
> >> >> >> +Setup SD card
> >> >> >> +
> >> >> >> +
> >> >> >> +The Raspberry Pis have an unconventional booting
> mechanism. The GPU
> >> >> >> +boots first, initializes itself, runs the bootloader
> and starts the CPU.
> >> >> >> +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 

Re: [PATCH 6/6] config: Remove CONFIGURE_DISABLE_SMP_CONFIGURATION

2020-02-15 Thread Sebastian Huber

Hello Joel,

On 15/02/2020 15:12, Joel Sherrill wrote:
Another historical detail for the commit message is that even in SMP 
builds, uniprocesor tests used a uniprocesor schedule. It took us a 
while to decide that the uniprocesor tests should behave the same with 
the proper SMP scheduler.


This is a pretty fundamental realisation and probably is worth 
capturing as a guiding principle for our tests.
I think I understand what you mean, however, I have difficulties to 
formulate this as a commit message part.

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


[PATCH v2] config: Add

2020-02-15 Thread Sebastian Huber
Unify handling of obsolete configuration options.  Change license to
BSD-2-Clause.

Update #3053.
Update #3875.
---
 cpukit/header-dirs.am|   2 +
 cpukit/headers.am|   1 +
 cpukit/include/rtems/confdefs.h  | 167 +-
 cpukit/include/rtems/confdefs/obsolete.h | 234 +++
 4 files changed, 238 insertions(+), 166 deletions(-)
 create mode 100644 cpukit/include/rtems/confdefs/obsolete.h

diff --git a/cpukit/header-dirs.am b/cpukit/header-dirs.am
index 7197f1a29f..d90271be9e 100644
--- a/cpukit/header-dirs.am
+++ b/cpukit/header-dirs.am
@@ -50,6 +50,8 @@ include_rtems_bfindir = $(includedir)/rtems/bfin
 include_rtems_bfin_HEADERS =
 include_rtems_bsdnetdir = $(includedir)/rtems/bsdnet
 include_rtems_bsdnet_HEADERS =
+include_rtems_confdefsdir = $(includedir)/rtems/confdefs
+include_rtems_confdefs_HEADERS =
 include_rtems_debuggerdir = $(includedir)/rtems/debugger
 include_rtems_debugger_HEADERS =
 include_rtems_m68kdir = $(includedir)/rtems/m68k
diff --git a/cpukit/headers.am b/cpukit/headers.am
index 6e1ab4ccd0..f0c8319dcb 100644
--- a/cpukit/headers.am
+++ b/cpukit/headers.am
@@ -183,6 +183,7 @@ include_rtems_HEADERS += include/rtems/userenv.h
 include_rtems_HEADERS += include/rtems/version.h
 include_rtems_HEADERS += include/rtems/vmeintr.h
 include_rtems_HEADERS += include/rtems/watchdogdrv.h
+include_rtems_confdefs_HEADERS += include/rtems/confdefs/obsolete.h
 include_rtems_debugger_HEADERS += include/rtems/debugger/rtems-debugger-bsp.h
 include_rtems_debugger_HEADERS += 
include/rtems/debugger/rtems-debugger-remote.h
 include_rtems_debugger_HEADERS += 
include/rtems/debugger/rtems-debugger-server.h
diff --git a/cpukit/include/rtems/confdefs.h b/cpukit/include/rtems/confdefs.h
index e0d4a77075..0b3b2af546 100644
--- a/cpukit/include/rtems/confdefs.h
+++ b/cpukit/include/rtems/confdefs.h
@@ -50,6 +50,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -138,11 +139,6 @@ extern "C" {
 #endif
 #endif
 
-#ifdef CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS
-  #warning "CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS has been renamed to 
CONFIGURE_MAXIMUM_FILE_DESCRIPTORS since RTEMS 5.1"
-  #define CONFIGURE_MAXIMUM_FILE_DESCRIPTORS 
CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS
-#endif
-
 /**
  * This macro defines the number of POSIX file descriptors allocated
  * and managed by libio.  These are the "integer" file descriptors that
@@ -167,11 +163,6 @@ extern "C" {
   const uint32_t rtems_libio_number_iops = RTEMS_ARRAY_SIZE(rtems_libio_iops);
 #endif
 
-#ifdef CONFIGURE_SMP_MAXIMUM_PROCESSORS
-  #warning "CONFIGURE_SMP_MAXIMUM_PROCESSORS has been renamed to 
CONFIGURE_MAXIMUM_PROCESSORS since RTEMS 5.1"
-  #define CONFIGURE_MAXIMUM_PROCESSORS CONFIGURE_SMP_MAXIMUM_PROCESSORS
-#endif
-
 /* Ensure that _CONFIGURE_MAXIMUM_PROCESSORS > 1 only in SMP configurations */
 #if defined(CONFIGURE_MAXIMUM_PROCESSORS) && defined(RTEMS_SMP)
   #define _CONFIGURE_MAXIMUM_PROCESSORS CONFIGURE_MAXIMUM_PROCESSORS
@@ -191,34 +182,10 @@ extern "C" {
   #endif
 #endif
 
-#ifdef CONFIGURE_SMP_APPLICATION
-  #warning "CONFIGURE_SMP_APPLICATION is obsolete since RTEMS 5.1"
-#endif
-
 /*
  * This sets up the resources for the FIFOs/pipes.
  */
 
-/**
- * This is specified to configure the maximum number of POSIX FIFOs.
- */
-#ifdef CONFIGURE_MAXIMUM_FIFOS
-  #warning "CONFIGURE_MAXIMUM_FIFOS is obsolete since RTEMS 5.1; use 
CONFIGURE_IMFS_ENABLE_MKFIFO instead"
-  #if CONFIGURE_MAXIMUM_FIFOS > 0
-#define CONFIGURE_IMFS_ENABLE_MKFIFO
-  #endif
-#endif
-
-/**
- * This is specified to configure the maximum number of POSIX named pipes.
- */
-#ifdef CONFIGURE_MAXIMUM_PIPES
-  #warning "CONFIGURE_MAXIMUM_PIPES is obsolete since RTEMS 5.1; use 
CONFIGURE_IMFS_ENABLE_MKFIFO instead"
-  #if CONFIGURE_MAXIMUM_PIPES > 0
-#define CONFIGURE_IMFS_ENABLE_MKFIFO
-  #endif
-#endif
-
 /**
  *  @defgroup ConfigFilesystems Filesystems and Mount Table Configuration
  *
@@ -617,14 +584,6 @@ extern "C" {
 #endif
 /**@}*/ /* end of file system group */
 
-/*
- *  STACK_CHECKER_ON was still available in 4.9 so give a warning for now.
- */
-#if defined(STACK_CHECKER_ON)
-  #define CONFIGURE_STACK_CHECKER_ENABLED
-  #warning "STACK_CHECKER_ON deprecated -- use CONFIGURE_STACK_CHECKER_ENABLED"
-#endif
-
 /**
  * This configures the stack checker user extension.
  */
@@ -702,21 +661,6 @@ extern "C" {
  *- CONFIGURE_SCHEDULER_USER_PER_THREAD
  */
 
-#ifdef CONFIGURE_SCHEDULER_CONTEXT
-  #warning "CONFIGURE_SCHEDULER_CONTEXT has been renamed to 
CONFIGURE_SCHEDULER since RTEMS 5.1"
-  #define CONFIGURE_SCHEDULER CONFIGURE_SCHEDULER_CONTEXT
-#endif
-
-#ifdef CONFIGURE_SCHEDULER_CONTROLS
-  #warning "CONFIGURE_SCHEDULER_CONTROLS has been renamed to 
CONFIGURE_SCHEDULER_TABLE_ENTRIES since RTEMS 5.1"
-  #define CONFIGURE_SCHEDULER_TABLE_ENTRIES CONFIGURE_SCHEDULER_CONTROLS
-#endif
-
-#ifdef CONFIGURE_SMP_SCHEDULER_ASSIGNMENTS
-  #warning 

Re: [PATCH 18/18] config: Add

2020-02-15 Thread Sebastian Huber

On 15/02/2020 15:16, Joel Sherrill wrote:



And note when perhaps with a version when an option was deemed 
obsolete. You might be able to get that from git blame in the future 
but for now we just destroyed all that info for blame by creating a 
new file.
I tried to do that, for some options I was not able to find the 
corresponding release. There is a gap in the tags 4.0.0 -> 4.5.0.

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


Re: [PATCH 18/18] config: Add

2020-02-15 Thread Gedare Bloom
On Sat, Feb 15, 2020 at 7:16 AM Joel Sherrill  wrote:

>
>
> On Sat, Feb 15, 2020, 2:38 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 15/02/2020 05:22, Gedare Bloom wrote:
>>
>> > This makes sense. Is there any reason for the ordering?
>> It should be alphabetically sorted.
>> >
>> > If possible, I think grouping by obsoleted version or alphabetical
>> > ordering would be a good idea.
>>
>> Maybe I should add a comment like this to the top of the list:
>>
>> /*
>>   * Please keep the list of obsolete configuration options
>> alphabetically sorted.
>>   *
>>   * Use #warning for renamed options and define the new option
>> accordingly.
>>   *
>>   * Use #warning for obsolete options which are now superfluous, e.g.
>> because
>>   * the objects are now self-contained.
>>   *
>>   * Use #error for options which require now a different configuration
>> approach,
>>   * e.g. options for an own configuration table.
>>   *
>>
>
> And note when perhaps with a version when an option was deemed obsolete.
> You might be able to get that from git blame in the future but for now we
> just destroyed all that info for blame by creating a new file.
>

+1 the internal documentation should explicitly say that. It looks like the
existing warnings do spit out the version of obsolescence.

Some of the macros are out-of-order.

I noticed that there is N -> M -> L that are backwards.


>
>> ___
>> 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] first commit

2020-02-15 Thread Joel Sherrill
I got the screenshot in a private email before I saw this. Looks good.

What kind of projects are you interested in?

On Sat, Feb 15, 2020, 1:41 AM suyash singh  wrote:

> Hello I am Suyash Singh and this is my first commit. I am from India and
> currently in 2nd year of BTech Computer Science Engineering. I am hoping to
> participate in RTEMS as a GSOC student and beyond.
>
>
>
> On Sat, Feb 15, 2020 at 12:56 PM suyash singh 
> wrote:
>
>> ---
>>  testsuites/samples/hello/init.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/testsuites/samples/hello/init.c
>> b/testsuites/samples/hello/init.c
>> index 34ded37c55..7f165d17a5 100644
>> --- a/testsuites/samples/hello/init.c
>> +++ b/testsuites/samples/hello/init.c
>> @@ -22,7 +22,7 @@ static rtems_task Init(
>>  {
>>rtems_print_printer_fprintf_putc(_test_printer);
>>TEST_BEGIN();
>> -  printf( "Hello World\n" );
>> +  printf( "Hello RTEMS. I am Suyash Singh" );
>>TEST_END();
>>rtems_test_exit( 0 );
>>  }
>> --
>> 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 v4] doc/raspberrypi: Added instructions for raspberrypi

2020-02-15 Thread G. S. Niteesh
Another remainder.
Can someone please push this?

Thanks,
Niteesh

On Thu, Feb 13, 2020 at 11:19 PM G. S. Niteesh  wrote:

> On Thu, Feb 13, 2020 at 11:16 PM Alan Cudmore 
> wrote:
>
>> "set scheduler-locking on" in GDB works! I was able to run RPI2 hello.exe
>>
>> So I consider your instructions ready to go in the repo.
>> More Pi 2 SMP debugging when I get the time..
>> Thanks!
>> Alan
>>
>> Great. But just a caution, QEMU support raspberry pi is very
> much incomplete
> so any exception or problem may be from QEMU side and not RTEMS. So if any
> test goes wrong, try running it on a real board.
>
> Thanks,
> Niteesh
>
>> On Thu, Feb 13, 2020 at 12:30 PM G. S. Niteesh  wrote:
>> >
>> > On Thu, Feb 13, 2020 at 10:57 PM Alan Cudmore 
>> wrote:
>> >>
>> >> I get exceptions when trying to run hello.exe.
>> >> I'm using qemu-system-arm v 2.11.1 from ubuntu. Should I try using the
>> >> one built by RSB?
>> >
>> > No this should be fine. Can you post a screenshot of the output?
>> >>
>> >> I was trying to get this setup to try RPI 2 SMP in QEMU. I may want to
>> >> get the latest repo and do a clean build to try this again.
>> >
>> > SMP doesn't work well with QEMU. Did you try set scheduler-locking on
>> in GDB?
>> > Running the executables directly in QEMU doesn't work.
>> >>
>> >> Thanks,
>> >> Alan
>> >>
>> >> On Thu, Feb 13, 2020 at 12:12 PM G. S. Niteesh 
>> wrote:
>> >> >
>> >> > On Thu, Feb 13, 2020 at 10:40 PM Alan Cudmore <
>> alan.cudm...@gmail.com> wrote:
>> >> >>
>> >> >> Hi Niteesh,
>> >> >> I have followed your instructions for getting RTEMS running on the
>> Pi
>> >> >> 1 and 2. SMP currently is not working on the 2 for me, but that is
>> not
>> >> >> a problem with these instructions.
>> >> >> I started to try running on QEMU following your instructions but
>> have
>> >> >> not been able to get time to complete my tests.
>> >> >
>> >> > What problem are you exactly facing?
>> >> >>
>> >> >>
>> >> >>
>> >> >> But this is a vast improvement over "TODO", so I recommend accepting
>> >> >> this change.
>> >> >>
>> >> >> Thanks for creating this,
>> >> >> Alan
>> >> >>
>> >> >> On Thu, Feb 13, 2020 at 1:49 AM G. S. Niteesh 
>> wrote:
>> >> >> >
>> >> >> > Can someone take a look at this, It has been unnoticed for quite
>> a while.
>> >> >> >
>> >> >> > Thank you,
>> >> >> > Niteesh
>> >> >> >
>> >> >> > On Sat, Jan 25, 2020 at 10:49 PM G S Niteesh 
>> wrote:
>> >> >> >>
>> >> >> >> Added instructions to run examples on raspberrypi.
>> >> >> >> ---
>> >> >> >>  user/bsps/arm/raspberrypi.rst | 111
>> +-
>> >> >> >>  1 file changed, 110 insertions(+), 1 deletion(-)
>> >> >> >>
>> >> >> >> diff --git a/user/bsps/arm/raspberrypi.rst
>> b/user/bsps/arm/raspberrypi.rst
>> >> >> >> index 4ef75bd..72889a5 100644
>> >> >> >> --- a/user/bsps/arm/raspberrypi.rst
>> >> >> >> +++ b/user/bsps/arm/raspberrypi.rst
>> >> >> >> @@ -5,4 +5,113 @@
>> >> >> >>  raspberrypi
>> >> >> >>  ===
>> >> >> >>
>> >> >> >> -TODO.
>> >> >> >> +This BSP supports `Raspberry Pi 1` and `Raspberry Pi 2`
>> currently.
>> >> >> >> +The support for `Raspberry Pi 3` is work under progress.
>> >> >> >> +The default bootloader on the Raspberry Pi which is used to
>> boot Raspbian
>> >> >> >> +or other OS can be also used to boot RTEMS. U-boot can also be
>> used.
>> >> >> >> +
>> >> >> >> +Setup SD card
>> >> >> >> +
>> >> >> >> +
>> >> >> >> +The Raspberry Pis have an unconventional booting mechanism. The
>> GPU
>> >> >> >> +boots first, initializes itself, runs the bootloader and starts
>> the CPU.
>> >> >> >> +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 can remove the ``kernel*.img`` files if you want too, but
>> don't touch
>> >> >> >> +the other files.
>> >> >> >> +
>> >> >> >> +Copy these files in to a SD card with FAT filesystem.
>> >> >> >> +
>> >> >> >> +Kernel image
>> >> >> >> +
>> >> >> >> +
>> >> >> >> +The following steps show how to run ``hello.exe`` on a
>> Raspberry Pi 2.
>> >> >> >> +The same instructions can be applied to Raspberry Pi 1 also.
>> >> >> >> +Other executables can be processed in a similar way.
>> >> >> >> +
>> >> >> >> +To create the kernel image:
>> >> >> >> +
>> >> >> >> +.. code-block:: none
>> >> >> >> +
>> >> >> >> + $ arm-rtems5-objcopy -Obinary hello.exe kernel.img
>> >> >> >> +
>> >> >> >> +Copy the kernel image to the SD card.
>> >> >> >> +
>> >> >> >> +Make sure you have these lines below, in your ``config.txt``.
>> >> >> >> +
>> >> >> >> +.. code-block:: none
>> >> >> >> +
>> >> >> >> + 

Re: [PATCH 18/18] config: Add

2020-02-15 Thread Joel Sherrill
On Sat, Feb 15, 2020, 2:38 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 15/02/2020 05:22, Gedare Bloom wrote:
>
> > This makes sense. Is there any reason for the ordering?
> It should be alphabetically sorted.
> >
> > If possible, I think grouping by obsoleted version or alphabetical
> > ordering would be a good idea.
>
> Maybe I should add a comment like this to the top of the list:
>
> /*
>   * Please keep the list of obsolete configuration options
> alphabetically sorted.
>   *
>   * Use #warning for renamed options and define the new option accordingly.
>   *
>   * Use #warning for obsolete options which are now superfluous, e.g.
> because
>   * the objects are now self-contained.
>   *
>   * Use #error for options which require now a different configuration
> approach,
>   * e.g. options for an own configuration table.
>   *
>

And note when perhaps with a version when an option was deemed obsolete.
You might be able to get that from git blame in the future but for now we
just destroyed all that info for blame by creating a new file.

>
> ___
> 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 6/6] config: Remove CONFIGURE_DISABLE_SMP_CONFIGURATION

2020-02-15 Thread Joel Sherrill
Another historical detail for the commit message is that even in SMP
builds, uniprocesor tests used a uniprocesor schedule. It took us a while
to decide that the uniprocesor tests should behave the same with the proper
SMP scheduler.

This is a pretty fundamental realisation and probably is worth capturing as
a guiding principle for our tests.

On Sat, Feb 15, 2020, 6:36 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> The CONFIGURE_DISABLE_SMP_CONFIGURATION configuration option and
> rtems_configuration_is_smp_enabled() were added during the SMP support
> development cycle as a workaround to fix some testsuite failures in SMP
> configurations.  All use cases were replaced with tests for specific
> conditions.  The configuration option and test macro were undocumented.
>
> Close #3876.
> ---
>  cpukit/include/rtems/confdefs.h   | 19
> ---
>  cpukit/include/rtems/config.h | 13 -
>  cpukit/include/rtems/score/smp.h  | 13 -
>  testsuites/ada/support/initimpl.h |  2 --
>  testsuites/libtests/block08/system.h  |  2 --
>  testsuites/libtests/cpuuse/system.h   |  2 --
>  testsuites/libtests/rtmonuse/system.h |  1 -
>  testsuites/libtests/termios05/init.c  |  2 --
>  testsuites/smptests/smpunsupported01/init.c   |  2 --
>  testsuites/sptests/sp01/system.h  |  2 --
>  testsuites/sptests/sp04/system.h  |  2 --
>  testsuites/sptests/sp07/system.h  |  2 --
>  testsuites/sptests/sp08/init.c|  2 --
>  testsuites/sptests/sp12/system.h  |  2 --
>  testsuites/sptests/sp13/system.h  |  2 --
>  testsuites/sptests/sp14/system.h  |  2 --
>  testsuites/sptests/sp16/system.h  |  2 --
>  testsuites/sptests/sp20/system.h  |  2 --
>  testsuites/sptests/sp37/system.h  |  2 --
>  testsuites/sptests/sp65/sp65impl.h|  2 --
>  testsuites/sptests/spcbssched01/system.h  |  2 --
>  testsuites/sptests/spcbssched02/system.h  |  2 --
>  testsuites/sptests/spcbssched03/system.h  |  2 --
>  testsuites/sptests/spedfsched01/system.h  |  2 --
>  testsuites/sptests/spedfsched02/system.h  |  2 --
>  testsuites/sptests/spedfsched03/system.h  |  2 --
>  testsuites/sptests/spfatal29/init.c   |  2 --
>  testsuites/sptests/spfifo03/init.c|  2 --
>  testsuites/sptests/spfifo05/init.c|  2 --
>  .../sptests/spintrcritical06/spintrcritical06impl.h   |  2 --
>  testsuites/sptests/spintrcritical15/init.c|  2 --
>  testsuites/sptests/spmrsp01/init.c|  2 --
>  testsuites/sptests/spsimplesched02/init.c |  2 --
>  testsuites/tmtests/tm04/system.h  |  2 --
>  testsuites/tmtests/tm08/system.h  |  2 --
>  testsuites/tmtests/tm15/system.h  |  2 --
>  testsuites/tmtests/tm20/system.h  |  2 --
>  testsuites/tmtests/tm22/system.h  |  2 --
>  testsuites/tmtests/tm24/system.h  |  2 --
>  39 files changed, 116 deletions(-)
>
> diff --git a/cpukit/include/rtems/confdefs.h
> b/cpukit/include/rtems/confdefs.h
> index eb837fd389..d45287591e 100644
> --- a/cpukit/include/rtems/confdefs.h
> +++ b/cpukit/include/rtems/confdefs.h
> @@ -159,18 +159,6 @@ extern "C" {
>#define _CONFIGURE_MAXIMUM_PROCESSORS 1
>  #endif
>
> -/*
> - * An internal define to indicate that this is an SMP application
> - * configuration.
> - */
> -#ifdef RTEMS_SMP
> -  #if !defined(CONFIGURE_DISABLE_SMP_CONFIGURATION)
> -#define _CONFIGURE_SMP_APPLICATION
> -  #elif _CONFIGURE_MAXIMUM_PROCESSORS > 1
> -#error "CONFIGURE_DISABLE_SMP_CONFIGURATION and
> CONFIGURE_MAXIMUM_PROCESSORS > 1 makes no sense"
> -  #endif
> -#endif
> -
>  /*
>   * This sets up the resources for the FIFOs/pipes.
>   */
> @@ -2576,13 +2564,6 @@ struct _reent *__getreent(void)
>#endif
>
>#ifdef RTEMS_SMP
> -const bool _SMP_Is_enabled =
> -  #ifdef _CONFIGURE_SMP_APPLICATION
> -true;
> -  #else
> -false;
> -  #endif
> -
>  const uint32_t _SMP_Processor_configured_maximum =
>_CONFIGURE_MAXIMUM_PROCESSORS;
>#endif
> diff --git a/cpukit/include/rtems/config.h b/cpukit/include/rtems/config.h
> index 4811d0e704..e82c7abf11 100644
> --- a/cpukit/include/rtems/config.h
> +++ b/cpukit/include/rtems/config.h
> @@ -150,19 +150,6 @@ uint32_t rtems_configuration_get_maximum_extensions(
> void );
>  NULL
>  #endif
>
> -/**
> - * @brief Returns true if the SMP mode of operation is enabled, and false
> - * otherwise.
> - *
> - * In uni-processor configurations this 

Re: Ticket #1977

2020-02-15 Thread Joel Sherrill
On Sat, Feb 15, 2020, 6:20 AM Eshan Dhawan  wrote:

> Also, I wanted to know if there were test suites to check it?
>

Not yet since there is no functionality to test


> On Sat, Feb 15, 2020 at 5:48 PM Eshan Dhawan 
> wrote:
>
>> Hi,
>> As I was going through the ticket I wanted to know the main arguments
>> that are to be passed in mode and how they are to be processed in the
>> mq_open.
>>
>
The mode argument is like a file mode provided to open(2) per
https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.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

[PATCH 6/6] config: Remove CONFIGURE_DISABLE_SMP_CONFIGURATION

2020-02-15 Thread Sebastian Huber
The CONFIGURE_DISABLE_SMP_CONFIGURATION configuration option and
rtems_configuration_is_smp_enabled() were added during the SMP support
development cycle as a workaround to fix some testsuite failures in SMP
configurations.  All use cases were replaced with tests for specific
conditions.  The configuration option and test macro were undocumented.

Close #3876.
---
 cpukit/include/rtems/confdefs.h   | 19 ---
 cpukit/include/rtems/config.h | 13 -
 cpukit/include/rtems/score/smp.h  | 13 -
 testsuites/ada/support/initimpl.h |  2 --
 testsuites/libtests/block08/system.h  |  2 --
 testsuites/libtests/cpuuse/system.h   |  2 --
 testsuites/libtests/rtmonuse/system.h |  1 -
 testsuites/libtests/termios05/init.c  |  2 --
 testsuites/smptests/smpunsupported01/init.c   |  2 --
 testsuites/sptests/sp01/system.h  |  2 --
 testsuites/sptests/sp04/system.h  |  2 --
 testsuites/sptests/sp07/system.h  |  2 --
 testsuites/sptests/sp08/init.c|  2 --
 testsuites/sptests/sp12/system.h  |  2 --
 testsuites/sptests/sp13/system.h  |  2 --
 testsuites/sptests/sp14/system.h  |  2 --
 testsuites/sptests/sp16/system.h  |  2 --
 testsuites/sptests/sp20/system.h  |  2 --
 testsuites/sptests/sp37/system.h  |  2 --
 testsuites/sptests/sp65/sp65impl.h|  2 --
 testsuites/sptests/spcbssched01/system.h  |  2 --
 testsuites/sptests/spcbssched02/system.h  |  2 --
 testsuites/sptests/spcbssched03/system.h  |  2 --
 testsuites/sptests/spedfsched01/system.h  |  2 --
 testsuites/sptests/spedfsched02/system.h  |  2 --
 testsuites/sptests/spedfsched03/system.h  |  2 --
 testsuites/sptests/spfatal29/init.c   |  2 --
 testsuites/sptests/spfifo03/init.c|  2 --
 testsuites/sptests/spfifo05/init.c|  2 --
 .../sptests/spintrcritical06/spintrcritical06impl.h   |  2 --
 testsuites/sptests/spintrcritical15/init.c|  2 --
 testsuites/sptests/spmrsp01/init.c|  2 --
 testsuites/sptests/spsimplesched02/init.c |  2 --
 testsuites/tmtests/tm04/system.h  |  2 --
 testsuites/tmtests/tm08/system.h  |  2 --
 testsuites/tmtests/tm15/system.h  |  2 --
 testsuites/tmtests/tm20/system.h  |  2 --
 testsuites/tmtests/tm22/system.h  |  2 --
 testsuites/tmtests/tm24/system.h  |  2 --
 39 files changed, 116 deletions(-)

diff --git a/cpukit/include/rtems/confdefs.h b/cpukit/include/rtems/confdefs.h
index eb837fd389..d45287591e 100644
--- a/cpukit/include/rtems/confdefs.h
+++ b/cpukit/include/rtems/confdefs.h
@@ -159,18 +159,6 @@ extern "C" {
   #define _CONFIGURE_MAXIMUM_PROCESSORS 1
 #endif
 
-/*
- * An internal define to indicate that this is an SMP application
- * configuration.
- */
-#ifdef RTEMS_SMP
-  #if !defined(CONFIGURE_DISABLE_SMP_CONFIGURATION)
-#define _CONFIGURE_SMP_APPLICATION
-  #elif _CONFIGURE_MAXIMUM_PROCESSORS > 1
-#error "CONFIGURE_DISABLE_SMP_CONFIGURATION and 
CONFIGURE_MAXIMUM_PROCESSORS > 1 makes no sense"
-  #endif
-#endif
-
 /*
  * This sets up the resources for the FIFOs/pipes.
  */
@@ -2576,13 +2564,6 @@ struct _reent *__getreent(void)
   #endif
 
   #ifdef RTEMS_SMP
-const bool _SMP_Is_enabled =
-  #ifdef _CONFIGURE_SMP_APPLICATION
-true;
-  #else
-false;
-  #endif
-
 const uint32_t _SMP_Processor_configured_maximum =
   _CONFIGURE_MAXIMUM_PROCESSORS;
   #endif
diff --git a/cpukit/include/rtems/config.h b/cpukit/include/rtems/config.h
index 4811d0e704..e82c7abf11 100644
--- a/cpukit/include/rtems/config.h
+++ b/cpukit/include/rtems/config.h
@@ -150,19 +150,6 @@ uint32_t rtems_configuration_get_maximum_extensions( void 
);
 NULL
 #endif
 
-/**
- * @brief Returns true if the SMP mode of operation is enabled, and false
- * otherwise.
- *
- * In uni-processor configurations this is a compile-time constant which
- * evaluates to false.
- *
- * @retval true SMP mode of operation is enabled.
- * @retval false Otherwise.
- */
-#define rtems_configuration_is_smp_enabled() \
-  (_SMP_Is_enabled)
-
 /**
  * @brief Returns the configured maximum count of processors.
  *
diff --git a/cpukit/include/rtems/score/smp.h b/cpukit/include/rtems/score/smp.h
index 36cfd981ab..2722fbdcee 100644
--- a/cpukit/include/rtems/score/smp.h
+++ b/cpukit/include/rtems/score/smp.h
@@ -36,19 +36,6 @@ extern "C" {
  * @{
  */
 
-/**
- * @brief Indicates if SMP is enabled.
- *
- * In SMP configurations, this constant is defined 

[PATCH 1/6] score: Add _SMP_Need_inter_processor_interrupts()

2020-02-15 Thread Sebastian Huber
Test for the proper system condition instead of using the
rtems_configuration_is_smp_enabled() workaround.

Update #3876.
---
 cpukit/include/rtems/score/smpimpl.h | 15 +++
 cpukit/rtems/src/taskmode.c  |  3 ++-
 cpukit/score/src/threaddispatch.c|  2 +-
 cpukit/score/src/threadinitialize.c  |  2 +-
 4 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/cpukit/include/rtems/score/smpimpl.h 
b/cpukit/include/rtems/score/smpimpl.h
index 889ef5be58..dbca09d5cb 100644
--- a/cpukit/include/rtems/score/smpimpl.h
+++ b/cpukit/include/rtems/score/smpimpl.h
@@ -324,6 +324,21 @@ RTEMS_INLINE_ROUTINE const Processor_mask 
*_SMP_Get_online_processors( void )
 #endif
 }
 
+/**
+ * @brief Indicate if inter-processor interrupts are needed.
+ *
+ * @return True if inter-processor interrupts are needed for the correct system
+ * operation, otherwise false.
+ */
+RTEMS_INLINE_ROUTINE const bool _SMP_Need_inter_processor_interrupts( void )
+{
+  /*
+   * Use the configured processor maximum instead of the actual to allow
+   * testing on uni-processor systems.
+   */
+  return _SMP_Processor_configured_maximum > 1;
+}
+
 /** @} */
 
 #ifdef __cplusplus
diff --git a/cpukit/rtems/src/taskmode.c b/cpukit/rtems/src/taskmode.c
index 906f86bdcd..8830f6bb5d 100644
--- a/cpukit/rtems/src/taskmode.c
+++ b/cpukit/rtems/src/taskmode.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -58,7 +59,7 @@ rtems_status_code rtems_task_mode(
 ( mask & RTEMS_INTERRUPT_MASK ) != 0
   && _Modes_Get_interrupt_level( mode_set ) != 0
 #if CPU_ENABLE_ROBUST_THREAD_DISPATCH == FALSE
-  && rtems_configuration_is_smp_enabled()
+  && _SMP_Need_inter_processor_interrupts()
 #endif
   ) {
 return RTEMS_NOT_IMPLEMENTED;
diff --git a/cpukit/score/src/threaddispatch.c 
b/cpukit/score/src/threaddispatch.c
index 65951cccfe..cd32f5a1d2 100644
--- a/cpukit/score/src/threaddispatch.c
+++ b/cpukit/score/src/threaddispatch.c
@@ -265,7 +265,7 @@ void _Thread_Do_dispatch( Per_CPU_Control *cpu_self, 
ISR_Level level )
   if (
 !_ISR_Is_enabled( level )
 #if defined(RTEMS_SMP) && CPU_ENABLE_ROBUST_THREAD_DISPATCH == FALSE
-  && rtems_configuration_is_smp_enabled()
+  && _SMP_Need_inter_processor_interrupts()
 #endif
   ) {
 _Internal_error( INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT );
diff --git a/cpukit/score/src/threadinitialize.c 
b/cpukit/score/src/threadinitialize.c
index 4dc6d51d72..976c97701a 100644
--- a/cpukit/score/src/threadinitialize.c
+++ b/cpukit/score/src/threadinitialize.c
@@ -72,7 +72,7 @@ bool _Thread_Initialize(
   if (
 config->isr_level != 0
 #if CPU_ENABLE_ROBUST_THREAD_DISPATCH == FALSE
-  && rtems_configuration_is_smp_enabled()
+  && _SMP_Need_inter_processor_interrupts()
 #endif
   ) {
 goto failed;
-- 
2.16.4

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


[PATCH 3/6] config: CONFIGURE_INIT_TASK_INITIAL_MODES

2020-02-15 Thread Sebastian Huber
Determine the default for CONFIGURE_INIT_TASK_INITIAL_MODES depeding on
whether RTEMS_SMP is defined or not.

In the tests, use CONFIGURE_INIT_TASK_INITIAL_MODES to explicitly
request RTEMS_NO_PREEMPT mode if necessary.

Update #3876.
---
 cpukit/include/rtems/confdefs.h   | 2 +-
 testsuites/sptests/sp66/init.c| 1 +
 testsuites/sptests/spsimplesched02/init.c | 2 ++
 3 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/cpukit/include/rtems/confdefs.h b/cpukit/include/rtems/confdefs.h
index bbbaa9d6d1..eb837fd389 100644
--- a/cpukit/include/rtems/confdefs.h
+++ b/cpukit/include/rtems/confdefs.h
@@ -1304,7 +1304,7 @@ const Thread_Idle_body _Thread_Idle_body = 
CONFIGURE_IDLE_TASK_BODY;
  * used to specify the initial execution mode of the single Classic API task.
  */
 #ifndef CONFIGURE_INIT_TASK_INITIAL_MODES
-  #ifdef _CONFIGURE_SMP_APPLICATION
+  #ifdef RTEMS_SMP
 #define CONFIGURE_INIT_TASK_INITIAL_MODES RTEMS_DEFAULT_MODES
   #else
 #define CONFIGURE_INIT_TASK_INITIAL_MODES RTEMS_NO_PREEMPT
diff --git a/testsuites/sptests/sp66/init.c b/testsuites/sptests/sp66/init.c
index f2bf46d049..3dd8e75a32 100644
--- a/testsuites/sptests/sp66/init.c
+++ b/testsuites/sptests/sp66/init.c
@@ -1,2 +1,3 @@
 #define INHERIT_CEILING
+#define CONFIGURE_INIT_TASK_INITIAL_MODES RTEMS_NO_PREEMPT
 #include "../sp65/sp65impl.h"
diff --git a/testsuites/sptests/spsimplesched02/init.c 
b/testsuites/sptests/spsimplesched02/init.c
index b7b1a21919..4a08a6c8ac 100644
--- a/testsuites/sptests/spsimplesched02/init.c
+++ b/testsuites/sptests/spsimplesched02/init.c
@@ -154,6 +154,8 @@ rtems_task Init(
 #define CONFIGURE_RTEMS_INIT_TASKS_TABLE
 
 #define CONFIGURE_EXTRA_TASK_STACKS (3 * RTEMS_MINIMUM_STACK_SIZE)
+
+#define CONFIGURE_INIT_TASK_INITIAL_MODES   RTEMS_NO_PREEMPT
 #define CONFIGURE_INIT_TASK_PRIORITY4
 
 #define CONFIGURE_DISABLE_SMP_CONFIGURATION
-- 
2.16.4

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


[PATCH 2/6] bsps/clock: Use _SMP_Get_processor_maximum()

2020-02-15 Thread Sebastian Huber
Use a specific test to enable the fast idle mode instead of using the
rtems_configuration_is_smp_enabled() workaround.

Update #3876.
---
 bsps/shared/dev/clock/clockimpl.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bsps/shared/dev/clock/clockimpl.h 
b/bsps/shared/dev/clock/clockimpl.h
index 163b498a18..3c08c80859 100644
--- a/bsps/shared/dev/clock/clockimpl.h
+++ b/bsps/shared/dev/clock/clockimpl.h
@@ -150,7 +150,7 @@ rtems_isr Clock_isr(
 
   Clock_driver_timecounter_tick();
 
-  if (!rtems_configuration_is_smp_enabled()) {
+  if (_SMP_Get_processor_maximum() == 1) {
 while (
   _Thread_Heir == _Thread_Executing && _Thread_Executing->is_idle
 ) {
-- 
2.16.4

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


[PATCH 0/6] Remove CONFIGURE_DISABLE_SMP_CONFIGURATION

2020-02-15 Thread Sebastian Huber
The CONFIGURE_DISABLE_SMP_CONFIGURATION configuration option and
rtems_configuration_is_smp_enabled() were added during the SMP support
development cycle as a workaround to fix some testsuite failures in SMP
configurations.  Replace all use cases with tests for specific
conditions.  The configuration option and test macro were undocumented.

Sebastian Huber (6):
  score: Add _SMP_Need_inter_processor_interrupts()
  bsps/clock: Use _SMP_Get_processor_maximum()
  config: CONFIGURE_INIT_TASK_INITIAL_MODES
  score: _Scheduler_Is_non_preempt_mode_supported()
  rtems: Change timer server task mode setting
  config: Remove CONFIGURE_DISABLE_SMP_CONFIGURATION

 bsps/shared/dev/clock/clockimpl.h   |  2 +-
 cpukit/include/rtems/confdefs.h | 21 +
 cpukit/include/rtems/config.h   | 13 -
 cpukit/include/rtems/scheduler.h| 16 
 cpukit/include/rtems/score/scheduler.h  |  8 
 cpukit/include/rtems/score/schedulerimpl.h  | 18 ++
 cpukit/include/rtems/score/smp.h| 13 -
 cpukit/include/rtems/score/smpimpl.h| 15 +++
 cpukit/rtems/src/taskmode.c | 12 
 cpukit/rtems/src/timerserver.c  | 12 +++-
 cpukit/score/src/threaddispatch.c   |  2 +-
 cpukit/score/src/threadinitialize.c |  7 +--
 testsuites/ada/support/initimpl.h   |  2 --
 testsuites/libtests/block08/system.h|  2 --
 testsuites/libtests/cpuuse/system.h |  2 --
 testsuites/libtests/rtmonuse/system.h   |  1 -
 testsuites/libtests/termios05/init.c|  2 --
 testsuites/smptests/smpunsupported01/init.c |  2 --
 testsuites/sptests/sp01/system.h|  2 --
 testsuites/sptests/sp04/system.h|  2 --
 testsuites/sptests/sp07/system.h|  2 --
 testsuites/sptests/sp08/init.c  |  2 --
 testsuites/sptests/sp12/system.h|  2 --
 testsuites/sptests/sp13/system.h|  2 --
 testsuites/sptests/sp14/system.h|  2 --
 testsuites/sptests/sp16/system.h|  2 --
 testsuites/sptests/sp20/system.h|  2 --
 testsuites/sptests/sp37/system.h|  2 --
 testsuites/sptests/sp65/sp65impl.h  |  2 --
 testsuites/sptests/sp66/init.c  |  1 +
 testsuites/sptests/spcbssched01/system.h|  2 --
 testsuites/sptests/spcbssched02/system.h|  2 --
 testsuites/sptests/spcbssched03/system.h|  2 --
 testsuites/sptests/spedfsched01/system.h|  2 --
 testsuites/sptests/spedfsched02/system.h|  2 --
 testsuites/sptests/spedfsched03/system.h|  2 --
 testsuites/sptests/spfatal29/init.c |  2 --
 testsuites/sptests/spfifo03/init.c  |  2 --
 testsuites/sptests/spfifo05/init.c  |  2 --
 .../sptests/spintrcritical06/spintrcritical06impl.h |  2 --
 testsuites/sptests/spintrcritical15/init.c  |  2 --
 testsuites/sptests/spmrsp01/init.c  |  2 --
 testsuites/sptests/spsimplesched02/init.c   |  4 ++--
 testsuites/tmtests/tm04/system.h|  2 --
 testsuites/tmtests/tm08/system.h|  2 --
 testsuites/tmtests/tm15/system.h|  2 --
 testsuites/tmtests/tm20/system.h|  2 --
 testsuites/tmtests/tm22/system.h|  2 --
 testsuites/tmtests/tm24/system.h|  2 --
 49 files changed, 83 insertions(+), 130 deletions(-)

-- 
2.16.4

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


[PATCH 4/6] score: _Scheduler_Is_non_preempt_mode_supported()

2020-02-15 Thread Sebastian Huber
If the non-preempt mode for threads is supported depends on the
scheduler implementation.  Add
_Scheduler_Is_non_preempt_mode_supported() to indicate this.

Update #3876.
---
 cpukit/include/rtems/scheduler.h   | 16 
 cpukit/include/rtems/score/scheduler.h |  8 
 cpukit/include/rtems/score/schedulerimpl.h | 18 ++
 cpukit/rtems/src/taskmode.c|  9 ++---
 cpukit/score/src/threadinitialize.c|  5 -
 5 files changed, 52 insertions(+), 4 deletions(-)

diff --git a/cpukit/include/rtems/scheduler.h b/cpukit/include/rtems/scheduler.h
index dbc161a69d..955a83cfb4 100644
--- a/cpukit/include/rtems/scheduler.h
+++ b/cpukit/include/rtems/scheduler.h
@@ -26,6 +26,13 @@
 #define SCHEDULER_CONTEXT_NAME( name ) \
   _Configuration_Scheduler_ ## name
 
+#if defined(RTEMS_SMP)
+  #define SCHEDULER_CONTROL_IS_NON_PREEMPT_MODE_SUPPORTED( value ) \
+, value
+#else
+  #define SCHEDULER_CONTROL_IS_NON_PREEMPT_MODE_SUPPORTED( value )
+#endif
+
 #if defined(RTEMS_SMP)
   /* This object doesn't exist and indicates a configuration error */
   extern const Scheduler_Control RTEMS_SCHEDULER_INVALID_INDEX;
@@ -72,6 +79,7 @@
   SCHEDULER_CBS_ENTRY_POINTS, \
   SCHEDULER_CBS_MAXIMUM_PRIORITY, \
   ( obj_name ) \
+  SCHEDULER_CONTROL_IS_NON_PREEMPT_MODE_SUPPORTED( true ) \
 }
 
   /* Provided for backward compatibility */
@@ -98,6 +106,7 @@
   SCHEDULER_EDF_ENTRY_POINTS, \
   SCHEDULER_EDF_MAXIMUM_PRIORITY, \
   ( obj_name ) \
+  SCHEDULER_CONTROL_IS_NON_PREEMPT_MODE_SUPPORTED( true ) \
 }
 
   /* Provided for backward compatibility */
@@ -131,6 +140,7 @@
   SCHEDULER_EDF_SMP_ENTRY_POINTS, \
   SCHEDULER_EDF_MAXIMUM_PRIORITY, \
   ( obj_name ) \
+  SCHEDULER_CONTROL_IS_NON_PREEMPT_MODE_SUPPORTED( false ) \
 }
 
   /* Provided for backward compatibility */
@@ -162,6 +172,7 @@
 SCHEDULER_PRIORITY_CONTEXT_NAME( name ).Ready \
   ) - 1, \
   ( obj_name ) \
+  SCHEDULER_CONTROL_IS_NON_PREEMPT_MODE_SUPPORTED( true ) \
 }
 
   /* Provided for backward compatibility */
@@ -193,6 +204,7 @@
 SCHEDULER_PRIORITY_AFFINITY_SMP_CONTEXT_NAME( name ).Ready \
   ) - 1, \
   ( obj_name ) \
+  SCHEDULER_CONTROL_IS_NON_PREEMPT_MODE_SUPPORTED( false ) \
 }
 
   /* Provided for backward compatibility */
@@ -224,6 +236,7 @@
 SCHEDULER_PRIORITY_SMP_CONTEXT_NAME( name ).Ready \
   ) - 1, \
   ( obj_name ) \
+  SCHEDULER_CONTROL_IS_NON_PREEMPT_MODE_SUPPORTED( false ) \
 }
 
   /* Provided for backward compatibility */
@@ -255,6 +268,7 @@
 SCHEDULER_STRONG_APA_CONTEXT_NAME( name ).Ready \
   ) - 1, \
   ( obj_name ) \
+  SCHEDULER_CONTROL_IS_NON_PREEMPT_MODE_SUPPORTED( false ) \
 }
 
   /* Provided for backward compatibility */
@@ -282,6 +296,7 @@
   SCHEDULER_SIMPLE_ENTRY_POINTS, \
   SCHEDULER_SIMPLE_MAXIMUM_PRIORITY, \
   ( obj_name ) \
+  SCHEDULER_CONTROL_IS_NON_PREEMPT_MODE_SUPPORTED( true ) \
 }
 
   /* Provided for backward compatibility */
@@ -309,6 +324,7 @@
   SCHEDULER_SIMPLE_SMP_ENTRY_POINTS, \
   SCHEDULER_SIMPLE_SMP_MAXIMUM_PRIORITY, \
   ( obj_name ) \
+  SCHEDULER_CONTROL_IS_NON_PREEMPT_MODE_SUPPORTED( false ) \
 }
 
   /* Provided for backward compatibility */
diff --git a/cpukit/include/rtems/score/scheduler.h 
b/cpukit/include/rtems/score/scheduler.h
index 15effd462c..9a6515ba1e 100644
--- a/cpukit/include/rtems/score/scheduler.h
+++ b/cpukit/include/rtems/score/scheduler.h
@@ -289,6 +289,14 @@ struct _Scheduler_Control {
* @brief The scheduler name.
*/
   uint32_t name;
+
+#if defined(RTEMS_SMP)
+  /**
+   * @brief True if the non-preempt mode for threads is supported by the
+   * scheduler, otherwise false.
+   */
+  bool is_non_preempt_mode_supported;
+#endif
 };
 
 /**
diff --git a/cpukit/include/rtems/score/schedulerimpl.h 
b/cpukit/include/rtems/score/schedulerimpl.h
index dcc81fcbbf..e7fbb8b166 100644
--- a/cpukit/include/rtems/score/schedulerimpl.h
+++ b/cpukit/include/rtems/score/schedulerimpl.h
@@ -129,6 +129,24 @@ RTEMS_INLINE_ROUTINE void _Scheduler_Release_critical(
 #endif
 }
 
+#if defined(RTEMS_SMP)
+/**
+ * @brief Indicate if the thread non-preempt mode is supported by the
+ * scheduler.
+ *
+ * @param scheduler The scheduler instance.
+ *
+ * @return True if the non-preempt mode for threads is supported by the
+ *   scheduler, otherwise false.
+ */
+RTEMS_INLINE_ROUTINE bool _Scheduler_Is_non_preempt_mode_supported(
+  const Scheduler_Control *scheduler
+)
+{
+  return scheduler->is_non_preempt_mode_supported;
+}
+#endif
+
 #if defined(RTEMS_SMP)
 void _Scheduler_Request_ask_for_help( Thread_Control *the_thread );
 
diff --git a/cpukit/rtems/src/taskmode.c b/cpukit/rtems/src/taskmode.c
index 8830f6bb5d..3ba5ce7f95 100644
--- a/cpukit/rtems/src/taskmode.c
+++ b/cpukit/rtems/src/taskmode.c
@@ -41,6 +41,8 @@ rtems_status_code rtems_task_mode(
   

[PATCH 5/6] rtems: Change timer server task mode setting

2020-02-15 Thread Sebastian Huber
Use the non-preempt mode only in uni-processor configurations.

Update #3876.
---
 cpukit/rtems/src/timerserver.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/cpukit/rtems/src/timerserver.c b/cpukit/rtems/src/timerserver.c
index 2ebceca1ba..1a332b89ec 100644
--- a/cpukit/rtems/src/timerserver.c
+++ b/cpukit/rtems/src/timerserver.c
@@ -181,11 +181,13 @@ static rtems_status_code _Timer_server_Initiate(
 rtems_build_name('T','I','M','E'),
 priority,
 stack_size,
-rtems_configuration_is_smp_enabled() ?
-  RTEMS_DEFAULT_MODES : /* no preempt is not supported for SMP */
-  RTEMS_NO_PREEMPT,   /* no preempt is like an interrupt */
-  /* user may want floating point but we need */
-  /*   system task specified for 0 priority */
+#ifdef RTEMS_SMP
+RTEMS_DEFAULT_MODES, /* no preempt is not recommended for SMP */
+#else
+RTEMS_NO_PREEMPT,/* no preempt is like an interrupt */
+#endif
+/* user may want floating point but we need */
+/*   system task specified for 0 priority */
 attribute_set | RTEMS_SYSTEM_TASK,
 
   );
-- 
2.16.4

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


Re: Ticket #1977

2020-02-15 Thread Eshan Dhawan
Also, I wanted to know if there were test suites to check it?

On Sat, Feb 15, 2020 at 5:48 PM Eshan Dhawan 
wrote:

> Hi,
> As I was going through the ticket I wanted to know the main arguments that
> are to be passed in mode and how they are to be processed in the mq_open.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Ticket #1977

2020-02-15 Thread Eshan Dhawan
Hi,
As I was going through the ticket I wanted to know the main arguments that
are to be passed in mode and how they are to be processed in the mq_open.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 18/18] config: Add

2020-02-15 Thread Sebastian Huber

On 15/02/2020 05:22, Gedare Bloom wrote:


This makes sense. Is there any reason for the ordering?

It should be alphabetically sorted.


If possible, I think grouping by obsoleted version or alphabetical 
ordering would be a good idea.


Maybe I should add a comment like this to the top of the list:

/*
 * Please keep the list of obsolete configuration options 
alphabetically sorted.

 *
 * Use #warning for renamed options and define the new option accordingly.
 *
 * Use #warning for obsolete options which are now superfluous, e.g. 
because

 * the objects are now self-contained.
 *
 * Use #error for options which require now a different configuration 
approach,

 * e.g. options for an own configuration table.
 */

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