[PATCH] Patch attempt two to avoid nameclash of PAGESIZE define

[Robin Mueller]

This commit excludes the PAGESIZE legacy define
because there is a nameclash with a define of the same name
coming from the RTEMS header limits.h.
---
 .../stm32h7/include/Legacy/stm32_hal_legacy.h | 172 +-
 1 file changed, 88 insertions(+), 84 deletions(-)

diff --git a/bsps/arm/stm32h7/include/Legacy/stm32_hal_legacy.h 
b/bsps/arm/stm32h7/include/Legacy/stm32_hal_legacy.h
index c311c1618e..804a4c87da 100644
--- a/bsps/arm/stm32h7/include/Legacy/stm32_hal_legacy.h
+++ b/bsps/arm/stm32h7/include/Legacy/stm32_hal_legacy.h
@@ -31,7 +31,7 @@
 /* Exported constants 
*/
 
 /** @defgroup HAL_AES_Aliased_Defines HAL CRYP Aliased Defines maintained for 
legacy purpose
-  * @ingroup RTEMSBSPsARMSTM32H7
+  * @ingroup RTEMSBSPsARMSTM32H7
   * @{
   */
 #define AES_FLAG_RDERR  CRYP_FLAG_RDERR
@@ -45,7 +45,7 @@
   */
 
 /** @defgroup HAL_ADC_Aliased_Defines HAL ADC Aliased Defines maintained for 
legacy purpose
-  * @ingroup RTEMSBSPsARMSTM32H7
+  * @ingroup RTEMSBSPsARMSTM32H7
   * @{
   */
 #define ADC_RESOLUTION12b   ADC_RESOLUTION_12B
@@ -105,7 +105,7 @@
   */
 
 /** @defgroup HAL_CEC_Aliased_Defines HAL CEC Aliased Defines maintained for 
legacy purpose
-  * @ingroup RTEMSBSPsARMSTM32H7
+  * @ingroup RTEMSBSPsARMSTM32H7
   * @{
   */
 
@@ -116,7 +116,7 @@
   */
 
 /** @defgroup HAL_COMP_Aliased_Defines HAL COMP Aliased Defines maintained for 
legacy purpose
-  * @ingroup RTEMSBSPsARMSTM32H7
+  * @ingroup RTEMSBSPsARMSTM32H7
   * @{
   */
 #define COMP_WINDOWMODE_DISABLED   COMP_WINDOWMODE_DISABLE
@@ -208,7 +208,7 @@
   */
 
 /** @defgroup HAL_CORTEX_Aliased_Defines HAL CORTEX Aliased Defines maintained 
for legacy purpose
-  * @ingroup RTEMSBSPsARMSTM32H7
+  * @ingroup RTEMSBSPsARMSTM32H7
   * @{
   */
 #define __HAL_CORTEX_SYSTICKCLK_CONFIG HAL_SYSTICK_CLKSourceConfig
@@ -217,7 +217,7 @@
   */
 
 /** @defgroup HAL_CRC_Aliased_Defines HAL CRC Aliased Defines maintained for 
legacy purpose
-  * @ingroup RTEMSBSPsARMSTM32H7
+  * @ingroup RTEMSBSPsARMSTM32H7
   * @{
   */
 
@@ -229,7 +229,7 @@
   */
 
 /** @defgroup HAL_DAC_Aliased_Defines HAL DAC Aliased Defines maintained for 
legacy purpose
-  * @ingroup RTEMSBSPsARMSTM32H7
+  * @ingroup RTEMSBSPsARMSTM32H7
   * @{
   */
 
@@ -258,7 +258,7 @@
   */
 
 /** @defgroup HAL_DMA_Aliased_Defines HAL DMA Aliased Defines maintained for 
legacy purpose
-  * @ingroup RTEMSBSPsARMSTM32H7
+  * @ingroup RTEMSBSPsARMSTM32H7
   * @{
   */
 #define HAL_REMAPDMA_ADC_DMA_CH2DMA_REMAP_ADC_DMA_CH2
@@ -392,7 +392,7 @@
   */
 
 /** @defgroup HAL_FLASH_Aliased_Defines HAL FLASH Aliased Defines maintained 
for legacy purpose
-  * @ingroup RTEMSBSPsARMSTM32H7
+  * @ingroup RTEMSBSPsARMSTM32H7
   * @{
   */
 
@@ -420,7 +420,11 @@
 #define TYPEPROGRAMDATA_FASTBYTE  FLASH_TYPEPROGRAMDATA_FASTBYTE
 #define TYPEPROGRAMDATA_FASTHALFWORD  FLASH_TYPEPROGRAMDATA_FASTHALFWORD
 #define TYPEPROGRAMDATA_FASTWORD  FLASH_TYPEPROGRAMDATA_FASTWORD
+#ifndef __rtems__
+/* Commented out for the RTEMS BSP because there can be nameclashes with 
another
+similar defininition in limits.h */
 #define PAGESIZE  FLASH_PAGE_SIZE
+#endif /* __rtems__ */
 #define TYPEPROGRAM_FASTBYTE  FLASH_TYPEPROGRAM_BYTE
 #define TYPEPROGRAM_FASTHALFWORD  FLASH_TYPEPROGRAM_HALFWORD
 #define TYPEPROGRAM_FASTWORD  FLASH_TYPEPROGRAM_WORD
@@ -490,7 +494,7 @@
   */
 
 /** @defgroup HAL_JPEG_Aliased_Macros HAL JPEG Aliased Macros maintained for 
legacy purpose
-  * @ingroup RTEMSBSPsARMSTM32H7
+  * @ingroup RTEMSBSPsARMSTM32H7
   * @{
   */
 
@@ -508,7 +512,7 @@
   */
 
 /** @defgroup HAL_SYSCFG_Aliased_Defines HAL SYSCFG Aliased Defines maintained 
for legacy purpose
-  * @ingroup RTEMSBSPsARMSTM32H7
+  * @ingroup RTEMSBSPsARMSTM32H7
   * @{
   */
 
@@ -534,7 +538,7 @@
 
 
 /** @defgroup LL_FMC_Aliased_Defines LL FMC Aliased Defines maintained for 
compatibility purpose
-  * @ingroup RTEMSBSPsARMSTM32H7
+  * @ingroup RTEMSBSPsARMSTM32H7
   * @{
   */
 #if defined(STM32L4) || defined(STM32F7) || defined(STM32H7) || 
defined(STM32G4)
@@ -553,7 +557,7 @@
   */
 
 /** @defgroup LL_FSMC_Aliased_Defines LL FSMC Aliased Defines maintained for 
legacy purpose
-  * @ingroup RTEMSBSPsARMSTM32H7
+  * @ingroup RTEMSBSPsARMSTM32H7
   * @{
   */
 
@@ -564,7 +568,7 @@
   */
 
 /** @defgroup HAL_GPIO_Aliased_Macros HAL GPIO Aliased Macros maintained for 
legacy purpose
-  * @ingroup RTEMSBSPsARMSTM32H7
+  * @ingroup RTEMSBSPsARMSTM32H7
   * @{
   */
 #define GET_GPIO_SOURCE   GPIO_GET_INDEX
@@ -631,7 +635,7 @@
   */
 
 /** @defgroup HAL_HRTIM_Aliased_Macros HAL HRTIM Aliased Macros maintained for 
legacy purpose
-  * @ingroup RTEMSBSPsARMSTM32H7
+  * @ingroup RTEMSBSPsARMSTM32H7
   * @{
   */
 #define HRTIM_TIMDELAYEDPROTECTION_DISABLED   
HRTIM_TIMER_A_B_C_DELAYEDPROTECTION_DISABLED
@@ -836,7 +840,7 @@
   */
 
 /** @defgroup HAL_I2C_Aliased_Defines HAL I2C

Re: [PATCH] Patch attempt two to avoid nameclash of PAGESIZE define

[Robin Müller]

I just resent the patch and I hope this can be applied properly.

Like already mentioned, when loading this file in Ubuntu 20.04, something
was done to the line endings automatically..
But maybe this is the reason the patch could not be applied before, because
I had the same issue of not being able to apply my patch file.

Kind Regards
Robin

On Wed, 21 Apr 2021 at 10:55, Robin Mueller 
wrote:

> This commit excludes the PAGESIZE legacy define
> because there is a nameclash with a define of the same name
> coming from the RTEMS header limits.h.
> ---
>  .../stm32h7/include/Legacy/stm32_hal_legacy.h | 172 +-
>  1 file changed, 88 insertions(+), 84 deletions(-)
>
> diff --git a/bsps/arm/stm32h7/include/Legacy/stm32_hal_legacy.h
> b/bsps/arm/stm32h7/include/Legacy/stm32_hal_legacy.h
> index c311c1618e..804a4c87da 100644
> --- a/bsps/arm/stm32h7/include/Legacy/stm32_hal_legacy.h
> +++ b/bsps/arm/stm32h7/include/Legacy/stm32_hal_legacy.h
> @@ -31,7 +31,7 @@
>  /* Exported constants
> */
>
>  /** @defgroup HAL_AES_Aliased_Defines HAL CRYP Aliased Defines maintained
> for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>  #define AES_FLAG_RDERR  CRYP_FLAG_RDERR
> @@ -45,7 +45,7 @@
>*/
>
>  /** @defgroup HAL_ADC_Aliased_Defines HAL ADC Aliased Defines maintained
> for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>  #define ADC_RESOLUTION12b   ADC_RESOLUTION_12B
> @@ -105,7 +105,7 @@
>*/
>
>  /** @defgroup HAL_CEC_Aliased_Defines HAL CEC Aliased Defines maintained
> for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>
> @@ -116,7 +116,7 @@
>*/
>
>  /** @defgroup HAL_COMP_Aliased_Defines HAL COMP Aliased Defines
> maintained for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>  #define COMP_WINDOWMODE_DISABLED   COMP_WINDOWMODE_DISABLE
> @@ -208,7 +208,7 @@
>*/
>
>  /** @defgroup HAL_CORTEX_Aliased_Defines HAL CORTEX Aliased Defines
> maintained for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>  #define __HAL_CORTEX_SYSTICKCLK_CONFIG HAL_SYSTICK_CLKSourceConfig
> @@ -217,7 +217,7 @@
>*/
>
>  /** @defgroup HAL_CRC_Aliased_Defines HAL CRC Aliased Defines maintained
> for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>
> @@ -229,7 +229,7 @@
>*/
>
>  /** @defgroup HAL_DAC_Aliased_Defines HAL DAC Aliased Defines maintained
> for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>
> @@ -258,7 +258,7 @@
>*/
>
>  /** @defgroup HAL_DMA_Aliased_Defines HAL DMA Aliased Defines maintained
> for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>  #define HAL_REMAPDMA_ADC_DMA_CH2DMA_REMAP_ADC_DMA_CH2
> @@ -392,7 +392,7 @@
>*/
>
>  /** @defgroup HAL_FLASH_Aliased_Defines HAL FLASH Aliased Defines
> maintained for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>
> @@ -420,7 +420,11 @@
>  #define TYPEPROGRAMDATA_FASTBYTE  FLASH_TYPEPROGRAMDATA_FASTBYTE
>  #define TYPEPROGRAMDATA_FASTHALFWORD  FLASH_TYPEPROGRAMDATA_FASTHALFWORD
>  #define TYPEPROGRAMDATA_FASTWORD  FLASH_TYPEPROGRAMDATA_FASTWORD
> +#ifndef __rtems__
> +/* Commented out for the RTEMS BSP because there can be nameclashes with
> another
> +similar defininition in limits.h */
>  #define PAGESIZE  FLASH_PAGE_SIZE
> +#endif /* __rtems__ */
>  #define TYPEPROGRAM_FASTBYTE  FLASH_TYPEPROGRAM_BYTE
>  #define TYPEPROGRAM_FASTHALFWORD  FLASH_TYPEPROGRAM_HALFWORD
>  #define TYPEPROGRAM_FASTWORD  FLASH_TYPEPROGRAM_WORD
> @@ -490,7 +494,7 @@
>*/
>
>  /** @defgroup HAL_JPEG_Aliased_Macros HAL JPEG Aliased Macros maintained
> for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>
> @@ -508,7 +512,7 @@
>*/
>
>  /** @defgroup HAL_SYSCFG_Aliased_Defines HAL SYSCFG Aliased Defines
> maintained for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>
> @@ -534,7 +538,7 @@
>
>
>  /** @defgroup LL_FMC_Aliased_Defines LL FMC Aliased Defines maintained
> for compatibility purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>  #if defined(STM32L4) || defined(STM32F7) || defined(STM32H7) ||
> defined(STM32G4)
> @@ -553,7 +557,7 @@
>*/
>
>  /** @defgroup LL_FSMC_Aliased_Defines LL FSMC Aliased Defines maintained
> for legacy purpose
> -  * @ingroup RTEMSBSPsARMSTM32H7
> +  * @ingroup RTEMSBSPsARMSTM32H7
>* @{
>*/
>

Re: [PATCH] Updated tick implementation for HAL_GetTick

[Robin Müller]

Okay, good to know. Do you think it's okay if my simpler implementation is
used completely?
Another option would be to use the simple function for the oscillator init
functions (sth like a private HAL_GetTick_OscInit function).
But maybe you have a better idea.

Kind Regards
Robin


