Re: [PATCH] Correct NUCLEO-H743ZI Ethernet Pins

[Robin Müller]

Hi Sebastian,

How can i specify a define to only be generated for a certain variant and
nothing for default?

Kind Regards
Robin

On Thu, 22 Apr 2021 at 19:56, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
> On 22/04/2021 19:35, Robin Mueller wrote:
> >
>
> Please change this to (add an option for STM32H7_ETH_GPIOB_PINS)
>
> #ifdef STM32H7_ETH_GPIOB_PINS
>
> > +static const stm32h7_gpio_config gpiob = {
> > +  .regs = GPIOB,
> > +  .config = {
> > +.Pin = GPIO_PIN_13,
> > +.Mode = GPIO_MODE_AF_PP,
> > +.Pull = GPIO_NOPULL,
> > +.Speed = GPIO_SPEED_FREQ_LOW,
> > +.Alternate = GPIO_AF11_ETH
> > +  }
> > +};
> > +
> >   void
> >   HAL_ETH_MspInit(ETH_HandleTypeDef *heth)
> >   {
> > @@ -73,4 +86,7 @@ HAL_ETH_MspInit(ETH_HandleTypeDef *heth)
> > stm32h7_gpio_init(&gpiog);
> > stm32h7_gpio_init(&gpioc);
> > stm32h7_gpio_init(&gpioa);
> > +#if RTEMS_BSP == nucleo-h743zi
>
> #ifdef STM32H7_ETH_GPIOB_PINS
>
> There should be not checks which use the BSP name.
>
> > +  stm32h7_gpio_init(&gpiob);
> > +#endif
> >   }
>
> --
> 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] Correct NUCLEO-H743ZI Ethernet Pins

[Sebastian Huber]

On 23/04/2021 09:44, Robin Müller wrote:



How can i specify a define to only be generated for a certain variant 
and nothing for default?

Yes, just use "default: null".

--
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 3/4] Additional define for stmh32xx_hal_uart.h

[Robin Müller]

Ping :)

On Mon, 12 Apr 2021 at 11:56, Robin.Mueller 
wrote:

