Re: How do we know what priority of the Init task is?

[Sebastian Huber]

On 23/02/2021 08:36, Heinz Junkes wrote:


I would have a similar question ;-)

What is the priority of the POSIX_Init - Task (as Posix-Prio)?
There is no option to configure the priority of the POSIX initialization 
thread, so the default priority of 2 is used, see 
_POSIX_Threads_Default_attributes.


--
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 v4 1/2] bsps/beagle: Adding QEP driver support to BeagleBoneBlack BSP

[James Fitzsimons]

---
 bsps/arm/beagle/headers.am  |   2 +
 bsps/arm/beagle/include/bsp/bbb-pwm.h   |  11 -
 bsps/arm/beagle/include/bsp/pwmss.h |  54 +++
 bsps/arm/beagle/include/bsp/qep.h   | 382 
 bsps/arm/beagle/pwm/pwm.c   |  60 +---
 bsps/arm/beagle/pwmss/pwmss.c   |  64 
 bsps/arm/beagle/qep/qep.c   | 445 
 c/src/lib/libbsp/arm/beagle/Makefile.am |   6 +
 spec/build/bsps/arm/beagle/obj.yml  |   5 +-
 9 files changed, 959 insertions(+), 70 deletions(-)
 create mode 100644 bsps/arm/beagle/include/bsp/pwmss.h
 create mode 100644 bsps/arm/beagle/include/bsp/qep.h
 create mode 100644 bsps/arm/beagle/pwmss/pwmss.c
 create mode 100644 bsps/arm/beagle/qep/qep.c

diff --git a/bsps/arm/beagle/headers.am b/bsps/arm/beagle/headers.am
index 4dc35f2e2a..e4a746b2e1 100644
--- a/bsps/arm/beagle/headers.am
+++ b/bsps/arm/beagle/headers.am
@@ -13,3 +13,5 @@ include_bsp_HEADERS += 
../../../../../../bsps/arm/beagle/include/bsp/beagleboneb
 include_bsp_HEADERS += ../../../../../../bsps/arm/beagle/include/bsp/i2c.h
 include_bsp_HEADERS += ../../../../../../bsps/arm/beagle/include/bsp/irq.h
 include_bsp_HEADERS += ../../../../../../bsps/arm/beagle/include/bsp/spi.h