On Tue, 20 Apr 2021 at 19:48, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 20/04/2021 19:45, Robin Müller wrote:
>
> > Hmm, do you have an idea how to fix this cleanly? Was this the reason
> > the implementation returned 0?
> Yes.
> > This was not an issue with the other implementation:
> >
> > (rtems_clock_get_ticks_since_boot() * 1000) /
> > rtems_clock_get_ticks_per_second();
>
> This function is much simpler. It just reads a global variable. During
> startup the time is frozen.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] STM32H743ZI Nucleo and basic lwIP support

[Robin Müller]

I'm sorry I have to dig this up and bother you again but it's something
that i spotted when browsing the STM CubeH7 code and which is a similar
problem to the UART3 issue and might affect NUCLEO users who would like to
use libbsd networking.
Similarly to the UART3, the pins for the ETH initialization seem to be
different for the NUCLEO device.

More specifically, the code for the NUCLEO-H743ZI looks like this:

  /* Configure PA1, PA2 and PA7 */
  GPIO_InitStructure.Speed = GPIO_SPEED_FREQ_HIGH;
  GPIO_InitStructure.Mode = GPIO_MODE_AF_PP;
  GPIO_InitStructure.Pull = GPIO_NOPULL;
  GPIO_InitStructure.Alternate = GPIO_AF11_ETH;
  GPIO_InitStructure.Pin = GPIO_PIN_1 | GPIO_PIN_2 | GPIO_PIN_7;
  HAL_GPIO_Init(GPIOA, &GPIO_InitStructure);

  /* Configure PB13 */
  GPIO_InitStructure.Pin = GPIO_PIN_13;
  HAL_GPIO_Init(GPIOB, &GPIO_InitStructure);

  /* Configure PC1, PC4 and PC5 */
  GPIO_InitStructure.Pin = GPIO_PIN_1 | GPIO_PIN_4 | GPIO_PIN_5;
  HAL_GPIO_Init(GPIOC, &GPIO_InitStructure);

  /* Configure PG2, PG11, PG13 and PG14 */
  GPIO_InitStructure.Pin =  GPIO_PIN_2 | GPIO_PIN_11 | GPIO_PIN_13;
  HAL_GPIO_Init(GPIOG, &GPIO_InitStructure);

So instead of GPIOA 1,2 and 7, GPIOG 11, 12 and 13 and GPIOC 1, 4, 5, the
pins above are used.

KInd Regards
Robin

On Mon, 12 Apr 2021 at 11:23, Robin Müller 
wrote:

> I can split up the rest of the patch.
> I would rename STM32H7_ADD_LWIP from the BSP configuration to
> RTEMS_USE_LWIP as a more generic variant which could be reused for other
> BSPs if that is okay.
>
> Kind Regards
> Robin
>
> On Mon, 12 Apr 2021 at 10:46, Robin Müller 
> wrote:
>
>> The variant worked without issues.
>>
>> Kind Regards
>> Robin
>>
>> On Fri, 9 Apr 2021 at 09:21, Robin Müller 
>> wrote:
>>
>>> Hello Sebastian,
>>>
>>> I will have a look at it soon.
>>>
>>> Kind Regards
>>> Robin
>>>
>>> On Tue, 6 Apr 2021 at 10:01, Sebastian Huber <
>>> sebastian.hu...@embedded-brains.de> wrote:
>>>
 Hello Robin,

 sorry for the delay. I checked in some patches to add a
 "arm/nucleo-h743zi" BSP variant. Could you please check if this variant
 works on the board.

 Could you please split up the remaining pieces of the patch into
 separate commits.

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

 Registergericht: Amtsgericht München
 Registernummer: HRB 157899
 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
 Unsere Datenschutzerklärung finden Sie hier:
 https://embedded-brains.de/datenschutzerklaerung/


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

Re: [PATCH] STM32H743ZI Nucleo and basic lwIP support

[Robin Müller]

Actually, the configurations for GPIOA and GPIOC are completely overlapping
and could be reused to the NUCLEO BSP.

Kind Regards
Robin

On Wed, 21 Apr 2021 at 11:23, Robin Müller 
wrote:

> I'm sorry I have to dig this up and bother you again but it's something
> that i spotted when browsing the STM CubeH7 code and which is a similar
> problem to the UART3 issue and might affect NUCLEO users who would like to
> use libbsd networking.
> Similarly to the UART3, the pins for the ETH initialization seem to be
> different for the NUCLEO device.
>
> More specifically, the code for the NUCLEO-H743ZI looks like this:
>
>   /* Configure PA1, PA2 and PA7 */
>   GPIO_InitStructure.Speed = GPIO_SPEED_FREQ_HIGH;
>   GPIO_InitStructure.Mode = GPIO_MODE_AF_PP;
>   GPIO_InitStructure.Pull = GPIO_NOPULL;
>   GPIO_InitStructure.Alternate = GPIO_AF11_ETH;
>   GPIO_InitStructure.Pin = GPIO_PIN_1 | GPIO_PIN_2 | GPIO_PIN_7;
>   HAL_GPIO_Init(GPIOA, &GPIO_InitStructure);
>
>   /* Configure PB13 */
>   GPIO_InitStructure.Pin = GPIO_PIN_13;
>   HAL_GPIO_Init(GPIOB, &GPIO_InitStructure);
>
>   /* Configure PC1, PC4 and PC5 */
>   GPIO_InitStructure.Pin = GPIO_PIN_1 | GPIO_PIN_4 | GPIO_PIN_5;
>   HAL_GPIO_Init(GPIOC, &GPIO_InitStructure);
>
>   /* Configure PG2, PG11, PG13 and PG14 */
>   GPIO_InitStructure.Pin =  GPIO_PIN_2 | GPIO_PIN_11 | GPIO_PIN_13;
>   HAL_GPIO_Init(GPIOG, &GPIO_InitStructure);
>
> So instead of GPIOA 1,2 and 7, GPIOG 11, 12 and 13 and GPIOC 1, 4, 5, the
> pins above are used.
>
> KInd Regards
> Robin
>
> On Mon, 12 Apr 2021 at 11:23, Robin Müller 
> wrote:
>
>> I can split up the rest of the patch.
>> I would rename STM32H7_ADD_LWIP from the BSP configuration to
>> RTEMS_USE_LWIP as a more generic variant which could be reused for other
>> BSPs if that is okay.
>>
>> Kind Regards
>> Robin
>>
>> On Mon, 12 Apr 2021 at 10:46, Robin Müller 
>> wrote:
>>
>>> The variant worked without issues.
>>>
>>> Kind Regards
>>> Robin
>>>
>>> On Fri, 9 Apr 2021 at 09:21, Robin Müller 
>>> wrote:
>>>
 Hello Sebastian,

 I will have a look at it soon.

 Kind Regards
 Robin

 On Tue, 6 Apr 2021 at 10:01, Sebastian Huber <
 sebastian.hu...@embedded-brains.de> wrote:

> Hello Robin,
>
> sorry for the delay. I checked in some patches to add a
> "arm/nucleo-h743zi" BSP variant. Could you please check if this
> variant
> works on the board.
>
> Could you please split up the remaining pieces of the patch into
> separate commits.
>
> --
> 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: Write the BSP for ARM Versatile Express device

[Đức Anh]

Hi Gedare,

For the last few days, I am reading the rtems source code, trying to
understand the build system, how a bsp is built. I just has a few questions:
- it seems like the configure.ac and Makefile.am for each BSP
(c/src/lib/libbsp/) is separate from the BSP source code (bsps/). However
not all BSP has configure.ac and Makefile.am, for example, the FVP BSP you
said. What is the difference here?
- my speculation right now is to create a new folder in c/src/lib/libbsp/
for the VExpress device, put the configure.ac and Makefile.am in and put
the source file in bsps/ ?

Best regards,
Duc Anh


Vào Th 4, 14 thg 4, 2021 vào lúc 12:53 Gedare Bloom  đã
viết:

> Hi Duc,
>
> On Tue, Apr 13, 2021 at 8:57 AM Đức Anh  wrote:
> >
> > Dear all,
> >
> > I want to develop a BSP for ARM Versatile Express platform. My final
> purpose is to run Gem5 simulation using RTEMS as the kernel. Now Gem5 only
> model Versatile Express device, and I can see RTEMS does not have a BSP for
> it yet.
> >
> > More specifically, the machine type modelled in Gem5 is:
> > - Arm Motherboard Express uATX (V2M-P1)
> > - The memory map is based on Versatile Express RS1, with RS2 extension
> > - Arm CoreTile Express A15x2 (V2P-CA15) as daughterboard. It contains
> Cortex-A15 CPU.
> >
> > In the past, the Realview-pbx-a9 BSP used to run successfully in Gem5,
> when they still supported realview machine type. It is not the case now. So
> I guess I can reuse the CPU related code in realview-pbx-a9 and just write
> new code for the BSP ?
> >
> Well, the realview pbx a9 is a cortex-a9 device and not an a15. Plus,
> I guess the vexpress will have some differences in how it deals with
> interrupts and maybe messaging given its tiled architecture? I don't
> know too much about it. But, your best bet is probably to try to start
> with the FVP bsp, which was only added about 5 months ago and supports
> just a Cortex-R52 right now, but probably adding the vexpress RS1
> memory map with the V2P-CA15 is the right way for you to go.
>
> > I am new to RTEMS so I need some help. Which direction should I head for?
> >
> Join the devel@rtems.org mailing list for technical email discussions
> regarding hacking within RTEMS proper. (The "users" mailing list is a
> bit more for people trying to develop/maintain their application
> software using RTEMS mostly *fingers crossed* out of the box.) I would
> strongly recommend that you get started by following through our
> tutorials to get a feel for the tools and development environment:
> https://docs.rtems.org/branches/master/user/start/index.html
> Read carefully and don't skip steps, or you probably miss something
> important that you won't figure out until a couple hours later and
> have to redo everything. Since you plan new development, you should
> use the `master` branch of RTEMS with the `master` branch of the
> rtems-source-builder to build your cross-compiler toolchain. This is
> referred to as version '6' although it is not yet a released version.
>
> Right now we have a lot of new faces on devel@ because of the Google
> Summer of Code, so you'll find a lot of other people with questions
> and answers about how to get started etc. I would recommend you also
> do our GSoC Getting Started part of the tutorial so that you can get
> some comfort with the developer workflow and how to make changes in
> RTEMS and see them in the recompiled version.
>
> Finally, for new BSP development, I guess you can start by having a
> look at https://docs.rtems.org/branches/master/bsp-howto/index.html
> This is an aging document, but still a good resource to understand the
> basic ideas about BSP implementation.
>
> -Gedare
>
> > Best regards,
> > Duc Anh
> > ___
> > users mailing list
> > us...@rtems.org
> > http://lists.rtems.org/mailman/listinfo/users
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Write the BSP for ARM Versatile Express device

[Joel Sherrill]

On Wed, Apr 21, 2021, 5:32 AM Đức Anh  wrote:

> Hi Gedare,
>
> For the last few days, I am reading the rtems source code, trying to
> understand the build system, how a bsp is built. I just has a few questions:
> - it seems like the configure.ac and Makefile.am for each BSP
> (c/src/lib/libbsp/) is separate from the BSP source code (bsps/). However
> not all BSP has configure.ac and Makefile.am, for example, the FVP BSP
> you said. What is the difference here?
> - my speculation right now is to create a new folder in c/src/lib/libbsp/
> for the VExpress device, put the configure.ac and Makefile.am in and put
> the source file in bsps/ ?
>

First, that's the old build system and separate so it will be easier to
remove. It reflects an older organisation of the source tree.  The new
build system is waf and under spec/ at the top of the tree. Please use that
for new work.

Next, the BSPs have families and variants within a family. The directory is
the family and there are configuration files to build variants within the
family. The Zynq bsp family has a handful of variants. Run rtems-bsps from
the top of the tree for a list.

Do you have any executables from anywhere that run on the simulator in the
configuration you intend for RTEMS to use?

Focus on uniprocessor and getting hello to run first. But the devel@ list
is a better resource.

