Re: Repo Transition to GitLab

[Sebastian Huber]

On 26.04.24 00:38, Chris Johns wrote:

Hi RTEMS Community

The git repos on git.rtems.org are open and accepting patches. The GitLab repos
will move us to main, something we have been waiting to do. Allowing commits
into the repos means they will be brought across and played on top of the new
main branch. We have changes in the repo on GitLab as part of our testing and
new files such as CODEOWNERS.

As a result you will check out main and not rename your master to main.


When will the GitLab available? I can wait with my pending patches so 
that the associated tickets get updated when they are checked in. How 
will the ticket updates work in GitLab? Are the ticket numbers the same?


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

Repo Transition to GitLab

[Chris Johns]

Hi RTEMS Community

The git repos on git.rtems.org are open and accepting patches. The GitLab repos
will move us to main, something we have been waiting to do. Allowing commits
into the repos means they will be brought across and played on top of the new
main branch. We have changes in the repo on GitLab as part of our testing and
new files such as CODEOWNERS.

As a result you will check out main and not rename your master to main.

Regards
Chris
RTEMS GitLab Team
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[RFC v2] rtems: Add options to kernel output char handler

[Sebastian Huber]

Make the kernel I/O output character device processing configurable
through an option set parameter.  Add RTEMS_IO_NO_OUTPUT and
RTEMS_IO_DRAIN options.  The goal of this API change is to enable
draining the kernel output device in the system termination process
before a reset is issued.  A use case for using RTEMS_NO_WAIT is the
polled processing of an input and output stream from and to the I/O
device.
---
v2:

* Do not use EARS.

* Rename RTEMS_FLUSH in RTEMS_IO_DRAIN.

* Rename RTEMS_NO_OUTPUT in RTEMS_IO_NO_TRANSMISSION.

* Add example adoption for sparc/leon3.

 bsps/sparc/leon3/console/printk_support.c | 54 +++---
 cpukit/include/rtems/bspIo.h  | 55 ++-
 cpukit/include/rtems/rtems/options.h  | 22 -
 cpukit/libcsupport/src/rtems_putc.c   |  4 +-
 testsuites/validation/tc-io-put-char.c|  8 +++-
 testsuites/validation/tr-io-kernel.c  |  4 +-
 6 files changed, 132 insertions(+), 15 deletions(-)

diff --git a/bsps/sparc/leon3/console/printk_support.c 
b/bsps/sparc/leon3/console/printk_support.c
index fd23a5033f..adfd653060 100644
--- a/bsps/sparc/leon3/console/printk_support.c
+++ b/bsps/sparc/leon3/console/printk_support.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -56,6 +57,11 @@ apbuart *leon3_debug_uart = NULL;
 
 static void bsp_debug_uart_init(void);
 
+static bool apbuart_can_transmit(apbuart *regs)
+{
+  return (grlib_load_32(>status) & APBUART_STATUS_TE) != 0;
+}
+
 static void apbuart_enable_receive_and_transmit(apbuart *regs)
 {
   uint32_t ctrl;
@@ -66,10 +72,38 @@ static void apbuart_enable_receive_and_transmit(apbuart 
*regs)
   grlib_store_32(>status, 0);
 }
 
-static void bsp_debug_uart_output_char(char c)
+static rtems_status_code bsp_debug_uart_output_char(
+  char c,
+  rtems_option option_set
+)
 {
-  apbuart_outbyte_polled(leon3_debug_uart, c);
-  apbuart_outbyte_wait(leon3_debug_uart);
+  apbuart *regs = leon3_debug_uart;
+  rtems_status_code status = RTEMS_SUCCESSFUL;
+
+  while (true) {
+if (apbuart_can_transmit(regs)) {
+  if ((option_set & RTEMS_IO_NO_TRANSMISSION) == 0) {
+grlib_store_32(>data, (uint8_t) c);
+  }
+
+  break;
+}
+
+if ((option_set & RTEMS_NO_WAIT) != 0) {
+  status = RTEMS_UNSATISFIED;
+  break;
+}
+
+_IO_Relax();
+  }
+
+  if ((option_set & RTEMS_IO_DRAIN) != 0) {
+while (!apbuart_can_transmit(regs)) {
+  _IO_Relax();
+}
+  }
+
+  return status;
 }
 
 static int bsp_debug_uart_poll_char(void)
@@ -77,10 +111,13 @@ static int bsp_debug_uart_poll_char(void)
   return apbuart_inbyte_nonblocking(leon3_debug_uart);
 }
 
-static void bsp_debug_uart_pre_init_out(char c)
+static rtems_status_code bsp_debug_uart_pre_init_out(
+  char c,
+  rtems_option option_set
+)
 {
   bsp_debug_uart_init();
-  (*BSP_output_char)(c);
+  return (*BSP_output_char)(c, option_set);
 }
 
 #if defined(LEON3_APBUART_BASE)
@@ -94,9 +131,14 @@ static void bsp_debug_uart_init(void)
 
 #else /* !LEON3_APBUART_BASE */
 
-static void bsp_debug_uart_discard(char c)
+static rtems_status_code bsp_debug_uart_discard(
+  char c,
+  rtems_option option_set
+)
 {
   (void) c;
+  (void) option_set;
+  return RTEMS_SUCCESSFUL;
 }
 
 /* Initialize the BSP system debug console layer. It will scan AMBA Plu
diff --git a/cpukit/include/rtems/bspIo.h b/cpukit/include/rtems/bspIo.h
index 31580cd800..7848704992 100644
--- a/cpukit/include/rtems/bspIo.h
+++ b/cpukit/include/rtems/bspIo.h
@@ -10,7 +10,7 @@
  */
 
 /*
- * Copyright (C) 2020, 2021 embedded brains GmbH & Co. KG
+ * Copyright (C) 2020, 2024 embedded brains GmbH & Co. KG
  * Copyright (C) 2015 On-Line Applications Research Corporation (OAR)
  *
  * Redistribution and use in source and binary forms, with or without
@@ -58,6 +58,8 @@
 #define _RTEMS_BSPIO_H
 
 #include 
+#include 
+#include 
 #include 
 
 #ifdef __cplusplus
@@ -89,8 +91,48 @@ extern "C" {
  * @ingroup RTEMSAPIKernelCharIO
  *
  * @brief Polled character output functions shall have this type.
+ *
+ * @param out is the character to transmit.
+ *
+ * @param option_set is the option set.
+ *
+ * The behaviour of polled character output functions can be controlled by the
+ * three options #RTEMS_NO_WAIT, #RTEMS_IO_NO_TRANSMISSION, and #RTEMS_IO_DRAIN
+ * specified in the ``option_set`` parameter.
+ *
+ * If the #RTEMS_NO_WAIT option is set in the ``option_set`` parameter and the
+ * device cannot immediately accept a character for transmission, then the
+ * character in ``out`` shall not be transmitted by the device, optionally the
+ * device shall be drained, and ::RTEMS_UNSATISFIED shall be returned.
+ *
+ * If the #RTEMS_IO_NO_TRANSMISSION option is set in the ``option_set``
+ * parameter, the character in the ``out`` parameter shall not be transmitted
+ * by the device.
+ *
+ * If the #RTEMS_NO_WAIT and #RTEMS_IO_NO_TRANSMISSION options are cleared in
+ * the ``option_set`` parameter, then the character in the 

Re: [PATCH v2] rtems: Add get/set interrupt priorities

[Sebastian Huber]

On 16.04.24 07:25, Sebastian Huber wrote:

On 09.04.24 16:28, Sebastian Huber wrote:

Add directives to get and set the priority of an interrupt vector.

Implement the directives for the following BSP families:

* arm/lpc24xx
* arm/lpc32xx
* powerpc/mpc55xxevb
* powerpc/qoriq

Implement the directives for the following interrupt controllers:

* GICv2 and GICv3 (arm and aarch64)
* NVIC (arm)
* PLIC (riscv)

Update #5002.


Any comments to this API extension?


If there are no objections, then I will commit this patch set next Monday.

--
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: Cortex-M floating point (Was: RTEMS 6 branching)

[Sebastian Huber]

On 24.04.24 14:37, Cedric Berger wrote:

Hello Sebastian,

On 23.04.2024 19:56, Sebastian Huber wrote:

1. Are all the things need for the release resolved? Tickets reviewed?

It would be nice to have the interrupt get/set priority API in RTEMS 6. The 
Cortex-M floating point issue is not yet fixed in the RTEMS master.


Do you have any feedback on the two patches that I posted on the ticket, 
which seems to fix the issue?


It would be great if you could check the patch at the end of this mail:

https://lists.rtems.org/pipermail/devel/2024-February/077228.html

--
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: Introduction and preparation for the "Add BSP for Polarfire based Beagle" Project

[Vijay Kumar Banerjee]

(Adding devel back in the CC)

On Wed, Apr 24, 2024 at 1:34 AM Purva Yeshi  wrote:

> Please feel free to call me Vijay :)
>
> Sure.
>
> That's great! You might be able to relate some of the documentation to the
>> riscv BSP code in the repository.
>
> Yes, and I also added examples related to riscv
>
> Nice


> Have you set up any public repository that we might be able to follow and
>> provide early feedback? It is okay to have work-in-progress commits in your
>> repository.
>
> Yes I forked rtems-docs and commit those changes
> Here is the link:
> https://github.com/purviyeshi/rtems-docs/blob/master/bsp-howto/target_dependant_files.rst
>
>
I had a quick look at the document. Did the content under "peripheral
dependant" and "board dependant" get switched? Based on the lines preceding
your additions.


On Wed, 24 Apr 2024 at 03:26, Vijay Kumar Banerjee  wrote:
>
>> Hi Purva,
>>
>> On Tue, Apr 23, 2024 at 3:18 PM Purva Yeshi 
>> wrote:
>>
>>> Hello Sir,
>>>
>>
>> Please feel free to call me Vijay :)
>>
>>
>>>
>>> Up until now, I have been studying the BSP driver documentation from
>>> https://docs.rtems.org/branches/master/bsp-howto/ . I have gained a
>>> good understanding of why and how target-dependent files are written.
>>> Additionally, I am currently working on how the console and clock driver
>>> are written.
>>>
>>> That's great! You might be able to relate some of the documentation to
>> the riscv BSP code in the repository.
>>
>>
>>> Furthermore, I have been modifying the target-dependent files by adding
>>> more examples to make them more understandable for new users.
>>>
>>
>> Have you set up any public repository that we might be able to follow and
>> provide early feedback? It is okay to have work-in-progress commits in your
>> repository.
>>
>>
>> Best regards,
>> Vijay
>>
>>>
>>> On Fri, 5 Apr 2024 at 21:36, Purva Yeshi 
>>> wrote:
>>>
 Thank you for all the resources.

 Yes, I go through the documentation and the codebase, and I'll try to
 send patches
 Okay, got the point about mailing list and github

 On Fri, 5 Apr 2024 at 02:21, Vijay Kumar Banerjee 
 wrote:

> Hi Purva,
>
>
>
> On Thu, Apr 4, 2024 at 6:05 AM Purva Yeshi 
> wrote:
>
>> Hello,
>>
>> I am Purva Yeshi, I applied for the project "Add BSP for Polarfire
>> based Beagle" for GSoC 2024. I proposed a project to create a BSP for the
>> Beagle-V fire board from scratch. The primary objective of the project is
>> to run a "Hello World" code and a ticker on the board. After that, I will
>> focus on developing support for other devices such as Ethernet and U54 
>> MMU.
>>
>> Great! Thanks for completing the proposal and submitting it on the
> portal.
>
>
>> During this waiting period for acceptance, I want to familiarize
>> myself with the codebase of existing supported components of other RISC-V
>> BSP variants. As part of my preparation, I have already built an RTEMS
>> development environment and successfully completed the RTEMS Hello World
>> project on the Qemu spike simulator for the riscv/rv64imafdc BSP variant.
>>
>>
> Since you already have a working RTEMS environment, it would be a
> great idea to start looking at the source code organization of riscv bsps 
> (
> https://git.rtems.org/rtems/tree/bsps/risc). It would also be helpful
> to find some smaller issues (maybe in the documentation) and try to send
> patches for that. Submitting patches for smaller issues is a great idea to
> become familiar with the code contribution process. The documentation for
> riscv bsps can be found at
> https://docs.rtems.org/branches/master/user/bsps/bsps-riscv.html
>
> You can also utilize this time to read up on the Beagle-V fire
> documentation and the prior FreeBSD efforts to support that board.
>
> Could you please provide guidance on this. Additionally, is there any
>> specific task or area you suggest I focus on during this period for the
>> project?
>>
>
> Feel free to ask about anything you find interesting (or confusing)
> while going through the source code and the documentation. Especially with
> the documentation, if something confuses you it likely confuses other
> people too, it can be a place to make a great contribution!
>
> The mailing list is the best place to discuss longer questions, and
> the discord channel is better for quick help from people who are signed 
> in.
> The discord channel has a subset of the RTEMS developers on it, the 
> mailing
> list has a wider audience.
>
>
> Good luck with the GSoC application!
>
> Best regards,
> Vijay
>
> ___
>
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>

Re: Cortex-M floating point (Was: RTEMS 6 branching)

[Chris Johns]

On 24/4/2024 10:37 pm, Cedric Berger wrote:
> Hello Sebastian,
> 
> On 23.04.2024 19:56, Sebastian Huber wrote:
>>> 1. Are all the things need for the release resolved? Tickets reviewed?
>> It would be nice to have the interrupt get/set priority API in RTEMS 6. The 
>> Cortex-M floating point issue is not yet fixed in the RTEMS master.
> 
> Do you have any feedback on the two patches that I posted on the ticket, which
> seems to fix the issue?

Thanks to everyone for responding. It seems clear the 6 branch will happen once
GitLab is launched. Once we launch the 6 milestone can be used with burndown and
burnup charts
(https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html)
to track the branch point.

I know I am getting ahead of myself but once we have GiLab running and you have
a patch you would like merged please make a merge request. If there is an issue
please make sure it is on the 6.1 milestone or create one and assign it to the
milestone.

In the meantime Amar and I will take a look at the release notes. We think these
can be based on a ChangeLog report created via the GitLab API. The wrinkle here
is the API needs a key and that of course cannot be exposed in commits.

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

Re: Cortex-M floating point (Was: RTEMS 6 branching)

[Chris Johns]

On 24/4/2024 10:37 pm, Cedric Berger wrote:
> Hello Sebastian,
> 
> On 23.04.2024 19:56, Sebastian Huber wrote:
>>> 1. Are all the things need for the release resolved? Tickets reviewed?
>> It would be nice to have the interrupt get/set priority API in RTEMS 6. The 
>> Cortex-M floating point issue is not yet fixed in the RTEMS master.
> 
> Do you have any feedback on the two patches that I posted on the ticket, which
> seems to fix the issue?

Thanks to everyone for responding. It seems clear the 6 branch will happen once
GitLab is launched. Once we launch the 6 milestone can be used with burndown and
burnup charts
(https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html)
to track the branch point.

I know I am getting ahead of myself but once we have GiLab running and you have
a patch you would like merged please make a merge request. If there is an issue
please make sure it is on the 6.1 milestone or create one and assign it to the
milestone.

In the meantime Amar and I will take a look at the release notes. We think these
can be based on a ChangeLog report created via the GitLab API. The wrinkle here
is the API needs a key and that of course cannot be exposed in commits.

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

Re: RTEMS 6 branching

[Chris Johns]

On 25/4/2024 12:06 am, Peter Dufault wrote:
>> On Apr 24, 2024, at 9:27 AM, Kinsey Moore  wrote:
>>
>> That use case definitely wasn't considered for rtems-lwip and I don't know 
>> that it's ever been discussed. If that were intended, I'd expect a "./waf 
>> uninstall" target to exist that would remove the installed network stack so 
>> that you could install a different one since the different stacks install 
>> vastly different sets of headers. IIRC, Chris advocates for installing the 
>> network libraries into a different location than the installed BSP to allow 
>> you to choose which you want at a later time.
>>
> 
> I've been moving a driver from legacy to bsd so I definitely need to easily 
> switch back and forth for the same BSP for testing.
> 
> I agree with Chris, but it's apparently a desirement, not a requirement, so 
> it shouldn't hold up the branching.

Agreed. It would be nice but is it something user would really want or use? I
get there are use cases like the one you raise but a single installed network
stack in a single install prefix makes it easier to write build system checks to
detect the type of stack. I have applications that can switch between legacy and
libbsd and that is important when migrating stacks and debugging.

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

Re: [PATCH] bsps/aarch64/raspberrypi: Add system timer support

[Kinsey Moore]

Looks good, thanks!

Kinsey

On Tue, Apr 16, 2024 at 5:20 AM Ning Yang  wrote:

> The clock from the ARM timer is derived from the system clock. This clock
> can
> change dynamically e.g. if the system goes into reduced power or in low
> power
> mode. Thus the clock speed adapts to the overall system performance
> capabilities. For accurate timing it is recommended to use the system
> timers.
>
> if BSP_CLOCK_USE_SYSTEMTIMER = 1, use the System Timer, otherwise use the
> ARM
> Timer.
> ---
>  bsps/aarch64/raspberrypi/include/bsp/irq.h| 14 ++---
>  .../raspberrypi/include/bsp/raspberrypi.h |  9 ++
>  spec/build/bsps/aarch64/grp.yml   |  3 --
>  .../aarch64/raspberrypi/bspraspberrypi4.yml   |  6 ++--
>  .../bsps/aarch64/raspberrypi/objclock.yml | 31 +++
>  .../aarch64/raspberrypi/objsystemtimer.yml| 23 ++
>  .../aarch64/raspberrypi/optsystemtimer.yml| 24 ++
>  7 files changed, 100 insertions(+), 10 deletions(-)
>  create mode 100644 spec/build/bsps/aarch64/raspberrypi/objclock.yml
>  create mode 100644 spec/build/bsps/aarch64/raspberrypi/objsystemtimer.yml
>  create mode 100644 spec/build/bsps/aarch64/raspberrypi/optsystemtimer.yml
>
> diff --git a/bsps/aarch64/raspberrypi/include/bsp/irq.h
> b/bsps/aarch64/raspberrypi/include/bsp/irq.h
> index 1ff6ae80de..d493e83707 100644
> --- a/bsps/aarch64/raspberrypi/include/bsp/irq.h
> +++ b/bsps/aarch64/raspberrypi/include/bsp/irq.h
> @@ -9,6 +9,7 @@
>  /**
>   * Copyright (c) 2013 Alan Cudmore
>   * Copyright (c) 2022 Mohd Noor Aman
> + * Copyright (c) 2024 Ning Yang
>   *
>   *  The license and distribution terms for this file may be
>   *  found in the file LICENSE in this distribution or at
> @@ -33,15 +34,18 @@
>   * @brief Interrupt support.
>   */
>
> -#define BCM2835_INTC_TOTAL_IRQ   (64 + 8)
> +#define BCM2835_INTC_TOTAL_IRQ   216
>
>  #define BCM2835_IRQ_SET1_MIN 0
>  #define BCM2835_IRQ_SET2_MIN 32
>
> -#define BCM2835_IRQ_ID_GPU_TIMER_M0  0
> -#define BCM2835_IRQ_ID_GPU_TIMER_M1  1
> -#define BCM2835_IRQ_ID_GPU_TIMER_M2  2
> -#define BCM2835_IRQ_ID_GPU_TIMER_M3  3
> +#define BCM2711_IRQ_VC_PERIPHERAL_BASE 96
> +
> +/* Interrupt Vectors: System Timer */
> +#define BCM2835_IRQ_ID_GPU_TIMER_M0(BCM2711_IRQ_VC_PERIPHERAL_BASE +
> 0)
> +#define BCM2835_IRQ_ID_GPU_TIMER_M1(BCM2711_IRQ_VC_PERIPHERAL_BASE +
> 1)
> +#define BCM2835_IRQ_ID_GPU_TIMER_M2(BCM2711_IRQ_VC_PERIPHERAL_BASE +
> 2)
> +#define BCM2835_IRQ_ID_GPU_TIMER_M3(BCM2711_IRQ_VC_PERIPHERAL_BASE +
> 3)
>
>  #define BCM2835_IRQ_ID_USB   9
>  #define BCM2835_IRQ_ID_AUX   29
> diff --git a/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
> b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
> index 55dd9ed1e9..f185d1df57 100644
> --- a/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
> +++ b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
> @@ -8,6 +8,7 @@
>
>  /*
>   *  Copyright (c) 2022 Mohd Noor Aman
> + *  Copyright (c) 2024 Ning Yang
>   *
>   *  The license and distribution terms for this file may be
>   *  found in the file LICENSE in this distribution or at
> @@ -44,6 +45,7 @@
>
>  #define BCM2711_REG(x)   (*(volatile uint64_t *)(x))
>  #define BCM2711_BIT(n)   (1 << (n))
> +#define BCM2835_REG(addr)(*(volatile uint32_t*)(addr))
>
>  /** @} */
>
> @@ -198,6 +200,13 @@
>  #define BCM2711_GPU_TIMER_C2 (BCM2711_GPU_TIMER_BASE + 0x14)
>  #define BCM2711_GPU_TIMER_C3 (BCM2711_GPU_TIMER_BASE + 0x18)
>
> +/**
> + * NOTE: compatible with the BCM2835 system timer
> + */
> +#define BCM2835_GPU_TIMER_CS_M3  BCM2711_GPU_TIMER_CS_M3
> +#define BCM2835_GPU_TIMER_C3 BCM2711_GPU_TIMER_C3
> +#define BCM2835_GPU_TIMER_CLOBCM2711_GPU_TIMER_CLO
> +#define BCM2835_GPU_TIMER_CS BCM2711_GPU_TIMER_CS
>  /** @} */
>
>  /**
> diff --git a/spec/build/bsps/aarch64/grp.yml
> b/spec/build/bsps/aarch64/grp.yml
> index 9428fb9435..8f40a9952e 100644
> --- a/spec/build/bsps/aarch64/grp.yml
> +++ b/spec/build/bsps/aarch64/grp.yml
> @@ -12,9 +12,6 @@ install:
>source:
>- bsps/aarch64/include/bsp/linker-symbols.h
>- bsps/aarch64/include/bsp/start.h
> -- destination: ${BSP_INCLUDEDIR}/dev/clock
> -  source:
> -  - bsps/include/dev/clock/arm-generic-timer.h
>  - destination: ${BSP_INCLUDEDIR}/dev/irq
>source:
>- bsps/aarch64/include/dev/irq/arm-gic-arch.h
> diff --git a/spec/build/bsps/aarch64/raspberrypi/bspraspberrypi4.yml
> b/spec/build/bsps/aarch64/raspberrypi/bspraspberrypi4.yml
> index a579c094ba..7b6511a8cc 100644
> --- a/spec/build/bsps/aarch64/raspberrypi/bspraspberrypi4.yml
> +++ b/spec/build/bsps/aarch64/raspberrypi/bspraspberrypi4.yml
> @@ -19,6 +19,10 @@ install:
>- bsps/aarch64/raspberrypi/include/bsp/irq.h
>- bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
>  links:
> +- role: build-dependency
> +  uid: objclock
> +- role: build-dependency
> +  uid: objsystemtimer
>  - role: 

Re: RTEMS 6 branching

[Peter Dufault]

> On Apr 24, 2024, at 9:27 AM, Kinsey Moore  wrote:
> 
> That use case definitely wasn't considered for rtems-lwip and I don't know 
> that it's ever been discussed. If that were intended, I'd expect a "./waf 
> uninstall" target to exist that would remove the installed network stack so 
> that you could install a different one since the different stacks install 
> vastly different sets of headers. IIRC, Chris advocates for installing the 
> network libraries into a different location than the installed BSP to allow 
> you to choose which you want at a later time.
> 
> Kinsey

I've been moving a driver from legacy to bsd so I definitely need to easily 
switch back and forth for the same BSP for testing.

I agree with Chris, but it's apparently a desirement, not a requirement, so it 
shouldn't hold up the branching.

Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering



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

Re: RTEMS 6 branching

[Kinsey Moore]

On Wed, Apr 24, 2024 at 6:43 AM Peter Dufault  wrote:

> > On Apr 23, 2024, at 5:45 PM, Vijay Kumar Banerjee 
> wrote:
> > On Tue, Apr 23, 2024 at 1:02 PM Joel Sherrill  wrote:
> >
> >
> > On Tue, Apr 23, 2024, 12:56 PM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> > - Am 21. Apr 2024 um 3:00 schrieb Chris Johns chr...@rtems.org:
> >
> > > Hi,
> > >
> > > There has been some discussion about when we will branch and it is
> timely we
> > > discuss this. This is my input. :)
> > >
> > > While I create the releases I am not solely responsible for milestone
> dates or
> > > thresholds for a release.
> > >
> > > Please test the RC snaphots on our ftp server. Saying you have is as
> important
> > > as reporting issues.
> > >
> > > 1. Are all the things need for the release resolved? Tickets reviewed?
> >
> > It would be nice to have the interrupt get/set priority API in RTEMS 6.
> The Cortex-M floating point issue is not yet fixed in the RTEMS master.
> >
> > There should be time to get it in. The Gitlab transition needs to be
> complete before the branch is cut.
> >
> > >
> > > 2. The tickets are now in GitLab and locked down in Trac so how does
> that work
> > > if we make a release now? I do not think it does.
> > >
> > > 3. GitLab is going to happen soon so do we take this moment in time
> and make 6
> > > with GitLab and learn what we need to do easing dot releases that
> always follow?
> > > If we do not we may end up with 6.1 and then 6.2 that has differences.
> >
> > We should definitely wait with the release after the Gitlab migration is
> done and some basic CI is running.
> >
> > I don't think holding a release for CI is needed. We have the same basic
> quality and testing we have now.
> >
> > Requiring more work and improvements just moves the release bar.
> >
> > That said, we do need to get some CI processes in place. Hopefully
> between 6.1 and 6.2, we will have at least one or two BSPs required to
> build.
> >
> > >
> > > 4. GitLab breaks the release scripts for the release notes
> (ChangeLog). Amar and
> > > I have discussed a few options but we are yet to test and settle on
> anything. As
> > > is the case with these things easy is often is a series of small
> things that
> > > take time to get right.
> > >
> > > 5. Have the docs been reviewed for RTEMS 5 vs RTEMS 6 changes? Are
> they updated
> > > for a separated legacy network stack, net services and waf building?
> >
> > Ryan and Ray worked on the autoconf to waf documentation changes a
> couple of years ago.
> >
> > I have no idea what impact the separated Network stacks have on the
> documentation.
> >
> > The legacy networking docs are separated now with instructions on how to
> build them using waf:
> > https://docs.rtems.org/branches/master/legacy-networking/index.html
> >
> > We might need to mention in the user manual that there is no default
> networking stack anymore and the user needs to build the network stack
> separately.
>
> I do (or did, haven't checked lately) have an issue that if I "./waf
> install" one of the network stacks, probably "libbsd", that I can't then
> switch back and forth.  I think a header file got installed that broke
> things.  Don't know if that was fixed, I've just been careful to not
> install either stack so I can switch.
>
> Is that a bug?  Should I figure out what the problem was and report it?
>

That use case definitely wasn't considered for rtems-lwip and I don't know
that it's ever been discussed. If that were intended, I'd expect a "./waf
uninstall" target to exist that would remove the installed network stack so
that you could install a different one since the different stacks install
vastly different sets of headers. IIRC, Chris advocates for installing the
network libraries into a different location than the installed BSP to allow
you to choose which you want at a later time.

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

Cortex-M floating point (Was: RTEMS 6 branching)

[Cedric Berger]

Hello Sebastian,

On 23.04.2024 19:56, Sebastian Huber wrote:

1. Are all the things need for the release resolved? Tickets reviewed?

It would be nice to have the interrupt get/set priority API in RTEMS 6. The 
Cortex-M floating point issue is not yet fixed in the RTEMS master.


Do you have any feedback on the two patches that I posted on the ticket, 
which seems to fix the issue?


Thanks,

Cedric

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

Re: RTEMS 6 branching

[Peter Dufault]

> On Apr 23, 2024, at 5:45 PM, Vijay Kumar Banerjee  wrote:
> 
> 
> 
> On Tue, Apr 23, 2024 at 1:02 PM Joel Sherrill  wrote:
> 
> 
> On Tue, Apr 23, 2024, 12:56 PM Sebastian Huber 
>  wrote:
> - Am 21. Apr 2024 um 3:00 schrieb Chris Johns chr...@rtems.org:
> 
> > Hi,
> > 
> > There has been some discussion about when we will branch and it is timely we
> > discuss this. This is my input. :)
> > 
> > While I create the releases I am not solely responsible for milestone dates 
> > or
> > thresholds for a release.
> > 
> > Please test the RC snaphots on our ftp server. Saying you have is as 
> > important
> > as reporting issues.
> > 
> > 1. Are all the things need for the release resolved? Tickets reviewed?
> 
> It would be nice to have the interrupt get/set priority API in RTEMS 6. The 
> Cortex-M floating point issue is not yet fixed in the RTEMS master.
> 
> There should be time to get it in. The Gitlab transition needs to be complete 
> before the branch is cut. 
> 
> > 
> > 2. The tickets are now in GitLab and locked down in Trac so how does that 
> > work
> > if we make a release now? I do not think it does.
> > 
> > 3. GitLab is going to happen soon so do we take this moment in time and 
> > make 6
> > with GitLab and learn what we need to do easing dot releases that always 
> > follow?
> > If we do not we may end up with 6.1 and then 6.2 that has differences.
> 
> We should definitely wait with the release after the Gitlab migration is done 
> and some basic CI is running.
> 
> I don't think holding a release for CI is needed. We have the same basic 
> quality and testing we have now.
> 
> Requiring more work and improvements just moves the release bar. 
> 
> That said, we do need to get some CI processes in place. Hopefully between 
> 6.1 and 6.2, we will have at least one or two BSPs required to build.
> 
> > 
> > 4. GitLab breaks the release scripts for the release notes (ChangeLog). 
> > Amar and
> > I have discussed a few options but we are yet to test and settle on 
> > anything. As
> > is the case with these things easy is often is a series of small things that
> > take time to get right.
> > 
> > 5. Have the docs been reviewed for RTEMS 5 vs RTEMS 6 changes? Are they 
> > updated
> > for a separated legacy network stack, net services and waf building?
> 
> Ryan and Ray worked on the autoconf to waf documentation changes a couple of 
> years ago.
> 
> I have no idea what impact the separated Network stacks have on the 
> documentation.
> 
> The legacy networking docs are separated now with instructions on how to 
> build them using waf:
> https://docs.rtems.org/branches/master/legacy-networking/index.html
> 
> We might need to mention in the user manual that there is no default 
> networking stack anymore and the user needs to build the network stack 
> separately.

I do (or did, haven't checked lately) have an issue that if I "./waf install" 
one of the network stacks, probably "libbsd", that I can't then switch back and 
forth.  I think a header file got installed that broke things.  Don't know if 
that was fixed, I've just been careful to not install either stack so I can 
switch.

Is that a bug?  Should I figure out what the problem was and report it?

> 
> > 6. I have a few small patches to push and then an update to the RSB to pick
> > those changes up before I can create RC4.
> 
> I recently checked in a fix for powerpc and the AArch64 multilib changes for 
> Cortex-A53 in GCC 13. To pick this up, the GCC commit needs to be updated. 
> Maybe we should even wait for the GCC 13.3 release.
> 
> I asked about a gcc 13.3 release and we should not wait. They intend to do a 
> 14 release before returning to 13.3. We should plan to do 6.1 with a GCC 13 
> branch hash and probably plan to swap that out with a 13.3 tarball when it's 
> released. 
> 
> We are good at imposing more requirements. :)
> 
> 


Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering



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

Re: RTEMS 6 branching

[Vijay Kumar Banerjee]

On Tue, Apr 23, 2024 at 1:02 PM Joel Sherrill  wrote:

>
>
> On Tue, Apr 23, 2024, 12:56 PM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> - Am 21. Apr 2024 um 3:00 schrieb Chris Johns chr...@rtems.org:
>>
>> > Hi,
>> >
>> > There has been some discussion about when we will branch and it is
>> timely we
>> > discuss this. This is my input. :)
>> >
>> > While I create the releases I am not solely responsible for milestone
>> dates or
>> > thresholds for a release.
>> >
>> > Please test the RC snaphots on our ftp server. Saying you have is as
>> important
>> > as reporting issues.
>> >
>> > 1. Are all the things need for the release resolved? Tickets reviewed?
>>
>> It would be nice to have the interrupt get/set priority API in RTEMS 6.
>> The Cortex-M floating point issue is not yet fixed in the RTEMS master.
>>
>
> There should be time to get it in. The Gitlab transition needs to be
> complete before the branch is cut.
>
>>
>> >
>> > 2. The tickets are now in GitLab and locked down in Trac so how does
>> that work
>> > if we make a release now? I do not think it does.
>> >
>> > 3. GitLab is going to happen soon so do we take this moment in time and
>> make 6
>> > with GitLab and learn what we need to do easing dot releases that
>> always follow?
>> > If we do not we may end up with 6.1 and then 6.2 that has differences.
>>
>> We should definitely wait with the release after the Gitlab migration is
>> done and some basic CI is running.
>>
>
> I don't think holding a release for CI is needed. We have the same basic
> quality and testing we have now.
>
> Requiring more work and improvements just moves the release bar.
>
> That said, we do need to get some CI processes in place. Hopefully between
> 6.1 and 6.2, we will have at least one or two BSPs required to build.
>
>>
>> >
>> > 4. GitLab breaks the release scripts for the release notes (ChangeLog).
>> Amar and
>> > I have discussed a few options but we are yet to test and settle on
>> anything. As
>> > is the case with these things easy is often is a series of small things
>> that
>> > take time to get right.
>> >
>> > 5. Have the docs been reviewed for RTEMS 5 vs RTEMS 6 changes? Are they
>> updated
>> > for a separated legacy network stack, net services and waf building?
>>
>
> Ryan and Ray worked on the autoconf to waf documentation changes a couple
> of years ago.
>
> I have no idea what impact the separated Network stacks have on the
> documentation.
>

The legacy networking docs are separated now with instructions on how to
build them using waf:
https://docs.rtems.org/branches/master/legacy-networking/index.html

We might need to mention in the user manual that there is no default
networking stack anymore and the user needs to build the network stack
separately.

>
> > 6. I have a few small patches to push and then an update to the RSB to
>> pick
>> > those changes up before I can create RC4.
>>
>> I recently checked in a fix for powerpc and the AArch64 multilib changes
>> for Cortex-A53 in GCC 13. To pick this up, the GCC commit needs to be
>> updated. Maybe we should even wait for the GCC 13.3 release.
>>
>
> I asked about a gcc 13.3 release and we should not wait. They intend to do
> a 14 release before returning to 13.3. We should plan to do 6.1 with a GCC
> 13 branch hash and probably plan to swap that out with a 13.3 tarball when
> it's released.
>
> We are good at imposing more requirements. :)
>
>
>
>
>> >
>> >
>> > Thanks
>> > Chris
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>>
>> --
>> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Introduction and preparation for the "Add BSP for Polarfire based Beagle" Project

[Vijay Kumar Banerjee]

Hi Purva,

On Tue, Apr 23, 2024 at 3:18 PM Purva Yeshi  wrote:

> Hello Sir,
>

Please feel free to call me Vijay :)


>
> Up until now, I have been studying the BSP driver documentation from
> https://docs.rtems.org/branches/master/bsp-howto/ . I have gained a good
> understanding of why and how target-dependent files are written.
> Additionally, I am currently working on how the console and clock driver
> are written.
>
> That's great! You might be able to relate some of the documentation to the
riscv BSP code in the repository.


> Furthermore, I have been modifying the target-dependent files by adding
> more examples to make them more understandable for new users.
>

Have you set up any public repository that we might be able to follow and
provide early feedback? It is okay to have work-in-progress commits in your
repository.


Best regards,
Vijay

>
> On Fri, 5 Apr 2024 at 21:36, Purva Yeshi  wrote:
>
>> Thank you for all the resources.
>>
>> Yes, I go through the documentation and the codebase, and I'll try to
>> send patches
>> Okay, got the point about mailing list and github
>>
>> On Fri, 5 Apr 2024 at 02:21, Vijay Kumar Banerjee 
>> wrote:
>>
>>> Hi Purva,
>>>
>>>
>>>
>>> On Thu, Apr 4, 2024 at 6:05 AM Purva Yeshi 
>>> wrote:
>>>
 Hello,

 I am Purva Yeshi, I applied for the project "Add BSP for Polarfire
 based Beagle" for GSoC 2024. I proposed a project to create a BSP for the
 Beagle-V fire board from scratch. The primary objective of the project is
 to run a "Hello World" code and a ticker on the board. After that, I will
 focus on developing support for other devices such as Ethernet and U54 MMU.

 Great! Thanks for completing the proposal and submitting it on the
>>> portal.
>>>
>>>
 During this waiting period for acceptance, I want to familiarize myself
 with the codebase of existing supported components of other RISC-V BSP
 variants. As part of my preparation, I have already built an RTEMS
 development environment and successfully completed the RTEMS Hello World
 project on the Qemu spike simulator for the riscv/rv64imafdc BSP variant.


>>> Since you already have a working RTEMS environment, it would be a great
>>> idea to start looking at the source code organization of riscv bsps (
>>> https://git.rtems.org/rtems/tree/bsps/risc). It would also be helpful
>>> to find some smaller issues (maybe in the documentation) and try to send
>>> patches for that. Submitting patches for smaller issues is a great idea to
>>> become familiar with the code contribution process. The documentation for
>>> riscv bsps can be found at
>>> https://docs.rtems.org/branches/master/user/bsps/bsps-riscv.html
>>>
>>> You can also utilize this time to read up on the Beagle-V fire
>>> documentation and the prior FreeBSD efforts to support that board.
>>>
>>> Could you please provide guidance on this. Additionally, is there any
 specific task or area you suggest I focus on during this period for the
 project?

>>>
>>> Feel free to ask about anything you find interesting (or confusing)
>>> while going through the source code and the documentation. Especially with
>>> the documentation, if something confuses you it likely confuses other
>>> people too, it can be a place to make a great contribution!
>>>
>>> The mailing list is the best place to discuss longer questions, and the
>>> discord channel is better for quick help from people who are signed in. The
>>> discord channel has a subset of the RTEMS developers on it, the mailing
>>> list has a wider audience.
>>>
>>>
>>> Good luck with the GSoC application!
>>>
>>> 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

Re: Introduction and preparation for the "Add BSP for Polarfire based Beagle" Project

[Purva Yeshi]

Hello Sir,

Up until now, I have been studying the BSP driver documentation from
https://docs.rtems.org/branches/master/bsp-howto/ . I have gained a good
understanding of why and how target-dependent files are written.
Additionally, I am currently working on how the console and clock driver
are written.

Furthermore, I have been modifying the target-dependent files by adding
more examples to make them more understandable for new users.

On Fri, 5 Apr 2024 at 21:36, Purva Yeshi  wrote:

> Thank you for all the resources.
>
> Yes, I go through the documentation and the codebase, and I'll try to send
> patches
> Okay, got the point about mailing list and github
>
> On Fri, 5 Apr 2024 at 02:21, Vijay Kumar Banerjee  wrote:
>
>> Hi Purva,
>>
>>
>>
>> On Thu, Apr 4, 2024 at 6:05 AM Purva Yeshi 
>> wrote:
>>
>>> Hello,
>>>
>>> I am Purva Yeshi, I applied for the project "Add BSP for Polarfire based
>>> Beagle" for GSoC 2024. I proposed a project to create a BSP for the
>>> Beagle-V fire board from scratch. The primary objective of the project is
>>> to run a "Hello World" code and a ticker on the board. After that, I will
>>> focus on developing support for other devices such as Ethernet and U54 MMU.
>>>
>>> Great! Thanks for completing the proposal and submitting it on the
>> portal.
>>
>>
>>> During this waiting period for acceptance, I want to familiarize myself
>>> with the codebase of existing supported components of other RISC-V BSP
>>> variants. As part of my preparation, I have already built an RTEMS
>>> development environment and successfully completed the RTEMS Hello World
>>> project on the Qemu spike simulator for the riscv/rv64imafdc BSP variant.
>>>
>>>
>> Since you already have a working RTEMS environment, it would be a great
>> idea to start looking at the source code organization of riscv bsps (
>> https://git.rtems.org/rtems/tree/bsps/risc). It would also be helpful to
>> find some smaller issues (maybe in the documentation) and try to send
>> patches for that. Submitting patches for smaller issues is a great idea to
>> become familiar with the code contribution process. The documentation for
>> riscv bsps can be found at
>> https://docs.rtems.org/branches/master/user/bsps/bsps-riscv.html
>>
>> You can also utilize this time to read up on the Beagle-V fire
>> documentation and the prior FreeBSD efforts to support that board.
>>
>> Could you please provide guidance on this. Additionally, is there any
>>> specific task or area you suggest I focus on during this period for the
>>> project?
>>>
>>
>> Feel free to ask about anything you find interesting (or confusing) while
>> going through the source code and the documentation. Especially with the
>> documentation, if something confuses you it likely confuses other people
>> too, it can be a place to make a great contribution!
>>
>> The mailing list is the best place to discuss longer questions, and the
>> discord channel is better for quick help from people who are signed in. The
>> discord channel has a subset of the RTEMS developers on it, the mailing
>> list has a wider audience.
>>
>>
>> Good luck with the GSoC application!
>>
>> 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 9/9] bsp/tms570: Use write-back/write-allocate SDRAM

[Sebastian Huber]

Update #4982.
---
 bsps/arm/tms570/start/tms570_sys_core.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bsps/arm/tms570/start/tms570_sys_core.S 
b/bsps/arm/tms570/start/tms570_sys_core.S
index 83dee26ec8..ef28d88ede 100644
--- a/bsps/arm/tms570/start/tms570_sys_core.S
+++ b/bsps/arm/tms570/start/tms570_sys_core.S
@@ -655,7 +655,7 @@ _mpuInit_:
 mcr   p15, #0,r0, c6, c2, #0
 ldr   r0,  r6Base
 mcr   p15, #0,r0, c6, c1, #0
-mov   r0,  #0x0002
+mov   r0,  #0x000B
 orr   r0,  r0,#0x0300
 mcr   p15, #0,r0, c6, c1, #4
 movw  r0,  #((0 << 15) + (0 << 14) + (0 << 13) + (0 << 12) + (0 << 11) 
+ (0 << 10) + (0 <<  9) + (0 <<  8) + (0x1A << 1) + (1))
-- 
2.35.3

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

[PATCH 8/9] bsp/tms570: Use RTI for CPU counter

[Sebastian Huber]

The performance monitor counter is stopped when the core is waiting for
interrupts.

Update #4982.
---
 bsps/arm/tms570/clock/clock.c   | 71 --
 bsps/arm/tms570/cpucounter/cpucounterread.c | 83 -
 spec/build/bsps/arm/tms570/obj.yml  |  1 -
 3 files changed, 48 insertions(+), 107 deletions(-)
 delete mode 100644 bsps/arm/tms570/cpucounter/cpucounterread.c

diff --git a/bsps/arm/tms570/clock/clock.c b/bsps/arm/tms570/clock/clock.c
index 2fb884b3ce..4465e33843 100644
--- a/bsps/arm/tms570/clock/clock.c
+++ b/bsps/arm/tms570/clock/clock.c
@@ -44,27 +44,24 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 static struct timecounter tms570_rti_tc;
 
-static uint32_t tms570_rti_get_timecount(struct timecounter *tc)
+uint32_t _CPU_Counter_frequency(void)
 {
-  return TMS570_RTI.CNT[0].FRCx;
+  return TMS570_RTICLK_HZ / 2;
 }
 
-static void tms570_clock_driver_support_initialize_hardware( void )
+CPU_Counter_ticks _CPU_Counter_read(void)
 {
+  return TMS570_RTI.CNT[0].FRCx;
+}
 
-  uint64_t usec_per_tick;
-  uint32_t tc_frequency;
-  uint32_t tc_increments_per_tick;
-  struct timecounter *tc;
-
-  usec_per_tick = rtems_configuration_get_microseconds_per_tick();
-  tc_frequency = TMS570_RTICLK_HZ / 2;
-  tc_increments_per_tick = (usec_per_tick * tc_frequency + 50) / 100;
-
+static void tms570_rti_initialize( void )
+{
   /* Initialize module */
   TMS570_RTI.GCTRL = 0;
   TMS570_RTI.CAPCTRL = 0;
