Re: [PATCH 1/2] cpukit/jffs2: Set extracted nodes off-chain

[Sebastian Huber]

On 21.09.23 18:48, Kinsey Moore wrote:
On Thu, Sep 21, 2023 at 10:23 AM Sebastian Huber 
> wrote:


On 21.09.23 17:06, Kinsey Moore wrote:
 > On Thu, Sep 21, 2023 at 10:01 AM Sebastian Huber
 > mailto:sebastian.hu...@embedded-brains.de>
 > >> wrote:
 >
 >     On 21.09.23 16:52, Kinsey Moore wrote:
 >      > On Thu, Sep 21, 2023 at 9:47 AM Sebastian Huber
 >      > mailto:sebastian.hu...@embedded-brains.de>
 >     >
 >      > 
 >           >
 >      >     On 20.09.23 20:35, Kinsey Moore wrote:
 >      >     [...]
 >      >      > @@ -1306,8 +1307,22 @@ static void
process_delayed_work(void)
 >      >      >       while (!rtems_chain_is_tail(_work_chain,
 >     node)) {
 >      >      >               work = (struct delayed_work*) node;
 >      >      >               rtems_chain_node* next_node =
 >     rtems_chain_next(node);
 >      >      > +
 >      >      > +             /*
 >      >      > +              * Don't leave extracted node exposed
to other
 >      >     operations
 >      >      > +              * under RTEMS_DEBUG
 >      >      > +              */
 >      >      > +#ifdef RTEMS_DEBUG
 >      >      > +             mutex_lock(_work_mutex);
 >      >      > +#endif
 >      >      >               rtems_chain_extract(node);
 >      >      > +#ifdef RTEMS_DEBUG
 >      >      > +             node->next = node;
 >      >      > +             mutex_unlock(_work_mutex);
 >      >      > +#endif
 >      >      > +
 >      >      >               work->callback(>work);
 >      >      > +             rtems_chain_set_off_chain(node);
 >      >      >               node = next_node;
 >      >      >       }
 >      >      >   }
 >      >
 >      >     This change makes no sense to me. The code should work
 >     regardless if
 >      >     RTEMS_DEBUG is defined or not.
 >      >
 >      >
 >      > RTEMS_DEBUG introduces a behavioral change in
 >     rtems_chain_extract() such
 >      > that extracted nodes are automatically set off-chain. When
 >     RTEMS_DEBUG
 >      > is not set, node->next is left untouched. This has to be
managed
 >     because
 >      > this code needs the node to remain on-chain so that it is not
 >     re-queued
 >      > during the operation.
 >
 >     Yes, but while a node is on a chain you must not call
 >     rtems_chain_set_off_chain(). If you want to use the off-chain
state,
 >     then you have to use this:
 >
 >     rtems_chain_extract(node);
 >     rtems_chain_set_off_chain(node);
 >
 >     or
 >
 >     rtems_chain_extract_unprotected(node);
 >     rtems_chain_set_off_chain(node);
 >
 >     The automatic set off-chain in RTEMS_DEBUG is just to ensure
that basic
 >     chain operations are used in the right state.
 >
 >
 > Yes, there is no behavior here where rtems_chain_set_off_chain() is
 > being called on a node that is still in a chain. This section of
code is
 > entirely managing the side-effect of RTEMS_DEBUG that sets the
node in
 > the off-chain state post-extraction. In this case, that
side-effect is
 > undesirable and so a lock is in place to prevent that temporary
 > side-effect from leaking to other parts of the system since all
other
 > off-chain checks are behind the same lock.

Ok, so you want to delay the set-off state visibility in case
RTEMS_DEBUG is defined. This is the first place in the code base which
needs this behaviour.


Would it be more acceptable to always lock it and ensure that it's 
recognized as on-chain instead of checking for RTEMS_DEBUG?



We basically don't use internal locking in JFFS2 in RTEMS. Why can't
you
use the global file system lock of the JFFS2 instance to work carry out
this delayed work?


The JFFS2 instance to which the delayed work belongs is a detail 
internal to the delayed work itself. Reaching that information is 
possible, but would be fragile. The other option I had in mind was to 
create one delayed work thread per JFFS2 FS instance so that the delayed 
work processor can know reliably which JFFS2 instance it is working on, 
but that seemed wasteful.


I would do the following.

1. The delayed work support uses a mutex D and a condition variable C 
used with D.


2. Add a queue for the delayed work to the fs information and a node 

Re: [PATCH 1/1] trace: build with c++17 if building against llvm 16+

[Sebastian Huber]

On 22.09.23 04:36, Joel Sherrill wrote:
Are we doing something that particularly requires C++17? AFAIK we 
haven't needed it yet and why wouldn't it also be needed with gcc? If 
the default on recent gcc versions is that, ok but we should be precise 
in case an older gcc with a different default is used.


The problem is not that we use features of a particular standard. It is 
that LLVM requires a particular standard for the header files it ships 
and that we use.


I already fixed this some time ago:

https://lists.rtems.org/pipermail/devel/2023-May/075269.html

However, Chris didn't like the change.

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

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/1] trace: build with c++17 if building against llvm 16+

[Joel Sherrill]

Are we doing something that particularly requires C++17? AFAIK we haven't
needed it yet and why wouldn't it also be needed with gcc? If the default
on recent gcc versions is that, ok but we should be precise in case an
older gcc with a different default is used.

This may also eliminate some hoats.

Just asking configuration management type questions.

--jorl

On Thu, Sep 21, 2023, 8:31 PM JJL772  wrote:

> ---
>  trace/wscript | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/trace/wscript b/trace/wscript
> index a3dd5d5..0ae90f8 100644
> --- a/trace/wscript
> +++ b/trace/wscript
> @@ -33,11 +33,14 @@ def options(opt):
>  def configure(conf):
>  conf.load('compiler_c')
>  conf.load('compiler_cxx')
> +needs_cxx17 = False
>  try:
>  cppflags = conf.cmd_and_log(['llvm-config', '--cppflags'])
>  ldflags = conf.cmd_and_log(['llvm-config', '--ldflags'])
>  conf.env.append_value('CPPFLAGS', cppflags.split())
>  conf.env.append_value('LDFLAGS', ldflags.split())
> +# llvm 16+ requires C++17 to build
> +needs_cxx17 = int(conf.cmd_and_log(['llvm-config',
> '--version']).split()[0]) >= 16
>  except:
>  pass
>  if conf.check_cxx(lib = 'LLVM', mandatory=False):
> @@ -46,6 +49,7 @@ def configure(conf):
>  conf.check_cxx(lib = 'z')
>  conf.check_cxx(lib = 'ws2_32', mandatory=False)
>  conf.check_cxx(cxxflags='-std=c++14', mandatory=False,
> define_name="HAVE_STD_CXX14")
> +conf.check_cxx(cxxflags='-std=c++17', mandatory=needs_cxx17,
> define_name="HAVE_STD_CXX17")
>  conf.write_config_header('config.h')
>
>  def build(bld):
> @@ -63,7 +67,9 @@ def build(bld):
>  cstd = '-std=c99'
>  conf['cflags'] = [cstd] + ['-pipe', '-g'] + conf['optflags']
>  cxxstd = '-std=c++11'
> -if bld.env.HAVE_STD_CXX14:
> +if bld.env.HAVE_STD_CXX17:
> +cxxstd = '-std=c++17'
> +elif bld.env.HAVE_STD_CXX14:
>  cxxstd = '-std=c++14'
>  conf['cxxflags'] = [cxxstd] + ['-pipe', '-g'] + conf['optflags']
>  conf['linkflags'] = ['-g']
> --
> 2.40.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 0/1] trace: Build with C++17 if using LLVM 16+

[JJL772]

Build trace with C++17 if LLVM-16+ is present. Headers provided by LLVM
may use C++17 features as of 16.0.

JJL772 (1):
  trace: build with c++17 if building against llvm 16+

 trace/wscript | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

-- 
2.40.1

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

[PATCH 1/1] trace: build with c++17 if building against llvm 16+

[JJL772]

---
 trace/wscript | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/trace/wscript b/trace/wscript
index a3dd5d5..0ae90f8 100644
--- a/trace/wscript
+++ b/trace/wscript
@@ -33,11 +33,14 @@ def options(opt):
 def configure(conf):
 conf.load('compiler_c')
 conf.load('compiler_cxx')
+needs_cxx17 = False
 try:
 cppflags = conf.cmd_and_log(['llvm-config', '--cppflags'])
 ldflags = conf.cmd_and_log(['llvm-config', '--ldflags'])
 conf.env.append_value('CPPFLAGS', cppflags.split())
 conf.env.append_value('LDFLAGS', ldflags.split())
+# llvm 16+ requires C++17 to build
+needs_cxx17 = int(conf.cmd_and_log(['llvm-config', 
'--version']).split()[0]) >= 16
 except:
 pass
 if conf.check_cxx(lib = 'LLVM', mandatory=False):
@@ -46,6 +49,7 @@ def configure(conf):
 conf.check_cxx(lib = 'z')
 conf.check_cxx(lib = 'ws2_32', mandatory=False)
 conf.check_cxx(cxxflags='-std=c++14', mandatory=False, 
define_name="HAVE_STD_CXX14")
+conf.check_cxx(cxxflags='-std=c++17', mandatory=needs_cxx17, 
define_name="HAVE_STD_CXX17")
 conf.write_config_header('config.h')
 
 def build(bld):
@@ -63,7 +67,9 @@ def build(bld):
 cstd = '-std=c99'
 conf['cflags'] = [cstd] + ['-pipe', '-g'] + conf['optflags']
 cxxstd = '-std=c++11'
-if bld.env.HAVE_STD_CXX14:
+if bld.env.HAVE_STD_CXX17:
+cxxstd = '-std=c++17'
+elif bld.env.HAVE_STD_CXX14:
 cxxstd = '-std=c++14'
 conf['cxxflags'] = [cxxstd] + ['-pipe', '-g'] + conf['optflags']
 conf['linkflags'] = ['-g']
-- 
2.40.1

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

Re: [PATCH] bsd/ntpq: Use the correct address length

[Kinsey Moore]

Yes, sorry about that. I apparently haven't added the subject tweak to this
repo yet.

Thanks,
Kinsey

On Thu, Sep 21, 2023 at 7:02 PM Chris Johns  wrote:

> I assume this is in the network services repo?
>
> OK and thanks
>
> Chris
>
> On 22/9/2023 4:38 am, Kinsey Moore wrote:
> > lwIP includes more than the bare address structures in its accounting of
> > the total addrinfo struct size. Ensure that lwIP gets the correct
> > address size.
> > ---
> >  bsd/freebsd/contrib/ntp/ntpq/ntpq.c | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/bsd/freebsd/contrib/ntp/ntpq/ntpq.c
> b/bsd/freebsd/contrib/ntp/ntpq/ntpq.c
> > index 1cea922..0ea6c08 100644
> > --- a/bsd/freebsd/contrib/ntp/ntpq/ntpq.c
> > +++ b/bsd/freebsd/contrib/ntp/ntpq/ntpq.c
> > @@ -828,6 +828,14 @@ openhost(
> >  #ifdef SYS_VXWORKS
> >  (connect(sockfd, (struct sockaddr *),
> >   sizeof(hostaddr)) == -1)
> > +#elif defined(__rtems__)
> > +/*
> > + * lwIP's ai_addrlen covers the entire struct which includes
> > + * padding for extra data and is not accurate for calls which
> > + * validate the size of the address structure. Use sa_len
> instead
> > + */
> > +(connect(sockfd, (struct sockaddr *)ai->ai_addr,
> > + ai->ai_addr->sa_len) == -1)
> >  #else
> >  (connect(sockfd, (struct sockaddr *)ai->ai_addr,
> >   ai->ai_addrlen) == -1)
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/2] bsps/xqspipsu: Break out RDID

[Chris Johns]

OK to 1 and 2

Thanks
Chris

