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

[Joel Sherrill]

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

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

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

Re: RSB format changes to meet coding standard

[Joel Sherrill]

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

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

I'm certainly ok with this.

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

Re: 6.1rc3 CentOS 7 Build Sweep Report

[Joel Sherrill]

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

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

Last spring.

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

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

--joel


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

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

[Joel Sherrill]

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

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

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

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

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

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

--joel

>
> Peter
> -
> Peter Dufault
> HD Associates, Inc.  Software and System Engineering
>
>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Fwd: Deprecation/removal of nios2 target support

[Joel Sherrill]

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

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

--joel

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


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

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

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

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

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

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

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

6.1rc3 CentOS 7 Build Sweep Report

[Joel Sherrill]

Hi

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

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

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

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

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

[Joel Sherrill]

This is ok to push.

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

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

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

Re: [PATCH] score: Improve C/C++ standard compatibility

[Joel Sherrill]

This looks ok.

On Tue, Apr 9, 2024, 7:30 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> The processor mask implementation uses flsl() from  which is
> only BSD visible.  Move the implementation to a separate header file to
> hide it from the API level.  This fixes build errors with GCC 14.
> ---
>  cpukit/include/rtems/score/processormask.h| 379 +--
>  .../include/rtems/score/processormaskimpl.h   | 437 ++
>  cpukit/include/rtems/score/smpimpl.h  |   2 +-
>  cpukit/score/src/processormaskcopy.c  |   2 +-
>  4 files changed, 440 insertions(+), 380 deletions(-)
>  create mode 100644 cpukit/include/rtems/score/processormaskimpl.h
>
> diff --git a/cpukit/include/rtems/score/processormask.h
> b/cpukit/include/rtems/score/processormask.h
> index ce23f6c10d..71ed37cd0e 100644
> --- a/cpukit/include/rtems/score/processormask.h
> +++ b/cpukit/include/rtems/score/processormask.h
> @@ -39,9 +39,7 @@
>
>  #include 
>
> -#include 
> -
> -#include 
> +#include 
>
>  #ifdef __cplusplus
>  extern "C" {
> @@ -123,381 +121,6 @@ extern "C" {
>   */
>  typedef __BITSET_DEFINE( Processor_mask, CPU_MAXIMUM_PROCESSORS )
> Processor_mask;
>
> -/**
> - * @brief Sets the bits of the mask to zero, also considers
> CPU_MAXIMUM_PROCESSORS.
> - *
> - * @param[out] mask The mask to set to zero.
> - */
> -static inline void _Processor_mask_Zero( Processor_mask *mask )
> -{
> -  __BIT_ZERO( CPU_MAXIMUM_PROCESSORS, mask );
> -}
> -
> -/**
> - * @brief Checks if the mask is zero, also considers
> CPU_MAXIMUM_PROCESSORS.
> - *
> - * @param mask The mask to check whether is is zero
> - *
> - * @retval true The mask is zero.
> - * @retval false The mask is not zero.
> - */
> -static inline bool _Processor_mask_Is_zero( const Processor_mask *mask )
> -{
> -  return __BIT_EMPTY( CPU_MAXIMUM_PROCESSORS, mask );
> -}
> -
> -/**
> - * @brief Fills the mask, also considers CPU_MAXIMUM_PROCESSORS.
> - *
> - * @param[out] mask The mask to fill
> - */
> -static inline void _Processor_mask_Fill( Processor_mask *mask )
> -{
> -  __BIT_FILL( CPU_MAXIMUM_PROCESSORS, mask );
> -}
> -
> -/**
> - * @brief Copies the mask to another mask, also considers
> CPU_MAXIMUM_PROCESSORS.
> - *
> - * @param[out] dst The mask to copy @a src to.
> - * @param src The mask to copy to @a dst.
> - */
> -static inline void _Processor_mask_Assign(
> -  Processor_mask *dst, const Processor_mask *src
> -)
> -{
> -  __BIT_COPY( CPU_MAXIMUM_PROCESSORS, src, dst );
> -}
> -
> -/**
> - * @brief Sets the specified index bit of the mask.
> - *
> - * @param[out] mask The mask to set the bit of.
> - * @param index The index of the bit that shall be set.
> - */
> -static inline void _Processor_mask_Set(
> -  Processor_mask *mask,
> -  uint32_tindex
> -)
> -{
> -  __BIT_SET( CPU_MAXIMUM_PROCESSORS, index, mask );
> -}
> -
> -/**
> - * @brief Clears the specified index bit of the mask.
> - *
> - * @param[out] mask The mask to clear the bit of.
> - * @param index The index of the bit that shall be cleared.
> - */
> -static inline void _Processor_mask_Clear(
> -  Processor_mask *mask,
> -  uint32_tindex
> -)
> -{
> -  __BIT_CLR( CPU_MAXIMUM_PROCESSORS, index, mask );
> -}
> -
> -/**
> - * @brief Checks if the specified index bit of the mask is set.
> - *
> - * @param mask The mask to check if the specified bit is set.
> - * @param index The index of the bit that is checked.
> - *
> - * @retval true The specified index bit is set.
> - * @retval false The specified index bit is not set.
> - */
> -static inline bool _Processor_mask_Is_set(
> -  const Processor_mask *mask,
> -  uint32_t  index
> -)
> -{
> -  return __BIT_ISSET( CPU_MAXIMUM_PROCESSORS, index, mask );
> -}
> -
> -/**
> - * @brief Checks if the processor sets a and b are equal.
> - *
> - * @param a The first processor set.
> - * @param b The seconde processor set.
> - *
> - * @retval true The processor sets a and b are equal.
> - * @retval false The processor sets a and b are not equal.
> - */
> -static inline bool _Processor_mask_Is_equal(
> -  const Processor_mask *a,
> -  const Processor_mask *b
> -)
> -{
> -  return !__BIT_CMP( CPU_MAXIMUM_PROCESSORS, a, b );
> -}
> -
> -/**
> - * @brief Checks if the intersection of the processor sets a and b is
> - * non-empty.
> - *
> - * @param a The first processor set.
> - * @param b The second processor set.
> - *
> - * @retval true The intersection of the processor sets a and b is
> non-empty.
> - * @retval false The intersection of the processor sets a and b is empty.
> - */
> -static inline bool _Processor_mask_Has_overlap(
> -  const Processor_mask *a,
> -  const Processor_mask *b
> -)
> -{
> -  return __BIT_OVERLAP( CPU_MAXIMUM_PROCESSORS, a, b );
> -}
> -
> -/**
> - * @brief Checks if the processor set small is a subset of processor set
> - * big.
> - *
> - * @param big The bigger processor set.
> - * @param small The smaller processor set.
> - *
> - * @retval true @a small is a subset 

Re: GCC 14: Some warnings are now errors

[Joel Sherrill]

Is 14 the version for RTEMS 7 tools? If so, that makes it easier to address
the issues.

And Chris says we need 13 for RTEMS 6 because older doesn't compile on new
Mac tools. So that needs action.

On Tue, Apr 9, 2024, 8:29 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> I did some tests with GCC 14 and it turned out that this release turns a
> couple of warnings into errors:
>
> https://gcc.gnu.org/gcc-14/porting_to.html
>
> It will be a bit of work to get RTEMS compile clean for GCC 14.
>
> --
> embedded brains GmbH & Co. KG
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [RSB PATCH] sb: Add sb-rtems-pkg to update the RTEMS package hashes and checksums

[Joel Sherrill]

Chris.. if you post a V2 addressing those, I will commit it.

On Wed, Apr 3, 2024, 11:52 AM Kinsey Moore  wrote:

> Looks fine overall. Minor nits:
> "host" is set to "freebsd" and is never used.
> Numeric indexes for repo config details are nice for brevity, but not for
> readability.
>
> Kinsey
>
> On Wed, Apr 3, 2024 at 11:29 AM Joel Sherrill 
> wrote:
>
>> This looks handy. I don't have an issue with it.
>>
>> On Tue, Apr 2, 2024 at 11:25 PM  wrote:
>>
>>> From: Chris Johns 
>>>
>>> ---
>>>  source-builder/sb-rtems-pkg   |  29 
>>>  source-builder/sb/download.py |   5 +-
>>>  source-builder/sb/git.py  |  12 ++
>>>  source-builder/sb/rtemspkg.py | 279 ++
>>>  4 files changed, 324 insertions(+), 1 deletion(-)
>>>  create mode 100755 source-builder/sb-rtems-pkg
>>>  create mode 100644 source-builder/sb/rtemspkg.py
>>>
>>> diff --git a/source-builder/sb-rtems-pkg b/source-builder/sb-rtems-pkg
>>> new file mode 100755
>>> index 000..99ed26c
>>> --- /dev/null
>>> +++ b/source-builder/sb-rtems-pkg
>>> @@ -0,0 +1,29 @@
>>> +#! /usr/bin/env python
>>> +#
>>> +# RTEMS Tools Project (http://www.rtems.org/)
>>> +# Copyright 2024 Chris Johns (chr...@rtems.org)
>>> +# All rights reserved.
>>> +#
>>> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
>>> +#
>>> +# Permission to use, copy, modify, and/or distribute this software for
>>> any
>>> +# purpose with or without fee is hereby granted, provided that the above
>>> +# copyright notice and this permission notice appear in all copies.
>>> +#
>>> +# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL
>>> WARRANTIES
>>> +# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
>>> +# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE
>>> FOR
>>> +# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
>>> +# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
>>> +# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
>>> OF
>>> +# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
>>> +
>>> +from __future__ import print_function
>>> +
>>> +try:
>>> +import sb.rtemspkg
>>> +sb.rtemspkg.run()
>>> +except ImportError:
>>> +import sys
>>> +print("Incorrect Source Builder installation", file = sys.stderr)
>>> +sys.exit(1)
>>> diff --git a/source-builder/sb/download.py
>>> b/source-builder/sb/download.py
>>> index 6e6f9f2..0201675 100644
>>> --- a/source-builder/sb/download.py
>>> +++ b/source-builder/sb/download.py
>>> @@ -85,6 +85,8 @@ def _hash_check(file_, absfile, macros, remove = True):
>>>  hash = hash.split()
>>>  if len(hash) != 2:
>>>  raise error.internal('invalid hash format: %s' % (file_))
>>> +if hash[0] == 'NO-HASH':
>>> +return not failed
>>>  try:
>>>  hashlib_algorithms = hashlib.algorithms
>>>  except:
>>> @@ -479,7 +481,8 @@ def _git_downloader(url, local, config, opts):
>>>  else:
>>>  repo.clean(['-f', '-d'])
>>>  repo.reset('--hard')
>>> -repo.checkout('master')
>>> +default_branch = repo.default_branch()
>>> +repo.checkout(default_branch)
>>>  for a in us[1:]:
>>>  _as = a.split('=')
>>>  if _as[0] == 'branch' or _as[0] == 'checkout':
>>> diff --git a/source-builder/sb/git.py b/source-builder/sb/git.py
>>> index 237e690..0aa4da9 100644
>>> --- a/source-builder/sb/git.py
>>> +++ b/source-builder/sb/git.py
>>> @@ -226,6 +226,18 @@ class repo:
>>>  hash = l1[len('commit '):]
>>>  return hash
>>>
>>> +def default_branch(self):
>>> +ec, output = self._run(['remote', 'show'])
>>> +if ec == 0:
>>> +origin = output.split('\n')[0]
>>> +ec, output = self._run(['remote', 'show', origin])
>>> +if ec == 0:
>>> +for l in output.split('\n'):
>>> +l = l.strip()
>>> +if l.startswith('HEAD branch: '):
>>> +

Re: [RSB PATCH] sb: Add sb-rtems-pkg to update the RTEMS package hashes and checksums

[Joel Sherrill]

This looks handy. I don't have an issue with it.

On Tue, Apr 2, 2024 at 11:25 PM  wrote:

> From: Chris Johns 
>
> ---
>  source-builder/sb-rtems-pkg   |  29 
>  source-builder/sb/download.py |   5 +-
>  source-builder/sb/git.py  |  12 ++
>  source-builder/sb/rtemspkg.py | 279 ++
>  4 files changed, 324 insertions(+), 1 deletion(-)
>  create mode 100755 source-builder/sb-rtems-pkg
>  create mode 100644 source-builder/sb/rtemspkg.py
>
> diff --git a/source-builder/sb-rtems-pkg b/source-builder/sb-rtems-pkg
> new file mode 100755
> index 000..99ed26c
> --- /dev/null
> +++ b/source-builder/sb-rtems-pkg
> @@ -0,0 +1,29 @@
> +#! /usr/bin/env python
> +#
> +# RTEMS Tools Project (http://www.rtems.org/)
> +# Copyright 2024 Chris Johns (chr...@rtems.org)
> +# All rights reserved.
> +#
> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
> +#
> +# Permission to use, copy, modify, and/or distribute this software for any
> +# purpose with or without fee is hereby granted, provided that the above
> +# copyright notice and this permission notice appear in all copies.
> +#
> +# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> +# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> +# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> +# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> +# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> +# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> +# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> +
> +from __future__ import print_function
> +
> +try:
> +import sb.rtemspkg
> +sb.rtemspkg.run()
> +except ImportError:
> +import sys
> +print("Incorrect Source Builder installation", file = sys.stderr)
> +sys.exit(1)
> diff --git a/source-builder/sb/download.py b/source-builder/sb/download.py
> index 6e6f9f2..0201675 100644
> --- a/source-builder/sb/download.py
> +++ b/source-builder/sb/download.py
> @@ -85,6 +85,8 @@ def _hash_check(file_, absfile, macros, remove = True):
>  hash = hash.split()
>  if len(hash) != 2:
>  raise error.internal('invalid hash format: %s' % (file_))
> +if hash[0] == 'NO-HASH':
> +return not failed
>  try:
>  hashlib_algorithms = hashlib.algorithms
>  except:
> @@ -479,7 +481,8 @@ def _git_downloader(url, local, config, opts):
>  else:
>  repo.clean(['-f', '-d'])
>  repo.reset('--hard')
> -repo.checkout('master')
> +default_branch = repo.default_branch()
> +repo.checkout(default_branch)
>  for a in us[1:]:
>  _as = a.split('=')
>  if _as[0] == 'branch' or _as[0] == 'checkout':
> diff --git a/source-builder/sb/git.py b/source-builder/sb/git.py
> index 237e690..0aa4da9 100644
> --- a/source-builder/sb/git.py
> +++ b/source-builder/sb/git.py
> @@ -226,6 +226,18 @@ class repo:
>  hash = l1[len('commit '):]
>  return hash
>
> +def default_branch(self):
> +ec, output = self._run(['remote', 'show'])
> +if ec == 0:
> +origin = output.split('\n')[0]
> +ec, output = self._run(['remote', 'show', origin])
> +if ec == 0:
> +for l in output.split('\n'):
> +l = l.strip()
> +if l.startswith('HEAD branch: '):
> +return l[len('HEAD branch: '):]
> +return None
> +
>  if __name__ == '__main__':
>  import os.path
>  import sys
> diff --git a/source-builder/sb/rtemspkg.py b/source-builder/sb/rtemspkg.py
> new file mode 100644
> index 000..0b43d23
> --- /dev/null
> +++ b/source-builder/sb/rtemspkg.py
> @@ -0,0 +1,279 @@
> +#
> +# RTEMS Tools Project (http://www.rtems.org/)
> +# Copyright 2024 Chris Johns (chr...@rtems.org)
> +# All rights reserved.
> +#
> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
> +#
> +# Permission to use, copy, modify, and/or distribute this software for any
> +# purpose with or without fee is hereby granted, provided that the above
> +# copyright notice and this permission notice appear in all copies.
> +#
> +# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> +# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> +# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> +# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> +# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> +# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> +# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> +
> +#
> +# This code builds a package compiler tool suite given a tool set. A tool
> +# set lists the various tools. These are specific tool configurations.
> +#
> +
> +from 

Re: [RSB PATCH] rtems: Update RTEMS packages to their HEAD

[Joel Sherrill]

Looks good. I will push.

On Tue, Apr 2, 2024 at 11:23 PM  wrote:

> From: Chris Johns 
>
> ---
>  rtems/config/tools/rtems-kernel-6.cfg | 4 ++--
>  rtems/config/tools/rtems-libbsd-6.cfg | 4 ++--
>  rtems/config/tools/rtems-tools-6.cfg  | 6 +++---
>  3 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/rtems/config/tools/rtems-kernel-6.cfg
> b/rtems/config/tools/rtems-kernel-6.cfg
> index 1e90184..9219263 100644
> --- a/rtems/config/tools/rtems-kernel-6.cfg
> +++ b/rtems/config/tools/rtems-kernel-6.cfg
> @@ -2,10 +2,10 @@
>  # RTEMS 6
>  #
>
> -%define rtems_kernel_version e7cb79c39d8dbc02ded1d6d9c37ee00323508bf3
> +%define rtems_kernel_version 1ef5fa07aa87adc9925c75060a7888f110104fa7
>
>  %hash sha512 rtems-kernel-%{rtems_kernel_version}.tar.bz2 \
> -
>  
> ZLKEYfCw1B7bzEMixtVB8Ire77RqdidztgGj6bX9LL/fYqfG74UNkyLl9uMK4mGKML3xOszXKn+lURAhyfDhDg==
> +
> 5WE5sLbkU9p3atZ9PV6Dcy1TGKXZKErJ+kEfe9j6IyXohS3vc76hFIrVt8I8beDDKEogNB8HAuVsZklPv3YViA==
>  #
>  # The RTEMS build instructions.
>  #
> diff --git a/rtems/config/tools/rtems-libbsd-6.cfg
> b/rtems/config/tools/rtems-libbsd-6.cfg
> index 3dfc693..c71ba07 100644
> --- a/rtems/config/tools/rtems-libbsd-6.cfg
> +++ b/rtems/config/tools/rtems-libbsd-6.cfg
> @@ -3,9 +3,9 @@
>  #
>
>  #  branch: 6-freebsd-12
> -%define rtems_libbsd_version 1524f95e93a0e0ff85d676d214e0e57cac44e4f5
> +%define rtems_libbsd_version 388d46bb1b3080402c68ae11d14b2b36c3138952
>  %hash sha512 rtems-libbsd-%{rtems_libbsd_version}.tar.bz2 \
> -
> QiNVx1kFPcX9tmkY2mdWO2gb/t32J+AJkXOBAkyjfsaUuvBz43oMeOrpBFJuuix6eTmmukSzAulUCLdqBJlAWQ==
> +
> zMyTB+Z7vJXpywhCbRCK/vz2KUbwdg1JwoQ/JPqFbicmo/W42D/fGjKFxhPrzg0mL4silqSJ4xPdfOhET5vrtw==
>  %define rtems_waf_version ad08908c452c6a9bbb3bf7bbbcc9fc03fe46cc7f
>  %hash sha512 rtems_waf-%{rtems_waf_version}.tar.bz2 \
>
>  
> EyuEit0DsAR1gK9Ki1sjl416PFgFe7dcggH3H/hmdAPmMjEIIdX7TVOTDgOIK1Pt0DW6lZ9NcW7O87GZFyy8hg==
> diff --git a/rtems/config/tools/rtems-tools-6.cfg
> b/rtems/config/tools/rtems-tools-6.cfg
> index 8abfeea..9a1c625 100644
> --- a/rtems/config/tools/rtems-tools-6.cfg
> +++ b/rtems/config/tools/rtems-tools-6.cfg
> @@ -10,14 +10,14 @@
>   %define rtems_tools_source rtems-tools-%{rtems_tools_version}
>   %define rtems_tools_ext xz
>  %else
> - %define rtems_tools_version 12971a8
> +%define rtems_tools_version 12971a8b858add612833a43360e7a7ba95902d3e
>   %define rtems_tools_ext bz2
>  %endif
>
>  %define rtems_tools_source rtems-tools-%{rtems_tools_version}
>  %source set rtems-tools
> https://git.rtems.org/rtems-tools/snapshot/%{rtems_tools_source}.tar.%{rtems_tools_ext}
> -%hash   sha512 rtems-tools-%{rtems_tools_version}.tar.bz2 \
> -
> SrjY0gweRgWHmqBYj0wFnu1LFkaeNeS05SD1dKVzz2kvs3UCZ6AM8DrLbVe0q4H14DZwmrE3mMgbutsVev0Oxg==
> +%hash sha512 rtems-tools-%{rtems_tools_version}.tar.bz2 \
> +
> SpaYAsHhzHncHC0tlQOJwexUJ7i+l5yG1Vf8Twl61dAyOEYhkugjvRCtchN4GJQmzPrqjqFIdwciemveysouJA==
>
>  #
>  # Optionally enable/disable building the RTEMS Tools via the command line.
> --
> 2.42.0
>
> ___
> 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: Finished Hello World Example

[Joel Sherrill]

This patch looks ok. We also need a screenshot of it running.

I hope you made the deadline of applying via the Google site.

We track proposals at https://devel.rtems.org/wiki/GSoC/2024

On Tue, Apr 2, 2024 at 2:47 PM SEAN TANG  wrote:

>
> ___
> 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: Clarification Regarding Initial Project Scope for "Add BSP for Polarfire based Beagle"

[Joel Sherrill]

On Tue, Apr 2, 2024, 9:28 AM Purva Yeshi  wrote:

> Hello,
>
> I'm reaching out to seek clarification regarding the initial scope of the
> "Add BSP for Polarfire based Beagle" project that I've applied for.
>
> As outlined in the project description, the primary aim is to create a BSP
> for the Beagle-V Fire board. Therefore, one part of the project involves
> developing support for essential components such as CPU cores (both E51 and
> U54), interrupt controller (PLIC), timer (CLINT), and UART. If the
> UART, CPU cores, interrupt controller and timer are already supported, I'm
> considering modifications may be required for the *particular hardware*
> BSP.
>
> Considering these requirements,  I'm seeking clarification on whether it
> would be acceptable   to focus on running a "Hello World" code on the
> Beagle-V Fire board at the initial stage. My plan is to prioritize the
> implementation of support for the aforementioned components while keeping
> Ethernet and U54 MMU support for future development.
>
> Could you please provide guidance on whether running a "Hello World" code
> initially aligns with the project's expectations? Additionally, I would
> like to know if there is a high requirement to include support for Ethernet
> and U54 MMU in the proposal, or if it could be considered as part of the
> future scope.
>

When authoring a new BSP, it is best to focus on hello world and then
ticker. With those working, all of the tests in RTEMS.git should be ok. So
third is testing using RTEMS tester

Then focus on additional capabilities like adding individual devices
drivers, SMP, etc.

But if you cannot run hello and ticker, nothing else will be worth running

>
> ___
> 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: PowerPC e7400 executable is type powerpc:e500 making debug difficult

[Joel Sherrill]

On Sat, Mar 30, 2024, 12:18 PM Peter Dufault  wrote:

> It's the source code lines that I quoted that cause the problem.
>
> To avoid getting the object defined as an e500 then that file needs to be
> conditionally compiled (I think that's the way it is, there should be
> another way, having a binary that adapts to its target isn't *that*
> evil.).  Including those e500 instructions "taints" the object.  That's the
> only object I could find that wasn't e7400.
>
> I guess there is a rule for the ABI to promote objects up to whatever
> architecture includes all the instructions that are present.  And that
> survives through the linker stage.  So that particular object file winds up
> needing the "Signal Processing Extensions", as do any executables that it
> is linked into.
>
> It makes sense, it also makes sense to have a way to avoid it.
>

It also leads to dead/unused code in any deployment whose BSP uses this file


Feel free to submit a patch

>

> > On Mar 29, 2024, at 2:05 PM, Joel Sherrill  wrote:
> >
> > Hi
> >
> > Chris and I discussed this for a few minutes last night and wondered if
> > code like this which includes arbitrary CPU model specific code could
> > be the culprit?
> >
> >
> https://git.rtems.org/rtems/tree/bsps/powerpc/shared/exceptions/ppc_exc_initialize.c#n65
> >
> > There may be other sections that do this.
> >
> > If this were wrapped in a conditional for the proper CPU core variants,
> it
> > might resolve the issue. One would hope that if there were no e500 code,
> > binutils and gdb wouldn't get confused.
> >
> > --joel
> >
> > On Wed, Mar 27, 2024 at 12:19 PM Peter Dufault  wrote:
> > The PowerPC e7400 executables I built for the PowerPC-Beatnik BSP have
> an architecture of "powerpc:e500".  I assume it is like this for any
> powerpc target that includes "ppc_exc_initialize.c". This causes "GDB" to
> use the wrong size register set in remote debugging, and I couldn't figure
> out how to convince "gdb" to do something different.  I tried multiple
> settings but the "bfd_arch_info" wouldn't change from "powerpc:e500" (seen
> with "maint print architecture") and "gdb" continued to use the wrong
> register set size.
> >
> > (gdb) set powerpc vector-abi altivec
> > (gdb) set arch powerpc:7400
> > The target architecture is set to "powerpc:7400".
> > (gdb) set gnutarget powerpc:7400
> > (gdb) target remote 192.168.240.3:2159
> > Remote debugging using 192.168.240.3:2159
> > Remote 'g' packet reply is too long (expected 292 bytes, got 412 bytes):
> 003a5914007a0ae0007a7b60006577e00052af140052af1c007a0ac80a010014003764ec2062885000645760007a0ae00037265c0202b03240376508003764ecfff8
> > (gdb) maint print architecture
> > gdbarch_dump: GDB_NM_FILE = 
> > gdbarch_dump: bfd_arch_info = powerpc:e500
> > gdbarch_dump: byte_order = 0
> > gdbarch_dump: byte_order_for_code = 0
> > (...)
> >
> > This is because "ppc_exc_initialize.o" has a ".PPC.EMB.apuinfo" section
> that says it needs the "E500 SPE APU".  Here's what is in that section.
> >
> > 0 | 0008 | 8 bytes in "APUinfo\0"
> > 4 | 0008 | 8 bytes (2 words) of APU information.
> > 8 | 0002 | Section type is rev 2.
> > 12 | "APUinfo\0"
> > 16 | 0101 | APU 0x100 "e500 SPE APU" revision 1
> > 20 | 00410001 | APU 0x041 "Motorola Book E Performance Monitor APU"
> revision 1.
> >
> > The resultant linked output is the superset of all requirements, so the
> linked output is also "powerpc:e500".
> >
> > This is because "ppc_exc_initialize.c" includes instructions for
> different targets that it avoids at run time.
> >
> > These code lines cause the ".o" to be "powerpc:e500":
> >
> > ppc_mtivor(32, ppc_exc_vector_address(ASM_E500_SPE_UNAVAILABLE

Re: approve google docs editing request

[Joel Sherrill]

You do not edit the master proposal template. You make a copy of it and
turn it into your proposal.

--joel

On Sat, Mar 30, 2024 at 12:29 AM ashish ashish 
wrote:

> I requested on google docs for editing to write my proposal. and it needs
> approval.
> please approve it.
> request with email: ashishashish7...@gmail.com
> thanks.
> ___
> 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: PowerPC e7400 executable is type powerpc:e500 making debug difficult

[Joel Sherrill]

Hi

Chris and I discussed this for a few minutes last night and wondered if
code like this which includes arbitrary CPU model specific code could
be the culprit?

https://git.rtems.org/rtems/tree/bsps/powerpc/shared/exceptions/ppc_exc_initialize.c#n65

There may be other sections that do this.

If this were wrapped in a conditional for the proper CPU core variants, it
might resolve the issue. One would hope that if there were no e500 code,
binutils and gdb wouldn't get confused.

--joel

On Wed, Mar 27, 2024 at 12:19 PM Peter Dufault  wrote:

> The PowerPC e7400 executables I built for the PowerPC-Beatnik BSP have an
> architecture of "powerpc:e500".  I assume it is like this for any powerpc
> target that includes "ppc_exc_initialize.c". This causes "GDB" to use the
> wrong size register set in remote debugging, and I couldn't figure out how
> to convince "gdb" to do something different.  I tried multiple settings but
> the "bfd_arch_info" wouldn't change from "powerpc:e500" (seen with "maint
> print architecture") and "gdb" continued to use the wrong register set size.
>
> (gdb) set powerpc vector-abi altivec
> (gdb) set arch powerpc:7400
> The target architecture is set to "powerpc:7400".
> (gdb) set gnutarget powerpc:7400
> (gdb) target remote 192.168.240.3:2159
> Remote debugging using 192.168.240.3:2159
> Remote 'g' packet reply is too long (expected 292 bytes, got 412 bytes):
> 003a5914007a0ae0007a7b60006577e00052af140052af1c007a0ac80a010014003764ec2062885000645760007a0ae00037265c0202b03240376508003764ecfff8
> (gdb) maint print architecture
> gdbarch_dump: GDB_NM_FILE = 
> gdbarch_dump: bfd_arch_info = powerpc:e500
> gdbarch_dump: byte_order = 0
> gdbarch_dump: byte_order_for_code = 0
> (...)
>
> This is because "ppc_exc_initialize.o" has a ".PPC.EMB.apuinfo" section
> that says it needs the "E500 SPE APU".  Here's what is in that section.
>
> 0 | 0008 | 8 bytes in "APUinfo\0"
> 4 | 0008 | 8 bytes (2 words) of APU information.
> 8 | 0002 | Section type is rev 2.
> 12 | "APUinfo\0"
> 16 | 0101 | APU 0x100 "e500 SPE APU" revision 1
> 20 | 00410001 | APU 0x041 "Motorola Book E Performance Monitor APU"
> revision 1.
>
> The resultant linked output is the superset of all requirements, so the
> linked output is also "powerpc:e500".
>
> This is because "ppc_exc_initialize.c" includes instructions for different
> targets that it avoids at run time.
>
> These code lines cause the ".o" to be "powerpc:e500":
>
> ppc_mtivor(32, ppc_exc_vector_address(ASM_E500_SPE_UNAVAILABLE_VECTOR,
> vector_base));
> ppc_mtivor(33, ppc_exc_vector_address(ASM_E500_EMB_FP_DATA_VECTOR,
> vector_base));
> ppc_mtivor(34, ppc_exc_vector_address(ASM_E500_EMB_FP_ROUND_VECTOR,
> vector_base));
>
> This line causes the ".o" to be "powerpc:titan" (if the above E500 lines
> are removed):
>
> ppc_mtivor(35, ppc_exc_vector_address(ASM_E500_PERFMON_VECTOR,
> vector_base));
>
> I "#ifdef'd" them out to get it to "work" but unless someone can figure
> out how to get rid of that section in the output "ppc_exc_initialize.c"
> needs to be changed to be conditionally compiled.
>
> If no one has any good ideas I'll open a bug with this.
>
> Peter
> -
> Peter Dufault
> HD Associates, Inc.  Software and System Engineering
>
>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 0/1] x86_64: Fix stack aligment for x86-64 SysV ABI

[Joel Sherrill]

This is a great explanation. Would you mind filing a ticket with this
explanatino and referencing the ticket in the commit message of the patch?

When someone wonders about the change in the future, the ticket explanation
will be useful

On Fri, Mar 22, 2024 at 9:24 PM Matheus Pecoraro  wrote:

> I kept getting a general protection fault whenever attempting to
> execute the amd64 BSP while preparing for my GSOC proposal.
>
> The GPF was being caused by an instruction attempting to move an SSE
> register to an address on the stack not aligned to 16 bytes. After
> some debugging I noticed that the code for setting up the stack frame
> for a context would result in it being misaligned by 8 bytes as to
> what is expected by the x86-64 SysV ABI, thus leading the compiler to
> unknowingly cause the exception (when control is transferred to the
> function entry point RSP+8 is supposed to be a multiple of 16, without
> this patch RSP itself was a multiple of 16).
>
> After the fix I was able to run the hello test on the amd64 BSP both
> while booting through the FreeBSD bootloader with no EFI boot services
> as well as through GRUB with multiboot2 and EFI boot services.
>
> Matheus Pecoraro (1):
>   x86_64: Fix stack aligment for x86-64 SysV ABI
>
>  bsps/x86_64/amd64/clock/eficlock.c| 28 ++-
>  bsps/x86_64/amd64/start/start.S   |  1 -
>  .../cpu/x86_64/x86_64-context-initialize.c|  4 +--
>  3 files changed, 5 insertions(+), 28 deletions(-)
>
> --
> 2.43.0
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [Docs] c-user: Clarify CONFIGURE_TICKS_PER_TIMESLICE

[Joel Sherrill]

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

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

OK. Just didn't see a patch posted.

>
> Module:rtems-central
> Branch:master
> Commit:f5e42e5d9fae95e50f41a2ed71ee94e9908612c0
> Changeset:
>
> http://git.rtems.org/rtems-central/commit/?id=f5e42e5d9fae95e50f41a2ed71ee94e9908612c0
>
> Author:Sebastian Huber 
> Date:  Thu Mar 21 11:55:22 2024 +0100
>
> spec: Fix CONFIGURE_TICKS_PER_TIMESLICE constraint
>
> Update #4986.
>
> --
> embedded brains GmbH & Co. KG
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [Docs] c-user: Clarify CONFIGURE_TICKS_PER_TIMESLICE

[Joel Sherrill]

Isn't this content generated from rtems-central?

Shouldn't there also be a change there?

--joel

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

> Close #4986.
> ---
>  c-user/config/general.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/c-user/config/general.rst b/c-user/config/general.rst
> index 5ff79e7..61bfa1e 100644
> --- a/c-user/config/general.rst
> +++ b/c-user/config/general.rst
> @@ -1017,7 +1017,7 @@ configured, see
> :ref:`CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER`.
>
>  The following constraints apply to this configuration option:
>
> -* The value of the configuration option shall be greater than or equal to
> zero.
> +* The value of the configuration option shall be greater than or equal to
> one.
>
>  * The value of the configuration option shall be less than or equal to
>`UINT32_MAX `_.
> --
> 2.35.3
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

gprof Support

[Joel Sherrill]

Hi

Did gprof support some along as a side-effect of gcov support?

Any hints on getting it working appreciated.

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

Re: [PATCH] Do not define CONFIGURE_TICKS_PER_TIMESLICE to 0

[Joel Sherrill]

This is generally ok but it contradicts the documented behavior
for CONFIGURE_TICKS_PER_TIMESLICE which states "The value of the
configuration option shall be greater than or equal to zero."

If zero is to be an error, then that needs to change.

Further, this series of changes has made me realize that
CONFIGURE_TICKS_PER_TIMESLICE and CONFIGURE_MICROSECONDS_PER_TICK should
not be defined if the application has not defined
CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER. Currently the documentation just
says it has no effect.

Also the formatting of the text in the description is inconsistent. Could a
ref be used for all of this?

The application shall define exactly one of the following configuration
options

* :ref:`CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER`,
* ``CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER``, or
* :ref:`CONFIGURE_APPLICATION_NEEDS_TIMER_DRIVER`,

--joel

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

> Unconditionally make a CONFIGURE_TICKS_PER_TIMESLICE value less than or
> equal
> to zero an error.
>
> Update #4986.
> ---
>  cpukit/doxygen/appl-config.h  | 2 +-
>  cpukit/include/rtems/confdefs/clock.h | 3 +--
>  testsuites/ada/tmtests/tm01/init.c| 1 -
>  testsuites/ada/tmtests/tm02/init.c| 1 -
>  testsuites/ada/tmtests/tm03/init.c| 1 -
>  testsuites/ada/tmtests/tm04/init.c| 1 -
>  testsuites/ada/tmtests/tm05/init.c| 1 -
>  testsuites/ada/tmtests/tm06/init.c| 1 -
>  testsuites/ada/tmtests/tm07/init.c| 1 -
>  testsuites/ada/tmtests/tm08/init.c| 1 -
>  testsuites/ada/tmtests/tm09/init.c| 1 -
>  testsuites/ada/tmtests/tm10/init.c| 1 -
>  testsuites/ada/tmtests/tm11/init.c| 1 -
>  testsuites/ada/tmtests/tm12/init.c| 1 -
>  testsuites/ada/tmtests/tm13/init.c| 1 -
>  testsuites/ada/tmtests/tm14/init.c| 1 -
>  testsuites/ada/tmtests/tm15/init.c| 1 -
>  testsuites/ada/tmtests/tm16/init.c| 1 -
>  testsuites/ada/tmtests/tm17/init.c| 1 -
>  testsuites/ada/tmtests/tm18/init.c| 1 -
>  testsuites/ada/tmtests/tm19/init.c| 1 -
>  testsuites/ada/tmtests/tm20/init.c| 1 -
>  testsuites/ada/tmtests/tm21/init.c| 1 -
>  testsuites/ada/tmtests/tm22/init.c| 1 -
>  testsuites/ada/tmtests/tm23/init.c| 1 -
>  testsuites/ada/tmtests/tm24/init.c| 1 -
>  testsuites/ada/tmtests/tm25/init.c| 1 -
>  testsuites/ada/tmtests/tm28/init.c| 1 -
>  testsuites/ada/tmtests/tm29/init.c| 1 -
>  testsuites/ada/tmtests/tmck/init.c| 1 -
>  testsuites/rhealstone/rhdeadlockbrk/deadlockbrk.c | 1 -
>  testsuites/rhealstone/rhilatency/ilatency.c   | 1 -
>  testsuites/rhealstone/rhmlatency/mlatency.c   | 1 -
>  testsuites/rhealstone/rhtaskpreempt/taskpreempt.c | 1 -
>  testsuites/rhealstone/rhtaskswitch/taskswitch.c   | 1 -
>  testsuites/tmtests/tm01/system.h  | 1 -
>  testsuites/tmtests/tm02/system.h  | 1 -
>  testsuites/tmtests/tm03/system.h  | 1 -
>  testsuites/tmtests/tm04/system.h  | 1 -
>  testsuites/tmtests/tm05/system.h  | 1 -
>  testsuites/tmtests/tm06/system.h  | 1 -
>  testsuites/tmtests/tm07/system.h  | 1 -
>  testsuites/tmtests/tm08/system.h  | 1 -
>  testsuites/tmtests/tm09/system.h  | 1 -
>  testsuites/tmtests/tm10/system.h  | 1 -
>  testsuites/tmtests/tm11/system.h  | 1 -
>  testsuites/tmtests/tm12/system.h  | 1 -
>  testsuites/tmtests/tm13/system.h  | 1 -
>  testsuites/tmtests/tm14/system.h  | 1 -
>  testsuites/tmtests/tm15/system.h  | 1 -
>  testsuites/tmtests/tm16/system.h  | 1 -
>  testsuites/tmtests/tm17/system.h  | 1 -
>  testsuites/tmtests/tm18/system.h  | 1 -
>  testsuites/tmtests/tm19/system.h  | 1 -
>  testsuites/tmtests/tm20/system.h  | 1 -
>  testsuites/tmtests/tm21/system.h  | 1 -
>  testsuites/tmtests/tm22/system.h  | 1 -
>  testsuites/tmtests/tm23/system.h  | 1 -
>  testsuites/tmtests/tm24/system.h  | 1 -
>  testsuites/tmtests/tm25/system.h  | 1 -
>  testsuites/tmtests/tm26/system.h  | 1 -
>  testsuites/tmtests/tm27/system.h  | 1 -
>  testsuites/tmtests/tm28/system.h  | 1 -
>  testsuites/tmtests/tm29/system.h  | 1 -
>  testsuites/tmtests/tmck/system.h  | 1 -
>  65 files changed, 2 insertions(+), 66 deletions(-)
>
> 

Re: [PATCH] improved error checking in ticks per timeslice

[Joel Sherrill]

No. Just a lesson to remember -- Everyone along the path should have built
rtems with all tests enabled.

This is something that should never happen after the upcoming transition to
GitLab. It definitely shows we need to build at least one BSP with tests
enabled.


On Mon, Mar 18, 2024, 7:45 PM zack leung  wrote:

>  Do I need to do anything?
>
>
> On Mon, 18 Mar 2024 at 16:38, Kinsey Moore 
> wrote:
>
>> Sorry, I didn't realize I had tests turned off in my local build when I
>> checked this. The test is now gated behind NEEDS_CLOCK_DRIVER as well.
>>
>> Kinsey
>>
>> On Mon, Mar 18, 2024 at 4:15 AM Sebastian Huber <
>> sebastian.hu...@embedded-brains.de> wrote:
>>
>>> This patch breaks the build:
>>>
>>> In file included from ../../../cpukit/include/rtems/confdefs.h:64,
>>>   from
>>> ../../../testsuites/rhealstone/rhdeadlockbrk/deadlockbrk.c:215:
>>> ../../../cpukit/include/rtems/confdefs/clock.h:74:4: error: #error
>>> "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
>>> 74 |   #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than
>>> zero"
>>>|^
>>>
>>> In file included from ../../../cpukit/include/rtems/confdefs.h:64,
>>>   from
>>> ../../../testsuites/rhealstone/rhmlatency/mlatency.c:158:
>>> ../../../cpukit/include/rtems/confdefs/clock.h:74:4: error: #error
>>> "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
>>> 74 |   #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than
>>> zero"
>>>|^
>>>
>>> In file included from ../../../cpukit/include/rtems/confdefs.h:64,
>>>   from
>>> ../../../testsuites/rhealstone/rhtaskswitch/taskswitch.c:122:
>>> ../../../cpukit/include/rtems/confdefs/clock.h:74:4: error: #error
>>> "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
>>> 74 |   #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than
>>> zero"
>>>|^
>>>
>>> In file included from ../../../cpukit/include/rtems/confdefs.h:64,
>>>   from
>>> ../../../testsuites/rhealstone/rhilatency/ilatency.c:29:
>>> ../../../cpukit/include/rtems/confdefs/clock.h:74:4: error: #error
>>> "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
>>> 74 |   #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than
>>> zero"
>>>|^
>>>
>>> In file included from ../../../cpukit/include/rtems/confdefs.h:64,
>>>   from
>>> ../../../testsuites/rhealstone/rhtaskpreempt/taskpreempt.c:120:
>>> ../../../cpukit/include/rtems/confdefs/clock.h:74:4: error: #error
>>> "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
>>> 74 |   #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than
>>> zero"
>>>|^
>>>
>>> --
>>> embedded brains GmbH & Co. KG
>>> Herr Sebastian HUBER
>>> Dornierstr. 4
>>> 82178 Puchheim
>>> Germany
>>> email: sebastian.hu...@embedded-brains.de
>>> phone: +49-89-18 94 741 - 16
>>> fax:   +49-89-18 94 741 - 08
>>>
>>> Registergericht: Amtsgericht München
>>> Registernummer: HRB 157899
>>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>>> Unsere Datenschutzerklärung finden Sie hier:
>>> https://embedded-brains.de/datenschutzerklaerung/
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: utf32 support

[Joel Sherrill]

What does support for UTF-32 entail? Do you have an idea what software
functions you are looking for?

I see the International Components for Unicode (ICU) has a converter (
https://icu.unicode.org/download) which looks it might be part of a
solution.

Multibyte character methods defined by POSIX would be in newlib.

I'm not well versed in this area so have questions but I think it basically
comes down to what software libraries an application needs and porting
those to RTEMS -- assuming the license is ok.

--joel

On Mon, Mar 18, 2024 at 12:15 PM John Howard  wrote:

> I want to add utf32 support.
>
> Where do I start?
>
> — John
> ___
> 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

RTEMS 7 GDB Build Failure on FreeBSD 13

[Joel Sherrill]

Hi

I am going through the logs on the test sweep VMs to see why some builds
are failing. This is due to gdb's requirement for GMP and MPFR. What's the
recommended way to address this? Load native packages?

checking for the correct version of gmp.h... yes
checking for the correct version of mpfr.h... no
configure: error: Building GDB requires GMP 4.2+, and MPFR 3.1.0+.
Try the --with-gmp and/or --with-mpfr options to specify
their locations.  If you obtained GMP and/or MPFR from a vendor
distribution package, make sure that you have installed both the libraries
and the header files.  They may be located in separate packages.
shell cmd failed: /bin/sh -ex
 /usr/home/tester/rtems-cron-7/rtems-source-builde

Thanks.

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

Re: [PATCH rtems-tools] rtems-score-thread.ini: Remove _Thread_Close so trace examples link

[Joel Sherrill]

Thanks. All pushed now.

On Thu, Mar 14, 2024 at 6:46 PM Chris Johns  wrote:

> OK
>
> Thanks
> Chris
>
> On 12/3/2024 1:06 am, Joel Sherrill wrote:
> > _Thread_Close no longer exists. There are multiple exapmles which
> > show tracing in rtems-examples which fail to link due to this.
> > ---
> >  linkers/rtems-score-thread.ini | 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/linkers/rtems-score-thread.ini
> b/linkers/rtems-score-thread.ini
> > index 974bcfd..a759f72 100644
> > --- a/linkers/rtems-score-thread.ini
> > +++ b/linkers/rtems-score-thread.ini
> > @@ -5,7 +5,7 @@
> >  trace = _Thread_Handler_initialization, _Thread_Create_idle,
> _Thread_Start_multitasking
> >  trace = _Stack_Allocate, _Stack_Free, _Thread_Start
> >  trace = _Thread_Yield, _Thread_Set_life_protection
> > -trace = _Thread_Kill_zombies, _Thread_Close
> > +trace = _Thread_Kill_zombies
> >  trace = _Thread_Clear_state, _Thread_Set_state, _Thread_Load_environment
> >  trace = _Thread_Handler
> >  trace = _Thread_Get
> > @@ -19,7 +19,7 @@ trace = _Stack_Allocate, _Thread_Start
> >  trace = _Thread_Restart, _Thread_Handler
> >
> >  [rtems-score-thread-destroy]
> > -trace = _Thread_Kill_zombies, _Thread_Close
> > +trace = _Thread_Kill_zombies
> >
> >  [rtems-score-thread-activity]
> >  trace = _Thread_Yield, _Thread_Set_life_protection
> > @@ -38,7 +38,6 @@ _Thread_Start = Status_Control, Thread_Control*, const
> Thread_Entry_information*
> >  _Thread_Yield = void, Thread_Control*
> >  _Thread_Set_life_protection = Thread_Life_state, Thread_Life_state
> >  _Thread_Kill_zombies = void, void
> > -_Thread_Close = void, Thread_Control*, Thread_Control*,
> Thread_Close_context*
> >  _Thread_Clear_state = States_Control, Thread_Control*, States_Control
> >  _Thread_Set_state = States_Control, Thread_Control*, States_Control
> >  _Thread_Load_environment = void, Thread_Control*
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH rtems-source-builder 2/2] rtems-gcc-*-newlib-head.cfg: Bump hash for newlib

[Joel Sherrill]

This was driven by the increase in fdset size from 64 to 256
files.
---
 rtems/config/tools/rtems-gcc-10-newlib-head.cfg   | 4 ++--
 rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg | 4 ++--
 rtems/config/tools/rtems-gcc-12-newlib-head.cfg   | 4 ++--
 rtems/config/tools/rtems-gcc-13-newlib-head.cfg   | 4 ++--
 rtems/config/tools/rtems-gcc-13.2-newlib-head.cfg | 4 ++--
 rtems/config/tools/rtems-gcc-head-newlib-head.cfg | 4 ++--
 6 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg 
b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
index 387e8c9..1627dac 100644
--- a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
+++ b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
@@ -14,12 +14,12 @@
 %patch add gcc -p1 
https://devel.rtems.org/raw-attachment/ticket/4215/0001-nios2-Remove-custom-instruction-warnings.patch
 %hash sha512 0001-nios2-Remove-custom-instruction-warnings.patch 
afd8a5e6bdcc5b75d5fbbf558bdf56ccac400521a6eec9d88cc95f6be67c481f2dbf8faa0f6ddc1e4ac7c56a84938714d80e46e9cf80ec4b8fcd739986449881
 
-%define newlib_version 3cacedb
+%define newlib_version 176b19f
 %define newlib_external 1
 %define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
 %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz 
https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
 %hash sha512 newlib-%{newlib_version}.tar.gz \
-  
ia0ce+bdENUO3qYj00jrZB8FjSejmTWuRqEdNE8nI2llf30mh8leUn5fCoHB0Oa7rRVBjEu3n0F12ZK9skuegQ==
+  
ZUzGjXI3ZJ6GrxMXggg+jIO0nyi+edKoilckRxtujsOiwhOyITahIqcOHhZiX5nd4E4UX9p3BSDima/Fd0Gr0w==
 
 %define with_threads 1
 %define with_plugin 0
diff --git a/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg 
b/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
index b37af1e..315f70b 100644
--- a/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
+++ b/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
@@ -17,12 +17,12 @@
 %patch add gcc -p1 
https://devel.rtems.org/raw-attachment/ticket/4215/0001-nios2-Remove-custom-instruction-warnings.patch
 %hash sha512 0001-nios2-Remove-custom-instruction-warnings.patch 
afd8a5e6bdcc5b75d5fbbf558bdf56ccac400521a6eec9d88cc95f6be67c481f2dbf8faa0f6ddc1e4ac7c56a84938714d80e46e9cf80ec4b8fcd739986449881
 
-%define newlib_version 3cacedb
+%define newlib_version 176b19f
 %define newlib_external 1
 %define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
 %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz 
https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
 %hash sha512 newlib-%{newlib_version}.tar.gz \
-  
ia0ce+bdENUO3qYj00jrZB8FjSejmTWuRqEdNE8nI2llf30mh8leUn5fCoHB0Oa7rRVBjEu3n0F12ZK9skuegQ==
+  
ZUzGjXI3ZJ6GrxMXggg+jIO0nyi+edKoilckRxtujsOiwhOyITahIqcOHhZiX5nd4E4UX9p3BSDima/Fd0Gr0w==
 
 %define with_threads 1
 %define with_plugin 0
diff --git a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg 
b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
index 4a31a50..4387486 100644
--- a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
+++ b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
@@ -34,13 +34,13 @@
 
KEmxHjYOqY4LTXCMZ3I60tbHusbR5GlnP0CLARHPAnhCnovDj9K3U43C1bsMxDDGRqD6fwtrEFoEgqVFX63IuQ==
 # Comment above related to #4657 and patches ends here
 
-%define newlib_version 3cacedb
+%define newlib_version 176b19f
 %define newlib_external 1
 %define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
 %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz \

https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
 %hash sha512 newlib-%{newlib_version}.tar.gz \
-  
ia0ce+bdENUO3qYj00jrZB8FjSejmTWuRqEdNE8nI2llf30mh8leUn5fCoHB0Oa7rRVBjEu3n0F12ZK9skuegQ==
+  
ZUzGjXI3ZJ6GrxMXggg+jIO0nyi+edKoilckRxtujsOiwhOyITahIqcOHhZiX5nd4E4UX9p3BSDima/Fd0Gr0w==
 
 %define with_threads 1
 %define with_plugin 0
diff --git a/rtems/config/tools/rtems-gcc-13-newlib-head.cfg 
b/rtems/config/tools/rtems-gcc-13-newlib-head.cfg
index efd546b..c73d5a6 100644
--- a/rtems/config/tools/rtems-gcc-13-newlib-head.cfg
+++ b/rtems/config/tools/rtems-gcc-13-newlib-head.cfg
@@ -8,12 +8,12 @@
 %hash sha512 %{gcc_expand_name}.tar.gz \
   
YSkX/JY61N+I4CPkJInUNGzwhb+uv+YNs9qcTxxJhg/HpGD5vI9duEPNw++F3y8J4re87DPJGIzV5DsFUBCJnA==
 
-%define newlib_version 3cacedb
+%define newlib_version 176b19f
 %define newlib_external 1
 %define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
 %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz 
https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
 %hash sha512 newlib-%{newlib_version}.tar.gz \
-  
ia0ce+bdENUO3qYj00jrZB8FjSejmTWuRqEdNE8nI2llf30mh8leUn5fCoHB0Oa7rRVBjEu3n0F12ZK9skuegQ==
+  
ZUzGjXI3ZJ6GrxMXggg+jIO0nyi+edKoilckRxtujsOiwhOyITahIqcOHhZiX5nd4E4UX9p3BSDima/Fd0Gr0w==
 
 %define with_threads 1
 %define with_plugin 0
diff --git 

[PATCH rtems-source-builder 1/2] rtems-tools-6.cfg: Bump hash to account for 5 months of changes

[Joel Sherrill]

In particular, the BSP set definitions for rtems-bsp-builder were
out of sync with RTEMS and caused unnecessary failures reported to
the build@ mailing list.
---
 rtems/config/tools/rtems-tools-6.cfg | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/rtems/config/tools/rtems-tools-6.cfg 
b/rtems/config/tools/rtems-tools-6.cfg
index 7ef2052..8abfeea 100644
--- a/rtems/config/tools/rtems-tools-6.cfg
+++ b/rtems/config/tools/rtems-tools-6.cfg
@@ -10,14 +10,14 @@
  %define rtems_tools_source rtems-tools-%{rtems_tools_version}
  %define rtems_tools_ext xz
 %else
- %define rtems_tools_version f408c0f8d935d53c232c67bed39e4018fd8d7a2a
+ %define rtems_tools_version 12971a8
  %define rtems_tools_ext bz2
 %endif
 
 %define rtems_tools_source rtems-tools-%{rtems_tools_version}
 %source set rtems-tools 
https://git.rtems.org/rtems-tools/snapshot/%{rtems_tools_source}.tar.%{rtems_tools_ext}
 %hash   sha512 rtems-tools-%{rtems_tools_version}.tar.bz2 \
-   
xZIWwcW4y9wOsIY+8XWDAxKk51TwKFHeOw39SS6zxrgE0LOFxfpy/SQeidCRvOUieQPbEmZRUdLyFW1UDEHh3w==
+  
SrjY0gweRgWHmqBYj0wFnu1LFkaeNeS05SD1dKVzz2kvs3UCZ6AM8DrLbVe0q4H14DZwmrE3mMgbutsVev0Oxg==
 
 #
 # Optionally enable/disable building the RTEMS Tools via the command line.
-- 
2.39.3

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

Re: Multiple PowerPC BSPs Fail to BUIld

[Joel Sherrill]

FWIW I am still waiting for an ACK on the fdset size increase patch to
newlib. Once that's in place, I will bump the rtems-tools hash and newlib
hash.

--joel

On Mon, Mar 11, 2024 at 10:16 PM Chris Johns  wrote:

> On 11/3/2024 6:04 pm, Sebastian Huber wrote:
> > sorry for breaking the build. I fixed it. The problem is that
> 
> > header file depends on the BSP-provided define
> BSP_SHARED_HANDLER_SUPPORT. So,
> > the include order matters.
>
> Thank you for quickly sorting this out.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: arm/tms570ls3137_hdk_with_loader build failures

[Joel Sherrill]

On Mon, Mar 11, 2024 at 12:14 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 09.03.24 22:39, Joel Sherrill wrote:
> > Hi
> >
> > The build sweep using rtems-bsp-builder reports that 8 build
> > configurations of arm/tms570ls3137_hdk_with_loader fail. See the
> > following for more details.
> >
> > https://lists.rtems.org/pipermail/build/2024-March/051698.html
> > <https://lists.rtems.org/pipermail/build/2024-March/051698.html>
> >
> > The first reported configuration is:
> >
> > 1 debug arm/tms570ls3137_hdk_with_loader configure:
> >configure: /home/tester/rtems-cron-6/rtems/waf configure\
> >--prefix=/home/tester/rtems-cron-6/tools/6/bsps
> --top=/home/tester\
> >/rtems-cron-6/rtems --rtems-config=config-arm-\
> >tms570ls3137_hdk_with_loader-debug.ini
> >
> > It would be appreciated if someone could look into that and fix it.
>
> This should be fixed by:
>
> commit 9fdaa4e7c7577710405dab0da828ff9d0710a2d0
> Author: Sebastian Huber 
> Date:   Sat Jan 20 21:55:47 2024 +0100
>
>  config: Update BSPs
>
>  Update #4982.
>

Thanks. The RSB is still referencing an RTEMS tool hash from August. I will
fix that and the newlib hash once the fdset limit is pushed.

It would be nice to have a way to check that ./rtems-bsps and the
rtems-bsp-builder sets of BSPs match.

Thanks.

--joel

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

[PATCH rtems-tools] rtems-score-thread.ini: Remove _Thread_Close so trace examples link

[Joel Sherrill]

_Thread_Close no longer exists. There are multiple exapmles which
show tracing in rtems-examples which fail to link due to this.
---
 linkers/rtems-score-thread.ini | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/linkers/rtems-score-thread.ini b/linkers/rtems-score-thread.ini
index 974bcfd..a759f72 100644
--- a/linkers/rtems-score-thread.ini
+++ b/linkers/rtems-score-thread.ini
@@ -5,7 +5,7 @@
 trace = _Thread_Handler_initialization, _Thread_Create_idle, 
_Thread_Start_multitasking
 trace = _Stack_Allocate, _Stack_Free, _Thread_Start
 trace = _Thread_Yield, _Thread_Set_life_protection
-trace = _Thread_Kill_zombies, _Thread_Close
+trace = _Thread_Kill_zombies
 trace = _Thread_Clear_state, _Thread_Set_state, _Thread_Load_environment
 trace = _Thread_Handler
 trace = _Thread_Get
@@ -19,7 +19,7 @@ trace = _Stack_Allocate, _Thread_Start
 trace = _Thread_Restart, _Thread_Handler
 
 [rtems-score-thread-destroy]
-trace = _Thread_Kill_zombies, _Thread_Close
+trace = _Thread_Kill_zombies
 
 [rtems-score-thread-activity]
 trace = _Thread_Yield, _Thread_Set_life_protection
@@ -38,7 +38,6 @@ _Thread_Start = Status_Control, Thread_Control*, const 
Thread_Entry_information*
 _Thread_Yield = void, Thread_Control*
 _Thread_Set_life_protection = Thread_Life_state, Thread_Life_state
 _Thread_Kill_zombies = void, void
-_Thread_Close = void, Thread_Control*, Thread_Control*, Thread_Close_context*
 _Thread_Clear_state = States_Control, Thread_Control*, States_Control
 _Thread_Set_state = States_Control, Thread_Control*, States_Control
 _Thread_Load_environment = void, Thread_Control*
-- 
2.24.4

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

Multiple PowerPC BSPs Fail to BUIld

[Joel Sherrill]

Hi

In looking at the build sweep log, I see what looks like motorola_powerpc
and beatnik all have a common build failure that results in 53
configurations failing per

https://lists.rtems.org/pipermail/build/2024-March/051698.html

This is one but there are a lot.

debug powerpc/mvme2307 build:
  configure: /home/tester/rtems-cron-6/rtems/waf configure\
  --prefix=/home/tester/rtems-cron-6/tools/6/bsps --top=/home/tester\
  /rtems-cron-6/rtems --rtems-config=config-powerpc-mvme2307-debug.ini
 error: home/tester/bsps/powerpc/include/bsp/irq_supp.h:87:65: error:
'rtems_irq_connect_data' {aka 'struct
__rtems_irq_connect_data__'} has no member named
'next_handler'

Anyone care to fix that?

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

arm/tms570ls3137_hdk_with_loader build failures

[Joel Sherrill]

Hi

The build sweep using rtems-bsp-builder reports that 8 build configurations
of arm/tms570ls3137_hdk_with_loader fail. See the following for more
details.

https://lists.rtems.org/pipermail/build/2024-March/051698.html

The first reported configuration is:

1 debug arm/tms570ls3137_hdk_with_loader configure:
  configure: /home/tester/rtems-cron-6/rtems/waf configure\
  --prefix=/home/tester/rtems-cron-6/tools/6/bsps --top=/home/tester\
  /rtems-cron-6/rtems --rtems-config=config-arm-\
  tms570ls3137_hdk_with_loader-debug.ini

It would be appreciated if someone could look into that and fix it.

Thanks.

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

Fwd: Coverity Scan: Analysis completed for RTEMS

[Joel Sherrill]

-- Forwarded message -
From: 
Date: Mon, Mar 4, 2024 at 7:49 PM
Subject: Coverity Scan: Analysis completed for RTEMS
To: 



Your request for analysis of RTEMS has been completed successfully.
The results are available at
https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2BKADyCpvUKOL6EWmZljiu5GLWnGNEwbhcanGyCDC8W1Qe-2Bl-2BDPHTVhmy2cKk1eNLQ-3D-3DR3TL_ef-2B74248LNtJbbvO56NlyzePMg-2FngzSLDObEQKfcrJUqp0o9I5xUjWrBVg-2FINnA1F4ND5NmOwiFUmoDX4eahJjy-2Bokw5PJOvBjoPE2qUWnTi8CyrB-2BldopXZA9g2vkM4xwDr286PsZx0alN-2BmsoD3CDLX83OD-2BT8I9qnMESPQuQFc-2Fnr9reg2j7WhSWh-2FyE9CNh-2Bqu9f12jNIkDDCUzRZg-3D-3D

Build ID: 595887

Analysis Summary:
   New defects found: 13
   Defects eliminated: 2

If you have difficulty understanding any defects, email us at
scan-ad...@coverity.com,
or post your question to StackOverflow
at
https://u15810271.ct.sendgrid.net/ls/click?upn=u001.flnyKa-2FqvaKqx4fLQsH4bW35wEOELQKXyfspKiPYDJTkkE6I9WJzTo3tzdZlfNLaav4ccqKPQZ-2BbcFiem7UEug-3D-3D2vsD_ef-2B74248LNtJbbvO56NlyzePMg-2FngzSLDObEQKfcrJUqp0o9I5xUjWrBVg-2FINnA1F4ND5NmOwiFUmoDX4eahJpG23VOC-2Fx24UXCA-2B-2FiL130UCNmjcfZnj3rPwxZVaKAD7ahHIxVhA8qeITx4hE7q2YLmbrfJjcbL4zUyAlDnIBGQapWFV-2F-2B3KNGV4Wb4ErhsyqjAadnrjZV5aLsthEPRNA-3D-3D
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Fwd: Coverity Scan: Analysis completed for RTEMS-Newlib

[Joel Sherrill]

-- Forwarded message -
From: 
Date: Mon, Mar 4, 2024 at 7:51 PM
Subject: Coverity Scan: Analysis completed for RTEMS-Newlib
To: 



Your request for analysis of RTEMS-Newlib has been completed
successfully.
The results are available at
https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2BKADyCpvUKOL6EWmZljiu5GLWnGNEwbhcanGyCDC8W1J39mgdb8fmXn9Cyr-2Btccag-3D-3DLIns_ef-2B74248LNtJbbvO56NlyzePMg-2FngzSLDObEQKfcrJUGmeXqTES5HLeblXSntqgw-2Bz-2FDgSGBhFCvhcQheofNv1bv1F025sNPmoYDRtZp9cE1HsTzaCQqn53hPn8PctY-2B3KpBMYKwae2ER6uZvoEOOTpXNvDEBZN2ZgMF3SwBl60XXWW7k5hYJpnz0MFfI-2BgQhGu67aiLB76I3rV-2B1RENpQ-3D-3D

Build ID: 595890

Analysis Summary:
   New defects found: 0
   Defects eliminated: 7
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Fwd: Coverity Scan: Analysis completed for RTEMS-Tools

[Joel Sherrill]

-- Forwarded message -
From: 
Date: Mon, Mar 4, 2024 at 5:56 PM
Subject: Coverity Scan: Analysis completed for RTEMS-Tools
To: 



Your request for analysis of RTEMS-Tools has been completed
successfully.
The results are available at
https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2BKADyCpvUKOL6EWmZljiu5GLWnGNEwbhcanGyCDC8W1rzZN7RImWJ9Tw6MBdBzn-2Bg-3D-3DAP_C_ef-2B74248LNtJbbvO56NlyzePMg-2FngzSLDObEQKfcrJVKHHLpV-2B-2Ffn5FMhx7B5vUz50Kp6uOWpcWVOwWoiPJgOII4zYRv8KZn1eJBVovP0JieXjAo9d2128tqu6B4ZNdsgarWIA4fOgSqhfjDbMz-2BG1JTzcrx20Y8uaG6dRJSpuz9pWdus-2FsqODbPaFZyrSQA3mWPOZlIdsVU90EzZMUmlg-3D-3D

Build ID: 595829

Analysis Summary:
   New defects found: 0
   Defects eliminated: 0
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Coverity Scan Runs Renabled

[Joel Sherrill]

Hi

Coverity required an update of their client tool to keep doing scans. The
new client tool was based on a libc library version which was newer than
what was on the machine running the scans. This required setting this up
again on another computer with a newer OS.

I am forwarding three Coverity emails to devel@. The one for rtems itself
shows 8 new issues since the last run. That needs some attention.

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

Re: [PATCH 2/2] testsuites/dhrystone: Initialize before use

[Joel Sherrill]

On Fri, Mar 1, 2024 at 8:21 AM Kinsey Moore 
wrote:

> A very similar change was made in 2017 to resolve the same warning for a
> different variable. The only real difference is that it is wrapped in
> __rtems__ ifdefs. I can move this change to the #ifdef'd section if that's
> preferable.
>

Do not rearrange. Just add the __rtems__ conditional. The goal is to fix
issues while minimizing differences.

--joel

>
> Kinsey
>
> On Fri, Mar 1, 2024 at 1:02 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 28.02.24 19:15, Kinsey Moore wrote:
>> > This resovles a warning where a variable could be used before it is
>> > initialized in some code paths.
>>
>> I am not sure if we should modify benchmark code.
>>
>> --
>> embedded brains GmbH & Co. KG
>> Herr Sebastian HUBER
>> Dornierstr. 4
>> 82178 Puchheim
>> Germany
>> email: sebastian.hu...@embedded-brains.de
>> phone: +49-89-18 94 741 - 16
>> fax:   +49-89-18 94 741 - 08
>>
>> Registergericht: Amtsgericht München
>> Registernummer: HRB 157899
>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>> Unsere Datenschutzerklärung finden Sie hier:
>> https://embedded-brains.de/datenschutzerklaerung/
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

6.1rc2 on Rocky 9

[Joel Sherrill]

Hi

Looks pretty good overall. This appears to be the only issue:

Testing: riscv rv64imac_spike
BSP to Build: rv64imac
'distclean' finished successfully (0.011s)
Regenerate build specification cache (needs a couple of seconds)...

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

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

6.1rc2 Tool Build Failures

[Joel Sherrill]

Hi

rtems 6.1rc2 has a lot of tool build failures because I didn't have
gmp-devel installed.

hecking for gmp.h... no
configure: error: gmp.h header not found

This is reported as part of building gcc-newlib. Should the RSB account for
this by building gmp at the same time?

For now, I installed a host gmp-devel and restarted the build sweep.

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

Re: Documentation theme update

[Joel Sherrill]

Based on Christian saying it works and me confirming that, I pushed this.

Thanks a lot Chris! 

--joel

On Wed, Feb 21, 2024 at 2:22 AM Christian MAUDERER <
christian.maude...@embedded-brains.de> wrote:

> Hello Chris,
>
> On 2024-02-21 06:16, Chris Johns wrote:
> > Hi,
> >
> > I have a patch for rtems-docs.git to move us to the pip installed
> > sphinx-rtd-theme removing the custom theme based on sphinx-rtd-theme we
> > currently use.
> >
>
> I think reducing RTEMS specific adaptions is a great idea. So thank you
> for that.
>
> > The ticket is #4994.
> >
> > The patch is over 4M in size as it deletes
> common/sphinx_rtd_theme_rtems. YOu
> > can download it from:
> >
> >
> https://ftp.rtems.org/pub/rtems/people/chrisj/0001-sphinx-Use-the-pip-installed-sphinx-rtd-theme.patch
> >
> > What I am not sure about is how old Sphinx can be to build the
> documentation. My
> > versions are:
> >
> >   Sphinx7.2.6
> >   sphinx-rtd-theme  2.0.0
> >   sphinxcontrib-applehelp   1.0.7
> >   sphinxcontrib-bibtex  2.6.1
> >   sphinxcontrib-devhelp 1.0.5
> >   sphinxcontrib-htmlhelp2.0.4
> >   sphinxcontrib-jquery  4.1
> >   sphinxcontrib-jsmath  1.0.1
> >   sphinxcontrib-qthelp  1.0.6
> >   sphinxcontrib-serializinghtml 1.1.9
> >
> > Is it OK to push?
>
> I tried building the manuals with your patches on OpenSUSE. It's
> basically the same procedure as without the patch except that the
> sphinx-rtd-theme is now necessary. The result looks as expected.
>
> With the patch, the search seems to work again. That hasn't been the
> case with the old version.
>
> So from my point of view, the patch is a great improvement and OK.
>
> Best regards
>
> Christian
> ___
> 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] testsuites/dl11: Test TLS on a secondary thread

[Joel Sherrill]

I think this is ok also.

On Sun, Feb 18, 2024, 10:20 PM Chris Johns  wrote:

> Looks good. Thanks
>
> Chris
>
> On 19/2/2024 3:16 pm, Kinsey Moore wrote:
> > This adds a pthread that runs the test as well to increase test
> > coverage. The original test would have passed if all threads returned
> > the address of the Init task's errno since no additional threads or
> > tasks were checked.
> > ---
> >  testsuites/libtests/dl11/dl-load.c | 72 +++---
> >  testsuites/libtests/dl11/init.c|  2 +
> >  2 files changed, 59 insertions(+), 15 deletions(-)
> >
> > diff --git a/testsuites/libtests/dl11/dl-load.c
> b/testsuites/libtests/dl11/dl-load.c
> > index 70d7bf1c65..b09128acdf 100644
> > --- a/testsuites/libtests/dl11/dl-load.c
> > +++ b/testsuites/libtests/dl11/dl-load.c
> > @@ -27,6 +27,8 @@
> >
> >  #include 
> >  #include 
> > +#include "tmacros.h"
> > +#include 
> >
> >  #include 
> >
> > @@ -79,13 +81,60 @@ typedef int* (*ptr_call_t)(void);
> >  void* get_errno_ptr(void);
> >  int get_errno(void);
> >
> > -int dl_load_test(void)
> > +int_call_t int_call;
> > +ptr_call_t ptr_call;
> > +static int perform_test(void)
> >  {
> > -  void*  handle;
> > -  int_call_t int_call;
> > -  ptr_call_t ptr_call;
> >intint_call_ret;
> >int*   ptr_call_ret;
> > +  ptr_call_ret = ptr_call ();
> > +  if (ptr_call_ret != get_errno_ptr())
> > +  {
> > +printf("dlsym ptr_call failed: ret value bad\n");
> > +return 1;
> > +  }
> > +
> > +  errno = 12345;
> > +  int_call_ret = int_call ();
> > +  if (int_call_ret != get_errno())
> > +  {
> > +printf("dlsym int_call failed: ret value bad\n");
> > +return 1;
> > +  }
> > +  errno = 0;
> > +
> > +  return 0;
> > +}
> > +
> > +static void *secondary_thread(void *arg)
> > +{
> > +  printf("Running test on secondary thread\n");
> > +  if (perform_test()) {
> > +printf("Test failed on secondary task\n");
> > +return (void *) 1;
> > +  }
> > +
> > +  return NULL;
> > +}
> > +
> > +static void start_secondary(void)
> > +{
> > +  /* Run the test on a secondary thread */
> > +  pthread_t threadId;
> > +  int status;
> > +  void *ret;
> > +  status = pthread_create( , NULL, secondary_thread, NULL );
> > +  rtems_test_assert( !status );
> > +
> > +  /* Wait on thread to exit */
> > +  status = pthread_join(threadId, );
> > +  rtems_test_assert( !status );
> > +  rtems_test_assert( ret == NULL );
> > +}
> > +
> > +int dl_load_test(void)
> > +{
> > +  void*  handle;
> >intunresolved;
> >char*  message = "loaded";
> >
> > @@ -125,20 +174,13 @@ int dl_load_test(void)
> >  return 1;
> >}
> >
> > -  ptr_call_ret = ptr_call ();
> > -  if (ptr_call_ret != get_errno_ptr())
> > -  {
> > -printf("dlsym ptr_call failed: ret value bad\n");
> > +  /* Run the test on the init thread */
> > +  printf("Running test on init task\n");
> > +  if (perform_test()) {
> >  return 1;
> >}
> >
> > -  errno = 12345;
> > -  int_call_ret = int_call ();
> > -  if (int_call_ret != get_errno())
> > -  {
> > -printf("dlsym int_call failed: ret value bad\n");
> > -return 1;
> > -  }
> > +  start_secondary();
> >
> >if (dlclose (handle) < 0)
> >{
> > diff --git a/testsuites/libtests/dl11/init.c
> b/testsuites/libtests/dl11/init.c
> > index 91f529b055..0ff4557421 100644
> > --- a/testsuites/libtests/dl11/init.c
> > +++ b/testsuites/libtests/dl11/init.c
> > @@ -86,6 +86,8 @@ static void Init(rtems_task_argument arg)
> >
> >  #define CONFIGURE_MAXIMUM_FILE_DESCRIPTORS 4
> >
> > +#define CONFIGURE_MAXIMUM_POSIX_THREADS 1
> > +
> >  #define CONFIGURE_MAXIMUM_TASKS 1
> >
> >  #define CONFIGURE_MAXIMUM_SEMAPHORES 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] improved error checking in ticks per timeslice

[Joel Sherrill]

On Wed, Feb 14, 2024, 9:54 PM zack leung  wrote:

> > This file is generated from something in rtems-central. This was at the
> > top of the file:
> >
> >   * 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
>
> No, problem. I can fix this before I check in the patch.
>
> re: this do you need me to change it to something?
>

I'm hoping Sebastian has some guidance for you on what to edit for this and
how to propagate it dull.

>
>
> On Wed, 14 Feb 2024 at 09:28, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>>
>>
>> On 14.02.24 15:18, Joel Sherrill wrote:
>> > I'm cc'ing Sebastian because you edited the text in a generated file.
>> He
>> > should be able to point us to the right place to fix it.
>> >
>> > On Mon, Feb 12, 2024 at 8:26 PM > > <mailto:zakthertems...@gmail.com>> wrote:
>> >
>> > From: Zack leung mailto:z.liang...@gmail.com
>> >>
>> >
>> > diff --git a/cpukit/doxygen/appl-config.h
>> b/cpukit/doxygen/appl-config.h
>> > index bd7cde628f..d480eb3971 100644
>> > --- a/cpukit/doxygen/appl-config.h
>> > +++ b/cpukit/doxygen/appl-config.h
>> > @@ -3312,7 +3312,7 @@
>> >* @parblock
>> >* The following constraints apply to this configuration option:
>> >*
>> > - * * The value of the configuration option shall be greater than or
>> > equal to
>> > + * * The value of the configuration option shall be greater than
>> >*   zero.
>> >
>> >
>> >
>> > This file is generated from something in rtems-central. This was at the
>> > top of the file:
>> >
>> >   * 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
>>
>> No, problem. I can fix this before I check in the patch.
>>
>> >
>> >*
>> >* * The value of the configuration option shall be less than or
>> > equal to > > diff --git a/cpukit/include/rtems/confdefs/clock.h
>> > b/cpukit/include/rtems/confdefs/clock.h
>> > index 26519cc70b..d0d7c453bc 100644
>> > --- a/cpukit/include/rtems/confdefs/clock.h
>> > +++ b/cpukit/include/rtems/confdefs/clock.h
>> > @@ -74,6 +74,10 @@
>> > #error "CONFIGURE_MICROSECONDS_PER_TICK must be positive"
>> >   #endif
>> >
>> > +#if CONFIGURE_TICKS_PER_TIMESLICE <= 0 &&
>> > defined(CONFIGURE_TICKS_PER_TIMESLICE)
>> > +  #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
>> > +#endif
>> > +
>> >
>> >
>> > This is modifying the right file but I think it is safer to check that
>> > it is defined
>> > before checking its value.
>>
>> Yes, the defined() check should be first.
>>
>> --
>> embedded brains GmbH & Co. KG
>> Herr Sebastian HUBER
>> Dornierstr. 4
>> 82178 Puchheim
>> Germany
>> email: sebastian.hu...@embedded-brains.de
>> phone: +49-89-18 94 741 - 16
>> fax:   +49-89-18 94 741 - 08
>>
>> Registergericht: Amtsgericht München
>> Registernummer: HRB 157899
>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>> Unsere Datenschutzerklärung finden Sie hier:
>> https://embedded-brains.de/datenschutzerklaerung/
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-source-builder 2/2] devel/qemu-xilinx: Fix build on GCC 13.2.0

[Joel Sherrill]

On Wed, Feb 14, 2024 at 1:37 PM Kinsey Moore 
wrote:

> On Wed, Feb 14, 2024 at 9:14 AM Sam Price  wrote:
>
>> I was wondering if you had any notes on your process of working with
>> qemu in the rtems builder.
>> I imagine you have your own xilinx qemu forked to work on, and then
>> take the patches and integrate them into the rsb builder?
>>
>
> Nothing so fancy. Here's my current setup for this:
> * have a checkout of the qemu-xilinx repo to generate patches
> * copy generated patches into the rsb/rtems/patches directory
> * set up the RSB recipe to pull in the patch with appropriate SHA512
> * attempt build
>
> This lets me pull in a custom patch for testing without actually hosting
> it somewhere. I've been wanting an easier way to do this since it's a pain
> to push patches elsewhere for test hosting before actually pushing it to
> the ticket, but this is the compromise I've settled on that smooths out the
> workflow just enough. Ideally, I'd be able to specify a local file path for
> a patch for test purposes, but that would necessitate some very verbose
> flag to sb-set-builder like
> --really-allow-local-patches-just-for-test-purposes because we really don't
> want to host these patches within RSB.
>

This is essentially what I have done when generating patches for newlib,
gcc, etc. For some packages, you need a patch based on git and sometimes
you have to generate one against a released version. But you still have to
put a patch in your patches directory and update the sha hash. Eventually
putting the working patch somewhere (hopefully merged upstream) not local.

--joel

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

Re: RSB checksum updates for RTEMS 6

[Joel Sherrill]

On Fri, Feb 16, 2024, 12:56 AM Chris Johns  wrote:

> Hi,
>
> I have opened https://devel.rtems.org/ticket/4991 to track checksum
> errors in
> some of the sources being downloaded by the RSB such as:
>
> error: checksum failure file:
> patches/Make-lang.in-b09fb02bb4c0d16fc2c842bec4069c033897b5f2.patch
>
> I am seeing this error while I attempt to create 6.1-rc2. I am asking if it
> would be OK for me to push changes to the RSB under this ticket without
> review
> while I sort this out?
>

Absolutely

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

Re: [PATCH] improved error checking in ticks per timeslice

[Joel Sherrill]

I'm cc'ing Sebastian because you edited the text in a generated file. He
should be able to point us to the right place to fix it.

On Mon, Feb 12, 2024 at 8:26 PM  wrote:

> From: Zack leung 
>
> diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
> index bd7cde628f..d480eb3971 100644
> --- a/cpukit/doxygen/appl-config.h
> +++ b/cpukit/doxygen/appl-config.h
> @@ -3312,7 +3312,7 @@
>   * @parblock
>   * The following constraints apply to this configuration option:
>   *
> - * * The value of the configuration option shall be greater than or equal
> to
> + * * The value of the configuration option shall be greater than
>   *   zero.
>


This file is generated from something in rtems-central. This was at the top
of the file:

 * 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



>   *
>   * * The value of the configuration option shall be less than or equal to
>  diff --git a/cpukit/include/rtems/confdefs/clock.h
> b/cpukit/include/rtems/confdefs/clock.h
> index 26519cc70b..d0d7c453bc 100644
> --- a/cpukit/include/rtems/confdefs/clock.h
> +++ b/cpukit/include/rtems/confdefs/clock.h
> @@ -74,6 +74,10 @@
>#error "CONFIGURE_MICROSECONDS_PER_TICK must be positive"
>  #endif
>
> +#if CONFIGURE_TICKS_PER_TIMESLICE <= 0 &&
> defined(CONFIGURE_TICKS_PER_TIMESLICE)
> +  #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
> +#endif
> +
>

This is modifying the right file but I think it is safer to check that it
is defined
before checking its value.

--joel


>  #ifdef __cplusplus
>  extern "C" {
>  #endif
> --
> 2.43.0
>
> ___
> 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

Apparently Unused ARM Linker Symbol

[Joel Sherrill]

Hi

In looking at linkcmds code, one of the folks in the class noticed this
symbol which appears to be unused. This is a grep from the top of the tree.
It appears that bsp_stack_main_size is defined but never really used. If
someone can confirm this, it needs to be purged.

[joel@localhost rtems]$ grep -r bsp_stack_main_size
testsuites/libtests/dl05/dl05.scn:rtl: esyms: bsp_stack_main_size ->
 0x0
testsuites/libtests/dl04/dl04.scn:rtl: esyms: bsp_stack_main_size ->
 0x0
bsps/arm/lpc176x/start/linkcmds.lpc1768_mbed:bsp_stack_main_size = DEFINED
(bsp_stack_main_size) ? bsp_stack_main_size : 1024;
bsps/arm/lpc176x/start/linkcmds.lpc1768_mbed:bsp_stack_main_size = ALIGN
(bsp_stack_main_size, bsp_stack_align);
bsps/arm/lpc176x/start/linkcmds.lpc1768_mbed_ahb_ram:bsp_stack_main_size =
DEFINED (bsp_stack_main_size) ? bsp_stack_main_size : 1024;
bsps/arm/lpc176x/start/linkcmds.lpc1768_mbed_ahb_ram:bsp_stack_main_size =
ALIGN (bsp_stack_main_size, bsp_stack_align);
bsps/arm/lpc176x/start/linkcmds.lpc1768_mbed_ahb_ram_eth:bsp_stack_main_size
= DEFINED (bsp_stack_main_size) ? bsp_stack_main_size : 1024;
bsps/arm/lpc176x/start/linkcmds.lpc1768_mbed_ahb_ram_eth:bsp_stack_main_size
= ALIGN (bsp_stack_main_size, bsp_stack_align);
bsps/arm/shared/start/linkcmds.armv7m:bsp_stack_main_size = DEFINED
(bsp_stack_main_size) ? bsp_stack_main_size : 4096;
bsps/arm/shared/start/linkcmds.armv7m:bsp_stack_main_size = ALIGN
(bsp_stack_main_size, bsp_stack_align)

Thanks.

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

Wrong BSP Names in arm spec files

[Joel Sherrill]

Hi

While teaching a class this week, I noticed that some arm optcachedata.yml
files appear to reference BSP variants that are not associated with the BSP
whose directory the yml file is located in. These greps show the issue:

[joel@localhost arm]$ grep lm3s6965_qemu */optcachedat*
imx/optcachedata.yml:  - arm/lm3s6965_qemu
realview-pbx-a9/optcachedata.yml:  - arm/lm3s6965_qemu
xilinx-zynqmp/optcachedata.yml:  - arm/lm3s6965_qemu
xilinx-zynq/optcachedata.yml:  - arm/lm3s6965_qemu

[joel@localhost arm]$ grep realview_pbx_a9_qemu */optcacheda*
imx/optcachedata.yml:  - arm/realview_pbx_a9_qemu
realview-pbx-a9/optcachedata.yml:  - arm/realview_pbx_a9_qemu
xilinx-zynqmp/optcachedata.yml:  - arm/realview_pbx_a9_qemu
xilinx-zynq/optcachedata.yml:  - arm/realview_pbx_a9_qemu

[joel@localhost arm]$ grep xilinx_zynq_a9_qemu */optcachedata*
imx/optcachedata.yml:  - arm/xilinx_zynq_a9_qemu
realview-pbx-a9/optcachedata.yml:  - arm/xilinx_zynq_a9_qemu
xilinx-zynqmp/optcachedata.yml:  - arm/xilinx_zynq_a9_qemu
xilinx-zynq/optcachedata.yml:  - arm/xilinx_zynq_a9_qemu

I think these files have BSPs listed in them which should not appear.

Could someone confirm and possibly fix?

Thanks.

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

Incorrect Rendering in Rate Monotonic Manager Chapter

[Joel Sherrill]

Hi

https://docs.rtems.org/branches/master/c-user/rate-monotonic/background.html#schedulability-analysis
has a bullet list which does not have bullets. But they are there in the
PDF version:

https://docs.rtems.org/branches/master/c-user.pdf

Is there something wrong with the markup? Is something broken with the
tooling that produces the online version?

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

Re: [PATCH] cpukit/jffs2: Handle used empty file system

[Joel Sherrill]

Ignoring any specific technical comments from others.

(1) Should this have a ticket? Seems impactful and odd enough to since that
shows up in release notes.

(2) Should it also be applied to 5.x with a separate ticket?

--joel

On Fri, Feb 2, 2024 at 4:40 PM Kinsey Moore 
wrote:

> On JFFS2 file systems on NOR flash or dataflash that does not have spare
> area for metadata and thus does not invoke delayed writes, it is
> possible to put the file system into a state where all blocks have been
> written to and all files have been deleted from the filesystem. There is
> a bug in the JFFS2 file system scan routine that detects this situation
> as a corrupted file system since the scan routine relies on "used" space
> to discriminate a valid file system when there are blocks that need to
> be erased. The correct fix would require a partial rewrite of the scan
> routine, so instead this patch tracks the space marked as obsolete along
> with space at the end of each block that is otherwise too small to
> contain a JFFS2 node so that it can me compared with the dirty space.
> Corrupted data (or otherwise non-JFFS2 blocks) will still cause this
> check to fail as corrupted data isn't recognized as obsoleted (deleted)
> nodes.
> ---
>  cpukit/libfs/src/jffs2/src/jffs2_fs_sb.h |  3 +++
>  cpukit/libfs/src/jffs2/src/scan.c| 24 
>  2 files changed, 27 insertions(+)
>
> diff --git a/cpukit/libfs/src/jffs2/src/jffs2_fs_sb.h
> b/cpukit/libfs/src/jffs2/src/jffs2_fs_sb.h
> index 4ee43a6f30..7960f92f85 100644
> --- a/cpukit/libfs/src/jffs2/src/jffs2_fs_sb.h
> +++ b/cpukit/libfs/src/jffs2/src/jffs2_fs_sb.h
> @@ -75,6 +75,9 @@ struct jffs2_sb_info {
> uint32_t bad_size;
> uint32_t sector_size;
> uint32_t unchecked_size;
> +#ifdef __rtems__
> +   uint32_t obsolete_size;
> +#endif
>
> uint32_t nr_free_blocks;
> uint32_t nr_erasing_blocks;
> diff --git a/cpukit/libfs/src/jffs2/src/scan.c
> b/cpukit/libfs/src/jffs2/src/scan.c
> index 10663feb1f..8ac4a40414 100644
> --- a/cpukit/libfs/src/jffs2/src/scan.c
> +++ b/cpukit/libfs/src/jffs2/src/scan.c
> @@ -264,14 +264,32 @@ int jffs2_scan_medium(struct jffs2_sb_info *c)
> }
>  #endif
> if (c->nr_erasing_blocks) {
> +#ifdef __rtems__
> +   if (c->obsolete_size != c->dirty_size) {
> +#endif
> if (!c->used_size && !c->unchecked_size &&
> ((c->nr_free_blocks+empty_blocks+bad_blocks) !=
> c->nr_blocks || bad_blocks == c->nr_blocks)) {
> pr_notice("Cowardly refusing to erase blocks on
> filesystem with no valid JFFS2 nodes\n");
> pr_notice("empty_blocks %d, bad_blocks %d,
> c->nr_blocks %d\n",
>   empty_blocks, bad_blocks, c->nr_blocks);
> +#ifdef __rtems__
> +   pr_notice("nr_erasing_blocks %d, used 0x%x, dirty
> 0x%x, wasted 0x%x, free 0x%x, erasing 0x%x, bad 0x%x, obsolete 0x%x,
> unchecked 0x%x\n",
> + c->nr_erasing_blocks,
> + c->used_size,
> + c->dirty_size,
> + c->wasted_size,
> + c->free_size,
> + c->erasing_size,
> + c->bad_size,
> + c->obsolete_size,
> + c->unchecked_size);
> +#endif
> ret = -EIO;
> goto out;
> }
> +#ifdef __rtems__
> +   }
> +#endif
> spin_lock(>erase_completion_lock);
> jffs2_garbage_collect_trigger(c);
> spin_unlock(>erase_completion_lock);
> @@ -646,6 +664,9 @@ scan_more:
>   sizeof(struct jffs2_unknown_node),
>   jeb->offset, c->sector_size, ofs,
>   sizeof(*node));
> +#ifdef __rtems__
> +   c->obsolete_size += (jeb->offset + c->sector_size
> - ofs);
> +#endif
> if ((err = jffs2_scan_dirty_space(c, jeb,
> (jeb->offset + c->sector_size)-ofs)))
> return err;
> break;
> @@ -796,6 +817,9 @@ scan_more:
> if ((err = jffs2_scan_dirty_space(c, jeb,
> PAD(je32_to_cpu(node->totlen)
> return err;
> ofs += PAD(je32_to_cpu(node->totlen));
> +#ifdef __rtems__
> +   c->obsolete_size += PAD(je32_to_cpu(node->totlen));
> +#endif
> continue;
> }
>
> --
> 2.39.2
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org

Re: Naming convention for Rust target platforms

[Joel Sherrill]

On Wed, Jan 31, 2024 at 12:31 AM Karel Gardas 
wrote:

> On 1/30/24 18:13, Frank Kühndel wrote:
> > Which name Rust accepts instead of "armv7a-rtems6-eabihf" depends on the
> > naming convention of the Rust community:
> >  https://docs.rust-embedded.org/embedonomicon/custom-target.html
> > According to this file, the part `eabi` is for bare metal. Would this be
> > correct when it is based on RTEMS? For example, a Linux target would be
> > "x86_64-unknown-linux-gnu" where `gnu` means started by 'glibc'.
>
> This is not completely fair to Jan as the x86_64 example is quite the
> exception instead of a common norm in rust platforms names. But you
> started with Linux so let's continue with Linux -- see the listing below.
>
> Also IMHO this convention is not about rust per se, but IMHO about LLVM
> way of doing things. GCC does that differently. So no C vs Rust, but GCC
> vs. LLVM. Once Rust in GCC happen it'll be done in GCC more RTEMS used
> way probably...
>
> So for Rust/LLVM I think Jan's proposal is about right except that I
> would strip '6' from rtems6. Neither OS (Linux, FreeBSD, NetBSD,
> Windows, OpenBSD, VxWorks, etc) uses any version notion in the OS name
> anyway... And also would strip 'a' from arm7a. We do not need to mention
> 'a' here explicitly since for 'm' we do have whole family of 'thumb*'
> platform names... E.g. VxWorks in this particular case (ARMv7-A) uses:
> armv7-wrs-vxworks-eabihf
>

WRS took the vendor part of the triple and I would not judge correctness
on what they did.

I have reached out to a contact at a company that has a long history of
supporting the GNU tools and has added Rust to their services in the past
few years. I would like to hear their opinion.

>
>
> Cheers,
> Karel
>
>
On these, they actually do distinguish the OS. I see Linux, Android, and
Open
Harmony.

There is also a distinction in the target name for C library used. I see
glibc,
musl, and ulibc.

The rest of the target names are multilib variants and appear to reflect a
lack
of support for or use of multilibs.

IMO this naming seems to reflect a Linux focus and a lack of understanding
of the processor variations seen in the embedded world.

If this is the final pattern, it may work for RTEMS because people build
their
own tools and tend to use 1-2 BSPs. But it will be painful for developers
testing
multiple BSPs, etc. My cron sweeper builds almost 20 tool chains now. With
this,
we would be between 100 and 200 I expect. Some of the BSPs will have a
similar
enough processor to share a tool chain but a lot won't.

I am glad you are working through this and this issue isn't a blocker for
ironing
out a long list of other potential issues.

--joel

>
>
> $ rustc --print target-list|grep linux
> aarch64-linux-android
> aarch64-unknown-linux-gnu
> aarch64-unknown-linux-gnu_ilp32
> aarch64-unknown-linux-musl
> aarch64-unknown-linux-ohos
> aarch64_be-unknown-linux-gnu
> aarch64_be-unknown-linux-gnu_ilp32
> arm-linux-androideabi
> arm-unknown-linux-gnueabi
> arm-unknown-linux-gnueabihf
> arm-unknown-linux-musleabi
> arm-unknown-linux-musleabihf
> armeb-unknown-linux-gnueabi
> armv4t-unknown-linux-gnueabi
> armv5te-unknown-linux-gnueabi
> armv5te-unknown-linux-musleabi
> armv5te-unknown-linux-uclibceabi
> armv7-linux-androideabi
> armv7-unknown-linux-gnueabi
> armv7-unknown-linux-gnueabihf
> armv7-unknown-linux-musleabi
> armv7-unknown-linux-musleabihf
> armv7-unknown-linux-ohos
> armv7-unknown-linux-uclibceabi
> armv7-unknown-linux-uclibceabihf
> csky-unknown-linux-gnuabiv2
> hexagon-unknown-linux-musl
> i586-unknown-linux-gnu
> i586-unknown-linux-musl
> i686-linux-android
> i686-unknown-linux-gnu
> i686-unknown-linux-musl
> loongarch64-unknown-linux-gnu
> m68k-unknown-linux-gnu
> mips-unknown-linux-gnu
> mips-unknown-linux-musl
> mips-unknown-linux-uclibc
> mips64-openwrt-linux-musl
> mips64-unknown-linux-gnuabi64
> mips64-unknown-linux-muslabi64
> mips64el-unknown-linux-gnuabi64
> mips64el-unknown-linux-muslabi64
> mipsel-unknown-linux-gnu
> mipsel-unknown-linux-musl
> mipsel-unknown-linux-uclibc
> mipsisa32r6-unknown-linux-gnu
> mipsisa32r6el-unknown-linux-gnu
> mipsisa64r6-unknown-linux-gnuabi64
> mipsisa64r6el-unknown-linux-gnuabi64
> powerpc-unknown-linux-gnu
> powerpc-unknown-linux-gnuspe
> powerpc-unknown-linux-musl
> powerpc64-unknown-linux-gnu
> powerpc64-unknown-linux-musl
> powerpc64le-unknown-linux-gnu
> powerpc64le-unknown-linux-musl
> riscv32gc-unknown-linux-gnu
> riscv32gc-unknown-linux-musl
> riscv64-linux-android
> riscv64gc-unknown-linux-gnu
> riscv64gc-unknown-linux-musl
> s390x-unknown-linux-gnu
> s390x-unknown-linux-musl
> sparc-unknown-linux-gnu
> sparc64-unknown-linux-gnu
> thumbv7neon-linux-androideabi
> thumbv7neon-unknown-linux-gnueabihf
> thumbv7neon-unknown-linux-musleabihf
> x86_64-linux-android
> x86_64-unikraft-linux-musl
> x86_64-unknown-linux-gnu
> x86_64-unknown-linux-gnux32
> x86_64-unknown-linux-musl
> x86_64-unknown-linux-ohos
>
> 

Re: Naming convention for Rust target platforms

[Joel Sherrill]

On Tue, Jan 30, 2024 at 3:15 PM Joel Sherrill  wrote:

>
>
> On Tue, Jan 30, 2024 at 11:13 AM Frank Kühndel <
> frank.kuehn...@embedded-brains.de> wrote:
>
>> Hello Jan,
>>
>> On 1/29/24 19:41, jan.som...@dlr.de wrote:
>> > Hi everyone,
>> >
>> > As mentioned in the other Rust thread, I am working on an initial Rust
>> port for RTEMS.
>> > The target platform for testing is the ARM Xilinx Zynq-7000 based BSPs.
>> > Where I am not completely sure, is how to name the new target for Rust
>> (see here the current list:
>> https://doc.rust-lang.org/nightly/rustc/platform-support.html#tier-3).
>> > The Rust ARM targets usually have the instruction set version and ABI
>> as part of the name, e.g. armv7a-none-eabihf.
>> > In RTEMS the arm-rtems6-gcc covers all supported ARM versions and
>> different ABIs (i.e. hard-float or soft-float) collectively.
>> >
>> > So, for the Zynq and similar BSPs this would yield for the Rust target
>> something like: armv7a-rtems6-eabihf (and possibly armv7a-rtems6-eabi).
>> > Similarly, for other ARM BSPs additional Rust targets would need to be
>> added. Which might add up to quite a  number of Rust targets over time.
>> > Is this fine or do you see another solution?
>> Just to make sure I understand your question correct:
>> You want to push the RTEMS support you have developed (changes to Rust
>> libraries, test framework, ability to have a main() in the Rust code for
>> RTEMS etc.) to the official Rust repository - so that it is available to
>> everyone through the Rust nightly builds?
>>
>> If this is so, then your question would be primarily a question to the
>> Rust folks because it is their repository which would possibly receive
>> many different entries for (similar?) RTEMS BSPs?
>>
>> As far as I understand this, the steps for an RTEMS developer would be:
>>
>> 1) Build the right RTEMS tools with the Source Builder. Here: ARM tools.
>> 2) Build RTEMS (kernel) for the right (RTEMS) BSP
>> 3) Install the Rust compiler and its tools
>> 4) Create a Rust project
>> 5) Fine tune some Rust configuration files in that project.
>> Here the "armv7a-rtems6-eabihf" or something fitting the BSP would
>> be used in a config file. The point is, it must be for the processor
>> and BSP which matches the RTEMS tools and BSP selected in steps 1)
>> and 2)
>> 6) Make changes to the sample Rust code generated in the project
>> or write the Rust code desired.
>> 7) Load the nightly build of the Rust compiler.
>> (The nightly is only needed as long as your code has not entered the
>> stable build).
>> 8) Compile the Rust program code with the Rust nightly compiler.
>> 9) Link the Rust binary with the RTEMS libraries into a single
>> executable (using a linker build by the RTEMS tools).
>>
>> Which name Rust accepts instead of "armv7a-rtems6-eabihf" depends on the
>> naming convention of the Rust community:
>>  https://docs.rust-embedded.org/embedonomicon/custom-target.html
>> According to this file, the part `eabi` is for bare metal. Would this be
>> correct when it is based on RTEMS? For example, a Linux target would be
>> "x86_64-unknown-linux-gnu" where `gnu` means started by 'glibc'.
>>
>
> This is the more correct target name. We have worked hard for GCC,
> binutils,
> etc. to not have any BSP specific knowledge. They know about processor
> architectures and processor variations (e.g. core models) within each
> family.
> GCC may include shortcuts with SoC names as arguments but those just
> map to the proper arguments for the CPU core on the SoC. There is no
> implication of device support of any kind, much less a full BSP.
>
> Is there no notion of multilib in the Rust tooling?
>