@@ -72,14 +69,7 @@ static void tms570_clock_driver_support_initialize_hardware( 
void )
   TMS570_RTI.TBCTRL = TMS570_RTI_TBCTRL_INC;
   TMS570_RTI.INTCLRENABLE = 0x05050505;
 
-  /* Initialize counter 0 */
-  TMS570_RTI.CNT[0].CPUCx = 1;
-  TMS570_RTI.CNT[0].UCx = 0;
-  TMS570_RTI.CNT[0].FRCx = 0;
-  TMS570_RTI.CMP[0].COMPx = tc_increments_per_tick;
-  TMS570_RTI.CMP[0].UDCPx = tc_increments_per_tick;
-
-  /* Clear interrupts */
+  /* Disable interrupts */
   TMS570_RTI.CLEARINTENA = TMS570_RTI_CLEARINTENA_CLEAROVL1INT |
TMS570_RTI_CLEARINTENA_CLEAROVL0INT |
TMS570_RTI_CLEARINTENA_CLEARTBINT |
@@ -91,6 +81,44 @@ static void tms570_clock_driver_support_initialize_hardware( 
void )
TMS570_RTI_CLEARINTENA_CLEARINT2 |
TMS570_RTI_CLEARINTENA_CLEARINT1 |
TMS570_RTI_CLEARINTENA_CLEARINT0;
+
+  /* Initialize counter 0 */
+  TMS570_RTI.CNT[0].CPUCx = 1;
+  TMS570_RTI.CNT[0].UCx = 0;
+  TMS570_RTI.CNT[0].FRCx = 0;
+
+  /* Enable counter 0 */
+  TMS570_RTI.GCTRL = TMS570_RTI_GCTRL_CNT0EN;
+}
+
+RTEMS_SYSINIT_ITEM(
+  tms570_rti_initialize,
+  RTEMS_SYSINIT_CPU_COUNTER,
+  RTEMS_SYSINIT_ORDER_MIDDLE
+);
+
+static uint32_t tms570_rti_get_timecount(struct timecounter *tc)
+{
+  return TMS570_RTI.CNT[0].FRCx;
+}
+
+static void tms570_clock_driver_support_initialize_hardware( void )
+{
+
+  uint64_t usec_per_tick;
+  uint32_t tc_frequency;
+  uint32_t tc_increments_per_tick;
+  struct timecounter *tc;
+
+  usec_per_tick = rtems_configuration_get_microseconds_per_tick();
+  tc_frequency = TMS570_RTICLK_HZ / 2;
+  tc_increments_per_tick = (usec_per_tick * tc_frequency + 50) / 100;
+
+  /* Initialize compare 0 */
+  TMS570_RTI.CMP[0].UDCPx = tc_increments_per_tick;
+  TMS570_RTI.CMP[0].COMPx = TMS570_RTI.CNT[0].FRCx + tc_increments_per_tick;
+
+  /* Clear interrupts */
   TMS570_RTI.INTFLAG = TMS570_RTI_INTFLAG_OVL1INT |
TMS570_RTI_INTFLAG_OVL0INT |
TMS570_RTI_INTFLAG_TBINT |
@@ -99,9 +127,6 @@ static void tms570_clock_driver_support_initialize_hardware( 
void )
TMS570_RTI_INTFLAG_INT1 |
TMS570_RTI_INTFLAG_INT0;
 
-  /* Enable counter 0 */
-  TMS570_RTI.GCTRL = TMS570_RTI_GCTRL_CNT0EN;
-
   /* Enable interrupts for counter 0 */
   TMS570_RTI.SETINTENA = TMS570_RTI_SETINTENA_SETINT0;
 
diff --git a/bsps/arm/tms570/cpucounter/cpucounterread.c 
b/bsps/arm/tms570/cpucounter/cpucounterread.c
deleted file mode 100644
index 8cda09f0c6..00
--- a/bsps/arm/tms570/cpucounter/cpucounterread.c
+++ /dev/null
@@ -1,83 +0,0 @@
-/* SPDX-License-Identifier: BSD-2-Clause */
-
-/**
- * @file
- *
- * @ingroup RTEMSBSPsARMTMS570
- *
- * @brief This source file contains the CPU Counter implementation.
- *
- * The counters setup functions are these which has been suggested on
- * StackOverflow.  Code is probably for use on Cortex-A without modifications
- * as well.
- *
- * 
http://stackoverflow.com/questions/3247373/how-to-measure-program-execution-time-in-arm-cortex-a8-processor
- */
-
-/*
- * Copyright (C) 2014 Pavel Pisa 
- *
- * Czech Technical University in Prague
- * Zikova 1903/4
- * 166 36 Praha 6
- * Czech Republic
- *
- * 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 

[PATCH 7/9] bsp/tms570: Add TMS570_FATAL_RTI_IRQ_INSTALL

[Sebastian Huber]

Update #4982.
---
 bsps/arm/tms570/clock/clock.c | 15 ---
 bsps/include/bsp/fatal.h  |  3 +++
 2 files changed, 7 insertions(+), 11 deletions(-)

diff --git a/bsps/arm/tms570/clock/clock.c b/bsps/arm/tms570/clock/clock.c
index cf14d5772f..2fb884b3ce 100644
--- a/bsps/arm/tms570/clock/clock.c
+++ b/bsps/arm/tms570/clock/clock.c
@@ -41,6 +41,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -117,19 +118,11 @@ static void tms570_clock_driver_support_at_tick(volatile 
tms570_rti_t *rti)
   rti->INTFLAG = TMS570_RTI_INTFLAG_INT0;
 }
 
-/**
- * @brief registers RTI interrupt handler
- *
- * @param[in] Clock_isr new ISR handler
- * @param[in] Old_ticker old ISR handler (unused and type broken)
- *
- * @retval Void
- */
 static void tms570_clock_driver_support_install_isr(
   rtems_interrupt_handler handler
 )
 {
-  rtems_status_code sc = RTEMS_SUCCESSFUL;
+  rtems_status_code sc;
 
   sc = rtems_interrupt_handler_install(
 TMS570_IRQ_TIMER_0,
@@ -138,8 +131,8 @@ static void tms570_clock_driver_support_install_isr(
 handler,
 RTEMS_DEVOLATILE(tms570_rti_t *, _RTI)
   );
-  if ( sc != RTEMS_SUCCESSFUL ) {
-rtems_fatal_error_occurred(0xdeadbeef);
+  if (sc != RTEMS_SUCCESSFUL) {
+bsp_fatal(TMS570_FATAL_RTI_IRQ_INSTALL);
   }
 }
 
diff --git a/bsps/include/bsp/fatal.h b/bsps/include/bsp/fatal.h
index 87fc481ead..b41ef2d5c2 100644
--- a/bsps/include/bsp/fatal.h
+++ b/bsps/include/bsp/fatal.h
@@ -217,6 +217,9 @@ typedef enum {
 
   /* Xilinx fatal codes */
   XIL_FATAL_TTC_IRQ_INSTALL = BSP_FATAL_CODE_BLOCK(17),
+
+  /* TMS570 fatal codes */
+  TMS570_FATAL_RTI_IRQ_INSTALL = BSP_FATAL_CODE_BLOCK(18),
 } bsp_fatal_code;
 
 RTEMS_NO_RETURN static inline void
-- 
2.35.3

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

[PATCH 1/9] arm: Add arm_cp15_data_cache_all_invalidate()

[Sebastian Huber]

Update #4982.
---
 cpukit/score/cpu/arm/include/libcpu/arm-cp15.h | 17 +
 1 file changed, 17 insertions(+)

diff --git a/cpukit/score/cpu/arm/include/libcpu/arm-cp15.h 
b/cpukit/score/cpu/arm/include/libcpu/arm-cp15.h
index c239eaccc8..4a5ddb561e 100644
--- a/cpukit/score/cpu/arm/include/libcpu/arm-cp15.h
+++ b/cpukit/score/cpu/arm/include/libcpu/arm-cp15.h
@@ -2371,6 +2371,23 @@ arm_cp15_set_diagnostic_control(uint32_t val)
   );
 }
 
+/* This is probably a Cortex-R5 specific operation */
+ARM_CP15_TEXT_SECTION static inline void
+arm_cp15_data_cache_all_invalidate(void)
+{
+  ARM_SWITCH_REGISTERS;
+  uint32_t sbz = 0;
+
+  __asm__ volatile (
+ARM_SWITCH_TO_ARM
+"mcr p15, 0, %[sbz], c15, c5, 0\n"
+ARM_SWITCH_BACK
+: ARM_SWITCH_OUTPUT
+: [sbz] "r" (sbz)
+: "memory"
+  );
+}
+
 /**
  * @brief Sets the @a section_flags for the address range [@a begin, @a end).
  *
-- 
2.35.3

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

[PATCH 6/9] bsp/tms570: Fix clock driver

[Sebastian Huber]

The clock tick rate was off by a factor of two in some configurations.
Use the maximum counter frequency to get the best time resolution.  Do
not use the automatic interrupt clear feature.

Update #4982.
---
 bsps/arm/tms570/clock/clock.c | 99 +++
 1 file changed, 32 insertions(+), 67 deletions(-)

diff --git a/bsps/arm/tms570/clock/clock.c b/bsps/arm/tms570/clock/clock.c
index a3ea08c967..cf14d5772f 100644
--- a/bsps/arm/tms570/clock/clock.c
+++ b/bsps/arm/tms570/clock/clock.c
@@ -9,6 +9,7 @@
  */
 
 /*
+ * Copyright (C) 2024 embedded brains GmbH & Co. KG
  * Copyright (C) 2014 Premysl Houdek 
  *
  * Google Summer of Code 2014 at
@@ -39,9 +40,6 @@
  * POSSIBILITY OF SUCH DAMAGE.
  */
 
-#include 
-
-#include 
 #include 
 #include 
 #include 
@@ -54,57 +52,33 @@ static uint32_t tms570_rti_get_timecount(struct timecounter 
*tc)
   return TMS570_RTI.CNT[0].FRCx;
 }
 
-#ifndef TMS570_PREFERRED_TC_FREQUENCY
-/*
- * Define preferred main time base counter frequency
- * The value of 1MHz is the best matching RTEMS
- * timing system because then there is no need
- * to scale RTEMS configuration microseconds_per_tick
- * parameter
- */
-#define TMS570_PREFERRED_TC_FREQUENCY 100
-#endif /* TMS570_PREFERRED_TC_FREQUENCY */
-
-/**
- *  @brief Initialize the HW peripheral for clock driver
- *
- *  Clock driver is implemented by RTI module
- *
- * @retval Void
- */
 static void tms570_clock_driver_support_initialize_hardware( void )
 {
 
-  uint32_t microsec_per_tick;
+  uint64_t usec_per_tick;
   uint32_t tc_frequency;
-  uint32_t tc_prescaler;
   uint32_t tc_increments_per_tick;
+  struct timecounter *tc;
 
-  microsec_per_tick = rtems_configuration_get_microseconds_per_tick();
-  tc_frequency = TMS570_PREFERRED_TC_FREQUENCY;
-
-  tc_prescaler = (TMS570_RTICLK_HZ + tc_frequency) / (tc_frequency * 2);
-
-  /* Recompute actual most close frequency which can be realized */
-  tc_frequency = (TMS570_RTICLK_HZ + tc_prescaler) / (tc_prescaler * 2);
+  usec_per_tick = rtems_configuration_get_microseconds_per_tick();
+  tc_frequency = TMS570_RTICLK_HZ / 2;
+  tc_increments_per_tick = (usec_per_tick * tc_frequency + 50) / 100;
 
-  /*
-   * Recompute tick period to adjust for configurable or exact
-   * preferred time base 1 usec resolution.
-   */
-  tc_increments_per_tick = ((uint64_t)microsec_per_tick * tc_frequency +
-   50) / 100;
-
-  /* Hardware specific initialize */
+  /* Initialize module */
   TMS570_RTI.GCTRL = 0;
-  TMS570_RTI.CNT[0].CPUCx = tc_prescaler - 1;
-  TMS570_RTI.TBCTRL = TMS570_RTI_TBCTRL_INC;
   TMS570_RTI.CAPCTRL = 0;
   TMS570_RTI.COMPCTRL = 0;
-  /* set counter to zero */
+  TMS570_RTI.TBCTRL = TMS570_RTI_TBCTRL_INC;
+  TMS570_RTI.INTCLRENABLE = 0x05050505;
+
+  /* Initialize counter 0 */
+  TMS570_RTI.CNT[0].CPUCx = 1;
   TMS570_RTI.CNT[0].UCx = 0;
   TMS570_RTI.CNT[0].FRCx = 0;
-  /* clear interrupts*/
+  TMS570_RTI.CMP[0].COMPx = tc_increments_per_tick;
+  TMS570_RTI.CMP[0].UDCPx = tc_increments_per_tick;
+
+  /* Clear interrupts */
   TMS570_RTI.CLEARINTENA = TMS570_RTI_CLEARINTENA_CLEAROVL1INT |
TMS570_RTI_CLEARINTENA_CLEAROVL0INT |
TMS570_RTI_CLEARINTENA_CLEARTBINT |
@@ -123,27 +97,21 @@ static void 
tms570_clock_driver_support_initialize_hardware( void )
TMS570_RTI_INTFLAG_INT2 |
TMS570_RTI_INTFLAG_INT1 |
TMS570_RTI_INTFLAG_INT0;
-  /* set timer */
-  TMS570_RTI.CMP[0].COMPx = TMS570_RTI.CNT[0].FRCx + tc_increments_per_tick;
-  TMS570_RTI.COMP0CLR = TMS570_RTI.CMP[0].COMPx + tc_increments_per_tick / 2;
-  TMS570_RTI.CMP[0].UDCPx = tc_increments_per_tick;
-  /* enable interupt */
-  TMS570_RTI.SETINTENA = TMS570_RTI_SETINTENA_SETINT0;
-  /* enable timer */
+
+  /* Enable counter 0 */
   TMS570_RTI.GCTRL = TMS570_RTI_GCTRL_CNT0EN;
-  /* set timecounter */
-  tms570_rti_tc.tc_get_timecount = tms570_rti_get_timecount;
-  tms570_rti_tc.tc_counter_mask = 0x;
-  tms570_rti_tc.tc_frequency = tc_frequency;
-  tms570_rti_tc.tc_quality = RTEMS_TIMECOUNTER_QUALITY_CLOCK_DRIVER;
-  rtems_timecounter_install(_rti_tc);
+
+  /* Enable interrupts for counter 0 */
+  TMS570_RTI.SETINTENA = TMS570_RTI_SETINTENA_SETINT0;
+
+  tc = _rti_tc;
+  tc->tc_get_timecount = tms570_rti_get_timecount;
+  tc->tc_counter_mask = 0x;
+  tc->tc_frequency = tc_frequency;
+  tc->tc_quality = RTEMS_TIMECOUNTER_QUALITY_CLOCK_DRIVER;
+  rtems_timecounter_install(tc);
 }
 
-/**
- * @brief Clears interrupt source
- *
- * @retval Void
- */
 static void tms570_clock_driver_support_at_tick(volatile tms570_rti_t *rti)
 {
   rti->INTFLAG = TMS570_RTI_INTFLAG_INT0;
@@ -175,14 +143,11 @@ static void tms570_clock_driver_support_install_isr(
   }
 }
 
-#define Clock_driver_support_initialize_hardware \
-tms570_clock_driver_support_initialize_hardware
+#define Clock_driver_support_initialize_hardware() 

[PATCH 4/9] bsp/tms570: Add TMS570LC4357 PLL support

[Sebastian Huber]

Update #4982.
---
 bsps/arm/tms570/include/bsp/ti_herc/reg_sys.h | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/bsps/arm/tms570/include/bsp/ti_herc/reg_sys.h 