> The DMA include was missing and could lead to compilation
> errors for certain cases.
> ---
>  bsps/arm/stm32h7/include/stm32h7xx_hal_uart.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/bsps/arm/stm32h7/include/stm32h7xx_hal_uart.h
> b/bsps/arm/stm32h7/include/stm32h7xx_hal_uart.h
> index e9fecc4aa0..b171f7dac7 100644
> --- a/bsps/arm/stm32h7/include/stm32h7xx_hal_uart.h
> +++ b/bsps/arm/stm32h7/include/stm32h7xx_hal_uart.h
> @@ -27,6 +27,7 @@ extern "C" {
>
>  /* Includes
> --*/
>  #include "stm32h7xx_hal_def.h"
> +#include "stm32h7xx_hal_dma.h"
>
>  /** @addtogroup STM32H7xx_HAL_Driver
>* @{
> --
> 2.25.1
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 2/2] added GPIOB option for STM32 ETH config

[Robin Mueller]

Follow-up patch to avoid checks against the BSP name.
Separate option to only define the pins for nucleo-h743zi BSP

---
 bsps/arm/stm32h7/start/stm32h7-hal-eth.c  |  8 ++--
 spec/build/bsps/arm/stm32h7/grp.yml   |  2 ++
 .../bsps/arm/stm32h7/optethgpiobregs.yml  | 19 +++
 .../bsps/arm/stm32h7/optethgpiogregs.yml  |  2 +-
 4 files changed, 28 insertions(+), 3 deletions(-)
 create mode 100644 spec/build/bsps/arm/stm32h7/optethgpiobregs.yml

diff --git a/bsps/arm/stm32h7/start/stm32h7-hal-eth.c 
b/bsps/arm/stm32h7/start/stm32h7-hal-eth.c
index 0a128e4e5a..b9dac6d7f9 100644
--- a/bsps/arm/stm32h7/start/stm32h7-hal-eth.c
+++ b/bsps/arm/stm32h7/start/stm32h7-hal-eth.c
@@ -66,10 +66,12 @@ static const stm32h7_gpio_config gpioa = {
   }
 };
 
+#ifdef STM32H7_ETH_GPIOB_PINS
+
 static const stm32h7_gpio_config gpiob = {
   .regs = GPIOB,
   .config = {
-.Pin = GPIO_PIN_13,
+.Pin = STM32H7_ETH_GPIOB_PINS,
 .Mode = GPIO_MODE_AF_PP,
 .Pull = GPIO_NOPULL,
 .Speed = GPIO_SPEED_FREQ_LOW,
@@ -77,6 +79,8 @@ static const stm32h7_gpio_config gpiob = {
   }
 };
 
+#endif
+
 void
 HAL_ETH_MspInit(ETH_HandleTypeDef *heth)
 {
@@ -86,7 +90,7 @@ HAL_ETH_MspInit(ETH_HandleTypeDef *heth)
   stm32h7_gpio_init(&gpiog);
   stm32h7_gpio_init(&gpioc);
   stm32h7_gpio_init(&gpioa);
-#if RTEMS_BSP == nucleo-h743zi
+#ifdef STM32H7_ETH_GPIOB_PINS
   stm32h7_gpio_init(&gpiob);
 #endif
 }
diff --git a/spec/build/bsps/arm/stm32h7/grp.yml 
b/spec/build/bsps/arm/stm32h7/grp.yml
index 9e35cb49ac..a7e7affa05 100644
--- a/spec/build/bsps/arm/stm32h7/grp.yml
+++ b/spec/build/bsps/arm/stm32h7/grp.yml
@@ -85,6 +85,8 @@ links:
   uid: optvariant
 - role: build-dependency
   uid: optethgpiogregs
+- role: build-dependency
+  uid: optethgpiobregs
 - role: build-dependency
   uid: ../../optconsolebaud
 - role: build-dependency
diff --git a/spec/build/bsps/arm/stm32h7/optethgpiobregs.yml 
b/spec/build/bsps/arm/stm32h7/optethgpiobregs.yml
new file mode 100644
index 00..fcd720f186
--- /dev/null
+++ b/spec/build/bsps/arm/stm32h7/optethgpiobregs.yml
@@ -0,0 +1,19 @@
+actions:
+- get-string: null
+- define-unquoted: null
+build-type: option
+default: null
+default-by-variant:
+- value: GPIO_PIN_13
+  variants:
+  - arm/nucleo-h743zi
+enabled-by: true
+format: '{}'
+links: []
+name: STM32H7_ETH_GPIOB_PINS
+description: |
+  GPIO B pins used for the ETH pin configuration.
+type: build
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+copyrights:
+- Copyright (C) 2021 embedded brains GmbH (http://www.embedded-brains.de)
diff --git a/spec/build/bsps/arm/stm32h7/optethgpiogregs.yml 
b/spec/build/bsps/arm/stm32h7/optethgpiogregs.yml
index b76e19eb36..a6c0acbb7d 100644
--- a/spec/build/bsps/arm/stm32h7/optethgpiogregs.yml
+++ b/spec/build/bsps/arm/stm32h7/optethgpiogregs.yml
@@ -12,7 +12,7 @@ format: '{}'
 links: []
 name: STM32H7_ETH_GPIOG_PINS
 description: |
-  GPIO pins used for the ETH pin configuration.
+  GPIO G pins used for the ETH pin configuration.
 type: build
 SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
 copyrights:
-- 
2.25.1

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

Re: [PATCH] Correct NUCLEO-H743ZI Ethernet Pins

[Robin Müller]

I sent a follow-up patch.

Kind Regards
Robin

On Fri, 23 Apr 2021 at 09:45, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 23/04/2021 09:44, Robin Müller wrote:
>
> >
> > How can i specify a define to only be generated for a certain variant
> > and nothing for default?
> Yes, just use "default: null".
>
> --
> 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] Nucleo UART3 (console) pins correction

[Robin Mueller]

Now using default pins
---
 spec/build/bsps/arm/stm32h7/optusart3gpiopins.yml | 5 +
 spec/build/bsps/arm/stm32h7/optusart3gpioregs.yml | 5 +
 2 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/spec/build/bsps/arm/stm32h7/optusart3gpiopins.yml 
b/spec/build/bsps/arm/stm32h7/optusart3gpiopins.yml
index dd236421c8..87aad00ee0 100644
--- a/spec/build/bsps/arm/stm32h7/optusart3gpiopins.yml
+++ b/spec/build/bsps/arm/stm32h7/optusart3gpiopins.yml
@@ -3,10 +3,7 @@ actions:
 - define-unquoted: null
 build-type: option
 default: ( GPIO_PIN_8 | GPIO_PIN_9 )
-default-by-variant:
-- value: ( GPIO_PIN_9 | GPIO_PIN_10 )
-  variants:
-  - arm/nucleo-h743zi
+default-by-variant: []
 enabled-by: true
 format: '{}'
 links: []
diff --git a/spec/build/bsps/arm/stm32h7/optusart3gpioregs.yml 
b/spec/build/bsps/arm/stm32h7/optusart3gpioregs.yml
index fa3e05b3ba..7168a00111 100644
--- a/spec/build/bsps/arm/stm32h7/optusart3gpioregs.yml
+++ b/spec/build/bsps/arm/stm32h7/optusart3gpioregs.yml
@@ -3,10 +3,7 @@ actions:
 - define-unquoted: null
 build-type: option
 default: GPIOD
-default-by-variant:
-- value: GPIOB
-  variants:
-  - arm/nucleo-h743zi
+default-by-variant: []
 enabled-by: true
 format: '{}'
 links: []
-- 
2.25.1

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

Re: Qemu for ultra96

[Alireza Banejad]

thank you for your response,
i understood your second option but I somewhat haven't understood your
first option. isn't the code written for the ultra96 BSP already meant to
be 32-bit?
would you give me a further explanation?

On Thu, Apr 22, 2021 at 8:29 PM Kinsey Moore 
wrote:

> On 4/22/2021 08:47, Alireza Banejad wrote:
> > Hello
> > I want to know could I run applications for the ultra96 bsp in qemu?
> > I tried the qemu-system-arm with the virt machine and cpu specified as
> > cortex-a7 yet I don't get anything
> > I also tried the qemu-system-aarch64 specifying the machine as
> > xlnx-zcu102 and it still couldn't run the application.
> > BTW the application is just the hello sample from the testsuite
> > In reality I actually could run applications that were built with the
> > xilinx_zynqmp_ultra96 on a actual zcu102 board
> > But I don't understand why this doesn't happen in qemu
> > I don't have the board right now that why I need to test my
> > applications in qemu
> > Long story short, how can I run my applications built for
> > xilinx_zynqmp_ultra96 in qemu??
> >
> The issue that you're having is that the ARM xilinx_zynqmp_ultra96 BSP
> is designed to run on the Ultrascale+ ZynqMP chip in 32-bit mode instead
> of 64-bit mode. qemu-system-aarch64 is the correct QEMU to use, but it
> starts in EL1/AArch64 mode by default. I haven't seen a way to directly
> start AArch32/ARMv7 code on the virtualized Cortex-A53 CPU, but on real
> hardware it would be controlled by the AA64nAA32 signal line. From what
> I can find, similar discussions have happened around the Raspberry Pi
> platform and as of 2019 there was no way to configure direct boot to
> AArch32.
>
> Two viable options:
>
> Write a piece of shim code to drop from EL1 to 32-bit mode based on the
> ARMv8 bare metal boot code (what you need is there, almost verbatim).
>
> Recompile QEMU to get the functionality you want (the relevant code is
> in hw/arm/boot.c, look for EM_AARCH64).
>
>
> Kinsey
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS on PolarFire SoC ICICLE Kit FPGA

[Karel Gardas]

Hi Somesh,

your information are very interesting. Is it possible for your to send a
diff of your changes?

Thanks,
Karel

On 4/23/21 5:52 AM, somesh deshmukh wrote:
> I was able to test the rtems hello-world example and ticker example on
> the polarfire soc icicle kit.
> 
> A little background about Polarfire SoC ICICLE Kit.
> The PolarFire SoC Icicle kit is a low-cost development platform that
> enables the evaluation of the five-core Linux capable RISC-V
> microprocessor subsystem. It includes
> 
>   * SiFive E51 Monitor core (1 x RV64IMAC)
>   * SiFive U54 Application cores (4 x RV64GC)
> 
> More info is available at the link below:
> https://www.microsemi.com/existing-parts/parts/152514
> 
> 
> There were few changes I had to make in the rtems source code to make it
> work, as mentioned below.
> 
> 1. In the startup code the bsp_fdt_copy copies the device tree blob from
> the address from #a1 register to the .rodata section. This is followed
> by a memset operation for the bss section.
> The problem was the call to a memset function was clearing the device
> tree blob copied in the bsp_fdt_copy() operation.
> To fix this I performed the memset first and then bsp_fdt_copy operation.
> 
> 2. The riscv_console_probe() will try to read the console_node from the
> device tree. The original code provided for ns16550 UART was not able to
> read the console node from the device tree correctly.
> To fix this I used the sifive code to read the console node. The sifive
> code was limited to only sifive-uart.
> 
> 3. RTEMS uses -O2 as default optimization settings. With these settings,
> we were facing a trap while trying to perform the open call on the
> console device after mounting the file system.
> To fix this I changed the optimization to -O0 and it resolved the issue.
> I need to debug this more to find the exact cause.
> 
> 4. The default clock driver simply assumes that the code is running on
> hart0. This was breaking the ticker example testing.
> To fix this I updated the clock driver to read the hart ID and then
> configure the
> mtimecmp register accordingly.
> 
> Let me know if these changes are valid.
> 
> Regards,
> Somesh
> 
> 
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 

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

Re: [PATCH] Nucleo UART3 (console) pins correction

[Sebastian Huber]

On 23/04/2021 10:18, Robin Mueller wrote:


Now using default pins

Thanks, I checked it in.

--
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] Patch attempt two to avoid nameclash of PAGESIZE define

[Sebastian Huber]

On 21/04/2021 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.


I am still not able to apply this patch.

git am \[PATCH\]\ Patch\ attempt\ two\ to\ avoid\ nameclash\ of\ 
PAGESIZE\ define.eml

Applying: Patch attempt two to avoid nameclash of PAGESIZE define
error: patch failed: bsps/arm/stm32h7/include/Legacy/stm32_hal_legacy.h:31
error: bsps/arm/stm32h7/include/Legacy/stm32_hal_legacy.h: patch does 
not apply

Patch failed at 0001 Patch attempt two to avoid nameclash of PAGESIZE define
hint: Use 'git am --show-current-patch=diff' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

Maybe send the patch as an attachment.

--
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] Implementation for STM32 HAL_GetTick using RTEMS

[Sebastian Huber]

On 22/04/2021 19:17, Robin Mueller wrote:


Accounts for the tick base not being 1ms now.
Perform division first to reduce chance of arithmetic overflow.
---
  bsps/arm/stm32h7/start/bspstart.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/bsps/arm/stm32h7/start/bspstart.c 
b/bsps/arm/stm32h7/start/bspstart.c
index 7ae39f1410..536325293d 100644
--- a/bsps/arm/stm32h7/start/bspstart.c
+++ b/bsps/arm/stm32h7/start/bspstart.c
@@ -35,8 +35,7 @@
  /* Get number of milliseconds elapsed since startup */
  uint32_t HAL_GetTick(void)
  {
-  uint64_t temp = rtems_clock_get_uptime_nanoseconds() / (1000 * 1000);
-  return temp;
+  return (rtems_clock_get_ticks_since_boot() / 
rtems_clock_get_ticks_per_second()) * 1000;
  }
  
  uint32_t stm32h7_systick_frequency(void)


With this calculation the tick increments in one second steps. Maybe 
just use:


return rtems_clock_get_ticks_since_boot() * 
rtems_configuration_get_milliseconds_per_tick().


--
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] Patch attempt two to avoid nameclash of PAGESIZE define