On 22/9/2023 7:31 am, Kinsey Moore wrote:
> Expose a function to read the NOR flash chip ID information beyond the
> minimum 3 bytes for the lookup table.
> ---
>  bsps/include/dev/spi/xqspipsu-flash-helper.h | 15 +++
>  bsps/shared/dev/spi/xqspipsu-flash-helper.c  | 45 +---
>  2 files changed, 44 insertions(+), 16 deletions(-)
> 
> diff --git a/bsps/include/dev/spi/xqspipsu-flash-helper.h 
> b/bsps/include/dev/spi/xqspipsu-flash-helper.h
> index 5e4233e64e..1578fe8485 100644
> --- a/bsps/include/dev/spi/xqspipsu-flash-helper.h
> +++ b/bsps/include/dev/spi/xqspipsu-flash-helper.h
> @@ -155,3 +155,18 @@ u32 QspiPsu_NOR_Get_Device_Size(XQspiPsu *QspiPsuPtr);
>   *
>   
> **/
>  u32 QspiPsu_NOR_Get_Sector_Size(XQspiPsu *QspiPsuPtr);
> +
> +/*/
> +/**
> + *
> + * This function performs a read of the RDID configuration space.
> + *
> + * @paramQspiPsuPtr is a pointer to the QSPIPSU driver component to use.
> + * @paramReadBfrPtr is a pointer to a buffer to be filled with
> + *   configuration data.
> + * @paramReadLen is the total length of the configuration space to read.
> + *
> + * @return   XST_SUCCESS if successful, else XST_FAILURE.
> + *
> + 
> **/
> +int QspiPsu_NOR_RDID(XQspiPsu *QspiPsuPtr, u8 *ReadBfrPtr, u32 ReadLen);
> diff --git a/bsps/shared/dev/spi/xqspipsu-flash-helper.c 
> b/bsps/shared/dev/spi/xqspipsu-flash-helper.c
> index c9d8273b87..0dd065f02e 100644
> --- a/bsps/shared/dev/spi/xqspipsu-flash-helper.c
> +++ b/bsps/shared/dev/spi/xqspipsu-flash-helper.c
> @@ -274,22 +274,9 @@ static void QspiPsuHandler(
>}
>  }
>  
> -/*/
> -/**
> - *
> - * Reads the flash ID and identifies the flash in FCT table.
> - *
> - * @paramQspiPsuPtr is a pointer to the QSPIPSU driver component to use.
> - *
> - * @return   XST_SUCCESS if successful, else XST_FAILURE.
> - *
> - * @note None.
> - *
> - 
> */
> -static int FlashReadID(XQspiPsu *QspiPsuPtr)
> +int QspiPsu_NOR_RDID(XQspiPsu *QspiPsuPtr, u8 *ReadBfrPtr, u32 ReadLen)
>  {
>int Status;
> -  u32 ReadId = 0;
>  
>/*
> * Read ID
> @@ -303,7 +290,7 @@ static int FlashReadID(XQspiPsu *QspiPsuPtr)
>  
>FlashMsg[1].TxBfrPtr = NULL;
>FlashMsg[1].RxBfrPtr = ReadBfrPtr;
> -  FlashMsg[1].ByteCount = 3;
> +  FlashMsg[1].ByteCount = ReadLen;
>FlashMsg[1].BusWidth = XQSPIPSU_SELECT_MODE_SPI;
>FlashMsg[1].Flags = XQSPIPSU_MSG_FLAG_RX;
>  
> @@ -314,7 +301,33 @@ static int FlashReadID(XQspiPsu *QspiPsuPtr)
>}
>while (TransferInProgress);
>  
> -  rtems_cache_invalidate_multiple_data_lines(ReadBfrPtr, 3);
> +  rtems_cache_invalidate_multiple_data_lines(ReadBfrPtr, ReadLen);
> +  return XST_SUCCESS;
> +}
> +
> +/*/
> +/**
> + *
> + * Reads the flash ID and identifies the flash in FCT table.
> + *
> + * @paramQspiPsuPtr is a pointer to the QSPIPSU driver component to use.
> + *
> + * @return   XST_SUCCESS if successful, else XST_FAILURE.
> + *
> + * @note None.
> + *
> + 
> */
> +static int FlashReadID(XQspiPsu *QspiPsuPtr)
> +{
> +  u32 ReadId = 0;
> +  u32 ReadLen = 3;
> +  int Status;
> +
> +  Status = QspiPsu_NOR_RDID(QspiPsuPtr, ReadBfrPtr, ReadLen);
> +  if (Status != XST_SUCCESS) {
> +return XST_FAILURE;
> +  }
> +
>/* In case of dual, read both and ensure they are same make/size */
>  
>/*
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsd/ntpq: Use the correct address length

[Chris Johns]

I assume this is in the network services repo?

OK and thanks

Chris

On 22/9/2023 4:38 am, Kinsey Moore wrote:
> lwIP includes more than the bare address structures in its accounting of
> the total addrinfo struct size. Ensure that lwIP gets the correct
> address size.
> ---
>  bsd/freebsd/contrib/ntp/ntpq/ntpq.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/bsd/freebsd/contrib/ntp/ntpq/ntpq.c 
> b/bsd/freebsd/contrib/ntp/ntpq/ntpq.c
> index 1cea922..0ea6c08 100644
> --- a/bsd/freebsd/contrib/ntp/ntpq/ntpq.c
> +++ b/bsd/freebsd/contrib/ntp/ntpq/ntpq.c
> @@ -828,6 +828,14 @@ openhost(
>  #ifdef SYS_VXWORKS
>  (connect(sockfd, (struct sockaddr *),
>   sizeof(hostaddr)) == -1)
> +#elif defined(__rtems__)
> +/*
> + * lwIP's ai_addrlen covers the entire struct which includes
> + * padding for extra data and is not accurate for calls which
> + * validate the size of the address structure. Use sa_len instead
> + */
> +(connect(sockfd, (struct sockaddr *)ai->ai_addr,
> + ai->ai_addr->sa_len) == -1)
>  #else
>  (connect(sockfd, (struct sockaddr *)ai->ai_addr,
>   ai->ai_addrlen) == -1)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 1/2] bsps/xqspipsu: Break out RDID

[Kinsey Moore]

Expose a function to read the NOR flash chip ID information beyond the
minimum 3 bytes for the lookup table.
---
 bsps/include/dev/spi/xqspipsu-flash-helper.h | 15 +++
 bsps/shared/dev/spi/xqspipsu-flash-helper.c  | 45 +---
 2 files changed, 44 insertions(+), 16 deletions(-)

diff --git a/bsps/include/dev/spi/xqspipsu-flash-helper.h 
b/bsps/include/dev/spi/xqspipsu-flash-helper.h
index 5e4233e64e..1578fe8485 100644
--- a/bsps/include/dev/spi/xqspipsu-flash-helper.h
+++ b/bsps/include/dev/spi/xqspipsu-flash-helper.h
@@ -155,3 +155,18 @@ u32 QspiPsu_NOR_Get_Device_Size(XQspiPsu *QspiPsuPtr);
  *
  
**/
 u32 QspiPsu_NOR_Get_Sector_Size(XQspiPsu *QspiPsuPtr);
+
+/*/
+/**
+ *
+ * This function performs a read of the RDID configuration space.
+ *
+ * @param  QspiPsuPtr is a pointer to the QSPIPSU driver component to use.
+ * @param  ReadBfrPtr is a pointer to a buffer to be filled with
+ * configuration data.
+ * @param  ReadLen is the total length of the configuration space to read.
+ *
+ * @return XST_SUCCESS if successful, else XST_FAILURE.
+ *
+ 
**/
+int QspiPsu_NOR_RDID(XQspiPsu *QspiPsuPtr, u8 *ReadBfrPtr, u32 ReadLen);
diff --git a/bsps/shared/dev/spi/xqspipsu-flash-helper.c 
b/bsps/shared/dev/spi/xqspipsu-flash-helper.c
index c9d8273b87..0dd065f02e 100644
--- a/bsps/shared/dev/spi/xqspipsu-flash-helper.c
+++ b/bsps/shared/dev/spi/xqspipsu-flash-helper.c
@@ -274,22 +274,9 @@ static void QspiPsuHandler(
   }
 }
 