+include_bsp_HEADERS += ../../../../../../bsps/arm/beagle/include/bsp/qep.h
+include_bsp_HEADERS += ../../../../../../bsps/arm/beagle/include/bsp/pwmss.h
diff --git a/bsps/arm/beagle/include/bsp/bbb-pwm.h 
b/bsps/arm/beagle/include/bsp/bbb-pwm.h
index cf5d6fe552..6fdba486be 100644
--- a/bsps/arm/beagle/include/bsp/bbb-pwm.h
+++ b/bsps/arm/beagle/include/bsp/bbb-pwm.h
@@ -31,17 +31,6 @@ extern "C" {
 #define BBB_CONTROL_CONF_GPMC_AD(n)   (0x800 + (n * 4))
 #define BBB_CONTROL_CONF_LCD_DATA(n)   (0x8a0 + (n * 4))
 
-/**
- * @brief The set of possible PWM subsystem module
- *
- * Enumerated type to define various instance of pwm module.
- */
-typedef enum{
-  BBB_PWMSS0 = 0,
-  BBB_PWMSS1,
-  BBB_PWMSS2,
-  BBB_PWMSS_COUNT
-}BBB_PWMSS;
 
 typedef enum{
   BBB_P8_13_2B = 3,
diff --git a/bsps/arm/beagle/include/bsp/pwmss.h 
b/bsps/arm/beagle/include/bsp/pwmss.h
new file mode 100644
index 00..3a9dcbb70a
--- /dev/null
+++ b/bsps/arm/beagle/include/bsp/pwmss.h
@@ -0,0 +1,54 @@
+/**
+ * @file
+ *
+ * @ingroup arm_beagle
+ *
+ * @brief Shared PWMSS module functions used by PWM, eQEP and eCAP (when 
added).
+ */
+
+/**
+ * Copyright (c) 2020 James Fitzsimons 
+ *
+ * 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.
+ *.
+ */
+
+#ifndef LIBBSP_ARM_BEAGLE_PWMSS_H
+#define LIBBSP_ARM_BEAGLE_PWMSS_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
+/* The following definitions are bitmasks for the clk control registers for
+ * the PWMSS module clocks. All three modules have the same clock control
+ * hence the EPMSSx to signify these values are consistent across all
+ * EPWMSS instances. */
+#define AM335X_CM_PER_EPWMSSx_CLKCTRL_MODULEMODE_ENABLE   (0x2u)
+#define AM335X_CM_PER_EPWMSSx_CLKCTRL_MODULEMODE   (0x0003u)
+#define AM335X_CM_PER_EPWMSSx_CLKCTRL_IDLEST_FUNC  (0x0u)
+#define AM335X_CM_PER_EPWMSSx_CLKCTRL_IDLEST_SHIFT (0x0010u)
+#define AM335X_CM_PER_EPWMSSx_CLKCTRL_IDLEST   (0x0003u)
+
+/**
+ * @brief The set of possible PWM subsystem module
+ *
+ * Enumerated type to define various instance of pwm module.
+ */
+typedef enum {
+  BBB_PWMSS0 = 0,
+  BBB_PWMSS1,
+  BBB_PWMSS2,
+  BBB_PWMSS_COUNT
+} BBB_PWMSS;
+
+
+rtems_status_code pwmss_module_clk_config(BBB_PWMSS pwmss_id);
+
+#ifdef __cplusplus
+}
+#endif /* __cplusplus */
+
+#endif /* LIBBSP_ARM_BEAGLE_PWMSS_H */
diff --git a/bsps/arm/beagle/include/bsp/qep.h 
b/bsps/arm/beagle/include/bsp/qep.h
new file mode 100644
index 00..fc086e3c80
--- /dev/null
+++ b/bsps/arm/beagle/include/bsp/qep.h
@@ -0,0 +1,382 @@
+/**
+ * @file
+ *
+ * @ingroup arm_beagle
+ *
+ * @brief eQEP (enhanced Quadrature Encoder Pulse) support API.
+ */
+
+/**
+ * Copyright (c) 2020 James Fitzsimons 
+ *
+ * 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.
+ *
+ * For details of the Enhanced Quadrature Encoder Pulse (eQEP) Module refer to
+ * page 2511 of the TI Technical Reference Manual
+ * (https://www.ti.com/lit/ug/spruh73q/spruh73q.pdf)
+ *
+ * This driver supports using the QEP modules in Quadrature-clock Mode.
+ * Direction-count Mode is not currently supported. Similarly the QEPI: Index
+ * or Zero Marker and QEPS: Strobe Input pins are not currently supported.
+ *
+ * The mode can be any one of:
+ *  - Quadrature-count mode - For encoders that generate pulses 90 degrees
+ *  out of phase for determining direction and speed.
+ *  - Direction-count mode - for position encoders that provide direction and
+ *  clock outputs, instead of quadrature outputs.
+ *  - UP-count mode - The counter direc

[PATCH v4 2/2] bsps/beagle: Updating licences to latest BSD 2 clause

[James Fitzsimons]

---
 bsps/arm/beagle/include/bsp/bbb-pwm.h | 28 +++
 bsps/arm/beagle/include/bsp/pwmss.h   | 30 -
 bsps/arm/beagle/include/bsp/qep.h | 32 ++-
 bsps/arm/beagle/pwm/pwm.c | 27 ++
 bsps/arm/beagle/pwmss/pwmss.c | 29 +++-
 bsps/arm/beagle/qep/qep.c | 29 +++-
 6 files changed, 146 insertions(+), 29 deletions(-)

diff --git a/bsps/arm/beagle/include/bsp/bbb-pwm.h 
b/bsps/arm/beagle/include/bsp/bbb-pwm.h
index 6fdba486be..34f610f86d 100644
--- a/bsps/arm/beagle/include/bsp/bbb-pwm.h
+++ b/bsps/arm/beagle/include/bsp/bbb-pwm.h
@@ -6,14 +6,34 @@
  * @brief BeagleBone Black PWM support definitions.
  */
 
-/**
+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
  * Copyright (c) 2016 Punit Vara 
  *
- * 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.
  */
 
+
 /** Some constants are taken from 
  * 
https://github.com/VegetableAvenger/BBBIOlib/blob/master/BBBio_lib/BBBiolib_PWMSS.h
  */
diff --git a/bsps/arm/beagle/include/bsp/pwmss.h 
b/bsps/arm/beagle/include/bsp/pwmss.h
index 3a9dcbb70a..c1449ec600 100644
--- a/bsps/arm/beagle/include/bsp/pwmss.h
+++ b/bsps/arm/beagle/include/bsp/pwmss.h
@@ -6,13 +6,31 @@
  * @brief Shared PWMSS module functions used by PWM, eQEP and eCAP (when 
added).
  */
 
-/**
- * Copyright (c) 2020 James Fitzsimons 
+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (c) 2020, 2021 James Fitzsimons 
+ *
+ * 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.
  *
- * 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.
- *.
+ * 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 LIBBSP_ARM_BEAGLE_PWMSS_H
diff --git a/bsps/arm/beagle/include/bsp/qep.h 
b/bsps/arm/beagle/include/bsp/qep.h
index fc086e3c80..736224503e 100644
--- a/bsps/arm/beagle/include/bsp/qep.h
+++ b/bsps/arm/beagle/include/bsp/qep.h
@@ -6,12 +6,34 @@
  * @brief eQEP (enhanced Quadrature Encoder Pulse) support API.
  */
 
-/**
- * Copyright (c) 2020 James Fitzsimons 
+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (c) 2020, 2021 James Fitzsimons 
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are

Re: [PATCH v3 0/1] Resubmission of patch previously submitted Sept 2020

[James Fitzsimons]

Hi Chris,

I've just submitted v4 with those licences updated. I hope I've done it
correctly.

Cheers,
James

On Tue, 23 Feb 2021 at 10:23, Chris Johns  wrote:

> Hi James,
>
> Thanks for the patch. It is close. Could I ask if all the source files
> from you
> please be updated to the latest template with the 2-clause BSD license? It
> will
> say us having to include them in the sweep when we get to that task. I see
> a mix
> in the files provided.
>
> Thanks
> Chris
>
> On 21/2/21 8:29 pm, James Fitzsimons wrote:
> > This patch adds driver support for the eQEP (enhanced Quadrature Encoder
> Pulse)
> > module within each of the PWMSS units in the AM335x. The eQEP module is
> used for
> > hardware decoding of rotrary encoders, motor encoders etc.
> >
> > Because the PWMSS module includes several components some of the
> existing code in
> > the pwm driver could be reused. To make this common I have added a
> pwmss.h header
> > and moved some of the pwmss specific defines and enum to this file. The
> pwmss.c
> > file contains a refactored (simplified) version of the clock
> configuration
> > method that was previously in the pwm.c file. The
> pwmss_module_clk_config will
> > now be shared by both the pwm and eqep drivers (and eventually the ecap
> driver if
> > that is ever added).
> >
> > The approach taken with the qep.h header was to move some of the qep
> specific
> > defines from the am335x.h header to this file. They are specific to the
> qep
> > function and would likely never be referenced by anything other than
> this driver.
> > Doing this keeps these definitions with the driver code and reduces
> clutter in
> > am335x.h header.
> >
> > The driver supports two primary modes of operation. A polled mode (which
> is the
> > default mode), and an interrupt event driven mode.
> >
> > This patch includes the following revisions after feedback from Chris
> Johns:
> >  - improved documentation
> >  - addition of void* user argument to interrupt callback
> >  - addition of position value arg to interrupt callback
> >
> > James Fitzsimons (1):
> >   Adding QEP driver support to BeagleBoneBlack BSP
> >
> >  bsps/arm/beagle/headers.am  |   2 +
> >  bsps/arm/beagle/include/bsp/bbb-pwm.h   |  11 -
> >  bsps/arm/beagle/include/bsp/pwmss.h |  54 +++
> >  bsps/arm/beagle/include/bsp/qep.h   | 382 
> >  bsps/arm/beagle/pwm/pwm.c   |  60 +---
> >  bsps/arm/beagle/pwmss/pwmss.c   |  64 
> >  bsps/arm/beagle/qep/qep.c   | 445 
> >  c/src/lib/libbsp/arm/beagle/Makefile.am |   6 +
> >  spec/build/bsps/arm/beagle/obj.yml  |   5 +-
> >  9 files changed, 959 insertions(+), 70 deletions(-)
> >  create mode 100644 bsps/arm/beagle/include/bsp/pwmss.h
> >  create mode 100644 bsps/arm/beagle/include/bsp/qep.h
> >  create mode 100644 bsps/arm/beagle/pwmss/pwmss.c
> >  create mode 100644 bsps/arm/beagle/qep/qep.c
> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Device Drivers Which Include mkdir("/dev")

[Daniel Hellstrom]

Hi,

I think the main reason why the mkdir() is called in the first place, 
from for example rasta-io driver, is that once other drivers register 
their device pciN.devM into the /dev/pciboardN/devM it would fail if the 
the directory /dev/pciboardN has not been created. So it is an attempt 
to avoid mkdir() in all IO drivers and move themkdir() dependency up to 
the pciboardN driver instead. An alternative approach could be that 
rtems_io_register_name("/dev/pciboardN/devM") would actually make sure 
that /dev/pciboardN directory is created if does not exist? or by 
introducing a new supporting function rtems_io_register_name_dircreat()? 
However, I suppose that would mean we would drag in mkdir() routines in 
all cases even when the IO drivers are only registering devices directly 
under /dev/ which is the most common case.


Daniel

  


On 2021-02-20 20:31, Chris Johns wrote:

On 21/2/21 5:29 am, Gedare Bloom wrote:

On Fri, Feb 19, 2021 at 5:26 PM Joel Sherrill  wrote:

On Fri, Feb 19, 2021, 5:32 PM Chris Johns  wrote:

On 20/2/21 7:56 am, Joel Sherrill wrote:

On Fri, Feb 19, 2021 at 2:51 PM Gedare Bloom mailto:ged...@rtems.org>> wrote:

 I think the suggestion is to provide a catch-all rather than try to add new
 faults for every possible condition. This mkdir is a pretty esoteric fault
 that is unlikely to happen in properly developed code.

Then why shouldn't this just be a debug _Assert and value not check 
deliberately?

Will the call ever fail in production? Could a user configure RTEMS in a manner
that generates the failure?


Isn't an assert something that should not happen in a properly designed BSP. In
this case, it would be the sysinit magic that would be utterly broken.

I would not step out as far as utterly broken but yes I see your point. There
are other places where we have taken this approach.

If the lack of making a directory in GRLIB is handled by errors in the other
dependent calls then why not add some documentation to the BSP.

Confirmation appreciated but it is making the directory to out a device node. 
The device node create will fail if there isn't a directory so this will return 
an error.

https://git.rtems.org/rtems/tree/bsps/shared/grlib/pci/gr_rasta_io.c#n577

Which means an assert is ok


I think an assert that /dev exists is fine within device drivers that
want to create device nodes on /dev. It's not their responsibility to
create the /dev tree, right?

I agree. It means there is a system level initialisation issue. Maybe a sysint
call that is fatal is added before drivers are initialised?

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: How do we know what priority of the Init task is?

[Heinz Junkes]

what I have just never understood

POSIX  Prio 2 ist LOW Priority
RTEMS Prio 1 is HIGH Priority

Heinz


> On 23. Feb 2021, at 09:17, Sebastian Huber 
>  wrote:
> 
> On 23/02/2021 08:36, Heinz Junkes wrote:
> 
>> I would have a similar question ;-)
>> 
>> What is the priority of the POSIX_Init - Task (as Posix-Prio)?
> There is no option to configure the priority of the POSIX initialization 
> thread, so the default priority of 2 is used, see 
> _POSIX_Threads_Default_attributes.
> 
> -- 
> 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/
> 



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: How do we know what priority of the Init task is?

[Joel Sherrill]

On Tue, Feb 23, 2021 at 4:25 AM Heinz Junkes 
wrote:

> what I have just never understood
>
> POSIX  Prio 2 ist LOW Priority
> RTEMS Prio 1 is HIGH Priority
>

In general, RTOS threading APIs tended to use 1 as a high priority. The
RTEMS
Classic API based on pSOS+, VxWorks, and VRTX32 which preceded all those
all follow 1 is high priority model.

POSIX calls for the opposite range. Not sure why. Interestingly, I had a
discussion
with the main kernel person for another RTOS about this in a standards
meeting
and he noted that although every implementation of POSIX threads we both
knew
about does use low number as low priority, it is not as explicit in the
POSIX standard
as one would think. We have just all read the same text that way since
POSIX is
careful to say raises or lowers priority and the implication we all saw is
that the
numbers follow that languge. But at this point, the priorities run this way
for no
other reason than history and compatibility. For all I know, it may even be
baked
into the POSIX Compliance Test Suite. Any program with hard-coded numbers
certainly has it baked in.

While I am beating this topic mercilessly, let me point out that POSIX only
calls
for a minimum of 32 priority levels. Portable programs cannot assume more.
And the default attribute set for all POSIX threading and synchronization
objects is implementation defined. Portable programs should always
explicitly
set all attributes for pthreads, mutexes, etc.

The RTOS choice probably reflects using a bitmap to represent if a thread
is present on the FIFO for each priority. This would make a bit index map
directly to priority in most cases. This design dates back to at least VMS
where you have 32 priority levels because you could scan 32 bits in a
single instruction. This was carried forward into Windows NT.

THe diversity of choices reminded me of this quote from Andrew Tanenbaum:

"The nice thing about standards is that there are so many of them to choose
from."

In the end different people had an arbitrary decision and picked different
answers. Ada task priority is another set of choices. :)

--joel


> Heinz
>
>
> > On 23. Feb 2021, at 09:17, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> >
> > On 23/02/2021 08:36, Heinz Junkes wrote:
> >
> >> I would have a similar question ;-)
> >>
> >> What is the priority of the POSIX_Init - Task (as Posix-Prio)?
> > There is no option to configure the priority of the POSIX initialization
> thread, so the default priority of 2 is used, see
> _POSIX_Threads_Default_attributes.
> >
> > --
> > 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: Device Drivers Which Include mkdir("/dev")

[Joel Sherrill]

On Tue, Feb 23, 2021 at 2:52 AM Daniel Hellstrom  wrote:

> Hi,
>
> I think the main reason why the mkdir() is called in the first place, from
> for example rasta-io driver, is that once other drivers register their
> device pciN.devM into the /dev/pciboardN/devM it would fail if the the
> directory /dev/pciboardN has not been created. So it is an attempt to avoid
> mkdir() in all IO drivers and move themkdir() dependency up to the
> pciboardN driver instead. An alternative approach could be that
> rtems_io_register_name("/dev/pciboardN/devM") would actually make sure that
> /dev/pciboardN directory is created if does not exist? or by introducing a
> new supporting function rtems_io_register_name_dircreat()? However, I
> suppose that would mean we would drag in mkdir() routines in all cases even
> when the IO drivers are only registering devices directly under /dev/ which
> is the most common case.
>

I don't like adding another method especially since you
would have to parse the device name to find a subdirectory
and that just adds complication. And all that logic ends up in the
minimum BSP footprint for using a device.

I started this discussion wanting a fatal error and now I am happy just
adding _Assert_Unused_variable_equals().  If the directory doesn't end up
getting created, the mknod on the device will fail a few lines down so
there will be a failure.

--joel


> Daniel
>
>On 2021-02-20 20:31, Chris Johns wrote:
>
> On 21/2/21 5:29 am, Gedare Bloom wrote:
>
> On Fri, Feb 19, 2021 at 5:26 PM Joel Sherrill  
>  wrote:
>
> On Fri, Feb 19, 2021, 5:32 PM Chris Johns  
>  wrote:
>
> On 20/2/21 7:56 am, Joel Sherrill wrote:
>
> On Fri, Feb 19, 2021 at 2:51 PM Gedare Bloom 
> mailto:ged...@rtems.org> > wrote:
>
> I think the suggestion is to provide a catch-all rather than try to add 
> new
> faults for every possible condition. This mkdir is a pretty esoteric fault
> that is unlikely to happen in properly developed code.
>
> Then why shouldn't this just be a debug _Assert and value not check 
> deliberately?
>
> Will the call ever fail in production? Could a user configure RTEMS in a 
> manner
> that generates the failure?
>
>
> Isn't an assert something that should not happen in a properly designed BSP. 
> In
> this case, it would be the sysinit magic that would be utterly broken.
>
> I would not step out as far as utterly broken but yes I see your point. There
> are other places where we have taken this approach.
>
> If the lack of making a directory in GRLIB is handled by errors in the other
> dependent calls then why not add some documentation to the BSP.
>
> Confirmation appreciated but it is making the directory to out a device node. 
> The device node create will fail if there isn't a directory so this will 
> return an error.
> https://git.rtems.org/rtems/tree/bsps/shared/grlib/pci/gr_rasta_io.c#n577
>
> Which means an assert is ok
>
>
> I think an assert that /dev exists is fine within device drivers that
> want to create device nodes on /dev. It's not their responsibility to
> create the /dev tree, right?
>
> I agree. It means there is a system level initialisation issue. Maybe a sysint
> call that is fatal is added before drivers are initialised?
>
> Chris
> ___
> devel mailing listdevel@rtems.orghttp://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Unchecked return value on third party code

[Joel Sherrill]

Hi

Ryan has wandered into the land of third party code and Coverity issues. It
is not a very welcoming land and we need to decide what we want to do as a
project. I put one

In these cases, we have a few patterns to fall back on. There are basically
a few choices here:

+ ignore third party code in Coverity. I'm not a fan since we still have
code with issues.

  + Do the minimum which is often just adding (void) in front of the call
not checking a return code..Still wrap in #ifdef __rtems__ as below with a
more robust solution.

+ Add #ifdef __rtems__ so the original code and rtems changes are side by
side. This is more like what we do with libbsd. But I would still tend to
use the correct fix and not just slap a (void) in front. If we are going to
modify the file, we might as well fix it.

#ifdef __rtems__
   rc = XXX
   _Assert_Unused_variable_equals'
#else
   XXX
#endif

Any other options? Opinions.

--joel


 CID 1047324: Unchecked return value in fdt_add_subnode_namelen().

Closes #4256
---
cpukit/dtc/libfdt/fdt_rw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/dtc/libfdt/fdt_rw.c b/cpukit/dtc/libfdt/fdt_rw.c
index 1385425..ceeeb44 100644
--- a/cpukit/dtc/libfdt/fdt_rw.c
+++ b/cpukit/dtc/libfdt/fdt_rw.c
@@ -348,7 +348,7 @@ int fdt_add_subnode_namelen(void *fdt, int parentoffset,
return offset;
/* Try to place the new node after the parent's properties */
- fdt_next_tag(fdt, parentoffset, &nextoffset); /* skip the BEGIN_NODE */
+ (void)fdt_next_tag(fdt, parentoffset, &nextoffset); /* skip the
BEGIN_NODE */
do {
offset = nextoffset;
tag = fdt_next_tag(fdt, offset, &nextoffset);
-- 
1.8.3.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Unchecked return value on third party code

[Christian MAUDERER]

Hello Joel,

Am 23.02.21 um 16:23 schrieb Joel Sherrill:

Hi

Ryan has wandered into the land of third party code and Coverity issues. 
It is not a very welcoming land and we need to decide what we want to do 
as a project. I put one


In these cases, we have a few patterns to fall back on. There are 
basically a few choices here:


+ ignore third party code in Coverity. I'm not a fan since we still have 
code with issues.


Depends a bit on the third party code and the types of Coverity errors. 
But in general you are right: It's not a good solution.




   + Do the minimum which is often just adding (void) in front of the 
call not checking a return code..Still wrap in #ifdef __rtems__ as below 
with a more robust solution.


+ Add #ifdef __rtems__ so the original code and rtems changes are 
side by side. This is more like what we do with libbsd. But I would 
still tend to use the correct fix and not just slap a (void) in front. 
If we are going to modify the file, we might as well fix it.


#ifdef __rtems__
    rc = XXX
    _Assert_Unused_variable_equals'
#else
    XXX
#endif

Any other options? Opinions.


Best option would be to fix it upstream (regardless whether it's a real 
bug or a false positive) and update our copy of the code.


If that is not an option (patches not accepted; running out of time; 
some other reason) I think it needs a case by case analysis:


Is it really a potential problem or is it a false positive of Coverity.

1) If it is a false positive we have two conflicting interests:

a) Have as few changes as possible so that we can easily upgrade third 
party code to newer versions.