I should have also mentioned that the bare metal nature of the *-eabi nature
as Frank noted has implications. It selects different configurations of
support
libraries which I assume Rust is layered on. The *-rtems* tool target
enables
the multithread safety and RTEMS awareness in various libraries. We may use
the same object format as the bare metal target but the library build
configurations
are quite different.

>
>
>>
>> By the way, section "Adding a new target" of
>> https://doc.rust-lang.org/nightly/rustc/target-tier-policy.html
>> points to an example:
>> https://github.com/rust-lang/rust/pull/94872
>> and that person discussed that triple name here:
>>
>>
>> https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/LLVM

Re: Naming convention for Rust target platforms

[Joel Sherrill]

On Tue, Jan 30, 2024 at 11:13 AM Frank Kühndel <
frank.kuehn...@embedded-brains.de> wrote:

> Hello Jan,
>
> On 1/29/24 19:41, jan.som...@dlr.de wrote:
> > Hi everyone,
> >
> > As mentioned in the other Rust thread, I am working on an initial Rust
> port for RTEMS.
> > The target platform for testing is the ARM Xilinx Zynq-7000 based BSPs.
> > Where I am not completely sure, is how to name the new target for Rust
> (see here the current list:
> https://doc.rust-lang.org/nightly/rustc/platform-support.html#tier-3).
> > The Rust ARM targets usually have the instruction set version and ABI as
> part of the name, e.g. armv7a-none-eabihf.
> > In RTEMS the arm-rtems6-gcc covers all supported ARM versions and
> different ABIs (i.e. hard-float or soft-float) collectively.
> >
> > So, for the Zynq and similar BSPs this would yield for the Rust target
> something like: armv7a-rtems6-eabihf (and possibly armv7a-rtems6-eabi).
> > Similarly, for other ARM BSPs additional Rust targets would need to be
> added. Which might add up to quite a  number of Rust targets over time.
> > Is this fine or do you see another solution?
> Just to make sure I understand your question correct:
> You want to push the RTEMS support you have developed (changes to Rust
> libraries, test framework, ability to have a main() in the Rust code for
> RTEMS etc.) to the official Rust repository - so that it is available to
> everyone through the Rust nightly builds?
>
> If this is so, then your question would be primarily a question to the
> Rust folks because it is their repository which would possibly receive
> many different entries for (similar?) RTEMS BSPs?
>
> As far as I understand this, the steps for an RTEMS developer would be:
>
> 1) Build the right RTEMS tools with the Source Builder. Here: ARM tools.
> 2) Build RTEMS (kernel) for the right (RTEMS) BSP
> 3) Install the Rust compiler and its tools
> 4) Create a Rust project
> 5) Fine tune some Rust configuration files in that project.
> Here the "armv7a-rtems6-eabihf" or something fitting the BSP would
> be used in a config file. The point is, it must be for the processor
> and BSP which matches the RTEMS tools and BSP selected in steps 1)
> and 2)
> 6) Make changes to the sample Rust code generated in the project
> or write the Rust code desired.
> 7) Load the nightly build of the Rust compiler.
> (The nightly is only needed as long as your code has not entered the
> stable build).
> 8) Compile the Rust program code with the Rust nightly compiler.
> 9) Link the Rust binary with the RTEMS libraries into a single
> executable (using a linker build by the RTEMS tools).
>
> Which name Rust accepts instead of "armv7a-rtems6-eabihf" depends on the
> naming convention of the Rust community:
>  https://docs.rust-embedded.org/embedonomicon/custom-target.html
> According to this file, the part `eabi` is for bare metal. Would this be
> correct when it is based on RTEMS? For example, a Linux target would be
> "x86_64-unknown-linux-gnu" where `gnu` means started by 'glibc'.
>