[Robin Müller]

Can you try

git apply --reject --whitespace=fix mychanges.patch

taken from
https://stackoverflow.com/questions/4770177/git-patch-does-not-apply .
This worked for me

Kind Regards
Robin

On Fri, 23 Apr 2021 at 12:32, Robin Müller 
wrote:

> Can you try
>
> git apply --reject --whitespace=fix mychanges.patch
>
> taken from
> https://stackoverflow.com/questions/4770177/git-patch-does-not-apply .
> This worked for me
>
> Kind Regards
> Robin
>
> On Fri, 23 Apr 2021 at 11:42, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 21/04/2021 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.
>>
>> I am still not able to apply this patch.
>>
>> git am \[PATCH\]\ Patch\ attempt\ two\ to\ avoid\ nameclash\ of\
>> PAGESIZE\ define.eml
>> Applying: Patch attempt two to avoid nameclash of PAGESIZE define
>> error: patch failed: bsps/arm/stm32h7/include/Legacy/stm32_hal_legacy.h:31
>> error: bsps/arm/stm32h7/include/Legacy/stm32_hal_legacy.h: patch does
>> not apply
>> Patch failed at 0001 Patch attempt two to avoid nameclash of PAGESIZE
>> define
>> hint: Use 'git am --show-current-patch=diff' to see the failed patch
>> When you have resolved this problem, run "git am --continue".
>> If you prefer to skip this patch, run "git am --skip" instead.
>> To restore the original branch and stop patching, run "git am --abort".
>>
>> Maybe send the patch as an attachment.
>>
>> --
>> 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: RTEMS on PolarFire SoC ICICLE Kit FPGA