b) Have as few Coverity warnings as possible.

If possible I would rather disable specific warnings for specific third 
party files (or on a function level - is that possible?) rather then 
adding complexity to upgrades. Otherwise we might tend to rather not do 
an upgrade because it's too much work to re-integrate all the patches.


2) If it is not a false positive it should be definitively fixed (and 
not only masked with a (void)). In that case I think the #if(n)def 
__rtems__ like in libbsd is a good solution to make updates as simple as 
possible.


Best regards

Christian



--joel


  CID 1047324: Unchecked return value in fdt_add_subnode_namelen().

Closes #4256
---
cpukit/dtc/libfdt/fdt_rw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/dtc/libfdt/fdt_rw.c b/cpukit/dtc/libfdt/fdt_rw.c
index 1385425..ceeeb44 100644
--- a/cpukit/dtc/libfdt/fdt_rw.c
+++ b/cpukit/dtc/libfdt/fdt_rw.c
@@ -348,7 +348,7 @@ int fdt_add_subnode_namelen(void *fdt, int parentoffset,
return offset;
/* Try to place the new node after the parent's properties */
- fdt_next_tag(fdt, parentoffset, &nextoffset); /* skip the BEGIN_NODE */
+ (void)fdt_next_tag(fdt, parentoffset, &nextoffset); /* skip the 
BEGIN_NODE */

do {
offset = nextoffset;
tag = fdt_next_tag(fdt, offset, &nextoffset);
--
1.8.3.1

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



--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
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: Unchecked return value on third party code

[Joel Sherrill]

On Tue, Feb 23, 2021 at 9:50 AM Christian MAUDERER <
christian.maude...@embedded-brains.de> wrote:

> Hello Joel,
>
> Am 23.02.21 um 16:23 schrieb Joel Sherrill:
> > Hi
> >
> > Ryan has wandered into the land of third party code and Coverity issues.
> > It is not a very welcoming land and we need to decide what we want to do
> > as a project. I put one
> >
> > In these cases, we have a few patterns to fall back on. There are
> > basically a few choices here:
> >
> > + ignore third party code in Coverity. I'm not a fan since we still have
> > code with issues.
>
> Depends a bit on the third party code and the types of Coverity errors.
> But in general you are right: It's not a good solution.
>

There isn't a good one.

>
> >
> >+ Do the minimum which is often just adding (void) in front of the
> > call not checking a return code..Still wrap in #ifdef __rtems__ as below
> > with a more robust solution.
> >
> > + Add #ifdef __rtems__ so the original code and rtems changes are
> > side by side. This is more like what we do with libbsd. But I would
> > still tend to use the correct fix and not just slap a (void) in front.
> > If we are going to modify the file, we might as well fix it.
> >
> > #ifdef __rtems__
> > rc = XXX
> > _Assert_Unused_variable_equals'
> > #else
> > XXX
> > #endif
> >
> > Any other options? Opinions.
>
> Best option would be to fix it upstream (regardless whether it's a real
> bug or a false positive) and update our copy of the code.
>
> If that is not an option (patches not accepted; running out of time;
> some other reason) I think it needs a case by case analysis:
>
> Is it really a potential problem or is it a false positive of Coverity.
>
> 1) If it is a false positive we have two conflicting interests:
>
> a) Have as few changes as possible so that we can easily upgrade third
> party code to newer versions.
>
> b) Have as few Coverity warnings as possible.
>
> If possible I would rather disable specific warnings for specific third
> party files (or on a function level - is that possible?) rather then
> adding complexity to upgrades. Otherwise we might tend to rather not do
> an upgrade because it's too much work to re-integrate all the patches.
>

