Re: [PATCH v2] bsps: Add BSP_FLUSH_KERNEL_CHAR_OUTPUT BSP option

[Chris Johns]

On 21/3/2024 5:39 pm, Sebastian Huber wrote:> On 21.03.24 00:28, Chris Johns 
wrote:
>> On 21/3/2024 2:11 am, Sebastian Huber wrote:
>>> On 19.03.24 18:44, Chris Johns wrote:
 On 20/3/2024 2:03 am, Sebastian Huber wrote:
> On 19.03.24 14:50, Kinsey Moore wrote:
>> The xilinx-zynqmp-rpu bsp_reset() is modified, but not included in the 
>> spec
>> file for the new option. Its family differs from the arm/xilinx-zynqmp 
>> BSP
>> family with a -rpu suffix.
> Yes, but this BSP is quite new. I would prefer to let it not flush 
> anything by
> default to carry out a reset.
>
>> I'd be fine with this being enabled for the AArch64 BSPs as well, but I
>> imagine that's better as a separate patch.
> Why should it be enabled by default? The arm/xilinx-zynq and 
> arm/xilinx-zynqmp
> BSPs were the only ones doing an UART flush in the general termination
> procedure. It probably was done to address a specific use case (maybe test
> runs).
 Is the issue the flush is before an infinite loop which means the UART FIFO
 should drain?
>>
>> What is the issue you are wanting to solve removing the flush?
> 
> The bsp_reset() function should reset the system and do nothing more. Doing
> additional things like flushing an UART device may not make sense for all
> applications. Some applications may not use the UART device, so it may not be
> initialized and powered off.  Some applications may use it with an
> application-specific protocol which doesn't like the additional four '\r' 
> during
> reset. Doing a UART flush takes some time and some applications may prefer a
> fast reset time. The bsp_reset() is the wrong place to do add specific cleanup
> functions. Applications can customize the termination procedure with their own
> fatal error extension, destructors, and exit handlers.

This makes sense however the console needs this. Removing the code as my reading
of this changes does breaks those systems where the console is in use and relies
on the UART being flushed. A solution that addresses the console side of things
would be more acceptable. You present some valid cases for making a change but a
user should be able to enter reset in a shell and see all output or invoke a
fatal error and expect to see the full error message.

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

Re: [PATCH] bsps: Avoid unused argument in clock interrupt

[Gedare Bloom]

Generally this looks ok to me, but please update
https://docs.rtems.org/branches/master/bsp-howto/clock.html#initialization
https://docs.rtems.org/branches/master/bsp-howto/clock.html#support-at-tick
to explain how this arg works.

On Wed, Mar 20, 2024 at 8:29 AM Sebastian Huber
 wrote:
>
> Pass the parameter of the clock interrupt handler to
> Clock_driver_support_at_tick() and Clock_driver_timecounter_tick().  This 
> makes
> it possible to use the interrupt handler argument in clock drivers.
>
> Use the interrupt handler provided by Clock_driver_support_install_isr() to
> avoid local delarations of Clock_isr().
>
> Update #4862.
> ---
>  bsps/arm/beagle/clock/clock.c |  2 +-
>  bsps/arm/csb336/clock/clockdrv.c  |  2 +-
>  bsps/arm/csb337/clock/clock.c |  2 +-
>  bsps/arm/edb7312/clock/clockdrv.c |  6 +--
>  bsps/arm/gumstix/clock/clock.c|  2 +-
>  bsps/arm/raspberrypi/clock/clockdrv.c | 27 +-
>  bsps/arm/rtl22xx/clock/clockdrv.c |  2 +-
>  bsps/arm/shared/clock/clock-a9mpcore.c| 28 ++
>  bsps/arm/shared/clock/clock-nxp-lpc.c | 17 -
>  bsps/arm/smdk2410/clock/clockdrv.c|  2 +-
>  bsps/arm/tms570/clock/clock.c | 20 +-
>  bsps/i386/pc386/clock/ckinit.c|  2 +-
>  bsps/lm32/shared/clock/ckinit.c   |  2 +-
>  bsps/lm32/shared/milkymist_clock/ckinit.c |  2 +-
>  bsps/m68k/av5282/clock/clock.c|  2 +-
>  bsps/m68k/gen68360/clock/clock.c  |  2 +-
>  bsps/m68k/genmcf548x/clock/clock.c|  2 +-
>  bsps/m68k/mcf52235/clock/clock.c  |  2 +-
>  bsps/m68k/mcf5225x/clock/clock.c  |  2 +-
>  bsps/m68k/mcf5235/clock/clock.c   |  2 +-
>  bsps/m68k/mcf5329/clock/clock.c   |  2 +-
>  bsps/m68k/mrm332/btimer/btimer.c  |  2 -
>  bsps/m68k/uC5282/clock/clock.c|  2 +-
>  bsps/microblaze/microblaze_fpga/clock/clock.c |  8 ++--
>  bsps/mips/csb350/clock/clockdrv.c |  4 +-
>  bsps/mips/rbtx4925/clock/clockdrv.c   |  2 +-
>  bsps/mips/rbtx4938/clock/clockdrv.c   |  2 +-
>  bsps/mips/shared/clock/clockdrv.c |  2 +-
>  bsps/nios2/nios2_iss/clock/clock.c|  2 +-
>  bsps/or1k/generic_or1k/clock/clockdrv.c   |  2 +-
>  bsps/powerpc/mpc55xxevb/clock/clock-config.c  | 24 ++--
>  bsps/powerpc/qoriq/clock/clock-config.c   | 14 +++
>  bsps/riscv/griscv/clock/clockdrv.c|  2 +-
>  bsps/riscv/riscv/clock/clockdrv.c | 13 +++
>  bsps/shared/dev/clock/arm-generic-timer.c | 19 --
>  bsps/shared/dev/clock/clockimpl.h | 37 +--
>  bsps/shared/dev/clock/xil-ttc.c   | 32 ++--
>  bsps/shared/grlib/btimer/tlib_ckinit.c|  4 +-
>  bsps/sparc/erc32/clock/ckinit.c   |  8 ++--
>  bsps/sparc/leon2/clock/ckinit.c   |  2 +-
>  bsps/sparc/leon3/clock/ckinit.c   |  2 +-
>  bsps/sparc64/shared/clock/ckinit.c|  2 +-
>  42 files changed, 137 insertions(+), 178 deletions(-)
>
> diff --git a/bsps/arm/beagle/clock/clock.c b/bsps/arm/beagle/clock/clock.c
> index d42b051c98..a32dde86bf 100644
> --- a/bsps/arm/beagle/clock/clock.c
> +++ b/bsps/arm/beagle/clock/clock.c
> @@ -290,7 +290,7 @@ static void 
> beagle_clock_handler_install(rtems_interrupt_handler isr)
>clock_isr = isr;
>  }
>
> -#define Clock_driver_support_at_tick() beagle_clock_at_tick()
> +#define Clock_driver_support_at_tick(arg) beagle_clock_at_tick()
>  #define Clock_driver_support_initialize_hardware() beagle_clock_initialize()
>  #define Clock_driver_support_install_isr(isr) \
>beagle_clock_handler_install(isr)
> diff --git a/bsps/arm/csb336/clock/clockdrv.c 
> b/bsps/arm/csb336/clock/clockdrv.c
> index 58f98d87be..6af507a877 100644
> --- a/bsps/arm/csb336/clock/clockdrv.c
> +++ b/bsps/arm/csb336/clock/clockdrv.c
> @@ -38,7 +38,7 @@ rtems_irq_connect_data clock_isr_data = {
>   *- clear the interrupt bit?
>   *- restart the timer?
>   */
> -#define Clock_driver_support_at_tick()   \
> +#define Clock_driver_support_at_tick(arg)\
>do {   \
>  uint32_t reg;\
>   \
> diff --git a/bsps/arm/csb337/clock/clock.c b/bsps/arm/csb337/clock/clock.c
> index 69a3dafd81..ee05387baa 100644
> --- a/bsps/arm/csb337/clock/clock.c
> +++ b/bsps/arm/csb337/clock/clock.c
> @@ -94,7 +94,7 @@ static void Clock_driver_support_initialize_hardware(void)
>ST_REG(ST_PIMR) = value;
>  }
>
> -#define Clock_driver_support_at_tick() \
> +#define Clock_driver_support_at_tick(arg) \
>do { \
>  uint32_t st_str; \
>  \
> diff --git a/bsps/arm/edb7312/clock/clockdrv.c 
> b/bsps/arm/edb7312/clock/clockdrv.c
> index 

Re: RFC: Add API to get and set interrupt priorities for interrupt vectors

[Gedare Bloom]

Two basic questions:

Does the priority field type need to be Architecture- or BSP-defined
or is uint32_t always going to be fine.

Does changing (increasing) the priority of a vector from within
interrupt context possibly cause a pending interrupt to post that was
previously at a lower priority than the currently masked priority
level? In that case, it would cause a preemption to occur. I'm
guessing this behavior could be architecture-specific.

I added those questions to the ticket also.
Gedare

On Wed, Mar 20, 2024 at 2:59 AM Sebastian Huber
 wrote:
>
> Hello,
>
> I added a ticket for a proposal for an API to get and set interrupt
> priorities for interrupt vectors:
>
> https://devel.rtems.org/ticket/5002
>
> I would like to implement this API at least for the BSPs using the
> ARM/AArch64 GIC.
>
> --
> embedded brains GmbH & Co. KG
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [Docs] c-user: Clarify CONFIGURE_TICKS_PER_TIMESLICE

[Joel Sherrill]

On Thu, Mar 21, 2024 at 9:06 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 21.03.24 15:05, Joel Sherrill wrote:
> > Isn't this content generated from rtems-central?
>
> Yes, it is generated.
>
> >
> > Shouldn't there also be a change there?
>
> It should be there:
>

OK. Just didn't see a patch posted.

>
> Module:rtems-central
> Branch:master
> Commit:f5e42e5d9fae95e50f41a2ed71ee94e9908612c0
> Changeset:
>
> http://git.rtems.org/rtems-central/commit/?id=f5e42e5d9fae95e50f41a2ed71ee94e9908612c0
>
> Author:Sebastian Huber 
> Date:  Thu Mar 21 11:55:22 2024 +0100
>
> spec: Fix CONFIGURE_TICKS_PER_TIMESLICE constraint
>
> Update #4986.
>
> --
> embedded brains GmbH & Co. KG
> 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: [Docs] c-user: Clarify CONFIGURE_TICKS_PER_TIMESLICE

[Sebastian Huber]

On 21.03.24 15:05, Joel Sherrill wrote:

Isn't this content generated from rtems-central?


Yes, it is generated.



Shouldn't there also be a change there?


It should be there:

Module:rtems-central
Branch:master
Commit:f5e42e5d9fae95e50f41a2ed71ee94e9908612c0
Changeset: 
http://git.rtems.org/rtems-central/commit/?id=f5e42e5d9fae95e50f41a2ed71ee94e9908612c0


Author:Sebastian Huber 
Date:  Thu Mar 21 11:55:22 2024 +0100

spec: Fix CONFIGURE_TICKS_PER_TIMESLICE constraint

Update #4986.

--
embedded brains GmbH & Co. KG
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: [Docs] c-user: Clarify CONFIGURE_TICKS_PER_TIMESLICE

[Joel Sherrill]

Isn't this content generated from rtems-central?

Shouldn't there also be a change there?

--joel

On Wed, Mar 20, 2024 at 9:24 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Close #4986.
> ---
>  c-user/config/general.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/c-user/config/general.rst b/c-user/config/general.rst
> index 5ff79e7..61bfa1e 100644
> --- a/c-user/config/general.rst
> +++ b/c-user/config/general.rst
> @@ -1017,7 +1017,7 @@ configured, see
> :ref:`CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER`.
>
>  The following constraints apply to this configuration option:
>
> -* The value of the configuration option shall be greater than or equal to
> zero.
> +* The value of the configuration option shall be greater than or equal to
> one.
>
>  * The value of the configuration option shall be less than or equal to
>`UINT32_MAX `_.
> --
> 2.35.3
>
> ___
> 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 v2] bsps: Add BSP_FLUSH_KERNEL_CHAR_OUTPUT BSP option

[Sebastian Huber]

On 21.03.24 00:28, Chris Johns wrote:

On 21/3/2024 2:11 am, Sebastian Huber wrote:

On 19.03.24 18:44, Chris Johns wrote:

On 20/3/2024 2:03 am, Sebastian Huber wrote:

On 19.03.24 14:50, Kinsey Moore wrote:

The xilinx-zynqmp-rpu bsp_reset() is modified, but not included in the spec
file for the new option. Its family differs from the arm/xilinx-zynqmp BSP
family with a -rpu suffix.

Yes, but this BSP is quite new. I would prefer to let it not flush anything by
default to carry out a reset.


I'd be fine with this being enabled for the AArch64 BSPs as well, but I
imagine that's better as a separate patch.

Why should it be enabled by default? The arm/xilinx-zynq and arm/xilinx-zynqmp
BSPs were the only ones doing an UART flush in the general termination
procedure. It probably was done to address a specific use case (maybe test
runs).

Is the issue the flush is before an infinite loop which means the UART FIFO
should drain?


What is the issue you are wanting to solve removing the flush?


The bsp_reset() function should reset the system and do nothing more. 
Doing additional things like flushing an UART device may not make sense 
for all applications. Some applications may not use the UART device, so 
it may not be initialized and powered off.  Some applications may use it 
with an application-specific protocol which doesn't like the additional 
four '\r' during reset. Doing a UART flush takes some time and some 
applications may prefer a fast reset time. The bsp_reset() is the wrong 
place to do add specific cleanup functions. Applications can customize 
the termination procedure with their own fatal error extension, 
destructors, and exit handlers.


--
embedded brains GmbH & Co. KG
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