[Joel Sherrill]

I agree with Karel that a diff posted would be appreciated. It.would be
nice to see this worked through and merged. Also updates to the Users Guide
on this.

On Thu, Apr 22, 2021, 10:52 PM somesh deshmukh 
wrote:

> I was able to test the rtems hello-world example and ticker example on the
> polarfire soc icicle kit.
>
> A little background about Polarfire SoC ICICLE Kit.
> The PolarFire SoC Icicle kit is a low-cost development platform that
> enables the evaluation of the five-core Linux capable RISC-V microprocessor
> subsystem. It includes
>
>- SiFive E51 Monitor core (1 x RV64IMAC)
>- SiFive U54 Application cores (4 x RV64GC)
>
> More info is available at the link below:
> https://www.microsemi.com/existing-parts/parts/152514
>
> There were few changes I had to make in the rtems source code to make it
> work, as mentioned below.
>
> 1. In the startup code the bsp_fdt_copy copies the device tree blob from
> the address from #a1 register to the .rodata section. This is followed by a
> memset operation for the bss section.
> The problem was the call to a memset function was clearing the device tree
> blob copied in the bsp_fdt_copy() operation.
> To fix this I performed the memset first and then bsp_fdt_copy operation.
>

This sounds like a bug from what you describe. Patch will show.

>
> 2. The riscv_console_probe() will try to read the console_node from the
> device tree. The original code provided for ns16550 UART was not able to
> read the console node from the device tree correctly.
> To fix this I used the sifive code to read the console node. The sifive
> code was limited to only sifive-uart.
>

We'll have to see. This may require more smarts in the console driver to
support both. Or a BSP variant.



> 3. RTEMS uses -O2 as default optimization settings. With these settings,
> we were facing a trap while trying to perform the open call on the console
> device after mounting the file system.
> To fix this I changed the optimization to -O0 and it resolved the issue.
> I need to debug this more to find the exact cause.
>

This is unfortunate. Could be anything from a driver missing a volatile to
bad code generation. You can try at different optimisation levels and that
narrows down things a bit. You are right. This requires debugging.


> 4. The default clock driver simply assumes that the code is running on
> hart0. This was breaking the ticker example testing.
> To fix this I updated the clock driver to read the hart ID and then
> configure the
> mtimecmp register accordingly.
>

This sounds like an improvement.


> Let me know if these changes are valid.
>

Patches welcome and then we shall see.

>
>
> Regards,
> Somesh
>
>
> ___
> 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] c-user: Generate interrupt manager documentation

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

Here is the updated document for review:

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

 c-user/glossary.rst   |5 +
 c-user/interrupt/directives.rst   | 1229 +
 c-user/interrupt/introduction.rst |  101 ++-
 3 files changed, 991 insertions(+), 344 deletions(-)

diff --git a/c-user/glossary.rst b/c-user/glossary.rst
index 16ddcef..0dacef5 100644
--- a/c-user/glossary.rst
+++ b/c-user/glossary.rst
@@ -928,6 +928,11 @@ Glossary
 target
 The system on which the application will ultimately execute.
 
+target architecture
+The target architecture is the instruction set architecture (ISA) of 
the
+:term:`target`.  Some RTEMS features depend on the target 
architecture.  For
+the details consult the *RTEMS CPU Architecture Supplement*.
+
 TAS
 This term is an acronym for Test-And-Set.
 
diff --git a/c-user/interrupt/directives.rst b/c-user/interrupt/directives.rst
index 95181db..ec8a6ff 100644
--- a/c-user/interrupt/directives.rst
+++ b/c-user/interrupt/directives.rst
@@ -1,521 +1,1090 @@
 .. 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
+
+.. _InterruptManagerDirectives:
+
 Directives
 ==
 
-This section details the interrupt 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 Interrupt 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/intr/if/catch
 
 .. raw:: latex
 
-   \clearpage
+\clearpage
 
+.. index:: rtems_interrupt_catch()
 .. index:: establish an ISR
 .. index:: install an ISR
-.. index:: rtems_interrupt_catch
 
-.. _rtems_interrupt_catch:
+.. _InterfaceRtemsInterruptCatch:
 