This isn't possible but we can flag a specific case as "don't care" and
move on.

I'm prone to think the one in the patch below is OK to do this with
since even if the calls fails, the next call to fdt_next_tag() will also
fail and get caught.

>
> 2) If it is not a false positive it should be definitively fixed (and
> not only masked with a (void)). In that case I think the #if(n)def
> __rtems__ like in libbsd is a good solution to make updates as simple as
> possible.
>

I suppose this is the solution and trying to at least file an issue
upstream.

I'm hesitant to hold up fixing it for us while waiting on a fix upstream
and then
an update on our side is twofold. First, the loop is quite time consuming
even
when it works. Worse, my history with upstreams and Coverity issues isn't
great.
It is possible in the end that we get stuck with the issue after all. I had
this happen
with gzip where the end result was an email that said they had decided it
was a
false positive. But every project including gzip gets the same issue
flagged. :(

We'll try to be good open source citizens, file issues upstream, and do
what we
think is right locally.

--joel

>
> Best regards
>
> Christian
>
> >
> > --joel
> >
> > 
> >   CID 1047324: Unchecked return value in fdt_add_subnode_namelen().
> >
> > Closes #4256
> > ---
> > cpukit/dtc/libfdt/fdt_rw.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/cpukit/dtc/libfdt/fdt_rw.c b/cpukit/dtc/libfdt/fdt_rw.c
> > index 1385425..ceeeb44 100644
> > --- a/cpukit/dtc/libfdt/fdt_rw.c
> > +++ b/cpukit/dtc/libfdt/fdt_rw.c
> > @@ -348,7 +348,7 @@ int fdt_add_subnode_namelen(void *fdt, int
> parentoffset,
> > return offset;
> > /* Try to place the new node after the parent's properties */
> > - fdt_next_tag(fdt, parentoffset, &nextoffset); /* skip the BEGIN_NODE */
> > + (void)fdt_next_tag(fdt, parentoffset, &nextoffset); /* skip the
> > BEGIN_NODE */
> > do {
> > offset = nextoffset;
> > tag = fdt_next_tag(fdt, offset, &nextoffset);
> > --
> > 1.8.3.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> >
>
> --
> 
> embedded brains GmbH
> Herr Christian MAUDERER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> phone: +49-89-18 94 741 - 18
> 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 

Re: Unchecked return value on third party code

[Christian MAUDERER]

Am 23.02.21 um 17:14 schrieb Joel Sherrill:



On Tue, Feb 23, 2021 at 9:50 AM Christian MAUDERER 
> wrote:


Hello Joel,

Am 23.02.21 um 16:23 schrieb Joel Sherrill:
 > Hi
 >
 > Ryan has wandered into the land of third party code and Coverity
issues.
 > It is not a very welcoming land and we need to decide what we
want to do
 > as a project. I put one
 >
 > In these cases, we have a few patterns to fall back on. There are
 > basically a few choices here:
 >
 > + ignore third party code in Coverity. I'm not a fan since we
still have
 > code with issues.

Depends a bit on the third party code and the types of Coverity errors.
But in general you are right: It's not a good solution.


There isn't a good one.


True.




 >
 >    + Do the minimum which is often just adding (void) in front of
the
 > call not checking a return code..Still wrap in #ifdef __rtems__
as below
 > with a more robust solution.
 >
 > + Add #ifdef __rtems__ so the original code and rtems changes are
 > side by side. This is more like what we do with libbsd. But I would
 > still tend to use the correct fix and not just slap a (void) in
front.
 > If we are going to modify the file, we might as well fix it.
 >
 > #ifdef __rtems__
 >     rc = XXX
 >     _Assert_Unused_variable_equals'
 > #else
 >     XXX
 > #endif
 >
 > Any other options? Opinions.

Best option would be to fix it upstream (regardless whether it's a real
bug or a false positive) and update our copy of the code.

If that is not an option (patches not accepted; running out of time;
some other reason) I think it needs a case by case analysis:

Is it really a potential problem or is it a false positive of Coverity.

1) If it is a false positive we have two conflicting interests:

a) Have as few changes as possible so that we can easily upgrade third
party code to newer versions.

b) Have as few Coverity warnings as possible.