-/*/
-/**
- *
- * Reads the flash ID and identifies the flash in FCT table.
- *
- * @param  QspiPsuPtr is a pointer to the QSPIPSU driver component to use.
- *
- * @return XST_SUCCESS if successful, else XST_FAILURE.
- *
- * @note   None.
- *
- */
-static int FlashReadID(XQspiPsu *QspiPsuPtr)
+int QspiPsu_NOR_RDID(XQspiPsu *QspiPsuPtr, u8 *ReadBfrPtr, u32 ReadLen)
 {
   int Status;
-  u32 ReadId = 0;
 
   /*
* Read ID
@@ -303,7 +290,7 @@ static int FlashReadID(XQspiPsu *QspiPsuPtr)
 
   FlashMsg[1].TxBfrPtr = NULL;
   FlashMsg[1].RxBfrPtr = ReadBfrPtr;
-  FlashMsg[1].ByteCount = 3;
+  FlashMsg[1].ByteCount = ReadLen;
   FlashMsg[1].BusWidth = XQSPIPSU_SELECT_MODE_SPI;
   FlashMsg[1].Flags = XQSPIPSU_MSG_FLAG_RX;
 
@@ -314,7 +301,33 @@ static int FlashReadID(XQspiPsu *QspiPsuPtr)
   }
   while (TransferInProgress);
 
-  rtems_cache_invalidate_multiple_data_lines(ReadBfrPtr, 3);
+  rtems_cache_invalidate_multiple_data_lines(ReadBfrPtr, ReadLen);
+  return XST_SUCCESS;
+}
+
+/*/
+/**
+ *
+ * Reads the flash ID and identifies the flash in FCT table.
+ *
+ * @param  QspiPsuPtr is a pointer to the QSPIPSU driver component to use.
+ *
+ * @return XST_SUCCESS if successful, else XST_FAILURE.
+ *
+ * @note   None.
+ *
+ */
+static int FlashReadID(XQspiPsu *QspiPsuPtr)
+{
+  u32 ReadId = 0;
+  u32 ReadLen = 3;
+  int Status;
+
+  Status = QspiPsu_NOR_RDID(QspiPsuPtr, ReadBfrPtr, ReadLen);
+  if (Status != XST_SUCCESS) {
+return XST_FAILURE;
+  }
+
   /* In case of dual, read both and ensure they are same make/size */
 
   /*
-- 
2.39.2

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

[PATCH 2/2] bsps/xqspipsu: Add SFDP config space read ability

[Kinsey Moore]

This adds a function to allow reading of the SFDP configuration space
that describes attributes of NOR flash chips.
---
 bsps/include/dev/spi/xqspipsu-flash-helper.h | 20 
 bsps/include/dev/spi/xqspipsu_flash_config.h |  1 +
 bsps/shared/dev/spi/xqspipsu-flash-helper.c  | 48 
 3 files changed, 69 insertions(+)

diff --git a/bsps/include/dev/spi/xqspipsu-flash-helper.h 
b/bsps/include/dev/spi/xqspipsu-flash-helper.h
index 1578fe8485..e689660881 100644
--- a/bsps/include/dev/spi/xqspipsu-flash-helper.h
+++ b/bsps/include/dev/spi/xqspipsu-flash-helper.h
@@ -170,3 +170,23 @@ u32 QspiPsu_NOR_Get_Sector_Size(XQspiPsu *QspiPsuPtr);
  *
  
**/
 int QspiPsu_NOR_RDID(XQspiPsu *QspiPsuPtr, u8 *ReadBfrPtr, u32 ReadLen);
+
+/*/
+/**
+ *
+ * This function performs a read of the SFDP configuration space.
+ *
+ * @param  QspiPsuPtr is a pointer to the QSPIPSU driver component to use.
+ * @param  ReadBfrPtr is a pointer to a buffer to be filled with
+ * configuration data.
+ * @param  ReadLen is the total length of the configuration space to read.
+ *
+ * @return XST_SUCCESS if successful, else XST_FAILURE.
+ *
+ 
**/
+int QspiPsu_NOR_RDSFDP(
+  XQspiPsu *QspiPsuPtr,
+  u32 Address,
+  u32 ByteCount,
+  u8 **ReadBfrPtr
+);
diff --git a/bsps/include/dev/spi/xqspipsu_flash_config.h 
b/bsps/include/dev/spi/xqspipsu_flash_config.h
index 8310a87536..0b04fffc28 100644
--- a/bsps/include/dev/spi/xqspipsu_flash_config.h
+++ b/bsps/include/dev/spi/xqspipsu_flash_config.h
@@ -64,6 +64,7 @@ extern "C" {
 #define BULK_ERASE_CMD 0xC7
 #defineSEC_ERASE_CMD   0xD8
 #define READ_ID0x9F
+#define READ_SFDP  0x5A
 #define READ_CONFIG_CMD0x35
 #define WRITE_CONFIG_CMD   0x01
 #define ENTER_4B_ADDR_MODE 0xB7
diff --git a/bsps/shared/dev/spi/xqspipsu-flash-helper.c 
b/bsps/shared/dev/spi/xqspipsu-flash-helper.c
index 0dd065f02e..69c4035e6a 100644
--- a/bsps/shared/dev/spi/xqspipsu-flash-helper.c
+++ b/bsps/shared/dev/spi/xqspipsu-flash-helper.c
@@ -274,6 +274,54 @@ static void QspiPsuHandler(
   }
 }
 
+int QspiPsu_NOR_RDSFDP(
+  XQspiPsu *QspiPsuPtr,
+  u32 Address,
+  u32 ByteCount,
+  u8 **ReadBfrPtr
+)
+{
+  int Status;
+
+  *ReadBfrPtr = ReadBuffer;
+
+  CmdBfr[COMMAND_OFFSET]   = READ_SFDP;
+  CmdBfr[ADDRESS_1_OFFSET] =
+  (u8)((Address & 0xFF) >> 16);
+  CmdBfr[ADDRESS_2_OFFSET] =
+  (u8)((Address & 0xFF00) >> 8);
+  CmdBfr[ADDRESS_3_OFFSET] =
+  (u8)(Address & 0xFF);
+
+  FlashMsg[0].BusWidth = XQSPIPSU_SELECT_MODE_SPI;
+  FlashMsg[0].TxBfrPtr = CmdBfr;
+  FlashMsg[0].RxBfrPtr = NULL;
+  FlashMsg[0].ByteCount = 4;
+  FlashMsg[0].Flags = XQSPIPSU_MSG_FLAG_TX;
+
+  FlashMsg[1].BusWidth = XQSPIPSU_SELECT_MODE_SPI;
+  FlashMsg[1].TxBfrPtr = NULL;
+  FlashMsg[1].RxBfrPtr = NULL;
+  FlashMsg[1].ByteCount = DUMMY_CLOCKS;
+  FlashMsg[1].Flags = 0;
+
+  FlashMsg[2].BusWidth = XQSPIPSU_SELECT_MODE_SPI;
+  FlashMsg[2].TxBfrPtr = NULL;
+  FlashMsg[2].RxBfrPtr = *ReadBfrPtr;
+  FlashMsg[2].ByteCount = ByteCount;
+  FlashMsg[2].Flags = XQSPIPSU_MSG_FLAG_RX;
+
+  TransferInProgress = TRUE;
+  Status = XQspiPsu_InterruptTransfer(QspiPsuPtr, FlashMsg, 3);
+  if (Status != XST_SUCCESS)
+return XST_FAILURE;
+
+  while (TransferInProgress);
+
+  rtems_cache_invalidate_multiple_data_lines(ReadBuffer, ByteCount);
+  return 0;
+}
+
 int QspiPsu_NOR_RDID(XQspiPsu *QspiPsuPtr, u8 *ReadBfrPtr, u32 ReadLen)
 {
   int Status;
-- 
2.39.2

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

[PATCH] bsd/ntpq: Use the correct address length

[Kinsey Moore]

lwIP includes more than the bare address structures in its accounting of
the total addrinfo struct size. Ensure that lwIP gets the correct
address size.
---
 bsd/freebsd/contrib/ntp/ntpq/ntpq.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/bsd/freebsd/contrib/ntp/ntpq/ntpq.c 
b/bsd/freebsd/contrib/ntp/ntpq/ntpq.c
index 1cea922..0ea6c08 100644
--- a/bsd/freebsd/contrib/ntp/ntpq/ntpq.c
+++ b/bsd/freebsd/contrib/ntp/ntpq/ntpq.c
@@ -828,6 +828,14 @@ openhost(
 #ifdef SYS_VXWORKS
   (connect(sockfd, (struct sockaddr *),
sizeof(hostaddr)) == -1)
+#elif defined(__rtems__)
+  /*
+   * lwIP's ai_addrlen covers the entire struct which includes
+   * padding for extra data and is not accurate for calls which
+   * validate the size of the address structure. Use sa_len instead
+   */
+  (connect(sockfd, (struct sockaddr *)ai->ai_addr,
+   ai->ai_addr->sa_len) == -1)
 #else
   (connect(sockfd, (struct sockaddr *)ai->ai_addr,
ai->ai_addrlen) == -1)
-- 
2.39.2

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

Re: [PATCH 1/2] cpukit/jffs2: Set extracted nodes off-chain

[Kinsey Moore]

On Thu, Sep 21, 2023 at 10:23 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 21.09.23 17:06, Kinsey Moore wrote:
> > On Thu, Sep 21, 2023 at 10:01 AM Sebastian Huber
> >  > > wrote:
> >
> > On 21.09.23 16:52, Kinsey Moore wrote:
> >  > On Thu, Sep 21, 2023 at 9:47 AM Sebastian Huber
> >  >  > 
> >  >  > >> wrote:
> >  >
> >  > On 20.09.23 20:35, Kinsey Moore wrote:
> >  > [...]
> >  >  > @@ -1306,8 +1307,22 @@ static void
> process_delayed_work(void)
> >  >  >   while (!rtems_chain_is_tail(_work_chain,
> > node)) {
> >  >  >   work = (struct delayed_work*) node;
> >  >  >   rtems_chain_node* next_node =
> > rtems_chain_next(node);
> >  >  > +
> >  >  > + /*
> >  >  > +  * Don't leave extracted node exposed to
> other
> >  > operations
> >  >  > +  * under RTEMS_DEBUG
> >  >  > +  */
> >  >  > +#ifdef RTEMS_DEBUG
> >  >  > + mutex_lock(_work_mutex);
> >  >  > +#endif
> >  >  >   rtems_chain_extract(node);
> >  >  > +#ifdef RTEMS_DEBUG
> >  >  > + node->next = node;
> >  >  > + mutex_unlock(_work_mutex);
> >  >  > +#endif
> >  >  > +
> >  >  >   work->callback(>work);
> >  >  > + rtems_chain_set_off_chain(node);
> >  >  >   node = next_node;
> >  >  >   }
> >  >  >   }
> >  >
> >  > This change makes no sense to me. The code should work
> > regardless if
> >  > RTEMS_DEBUG is defined or not.
> >  >
> >  >
> >  > RTEMS_DEBUG introduces a behavioral change in
> > rtems_chain_extract() such
> >  > that extracted nodes are automatically set off-chain. When
> > RTEMS_DEBUG
> >  > is not set, node->next is left untouched. This has to be managed
> > because
> >  > this code needs the node to remain on-chain so that it is not
> > re-queued
> >  > during the operation.
> >
> > Yes, but while a node is on a chain you must not call
> > rtems_chain_set_off_chain(). If you want to use the off-chain state,
> > then you have to use this:
> >
> > rtems_chain_extract(node);
> > rtems_chain_set_off_chain(node);
> >
> > or
> >
> > rtems_chain_extract_unprotected(node);
> > rtems_chain_set_off_chain(node);
> >
> > The automatic set off-chain in RTEMS_DEBUG is just to ensure that
> basic
> > chain operations are used in the right state.
> >
> >
> > Yes, there is no behavior here where rtems_chain_set_off_chain() is
> > being called on a node that is still in a chain. This section of code is
> > entirely managing the side-effect of RTEMS_DEBUG that sets the node in
> > the off-chain state post-extraction. In this case, that side-effect is
> > undesirable and so a lock is in place to prevent that temporary
> > side-effect from leaking to other parts of the system since all other
> > off-chain checks are behind the same lock.
>
> Ok, so you want to delay the set-off state visibility in case
> RTEMS_DEBUG is defined. This is the first place in the code base which
> needs this behaviour.
>

Would it be more acceptable to always lock it and ensure that it's
recognized as on-chain instead of checking for RTEMS_DEBUG?

>
> We basically don't use internal locking in JFFS2 in RTEMS. Why can't you
> use the global file system lock of the JFFS2 instance to work carry out
> this delayed work?
>

The JFFS2 instance to which the delayed work belongs is a detail internal
to the delayed work itself. Reaching that information is possible, but
would be fragile. The other option I had in mind was to create one delayed
work thread per JFFS2 FS instance so that the delayed work processor can
know reliably which JFFS2 instance it is working on, but that seemed
wasteful.

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

Re: Add Formal Verification chapter v4

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

On 21/09/2023, 16:42, "Sebastian Huber" mailto:sebastian.hu...@embedded-brains.de>> wrote:
On 21.09.23 17:41, Gedare Bloom wrote:
>> On Thu, Sep 21, 2023 at 9:36 AM Sebastian Huber
>> > > wrote:
>>> On 21.09.23 17:28, Gedare Bloom wrote:
 I've taken a look and resolved / commented. We can leave some of the
 `sis` specific bits, with the understanding that hopefully the
 simulation target can be made more generic in the future. This could be
 a potential GSoC project for Prequalification to hook it up to
 `rtems-tools.git/tester` to make use of the capabilities we already have
 for running simulators.
>>> The model based tests are not target-specific. You could run them with
>>> any (simulator) BSP.
>>>
>> Yes, I suspected that. However, the documentation is currently written
>> toward sis. It may be better to point the reader to another doc that
>> explains how to run tests, such as
>> https://docs.rtems.org/branches/master/user/tools/tester.html 
>> 
>> 
>> I don't recall any documentation that discusses simulator targets 
>> specifically.
>Yes, we should not duplicate this documentation. This is not maintainable.

I can remove all references to `sis` from the documentation and point to  
tester.html

However note that the python sources for all of this, in 
rtems-central/formal/promela/src
we have explicit references in testbuilder-template.yml to  `simulator: 
/sparc-rtems6-sis` 

I guess that needs to be changed.

Regards, Andrew


 
Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 
Lero@TCD, Head of Software Foundations & Verification Research Group 
School of Computer Science and Statistics, 
Room G.39, O'Reilly Institute, Trinity College, University of Dublin 
http://www.scss.tcd.ie/Andrew.Butterfield/ 
 

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de 

phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08


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




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

Re: Add Formal Verification chapter v4

[Sebastian Huber]

On 21.09.23 17:41, Gedare Bloom wrote:

On Thu, Sep 21, 2023 at 9:36 AM Sebastian Huber
  wrote:

On 21.09.23 17:28, Gedare Bloom wrote:

I've taken a look and resolved / commented. We can leave some of the
`sis` specific bits, with the understanding that hopefully the
simulation target can be made more generic in the future. This could be
a potential GSoC project for Prequalification to hook it up to
`rtems-tools.git/tester` to make use of the capabilities we already have
for running simulators.

The model based tests are not target-specific. You could run them with
any (simulator) BSP.


Yes, I suspected that. However, the documentation is currently written
toward sis. It may be better to point the reader to another doc that
explains how to run tests, such as
https://docs.rtems.org/branches/master/user/tools/tester.html

I don't recall any documentation that discusses simulator targets specifically.


Yes, we should not duplicate this documentation. This is not maintainable.

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

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Add Formal Verification chapter v4

[Gedare Bloom]

On Thu, Sep 21, 2023 at 9:36 AM Sebastian Huber
 wrote:
>
> On 21.09.23 17:28, Gedare Bloom wrote:
> > I've taken a look and resolved / commented. We can leave some of the
> > `sis` specific bits, with the understanding that hopefully the
> > simulation target can be made more generic in the future. This could be
> > a potential GSoC project for Prequalification to hook it up to
> > `rtems-tools.git/tester` to make use of the capabilities we already have
> > for running simulators.
>
> The model based tests are not target-specific. You could run them with
> any (simulator) BSP.
>
Yes, I suspected that. However, the documentation is currently written
toward sis. It may be better to point the reader to another doc that
explains how to run tests, such as
https://docs.rtems.org/branches/master/user/tools/tester.html

I don't recall any documentation that discusses simulator targets specifically.

> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Add Formal Verification chapter v4

[Sebastian Huber]

On 21.09.23 17:28, Gedare Bloom wrote:
I've taken a look and resolved / commented. We can leave some of the 
`sis` specific bits, with the understanding that hopefully the 
simulation target can be made more generic in the future. This could be 
a potential GSoC project for Prequalification to hook it up to 
`rtems-tools.git/tester` to make use of the capabilities we already have 
for running simulators.


The model based tests are not target-specific. You could run them with 
any (simulator) BSP.


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

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Add Formal Verification chapter v4

[Gedare Bloom]

I've taken a look and resolved / commented. We can leave some of the
`sis` specific bits, with the understanding that hopefully the
simulation target can be made more generic in the future. This could
be a potential GSoC project for Prequalification to hook it up to
`rtems-tools.git/tester` to make use of the capabilities we already
have for running simulators.

On Thu, Sep 21, 2023 at 4:33 AM andrew.butterfi...@scss.tcd.ie
 wrote:
>
> Hi Gedare,
>  I've made some changes and raised some further queries - I don't know if you 
> get any notifications from github
>
> PR: (https://github.com/RTEMS/rtems-docs/pull/6)
>
> Regards,
>   Andrew
>
>
>
> 
> Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204
> Lero@TCD, Head of Software Foundations & Verification Research Group
> School of Computer Science and Statistics,
> Room G.39, O'Reilly Institute, Trinity College, University of Dublin
> http://www.scss.tcd.ie/Andrew.Butterfield/ 
> 
> 
>
>
>
>
>
> On 14/09/2023, 20:17, "Gedare Bloom"  > wrote:
>
>
> Thanks, I left comments on your pull request.
>
>
> On Wed, Sep 6, 2023 at 7:26 AM andrew.butterfi...@scss.tcd.ie 
> 
> mailto:andrew.butterfi...@scss.tcd.ie>> 
> wrote:
> >
> > Ping
> >
> > (I've let this sit a while - time to wake it up!)
> >
> > 
> > Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204
> > Lero@TCD, Head of Software Foundations & Verification Research Group
> > School of Computer Science and Statistics,
> > Room G.39, O'Reilly Institute, Trinity College, University of Dublin
> > http://www.scss.tcd.ie/Andrew.Butterfield/ 
> >  
> >  
> > 
> > 
> >
> >
> >
> >
> >
> >
> >
> >
> > -Original Message-
> > From: devel mailto:devel-boun...@rtems.org> 
> > >> on 
> > behalf of "andrew.butterfi...@scss.tcd.ie 
> >  
> >  > >"  >  
> >  > >>
> > Date: Tuesday 18 July 2023 at 13:54
> > To: "rtems-de...@rtems.org  
> > >" 
> > mailto:rtems-de...@rtems.org> 
> > >>
> > Subject: Add Formal Verification chapter v4
> >
> >
> > Dear all,
> > I've attached a patch-set for v4 of the proposal to add a formal 
> > verification chapter to the Software Engineering manual.
> > (I can’t do git-mail)
> >
> >
> > I've setup a pull-request at https://github.com/RTEMS/rtems-docs/pull/6 
> >  
> >  
> >  for review purposes.
> >
> >
> > Regards,
> > Andrew
> > 
> > Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204
> > Lero@TCD, Head of Software Foundations & Verification Research Group
> > School of Computer Science and Statistics,
> > Room G.39, O'Reilly Institute, Trinity College, University of Dublin
> > http://www.scss.tcd.ie/Andrew.Butterfield/ 
> >  
> >  
> >  
> >  
> >  
> >  
> > 
> > 
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2 8/9] bsps/leon3: leon3_counter_use_irqamp_timestamp()

[Sebastian Huber]

Simplify leon3_counter_use_irqamp_timestamp().

Update #4954.
---
 bsps/sparc/leon3/start/cpucounter.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/bsps/sparc/leon3/start/cpucounter.c 
b/bsps/sparc/leon3/start/cpucounter.c
index dcf8d15a65..db4f566021 100644
--- a/bsps/sparc/leon3/start/cpucounter.c
+++ b/bsps/sparc/leon3/start/cpucounter.c
@@ -165,11 +165,7 @@ static void leon3_counter_use_irqamp_timestamp(
 
   tc->counter_register = _ts->itcnt;
   tc->base.tc_get_timecount = leon3_timecounter_get_counter_up;
-#if defined(LEON3_PLB_FREQUENCY_DEFINED_BY_GPTIMER)
   tc->base.tc_frequency = leon3_processor_local_bus_frequency();
-#else
-  tc->base.tc_frequency = ambapp_freq_get(ambapp_plb(), LEON3_IrqCtrl_Adev);
-#endif
 }
 
 #endif /* LEON3_IRQAMP_PROBE_TIMESTAMP */
-- 
2.35.3

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

[PATCH v2 9/9] bsps/leon3: Use DSU time tag for GR712RC

[Sebastian Huber]

Update #4954.
---
 bsps/sparc/leon3/start/cpucounter.c| 62 --
 spec/build/bsps/sparc/leon3/grp.yml|  2 +
 spec/build/bsps/sparc/leon3/optdsubase.yml | 24 +
 3 files changed, 84 insertions(+), 4 deletions(-)
 create mode 100644 spec/build/bsps/sparc/leon3/optdsubase.yml

diff --git a/bsps/sparc/leon3/start/cpucounter.c 
b/bsps/sparc/leon3/start/cpucounter.c
index db4f566021..35db839cd4 100644
--- a/bsps/sparc/leon3/start/cpucounter.c
+++ b/bsps/sparc/leon3/start/cpucounter.c
@@ -77,7 +77,57 @@ RTEMS_ALIAS(_CPU_Counter_read) uint32_t 
_SPARC_Counter_read_ISR_disabled(void);
 
 #define LEON3_GET_TIMECOUNT_INIT leon3_timecounter_get_processor_up_counter
 
-#else /* !LEON3_HAS_ASR_22_23_UP_COUNTER */
+#elif defined(LEON3_DSU_BASE)
+
+/*
+ * In general, using the Debug Support Unit (DSU) is not recommended.  Before
+ * you use it, check that it is available in flight models and that the time
+ * tag register is implemented in radiation hardened flip-flops.  For the
+ * GR712RC, this is the case.
+ */
+
+/* This value is specific to the GR712RC */
+#define LEON3_DSU_TIME_TAG_ZERO_BITS 2
+
+static uint32_t leon3_read_dsu_time_tag(void)
+{
+  uint32_t value;
+  volatile uint32_t *reg;
+
+  /* Use a load with a forced cache miss */
+  reg = (uint32_t *) (LEON3_DSU_BASE + 8);
+  __asm__ volatile (
+"\tlda\t[%1]1, %0"
+: "="(value)
+: "r"(reg)
+  );
+  return value << LEON3_DSU_TIME_TAG_ZERO_BITS;
+}
+
+static uint32_t leon3_timecounter_get_dsu_time_tag(
+  struct timecounter *tc
+)
+{
+  (void) tc;
+  return leon3_read_dsu_time_tag();
+}
+
+CPU_Counter_ticks _CPU_Counter_read(void)
+{
+  return leon3_read_dsu_time_tag();
+}
+
+RTEMS_ALIAS(_CPU_Counter_read) uint32_t _SPARC_Counter_read_ISR_disabled(void);
+
+static void leon3_counter_use_dsu_time_tag(leon3_timecounter *tc)
+{
+  tc->base.tc_frequency =
+leon3_processor_local_bus_frequency() << LEON3_DSU_TIME_TAG_ZERO_BITS;
+}
+
+#define LEON3_GET_TIMECOUNT_INIT leon3_timecounter_get_dsu_time_tag
+
+#else /* !LEON3_HAS_ASR_22_23_UP_COUNTER && !LEON3_DSU_BASE */
 
 /*
  * This is a workaround for:
@@ -169,7 +219,7 @@ static void leon3_counter_use_irqamp_timestamp(
 }
 
 #endif /* LEON3_IRQAMP_PROBE_TIMESTAMP */
-#endif /* LEON3_HAS_ASR_22_23_UP_COUNTER */
+#endif /* LEON3_HAS_ASR_22_23_UP_COUNTER || LEON3_DSU_BASE */
 
 leon3_timecounter leon3_timecounter_instance = {
   .base = {
@@ -192,7 +242,11 @@ static void leon3_counter_initialize(void)
   leon3_up_counter_enable();
   leon3_counter_use_asr_22_23_up_counter(_timecounter_instance);
 
-#else /* !LEON3_HAS_ASR_22_23_UP_COUNTER */
+#elif defined(LEON3_DSU_BASE)
+
+  leon3_counter_use_dsu_time_tag(_timecounter_instance);
+
+#else /* !LEON3_HAS_ASR_22_23_UP_COUNTER && !LEON3_DSU_BASE */
 
   /* Try to find the best CPU counter available */
 
@@ -235,7 +289,7 @@ static void leon3_counter_initialize(void)
   }
 #endif
 
-#endif /* LEON3_HAS_ASR_22_23_UP_COUNTER */
+#endif /* LEON3_HAS_ASR_22_23_UP_COUNTER || LEON3_DSU_BASE */
 }
 
 RTEMS_SYSINIT_ITEM(
diff --git a/spec/build/bsps/sparc/leon3/grp.yml 
b/spec/build/bsps/sparc/leon3/grp.yml
index d708a65735..a995ccc60a 100644
--- a/spec/build/bsps/sparc/leon3/grp.yml
+++ b/spec/build/bsps/sparc/leon3/grp.yml
@@ -38,6 +38,8 @@ links:
   uid: optasrupcnt
 - role: build-dependency
   uid: optasrupcntprobe
+- role: build-dependency
+  uid: optdsubase
 - role: build-dependency
   uid: optgptimerbase
 - role: build-dependency
diff --git a/spec/build/bsps/sparc/leon3/optdsubase.yml 
b/spec/build/bsps/sparc/leon3/optdsubase.yml
new file mode 100644
index 00..5fd0b9bfb7
--- /dev/null
+++ b/spec/build/bsps/sparc/leon3/optdsubase.yml
@@ -0,0 +1,24 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+copyrights:
+- Copyright (C) 2023 embedded brains GmbH & Co. KG
+actions:
+- get-integer: null
+- format-and-define: null
+build-type: option
+default:
+- enabled-by: sparc/gr712rc
+  value: 0x9000
+enabled-by: true
+format: '{:#010x}'
+links: []
+name: LEON3_DSU_BASE
+description: |
+  This option defines the base address of the DSU register block used by
+  the clock driver and CPU counter implementation.
+
+  In general, using the Debug Support Unit (DSU) is not recommended for the
+  clock driver and CPU counter implementation.  Before you use it, check that
+  it is available in flight models and that the time tag register is
+  implemented in radiation hardened flip-flops.  For the GR712RC, this is the
+  case.
+type: build
-- 
2.35.3

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

[PATCH v2 6/9] bsps/leon3: Move code blocks

[Sebastian Huber]

Move code blocks to simplify C preprocessor usage.

Update #4954.
---
 bsps/sparc/leon3/start/cpucounter.c | 110 ++--
 1 file changed, 57 insertions(+), 53 deletions(-)

diff --git a/bsps/sparc/leon3/start/cpucounter.c 
b/bsps/sparc/leon3/start/cpucounter.c
index 71262ff210..a923c2fe63 100644
--- a/bsps/sparc/leon3/start/cpucounter.c
+++ b/bsps/sparc/leon3/start/cpucounter.c
@@ -48,8 +48,22 @@ static uint32_t leon3_timecounter_get_asr_22_23_up_counter(
 {
   return leon3_up_counter_low();
 }
+
+static void leon3_counter_use_asr_22_23_up_counter(leon3_timecounter *tc)
+{
+  tc->base.tc_get_timecount = leon3_timecounter_get_asr_22_23_up_counter;
+  tc->base.tc_frequency = leon3_up_counter_frequency();
+}
 #endif
 
+/*
+ * The following code blocks provide different CPU counter implementations.
+ * The implementation used is defined by build configuration options.  For a
+ * particular chip, the best available hardware counter module may be selected
+ * by build configuration options.  The default implementation tries to select
+ * the best module at runtime.
+ */
+
 #if defined(LEON3_HAS_ASR_22_23_UP_COUNTER)
 
 CPU_Counter_ticks _CPU_Counter_read(void)
@@ -91,7 +105,31 @@ static uint32_t leon3_timecounter_get_counter_down(struct 
timecounter *base)
   return -(*tc->counter_register);
 }
 
+static void leon3_counter_use_gptimer(
+  leon3_timecounter *tc,
+  gptimer *gpt
+)
+{
+  gptimer_timer *timer;
+
+  timer = >timer[LEON3_COUNTER_GPTIMER_INDEX];
+
+  /* Make timer free-running */
+  grlib_store_32(>trldval, 0x);
+  grlib_store_32(>tctrl, GPTIMER_TCTRL_EN | GPTIMER_TCTRL_RS);
+
+  tc->counter_register = >tcntval;
+  tc->base.tc_get_timecount = leon3_timecounter_get_counter_down;
+#if defined(LEON3_PLB_FREQUENCY_DEFINED_BY_GPTIMER)
+  tc->base.tc_frequency = LEON3_GPTIMER_0_FREQUENCY_SET_BY_BOOT_LOADER;
+#else
+  tc->base.tc_frequency = ambapp_freq_get(ambapp_plb(), LEON3_Timer_Adev) /
+(grlib_load_32(>sreload) + 1);
+#endif
+}
+
 #if defined(LEON3_IRQAMP_PROBE_TIMESTAMP)
+
 static uint32_t leon3_timecounter_get_counter_up(struct timecounter *base)
 {
   leon3_timecounter *tc;
@@ -99,8 +137,25 @@ static uint32_t leon3_timecounter_get_counter_up(struct 
timecounter *base)
   tc = (leon3_timecounter *) base;
   return *tc->counter_register;
 }
+
+static void leon3_counter_use_irqamp_timestamp(
+  leon3_timecounter *tc,
+  irqamp_timestamp *irqmp_ts
+)
+{
+  /* Enable interrupt timestamping for an arbitrary interrupt line */
+  grlib_store_32(_ts->itstmpc, IRQAMP_ITSTMPC_TSISEL(1));
+
+  tc->counter_register = _ts->itcnt;
+  tc->base.tc_get_timecount = leon3_timecounter_get_counter_up;
+#if defined(LEON3_PLB_FREQUENCY_DEFINED_BY_GPTIMER)
+  tc->base.tc_frequency = leon3_processor_local_bus_frequency();
+#else
+  tc->base.tc_frequency = ambapp_freq_get(ambapp_plb(), LEON3_IrqCtrl_Adev);
 #endif
+}
 
+#endif /* LEON3_IRQAMP_PROBE_TIMESTAMP */
 #endif /* LEON3_HAS_ASR_22_23_UP_COUNTER */
 
 static uint32_t leon3_timecounter_get_dummy(struct timecounter *base)
@@ -128,59 +183,6 @@ uint32_t _CPU_Counter_frequency(void)
   return leon3_timecounter_instance.base.tc_frequency;
 }
 
-#if defined(LEON3_HAS_ASR_22_23_UP_COUNTER) || \
-   defined(LEON3_PROBE_ASR_22_23_UP_COUNTER)
-static void leon3_counter_use_asr_22_23_up_counter(leon3_timecounter *tc)
-{
-  tc->base.tc_get_timecount = leon3_timecounter_get_asr_22_23_up_counter;
-  tc->base.tc_frequency = leon3_up_counter_frequency();
-}
-#endif
-
-#if defined(LEON3_IRQAMP_PROBE_TIMESTAMP)
-static void leon3_counter_use_irqamp_timestamp(
-  leon3_timecounter *tc,
-  irqamp_timestamp *irqmp_ts
-)
-{
-  /* Enable interrupt timestamping for an arbitrary interrupt line */
-  grlib_store_32(_ts->itstmpc, IRQAMP_ITSTMPC_TSISEL(1));
-
-  tc->counter_register = _ts->itcnt;
-  tc->base.tc_get_timecount = leon3_timecounter_get_counter_up;
-#if defined(LEON3_PLB_FREQUENCY_DEFINED_BY_GPTIMER)
-  tc->base.tc_frequency = leon3_processor_local_bus_frequency();
-#else
-  tc->base.tc_frequency = ambapp_freq_get(ambapp_plb(), LEON3_IrqCtrl_Adev);
-#endif
-}
-#endif
-
-#if !defined(LEON3_HAS_ASR_22_23_UP_COUNTER)
-static void leon3_counter_use_gptimer(
-  leon3_timecounter *tc,
-  gptimer *gpt
-)
-{
-  gptimer_timer *timer;
-
-  timer = >timer[LEON3_COUNTER_GPTIMER_INDEX];
-
-  /* Make timer free-running */
-  grlib_store_32(>trldval, 0x);
-  grlib_store_32(>tctrl, GPTIMER_TCTRL_EN | GPTIMER_TCTRL_RS);
-
-  tc->counter_register = >tcntval;
-  tc->base.tc_get_timecount = leon3_timecounter_get_counter_down;
-#if defined(LEON3_PLB_FREQUENCY_DEFINED_BY_GPTIMER)
-  tc->base.tc_frequency = LEON3_GPTIMER_0_FREQUENCY_SET_BY_BOOT_LOADER;
-#else
-  tc->base.tc_frequency = ambapp_freq_get(ambapp_plb(), LEON3_Timer_Adev) /
-(grlib_load_32(>sreload) + 1);
-#endif
-}
-#endif
-
 static void leon3_counter_initialize(void)
 {
 #if defined(LEON3_HAS_ASR_22_23_UP_COUNTER)
@@ -190,6 +192,8 @@ static void leon3_counter_initialize(void)
 
 #else /* 

[PATCH v2 7/9] bsps/leon3: Statically initialize get timecount

[Sebastian Huber]

Update #4954.
---
 bsps/sparc/leon3/include/bsp/leon3.h |  2 +-
 bsps/sparc/leon3/start/cpucounter.c  | 30 +---
 2 files changed, 19 insertions(+), 13 deletions(-)

diff --git a/bsps/sparc/leon3/include/bsp/leon3.h 
b/bsps/sparc/leon3/include/bsp/leon3.h
index 4ee5531941..9376ab4ec0 100644
--- a/bsps/sparc/leon3/include/bsp/leon3.h
+++ b/bsps/sparc/leon3/include/bsp/leon3.h
@@ -321,12 +321,12 @@ typedef struct {
*/
   struct timecounter base;
 
+#if !defined(LEON3_HAS_ASR_22_23_UP_COUNTER)
   /**
* @brief This member provides a software fall-back counter.
*/
   uint32_t software_counter;
 
-#if !defined(LEON3_HAS_ASR_22_23_UP_COUNTER)
   /**
* @brief This member may reference a hardware counter register.
*/
diff --git a/bsps/sparc/leon3/start/cpucounter.c 
b/bsps/sparc/leon3/start/cpucounter.c
index a923c2fe63..dcf8d15a65 100644
--- a/bsps/sparc/leon3/start/cpucounter.c
+++ b/bsps/sparc/leon3/start/cpucounter.c
@@ -51,7 +51,9 @@ static uint32_t leon3_timecounter_get_asr_22_23_up_counter(
 
 static void leon3_counter_use_asr_22_23_up_counter(leon3_timecounter *tc)
 {
+#if !defined(LEON3_HAS_ASR_22_23_UP_COUNTER)
   tc->base.tc_get_timecount = leon3_timecounter_get_asr_22_23_up_counter;
+#endif
   tc->base.tc_frequency = leon3_up_counter_frequency();
 }
 #endif
@@ -73,6 +75,8 @@ CPU_Counter_ticks _CPU_Counter_read(void)
 
 RTEMS_ALIAS(_CPU_Counter_read) uint32_t _SPARC_Counter_read_ISR_disabled(void);
 
+#define LEON3_GET_TIMECOUNT_INIT leon3_timecounter_get_processor_up_counter
+
 #else /* !LEON3_HAS_ASR_22_23_UP_COUNTER */
 
 /*
@@ -97,6 +101,19 @@ __asm__ (
   "\t.previous\n"
 );
 
+static uint32_t leon3_timecounter_get_dummy(struct timecounter *base)
+{
+  leon3_timecounter *tc;
+  uint32_t counter;
+
+  tc = (leon3_timecounter *) base;
+  counter = tc->software_counter + 1;
+  tc->software_counter = counter;
+  return counter;
+}
+
+#define LEON3_GET_TIMECOUNT_INIT leon3_timecounter_get_dummy
+
 static uint32_t leon3_timecounter_get_counter_down(struct timecounter *base)
 {
   leon3_timecounter *tc;
@@ -158,20 +175,9 @@ static void leon3_counter_use_irqamp_timestamp(
 #endif /* LEON3_IRQAMP_PROBE_TIMESTAMP */
 #endif /* LEON3_HAS_ASR_22_23_UP_COUNTER */
 
-static uint32_t leon3_timecounter_get_dummy(struct timecounter *base)
-{
-  leon3_timecounter *tc;
-  uint32_t counter;
-
-  tc = (leon3_timecounter *) base;
-  counter = tc->software_counter + 1;
-  tc->software_counter = counter;
-  return counter;
-}
-
 leon3_timecounter leon3_timecounter_instance = {
   .base = {
-.tc_get_timecount = leon3_timecounter_get_dummy,
+.tc_get_timecount = LEON3_GET_TIMECOUNT_INIT,
 .tc_counter_mask = 0x,
 .tc_frequency = 10,
 .tc_quality = RTEMS_TIMECOUNTER_QUALITY_CLOCK_DRIVER
-- 
2.35.3

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

[PATCH v2 2/9] sparc: Move CPU counter implementation

[Sebastian Huber]

Enable a BSP-specific CPU counter implementation.

Update #4954.
---
 bsps/sparc/erc32/clock/ckinit.c   |  8 +--
 .../sparc/include/bsp/sparc-counter.h | 64 +--
 bsps/sparc/leon2/clock/ckinit.c   |  8 +--
 bsps/sparc/leon3/clock/ckinit.c   |  6 +-
 bsps/sparc/leon3/start/cpucounter.c   |  4 +-
 .../sparc/shared/start}/sparc-counter-asm.S   | 28 +++-
 cpukit/score/cpu/sparc/cpu_asm.S  |  6 +-
 .../score/cpu/sparc/include/rtems/score/cpu.h | 26 +---
 .../cpu/sparc/include/rtems/score/cpuimpl.h   |  7 ++
 spec/build/bsps/sparc/erc32/bsperc32.yml  |  2 +
 spec/build/bsps/sparc/leon2/obj.yml   |  2 +
 spec/build/bsps/sparc/leon3/obj.yml   |  2 +
 spec/build/cpukit/cpusparc.yml|  2 -
 13 files changed, 86 insertions(+), 79 deletions(-)
 rename cpukit/score/cpu/sparc/include/rtems/score/sparcimpl.h => 
bsps/sparc/include/bsp/sparc-counter.h (63%)
 rename {cpukit/score/cpu/sparc => bsps/sparc/shared/start}/sparc-counter-asm.S 
(86%)

diff --git a/bsps/sparc/erc32/clock/ckinit.c b/bsps/sparc/erc32/clock/ckinit.c
index 83cafb73c3..e8cf7188eb 100644
--- a/bsps/sparc/erc32/clock/ckinit.c
+++ b/bsps/sparc/erc32/clock/ckinit.c
@@ -26,7 +26,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 extern int CLOCK_SPEED;
 
@@ -46,7 +46,7 @@ static void erc32_clock_init( void )
   rtems_timecounter_install(tc);
 }
 
-uint32_t _CPU_Counter_frequency(void)
+uint32_t _CPU_Counter_frequency( void )
 {
   return ERC32_REAL_TIME_CLOCK_FREQUENCY;
 }
@@ -56,7 +56,7 @@ static void erc32_clock_at_tick( void )
   SPARC_Counter *counter;
   rtems_interrupt_level level;
 
-  counter = &_SPARC_Counter_mutable;
+  counter = &_SPARC_Counter;
   rtems_interrupt_local_disable(level);
 
   ERC32_Clear_interrupt( ERC32_INTERRUPT_REAL_TIME_CLOCK );
@@ -83,7 +83,7 @@ static void erc32_clock_initialize_early( void )
 ERC32_MEC_TIMER_COUNTER_RELOAD_AT_ZERO
   );
 
-  counter = &_SPARC_Counter_mutable;
+  counter = &_SPARC_Counter;
   counter->read_isr_disabled = _SPARC_Counter_read_clock_isr_disabled;
   counter->read = _SPARC_Counter_read_clock;
   counter->counter_register = _MEC.Real_Time_Clock_Counter,
diff --git a/cpukit/score/cpu/sparc/include/rtems/score/sparcimpl.h 
b/bsps/sparc/include/bsp/sparc-counter.h
similarity index 63%
rename from cpukit/score/cpu/sparc/include/rtems/score/sparcimpl.h
rename to bsps/sparc/include/bsp/sparc-counter.h
index d9be984179..c71cddf304 100644
--- a/cpukit/score/cpu/sparc/include/rtems/score/sparcimpl.h
+++ b/bsps/sparc/include/bsp/sparc-counter.h
@@ -3,13 +3,14 @@
 /**
  * @file
  *
- * @ingroup RTEMSScoreCPUSPARC
+ * @ingroup RTEMSBSPsSPARCShared
  *
- * @brief This header file provides interfaces used by the SPARC port of RTEMS.
+ * @brief This header file provides interfaces of a CPU counter implementation
+ *   for SPARC BSPs.
  */
 
 /*
- * Copyright (C) 2016, 2018 embedded brains GmbH & Co. KG
+ * Copyright (C) 2016, 2023 embedded brains GmbH & Co. KG
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
@@ -33,8 +34,8 @@
  * POSSIBILITY OF SUCH DAMAGE.
  */
 
-#ifndef _RTEMS_SCORE_SPARCIMPL_H
-#define _RTEMS_SCORE_SPARCIMPL_H
+#ifndef _BSP_SPARC_COUNTER_H
+#define _BSP_SPARC_COUNTER_H
 
 #include 
 
@@ -44,13 +45,6 @@ extern "C" {
 
 struct timecounter;
 
-/*
- * Provides a mutable alias to _SPARC_Counter for use in
- * _SPARC_Counter_initialize().  The _SPARC_Counter and _SPARC_Counter_mutable
- * are defined via the SPARC_COUNTER_DEFINITION define.
- */
-extern SPARC_Counter _SPARC_Counter_mutable;
-
 void _SPARC_Counter_at_tick_clock( void );
 
 CPU_Counter_ticks _SPARC_Counter_read_default( void );
@@ -73,33 +67,35 @@ uint32_t _SPARC_Get_timecount_clock( struct timecounter * );
 
 uint32_t _SPARC_Get_timecount_asr23( struct timecounter * );
 
+typedef CPU_Counter_ticks ( *SPARC_Counter_read )( void );
+
 /*
- * Defines the _SPARC_Counter and _SPARC_Counter_mutable global variables.
- * Place this define in the global file scope of the CPU counter support file
- * of the BSP.
+ * The SPARC processors supported by RTEMS have no built-in CPU counter
+ * support.  We have to use some hardware counter module for this purpose, for
+ * example the GPTIMER instance used by the clock driver.  The BSP must provide
+ * an implementation of the CPU counter read function.  This allows the use of
+ * dynamic hardware enumeration.
  */
+typedef struct {
+  SPARC_Counter_readread_isr_disabled;
+  SPARC_Counter_readread;
+  volatile const CPU_Counter_ticks *counter_register;
+  volatile const uint32_t  *pending_register;
+  uint32_t  pending_mask;
+  CPU_Counter_ticks accumulated;
+  CPU_Counter_ticks interval;
+} SPARC_Counter;
+
+extern SPARC_Counter _SPARC_Counter;
+
 #define 

[PATCH v2 5/9] bsps/leon3: Use custom CPU counter implementation

[Sebastian Huber]

Merge the timecounter and CPU counter support for the leon3 BSP family.
Remove now unused functions from the CPU counter support of the erc32
and leon3 BSPs.

Update #4954.
---
 bsps/sparc/include/bsp/sparc-counter.h  |  12 --
 bsps/sparc/leon3/clock/ckinit.c |   2 +-
 bsps/sparc/leon3/include/bsp/leon3.h|  26 +++-
 bsps/sparc/leon3/start/cpucounter.c | 157 ++--
 bsps/sparc/shared/start/sparc-counter-asm.S |  26 
 spec/build/bsps/sparc/leon3/obj.yml |   2 -
 6 files changed, 134 insertions(+), 91 deletions(-)

diff --git a/bsps/sparc/include/bsp/sparc-counter.h 
b/bsps/sparc/include/bsp/sparc-counter.h
index c71cddf304..bc4f2220e7 100644
--- a/bsps/sparc/include/bsp/sparc-counter.h
+++ b/bsps/sparc/include/bsp/sparc-counter.h
@@ -49,24 +49,12 @@ void _SPARC_Counter_at_tick_clock( void );
 
 CPU_Counter_ticks _SPARC_Counter_read_default( void );
 
-CPU_Counter_ticks _SPARC_Counter_read_up( void );
-
-CPU_Counter_ticks _SPARC_Counter_read_down( void );
-
 CPU_Counter_ticks _SPARC_Counter_read_clock_isr_disabled( void );
 
 CPU_Counter_ticks _SPARC_Counter_read_clock( void );
 
-CPU_Counter_ticks _SPARC_Counter_read_asr23( void );
-
-uint32_t _SPARC_Get_timecount_up( struct timecounter * );
-
-uint32_t _SPARC_Get_timecount_down( struct timecounter * );
-
 uint32_t _SPARC_Get_timecount_clock( struct timecounter * );
 
-uint32_t _SPARC_Get_timecount_asr23( struct timecounter * );
-
 typedef CPU_Counter_ticks ( *SPARC_Counter_read )( void );
 
 /*
diff --git a/bsps/sparc/leon3/clock/ckinit.c b/bsps/sparc/leon3/clock/ckinit.c
index c77fd23aff..d530f260a8 100644
--- a/bsps/sparc/leon3/clock/ckinit.c
+++ b/bsps/sparc/leon3/clock/ckinit.c
@@ -196,7 +196,7 @@ static void leon3_clock_initialize(void)
   }
 #endif
 
-  rtems_timecounter_install(_timecounter_instance);
+  rtems_timecounter_install(_timecounter_instance.base);
 }
 
 #define Clock_driver_support_initialize_hardware() \
diff --git a/bsps/sparc/leon3/include/bsp/leon3.h 
b/bsps/sparc/leon3/include/bsp/leon3.h
index a5eecdded7..4ee5531941 100644
--- a/bsps/sparc/leon3/include/bsp/leon3.h
+++ b/bsps/sparc/leon3/include/bsp/leon3.h
@@ -9,7 +9,7 @@
  */
 
 /*
- * Copyright (C) 2014, 2021 embedded brains GmbH & Co. KG
+ * Copyright (C) 2014, 2023 embedded brains GmbH & Co. KG
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
@@ -312,12 +312,34 @@ static inline uint32_t leon3_up_counter_frequency( void )
 extern apbuart *leon3_debug_uart;
 #endif
 
+/**
+ * @brief Represents the LEON3-specific timecounter.
+ */
+typedef struct {
+  /**
+   * @brief This member contains the base timecounter.
+   */
+  struct timecounter base;
+
+  /**
+   * @brief This member provides a software fall-back counter.
+   */
+  uint32_t software_counter;
+
+#if !defined(LEON3_HAS_ASR_22_23_UP_COUNTER)
+  /**
+   * @brief This member may reference a hardware counter register.
+   */
+  volatile uint32_t *counter_register;
+#endif
+} leon3_timecounter;
+
 /**
  * @brief Provides the LEON3-specific timecounter.
  *
  * It is also used by the CPU counter implementation.
  */
-extern struct timecounter leon3_timecounter_instance;
+extern leon3_timecounter leon3_timecounter_instance;
 
 /** @} */
 
diff --git a/bsps/sparc/leon3/start/cpucounter.c 
b/bsps/sparc/leon3/start/cpucounter.c
index 61b767568d..71262ff210 100644
--- a/bsps/sparc/leon3/start/cpucounter.c
+++ b/bsps/sparc/leon3/start/cpucounter.c
@@ -9,7 +9,7 @@
  */
 
 /*
- * Copyright (C) 2014, 2018 embedded brains GmbH & Co. KG
+ * Copyright (C) 2014, 2023 embedded brains GmbH & Co. KG
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
@@ -39,80 +39,143 @@
 #include 
 #include 
 #include 
-#include 
 
-struct timecounter leon3_timecounter_instance = {
-  .tc_counter_mask = 0x,
-  .tc_frequency = 10,
-  .tc_quality = RTEMS_TIMECOUNTER_QUALITY_CLOCK_DRIVER
+#if defined(LEON3_HAS_ASR_22_23_UP_COUNTER) || \
+  defined(LEON3_PROBE_ASR_22_23_UP_COUNTER)
+static uint32_t leon3_timecounter_get_asr_22_23_up_counter(
+  struct timecounter *tc
+)
+{
+  return leon3_up_counter_low();
+}
+#endif
+
+#if defined(LEON3_HAS_ASR_22_23_UP_COUNTER)
+
+CPU_Counter_ticks _CPU_Counter_read(void)
+{
+  return leon3_up_counter_low();
+}
+
+RTEMS_ALIAS(_CPU_Counter_read) uint32_t _SPARC_Counter_read_ISR_disabled(void);
+
+#else /* !LEON3_HAS_ASR_22_23_UP_COUNTER */
+
+/*
+ * This is a workaround for:
+ * https://gcc.gnu.org/bugzilla//show_bug.cgi?id=69027
+ */
+__asm__ (
+  "\t.section\t\".text\"\n"
+  "\t.align\t4\n"
+  "\t.globl\t_CPU_Counter_read\n"
+  "\t.globl\t_SPARC_Counter_read_ISR_disabled\n"
+  "\t.type\t_CPU_Counter_read, #function\n"
+  "\t.type\t_SPARC_Counter_read_ISR_disabled, #function\n"
+  "_CPU_Counter_read:\n"
+  "_SPARC_Counter_read_ISR_disabled:\n"
+  

[PATCH v2 3/9] bsps/leon3: Make GPTIMER fall back mandatory

[Sebastian Huber]

Using the auto reload counter which generates the clock ticks for the
timecounter or CPU counter is quite difficult and only works in
uniprocessor configurations.

Update #4954.
---
 bsps/sparc/leon3/clock/ckinit.c  | 35 ++--
 bsps/sparc/leon3/include/bsp/leon3.h |  4 
 bsps/sparc/leon3/start/cpucounter.c  |  2 +-
 3 files changed, 3 insertions(+), 38 deletions(-)

diff --git a/bsps/sparc/leon3/clock/ckinit.c b/bsps/sparc/leon3/clock/ckinit.c
index eea4649fa3..d800f01e4a 100644
--- a/bsps/sparc/leon3/clock/ckinit.c
+++ b/bsps/sparc/leon3/clock/ckinit.c
@@ -69,19 +69,6 @@ static struct timecounter leon3_tc;
 
 static void leon3_tc_tick_default(void)
 {
-#if !defined(RTEMS_SMP)
-  SPARC_Counter *counter;
-  rtems_interrupt_level level;
-
-  counter = &_SPARC_Counter;
-  rtems_interrupt_local_disable(level);
-
-  grlib_store_32(_IrqCtrl_Regs->iclear, counter->pending_mask);
-  counter->accumulated += counter->interval;
-
-  rtems_interrupt_local_enable(level);
-#endif
-
   rtems_timecounter_tick();
 }
 
@@ -238,29 +225,11 @@ static void leon3_clock_use_gptimer(
   gptimer_timer *timer
 )
 {
-#ifdef RTEMS_SMP
   /*
-   * The GR712RC for example has no timestamp unit in the interrupt
-   * controller.  At least on SMP configurations we must use a second timer
-   * in free running mode for the timecounter.  The timer is initialized by
-   * leon3_counter_initialize().
+   * As a fall back, use a second timer in free-running mode for the
+   * timecounter.  The timer is initialized by leon3_counter_initialize().
*/
   tc->tc_get_timecount = _SPARC_Get_timecount_down;
-#else
-  SPARC_Counter *counter;
-
-  counter = &_SPARC_Counter;
-  counter->read_isr_disabled = _SPARC_Counter_read_clock_isr_disabled;
-  counter->read = _SPARC_Counter_read_clock;
-  counter->counter_register = >tcntval;
-  counter->pending_register = _IrqCtrl_Regs->ipend;
-  counter->pending_mask = UINT32_C(1) << clkirq;
-  counter->accumulated = rtems_configuration_get_microseconds_per_tick();
-  counter->interval = rtems_configuration_get_microseconds_per_tick();
-
-  tc->tc_get_timecount = _SPARC_Get_timecount_clock;
-#endif
-
   tc->tc_frequency = LEON3_GPTIMER_0_FREQUENCY_SET_BY_BOOT_LOADER,
 
   rtems_timecounter_install(tc);
diff --git a/bsps/sparc/leon3/include/bsp/leon3.h 
b/bsps/sparc/leon3/include/bsp/leon3.h
index fdb43b5817..84790b590f 100644
--- a/bsps/sparc/leon3/include/bsp/leon3.h
+++ b/bsps/sparc/leon3/include/bsp/leon3.h
@@ -188,11 +188,7 @@ static inline uint32_t leon3_get_cpu_count( const irqamp 
*regs )
  * @brief This constant defines the index of the GPTIMER timer used by the
  *   CPU counter if the CPU counter uses the GPTIMER.
  */
-#if defined(RTEMS_SMP)
 #define LEON3_COUNTER_GPTIMER_INDEX ( LEON3_CLOCK_INDEX + 1 )
-#else
-#define LEON3_COUNTER_GPTIMER_INDEX LEON3_CLOCK_INDEX
-#endif
 
 /**
  * @brief This constant defines the frequency set by the boot loader of the
diff --git a/bsps/sparc/leon3/start/cpucounter.c 
b/bsps/sparc/leon3/start/cpucounter.c
index a6db7677a3..374e43c9b1 100644
--- a/bsps/sparc/leon3/start/cpucounter.c
+++ b/bsps/sparc/leon3/start/cpucounter.c
@@ -89,7 +89,7 @@ static void leon3_counter_use_gptimer(SPARC_Counter *counter, 
gptimer *gpt)
   counter->read = _SPARC_Counter_read_down;
   counter->counter_register = >tcntval;
 
-  /* Make timer free running */
+  /* Make timer free-running */
   grlib_store_32(>trldval, 0x);
   grlib_store_32(>tctrl, GPTIMER_TCTRL_EN | GPTIMER_TCTRL_RS);
 
-- 
2.35.3

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

[PATCH v2 4/9] bsps/leon3: Simplify clock and CPU counter

[Sebastian Huber]

Share the timecounter instance between the clock and the CPU counter.
This greatly simplifies the clock driver since we have to do the device
selection only in one place, the CPU counter support.

Update #4954.
---
 bsps/sparc/leon3/clock/ckinit.c  | 130 +--
 bsps/sparc/leon3/include/bsp/leon3.h |   9 ++
 bsps/sparc/leon3/start/cpucounter.c  |  46 +++---
 3 files changed, 62 insertions(+), 123 deletions(-)

diff --git a/bsps/sparc/leon3/clock/ckinit.c b/bsps/sparc/leon3/clock/ckinit.c
index d800f01e4a..c77fd23aff 100644
--- a/bsps/sparc/leon3/clock/ckinit.c
+++ b/bsps/sparc/leon3/clock/ckinit.c
@@ -16,7 +16,7 @@
  *  COPYRIGHT (c) 2004.
  *  Gaisler Research.
  *
- *  Copyright (C) 2014, 2018 embedded brains GmbH & Co. KG
+ *  Copyright (C) 2014, 2023 embedded brains GmbH & Co. KG
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
@@ -47,13 +47,8 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
-#if !defined(LEON3_PLB_FREQUENCY_DEFINED_BY_GPTIMER)
-#include 
-#endif
-
 /* The LEON3 BSP Timer driver can rely on the Driver Manager if the
  * DrvMgr is initialized during startup. Otherwise the classic driver
  * must be used.
@@ -65,17 +60,26 @@
 /* LEON3 Timer system interrupt number */
 static int clkirq;
 
-static struct timecounter leon3_tc;
+#if defined(RTEMS_PROFILING) && \
+  (defined(LEON3_HAS_ASR_22_23_UP_COUNTER) || \
+ defined(LEON3_PROBE_ASR_22_23_UP_COUNTER) || \
+ defined(LEON3_IRQAMP_PROBE_TIMESTAMP))
+
+#define LEON3_CLOCK_PROBE_IRQAMP_TIMESTAMP
+
+#define IRQMP_TIMESTAMP_S1_S2 ((1U << 25) | (1U << 26))
 
 static void leon3_tc_tick_default(void)
 {
   rtems_timecounter_tick();
 }
 
-#if defined(RTEMS_PROFILING)
 static void (*leon3_tc_tick)(void) = leon3_tc_tick_default;
 
-#define IRQMP_TIMESTAMP_S1_S2 ((1U << 25) | (1U << 26))
+static void leon3_tc_do_tick(void)
+{
+  (*leon3_tc_tick)();
+}
 
 static void leon3_tc_tick_irqmp_timestamp(void)
 {
@@ -124,16 +128,12 @@ static void leon3_tc_tick_irqmp_timestamp_init(void)
 
   rtems_timecounter_tick();
 }
-#endif /* RTEMS_PROFILING */
-
+#else
 static void leon3_tc_do_tick(void)
 {
-#if defined(RTEMS_PROFILING)
-  (*leon3_tc_tick)();
-#else
-  leon3_tc_tick_default();
-#endif
+  rtems_timecounter_tick();
 }
+#endif
 
 #define Adjust_clkirq_for_node() do { clkirq += LEON3_CLOCK_INDEX; } while(0)
 
@@ -175,74 +175,9 @@ static void 
bsp_clock_handler_install(rtems_interrupt_handler isr)
 #define Clock_driver_support_set_interrupt_affinity(online_processors) \
   bsp_interrupt_set_affinity(clkirq, online_processors)
 
-#if defined(LEON3_HAS_ASR_22_23_UP_COUNTER) || \
-   defined(LEON3_PROBE_ASR_22_23_UP_COUNTER)
-static void leon3_clock_use_up_counter(struct timecounter *tc)
-{
-  tc->tc_get_timecount = _SPARC_Get_timecount_asr23;
-  tc->tc_frequency = leon3_up_counter_frequency();
-
-#if defined(RTEMS_PROFILING)
-  if (irqamp_get_timestamp_registers(LEON3_IrqCtrl_Regs) != NULL) {
-leon3_tc_tick = leon3_tc_tick_irqmp_timestamp_init;
-  }
-#endif
-
-  rtems_timecounter_install(tc);
-}
-#endif
-
-#if defined(LEON3_IRQAMP_PROBE_TIMESTAMP)
-static void leon3_clock_use_irqamp_timestamp(
-  struct timecounter *tc,
-  irqamp_timestamp *irqmp_ts
-)
-{
-  tc->tc_get_timecount = _SPARC_Get_timecount_up;
-#if defined(LEON3_PLB_FREQUENCY_DEFINED_BY_GPTIMER)
-  tc->tc_frequency = leon3_processor_local_bus_frequency();
-#else
-  tc->tc_frequency = ambapp_freq_get(ambapp_plb(), LEON3_Timer_Adev);
-#endif
-
-#if defined(RTEMS_PROFILING)
-  leon3_tc_tick = leon3_tc_tick_irqmp_timestamp_init;
-#endif
-
-  /*
-   * At least one TSISEL field must be non-zero to enable the timestamp
-   * counter.  Use an arbitrary interrupt source.
-   */
-  grlib_store_32(_ts->itstmpc, IRQAMP_ITSTMPC_TSISEL(1));
-
-  rtems_timecounter_install(tc);
-}
-#endif
-
-#if !defined(LEON3_HAS_ASR_22_23_UP_COUNTER)
-static void leon3_clock_use_gptimer(
-  struct timecounter *tc,
-  gptimer_timer *timer
-)
-{
-  /*
-   * As a fall back, use a second timer in free-running mode for the
-   * timecounter.  The timer is initialized by leon3_counter_initialize().
-   */
-  tc->tc_get_timecount = _SPARC_Get_timecount_down;
-  tc->tc_frequency = LEON3_GPTIMER_0_FREQUENCY_SET_BY_BOOT_LOADER,
-
-  rtems_timecounter_install(tc);
-}
-#endif
-
 static void leon3_clock_initialize(void)
 {
-#if defined(LEON3_IRQAMP_PROBE_TIMESTAMP)
-  irqamp_timestamp *irqmp_ts;
-#endif
   gptimer_timer *timer;
-  struct timecounter *tc;
 
   timer = _Timer_Regs->timer[LEON3_CLOCK_INDEX];
 
@@ -255,36 +190,13 @@ static void leon3_clock_initialize(void)
 GPTIMER_TCTRL_EN | GPTIMER_TCTRL_RS | GPTIMER_TCTRL_LD | GPTIMER_TCTRL_IE
   );
 
-  tc = _tc;
-  tc->tc_counter_mask = 0x;
-  tc->tc_quality = RTEMS_TIMECOUNTER_QUALITY_CLOCK_DRIVER;
-
-#if defined(LEON3_HAS_ASR_22_23_UP_COUNTER)
-  leon3_up_counter_enable();
-  leon3_clock_use_up_counter(tc);
-#else /* 

[PATCH v2 0/9] sparc: Simplify clock drivers and CPU counter

[Sebastian Huber]

This patch set simplifies the clock drivers and CPU counter
implementations of the sparc BSPs.  For the GR712RC the Debug Support
Unit (DSU) is used as a performance optimization.

v2:

Improve code clarity.

Sebastian Huber (9):
  bsps/leon3: Optional IRQ(A)MP timestamp support
  sparc: Move CPU counter implementation
  bsps/leon3: Make GPTIMER fall back mandatory
  bsps/leon3: Simplify clock and CPU counter
  bsps/leon3: Use custom CPU counter implementation
  bsps/leon3: Move code blocks
  bsps/leon3: Statically initialize get timecount
  bsps/leon3: leon3_counter_use_irqamp_timestamp()
  bsps/leon3: Use DSU time tag for GR712RC

 bsps/include/bsp/fatal.h  |   1 -
 bsps/sparc/erc32/clock/ckinit.c   |   8 +-
 .../sparc/include/bsp/sparc-counter.h |  74 +++---
 bsps/sparc/leon2/clock/ckinit.c   |   8 +-
 bsps/sparc/leon3/clock/ckinit.c   | 163 ++--
 bsps/sparc/leon3/include/bsp/leon3.h  |  37 ++-
 bsps/sparc/leon3/start/cpucounter.c   | 241 ++
 .../sparc/shared/start}/sparc-counter-asm.S   |  54 ++--
 cpukit/score/cpu/sparc/cpu_asm.S  |   6 +-
 .../score/cpu/sparc/include/rtems/score/cpu.h |  26 +-
 .../cpu/sparc/include/rtems/score/cpuimpl.h   |   7 +
 spec/build/bsps/sparc/erc32/bsperc32.yml  |   2 +
 spec/build/bsps/sparc/leon2/obj.yml   |   2 +
 spec/build/bsps/sparc/leon3/grp.yml   |   2 +
 spec/build/bsps/sparc/leon3/optdsubase.yml|  24 ++
 spec/build/cpukit/cpusparc.yml|   2 -
 16 files changed, 347 insertions(+), 310 deletions(-)
 rename cpukit/score/cpu/sparc/include/rtems/score/sparcimpl.h => 
bsps/sparc/include/bsp/sparc-counter.h (54%)
 rename {cpukit/score/cpu/sparc => bsps/sparc/shared/start}/sparc-counter-asm.S 
(83%)
 create mode 100644 spec/build/bsps/sparc/leon3/optdsubase.yml

-- 
2.35.3

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

[PATCH v2 1/9] bsps/leon3: Optional IRQ(A)MP timestamp support

[Sebastian Huber]

This is necessary to run the tests on SIS with profiling enabled.

Update #4954.
---
 bsps/include/bsp/fatal.h| 1 -
 bsps/sparc/leon3/clock/ckinit.c | 6 ++
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/bsps/include/bsp/fatal.h b/bsps/include/bsp/fatal.h
index 4b7d0f6ced..1726bfea54 100644
--- a/bsps/include/bsp/fatal.h
+++ b/bsps/include/bsp/fatal.h
@@ -91,7 +91,6 @@ typedef enum {
   LEON3_FATAL_CLOCK_INITIALIZATION,
   LEON3_FATAL_INVALID_CACHE_CONFIG_BOOT_PROCESSOR,
   LEON3_FATAL_INVALID_CACHE_CONFIG_SECONDARY_PROCESSOR,
-  LEON3_FATAL_CLOCK_NO_IRQMP_TIMESTAMP_SUPPORT,
 
   /* LPC24XX fatal codes */
   LPC24XX_FATAL_PL111_SET_UP = BSP_FATAL_CODE_BLOCK(3),
diff --git a/bsps/sparc/leon3/clock/ckinit.c b/bsps/sparc/leon3/clock/ckinit.c
index c335652a56..cff2991e60 100644
--- a/bsps/sparc/leon3/clock/ckinit.c
+++ b/bsps/sparc/leon3/clock/ckinit.c
@@ -196,11 +196,9 @@ static void leon3_clock_use_up_counter(struct timecounter 
*tc)
   tc->tc_frequency = leon3_up_counter_frequency();
 
 #if defined(RTEMS_PROFILING)
-  if (irqamp_get_timestamp_registers(LEON3_IrqCtrl_Regs) == NULL) {
-bsp_fatal(LEON3_FATAL_CLOCK_NO_IRQMP_TIMESTAMP_SUPPORT);
+  if (irqamp_get_timestamp_registers(LEON3_IrqCtrl_Regs) != NULL) {
+leon3_tc_tick = leon3_tc_tick_irqmp_timestamp_init;
   }
-
-  leon3_tc_tick = leon3_tc_tick_irqmp_timestamp_init;
 #endif
 
   rtems_timecounter_install(tc);
-- 
2.35.3

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

Re: [PATCH 1/2] cpukit/jffs2: Set extracted nodes off-chain

[Sebastian Huber]

On 21.09.23 17:06, Kinsey Moore wrote:
On Thu, Sep 21, 2023 at 10:01 AM Sebastian Huber 
> wrote:


On 21.09.23 16:52, Kinsey Moore wrote:
 > On Thu, Sep 21, 2023 at 9:47 AM Sebastian Huber
 > mailto:sebastian.hu...@embedded-brains.de>
 > >> wrote:
 >
 >     On 20.09.23 20:35, Kinsey Moore wrote:
 >     [...]
 >      > @@ -1306,8 +1307,22 @@ static void process_delayed_work(void)
 >      >       while (!rtems_chain_is_tail(_work_chain,
node)) {
 >      >               work = (struct delayed_work*) node;
 >      >               rtems_chain_node* next_node =
rtems_chain_next(node);
 >      > +
 >      > +             /*
 >      > +              * Don't leave extracted node exposed to other
 >     operations
 >      > +              * under RTEMS_DEBUG
 >      > +              */
 >      > +#ifdef RTEMS_DEBUG
 >      > +             mutex_lock(_work_mutex);
 >      > +#endif
 >      >               rtems_chain_extract(node);
 >      > +#ifdef RTEMS_DEBUG
 >      > +             node->next = node;
 >      > +             mutex_unlock(_work_mutex);
 >      > +#endif
 >      > +
 >      >               work->callback(>work);
 >      > +             rtems_chain_set_off_chain(node);
 >      >               node = next_node;
 >      >       }
 >      >   }
 >
 >     This change makes no sense to me. The code should work
regardless if
 >     RTEMS_DEBUG is defined or not.
 >
 >
 > RTEMS_DEBUG introduces a behavioral change in
rtems_chain_extract() such
 > that extracted nodes are automatically set off-chain. When
RTEMS_DEBUG
 > is not set, node->next is left untouched. This has to be managed
because
 > this code needs the node to remain on-chain so that it is not
re-queued
 > during the operation.

Yes, but while a node is on a chain you must not call
rtems_chain_set_off_chain(). If you want to use the off-chain state,
then you have to use this:

rtems_chain_extract(node);
rtems_chain_set_off_chain(node);

or

rtems_chain_extract_unprotected(node);
rtems_chain_set_off_chain(node);

The automatic set off-chain in RTEMS_DEBUG is just to ensure that basic
chain operations are used in the right state.


Yes, there is no behavior here where rtems_chain_set_off_chain() is 
being called on a node that is still in a chain. This section of code is 
entirely managing the side-effect of RTEMS_DEBUG that sets the node in 
the off-chain state post-extraction. In this case, that side-effect is 
undesirable and so a lock is in place to prevent that temporary 
side-effect from leaking to other parts of the system since all other 
off-chain checks are behind the same lock.


Ok, so you want to delay the set-off state visibility in case 
RTEMS_DEBUG is defined. This is the first place in the code base which 
needs this behaviour.


We basically don't use internal locking in JFFS2 in RTEMS. Why can't you 
use the global file system lock of the JFFS2 instance to work carry out 
this delayed work?


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

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/2] cpukit/jffs2: Set extracted nodes off-chain

[Kinsey Moore]

On Thu, Sep 21, 2023 at 10:01 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 21.09.23 16:52, Kinsey Moore wrote:
> > On Thu, Sep 21, 2023 at 9:47 AM Sebastian Huber
> >  > > wrote:
> >
> > On 20.09.23 20:35, Kinsey Moore wrote:
> > [...]
> >  > @@ -1306,8 +1307,22 @@ static void process_delayed_work(void)
> >  >   while (!rtems_chain_is_tail(_work_chain, node)) {
> >  >   work = (struct delayed_work*) node;
> >  >   rtems_chain_node* next_node =
> rtems_chain_next(node);
> >  > +
> >  > + /*
> >  > +  * Don't leave extracted node exposed to other
> > operations
> >  > +  * under RTEMS_DEBUG
> >  > +  */
> >  > +#ifdef RTEMS_DEBUG
> >  > + mutex_lock(_work_mutex);
> >  > +#endif
> >  >   rtems_chain_extract(node);
> >  > +#ifdef RTEMS_DEBUG
> >  > + node->next = node;
> >  > + mutex_unlock(_work_mutex);
> >  > +#endif
> >  > +
> >  >   work->callback(>work);
> >  > + rtems_chain_set_off_chain(node);
> >  >   node = next_node;
> >  >   }
> >  >   }
> >
> > This change makes no sense to me. The code should work regardless if
> > RTEMS_DEBUG is defined or not.
> >
> >
> > RTEMS_DEBUG introduces a behavioral change in rtems_chain_extract() such
> > that extracted nodes are automatically set off-chain. When RTEMS_DEBUG
> > is not set, node->next is left untouched. This has to be managed because
> > this code needs the node to remain on-chain so that it is not re-queued
> > during the operation.
>
> Yes, but while a node is on a chain you must not call
> rtems_chain_set_off_chain(). If you want to use the off-chain state,
> then you have to use this:
>
> rtems_chain_extract(node);
> rtems_chain_set_off_chain(node);
>
> or
>
> rtems_chain_extract_unprotected(node);
> rtems_chain_set_off_chain(node);
>
> The automatic set off-chain in RTEMS_DEBUG is just to ensure that basic
> chain operations are used in the right state.
>

Yes, there is no behavior here where rtems_chain_set_off_chain() is being
called on a node that is still in a chain. This section of code is entirely
managing the side-effect of RTEMS_DEBUG that sets the node in the off-chain
state post-extraction. In this case, that side-effect is undesirable and so
a lock is in place to prevent that temporary side-effect from leaking to
other parts of the system since all other off-chain checks are behind the
same lock.

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

Re: [PATCH 1/2] cpukit/jffs2: Set extracted nodes off-chain

[Sebastian Huber]

On 21.09.23 16:52, Kinsey Moore wrote:
On Thu, Sep 21, 2023 at 9:47 AM Sebastian Huber 
> wrote:


On 20.09.23 20:35, Kinsey Moore wrote:
[...]
 > @@ -1306,8 +1307,22 @@ static void process_delayed_work(void)
 >       while (!rtems_chain_is_tail(_work_chain, node)) {
 >               work = (struct delayed_work*) node;
 >               rtems_chain_node* next_node = rtems_chain_next(node);
 > +
 > +             /*
 > +              * Don't leave extracted node exposed to other
operations
 > +              * under RTEMS_DEBUG
 > +              */
 > +#ifdef RTEMS_DEBUG
 > +             mutex_lock(_work_mutex);
 > +#endif
 >               rtems_chain_extract(node);
 > +#ifdef RTEMS_DEBUG
 > +             node->next = node;
 > +             mutex_unlock(_work_mutex);
 > +#endif
 > +
 >               work->callback(>work);
 > +             rtems_chain_set_off_chain(node);
 >               node = next_node;
 >       }
 >   }

This change makes no sense to me. The code should work regardless if
RTEMS_DEBUG is defined or not.


RTEMS_DEBUG introduces a behavioral change in rtems_chain_extract() such 
that extracted nodes are automatically set off-chain. When RTEMS_DEBUG 
is not set, node->next is left untouched. This has to be managed because 
this code needs the node to remain on-chain so that it is not re-queued 
during the operation.


Yes, but while a node is on a chain you must not call 
rtems_chain_set_off_chain(). If you want to use the off-chain state, 
then you have to use this:


rtems_chain_extract(node);
rtems_chain_set_off_chain(node);

or

rtems_chain_extract_unprotected(node);
rtems_chain_set_off_chain(node);

The automatic set off-chain in RTEMS_DEBUG is just to ensure that basic 
chain operations are used in the right state.


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

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] validation: Check stack of interrupted context

[Kinsey Moore]

On Thu, Sep 21, 2023 at 9:56 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Kinsey,
>
> I added a test case for
>
> https://devel.rtems.org/ticket/4955
>
> which started as a sparc-specific bug. The test case should also work on
> aarch64. In uniprocessor configurations, it is fine:
>
> qemu-system-aarch64 -no-reboot -nographic -serial mon:stdio -machine
> xlnx-zcu102 -m 4096 -kernel
> build/aarch64/xilinx_zynqmp_lp64_qemu/testsuites/validation/ts-validation-intr.exe
>
>
>
> *** BEGIN OF TEST TestsuitesValidationIntr ***
> *** TEST VERSION: 6.0.0.34e16f56b64a9a0a696775f4ac699780fc518306
> *** TEST STATE: EXPECTED_PASS
> *** TEST BUILD:
> *** TEST TOOLS: 13.2.0 20230727 (RTEMS 6, RSB
> 02252b96835f1edc7a582e2309ee2f5b46764d64, Newlib a021448)
> A:TestsuitesValidationIntr
> S:Platform:RTEMS
> S:Compiler:13.2.0 20230727 (RTEMS 6, RSB
> 02252b96835f1edc7a582e2309ee2f5b46764d64, Newlib a021448)
> S:Version:6.0.0.34e16f56b64a9a0a696775f4ac699780fc518306
> S:BSP:xilinx_zynqmp_lp64_qemu
> S:BuildLabel:DEFAULT
> S:TargetHash:SHA256:huGRj7kHeBWgSJolmeboNSyCgeX2U62J9RiNQ18YPFc=
> S:RTEMS_DEBUG:0
> S:RTEMS_MULTIPROCESSING:0
> S:RTEMS_POSIX_API:0
> S:RTEMS_PROFILING:0
> S:RTEMS_SMP:0
> B:ScoreIsrValIsr
> E:ScoreIsrValIsr:N:1:F:0:D:0.000397
> B:RtemsIntrReqVectorIsEnabled
> E:RtemsIntrReqVectorIsEnabled:N:958:F:0:D:0.001529
> B:RtemsIntrReqVectorEnable
> E:RtemsIntrReqVectorEnable:N:12834:F:0:D:0.014386
> B:RtemsIntrReqVectorDisable
> E:RtemsIntrReqVectorDisable:N:12858:F:0:D:0.013536
> B:RtemsIntrReqSetAffinity
> E:RtemsIntrReqSetAffinity:N:4060:F:0:D:0.002265
> B:RtemsIntrReqRaiseOn
> E:RtemsIntrReqRaiseOn:N:6754:F:0:D:0.009210
> B:RtemsIntrReqRaise
> E:RtemsIntrReqRaise:N:6750:F:0:D:0.009304
> B:RtemsIntrReqIsPending
> E:RtemsIntrReqIsPending:N:5358:F:0:D:0.008721
> B:RtemsIntrReqHandlerIterate
> E:RtemsIntrReqHandlerIterate:N:31:F:0:D:0.000753
> B:RtemsIntrReqGetAttributes
> E:RtemsIntrReqGetAttributes:N:552:F:0:D:0.000547
> B:RtemsIntrReqGetAffinity
> E:RtemsIntrReqGetAffinity:N:1195:F:0:D:0.000923
> B:RtemsIntrReqEntryRemove
> E:RtemsIntrReqEntryRemove:N:4486:F:0:D:0.006436
> B:RtemsIntrReqEntryInstall
> E:RtemsIntrReqEntryInstall:N:13528:F:0:D:0.018137
> B:RtemsIntrReqClear
> E:RtemsIntrReqClear:N:12834:F:0:D:0.011950
> B:BspReqInterruptHandlerDispatchUnchecked
> E:BspReqInterruptHandlerDispatchUnchecked:N:13:F:0:D:0.000520
> Z:TestsuitesValidationIntr:C:15:N:82212:F:0:D:0.103215
> Y:ReportHash:SHA256:9MhLl5LJSiL-O5P8y5BXelnhD38UNTvwHZ5QX_X-kTU=
>
> *** END OF TEST TestsuitesValidationIntr ***
>
>
> [ RTEMS shutdown ]
> RTEMS version: 6.0.0.34e16f56b64a9a0a696775f4ac699780fc518306
> RTEMS tools: 13.2.0 20230727 (RTEMS 6, RSB
> 02252b96835f1edc7a582e2309ee2f5b46764d64, Newlib a021448)
> executing thread ID: 0x0a010001
> executing thread name: RUN
>
> In SMP configurations, there is a crash:
>
> qemu-system-aarch64 -no-reboot -nographic -serial mon:stdio -machine
> xlnx-zcu102 -m 4096 -kernel
>
> build/aarch64/xilinx_zynqmp_lp64_qemu_smp/testsuites/validation/ts-validation-intr.exe
>
> Thread 1 hit Breakpoint 1, _Terminate
> (the_source=the_source@entry=INTERNAL_ERROR_CORE,
> the_error=the_error@entry=31) at
> /home/EB/sebastian_h/src/rtems/cpukit/score/src/interr.c:55
> 55_User_extensions_Fatal( the_source, the_error );
> (gdb) bt
> #0  _Terminate (the_source=the_source@entry=INTERNAL_ERROR_CORE,
> the_error=the_error@entry=31) at
> /home/EB/sebastian_h/src/rtems/cpukit/score/src/interr.c:55
> #1  0x40027ab4 in _Internal_error
> (core_error=core_error@entry=INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT)
>
> at /home/EB/sebastian_h/src/rtems/cpukit/score/src/interr.c:63
> #2  0x400285d8 in _Thread_Do_dispatch (cpu_self=0x40101980
> <_Per_CPU_Information>, level=960) at
> /home/EB/sebastian_h/src/rtems/cpukit/score/src/threaddispatch.c:290
> #3  0x4002878c in _Thread_Handler () at
> /home/EB/sebastian_h/src/rtems/cpukit/score/src/threadhandler.c:147
> #4  0x400286d0 in ?? ()
>
> I don't know the architecture good enough to debug this test case. It
> would be good if you could have a look at it since this crash could
> indicate a generic bug in the SMP startup.
>

Ok, thanks! I'll take a look and see what I can find.

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

Re: [PATCH] validation: Check stack of interrupted context

[Sebastian Huber]

Hello Kinsey,

I added a test case for

https://devel.rtems.org/ticket/4955

which started as a sparc-specific bug. The test case should also work on 
aarch64. In uniprocessor configurations, it is fine:


qemu-system-aarch64 -no-reboot -nographic -serial mon:stdio -machine 
xlnx-zcu102 -m 4096 -kernel 
build/aarch64/xilinx_zynqmp_lp64_qemu/testsuites/validation/ts-validation-intr.exe 



*** BEGIN OF TEST TestsuitesValidationIntr ***
*** TEST VERSION: 6.0.0.34e16f56b64a9a0a696775f4ac699780fc518306
*** TEST STATE: EXPECTED_PASS
*** TEST BUILD:
*** TEST TOOLS: 13.2.0 20230727 (RTEMS 6, RSB 
02252b96835f1edc7a582e2309ee2f5b46764d64, Newlib a021448)

A:TestsuitesValidationIntr
S:Platform:RTEMS
S:Compiler:13.2.0 20230727 (RTEMS 6, RSB 
02252b96835f1edc7a582e2309ee2f5b46764d64, Newlib a021448)

S:Version:6.0.0.34e16f56b64a9a0a696775f4ac699780fc518306
S:BSP:xilinx_zynqmp_lp64_qemu
S:BuildLabel:DEFAULT
S:TargetHash:SHA256:huGRj7kHeBWgSJolmeboNSyCgeX2U62J9RiNQ18YPFc=
S:RTEMS_DEBUG:0
S:RTEMS_MULTIPROCESSING:0
S:RTEMS_POSIX_API:0
S:RTEMS_PROFILING:0
S:RTEMS_SMP:0
B:ScoreIsrValIsr
E:ScoreIsrValIsr:N:1:F:0:D:0.000397
B:RtemsIntrReqVectorIsEnabled
E:RtemsIntrReqVectorIsEnabled:N:958:F:0:D:0.001529
B:RtemsIntrReqVectorEnable
E:RtemsIntrReqVectorEnable:N:12834:F:0:D:0.014386
B:RtemsIntrReqVectorDisable
E:RtemsIntrReqVectorDisable:N:12858:F:0:D:0.013536
B:RtemsIntrReqSetAffinity
E:RtemsIntrReqSetAffinity:N:4060:F:0:D:0.002265
B:RtemsIntrReqRaiseOn
E:RtemsIntrReqRaiseOn:N:6754:F:0:D:0.009210
B:RtemsIntrReqRaise
E:RtemsIntrReqRaise:N:6750:F:0:D:0.009304
B:RtemsIntrReqIsPending
E:RtemsIntrReqIsPending:N:5358:F:0:D:0.008721
B:RtemsIntrReqHandlerIterate
E:RtemsIntrReqHandlerIterate:N:31:F:0:D:0.000753
B:RtemsIntrReqGetAttributes
E:RtemsIntrReqGetAttributes:N:552:F:0:D:0.000547
B:RtemsIntrReqGetAffinity
E:RtemsIntrReqGetAffinity:N:1195:F:0:D:0.000923
B:RtemsIntrReqEntryRemove
E:RtemsIntrReqEntryRemove:N:4486:F:0:D:0.006436
B:RtemsIntrReqEntryInstall
E:RtemsIntrReqEntryInstall:N:13528:F:0:D:0.018137
B:RtemsIntrReqClear
E:RtemsIntrReqClear:N:12834:F:0:D:0.011950
B:BspReqInterruptHandlerDispatchUnchecked
E:BspReqInterruptHandlerDispatchUnchecked:N:13:F:0:D:0.000520
Z:TestsuitesValidationIntr:C:15:N:82212:F:0:D:0.103215
Y:ReportHash:SHA256:9MhLl5LJSiL-O5P8y5BXelnhD38UNTvwHZ5QX_X-kTU=

*** END OF TEST TestsuitesValidationIntr ***


[ RTEMS shutdown ]
RTEMS version: 6.0.0.34e16f56b64a9a0a696775f4ac699780fc518306
RTEMS tools: 13.2.0 20230727 (RTEMS 6, RSB 
02252b96835f1edc7a582e2309ee2f5b46764d64, Newlib a021448)

executing thread ID: 0x0a010001
executing thread name: RUN

In SMP configurations, there is a crash:

qemu-system-aarch64 -no-reboot -nographic -serial mon:stdio -machine 
xlnx-zcu102 -m 4096 -kernel 
build/aarch64/xilinx_zynqmp_lp64_qemu_smp/testsuites/validation/ts-validation-intr.exe


Thread 1 hit Breakpoint 1, _Terminate 
(the_source=the_source@entry=INTERNAL_ERROR_CORE, 
the_error=the_error@entry=31) at 
/home/EB/sebastian_h/src/rtems/cpukit/score/src/interr.c:55

55_User_extensions_Fatal( the_source, the_error );
(gdb) bt
#0  _Terminate (the_source=the_source@entry=INTERNAL_ERROR_CORE, 
the_error=the_error@entry=31) at 
/home/EB/sebastian_h/src/rtems/cpukit/score/src/interr.c:55
#1  0x40027ab4 in _Internal_error 
(core_error=core_error@entry=INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT) 
at /home/EB/sebastian_h/src/rtems/cpukit/score/src/interr.c:63
#2  0x400285d8 in _Thread_Do_dispatch (cpu_self=0x40101980 
<_Per_CPU_Information>, level=960) at 
/home/EB/sebastian_h/src/rtems/cpukit/score/src/threaddispatch.c:290
#3  0x4002878c in _Thread_Handler () at 
/home/EB/sebastian_h/src/rtems/cpukit/score/src/threadhandler.c:147

#4  0x400286d0 in ?? ()

I don't know the architecture good enough to debug this test case. It 
would be good if you could have a look at it since this crash could 
indicate a generic bug in the SMP startup.


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

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/2] cpukit/jffs2: Set extracted nodes off-chain