-INTERRUPT_CATCH - Establish an ISR
---
+rtems_interrupt_catch()
+---
+
+Establishes an interrupt service routine.
+
+.. rubric:: CALLING SEQUENCE:
+
+.. code-block:: c
+
+rtems_status_code rtems_interrupt_catch(
+  rtems_isr_entry new_isr_handler,
+  rtems_vector_number vector,
+  rtems_isr_entry*old_isr_handler
+);
+
+.. rubric:: PARAMETERS:
+
+``new_isr_handler``
+This parameter is the new interrupt service routine.
+
+``vector``
+This parameter is the interrupt vector number.
+
+``old_isr_handler``
+This parameter is the pointer to an :c:type:`rtems_isr_entry` variable.
+When the directive call is successful, the previous interrupt service
+routine established for this interrupt vector will be stored in this
+variable.
+
+.. rubric:: DESCRIPTION:
+
+This directive establishes an interrupt service routine (ISR) for the interrupt
+specified by the ``vector`` number.  The ``new_isr_handler`` parameter
+specifies the entry point of the ISR.  The entry point of the previous ISR for
+the specified vector is returned in ``old_isr_handler``.
+
+To release an interrupt vector, pass the old handler's address obtained when
+the vector was first capture.
+
+.. rubric:: RETURN VALUES:
+
+:c:macro:`RTEMS_SUCCESSFUL`
+The requested operation was successful.
+
+:c:macro:`RTEMS_INVALID_NUMBER`
+The interrupt vector number was illegal.
+
+:c:macro:`RTEMS_INVALID_ADDRESS`
+The ``new_isr_handler`` parameter was `NULL
+`_.
 
-CALLING SEQUENCE:
-.. code-block:: c
+:c:macro:`RTEMS_INVALID_ADDRESS`
+The ``old_isr_handler`` parameter was `NULL
+`_.
 
-rtems_status_code rtems_interrupt_catch(
-  rtems_isr_entry  new_isr_handler,
-  rtems_vector_number  vector,
-  rtems_isr_entry *old_isr_handler
-);
+.. rubric:: CONSTRAINTS:
 
-DIRE

Re: Qemu for ultra96

[Kinsey Moore]

Yes, the ultra96 BSP generates a 32-bit executable. QEMU starts its CPUs 
in 64-bit mode. You would need a small piece of 64-bit AArch64 assembly 
to start on the CPU which would jump into the 32-bit executable. It 
could even theoretically be inlined into start.S as raw machine code.



Kinsey

On 4/23/2021 03:56, Alireza Banejad wrote:

thank you for your response,
i understood your second option but I somewhat haven't understood your 
first option. isn't the code written for the ultra96 BSP already meant 
to be 32-bit?

would you give me a further explanation?

On Thu, Apr 22, 2021 at 8:29 PM Kinsey Moore > wrote:


On 4/22/2021 08:47, Alireza Banejad wrote:
> Hello
> I want to know could I run applications for the ultra96 bsp in qemu?
> I tried the qemu-system-arm with the virt machine and cpu
specified as
> cortex-a7 yet I don't get anything
> I also tried the qemu-system-aarch64 specifying the machine as
> xlnx-zcu102 and it still couldn't run the application.
> BTW the application is just the hello sample from the testsuite
> In reality I actually could run applications that were built
with the
> xilinx_zynqmp_ultra96 on a actual zcu102 board
> But I don't understand why this doesn't happen in qemu
> I don't have the board right now that why I need to test my
> applications in qemu
> Long story short, how can I run my applications built for
> xilinx_zynqmp_ultra96 in qemu??
>
The issue that you're having is that the ARM xilinx_zynqmp_ultra96
BSP
is designed to run on the Ultrascale+ ZynqMP chip in 32-bit mode
instead
of 64-bit mode. qemu-system-aarch64 is the correct QEMU to use,
but it
starts in EL1/AArch64 mode by default. I haven't seen a way to
directly
start AArch32/ARMv7 code on the virtualized Cortex-A53 CPU, but on
real
hardware it would be controlled by the AA64nAA32 signal line. From
what
I can find, similar discussions have happened around the Raspberry Pi
platform and as of 2019 there was no way to configure direct boot to
AArch32.

Two viable options:

Write a piece of shim code to drop from EL1 to 32-bit mode based
on the
ARMv8 bare metal boot code (what you need is there, almost verbatim).

Recompile QEMU to get the functionality you want (the relevant
code is
in hw/arm/boot.c, look for EM_AARCH64).


Kinsey

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


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

Re: [PATCH v1 1/3] cpukit: Add signal mapping support

[Kinsey Moore]

On 4/20/2021 01:44, Chris Johns wrote:

On 20/4/21 4:38 pm, Sebastian Huber wrote:

On 20/04/2021 08:30, Chris Johns wrote:

On 20/4/21 3:54 pm, Sebastian Huber wrote:

On 20/04/2021 07:30, Chris Johns wrote:


We need a way for libdebugger or any other piece of software to capture and
cascade the call. If this can be done on aarch64 then I am happy.

The fatal error extensions execute in a user controllable order. You can for
example register a libdebugger handler which deals with break point exceptions
before the signal mapping handler is called.

Synchronous exceptions should end up in an RTEMS_FATAL_SOURCE_EXCEPTION fatal
error. The fatal code is a pointer to rtems_exception_frame
(CPU_Exception_frame). In this data structure should be the complete state of
the interrupted context (which could be also an interrupt handler). If you want
to resume execution of the interrupted context, then we need an API for this
(setters/getters and some sort of a longjmp()).

I do not think the fatal error handler support is suitable for a debugger, the
frame maybe on the wrong stack. It was more complicated to implement than this
and the reality of what is needed on the ARM required lots more. The fatal error
handler handles fatal errors however surviving a data abort and then continuing
in the correct CPU context/space and stack is much harder to do 

https://git.rtems.org/rtems/tree/cpukit/libdebugger/rtems-debugger-arm.c#n1454

That code has to work with all data and states saved.

Yes, this code is the "some sort of a longjump()". The code mentioned above
doesn't seem to be necessarily libdebugger-specific.

Ah OK we agree :). I would love to see that happen.

The fatal error handler API would then be built on an exception management API.
I personally believe this is a key piece of functionality RTEMS would benefit
from. It would make adding signal support easy.



My initial thoughts on an exception management API (EMAPI):