If possible I would rather disable specific warnings for specific third
party files (or on a function level - is that possible?) rather then
adding complexity to upgrades. Otherwise we might tend to rather not do
an upgrade because it's too much work to re-integrate all the patches.


This isn't possible but we can flag a specific case as "don't care" and
move on.


Hm. Would have been nice if it would have worked.



I'm prone to think the one in the patch below is OK to do this with
since even if the calls fails, the next call to fdt_next_tag() will also
fail and get caught.



That's what I meant with "false positive".



2) If it is not a false positive it should be definitively fixed (and
not only masked with a (void)). In that case I think the #if(n)def
__rtems__ like in libbsd is a good solution to make updates as
simple as
possible.


I suppose this is the solution and trying to at least file an issue 
upstream.


I'm hesitant to hold up fixing it for us while waiting on a fix upstream 
and then
an update on our side is twofold. First, the loop is quite time 
consuming even

when it works.


Yes, I know. Upstream loops can be quite time consuming. I'm waiting 
since about half a year that a FreeBSD patch for the i.MX6ULL SDHCI gets 
reviewed (after someone here suggested it should go upstream). It's not 
a chip that is used in FreeBSD so it's not a high priority.


Worse, my history with upstreams and Coverity issues 
isn't great.
It is possible in the end that we get stuck with the issue after all. I 
had this happen
with gzip where the end result was an email that said they had decided 
it was a
false positive. But every project including gzip gets the same issue 
flagged. :(


Only possibility: Find another bug at the same location and fix the 
Coverity issue as a side effect ;-)




We'll try to be good open source citizens, file issues upstream, and do 
what we

think is right locally.


Agreed.

Again: I think such fixes are case by case decisions. We should fix as 
much as necessary and possible. But we have to make sure that we don't 
make our updates more complex with unnecessary fixes.


Best regards

Christian



--joel


Best regards