b/bsps/arm/tms570/include/bsp/ti_herc/reg_sys.h
index d5583a1cca..1ca2bff685 100644
--- a/bsps/arm/tms570/include/bsp/ti_herc/reg_sys.h
+++ b/bsps/arm/tms570/include/bsp/ti_herc/reg_sys.h
@@ -355,6 +355,11 @@ typedef struct{
 /* field: ROS - Reset on PLL Slip */
 #define TMS570_SYS1_PLLCTL1_ROS BSP_BIT32(31)
 
+/* field: BPOS - Bypass of PLL Slip */
+#define TMS570_SYS1_PLLCTL1_BPOS(val) BSP_FLD32(val,29, 30)
+#define TMS570_SYS1_PLLCTL1_BPOS_GET(reg) BSP_FLD32GET(reg,29, 30)
+#define TMS570_SYS1_PLLCTL1_BPOS_SET(reg,val) BSP_FLD32SET(reg, val,29, 30)
+
 /* field: MASK_SLIP - Mask detection of PLL slip */
 #define TMS570_SYS1_PLLCTL1_MASK_SLIP(val) BSP_FLD32(val,29, 30)
 #define TMS570_SYS1_PLLCTL1_MASK_SLIP_GET(reg) BSP_FLD32GET(reg,29, 30)
@@ -404,6 +409,28 @@ typedef struct{
 #define TMS570_SYS1_PLLCTL2_SPR_AMOUNT_SET(reg,val) BSP_FLD32SET(reg, val,0, 8)
 
 
+/*TMS570_SYS1_PLLCTL3*/
+/* field: ODPLL2 - Internal PLL Output Divider. */
+#define TMS570_SYS1_PLLCTL3_ODPLL2(val) BSP_FLD32(val, 29, 31)
+#define TMS570_SYS1_PLLCTL3_ODPLL2_GET(reg) BSP_FLD32GET(reg, 29, 31)
+#define TMS570_SYS1_PLLCTL3_ODPLL2_SET(reg,val) BSP_FLD32SET(reg, val, 29, 31)
+
+/* field: PLLDIV2 - PLL2 Output Clock Divider. */
+#define TMS570_SYS1_PLLCTL3_PLLDIV2(val) BSP_FLD32(val, 24, 28)
+#define TMS570_SYS1_PLLCTL3_PLLDIV2_GET(reg) BSP_FLD32GET(reg, 24, 28)
+#define TMS570_SYS1_PLLCTL3_PLLDIV2_SET(reg,val) BSP_FLD32SET(reg, val, 24, 28)
+
+/* field: REFCLKDIV2 - Reference Clock Divider. */
+#define TMS570_SYS1_PLLCTL3_REFCLKDIV2(val) BSP_FLD32(val, 16, 21)
+#define TMS570_SYS1_PLLCTL3_REFCLKDIV2_GET(reg) BSP_FLD32GET(reg, 16, 21)
+#define TMS570_SYS1_PLLCTL3_REFCLKDIV2_SET(reg,val) BSP_FLD32SET(reg, val, 16, 
21)
+
+/* field: PLLMUL2 - PLL2 Multiplication Factor. */
+#define TMS570_SYS1_PLLCTL3_PLLMUL2(val) BSP_FLD32(val, 0, 15)
+#define TMS570_SYS1_PLLCTL3_PLLMUL2_GET(reg) BSP_FLD32GET(reg, 0, 15)
+#define TMS570_SYS1_PLLCTL3_PLLMUL2_SET(reg,val) BSP_FLD32SET(reg, val, 0, 15)
+
+
 /*TMS570_SYS1_SYSPC10*/
 /* field: ECPCLK_SLEW - ECPCLK slew control. This bit controls between the 
fast or slow slew mode. */
 #define TMS570_SYS1_SYSPC10_ECPCLK_SLEW BSP_BIT32(0)
-- 
2.35.3

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

[PATCH 5/9] bsp/tms570: Add clock BSP options

[Sebastian Huber]

Update #4982.
---
 bsps/arm/tms570/clock/clock.c   |  4 ++--
 bsps/arm/tms570/console/tms570-sci.c|  2 +-
 bsps/arm/tms570/cpucounter/cpucounterread.c |  2 +-
 bsps/arm/tms570/include/bsp.h   |  6 --
 spec/build/bsps/arm/tms570/grp.yml  | 12 
 spec/build/bsps/arm/tms570/optgclk.yml  | 21 +
 spec/build/bsps/arm/tms570/opthclk.yml  | 21 +
 spec/build/bsps/arm/tms570/optrticlk.yml| 21 +
 spec/build/bsps/arm/tms570/optvclk.yml  | 21 +
 spec/build/bsps/arm/tms570/optvclk2.yml | 21 +
 spec/build/bsps/arm/tms570/optvclk3.yml | 21 +
 11 files changed, 142 insertions(+), 10 deletions(-)
 create mode 100644 spec/build/bsps/arm/tms570/optgclk.yml
 create mode 100644 spec/build/bsps/arm/tms570/opthclk.yml
 create mode 100644 spec/build/bsps/arm/tms570/optrticlk.yml
 create mode 100644 spec/build/bsps/arm/tms570/optvclk.yml
 create mode 100644 spec/build/bsps/arm/tms570/optvclk2.yml
 create mode 100644 spec/build/bsps/arm/tms570/optvclk3.yml

diff --git a/bsps/arm/tms570/clock/clock.c b/bsps/arm/tms570/clock/clock.c
index 2e71440857..a3ea08c967 100644
--- a/bsps/arm/tms570/clock/clock.c
+++ b/bsps/arm/tms570/clock/clock.c
@@ -83,10 +83,10 @@ static void 
tms570_clock_driver_support_initialize_hardware( void )
   microsec_per_tick = rtems_configuration_get_microseconds_per_tick();
   tc_frequency = TMS570_PREFERRED_TC_FREQUENCY;
 
-  tc_prescaler = (BSP_PLL_OUT_CLOCK + tc_frequency) / (tc_frequency * 2);
+  tc_prescaler = (TMS570_RTICLK_HZ + tc_frequency) / (tc_frequency * 2);
 
   /* Recompute actual most close frequency which can be realized */
-  tc_frequency = (BSP_PLL_OUT_CLOCK + tc_prescaler) / (tc_prescaler * 2);
+  tc_frequency = (TMS570_RTICLK_HZ + tc_prescaler) / (tc_prescaler * 2);
 
   /*
* Recompute tick period to adjust for configurable or exact
diff --git a/bsps/arm/tms570/console/tms570-sci.c 
b/bsps/arm/tms570/console/tms570-sci.c
index 63f8e7c8ee..6cb61f2b5d 100644
--- a/bsps/arm/tms570/console/tms570-sci.c
+++ b/bsps/arm/tms570/console/tms570-sci.c
@@ -297,7 +297,7 @@ bool tms570_sci_set_attributes(
 
   /* Apply baudrate to the hardware */
   baudrate *= 2 * 16;
-  bauddiv = (BSP_PLL_OUT_CLOCK + baudrate / 2) / baudrate;
+  bauddiv = (TMS570_VCLK_HZ + baudrate / 2) / baudrate;
   ctx->regs->BRS = bauddiv? bauddiv - 1: 0;
 
   ctx->regs->GCR1 |= TMS570_SCI_GCR1_SWnRST | TMS570_SCI_GCR1_TXENA |
diff --git a/bsps/arm/tms570/cpucounter/cpucounterread.c 
b/bsps/arm/tms570/cpucounter/cpucounterread.c
index 009a37bec3..8cda09f0c6 100644
--- a/bsps/arm/tms570/cpucounter/cpucounterread.c
+++ b/bsps/arm/tms570/cpucounter/cpucounterread.c
@@ -68,7 +68,7 @@ static void tms570_cpu_counter_initialize(void)
 
 uint32_t _CPU_Counter_frequency(void)
 {
-  return 2 * BSP_PLL_OUT_CLOCK;
+  return TMS570_GCLK_HZ;
 }
 
 CPU_Counter_ticks _CPU_Counter_read(void)
diff --git a/bsps/arm/tms570/include/bsp.h b/bsps/arm/tms570/include/bsp.h
index 287750295f..1f84486ad4 100644
--- a/bsps/arm/tms570/include/bsp.h
+++ b/bsps/arm/tms570/include/bsp.h
@@ -61,12 +61,6 @@
 #include 
 #include 
 
-#if TMS570_VARIANT == 4357
-#define BSP_PLL_OUT_CLOCK 15000
-#else
-#define BSP_PLL_OUT_CLOCK 16000
-#endif
-
 RTEMS_NO_RETURN void bsp_restart(const void *addr);
 
 #endif /* ASM */
diff --git a/spec/build/bsps/arm/tms570/grp.yml 
b/spec/build/bsps/arm/tms570/grp.yml
index 5a3d4784be..c6d9f02d14 100644
--- a/spec/build/bsps/arm/tms570/grp.yml
+++ b/spec/build/bsps/arm/tms570/grp.yml
@@ -32,6 +32,18 @@ links:
   uid: optmintskstksz
 - role: build-dependency
   uid: optoscmain
+- role: build-dependency
+  uid: optgclk
+- role: build-dependency
+  uid: opthclk
+- role: build-dependency
+  uid: optvclk
+- role: build-dependency
+  uid: optvclk2
+- role: build-dependency
+  uid: optvclk3
+- role: build-dependency
+  uid: optrticlk
 - role: build-dependency
   uid: optreginit
 - role: build-dependency
diff --git a/spec/build/bsps/arm/tms570/optgclk.yml 
b/spec/build/bsps/arm/tms570/optgclk.yml
new file mode 100644
index 00..f7ec86a250
--- /dev/null
+++ b/spec/build/bsps/arm/tms570/optgclk.yml
@@ -0,0 +1,21 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-integer: null
+- define: null
+build-type: option
+copyrights:
+- Copyright (C) 2024 embedded brains GmbH & Co. KG
+default:
+- enabled-by:
+  - arm/tms570lc4357_hdk
+  - arm/tms570lc4357_hdk_sdram
+  value: 3
+- enabled-by: true
+  value: 16000
+description: |
+  The option value shall be the GCLK frequency in Hz.
+enabled-by: true
+format: '{}'
+links: []
+name: TMS570_GCLK_HZ
+type: build
diff --git a/spec/build/bsps/arm/tms570/opthclk.yml 
b/spec/build/bsps/arm/tms570/opthclk.yml
new file mode 100644
index 00..652c151eec
--- /dev/null
+++ b/spec/build/bsps/arm/tms570/opthclk.yml
@@ -0,0 +1,21 @@
+SPDX-License-Identifier: 

[PATCH 3/9] bsps/cache: Fix ARM CP-15 get cache size

[Sebastian Huber]

The rtems_cache_get_data_cache_size() and
rtems_cache_get_instruction_cache_size() functions shall return the entire
cache size for a level of 0.  Levels greater than 0 shall return the size of
the associated level.

Update #4982.
---
 bsps/arm/shared/cache/cache-cp15.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/bsps/arm/shared/cache/cache-cp15.c 
b/bsps/arm/shared/cache/cache-cp15.c
index 92ccfcb276..8e0f22282b 100644
--- a/bsps/arm/shared/cache/cache-cp15.c
+++ b/bsps/arm/shared/cache/cache-cp15.c
@@ -222,12 +222,12 @@ static inline size_t arm_cp15_get_cache_size(
   clidr = arm_cp15_get_cache_level_id();
   loc = arm_clidr_get_level_of_coherency(clidr);
 
-  if (level >= loc) {
-return 0;
-  }
-
   if (level == 0) {
 level = loc - 1;
+  } else if (level - 1 >= loc) {
+return 0;
+  } else {
+--level;
   }
 
   ccsidr = arm_cp15_get_cache_size_id_for_level(
-- 
2.35.3

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

[PATCH 2/9] bsps/cache: Simplify Cortex-R5 cache support

[Sebastian Huber]

Update #4982.
---
 bsps/arm/shared/cache/cache-cp15.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/bsps/arm/shared/cache/cache-cp15.c 
b/bsps/arm/shared/cache/cache-cp15.c
index 88fae2fb1f..92ccfcb276 100644
--- a/bsps/arm/shared/cache/cache-cp15.c
+++ b/bsps/arm/shared/cache/cache-cp15.c
@@ -54,6 +54,10 @@
   #define CPU_CACHE_SUPPORT_PROVIDES_DISABLE_DATA
 #endif
 
+#if __ARM_ARCH == 7 && __ARM_ARCH_PROFILE == 'R'
+  #define CACHE_CP15_IS_CORTEX_R5
+#endif
+
 static inline void _CPU_cache_flush_1_data_line(const void *d_addr)
 {
   arm_cache_l1_flush_1_data_line(d_addr);
@@ -128,7 +132,9 @@ static inline void _CPU_cache_unfreeze_instruction(void)
 static inline void _CPU_cache_flush_entire_data(void)
 {
   _ARM_Data_synchronization_barrier();
-#if __ARM_ARCH >= 7
+#if defined(CACHE_CP15_IS_CORTEX_R5)
+  arm_cp15_data_cache_clean_level(0);
+#elif __ARM_ARCH >= 7
   arm_cp15_data_cache_clean_all_levels();
 #else
   arm_cp15_data_cache_clean_and_invalidate();
@@ -139,7 +145,9 @@ static inline void _CPU_cache_flush_entire_data(void)
 
 static inline void _CPU_cache_invalidate_entire_data(void)
 {
-#if __ARM_ARCH >= 7
+#if defined(CACHE_CP15_IS_CORTEX_R5)
+  arm_cp15_data_cache_all_invalidate();
+#elif __ARM_ARCH >= 7
   arm_cp15_data_cache_invalidate_all_levels();
 #else
   arm_cp15_data_cache_invalidate();
-- 
2.35.3

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

[PATCH 0/9] bsp/tms570 Improvements

[Sebastian Huber]

Sebastian Huber (9):
  arm: Add arm_cp15_data_cache_all_invalidate()
  bsps/cache: Simplify Cortex-R5 cache support
  bsps/cache: Fix ARM CP-15 get cache size
  bsp/tms570: Add TMS570LC4357 PLL support
  bsp/tms570: Add clock BSP options
  bsp/tms570: Fix clock driver
  bsp/tms570: Add TMS570_FATAL_RTI_IRQ_INSTALL
  bsp/tms570: Use RTI for CPU counter
  bsp/tms570: Use write-back/write-allocate SDRAM

 bsps/arm/shared/cache/cache-cp15.c|  20 ++-
 bsps/arm/tms570/clock/clock.c | 157 --
 bsps/arm/tms570/console/tms570-sci.c  |   2 +-
 bsps/arm/tms570/cpucounter/cpucounterread.c   |  83 -
 bsps/arm/tms570/include/bsp.h |   6 -
 bsps/arm/tms570/include/bsp/ti_herc/reg_sys.h |  27 +++
 bsps/arm/tms570/start/tms570_sys_core.S   |   2 +-
 bsps/include/bsp/fatal.h  |   3 +
 .../score/cpu/arm/include/libcpu/arm-cp15.h   |  17 ++
 spec/build/bsps/arm/tms570/grp.yml|  12 ++
 spec/build/bsps/arm/tms570/obj.yml|   1 -
 spec/build/bsps/arm/tms570/optgclk.yml|  21 +++
 spec/build/bsps/arm/tms570/opthclk.yml|  21 +++
 spec/build/bsps/arm/tms570/optrticlk.yml  |  21 +++
 spec/build/bsps/arm/tms570/optvclk.yml|  21 +++
 spec/build/bsps/arm/tms570/optvclk2.yml   |  21 +++
 spec/build/bsps/arm/tms570/optvclk3.yml   |  21 +++
 17 files changed, 271 insertions(+), 185 deletions(-)
 delete mode 100644 bsps/arm/tms570/cpucounter/cpucounterread.c
 create mode 100644 spec/build/bsps/arm/tms570/optgclk.yml
 create mode 100644 spec/build/bsps/arm/tms570/opthclk.yml
 create mode 100644 spec/build/bsps/arm/tms570/optrticlk.yml
 create mode 100644 spec/build/bsps/arm/tms570/optvclk.yml
 create mode 100644 spec/build/bsps/arm/tms570/optvclk2.yml
 create mode 100644 spec/build/bsps/arm/tms570/optvclk3.yml

-- 
2.35.3

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

[PATCH 6/6] bsps/arm: Fix Doxygen group assignment

[Sebastian Huber]

---
 bsps/arm/shared/cache/cache-cp15.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/bsps/arm/shared/cache/cache-cp15.c 
b/bsps/arm/shared/cache/cache-cp15.c
index d78ec4feb4..88fae2fb1f 100644
--- a/bsps/arm/shared/cache/cache-cp15.c
+++ b/bsps/arm/shared/cache/cache-cp15.c
@@ -3,9 +3,10 @@
 /**
  * @file
  *
- * @ingroup arm
+ * @ingroup RTEMSImplClassicCache
  *
- * @brief ARM cache defines and implementation.
+ * @brief This source file contains the Cache Manager implementation for
+ *   devices using the ARM CP15.
  */
 
 /*
-- 
2.35.3

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

[PATCH 4/6] bsps/arm: Add Doxygen group for Armv7-M SysTick

[Sebastian Huber]

Change license to BSD-2-Clause according to file history and contributor
agreements.
---
 bsps/arm/include/bsp/clock-armv7m.h   | 49 +--
 bsps/arm/shared/clock/clock-armv7m.c  |  8 +++
 .../arm/shared/cpucounter/cpucounter-armv7m.c |  8 +++
 3 files changed, 61 insertions(+), 4 deletions(-)

diff --git a/bsps/arm/include/bsp/clock-armv7m.h 
b/bsps/arm/include/bsp/clock-armv7m.h
index 62f201153e..28adf34453 100644
--- a/bsps/arm/include/bsp/clock-armv7m.h
+++ b/bsps/arm/include/bsp/clock-armv7m.h
@@ -1,9 +1,37 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSDriverClockArmv7MSysTick
+ *
+ * @brief This header file provides support for Armv7-M clock drivers.
+ */
+
 /*
- * Copyright (c) 2011, 2018 Sebastian Huber.  All rights reserved.
+ * Copyright (C) 2024 embedded brains GmbH & Co. KG
+ * Copyright (C) 2011, 2018 Sebastian Huber
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
  *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
  */
 
 #ifndef BSP_CLOCK_ARMV7M_H
@@ -18,6 +46,17 @@
 extern "C" {
 #endif /* __cplusplus */
 
+/**
+ * @defgroup RTEMSDriverClockArmv7MSysTick Armv7-M SysTick Clock Driver
+ *
+ * @ingroup RTEMSDriverClockImpl
+ *
+ * @brief This group contains the Armv7-M SysTick support and Clock Driver
+ *   implementation.
+ *
+ * @{
+ */
+
 #ifdef ARM_MULTILIB_ARCH_V7M
 
 typedef struct {
@@ -67,6 +106,8 @@ static uint32_t _ARMV7M_Clock_counter(ARMV7M_Timecounter *tc)
 
 #endif /* ARM_MULTILIB_ARCH_V7M */
 
+/** @} */
+
 #ifdef __cplusplus
 }
 #endif /* __cplusplus */
diff --git a/bsps/arm/shared/clock/clock-armv7m.c 
b/bsps/arm/shared/clock/clock-armv7m.c
index ce1d3b38bd..ee3b8a7939 100644
--- a/bsps/arm/shared/clock/clock-armv7m.c
+++ b/bsps/arm/shared/clock/clock-armv7m.c
@@ -1,5 +1,13 @@
 /* SPDX-License-Identifier: BSD-2-Clause */
 
+/**
+ * @file
+ *
+ * @ingroup RTEMSDriverClockArmv7MSysTick
+ *
+ * @brief This source file contains the Armv7-M SysTick Clock Driver.
+ */
+
 /*
  * Copyright (C) 2020 embedded brains GmbH & Co. KG
  * Copyright (C) 2011, 2018 Sebastian Huber
diff --git a/bsps/arm/shared/cpucounter/cpucounter-armv7m.c 
b/bsps/arm/shared/cpucounter/cpucounter-armv7m.c
index f43ad42248..95fdee365c 100644
--- a/bsps/arm/shared/cpucounter/cpucounter-armv7m.c
+++ b/bsps/arm/shared/cpucounter/cpucounter-armv7m.c
@@ -1,5 +1,13 @@
 /* SPDX-License-Identifier: BSD-2-Clause */
 
+/**
+ * @file
+ *
+ * @ingroup RTEMSDriverClockArmv7MSysTick
+ *
+ * @brief This source file contains the Armv7-M SysTick CPU counter.
+ */
+
 /*
  * Copyright (C) 2016, 2018 embedded brains GmbH & Co. KG
  *
-- 
2.35.3

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

[PATCH 5/6] bsps/arm: Add CMSIS files to Doxygen group

[Sebastian Huber]

---
 bsps/arm/shared/doxygen.h | 56 +++
 1 file changed, 56 insertions(+)

diff --git a/bsps/arm/shared/doxygen.h b/bsps/arm/shared/doxygen.h
index 469928d712..8dbf129f07 100644
--- a/bsps/arm/shared/doxygen.h
+++ b/bsps/arm/shared/doxygen.h
@@ -29,3 +29,59 @@
  *
  * @brief Cortex Microcontroller Software Interface Standard (CMSIS).
  */
+
+/**
+ * @file cachel1_armv7.h
+ *
+ * @ingroup CMSIS
+ *
+ * @brief This header file provides CMSIS interfaces.
+ */
+
+/**
+ * @file cmsis_compiler.h
+ *
+ * @ingroup CMSIS
+ *
+ * @brief This header file provides CMSIS interfaces.
+ */
+
+/**
+ * @file cmsis_gcc.h
+ *
+ * @ingroup CMSIS
+ *
+ * @brief This header file provides CMSIS interfaces.
+ */
+
+/**
+ * @file cmsis_version.h
+ *
+ * @ingroup CMSIS
+ *
+ * @brief This header file provides CMSIS interfaces.
+ */
+
+/**
+ * @file core_cm4.h
+ *
+ * @ingroup CMSIS
+ *
+ * @brief This header file provides CMSIS interfaces.
+ */
+
+/**
+ * @file core_cm7.h
+ *
+ * @ingroup CMSIS
+ *
+ * @brief This header file provides CMSIS interfaces.
+ */
+
+/**
+ * @file mpu_armv7.h
+ *
+ * @ingroup CMSIS
+ *
+ * @brief This header file provides CMSIS interfaces.
+ */
-- 
2.35.3

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

[PATCH 3/6] bsps/aarch64: Define Doxygen groups

[Sebastian Huber]

Fix typos.
---
 bsps/aarch64/include/bsp/linker-symbols.h |  2 +-
 bsps/aarch64/include/bsp/start.h  |  2 +-
 bsps/aarch64/shared/doxygen.h | 23 +++
 3 files changed, 25 insertions(+), 2 deletions(-)
 create mode 100644 bsps/aarch64/shared/doxygen.h

diff --git a/bsps/aarch64/include/bsp/linker-symbols.h 
b/bsps/aarch64/include/bsp/linker-symbols.h
index 222c217abb..c550bd9eba 100644
--- a/bsps/aarch64/include/bsp/linker-symbols.h
+++ b/bsps/aarch64/include/bsp/linker-symbols.h
@@ -46,7 +46,7 @@ extern "C" {
 /**
  * @defgroup aarch64_linker Linker Support
  *
- * @ingroup RTEMSBSPsAARCH64Shared
+ * @ingroup RTEMSBSPsAArch64Shared
  *
  * @brief Linker support.
  *
diff --git a/bsps/aarch64/include/bsp/start.h b/bsps/aarch64/include/bsp/start.h
index f0af5be841..bd46087949 100644
--- a/bsps/aarch64/include/bsp/start.h
+++ b/bsps/aarch64/include/bsp/start.h
@@ -48,7 +48,7 @@ extern "C" {
 /**
  * @defgroup aarch64_start System Start
  *
- * @ingroup RTEMSBSPsAarch64Shared
+ * @ingroup RTEMSBSPsAArch64Shared
  *
  * @brief Aarch64 system low level start.
  *
diff --git a/bsps/aarch64/shared/doxygen.h b/bsps/aarch64/shared/doxygen.h
new file mode 100644
index 00..5f639f5008
--- /dev/null
+++ b/bsps/aarch64/shared/doxygen.h
@@ -0,0 +1,23 @@
+/**
+ * @file
+ *
+ * @ingroup RTEMSImplDoxygen
+ *
+ * @brief This header file defines BSP-specific groups.
+ */
+
+/**
+ * @defgroup RTEMSBSPsAArch64 AArch64
+ *
+ * @ingroup RTEMSBSPs
+ *
+ * @brief This group contains AArch64 Board Support Packages.
+ */
+
+/**
+ * @defgroup RTEMSBSPsAArch64Shared Shared
+ *
+ * @ingroup RTEMSBSPsAArch64
+ *
+ * @brief This group contains support shared by AArch64 Board Support Packages.
+ */
-- 
2.35.3

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

[PATCH 2/6] aarch64: Add files to Doxygen groups

[Sebastian Huber]

---
 cpukit/score/cpu/aarch64/aarch64-thread-idle.c |  7 +--
 cpukit/score/cpu/aarch64/include/rtems/asm.h   |  5 -
 .../include/rtems/score/aarch64-system-registers.h |  2 ++
 cpukit/score/cpu/aarch64/include/rtems/score/cpu.h | 10 +++---
 4 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/cpukit/score/cpu/aarch64/aarch64-thread-idle.c 
b/cpukit/score/cpu/aarch64/aarch64-thread-idle.c
index ce93b4facd..cbaa29a166 100644
--- a/cpukit/score/cpu/aarch64/aarch64-thread-idle.c
+++ b/cpukit/score/cpu/aarch64/aarch64-thread-idle.c
@@ -1,9 +1,12 @@
 /* SPDX-License-Identifier: BSD-2-Clause */
 
 /**
- *  @file
+ * @file
  *
- *  @brief CPU Thread Idle Body
+ * @ingroup RTEMSScoreCPUAArch64
+ *
+ * @brief This source file contains the AArch64-specific
+ *   _CPU_Thread_Idle_body() implementation.
  */
 
 /*
diff --git a/cpukit/score/cpu/aarch64/include/rtems/asm.h 
b/cpukit/score/cpu/aarch64/include/rtems/asm.h
index fa53e08291..1870af97d2 100644
--- a/cpukit/score/cpu/aarch64/include/rtems/asm.h
+++ b/cpukit/score/cpu/aarch64/include/rtems/asm.h
@@ -3,7 +3,10 @@
 /**
  * @file
  *
- * @brief AArch64 Assembler Support API
+ * @ingroup RTEMSScoreCPUAArch64ASM
+ *
+ * @brief This header file provides interfaces to address problems caused by
+ *   incompatible flavor of assemblers and toolsets.
  *
  * This include file attempts to address the problems
  * caused by incompatible flavors of assemblers and
diff --git 
a/cpukit/score/cpu/aarch64/include/rtems/score/aarch64-system-registers.h 
b/cpukit/score/cpu/aarch64/include/rtems/score/aarch64-system-registers.h
index 8ddad5becf..364ff8e836 100644
--- a/cpukit/score/cpu/aarch64/include/rtems/score/aarch64-system-registers.h
+++ b/cpukit/score/cpu/aarch64/include/rtems/score/aarch64-system-registers.h
@@ -3,6 +3,8 @@
 /**
  * @file
  *
+ * @ingroup RTEMSScoreCPUAArch64
+ *
  * @brief This header file provides the API to read and write the AArch64
  *   system registers.
  */
diff --git a/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h 
b/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h
index aa4f90f1a8..8a8e80832f 100644
--- a/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h
+++ b/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h
@@ -3,9 +3,9 @@
 /**
  * @file
  *
- * @ingroup RTEMSScoreCPU
+ * @ingroup RTEMSScoreCPUAArch64
  *
- * @brief AArch64 Architecture Support API
+ * @brief This header file provides interfaces of the AArch64 CPU port.
  */
 
 /*
@@ -46,7 +46,11 @@
 #include 
 
 /**
- * @addtogroup RTEMSScoreCPUAArch64
+ * @defgroup RTEMSScoreCPUAArch64 AArch64
+ *
+ * @ingroup RTEMSScoreCPU
+ *
+ * @brief This group contains the AArch64 CPU port.
  *
  * @{
  */
-- 
2.35.3

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

[PATCH 0/6] Doxygen improvements

[Sebastian Huber]

Sebastian Huber (6):
  bsps: Add Doxygen group for Arm Generic Timer
  aarch64: Add files to Doxygen groups
  bsps/aarch64: Define Doxygen groups
  bsps/arm: Add Doxygen group for Armv7-M SysTick
  bsps/arm: Add CMSIS files to Doxygen group
  bsps/arm: Fix Doxygen group assignment

 bsps/aarch64/include/bsp/linker-symbols.h |  2 +-
 bsps/aarch64/include/bsp/start.h  |  2 +-
 bsps/aarch64/shared/doxygen.h | 23 
 bsps/arm/include/bsp/clock-armv7m.h   | 49 ++--
 bsps/arm/shared/cache/cache-cp15.c|  5 +-
 bsps/arm/shared/clock/clock-armv7m.c  |  8 +++
 .../arm/shared/cpucounter/cpucounter-armv7m.c |  8 +++
 bsps/arm/shared/doxygen.h | 56 +++
 bsps/shared/dev/clock/arm-generic-timer.c | 26 -
 .../score/cpu/aarch64/aarch64-thread-idle.c   |  7 ++-
 cpukit/score/cpu/aarch64/include/rtems/asm.h  |  5 +-
 .../rtems/score/aarch64-system-registers.h|  2 +
 .../cpu/aarch64/include/rtems/score/cpu.h | 10 +++-
 13 files changed, 186 insertions(+), 17 deletions(-)
 create mode 100644 bsps/aarch64/shared/doxygen.h

-- 
2.35.3

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

[PATCH 1/6] bsps: Add Doxygen group for Arm Generic Timer

[Sebastian Huber]

---
 bsps/shared/dev/clock/arm-generic-timer.c | 26 ---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/bsps/shared/dev/clock/arm-generic-timer.c 
b/bsps/shared/dev/clock/arm-generic-timer.c
index 44cf1ebe6c..b2842df175 100644
--- a/bsps/shared/dev/clock/arm-generic-timer.c
+++ b/bsps/shared/dev/clock/arm-generic-timer.c
@@ -1,5 +1,14 @@
 /* SPDX-License-Identifier: BSD-2-Clause */
 
+/**
+ * @file
+ *
+ * @ingroup RTEMSDriverClockArmGenericTimer
+ *
+ * @brief This source file contains a Clock Driver implementation using
+ *   Armv7-AR/AArch64 Generic Timer.
+ */
+
 /*
  * Copyright (c) 2017 embedded brains GmbH & Co. KG
  *
@@ -36,14 +45,23 @@
 #include 
 #include 
 
-/*
- * Clock driver using the ARMv7-AR/AArch64 Generic Timer.  The BSP must 
provide the
- * following function:
+/**
+ * @defgroup RTEMSDriverClockArmGenericTimer \
+ *   Armv7-AR/AArch64 Generic Timer Clock Driver
+ *
+ * @ingroup RTEMSDriverClockImpl
+ *
+ * @brief This group contains the Armv7-AR/AArch64 Generic Timer Clock Driver
+ *   implementation.
+ *
+ * The BSP must provide the following function:
  *
  * void arm_generic_timer_get_config(uint32_t *frequency, uint32_t *irq);
  *
  * The BSP may optionally define ARM_GENERIC_TIMER_USE_VIRTUAL in  to
  * use the virtual timer instead of the physical timer.
+ *
+ * @{
  */
 
 typedef struct {
@@ -197,5 +215,7 @@ RTEMS_SYSINIT_ITEM(
 #define Clock_driver_support_install_isr(isr) \
   arm_gt_clock_handler_install(isr)
 
+/** @} */
+
 /* Include shared source clock driver code */
 #include "../../shared/dev/clock/clockimpl.h"
-- 
2.35.3

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

[PATCH 3/3] bsps/arm: Move BSP-specific header file

[Sebastian Huber]

---
 bsps/arm/{ => edb7312}/include/uart.h  | 0
 spec/build/bsps/arm/edb7312/bspedb7312.yml | 1 +
 spec/build/bsps/arm/grp.yml| 1 -
 3 files changed, 1 insertion(+), 1 deletion(-)
 rename bsps/arm/{ => edb7312}/include/uart.h (100%)

diff --git a/bsps/arm/include/uart.h b/bsps/arm/edb7312/include/uart.h
similarity index 100%
rename from bsps/arm/include/uart.h
rename to bsps/arm/edb7312/include/uart.h
diff --git a/spec/build/bsps/arm/edb7312/bspedb7312.yml 
b/spec/build/bsps/arm/edb7312/bspedb7312.yml
index a86000cbc5..9461841aa4 100644
--- a/spec/build/bsps/arm/edb7312/bspedb7312.yml
+++ b/spec/build/bsps/arm/edb7312/bspedb7312.yml
@@ -14,6 +14,7 @@ install:
   source:
   - bsps/arm/edb7312/include/bsp.h
   - bsps/arm/edb7312/include/ep7312.h
+  - bsps/arm/edb7312/include/uart.h
 - destination: ${BSP_INCLUDEDIR}/bsp
   source:
   - bsps/arm/edb7312/include/bsp/irq.h
diff --git a/spec/build/bsps/arm/grp.yml b/spec/build/bsps/arm/grp.yml
index 6979e02fb2..1086e0f7ab 100644
--- a/spec/build/bsps/arm/grp.yml
+++ b/spec/build/bsps/arm/grp.yml
@@ -17,7 +17,6 @@ install:
   - bsps/arm/include/core_cm7.h
   - bsps/arm/include/core_cm4.h
   - bsps/arm/include/mpu_armv7.h
-  - bsps/arm/include/uart.h
 - destination: ${BSP_INCLUDEDIR}/bsp
   source:
   - bsps/arm/include/bsp/arm-a9mpcore-clock.h
-- 
2.35.3

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

[PATCH 2/3] bsps/arm: Use shared object for ARM920 MMU support

[Sebastian Huber]

---
 spec/build/bsps/arm/csb336/bspcsb336.yml |  3 ++-
 spec/build/bsps/arm/csb337/grp.yml   |  2 ++
 spec/build/bsps/arm/csb337/obj.yml   |  1 -
 spec/build/bsps/arm/grp.yml  |  3 ---
 spec/build/bsps/arm/gumstix/bspgumstix.yml   |  3 ++-
 spec/build/bsps/arm/objarm920mmu.yml | 17 +
 spec/build/bsps/arm/smdk2410/bspsmdk2410.yml |  3 ++-
 7 files changed, 25 insertions(+), 7 deletions(-)
 create mode 100644 spec/build/bsps/arm/objarm920mmu.yml

diff --git a/spec/build/bsps/arm/csb336/bspcsb336.yml 
b/spec/build/bsps/arm/csb336/bspcsb336.yml
index edfd813227..7028925662 100644
--- a/spec/build/bsps/arm/csb336/bspcsb336.yml
+++ b/spec/build/bsps/arm/csb336/bspcsb336.yml
@@ -28,6 +28,8 @@ links:
   uid: start
 - role: build-dependency
   uid: ../grp
+- role: build-dependency
+  uid: ../objarm920mmu
 - role: build-dependency
   uid: ../../obj
 - role: build-dependency
@@ -46,7 +48,6 @@ source:
 - bsps/arm/csb336/start/bspstart.c
 - bsps/arm/csb336/start/memmap.c
 - bsps/arm/shared/cache/cache-cp15.c
-- bsps/arm/shared/cp15/arm920-mmu.c
 - bsps/shared/dev/cpucounter/cpucounterfrequency.c
 - bsps/shared/dev/cpucounter/cpucounterread.c
 - bsps/shared/dev/getentropy/getentropy-cpucounter.c
diff --git a/spec/build/bsps/arm/csb337/grp.yml 
b/spec/build/bsps/arm/csb337/grp.yml
index 47c3b68a26..7a8602aea4 100644
--- a/spec/build/bsps/arm/csb337/grp.yml
+++ b/spec/build/bsps/arm/csb337/grp.yml
@@ -40,6 +40,8 @@ links:
   uid: start
 - role: build-dependency
   uid: ../grp
+- role: build-dependency
+  uid: ../objarm920mmu
 - role: build-dependency
   uid: ../../linkcmds
 - role: build-dependency
diff --git a/spec/build/bsps/arm/csb337/obj.yml 
b/spec/build/bsps/arm/csb337/obj.yml
index 3858e4f00d..d817e08a58 100644
--- a/spec/build/bsps/arm/csb337/obj.yml
+++ b/spec/build/bsps/arm/csb337/obj.yml
@@ -42,7 +42,6 @@ source:
 - bsps/arm/csb337/start/memmap.c
 - bsps/arm/csb337/start/pmc.c
 - bsps/arm/shared/cache/cache-cp15.c
-- bsps/arm/shared/cp15/arm920-mmu.c
 - bsps/shared/dev/cpucounter/cpucounterfrequency.c
 - bsps/shared/dev/cpucounter/cpucounterread.c
 - bsps/shared/dev/getentropy/getentropy-cpucounter.c
diff --git a/spec/build/bsps/arm/grp.yml b/spec/build/bsps/arm/grp.yml
index ff4ff854ee..6979e02fb2 100644
--- a/spec/build/bsps/arm/grp.yml
+++ b/spec/build/bsps/arm/grp.yml
@@ -47,9 +47,6 @@ install:
   - bsps/include/dev/irq/arm-gic-regs.h
   - bsps/include/dev/irq/arm-gic-tm27.h
   - bsps/include/dev/irq/arm-gic.h
-- destination: ${BSP_INCLUDEDIR}/libcpu
-  source:
-  - bsps/arm/include/libcpu/mmu.h
 - destination: ${BSP_LIBDIR}
   source:
   - bsps/arm/shared/start/linkcmds.armv4
diff --git a/spec/build/bsps/arm/gumstix/bspgumstix.yml 
b/spec/build/bsps/arm/gumstix/bspgumstix.yml
index 7946a64ed4..2b40b50e0e 100644
--- a/spec/build/bsps/arm/gumstix/bspgumstix.yml
+++ b/spec/build/bsps/arm/gumstix/bspgumstix.yml
@@ -30,6 +30,8 @@ links:
   uid: optskyeye
 - role: build-dependency
   uid: start
+- role: build-dependency
+  uid: ../objarm920mmu
 - role: build-dependency
   uid: ../../obj
 - role: build-dependency
@@ -50,7 +52,6 @@ source:
 - bsps/arm/gumstix/start/bspreset.c
 - bsps/arm/gumstix/start/bspstart.c
 - bsps/arm/gumstix/start/memmap.c
-- bsps/arm/shared/cp15/arm920-mmu.c
 - bsps/shared/cache/nocache.c
 - bsps/shared/dev/cpucounter/cpucounterfrequency.c
 - bsps/shared/dev/cpucounter/cpucounterread.c
diff --git a/spec/build/bsps/arm/objarm920mmu.yml 
b/spec/build/bsps/arm/objarm920mmu.yml
new file mode 100644
index 00..f440a15d7d
--- /dev/null
+++ b/spec/build/bsps/arm/objarm920mmu.yml
@@ -0,0 +1,17 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+build-type: objects
+cflags: []
+copyrights:
+- Copyright (C) 2024 embedded brains GmbH & Co. KG
+cppflags: []
+cxxflags: []
+enabled-by: true
+includes: []
+install:
+- destination: ${BSP_INCLUDEDIR}/libcpu
+  source:
+  - bsps/arm/include/libcpu/mmu.h
+links: []
+source:
+- bsps/arm/shared/cp15/arm920-mmu.c
+type: build
diff --git a/spec/build/bsps/arm/smdk2410/bspsmdk2410.yml 
b/spec/build/bsps/arm/smdk2410/bspsmdk2410.yml
index ec7dc73af4..967bd8b87e 100644
--- a/spec/build/bsps/arm/smdk2410/bspsmdk2410.yml
+++ b/spec/build/bsps/arm/smdk2410/bspsmdk2410.yml
@@ -34,6 +34,8 @@ links:
   uid: optskyeye
 - role: build-dependency
   uid: start
+- role: build-dependency
+  uid: ../objarm920mmu
 - role: build-dependency
   uid: ../../obj
 - role: build-dependency
@@ -46,7 +48,6 @@ links:
   uid: ../../bspopts
 source:
 - bsps/arm/shared/cache/cache-cp15.c
-- bsps/arm/shared/cp15/arm920-mmu.c
 - bsps/arm/smdk2410/btimer/btimer.c
 - bsps/arm/smdk2410/clock/clockdrv.c
 - bsps/arm/smdk2410/clock/support.c
-- 
2.35.3

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

[PATCH 1/3] bsps/arm: Move BSP-specific header file installs

[Sebastian Huber]

---
 spec/build/bsps/arm/beagle/obj.yml | 5 +
 spec/build/bsps/arm/grp.yml| 3 ---
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/spec/build/bsps/arm/beagle/obj.yml 
b/spec/build/bsps/arm/beagle/obj.yml
index 0f2f354ab9..eaaf09f6ac 100644
--- a/spec/build/bsps/arm/beagle/obj.yml
+++ b/spec/build/bsps/arm/beagle/obj.yml
@@ -21,6 +21,11 @@ install:
   - bsps/arm/beagle/include/bsp/pwmss.h
   - bsps/arm/beagle/include/bsp/qep.h
   - bsps/arm/beagle/include/bsp/spi.h
+- destination: ${BSP_INCLUDEDIR}/libcpu
+  source:
+  - bsps/arm/include/libcpu/am335x.h
+  - bsps/arm/include/libcpu/omap3.h
+  - bsps/arm/include/libcpu/omap_timer.h
 - destination: ${BSP_LIBDIR}
   source:
   - bsps/arm/beagle/start/linkcmds
diff --git a/spec/build/bsps/arm/grp.yml b/spec/build/bsps/arm/grp.yml
index a48cd80d74..ff4ff854ee 100644
--- a/spec/build/bsps/arm/grp.yml
+++ b/spec/build/bsps/arm/grp.yml
@@ -49,10 +49,7 @@ install:
   - bsps/include/dev/irq/arm-gic.h
 - destination: ${BSP_INCLUDEDIR}/libcpu
   source:
-  - bsps/arm/include/libcpu/am335x.h
   - bsps/arm/include/libcpu/mmu.h
-  - bsps/arm/include/libcpu/omap3.h
-  - bsps/arm/include/libcpu/omap_timer.h
 - destination: ${BSP_LIBDIR}
   source:
   - bsps/arm/shared/start/linkcmds.armv4
-- 
2.35.3

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

[PATCH 0/3] Build optimizations for arm BSPs

[Sebastian Huber]

Sebastian Huber (3):
  bsps/arm: Move BSP-specific header file installs
  bsps/arm: Use shared object for ARM920 MMU support
  bsps/arm: Move BSP-specific header file

 bsps/arm/{ => edb7312}/include/uart.h|  0
 spec/build/bsps/arm/beagle/obj.yml   |  5 +
 spec/build/bsps/arm/csb336/bspcsb336.yml |  3 ++-
 spec/build/bsps/arm/csb337/grp.yml   |  2 ++
 spec/build/bsps/arm/csb337/obj.yml   |  1 -
 spec/build/bsps/arm/edb7312/bspedb7312.yml   |  1 +
 spec/build/bsps/arm/grp.yml  |  7 ---
 spec/build/bsps/arm/gumstix/bspgumstix.yml   |  3 ++-
 spec/build/bsps/arm/objarm920mmu.yml | 17 +
 spec/build/bsps/arm/smdk2410/bspsmdk2410.yml |  3 ++-
 10 files changed, 31 insertions(+), 11 deletions(-)
 rename bsps/arm/{ => edb7312}/include/uart.h (100%)
 create mode 100644 spec/build/bsps/arm/objarm920mmu.yml

-- 
2.35.3

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

[PATCH] bsps: Use interrupt entry in clock driver

[Sebastian Huber]

This avoids a dependency on memory allocations.
---
 bsps/shared/dev/clock/arm-generic-timer.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/bsps/shared/dev/clock/arm-generic-timer.c 
b/bsps/shared/dev/clock/arm-generic-timer.c
index ba159f6833..44cf1ebe6c 100644
--- a/bsps/shared/dev/clock/arm-generic-timer.c
+++ b/bsps/shared/dev/clock/arm-generic-timer.c
@@ -68,16 +68,22 @@ static void arm_gt_clock_at_tick(arm_gt_clock_context *ctx)
 #endif /* ARM_GENERIC_TIMER_UNMASK_AT_TICK */
 }
 
+static rtems_interrupt_entry arm_gt_interrupt_entry;
+
 static void arm_gt_clock_handler_install(rtems_interrupt_handler handler)
 {
   rtems_status_code sc;
 
-  sc = rtems_interrupt_handler_install(
+  rtems_interrupt_entry_initialize(
+_gt_interrupt_entry,
+handler,
+_gt_clock_instance,
+"Clock"
+  );
+  sc = rtems_interrupt_entry_install(
 arm_gt_clock_instance.irq,
-"Clock",
 RTEMS_INTERRUPT_UNIQUE,
-handler,
-_gt_clock_instance
+_gt_interrupt_entry
   );
   if (sc != RTEMS_SUCCESSFUL) {
 bsp_fatal(BSP_ARM_FATAL_GENERIC_TIMER_CLOCK_IRQ_INSTALL);
-- 
2.35.3

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

Re: RTEMS 6 branching

[Joel Sherrill]

On Tue, Apr 23, 2024, 12:56 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> - Am 21. Apr 2024 um 3:00 schrieb Chris Johns chr...@rtems.org:
>
> > Hi,
> >
> > There has been some discussion about when we will branch and it is
> timely we
> > discuss this. This is my input. :)
> >
> > While I create the releases I am not solely responsible for milestone
> dates or
> > thresholds for a release.
> >
> > Please test the RC snaphots on our ftp server. Saying you have is as
> important
> > as reporting issues.
> >
> > 1. Are all the things need for the release resolved? Tickets reviewed?
>
> It would be nice to have the interrupt get/set priority API in RTEMS 6.
> The Cortex-M floating point issue is not yet fixed in the RTEMS master.
>

There should be time to get it in. The Gitlab transition needs to be
complete before the branch is cut.

>
> >
> > 2. The tickets are now in GitLab and locked down in Trac so how does
> that work
> > if we make a release now? I do not think it does.
> >
> > 3. GitLab is going to happen soon so do we take this moment in time and
> make 6
> > with GitLab and learn what we need to do easing dot releases that always
> follow?
> > If we do not we may end up with 6.1 and then 6.2 that has differences.
>
> We should definitely wait with the release after the Gitlab migration is
> done and some basic CI is running.
>

I don't think holding a release for CI is needed. We have the same basic
quality and testing we have now.

Requiring more work and improvements just moves the release bar.

That said, we do need to get some CI processes in place. Hopefully between
6.1 and 6.2, we will have at least one or two BSPs required to build.

>
> >
> > 4. GitLab breaks the release scripts for the release notes (ChangeLog).
> Amar and
> > I have discussed a few options but we are yet to test and settle on
> anything. As
> > is the case with these things easy is often is a series of small things
> that
> > take time to get right.
> >
> > 5. Have the docs been reviewed for RTEMS 5 vs RTEMS 6 changes? Are they
> updated
> > for a separated legacy network stack, net services and waf building?
>

Ryan and Ray worked on the autoconf to waf documentation changes a couple
of years ago.

I have no idea what impact the separated Network stacks have on the
documentation.

> 6. I have a few small patches to push and then an update to the RSB to
> pick
> > those changes up before I can create RC4.
>
> I recently checked in a fix for powerpc and the AArch64 multilib changes
> for Cortex-A53 in GCC 13. To pick this up, the GCC commit needs to be
> updated. Maybe we should even wait for the GCC 13.3 release.
>

I asked about a gcc 13.3 release and we should not wait. They intend to do
a 14 release before returning to 13.3. We should plan to do 6.1 with a GCC
13 branch hash and probably plan to swap that out with a 13.3 tarball when
it's released.

We are good at imposing more requirements. :)




> >
> >
> > Thanks
> > Chris
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
> --
> 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: RTEMS 6 branching

[Sebastian Huber]

- Am 21. Apr 2024 um 3:00 schrieb Chris Johns chr...@rtems.org:

> Hi,
> 
> There has been some discussion about when we will branch and it is timely we
> discuss this. This is my input. :)
> 
> While I create the releases I am not solely responsible for milestone dates or
> thresholds for a release.
> 
> Please test the RC snaphots on our ftp server. Saying you have is as important
> as reporting issues.
> 
> 1. Are all the things need for the release resolved? Tickets reviewed?

It would be nice to have the interrupt get/set priority API in RTEMS 6. The 
Cortex-M floating point issue is not yet fixed in the RTEMS master.

> 
> 2. The tickets are now in GitLab and locked down in Trac so how does that work
> if we make a release now? I do not think it does.
> 
> 3. GitLab is going to happen soon so do we take this moment in time and make 6
> with GitLab and learn what we need to do easing dot releases that always 
> follow?
> If we do not we may end up with 6.1 and then 6.2 that has differences.

We should definitely wait with the release after the Gitlab migration is done 
and some basic CI is running.

> 
> 4. GitLab breaks the release scripts for the release notes (ChangeLog). Amar 
> and
> I have discussed a few options but we are yet to test and settle on anything. 
> As
> is the case with these things easy is often is a series of small things that
> take time to get right.
> 
> 5. Have the docs been reviewed for RTEMS 5 vs RTEMS 6 changes? Are they 
> updated
> for a separated legacy network stack, net services and waf building?
> 
> 6. I have a few small patches to push and then an update to the RSB to pick
> those changes up before I can create RC4.

I recently checked in a fix for powerpc and the AArch64 multilib changes for 
Cortex-A53 in GCC 13. To pick this up, the GCC commit needs to be updated. 
Maybe we should even wait for the GCC 13.3 release.

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

-- 
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: RSB format changes to meet coding standard

[Joel Sherrill]

On Sat, Apr 20, 2024, 7:19 PM Chris Johns  wrote:

> On 19/4/2024 7:15 pm, andrew.butterfi...@scss.tcd.ie wrote:
> > Will you also do this with the formal code in rtems-central/formal ?
>
> Sorry, I do not use it so would prefer not to update it just yet. I think
> it
> best left to the leaders of that repo.
>
> > I do remember using yapf at some point – I have no problem in your doing
> this here.
>
> Great.
>
> > I expect to be proposing an update to the formal stuff
> >  (models,code,documentation) over the Summer period as well.
>
> Great and looking forward to see the results. We will be on GitLab soon
> and that
> will help us all with merge requests as well as coordinating these
> activities,
> for example GitLab has Epics.
>

Checking that Python source is properly formatted sounds like a nice low
hanging CI job once we have switched over and things have settled.

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

RTEMS 6 branching

[Chris Johns]

Hi,

There has been some discussion about when we will branch and it is timely we
discuss this. This is my input. :)

While I create the releases I am not solely responsible for milestone dates or
thresholds for a release.

Please test the RC snaphots on our ftp server. Saying you have is as important
as reporting issues.

1. Are all the things need for the release resolved? Tickets reviewed?

2. The tickets are now in GitLab and locked down in Trac so how does that work
if we make a release now? I do not think it does.

3. GitLab is going to happen soon so do we take this moment in time and make 6
with GitLab and learn what we need to do easing dot releases that always follow?
If we do not we may end up with 6.1 and then 6.2 that has differences.

4. GitLab breaks the release scripts for the release notes (ChangeLog). Amar and
I have discussed a few options but we are yet to test and settle on anything. As
is the case with these things easy is often is a series of small things that
take time to get right.

5. Have the docs been reviewed for RTEMS 5 vs RTEMS 6 changes? Are they updated
for a separated legacy network stack, net services and waf building?

6. I have a few small patches to push and then an update to the RSB to pick
those changes up before I can create RC4.


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

Re: [PATCH] bsps/powerpc: Introduction of interrupt locks

[Chris Johns]

On 19/4/2024 6:12 pm, Christian MAUDERER wrote:
> it is tested on an MVME2500 which uses the powerpc/qoriq_e500 in an SMP
> configuration.

Great and thanks. I should have access next week to MVME2700 hardware and can
test it there. I doubt there will be an issue looking at the change but this
group of BSPs has had issues in the past, eg interrupts on some boards did not
work for over 10 years after a change, ie RTEMS 4.10 until 5.

I am OK to push the change and if I find anything I will raise it.

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

Re: RSB format changes to meet coding standard

[Chris Johns]

On 19/4/2024 7:15 pm, andrew.butterfi...@scss.tcd.ie wrote:
> Will you also do this with the formal code in rtems-central/formal ?

Sorry, I do not use it so would prefer not to update it just yet. I think it
best left to the leaders of that repo.

> I do remember using yapf at some point – I have no problem in your doing this 
> here.

Great.

> I expect to be proposing an update to the formal stuff
>  (models,code,documentation) over the Summer period as well.

Great and looking forward to see the results. We will be on GitLab soon and that
will help us all with merge requests as well as coordinating these activities,
for example GitLab has Epics.

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

Re: [rtems-tools PATCH 1/2] rtemstoolkit: Fix decoding unicode strings in output

[Joel Sherrill]

Please apply both. I think this was the only bad issue with rc2 on CentOS 7
or 8.

On Thu, Apr 18, 2024 at 10:09 PM  wrote:

> From: Chris Johns 
>
> ---
>  rtemstoolkit/execute.py | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/rtemstoolkit/execute.py b/rtemstoolkit/execute.py
> index 31d3a8a..c7d8134 100755
> --- a/rtemstoolkit/execute.py
> +++ b/rtemstoolkit/execute.py
> @@ -37,6 +37,7 @@
>  from __future__ import print_function
>
>  import functools
> +import codecs
>  import io
>  import os
>  import re
> @@ -203,6 +204,10 @@ class execute(object):
>  stacktraces.trace()
>  if trace_threads:
>  print('execute:_readthread: start')
> +if sys.stdout.encoding is not None:
> +decoder =
> codecs.getincrementaldecoder(sys.stdout.encoding)()
> +else:
> +decoder = None
>  count = 0
>  line = ''
>  try:
> @@ -222,8 +227,8 @@ class execute(object):
>  _output_line(line + '\n', exe, prefix, out,
> count)
>  break
>  # str and bytes are the same type in Python2
> -if type(data) is not str and type(data) is bytes:
> -data = data.decode(sys.stdout.encoding)
> +if decoder is not None and type(data) is not str and
> type(data) is bytes:
> +data = decoder.decode(data)
>  last_ch = data[-1]
>  sd = (line + data).split('\n')
>  if last_ch != '\n':
> @@ -382,6 +387,9 @@ class execute(object):
>  if self.verbose:
>  log.output(what + ': ' + cs)
>  log.trace('exe: %s' % (cs))
> +if shell and self.shell_exe:
> +command = arg_list(command)
> +command[:0] = self.shell_exe
>  if not stdin and self.input:
>  stdin = subprocess.PIPE
>  if not stdout:
> --
> 2.39.3 (Apple Git-146)
>
> ___
> 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: [RFC] rtems: Add options to kernel output char handler

[Peter Dufault]

> On Apr 18, 2024, at 6:32 PM, Chris Johns  wrote:
> 
> On 18/4/2024 4:16 pm, Sebastian Huber wrote:
>> On 18.04.24 04:02, Chris Johns wrote:
>>> On 17/4/2024 11:06 pm, Sebastian Huber wrote:
 Make the kernel I/O output character device processing configurable
 through an option set parameter.  Add RTEMS_NO_OUTPUT and RTEMS_FLUSH
 options.  The goal of this API change is to enable flushing the kernel
 output device in the system termination process before a reset is
 issued.  A use case for using RTEMS_NO_WAIT is the polled processing of
 an input and output stream from and to the I/O device.
>>> 
>>> Thanks for providing this overview.
>>> 
>>> I am still confused about the differences in terms of why you would need the
>>> RTEMS_NO_WAIT. Do you have a specific application where this is required? It
>>> might help me understand the need for the change? Examples are need to 
>>> reset in
>>> a specific period, a test mode you are running in a system, etc?
>> 
>> The RTEMS_NO_WAIT can be used to process an input stream using getchark() and
>> then send responses using a non-blocking output char variant. This helps to 
>> have
>> enough processing time and allows an overlapping send/receive.
>> 
>>> 
>>> Is this change for RTEMS 7?
>> 
>> Yes, this would be good.
> 
> Great, I think it is too late for 6.
> 
>>> In the context of the change:
>>> 
>>> 1. RTEMS_FLUSH etc are too generic.
>> 
>> I added them to , so they could be reused in other
>> directives. A bit less generic names could be:
>> 
>> * RTEMS_IO_FLUSH
>> 
>> * RTEMS_IO_DRAIN
>> 
>> * RTEMS_IO_NO_OUTPUT
>> 
> 
> Sure, that is better.
> 
>> This would be in the IO namespace similar to RTEMS_EVENT_ANY and 
>> RTEMS_EVENT_ALL.
> 
> Yeap
> 
>>> 2. The language used needs some work, maybe fewer "while"s. For example:
>>> 
>>>   While the #RTEMS_NO_WAIT option is set in the option_set parameter, while
>>>   the #RTEMS_NO_OUTPUT option is cleared in the option_set parameter, while
>>>   the device can immediately accept a character for output, the character in
>>>   out shall be hand over to the device for output.
>>> 
>>> This is difficult to read and when it is probability easier to read the 
>>> code it
>>> is of questionable value. I appreciate it is not always easy to write but I 
>>> feel
>>> clarity would be a good to have here.
>> 
>> This is the documentation of a function pointer type, so there is no direct
>> code. With three flags, you have to specify for eight variants what should
>> happen. The wording is in EARS. It should be easy to translate this into code
>> for a particular device.
>> 
>> https://docs.rtems.org/branches/master/eng/req/req-for-req.html#syntax
> 
> I think EARS is too specialised for RTEMS and here in this small isolated 
> case.
> If it was taught in first year undergrad courses and widely adopted it would 
> be
> a different. It is not used in RTEMS and starting here and now only makes this
> piece of code harder to maintain.
> 
>>> Another example:
>>> 
>>>   While no character is available in the device, a polled
>>>   character input functions shall return minus one.
>>> 
>>> It could be written as:
>>> 
>>>   A polled character input function shall return a character if the device
>>>   has successfully received one else the function returns minus one.
>> 
>> I would prefer the EARS variant. This function type should define 
>> requirements
>> for the associated implementations.
> 
> I do not agree and until EARS is agreed to at the project level this will not
> change.

I like EARS.  I've used it for my own use, and refer to it when I create a 
specification that will be reviewed by multiple people outside of HDA.

With no other definition of a format, and no one working on one, I don't think 
there is a drawback to use EARS unless and until something else is adopted.  
I'd make it a recommended (not required) format so more people try it out.

Or is "recommended not required" too weak to even bother with?

> 
>>> I think receive and transmit is better than for example "be hand over to the
>>> device for output", maybe "shall be transmitted by the device".
>> 
>> The name of this function type is BSP_output_char_function_type and not
>> BSP_transmit_char_function_type, so I used "output" here and not "transmit".
> 
> The function outputs data, the device transmits. If the requirement is to 
> output
> the data it does not cover the transmission and the transmission is the
> important part.
> 
>> Also, the character may not get immediately transmitted if FIFOs are involved
>> (thus the need for the flush). Maybe my understanding of transmitted is 
>> wrong,
>> but for me transmitting has something to do with signals on a medium.
> 
> I have never heard of a device that has data loaded into a FIFO to transmit 
> has
> a mode that transmits sooner or faster? I would have assumed outputting the 
> data
> to the FIFO would sent it. There is a distinct difference between output and
> transmit 

Re: [PATCH] Fix the CPU count calculation error.

[zhengxiaojun]

在 2024/4/19 16:50, Sebastian Huber 写道:

On 19.04.24 09:16, zhengxiaojun wrote:
I tested on arm64, the cpu_count do not increase when 
(redist->icrtyper & GIC_REDIST_ICRTYPER_LAST != 0)，but it is the last 
core.


The current code assumes that you have exactly one interrupt export 
port. With which SoC are you working currently? One option could be to 

Rockchip RK3568,which has 4 cores arranged in 4 clusters.


make the number of interrupt export ports configurable.



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

Re: RSB format changes to meet coding standard

[andrew.butterfi...@scss.tcd.ie]

Hi Chris,
Will you also do this with the formal code in rtems-central/formal ?

I do remember using yapf at some point – I have no problem in your doing this 
here.

I expect to be proposing an update to the formal stuff  
(models,code,documentation) over the Summer period as well.

Regards, Andrew



From: devel  on behalf of Joel Sherrill 

Date: Friday, 19 April 2024 at 03:09
To: Chris Johns 
Cc: Development 
Subject: Re: RSB format changes to meet coding standard

On Thu, Apr 18, 2024, 7:31 PM Chris Johns 
mailto:chr...@rtems.org>> wrote:
Hi,

I would like to run the python code we own through yapf and it's default to
standardise the formatting and to being it inline with the coding standards. It
would be good to do this before we branch for RTEMS 6.

I can crate a patch and post if required but it will be noise and doubt anyone
will review it, I would not. I will run builds etc to make sure the conversion
is clean.

Do I have permission to make the format change as a single commit and push it?

I'm certainly ok with this.

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

Re: [PATCH] Fix the CPU count calculation error.

[Sebastian Huber]

On 19.04.24 09:16, zhengxiaojun wrote:
I tested on arm64, the cpu_count do not increase when (redist->icrtyper 
& GIC_REDIST_ICRTYPER_LAST != 0)，but it is the last core.


The current code assumes that you have exactly one interrupt export 
port. With which SoC are you working currently? One option could be to 
make the number of interrupt export ports configurable.


--
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: [PATCH] bsps/powerpc: Introduction of interrupt locks

[Christian MAUDERER]

Hello Chris,

it is tested on an MVME2500 which uses the powerpc/qoriq_e500 in an SMP 
configuration.


Best regards

Christian

On 2024-04-18 04:04, Chris Johns wrote:

Hi Vincenzo,

Welcome to RTEMS.

What hardware in the shared VME PowerPC family of BSPS has this change been
tested on?

Thanks
Chris

On 17/4/2024 5:34 pm, Vincenzo Calabretta wrote:

Interrupt locks are introduced in shared vme device drivers to enable
compilation in an SMP configuration of the qoriq BSP.
---
  bsps/powerpc/shared/vme/vmeTsi148.c   | 44 ++-
  bsps/powerpc/shared/vme/vmeUniverse.c | 40 +---
  2 files changed, 45 insertions(+), 39 deletions(-)

diff --git a/bsps/powerpc/shared/vme/vmeTsi148.c 
b/bsps/powerpc/shared/vme/vmeTsi148.c
index aaabb1b28d..a6f0ac87ab 100644
--- a/bsps/powerpc/shared/vme/vmeTsi148.c
+++ b/bsps/powerpc/shared/vme/vmeTsi148.c
@@ -545,16 +545,17 @@ vmeTsi148Reset(void)
vmeTsi148ResetXX(THEBASE);
  }
  
+RTEMS_INTERRUPT_LOCK_DEFINE( static, vmeTsi148_lock, "vmeTsi148_lock" )

  void
  vmeTsi148ResetBusXX(BERegister *base)
  {
-unsigned long flags;
  uint32_t  v;
+rtems_interrupt_lock_context lock_context;
  
-	rtems_interrupt_disable(flags);

+   rtems_interrupt_lock_acquire( _lock, _context );
v = TSI_RD(base, TSI_VCTRL_REG);
TSI_WR(base, TSI_VCTRL_REG, v | TSI_VCTRL_SRESET);
-   rtems_interrupt_enable(flags);
+   rtems_interrupt_lock_release( _lock, _context );
  }
  
  void

@@ -1410,7 +1411,8 @@ int
  vmeTsi148IntRoute(unsigned int level, unsigned int pin)
  {
  int   i;
-unsigned long  mask, shift, mapreg, flags, wire;
+unsigned long  mask, shift, mapreg, wire;
+rtems_interrupt_lock_context lock_context;
  
  	if ( pin >= TSI_NUM_WIRES || ! tsi_wire[pin] || !vmeTsi148IrqMgrInstalled )

return -1;
@@ -1442,8 +1444,7 @@ unsigned long mask, shift, mapreg, flags, wire;
/* wires are offset by 1 so we can initialize the wire table to all 
zeros */
wire = (tsi_wire[pin]-1) << shift;
  
-rtems_interrupt_disable(flags);

-
+   rtems_interrupt_lock_acquire( _lock, _context );
for ( i = 0; i  
-rtems_interrupt_enable(flags);

+   rtems_interrupt_lock_release( _lock, _context );
return 0;
  }
  
@@ -1461,9 +1462,9 @@ VmeTsi148ISR

  vmeTsi148ISRGet(unsigned long vector, void **parg)
  {
  VmeTsi148ISRrval = 0;
-unsigned longflags;
  volatile IRQEntry *p;
  int   v = uni2tsivec(vector);
+rtems_interrupt_lock_context lock_context;
  
  
  	if ( v < 0 )

@@ -1471,13 +1472,13 @@ int   v = uni2tsivec(vector);
  
  	p = irqHdlTbl + v;
  
-	rtems_interrupt_disable(flags);

+   rtems_interrupt_lock_acquire( _lock, _context );
if ( *p ) {
if ( parg )
*parg = (*p)->usrData;
rval = (*p)->isr;
}
-   rtems_interrupt_enable(flags);
+   rtems_interrupt_lock_release( _lock, _context );
  
  	return rval;

  }
@@ -1794,8 +1795,8 @@ vmeTsi148InstallISR(unsigned long vector, VmeTsi148ISR 
hdl, void *arg)
  {
  IRQEntry  ip;
  int v;
-unsigned longflags;
  volatile IRQEntry *p;
+rtems_interrupt_lock_context lock_context;
  
  		if ( !vmeTsi148IrqMgrInstalled || (v = uni2tsivec(vector)) < 0 )

return -1;
@@ -1808,14 +1809,14 @@ volatile IRQEntry *p;
ip->isr=hdl;
ip->usrData=arg;
  
-		rtems_interrupt_disable(flags);

+   rtems_interrupt_lock_acquire( _lock, _context );
if (*p) {
-   rtems_interrupt_enable(flags);
+   rtems_interrupt_lock_release( _lock, 
_context );
free(ip);
return -1;
}
*p = ip;
-   rtems_interrupt_enable(flags);
+   rtems_interrupt_lock_release( _lock, _context );
return 0;
  }
  
@@ -1824,22 +1825,22 @@ vmeTsi148RemoveISR(unsigned long vector, VmeTsi148ISR hdl, void *arg)

  {
  int   v;
  IRQEntry  ip;
-unsigned long flags;
  volatile IRQEntry *p;
+rtems_interrupt_lock_context lock_context;
  
  		if ( !vmeTsi148IrqMgrInstalled || (v = uni2tsivec(vector)) < 0 )

return -1;
  
  		p = irqHdlTbl + v;
  
-		rtems_interrupt_disable(flags);

+   rtems_interrupt_lock_acquire( _lock, _context );
ip = *p;
if ( !ip || ip->isr!=hdl || ip->usrData!=arg ) {
-   rtems_interrupt_enable(flags);
+   rtems_interrupt_lock_release( _lock, 
_context );
return -1;
}
*p = 0;
-   rtems_interrupt_enable(flags);
+   rtems_interrupt_lock_release( _lock, _context );
  
  		free(ip);

Re: [PATCH] Fix the CPU count calculation error.

[zhengxiaojun]

I tested on arm64, the cpu_count do not increase when (redist->icrtyper 
& GIC_REDIST_ICRTYPER_LAST != 0)，but it is the last core.


在 2024/4/19 15:00, Sebastian Huber 写道:

Hello,

on which platform does this fix a error?



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

Re: [PATCH] Fix the CPU count calculation error.

[Sebastian Huber]

Hello,

on which platform does this fix a error?

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

[PATCH] Fix the CPU count calculation error.

[zhengxiaojun]

Fix the CPU count calculation error.

Signed-off-by: zhengxiaojun 
---
 bsps/shared/dev/irq/arm-gicv3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bsps/shared/dev/irq/arm-gicv3.c 
b/bsps/shared/dev/irq/arm-gicv3.c

index 958b1061bd..6422a191f1 100644
--- a/bsps/shared/dev/irq/arm-gicv3.c
+++ b/bsps/shared/dev/irq/arm-gicv3.c
@@ -309,7 +309,7 @@ uint32_t arm_gic_irq_processor_count(void)
 int i;

 /* Assume that an interrupt export port exists */
-cpu_count = 0;
+cpu_count = 1;

 for (i = 0; i < CPU_MAXIMUM_PROCESSORS; ++i) {
   volatile gic_redist *redist = gicv3_get_redist(i);
--
2.42.0

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

[rtems-tools PATCH 2/2] test, rtemstoolkit: Fix regx escape errors on python 3.12

[chrisj]

From: Chris Johns 

---
 tester/rt/pygdb/spark.py | 2 +-
 tester/rt/test.py| 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/tester/rt/pygdb/spark.py b/tester/rt/pygdb/spark.py
index 0eac365..b669998 100644
--- a/tester/rt/pygdb/spark.py
+++ b/tester/rt/pygdb/spark.py
@@ -119,7 +119,7 @@ class GenericParser:
self.augment(start)
self.ruleschanged = 1
 
-   _NULLABLE = '\e_'
+   _NULLABLE = r'\e_'
_START = 'START'
_BOF = '|-'
 
diff --git a/tester/rt/test.py b/tester/rt/test.py
index db5939b..9108206 100644
--- a/tester/rt/test.py
+++ b/tester/rt/test.py
@@ -71,7 +71,7 @@ class log_capture(object):
 def get(self):
 s = []
 status = []
-status_regx = re.compile('^\[\s*\d+/\s*\d+\] p:.+')
+status_regx = re.compile(r'^\[\s*\d+/\s*\d+\] p:.+')
 for l in self.log:
 if status_regx.match(l):
 status += [l]
@@ -175,7 +175,7 @@ def find_executables(paths, glob):
 for f in files:
 if fnmatch.fnmatch(f.lower(), glob):
 executables += [path.join(root, f)]
-norun = re.compile('.*\.norun.*')
+norun = re.compile(r'.*\.norun.*')
 executables = [e for e in executables if not norun.match(e)]
 return sorted(executables)
 
-- 
2.39.3 (Apple Git-146)

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

[rtems-tools PATCH 1/2] rtemstoolkit: Fix decoding unicode strings in output

[chrisj]

From: Chris Johns 

---
 rtemstoolkit/execute.py | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/rtemstoolkit/execute.py b/rtemstoolkit/execute.py
index 31d3a8a..c7d8134 100755
--- a/rtemstoolkit/execute.py
+++ b/rtemstoolkit/execute.py
@@ -37,6 +37,7 @@
 from __future__ import print_function
 
 import functools
+import codecs
 import io
 import os
 import re
@@ -203,6 +204,10 @@ class execute(object):
 stacktraces.trace()
 if trace_threads:
 print('execute:_readthread: start')
+if sys.stdout.encoding is not None:
+decoder = codecs.getincrementaldecoder(sys.stdout.encoding)()
+else:
+decoder = None
 count = 0
 line = ''
 try:
@@ -222,8 +227,8 @@ class execute(object):
 _output_line(line + '\n', exe, prefix, out, count)
 break
 # str and bytes are the same type in Python2
-if type(data) is not str and type(data) is bytes:
-data = data.decode(sys.stdout.encoding)
+if decoder is not None and type(data) is not str and 
type(data) is bytes:
+data = decoder.decode(data)
 last_ch = data[-1]
 sd = (line + data).split('\n')
 if last_ch != '\n':
@@ -382,6 +387,9 @@ class execute(object):
 if self.verbose:
 log.output(what + ': ' + cs)
 log.trace('exe: %s' % (cs))
+if shell and self.shell_exe:
+command = arg_list(command)
+command[:0] = self.shell_exe
 if not stdin and self.input:
 stdin = subprocess.PIPE
 if not stdout:
-- 
2.39.3 (Apple Git-146)

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

Re: RSB format changes to meet coding standard

[Joel Sherrill]

On Thu, Apr 18, 2024, 7:31 PM Chris Johns  wrote:

> Hi,
>
> I would like to run the python code we own through yapf and it's default to
> standardise the formatting and to being it inline with the coding
> standards. It
> would be good to do this before we branch for RTEMS 6.
>
> I can crate a patch and post if required but it will be noise and doubt
> anyone
> will review it, I would not. I will run builds etc to make sure the
> conversion
> is clean.
>
> Do I have permission to make the format change as a single commit and push
> it?
>

I'm certainly ok with this.

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

RSB format changes to meet coding standard

[Chris Johns]

Hi,

I would like to run the python code we own through yapf and it's default to
standardise the formatting and to being it inline with the coding standards. It
would be good to do this before we branch for RTEMS 6.

I can crate a patch and post if required but it will be noise and doubt anyone
will review it, I would not. I will run builds etc to make sure the conversion
is clean.

Do I have permission to make the format change as a single commit and push it?

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

Re: [RFC] rtems: Add options to kernel output char handler

[Chris Johns]

On 18/4/2024 4:16 pm, Sebastian Huber wrote:
> On 18.04.24 04:02, Chris Johns wrote:
>> On 17/4/2024 11:06 pm, Sebastian Huber wrote:
>>> Make the kernel I/O output character device processing configurable
>>> through an option set parameter.  Add RTEMS_NO_OUTPUT and RTEMS_FLUSH
>>> options.  The goal of this API change is to enable flushing the kernel
>>> output device in the system termination process before a reset is
>>> issued.  A use case for using RTEMS_NO_WAIT is the polled processing of
>>> an input and output stream from and to the I/O device.
>>
>> Thanks for providing this overview.
>>
>> I am still confused about the differences in terms of why you would need the
>> RTEMS_NO_WAIT. Do you have a specific application where this is required? It
>> might help me understand the need for the change? Examples are need to reset 
>> in
>> a specific period, a test mode you are running in a system, etc?
> 
> The RTEMS_NO_WAIT can be used to process an input stream using getchark() and
> then send responses using a non-blocking output char variant. This helps to 
> have
> enough processing time and allows an overlapping send/receive.
> 
>>
>> Is this change for RTEMS 7?
> 
> Yes, this would be good.

Great, I think it is too late for 6.

>> In the context of the change:
>>
>> 1. RTEMS_FLUSH etc are too generic.
> 
> I added them to , so they could be reused in other
> directives. A bit less generic names could be:
> 
> * RTEMS_IO_FLUSH
> 
> * RTEMS_IO_DRAIN
> 
> * RTEMS_IO_NO_OUTPUT
> 

Sure, that is better.

> This would be in the IO namespace similar to RTEMS_EVENT_ANY and 
> RTEMS_EVENT_ALL.

Yeap

>> 2. The language used needs some work, maybe fewer "while"s. For example:
>>
>>   While the #RTEMS_NO_WAIT option is set in the option_set parameter, while
>>   the #RTEMS_NO_OUTPUT option is cleared in the option_set parameter, while
>>   the device can immediately accept a character for output, the character in
>>   out shall be hand over to the device for output.
>>
>> This is difficult to read and when it is probability easier to read the code 
>> it
>> is of questionable value. I appreciate it is not always easy to write but I 
>> feel
>> clarity would be a good to have here.
> 
> This is the documentation of a function pointer type, so there is no direct
> code. With three flags, you have to specify for eight variants what should
> happen. The wording is in EARS. It should be easy to translate this into code
> for a particular device.
> 
> https://docs.rtems.org/branches/master/eng/req/req-for-req.html#syntax

I think EARS is too specialised for RTEMS and here in this small isolated case.
If it was taught in first year undergrad courses and widely adopted it would be
a different. It is not used in RTEMS and starting here and now only makes this
piece of code harder to maintain.

>> Another example:
>>
>>   While no character is available in the device, a polled
>>   character input functions shall return minus one.
>>
>> It could be written as:
>>
>>   A polled character input function shall return a character if the device
>>   has successfully received one else the function returns minus one.
> 
> I would prefer the EARS variant. This function type should define requirements
> for the associated implementations.

I do not agree and until EARS is agreed to at the project level this will not
change.

>> I think receive and transmit is better than for example "be hand over to the
>> device for output", maybe "shall be transmitted by the device".
> 
> The name of this function type is BSP_output_char_function_type and not
> BSP_transmit_char_function_type, so I used "output" here and not "transmit".

The function outputs data, the device transmits. If the requirement is to output
the data it does not cover the transmission and the transmission is the
important part.

> Also, the character may not get immediately transmitted if FIFOs are involved
> (thus the need for the flush). Maybe my understanding of transmitted is wrong,
> but for me transmitting has something to do with signals on a medium.

I have never heard of a device that has data loaded into a FIFO to transmit has
a mode that transmits sooner or faster? I would have assumed outputting the data
to the FIFO would sent it. There is a distinct difference between output and
transmit and I would like to see the transmit aspect be specified and met.

>> 3. Flush needs to be worded in terms of successfully transmitted by the 
>> device
>> to avoid the case of data being written to the device is held in FIFOs 
>> awaiting
>> transmission and reset is asserted. Maybe FLUSH is the wrong term because it 
>> is
>> so overloaded in what it means? An alternative could be
>> RTEMS_BSP_IO_TRANSMISSION_COMPLETE? And following on you could have
>> RTEMS_BSP_IO_NO_TRANSMISSION? The key point is "transmission" relates to the
>> external data pin of the interface.
> 
> The no-output option is used to just flush the device without transmitting a 
> new
> 

Re: rtems-kernel-init.c tries to re-make existing "/etc"

[Peter Dufault]

> On Apr 18, 2024, at 10:55 AM, Joel Sherrill  wrote:
> 
> 
> 
> On Thu, Apr 18, 2024 at 9:50 AM Peter Dufault  wrote:
> 
> 
> > On Apr 18, 2024, at 10:34 AM, Kinsey Moore  wrote:
> > 
> > A patch for EEXIST here should be fine. It would be nice if the caller were 
> > more resilient.
> > 
> 
> I also changed "default-network-init.h" to assert rtems_bsd_initialize() 
> worked.
> 
>   sc = rtems_bsd_initialize();
>   assert(sc == RTEMS_SUCCESSFUL);
> 
> At least you get a panic message.  I'll submit a patch.
> 
> Why does /etc already exist? Is it really an error if it already exists?
> 
> If the startup code untar'ed some initial file system contents before calling 
> this, then /etc would almost certainly exist.
> 
> Unless I am missing something EEXIST should be acceptable. Other errors are 
> most likely really fatal.
> 
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/mkdir.html
> 
> --joel 
> 
> Peter
> -
> Peter Dufault
> HD Associates, Inc.  Software and System Engineering
> 

Oh, and maybe you misunderstood: The "assert()" is in *addition* to allowing 
EEXIST for the "mkdir()" call.  It avoids a weird crash in case 
"rtems_bsd_initialize()" fails for some other reason.

Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering



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

Re: rtems-kernel-init.c tries to re-make existing "/etc"

[Peter Dufault]

> On Apr 18, 2024, at 10:55 AM, Joel Sherrill  wrote:
> 
> 
> 
> On Thu, Apr 18, 2024 at 9:50 AM Peter Dufault  wrote:
> 
> 
> > On Apr 18, 2024, at 10:34 AM, Kinsey Moore  wrote:
> > 
> > A patch for EEXIST here should be fine. It would be nice if the caller were 
> > more resilient.
> > 
> 
> I also changed "default-network-init.h" to assert rtems_bsd_initialize() 
> worked.
> 
>   sc = rtems_bsd_initialize();
>   assert(sc == RTEMS_SUCCESSFUL);
> 
> At least you get a panic message.  I'll submit a patch.
> 
> Why does /etc already exist? Is it really an error if it already exists?
> 
> If the startup code untar'ed some initial file system contents before calling 
> this, then /etc would almost certainly exist.
> 
> Unless I am missing something EEXIST should be acceptable. Other errors are 
> most likely really fatal.
> 
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/mkdir.html
> 
> --joel 
> 

The function "_libcsupport_pwdgrp_init()" over in RTEMS also creates "/etc" 
through a "pthread_once()".  A call to "getpwnam()", "getpwuid()", "getgrnam()" 
and family will create it.  Apparently that is called first.

Peter Dufault
HD Associates, Inc.  Software and System Engineering



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

Re: 6.1rc3 CentOS 7 Build Sweep Report

[Joel Sherrill]

On Thu, Apr 18, 2024 at 2:00 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hallo Joel,
>
> it would be nice to have the interrupt get/set priority directives in
> RTEMS 6. When do you want to create the RTEMS 6 branch?
>

Last spring.

Seriously, Chris has been cutting 6.1 rc snapshots to help shake out
lurking issues. We use tarballs on rtems.org for the RSB and this had
to be worked through. rc1 including tools not building at all. rc2 had
some issues and I don't recall even getting to building the BSPs. rc3
is looking better.

If you have something you want to make 6, I think there is still time.
But hopefully very little. We have been working to reduce tickets
identifying 6.1 as a milestone for months.

--joel


>
> --
> 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: rtems-kernel-init.c tries to re-make existing "/etc"

[Joel Sherrill]

On Thu, Apr 18, 2024 at 9:50 AM Peter Dufault  wrote:

>
>
> > On Apr 18, 2024, at 10:34 AM, Kinsey Moore 
> wrote:
> >
> > A patch for EEXIST here should be fine. It would be nice if the caller
> were more resilient.
> >
>
> I also changed "default-network-init.h" to assert rtems_bsd_initialize()
> worked.
>
>   sc = rtems_bsd_initialize();
>   assert(sc == RTEMS_SUCCESSFUL);
>
> At least you get a panic message.  I'll submit a patch.
>

Why does /etc already exist? Is it really an error if it already exists?

If the startup code untar'ed some initial file system contents before
calling this, then /etc would almost certainly exist.

Unless I am missing something EEXIST should be acceptable. Other errors are
most likely really fatal.

https://pubs.opengroup.org/onlinepubs/9699919799/functions/mkdir.html

--joel

>
> Peter
> -
> Peter Dufault
> HD Associates, Inc.  Software and System Engineering
>
>
>
> ___
> 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-kernel-init.c tries to re-make existing "/etc"

[Peter Dufault]

> On Apr 18, 2024, at 10:34 AM, Kinsey Moore  wrote:
> 
> A patch for EEXIST here should be fine. It would be nice if the caller were 
> more resilient.
> 

I also changed "default-network-init.h" to assert rtems_bsd_initialize() worked.

  sc = rtems_bsd_initialize();
  assert(sc == RTEMS_SUCCESSFUL);

At least you get a panic message.  I'll submit a patch.

Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering



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

Re: rtems-kernel-init.c tries to re-make existing "/etc"

[Kinsey Moore]

On Thu, Apr 18, 2024 at 9:18 AM Peter Dufault  wrote:

> I just rebased to "6-freebsd-12".  This change:
>
> ###
> commit 62e0ca8283603573d42a0f15da044cd406a2f00a
> Author: Kinsey Moore 
> Date:   Tue Jan 23 13:25:45 2024 -0600
>
> rtemsbsd/rtems: Check function return values
> ###
> [dufault@gen6 rtems-libbsd]$ git diff
> 6514d561587fd1527fe6a26cb43e6b5742c8c779 rtemsbsd/rtems/rtems-kernel-init.c
> diff --git a/rtemsbsd/rtems/rtems-kernel-init.c
> b/rtemsbsd/rtems/rtems-kernel-init.c
> index 90a9c80..8ac2f59 100644
> --- a/rtemsbsd/rtems/rtems-kernel-init.c
> +++ b/rtemsbsd/rtems/rtems-kernel-init.c
> @@ -223,7 +223,9 @@ rtems_bsd_initialize(void)
> return RTEMS_UNSATISFIED;
> }
>
> -   mkdir("/etc", S_IRWXU | S_IRWXG | S_IRWXO);
> +   if (mkdir("/etc", S_IRWXU | S_IRWXG | S_IRWXO) != 0) {
> +   return RTEMS_UNSATISFIED;
> +   }
>
> sc = rtems_timer_initiate_server(rtems_bsd_get_task_priority(name),
> rtems_bsd_get_task_stack_size(name), RTEMS_DEFAULT_ATTRIBUTES);
> ###
>
> causes a crash at startup in "uma_zalloc()" (in at least the "telnetd01"
> test).
> I printed out the error, the directory already exists:
>
> mkdir("/etc",...): File exists
>
> For now I'm just checking for EEXIST and ignoring the error.
> Does anyone care to object now and say I should investigate further to fix
> the caller before I submit a patch?
>

A patch for EEXIST here should be fine. It would be nice if the caller were
more resilient.

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

rtems-kernel-init.c tries to re-make existing "/etc"

[Peter Dufault]

I just rebased to "6-freebsd-12".  This change:

###
commit 62e0ca8283603573d42a0f15da044cd406a2f00a
Author: Kinsey Moore 
Date:   Tue Jan 23 13:25:45 2024 -0600

rtemsbsd/rtems: Check function return values
###
[dufault@gen6 rtems-libbsd]$ git diff 6514d561587fd1527fe6a26cb43e6b5742c8c779 
rtemsbsd/rtems/rtems-kernel-init.c
diff --git a/rtemsbsd/rtems/rtems-kernel-init.c 
b/rtemsbsd/rtems/rtems-kernel-init.c
index 90a9c80..8ac2f59 100644
--- a/rtemsbsd/rtems/rtems-kernel-init.c
+++ b/rtemsbsd/rtems/rtems-kernel-init.c
@@ -223,7 +223,9 @@ rtems_bsd_initialize(void)
return RTEMS_UNSATISFIED;
}
 
-   mkdir("/etc", S_IRWXU | S_IRWXG | S_IRWXO);
+   if (mkdir("/etc", S_IRWXU | S_IRWXG | S_IRWXO) != 0) {
+   return RTEMS_UNSATISFIED;
+   }
 
sc = rtems_timer_initiate_server(rtems_bsd_get_task_priority(name),
rtems_bsd_get_task_stack_size(name), RTEMS_DEFAULT_ATTRIBUTES);
###

causes a crash at startup in "uma_zalloc()" (in at least the "telnetd01" test).
I printed out the error, the directory already exists:

mkdir("/etc",...): File exists

For now I'm just checking for EEXIST and ignoring the error.
Does anyone care to object now and say I should investigate further to fix the 
caller before I submit a patch?

Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering



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

Re: 6.1rc3 CentOS 7 Build Sweep Report

[Sebastian Huber]

Hallo Joel,

it would be nice to have the interrupt get/set priority directives in 
RTEMS 6. When do you want to create the RTEMS 6 branch?


--
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: [RFC] rtems: Add options to kernel output char handler

[Sebastian Huber]

On 18.04.24 04:02, Chris Johns wrote:

On 17/4/2024 11:06 pm, Sebastian Huber wrote:

Make the kernel I/O output character device processing configurable
through an option set parameter.  Add RTEMS_NO_OUTPUT and RTEMS_FLUSH
options.  The goal of this API change is to enable flushing the kernel
output device in the system termination process before a reset is
issued.  A use case for using RTEMS_NO_WAIT is the polled processing of
an input and output stream from and to the I/O device.


Thanks for providing this overview.

I am still confused about the differences in terms of why you would need the
RTEMS_NO_WAIT. Do you have a specific application where this is required? It
might help me understand the need for the change? Examples are need to reset in
a specific period, a test mode you are running in a system, etc?


The RTEMS_NO_WAIT can be used to process an input stream using 
getchark() and then send responses using a non-blocking output char 
variant. This helps to have enough processing time and allows an 
overlapping send/receive.




Is this change for RTEMS 7?


Yes, this would be good.



In the context of the change:

1. RTEMS_FLUSH etc are too generic.


I added them to , so they could be reused in 
other directives. A bit less generic names could be:


* RTEMS_IO_FLUSH

* RTEMS_IO_DRAIN

* RTEMS_IO_NO_OUTPUT

This would be in the IO namespace similar to RTEMS_EVENT_ANY and 
RTEMS_EVENT_ALL.




2. The language used needs some work, maybe fewer "while"s. For example:

  While the #RTEMS_NO_WAIT option is set in the option_set parameter, while
  the #RTEMS_NO_OUTPUT option is cleared in the option_set parameter, while
  the device can immediately accept a character for output, the character in
  out shall be hand over to the device for output.

This is difficult to read and when it is probability easier to read the code it
is of questionable value. I appreciate it is not always easy to write but I feel
clarity would be a good to have here.


This is the documentation of a function pointer type, so there is no 
direct code. With three flags, you have to specify for eight variants 
what should happen. The wording is in EARS. It should be easy to 
translate this into code for a particular device.


https://docs.rtems.org/branches/master/eng/req/req-for-req.html#syntax



Another example:

  While no character is available in the device, a polled
  character input functions shall return minus one.

It could be written as:

  A polled character input function shall return a character if the device
  has successfully received one else the function returns minus one.


I would prefer the EARS variant. This function type should define 
requirements for the associated implementations.




I think receive and transmit is better than for example "be hand over to the
device for output", maybe "shall be transmitted by the device".


The name of this function type is BSP_output_char_function_type and not 
BSP_transmit_char_function_type, so I used "output" here and not 
"transmit". Also, the character may not get immediately transmitted if 
FIFOs are involved (thus the need for the flush). Maybe my understanding 
of transmitted is wrong, but for me transmitting has something to do 
with signals on a medium.




3. Flush needs to be worded in terms of successfully transmitted by the device
to avoid the case of data being written to the device is held in FIFOs awaiting
transmission and reset is asserted. Maybe FLUSH is the wrong term because it is
so overloaded in what it means? An alternative could be
RTEMS_BSP_IO_TRANSMISSION_COMPLETE? And following on you could have
RTEMS_BSP_IO_NO_TRANSMISSION? The key point is "transmission" relates to the
external data pin of the interface.


The no-output option is used to just flush the device without 
transmitting a new character. For the flush, we could add something like 
this:


Flushing the device should ensure that all characters handed over to the 
device for output are visible to external consumers. For example, the 
device output FIFO and transmit shift registers should be empty.




Chris


---
  cpukit/include/rtems/bspIo.h | 50 ++--
  cpukit/include/rtems/rtems/options.h | 20 ++-
  2 files changed, 67 insertions(+), 3 deletions(-)

diff --git a/cpukit/include/rtems/bspIo.h b/cpukit/include/rtems/bspIo.h
index 31580cd800..09a3c47243 100644
--- a/cpukit/include/rtems/bspIo.h
+++ b/cpukit/include/rtems/bspIo.h
@@ -10,7 +10,7 @@
   */
  
  /*

- * Copyright (C) 2020, 2021 embedded brains GmbH & Co. KG
+ * Copyright (C) 2020, 2024 embedded brains GmbH & Co. KG
   * Copyright (C) 2015 On-Line Applications Research Corporation (OAR)
   *
   * Redistribution and use in source and binary forms, with or without
@@ -58,6 +58,8 @@
  #define _RTEMS_BSPIO_H
  
  #include 

+#include 
+#include 
  #include 
  
  #ifdef __cplusplus

@@ -89,8 +91,42 @@ extern "C" {
   * @ingroup RTEMSAPIKernelCharIO
   *
   * @brief Polled character 

Fwd: Deprecation/removal of nios2 target support

[Joel Sherrill]

We should track this but if the GNU tools drop support, this is normally
the trigger for RTEMS.

Unless the support situation changes, I think we will have to remove nios2
in RTEMS 7

--joel

-- Forwarded message -
From: Sandra Loosemore 
Date: Wed, Apr 17, 2024, 10:28 PM
Subject: Deprecation/removal of nios2 target support
To: , , <
gdb-patc...@sourceware.org>, , Chung-Lin Tang <
clt...@baylibre.com>, , Yao Qi 
Cc: Dinh Nguyen , , <
new...@sourceware.org>


Tomorrow I plan to push patches to mark the nios2 target as obsolete in
GCC 14.

Background: Intel has EOL'ed the Nios II processor IP and is now
directing their FPGA customers to a RISC-V platform instead.

https://www.intel.com/content/www/us/en/content-details/781327/intel-is-discontinuing-ip-ordering-codes-listed-in-pdn2312-for-nios-ii-ip.html

The Nios II hardware on loan from Intel that we were using for testing
at Mentor Graphics/Siemens was returned around the first of the year.
For some time we had been using QEMU to test the nios2-elf target, but
we never had a QEMU test harness set up that would boot the Linux
kernel, and user-mode QEMU on this target is too buggy/unmaintained to
use for primary testing.  So the current situation is that none of the
listed maintainers for any of the GNU toolchain components have access
to a fully working test configuration any more, we have all moved on to
new jobs and different projects, Intel has also moved on to a different
platform, and our former contacts on Intel's Nios II team have moved on
as well.  It seems like it's time to pull the plug.

Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and remove
support from all toolchain components after the release is made.  I'm
not sure there is an established process for obsoleting/removing support
in other components; besides binutils, GDB, and GLIBC, there's QEMU,
newlib/libgloss, and the Linux kernel.  But, we need to get the ball
rolling somewhere.

I did do some GCC testing on both ELF and Linux Nios II targets around
the end of December and another round about a month ago, so I believe
GCC 14 will pretty much be in working order.  Beyond that, though, I
think it would be better to remove support promptly, rather than having
it hang around in an unmaintained/untestable zombie state, getting ever
more bit-rotten.

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

Re: [PATCH] bsps/powerpc: Introduction of interrupt locks

[Chris Johns]

Hi Vincenzo,

Welcome to RTEMS.

What hardware in the shared VME PowerPC family of BSPS has this change been
tested on?

Thanks
Chris

On 17/4/2024 5:34 pm, Vincenzo Calabretta wrote:
> Interrupt locks are introduced in shared vme device drivers to enable
> compilation in an SMP configuration of the qoriq BSP.
> ---
>  bsps/powerpc/shared/vme/vmeTsi148.c   | 44 ++-
>  bsps/powerpc/shared/vme/vmeUniverse.c | 40 +---
>  2 files changed, 45 insertions(+), 39 deletions(-)
> 
> diff --git a/bsps/powerpc/shared/vme/vmeTsi148.c 
> b/bsps/powerpc/shared/vme/vmeTsi148.c
> index aaabb1b28d..a6f0ac87ab 100644
> --- a/bsps/powerpc/shared/vme/vmeTsi148.c
> +++ b/bsps/powerpc/shared/vme/vmeTsi148.c
> @@ -545,16 +545,17 @@ vmeTsi148Reset(void)
>   vmeTsi148ResetXX(THEBASE);
>  }
>  
> +RTEMS_INTERRUPT_LOCK_DEFINE( static, vmeTsi148_lock, "vmeTsi148_lock" )
>  void
>  vmeTsi148ResetBusXX(BERegister *base)
>  {
> -unsigned long flags;
>  uint32_t  v;
> +rtems_interrupt_lock_context lock_context;
>  
> - rtems_interrupt_disable(flags);
> + rtems_interrupt_lock_acquire( _lock, _context );
>   v = TSI_RD(base, TSI_VCTRL_REG);
>   TSI_WR(base, TSI_VCTRL_REG, v | TSI_VCTRL_SRESET);
> - rtems_interrupt_enable(flags);
> + rtems_interrupt_lock_release( _lock, _context );
>  }
>  
>  void
> @@ -1410,7 +1411,8 @@ int
>  vmeTsi148IntRoute(unsigned int level, unsigned int pin)
>  {
>  int  i;
> -unsigned longmask, shift, mapreg, flags, wire;
> +unsigned longmask, shift, mapreg, wire;
> +rtems_interrupt_lock_context lock_context;
>  
>   if ( pin >= TSI_NUM_WIRES || ! tsi_wire[pin] || 
> !vmeTsi148IrqMgrInstalled )
>   return -1;
> @@ -1442,8 +1444,7 @@ unsigned long   mask, shift, mapreg, flags, wire;
>   /* wires are offset by 1 so we can initialize the wire table to all 
> zeros */
>   wire = (tsi_wire[pin]-1) << shift;
>  
> -rtems_interrupt_disable(flags);
> -
> + rtems_interrupt_lock_acquire( _lock, _context );
>   for ( i = 0; i   wire_mask[i] &= ~mask;
>   }
> @@ -1453,7 +1454,7 @@ rtems_interrupt_disable(flags);
>   mask |= wire;
>   TSI_WR( THEBASE, mapreg, mask );
>  
> -rtems_interrupt_enable(flags);
> + rtems_interrupt_lock_release( _lock, _context );
>   return 0;
>  }
>  
> @@ -1461,9 +1462,9 @@ VmeTsi148ISR
>  vmeTsi148ISRGet(unsigned long vector, void **parg)
>  {
>  VmeTsi148ISR   rval = 0;
> -unsigned long  flags;
>  volatile IRQEntry *p;
>  int   v = uni2tsivec(vector);
> +rtems_interrupt_lock_context lock_context;
>  
>  
>   if ( v < 0 )
> @@ -1471,13 +1472,13 @@ int   v = uni2tsivec(vector);
>  
>   p = irqHdlTbl + v;
>  
> - rtems_interrupt_disable(flags);
> + rtems_interrupt_lock_acquire( _lock, _context );
>   if ( *p ) {
>   if ( parg )
>   *parg = (*p)->usrData;
>   rval = (*p)->isr;
>   }
> - rtems_interrupt_enable(flags);
> + rtems_interrupt_lock_release( _lock, _context );
>  
>   return rval;
>  }
> @@ -1794,8 +1795,8 @@ vmeTsi148InstallISR(unsigned long vector, VmeTsi148ISR 
> hdl, void *arg)
>  {
>  IRQEntry  ip;
>  intv;
> -unsigned long  flags;
>  volatile IRQEntry *p;
> +rtems_interrupt_lock_context lock_context;
>  
>   if ( !vmeTsi148IrqMgrInstalled || (v = uni2tsivec(vector)) < 0 )
>   return -1;
> @@ -1808,14 +1809,14 @@ volatile IRQEntry *p;
>   ip->isr=hdl;
>   ip->usrData=arg;
>  
> - rtems_interrupt_disable(flags);
> + rtems_interrupt_lock_acquire( _lock, _context );
>   if (*p) {
> - rtems_interrupt_enable(flags);
> + rtems_interrupt_lock_release( _lock, 
> _context );
>   free(ip);
>   return -1;
>   }
>   *p = ip;
> - rtems_interrupt_enable(flags);
> + rtems_interrupt_lock_release( _lock, _context );
>   return 0;
>  }
>  
> @@ -1824,22 +1825,22 @@ vmeTsi148RemoveISR(unsigned long vector, VmeTsi148ISR 
> hdl, void *arg)
>  {
>  int   v;
>  IRQEntry  ip;
> -unsigned long flags;
>  volatile IRQEntry *p;
> +rtems_interrupt_lock_context lock_context;
>  
>   if ( !vmeTsi148IrqMgrInstalled || (v = uni2tsivec(vector)) < 0 )
>   return -1;
>  
>   p = irqHdlTbl + v;
>  
> - rtems_interrupt_disable(flags);
> + rtems_interrupt_lock_acquire( _lock, _context );
>   ip = *p;
>   if ( !ip || ip->isr!=hdl || ip->usrData!=arg ) {
> - rtems_interrupt_enable(flags);
> + rtems_interrupt_lock_release( _lock, 
> _context );
>  

Re: [RFC] rtems: Add options to kernel output char handler

[Chris Johns]

On 17/4/2024 11:06 pm, Sebastian Huber wrote:
> Make the kernel I/O output character device processing configurable
> through an option set parameter.  Add RTEMS_NO_OUTPUT and RTEMS_FLUSH
> options.  The goal of this API change is to enable flushing the kernel
> output device in the system termination process before a reset is
> issued.  A use case for using RTEMS_NO_WAIT is the polled processing of
> an input and output stream from and to the I/O device.

Thanks for providing this overview.

I am still confused about the differences in terms of why you would need the
RTEMS_NO_WAIT. Do you have a specific application where this is required? It
might help me understand the need for the change? Examples are need to reset in
a specific period, a test mode you are running in a system, etc?

Is this change for RTEMS 7?

In the context of the change:

1. RTEMS_FLUSH etc are too generic.

2. The language used needs some work, maybe fewer "while"s. For example:

 While the #RTEMS_NO_WAIT option is set in the option_set parameter, while
 the #RTEMS_NO_OUTPUT option is cleared in the option_set parameter, while
 the device can immediately accept a character for output, the character in
 out shall be hand over to the device for output.

This is difficult to read and when it is probability easier to read the code it
is of questionable value. I appreciate it is not always easy to write but I feel
clarity would be a good to have here.

Another example:

 While no character is available in the device, a polled
 character input functions shall return minus one.

It could be written as:

 A polled character input function shall return a character if the device
 has successfully received one else the function returns minus one.

I think receive and transmit is better than for example "be hand over to the
device for output", maybe "shall be transmitted by the device".

3. Flush needs to be worded in terms of successfully transmitted by the device
to avoid the case of data being written to the device is held in FIFOs awaiting
transmission and reset is asserted. Maybe FLUSH is the wrong term because it is
so overloaded in what it means? An alternative could be
RTEMS_BSP_IO_TRANSMISSION_COMPLETE? And following on you could have
RTEMS_BSP_IO_NO_TRANSMISSION? The key point is "transmission" relates to the
external data pin of the interface.

Chris

> ---
>  cpukit/include/rtems/bspIo.h | 50 ++--
>  cpukit/include/rtems/rtems/options.h | 20 ++-
>  2 files changed, 67 insertions(+), 3 deletions(-)
> 
> diff --git a/cpukit/include/rtems/bspIo.h b/cpukit/include/rtems/bspIo.h
> index 31580cd800..09a3c47243 100644
> --- a/cpukit/include/rtems/bspIo.h
> +++ b/cpukit/include/rtems/bspIo.h
> @@ -10,7 +10,7 @@
>   */
>  
>  /*
> - * Copyright (C) 2020, 2021 embedded brains GmbH & Co. KG
> + * Copyright (C) 2020, 2024 embedded brains GmbH & Co. KG
>   * Copyright (C) 2015 On-Line Applications Research Corporation (OAR)
>   *
>   * Redistribution and use in source and binary forms, with or without
> @@ -58,6 +58,8 @@
>  #define _RTEMS_BSPIO_H
>  
>  #include 
> +#include 
> +#include 
>  #include 
>  
>  #ifdef __cplusplus
> @@ -89,8 +91,42 @@ extern "C" {
>   * @ingroup RTEMSAPIKernelCharIO
>   *
>   * @brief Polled character output functions shall have this type.
> + *
> + * @param out is the character to output.
> + *
> + * @param option_set is the option set.
> + *
> + * While the #RTEMS_NO_WAIT option is set in the option_set parameter, while
> + * the device cannot immediately accept a character for output, the character
> + * in out shall not be hand over to the device for output, optionally the
> + * device output shall be flushed, and ::RTEMS_UNSATISFIED shall be returned.
> + *
> + * While the #RTEMS_NO_OUTPUT option is set in the option_set parameter, the
> + * character in the out parameter shall not be handed over to the device for
> + * output.
> + *
> + * While the #RTEMS_NO_WAIT option is cleared in the option_set parameter,
> + * while the #RTEMS_NO_OUTPUT option is cleared in the option_set parameter,
> + * the character in the out parameter shall be hand over to the device for
> + * output.
> + *
> + * While the #RTEMS_NO_WAIT option is set in the option_set parameter, while
> + * the #RTEMS_NO_OUTPUT option is cleared in the option_set parameter, while
> + * the device can immediately accept a character for output, the character in
> + * out shall be hand over to the device for output.
> + *
> + * While the #RTEMS_FLUSH option is set in the option_set parameter, the 
> device
> + * output shall be flushed before the function returns.
> + *
> + * @retval ::RTEMS_SUCCESSFUL The requested operation was successful.
> + *
> + * @retval ::RTEMS_UNSATISFIED The device is was not ready to output a
> + *   character.
>   */
> -typedef void ( *BSP_output_char_function_type )( char );
> +typedef rtems_status_code ( *BSP_output_char_function_type )(
> +  char out,
> +  rtems_option option_set

Re: 6.1rc3 CentOS 7 Build Sweep Report

[Chris Johns]

On 18/4/2024 4:13 am, Joel Sherrill wrote:
> Hi
> 
> 6.1rc3 appears to be in pretty good shape on CentOS 7 (w/GCC 8 and Python 3
> SCL). Results should be on the build@ list. One odd issue appears to be in the
> rtems-tester.
> 
> Testing a riscv-bsp with spike, I get this output. It is repeated with other
> spike/risc-v bsp tests. Any ideas?
> 
> Exception in thread _stdout[spike]:
> Traceback (most recent call last):
>   File "/opt/rh/rh-python36/root/usr/lib64/python3.6/threading.py", line 916, 
> in
> _bootstrap_inner
>     self.run()
>   File "/opt/rh/rh-python36/root/usr/lib64/python3.6/threading.py", line 864, 
> in run
>     self._target(*self._args, **self._kwargs)
>   File "/home/joel/rtems-6.1rc3/tools/6/share/rtems/rtemstoolkit/execute.py",
> line 226, in _readthread
>     data = data.decode(sys.stdout.encoding)
> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0: 
> invalid
> start byte

The rtems-tools's execute.py needs to be updated to use an incremental decoder
codec. This also happened in the RSB and was fixed with:

https://git.rtems.org/rtems-source-builder/commit/source-builder/sb/execute.py?id=e04c84191b790b7bddd179bc67337e4205b61f8e

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

Re: 6.1rc3 CentOS 7 Build Sweep Report

[John Howard]

UTF-8 start byte cannot be 0xff.

Off-by-1 bug is possible. Maybe a hidden control character is throwing off the 
count but being stripped away prior to the attempt to convert to UTF-8.

On Apr 17, 2024, at 1:13 PM, Joel Sherrill  wrote:

Hi

6.1rc3 appears to be in pretty good shape on CentOS 7 (w/GCC 8 and Python 3 
SCL). Results should be on the build@ list. One odd issue appears to be in the 
rtems-tester.

Testing a riscv-bsp with spike, I get this output. It is repeated with other 
spike/risc-v bsp tests. Any ideas?

Exception in thread _stdout[spike]:
Traceback (most recent call last):
  File "/opt/rh/rh-python36/root/usr/lib64/python3.6/threading.py", line 916, 
in _bootstrap_inner
self.run()
  File "/opt/rh/rh-python36/root/usr/lib64/python3.6/threading.py", line 864, 
in run
self._target(*self._args, **self._kwargs)
  File "/home/joel/rtems-6.1rc3/tools/6/share/rtems/rtemstoolkit/execute.py", 
line 226, in _readthread
data = data.decode(sys.stdout.encoding)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0: invalid 
start byte

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

6.1rc3 CentOS 7 Build Sweep Report

[Joel Sherrill]

Hi

6.1rc3 appears to be in pretty good shape on CentOS 7 (w/GCC 8 and Python 3
SCL). Results should be on the build@ list. One odd issue appears to be in
the rtems-tester.

Testing a riscv-bsp with spike, I get this output. It is repeated with
other spike/risc-v bsp tests. Any ideas?

Exception in thread _stdout[spike]:
Traceback (most recent call last):
  File "/opt/rh/rh-python36/root/usr/lib64/python3.6/threading.py", line
916, in _bootstrap_inner
self.run()
  File "/opt/rh/rh-python36/root/usr/lib64/python3.6/threading.py", line
864, in run
self._target(*self._args, **self._kwargs)
  File
"/home/joel/rtems-6.1rc3/tools/6/share/rtems/rtemstoolkit/execute.py", line
226, in _readthread
data = data.decode(sys.stdout.encoding)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0:
invalid start byte

RTEMS Testing - Tester, 6.0.not_released
[ 3/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  L:0  i:0  W:0  |
riscv64/rv64imac: cdtest.exe
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps/arm: Improve GICv3 support

[Kinsey Moore]

On Wed, Apr 17, 2024 at 12:51 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 16.04.24 16:51, Kinsey Moore wrote:
> > This adds warnings for arm_interrupt_enable_interrupts and
> > arm_interrupt_restore_interrupts. I suspect a missing header. They also
> > generate a link error on the a53_lp64_qemu bsp. I also dislike the
> > while(true), but I don't think we officially have anything against it
> > and there are existing examples in the codebase.
>
> Did you test this with the latest master? Actually, I committed a
> similar patch for the GICv2 and then noticed that this broke the GICv3
> support. This is fixed by the current patch.
>
> What would be your alternative to this while (true) loop?
>
> void bsp_interrupt_dispatch(void)
> {
>while (true) {
>  uint32_t icciar = READ_SR(ICC_IAR1);
>  rtems_vector_number vector = GIC_CPUIF_ICCIAR_ACKINTID_GET(icciar);
>  uint32_t status;
>
>  if (!bsp_interrupt_is_valid_vector(vector)) {
>break;
>  }
>
>  status = arm_interrupt_enable_interrupts();
>  bsp_interrupt_handler_dispatch_unchecked(vector);
>  arm_interrupt_restore_interrupts(status);
>
>  WRITE_SR(ICC_EOIR1, icciar);
>}
> }
>

You're right, I was a couple patches behind when I checked this out. That's
my fault. When I tried again just now the patch wouldn't apply because it
was already committed.

As far as the loop, the sequence of calls just doesn't lead to a clean
implementation since it's the above example, adding a loop prologue with
duplicated code, duplicating a check, or stuffing several calls including
an assignment into the conditional.

In any case, I suppose the point is moot since it's already upstream and
there's not a clear answer for "better".

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

[RFC] rtems: Add options to kernel output char handler

[Sebastian Huber]

Make the kernel I/O output character device processing configurable
through an option set parameter.  Add RTEMS_NO_OUTPUT and RTEMS_FLUSH
options.  The goal of this API change is to enable flushing the kernel
output device in the system termination process before a reset is
issued.  A use case for using RTEMS_NO_WAIT is the polled processing of
an input and output stream from and to the I/O device.
---
 cpukit/include/rtems/bspIo.h | 50 ++--
 cpukit/include/rtems/rtems/options.h | 20 ++-
 2 files changed, 67 insertions(+), 3 deletions(-)

diff --git a/cpukit/include/rtems/bspIo.h b/cpukit/include/rtems/bspIo.h
index 31580cd800..09a3c47243 100644
--- a/cpukit/include/rtems/bspIo.h
+++ b/cpukit/include/rtems/bspIo.h
@@ -10,7 +10,7 @@
  */
 
 /*
- * Copyright (C) 2020, 2021 embedded brains GmbH & Co. KG
+ * Copyright (C) 2020, 2024 embedded brains GmbH & Co. KG
  * Copyright (C) 2015 On-Line Applications Research Corporation (OAR)
  *
  * Redistribution and use in source and binary forms, with or without
@@ -58,6 +58,8 @@
 #define _RTEMS_BSPIO_H
 
 #include 
+#include 
+#include 
 #include 
 
 #ifdef __cplusplus
@@ -89,8 +91,42 @@ extern "C" {
  * @ingroup RTEMSAPIKernelCharIO
  *
  * @brief Polled character output functions shall have this type.
+ *
+ * @param out is the character to output.
+ *
+ * @param option_set is the option set.
+ *
+ * While the #RTEMS_NO_WAIT option is set in the option_set parameter, while
+ * the device cannot immediately accept a character for output, the character
+ * in out shall not be hand over to the device for output, optionally the
+ * device output shall be flushed, and ::RTEMS_UNSATISFIED shall be returned.
+ *
+ * While the #RTEMS_NO_OUTPUT option is set in the option_set parameter, the
+ * character in the out parameter shall not be handed over to the device for
+ * output.
+ *
+ * While the #RTEMS_NO_WAIT option is cleared in the option_set parameter,
+ * while the #RTEMS_NO_OUTPUT option is cleared in the option_set parameter,
+ * the character in the out parameter shall be hand over to the device for
+ * output.
+ *
+ * While the #RTEMS_NO_WAIT option is set in the option_set parameter, while
+ * the #RTEMS_NO_OUTPUT option is cleared in the option_set parameter, while
+ * the device can immediately accept a character for output, the character in
+ * out shall be hand over to the device for output.
+ *
+ * While the #RTEMS_FLUSH option is set in the option_set parameter, the device
+ * output shall be flushed before the function returns.
+ *
+ * @retval ::RTEMS_SUCCESSFUL The requested operation was successful.
+ *
+ * @retval ::RTEMS_UNSATISFIED The device is was not ready to output a
+ *   character.
  */
-typedef void ( *BSP_output_char_function_type )( char );
+typedef rtems_status_code ( *BSP_output_char_function_type )(
+  char out,
+  rtems_option option_set
+);
 
 /* Generated from spec:/rtems/io/if/bsp-output-char */
 
@@ -333,6 +369,16 @@ int rtems_printk_printer( void *unused, const char *fmt, 
va_list ap );
  * @ingroup RTEMSAPIKernelCharIO
  *
  * @brief Polled character input functions shall have this type.
+ *
+ * While a character is available in the device, a polled character input
+ * function shall return the least recently received character as an unsigned
+ * character.  While no character is available in the device, a polled
+ * character input functions shall return minus one.
+ *
+ * @retval -1 There was no input character available in the device.
+ *
+ * @return Returns the least recently received character available in the
+ *   device as an unsigned character.
  */
 typedef int (* BSP_polling_getchar_function_type )( void );
 
diff --git a/cpukit/include/rtems/rtems/options.h 
b/cpukit/include/rtems/rtems/options.h
index 44a8d6ccb8..3522fc4fcd 100644
--- a/cpukit/include/rtems/rtems/options.h
+++ b/cpukit/include/rtems/rtems/options.h
@@ -9,7 +9,7 @@
  */
 
 /*
- * Copyright (C) 2020 embedded brains GmbH & Co. KG
+ * Copyright (C) 2020, 2024 embedded brains GmbH & Co. KG
  * Copyright (C) 1989, 2008 On-Line Applications Research Corporation (OAR)
  *
  * Redistribution and use in source and binary forms, with or without
@@ -103,6 +103,24 @@ extern "C" {
  */
 #define RTEMS_EVENT_ANY 0x0002
 
+/* Generated from spec:/rtems/option/if/flush */
+
+/**
+ * @ingroup RTEMSAPIClassicOptions
+ *
+ * @brief This option constant indicates that something shall be flushed.
+ */
+#define RTEMS_FLUSH 0x0008
+
+/* Generated from spec:/rtems/option/if/no-output */
+
+/**
+ * @ingroup RTEMSAPIClassicOptions
+ *
+ * @brief This option constant indicates that the nothing shall be output.
+ */
+#define RTEMS_NO_OUTPUT 0x0004
+
 /* Generated from spec:/rtems/option/if/no-wait */
 
 /**
-- 
2.35.3

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

[PATCH] bsps/powerpc: Introduction of interrupt locks

[Vincenzo Calabretta]

Interrupt locks are introduced in shared vme device drivers to enable
compilation in an SMP configuration of the qoriq BSP.
---
 bsps/powerpc/shared/vme/vmeTsi148.c   | 44 ++-
 bsps/powerpc/shared/vme/vmeUniverse.c | 40 +---
 2 files changed, 45 insertions(+), 39 deletions(-)

diff --git a/bsps/powerpc/shared/vme/vmeTsi148.c 
b/bsps/powerpc/shared/vme/vmeTsi148.c
index aaabb1b28d..a6f0ac87ab 100644
--- a/bsps/powerpc/shared/vme/vmeTsi148.c
+++ b/bsps/powerpc/shared/vme/vmeTsi148.c
@@ -545,16 +545,17 @@ vmeTsi148Reset(void)
vmeTsi148ResetXX(THEBASE);
 }
 
+RTEMS_INTERRUPT_LOCK_DEFINE( static, vmeTsi148_lock, "vmeTsi148_lock" )
 void
 vmeTsi148ResetBusXX(BERegister *base)
 {
-unsigned long flags;
 uint32_t  v;
+rtems_interrupt_lock_context lock_context;
 
-   rtems_interrupt_disable(flags);
+   rtems_interrupt_lock_acquire( _lock, _context );
v = TSI_RD(base, TSI_VCTRL_REG);
TSI_WR(base, TSI_VCTRL_REG, v | TSI_VCTRL_SRESET);
-   rtems_interrupt_enable(flags);
+   rtems_interrupt_lock_release( _lock, _context );
 }
 
 void
@@ -1410,7 +1411,8 @@ int
 vmeTsi148IntRoute(unsigned int level, unsigned int pin)
 {
 inti;
-unsigned long  mask, shift, mapreg, flags, wire;
+unsigned long  mask, shift, mapreg, wire;
+rtems_interrupt_lock_context lock_context;
 
if ( pin >= TSI_NUM_WIRES || ! tsi_wire[pin] || 
!vmeTsi148IrqMgrInstalled )
return -1;
@@ -1442,8 +1444,7 @@ unsigned long mask, shift, mapreg, flags, wire;
/* wires are offset by 1 so we can initialize the wire table to all 
zeros */
wire = (tsi_wire[pin]-1) << shift;
 
-rtems_interrupt_disable(flags);
-
+   rtems_interrupt_lock_acquire( _lock, _context );
for ( i = 0; iusrData;
rval = (*p)->isr;
}
-   rtems_interrupt_enable(flags);
+   rtems_interrupt_lock_release( _lock, _context );
 
return rval;
 }
@@ -1794,8 +1795,8 @@ vmeTsi148InstallISR(unsigned long vector, VmeTsi148ISR 
hdl, void *arg)
 {
 IRQEntry  ip;
 int  v;
-unsigned longflags;
 volatile IRQEntry *p;
+rtems_interrupt_lock_context lock_context;
 
if ( !vmeTsi148IrqMgrInstalled || (v = uni2tsivec(vector)) < 0 )
return -1;
@@ -1808,14 +1809,14 @@ volatile IRQEntry *p;
ip->isr=hdl;
ip->usrData=arg;
 
-   rtems_interrupt_disable(flags);
+   rtems_interrupt_lock_acquire( _lock, _context );
if (*p) {
-   rtems_interrupt_enable(flags);
+   rtems_interrupt_lock_release( _lock, 
_context );
free(ip);
return -1;
}
*p = ip;
-   rtems_interrupt_enable(flags);
+   rtems_interrupt_lock_release( _lock, _context );
return 0;
 }
 
@@ -1824,22 +1825,22 @@ vmeTsi148RemoveISR(unsigned long vector, VmeTsi148ISR 
hdl, void *arg)
 {
 int   v;
 IRQEntry  ip;
-unsigned long flags;
 volatile IRQEntry *p;
+rtems_interrupt_lock_context lock_context;
 
if ( !vmeTsi148IrqMgrInstalled || (v = uni2tsivec(vector)) < 0 )
return -1;
 
p = irqHdlTbl + v;
 
-   rtems_interrupt_disable(flags);
+   rtems_interrupt_lock_acquire( _lock, _context );
ip = *p;
if ( !ip || ip->isr!=hdl || ip->usrData!=arg ) {
-   rtems_interrupt_enable(flags);
+   rtems_interrupt_lock_release( _lock, 
_context );
return -1;
}
*p = 0;
-   rtems_interrupt_enable(flags);
+   rtems_interrupt_lock_release( _lock, _context );
 
free(ip);
return 0;
@@ -1849,8 +1850,9 @@ static int
 intDoEnDis(unsigned int level, int dis)
 {
 BERegister *b = THEBASE;
-unsigned long  flags, v;
+unsigned long   v;
 intshift;
+rtems_interrupt_lock_context lock_context;
 
if (  ! vmeTsi148IrqMgrInstalled || (shift = lvl2bitno(level)) < 0 )
return -1;
@@ -1860,7 +1862,7 @@ int   shift;
if ( !dis )
return (int)(v & TSI_RD(b, TSI_INTEO_REG) & TSI_RD(b, 
TSI_INTEN_REG)) ? 1 : 0;
 
-   rtems_interrupt_disable(flags);
+   rtems_interrupt_lock_acquire( _lock, _context );
if ( dis<0 ) {
TSI_WR(b, TSI_INTEN_REG, TSI_RD(b, TSI_INTEN_REG) & ~v);
TSI_WR(b, TSI_INTEO_REG, TSI_RD(b, TSI_INTEO_REG) & ~v);
@@ -1868,7 +1870,7 @@ int   shift;
TSI_WR(b, TSI_INTEN_REG, TSI_RD(b, TSI_INTEN_REG) |  v);
TSI_WR(b, TSI_INTEO_REG, TSI_RD(b, 

Re: [PATCH] bsps/arm: Improve GICv3 support

[Sebastian Huber]

On 16.04.24 16:51, Kinsey Moore wrote:
This adds warnings for arm_interrupt_enable_interrupts and 
arm_interrupt_restore_interrupts. I suspect a missing header. They also 
generate a link error on the a53_lp64_qemu bsp. I also dislike the 
while(true), but I don't think we officially have anything against it 
and there are existing examples in the codebase.


Did you test this with the latest master? Actually, I committed a 
similar patch for the GICv2 and then noticed that this broke the GICv3 
support. This is fixed by the current patch.


What would be your alternative to this while (true) loop?

void bsp_interrupt_dispatch(void)
{
  while (true) {
uint32_t icciar = READ_SR(ICC_IAR1);
rtems_vector_number vector = GIC_CPUIF_ICCIAR_ACKINTID_GET(icciar);
uint32_t status;

if (!bsp_interrupt_is_valid_vector(vector)) {
  break;
}

status = arm_interrupt_enable_interrupts();
bsp_interrupt_handler_dispatch_unchecked(vector);
arm_interrupt_restore_interrupts(status);

WRITE_SR(ICC_EOIR1, icciar);
  }
}

--
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: [PATCH] bsps/arm: Improve GICv3 support

[Kinsey Moore]

This adds warnings for arm_interrupt_enable_interrupts and
arm_interrupt_restore_interrupts. I suspect a missing header. They also
generate a link error on the a53_lp64_qemu bsp. I also dislike the
while(true), but I don't think we officially have anything against it and
there are existing examples in the codebase.

Kinsey

On Tue, Apr 16, 2024 at 3:24 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> In addtion to 1023, the GICC_IAR register may return 1022 as a special
> value.
> Simply check for a valid interrupt vector for the dispatching.
>
> Check the GICC_IAR again after the dispatch to quickly process a next
> interrupt
> without having to go through the interrupt prologue and epiloge.
> ---
>  bsps/shared/dev/irq/arm-gicv3.c | 16 +++-
>  1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/bsps/shared/dev/irq/arm-gicv3.c
> b/bsps/shared/dev/irq/arm-gicv3.c
> index 88ac3c8293..dcfada6cd0 100644
> --- a/bsps/shared/dev/irq/arm-gicv3.c
> +++ b/bsps/shared/dev/irq/arm-gicv3.c
> @@ -42,12 +42,18 @@
>
>  void bsp_interrupt_dispatch(void)
>  {
> -  uint32_t icciar = READ_SR(ICC_IAR1);
> -  rtems_vector_number vector = GIC_CPUIF_ICCIAR_ACKINTID_GET(icciar);
> -  rtems_vector_number spurious = 1023;
> +  while (true) {
> +uint32_t icciar = READ_SR(ICC_IAR1);
> +rtems_vector_number vector = GIC_CPUIF_ICCIAR_ACKINTID_GET(icciar);
> +uint32_t status;
>
> -  if (vector != spurious) {
> -arm_interrupt_handler_dispatch(vector);
> +if (!bsp_interrupt_is_valid_vector(vector)) {
> +  break;
> +}
> +
> +status = arm_interrupt_enable_interrupts();
> +bsp_interrupt_handler_dispatch_unchecked(vector);
> +arm_interrupt_restore_interrupts(status);
>
>  WRITE_SR(ICC_EOIR1, icciar);
>}
> --
> 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

[PATCH] bsps/aarch64/raspberrypi: Add system timer support

[Ning Yang]

The clock from the ARM timer is derived from the system clock. This clock can 
change dynamically e.g. if the system goes into reduced power or in low power 
mode. Thus the clock speed adapts to the overall system performance 
capabilities. For accurate timing it is recommended to use the system timers.

if BSP_CLOCK_USE_SYSTEMTIMER = 1, use the System Timer, otherwise use the ARM 
Timer.
---
 bsps/aarch64/raspberrypi/include/bsp/irq.h| 14 ++---
 .../raspberrypi/include/bsp/raspberrypi.h |  9 ++
 spec/build/bsps/aarch64/grp.yml   |  3 --
 .../aarch64/raspberrypi/bspraspberrypi4.yml   |  6 ++--
 .../bsps/aarch64/raspberrypi/objclock.yml | 31 +++
 .../aarch64/raspberrypi/objsystemtimer.yml| 23 ++
 .../aarch64/raspberrypi/optsystemtimer.yml| 24 ++
 7 files changed, 100 insertions(+), 10 deletions(-)
 create mode 100644 spec/build/bsps/aarch64/raspberrypi/objclock.yml
 create mode 100644 spec/build/bsps/aarch64/raspberrypi/objsystemtimer.yml
 create mode 100644 spec/build/bsps/aarch64/raspberrypi/optsystemtimer.yml

diff --git a/bsps/aarch64/raspberrypi/include/bsp/irq.h 
b/bsps/aarch64/raspberrypi/include/bsp/irq.h
index 1ff6ae80de..d493e83707 100644
--- a/bsps/aarch64/raspberrypi/include/bsp/irq.h
+++ b/bsps/aarch64/raspberrypi/include/bsp/irq.h
@@ -9,6 +9,7 @@
 /**
  * Copyright (c) 2013 Alan Cudmore
  * Copyright (c) 2022 Mohd Noor Aman
+ * Copyright (c) 2024 Ning Yang
  *
  *  The license and distribution terms for this file may be
  *  found in the file LICENSE in this distribution or at
@@ -33,15 +34,18 @@
  * @brief Interrupt support.
  */

-#define BCM2835_INTC_TOTAL_IRQ   (64 + 8)
+#define BCM2835_INTC_TOTAL_IRQ   216

 #define BCM2835_IRQ_SET1_MIN 0
 #define BCM2835_IRQ_SET2_MIN 32

-#define BCM2835_IRQ_ID_GPU_TIMER_M0  0
-#define BCM2835_IRQ_ID_GPU_TIMER_M1  1
-#define BCM2835_IRQ_ID_GPU_TIMER_M2  2
-#define BCM2835_IRQ_ID_GPU_TIMER_M3  3
+#define BCM2711_IRQ_VC_PERIPHERAL_BASE 96
+
+/* Interrupt Vectors: System Timer */
+#define BCM2835_IRQ_ID_GPU_TIMER_M0(BCM2711_IRQ_VC_PERIPHERAL_BASE + 0)
+#define BCM2835_IRQ_ID_GPU_TIMER_M1(BCM2711_IRQ_VC_PERIPHERAL_BASE + 1)
+#define BCM2835_IRQ_ID_GPU_TIMER_M2(BCM2711_IRQ_VC_PERIPHERAL_BASE + 2)
+#define BCM2835_IRQ_ID_GPU_TIMER_M3(BCM2711_IRQ_VC_PERIPHERAL_BASE + 3)

 #define BCM2835_IRQ_ID_USB   9
 #define BCM2835_IRQ_ID_AUX   29
diff --git a/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h 
b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
index 55dd9ed1e9..f185d1df57 100644
--- a/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
+++ b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
@@ -8,6 +8,7 @@

 /*
  *  Copyright (c) 2022 Mohd Noor Aman
+ *  Copyright (c) 2024 Ning Yang
  *
  *  The license and distribution terms for this file may be
  *  found in the file LICENSE in this distribution or at
@@ -44,6 +45,7 @@

 #define BCM2711_REG(x)   (*(volatile uint64_t *)(x))
 #define BCM2711_BIT(n)   (1 << (n))
+#define BCM2835_REG(addr)(*(volatile uint32_t*)(addr))

 /** @} */

@@ -198,6 +200,13 @@
 #define BCM2711_GPU_TIMER_C2 (BCM2711_GPU_TIMER_BASE + 0x14)
 #define BCM2711_GPU_TIMER_C3 (BCM2711_GPU_TIMER_BASE + 0x18)

+/**
+ * NOTE: compatible with the BCM2835 system timer
+ */
+#define BCM2835_GPU_TIMER_CS_M3  BCM2711_GPU_TIMER_CS_M3
+#define BCM2835_GPU_TIMER_C3 BCM2711_GPU_TIMER_C3
+#define BCM2835_GPU_TIMER_CLOBCM2711_GPU_TIMER_CLO
+#define BCM2835_GPU_TIMER_CS BCM2711_GPU_TIMER_CS
 /** @} */

 /**
diff --git a/spec/build/bsps/aarch64/grp.yml b/spec/build/bsps/aarch64/grp.yml
index 9428fb9435..8f40a9952e 100644
--- a/spec/build/bsps/aarch64/grp.yml
+++ b/spec/build/bsps/aarch64/grp.yml
@@ -12,9 +12,6 @@ install:
   source:
   - bsps/aarch64/include/bsp/linker-symbols.h
   - bsps/aarch64/include/bsp/start.h
-- destination: ${BSP_INCLUDEDIR}/dev/clock
-  source:
-  - bsps/include/dev/clock/arm-generic-timer.h
 - destination: ${BSP_INCLUDEDIR}/dev/irq
   source:
   - bsps/aarch64/include/dev/irq/arm-gic-arch.h
diff --git a/spec/build/bsps/aarch64/raspberrypi/bspraspberrypi4.yml 
b/spec/build/bsps/aarch64/raspberrypi/bspraspberrypi4.yml
index a579c094ba..7b6511a8cc 100644
--- a/spec/build/bsps/aarch64/raspberrypi/bspraspberrypi4.yml
+++ b/spec/build/bsps/aarch64/raspberrypi/bspraspberrypi4.yml
@@ -19,6 +19,10 @@ install:
   - bsps/aarch64/raspberrypi/include/bsp/irq.h
   - bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
 links:
+- role: build-dependency
+  uid: objclock
+- role: build-dependency
+  uid: objsystemtimer
 - role: build-dependency
   uid: ../grp
 - role: build-dependency
@@ -50,10 +54,8 @@ source:
 - bsps/aarch64/raspberrypi/start/bspstart.c
 - bsps/aarch64/raspberrypi/start/bspstarthooks.c
 - bsps/aarch64/raspberrypi/start/bspstartmmu.c
-- bsps/aarch64/shared/clock/arm-generic-timer-aarch64.c
 - bsps/aarch64/shared/cache/cache.c
 - 

[PATCH] bsps/arm: Improve GICv3 support

[Sebastian Huber]

In addtion to 1023, the GICC_IAR register may return 1022 as a special value.
Simply check for a valid interrupt vector for the dispatching.

Check the GICC_IAR again after the dispatch to quickly process a next interrupt
without having to go through the interrupt prologue and epiloge.
---
 bsps/shared/dev/irq/arm-gicv3.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/bsps/shared/dev/irq/arm-gicv3.c b/bsps/shared/dev/irq/arm-gicv3.c
index 88ac3c8293..dcfada6cd0 100644
--- a/bsps/shared/dev/irq/arm-gicv3.c
+++ b/bsps/shared/dev/irq/arm-gicv3.c
@@ -42,12 +42,18 @@
 
 void bsp_interrupt_dispatch(void)
 {
-  uint32_t icciar = READ_SR(ICC_IAR1);
-  rtems_vector_number vector = GIC_CPUIF_ICCIAR_ACKINTID_GET(icciar);
-  rtems_vector_number spurious = 1023;
+  while (true) {
+uint32_t icciar = READ_SR(ICC_IAR1);
+rtems_vector_number vector = GIC_CPUIF_ICCIAR_ACKINTID_GET(icciar);
+uint32_t status;
 
-  if (vector != spurious) {
-arm_interrupt_handler_dispatch(vector);
+if (!bsp_interrupt_is_valid_vector(vector)) {
+  break;
+}
+
+status = arm_interrupt_enable_interrupts();
+bsp_interrupt_handler_dispatch_unchecked(vector);
+arm_interrupt_restore_interrupts(status);
 
 WRITE_SR(ICC_EOIR1, icciar);
   }
-- 
2.35.3

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

[PATCH] bsps/arm/beagle: bugfix clearing gpio bit

[Jens Gollasch]

Hi,

it seems there is a bug in rtems_gpio_bsp_clear; mmio_set reads back the 
GPIO_DATAOUT register, so other active gpios are cleared too.

To clear a bit its necessary to use mmio_write.

---
 bsps/arm/beagle/gpio/bbb-gpio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bsps/arm/beagle/gpio/bbb-gpio.c 
b/bsps/arm/beagle/gpio/bbb-gpio.c

index bd081fae5a..06f7275301 100644
--- a/bsps/arm/beagle/gpio/bbb-gpio.c
+++ b/bsps/arm/beagle/gpio/bbb-gpio.c
@@ -96,7 +96,7 @@ rtems_status_code rtems_gpio_bsp_set(uint32_t bank, 
uint32_t pin)


 rtems_status_code rtems_gpio_bsp_clear(uint32_t bank, uint32_t pin)
 {
-  mmio_set(bbb_reg(bank, AM335X_GPIO_CLEARDATAOUT), BIT(pin));
+  mmio_write(bbb_reg(bank, AM335X_GPIO_CLEARDATAOUT), BIT(pin));

   return RTEMS_SUCCESSFUL;
 }

--
Jens Gollasch
Licht-, Steuer- und Schaltanlagenbau GmbH
NL Dresden
Warnemünder Straße 1, 01109 Dresden
Tel.: 0351/79565691
mail: jens.golla...@lss-lighting.de
www.lss-lighting.de

---
LSS Licht-, Steuer- und Schaltanlagenbau GmbH
Gesellschaft mit beschränkter Haftung
Sitz der Gesellschaft: Am Eichenberg 1, 04600 Altenburg
Registergericht: AmtsgerichtJena, HRB 206496
Geschäftsführer: Markus Kaminski
Steuer-Nummer: 161/113/04371; Finanzamt Altenburg
USt-ID: DE 150 516 887
---

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

[PATCH] bsp/qoriq: Include missing processormaskimpl.h

[Vincenzo Calabretta]

---
 bsps/powerpc/qoriq/irq/irq.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bsps/powerpc/qoriq/irq/irq.c b/bsps/powerpc/qoriq/irq/irq.c
index 2a5e3e9a75..96fbe4e020 100644
--- a/bsps/powerpc/qoriq/irq/irq.c
+++ b/bsps/powerpc/qoriq/irq/irq.c
@@ -47,6 +47,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef RTEMS_SMP
 #include 
-- 
2.35.3

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

Re: [PATCH v2] rtems: Add get/set interrupt priorities

[Sebastian Huber]

On 09.04.24 16:28, Sebastian Huber wrote:

Add directives to get and set the priority of an interrupt vector.

Implement the directives for the following BSP families:

* arm/lpc24xx
* arm/lpc32xx
* powerpc/mpc55xxevb
* powerpc/qoriq

Implement the directives for the following interrupt controllers:

* GICv2 and GICv3 (arm and aarch64)
* NVIC (arm)
* PLIC (riscv)

Update #5002.


Any comments to this API extension?

--
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: [RSB PATCH] 6/rtems-gcc: Revert to the gcc-13 release branch for MacOS fixes

[Joel Sherrill]

This is ok to push.

Unfortunate but this is the reality. A GCC 14 release is still future tense.

On Sat, Apr 13, 2024, 8:49 PM  wrote:

> From: Chris Johns 
>
> Change back to gcc-13 branch and a git version as gcc-13.2 does
> not build on MacOS 14.4. The fixes are on the gcc-13 release branch.
> ---
>  rtems/config/6/rtems-default.bset   | 2 +-
>  rtems/config/tools/rtems-gcc-13-newlib-head.cfg | 6 +++---
>  2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/rtems/config/6/rtems-default.bset
> b/rtems/config/6/rtems-default.bset
> index 2d7a223..2d51c50 100644
> --- a/rtems/config/6/rtems-default.bset
> +++ b/rtems/config/6/rtems-default.bset
> @@ -14,7 +14,7 @@
>  %defineifnot with_rtems_gmp  devel/gmp-6.3.0
>  %defineifnot with_rtems_gdb  tools/rtems-gdb-13.2
>  %defineifnot with_rtems_binutils tools/rtems-binutils-2.41
> -%defineifnot with_rtems_gcc  tools/rtems-gcc-13.2-newlib-head
> +%defineifnot with_rtems_gcc  tools/rtems-gcc-13-newlib-head
>  %defineifnot with_rtems_toolstools/rtems-tools-6
>
>  tools/rtems-default-tools.bset
> diff --git a/rtems/config/tools/rtems-gcc-13-newlib-head.cfg
> b/rtems/config/tools/rtems-gcc-13-newlib-head.cfg
> index c73d5a6..4dbbd9b 100644
> --- a/rtems/config/tools/rtems-gcc-13-newlib-head.cfg
> +++ b/rtems/config/tools/rtems-gcc-13-newlib-head.cfg
> @@ -1,12 +1,12 @@
>  %include %{_configdir}/checks.cfg
>  %include %{_configdir}/base.cfg
>
> -%define gcc_version 8c04837
> +%define gcc_version 54a235e
>  %define gcc_external 1
>  %define gcc_expand_name gnu-mirror-gcc-%{gcc_version}
>  %source set gcc --rsb-file=%{gcc_expand_name}.tar.gz
> https://codeload.github.com/RTEMS/gnu-mirror-gcc/tar.gz/%{gcc_version}
>  %hash sha512 %{gcc_expand_name}.tar.gz \
> -
> YSkX/JY61N+I4CPkJInUNGzwhb+uv+YNs9qcTxxJhg/HpGD5vI9duEPNw++F3y8J4re87DPJGIzV5DsFUBCJnA==
> +
> UAXjyfPP883wjLDnobDk4wmg/vAO0I4LjzzurLCKejj0FUSk0KvlkVj1CF+3XwFcdlCWRhN7z/Ls4fOunafe9w==
>
>  %define newlib_version 176b19f
>  %define newlib_external 1
> @@ -19,4 +19,4 @@
>  %define with_plugin 0
>  %define with_iconv 1
>
> -%include %{_configdir}/gcc-12.cfg
> +%include %{_configdir}/gcc-13.cfg
> --
> 2.39.3 (Apple Git-146)
>
> ___
> 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: Certificate of the documentation page expired yesterday

[Chris Johns]

Thanks, it should be fixed.

Chris

On 13/4/2024 12:41 am, Heinz Junkes wrote:
> Common Name (CN)
> docs.rtems.org
> Organisation (O)
> 
> Organisational Unit (OU)
> 
> Issued By
> Common Name (CN)
> R3
> Organisation (O)
> Let's Encrypt
> Organisational Unit (OU)
> 
> Validity Period
> Issued On
> Friday, 12 January 2024 at 20:02:57
> Expires On
> Thursday, 11 April 2024 at 21:02:56
> SHA-256 Fingerprints
> Certificate
> 9f6e41915a88f37a44627f92e459202504780eeab66109bfb4af1aa0f808ccc7
> Public key
> 8f203f1219335bee3b05d2a42e0e670e551cf7f69159463415a099580d8305fb
> 
> Heinz
> 
> 
> ___
> 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

[RSB PATCH] 6/rtems-gcc: Revert to the gcc-13 release branch for MacOS fixes

[chrisj]

From: Chris Johns 

Change back to gcc-13 branch and a git version as gcc-13.2 does
not build on MacOS 14.4. The fixes are on the gcc-13 release branch.
---
 rtems/config/6/rtems-default.bset   | 2 +-
 rtems/config/tools/rtems-gcc-13-newlib-head.cfg | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/rtems/config/6/rtems-default.bset 
b/rtems/config/6/rtems-default.bset
index 2d7a223..2d51c50 100644
--- a/rtems/config/6/rtems-default.bset
+++ b/rtems/config/6/rtems-default.bset
@@ -14,7 +14,7 @@
 %defineifnot with_rtems_gmp  devel/gmp-6.3.0
 %defineifnot with_rtems_gdb  tools/rtems-gdb-13.2
 %defineifnot with_rtems_binutils tools/rtems-binutils-2.41
-%defineifnot with_rtems_gcc  tools/rtems-gcc-13.2-newlib-head
+%defineifnot with_rtems_gcc  tools/rtems-gcc-13-newlib-head
 %defineifnot with_rtems_toolstools/rtems-tools-6
 
 tools/rtems-default-tools.bset
diff --git a/rtems/config/tools/rtems-gcc-13-newlib-head.cfg 
b/rtems/config/tools/rtems-gcc-13-newlib-head.cfg
index c73d5a6..4dbbd9b 100644
--- a/rtems/config/tools/rtems-gcc-13-newlib-head.cfg
+++ b/rtems/config/tools/rtems-gcc-13-newlib-head.cfg
@@ -1,12 +1,12 @@
 %include %{_configdir}/checks.cfg
 %include %{_configdir}/base.cfg
 
-%define gcc_version 8c04837
+%define gcc_version 54a235e
 %define gcc_external 1
 %define gcc_expand_name gnu-mirror-gcc-%{gcc_version}
 %source set gcc --rsb-file=%{gcc_expand_name}.tar.gz 
https://codeload.github.com/RTEMS/gnu-mirror-gcc/tar.gz/%{gcc_version}
 %hash sha512 %{gcc_expand_name}.tar.gz \
-  
YSkX/JY61N+I4CPkJInUNGzwhb+uv+YNs9qcTxxJhg/HpGD5vI9duEPNw++F3y8J4re87DPJGIzV5DsFUBCJnA==
+  
UAXjyfPP883wjLDnobDk4wmg/vAO0I4LjzzurLCKejj0FUSk0KvlkVj1CF+3XwFcdlCWRhN7z/Ls4fOunafe9w==
 
 %define newlib_version 176b19f
 %define newlib_external 1
@@ -19,4 +19,4 @@
 %define with_plugin 0
 %define with_iconv 1
 
-%include %{_configdir}/gcc-12.cfg
+%include %{_configdir}/gcc-13.cfg
-- 
2.39.3 (Apple Git-146)

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

[PATCH] bsps/aarch64/raspberrypi: Add system timer support

[Ning Yang]

The clock from the ARM timer is derived from the system clock. This clock can 
change dynamically e.g. if the system goes into reduced power or in low power 
mode. Thus the clock speed adapts to the overall system performance 
capabilities. For accurate timing it is recommended to use the system timers.

if BSP_CLOCK_USE_SYSTEMTIMER = 1, use the System Timer, otherwise use the ARM 
Timer.
---
 bsps/aarch64/raspberrypi/include/bsp/irq.h| 14 ++---
 .../raspberrypi/include/bsp/raspberrypi.h |  9 ++
 spec/build/bsps/aarch64/grp.yml   |  3 --
 .../aarch64/raspberrypi/bspraspberrypi4.yml   |  6 ++--
 .../bsps/aarch64/raspberrypi/objclock.yml | 31 +++
 .../aarch64/raspberrypi/objsystemtimer.yml| 23 ++
 .../aarch64/raspberrypi/optsystemtimer.yml| 24 ++
 7 files changed, 100 insertions(+), 10 deletions(-)
 create mode 100644 spec/build/bsps/aarch64/raspberrypi/objclock.yml
 create mode 100644 spec/build/bsps/aarch64/raspberrypi/objsystemtimer.yml
 create mode 100644 spec/build/bsps/aarch64/raspberrypi/optsystemtimer.yml

diff --git a/bsps/aarch64/raspberrypi/include/bsp/irq.h 
b/bsps/aarch64/raspberrypi/include/bsp/irq.h
index 1ff6ae80de..d493e83707 100644
--- a/bsps/aarch64/raspberrypi/include/bsp/irq.h
+++ b/bsps/aarch64/raspberrypi/include/bsp/irq.h
@@ -9,6 +9,7 @@
 /**
  * Copyright (c) 2013 Alan Cudmore
  * Copyright (c) 2022 Mohd Noor Aman
+ * Copyright (c) 2024 Ning Yang
  *
  *  The license and distribution terms for this file may be
  *  found in the file LICENSE in this distribution or at
@@ -33,15 +34,18 @@
  * @brief Interrupt support.
  */
 
-#define BCM2835_INTC_TOTAL_IRQ   (64 + 8)
+#define BCM2835_INTC_TOTAL_IRQ   216
 
 #define BCM2835_IRQ_SET1_MIN 0
 #define BCM2835_IRQ_SET2_MIN 32
 
-#define BCM2835_IRQ_ID_GPU_TIMER_M0  0
-#define BCM2835_IRQ_ID_GPU_TIMER_M1  1
-#define BCM2835_IRQ_ID_GPU_TIMER_M2  2
-#define BCM2835_IRQ_ID_GPU_TIMER_M3  3
+#define BCM2711_IRQ_VC_PERIPHERAL_BASE 96
+
+/* Interrupt Vectors: System Timer */
+#define BCM2835_IRQ_ID_GPU_TIMER_M0(BCM2711_IRQ_VC_PERIPHERAL_BASE + 0)
+#define BCM2835_IRQ_ID_GPU_TIMER_M1(BCM2711_IRQ_VC_PERIPHERAL_BASE + 1)
+#define BCM2835_IRQ_ID_GPU_TIMER_M2(BCM2711_IRQ_VC_PERIPHERAL_BASE + 2)
+#define BCM2835_IRQ_ID_GPU_TIMER_M3(BCM2711_IRQ_VC_PERIPHERAL_BASE + 3)
 
 #define BCM2835_IRQ_ID_USB   9
 #define BCM2835_IRQ_ID_AUX   29
diff --git a/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h 
b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
index 55dd9ed1e9..f185d1df57 100644
--- a/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
+++ b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
@@ -8,6 +8,7 @@
 
 /*
  *  Copyright (c) 2022 Mohd Noor Aman
+ *  Copyright (c) 2024 Ning Yang
  *
  *  The license and distribution terms for this file may be
  *  found in the file LICENSE in this distribution or at
@@ -44,6 +45,7 @@
 
 #define BCM2711_REG(x)   (*(volatile uint64_t *)(x))
 #define BCM2711_BIT(n)   (1 << (n))
+#define BCM2835_REG(addr)(*(volatile uint32_t*)(addr))
 
 /** @} */
 
@@ -198,6 +200,13 @@
 #define BCM2711_GPU_TIMER_C2 (BCM2711_GPU_TIMER_BASE + 0x14)
 #define BCM2711_GPU_TIMER_C3 (BCM2711_GPU_TIMER_BASE + 0x18)
 
+/**
+ * NOTE: compatible with the BCM2835 system timer
+ */
+#define BCM2835_GPU_TIMER_CS_M3  BCM2711_GPU_TIMER_CS_M3
+#define BCM2835_GPU_TIMER_C3 BCM2711_GPU_TIMER_C3
+#define BCM2835_GPU_TIMER_CLOBCM2711_GPU_TIMER_CLO
+#define BCM2835_GPU_TIMER_CS BCM2711_GPU_TIMER_CS
 /** @} */
 
 /**
diff --git a/spec/build/bsps/aarch64/grp.yml b/spec/build/bsps/aarch64/grp.yml
index 9428fb9435..8f40a9952e 100644
--- a/spec/build/bsps/aarch64/grp.yml
+++ b/spec/build/bsps/aarch64/grp.yml
@@ -12,9 +12,6 @@ install:
   source:
   - bsps/aarch64/include/bsp/linker-symbols.h
   - bsps/aarch64/include/bsp/start.h
-- destination: ${BSP_INCLUDEDIR}/dev/clock
-  source:
-  - bsps/include/dev/clock/arm-generic-timer.h
 - destination: ${BSP_INCLUDEDIR}/dev/irq
   source:
   - bsps/aarch64/include/dev/irq/arm-gic-arch.h
diff --git a/spec/build/bsps/aarch64/raspberrypi/bspraspberrypi4.yml 
b/spec/build/bsps/aarch64/raspberrypi/bspraspberrypi4.yml
index a579c094ba..7b6511a8cc 100644
--- a/spec/build/bsps/aarch64/raspberrypi/bspraspberrypi4.yml
+++ b/spec/build/bsps/aarch64/raspberrypi/bspraspberrypi4.yml
@@ -19,6 +19,10 @@ install:
   - bsps/aarch64/raspberrypi/include/bsp/irq.h
   - bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
 links:
+- role: build-dependency
+  uid: objclock
+- role: build-dependency
+  uid: objsystemtimer
 - role: build-dependency
   uid: ../grp
 - role: build-dependency
@@ -50,10 +54,8 @@ source:
 - bsps/aarch64/raspberrypi/start/bspstart.c
 - bsps/aarch64/raspberrypi/start/bspstarthooks.c
 - bsps/aarch64/raspberrypi/start/bspstartmmu.c
-- bsps/aarch64/shared/clock/arm-generic-timer-aarch64.c
 - 

Re: [PATCH] bsps/aarch64/raspberrypi: Add system timer support

[Sebastian Huber]

On 13.04.24 12:13, Ning Yang wrote:

diff --git a/bsps/aarch64/raspberrypi/include/bsp/irq.h 
b/bsps/aarch64/raspberrypi/include/bsp/irq.h
index 1ff6ae80de..f2dd2f6c14 100644
--- a/bsps/aarch64/raspberrypi/include/bsp/irq.h
+++ b/bsps/aarch64/raspberrypi/include/bsp/irq.h
@@ -9,6 +9,7 @@
  /**
   * Copyright (c) 2013 Alan Cudmore
   * Copyright (c) 2022 Mohd Noor Aman
+ * Copyright (c) 2024 Ning Yang
   *
   *  The license and distribution terms for this file may be
   *  found in the file LICENSE in this distribution or at
@@ -24,6 +25,7 @@
  
  #include 

  #include 
+#include 


This is a legacy API, please don't include this header.

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

[PATCH] bsps/aarch64/raspberrypi: Add system timer support

[Ning Yang]

The clock from the ARM timer is derived from the system clock. This clock can 
change dynamically e.g. if the system goes into reduced power or in low power 
mode. Thus the clock speed adapts to the overall system performance 
capabilities. For accurate timing it is recommended to use the system timers.

if BSP_CLOCK_USE_SYSTEMTIMER = 1, use the System Timer, otherwise use the ARM 
Timer.
---
 bsps/aarch64/raspberrypi/include/bsp/irq.h| 15 ++---
 .../raspberrypi/include/bsp/raspberrypi.h |  9 ++
 spec/build/bsps/aarch64/grp.yml   |  3 --
 .../aarch64/raspberrypi/bspraspberrypi4.yml   |  6 ++--
 .../bsps/aarch64/raspberrypi/objclock.yml | 31 +++
 .../aarch64/raspberrypi/objsystemtimer.yml| 23 ++
 .../aarch64/raspberrypi/optsystemtimer.yml| 24 ++
 7 files changed, 101 insertions(+), 10 deletions(-)
 create mode 100644 spec/build/bsps/aarch64/raspberrypi/objclock.yml
 create mode 100644 spec/build/bsps/aarch64/raspberrypi/objsystemtimer.yml
 create mode 100644 spec/build/bsps/aarch64/raspberrypi/optsystemtimer.yml

diff --git a/bsps/aarch64/raspberrypi/include/bsp/irq.h 
b/bsps/aarch64/raspberrypi/include/bsp/irq.h
index 1ff6ae80de..f2dd2f6c14 100644
--- a/bsps/aarch64/raspberrypi/include/bsp/irq.h
+++ b/bsps/aarch64/raspberrypi/include/bsp/irq.h
@@ -9,6 +9,7 @@
 /**
  * Copyright (c) 2013 Alan Cudmore
  * Copyright (c) 2022 Mohd Noor Aman
+ * Copyright (c) 2024 Ning Yang
  *
  *  The license and distribution terms for this file may be
  *  found in the file LICENSE in this distribution or at
@@ -24,6 +25,7 @@
 
 #include 
 #include 
+#include 
 
 /**
  * @defgroup raspberrypi_interrupt Interrrupt Support
@@ -33,15 +35,18 @@
  * @brief Interrupt support.
  */
 
-#define BCM2835_INTC_TOTAL_IRQ   (64 + 8)
+#define BCM2835_INTC_TOTAL_IRQ   216
 
 #define BCM2835_IRQ_SET1_MIN 0
 #define BCM2835_IRQ_SET2_MIN 32
 
-#define BCM2835_IRQ_ID_GPU_TIMER_M0  0
-#define BCM2835_IRQ_ID_GPU_TIMER_M1  1
-#define BCM2835_IRQ_ID_GPU_TIMER_M2  2
-#define BCM2835_IRQ_ID_GPU_TIMER_M3  3
+#define BCM2711_IRQ_VC_PERIPHERAL_BASE 96
+
+/* Interrupt Vectors: System Timer */
+#define BCM2835_IRQ_ID_GPU_TIMER_M0(BCM2711_IRQ_VC_PERIPHERAL_BASE + 0)
+#define BCM2835_IRQ_ID_GPU_TIMER_M1(BCM2711_IRQ_VC_PERIPHERAL_BASE + 1)
+#define BCM2835_IRQ_ID_GPU_TIMER_M2(BCM2711_IRQ_VC_PERIPHERAL_BASE + 2)
+#define BCM2835_IRQ_ID_GPU_TIMER_M3(BCM2711_IRQ_VC_PERIPHERAL_BASE + 3)
 
 #define BCM2835_IRQ_ID_USB   9
 #define BCM2835_IRQ_ID_AUX   29
diff --git a/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h 
b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
index 55dd9ed1e9..f185d1df57 100644
--- a/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
+++ b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
@@ -8,6 +8,7 @@
 
 /*
  *  Copyright (c) 2022 Mohd Noor Aman
+ *  Copyright (c) 2024 Ning Yang
  *
  *  The license and distribution terms for this file may be
  *  found in the file LICENSE in this distribution or at
@@ -44,6 +45,7 @@
 
 #define BCM2711_REG(x)   (*(volatile uint64_t *)(x))
 #define BCM2711_BIT(n)   (1 << (n))
+#define BCM2835_REG(addr)(*(volatile uint32_t*)(addr))
 
 /** @} */
 
@@ -198,6 +200,13 @@
 #define BCM2711_GPU_TIMER_C2 (BCM2711_GPU_TIMER_BASE + 0x14)
 #define BCM2711_GPU_TIMER_C3 (BCM2711_GPU_TIMER_BASE + 0x18)
 
+/**
+ * NOTE: compatible with the BCM2835 system timer
+ */
+#define BCM2835_GPU_TIMER_CS_M3  BCM2711_GPU_TIMER_CS_M3
+#define BCM2835_GPU_TIMER_C3 BCM2711_GPU_TIMER_C3
+#define BCM2835_GPU_TIMER_CLOBCM2711_GPU_TIMER_CLO
+#define BCM2835_GPU_TIMER_CS BCM2711_GPU_TIMER_CS
 /** @} */
 
 /**
diff --git a/spec/build/bsps/aarch64/grp.yml b/spec/build/bsps/aarch64/grp.yml
index 9428fb9435..8f40a9952e 100644
--- a/spec/build/bsps/aarch64/grp.yml
+++ b/spec/build/bsps/aarch64/grp.yml
@@ -12,9 +12,6 @@ install:
   source:
   - bsps/aarch64/include/bsp/linker-symbols.h
   - bsps/aarch64/include/bsp/start.h
-- destination: ${BSP_INCLUDEDIR}/dev/clock
-  source:
-  - bsps/include/dev/clock/arm-generic-timer.h
 - destination: ${BSP_INCLUDEDIR}/dev/irq
   source:
   - bsps/aarch64/include/dev/irq/arm-gic-arch.h
diff --git a/spec/build/bsps/aarch64/raspberrypi/bspraspberrypi4.yml 
b/spec/build/bsps/aarch64/raspberrypi/bspraspberrypi4.yml
index a579c094ba..7b6511a8cc 100644
--- a/spec/build/bsps/aarch64/raspberrypi/bspraspberrypi4.yml
+++ b/spec/build/bsps/aarch64/raspberrypi/bspraspberrypi4.yml
@@ -19,6 +19,10 @@ install:
   - bsps/aarch64/raspberrypi/include/bsp/irq.h
   - bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
 links:
+- role: build-dependency
+  uid: objclock
+- role: build-dependency
+  uid: objsystemtimer
 - role: build-dependency
   uid: ../grp
 - role: build-dependency
@@ -50,10 +54,8 @@ source:
 - bsps/aarch64/raspberrypi/start/bspstart.c
 - bsps/aarch64/raspberrypi/start/bspstarthooks.c
 - 

Re: [PATCH] bsps/aarch64/raspberrypi: Add system timer support

[Kinsey Moore]

A couple of comments inline below.

On Fri, Apr 12, 2024 at 9:33 AM Ning Yang  wrote:

> The clock from the ARM timer is derived from the system clock. This clock
> can change dynamically e.g. if the system goes into reduced power or in low
> power mode. Thus the clock speed adapts to the overall system performance
> capabilities. For accurate timing it is recommended to use the system
> timers.
>
> if BSP_CLOCK_USE_SYSTEMTIMER = 1, use the System Timer, otherwise use the
> ARM Timer.
> ---
>  bsps/aarch64/raspberrypi/include/bsp/irq.h| 15 ++---
>  .../raspberrypi/include/bsp/raspberrypi.h | 28 +
>  spec/build/bsps/aarch64/grp.yml   |  3 --
>  .../aarch64/raspberrypi/bspraspberrypi4.yml   |  7 +++--
>  .../bsps/aarch64/raspberrypi/objclock.yml | 31 +++
>  .../aarch64/raspberrypi/objsystemtimer.yml| 23 ++
>  .../aarch64/raspberrypi/optsystemtimer.yml| 24 ++
>  7 files changed, 107 insertions(+), 24 deletions(-)
>  create mode 100644 spec/build/bsps/aarch64/raspberrypi/objclock.yml
>  create mode 100644 spec/build/bsps/aarch64/raspberrypi/objsystemtimer.yml
>  create mode 100644 spec/build/bsps/aarch64/raspberrypi/optsystemtimer.yml
>
> diff --git a/bsps/aarch64/raspberrypi/include/bsp/irq.h
> b/bsps/aarch64/raspberrypi/include/bsp/irq.h
> index 1ff6ae80de..f2dd2f6c14 100644
> --- a/bsps/aarch64/raspberrypi/include/bsp/irq.h
> +++ b/bsps/aarch64/raspberrypi/include/bsp/irq.h
> @@ -9,6 +9,7 @@
>  /**
>   * Copyright (c) 2013 Alan Cudmore
>   * Copyright (c) 2022 Mohd Noor Aman
> + * Copyright (c) 2024 Ning Yang
>   *
>   *  The license and distribution terms for this file may be
>   *  found in the file LICENSE in this distribution or at
> @@ -24,6 +25,7 @@
>
>  #include 
>  #include 
> +#include 
>
>  /**
>   * @defgroup raspberrypi_interrupt Interrrupt Support
> @@ -33,15 +35,18 @@
>   * @brief Interrupt support.
>   */
>
> -#define BCM2835_INTC_TOTAL_IRQ   (64 + 8)
> +#define BCM2835_INTC_TOTAL_IRQ   216
>
>  #define BCM2835_IRQ_SET1_MIN 0
>  #define BCM2835_IRQ_SET2_MIN 32
>
> -#define BCM2835_IRQ_ID_GPU_TIMER_M0  0
> -#define BCM2835_IRQ_ID_GPU_TIMER_M1  1
> -#define BCM2835_IRQ_ID_GPU_TIMER_M2  2
> -#define BCM2835_IRQ_ID_GPU_TIMER_M3  3
> +#define BCM2711_IRQ_VC_PERIPHERAL_BASE 96
> +
> +/* Interrupt Vectors: System Timer */
> +#define BCM2835_IRQ_ID_GPU_TIMER_M0(BCM2711_IRQ_VC_PERIPHERAL_BASE +
> 0)
> +#define BCM2835_IRQ_ID_GPU_TIMER_M1(BCM2711_IRQ_VC_PERIPHERAL_BASE +
> 1)
> +#define BCM2835_IRQ_ID_GPU_TIMER_M2(BCM2711_IRQ_VC_PERIPHERAL_BASE +
> 2)
> +#define BCM2835_IRQ_ID_GPU_TIMER_M3(BCM2711_IRQ_VC_PERIPHERAL_BASE +
> 3)
>
>  #define BCM2835_IRQ_ID_USB   9
>  #define BCM2835_IRQ_ID_AUX   29
> diff --git a/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
> b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
> index 55dd9ed1e9..3d6a03c715 100644
> --- a/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
> +++ b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
> @@ -8,6 +8,7 @@
>
>  /*
>   *  Copyright (c) 2022 Mohd Noor Aman
> + *  Copyright (c) 2024 Ning Yang
>   *
>   *  The license and distribution terms for this file may be
>   *  found in the file LICENSE in this distribution or at
> @@ -44,6 +45,7 @@
>
>  #define BCM2711_REG(x)   (*(volatile uint64_t *)(x))
>  #define BCM2711_BIT(n)   (1 << (n))
> +#define BCM2835_REG(addr)(*(volatile uint32_t*)(addr))
>
>  /** @} */
>
> @@ -184,19 +186,19 @@
>   *   it's own RTOS. 1 and 3 are available for use in
>   *   RTEMS.
>   */
> -#define BCM2711_GPU_TIMER_BASE   (RPI_PERIPHERAL_BASE + 0x3000)
> -
> -#define BCM2711_GPU_TIMER_CS (BCM2711_GPU_TIMER_BASE + 0x00)
> -#define BCM2711_GPU_TIMER_CS_M0  0x0001
> -#define BCM2711_GPU_TIMER_CS_M1  0x0002
> -#define BCM2711_GPU_TIMER_CS_M2  0x0004
> -#define BCM2711_GPU_TIMER_CS_M3  0x0008
> -#define BCM2711_GPU_TIMER_CLO(BCM2711_GPU_TIMER_BASE + 0x04)
> -#define BCM2711_GPU_TIMER_CHI(BCM2711_GPU_TIMER_BASE + 0x08)
> -#define BCM2711_GPU_TIMER_C0 (BCM2711_GPU_TIMER_BASE + 0x0C)
> -#define BCM2711_GPU_TIMER_C1 (BCM2711_GPU_TIMER_BASE + 0x10)
> -#define BCM2711_GPU_TIMER_C2 (BCM2711_GPU_TIMER_BASE + 0x14)
> -#define BCM2711_GPU_TIMER_C3 (BCM2711_GPU_TIMER_BASE + 0x18)
> +#define BCM2835_GPU_TIMER_BASE   (RPI_PERIPHERAL_BASE + 0x3000)
> +
> +#define BCM2835_GPU_TIMER_CS (BCM2835_GPU_TIMER_BASE + 0x00)
> +#define BCM2835_GPU_TIMER_CS_M0  0x0001
> +#define BCM2835_GPU_TIMER_CS_M1  0x0002
> +#define BCM2835_GPU_TIMER_CS_M2  0x0004
> +#define BCM2835_GPU_TIMER_CS_M3  0x0008
> +#define BCM2835_GPU_TIMER_CLO(BCM2835_GPU_TIMER_BASE + 0x04)
> +#define BCM2835_GPU_TIMER_CHI(BCM2835_GPU_TIMER_BASE + 0x08)
> +#define BCM2835_GPU_TIMER_C0 (BCM2835_GPU_TIMER_BASE + 0x0C)
> +#define 

Certificate of the documentation page expired yesterday

[Heinz Junkes]

Common Name (CN)
docs.rtems.org
Organisation (O)

Organisational Unit (OU)

Issued By
Common Name (CN)
R3
Organisation (O)
Let's Encrypt
Organisational Unit (OU)

Validity Period
Issued On
Friday, 12 January 2024 at 20:02:57
Expires On
Thursday, 11 April 2024 at 21:02:56
SHA-256 Fingerprints
Certificate
9f6e41915a88f37a44627f92e459202504780eeab66109bfb4af1aa0f808ccc7
Public key
8f203f1219335bee3b05d2a42e0e670e551cf7f69159463415a099580d8305fb

Heinz


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

[PATCH] bsps/aarch64/raspberrypi: Add system timer support

[Ning Yang]

The clock from the ARM timer is derived from the system clock. This clock can 
change dynamically e.g. if the system goes into reduced power or in low power 
mode. Thus the clock speed adapts to the overall system performance 
capabilities. For accurate timing it is recommended to use the system timers.

if BSP_CLOCK_USE_SYSTEMTIMER = 1, use the System Timer, otherwise use the ARM 
Timer.
---
 bsps/aarch64/raspberrypi/include/bsp/irq.h| 15 ++---
 .../raspberrypi/include/bsp/raspberrypi.h | 28 +
 spec/build/bsps/aarch64/grp.yml   |  3 --
 .../aarch64/raspberrypi/bspraspberrypi4.yml   |  7 +++--
 .../bsps/aarch64/raspberrypi/objclock.yml | 31 +++
 .../aarch64/raspberrypi/objsystemtimer.yml| 23 ++
 .../aarch64/raspberrypi/optsystemtimer.yml| 24 ++
 7 files changed, 107 insertions(+), 24 deletions(-)
 create mode 100644 spec/build/bsps/aarch64/raspberrypi/objclock.yml
 create mode 100644 spec/build/bsps/aarch64/raspberrypi/objsystemtimer.yml
 create mode 100644 spec/build/bsps/aarch64/raspberrypi/optsystemtimer.yml

diff --git a/bsps/aarch64/raspberrypi/include/bsp/irq.h 
b/bsps/aarch64/raspberrypi/include/bsp/irq.h
index 1ff6ae80de..f2dd2f6c14 100644
--- a/bsps/aarch64/raspberrypi/include/bsp/irq.h
+++ b/bsps/aarch64/raspberrypi/include/bsp/irq.h
@@ -9,6 +9,7 @@
 /**
  * Copyright (c) 2013 Alan Cudmore
  * Copyright (c) 2022 Mohd Noor Aman
+ * Copyright (c) 2024 Ning Yang
  *
  *  The license and distribution terms for this file may be
  *  found in the file LICENSE in this distribution or at
@@ -24,6 +25,7 @@
 
 #include 
 #include 
+#include 
 
 /**
  * @defgroup raspberrypi_interrupt Interrrupt Support
@@ -33,15 +35,18 @@
  * @brief Interrupt support.
  */
 
-#define BCM2835_INTC_TOTAL_IRQ   (64 + 8)
+#define BCM2835_INTC_TOTAL_IRQ   216
 
 #define BCM2835_IRQ_SET1_MIN 0
 #define BCM2835_IRQ_SET2_MIN 32
 
-#define BCM2835_IRQ_ID_GPU_TIMER_M0  0
-#define BCM2835_IRQ_ID_GPU_TIMER_M1  1
-#define BCM2835_IRQ_ID_GPU_TIMER_M2  2
-#define BCM2835_IRQ_ID_GPU_TIMER_M3  3
+#define BCM2711_IRQ_VC_PERIPHERAL_BASE 96
+
+/* Interrupt Vectors: System Timer */
+#define BCM2835_IRQ_ID_GPU_TIMER_M0(BCM2711_IRQ_VC_PERIPHERAL_BASE + 0)
+#define BCM2835_IRQ_ID_GPU_TIMER_M1(BCM2711_IRQ_VC_PERIPHERAL_BASE + 1)
+#define BCM2835_IRQ_ID_GPU_TIMER_M2(BCM2711_IRQ_VC_PERIPHERAL_BASE + 2)
+#define BCM2835_IRQ_ID_GPU_TIMER_M3(BCM2711_IRQ_VC_PERIPHERAL_BASE + 3)
 
 #define BCM2835_IRQ_ID_USB   9
 #define BCM2835_IRQ_ID_AUX   29
diff --git a/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h 
b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
index 55dd9ed1e9..3d6a03c715 100644
--- a/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
+++ b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
@@ -8,6 +8,7 @@
 
 /*
  *  Copyright (c) 2022 Mohd Noor Aman
+ *  Copyright (c) 2024 Ning Yang
  *
  *  The license and distribution terms for this file may be
  *  found in the file LICENSE in this distribution or at
@@ -44,6 +45,7 @@
 
 #define BCM2711_REG(x)   (*(volatile uint64_t *)(x))
 #define BCM2711_BIT(n)   (1 << (n))
+#define BCM2835_REG(addr)(*(volatile uint32_t*)(addr))
 
 /** @} */
 
@@ -184,19 +186,19 @@
  *   it's own RTOS. 1 and 3 are available for use in
  *   RTEMS.
  */
-#define BCM2711_GPU_TIMER_BASE   (RPI_PERIPHERAL_BASE + 0x3000)
-
-#define BCM2711_GPU_TIMER_CS (BCM2711_GPU_TIMER_BASE + 0x00)
-#define BCM2711_GPU_TIMER_CS_M0  0x0001
-#define BCM2711_GPU_TIMER_CS_M1  0x0002
-#define BCM2711_GPU_TIMER_CS_M2  0x0004
-#define BCM2711_GPU_TIMER_CS_M3  0x0008
-#define BCM2711_GPU_TIMER_CLO(BCM2711_GPU_TIMER_BASE + 0x04)
-#define BCM2711_GPU_TIMER_CHI(BCM2711_GPU_TIMER_BASE + 0x08)
-#define BCM2711_GPU_TIMER_C0 (BCM2711_GPU_TIMER_BASE + 0x0C)
-#define BCM2711_GPU_TIMER_C1 (BCM2711_GPU_TIMER_BASE + 0x10)
-#define BCM2711_GPU_TIMER_C2 (BCM2711_GPU_TIMER_BASE + 0x14)
-#define BCM2711_GPU_TIMER_C3 (BCM2711_GPU_TIMER_BASE + 0x18)
+#define BCM2835_GPU_TIMER_BASE   (RPI_PERIPHERAL_BASE + 0x3000)
+
+#define BCM2835_GPU_TIMER_CS (BCM2835_GPU_TIMER_BASE + 0x00)
+#define BCM2835_GPU_TIMER_CS_M0  0x0001
+#define BCM2835_GPU_TIMER_CS_M1  0x0002
+#define BCM2835_GPU_TIMER_CS_M2  0x0004
+#define BCM2835_GPU_TIMER_CS_M3  0x0008
+#define BCM2835_GPU_TIMER_CLO(BCM2835_GPU_TIMER_BASE + 0x04)
+#define BCM2835_GPU_TIMER_CHI(BCM2835_GPU_TIMER_BASE + 0x08)
+#define BCM2835_GPU_TIMER_C0 (BCM2835_GPU_TIMER_BASE + 0x0C)
+#define BCM2835_GPU_TIMER_C1 (BCM2835_GPU_TIMER_BASE + 0x10)
+#define BCM2835_GPU_TIMER_C2 (BCM2835_GPU_TIMER_BASE + 0x14)
+#define BCM2835_GPU_TIMER_C3 (BCM2835_GPU_TIMER_BASE + 0x18)
 
 /** @} */
 
diff --git a/spec/build/bsps/aarch64/grp.yml b/spec/build/bsps/aarch64/grp.yml
index 

Re: [PATCH] bsps/aarch64/raspberrypi: Add system timer support

[Ning Yang]

Hi Mr. Kinsey Moore,

I will send the patch based on the current RTEMS master as soon as possible.

I am an applicant for GSOC2024 and will continue to improve RPi4 BSP the year. 
I'm currently working on debugging UART interrupt mode. Please let me know if 
there's anything I can do to help.

Best regards,

Ning

> 2024年4月12日 00:08，Kinsey Moore  写道：
> 
> Ah, that makes sense. If your patch depends on Utkarsh's work, then we'll 
> need to work on getting that into upstream RTEMS as well. If your patch can 
> be rebased on to current RTEMS master, that would be ideal.
> 
> Regarding Utkarsh's work not being merged into RTEMS, patches sometimes slip 
> through the cracks and fail to get the reviews they need to progress to a 
> point where they can be accepted into RTEMS. I'm actually working on Noor's 
> SMP patch for RPi4 (also one of last year's GSoC projects) right now to get 
> it into good condition for merging into RTEMS.
> 
> Kinsey
> 
> On Thu, Apr 11, 2024 at 10:59 AM Ning Yang  wrote:
> Hi Mr. Kinsey Moore:
> 
> I am using the RPi4 BSP (project of GSOC2023) written by Utkarsh Verma. For 
> some reason it wasn't merged.
> https://lists.rtems.org/pipermail/devel/2023-August/076152.html
> I got the code from his github: https://github.com/UtkarshVerma/rtems
> 
> Best regards,
> 
> Ning
> 
> > 2024年4月11日 23:22，Kinsey Moore  写道：
> > 
> > I couldn't get this patch to apply. Are you sure it came from the right 
> > branch and has no merge commits ahead of it?
> > 
> > Kinsey
> > 
> > On Wed, Apr 10, 2024 at 9:24 AM Ning Yang  wrote:
> > The clock from the ARM timer is derived from the system clock. This clock 
> > can change dynamically e.g. if the system goes into reduced power or in low 
> > power mode. Thus the clock speed adapts to the overall system performance 
> > capabilities. For accurate timing it is recommended to use the system 
> > timers.
> > 
> > if BSP_CLOCK_USE_SYSTEMTIMER = 1, use the System Timer, otherwise use the 
> > ARM Timer.
> > ---
> >  .../aarch64/raspberrypi/include/bsp/bcm2711.h | 28 
> >  .../raspberrypi/include/bsp/raspberrypi.h | 43 +++
> >  bsps/aarch64/raspberrypi/start/bspstartmmu.c  |  8 
> >  spec/build/bsps/aarch64/raspberrypi/bsp4b.yml |  1 +
> >  spec/build/bsps/aarch64/raspberrypi/obj.yml   |  3 ++
> >  .../bsps/aarch64/raspberrypi/objclock.yml |  4 +-
> >  .../aarch64/raspberrypi/objsystemtimer.yml| 22 ++
> >  .../aarch64/raspberrypi/optsystemtimer.yml| 24 +++
> >  8 files changed, 132 insertions(+), 1 deletion(-)
> >  create mode 100644 bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
> >  create mode 100644 spec/build/bsps/aarch64/raspberrypi/objsystemtimer.yml
> >  create mode 100644 spec/build/bsps/aarch64/raspberrypi/optsystemtimer.yml
> > 
> > diff --git a/bsps/aarch64/raspberrypi/include/bsp/bcm2711.h 
> > b/bsps/aarch64/raspberrypi/include/bsp/bcm2711.h
> > index e6c77fa025..8707582ebb 100644
> > --- a/bsps/aarch64/raspberrypi/include/bsp/bcm2711.h
> > +++ b/bsps/aarch64/raspberrypi/include/bsp/bcm2711.h
> > @@ -11,6 +11,7 @@
> >  /*
> >   * Copyright (C) 2022 Mohd Noor Aman
> >   * Copyright (C) 2023 Utkarsh Verma
> > + * Copyright (C) 2024 Ning Yang
> >   *
> >   *
> >   * Redistribution and use in source and binary forms, with or without
> > @@ -91,6 +92,27 @@
> >  #define BCM2711_UART5_BASE (BCM2711_PL011_BASE + 0xa00)
> >  #define BCM2711_UART5_SIZE BCM2711_PL011_DEVICE_SIZE
> > 
> > +/* System Timer */
> > +/**
> > + * NOTE: The GPU uses Compare registers 0 and 2 for
> > + *   it's own RTOS. 1 and 3 are available for use in
> > + *   RTEMS.
> > + */
> > +#define BCM2835_GPU_TIMER_BASE(BCM2711_PERIPHERAL_BASE + 0x200+ 
> > 0x3000)
> > +#define BCM2835_GPU_TIMER_SIZE0x1C
> > +
> > +#define BCM2835_GPU_TIMER_CS  (BCM2835_GPU_TIMER_BASE + 0x00)
> > +#define BCM2835_GPU_TIMER_CS_M0   0x0001
> > +#define BCM2835_GPU_TIMER_CS_M1   0x0002
> > +#define BCM2835_GPU_TIMER_CS_M2   0x0004
> > +#define BCM2835_GPU_TIMER_CS_M3   0x0008
> > +#define BCM2835_GPU_TIMER_CLO (BCM2835_GPU_TIMER_BASE + 0x04)
> > +#define BCM2835_GPU_TIMER_CHI (BCM2835_GPU_TIMER_BASE + 0x08)
> > +#define BCM2835_GPU_TIMER_C0  (BCM2835_GPU_TIMER_BASE + 0x0C)
> > +#define BCM2835_GPU_TIMER_C1  (BCM2835_GPU_TIMER_BASE + 0x10)
> > +#define BCM2835_GPU_TIMER_C2  (BCM2835_GPU_TIMER_BASE + 0x14)
> > +#define BCM2835_GPU_TIMER_C3  (BCM2835_GPU_TIMER_BASE + 0x18)
> > +
> >  /* ARM Local */
> >  #define BCM2711_ARM_LOCAL_BASE 0xff80LL
> >  #define BCM2711_ARM_LOCAL_SIZE 0x80
> > @@ -114,4 +136,10 @@
> >  #define BCM2711_IRQ_AUX(BCM2711_IRQ_VC_PERIPHERAL_BASE + 
> > 29)
> >  #define BCM2711_IRQ_PL011_UART (BCM2711_IRQ_VC_PERIPHERAL_BASE + 
> > 57)
> > 
> > +/* Interrupt Vectors: System Timer */
> > +#define BCM2835_IRQ_ID_GPU_TIMER_M0(BCM2711_IRQ_VC_PERIPHERAL_BASE + 0)
> > +#define BCM2835_IRQ_ID_GPU_TIMER_M1

Re: [PATCH] bsps/aarch64/raspberrypi: Add system timer support

[Kinsey Moore]

Ah, that makes sense. If your patch depends on Utkarsh's work, then we'll
need to work on getting that into upstream RTEMS as well. If your patch can
be rebased on to current RTEMS master, that would be ideal.

Regarding Utkarsh's work not being merged into RTEMS, patches sometimes
slip through the cracks and fail to get the reviews they need to progress
to a point where they can be accepted into RTEMS. I'm actually working on
Noor's SMP patch for RPi4 (also one of last year's GSoC projects) right now
to get it into good condition for merging into RTEMS.

Kinsey

On Thu, Apr 11, 2024 at 10:59 AM Ning Yang  wrote:

> Hi Mr. Kinsey Moore:
>
> I am using the RPi4 BSP (project of GSOC2023) written by Utkarsh Verma.
> For some reason it wasn't merged.
> https://lists.rtems.org/pipermail/devel/2023-August/076152.html
> I got the code from his github: https://github.com/UtkarshVerma/rtems
>
> Best regards,
>
> Ning
>
> > 2024年4月11日 23:22，Kinsey Moore  写道：
> >
> > I couldn't get this patch to apply. Are you sure it came from the right
> branch and has no merge commits ahead of it?
> >
> > Kinsey
> >
> > On Wed, Apr 10, 2024 at 9:24 AM Ning Yang  wrote:
> > The clock from the ARM timer is derived from the system clock. This
> clock can change dynamically e.g. if the system goes into reduced power or
> in low power mode. Thus the clock speed adapts to the overall system
> performance capabilities. For accurate timing it is recommended to use the
> system timers.
> >
> > if BSP_CLOCK_USE_SYSTEMTIMER = 1, use the System Timer, otherwise use
> the ARM Timer.
> > ---
> >  .../aarch64/raspberrypi/include/bsp/bcm2711.h | 28 
> >  .../raspberrypi/include/bsp/raspberrypi.h | 43 +++
> >  bsps/aarch64/raspberrypi/start/bspstartmmu.c  |  8 
> >  spec/build/bsps/aarch64/raspberrypi/bsp4b.yml |  1 +
> >  spec/build/bsps/aarch64/raspberrypi/obj.yml   |  3 ++
> >  .../bsps/aarch64/raspberrypi/objclock.yml |  4 +-
> >  .../aarch64/raspberrypi/objsystemtimer.yml| 22 ++
> >  .../aarch64/raspberrypi/optsystemtimer.yml| 24 +++
> >  8 files changed, 132 insertions(+), 1 deletion(-)
> >  create mode 100644 bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
> >  create mode 100644
> spec/build/bsps/aarch64/raspberrypi/objsystemtimer.yml
> >  create mode 100644
> spec/build/bsps/aarch64/raspberrypi/optsystemtimer.yml
> >
> > diff --git a/bsps/aarch64/raspberrypi/include/bsp/bcm2711.h
> b/bsps/aarch64/raspberrypi/include/bsp/bcm2711.h
> > index e6c77fa025..8707582ebb 100644
> > --- a/bsps/aarch64/raspberrypi/include/bsp/bcm2711.h
> > +++ b/bsps/aarch64/raspberrypi/include/bsp/bcm2711.h
> > @@ -11,6 +11,7 @@
> >  /*
> >   * Copyright (C) 2022 Mohd Noor Aman
> >   * Copyright (C) 2023 Utkarsh Verma
> > + * Copyright (C) 2024 Ning Yang
> >   *
> >   *
> >   * Redistribution and use in source and binary forms, with or without
> > @@ -91,6 +92,27 @@
> >  #define BCM2711_UART5_BASE (BCM2711_PL011_BASE + 0xa00)
> >  #define BCM2711_UART5_SIZE BCM2711_PL011_DEVICE_SIZE
> >
> > +/* System Timer */
> > +/**
> > + * NOTE: The GPU uses Compare registers 0 and 2 for
> > + *   it's own RTOS. 1 and 3 are available for use in
> > + *   RTEMS.
> > + */
> > +#define BCM2835_GPU_TIMER_BASE(BCM2711_PERIPHERAL_BASE + 0x200+
> 0x3000)
> > +#define BCM2835_GPU_TIMER_SIZE0x1C
> > +
> > +#define BCM2835_GPU_TIMER_CS  (BCM2835_GPU_TIMER_BASE + 0x00)
> > +#define BCM2835_GPU_TIMER_CS_M0   0x0001
> > +#define BCM2835_GPU_TIMER_CS_M1   0x0002
> > +#define BCM2835_GPU_TIMER_CS_M2   0x0004
> > +#define BCM2835_GPU_TIMER_CS_M3   0x0008
> > +#define BCM2835_GPU_TIMER_CLO (BCM2835_GPU_TIMER_BASE + 0x04)
> > +#define BCM2835_GPU_TIMER_CHI (BCM2835_GPU_TIMER_BASE + 0x08)
> > +#define BCM2835_GPU_TIMER_C0  (BCM2835_GPU_TIMER_BASE + 0x0C)
> > +#define BCM2835_GPU_TIMER_C1  (BCM2835_GPU_TIMER_BASE + 0x10)
> > +#define BCM2835_GPU_TIMER_C2  (BCM2835_GPU_TIMER_BASE + 0x14)
> > +#define BCM2835_GPU_TIMER_C3  (BCM2835_GPU_TIMER_BASE + 0x18)
> > +
> >  /* ARM Local */
> >  #define BCM2711_ARM_LOCAL_BASE 0xff80LL
> >  #define BCM2711_ARM_LOCAL_SIZE 0x80
> > @@ -114,4 +136,10 @@
> >  #define BCM2711_IRQ_AUX(BCM2711_IRQ_VC_PERIPHERAL_BASE
> + 29)
> >  #define BCM2711_IRQ_PL011_UART (BCM2711_IRQ_VC_PERIPHERAL_BASE
> + 57)
> >
> > +/* Interrupt Vectors: System Timer */
> > +#define BCM2835_IRQ_ID_GPU_TIMER_M0(BCM2711_IRQ_VC_PERIPHERAL_BASE
> + 0)
> > +#define BCM2835_IRQ_ID_GPU_TIMER_M1(BCM2711_IRQ_VC_PERIPHERAL_BASE
> + 1)
> > +#define BCM2835_IRQ_ID_GPU_TIMER_M2(BCM2711_IRQ_VC_PERIPHERAL_BASE
> + 2)
> > +#define BCM2835_IRQ_ID_GPU_TIMER_M3(BCM2711_IRQ_VC_PERIPHERAL_BASE
> + 3)
> > +
> >  #endif /* LIBBSP_AARCH64_RASPBERRYPI_BSP_BCM2711_H */
> > diff --git a/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
> b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
> > new file mode 100644
> > index 

Re: [PATCH] bsps/aarch64/raspberrypi: Add system timer support

[Ning Yang]

Hi Mr. Kinsey Moore:

I am using the RPi4 BSP (project of GSOC2023) written by Utkarsh Verma. For 
some reason it wasn't merged.
https://lists.rtems.org/pipermail/devel/2023-August/076152.html
I got the code from his github: https://github.com/UtkarshVerma/rtems

Best regards,

Ning

> 2024年4月11日 23:22，Kinsey Moore  写道：
> 
> I couldn't get this patch to apply. Are you sure it came from the right 
> branch and has no merge commits ahead of it?
> 
> Kinsey
> 
> On Wed, Apr 10, 2024 at 9:24 AM Ning Yang  wrote:
> The clock from the ARM timer is derived from the system clock. This clock can 
> change dynamically e.g. if the system goes into reduced power or in low power 
> mode. Thus the clock speed adapts to the overall system performance 
> capabilities. For accurate timing it is recommended to use the system timers.
> 
> if BSP_CLOCK_USE_SYSTEMTIMER = 1, use the System Timer, otherwise use the ARM 
> Timer.
> ---
>  .../aarch64/raspberrypi/include/bsp/bcm2711.h | 28 
>  .../raspberrypi/include/bsp/raspberrypi.h | 43 +++
>  bsps/aarch64/raspberrypi/start/bspstartmmu.c  |  8 
>  spec/build/bsps/aarch64/raspberrypi/bsp4b.yml |  1 +
>  spec/build/bsps/aarch64/raspberrypi/obj.yml   |  3 ++
>  .../bsps/aarch64/raspberrypi/objclock.yml |  4 +-
>  .../aarch64/raspberrypi/objsystemtimer.yml| 22 ++
>  .../aarch64/raspberrypi/optsystemtimer.yml| 24 +++
>  8 files changed, 132 insertions(+), 1 deletion(-)
>  create mode 100644 bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
>  create mode 100644 spec/build/bsps/aarch64/raspberrypi/objsystemtimer.yml
>  create mode 100644 spec/build/bsps/aarch64/raspberrypi/optsystemtimer.yml
> 
> diff --git a/bsps/aarch64/raspberrypi/include/bsp/bcm2711.h 
> b/bsps/aarch64/raspberrypi/include/bsp/bcm2711.h
> index e6c77fa025..8707582ebb 100644
> --- a/bsps/aarch64/raspberrypi/include/bsp/bcm2711.h
> +++ b/bsps/aarch64/raspberrypi/include/bsp/bcm2711.h
> @@ -11,6 +11,7 @@
>  /*
>   * Copyright (C) 2022 Mohd Noor Aman
>   * Copyright (C) 2023 Utkarsh Verma
> + * Copyright (C) 2024 Ning Yang
>   *
>   *
>   * Redistribution and use in source and binary forms, with or without
> @@ -91,6 +92,27 @@
>  #define BCM2711_UART5_BASE (BCM2711_PL011_BASE + 0xa00)
>  #define BCM2711_UART5_SIZE BCM2711_PL011_DEVICE_SIZE
> 
> +/* System Timer */
> +/**
> + * NOTE: The GPU uses Compare registers 0 and 2 for
> + *   it's own RTOS. 1 and 3 are available for use in
> + *   RTEMS.
> + */
> +#define BCM2835_GPU_TIMER_BASE(BCM2711_PERIPHERAL_BASE + 0x200+ 
> 0x3000)
> +#define BCM2835_GPU_TIMER_SIZE0x1C
> +
> +#define BCM2835_GPU_TIMER_CS  (BCM2835_GPU_TIMER_BASE + 0x00)
> +#define BCM2835_GPU_TIMER_CS_M0   0x0001
> +#define BCM2835_GPU_TIMER_CS_M1   0x0002
> +#define BCM2835_GPU_TIMER_CS_M2   0x0004
> +#define BCM2835_GPU_TIMER_CS_M3   0x0008
> +#define BCM2835_GPU_TIMER_CLO (BCM2835_GPU_TIMER_BASE + 0x04)
> +#define BCM2835_GPU_TIMER_CHI (BCM2835_GPU_TIMER_BASE + 0x08)
> +#define BCM2835_GPU_TIMER_C0  (BCM2835_GPU_TIMER_BASE + 0x0C)
> +#define BCM2835_GPU_TIMER_C1  (BCM2835_GPU_TIMER_BASE + 0x10)
> +#define BCM2835_GPU_TIMER_C2  (BCM2835_GPU_TIMER_BASE + 0x14)
> +#define BCM2835_GPU_TIMER_C3  (BCM2835_GPU_TIMER_BASE + 0x18)
> +
>  /* ARM Local */
>  #define BCM2711_ARM_LOCAL_BASE 0xff80LL
>  #define BCM2711_ARM_LOCAL_SIZE 0x80
> @@ -114,4 +136,10 @@
>  #define BCM2711_IRQ_AUX(BCM2711_IRQ_VC_PERIPHERAL_BASE + 29)
>  #define BCM2711_IRQ_PL011_UART (BCM2711_IRQ_VC_PERIPHERAL_BASE + 57)
> 
> +/* Interrupt Vectors: System Timer */
> +#define BCM2835_IRQ_ID_GPU_TIMER_M0(BCM2711_IRQ_VC_PERIPHERAL_BASE + 0)
> +#define BCM2835_IRQ_ID_GPU_TIMER_M1(BCM2711_IRQ_VC_PERIPHERAL_BASE + 1)
> +#define BCM2835_IRQ_ID_GPU_TIMER_M2(BCM2711_IRQ_VC_PERIPHERAL_BASE + 2)
> +#define BCM2835_IRQ_ID_GPU_TIMER_M3(BCM2711_IRQ_VC_PERIPHERAL_BASE + 3)
> +
>  #endif /* LIBBSP_AARCH64_RASPBERRYPI_BSP_BCM2711_H */
> diff --git a/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h 
> b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
> new file mode 100644
> index 00..2e1c673bfb
> --- /dev/null
> +++ b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
> @@ -0,0 +1,43 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @ingroup RTEMSBSPsAArch64RaspberryPi
> + *
> + * @brief RaspberryPi shared Register Definitions
> + */
> +
> +/*
> + * Copyright (C) 2024 Ning Yang
> + *
> + *
> + * 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

Re: [PATCH] bsps/aarch64/raspberrypi: Add system timer support

[Kinsey Moore]

I couldn't get this patch to apply. Are you sure it came from the right
branch and has no merge commits ahead of it?

Kinsey

On Wed, Apr 10, 2024 at 9:24 AM Ning Yang  wrote:

> The clock from the ARM timer is derived from the system clock. This clock
> can change dynamically e.g. if the system goes into reduced power or in low
> power mode. Thus the clock speed adapts to the overall system performance
> capabilities. For accurate timing it is recommended to use the system
> timers.
>
> if BSP_CLOCK_USE_SYSTEMTIMER = 1, use the System Timer, otherwise use the
> ARM Timer.
> ---
>  .../aarch64/raspberrypi/include/bsp/bcm2711.h | 28 
>  .../raspberrypi/include/bsp/raspberrypi.h | 43 +++
>  bsps/aarch64/raspberrypi/start/bspstartmmu.c  |  8 
>  spec/build/bsps/aarch64/raspberrypi/bsp4b.yml |  1 +
>  spec/build/bsps/aarch64/raspberrypi/obj.yml   |  3 ++
>  .../bsps/aarch64/raspberrypi/objclock.yml |  4 +-
>  .../aarch64/raspberrypi/objsystemtimer.yml| 22 ++
>  .../aarch64/raspberrypi/optsystemtimer.yml| 24 +++
>  8 files changed, 132 insertions(+), 1 deletion(-)
>  create mode 100644 bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
>  create mode 100644 spec/build/bsps/aarch64/raspberrypi/objsystemtimer.yml
>  create mode 100644 spec/build/bsps/aarch64/raspberrypi/optsystemtimer.yml
>
> diff --git a/bsps/aarch64/raspberrypi/include/bsp/bcm2711.h
> b/bsps/aarch64/raspberrypi/include/bsp/bcm2711.h
> index e6c77fa025..8707582ebb 100644
> --- a/bsps/aarch64/raspberrypi/include/bsp/bcm2711.h
> +++ b/bsps/aarch64/raspberrypi/include/bsp/bcm2711.h
> @@ -11,6 +11,7 @@
>  /*
>   * Copyright (C) 2022 Mohd Noor Aman
>   * Copyright (C) 2023 Utkarsh Verma
> + * Copyright (C) 2024 Ning Yang
>   *
>   *
>   * Redistribution and use in source and binary forms, with or without
> @@ -91,6 +92,27 @@
>  #define BCM2711_UART5_BASE (BCM2711_PL011_BASE + 0xa00)
>  #define BCM2711_UART5_SIZE BCM2711_PL011_DEVICE_SIZE
>
> +/* System Timer */
> +/**
> + * NOTE: The GPU uses Compare registers 0 and 2 for
> + *   it's own RTOS. 1 and 3 are available for use in
> + *   RTEMS.
> + */
> +#define BCM2835_GPU_TIMER_BASE(BCM2711_PERIPHERAL_BASE + 0x200+
> 0x3000)
> +#define BCM2835_GPU_TIMER_SIZE0x1C
> +
> +#define BCM2835_GPU_TIMER_CS  (BCM2835_GPU_TIMER_BASE + 0x00)
> +#define BCM2835_GPU_TIMER_CS_M0   0x0001
> +#define BCM2835_GPU_TIMER_CS_M1   0x0002
> +#define BCM2835_GPU_TIMER_CS_M2   0x0004
> +#define BCM2835_GPU_TIMER_CS_M3   0x0008
> +#define BCM2835_GPU_TIMER_CLO (BCM2835_GPU_TIMER_BASE + 0x04)
> +#define BCM2835_GPU_TIMER_CHI (BCM2835_GPU_TIMER_BASE + 0x08)
> +#define BCM2835_GPU_TIMER_C0  (BCM2835_GPU_TIMER_BASE + 0x0C)
> +#define BCM2835_GPU_TIMER_C1  (BCM2835_GPU_TIMER_BASE + 0x10)
> +#define BCM2835_GPU_TIMER_C2  (BCM2835_GPU_TIMER_BASE + 0x14)
> +#define BCM2835_GPU_TIMER_C3  (BCM2835_GPU_TIMER_BASE + 0x18)
> +
>  /* ARM Local */
>  #define BCM2711_ARM_LOCAL_BASE 0xff80LL
>  #define BCM2711_ARM_LOCAL_SIZE 0x80
> @@ -114,4 +136,10 @@
>  #define BCM2711_IRQ_AUX(BCM2711_IRQ_VC_PERIPHERAL_BASE +
> 29)
>  #define BCM2711_IRQ_PL011_UART (BCM2711_IRQ_VC_PERIPHERAL_BASE +
> 57)
>
> +/* Interrupt Vectors: System Timer */
> +#define BCM2835_IRQ_ID_GPU_TIMER_M0(BCM2711_IRQ_VC_PERIPHERAL_BASE +
> 0)
> +#define BCM2835_IRQ_ID_GPU_TIMER_M1(BCM2711_IRQ_VC_PERIPHERAL_BASE +
> 1)
> +#define BCM2835_IRQ_ID_GPU_TIMER_M2(BCM2711_IRQ_VC_PERIPHERAL_BASE +
> 2)
> +#define BCM2835_IRQ_ID_GPU_TIMER_M3(BCM2711_IRQ_VC_PERIPHERAL_BASE +
> 3)
> +
>  #endif /* LIBBSP_AARCH64_RASPBERRYPI_BSP_BCM2711_H */
> diff --git a/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
> b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
> new file mode 100644
> index 00..2e1c673bfb
> --- /dev/null
> +++ b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
> @@ -0,0 +1,43 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @ingroup RTEMSBSPsAArch64RaspberryPi
> + *
> + * @brief RaspberryPi shared Register Definitions
> + */
> +
> +/*
> + * Copyright (C) 2024 Ning Yang
> + *
> + *
> + * 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
> 

Re: [PATCH 0/3] Improve Xilinx TTC clock driver

[Sebastian Huber]

On 11.04.24 16:56, Kinsey Moore wrote:

Beyond the rebase issue, this patch set looks good.


Thanks for the review, I checked it in.

--
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: [PATCH 0/3] Improve Xilinx TTC clock driver

[Kinsey Moore]

Beyond the rebase issue, this patch set looks good.

Kinsey

On Wed, Apr 10, 2024 at 6:16 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Sebastian Huber (3):
>   bsps/xil-ttc: Use interrupt entry
>   bsps/xil-ttc: Add XIL_FATAL_TTC_IRQ_INSTALL
>   bsps/xil-ttc: Improve clock driver
>
>  bsps/arm/xilinx-zynqmp-rpu/include/bsp.h  |   3 -
>  bsps/arm/xilinx-zynqmp-rpu/include/bsp/irq.h  |   1 -
>  bsps/include/bsp/fatal.h  |   3 +
>  bsps/shared/dev/clock/xil-ttc.c   | 267 +-
>  spec/build/bsps/arm/xilinx-zynqmp-rpu/grp.yml |   6 +
>  spec/build/bsps/optxilclockttcbaseaddr.yml|  18 ++
>  spec/build/bsps/optxilclockttcirq.yml |  18 ++
>  spec/build/bsps/optxilclockttcrefclk.yml  |  18 ++
>  .../bsps/fatal-clock-xil-ttc-irq-install.yml  |  21 ++
>  .../validation/bsps/objclockxilttc.yml|  14 +
>  .../validation/bsps/validation-bsp-0.yml  |   6 +-
>  spec/build/testsuites/validation/grp.yml  |   2 +
>  .../bsps/tr-fatal-clock-xil-ttc-irq-install.c | 187 
>  .../bsps/tr-fatal-clock-xil-ttc-irq-install.h |  84 ++
>  .../bsps/ts-fatal-clock-xil-ttc-irq-install.c |  79 ++
>  testsuites/validation/tc-dev-clock-xil-ttc.c  | 136 +
>  16 files changed, 721 insertions(+), 142 deletions(-)
>  create mode 100644 spec/build/bsps/optxilclockttcbaseaddr.yml
>  create mode 100644 spec/build/bsps/optxilclockttcirq.yml
>  create mode 100644 spec/build/bsps/optxilclockttcrefclk.yml
>  create mode 100644
> spec/build/testsuites/validation/bsps/fatal-clock-xil-ttc-irq-install.yml
>  create mode 100644
> spec/build/testsuites/validation/bsps/objclockxilttc.yml
>  create mode 100644
> testsuites/validation/bsps/tr-fatal-clock-xil-ttc-irq-install.c
>  create mode 100644
> testsuites/validation/bsps/tr-fatal-clock-xil-ttc-irq-install.h
>  create mode 100644
> testsuites/validation/bsps/ts-fatal-clock-xil-ttc-irq-install.c
>  create mode 100644 testsuites/validation/tc-dev-clock-xil-ttc.c
>
> --
> 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 1/3] bsps/xil-ttc: Use interrupt entry

[Sebastian Huber]

On 11.04.24 16:27, Kinsey Moore wrote:

  static void zynqmp_ttc_clock_driver_support_install_isr(
    rtems_interrupt_handler handler
  )
  {
    rtems_status_code sc;

-  sc = rtems_interrupt_handler_install(
-    BSP_SELECTED_TTC_IRQ,
-    "Clock",
-    RTEMS_INTERRUPT_UNIQUE,
+  rtems_interrupt_entry_initialize(
+    _ttc_interrupt_entry,
      handler,
      _clock_instance


There is a missing comma here preventing compilation.


Thanks, I will fix this. I introduced this error in a rebase.

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