This is the more correct target name. We have worked hard for GCC, binutils,
etc. to not have any BSP specific knowledge. They know about processor
architectures and processor variations (e.g. core models) within each
family.
GCC may include shortcuts with SoC names as arguments but those just
map to the proper arguments for the CPU core on the SoC. There is no
implication of device support of any kind, much less a full BSP.

Is there no notion of multilib in the Rust tooling?


>
> By the way, section "Adding a new target" of
> https://doc.rust-lang.org/nightly/rustc/target-tier-policy.html
> points to an example:
> https://github.com/rust-lang/rust/pull/94872
> and that person discussed that triple name here:
>
>
> https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/LLVM.2Bmingw-w64.20Windows.20targets
>
> Greetings,
> Frank
> >
> > Cheers,
> >
> >
> >  Jan
> >
> > Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR)
> > German Aerospace Center
> > Institute for Software Technology | Software for Space Systems and
> Interactive Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany
> >
> > Jan Sommer
> > Telephone +49 531 295-2494 | Telefax 0531 295-2767 |jan.som...@dlr.de
> > DLR.de/SC
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> >
>
> --
> embedded brains GmbH & Co. KG
> Herr Frank KÜHNDEL
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: frank.kuehn...@embedded-brains.de
> phone:  +49-89-18 94 741 - 23
> mobile: +49-176-15 22 06 - 11
>
> Registergericht: Amtsgericht München
> Registernummer: HRA 117265
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> ___
> devel mailing 