[Kinsey Moore]

On Thu, Sep 21, 2023 at 9:47 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 20.09.23 20:35, Kinsey Moore wrote:
> [...]
> > @@ -1306,8 +1307,22 @@ static void process_delayed_work(void)
> >   while (!rtems_chain_is_tail(_work_chain, node)) {
> >   work = (struct delayed_work*) node;
> >   rtems_chain_node* next_node = rtems_chain_next(node);
> > +
> > + /*
> > +  * Don't leave extracted node exposed to other operations
> > +  * under RTEMS_DEBUG
> > +  */
> > +#ifdef RTEMS_DEBUG
> > + mutex_lock(_work_mutex);
> > +#endif
> >   rtems_chain_extract(node);
> > +#ifdef RTEMS_DEBUG
> > + node->next = node;
> > + mutex_unlock(_work_mutex);
> > +#endif
> > +
> >   work->callback(>work);
> > + rtems_chain_set_off_chain(node);
> >   node = next_node;
> >   }
> >   }
>
> This change makes no sense to me. The code should work regardless if
> RTEMS_DEBUG is defined or not.
>

RTEMS_DEBUG introduces a behavioral change in rtems_chain_extract() such
that extracted nodes are automatically set off-chain. When RTEMS_DEBUG is
not set, node->next is left untouched. This has to be managed because this
code needs the node to remain on-chain so that it is not re-queued during
the operation.

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