>
> Best regards,
> Duc Anh
>
>
> Vào Th 4, 14 thg 4, 2021 vào lúc 12:53 Gedare Bloom 
> đã viết:
>
>> Hi Duc,
>>
>> On Tue, Apr 13, 2021 at 8:57 AM Đức Anh  wrote:
>> >
>> > Dear all,
>> >
>> > I want to develop a BSP for ARM Versatile Express platform. My final
>> purpose is to run Gem5 simulation using RTEMS as the kernel. Now Gem5 only
>> model Versatile Express device, and I can see RTEMS does not have a BSP for
>> it yet.
>> >
>> > More specifically, the machine type modelled in Gem5 is:
>> > - Arm Motherboard Express uATX (V2M-P1)
>> > - The memory map is based on Versatile Express RS1, with RS2 extension
>> > - Arm CoreTile Express A15x2 (V2P-CA15) as daughterboard. It contains
>> Cortex-A15 CPU.
>> >
>> > In the past, the Realview-pbx-a9 BSP used to run successfully in Gem5,
>> when they still supported realview machine type. It is not the case now. So
>> I guess I can reuse the CPU related code in realview-pbx-a9 and just write
>> new code for the BSP ?
>> >
>> Well, the realview pbx a9 is a cortex-a9 device and not an a15. Plus,
>> I guess the vexpress will have some differences in how it deals with
>> interrupts and maybe messaging given its tiled architecture? I don't
>> know too much about it. But, your best bet is probably to try to start
>> with the FVP bsp, which was only added about 5 months ago and supports
>> just a Cortex-R52 right now, but probably adding the vexpress RS1
>> memory map with the V2P-CA15 is the right way for you to go.
>>
>> > I am new to RTEMS so I need some help. Which direction should I head
>> for?
>> >
>> Join the devel@rtems.org mailing list for technical email discussions
>> regarding hacking within RTEMS proper. (The "users" mailing list is a
>> bit more for people trying to develop/maintain their application
>> software using RTEMS mostly *fingers crossed* out of the box.) I would
>> strongly recommend that you get started by following through our
>> tutorials to get a feel for the tools and development environment:
>> https://docs.rtems.org/branches/master/user/start/index.html
>> Read carefully and don't skip steps, or you probably miss something
>> important that you won't figure out until a couple hours later and
>> have to redo everything. Since you plan new development, you should
>> use the `master` branch of RTEMS with the `master` branch of the
>> rtems-source-builder to build your cross-compiler toolchain. This is
>> referred to as version '6' although it is not yet a released version.
>>
>> Right now we have a lot of new faces on devel@ because of the Google
>> Summer of Code, so you'll find a lot of other people with questions
>> and answers about how to get started etc. I would recommend you also
>> do our GSoC Getting Started part of the tutorial so that you can get
>> some comfort with the developer workflow and how to make changes in
>> RTEMS and see them in the recompiled version.
>>
>> Finally, for new BSP development, I guess you can start by having a
>> look at https://docs.rtems.org/branches/master/bsp-howto/index.html
>> This is an aging document, but still a good resource to understand the
>> basic ideas about BSP implementation.
>>
>> -Gedare
>>
>> > Best regards,
>> > Duc Anh
>> > ___
>> > users mailing list
>> > us...@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/users
>>
> ___
> 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] rtems: Generate

[Sebastian Huber]

Change license to BSD-2-Clause according to file histories and
documentation re-licensing agreement.

Update #3899.
Update #3993.
---
 cpukit/include/rtems/rtems/support.h | 404 +--
 1 file changed, 320 insertions(+), 84 deletions(-)

diff --git a/cpukit/include/rtems/rtems/support.h 
b/cpukit/include/rtems/rtems/support.h
index 92dd49076f..829548aae2 100644
--- a/cpukit/include/rtems/rtems/support.h
+++ b/cpukit/include/rtems/rtems/support.h
@@ -1,168 +1,404 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /**
  * @file
  *
- * @ingroup ClassicRTEMSWorkspace
+ * @brief This header file defines support services of the API.
  */
 
-/* COPYRIGHT (c) 1989-2008.
- * On-Line Applications Research Corporation (OAR).
+/*
+ * Copyright (C) 2020, 2021 embedded brains GmbH 
(http://www.embedded-brains.de)
+ * Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
+ *
+ * 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.
+ */
+
+/*
+ * This file is part of the RTEMS quality process and was automatically
+ * generated.  If you find something that needs to be fixed or
+ * worded better please post a report or patch to an RTEMS mailing list
+ * or raise a bug report:
+ *
+ * https://www.rtems.org/bugs.html
+ *
+ * For information on updating and regenerating please refer to the How-To
+ * section in the Software Requirements Engineering chapter of the
+ * RTEMS Software Engineering manual.  The manual is provided as a part of
+ * a release.  For development sources please refer to the online
+ * documentation at:
  *
- * 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.
+ * https://docs.rtems.org
  */
 
+/* Generated from spec:/rtems/support/if/header */
+
 #ifndef _RTEMS_RTEMS_SUPPORT_H
 #define _RTEMS_RTEMS_SUPPORT_H
 
+#include 
+#include 
+#include 
+#include 
 #include 
 #include 