Fwd: [rtems-bsp-builder] 2024-01-20 06:26:20: Profile(s): everything

[Joel Sherrill]

Looksike some of the rece t activities around the tms750 BSP have not been
fully accounted for.

Remember that if the set of BSPs has changed, the tiers definition files in
rtems-tools need to be updated

-- Forwarded message -
From: OAR Tester for Ubuntu 22.04 
Date: Sat, Jan 20, 2024, 11:22 AM
Subject: [rtems-bsp-builder] 2024-01-20 06:26:20: Profile(s): everything
To: 


RTEMS Tools Project - RTEMS Kernel BSP Builder, 6.0.not_released


Host: #14~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon Nov 20 18:15:30 UTC 2

command: /home/tester/rtems-cron-6/tools/6/bin/rtems-bsp-builder\
 --rtems=/home/tester/rtems-cron-6/rtems --build-path=/home/tester\
 /rtems-cron-6/build --prefix=/home/tester/rtems-\
 cron-6/tools/6/bsps --log=/home/tester/rtems-cron-6/bsp-\
 builder.log --warnings-report=warnings.log --mail --use-gitconfig\
 --profiles=everything

Total Time: 4:58:31.096177 for 1298 completed job(s)
Average BSP Build Time: 0:00:13.798995

Builds
==
 debug
 no-posix
 posix
 posix-debug
 posix-profiling
 profiling
 smp
 smp-debug

Failures Report
===
   1 debug arm/tms570ls3137_hdk_with_loader configure:
  configure: /home/tester/rtems-cron-6/rtems/waf configure\
  --prefix=/home/tester/rtems-cron-6/tools/6/bsps --top=/home/tester\
  /rtems-cron-6/rtems --rtems-config=config-arm-\
  tms570ls3137_hdk_with_loader-debug.ini

   2 no-posix arm/tms570ls3137_hdk_with_loader configure:
  configure: /home/tester/rtems-cron-6/rtems/waf configure\
  --prefix=/home/tester/rtems-cron-6/tools/6/bsps --top=/home/tester\
  /rtems-cron-6/rtems --rtems-config=config-arm-\
  tms570ls3137_hdk_with_loader-no-posix.ini

   3 posix arm/tms570ls3137_hdk_with_loader configure:
  configure: /home/tester/rtems-cron-6/rtems/waf configure\
  --prefix=/home/tester/rtems-cron-6/tools/6/bsps --top=/home/tester\
  /rtems-cron-6/rtems --rtems-config=config-arm-\
  tms570ls3137_hdk_with_loader-posix.ini

   4 posix-debug arm/tms570ls3137_hdk_with_loader configure:
  configure: /home/tester/rtems-cron-6/rtems/waf configure\
  --prefix=/home/tester/rtems-cron-6/tools/6/bsps --top=/home/tester\
  /rtems-cron-6/rtems --rtems-config=config-arm-\
  tms570ls3137_hdk_with_loader-posix-debug.ini

   5 posix-profiling arm/tms570ls3137_hdk_with_loader configure:
  configure: /home/tester/rtems-cron-6/rtems/waf configure\
  --prefix=/home/tester/rtems-cron-6/tools/6/bsps --top=/home/tester\
  /rtems-cron-6/rtems --rtems-config=config-arm-\
  tms570ls3137_hdk_with_loader-posix-profiling.ini

   6 profiling arm/tms570ls3137_hdk_with_loader configure:
  configure: /home/tester/rtems-cron-6/rtems/waf configure\
  --prefix=/home/tester/rtems-cron-6/tools/6/bsps --top=/home/tester\
  /rtems-cron-6/rtems --rtems-config=config-arm-\
  tms570ls3137_hdk_with_loader-profiling.ini

   7 smp arm/tms570ls3137_hdk_with_loader configure:
  configure: /home/tester/rtems-cron-6/rtems/waf configure\
  --prefix=/home/tester/rtems-cron-6/tools/6/bsps --top=/home/tester\
  /rtems-cron-6/rtems --rtems-config=config-arm-\
  tms570ls3137_hdk_with_loader-smp.ini

   8 smp-debug arm/tms570ls3137_hdk_with_loader configure:
  configure: /home/tester/rtems-cron-6/rtems/waf configure\
  --prefix=/home/tester/rtems-cron-6/tools/6/bsps --top=/home/tester\
  /rtems-cron-6/rtems --rtems-config=config-arm-\
  tms570ls3137_hdk_with_loader-smp-debug.ini


Warnings Report
===
 +=+
 | By Architecture (total : 11489) |
 +-+
 | common : 15 warning(s)  |
 +-+++-+
 |   Shared :  534 | BSP :0 | Network :0 |Tests :0 |
 |   LibCPU :0 | CPU Kit :  342 || |
 +---+-+++-+
 | aarch64 : 0 warning(s)  |
 +-+
 | arm : 57 warning(s) |
 +-+++-+
 |   Shared :  192 | BSP :0 | Network :0 |Tests :0 |
 |   LibCPU :0 | CPU Kit : 1116 || |
 +---+-+++-+
 | bfin : 32 warning(s)|
 +-+++-+
 |   Shared :  138 | BSP :0 | Network :0 |Tests :0 |
 |   LibCPU :  234 | CPU Kit :  132 |

Fwd: [RTEMS Project] #45: shsim does not build

[Joel Sherrill]

And this is the other half of the ticket number.

-- Forwarded message -
From: RTEMS trac 
Date: Mon, Jan 15, 2024, 3:37 AM
Subject: Re: [RTEMS Project] #45: shsim does not build
To:
Cc: 


#45: shsim does not build
---+-
 Reporter:  Joel Sherrill  |   Owner:  Ralf Corsepius
 Type:  defect |  Status:  closed
 Priority:  normal |   Milestone:  2
Component:  bsps   | Version:  unknown
 Severity:  major  |  Resolution:  fixed
 Keywords: |
---+-

Comment (by Sebastian Huber ):

 In [changeset:"75dd82407980a227a39aef70b383090778361f70/rtems"
 75dd824/rtems]:
 {{{
 #!CommitTicketReference repository="rtems"
 revision="75dd82407980a227a39aef70b383090778361f70"
 bsp/tms570: Add errata SSWF021#45 handling

 Update #4982.
 }}}

--
Ticket URL: <http://devel.rtems.org/ticket/45#comment:3>
RTEMS Project <http://www.rtems.org/>
RTEMS Project
___
bugs mailing list
b...@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Fwd: [RTEMS Project] #60: GNATS: Additional state

[Joel Sherrill]

Looks like one of the commits has the wrong ticket number.

And this ticket should be closed anyway. We haven't used GNATS in a long
time.

-- Forwarded message -
From: RTEMS trac 
Date: Mon, Jan 15, 2024, 3:37 AM
Subject: Re: [RTEMS Project] #60: GNATS: Additional state
To:
Cc: 


#60: GNATS: Additional state
+-
 Reporter:  Ralf Corsepius  |   Owner:  Jeff Mayes
 Type:  enhancement |  Status:  closed
 Priority:  lowest  |   Milestone:  2
Component:  admin   | Version:  unknown
 Severity:  minor   |  Resolution:  fixed
 Keywords:  |
+-

Comment (by Tyler Miller ):

 In [changeset:"2bbacdb557c74a513ecc6f3b2f581ac6b6344c4e/rtems"
 2bbacdb/rtems]:
 {{{
 #!CommitTicketReference repository="rtems"
 revision="2bbacdb557c74a513ecc6f3b2f581ac6b6344c4e"
 bsp/tms570: TMS570LC4x Errata DEVICE#60

 Update #4982.
 }}}

--
Ticket URL: 
RTEMS Project 
RTEMS Project
___
bugs mailing list
b...@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RTEMS 6.1-rc1 RSB URL Issue

[Joel Sherrill]

Hi

I was trying to test rc1 and all of the tool builds fail like this:

==
script: 86: source_dir_rtems_tools=${rtems_tools_source}
source setup: rtems-tools-6.1-rc1-1: source rtems-tools -q -n
${rtems_tools_source}
making dir:
/home/joel/rtems-6.1rc1/rtems-source-builder-6.1-rc1/rtems/sources
download: (full)
https://ftp.rtems.org/pub/rtems/releases/6/rc/6.1-rc1/6/rc/6.1-rc1/sources/rtems-tools-6.1-rc1.tar.xz
-> sources/rtems-tools-6.1-rc1.tar.xz
download:
https://ftp.rtems.org/pub/rtems/releases/6/rc/6.1-rc1/6/rc/6.1-rc1/sources/rtems-tools... -> sources/rtems-tools-6.1-rc1.tar.xz
download: no ssl context
download:
https://ftp.rtems.org/pub/rtems/releases/6/rc/6.1-rc1/6/rc/6.1-rc1/sources/rtems-tools...: error: HTTP Error 404: Not Found
download: (full)
https://git.rtems.org/rtems-tools/snapshot/rtems-tools-6.1-rc1.tar.xz ->
sources/rtems-tools-6.1-rc1.tar.xz
download:
https://git.rtems.org/rtems-tools/snapshot/rtems-tools-6.1-rc1.tar.xz ->
sources/rtems-tools-6.1-rc1.tar.xz
download: no ssl context
download:
https://git.rtems.org/rtems-tools/snapshot/rtems-tools-6.1-rc1.tar.xz:
error: HTTP Error 400: Bad request
error: downloading
https://git.rtems.org/rtems-tools/snapshot/rtems-tools-6.1-rc1.tar.xz: all
paths have failed, giving up
  See error report: rsb-report-rtems-tools-6.1-rc1-1.txt
  Note: In some cases the error appears only in
  the complete build log (see --log option)

==

Using wget directly, I could duplicate that error. When I tried the URL on
the rc1 index page, it worked. See below.

===
[joel@devel rtems]$ wget
https://ftp.rtems.org/pub/rtems/releases/6/rc/6.1-rc1/6/rc/6.1-rc1/sources/rtems-tools-6.1-rc1.tar.xz
--2024-01-11 09:13:17--
https://ftp.rtems.org/pub/rtems/releases/6/rc/6.1-rc1/6/rc/6.1-rc1/sources/rtems-tools-6.1-rc1.tar.xz
Resolving ftp.rtems.org (ftp.rtems.org)... 140.211.10.151
Connecting to ftp.rtems.org (ftp.rtems.org)|140.211.10.151|:443...
connected.
HTTP request sent, awaiting response... 404 Not Found
2024-01-11 09:13:18 ERROR 404: Not Found.

[joel@devel rtems]$ wget
https://ftp.rtems.org/pub/rtems/releases/6/rc/6.1-rc1/sources/rtems-tools-6.1-rc1.tar.xz
--2024-01-11 09:13:54--
https://ftp.rtems.org/pub/rtems/releases/6/rc/6.1-rc1/sources/rtems-tools-6.1-rc1.tar.xz
Resolving ftp.rtems.org (ftp.rtems.org)... 140.211.10.151
Connecting to ftp.rtems.org (ftp.rtems.org)|140.211.10.151|:443...
connected.
HTTP request sent, awaiting response... 200 OK
Length: 2035220 (1.9M) [application/x-xz]
Saving to: ‘rtems-tools-6.1-rc1.tar.xz’