Re: [PATCH 2/2] cpukit/jffs2: Use unprotected chain calls

[Sebastian Huber]

On 20.09.23 20:35, Kinsey Moore wrote:

Use unprotected chain calls for delayed write workqueues since these
calls are either protected by locks or only operate on local chains and
are never accessed from interrupt context.

Updates #4956


This change is all right, if you fix the chain operations outside the 
locks. Using the off-chain state doesn't work reliably in SMP 
configurations. You also have to ensure that a node in the local chain 
cannot be deleted (unmount). I think you should first write a test case 
which triggers the bug in the original implementation.


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

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/2] cpukit/jffs2: Set extracted nodes off-chain

[Sebastian Huber]

On 20.09.23 20:35, Kinsey Moore wrote:
[...]

@@ -1306,8 +1307,22 @@ static void process_delayed_work(void)
while (!rtems_chain_is_tail(_work_chain, node)) {
work = (struct delayed_work*) node;
rtems_chain_node* next_node = rtems_chain_next(node);
+
+   /*
+* Don't leave extracted node exposed to other operations
+* under RTEMS_DEBUG
+*/
+#ifdef RTEMS_DEBUG
+   mutex_lock(_work_mutex);
+#endif
rtems_chain_extract(node);
+#ifdef RTEMS_DEBUG
+   node->next = node;
+   mutex_unlock(_work_mutex);
+#endif
+
work->callback(>work);
+   rtems_chain_set_off_chain(node);
node = next_node;
}
  }