additional CPU port requirements for EMAPI support:
    provide functions which operate on CPU Exception Frame (CEF)
        get address of exception
        get exception class (these will be as granular as possible 
while still being arch-agnostic)

        set address to resume execution as instruction after exception
        set address to resume execution (arbitrary)

    upon exception, creates CEF on thread stack and calls into EMAPI
    upon return from EMAPI, restores CEF and returns to normal execution

EMAPI:
    No architecture-specific information is directly exposed
        CEF is provided as a handle on which to operate
        architecture-specific details can be pulled from CEF if necessary


    handler gets CEF as only argument
    handler return value determines whether it took final actions based 
on the CEF


    handler list is ordered based on priority, but not otherwise keyed
        a handler that takes a final action prevents execution of 
further handlers


    lowest priority handler is always present (frame dump and fatal 
extensions run here)



Kinsey

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

RTEMS Bootstrap fails

[Richi Dubey]

Hi,

I am building a new RTEMS from master source (to build the
xilinx_zynqmp_lp64 bsp from the aarch64 arch), and these are the steps I
followed:

mkdir -p $HOME/quick-start/src
cd $HOME/quick-start/src
git clone https://github.com/RTEMS/rtems-source-builder.git rsb
git clone https://github.com/RTEMS/rtems.git
cd $HOME/quick-start/src/rsb/rtems
../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6
6/rtems-aarch64
 export PATH=$HOME/quick-start/rtems/6/bin:"$PATH"
cd $HOME/quick-start/src/rtems
./rtems-bootstrap

-And I get this error-:
118/119: autoreconf: c/src/make/configure.ac
119/119: autoreconf: cpukit/configure.ac
automake: error: cannot open < libnetworking/headers.am: No such file or
directory
autoreconf: automake failed with exit status: 1
error: error: autoreconf: autoreconf -i --no-recursive
Bootstrap FAILED.

Can someone please help me with this?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS Bootstrap fails

[Vijay Kumar Banerjee]

Hi Richi,


On Fri, Apr 23, 2021 at 9:22 AM Richi Dubey  wrote:
>
> Hi,
>
> I am building a new RTEMS from master source (to build the xilinx_zynqmp_lp64 
> bsp from the aarch64 arch), and these are the steps I followed:
>
> mkdir -p $HOME/quick-start/src
> cd $HOME/quick-start/src
> git clone https://github.com/RTEMS/rtems-source-builder.git rsb
> git clone https://github.com/RTEMS/rtems.git
> cd $HOME/quick-start/src/rsb/rtems
> ../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6 
> 6/rtems-aarch64
>  export PATH=$HOME/quick-start/rtems/6/bin:"$PATH"
> cd $HOME/quick-start/src/rtems
> ./rtems-bootstrap
>
> -And I get this error-:
> 118/119: autoreconf: c/src/make/configure.ac
> 119/119: autoreconf: cpukit/configure.ac
> automake: error: cannot open < libnetworking/headers.am: No such file or 
> directory
> autoreconf: automake failed with exit status: 1
> error: error: autoreconf: autoreconf -i --no-recursive
> Bootstrap FAILED.
>

Please try using waf.

echo "[aarch64/xilinx_zynqmp_lp64]" > config.ini
echo "BUILD_TESTS=True" >> config.ini
./waf configure
./waf
./waf install

> Can someone please help me with this?

I hope the above instructions will build it without issues.

Best regards,
Vijay
> ___
> 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] c-user: Generate scheduling concepts documentation

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

Here is the updated document for review:

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

 c-user/scheduling-concepts/directives.rst   | 885 +---
 c-user/scheduling-concepts/introduction.rst |  86 +-
 2 files changed, 646 insertions(+), 325 deletions(-)

diff --git a/c-user/scheduling-concepts/directives.rst 
b/c-user/scheduling-concepts/directives.rst
index 5b1246f..f80c5bd 100644
--- a/c-user/scheduling-concepts/directives.rst
+++ b/c-user/scheduling-concepts/directives.rst
@@ -1,424 +1,701 @@
 .. SPDX-License-Identifier: CC-BY-SA-4.0
 