100%[==>] 2,035,220   1.54MB/s   in
1.3s

===

Looks like the release path is wrong for rtems-tools. That is also where
--source-only-download for 6/rtems-all fails.

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

Re: CentOS 8 - no python

[Joel Sherrill]

Chris.. an RSB feature submission question at the bottom.

Rest inlined.

On Tue, Jan 9, 2024 at 9:30 AM Michael G. South  wrote:

>
> > On Jan 8, 2024, at 10:53 , Joel Sherrill  wrote:
> >
> >
> >
> > On Mon, Jan 8, 2024 at 10:13 AM Frank Kühndel <
> frank.kuehn...@embedded-brains.de> wrote:
> > Hi Joel,
> >
> > have a great 2024!
> >
> > On 12/24/23 22:16, Joel Sherrill wrote:
> >  > Hi
> >  >
> >  > Trying to bring up Coverity builds on a Centos 8 machine, I ran into
> > this:
> >  >
> >  > + ../source-builder/sb-set-builder --log=l-sparc.txt
> >  > --prefix=/home/joel/rtems-cron-coverity/tools/6 --mail --mail-to=
> >  > bu...@rtems.org  --mail-from=j...@rtems.org 6/rtems-sparc
> >  >
> >  > /usr/bin/env: ‘python’: No such file or directory
> >  >
> >  > There is, in fact, no python executable -- there is python2 and
> python3.
> >  >
> >  > Suggestions other than adding a symlink?
> >
> > In RHEL 9.3 there exists the package python-unversioned-command which
> > creates a "python" command for "python3". I do not know whether it
> > exists in CentOS 8.
>

It appears to exist via Google but this was also suggested:

$ alternatives --set python /usr/bin/python3

Or select Python 2.

FWIW I think CentOS 8 is the last RHEL version to include Python 2.


> >
> > Thanks. It looks like CentOS 8 has that package but the computer is down
> right now.
> >
> > It is on a UPS that needs a new battery. So not much use. :(
> >
> > --joel
> >
> > Greetings,
> > Frank
> >
> > --
> > embedded brains GmbH & Co. KG
> > Herr Frank KÜHNDEL
> > Dornierstr. 4
> > 82178 Puchheim
> > Germany
> > email: frank.kuehn...@embedded-brains.de
> > phone:  +49-89-18 94 741 - 23
> > mobile: +49-176-15 22 06 - 11
> >
> > Registergericht: Amtsgericht München
> > Registernummer: HRA 117265
> > 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
>
> This might become an ongoing problem. As distros drop Python 2 support
> they have a tendency to also just drop “python” -> “pythonX” links. The
> Official Word ( https://peps.python.org/pep-0394/ ) is kind of weak-kneed
> about how “Python script publishers” should approach the issue, but
> basically says to either use a virtual environment, or figure out whether
> “python” or “python3” works and then use that.
>

Yep. I think the Python folks really made a mess with this transition. And
there are bumps in the 3.x series where things change. It is just messy.

In my standards work, I remind folks that if we need to fix/change
something that we should find a way to fix the issue so the fewest set of
users are impacted. The Python authors are a much smaller subset than
Python users. This is just whining I suppose.

>
> Does source builder still work with Python 2? I seem to recall the answer
> is “no,” that the gcc (or maybe lib?) build breaks with p2. If it does
> still work, is that an explicit goal for SB, and are there regression tests
> to avoid bit rot?
>

User facing tools like the RSBand waf  are supposed to work with Python 2
or 3. OAR actively tests on CentOS 7 which is Python 2.

But.. developer facing tools can require Python 3.  The documentation uses
Sphinx which requires Python 3. I had a virtual environment on CentOS 7 to
build this. CentOS/RHEL have a concept of software collections to let you
get newer tools like gcc or Python.

At some point, I assume Python 2 will become rare enough in the user
community that we won't care to support it any longer. Guessing, I would
suspect RTEMS 6 could be the last major release to worry about Python 2.


> As an aside, SB isn’t building on macOS Catalina for a similarish reason;
> there’s a path issue with the default Apple Python install, same issue with
> the official python.org  macOS bundles, and Homebrew patched it but no
> longer supports an old-enough python3 version that doesn’t break the GCC
> builds for other reasons.
>
> I think “the right way” would be to have sb/linux.py figure out the
> correct path for Python and pass that to the rest of the build. Though a
> lot more work in this particular case.
>
> Would you be interested in a patch to linux.py/rest of SB that
> implemented such a thing?
>

I cc'ed Chris about this. I expect it would be appreciated. If he doesn't
reply to this email thread,  please just email the patch to devel@ and
let's see the reaction.

--joel

>
> Mike
>
> --
>
> Michael South
> mso...@msouth.org
> LinkedIn:  www.linkedin.com/in/msouth
>
>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: CentOS 8 - no python

[Joel Sherrill]

On Mon, Jan 8, 2024 at 10:13 AM Frank Kühndel <
frank.kuehn...@embedded-brains.de> wrote:

> Hi Joel,
>
> have a great 2024!
>
> On 12/24/23 22:16, Joel Sherrill wrote:
>  > Hi
>  >
>  > Trying to bring up Coverity builds on a Centos 8 machine, I ran into
> this:
>  >
>  > + ../source-builder/sb-set-builder --log=l-sparc.txt
>  > --prefix=/home/joel/rtems-cron-coverity/tools/6 --mail --mail-to=
>  > bu...@rtems.org  --mail-from=j...@rtems.org 6/rtems-sparc
>  >
>  > /usr/bin/env: ‘python’: No such file or directory
>  >
>  > There is, in fact, no python executable -- there is python2 and python3.
>  >
>  > Suggestions other than adding a symlink?
>
> In RHEL 9.3 there exists the package python-unversioned-command which
> creates a "python" command for "python3". I do not know whether it
> exists in CentOS 8.
>

Thanks. It looks like CentOS 8 has that package but the computer is down
right now.

It is on a UPS that needs a new battery. So not much use. :(

--joel

>
> Greetings,
> Frank
>
> --
> embedded brains GmbH & Co. KG
> Herr Frank KÜHNDEL
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: frank.kuehn...@embedded-brains.de
> phone:  +49-89-18 94 741 - 23
> mobile: +49-176-15 22 06 - 11
>
> Registergericht: Amtsgericht München
> Registernummer: HRA 117265
> 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: Pause on console in libmisc/shell detecting terminal size (mvme5500, beatnik)

[Joel Sherrill]

On Thu, Jan 4, 2024, 5:47 PM zhengxiaojun <17935...@qq.com> wrote:

>
>
> 在 2024/1/5 4:25, Peter Dufault 写道:
> > I guess maybe the list went down for a while.  I sent this on 12-30, and
> just got a bounce message today and  no "devel" mail until today.
> >
> > On master when I type a shell command at the console there is a pause,
> rough timing:
> >
> > - Three second pause after hitting return;
> > - "0q" shows up on the console;
> > - Three second pause again, then the command is executed.
> >
> > This doesn't happen on a telnet session.  It is this commit:
> >
> > commit 8425e679c149096a5d0a97990f6ebdbdd55ca522
> > Author: Chris Johns 
> > Date:   Tue Nov 22 21:05:48 2022 +1100
> >
> > libmisc/shell: Support terminal size as env variables
> >
> > Closes #4763
> >
> > Which has this:
> >
> >   fputs("\033[>0q", stdout);
> >
> > I backed it out for now.  Anyone else seeing this?
>

>
> I have the same issue, I stared a discussion on discord, but no further
> information.
>

I suspect a lot of people are just now coming back from the holidays. I
know I am just now digging out from being off since the 18th.

>
> Commit 7260887fa989c0141e7265cd851e00b4101410d8 "Work around tmux bug in
> row and column" introduced 150ms timeout(usleep(1000) 150 times). I
> tested On my board, the exact delay is about 300ms.  Timeout (in process
> shell command) will be called 3times, so the whole delay is about 1s.
>
> So maybe 150ms seems a bit long.
>
> But I found usleep() always sleep 1 more millisecond. usleep(1000)
> actual delay is about 2000us, usleep(100) actual delay is about
> 1001000us. rtems_task_wake_after() is exact.
>

Sounds like some math is arbitrarily adding a tick in the conversion to
ticks. It should just be a matter of following the code in a desk check and
checking the math. Could need a modulo to only add an extra tick when there
is a remainder.

>
> > Peter
> > -
> > Peter Dufault
> > HD Associates, Inc.  Software and System Engineering
> >
> >
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] cpukit/dosfs: Cast away ignored return

[Joel Sherrill]

Don't we put a space after the (void)?

On Thu, Jan 4, 2024 at 12:55 PM Kinsey Moore 
wrote:

> An error is already being reported. Checking the return value of this
> function is not useful.
> ---
>  cpukit/libfs/src/dosfs/msdos_file.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/cpukit/libfs/src/dosfs/msdos_file.c
> b/cpukit/libfs/src/dosfs/msdos_file.c
> index d142968337..6728a960aa 100644
> --- a/cpukit/libfs/src/dosfs/msdos_file.c
> +++ b/cpukit/libfs/src/dosfs/msdos_file.c
> @@ -179,7 +179,7 @@ msdos_file_ftruncate(rtems_libio_t *iop, off_t length)
>   length,
>   _length);
>  if (rc == RC_OK && length != new_length) {
> -fat_file_truncate(_info->fat, fat_fd, old_length);
> +(void)fat_file_truncate(_info->fat, fat_fd, old_length);
>  errno = ENOSPC;
>  rc = -1;
>  }
> --
> 2.39.2
>
> ___
> 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 rtems6 - v1 05/16] FIX: Add missing default case

[Joel Sherrill]

https://docs.rtems.org/branches/master/eng/vc-users.html#commit-message-guidance

If that is missing something, please ask questions and we can address the
Software Engineering Guide.

--joel

On Thu, Jan 4, 2024 at 2:24 PM Bernd Moessner 
wrote:

> Dear Kinsey,
>
> sry for the stupid question. What is the correct way to reference the issue
>
> [#4981  rtems6 - v1 05/16] FIX: Add
> missing default case
>
> or
>
> [PATCH rtems6 - v1 05/16] #4981 
> FIX: Add missing default case
>
> ?
>
>
>
>
> On 04.01.2024 19:48, Kinsey Moore wrote:
> > All of the patches here need an issue reference. Beyond that, this
> > patch is good to go in. I'm still reviewing the remainder of the set
> > and I'll leave the renaming discussion to Aaron.
> >
> > Kinsey
> >
> > On Thu, Jan 4, 2024 at 12:35 PM  wrote:
> >
> > From: Bernd Moessner 
> >
> > ---
> >  cpukit/dev/flash/flashdev.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/cpukit/dev/flash/flashdev.c
> b/cpukit/dev/flash/flashdev.c
> > index 27edead968..8bd3d11246 100644
> > --- a/cpukit/dev/flash/flashdev.c
> > +++ b/cpukit/dev/flash/flashdev.c
> > @@ -390,6 +390,8 @@ static int rtems_flashdev_ioctl(
> >  case RTEMS_FLASHDEV_IOCTL_GET_WRITE_BLOCK_SIZE:
> >err = rtems_flashdev_ioctl_get_write_block_size( flash, arg );
> >break;
> > +default:
> > +  err = EINVAL;
> >}
> >
> >rtems_flashdev_release( flash );
> > --
> > 2.34.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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems6 - v1 05/16] FIX: Add missing default case

[Joel Sherrill]

On Thu, Jan 4, 2024 at 12:49 PM Kinsey Moore 
wrote:

> All of the patches here need an issue reference. Beyond that, this patch
> is good to go in. I'm still reviewing the remainder of the set and I'll
> leave the renaming discussion to Aaron.
>

I have only gotten this far into the patch set but I agree with Kinsey that
they look ok.

Aaron should ack though. Hopefully that won't take long.

>
> Kinsey
>
> On Thu, Jan 4, 2024 at 12:35 PM  wrote:
>
>> From: Bernd Moessner 
>>
>> ---
>>  cpukit/dev/flash/flashdev.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/cpukit/dev/flash/flashdev.c b/cpukit/dev/flash/flashdev.c
>> index 27edead968..8bd3d11246 100644
>> --- a/cpukit/dev/flash/flashdev.c
>> +++ b/cpukit/dev/flash/flashdev.c
>> @@ -390,6 +390,8 @@ static int rtems_flashdev_ioctl(
>>  case RTEMS_FLASHDEV_IOCTL_GET_WRITE_BLOCK_SIZE:
>>err = rtems_flashdev_ioctl_get_write_block_size( flash, arg );
>>break;
>> +default:
>> +  err = EINVAL;
>>}
>>
>>rtems_flashdev_release( flash );
>> --
>> 2.34.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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems6 - v1 04/16] Flashdev: Align IOCTL and shell function names

[Joel Sherrill]

This looks ok to me. Just more name realignment which shouldn't impact much.

On Thu, Jan 4, 2024 at 12:34 PM  wrote:

> From: Bernd Moessner 
>
> ---
>  cpukit/libmisc/shell/main_flashdev.c | 36 ++--
>  1 file changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/cpukit/libmisc/shell/main_flashdev.c
> b/cpukit/libmisc/shell/main_flashdev.c
> index 969b0687d2..516c77ae27 100644
> --- a/cpukit/libmisc/shell/main_flashdev.c
> +++ b/cpukit/libmisc/shell/main_flashdev.c
> @@ -35,12 +35,12 @@
>  static int flashdev_shell_read(char *dev_path, int argc, char *argv[]);
>  static int flashdev_shell_write(char *dev_path, int argc, char *argv[]);
>  static int flashdev_shell_erase(char *dev_path, int argc, char *argv[]);
> -static int flashdev_shell_type(char *dev_path);
> -static int flashdev_shell_jedecid(char *dev_path);
> -static int flashdev_shell_page_off(char *dev_path, int argc, char
> *argv[]);
> -static int flashdev_shell_page_idx(char *dev_path, int argc, char
> *argv[]);
> -static int flashdev_shell_pg_count(char *dev_path);
> -static int flashdev_shell_wb_size(char *dev_path);
> +static int flashdev_shell_get_type(char *dev_path);
> +static int flashdev_shell_get_jedec_id(char *dev_path);
> +static int flashdev_shell_get_page_by_off(char *dev_path, int argc, char
> *argv[]);
> +static int flashdev_shell_get_page_by_idx(char *dev_path, int argc, char
> *argv[]);
> +static int flashdev_shell_get_pg_count(char *dev_path);
> +static int flashdev_shell_get_wb_size(char *dev_path);
>
>  static int flashdev_shell_ioctl_value(
>char *dev_path,
> @@ -99,22 +99,22 @@ static int rtems_flashdev_shell_main( int argc, char
> *argv[] ) {
>  return flashdev_shell_erase(dev_path, argc, [i]);
>case ('t'):
>  /* Flash Type */
> -return flashdev_shell_type(dev_path);
> +return flashdev_shell_get_type(dev_path);
>case ('d'):
>  /* JEDEC Id */
> -return flashdev_shell_jedecid(dev_path);
> +return flashdev_shell_get_jedec_id(dev_path);
>case ('o'):
>  /* Page info by offset */
> -return flashdev_shell_page_off(dev_path, argc, [i]);
> +return flashdev_shell_get_page_by_off(dev_path, argc, [i]);
>case ('i'):
>  /* Page info by index */
> -return flashdev_shell_page_idx(dev_path, argc, [i]);
> +return flashdev_shell_get_page_by_idx(dev_path, argc, [i]);
>case ('p'):
>  /* Page count */
> -return flashdev_shell_pg_count(dev_path);
> +return flashdev_shell_get_pg_count(dev_path);
>case ('b'):
>  /* Write block size */
> -return flashdev_shell_wb_size(dev_path);
> +return flashdev_shell_get_wb_size(dev_path);
>case ('h'):
>default:
>  /* Help */
> @@ -377,7 +377,7 @@ int flashdev_shell_erase(
>return 0;
>  }
>
> -int flashdev_shell_type( char *dev_path )
> +int flashdev_shell_get_type( char *dev_path )
>  {
>int type;
>int status;
> @@ -409,7 +409,7 @@ int flashdev_shell_type( char *dev_path )
>return 0;
>  }
>
> -int flashdev_shell_jedecid( char *dev_path ) {
> +int flashdev_shell_get_jedec_id( char *dev_path ) {
>uint32_t ret;
>int status;
>
> @@ -430,7 +430,7 @@ int flashdev_shell_jedecid( char *dev_path ) {
>return 0;
>  }
>
> -static int flashdev_shell_page_off(
> +static int flashdev_shell_get_page_by_off(
>char *dev_path,
>int argc,
>char *argv[]
> @@ -444,7 +444,7 @@ static int flashdev_shell_page_off(
>);
>  }
>
> -static int flashdev_shell_page_idx(
> +static int flashdev_shell_get_page_by_idx(
>char *dev_path,
>int argc,
>char *argv[]
> @@ -458,7 +458,7 @@ static int flashdev_shell_page_idx(
>);
>  }
>
> -static int flashdev_shell_pg_count( char *dev_path )
> +static int flashdev_shell_get_pg_count( char *dev_path )
>  {
>uint32_t ret;
>int status;
> @@ -480,7 +480,7 @@ static int flashdev_shell_pg_count( char *dev_path )
>return 0;
>  }
>
> -static int flashdev_shell_wb_size( char *dev_path )
> +static int flashdev_shell_get_wb_size( char *dev_path )
>  {
>size_t ret;
>int status;
> --
> 2.34.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 rtems6 - v1 03/16] Flashdev: Align IOCTL function and macro names

[Joel Sherrill]

This looks ok to me. Similar naming change.

On Thu, Jan 4, 2024 at 12:34 PM  wrote:

> From: Bernd Moessner 
>
> ---
>  cpukit/dev/flash/flashdev.c   | 72 +--
>  cpukit/include/dev/flash/flashdev.h   | 12 ++--
>  .../libtests/flashdev01/test_flashdev.c   | 36 +-
>  3 files changed, 60 insertions(+), 60 deletions(-)
>
> diff --git a/cpukit/dev/flash/flashdev.c b/cpukit/dev/flash/flashdev.c
> index 40666290e0..27edead968 100644
> --- a/cpukit/dev/flash/flashdev.c
> +++ b/cpukit/dev/flash/flashdev.c
> @@ -99,31 +99,31 @@ static int rtems_flashdev_ioctl_clear_region(
>rtems_libio_t *iop
>  );
>
> -static uint32_t rtems_flashdev_ioctl_jedec_id(
> +static uint32_t rtems_flashdev_ioctl_get_jedec_id(
>rtems_flashdev *flash
>  );
>
> -static uint32_t rtems_flashdev_ioctl_flash_type(
> +static uint32_t rtems_flashdev_ioctl_get_flash_type(
>rtems_flashdev *flash,
>void *arg
>  );
>
> -static int rtems_flashdev_ioctl_pageinfo_offset(
> +static int rtems_flashdev_ioctl_get_pageinfo_offset(
>rtems_flashdev *flash,
>void *arg
>  );
>
> -static int rtems_flashdev_ioctl_pageinfo_index(
> +static int rtems_flashdev_ioctl_get_pageinfo_index(
>rtems_flashdev *flash,
>void *arg
>  );
>
> -static int rtems_flashdev_ioctl_page_count(
> +static int rtems_flashdev_ioctl_get_page_count(
>rtems_flashdev *flash,
>void *arg
>  );
>
> -static int rtems_flashdev_ioctl_write_block_size(
> +static int rtems_flashdev_ioctl_get_write_block_size(
>rtems_flashdev *flash,
>void *arg
>  );
> @@ -363,7 +363,7 @@ static int rtems_flashdev_ioctl(
>err = 0;
>break;
>  case RTEMS_FLASHDEV_IOCTL_GET_JEDEC_ID:
> -  *( (uint32_t *) arg ) = rtems_flashdev_ioctl_jedec_id( flash );
> +  *( (uint32_t *) arg ) = rtems_flashdev_ioctl_get_jedec_id( flash );
>err = 0;
>break;
>  case RTEMS_FLASHDEV_IOCTL_ERASE:
> @@ -376,19 +376,19 @@ static int rtems_flashdev_ioctl(
>err = rtems_flashdev_ioctl_clear_region( flash, iop );
>break;
>  case RTEMS_FLASHDEV_IOCTL_GET_TYPE:
> -  err = rtems_flashdev_ioctl_flash_type( flash, arg );
> +  err = rtems_flashdev_ioctl_get_flash_type( flash, arg );
>break;
>  case RTEMS_FLASHDEV_IOCTL_GET_PAGEINFO_BY_OFFSET:
> -  err = rtems_flashdev_ioctl_pageinfo_offset( flash, arg );
> +  err = rtems_flashdev_ioctl_get_pageinfo_offset( flash, arg );
>break;
>  case RTEMS_FLASHDEV_IOCTL_GET_PAGEINFO_BY_INDEX:
> -  err = rtems_flashdev_ioctl_pageinfo_index( flash, arg );
> +  err = rtems_flashdev_ioctl_get_pageinfo_index( flash, arg );
>break;
>  case RTEMS_FLASHDEV_IOCTL_GET_PAGE_COUNT:
> -  err = rtems_flashdev_ioctl_page_count( flash, arg );
> +  err = rtems_flashdev_ioctl_get_page_count( flash, arg );
>break;
>  case RTEMS_FLASHDEV_IOCTL_GET_WRITE_BLOCK_SIZE:
> -  err = rtems_flashdev_ioctl_write_block_size( flash, arg );
> +  err = rtems_flashdev_ioctl_get_write_block_size( flash, arg );
>break;
>}
>
> @@ -493,12 +493,12 @@ static int rtems_flashdev_do_init(
>flash->read = NULL;
>flash->write = NULL;
>flash->erase = NULL;
> -  flash->jedec_id = NULL;
> -  flash->flash_type = NULL;
> -  flash->page_info_by_offset = NULL;
> -  flash->page_info_by_index = NULL;
> -  flash->page_count = NULL;
> -  flash->write_block_size = NULL;
> +  flash->get_jedec_id = NULL;
> +  flash->get_flash_type = NULL;
> +  flash->get_page_info_by_offset = NULL;
> +  flash->get_page_info_by_index = NULL;
> +  flash->get_page_count = NULL;
> +  flash->get_write_block_size = NULL;
>flash->region_table = NULL;
>return 0;
>  }
> @@ -768,29 +768,29 @@ static size_t rtems_flashdev_get_region_size(
>return table->regions[ rtems_flashdev_get_region_index( iop ) ].size;
>  }
>
> -static uint32_t rtems_flashdev_ioctl_jedec_id( rtems_flashdev *flash )
> +static uint32_t rtems_flashdev_ioctl_get_jedec_id( rtems_flashdev *flash )
>  {
> -  if ( flash->jedec_id == NULL ) {
> +  if ( flash->get_jedec_id == NULL ) {
>  return 0;
>} else {
> -return ( *flash->jedec_id )( flash );
> +return ( *flash->get_jedec_id )( flash );
>}
>  }
>
> -static uint32_t rtems_flashdev_ioctl_flash_type(
> +static uint32_t rtems_flashdev_ioctl_get_flash_type(
>rtems_flashdev *flash,
>void *arg
>  )
>  {
>rtems_flashdev_flash_type *type = (rtems_flashdev_flash_type*)arg;
> -  if ( flash->flash_type == NULL ) {
> +  if ( flash->get_flash_type == NULL ) {
>  return 0;
>} else {
> -return ( *flash->flash_type )( flash, type );
> +return ( *flash->get_flash_type )( flash, type );
>}
>  }
>
> -static int rtems_flashdev_ioctl_pageinfo_offset(
> +static int rtems_flashdev_ioctl_get_pageinfo_offset(
>rtems_flashdev *flash,
>void *arg
>  )
> @@ -800,18 +800,18 @@ static int rtems_flashdev_ioctl_pageinfo_offset(
>if ( arg == NULL ) {
>  

Re: [PATCH rtems6 - v1 01/16] FIX: Add missing C++ include guards

[Joel Sherrill]

This looks ok to me.

On Thu, Jan 4, 2024 at 12:34 PM  wrote:

> From: Bernd Moessner 
>
> ---
>  cpukit/include/dev/flash/flashdev.h | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/cpukit/include/dev/flash/flashdev.h
> b/cpukit/include/dev/flash/flashdev.h
> index d1dc08a5c4..6759357206 100644
> --- a/cpukit/include/dev/flash/flashdev.h
> +++ b/cpukit/include/dev/flash/flashdev.h
> @@ -39,6 +39,11 @@
>  #include 
>  #include 
>
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +
>  typedef struct rtems_flashdev rtems_flashdev;
>
>  /**
> @@ -454,6 +459,10 @@ void rtems_flashdev_destroy_and_free(
>rtems_flashdev *flash
>  );
>
> +#ifdef __cplusplus
> +}
> +#endif
> +
>  /** @} */
>
>  #endif /* _DEV_FLASHDEV_H */
> --
> 2.34.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 rtems6 - v1 02/16] Flashdev: Unify IOCTL macro names

[Joel Sherrill]

I'm ok with this. I like the subject/verb/direct object naming of the
ioctls.

--joel

On Thu, Jan 4, 2024 at 12:34 PM  wrote:

> From: Bernd Moessner 
>
> ---
>  cpukit/dev/flash/flashdev.c   | 16 
>  cpukit/include/dev/flash/flashdev.h   | 16 
>  cpukit/libmisc/shell/main_flashdev.c  | 12 ++--
>  testsuites/libtests/flashdev01/init.c | 16 
>  4 files changed, 30 insertions(+), 30 deletions(-)
>
> diff --git a/cpukit/dev/flash/flashdev.c b/cpukit/dev/flash/flashdev.c
> index be85593201..40666290e0 100644
> --- a/cpukit/dev/flash/flashdev.c
> +++ b/cpukit/dev/flash/flashdev.c
> @@ -362,32 +362,32 @@ static int rtems_flashdev_ioctl(
>rtems_flashdev_release( flash );
>err = 0;
>break;
> -case RTEMS_FLASHDEV_IOCTL_JEDEC_ID:
> +case RTEMS_FLASHDEV_IOCTL_GET_JEDEC_ID:
>*( (uint32_t *) arg ) = rtems_flashdev_ioctl_jedec_id( flash );
>err = 0;
>break;
>  case RTEMS_FLASHDEV_IOCTL_ERASE:
>err = rtems_flashdev_ioctl_erase( flash, iop, arg );
>break;
> -case RTEMS_FLASHDEV_IOCTL_REGION_SET:
> +case RTEMS_FLASHDEV_IOCTL_SET_REGION:
>err = rtems_flashdev_ioctl_set_region( flash, iop, arg );
>break;
> -case RTEMS_FLASHDEV_IOCTL_REGION_UNSET:
> +case RTEMS_FLASHDEV_IOCTL_UNSET_REGION:
>err = rtems_flashdev_ioctl_clear_region( flash, iop );
>break;
> -case RTEMS_FLASHDEV_IOCTL_TYPE:
> +case RTEMS_FLASHDEV_IOCTL_GET_TYPE:
>err = rtems_flashdev_ioctl_flash_type( flash, arg );
>break;
> -case RTEMS_FLASHDEV_IOCTL_PAGEINFO_BY_OFFSET:
> +case RTEMS_FLASHDEV_IOCTL_GET_PAGEINFO_BY_OFFSET:
>err = rtems_flashdev_ioctl_pageinfo_offset( flash, arg );
>break;
> -case RTEMS_FLASHDEV_IOCTL_PAGEINFO_BY_INDEX:
> +case RTEMS_FLASHDEV_IOCTL_GET_PAGEINFO_BY_INDEX:
>err = rtems_flashdev_ioctl_pageinfo_index( flash, arg );
>break;
> -case RTEMS_FLASHDEV_IOCTL_PAGE_COUNT:
> +case RTEMS_FLASHDEV_IOCTL_GET_PAGE_COUNT:
>err = rtems_flashdev_ioctl_page_count( flash, arg );
>break;
> -case RTEMS_FLASHDEV_IOCTL_WRITE_BLOCK_SIZE:
> +case RTEMS_FLASHDEV_IOCTL_GET_WRITE_BLOCK_SIZE:
>err = rtems_flashdev_ioctl_write_block_size( flash, arg );
>break;
>}
> diff --git a/cpukit/include/dev/flash/flashdev.h
> b/cpukit/include/dev/flash/flashdev.h
> index 6759357206..59028a8cba 100644
> --- a/cpukit/include/dev/flash/flashdev.h
> +++ b/cpukit/include/dev/flash/flashdev.h
> @@ -77,7 +77,7 @@ typedef struct rtems_flashdev rtems_flashdev;
>   * @param[out] jedec_id Pointer to uint32_t in which the JEDEC ID is
>   * returned in.
>   */
> -#define RTEMS_FLASHDEV_IOCTL_JEDEC_ID 2
> +#define RTEMS_FLASHDEV_IOCTL_GET_JEDEC_ID 2
>  /**
>   * @brief Erases flash device.
>   *
> @@ -94,20 +94,20 @@ typedef struct rtems_flashdev rtems_flashdev;
>   * @param[in] region Pointer to rtems_flashdev_region struct containing
>   * base and length of defined region.
>   */
> -#define RTEMS_FLASHDEV_IOCTL_REGION_SET 4
> +#define RTEMS_FLASHDEV_IOCTL_SET_REGION 4
>  /**
>   * @brief Removes the set region on the file descriptor.
>   *
>   * This command has no argument.
>   */
> -#define RTEMS_FLASHDEV_IOCTL_REGION_UNSET 5
> +#define RTEMS_FLASHDEV_IOCTL_UNSET_REGION 5
>  /**
>   * @brief Returns the type of flash device (e.g. NOR or NAND).
>   *
>   * @param[out] flash_type Pointer to integer which is set to the flash
>   * type macro value.
>   */
> -#define RTEMS_FLASHDEV_IOCTL_TYPE 6
> +#define RTEMS_FLASHDEV_IOCTL_GET_TYPE 6
>
>  /**
>   * @brief Get the size and address of flash page at given offset
> @@ -118,7 +118,7 @@ typedef struct rtems_flashdev rtems_flashdev;
>   * @param[in,out] rtems_flashdev_ioctl_page_info arg Pointer to struct
>   * with offset and space for return values.
>   */
> -#define RTEMS_FLASHDEV_IOCTL_PAGEINFO_BY_OFFSET 7
> +#define RTEMS_FLASHDEV_IOCTL_GET_PAGEINFO_BY_OFFSET 7
>
>  /**
>   * @brief Get the size and address of nth flash page where n is index
> passed in.
> @@ -128,21 +128,21 @@ typedef struct rtems_flashdev rtems_flashdev;
>   * @param[in,out] rtems_flashdev_ioctl_page_info arg Pointer to struct
>   * with index and space for return values.
>   */
> -#define RTEMS_FLASHDEV_IOCTL_PAGEINFO_BY_INDEX 8
> +#define RTEMS_FLASHDEV_IOCTL_GET_PAGEINFO_BY_INDEX 8
>
>  /**
>   * @brief Get the number of pages in flash device.
>   *
>   * @param[out] count Integer containing the number of pages.
>   */
> -#define RTEMS_FLASHDEV_IOCTL_PAGE_COUNT 9
> +#define RTEMS_FLASHDEV_IOCTL_GET_PAGE_COUNT 9
>
>  /**
>   * @brief Get the minimum write size supported by the driver.
>   *
>   * @param[out] count Integer containing the minimum write size.
>   */
> -#define RTEMS_FLASHDEV_IOCTL_WRITE_BLOCK_SIZE 10
> +#define RTEMS_FLASHDEV_IOCTL_GET_WRITE_BLOCK_SIZE 10
>
>  /**
>   * @brief The maximum number of region limited file descriptors
> diff --git 

CentOS 8 - no python

[Joel Sherrill]

Hi

Trying to bring up Coverity builds on a Centos 8 machine, I ran into this:

+ ../source-builder/sb-set-builder --log=l-sparc.txt
--prefix=/home/joel/rtems-cron-coverity/tools/6 --mail --mail-to=
bu...@rtems.org --mail-from=j...@rtems.org 6/rtems-sparc

/usr/bin/env: ‘python’: No such file or directory

There is, in fact, no python executable -- there is python2 and python3.

Suggestions other than adding a symlink?

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

Fwd: New Defects reported by Coverity Scan for RTEMS-Tools

[Joel Sherrill]

Any suggestions on how to address these?

-- Forwarded message -
From: 
Date: Sun, Dec 24, 2023, 1:18 PM
Subject: New Defects reported by Coverity Scan for RTEMS-Tools
To: 


Hi,

Please find the latest report on new defect(s) introduced to RTEMS-Tools
found with Coverity Scan.

39 new defect(s) introduced to RTEMS-Tools found with Coverity Scan.
12 defect(s), reported by Coverity Scan earlier, were marked fixed in the
recent build analyzed by Coverity Scan.

New defect(s) Reported-by: Coverity Scan
Showing 20 of 39 defect(s)


** CID 1574966:  Performance inefficiencies  (COPY_INSTEAD_OF_MOVE)
/tester/covoar/Target_i386.cc: 17 in
Target::Target_i386::Target_i386(std::__cxx11::basic_string, std::allocator>)()



*** CID 1574966:  Performance inefficiencies  (COPY_INSTEAD_OF_MOVE)
/tester/covoar/Target_i386.cc: 17 in
Target::Target_i386::Target_i386(std::__cxx11::basic_string, std::allocator>)()
11 #include 
12 #include 
13
14 namespace Target {
15
16   Target_i386::Target_i386( std::string targetName ):
>>> CID 1574966:  Performance inefficiencies  (COPY_INSTEAD_OF_MOVE)
>>> "targetName" is passed-by-value as parameter to
"Target::TargetBase::TargetBase(std::__cxx11::string)" when it could be
moved instead.
17 TargetBase( targetName )
18   {
19 conditionalBranchInstructions.push_back("ja");
20 conditionalBranchInstructions.push_back("jb");
21 conditionalBranchInstructions.push_back("jc");
22 conditionalBranchInstructions.push_back("je");

** CID 1574965:(COPY_INSTEAD_OF_MOVE)
/rtemstoolkit/pkgconfig.cpp: 90 in pkgconfig::package::load(const
std::__cxx11::basic_string,
std::allocator> &)()
/rtemstoolkit/pkgconfig.cpp: 92 in pkgconfig::package::load(const
std::__cxx11::basic_string,
std::allocator> &)()



*** CID 1574965:(COPY_INSTEAD_OF_MOVE)
/rtemstoolkit/pkgconfig.cpp: 90 in pkgconfig::package::load(const
std::__cxx11::basic_string,
std::allocator> &)()
84
85 if (d != std::string::npos)
86 {
87   std::string lhs = rld::tolower (line.substr (0, d));
88   std::string rhs = line.substr (d + 1);
89   if (def)
>>> CID 1574965:(COPY_INSTEAD_OF_MOVE)
>>> "rhs" is copied in a call to copy assignment "operator =", when it
could be moved instead.
90 defines[lhs] = rhs;
91   else
92 fields[lhs] = rhs;
93 }
94   }
95 }
/rtemstoolkit/pkgconfig.cpp: 92 in pkgconfig::package::load(const
std::__cxx11::basic_string,
std::allocator> &)()
86 {
87   std::string lhs = rld::tolower (line.substr (0, d));
88   std::string rhs = line.substr (d + 1);
89   if (def)
90 defines[lhs] = rhs;
91   else
>>> CID 1574965:(COPY_INSTEAD_OF_MOVE)
>>> "rhs" is copied in a call to copy assignment "operator =", when it
could be moved instead.
92 fields[lhs] = rhs;
93 }
94   }
95 }
96
97 in.close ();

** CID 1574964:  Performance inefficiencies  (COPY_INSTEAD_OF_MOVE)
/tester/covoar/covoar.cc: 142 in
createBuildPath(std::__cxx11::list> &,
std::__cxx11::basic_string,
std::allocator> &, std::__cxx11::basic_string, std::allocator> &,
std::__cxx11::basic_string,
std::allocator> &)()



*** CID 1574964:  Performance inefficiencies  (COPY_INSTEAD_OF_MOVE)
/tester/covoar/covoar.cc: 142 in
createBuildPath(std::__cxx11::list> &,
std::__cxx11::basic_string,
std::allocator> &, std::__cxx11::basic_string, std::allocator> &,
std::__cxx11::basic_string,
std::allocator> &)()
136 for ( ; pri != eparts.rend(); ++pri )
137   bparts.insert(bparts.begin(), *pri);
138
139 std::string thisBuildPath;
140 rld::path::path_join( thisBuildPath, bparts, thisBuildPath
);
141 if ( buildPath.empty() ) {
>>> CID 1574964:  Performance inefficiencies  (COPY_INSTEAD_OF_MOVE)
>>> "thisBuildPath" is copied in a call to copy assignment "operator
=", when it could be moved instead.
142   buildPath = thisBuildPath;
143 } else {
144   if ( buildPath != thisBuildPath ) {
145 fail = "executable build path does not match: " +
buildPath;
146   }
147 }

** CID 1574963:  Performance inefficiencies  (COPY_INSTEAD_OF_MOVE)
/linkers/rtems-exeinfo.cpp: 757 in
rld::exeinfo::func_count::func_count(std::__cxx11::basic_string, std::allocator>, unsigned long)()



*** CID 1574963:  

Re: [rtems-docs PATCH] sphinx/style: Fix building with the latest sphinx

[Joel Sherrill]

It is working for me on Rocky 9 with Sphinx 7.2.6 and a Texlive from this
summer.

The missing step was removing the older Sphinx version. Then I had to also
install PlantUML npm.

--joel

On Tue, Dec 19, 2023 at 3:45 PM Chris Johns  wrote:

> On 20/12/2023 8:12 am, Joel Sherrill wrote:
> > I tried the patch on Rocky 9 with Python 3.9.14 and sphinx-build  5.3.0
> from a
> > pip local install.
> >
> > (rtemsdocs) [joel@localhost rtems-docs]$ ./waf distclean
> > Waf: The wscript in '/home/joel/rtems-work/rtems-docs' is unreadable
> > Traceback (most recent call last):
> >   File
> >
> "/home/joel/rtems-work/rtems-docs/.waf3-2.0.25-767522112be77f8585812fcfaa08e805/waflib/Scripting.py",
> line 102, in waf_entry_point
> > set_main_module(wscript)
> >   File
> >
> "/home/joel/rtems-work/rtems-docs/.waf3-2.0.25-767522112be77f8585812fcfaa08e805/waflib/Scripting.py",
> line 142, in set_main_module
> > Context.g_module=Context.load_module(file_path)
> >   File
> >
> "/home/joel/rtems-work/rtems-docs/.waf3-2.0.25-767522112be77f8585812fcfaa08e805/waflib/Context.py",
> line 362, in load_module
> > exec(compile(code,path,'exec'),module.__dict__)
> >   File "/home/joel/rtems-work/rtems-docs/wscript", line 17, in 
> > from common import waf as docs_waf
> >   File "/home/joel/rtems-work/rtems-docs/common/waf.py", line 17, in
> 
> > import conf
> >   File "/home/joel/rtems-work/rtems-docs/common/conf.py", line 87, in
> 
> > import sphinx_rtd_theme_rtems
> >   File
> >
> "/home/joel/rtems-work/rtems-docs/common/sphinx_rtd_theme_rtems/__init__.py",
> > line 9, in 
> > import sphinx
> > ModuleNotFoundError: No module named 'sphinx'
> >
> > Any ideas what I might be missing?
>
> This looks like a local set up issue.
>
> My testing was with python 3.11, venv and pip in the virtual env.
>
> > FWIW the patch didn't apply on my CentOS 7 VM with an even older Sphinx.
>
> The patch is from git to the mailing list. It is now pushed to master so
> please
> try there.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems-docs commit] sphinx/style: Fix building with the latest sphinx

[Joel Sherrill]

It didn't work on the CentOS 7 system because Chris pushed while I was
switching VMs.

I now get the same output on CentOS 7 as on Rocky 9. It has sphinx-build
5.3.0

--joel

On Tue, Dec 19, 2023 at 3:10 PM Chris Johns  wrote:

> Module:rtems-docs
> Branch:master
> Commit:e31a0b22fe43e0ec910678cdc4bdcf2be661a461
> Changeset:
> http://git.rtems.org/rtems-docs/commit/?id=e31a0b22fe43e0ec910678cdc4bdcf2be661a461
>
> Author:Chris Johns 
> Date:  Tue Dec 19 12:31:52 2023 +1100
>
> sphinx/style: Fix building with the latest sphinx
>
> Tested on sphinx 7.2, 6.1.3 AND 5.3.0
>
> Closes #4980
>
> ---
>
>  common/sphinx_rtd_theme_rtems/layout.html | 6 +-
>  common/waf.py | 4 +---
>  2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/common/sphinx_rtd_theme_rtems/layout.html
> b/common/sphinx_rtd_theme_rtems/layout.html
> index 0fe6c65..3542bea 100644
> --- a/common/sphinx_rtd_theme_rtems/layout.html
> +++ b/common/sphinx_rtd_theme_rtems/layout.html
> @@ -67,7 +67,11 @@
>{%- endblock %}
>
>{# CSS #}
> -   type="text/css" />
> +  {%- if sphinx_version <= "5.9.0" -%}
> +type="text/css" />
> +  {%- else %}
> +type="text/css" />
> +  {%- endif %}
> type="text/css" />
>{%- for css in css_files %}
>  {%- if css|attr("rel") %}
> diff --git a/common/waf.py b/common/waf.py
> index 6efe038..5f811f6 100644
> --- a/common/waf.py
> +++ b/common/waf.py
> @@ -16,11 +16,9 @@ from waflib.Build import BuildContext
>  import latex
>  import conf
>
> -# Sphinx >= 6 are currently broken.
>  # If you do not want to check for a maximum version, set it to None.
>  sphinx_min_version = (1, 3)
> -sphinx_max_version = (5, 9)
> -#sphinx_max_version = None
> +sphinx_max_version = None
>
>  def version_cmdline(ctx):
>  return '-Drelease="%s" -Dversion="%s" -Drtems_major="%s" ' \
>
> ___
> vc mailing list
> v...@rtems.org
> http://lists.rtems.org/mailman/listinfo/vc
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems-docs PATCH] sphinx/style: Fix building with the latest sphinx

[Joel Sherrill]

I tried the patch on Rocky 9 with Python 3.9.14 and sphinx-build  5.3.0
from a pip local install.

(rtemsdocs) [joel@localhost rtems-docs]$ ./waf distclean
Waf: The wscript in '/home/joel/rtems-work/rtems-docs' is unreadable
Traceback (most recent call last):
  File
"/home/joel/rtems-work/rtems-docs/.waf3-2.0.25-767522112be77f8585812fcfaa08e805/waflib/Scripting.py",
line 102, in waf_entry_point
set_main_module(wscript)
  File
"/home/joel/rtems-work/rtems-docs/.waf3-2.0.25-767522112be77f8585812fcfaa08e805/waflib/Scripting.py",
line 142, in set_main_module
Context.g_module=Context.load_module(file_path)
  File
"/home/joel/rtems-work/rtems-docs/.waf3-2.0.25-767522112be77f8585812fcfaa08e805/waflib/Context.py",
line 362, in load_module
exec(compile(code,path,'exec'),module.__dict__)
  File "/home/joel/rtems-work/rtems-docs/wscript", line 17, in 
from common import waf as docs_waf
  File "/home/joel/rtems-work/rtems-docs/common/waf.py", line 17, in

import conf
  File "/home/joel/rtems-work/rtems-docs/common/conf.py", line 87, in

import sphinx_rtd_theme_rtems
  File
"/home/joel/rtems-work/rtems-docs/common/sphinx_rtd_theme_rtems/__init__.py",
line 9, in 
import sphinx
ModuleNotFoundError: No module named 'sphinx'

Any ideas what I might be missing?

FWIW the patch didn't apply on my CentOS 7 VM with an even older Sphinx.

--joel

On Tue, Dec 19, 2023 at 1:05 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 19.12.23 02:34, chr...@rtems.org wrote:
> > From: Chris Johns
> >
> > Tested on sphinx 7.2, 6.1.3 AND 5.3.0
> >
> > Closes #4980
>
> Thanks, it is a really nice improvement to be able to use newer Sphinx
> versions.
>
> --
> embedded brains GmbH & Co. KG
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] glossary: Add terms

[Joel Sherrill]

On Tue, Nov 28, 2023 at 10:27 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> ---
>  c-user/glossary.rst   | 50 +++
>  eng/fv/approaches.rst |  2 +-
>  eng/fv/overview.rst   |  6 +++---
>  eng/glossary.rst  | 26 +-
>  4 files changed, 75 insertions(+), 9 deletions(-)
>
> diff --git a/c-user/glossary.rst b/c-user/glossary.rst
> index 82aedcd..9a9d12c 100644
> --- a/c-user/glossary.rst
> +++ b/c-user/glossary.rst
> @@ -1,5 +1,6 @@
>  .. SPDX-License-Identifier: CC-BY-SA-4.0
>
> +.. Copyright (C) 2022, 2023 Trinity College Dublin
>  .. Copyright (C) 2020 Richi Dubey (richidu...@gmail.com)
>  .. Copyright (C) 2015, 2023 embedded brains GmbH & Co. KG
>  .. Copyright (C) 1988, 1998 On-Line Applications Research Corporation
> (OAR)
> @@ -17,6 +18,9 @@ Glossary
>  A term used to describe an object which has been created by an
>  application.
>
> +AMP
> +This term is an acronym for Asymmetric Multiprocessing.
> +
>  APA
>  This term is an acronym for Arbitrary Processor Affinity.  APA
> schedulers
>  allow a thread to have an arbitrary affinity to a processor set,
> rather than
> @@ -357,6 +361,10 @@ Glossary
>  mathematically intensive situations.  It is typically viewed as a
> logical
>  extension of the primary processor.
>
> +formal model
> +A model of a computing component (hardware or software) that has a
> +mathematically based :term:`semantics`.
>

This is in the neighborhood of the definitions I found but is missing a word
like rigorous.


> +
>  freed
>  A resource that has been released by the application to RTEMS.
>
> @@ -386,6 +394,14 @@ Glossary
>  GNU
>  This term is an acronym for `GNU's Not Unix  >`_.
>
> +GPL
> +This term is an acronym for
> +`GNU General Public License `__.
> +
> +GPLv3
> +This term is an acronym for
> +`GNU General Public License Version 3 <
> https://www.gnu.org/licenses/gpl-3.0.html>`__.
> +
>

Do we need to include an entry for the GPLv2 w/exception that is actually
used by some RTEMS code.


>  GR712RC
>  The
>  `GR712RC <
> https://www.gaisler.com/index.php/products/components/gr712rc>`_
> @@ -511,6 +527,10 @@ Glossary
>  LIFO
>  This term is an acronym for :term:`Last In First Out`.
>
> +Linear Temporal Logic
> +This is a logic that states properties about (possibly infinite)
> sequences of
> +states.
> +
>  list
>  A data structure which allows for dynamic addition and removal of
>  entries.  It is not statically limited to a particular size.
> @@ -520,6 +540,12 @@ Glossary
>  are arranged such that the least significant byte is at the lowest
>  address.
>
> +LLVM
> +This term is an acronym for
> +`Low Level Virtual Machine `__.
> +The LLVM Project is a collection of modular and reusable compiler
> and
> +toolchain technologies.
> +
>  local
>  An object which was created with the LOCAL attribute and is
> accessible
>  only on the node it was created and resides upon.  In a single
> processor
> @@ -541,6 +567,9 @@ Glossary
>  A :term:`task` ``L`` has a lower :term:`priority` than a task
> ``H``, if
>  task ``L`` is less important than task ``H``.
>
> +LTL
> +This term is an acronym for :term:`Linear Temporal Logic`.
> +
>  major number
>  The index of a device driver in the Device Driver Table.
>
> @@ -632,6 +661,9 @@ Glossary
>  mathematically intensive situations.  It is typically viewed as a
> logical
>  extension of the primary processor.
>
> +OBC
> +This term is an acronym for On-Board Computer.
> +
>  object
>  In this document, this term is used to refer collectively to
> tasks,
>  timers, message queues, partitions, regions, semaphores, ports,
> and rate
> @@ -806,6 +838,10 @@ Glossary
>  A term used to describe routines which do not modify themselves
> or global
>  variables.
>
> +refinement
> +A *refinement* is a relationship between a specification and its
> +implementation as code.
> +
>  region
>  An RTEMS object which is used to allocate and deallocate variable
> size
>  blocks of memory from a dynamically specified area of memory.
> @@ -818,6 +854,9 @@ Glossary
>  Registers are locations physically located within a component,
> typically
>  used for device control or general purpose storage.
>
> +reification
> +Another term used to denote :term:`refinement`.
> +
>  remote
>  Any object that does not reside on the local node.
>
> @@ -865,6 +904,12 @@ Glossary
>  The state of a rate monotonic timer while it is being used to
> 

Re: [PATCH v3 rtems master 1/3] Fix add missing clock settings for zc706

[Joel Sherrill]

Since no one commented/complained and I saw no obvious issues, I took the
liberty to commit these.

Thanks.

--joel

On Tue, Nov 21, 2023 at 2:02 PM Bernd Moessner 
wrote:

> From: Bernd Moessner 
>
> ---
>  spec/build/bsps/arm/xilinx-zynq/opta9periphclk.yml | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/spec/build/bsps/arm/xilinx-zynq/opta9periphclk.yml
> b/spec/build/bsps/arm/xilinx-zynq/opta9periphclk.yml
> index 7233f73d5a..fdee4c0568 100644
> --- a/spec/build/bsps/arm/xilinx-zynq/opta9periphclk.yml
> +++ b/spec/build/bsps/arm/xilinx-zynq/opta9periphclk.yml
> @@ -6,7 +6,9 @@ build-type: option
>  copyrights:
>  - Copyright (C) 2020 embedded brains GmbH & Co. KG
>  default:
> -- enabled-by: arm/xilinx_zynq_zc702
> +- enabled-by:
> +  - arm/xilinx_zynq_zc702
> +  - arm/xilinx_zynq_zc706
>value: 3
>  - enabled-by: arm/xilinx_zynq_zedboard
>value: 7
> --
> 2.25.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: Fwd: [PATCH] Update GMP/MPFR/MPC/ISL/gettext to latest release

[Joel Sherrill]

Gdb now needs a couple of those installed. Perhaps they need to be in the
bset.

Also FreeBSD 12 and 13 regularly fail. See build@ for details.

On Sun, Nov 26, 2023, 6:53 PM Chris Johns  wrote:

> On 27/11/2023 1:35 am, Sebastian Huber wrote:
> > Hello,
> >
> > could some issues on macOS be cased by explicitly setting the configure
> --build
> > and --host in the RSB:
>
> Thanks for asking on the gcc patches list. I do not know and I also do not
> know
> the rational for the per version numbering on build and host commands we
> are
> being forced to adopt.
>
> I tested the change we have for gcc-12 with gcc-13 and it worked. The main
> effort I resolved is in #4892 [1] and I am not sure where the cross over
> is or
> the status of the problem I found.
>
> Chris
> [1] https://devel.rtems.org/ticket/4892
>
> >
> >  Forwarded Message 
> > Subject: Re: [PATCH] Update GMP/MPFR/MPC/ISL/gettext to latest release
> > Date: Sun, 26 Nov 2023 10:15:27 +
> > From: Iain Sandoe 
> > To: Sebastian Huber 
> > CC: Richard Biener , GCC Patches
> > 
> >
> >
> >
> >> On 26 Nov 2023, at 10:05, Sebastian Huber <
> sebastian.hu...@embedded-brains.de>
> >> wrote:
> >>
> >> On 26.11.23 01:35, Iain Sandoe wrote:
>  On 25 Nov 2023, at 21:44, Sebastian Huber
>   wrote:
> 
>  On 25.11.23 14:59, Richard Biener wrote:
> > On Sat, Nov 25, 2023 at 12:26 PM Sebastian Huber
> >   wrote:
> >> contrib/ChangeLog
> > Did you verify an in-tree build with these works and the testsuite
> > is clean?
> 
>  I was able to build a native GCC:
> 
>  /tmp/sh/i-native/bin/gcc --version --verbose
>  Using built-in specs.
>  COLLECT_AS_OPTIONS='--version'
>  COLLECT_GCC=/tmp/sh/i-native/bin/gcc
> 
> COLLECT_LTO_WRAPPER=/tmp/sh/i-native/lib/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
>  gcc (GCC) 14.0.0 20231125 (experimental) [master 9c26c91b94e]
>  Copyright (C) 2023 Free Software Foundation, Inc.
>  This is free software; see the source for copying conditions.  There
> is NO
>  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
> 
> 
>  Target: x86_64-pc-linux-gnu
>  Configured with: /home/EB/sebastian_h/src/gcc/configure
>  --prefix=/tmp/sh/i-native --verbose --enable-checking=yes,rtl
>  --disable-libsanitizer --disable-multilib --disable-bootstrap
>  --enable-languages=c,c++
>  Thread model: posix
>  Supported LTO compression algorithms: zlib
>  gcc version 14.0.0 20231125 (experimental) [master 9c26c91b94e] (GCC)
>  COLLECT_GCC_OPTIONS='--version' '-v' '-mtune=generic' '-march=x86-64'
>  '-dumpdir' 'a-'
>  /tmp/sh/i-native/lib/gcc/x86_64-pc-linux-gnu/14.0.0/cc1 -quiet -v
> help-dummy
>  -quiet -dumpdir a- -dumpbase help-dummy -mtune=generic -march=x86-64
>  -version --version -o /tmp/ccHTKJ5B.s
>  GNU C17 (GCC) version 14.0.0 20231125 (experimental) [master
> 9c26c91b94e]
>  (x86_64-pc-linux-gnu)
> compiled by GNU C version 14.0.0 20231122 (experimental)
> [master
>  6bf66276e3e], GMP version 6.3.0, MPFR version 4.2.1, MPC version
> 1.3.1, isl
>  version isl-0.26-GMP
>  [...]
> 
>  However, I noticed that this was with a disabled bootstrap (for the
> git
>  bisect). The bootstrap fails with an error in ISL 0.26 which seems to
> be a
>  known issue:
> 
>  https://www.mail-archive.com/gcc@gcc.gnu.org/msg101643.html
> 
>  I thought that the GCC prerequisite library maintainers check that a
> new
>  release is able to bootstrap GCC, but this seems to be not the case.
> The
>  older releases have problems to recognize arm64-apple.
> >>> 0.24 (at least) builds fine in-tree on aarch64-apple-darwin21; do you
> have a
> >>> pointer to the recognition issue?
> >>> I’ll try 0.25 in the next few days.
> >>
> >> For the RTEMS Project we had to add patches to ISL, MPC, MPFR for
> ARM64/Darwin
> >> hosts:
> >>
> >>
> https://github.com/RTEMS/rtems-source-builder/commit/5e76e64bccc2d84acb6c37380f2f9d98df3b7382
> >>
> >> Specifically for ISL 0.24 this is:
> >>
> >>
> https://devel.rtems.org/raw-attachment/ticket/4657/fix-mac-arm64-isl-config.patch
> >
> > OK, it is possible (even likely) that the issue you are seeing is
> configuring
> > with “arm64--darwinNN”.
> >
> > Although Apple has named the platform Arm64, the configuration used for
> OSS is
> > still “aarch64-apple-darwinNN”
> >
> > When I first began work on the port, I discussed this with the config
> script
> > maintainers, and the end result was that “aarch64-apple-darwinNN” had
> already
> > been adopted (and that was, shall we say, a “firm position” from their
> > perspective), so arm64-apple-darwinNN is not actually canonical.
> >
> > We do use “-arch arm64” in specs etc. that have to interface with system
> tools
> > (like ld etc); but elsewhere the port is ‘aarch64’.
> >
> > e.g.
> > $ ./config.sub arm64-apple-darwin21
> > 

Re: [PATCH] 6: Use GCC 13.2

[Joel Sherrill]

On Tue, Nov 21, 2023 at 5:29 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 12.09.23 08:43, Sebastian Huber wrote:
> >
> >
> > On 12.09.23 08:40, Chris Johns wrote:
> >> On 12/9/2023 4:31 pm, Sebastian Huber wrote:
> >>> On 27.07.23 13:33, Sebastian Huber wrote:
>  Prepare for RTEMS 6.1 release.
> 
>  Update #4921.
> >>> How do we want to proceed with the tools for the RTEMS 6.1 release?
> >> I need to move 6 to tar files but other tickets have taken what time I
> >> had.
> >
> > The patch uses a tar file for GCC. I guess for Newlib we have to host an
> > archive.
> >
> >>
> >>> Is GCC 13.2 still the desired GCC release?
> >> What is the alternative?
> >
> > Do we need one? GCC 13.2 is the best option from my point of view right
> > now.
>
> Can I check in the update to GCC 13.2?
>

Are there any test results to point to?

I'm generally ok if there are test results. But I didn't see any in the
build@ list

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

Re: [RSB 1/3] 6/7: Update Newlib

[Joel Sherrill]

Thanks.

Ask Kinsey some time the weird situation that caught this.

--joel

On Tue, Nov 21, 2023 at 3:05 PM Chris Johns  wrote:

> OK to all 3 and thanks
>
> Chris
>
> On 21/11/2023 11:39 pm, Sebastian Huber wrote:
> > Pick up fixes for ARM/optimized-routines and the memory reclamation at
> thread
> > exit.
> >
> > Update #4510.
> > Update #4967.
> > ---
> >  rtems/config/tools/rtems-gcc-10-newlib-head.cfg   | 4 ++--
> >  rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg | 4 ++--
> >  rtems/config/tools/rtems-gcc-12-newlib-head.cfg   | 4 ++--
> >  rtems/config/tools/rtems-gcc-13-newlib-head.cfg   | 4 ++--
> >  rtems/config/tools/rtems-gcc-13.2-newlib-head.cfg | 4 ++--
> >  rtems/config/tools/rtems-gcc-head-newlib-head.cfg | 4 ++--
> >  6 files changed, 12 insertions(+), 12 deletions(-)
> >
> > diff --git a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> > index 6668bc6..387e8c9 100644
> > --- a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> > +++ b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> > @@ -14,12 +14,12 @@
> >  %patch add gcc -p1
> https://devel.rtems.org/raw-attachment/ticket/4215/0001-nios2-Remove-custom-instruction-warnings.patch
> >  %hash sha512 0001-nios2-Remove-custom-instruction-warnings.patch
> afd8a5e6bdcc5b75d5fbbf558bdf56ccac400521a6eec9d88cc95f6be67c481f2dbf8faa0f6ddc1e4ac7c56a84938714d80e46e9cf80ec4b8fcd739986449881
> >
> > -%define newlib_version fbc5496
> > +%define newlib_version 3cacedb
> >  %define newlib_external 1
> >  %define newlib_expand_name
> sourceware-mirror-newlib-cygwin-%{newlib_version}
> >  %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz
> https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
> >  %hash sha512 newlib-%{newlib_version}.tar.gz \
> > -
> AFwyCjHHXfddx/lUcJbmcxSFOYtfj8cshzthqF9B2OtZxxxN/NQ8O+znhUPKDv20KjOBEMGh4VHpoiFBjZOrmA==
> > +
> ia0ce+bdENUO3qYj00jrZB8FjSejmTWuRqEdNE8nI2llf30mh8leUn5fCoHB0Oa7rRVBjEu3n0F12ZK9skuegQ==
> >
> >  %define with_threads 1
> >  %define with_plugin 0
> > diff --git a/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
> b/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
> > index dae3d2a..b37af1e 100644
> > --- a/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
> > +++ b/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
> > @@ -17,12 +17,12 @@
> >  %patch add gcc -p1
> https://devel.rtems.org/raw-attachment/ticket/4215/0001-nios2-Remove-custom-instruction-warnings.patch
> >  %hash sha512 0001-nios2-Remove-custom-instruction-warnings.patch
> afd8a5e6bdcc5b75d5fbbf558bdf56ccac400521a6eec9d88cc95f6be67c481f2dbf8faa0f6ddc1e4ac7c56a84938714d80e46e9cf80ec4b8fcd739986449881
> >
> > -%define newlib_version fbc5496
> > +%define newlib_version 3cacedb
> >  %define newlib_external 1
> >  %define newlib_expand_name
> sourceware-mirror-newlib-cygwin-%{newlib_version}
> >  %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz
> https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
> >  %hash sha512 newlib-%{newlib_version}.tar.gz \
> > -
> AFwyCjHHXfddx/lUcJbmcxSFOYtfj8cshzthqF9B2OtZxxxN/NQ8O+znhUPKDv20KjOBEMGh4VHpoiFBjZOrmA==
> > +
> ia0ce+bdENUO3qYj00jrZB8FjSejmTWuRqEdNE8nI2llf30mh8leUn5fCoHB0Oa7rRVBjEu3n0F12ZK9skuegQ==
> >
> >  %define with_threads 1
> >  %define with_plugin 0
> > diff --git a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> > index 9fe1ddd..4a0c6d1 100644
> > --- a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> > +++ b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> > @@ -34,13 +34,13 @@
> >
> KEmxHjYOqY4LTXCMZ3I60tbHusbR5GlnP0CLARHPAnhCnovDj9K3U43C1bsMxDDGRqD6fwtrEFoEgqVFX63IuQ==
> >  # Comment above related to #4657 and patches ends here
> >
> > -%define newlib_version fbc5496
> > +%define newlib_version 3cacedb
> >  %define newlib_external 1
> >  %define newlib_expand_name
> sourceware-mirror-newlib-cygwin-%{newlib_version}
> >  %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz \
> >
> https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
> >  %hash sha512 newlib-%{newlib_version}.tar.gz \
> > -
> AFwyCjHHXfddx/lUcJbmcxSFOYtfj8cshzthqF9B2OtZxxxN/NQ8O+znhUPKDv20KjOBEMGh4VHpoiFBjZOrmA==
> > +
> ia0ce+bdENUO3qYj00jrZB8FjSejmTWuRqEdNE8nI2llf30mh8leUn5fCoHB0Oa7rRVBjEu3n0F12ZK9skuegQ==
> >
> >  %define with_threads 1
> >  %define with_plugin 0
> > diff --git a/rtems/config/tools/rtems-gcc-13-newlib-head.cfg
> b/rtems/config/tools/rtems-gcc-13-newlib-head.cfg
> > index 7d5f610..5529563 100644
> > --- a/rtems/config/tools/rtems-gcc-13-newlib-head.cfg
> > +++ b/rtems/config/tools/rtems-gcc-13-newlib-head.cfg
> > @@ -8,12 +8,12 @@
> >  %hash sha512 %{gcc_expand_name}.tar.gz \
> >
> nKBXN9Qt/9CRYDVOp1geQdshXDP/kvr82RV1fE1LVIxNCbAVvhRmqz1p5kycg24T3TNGHPN58RySceaYgc6sCw==
> >
> > -%define newlib_version fbc5496
> > +%define newlib_version 3cacedb
> >  %define 

Re: [PATCH rtems v2] once.c, onceimplh.h: Make synchronization variable volatile

[Joel Sherrill]

Thanks. I will pass this along and resubmit a patch to at least add a
comment and fix formatting issues.

Do we have a good place to add this information to the documentation?

On Tue, Nov 21, 2023, 5:35 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 20.11.23 18:42, Joel Sherrill wrote:
> > The loop that waits for another thread to complete the once
> > initialization was flagged as a potential infinite loop.
> > This is because there was no way to break out of the loop
> > inside the loop.  The solution is to make the state variable
> > volatile which indicates it may be modified by another thread
> > of execution.
> >
> > This was flagged by a user Coverity Scan run which apparently is
> > configured differently from the instance provided by Coverity to
> > open source projects.
>
> This is a configuration issue of Coverity Scan. You have to teach
> Coverity Scan something about:
>
> _Atomic_Fence( ATOMIC_ORDER_ACQUIRE );
> _Atomic_Fence( ATOMIC_ORDER_RELEASE );
>
> rtems_mutex_lock();
> rtems_condition_variable_wait();
> rtems_mutex_unlock();
>
> Using "volatile" for multi-threaded synchronization is not correct in
> C11 or later. This keyword is for device access. For multi-threaded
> synchronization you need atomic operations or mutexes, etc. From my
> point of view, Coverity Scan should warn if you use volatile for
> multi-threaded synchronization.
>
> --
> 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

Coverity Scan Runs are Down

[Joel Sherrill]

Hi

I got a message from the last Coverity Scan run that I need to update the
Scan tool used to run them.

With this being a short week (US Thanksgiving), I don't know if I will get
to it in the next couple of days.

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

Re: [PATCH rtems-source-builder] rtems-mipstx39-gdb-head.bset: Add missing file

[Joel Sherrill]

Pushed.

Thanks.

On Sun, Nov 19, 2023 at 5:44 PM Chris Johns  wrote:

> Looks good and thanks
>
> Chris
>
> On 18/11/2023 5:11 am, Joel Sherrill wrote:
> > This configuration file was missing for the mipstx39 gdb build for the
> > head/7 tools.
> >
> > Closes #4935.
> > ---
> >  rtems/config/tools/rtems-mipstx39-gdb-head.bset | 7 +++
> >  1 file changed, 7 insertions(+)
> >  create mode 100644 rtems/config/tools/rtems-mipstx39-gdb-head.bset
> >
> > diff --git a/rtems/config/tools/rtems-mipstx39-gdb-head.bset
> b/rtems/config/tools/rtems-mipstx39-gdb-head.bset
> > new file mode 100644
> > index 000..252967c
> > --- /dev/null
> > +++ b/rtems/config/tools/rtems-mipstx39-gdb-head.bset
> > @@ -0,0 +1,7 @@
> > +%define release 1
> > +%define rtems_arch mips
> > +%define gdb-sim-options --enable-sim-hardware
> > +%define win32-gdb-disable-sim
> > +%define _target mipstx39-rtems%{rtems_version}
> > +devel/gmp-6.2.1
> > +tools//rtems-gdb-head
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH rtems v2] once.c, onceimplh.h: Make synchronization variable volatile

[Joel Sherrill]

The loop that waits for another thread to complete the once
initialization was flagged as a potential infinite loop.
This is because there was no way to break out of the loop
inside the loop.  The solution is to make the state variable
volatile which indicates it may be modified by another thread
of execution.

This was flagged by a user Coverity Scan run which apparently is
configured differently from the instance provided by Coverity to
open source projects.
---
 cpukit/include/rtems/score/onceimpl.h |  8 ++--
 cpukit/score/src/once.c   | 13 -
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/cpukit/include/rtems/score/onceimpl.h 
b/cpukit/include/rtems/score/onceimpl.h
index 9552cc0a67..5c716ce40a 100644
--- a/cpukit/include/rtems/score/onceimpl.h
+++ b/cpukit/include/rtems/score/onceimpl.h
@@ -64,11 +64,15 @@ extern "C" {
  * Once_Information_Mutex.
  *
  * @param once_state The once state.
- * @param init_routine The initialization routine called if @a once_state is 
ONCE_STATE_INIT.
+ * @param init_routine The initialization routine called if @a once_state
+ * is ONCE_STATE_INIT.
  *
  * @return This method always returns zero upon termination.
  */
-int _Once( unsigned char *once_state, void ( *init_routine )( void ) );
+int _Once(
+  volatile unsigned char   *once_state,
+  void   ( *init_routine )( void )
+);
 
 /** @} */
 
diff --git a/cpukit/score/src/once.c b/cpukit/score/src/once.c
index a395197c3a..10a5c4fee6 100644
--- a/cpukit/score/src/once.c
+++ b/cpukit/score/src/once.c
@@ -75,7 +75,10 @@ static void _Once_Unlock( Thread_Life_state 
thread_life_state )
   _Thread_Set_life_protection( thread_life_state );
 }
 
-int _Once( unsigned char *once_state, void ( *init_routine )( void ) )
+int _Once(
+  volatile unsigned char   *once_state,
+  void   ( *init_routine )( void )
+)
 {
   _Atomic_Fence( ATOMIC_ORDER_ACQUIRE );
 
@@ -93,6 +96,14 @@ int _Once( unsigned char *once_state, void ( *init_routine 
)( void ) )
   *once_state = ONCE_STATE_COMPLETE;
   rtems_condition_variable_broadcast( &_Once_Information.State );
 } else {
+  /*
+   * This is flagged as an infinite loop by at least Coverity. It is
+   * not an infinite loop because *once_state is set by another
+   * thread. This loop is used when a second thread concurrently
+   * attempts to process a once variable while it is in the process
+   * of being initialized.  The second and subsequent threads block
+   * until the broadcast above is executed.
+   */
   while ( *once_state != ONCE_STATE_COMPLETE ) {
 rtems_condition_variable_wait(
   &_Once_Information.State,
-- 
2.31.1

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

[PATCH rtems-source-builder] rtems-mipstx39-gdb-head.bset: Add missing file

[Joel Sherrill]

This configuration file was missing for the mipstx39 gdb build for the
head/7 tools.

Closes #4935.
---
 rtems/config/tools/rtems-mipstx39-gdb-head.bset | 7 +++
 1 file changed, 7 insertions(+)
 create mode 100644 rtems/config/tools/rtems-mipstx39-gdb-head.bset

diff --git a/rtems/config/tools/rtems-mipstx39-gdb-head.bset 
b/rtems/config/tools/rtems-mipstx39-gdb-head.bset
new file mode 100644
index 000..252967c
--- /dev/null
+++ b/rtems/config/tools/rtems-mipstx39-gdb-head.bset
@@ -0,0 +1,7 @@
+%define release 1
+%define rtems_arch mips
+%define gdb-sim-options --enable-sim-hardware
+%define win32-gdb-disable-sim
+%define _target mipstx39-rtems%{rtems_version}
+devel/gmp-6.2.1
+tools//rtems-gdb-head
-- 
2.31.1

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

Re: [PATCH] build: Do not use coverage for librtemstest

[Joel Sherrill]

Ok. Push this.

On Fri, Nov 3, 2023, 9:19 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 03.11.23 14:56, Joel Sherrill wrote:
> > Does this mean that anything under tests and bsps will not have coverage?
>
> The tests itself are built without coverage. The librtemsbsp.a stuff is
> built with coverage enabled.
>
> --
> 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] build: Do not use coverage for librtemstest

[Joel Sherrill]

Seems reasonable.

Does this mean that anything under tests and bsps will not have coverage?

--joel

On Fri, Nov 3, 2023 at 3:58 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> The goal is to get code and branch coverage from actual tests and not
> the test support itself.
> ---
>  spec/build/cpukit/grp.yml | 2 --
>  spec/build/cpukit/libdebugger.yml | 6 --
>  spec/build/cpukit/libftpfs.yml| 6 --
>  spec/build/cpukit/libjffs2.yml| 4 +++-
>  spec/build/cpukit/libmghttpd.yml  | 6 --
>  spec/build/cpukit/librtemscpu.yml | 6 --
>  spec/build/cpukit/librtemscxx.yml | 4 +++-
>  spec/build/cpukit/librtemsdfltcfg.yml | 6 --
>  spec/build/cpukit/libtelnetd.yml  | 6 --
>  spec/build/cpukit/libtftpfs.yml   | 6 --
>  spec/build/cpukit/libz.yml| 6 --
>  11 files changed, 38 insertions(+), 20 deletions(-)
>
> diff --git a/spec/build/cpukit/grp.yml b/spec/build/cpukit/grp.yml
> index e07e975d7d..7cd1f80ee7 100644
> --- a/spec/build/cpukit/grp.yml
> +++ b/spec/build/cpukit/grp.yml
> @@ -2,13 +2,11 @@ SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>  build-type: group
>  cflags:
>  - ${CPUKIT_OPTIMIZATION_FLAGS}
> -- ${COVERAGE_COMPILER_FLAGS}
>  copyrights:
>  - Copyright (C) 2020 embedded brains GmbH & Co. KG
>  cppflags: []
>  cxxflags:
>  - ${CPUKIT_OPTIMIZATION_FLAGS}
> -- ${COVERAGE_COMPILER_FLAGS}
>  enabled-by: true
>  includes: []
>  install: []
> diff --git a/spec/build/cpukit/libdebugger.yml
> b/spec/build/cpukit/libdebugger.yml
> index 3075ca1f9a..bc9db7b8d6 100644
> --- a/spec/build/cpukit/libdebugger.yml
> +++ b/spec/build/cpukit/libdebugger.yml
> @@ -1,10 +1,12 @@
>  SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>  build-type: library
> -cflags: []
> +cflags:
> +- ${COVERAGE_COMPILER_FLAGS}
>  copyrights:
>  - Copyright (C) 2020 embedded brains GmbH & Co. KG
>  cppflags: []
> -cxxflags: []
> +cxxflags:
> +- ${COVERAGE_COMPILER_FLAGS}
>  enabled-by: BUILD_LIBDEBUGGER
>  includes: []
>  install: []
> diff --git a/spec/build/cpukit/libftpfs.yml
> b/spec/build/cpukit/libftpfs.yml
> index 4dc6b8c651..cc9b9f7980 100644
> --- a/spec/build/cpukit/libftpfs.yml
> +++ b/spec/build/cpukit/libftpfs.yml
> @@ -1,10 +1,12 @@
>  SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>  build-type: library
> -cflags: []
> +cflags:
> +- ${COVERAGE_COMPILER_FLAGS}
>  copyrights:
>  - Copyright (C) 2020 embedded brains GmbH & Co. KG
>  cppflags: []
> -cxxflags: []
> +cxxflags:
> +- ${COVERAGE_COMPILER_FLAGS}
>  enabled-by: true
>  includes: []
>  install:
> diff --git a/spec/build/cpukit/libjffs2.yml
> b/spec/build/cpukit/libjffs2.yml
> index 4fec670f92..f7c74d8f21 100644
> --- a/spec/build/cpukit/libjffs2.yml
> +++ b/spec/build/cpukit/libjffs2.yml
> @@ -1,11 +1,13 @@
>  SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>  build-type: library
>  cflags:
> +- ${COVERAGE_COMPILER_FLAGS}
>  - -Wno-pointer-sign
>  copyrights:
>  - Copyright (C) 2020 embedded brains GmbH & Co. KG
>  cppflags: []
> -cxxflags: []
> +cxxflags:
> +- ${COVERAGE_COMPILER_FLAGS}
>  enabled-by: true
>  includes:
>  - cpukit/libfs/src/jffs2/include
> diff --git a/spec/build/cpukit/libmghttpd.yml
> b/spec/build/cpukit/libmghttpd.yml
> index 71dbbab974..c6cbe0a8be 100644
> --- a/spec/build/cpukit/libmghttpd.yml
> +++ b/spec/build/cpukit/libmghttpd.yml
> @@ -1,10 +1,12 @@
>  SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>  build-type: library
> -cflags: []
> +cflags:
> +- ${COVERAGE_COMPILER_FLAGS}
>  copyrights:
>  - Copyright (C) 2020 embedded brains GmbH & Co. KG
>  cppflags: []
> -cxxflags: []
> +cxxflags:
> +- ${COVERAGE_COMPILER_FLAGS}
>  enabled-by: true
>  includes: []
>  install:
> diff --git a/spec/build/cpukit/librtemscpu.yml
> b/spec/build/cpukit/librtemscpu.yml
> index 7a58a91299..9202c31715 100644
> --- a/spec/build/cpukit/librtemscpu.yml
> +++ b/spec/build/cpukit/librtemscpu.yml
> @@ -1,10 +1,12 @@
>  SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>  build-type: library
> -cflags: []
> +cflags:
> +- ${COVERAGE_COMPILER_FLAGS}
>  copyrights:
>  - Copyright (C) 2020 embedded brains GmbH & Co. KG
>  cppflags: []
> -cxxflags: []
> +cxxflags:
> +- ${COVERAGE_COMPILER_FLAGS}
>  enabled-by: true
>  includes: []
>  install:
> diff --git a/spec/build/cpukit/librtemscxx.yml
> b/spec/build/cpukit/librtemscxx.yml
> index 3803963470..97d65a1599 100644
> --- a/spec/build/cpukit/librtemscxx.yml
> +++ b/spec/build/cpukit/librtemscxx.yml
> @@ -1,10 +1,12 @@
>  SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>  build-type: library
> -cflags: []
> +cflags:
> +- ${COVERAGE_COMPILER_FLAGS}
>  copyrights:
>  - Copyright (C) 2020 Chris Johns (http://contemporary.software)
>  cppflags: []
>  cxxflags:
> +- ${COVERAGE_COMPILER_FLAGS}
>  - -std=c++17
>  enabled-by: true
>  includes: []
> diff --git a/spec/build/cpukit/librtemsdfltcfg.yml
> b/spec/build/cpukit/librtemsdfltcfg.yml
> index 3a77aa145d..2d5722fa2c 100644
> 

Re: [PATCH] libtest: Move parts to extra files

[Joel Sherrill]

Seems ok.

On Fri, Nov 3, 2023 at 3:58 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Move the RTEMS test printer and rtems_test_exit() to separate files, to
> remove dependencies from the begin/end test messsage support.
>
> Update #4963.
> ---
>  cpukit/libtest/testbeginend.c  | 28 -
>  cpukit/libtest/testexit.c  | 47 ++
>  cpukit/libtest/testprinter.c   | 63 ++
>  spec/build/cpukit/librtemstest.yml |  2 +
>  4 files changed, 112 insertions(+), 28 deletions(-)
>  create mode 100644 cpukit/libtest/testexit.c
>  create mode 100644 cpukit/libtest/testprinter.c
>
> diff --git a/cpukit/libtest/testbeginend.c b/cpukit/libtest/testbeginend.c
> index eca8712b35..d520a45e62 100644
> --- a/cpukit/libtest/testbeginend.c
> +++ b/cpukit/libtest/testbeginend.c
> @@ -42,13 +42,8 @@
>
>  #include 
>  #include 
> -#include 
>  #include 
>
> -rtems_printer rtems_test_printer = {
> -  .printer = rtems_printk_printer
> -};
> -
>  static const char* const test_state_strings[] =
>  {
>"EXPECTED_PASS",
> @@ -102,26 +97,3 @@ int rtems_test_end(const char* name)
>  "\n*** END OF TEST %s ***\n\n", name
>);
>  }
> -
> -void rtems_test_exit(int status)
> -{
> -  (void) status;
> -  rtems_shutdown_executive(0);
> -}
> -
> -int rtems_test_printf(
> -  const char* format,
> -  ...
> -)
> -{
> -  va_list ap;
> -  int len;
> -  va_start(ap, format);
> -  len = rtems_vprintf(
> -_test_printer,
> -format,
> -ap
> -  );
> -  va_end(ap);
> -  return len;
> -}
> diff --git a/cpukit/libtest/testexit.c b/cpukit/libtest/testexit.c
> new file mode 100644
> index 00..89f0dc341a
> --- /dev/null
> +++ b/cpukit/libtest/testexit.c
> @@ -0,0 +1,47 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @ingroup RTEMSTestFrameworkImpl
> + *
> + * @brief This source file contains the implementation of
> + *   rtems_test_exit().
> + */
> +
> +/*
> + * Copyright (c) 2017 Chris Johns . All rights
> reserved.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> "AS IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
> THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
> BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
> THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +
> +#include 
> +
> +void rtems_test_exit(int status)
> +{
> +  (void) status;
> +  rtems_shutdown_executive(0);
> +}
> diff --git a/cpukit/libtest/testprinter.c b/cpukit/libtest/testprinter.c
> new file mode 100644
> index 00..b2b782bf4b
> --- /dev/null
> +++ b/cpukit/libtest/testprinter.c
> @@ -0,0 +1,63 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @ingroup RTEMSTestFrameworkImpl
> + *
> + * @brief This source file contains the definition of
> ::rtems_test_printer and
> + *   the implementation of rtems_test_printf().
> + */
> +
> +/*
> + * Copyright (c) 2017 Chris Johns . All rights
> reserved.
> + *
> + * 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 

Re: [PATCH] testsuites/unit: Add tests for compiler builtins

[Joel Sherrill]

I noted a few cases where I don't think the value used is interesting
enough or an edge case. Hopefully I caught them all.

On Thu, Nov 2, 2023 at 7:12 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Test more compiler builtins which may use integer library routins:
>

routines.

>
> https://gcc.gnu.org/onlinedocs/gccint/Integer-library-routines.html
>
> Update #3716.
> ---
>  testsuites/unit/tc-compiler-builtins.c | 377 -
>  1 file changed, 369 insertions(+), 8 deletions(-)
>
> diff --git a/testsuites/unit/tc-compiler-builtins.c
> b/testsuites/unit/tc-compiler-builtins.c
> index 13a9c4a248..4bf8570eb0 100644
> --- a/testsuites/unit/tc-compiler-builtins.c
> +++ b/testsuites/unit/tc-compiler-builtins.c
> @@ -78,6 +78,39 @@
>   *
>   * - Check the return value of __builtin_ctz() for a sample set of inputs.
>   *
> + * - Check the return value of __builtin_ctzll() for a sample set of
> inputs.
> + *
> + * - Check the return value of __builtin_ffs() for a sample set of inputs.
> + *
> + * - Check the return value of __builtin_ffsll() for a sample set of
> inputs.
> + *
> + * - Check the return value of __builtin_parity() for a sample set of
> inputs.
> + *
> + * - Check the return value of __builtin_parityll() for a sample set of
> inputs.
> + *
> + * - Check the return value of __builtin_popcount() for a sample set of
> inputs.
> + *
> + * - Check the return value of __builtin_popcountll() for a sample set of
> + *   inputs.
> + *
> + * - Check the return value of __builtin_bswap32() for a sample set of
> inputs.
> + *
> + * - Check the return value of __builtin_bswap64() for a sample set of
> inputs.
> + *
> + * - Check signed 64-bit comparisons for a sample set of values.
> + *
> + * - Check unsigned 64-bit comparisons for a sample set of values.
> + *
> + * - Check signed 64-bit arithmetic left shift for a sample set of values.
> + *
> + * - Check signed 64-bit arithmetic right shift for a sample set of
> values.
> + *
> + * - Check unsigned 64-bit logical right shift for a sample set of values.
> + *
> + * - Check signed 64-bit multiplication for a sample set of values.
> + *
> + * - Check signed 64-bit negation for a sample set of values.
> + *
>   * - Check signed 64-bit divisions for a sample set of values.
>   *
>   * - Check unsigned 64-bit divisions for a sample set of values.
> @@ -180,22 +213,334 @@ static void CompilerUnitBuiltins_Action_1( void )
>   */
>  static void CompilerUnitBuiltins_Action_2( void )
>  {
> -  volatile int n;
> +  volatile unsigned int n;
>
> -  n = 1;
> +  n = 1U;
>T_eq_int( __builtin_ctz( n ), 0 );
>
> -  n = 1 << 31;
> +  n = 1U << 31;
>T_eq_int( __builtin_ctz( n ), 31 );
>
> -  n = ~0;
> +  n = ~0U;
>T_eq_int( __builtin_ctz( n ), 0 );
>  }
>
>  /**
> - * @brief Check signed 64-bit divisions for a sample set of values.
> + * @brief Check the return value of __builtin_ctzll() for a sample set of
> + *   inputs.
>   */
>  static void CompilerUnitBuiltins_Action_3( void )
> +{
> +  volatile unsigned long long n;
> +
> +  n = 1ULL;
> +  T_eq_int( __builtin_ctzll( n ), 0 );
> +
> +  n = 1ULL << 31;
> +  T_eq_int( __builtin_ctzll( n ), 31 );
> +
> +  n = 1ULL << 32;
> +  T_eq_int( __builtin_ctzll( n ), 32 );
> +
> +  n = 1ULL << 63;
> +  T_eq_int( __builtin_ctzll( n ), 63 );
> +
> +  n = ~0ULL;
> +  T_eq_int( __builtin_ctzll( n ), 0 );
> +}
> +
> +/**
> + * @brief Check the return value of __builtin_ffs() for a sample set of
> inputs.
> + */
> +static void CompilerUnitBuiltins_Action_4( void )
> +{
> +  volatile unsigned int n;
> +
> +  n = 1U;
> +  T_eq_int( __builtin_ffs( n ), 1 );
> +
> +  n = 1U << 31;
> +  T_eq_int( __builtin_ffs( n ), 32 );
> +
> +  n = 0U;
> +  T_eq_int( __builtin_ffs( n ), 0 );
> +}
> +
> +/**
> + * @brief Check the return value of __builtin_ffsll() for a sample set of
> + *   inputs.
> + */
> +static void CompilerUnitBuiltins_Action_5( void )
> +{
> +  volatile unsigned long long n;
> +
> +  n = 1ULL;
> +  T_eq_int( __builtin_ffsll( n ), 1 );
> +
> +  n = 1ULL << 31;
> +  T_eq_int( __builtin_ffsll( n ), 32 );
> +
> +  n = 1ULL << 32;
> +  T_eq_int( __builtin_ffsll( n ), 33 );
> +
> +  n = 1ULL << 63;
> +  T_eq_int( __builtin_ffsll( n ), 64 );
> +
> +  n = 0ULL;
> +  T_eq_int( __builtin_ffsll( n ), 0 );
> +}
> +
> +/**
> + * @brief Check the return value of __builtin_parity() for a sample set of
> + *   inputs.
> + */
> +static void CompilerUnitBuiltins_Action_6( void )
> +{
> +  volatile unsigned int n;
> +
> +  n = 1U;
> +  T_eq_int( __builtin_parity( n ), 1 );
> +
> +  n = ~0U;
> +  T_eq_int( __builtin_parity( n ), 0 );
> +}
> +
> +/**
> + * @brief Check the return value of __builtin_parityll() for a sample set
> of
> + *   inputs.
> + */
> +static void CompilerUnitBuiltins_Action_7( void )
> +{
> +  volatile unsigned long long n;
> +
> +  n = 1ULL;
> +  T_eq_int( __builtin_parityll( n ), 1 );
> +
> +  n = ~0ULL;
> +  T_eq_int( __builtin_parityll( n ), 0 );
> +}
> +
> +/**
> + * @brief Check 

Re: [PATCH] doxygen: Replace and move main page

[Joel Sherrill]

Sorry. Not sure how this kept slipping through the cracks.  The 13
September ping did coincide with me being on a trip and then sick.

This is the only revision I see in my inbox. There is an email which says
"how about this version?" but I don't see anything on it.

A few comments inline.

On Fri, Jul 28, 2023 at 9:37 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Replace the main page with a high level description of the RTEMS feature
> set similar to:
>
> https://docs.rtems.org/branches/master/user/overview/index.html#features
>
> The replaced content can be found in the RTEMS Classic API Guide:
>
> https://docs.rtems.org/branches/master/c-user/overview.html
>
> https://docs.rtems.org/branches/master/c-user/key_concepts.html
>
> Update #3705.
> ---
> v2:
>
> * Add OAR copyright.
>
> * Move to cpukit/doxygen/mainpage.h
>
> * Not not install
>
>  cpukit/doxygen/mainpage.h | 204 ++
>  cpukit/include/rtems/rtems/mainpage.h | 951 --
>  spec/build/cpukit/librtemscpu.yml |   1 -
>  3 files changed, 204 insertions(+), 952 deletions(-)
>  create mode 100644 cpukit/doxygen/mainpage.h
>  delete mode 100644 cpukit/include/rtems/rtems/mainpage.h
>
> diff --git a/cpukit/doxygen/mainpage.h b/cpukit/doxygen/mainpage.h
> new file mode 100644
> index 00..ce341e0ffd
> --- /dev/null
> +++ b/cpukit/doxygen/mainpage.h
> @@ -0,0 +1,204 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @ingroup RTEMSImplDoxygen
> + *
> + * @brief This file exists to provide a top level description of RTEMS for
> + *   Doxygen.
> + */
> +
> +/*
> + * Copyright (C) 2021 embedded brains GmbH & Co. KG
> + * Copyright (C) 1989, 2014 On-Line Applications Research Corporation
> (OAR)
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> "AS IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
> THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
> BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
> THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +/**
> + * @mainpage
> + *
> + * The Real-Time Executive for Multiprocessor Systems (RTEMS) is a
> + * multi-threaded, single address-space, real-time operating system with
> no
> + * kernel-space/user-space separation.  It is capable to operate in an SMP
> + * configuration providing a state of the art feature set.
> + *
> + * RTEMS and all third-party software distributed with RTEMS which may be
> + * linked to the application is licensed under permissive open source
> licenses.
> + * This means that the licenses do not properagate to the application
> software.
>

properagate -> propagate


> + * Most of the original RTEMS code is now under the [BSD 2-Clause
> + * license](https://git.rtems.org/rtems/tree/LICENSE.BSD-2-Clause).
> Legacy
>

GPLv2 does not imply legacy. Some code in RTEMS is under a legacy license.


> + * code of RTEMS is under a [modified GPL 2.0 or later license with an
> + * exception for static linking](https://git.rtems.org/rtems/tree/LICENSE
> >).
> + * It exposes no license requirements on application code.  Everything
> + * necessary to build RTEMS applications is available as open source
> software.
> + * This makes you completely vendor independent.
> + *
> + * RTEMS provides the following basic feature set:
> + *
> + * - @ref RTEMSAPI
> + *
> + * - POSIX with
> + *   [pthreads](
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/pthread.h.html)
> + *   (enables a broad range of standard software to run on RTEMS)
> + *
> + * - @ref RTEMSAPIClassic
> + *
> + * - C11 (including
> + *   [thread](https://en.cppreference.com/w/c/thread) support)
> + *
> + * - C++11 (including
> + *   [thread](https://en.cppreference.com/w/cpp/thread>) support)
> + *
> + * - Newlib and GCC internal
> + *
> + * - Programming languages
> + *
> + * - 

Re: [RSB 1/3] 6/7: Update Newlib

[Joel Sherrill]

What caused all the recently posted tool build failures?

On Mon, Oct 9, 2023, 4:52 PM Chris Johns  wrote:

> Ok to all patches in the series. Thanks for newlib changes for ARM, they
> will be
> nice to use.
>
> Chris
>
> On 10/10/2023 3:58 am, Sebastian Huber wrote:
> > Pick up latest changes from ARM/optimized-routines.
> >
> > Close 4510.
> > ---
> >  rtems/config/tools/rtems-gcc-10-newlib-head.cfg   | 4 ++--
> >  rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg | 4 ++--
> >  rtems/config/tools/rtems-gcc-12-newlib-head.cfg   | 4 ++--
> >  rtems/config/tools/rtems-gcc-13-newlib-head.cfg   | 4 ++--
> >  rtems/config/tools/rtems-gcc-head-newlib-head.cfg | 4 ++--
> >  5 files changed, 10 insertions(+), 10 deletions(-)
> >
> > diff --git a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> > index 1cbb301..06524d4 100644
> > --- a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> > +++ b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> > @@ -17,12 +17,12 @@
> >  %patch add newlib -p1
> https://devel.rtems.org/raw-attachment/ticket/4510/0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch
> >  %hash sha512 0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch
> 7ca237eabfd5b382713186e1fc290dfc999a353315795ecb8dd0d22fcd1ab7f5bf31f4329954adab91ad04c100dcac0e86d406fdbce8f82cf9dc23842c88caf6
> >
> > -%define newlib_version a021448
> > +%define newlib_version fe5886a
> >  %define newlib_external 1
> >  %define newlib_expand_name
> sourceware-mirror-newlib-cygwin-%{newlib_version}
> >  %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz
> https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
> >  %hash sha512 newlib-%{newlib_version}.tar.gz \
> > -
> YiC/BsmRpq8XsN1hx4s2Rvcwys/4DRFB3F6vvd+lEMJWXXpt3knXT4BBZkP11bkEcpDFCV9EaOlTT3HA7C3pCg==
> > +
> w7yxW6iO3ademyF5TTj0pe9zt6WCsYa46+MOY/Rter2loQjJDEnj2AE0YxUhV4fGG+mE/Df3igJH3rzuQYeXwQ==
> >
> >  %define with_threads 1
> >  %define with_plugin 0
> > diff --git a/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
> b/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
> > index 99e2a21..e457b75 100644
> > --- a/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
> > +++ b/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
> > @@ -20,12 +20,12 @@
> >  %patch add newlib -p1
> https://devel.rtems.org/raw-attachment/ticket/4510/0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch
> >  %hash sha512 0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch
> 7ca237eabfd5b382713186e1fc290dfc999a353315795ecb8dd0d22fcd1ab7f5bf31f4329954adab91ad04c100dcac0e86d406fdbce8f82cf9dc23842c88caf6
> >
> > -%define newlib_version a021448
> > +%define newlib_version fe5886a
> >  %define newlib_external 1
> >  %define newlib_expand_name
> sourceware-mirror-newlib-cygwin-%{newlib_version}
> >  %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz
> https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
> >  %hash sha512 newlib-%{newlib_version}.tar.gz \
> > -
> YiC/BsmRpq8XsN1hx4s2Rvcwys/4DRFB3F6vvd+lEMJWXXpt3knXT4BBZkP11bkEcpDFCV9EaOlTT3HA7C3pCg==
> > +
> w7yxW6iO3ademyF5TTj0pe9zt6WCsYa46+MOY/Rter2loQjJDEnj2AE0YxUhV4fGG+mE/Df3igJH3rzuQYeXwQ==
> >
> >  %define with_threads 1
> >  %define with_plugin 0
> > diff --git a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> > index 04616eb..75dfcb2 100644
> > --- a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> > +++ b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> > @@ -38,13 +38,13 @@
> >
> KEmxHjYOqY4LTXCMZ3I60tbHusbR5GlnP0CLARHPAnhCnovDj9K3U43C1bsMxDDGRqD6fwtrEFoEgqVFX63IuQ==
> >  # Comment above related to #4657 and patches ends here
> >
> > -%define newlib_version a021448
> > +%define newlib_version fe5886a
> >  %define newlib_external 1
> >  %define newlib_expand_name
> sourceware-mirror-newlib-cygwin-%{newlib_version}
> >  %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz \
> >
> https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
> >  %hash sha512 newlib-%{newlib_version}.tar.gz \
> > -
> YiC/BsmRpq8XsN1hx4s2Rvcwys/4DRFB3F6vvd+lEMJWXXpt3knXT4BBZkP11bkEcpDFCV9EaOlTT3HA7C3pCg==
> > +
> w7yxW6iO3ademyF5TTj0pe9zt6WCsYa46+MOY/Rter2loQjJDEnj2AE0YxUhV4fGG+mE/Df3igJH3rzuQYeXwQ==
> >
> >  %define with_threads 1
> >  %define with_plugin 0
> > diff --git a/rtems/config/tools/rtems-gcc-13-newlib-head.cfg
> b/rtems/config/tools/rtems-gcc-13-newlib-head.cfg
> > index 03b99da..7f7e3e2 100644
> > --- a/rtems/config/tools/rtems-gcc-13-newlib-head.cfg
> > +++ b/rtems/config/tools/rtems-gcc-13-newlib-head.cfg
> > @@ -8,12 +8,12 @@
> >  %hash sha512 %{gcc_expand_name}.tar.gz \
> >
> 7uw8yZWdjboqa1k1KPJTsOutVN66EEdrQ+ylaxZCFIwOihRUrct1loZ2Y3LXCYPG9JFso0i+22XEIlx3WMlrTQ==
> >
> > -%define newlib_version a021448
> > +%define newlib_version fe5886a
> >  %define newlib_external 1
> >  %define newlib_expand_name
> 

Re: ADA, gnat, rtems 6, ubuntu 22LTS

[Joel Sherrill]

Random thought. Is there a gnat1? Can you build a native Ada hello world?

I'm not sure what that configure check is trying but looking at that is the
next step.

On Wed, Oct 4, 2023, 12:02 PM emanuel stiebler  wrote:

> I just tried to compile the tools for rtems6,
> and just with "C", everything(?) works.
>
> Trying to add ADA to the tools, it fails, complaining about gnat not
> being installed.
> In the logfile:
>
> hecking for objdir... .libs
> configure: WARNING: using in-tree isl, disabling version check
> configure: error: GNAT is required to build ada
> shell cmd failed: /bin/sh -ex
>
> /AD1/PUB/RTEMS.work/rsb/rtems/build/aarch64-rtems6-gcc-506cb58-newlib-a021448-x86_64-linux-gnu-1/do-build
> error: building
> aarch64-rtems6-gcc-506cb58-newlib-a021448-x86_64-linux-gnu-1emu@W531:/AD1/PUB/RTEMS.work/rsb/rtems$
>
>
>
>
> but "gnat" gives me:
>
> DDD@W531:/AD1/PUB/RTEMS.work/rsb/rtems$ gnat
> GNAT 12.3.0
> Copyright 1996-2022, Free Software Foundation, Inc.
>
> To list Ada build switches use --help-ada
>
> List of available commands
>
> gnat bind   x86_64-linux-gnu-gnatbind-12
> gnat chop   x86_64-linux-gnu-gnatchop-12
> gnat clean  x86_64-linux-gnu-gnatclean-12
> gnat compilex86_64-linux-gnu-gnatmake-12 -f -u -c
> gnat check  x86_64-linux-gnu-gnatcheck-12
> gnat elim   x86_64-linux-gnu-gnatelim-12
> gnat find   x86_64-linux-gnu-gnatfind-12
> gnat krunch x86_64-linux-gnu-gnatkr-12
> gnat link   x86_64-linux-gnu-gnatlink-12
> gnat list   x86_64-linux-gnu-gnatls-12
> gnat make   x86_64-linux-gnu-gnatmake-12
> gnat metric x86_64-linux-gnu-gnatmetric-12
> gnat name   x86_64-linux-gnu-gnatname-12
> gnat preprocess x86_64-linux-gnu-gnatprep-12
> gnat pretty x86_64-linux-gnu-gnatpp-12
> gnat stack  x86_64-linux-gnu-gnatstack-12
> gnat stub   x86_64-linux-gnu-gnatstub-12
> gnat test   x86_64-linux-gnu-gnattest-12
> gnat xref   x86_64-linux-gnu-gnatxref-12
>
>
> Report bugs to rep...@adacore.com
>
> What am I missing?
> (GIT version of yesterday ...)
>
> Cheers & Thanks
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH rtems] fat_fat_operations.c: Fix incorrect indentation

[Joel Sherrill]

---
 cpukit/libfs/src/dosfs/fat_fat_operations.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/cpukit/libfs/src/dosfs/fat_fat_operations.c 
b/cpukit/libfs/src/dosfs/fat_fat_operations.c
index 24a408f9c7..1d94beb26a 100644
--- a/cpukit/libfs/src/dosfs/fat_fat_operations.c
+++ b/cpukit/libfs/src/dosfs/fat_fat_operations.c
@@ -203,9 +203,9 @@ fat_free_fat_clusters_chain(
 cur_cln = next_cln;
 }
 
-fs_info->vol.next_cl = chain;
-if (fs_info->vol.free_cls != FAT_UNDEFINED_VALUE)
-fs_info->vol.free_cls += freed_cls_cnt;
+fs_info->vol.next_cl = chain;
+if (fs_info->vol.free_cls != FAT_UNDEFINED_VALUE)
+fs_info->vol.free_cls += freed_cls_cnt;
 
 fat_buf_release(fs_info);
 if (rc1 != RC_OK)
-- 
2.31.1

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

Visit to Sunnyvale 11-13 October

[Joel Sherrill]

Hi

Vijay and I will be attending the Google Summer of Code Mentor Summit the
weekend of October 14-15. We are planning to fly out a bit early to give us
a chance to schedule visits with RTEMS users, see your project in action as
a site visit, and just have the opportunity to talk about your
successes and challenges with RTEMS.

I will have a car and in past years have went as far as Berkley. Dinner is
also an option for some nights.

As a virtual community, we rarely get to cross paths IRL. If this works for
you, please let me and Vijay know so we can plan accordingly.

FWIW I am traveling some again and will be happy to have dinner, site
visit, etc. if I end up where you are or if you end up in Huntsville.

Thanks.

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

Re: [rtems commit] libdl: Add support to import base image TLS symbols

[Joel Sherrill]

On Thu, Sep 14, 2023 at 4:33 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
>
> On 14.09.23 10:51, Chris Johns wrote:
> > On 14/9/2023 5:58 pm, Sebastian Huber wrote:
> >> On 14.09.23 09:38, Chris Johns wrote:
> > The issue I faced was no score interface to get the TLS base for a
> thread to
> > determine a symbol's offset. If we had that and something to say if
> TLS is
> > supported libdl would be easy to fix.
>  Why don't we add this interface if it simplifies things?
> >>> Yes please, that would be good. I do not know the TSL support well
> enough to do
> >>> a decent job of it.
> >> Which interface do you need?
> > A define that says TLS is support for an arch?
> >
> > A call that returns the base address for an arch? I have added some in
> libdl:
> >
> > https://git.rtems.org/rtems/tree/cpukit/libdl/rtl-tls.c
> >
> > however having this in score would mean a new arch does not break libdl.
>
> Yes, this should be definitely added to the CPU port. What is the
> purpose of rtems_rtl_tls_get_base()? It seems to be unused.
>

MIPS does not have TLS support. GCC generates a specific illegal
instruction and the exception handler does the right thing.

Is there a way to tell GCC to use a function call? That would be
much easier across all the secondary architectures.

--joel

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

Re: [PATCH 1/1] rtems-tools: stty rename / spelling bug.

[Joel Sherrill]

Thanks Sam. This is now committed.

--joel

On Mon, Sep 11, 2023 at 10:35 AM Sam Price  wrote:

> This patch fixes a spelling/rename mistake in rtems-tools.
>
> ---
>  tester/rt/stty.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tester/rt/stty.py b/tester/rt/stty.py
> index 130318d..fca026a 100644
> --- a/tester/rt/stty.py
> +++ b/tester/rt/stty.py
> @@ -558,7 +558,7 @@ class tty(object):
>  self._update()
>
>  def read(self):
> -return self.fs.read()
> +return self.fd.read()
>
>  if __name__ == "__main__":
>  if len(sys.argv) == 2:
> --
> 2.25.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: [rtems-tools PATCH] rtemstoolkit: Fix shell execution

[Joel Sherrill]

A bit more feedback. I got this failure on CentOS 7 building sparc-rtems6
tools.

+ cd rtems-tools-3ea0c249346fda427bf0d3c169aa3e7c2a521df8
+ ./waf distclean configure --prefix=/home/joel/rtems-work/tools/6
'distclean' finished successfully (0.001s)
Setting top to   :
/home/joel/rtems-work/rtems-source-builder/rtems/build/rtems-tools-3ea0c249346fda427bf0d3c169aa3e7c2a521df8-1/rtems-tools-3ea0c249346fda427bf0d3c169aa3e7c2a521df8

Setting out to   :
/home/joel/rtems-work/rtems-source-builder/rtems/build/rtems-tools-3ea0c249346fda427bf0d3c169aa3e7c2a521df8-1/rtems-tools-3ea0c249346fda427bf0d3c169aa3e7c2a521df8/build

invalid version file: 'module' object has no attribute 'join'
(complete log in
/home/joel/rtems-work/rtems-source-builder/rtems/build/rtems-tools-3ea0c249346fda427bf0d3c169aa3e7c2a521df8-1/rtems-tools-3ea0c249346fda427bf0d3c169aa3e7c2a521df8/build/config.log)
shell cmd failed: /bin/sh -ex
 
/home/joel/rtems-work/rtems-source-builder/rtems/build/rtems-tools-3ea0c249346fda427bf0d3c169aa3e7c2a521df8-1/do-build
error: building rtems-tools-3ea0c249346fda427bf0d3c169aa3e7c2a521df8-1

I tried the same target on Rocky 9 and did not get this error.

I loaded the software collection for Python 3.6 on CentOS 7 and got this:

+ ./waf distclean configure --prefix=/home/joel/rtems-work/tools/6
'distclean' finished successfully (0.001s)
Setting top to   :
/home/joel/rtems-work/rtems-source-builder/rtems/build/rtems-tools-3ea0c249346fda427bf0d3c169aa3e7c2a521df8-1/rtems-tools-3ea0c249346fda427bf0d3c169aa3e7c2a521df8

Setting out to   :
/home/joel/rtems-work/rtems-source-builder/rtems/build/rtems-tools-3ea0c249346fda427bf0d3c169aa3e7c2a521df8-1/rtems-tools-3ea0c249346fda427bf0d3c169aa3e7c2a521df8/build

invalid version file: module 'shlex' has no attribute 'join'

Not sure what the common factor on all this is.

--joel

On Tue, Aug 29, 2023 at 8:23 AM Joel Sherrill  wrote:

>
>
> On Tue, Aug 29, 2023 at 5:48 AM Frank Kühndel <
> frank.kuehn...@embedded-brains.de> wrote:
>
>> Hello Chris,
>>
>> On 8/29/23 12:45, Chris Johns wrote:
>> >> On 29 Aug 2023, at 6:24 pm, Frank Kühndel<
>> frank.kuehn...@embedded-brains.de>  wrote:
>> >>
>> >> Hello Chris,
>> >>
>> >> our continuous integration server found an issues with this patch
>> >> ("module 'shlex' has no attribute 'join'"):
>> > Frank, thanks for the post and the insight. I saw the build break in
>> Joel’s build but I could not see the reason. This will help.
>> >
>> > I will look into this tomorrow. Sorry for the breakage.
>>
>> No problem at all. I am happy I could help.
>>
>
> FYI I see some overnight CentOS 7 failures for rtems6 tools also. This
> looks like the same issue:
>
> https://lists.rtems.org/pipermail/build/2023-August/048307.html
>
> --joel
>
>>
>> Have a good night
>> Frank
>>
>> --
>> embedded brains GmbH & Co. KG
>> Herr Frank KÜHNDEL
>> Dornierstr. 4
>> 82178 Puchheim
>> Germany
>> email: frank.kuehn...@embedded-brains.de
>> phone:  +49-89-18 94 741 - 23
>> mobile: +49-176-15 22 06 - 11
>>
>> Registergericht: Amtsgericht München
>> Registernummer: HRA 117265
>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>> Unsere Datenschutzerklärung finden Sie hier:
>> https://embedded-brains.de/datenschutzerklaerung/
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems-tools PATCH] rtemstoolkit: Fix shell execution

[Joel Sherrill]

On Tue, Aug 29, 2023 at 5:48 AM Frank Kühndel <
frank.kuehn...@embedded-brains.de> wrote:

> Hello Chris,
>
> On 8/29/23 12:45, Chris Johns wrote:
> >> On 29 Aug 2023, at 6:24 pm, Frank Kühndel<
> frank.kuehn...@embedded-brains.de>  wrote:
> >>
> >> Hello Chris,
> >>
> >> our continuous integration server found an issues with this patch
> >> ("module 'shlex' has no attribute 'join'"):
> > Frank, thanks for the post and the insight. I saw the build break in
> Joel’s build but I could not see the reason. This will help.
> >
> > I will look into this tomorrow. Sorry for the breakage.
>
> No problem at all. I am happy I could help.
>

FYI I see some overnight CentOS 7 failures for rtems6 tools also. This
looks like the same issue:

https://lists.rtems.org/pipermail/build/2023-August/048307.html

--joel

>
> Have a good night
> Frank
>
> --
> embedded brains GmbH & Co. KG
> Herr Frank KÜHNDEL
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: frank.kuehn...@embedded-brains.de
> phone:  +49-89-18 94 741 - 23
> mobile: +49-176-15 22 06 - 11
>
> Registergericht: Amtsgericht München
> Registernummer: HRA 117265
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [RSB PATCH] rtems/tools: Shell execute fixes

[Joel Sherrill]

Looks ok to push

On Mon, Aug 28, 2023, 9:14 PM  wrote:

> From: Chris Johns 
>
> Updates #4951
> ---
>  rtems/config/tools/rtems-tools-6.cfg | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/rtems/config/tools/rtems-tools-6.cfg
> b/rtems/config/tools/rtems-tools-6.cfg
> index 6eed755..b360f7e 100644
> --- a/rtems/config/tools/rtems-tools-6.cfg
> +++ b/rtems/config/tools/rtems-tools-6.cfg
> @@ -10,14 +10,14 @@
>   %define rtems_tools_source rtems-tools-%{rtems_tools_version}
>   %define rtems_tools_ext xz
>  %else
> - %define rtems_tools_version 349bbd96543365e830e5ef5e851765e4b742a8a4
> + %define rtems_tools_version 3ea0c249346fda427bf0d3c169aa3e7c2a521df8
>   %define rtems_tools_ext bz2
>  %endif
>
>  %define rtems_tools_source rtems-tools-%{rtems_tools_version}
>  %source set rtems-tools
> https://git.rtems.org/rtems-tools/snapshot/%{rtems_tools_source}.tar.%{rtems_tools_ext}
>  %hash   sha512 rtems-tools-%{rtems_tools_version}.tar.bz2 \
> -
>  
> qb5EC4gWfahYLPliYk+mNRsgzaDuouqiRq6GURb8v0Pk4J6Uo6IiKrB6dPvqVPO+wh9Omb1xCs+86W/+fj8sZg==
> +
>  
> +wrMxGHJp5cd/hpgoGwTH65IvwZQsAWOb8JNmDZKdFqUbhUuUYq1zK1p5NJnvCUkHudxgDmghAe/5kaFE5DJ4w==
>
>  #
>  # Optionally enable/disable building the RTEMS Tools via the command line.
> --
> 2.37.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: (libdl) Fwd: New Defects reported by Coverity Scan for RTEMS

[Joel Sherrill]

Done.

On Mon, Aug 21, 2023 at 8:57 PM Chris Johns  wrote:

> On 22/8/2023 10:02 am, Gedare Bloom wrote:
> > flag it as a false positive.
>
> I agree.
>
> > g7 is a global register that is reserved for system / compiler use in
> > the sparc ABI
>
> The reigster is set up by the operating system out of the view of
> Coverity. I
> took the code from:
>
>
> https://git.rtems.org/rtems/tree/cpukit/score/cpu/sparc/include/rtems/score/cpuimpl.h#n242
>
> Chris
>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: (libdl) Fwd: New Defects reported by Coverity Scan for RTEMS

[Joel Sherrill]

Moving it back to devel@.

It appears to be from this bit of magic in the same file which implements
it using a direct reference to register g7.

#elif defined(__sparc__)
#include 
# define __get_tls() ({ void** __val; register uintptr_t g7 __asm__( "g7"
); __val = (void**) g7; __val; })

I honestly don't know how to tell Coverity or GCC that this is reading a
register we trust.


On Mon, Aug 21, 2023 at 2:58 PM Chris Johns  wrote:

> Hi
>
> It is code from somewhere else so sorry I have no idea.
>
> Chris
>
> On 21 Aug 2023, at 11:33 pm, Joel Sherrill  wrote:
>
> 
> Unitialized variable issue from Coverity in libdl
>
> -- Forwarded message -
> From: 
> Date: Mon, Aug 21, 2023 at 12:33 AM
> Subject: New Defects reported by Coverity Scan for RTEMS
> To: 
>
>
> Hi,
>
> Please find the latest report on new defect(s) introduced to RTEMS found
> with Coverity Scan.
>
> 1 new defect(s) introduced to RTEMS found with Coverity Scan.
>
>
> New defect(s) Reported-by: Coverity Scan
> Showing 1 of 1 defect(s)
>
>
> ** CID 1541150:  Memory - illegal accesses  (UNINIT)
> /cpukit/libdl/rtl-tls.c: 111 in rtems_rtl_tls_get_base()
>
>
>
> 
> *** CID 1541150:  Memory - illegal accesses  (UNINIT)
> /cpukit/libdl/rtl-tls.c: 111 in rtems_rtl_tls_get_base()
> 105 #endif
> 106
> 107 #if defined(__get_tls)
> 108
> 109 void* rtems_rtl_tls_get_base (void)
> 110 {
> >>> CID 1541150:  Memory - illegal accesses  (UNINIT)
> >>> Using uninitialized value "g7".
> 111   return (void*) __get_tls();
> 112 }
> 113
>
>
>
> 
> To view the defects in Coverity Scan visit,
> https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50ypUUzi-2FdSNmuyRB7BEFT8xQ4-2B8hpujh0hTgQljRGId4Dg-3D-3Deeiw_EU3W9teASMK00lBXX9WT4lsogDrkCcNZLvg-2FVxwAXMqJ0gdhGGumG7Gy0Tn5Dw3PQUbh2-2BNMdpxfdtJmNYuHO3QG97iSLio7uY7m4yyhwWxZmfc2p4Yk5m-2B2JQ7-2FNr1n2P8EvOyfDnsHe5-2FCDlZpmVnHhGqVY9mLjZbQG-2FJIE3w3MlGbiKwQw8j63a169WP32Wpts1j8m1uekKxkyIv1KA-3D-3D
>
> ___
> build mailing list
> bu...@rtems.org
> http://lists.rtems.org/mailman/listinfo/build
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH rtems v1 10/10] x86_64/include/rtems/score/cpuimpl.h: Address unused parameter warning

[Joel Sherrill]

---
 .../score/cpu/x86_64/include/rtems/score/cpuimpl.h | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/cpukit/score/cpu/x86_64/include/rtems/score/cpuimpl.h 
b/cpukit/score/cpu/x86_64/include/rtems/score/cpuimpl.h
index e0e301b6bc..726a515d4e 100644
--- a/cpukit/score/cpu/x86_64/include/rtems/score/cpuimpl.h
+++ b/cpukit/score/cpu/x86_64/include/rtems/score/cpuimpl.h
@@ -44,21 +44,25 @@ RTEMS_NO_RETURN void _CPU_Fatal_halt( uint32_t source, 
CPU_Uint32ptr error );
 
 static inline void _CPU_Context_volatile_clobber( uintptr_t pattern )
 {
-  /* TODO */
-}
+  (void) pattern;
 
-static inline void _CPU_Instruction_illegal( void )
-{
-  __asm__ volatile ( ".word 0" );
+  /* TODO */
 }
 
 static inline void _CPU_Context_validate( uintptr_t pattern )
 {
+  (void) pattern;
+
   while (1) {
 /* TODO */
   }
 }
 
+static inline void _CPU_Instruction_illegal( void )
+{
+  __asm__ volatile ( ".word 0" );
+}
+
 static inline void _CPU_Instruction_no_operation( void )
 {
   __asm__ volatile ( "nop" );
-- 
2.31.1

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