This change makes no sense to me. The code should work regardless if 
RTEMS_DEBUG is defined or not.


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

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] validation: Check stack of interrupted context

[Sebastian Huber]

Check the stack of the interrupted context during the multitasking
start.

Update #4955.
---
 .../testsuites/validation/validation-intr.yml |   3 +
 testsuites/validation/tc-score-isr.c  | 225 ++
 2 files changed, 228 insertions(+)
 create mode 100644 testsuites/validation/tc-score-isr.c

diff --git a/spec/build/testsuites/validation/validation-intr.yml 
b/spec/build/testsuites/validation/validation-intr.yml
index 1383aba2b3..2c478e6484 100644
--- a/spec/build/testsuites/validation/validation-intr.yml
+++ b/spec/build/testsuites/validation/validation-intr.yml
@@ -9,8 +9,10 @@ enabled-by: true
 features: c cprogram
 includes: []
 ldflags:
+- -Wl,--wrap=bsp_interrupt_dispatch
 - -Wl,--wrap=bsp_interrupt_handler_default
 - -Wl,--wrap=bsp_interrupt_spurious
+- -Wl,--wrap=_SPARC_Interrupt_dispatch
 links: []
 source:
 - testsuites/validation/tc-bsp-interrupt-handler-dispatch-unchecked.c