Christian

 >
 > --joel
 >
 > 
 >   CID 1047324: Unchecked return value in fdt_add_subnode_namelen().
 >
 > Closes #4256
 > ---
 > cpukit/dtc/libfdt/fdt_rw.c | 2 +-
 > 1 file changed, 1 insertion(+), 1 deletion(-)
 >
 > diff --git a/cpukit/dtc/libfdt/fdt_rw.c b/cpukit/dtc/libfdt/fdt_rw.c
 > index 1385425..ceeeb44 100644
 > --- a/cpukit/dtc/libfdt/fdt_rw.c
 > +++ b/cpukit/dtc/libfdt/fdt_rw.c
 > @@ -348,7 +348,7 @@ int fdt_add_subnode_namelen(void *fdt, int
parentoffset,
 > return offset;
 > /* Try to place the new node after the 

Re: How do we know what priority of the Init task is?

[Heinz Junkes]

Thank you for the detailed explanation. I may have asked my question 
incorrectly.

If I choose POSIX_Init for RTEMS the Init process has a very low priority and 
if I use 
the normal (RTEMS) Init a very high priority. This does not fit in my opinion.

Shouldn't the POSIX_Init - process have the prio 98 or so?

Heinz

> On 23. Feb 2021, at 15:17, Joel Sherrill  wrote:
> 
> 
> 
> On Tue, Feb 23, 2021 at 4:25 AM Heinz Junkes  wrote:
> what I have just never understood
> 
> POSIX  Prio 2 ist LOW Priority
> RTEMS Prio 1 is HIGH Priority
> 
> In general, RTOS threading APIs tended to use 1 as a high priority. The RTEMS 
> Classic API based on pSOS+, VxWorks, and VRTX32 which preceded all those 
> all follow 1 is high priority model.
> 
> POSIX calls for the opposite range. Not sure why. Interestingly, I had a 
> discussion 
> with the main kernel person for another RTOS about this in a standards 
> meeting 
> and he noted that although every implementation of POSIX threads we both knew
> about does use low number as low priority, it is not as explicit in the POSIX 
> standard
> as one would think. We have just all read the same text that way since POSIX 
> is 
> careful to say raises or lowers priority and the implication we all saw is 
> that the 
> numbers follow that languge. But at this point, the priorities run this way 
> for no
> other reason than history and compatibility. For all I know, it may even be 
> baked 
> into the POSIX Compliance Test Suite. Any program with hard-coded numbers
> certainly has it baked in.
> 
> While I am beating this topic mercilessly, let me point out that POSIX only 
> calls
> for a minimum of 32 priority levels. Portable programs cannot assume more.
> And the default attribute set for all POSIX threading and synchronization 
> objects is implementation defined. Portable programs should always explicitly
> set all attributes for pthreads, mutexes, etc. 
> 
> The RTOS choice probably reflects using a bitmap to represent if a thread
> is present on the FIFO for each priority. This would make a bit index map
> directly to priority in most cases. This design dates back to at least VMS
> where you have 32 priority levels because you could scan 32 bits in a
> single instruction. This was carried forward into Windows NT. 
> 
> THe diversity of choices reminded me of this quote from Andrew Tanenbaum:
> 
> "The nice thing about standards is that there are so many of them to choose 
> from."
> 
> In the end different people had an arbitrary decision and picked different 
> answers. Ada task priority is another set of choices. :)
> 
> --joel
> 
> 
> Heinz
> 
> 
> > On 23. Feb 2021, at 09:17, Sebastian Huber 
> >  wrote:
> > 
> > On 23/02/2021 08:36, Heinz Junkes wrote:
> > 
> >> I would have a similar question ;-)
> >> 
> >> What is the priority of the POSIX_Init - Task (as Posix-Prio)?
> > There is no option to configure the priority of the POSIX initialization 
> > thread, so the default priority of 2 is used, see 
> > _POSIX_Threads_Default_attributes.
> > 
> > -- 
> > 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



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: How do we know what priority of the Init task is?

[Joel Sherrill]

On Tue, Feb 23, 2021, 11:14 AM Heinz Junkes 
wrote:

> Thank you for the detailed explanation. I may have asked my question
> incorrectly.
>
> If I choose POSIX_Init for RTEMS the Init process has a very low priority
> and if I use
> the normal (RTEMS) Init a very high priority. This does not fit in my
> opinion.
>
> Shouldn't the POSIX_Init - process have the prio 98 or so?
>

No. To match, it would need to be 254 but it gets the default pthread
attributes which are implementation defined.  Being very low is probably a
good punishment for not specifying what you wanted in an application but
may not have been the best choice for POSIX init thread.

The ability to set very few attributes on the posix initialization thread
was a deliberate decision because you have to set them via API calls and
that would have increased the minimum footprint of a posix application to
include all pthread attribute set methods.

I don't have a good solution in mind. :(


> Heinz
>
> > On 23. Feb 2021, at 15:17, Joel Sherrill  wrote:
> >
> >
> >
> > On Tue, Feb 23, 2021 at 4:25 AM Heinz Junkes 
> wrote:
> > what I have just never understood
> >
> > POSIX  Prio 2 ist LOW Priority
> > RTEMS Prio 1 is HIGH Priority
> >
> > In general, RTOS threading APIs tended to use 1 as a high priority. The
> RTEMS
> > Classic API based on pSOS+, VxWorks, and VRTX32 which preceded all those
> > all follow 1 is high priority model.
> >
> > POSIX calls for the opposite range. Not sure why. Interestingly, I had a
> discussion
> > with the main kernel person for another RTOS about this in a standards
> meeting
> > and he noted that although every implementation of POSIX threads we both
> knew
> > about does use low number as low priority, it is not as explicit in the
> POSIX standard
> > as one would think. We have just all read the same text that way since
> POSIX is
> > careful to say raises or lowers priority and the implication we all saw
> is that the
> > numbers follow that languge. But at this point, the priorities run this
> way for no
> > other reason than history and compatibility. For all I know, it may even
> be baked
> > into the POSIX Compliance Test Suite. Any program with hard-coded numbers
> > certainly has it baked in.
> >
> > While I am beating this topic mercilessly, let me point out that POSIX
> only calls
> > for a minimum of 32 priority levels. Portable programs cannot assume
> more.
> > And the default attribute set for all POSIX threading and
> synchronization
> > objects is implementation defined. Portable programs should always
> explicitly
> > set all attributes for pthreads, mutexes, etc.
> >
> > The RTOS choice probably reflects using a bitmap to represent if a thread
> > is present on the FIFO for each priority. This would make a bit index map
> > directly to priority in most cases. This design dates back to at least
> VMS
> > where you have 32 priority levels because you could scan 32 bits in a
> > single instruction. This was carried forward into Windows NT.
> >
> > THe diversity of choices reminded me of this quote from Andrew Tanenbaum:
> >
> > "The nice thing about standards is that there are so many of them to
> choose from."
> >
> > In the end different people had an arbitrary decision and picked
> different
> > answers. Ada task priority is another set of choices. :)
> >
> > --joel
> >
> >
> > Heinz
> >
> >
> > > On 23. Feb 2021, at 09:17, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> > >
> > > On 23/02/2021 08:36, Heinz Junkes wrote:
> > >
> > >> I would have a similar question ;-)
> > >>
> > >> What is the priority of the POSIX_Init - Task (as Posix-Prio)?
> > > There is no option to configure the priority of the POSIX
> initialization thread, so the default priority of 2 is used, see
> _POSIX_Threads_Default_attributes.
> > >
> > > --
> > > 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: Unchecked return value on third party code

[Chris Johns]

On 24/2/21 3:29 am, Christian MAUDERER wrote:
> Yes, I know. Upstream loops can be quite time consuming. I'm waiting since 
> about
> half a year that a FreeBSD patch for the i.MX6ULL SDHCI gets reviewed (after
> someone here suggested it should go upstream). It's not a chip that is used in
> FreeBSD so it's not a high priority.

Please feel free to send me the details off list and lets see if we can find a
way to engage with the FreeBSD community to get these moving.

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

Re: Unchecked return value on third party code

[Joel Sherrill]

On Tue, Feb 23, 2021, 2:36 PM Chris Johns  wrote:

> On 24/2/21 3:29 am, Christian MAUDERER wrote:
> > Yes, I know. Upstream loops can be quite time consuming. I'm waiting
> since about
> > half a year that a FreeBSD patch for the i.MX6ULL SDHCI gets reviewed
> (after
> > someone here suggested it should go upstream). It's not a chip that is
> used in
> > FreeBSD so it's not a high priority.
>
> Please feel free to send me the details off list and lets see if we can
> find a
> way to engage with the FreeBSD community to get these moving


That's good if it is their code AND not introduced by the adaptation to
RTEMS.

Is DTC from FreeBSD?

The md4/5 code is owned by who?

I found where the cool editor in the shell came from so we can report to
that GitHub project.

Not intentionally being old and cranky but there are multiple upstreams and
I'm not sure if FreeBSD even is a large portion of it.

Oh.. did you think this was Coverity of libbsd? It is only non-network
portions of cpukit.

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

Re: Device Drivers Which Include mkdir("/dev")

[Chris Johns]

On 24/2/21 2:18 am, Joel Sherrill wrote:
> On Tue, Feb 23, 2021 at 2:52 AM Daniel Hellstrom  > wrote:
> I think the main reason why the mkdir() is called in the first place, from
> for example rasta-io driver, is that once other drivers register their
> device pciN.devM into the /dev/pciboardN/devM it would fail if the the
> directory /dev/pciboardN has not been created. So it is an attempt to 
> avoid
> mkdir() in all IO drivers and move themkdir() dependency up to the 
> pciboardN
> driver instead. An alternative approach could be that
> rtems_io_register_name("/dev/pciboardN/devM") would actually make sure 
> that
> /dev/pciboardN directory is created if does not exist? or by introducing a
> new supporting function rtems_io_register_name_dircreat()? However, I
> suppose that would mean we would drag in mkdir() routines in all cases 
> even
> when the IO drivers are only registering devices directly under /dev/ 
> which
> is the most common case.
> 
> I don't like adding another method especially since you 
> would have to parse the device name to find a subdirectory
> and that just adds complication. And all that logic ends up in the
> minimum BSP footprint for using a device. 
> 
> I started this discussion wanting a fatal error and now I am happy just 
> adding _Assert_Unused_variable_equals().  If the directory doesn't end up
> getting created, the mknod on the device will fail a few lines down so 
> there will be a failure. 
> 

I think there is an architectural issue we need to resolve about how a root file
system is created and what we would like to see in it. The scattered approach we
use is showing its age and the issue Joel has raised is an example.

There are a couple of root file systems (maybe more):

1. None, leave it to the application

2. Standard. Creates /etc, /etc/passwd, /etc/group and /dev.

I think we should remove all the mkdir's and move this responsibility to
confdefs.h and/or the application. It will help in standardising the RTEMS file
system layout. I would use SYSINT to manage the set up so we know the layout is
present.

Chris

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

Re: Unchecked return value on third party code

[Chris Johns]

On 24/2/21 7:45 am, Joel Sherrill wrote:
> On Tue, Feb 23, 2021, 2:36 PM Chris Johns  > wrote:
> 
> On 24/2/21 3:29 am, Christian MAUDERER wrote:
> > Yes, I know. Upstream loops can be quite time consuming. I'm waiting 
> since
> about
> > half a year that a FreeBSD patch for the i.MX6ULL SDHCI gets reviewed 
> (after
> > someone here suggested it should go upstream). It's not a chip that is 
> used in
> > FreeBSD so it's not a high priority.
> 
> Please feel free to send me the details off list and lets see if we can 
> find a
> way to engage with the FreeBSD community to get these moving
> 
> That's good if it is their code AND not introduced by the adaptation to 
> RTEMS. 
> 
> Is DTC from FreeBSD? 

I am only referring to the i.MX6ULL SDHC changes.

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

Re: [PATCH v4 1/2] bsps/beagle: Adding QEP driver support to BeagleBoneBlack BSP

[Chris Johns]

On 23/2/21 7:18 pm, James Fitzsimons wrote:
> ---
>  bsps/arm/beagle/headers.am  |   2 +
>  bsps/arm/beagle/include/bsp/bbb-pwm.h   |  11 -
>  bsps/arm/beagle/include/bsp/pwmss.h |  54 +++
>  bsps/arm/beagle/include/bsp/qep.h   | 382 
>  bsps/arm/beagle/pwm/pwm.c   |  60 +---
>  bsps/arm/beagle/pwmss/pwmss.c   |  64 
>  bsps/arm/beagle/qep/qep.c   | 445 
>  c/src/lib/libbsp/arm/beagle/Makefile.am |   6 +
>  spec/build/bsps/arm/beagle/obj.yml  |   5 +-
>  9 files changed, 959 insertions(+), 70 deletions(-)
>  create mode 100644 bsps/arm/beagle/include/bsp/pwmss.h
>  create mode 100644 bsps/arm/beagle/include/bsp/qep.h
>  create mode 100644 bsps/arm/beagle/pwmss/pwmss.c
>  create mode 100644 bsps/arm/beagle/qep/qep.c

Looks good. OK from me. Christian please push when you are happy.

James, thank you.

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

Re: How do we know what priority of the Init task is?

[Peter Dufault]

A few notes.  All are my understanding and IMHO.

- The reason that VRTX and other ancient RTOS's use 1 as the highest priority 
was the prevalence of "find first bit set" instructions.  With e.g. 32 
priorities you could in one instruction find the highest priority object that 
has something in it.  Such single instruction optimizations have been suspect 
for a long time, not to mention "find last bit set" instructions.
- That's why POSIX has a minimum of 32 priority levels.  POSIX standards need 
to support a "least common denominator", and when defining the standards some 
either wanted to match existing practice or support suspect optimal compilation.
- As for the decision to make higher priorities higher and not lower, I'd need 
to read the "rationale" sections of the POSIX work about priorities and POSIX.  
I'm guessing they were sick of saying "lower priorities are higher" and that it 
was time to move forward.  *I* think that was a mistake, the Unix "nice" levels 
had the same "lower is higher" attribute as do the legacy RTOS's.
- The default priority for the POSIX_Init thread should be obtained by mapping 
through the same function that maps classic priorities to POSIX priorities.  
POSIX_init is a "special" thread, and I don't see why it shouldn't have a 
special priority that matches the priorithy that rtems classic uses for it's 
init function.

It's probably safe to make the change.  All existing POSIX_init applications 
must either elevate their priority or ensure that any spawned threads do so.


> On Feb 23, 2021, at 12:47 , Joel Sherrill  wrote:
> 
> 
> 
> On Tue, Feb 23, 2021, 11:14 AM Heinz Junkes  wrote:
> Thank you for the detailed explanation. I may have asked my question 
> incorrectly.
> 
> If I choose POSIX_Init for RTEMS the Init process has a very low priority and 
> if I use
> the normal (RTEMS) Init a very high priority. This does not fit in my opinion.
> 
> Shouldn't the POSIX_Init - process have the prio 98 or so?
> 
> No. To match, it would need to be 254 but it gets the default pthread 
> attributes which are implementation defined.  Being very low is probably a 
> good punishment for not specifying what you wanted in an application but may 
> not have been the best choice for POSIX init thread.
> 
> The ability to set very few attributes on the posix initialization thread was 
> a deliberate decision because you have to set them via API calls and that 
> would have increased the minimum footprint of a posix application to include 
> all pthread attribute set methods.
> 
> I don't have a good solution in mind. :(
> 
> 
> Heinz
> 
> > On 23. Feb 2021, at 15:17, Joel Sherrill  wrote:
> >
> >
> >
> > On Tue, Feb 23, 2021 at 4:25 AM Heinz Junkes  
> > wrote:
> > what I have just never understood
> >
> > POSIX  Prio 2 ist LOW Priority
> > RTEMS Prio 1 is HIGH Priority
> >
> > In general, RTOS threading APIs tended to use 1 as a high priority. The 
> > RTEMS
> > Classic API based on pSOS+, VxWorks, and VRTX32 which preceded all those
> > all follow 1 is high priority model.
> >
> > POSIX calls for the opposite range. Not sure why. Interestingly, I had a 
> > discussion
> > with the main kernel person for another RTOS about this in a standards 
> > meeting
> > and he noted that although every implementation of POSIX threads we both 
> > knew
> > about does use low number as low priority, it is not as explicit in the 
> > POSIX standard
> > as one would think. We have just all read the same text that way since 
> > POSIX is
> > careful to say raises or lowers priority and the implication we all saw is 
> > that the
> > numbers follow that languge. But at this point, the priorities run this way 
> > for no
> > other reason than history and compatibility. For all I know, it may even be 
> > baked
> > into the POSIX Compliance Test Suite. Any program with hard-coded numbers
> > certainly has it baked in.
> >
> > While I am beating this topic mercilessly, let me point out that POSIX only 
> > calls
> > for a minimum of 32 priority levels. Portable programs cannot assume more.
> > And the default attribute set for all POSIX threading and synchronization
> > objects is implementation defined. Portable programs should always 
> > explicitly
> > set all attributes for pthreads, mutexes, etc.
> >
> > The RTOS choice probably reflects using a bitmap to represent if a thread
> > is present on the FIFO for each priority. This would make a bit index map
> > directly to priority in most cases. This design dates back to at least VMS
> > where you have 32 priority levels because you could scan 32 bits in a
> > single instruction. This was carried forward into Windows NT.
> >
> > THe diversity of choices reminded me of this quote from Andrew Tanenbaum:
> >
> > "The nice thing about standards is that there are so many of them to choose 
> > from."
> >
> > In the end different people had an arbitrary decision and picked different
> > answers. Ada task priority is another set of choices. :)
> >
> > --

Re: How do we know what priority of the Init task is?

[dufault]

I re-read Joel's mail and I agree, the priority should be left ridiculously low 
(as it is now) or maybe set in the middle (but why bother?).

I was thinking about matching classic RTEMS behavior.  I don't think it matters 
in POSIX.

> On Feb 23, 2021, at 17:12 , Peter Dufault  wrote:
> 
> Signed PGP part
> A few notes.  All are my understanding and IMHO.
> 
> - The reason that VRTX and other ancient RTOS's use 1 as the highest priority 
> was the prevalence of "find first bit set" instructions.  With e.g. 32 
> priorities you could in one instruction find the highest priority object that 
> has something in it.  Such single instruction optimizations have been suspect 
> for a long time, not to mention "find last bit set" instructions.
> - That's why POSIX has a minimum of 32 priority levels.  POSIX standards need 
> to support a "least common denominator", and when defining the standards some 
> either wanted to match existing practice or support suspect optimal 
> compilation.
> - As for the decision to make higher priorities higher and not lower, I'd 
> need to read the "rationale" sections of the POSIX work about priorities and 
> POSIX.  I'm guessing they were sick of saying "lower priorities are higher" 
> and that it was time to move forward.  *I* think that was a mistake, the Unix 
> "nice" levels had the same "lower is higher" attribute as do the legacy 
> RTOS's.
> - The default priority for the POSIX_Init thread should be obtained by 
> mapping through the same function that maps classic priorities to POSIX 
> priorities.  POSIX_init is a "special" thread, and I don't see why it 
> shouldn't have a special priority that matches the priorithy that rtems 
> classic uses for it's init function.
> 
> It's probably safe to make the change.  All existing POSIX_init applications 
> must either elevate their priority or ensure that any spawned threads do so.
> 
> 
>> On Feb 23, 2021, at 12:47 , Joel Sherrill  wrote:
>> 
>> 
>> 
>> On Tue, Feb 23, 2021, 11:14 AM Heinz Junkes  wrote:
>> Thank you for the detailed explanation. I may have asked my question 
>> incorrectly.
>> 
>> If I choose POSIX_Init for RTEMS the Init process has a very low priority 
>> and if I use
>> the normal (RTEMS) Init a very high priority. This does not fit in my 
>> opinion.
>> 
>> Shouldn't the POSIX_Init - process have the prio 98 or so?
>> 
>> No. To match, it would need to be 254 but it gets the default pthread 
>> attributes which are implementation defined.  Being very low is probably a 
>> good punishment for not specifying what you wanted in an application but may 
>> not have been the best choice for POSIX init thread.
>> 
>> The ability to set very few attributes on the posix initialization thread 
>> was a deliberate decision because you have to set them via API calls and 
>> that would have increased the minimum footprint of a posix application to 
>> include all pthread attribute set methods.
>> 
>> I don't have a good solution in mind. :(
>> 
>> 
>> Heinz
>> 
>>> On 23. Feb 2021, at 15:17, Joel Sherrill  wrote:
>>> 
>>> 
>>> 
>>> On Tue, Feb 23, 2021 at 4:25 AM Heinz Junkes  
>>> wrote:
>>> what I have just never understood
>>> 
>>> POSIX  Prio 2 ist LOW Priority
>>> RTEMS Prio 1 is HIGH Priority
>>> 
>>> In general, RTOS threading APIs tended to use 1 as a high priority. The 
>>> RTEMS
>>> Classic API based on pSOS+, VxWorks, and VRTX32 which preceded all those
>>> all follow 1 is high priority model.
>>> 
>>> POSIX calls for the opposite range. Not sure why. Interestingly, I had a 
>>> discussion
>>> with the main kernel person for another RTOS about this in a standards 
>>> meeting
>>> and he noted that although every implementation of POSIX threads we both 
>>> knew
>>> about does use low number as low priority, it is not as explicit in the 
>>> POSIX standard
>>> as one would think. We have just all read the same text that way since 
>>> POSIX is
>>> careful to say raises or lowers priority and the implication we all saw is 
>>> that the
>>> numbers follow that languge. But at this point, the priorities run this way 
>>> for no
>>> other reason than history and compatibility. For all I know, it may even be 
>>> baked
>>> into the POSIX Compliance Test Suite. Any program with hard-coded numbers
>>> certainly has it baked in.
>>> 
>>> While I am beating this topic mercilessly, let me point out that POSIX only 
>>> calls
>>> for a minimum of 32 priority levels. Portable programs cannot assume more.
>>> And the default attribute set for all POSIX threading and synchronization
>>> objects is implementation defined. Portable programs should always 
>>> explicitly
>>> set all attributes for pthreads, mutexes, etc.
>>> 
>>> The RTOS choice probably reflects using a bitmap to represent if a thread
>>> is present on the FIFO for each priority. This would make a bit index map
>>> directly to priority in most cases. This design dates back to at least VMS
>>> where you have 32 priority levels because you could scan 32 bit

Re: How do we know what priority of the Init task is?

[Chris Johns]

On 24/2/21 9:26 am, dufa...@hda.com wrote:
> I re-read Joel's mail and I agree, the priority should be left ridiculously 
> low (as it is now) or maybe set in the middle (but why bother?).
> 
> I was thinking about matching classic RTEMS behavior.  I don't think it 
> matters in POSIX.

The SYSINIT and constructors run on the first created thread before it is
entered so it makes me wonder if we test initialisation with both types of init
task?

Using the same priority would avoid any complication.

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

motorola_powerpc waf vs autoconf difference

[Chris Johns]

Hello,

I have noticed a difference in the build of RTEMS 6 waf compared to RTEMS 5 and
autoconf. The bootloader object files are not built with the code and data
section options. This is preferred and I like it but I thought I would ask if
this was intended?

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

[5 PATCH] powerpc/motorola_power: Link all text sections into the executable image

[chrisj]

From: Chris Johns 

- The change to building all code with code and data sections means
  we have a section per function. Make sure all functions are
  placed in the text section.

Closes #4266
---
 bsps/powerpc/motorola_powerpc/bootloader/ppcboot.lds | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bsps/powerpc/motorola_powerpc/bootloader/ppcboot.lds 
b/bsps/powerpc/motorola_powerpc/bootloader/ppcboot.lds
index 0ee7447546..a87a07cfd7 100644
--- a/bsps/powerpc/motorola_powerpc/bootloader/ppcboot.lds
+++ b/bsps/powerpc/motorola_powerpc/bootloader/ppcboot.lds
@@ -38,6 +38,7 @@ SECTIONS
 BYTE(0x75); BYTE(0x78); /* Partition name */
 . = 0x400;
 *(.text)
+*(.text*)
 *(.sdata2)
 *(.rodata)
 *(.rodata*)
@@ -98,4 +99,3 @@ SECTIONS
 *(.comment)
   }
 }