-.. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
+.. Copyright (C) 2013, 2021 embedded brains GmbH 
(http://www.embedded-brains.de)
+.. Copyright (C) 1988, 2017 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
+
+.. _SchedulerManagerDirectives:
 
 Directives
 ==
 
-This section details the scheduler manager.  A subsection is dedicated to each
-of these services and describes the calling sequence, related constants, usage,
-and status codes.
+This section details the directives of the Scheduler 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/scheduler/if/ident
 
 .. raw:: latex
 
-   \clearpage
+\clearpage
 
-.. _rtems_scheduler_ident:
+.. index:: rtems_scheduler_ident()
 
-SCHEDULER_IDENT - Get ID of a scheduler

+.. _InterfaceRtemsSchedulerIdent:
+
+rtems_scheduler_ident()
+---
+
+Identifies a scheduler by the object name.
+
+.. rubric:: CALLING SEQUENCE:
+
+.. code-block:: c
+
+rtems_status_code rtems_scheduler_ident( rtems_name name, rtems_id *id );
+
+.. rubric:: PARAMETERS:
+
+``name``
+This parameter is the scheduler name to look up.
+
+``id``
+This parameter is the pointer to an object identifier variable.  When the
+directive call is successful, the identifier of the scheduler will be
+stored in this variable.
 
-CALLING SEQUENCE:
-.. code-block:: c
+.. rubric:: DESCRIPTION:
 
-rtems_status_code rtems_scheduler_ident(
-rtems_name  name,
-rtems_id   *id
-);
+This directive obtains a scheduler identifier associated with the scheduler
+name specified in ``name``.
 
-DIRECTIVE STATUS CODES:
-.. list-table::
- :class: rtems-table
+.. rubric:: RETURN VALUES:
 
- * - ``RTEMS_SUCCESSFUL``
-   - Successful operation.
- * - ``RTEMS_INVALID_ADDRESS``
-   - The ``id`` parameter is ``NULL``.
- * - ``RTEMS_INVALID_NAME``
-   - Invalid scheduler name.
+:c:macro:`RTEMS_SUCCESSFUL`
+The requested operation was successful.
 
-DESCRIPTION:
-Identifies a scheduler by its name.  The scheduler name is determined by
-the scheduler configuration.  See :ref:`ConfigurationSchedulerTable`
-and :ref:`CONFIGURE_SCHEDULER_NAME`.
+:c:macro:`RTEMS_INVALID_NAME`
+There was no scheduler associated with the name.
 
-NOTES:
-None.
+:c:macro:`RTEMS_INVALID_ADDRESS`
+The ``id`` parameter was `NULL
+`_.
+
+.. rubric:: NOTES:
+
+The scheduler name is determined by the scheduler configuration.
+
+The scheduler identifier is used with other scheduler related directives to
+access the scheduler.
+
+.. rubric:: CONSTRAINTS:
+
+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.
+
+.. Generated from spec:/rtems/scheduler/if/ident-by-processor
 
 .. raw:: latex
 
-   \clearpage
+\clearpage
+
+.. index:: rtems_scheduler_ident_by_processor()
+
+.. _InterfaceRtemsSchedulerIdentByProcessor:
 
-.. _rtems_scheduler_ident_by_processor:
+rtems_scheduler_ident_by_processor()
+
 
-SCHEDULER_IDENT_BY_PROCESSOR - Get ID of a scheduler by processor
--
+Iden

Re: [PATCH] psx13: Reworked and relicensed

[Joel Sherrill]

On Thu, Apr 22, 2021 at 11:06 AM Ryan Long  wrote:

> >> +#ifdef __sparc__
> >What's this for?
> Joel said this was a special case, and that it needed to be put in, so I'm
> not sure.
>

https://git.rtems.org/rtems/tree/cpukit/posix/src/sysconf.c#n57

This was to support code in GCC which had hard-coded calls to this sysconf()
in the SPARC backend but I grep'ed for them and didn't find them on master.
Admittedly, I checked all the way back to egcs 1.1 and didn't find it there
either
so I am probably not looking right.

If we are sure this isn't in GCC anymore, then it can be removed in a
follow up
patch.


> For the printf's in test_main(), I should take out all of the print
> statements saying
>
> "Testing .Success"?
>
>
>
> -Original Message-
> From: Gedare Bloom 
> Sent: Thursday, April 22, 2021 8:45 AM
> To: Ryan Long 
> Cc: devel@rtems.org
> Subject: Re: [PATCH] psx13: Reworked and relicensed
>
> See below for comments. This test suite might be a good candidate for
> conversion to T_TEST_CASE framework. At any rate, this refactor is a marked
> improvement.
>
> On Wed, Apr 21, 2021 at 2:57 PM Ryan Long  wrote:
> >
> > Changed the way the tests were structured, added
> > rtems_test_assert()'s, updated psx13.scn and the license.
>
> relicense changes should generally Update #3899.
>
> > ---
> >  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()
> > + */
> > +
>
> While you're at it, please conform to
>
> https://docs.rtems.org/branches/master/eng/coding-file-hdr.html#c-c-header-file-template
>
> > +/*
> > + *  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 othe

Re: [PATCH] psx13: Reworked and relicensed

[Joel Sherrill]

On Fri, Apr 23, 2021 at 3:08 PM Joel Sherrill  wrote:

>
>
> On Thu, Apr 22, 2021 at 11:06 AM Ryan Long  wrote:
>
>> >> +#ifdef __sparc__
>> >What's this for?
>> Joel said this was a special case, and that it needed to be put in, so
>> I'm not sure.
>>
>
> https://git.rtems.org/rtems/tree/cpukit/posix/src/sysconf.c#n57
>
> This was to support code in GCC which had hard-coded calls to this
> sysconf()
> in the SPARC backend but I grep'ed for them and didn't find them on master.
> Admittedly, I checked all the way back to egcs 1.1 and didn't find it
> there either
> so I am probably not looking right.
>
> If we are sure this isn't in GCC anymore, then it can be removed in a
> follow up
> patch.
>
>
>> For the printf's in test_main(), I should take out all of the print
>> statements saying
>>
>> "Testing .Success"?
>>
>>
>>
>> -Original Message-
>> From: Gedare Bloom 
>> Sent: Thursday, April 22, 2021 8:45 AM
>> To: Ryan Long 
>> Cc: devel@rtems.org
>> Subject: Re: [PATCH] psx13: Reworked and relicensed
>>
>> See below for comments. This test suite might be a good candidate for
>> conversion to T_TEST_CASE framework. At any rate, this refactor is a marked
>> improvement.
>>
>> On Wed, Apr 21, 2021 at 2:57 PM Ryan Long  wrote:
>> >
>> > Changed the way the tests were structured, added
>> > rtems_test_assert()'s, updated psx13.scn and the license.
>>
>> relicense changes should generally Update #3899.
>>
>
You can have two lines for ticket updates in the git commit (I think).

close
updates



>
>> > ---
>> >  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()
>> > + */
>> > +
>>
>> While you're at it, please conform to
>>
>> https://docs.rtems.org/branches/master/eng/coding-file-hdr.html#c-c-header-file-template
>>
>> > +/*
>> > + *  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 sou

RE: [PATCH v2] psx13: Reworked and relicensed

[Ryan Long]

Forgot to put the #Updates statement in the commit message. Will resend as V3.

-Original Message-
From: Ryan Long  
Sent: Thursday, April 22, 2021 2:34 PM
To: devel@rtems.org
Cc: Ryan Long 
Subject: [PATCH v2] psx13: Reworked and relicensed

Changed the way the tests were structured, added rtems_test_assert()'s, updated 
psx13.scn and the license.
---
 testsuites/psxtests/psx13/main.c|  37 +-
 testsuites/psxtests/psx13/psx13.scn |  21 +-
 testsuites/psxtests/psx13/test.c| 852 
 3 files changed, 328 insertions(+), 582 deletions(-)

diff --git a/testsuites/psxtests/psx13/main.c b/testsuites/psxtests/psx13/main.c
index 20788b3..f9e7907 100644
--- a/testsuites/psxtests/psx13/main.c
+++ b/testsuites/psxtests/psx13/main.c
@@ -1,14 +1,37 @@
-/*
- *  Simple test program -- simplified version of sample test hello.
+/*  SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ *  @file
  *
- *  COPYRIGHT (c) 1989-2009.
- *  On-Line Applications Research Corporation (OAR).
+ *  @brief Simple test program -- simplified version of sample test hello.
  *
- *  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.
  */
 
+/*
+ *  COPYRIGHT (c) 1989-2009, 2021.
+ *  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.
+ */
 
 #ifdef HAVE_CONFIG_H
 #include "config.h"
diff --git a/testsuites/psxtests/psx13/psx13.scn 
b/testsuites/psxtests/psx13/psx13.scn
index 428a931..efa79c9 100644
--- a/testsuites/psxtests/psx13/psx13.scn
+++ b/testsuites/psxtests/psx13/psx13.scn
@@ -1,16 +1,7 @@
-*** POSIX TEST 13 ***
+*** BEGIN OF TEST PSX 13 ***
+*** TEST VERSION: 6.0.0.75f80242186af2dde0c5bc7272a119e3b78d7ba0
+*** TEST STATE: EXPECTED_PASS
+*** TEST BUILD: RTEMS_DEBUG RTEMS_POSIX_API
+*** TEST TOOLS: 10.2.1 20210309 (RTEMS 6, RSB 
+5e449fb5c2cb6812a238f9f9764fd339cbbf05c2, Newlib d10d0d9)
 
-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().. 
-
-*** 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..a82242b 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)
+/*  SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ *  @file
  *
- *  This test exercises the following routines:
+ *  @brief This tests various file system functions.
  *
- * 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
+ *  This test exercises the following routines:
  *
- *  COPYRIGHT (c) 1989-2009.
+ * - lseek()
+ * - dup()
+ * - dup2()
+ * - fdatasync()
+ * - fsync()
+ * - pathconf()
+ * - fpathconf()
+ * - umask()
+ * - utime()
+ * - utimes()
+ * - sync()
+ */
+
+/*
+ *  COPYRIGHT (c) 1989-2009, 2021.
  *  On-Line Applications Research Corporation (OAR).
  *
- 

Re: [PATCH] psx13: Reworked and relicensed

[Joel Sherrill]

On Fri, Apr 23, 2021 at 3:09 PM Joel Sherrill  wrote:

>
>
> On Fri, Apr 23, 2021 at 3:08 PM Joel Sherrill  wrote:
>
>>
>>
>> On Thu, Apr 22, 2021 at 11:06 AM Ryan Long  wrote:
>>
>>> >> +#ifdef __sparc__
>>> >What's this for?
>>> Joel said this was a special case, and that it needed to be put in, so
>>> I'm not sure.
>>>
>>
>> https://git.rtems.org/rtems/tree/cpukit/posix/src/sysconf.c#n57
>>
>> This was to support code in GCC which had hard-coded calls to this
>> sysconf()
>> in the SPARC backend but I grep'ed for them and didn't find them on
>> master.
>> Admittedly, I checked all the way back to egcs 1.1 and didn't find it
>> there either
>> so I am probably not looking right.
>>
>> If we are sure this isn't in GCC anymore, then it can be removed in a
>> follow up
>> patch.
>>
>
OK. Archeology update. The code in GCC requiring this was removed (drumroll
please..) 21 years ago

I have filed a ticket for this.

https://devel.rtems.org/ticket/4391#ticket

Ryan.. once this is merged, follow up with a simple patch to delete this
code.
#4391 is yours. :)

Thanks for triggering the investigation Gedare. Twenty years is a long time
to
carry this around and not need it.

>
>>
>>> For the printf's in test_main(), I should take out all of the print
>>> statements saying
>>>
>>> "Testing .Success"?
>>>
>>>
>>>
>>> -Original Message-
>>> From: Gedare Bloom 
>>> Sent: Thursday, April 22, 2021 8:45 AM
>>> To: Ryan Long 
>>> Cc: devel@rtems.org
>>> Subject: Re: [PATCH] psx13: Reworked and relicensed
>>>
>>> See below for comments. This test suite might be a good candidate for
>>> conversion to T_TEST_CASE framework. At any rate, this refactor is a marked
>>> improvement.
>>>
>>> On Wed, Apr 21, 2021 at 2:57 PM Ryan Long  wrote:
>>> >
>>> > Changed the way the tests were structured, added
>>> > rtems_test_assert()'s, updated psx13.scn and the license.
>>>
>>> relicense changes should generally Update #3899.
>>>
>>
> You can have two lines for ticket updates in the git commit (I think).
>
> close
> updates
>
>
>
>>
>>> > ---
>>> >  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()
>>> > + */
>>> > +
>>>
>>> While you're at it, please conform to
>>>
>>> https://docs.rtems.org/branches/master/eng/coding-file-hdr.html#c-c-hea