-#include 
 
 #ifdef __cplusplus
 extern "C" {
 #endif
 
+/* Generated from spec:/rtems/support/if/group */
+
 /**
- * @addtogroup ClassicTasks
+ * @defgroup RTEMSAPIClassicSupport Support Services
+ *
+ * @ingroup RTEMSAPIClassic
+ *
+ * @brief Items of this group should move to other groups.
  */
-/**@{**/
+
+/* Generated from spec:/rtems/support/if/is-name-valid */
 
 /**
- * @brief Returns the number of micro seconds for the milli seconds value @a 
_ms.
+ * @ingroup RTEMSAPIClassicSupport
+ *
+ * @brief Checks if the object name is valid.
+ *
+ * @param name is the object name to check.
+ *
+ * @return Returns true, if the object name is valid, otherwise false.
+ *
+ * @par Constraints
+ * @parblock
+ * The following constraints apply to this directive:
+ *
+ * * The directive may be called from within any runtime context.
+ *
+ * * The directive will not cause the calling task to be preempted.
+ * @endparblock
  */
-#define RTEMS_MILLISECONDS_TO_MICROSECONDS(_ms) ((_ms) * 1000UL)
+static inline bool rtems_is_name_valid( rtems_name name )
+{
+  return name != 0;
+}
+
+/* Generated from spec:/rtems/support/if/microseconds-to-ticks */
 
 /**
- * @brief Returns the number of ticks for the milli seconds value @a _ms.
+ * @ingroup RTEMSAPIClassicSupport
+ *
+ * @brief Gets the number of clock ticks for the microseconds value.
+ *
+ * @param _us is the microseconds value to convert to clock ticks.
+ *
+ * @return Returns the number of clock ticks for the specified microseconds
+ *   value.
+ *
+ * @par Notes
+ * The number of clock ticks per second is defined by the
+ * #CONFIGURE_MICROSECONDS_PER_TICK application configuration option.
+ *
+ * @par Constraints
+ * @parblock
+ * The following constraints apply to this directive:
+ *
+ * * The directive 

[PATCH 0/8] Generate documentation for managers

[Sebastian Huber]

This patch adds the next round of generated documentation.  The first
free patches just split up the existing documentation into multiple
files so that parts of it can be generated.  The fourth patch adds new
glossar terms.  The other patches add the generated documentation for
the Initialization, Fatal Error, Multiprocessing, and Dual-Ported Memory
Managers.

Here is the updated document for review:

https://ftp.rtems.org/pub/rtems/people/sebh/c-user.pdf

Sebastian Huber (8):
  c-user: Split up initialization manager
  c-user: Split up fatal error manager
  c-user: Split up multiprocessing manager
  c-user: Add user extensions glossary terms
  c-user: Generate initialization manager docs
  c-user: Generate fatal error manager docs
  c-user: Generate multiprocessing manager docs
  c-user: Generate dual-ported memory manager docs

 c-user/dual-ported-memory/directives.rst  | 500 --
 c-user/dual-ported-memory/introduction.rst|  43 +-
 .../background.rst}   | 300 ---
 c-user/fatal-error/directives.rst | 355 +
 c-user/fatal-error/index.rst  |  17 +
 c-user/fatal-error/introduction.rst   |  57 ++
 c-user/fatal-error/operations.rst |  51 ++
 c-user/glossary.rst   |  40 +-
 c-user/index.rst  |   6 +-
 c-user/initialization/background.rst  |  48 ++
 c-user/initialization/directives.rst  |  69 +++
 c-user/initialization/index.rst   |  15 +
 c-user/initialization/introduction.rst|  39 ++
 .../operations.rst}   |  98 
 .../background.rst}   |  89 
 c-user/multiprocessing/directives.rst |  74 +++
 c-user/multiprocessing/index.rst  |  17 +
 c-user/multiprocessing/introduction.rst   |  61 +++
 c-user/multiprocessing/operations.rst |  13 +
 c-user/user-extensions/background.rst |  13 +-
 20 files changed, 1234 insertions(+), 671 deletions(-)
 rename c-user/{fatal_error.rst => fatal-error/background.rst} (62%)
 create mode 100644 c-user/fatal-error/directives.rst
 create mode 100644 c-user/fatal-error/index.rst
 create mode 100644 c-user/fatal-error/introduction.rst
 create mode 100644 c-user/fatal-error/operations.rst
 create mode 100644 c-user/initialization/background.rst
 create mode 100644 c-user/initialization/directives.rst
 create mode 100644 c-user/initialization/index.rst
 create mode 100644 c-user/initialization/introduction.rst
 rename c-user/{initialization.rst => initialization/operations.rst} (80%)
 rename c-user/{multiprocessing.rst => multiprocessing/background.rst} (84%)
 create mode 100644 c-user/multiprocessing/directives.rst
 create mode 100644 c-user/multiprocessing/index.rst
 create mode 100644 c-user/multiprocessing/introduction.rst
 create mode 100644 c-user/multiprocessing/operations.rst

-- 
2.26.2

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

[PATCH 1/8] c-user: Split up initialization manager

[Sebastian Huber]

This makes it easier to automatically generate parts of the module
documentation in the future.

Update #3993.
---
 c-user/index.rst  |  2 +-
 c-user/initialization/background.rst  | 48 +
 c-user/initialization/directives.rst  | 41 
 c-user/initialization/index.rst   | 15 +++
 c-user/initialization/introduction.rst| 15 +++
 .../operations.rst}   | 98 ---
 6 files changed, 120 insertions(+), 99 deletions(-)
 create mode 100644 c-user/initialization/background.rst
 create mode 100644 c-user/initialization/directives.rst
 create mode 100644 c-user/initialization/index.rst
 create mode 100644 c-user/initialization/introduction.rst
 rename c-user/{initialization.rst => initialization/operations.rst} (80%)

diff --git a/c-user/index.rst b/c-user/index.rst
index 2f8109a..0a05c75 100644
--- a/c-user/index.rst
+++ b/c-user/index.rst
@@ -29,7 +29,7 @@ RTEMS Classic API Guide (|version|).
key_concepts
rtems_data_types
scheduling-concepts/index
-   initialization
+   initialization/index
task/index
interrupt/index
clock/index
diff --git a/c-user/initialization/background.rst 
b/c-user/initialization/background.rst
new file mode 100644
index 000..36d8ebd
--- /dev/null
+++ b/c-user/initialization/background.rst
@@ -0,0 +1,48 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
+
+Background
+==
+
+.. index:: initialization tasks
+
+Initialization Tasks
+
+
+Initialization task(s) are the mechanism by which RTEMS transfers initial
+control to the user's application.  Initialization tasks differ from other
+application tasks in that they are defined in the User Initialization Tasks
+Table and automatically created and started by RTEMS as part of its
+initialization sequence.  Since the initialization tasks are scheduled using
+the same algorithm as all other RTEMS tasks, they must be configured at a
+priority and mode which will ensure that they will complete execution before
+other application tasks execute.  Although there is no upper limit on the
+number of initialization tasks, an application is required to define at least
+one.
+
+A typical initialization task will create and start the static set of
+application tasks.  It may also create any other objects used by the
+application.  Initialization tasks which only perform initialization should
+delete themselves upon completion to free resources for other tasks.
+Initialization tasks may transform themselves into a "normal" application task.
+This transformation typically involves changing priority and execution mode.
+RTEMS does not automatically delete the initialization tasks.
+
+The Idle Task
+-
+
+The Idle Task is the lowest priority task in a system and executes only when no
+other task is ready to execute.  The default implementation of this task
+consists of an infinite loop. RTEMS allows the Idle Task body to be replaced by
+a CPU specific implementation, a BSP specific implementation or an application
+specific implementation.
+
+The Idle Task is preemptible and *WILL* be preempted when any other task is
+made ready to execute.  This characteristic is critical to the overall behavior
+of any application.
+
+Initialization Manager Failure
+--
+
+System initialization errors are fatal.  See :ref:`internal_errors`.
diff --git a/c-user/initialization/directives.rst 
b/c-user/initialization/directives.rst
new file mode 100644
index 000..97dea46
--- /dev/null
+++ b/c-user/initialization/directives.rst
@@ -0,0 +1,41 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
+
+Directives
+==
+
+This section details the Initialization Manager's directives.  A subsection is
+dedicated to each of this manager's directives and describes the calling
+sequence, related constants, usage, and status codes.
+
+.. raw:: latex
+
+   \clearpage
+
+.. index:: initialize RTEMS
+.. index:: start multitasking
+.. index:: rtems_initialize_executive
+
+.. _rtems_initialize_executive:
+
+INITIALIZE_EXECUTIVE - Initialize RTEMS
+---
+
+CALLING SEQUENCE:
+.. code-block:: c
+
+void rtems_initialize_executive(void);
+
+DIRECTIVE STATUS CODES:
+NONE - This function will not return to the caller.
+
+DESCRIPTION:
+Iterates through the system initialization linker set and invokes the
+registered handlers.  The final step is to start multitasking.
+
+NOTES:
+This directive should be called by :c:func:`boot_card()` only.
+
+This directive *does not return* to the caller.  Errors in the
+initialization sequence are usually fatal and lead to a system termination.
diff --git a/c-user/initialization/index.rst b/c-user/initialization/inde

[PATCH 4/8] c-user: Add user extensions glossary terms

[Sebastian Huber]

---
 c-user/glossary.rst   | 40 +--
 c-user/user-extensions/background.rst | 13 +++--
 2 files changed, 42 insertions(+), 11 deletions(-)

diff --git a/c-user/glossary.rst b/c-user/glossary.rst
index 71a0242..dc765ec 100644
--- a/c-user/glossary.rst
+++ b/c-user/glossary.rst
@@ -233,6 +233,12 @@ Glossary
 A term used to describe memory which can be accessed at two different
 addresses.
 
+dynamic extension sets
+The dynamic extension sets are a list of :term:`user extensions`.  The 
list
+is defined by the system services used by the application and 
directive calls
+such as :c:func:`rtems_extension_create`.  See also
+:term:`initial extension sets`.
+
 EARS
 This term is an acronym for Easy Approach to Requirements Syntax.
 
@@ -286,6 +292,26 @@ Glossary
 An object known by all nodes in a multiprocessor system.  An object
 created with the GLOBAL attribute will be exported.
 
+extension forward order
+The :term:`user extensions` may be invoked in extension forward order. 
 In
+forward order, an user extension of the :term:`initial extension sets` 
is
+invoked before an user extension of the :term:`dynamic extension 
sets`.  In
+the initial extension sets the order is defined by the table index.  
The user
+extension with the lowest table index is invoked first.  In the dynamic
+extension sets the order is defined by the registration order.  The 
first
+registered user extension is invoked first.  See also
+:term:`extension reverse order`.
+
+extension reverse order
+The :term:`user extensions` may be invoked in extension reverse order. 
 In
+reverse order, an user extension of the :term:`dynamic extension sets` 
is
+invoked before an user extension of the :term:`initial extension 
sets`.  In
+the initial extension sets the order is defined by the table index.  
The user
+extension with the highest table index is invoked first.  In the 
dynamic
+extension sets the order is defined by the registration order.  The 
last
+registered user extension is invoked first.  See also
+:term:`extension forward order`.
+
 external address
 The address used to access dual-ported memory by all the nodes in a
 system which do not own the memory.
@@ -371,6 +397,13 @@ Glossary
 An ineligible scheduler of a :term:`task` is a :term:`scheduler` which 
is
 not an :term:`eligible scheduler`.
 
+initial extension sets
+The initial extension sets are a table of :term:`user extensions`.  
The table
+is defined by the application configuration for example through the
+:ref:`CONFIGURE_INITIAL_EXTENSIONS` application configuration option.  
The
+initial extension sets cannot be altered during runtime through 
directive
+calls.  See also :term:`dynamic extension sets`.
+
 interface
 A specification of the methodology used to connect multiple independent
 subsystems.
@@ -991,8 +1024,11 @@ Glossary
 A table which contains the entry points for each user extensions.
 
 user extensions
-Software routines provided by the application to enhance the
-functionality of RTEMS.
+User extensions are software routines provided by the application to 
enhance
+the functionality of RTEMS.  An active user extension is either in the
+:term:`initial extension sets` or the :term:`dynamic extension sets`.  
User
+extensions are invoked in :term:`extension forward order` or
+:term:`extension reverse order`.
 
 User Initialization Tasks Table
 A table which contains the information needed to create and start each 
of
diff --git a/c-user/user-extensions/background.rst 
b/c-user/user-extensions/background.rst
index 2dc2577..5aa747b 100644
--- a/c-user/user-extensions/background.rst
+++ b/c-user/user-extensions/background.rst
@@ -109,15 +109,10 @@ and release the extension buffers.
 Order of Invocation
 ---
 
-The user extensions are invoked in either `forward` or `reverse` order.  In
-forward order, the user extensions of initial extension sets are invoked before
-the user extensions of the dynamic extension sets.  The forward order of
-initial extension sets is defined by the initial extension sets table index.
-The forward order of dynamic extension sets is defined by the order in which
-the dynamic extension sets were created.  The reverse order is defined
-accordingly.  By invoking the user extensions in this order, extensions can be
-built upon one another.  At the following system events, the user extensions
-are invoked in `forward` order
+The user extensions are invoked in either :term:`extension forward order` or
+:term:`extension reverse order`.  By invoking the user extensions in these
+orders, extension

[PATCH 3/8] c-user: Split up multiprocessing manager

[Sebastian Huber]

This makes it easier to automatically generate parts of the module
documentation in the future.

Update #3993.
---
 c-user/index.rst  |  2 +-
 .../background.rst}   | 89 ---
 c-user/multiprocessing/directives.rst | 44 +
 c-user/multiprocessing/index.rst  | 17 
 c-user/multiprocessing/introduction.rst   | 35 
 c-user/multiprocessing/operations.rst | 13 +++
 6 files changed, 110 insertions(+), 90 deletions(-)
 rename c-user/{multiprocessing.rst => multiprocessing/background.rst} (84%)
 create mode 100644 c-user/multiprocessing/directives.rst
 create mode 100644 c-user/multiprocessing/index.rst
 create mode 100644 c-user/multiprocessing/introduction.rst
 create mode 100644 c-user/multiprocessing/operations.rst

diff --git a/c-user/index.rst b/c-user/index.rst
index 267d56c..5cd87af 100644
--- a/c-user/index.rst
+++ b/c-user/index.rst
@@ -49,7 +49,7 @@ RTEMS Classic API Guide (|version|).
user-extensions/index
config/index
self_contained_objects
-   multiprocessing
+   multiprocessing/index
symmetric_multiprocessing_services
pci_library
stack_bounds_checker
diff --git a/c-user/multiprocessing.rst b/c-user/multiprocessing/background.rst
similarity index 84%
rename from c-user/multiprocessing.rst
rename to c-user/multiprocessing/background.rst
index f207106..2aaae6e 100644
--- a/c-user/multiprocessing.rst
+++ b/c-user/multiprocessing/background.rst
@@ -2,44 +2,6 @@
 
 .. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
 
-.. index:: multiprocessing
-
-Multiprocessing Manager
-***
-
-Introduction
-
-
-In multiprocessor real-time systems, new requirements, such as sharing data and
-global resources between processors, are introduced.  This requires an
-efficient and reliable communications vehicle which allows all processors to
-communicate with each other as necessary.  In addition, the ramifications of
-multiple processors affect each and every characteristic of a real-time system,
-almost always making them more complicated.
-
-RTEMS addresses these issues by providing simple and flexible real-time
-multiprocessing capabilities.  The executive easily lends itself to both
-tightly-coupled and loosely-coupled configurations of the target system
-hardware.  In addition, RTEMS supports systems composed of both homogeneous and
-heterogeneous mixtures of processors and target boards.
-
-A major design goal of the RTEMS executive was to transcend the physical
-boundaries of the target hardware configuration.  This goal is achieved by
-presenting the application software with a logical view of the target system
-where the boundaries between processor nodes are transparent.  As a result, the
-application developer may designate objects such as tasks, queues, events,
-signals, semaphores, and memory blocks as global objects.  These global objects
-may then be accessed by any task regardless of the physical location of the
-object and the accessing task.  RTEMS automatically determines that the object
-being accessed resides on another processor and performs the actions required
-to access the desired object.  Simply stated, RTEMS allows the entire system,
-both hardware and software, to be viewed logically as a single system.
-
-The directives provided by the  Manager are:
-
-- rtems_multiprocessing_announce_ - A multiprocessing communications packet has
-  arrived
-
 .. index:: multiprocessing topologies
 
 Background
@@ -455,54 +417,3 @@ of the following:
 
 - RTEMS makes no assumptions regarding the application data component of the
   packet.
-
-Operations
-==
-
-Announcing a Packet

-
-The ``rtems_multiprocessing_announce`` directive is called by the MPCI layer to
-inform RTEMS that a packet has arrived from another node.  This directive can
-be called from an interrupt service routine or from within a polling routine.
-
-Directives
-==
-
-This section details the additional directives required to support RTEMS in a
-multiprocessor configuration.  A subsection is dedicated to each of this
-manager's directives and describes the calling sequence, related constants,
-usage, and status codes.
-
-.. raw:: latex
-
-   \clearpage
-
-.. index:: announce arrival of package
-.. index:: rtems_multiprocessing_announce
-
-.. _rtems_multiprocessing_announce:
-
-MULTIPROCESSING_ANNOUNCE - Announce the arrival of a packet

-
-CALLING SEQUENCE:
-.. code-block:: c
-
-void rtems_multiprocessing_announce( void );
-
-DIRECTIVE STATUS CODES:
-NONE
-
-DESCRIPTION:
-This directive informs RTEMS that a multiprocessing communications packet
-has arrived from another node.  This directive is called by the
-user-provided MPCI, and is only used in multiprocessor configurations.
-
-NOTES:
-T

[PATCH 5/8] c-user: Generate initialization manager docs

[Sebastian Huber]

The documentation is a consolidation of the comments in Doxygen markup
and the documentation sources in Sphinx markup.  The documentation was
transfered to interface specification items.  The documentation source
files were generated from the items by a script.

Update #3993.
---
 c-user/initialization/directives.rst   | 68 ++
 c-user/initialization/introduction.rst | 36 +++---
 2 files changed, 78 insertions(+), 26 deletions(-)

diff --git a/c-user/initialization/directives.rst 
b/c-user/initialization/directives.rst
index 97dea46..7f67b9b 100644
--- a/c-user/initialization/directives.rst
+++ b/c-user/initialization/directives.rst
@@ -1,41 +1,69 @@
 .. SPDX-License-Identifier: CC-BY-SA-4.0
 
+.. Copyright (C) 2015, 2021 embedded brains GmbH 
(http://www.embedded-brains.de)
 .. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
 
+.. This file is part of the RTEMS quality process and was automatically
+.. generated.  If you find something that needs to be fixed or
+.. worded better please post a report or patch to an RTEMS mailing list
+.. or raise a bug report:
+..
+.. https://www.rtems.org/bugs.html
+..
+.. For information on updating and regenerating please refer to the How-To
+.. section in the Software Requirements Engineering chapter of the
+.. RTEMS Software Engineering manual.  The manual is provided as a part of
+.. a release.  For development sources please refer to the online
+.. documentation at:
+..
+.. https://docs.rtems.org
+
+.. _InitializationManagerDirectives:
+
 Directives
 ==
 
-This section details the Initialization Manager's directives.  A subsection is
-dedicated to each of this manager's directives and describes the calling
-sequence, related constants, usage, and status codes.
+This section details the directives of the Initialization Manager. A subsection
+is dedicated to each of this manager's directives and lists the calling
+sequence, parameters, description, return values, and notes of the directive.
+
+.. Generated from spec:/rtems/init/if/initialize-executive
 
 .. raw:: latex
 
-   \clearpage
+\clearpage
 
+.. index:: rtems_initialize_executive()
 .. index:: initialize RTEMS
 .. index:: start multitasking
-.. index:: rtems_initialize_executive
 
-.. _rtems_initialize_executive:
+.. _InterfaceRtemsInitializeExecutive:
+
+rtems_initialize_executive()
+
+
+Initializes the system and starts multitasking.
+
+.. rubric:: CALLING SEQUENCE:
+
+.. code-block:: c
+
+void rtems_initialize_executive( void );
+
+.. rubric:: DESCRIPTION:
 
-INITIALIZE_EXECUTIVE - Initialize RTEMS

+Iterates through the system initialization linker set and invokes the
+registered handlers.  The final step is to start multitasking.
 
-CALLING SEQUENCE:
-.. code-block:: c
+.. rubric:: NOTES:
 
-void rtems_initialize_executive(void);
+Errors in the initialization sequence are usually fatal and lead to a system
+termination.
 
-DIRECTIVE STATUS CODES:
-NONE - This function will not return to the caller.
+.. rubric:: CONSTRAINTS:
 
-DESCRIPTION:
-Iterates through the system initialization linker set and invokes the
-registered handlers.  The final step is to start multitasking.
+The following constraints apply to this directive:
 
-NOTES:
-This directive should be called by :c:func:`boot_card()` only.
+* This directive should be called by :c:func:`boot_card` only.
 
-This directive *does not return* to the caller.  Errors in the
-initialization sequence are usually fatal and lead to a system termination.
+* The directive will not return to the caller.
diff --git a/c-user/initialization/introduction.rst 
b/c-user/initialization/introduction.rst
index 88805f2..173e60f 100644
--- a/c-user/initialization/introduction.rst
+++ b/c-user/initialization/introduction.rst
@@ -1,15 +1,39 @@
 .. SPDX-License-Identifier: CC-BY-SA-4.0
 
+.. Copyright (C) 2015, 2021 embedded brains GmbH 
(http://www.embedded-brains.de)
 .. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
 
+.. This file is part of the RTEMS quality process and was automatically
+.. generated.  If you find something that needs to be fixed or
+.. worded better please post a report or patch to an RTEMS mailing list
+.. or raise a bug report:
+..
+.. https://www.rtems.org/bugs.html
+..
+.. For information on updating and regenerating please refer to the How-To
+.. section in the Software Requirements Engineering chapter of the
+.. RTEMS Software Engineering manual.  The manual is provided as a part of
+.. a release.  For development sources please refer to the online
+.. documentation at:
+..
+.. https://docs.rtems.org
+
+.. Generated from spec:/rtems/init/if/group
+
+.. _InitializationManagerIntroduction:
+
 Introduction
 
 
-The Initialization Manager is responsible for initializing the Board Support
-Package, RTEMS, device drivers, the root filesystem a

[PATCH 7/8] c-user: Generate multiprocessing manager docs

[Sebastian Huber]

The documentation is a consolidation of the comments in Doxygen markup
and the documentation sources in Sphinx markup.  The documentation was
transfered to interface specification items.  The documentation source
files were generated from the items by a script.

Update #3993.
---
 c-user/multiprocessing/directives.rst   | 78 +
 c-user/multiprocessing/introduction.rst | 34 +--
 2 files changed, 84 insertions(+), 28 deletions(-)

diff --git a/c-user/multiprocessing/directives.rst 
b/c-user/multiprocessing/directives.rst
index afa3244..ad7c6e2 100644
--- a/c-user/multiprocessing/directives.rst
+++ b/c-user/multiprocessing/directives.rst
@@ -1,44 +1,74 @@
 .. SPDX-License-Identifier: CC-BY-SA-4.0
 
+.. Copyright (C) 2021 embedded brains GmbH (http://www.embedded-brains.de)
 .. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
 
+.. This file is part of the RTEMS quality process and was automatically
+.. generated.  If you find something that needs to be fixed or
+.. worded better please post a report or patch to an RTEMS mailing list
+.. or raise a bug report:
+..
+.. https://www.rtems.org/bugs.html
+..
+.. For information on updating and regenerating please refer to the How-To
+.. section in the Software Requirements Engineering chapter of the
+.. RTEMS Software Engineering manual.  The manual is provided as a part of
+.. a release.  For development sources please refer to the online
+.. documentation at:
+..
+.. https://docs.rtems.org
+
+.. _MultiprocessingManagerDirectives:
+
 Directives
 ==
 
-This section details the additional directives required to support RTEMS in a
-multiprocessor configuration.  A subsection is dedicated to each of this
-manager's directives and describes the calling sequence, related constants,
-usage, and status codes.
+This section details the directives of the Multiprocessing Manager. A
+subsection is dedicated to each of this manager's directives and lists the
+calling sequence, parameters, description, return values, and notes of the
+directive.
+
+.. Generated from spec:/rtems/mp/if/announce
 
 .. raw:: latex
 
-   \clearpage
+\clearpage
+
+.. index:: rtems_multiprocessing_announce()
+
+.. _InterfaceRtemsMultiprocessingAnnounce:
+
+rtems_multiprocessing_announce()
+
+
+Announces the arrival of a packet.
+
+.. rubric:: CALLING SEQUENCE:
+
+.. code-block:: c
+
+void rtems_multiprocessing_announce( void );
+
+.. rubric:: DESCRIPTION:
 
-.. index:: announce arrival of package
-.. index:: rtems_multiprocessing_announce
+This directive informs RTEMS that a multiprocessing communications packet has
+arrived from another node.  This directive is called by the user-provided MPCI,
+and is only used in multiprocessing configurations.
 
-.. _rtems_multiprocessing_announce:
+.. rubric:: NOTES:
 
-MULTIPROCESSING_ANNOUNCE - Announce the arrival of a packet

+This directive is typically called from an :term:`ISR`.
 
-CALLING SEQUENCE:
-.. code-block:: c
+This directive does not generate activity on remote nodes.
 
-void rtems_multiprocessing_announce( void );
+.. rubric:: CONSTRAINTS:
 
-DIRECTIVE STATUS CODES:
-NONE
+The following constraints apply to this directive:
 
-DESCRIPTION:
-This directive informs RTEMS that a multiprocessing communications packet
-has arrived from another node.  This directive is called by the
-user-provided MPCI, and is only used in multiprocessor configurations.
+* The directive may be called from within interrupt context.
 
-NOTES:
-This directive is typically called from an ISR.
+* The directive may be called from within device driver initialization context.
 
-This directive will almost certainly cause the calling task to be
-preempted.
+* The directive may be called from within task context.
 
-This directive does not generate activity on remote nodes.
+* The directive may unblock another task which may preempt the calling task.
diff --git a/c-user/multiprocessing/introduction.rst 
b/c-user/multiprocessing/introduction.rst
index 3a5edd5..742a034 100644
--- a/c-user/multiprocessing/introduction.rst
+++ b/c-user/multiprocessing/introduction.rst
@@ -1,10 +1,36 @@
 .. SPDX-License-Identifier: CC-BY-SA-4.0
 
+.. Copyright (C) 2021 embedded brains GmbH (http://www.embedded-brains.de)
 .. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
 
+.. This file is part of the RTEMS quality process and was automatically
+.. generated.  If you find something that needs to be fixed or
+.. worded better please post a report or patch to an RTEMS mailing list
+.. or raise a bug report:
+..
+.. https://www.rtems.org/bugs.html
+..
+.. For information on updating and regenerating please refer to the How-To
+.. section in the Software Requirements Engineering chapter of the
+.. RTEMS Software Engineering manual.  The manual is provided as a part of
+.. a re

[PATCH 2/8] c-user: Split up fatal error manager

[Sebastian Huber]

This makes it easier to automatically generate parts of the module
documentation in the future.

Update #3993.
---
 .../background.rst}   | 300 --
 c-user/fatal-error/directives.rst | 226 +
 c-user/fatal-error/index.rst  |  17 +
 c-user/fatal-error/introduction.rst   |  25 ++
 c-user/fatal-error/operations.rst |  51 +++
 c-user/index.rst  |   2 +-
 c-user/initialization/introduction.rst|   2 +-
 7 files changed, 321 insertions(+), 302 deletions(-)
 rename c-user/{fatal_error.rst => fatal-error/background.rst} (62%)
 create mode 100644 c-user/fatal-error/directives.rst
 create mode 100644 c-user/fatal-error/index.rst
 create mode 100644 c-user/fatal-error/introduction.rst
 create mode 100644 c-user/fatal-error/operations.rst

diff --git a/c-user/fatal_error.rst b/c-user/fatal-error/background.rst
similarity index 62%
rename from c-user/fatal_error.rst
rename to c-user/fatal-error/background.rst
index 81cfa0c..571da10 100644
--- a/c-user/fatal_error.rst
+++ b/c-user/fatal-error/background.rst
@@ -2,35 +2,6 @@
 
 .. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
 
-.. index:: fatal errors
-
-.. _fatal_error_manager:
-
-Fatal Error Manager
-***
-
-Introduction
-
-
-The fatal error manager processes all fatal or irrecoverable errors and other
-sources of system termination (for example after :c:func:`exit()`).  Fatal
-errors are identified by the (fatal source, error code) pair.  The directives
-provided by the fatal error manager are:
-
-- rtems_fatal_ - Invoke the fatal error handler
-
-- rtems_panic_ - Print a message and invoke the fatal error handler
-
-- rtems_shutdown_executive_ - Shutdown RTEMS
-
-- rtems_exception_frame_print_ - Print the CPU exception frame
-
-- rtems_fatal_source_text_ - Return the fatal source text
-
-- rtems_internal_error_text_ - Return the error code text
-
-- rtems_fatal_error_occurred_ - Invoke the fatal error handler (deprecated)
-
 Background
 ==
 
@@ -383,274 +354,3 @@ INTERNAL_ERROR_TOO_LARGE_TLS_SIZE (41)
 :ref:`CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE 
`.
 You can get the thread-local storage size of an application using the RTEMS
 tool ``rtems-execinfo``.
-
-Operations
-==
-
-.. index:: _Terminate
-
-.. _Terminate:
-
-Announcing a Fatal Error
-
-
-The :c:func:`_Terminate()` internal error handler is invoked when the
-application or the executive itself determines that a fatal error has occurred
-or a final system state is reached (for example after :c:func:`rtems_fatal()`
-or :c:func:`exit()`).
-
-The first action of the internal error handler is to call the fatal extension 
of
-the user extensions.  For the initial extensions the following conditions are
-required
-
-- a valid stack pointer and enough stack space,
-
-- a valid code memory, and
-
-- valid read-only data.
-
-For the initial extensions the read-write data (including .bss segment) is not
-required on single processor configurations.  In SMP configurations, however,
-the read-write data must be initialized since this function must determine the
-state of the other processors and request them to shut-down if necessary.
-
-Non-initial extensions require in addition valid read-write data.  The board
-support package (BSP) may install an initial extension that performs a system
-reset.  In this case the non-initial extensions will be not called.
-
-The fatal extensions are called with three parameters:
-
-- the fatal source,
-
-- a legacy parameter which is always false, and
-
-- an error code with a fatal source dependent content.
-
-Once all fatal extensions executed, the error information will be stored to
-:c:data:`_Internal_errors_What_happened` and the system state is set to
-:c:macro:`SYSTEM_STATE_TERMINATED`.
-
-The final step is to call the CPU port specific :c:func:`_CPU_Fatal_halt()`.
-
-Directives
-==
-
-This section details the fatal error manager's directives.  A subsection is
-dedicated to each of this manager's directives and describes the calling
-sequence, related constants, usage, and status codes.
-
-.. raw:: latex
-
-   \clearpage
-
-.. index:: announce fatal error
-.. index:: fatal error, announce
-.. index:: rtems_fatal
-
-.. _rtems_fatal:
-
-FATAL - Invoke the fatal error handler
---
-
-CALLING SEQUENCE:
-.. code-block:: c
-
-void rtems_fatal(
-  rtems_fatal_source fatal_source,
-  rtems_fatal_code   error_code
-) RTEMS_NO_RETURN;
-
-DIRECTIVE STATUS CODES:
-NONE - This function will not return to the caller.
-
-DESCRIPTION:
-This directive terminates the system.
-
-NOTE:
-Registered :c:func:`atexit()` or :c:func:`on_exit()` handlers are not
-called.  Use :c:func:`exit()` in case these handlers should be invoked.
-
-.. raw:: latex
-
-   \clearpage
-
-.. 

[PATCH 6/8] c-user: Generate fatal error manager docs

[Sebastian Huber]

The documentation is a consolidation of the comments in Doxygen markup
and the documentation sources in Sphinx markup.  The documentation was
transfered to interface specification items.  The documentation source
files were generated from the items by a script.

Update #3993.
---
 c-user/fatal-error/directives.rst   | 397 ++--
 c-user/fatal-error/introduction.rst |  54 +++-
 2 files changed, 306 insertions(+), 145 deletions(-)

diff --git a/c-user/fatal-error/directives.rst 
b/c-user/fatal-error/directives.rst
index 2d9a476..98ce209 100644
--- a/c-user/fatal-error/directives.rst
+++ b/c-user/fatal-error/directives.rst
@@ -1,226 +1,355 @@
 .. SPDX-License-Identifier: CC-BY-SA-4.0
 
+.. Copyright (C) 2015, 2021 embedded brains GmbH 
(http://www.embedded-brains.de)
 .. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
 
+.. This file is part of the RTEMS quality process and was automatically
+.. generated.  If you find something that needs to be fixed or
+.. worded better please post a report or patch to an RTEMS mailing list
+.. or raise a bug report:
+..
+.. https://www.rtems.org/bugs.html
+..
+.. For information on updating and regenerating please refer to the How-To
+.. section in the Software Requirements Engineering chapter of the
+.. RTEMS Software Engineering manual.  The manual is provided as a part of
+.. a release.  For development sources please refer to the online
+.. documentation at:
+..
+.. https://docs.rtems.org
+
+.. _FatalErrorManagerDirectives:
+
 Directives
 ==
 
-This section details the fatal error manager's directives.  A subsection is
-dedicated to each of this manager's directives and describes the calling
-sequence, related constants, usage, and status codes.
+This section details the directives of the Fatal Error Manager. A subsection is
+dedicated to each of this manager's directives and lists the calling sequence,
+parameters, description, return values, and notes of the directive.
+
+.. Generated from spec:/rtems/fatal/if/fatal
 
 .. raw:: latex
 
-   \clearpage
+\clearpage
 
+.. index:: rtems_fatal()
 .. index:: announce fatal error
 .. index:: fatal error, announce
-.. index:: rtems_fatal
 
-.. _rtems_fatal:
+.. _InterfaceRtemsFatal:
+
+rtems_fatal()
+-
+
+Invokes the fatal error handler.
+
+.. rubric:: CALLING SEQUENCE:
+
+.. code-block:: c
+
+void rtems_fatal(
+  rtems_fatal_source fatal_source,
+  rtems_fatal_code   fatal_code
+);
+
+.. rubric:: PARAMETERS:
+
+``fatal_source``
+This parameter is the fatal source.
 
-FATAL - Invoke the fatal error handler
---
+``fatal_code``
+This parameter is the fatal code.
 
-CALLING SEQUENCE:
-.. code-block:: c
+.. rubric:: DESCRIPTION:
 
-void rtems_fatal(
-  rtems_fatal_source fatal_source,
-  rtems_fatal_code   error_code
-) RTEMS_NO_RETURN;
+This directive processes fatal errors.  The fatal source is set to the value of
+the ``fatal_source`` parameter.  The fatal code is set to the value of the
+``fatal_code`` parameter.
 
-DIRECTIVE STATUS CODES:
-NONE - This function will not return to the caller.
+.. rubric:: CONSTRAINTS:
 
-DESCRIPTION:
-This directive terminates the system.
+The following constraints apply to this directive:
 
-NOTE:
-Registered :c:func:`atexit()` or :c:func:`on_exit()` handlers are not
-called.  Use :c:func:`exit()` in case these handlers should be invoked.
+* The directive may be called from within any runtime context.
+
+* The directive will not return to the caller.
+
+* The directive invokes the fatal error extensions in :term:`extension forward
+  order`.
+
+* The directive does not invoke handlers registered by :c:func:`atexit` or
+  :c:func:`on_exit`.
+
+* The directive may terminate the system.
+
+.. Generated from spec:/rtems/fatal/if/panic
 
 .. raw:: latex
 
-   \clearpage
+\clearpage
 
+.. index:: rtems_panic()
 .. index:: panic
-.. index:: rtems_panic
 
-.. _rtems_panic:
+.. _InterfaceRtemsPanic:
+
+rtems_panic()
+-
+
+Prints the message and invokes the fatal error handler.
+
+.. rubric:: CALLING SEQUENCE:
+
+.. code-block:: c
 
-PANIC - Print a message and invoke the fatal error handler
---
+void rtems_panic( const char *fmt, ... );
 
-CALLING SEQUENCE:
-.. code-block:: c
+.. rubric:: PARAMETERS:
 
-void rtems_panic(
-  const char *fmt,
-  ...
-) RTEMS_NO_RETURN RTEMS_PRINTFLIKE( 1, 2 );
+``fmt``
+This parameter is the message format.
 
-DIRECTIVE STATUS CODES:
-NONE - This function will not return to the caller.
+``...``
+This parameter is a list of optional parameters required by the message
+format.
 
-DESCRIPTION:
-This directive prints a message via :c:func:`printk` specified by the
-format and optional parameters and then terminates the system with the
-:c:macro:`RTEMS_FATAL

[PATCH 8/8] c-user: Generate dual-ported memory manager docs

[Sebastian Huber]

The documentation is a consolidation of the comments in Doxygen markup
and the documentation sources in Sphinx markup.  The documentation was
transfered to interface specification items.  The documentation source
files were generated from the items by a script.

Update #3993.
---
 c-user/dual-ported-memory/directives.rst   | 500 ++---
 c-user/dual-ported-memory/introduction.rst |  43 +-
 2 files changed, 373 insertions(+), 170 deletions(-)

diff --git a/c-user/dual-ported-memory/directives.rst 
b/c-user/dual-ported-memory/directives.rst
index fb21a4f..d701a2b 100644
--- a/c-user/dual-ported-memory/directives.rst
+++ b/c-user/dual-ported-memory/directives.rst
@@ -1,229 +1,403 @@
 .. SPDX-License-Identifier: CC-BY-SA-4.0
 
+.. Copyright (C) 2020, 2021 embedded brains GmbH 
(http://www.embedded-brains.de)
 .. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
 
+.. This file is part of the RTEMS quality process and was automatically
+.. generated.  If you find something that needs to be fixed or
+.. worded better please post a report or patch to an RTEMS mailing list
+.. or raise a bug report:
+..
+.. https://www.rtems.org/bugs.html
+..
+.. For information on updating and regenerating please refer to the How-To
+.. section in the Software Requirements Engineering chapter of the
+.. RTEMS Software Engineering manual.  The manual is provided as a part of
+.. a release.  For development sources please refer to the online
+.. documentation at:
+..
+.. https://docs.rtems.org
+
+.. _DualPortedMemoryManagerDirectives:
+
 Directives
 ==
 
-This section details the dual-ported memory manager's directives.  A subsection
-is dedicated to each of this manager's directives and describes the calling
-sequence, related constants, usage, and status codes.
+This section details the directives of the Dual-Ported Memory Manager. A
+subsection is dedicated to each of this manager's directives and lists the
+calling sequence, parameters, description, return values, and notes of the
+directive.
+
+.. Generated from spec:/rtems/dpmem/if/create
 
 .. raw:: latex
 
-   \clearpage
+\clearpage
 
+.. index:: rtems_port_create()
 .. index:: create a port
-.. index:: rtems_port_create
-
-.. _rtems_port_create:
-
-PORT_CREATE - Create a port

-
-CALLING SEQUENCE:
-.. code-block:: c
-
-rtems_status_code rtems_port_create(
-rtems_name  name,
-void   *internal_start,
-void   *external_start,
-uint32_tlength,
-rtems_id   *id
-);
-
-DIRECTIVE STATUS CODES:
-.. list-table::
- :class: rtems-table
-
- * - ``RTEMS_SUCCESSFUL``
-   - port created successfully
- * - ``RTEMS_INVALID_NAME``
-   - invalid port name
- * - ``RTEMS_INVALID_ADDRESS``
-   - address not on four byte boundary
- * - ``RTEMS_INVALID_ADDRESS``
-   - ``id`` is NULL
- * - ``RTEMS_TOO_MANY``
-   - too many DP memory areas created
-
-DESCRIPTION:
-This directive creates a port which resides on the local node for the
-specified DPMA.  The assigned port id is returned in id.  This port id is
-used as an argument to other dual-ported memory manager directives to
-convert addresses within this DPMA.
-
-For control and maintenance of the port, RTEMS allocates and initializes an
-DPCB from the DPCB free pool.  Thus memory from the dual-ported memory area
-is not used to store the DPCB.
-
-NOTES:
-This directive may cause the calling task to be preempted due to an
-obtain and release of the object allocator mutex.
-
-The internal_address and external_address parameters must be on a four byte
-boundary.
+
+.. _InterfaceRtemsPortCreate:
+
+rtems_port_create()
+---
+
+Creates a port.
+
+.. rubric:: CALLING SEQUENCE:
+
+.. code-block:: c
+
+rtems_status_code rtems_port_create(
+  rtems_name name,
+  void  *internal_start,
+  void  *external_start,
+  uint32_t   length,
+  rtems_id  *id
+);
+
+.. rubric:: PARAMETERS:
+
+``name``
+This parameter is the object name of the port.
+
+``internal_start``
+This parameter is the internal start address of the memory area.
+
+``external_start``
+This parameter is the external start address of the memory area.
+
+``length``
+This parameter is the length in bytes of the memory area.
+
+``id``
+This parameter is the pointer to an object identifier variable.  When the
+directive call is successful, the identifier of the created port will be
+stored in this variable.
+
+.. rubric:: DESCRIPTION:
+
+This directive creates a port which resides on the local node.  The port has
+the user-defined object name specified in ``name``.  The assigned object
+identifier is returned in ``id``.  This identifier is used to access the port
+with other dual-ported memory port related directives.
+
+.. rubric:: RETURN VALUES:
+
+:c:macro:`RTEMS

Re: [PATCH] rtems: Generate

[Gedare Bloom]

On Wed, Apr 21, 2021 at 7:46 AM Sebastian Huber
 wrote:
>
> Change license to BSD-2-Clause according to file histories and
> documentation re-licensing agreement.
>
> Update #3899.
> Update #3993.
> ---
>  cpukit/include/rtems/rtems/support.h | 404 +--
>  1 file changed, 320 insertions(+), 84 deletions(-)
>
> diff --git a/cpukit/include/rtems/rtems/support.h 
> b/cpukit/include/rtems/rtems/support.h
> index 92dd49076f..829548aae2 100644
> --- a/cpukit/include/rtems/rtems/support.h
> +++ b/cpukit/include/rtems/rtems/support.h
> @@ -1,168 +1,404 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
>  /**
>   * @file
>   *
> - * @ingroup ClassicRTEMSWorkspace
> + * @brief This header file defines support services of the API.
>   */
>
> -/* COPYRIGHT (c) 1989-2008.
> - * On-Line Applications Research Corporation (OAR).
> +/*
> + * Copyright (C) 2020, 2021 embedded brains GmbH 
> (http://www.embedded-brains.de)
> + * Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
> + *
> + * 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.
> + */
> +
> +/*
> + * This file is part of the RTEMS quality process and was automatically
> + * generated.  If you find something that needs to be fixed or
> + * worded better please post a report or patch to an RTEMS mailing list
> + * or raise a bug report:
> + *
> + * https://www.rtems.org/bugs.html
> + *
> + * For information on updating and regenerating please refer to the How-To
> + * section in the Software Requirements Engineering chapter of the
> + * RTEMS Software Engineering manual.  The manual is provided as a part of
> + * a release.  For development sources please refer to the online
> + * documentation at:
>   *
> - * 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.
> + * https://docs.rtems.org
>   */
>
> +/* Generated from spec:/rtems/support/if/header */
> +
>  #ifndef _RTEMS_RTEMS_SUPPORT_H
>  #define _RTEMS_RTEMS_SUPPORT_H
>
> +#include 
> +#include 
> +#include 
> +#include 
>  #include 
>  #include 
> -#include 
>
>  #ifdef __cplusplus
>  extern "C" {
>  #endif
>
> +/* Generated from spec:/rtems/support/if/group */
> +
>  /**
> - * @addtogroup ClassicTasks
> + * @defgroup RTEMSAPIClassicSupport Support Services
> + *
> + * @ingroup RTEMSAPIClassic
> + *
> + * @brief Items of this group should move to other groups.

I don't understand this @brief comment. Should these support services
be added to some official API group?

Everything else looks good.

>   */
> -/**@{**/
> +
> +/* Generated from spec:/rtems/support/if/is-name-valid */
>
>  /**
> - * @brief Returns the number of micro seconds for the milli seconds value @a 
> _ms.
> + * @ingroup RTEMSAPIClassicSupport
> + *
> + * @brief Checks if the object name is valid.
> + *
> + * @param name is the object name to check.
> + *
> + * @return Returns true, if the object name is valid, otherwise false.
> + *
> + * @par Constraints
> + * @parblock
> + * The following constraints apply to this directive:
> + *
> + * * The directive may be called from within any runtime context.
> + *
> + * * The directive will not cause the calling task to be preempted.
> + * @endparblock
>   */
> -#define RTEMS_MILLISECONDS_TO_MICROSECONDS(_ms) ((_ms) * 1000UL)
> +static inline bool rtems_is_name_valid( rtems_name name )
> +{
> +  return name != 0;
> +}
> +
> +/* Generated from spec:/rtems/support/if/microseconds-to-ticks */
>
>  /**
> - * @brief Returns the number of ticks for the milli seconds value @a _ms.
> + * @ingroup RTEMSAPIClassicSupport
> + *
> + * @brief Gets the number of clock ticks for 

Re: [PATCH] rtems: Generate

[Sebastian Huber]

On 21/04/2021 16:19, Gedare Bloom wrote:


+/* Generated from spec:/rtems/support/if/group */
+
  /**
- * @addtogroup ClassicTasks
+ * @defgroup RTEMSAPIClassicSupport Support Services
+ *
+ * @ingroup RTEMSAPIClassic
+ *
+ * @brief Items of this group should move to other groups.

I don't understand this @brief comment. Should these support services
be added to some official API group?


This header looks like a kitchen sink. Maybe move:

rtems_is_name_valid -> types.h

rtems_name_to_characters -> types.h

RTEMS_MICROSECONDS_TO_TICKS -> clock.h

RTEMS_MILLISECONDS_TO_MICROSECONDS -> clock.h

RTEMS_MILLISECONDS_TO_TICKS -> clock.h

workspace -> ?

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

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

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

Re: [PATCH 4/8] c-user: Add user extensions glossary terms

[Gedare Bloom]

On Wed, Apr 21, 2021 at 7:50 AM Sebastian Huber
 wrote:
>
> ---
>  c-user/glossary.rst   | 40 +--
>  c-user/user-extensions/background.rst | 13 +++--
>  2 files changed, 42 insertions(+), 11 deletions(-)
>
> diff --git a/c-user/glossary.rst b/c-user/glossary.rst
> index 71a0242..dc765ec 100644
> --- a/c-user/glossary.rst
> +++ b/c-user/glossary.rst
> @@ -233,6 +233,12 @@ Glossary
>  A term used to describe memory which can be accessed at two different
>  addresses.
>
> +dynamic extension sets
> +The dynamic extension sets are a list of :term:`user extensions`.  
> The list
> +is defined by the system services used by the application and 
> directive calls
> +such as :c:func:`rtems_extension_create`.  See also
> +:term:`initial extension sets`.
> +
>  EARS
>  This term is an acronym for Easy Approach to Requirements Syntax.
>
> @@ -286,6 +292,26 @@ Glossary
>  An object known by all nodes in a multiprocessor system.  An object
>  created with the GLOBAL attribute will be exported.
>
> +extension forward order
> +The :term:`user extensions` may be invoked in extension forward 
> order.  In
> +forward order, an user extension of the :term:`initial extension 
> sets` is
> +invoked before an user extension of the :term:`dynamic extension 
> sets`.  In
s/an user extension/user extensions

in both these sentences, it is all initial extension set are invoked
before all dynamic extension sets, clarify by using the plural form.

> +the initial extension sets the order is defined by the table index.  
> The user
> +extension with the lowest table index is invoked first.  In the 
> dynamic
> +extension sets the order is defined by the registration order.  The 
> first
> +registered user extension is invoked first.  See also
> +:term:`extension reverse order`.
> +
> +extension reverse order
> +The :term:`user extensions` may be invoked in extension reverse 
> order.  In
> +reverse order, an user extension of the :term:`dynamic extension 
> sets` is
> +invoked before an user extension of the :term:`initial extension 
> sets`.  In
ditto

> +the initial extension sets the order is defined by the table index.  
> The user
> +extension with the highest table index is invoked first.  In the 
> dynamic

Maybe swap the order of description to put dynamic first, since they
would be invoked first in this reverse order.

> +extension sets the order is defined by the registration order.  The 
> last
> +registered user extension is invoked first.  See also
> +:term:`extension forward order`.
> +
>  external address
>  The address used to access dual-ported memory by all the nodes in a
>  system which do not own the memory.
> @@ -371,6 +397,13 @@ Glossary
>  An ineligible scheduler of a :term:`task` is a :term:`scheduler` 
> which is
>  not an :term:`eligible scheduler`.
>
> +initial extension sets
> +The initial extension sets are a table of :term:`user extensions`.  
> The table
> +is defined by the application configuration for example through the
> +:ref:`CONFIGURE_INITIAL_EXTENSIONS` application configuration 
> option.  The
> +initial extension sets cannot be altered during runtime through 
> directive
> +calls.  See also :term:`dynamic extension sets`.
> +
>  interface
>  A specification of the methodology used to connect multiple 
> independent
>  subsystems.
> @@ -991,8 +1024,11 @@ Glossary
>  A table which contains the entry points for each user extensions.
>
>  user extensions
> -Software routines provided by the application to enhance the
> -functionality of RTEMS.
> +User extensions are software routines provided by the application to 
> enhance
> +the functionality of RTEMS.  An active user extension is either in 
> the
> +:term:`initial extension sets` or the :term:`dynamic extension 
> sets`.  User
> +extensions are invoked in :term:`extension forward order` or
> +:term:`extension reverse order`.
>
>  User Initialization Tasks Table
>  A table which contains the information needed to create and start 
> each of
> diff --git a/c-user/user-extensions/background.rst 
> b/c-user/user-extensions/background.rst
> index 2dc2577..5aa747b 100644
> --- a/c-user/user-extensions/background.rst
> +++ b/c-user/user-extensions/background.rst
> @@ -109,15 +109,10 @@ and release the extension buffers.
>  Order of Invocation
>  ---
>
> -The user extensions are invoked in either `forward` or `reverse` order.  In
> -forward order, the user extensions of initial extension sets are invoked 
> before
> -the user extensions of the dynamic extension sets.  The forward order of
> -initial extens

Re: [PATCH 8/8] c-user: Generate dual-ported memory manager docs

[Gedare Bloom]

On Wed, Apr 21, 2021 at 7:50 AM Sebastian Huber
 wrote:
>
> The documentation is a consolidation of the comments in Doxygen markup
> and the documentation sources in Sphinx markup.  The documentation was
> transfered to interface specification items.  The documentation source
> files were generated from the items by a script.
>
> Update #3993.
> ---
>  c-user/dual-ported-memory/directives.rst   | 500 ++---
>  c-user/dual-ported-memory/introduction.rst |  43 +-
>  2 files changed, 373 insertions(+), 170 deletions(-)
>
> diff --git a/c-user/dual-ported-memory/directives.rst 
> b/c-user/dual-ported-memory/directives.rst
> index fb21a4f..d701a2b 100644
> --- a/c-user/dual-ported-memory/directives.rst
> +++ b/c-user/dual-ported-memory/directives.rst
> @@ -1,229 +1,403 @@
>  .. SPDX-License-Identifier: CC-BY-SA-4.0
>
> +.. Copyright (C) 2020, 2021 embedded brains GmbH 
> (http://www.embedded-brains.de)
>  .. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
>
> +.. This file is part of the RTEMS quality process and was automatically
> +.. generated.  If you find something that needs to be fixed or
> +.. worded better please post a report or patch to an RTEMS mailing list
> +.. or raise a bug report:
> +..
> +.. https://www.rtems.org/bugs.html
> +..
> +.. For information on updating and regenerating please refer to the How-To
> +.. section in the Software Requirements Engineering chapter of the
> +.. RTEMS Software Engineering manual.  The manual is provided as a part of
> +.. a release.  For development sources please refer to the online
> +.. documentation at:
> +..
> +.. https://docs.rtems.org
> +
> +.. _DualPortedMemoryManagerDirectives:
> +
>  Directives
>  ==
>
> -This section details the dual-ported memory manager's directives.  A 
> subsection
> -is dedicated to each of this manager's directives and describes the calling
> -sequence, related constants, usage, and status codes.
> +This section details the directives of the Dual-Ported Memory Manager. A
> +subsection is dedicated to each of this manager's directives and lists the
> +calling sequence, parameters, description, return values, and notes of the
> +directive.
> +
> +.. Generated from spec:/rtems/dpmem/if/create
>
>  .. raw:: latex
>
> -   \clearpage
> +\clearpage
>
> +.. index:: rtems_port_create()
>  .. index:: create a port
> -.. index:: rtems_port_create
> -
> -.. _rtems_port_create:
> -
> -PORT_CREATE - Create a port
> 
> -
> -CALLING SEQUENCE:
> -.. code-block:: c
> -
> -rtems_status_code rtems_port_create(
> -rtems_name  name,
> -void   *internal_start,
> -void   *external_start,
> -uint32_tlength,
> -rtems_id   *id
> -);
> -
> -DIRECTIVE STATUS CODES:
> -.. list-table::
> - :class: rtems-table
> -
> - * - ``RTEMS_SUCCESSFUL``
> -   - port created successfully
> - * - ``RTEMS_INVALID_NAME``
> -   - invalid port name
> - * - ``RTEMS_INVALID_ADDRESS``
> -   - address not on four byte boundary
> - * - ``RTEMS_INVALID_ADDRESS``
> -   - ``id`` is NULL
> - * - ``RTEMS_TOO_MANY``
> -   - too many DP memory areas created
> -
> -DESCRIPTION:
> -This directive creates a port which resides on the local node for the
> -specified DPMA.  The assigned port id is returned in id.  This port id is
> -used as an argument to other dual-ported memory manager directives to
> -convert addresses within this DPMA.
> -
> -For control and maintenance of the port, RTEMS allocates and initializes 
> an
> -DPCB from the DPCB free pool.  Thus memory from the dual-ported memory 
> area
> -is not used to store the DPCB.
> -
> -NOTES:
> -This directive may cause the calling task to be preempted due to an
> -obtain and release of the object allocator mutex.
> -
> -The internal_address and external_address parameters must be on a four 
> byte
> -boundary.
> +
> +.. _InterfaceRtemsPortCreate:
> +
> +rtems_port_create()
> +---
> +
> +Creates a port.
> +
> +.. rubric:: CALLING SEQUENCE:
> +
> +.. code-block:: c
> +
> +rtems_status_code rtems_port_create(
> +  rtems_name name,
> +  void  *internal_start,
> +  void  *external_start,
> +  uint32_t   length,
> +  rtems_id  *id
> +);
> +
> +.. rubric:: PARAMETERS:
> +
> +``name``
> +This parameter is the object name of the port.
> +
> +``internal_start``
> +This parameter is the internal start address of the memory area.
> +
> +``external_start``
> +This parameter is the external start address of the memory area.
> +
> +``length``
> +This parameter is the length in bytes of the memory area.
> +
> +``id``
> +This parameter is the pointer to an object identifier variable.  When the
> +directive call is successful, the identifier of the created port will be
> +stored in this variable.
> +
> +.. rubri

Re: [PATCH 8/8] c-user: Generate dual-ported memory manager docs

[Sebastian Huber]

On 21/04/2021 17:28, Gedare Bloom wrote:


+:c:macro:`RTEMS_INVALID_ADDRESS`
+The ``length`` parameter was `NULL

id?

everything else looks ok

Thanks a lot for the quick review.

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

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

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

Re: [PATCH] Updated tick implementation for HAL_GetTick

[Sebastian Huber]

On 21/04/2021 11:00, Robin Müller wrote:

Okay, good to know. Do you think it's okay if my simpler 
implementation is used completely?
Another option would be to use the simple function for the oscillator 
init functions (sth like a private HAL_GetTick_OscInit function).

But maybe you have a better idea.
If the ticks base solution works it is all right. The HAL_GetTick() - 
HAL_GetTick() (e.g. tick 0xabcd - tick 0x123) should return a 
correct interval during a tick overflow.


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

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

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

Re: [PATCH] Updated tick implementation for HAL_GetTick

[Sebastian Huber]

On 21/04/2021 19:30, Sebastian Huber wrote:


On 21/04/2021 11:00, Robin Müller wrote:

Okay, good to know. Do you think it's okay if my simpler 
implementation is used completely?
Another option would be to use the simple function for the oscillator 
init functions (sth like a private HAL_GetTick_OscInit function).

But maybe you have a better idea.
If the ticks base solution works it is all right. The HAL_GetTick() - 
HAL_GetTick() (e.g. tick 0xabcd - tick 0x123) should return a 
correct interval during a tick overflow. 

It should be 0x123 - 0xabcd.

--
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] psx13: Reworked and relicensed

[Ryan Long]

Changed the way the tests were structured, added rtems_test_assert()'s,
updated psx13.scn and the license.
---
 testsuites/psxtests/psx13/psx13.scn |  24 +-
 testsuites/psxtests/psx13/test.c| 879 +---
 2 files changed, 335 insertions(+), 568 deletions(-)

diff --git a/testsuites/psxtests/psx13/psx13.scn 
b/testsuites/psxtests/psx13/psx13.scn
index 428a931..ee99867 100644
--- a/testsuites/psxtests/psx13/psx13.scn
+++ b/testsuites/psxtests/psx13/psx13.scn
@@ -1,16 +1,16 @@
 *** POSIX TEST 13 ***
 
 Files initialized successfully.
-Testing device_lseek()... Failed!!!
-Testing dup() Failed!!!
-Testing dup2()... Success.
-Testing fdatasync().. Success.
-Testing umask().. Success.
-Testing utime().. Success.
-Testing utimes().. Success.
-Testing fsync().. Success.
-Testing pathconf()... Success.
-Testing fpathconf().. Success.
-Testing sync().. 
+Testing lseek() on device... Success.
+Testing dup()... Success.
+Testing dup2().. Success.
+Testing fdatasync(). Success.
+Testing umask(). Success.
+Testing utime(). Success.
+Testing utimes() Success.
+Testing fsync(). Success.
+Testing pathconf().. Success.
+Testing fpathconf(). Success.
+Testing sync().. Success.
 
-*** END OF TEST PSX13 ***
+*** END OF TEST PSX 13 ***
diff --git a/testsuites/psxtests/psx13/test.c b/testsuites/psxtests/psx13/test.c
index 79b24c2..2d25b02 100644
--- a/testsuites/psxtests/psx13/test.c
+++ b/testsuites/psxtests/psx13/test.c
@@ -1,26 +1,49 @@
-/*
- *  Psx13
- *  Chris Bond (working under Jennifer's account)
+/**
+ *  @file
+ *
+ *  @brief This tests various file system functions.
  *
  *  This test exercises the following routines:
  *
- * device_lseek - test implemented
- * dup  - test implemented
- * dup2 - test implemented
- * fdatasync- test implemented
- * fsync- test implemented
- * pathconf - test implemented
- * fpathconf- test implemented
- * umask- test implemented
- * utime- test implemented
- * utimes   - test implemented
+ * - lseek()
+ * - dup()
+ * - dup2()
+ * - fdatasync()
+ * - fsync()
+ * - pathconf()
+ * - fpathconf()
+ * - umask()
+ * - utime()
+ * - utimes()
+ * - sync()
+ */
+
+/*
+ *  SPDX-License-Identifier: BSD-2-Clause
  *
- *  COPYRIGHT (c) 1989-2009.
+ *  COPYRIGHT (c) 1989-2009, 2021.
  *  On-Line Applications Research Corporation (OAR).
  *
- *  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.
  */
 
 #ifdef HAVE_CONFIG_H
@@ -34,6 +57,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -42,685 +66,428 @@
 
 const char rtems_test_name[] = "PSX 13";
 
-int InitFiles(void);
-int DeviceLSeekTest(void);
-int DupTest(void);
-int Dup2Test(void);
-int FDataSyncTest(void);
-int UMaskTest(void);
-int UTimeTest(void);
-int UTimesTest(void);
-int PathConfTest(void);
-int FPathConfTest(void);
-int FSyncTest(void);
-
-/*---
- * InitFiles function
- *
- * Initializes the three files to be used in the test.
- *
- * arguments: none
- * assumptions: fopen, fprintf, fwrite, FILE are available
- * actions: creates testfile1, a text file with 'a'..'z' listed 4 times.
- *  creates testfile2, a text file with 'a'..'z' listed 4 times.
- *  creates testfile3, a binary file with 0

[PATCH] sb: Merge mailer changes from rtems-tools

[Alex White]

This adds the improved mailer.py script from rtems-tools.

Closes #4388
---
 source-builder/sb/mailer.py | 192 ++--
 source-builder/sb/options.py|   9 ++
 source-builder/sb/setbuilder.py |   2 +
 3 files changed, 171 insertions(+), 32 deletions(-)

diff --git a/source-builder/sb/mailer.py b/source-builder/sb/mailer.py
index ff25df5..ee5bf07 100644
--- a/source-builder/sb/mailer.py
+++ b/source-builder/sb/mailer.py
@@ -1,21 +1,32 @@
 #
 # RTEMS Tools Project (http://www.rtems.org/)
-# Copyright 2013 Chris Johns (chr...@rtems.org)
+# Copyright 2013-2016 Chris Johns (chr...@rtems.org)
 # All rights reserved.
 #
 # This file is part of the RTEMS Tools package in 'rtems-tools'.
 #
-# Permission to use, copy, modify, and/or distribute this software for any
-# purpose with or without fee is hereby granted, provided that the above
-# copyright notice and this permission notice appear in all copies.
+# 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 HOLDER 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.
 #
-# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
-# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
-# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
-# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
-# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
-# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
-# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 
 #
 # Manage emailing results or reports.
@@ -28,18 +39,71 @@ import smtplib
 import socket
 
 from . import error
+from . import execute
 from . import options
 from . import path
 
+_options = {
+'--mail' : 'Send email report or results.',
+'--use-gitconfig': 'Use mail configuration from git config.',
+'--mail-to'  : 'Email address to send the email to.',
+'--mail-from': 'Email address the report is from.',
+'--smtp-host': 'SMTP host to send via.',
+'--smtp-port': 'SMTP port to send via.',
+'--smtp-user': 'User for SMTP authentication.',
+'--smtp-password': 'Password for SMTP authentication.'
+}
+
 def append_options(opts):
-opts['--mail'] = 'Send email report or results.'
-opts['--smtp-host'] = 'SMTP host to send via.'
-opts['--mail-to'] = 'Email address to send the email too.'
-opts['--mail-from'] = 'Email address the report is from.'
+for o in _options:
+opts[o] = _options[o]
+
+def add_arguments(argsp):
+argsp.add_argument('--mail', help = _options['--mail'], action = 
'store_true')
+argsp.add_argument('--use-gitconfig', help = _options['--use-gitconfig'], 
action = 'store_true')
+for o in list(_options)[1:]:
+argsp.add_argument(o, help = _options[o], type = str)
 
 class mail:
 def __init__(self, opts):
 self.opts = opts
+self.gitconfig_lines = None
+if opts.find_arg('--use-gitconfig') is not None:
+# Read the output of `git config --list` instead of reading the
+# .gitconfig file directly because Python 2 ConfigParser does not
+# accept tabs at the beginning of lines.
+e = execute.capture_execution()
+exit_code, proc, output = e.open('git config --list', shell=True)
+if exit_code == 0:
+self.gitconfig_lines = output.split(os.linesep)
+
+def _args_are_macros(self):
+return isinstance(self.opts, options.command_line)
+
+def _get_arg(self, arg):
+if self._args_are_macros():
+value = self.opts.find_arg(arg)
+if value is not None:
+value = self.opts.find_arg(arg)[1]
+else:
+if arg.startswith('--'):
+   

Re: [PATCH] sb: Merge mailer changes from rtems-tools

[Chris Johns]

Hi Alex,

Is there a chance the password can end up in a log file?

See...
https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/options.py#n584

Chris

On 22/4/21 8:00 am, Alex White wrote:
> This adds the improved mailer.py script from rtems-tools.
> 
> Closes #4388
> ---
>  source-builder/sb/mailer.py | 192 ++--
>  source-builder/sb/options.py|   9 ++
>  source-builder/sb/setbuilder.py |   2 +
>  3 files changed, 171 insertions(+), 32 deletions(-)
> 
> diff --git a/source-builder/sb/mailer.py b/source-builder/sb/mailer.py
> index ff25df5..ee5bf07 100644
> --- a/source-builder/sb/mailer.py
> +++ b/source-builder/sb/mailer.py
> @@ -1,21 +1,32 @@
>  #
>  # RTEMS Tools Project (http://www.rtems.org/)
> -# Copyright 2013 Chris Johns (chr...@rtems.org)
> +# Copyright 2013-2016 Chris Johns (chr...@rtems.org)
>  # All rights reserved.
>  #
>  # This file is part of the RTEMS Tools package in 'rtems-tools'.
>  #
> -# Permission to use, copy, modify, and/or distribute this software for any
> -# purpose with or without fee is hereby granted, provided that the above
> -# copyright notice and this permission notice appear in all copies.
> +# 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 HOLDER 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.
>  #
> -# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> -# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> -# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> -# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> -# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> -# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> -# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
>  
>  #
>  # Manage emailing results or reports.
> @@ -28,18 +39,71 @@ import smtplib
>  import socket
>  
>  from . import error
> +from . import execute
>  from . import options
>  from . import path
>  
> +_options = {
> +'--mail' : 'Send email report or results.',
> +'--use-gitconfig': 'Use mail configuration from git config.',
> +'--mail-to'  : 'Email address to send the email to.',
> +'--mail-from': 'Email address the report is from.',
> +'--smtp-host': 'SMTP host to send via.',
> +'--smtp-port': 'SMTP port to send via.',
> +'--smtp-user': 'User for SMTP authentication.',
> +'--smtp-password': 'Password for SMTP authentication.'
> +}
> +
>  def append_options(opts):
> -opts['--mail'] = 'Send email report or results.'
> -opts['--smtp-host'] = 'SMTP host to send via.'
> -opts['--mail-to'] = 'Email address to send the email too.'
> -opts['--mail-from'] = 'Email address the report is from.'
> +for o in _options:
> +opts[o] = _options[o]
> +
> +def add_arguments(argsp):
> +argsp.add_argument('--mail', help = _options['--mail'], action = 
> 'store_true')
> +argsp.add_argument('--use-gitconfig', help = 
> _options['--use-gitconfig'], action = 'store_true')
> +for o in list(_options)[1:]:
> +argsp.add_argument(o, help = _options[o], type = str)
>  
>  class mail:
>  def __init__(self, opts):
>  self.opts = opts
> +self.gitconfig_lines = None
> +if opts.find_arg('--use-gitconfig') is not None:
> +# Read the output of `git config --list` instead of reading the
> +# .gitconfig file directly because Python 2 ConfigParser does not
> +# accept tabs at the beginning of lines.
> +e = execute.capture_execution()
> +exit_code, proc, output = e.open('git config --list', shell=True)
> +if exit_code == 0:
> +   

Re: [PATCH] sb: Merge mailer changes from rtems-tools

[Alex White]

On Wed, Apr 21, 2021 at 5:06 PM Chris Johns  wrote:
>
> Hi Alex,
>
> Is there a chance the password can end up in a log file?

I did not see the command line options in the email when I sent it to myself so 
it wasn't on my radar, but it could have ended up in a log file, yes.

I should do the same thing to this that I did in rtems-tools here: 
https://git.rtems.org/rtems-tools/commit/?id=92f7f67297b9053e6846760e6c8059be0fa1c86c

Would that change to remove sensitive command line options make this patch 
acceptable?

Thanks,

Alex

>
> See...
> https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/options.py#n584
>
> Chris
>
> On 22/4/21 8:00 am, Alex White wrote:
> > This adds the improved mailer.py script from rtems-tools.
> >
> > Closes #4388
> > ---
> >  source-builder/sb/mailer.py | 192 ++--
> >  source-builder/sb/options.py|   9 ++
> >  source-builder/sb/setbuilder.py |   2 +
> >  3 files changed, 171 insertions(+), 32 deletions(-)
> >
> > diff --git a/source-builder/sb/mailer.py b/source-builder/sb/mailer.py
> > index ff25df5..ee5bf07 100644
> > --- a/source-builder/sb/mailer.py
> > +++ b/source-builder/sb/mailer.py
> > @@ -1,21 +1,32 @@
> >  #
> >  # RTEMS Tools Project (http://www.rtems.org/)
> > -# Copyright 2013 Chris Johns (chr...@rtems.org)
> > +# Copyright 2013-2016 Chris Johns (chr...@rtems.org)
> >  # All rights reserved.
> >  #
> >  # This file is part of the RTEMS Tools package in 'rtems-tools'.
> >  #
> > -# Permission to use, copy, modify, and/or distribute this software for any
> > -# purpose with or without fee is hereby granted, provided that the above
> > -# copyright notice and this permission notice appear in all copies.
> > +# 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 HOLDER 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.
> >  #
> > -# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> > -# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> > -# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> > -# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> > -# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> > -# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> > -# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> >
> >  #
> >  # Manage emailing results or reports.
> > @@ -28,18 +39,71 @@ import smtplib
> >  import socket
> >
> >  from . import error
> > +from . import execute
> >  from . import options
> >  from . import path
> >
> > +_options = {
> > +'--mail' : 'Send email report or results.',
> > +'--use-gitconfig': 'Use mail configuration from git config.',
> > +'--mail-to'  : 'Email address to send the email to.',
> > +'--mail-from': 'Email address the report is from.',
> > +'--smtp-host': 'SMTP host to send via.',
> > +'--smtp-port': 'SMTP port to send via.',
> > +'--smtp-user': 'User for SMTP authentication.',
> > +'--smtp-password': 'Password for SMTP authentication.'
> > +}
> > +
> >  def append_options(opts):
> > -opts['--mail'] = 'Send email report or results.'
> > -opts['--smtp-host'] = 'SMTP host to send via.'
> > -opts['--mail-to'] = 'Email address to send the email too.'
> > -opts['--mail-from'] = 'Email address the report is from.'
> > +for o in _options:
> > +opts[o] = _options[o]
> > +
> > +def add_arguments(argsp):
> > +argsp.add_argument('--mail', help = _options['--mail'], action = 
> > 'store_true')
> > +argsp.add_argument('--use-gitconfig', help = 
> > _options['--use-gitconfig'], action = 'store_

Re: [PATCH] sb: Merge mailer changes from rtems-tools

[Chris Johns]

On 22/4/21 11:48 am, Alex White wrote:
> 
> On Wed, Apr 21, 2021 at 5:06 PM Chris Johns  wrote:
>>
>> Hi Alex,
>>
>> Is there a chance the password can end up in a log file?
> 
> I did not see the command line options in the email when I sent it to myself 
> so
> it wasn't on my radar, but it could have ended up in a log file, yes.
> 
> I should do the same thing to this that I did in rtems-tools
> here: 
> https://git.rtems.org/rtems-tools/commit/?id=92f7f67297b9053e6846760e6c8059be0fa1c86c
> 
> 
> Would that change to remove sensitive command line options make this patch
> acceptable?

Perfect. Please send a v2 :)

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

Re: [PATCH RTEMS v2 0/1] bsp/beagle: Refactored i2c driver and Updated

[Niteesh G. S.]

Hello Christian,

Reminder to push the patches.

Thanks,
Niteesh

On Sun, Apr 18, 2021 at 11:57 PM Christian Mauderer 
wrote:

> Hello Niteesh,
>
> looks good to me. I'll wait two or three days before pushing so that
> others can review the libbsd patch too. Please ping me on Wednesday if I
> didn't push it by then.
>
> Best regards
>
> Christian
>
> On 18/04/2021 17:19, Niteesh G. S. wrote:
> > Hello Christian,
> >
> > On Sun, Apr 18, 2021 at 4:54 PM Christian Mauderer  > > wrote:
> >
> > Hello Niteesh,
> >
> > sorry for not taking a look earlier.
> >
> > No problem
> >
> >
> > The patches seem OK for me. Just a tiny change request:
> >
> > I know that I suggested the "rtems,path" for the device tree. When
> > testing I noted that we have the rtems-i2c driver in libbsd which is
> > more or less just a compatibility layer between libbsd and RTEMS.
> This
> > driver uses "rtems,i2c-path" instead of "rtems,path". Maybe you could
> > add one of these two solutions:
> >
> > 1. Either change "rtems,path" to "rtems,i2c-path" in your driver.
> >
> > 2. Or add "rtems,path" as an additional possible path to
> > "libbsd/rtemsbsd/sys/dev/iicbus/rtems-i2c.c". Basically that would
> just
> > mean that in the error case of the current OF_getprop_alloc you just
> > try
> > the "rtems,path" before failing.
> >
> > I really like the short and universal name of "rtems,path" so I would
> > prefer the second solution. But I would be OK with the first one too.
> >
> >
> > I have sent a patch for your preferred solution.
> > Patches that are pending are:
> > 1) https://lists.rtems.org/pipermail/devel/2021-April/066458.html
> > 
> > 2) https://lists.rtems.org/pipermail/devel/2021-April/066460.html
> > 
> > 3) https://lists.rtems.org/pipermail/devel/2021-April/066629.html
> > 
> >
> > Thanks,
> > Niteesh.
> >
> >
> > Best regards
> >
> > Christian
> >
> > On 18/04/2021 06:20, Niteesh G. S. wrote:
> >  > ping.
> >  >
> >  > On Sun, Apr 11, 2021 at 12:45 AM G S Niteesh Babu
> > mailto:niteesh...@gmail.com>
> >  > >>
> wrote:
> >  >
> >  > The following two patches update the Beagle BSP i2c driver to
> use
> >  > device tree based initialization and the documentation
> related to
> >  > it.
> >  >
> >  > G S Niteesh Babu (1):
> >  >bsps/beagle: Refactored i2c driver
> >  >
> >  >   bsps/arm/beagle/i2c/bbb-i2c.c | 122
> > ++
> >  >   bsps/arm/beagle/include/bsp.h |   4 +
> >  >   bsps/arm/beagle/include/bsp/i2c.h |  32 +---
> >  >   bsps/arm/beagle/start/bspstart.c  |  51 +
> >  >   4 files changed, 114 insertions(+), 95 deletions(-)
> >  >
> >  > --
> >  > 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