@@ -27,6 +29,7 @@ source:
 - testsuites/validation/tc-intr-vector-disable.c
 - testsuites/validation/tc-intr-vector-enable.c
 - testsuites/validation/tc-intr-vector-is-enabled.c
+- testsuites/validation/tc-score-isr.c
 - testsuites/validation/ts-validation-intr.c
 stlib: []
 target: testsuites/validation/ts-validation-intr.exe
diff --git a/testsuites/validation/tc-score-isr.c 
b/testsuites/validation/tc-score-isr.c
new file mode 100644
index 00..4374b1b130
--- /dev/null
+++ b/testsuites/validation/tc-score-isr.c
@@ -0,0 +1,225 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup ScoreIsrValIsr
+ */
+
+/*
+ * Copyright (C) 2023 embedded brains GmbH & Co. KG
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/*
+ * This file is part of the RTEMS quality process and was automatically
+ * generated.  If you find something that needs to be fixed or
+ * worded better please post a report or patch to an RTEMS mailing list
+ * or raise a bug report:
+ *
+ * https://www.rtems.org/bugs.html
+ *
+ * For information on updating and regenerating please refer to the How-To
+ * section in the Software Requirements Engineering chapter of the
+ * RTEMS Software Engineering manual.  The manual is provided as a part of
+ * a release.  For development sources please refer to the online
+ * documentation at:
+ *
+ * https://docs.rtems.org
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+#include 
+#include 
+#include 
+
+#include "tx-support.h"
+
+#include 
+
+/**
+ * @defgroup ScoreIsrValIsr spec:/score/isr/val/isr
+ *
+ * @ingroup TestsuitesValidationIntr
+ *
+ * @brief Tests general interrupt support behaviour.
+ *
+ * This test case performs the following actions:
+ *
+ * - Submit an ISR request during system initialization.  Check the stack of
+ *   the interrupted context while the ISR request is serviced.  Store the
+ *   result of the check in interrupted_stack_at_multitasking_start_is_valid.
+ *
+ *   - Check that stack of the interrupted context was valid when an interrupt
+ * was serviced during the multitasking start.
+ *
+ * @{
+ */
+
+static uintptr_t interrupted_stack_at_multitasking_start;
+
+static bool interrupted_stack_at_multitasking_start_is_valid;
+
+#if defined(__aarch64__)
+void __real_bsp_interrupt_dispatch( void );
+
+void __wrap_bsp_interrupt_dispatch( void );
+
+void __wrap_bsp_interrupt_dispatch( void )
+{
+  if ( interrupted_stack_at_multitasking_start == 0 ) {
+uintptr_t sp;
+rtems_interrupt_level level;
+
+rtems_interrupt_local_disable( level );
+__asm__ volatile (
+  "msr spsel, #0\n"
+  "mov %0, sp\n"
+  "msr spsel, #1"
+  : "=r" ( sp )
+);
+rtems_interrupt_local_enable( level );
+
+

Re: Add Formal Verification chapter v4

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

Hi Gedare,
 I've made some changes and raised some further queries - I don't know if you 
get any notifications from github

PR: (https://github.com/RTEMS/rtems-docs/pull/6)

Regards,
  Andrew



 
Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 
Lero@TCD, Head of Software Foundations & Verification Research Group 
School of Computer Science and Statistics, 
Room G.39, O'Reilly Institute, Trinity College, University of Dublin 
http://www.scss.tcd.ie/Andrew.Butterfield/ 
 
 





On 14/09/2023, 20:17, "Gedare Bloom" mailto:ged...@rtems.org>> wrote:


Thanks, I left comments on your pull request.


On Wed, Sep 6, 2023 at 7:26 AM andrew.butterfi...@scss.tcd.ie 

mailto:andrew.butterfi...@scss.tcd.ie>> wrote:
>
> Ping
>
> (I've let this sit a while - time to wake it up!)
>
> 
> Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204
> Lero@TCD, Head of Software Foundations & Verification Research Group
> School of Computer Science and Statistics,
> Room G.39, O'Reilly Institute, Trinity College, University of Dublin
> http://www.scss.tcd.ie/Andrew.Butterfield/ 
>  
>  
> 
> 
>
>
>
>
>
>
>
>
> -Original Message-
> From: devel mailto:devel-boun...@rtems.org> 
> >> on behalf 
> of "andrew.butterfi...@scss.tcd.ie  
>  >"   
>  >>
> Date: Tuesday 18 July 2023 at 13:54
> To: "rtems-de...@rtems.org  
> >" 
> mailto:rtems-de...@rtems.org> 
> >>
> Subject: Add Formal Verification chapter v4
>
>
> Dear all,
> I've attached a patch-set for v4 of the proposal to add a formal verification 
> chapter to the Software Engineering manual.
> (I can’t do git-mail)
>
>
> I've setup a pull-request at https://github.com/RTEMS/rtems-docs/pull/6 
>  
>  
>  for review purposes.
>
>
> Regards,
> Andrew
> 
> Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204
> Lero@TCD, Head of Software Foundations & Verification Research Group
> School of Computer Science and Statistics,
> Room G.39, O'Reilly Institute, Trinity College, University of Dublin
> http://www.scss.tcd.ie/Andrew.Butterfield/ 
>  
>  
>  
>  
>  
>  
> 
> 
>
>
>
>
>
>
>
>
>
>
>
>
>



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