-
-- 
2.24.1

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

Re: motorola_powerpc waf vs autoconf difference

[Sebastian Huber]

On 24/02/2021 06:58, Chris Johns wrote:


I have noticed a difference in the build of RTEMS 6 waf compared to RTEMS 5 and
autoconf. The bootloader object files are not built with the code and data
section options. This is preferred and I like it but I thought I would ask if
this was intended?

This was definitely not intentional.

--
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: How do we know what priority of the Init task is?

[Sebastian Huber]

On 23/02/2021 23:41, Chris Johns wrote:


On 24/2/21 9:26 am, dufa...@hda.com wrote:

I re-read Joel's mail and I agree, the priority should be left ridiculously low 
(as it is now) or maybe set in the middle (but why bother?).

I was thinking about matching classic RTEMS behavior.  I don't think it matters 
in POSIX.

The SYSINIT and constructors run on the first created thread before it is
enteretd so it makes me wonder if we test initialisation with both types of init
task?
The SYSINIT doesn't run in a task context. It runs in whatever context 
is set up by the BSP low level initialization. Global construction is 
tested for all initialization task variants.


Using the same priority would avoid any complication.
Maybe we should add configuration options for the POSIX initialization 
thread.


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


--
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: Unchecked return value on third party code

[Sebastian Huber]

On 23/02/2021 16:23, Joel Sherrill wrote:


cpukit/dtc/libfdt/fdt_rw.c | 2 +-
The libfdt has an active upstream, so I would report this issue on their 
mailing list. This is a library I update occasionally.


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

About Thread_Cancel

[Richi Dubey]

Hi,

Can someone please give a brief overview of what these three lines aim to
achieve:

  } else if ( _Thread_Is_life_change_allowed( previous ) ) {
_Thread_Add_life_change_request( the_thread );
_Thread_State_release( the_thread, &lock_context );

_Thread_Finalize_life_change( the_thread, priority );

492 threadrestart.c

I am asking because in line 92
 of
sp02 ,
this _Thread_Cancel function is called, and because of
_Thread_Add_life_change_request( the_thread ) ->_Thread_Set_state_locked
-> _Scheduler_Block is called and because
of 
_Thread_Finalize_life_change->_Thread_Remove_life_change_request->_Thread_Clear_state_locked->_Scheduler_Unblock
is called, which is contradictory.

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