Re: Add Formal Verification chapter v4

[Gedare Bloom]

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

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

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

Re: Add Formal Verification chapter v4

[Gedare Bloom]

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

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

Re: Add Formal Verification chapter v4

[Gedare Bloom]

Thanks, I left comments on your pull request.

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

Re: bsps/xilinx-zynqmp : Add BSP for RPU

[Gedare Bloom]

By separating this from the zynqmp bsp, there should be some
modification of the naming conventions to specify rpu--unless they
will share the code files identically. I guess that decision must be
made. These files should not be duplicated in the tree simultaneously,
as they introduce name clashes that (even if compilable) can be
confusing to follow through the source code.

a few more comments below

On Thu, Jun 29, 2023 at 10:37 AM Philip Kirkpatrick
 wrote:
>
> Took a while to get to but here is a new patch incorporating the feedback.
>
> Sorry to drop this and run but I'm on vacation for a week as soon as I send 
> this.  So don't expect to see responses from me until July 10th or later.
>
> Once I'm back and this is through, expect to see some follow-on patches for 
> enabling MPU, cache, and lwip support.  I have that working and tested but it 
> needs some cleanup before I'll feel good about a patch.
>
> ---
>
> diff --git a/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c 
> b/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
> new file mode 100644
> index 00..469178fd86
> --- /dev/null
> +++ b/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
> @@ -0,0 +1,128 @@
> +/*
> + * SPDX-License-Identifier: BSD-2-Clause
> + *
> + * Copyright (C) 2013, 2017 embedded brains GmbH
> + *
> + * Copyright (C) 2019 DornerWorks
> + *
> + * Written by Jeff Kubascik 
> + *and Josh Whitehead 
> + *
> + * 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.
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#include 
> +
> +static zynq_uart_context zynqmp_uart_instances[2] = {
> +  {
> +.base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER( "Zynq UART 0" ),
> +.regs = (volatile struct zynq_uart *) 0xff00,
> +.irq = ZYNQMP_IRQ_UART_0
> +  }, {
> +.base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER( "Zynq UART 1" ),
> +.regs = (volatile struct zynq_uart *) 0xff01,
> +.irq = ZYNQMP_IRQ_UART_1
> +  }
> +};
> +
> +rtems_status_code console_initialize(
> +  rtems_device_major_number major,
> +  rtems_device_minor_number minor,
> +  void *arg
> +)
> +{
> +  size_t i;
> +
> +  for (i = 0; i < RTEMS_ARRAY_SIZE(zynqmp_uart_instances); ++i) {
> +char uart[] = "/dev/ttySX";
> +
> +uart[sizeof(uart) - 2] = (char) ('0' + i);
> +rtems_termios_device_install(
> +  [0],
> +  _uart_handler,
> +  NULL,
> +  _uart_instances[i].base
> +);
> +
> +if (i == BSP_CONSOLE_MINOR) {
> +  link([0], CONSOLE_DEVICE_NAME);
> +}
> +  }
> +
> +  return RTEMS_SUCCESSFUL;
> +}
> +
> +void zynqmp_debug_console_flush(void)
> +{
> +  zynq_uart_reset_tx_flush(_uart_instances[BSP_CONSOLE_MINOR]);
> +}
> +
> +static void zynqmp_debug_console_out(char c)
> +{
> +  rtems_termios_device_context *base =
> +_uart_instances[BSP_CONSOLE_MINOR].base;
> +
> +  zynq_uart_write_polled(base, c);
> +}
> +
> +static void zynqmp_debug_console_init(void)
> +{
> +  rtems_termios_device_context *base =
> +_uart_instances[BSP_CONSOLE_MINOR].base;
> +
> +  zynq_uart_initialize(base);
> +  BSP_output_char = zynqmp_debug_console_out;
> +}
> +
> +static void zynqmp_debug_console_early_init(char c)
> +{
> +  rtems_termios_device_context *base =
> +_uart_instances[BSP_CONSOLE_MINOR].base;
> +
> +  zynq_uart_initialize(base);
> +  zynqmp_debug_console_out(c);
> +}
> +
> +static int zynqmp_debug_console_in(void)
> +{
> +  rtems_termios_device_context *base =
> +_uart_instances[BSP_CONSOLE_MINOR].base;
> +
> +  return zynq_uart_read_polled(base);
> +}
> +
> +BSP_output_char_function_type BSP_output_char = 
> zynqmp_debug_console_early_init;
> +
> 

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

[Gedare Bloom]

flag it as a false positive.

g7 is a global register that is reserved for system / compiler use in
the sparc ABI

On Mon, Aug 21, 2023 at 2:17 PM Joel Sherrill  wrote:
>
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] libdl: Add support to import base image TLS symbols

[Gedare Bloom]

ok

On Wed, Aug 16, 2023 at 9:00 PM  wrote:
>
> From: Chris Johns 
>
> This change requires an rtems-tools update for symbol generation.
>
> Working architectures:
>  - aarch64
>  - arm
>  - powerpc
>  - sparc
>
> No newlib TLS support but checked:
>  - i386
>  - m69k
>
> Updates #4920
> ---
>  cpukit/include/rtems/rtl/rtl-sym.h |  26 -
>  cpukit/include/rtems/rtl/rtl.h |   8 +-
>  cpukit/libdl/rtl-elf.c |  20 +++-
>  cpukit/libdl/rtl-mdreloc-aarch64.c |   6 +-
>  cpukit/libdl/rtl-mdreloc-arm.c |   3 +-
>  cpukit/libdl/rtl-mdreloc-powerpc.c |  18 +++-
>  cpukit/libdl/rtl-mdreloc-sparc.c   | 154 -
>  cpukit/libdl/rtl-sym.c |  40 ++--
>  cpukit/libdl/rtl-tls.c | 114 +
>  cpukit/libdl/rtl-tls.h |  51 ++
>  cpukit/libdl/rtl.c |   8 +-
>  spec/build/cpukit/objdl.yml|   1 +
>  testsuites/libtests/dl11/dl-load.c |  27 -
>  13 files changed, 418 insertions(+), 58 deletions(-)
>  create mode 100644 cpukit/libdl/rtl-tls.c
>  create mode 100644 cpukit/libdl/rtl-tls.h
>
> diff --git a/cpukit/include/rtems/rtl/rtl-sym.h 
> b/cpukit/include/rtems/rtl/rtl-sym.h
> index 0d29a6ae40..3502b303b8 100644
> --- a/cpukit/include/rtems/rtl/rtl-sym.h
> +++ b/cpukit/include/rtems/rtl/rtl-sym.h
> @@ -62,6 +62,22 @@ typedef struct rtems_rtl_symbols
>size_t   nbuckets;
>  } rtems_rtl_symbols;
>
> +/**
> + * A TLS variable offset call. There is one per base image TLS
> + * variable.
> + */
> +typedef size_t (*rtems_rtl_tls_offset_func)(void);
> +
> +/**
> + * A TLS symbol offset entry. It is used with an exported symbol table
> + * to find a TSL table offset for a variable at runtime.
> + */
> +typedef struct rtems_rtl_tls_offset
> +{
> +  size_tindex;  /** exported symbol table index */
> +  rtems_rtl_tls_offset_func offset; /** TLS offset function */
> +} rtems_rtl_tls_offset;
> +
>  /**
>   * Open a symbol table with the specified number of buckets.
>   *
> @@ -101,10 +117,14 @@ void rtems_rtl_symbol_table_close (rtems_rtl_symbols* 
> symbols);
>   * @param obj The object table the symbols are for.
>   * @param esyms The exported symbol table.
>   * @param size The size of the table in bytes.
> + * @param tls_offsets The TLS offsets table. If NULL none provided.
> + * @param tls_size The number TLS offset entries in the table.
>   */
> -bool rtems_rtl_symbol_global_add (rtems_rtl_obj*   obj,
> -  const unsigned char* esyms,
> -  unsigned int size);
> +bool rtems_rtl_symbol_global_add (rtems_rtl_obj*obj,
> +  const unsigned char*  esyms,
> +  unsigned int  size,
> +  rtems_rtl_tls_offset* tls_offsets,
> +  unsigned int  tls_size);
>
>  /**
>   * Find a symbol given the symbol label in the global symbol table.
> diff --git a/cpukit/include/rtems/rtl/rtl.h b/cpukit/include/rtems/rtl/rtl.h
> index 0fd4e74cdf..bd3dce588a 100644
> --- a/cpukit/include/rtems/rtl/rtl.h
> +++ b/cpukit/include/rtems/rtl/rtl.h
> @@ -393,9 +393,13 @@ bool rtems_rtl_path_prepend (const char* path);
>   *
>   * @param esyms The exported symbol table.
>   * @param count The size of the exported symbol table.
> + * @param tls_offsets The TLS offsets table. If NULL none provided.
> + * @param tls_size The number TLS offset entries in the table.
>   */
> -void rtems_rtl_base_sym_global_add (const unsigned char* esyms,
> -unsigned int count);
> +void rtems_rtl_base_sym_global_add (const unsigned char*  esyms,
> +unsigned int  count,
> +rtems_rtl_tls_offset* tls_offsets,
> +unsigned int  tls_size);
>
>  /**
>   * Return the object file descriptor for the base image. The object file
> diff --git a/cpukit/libdl/rtl-elf.c b/cpukit/libdl/rtl-elf.c
> index 5754070518..b46d2ac3a0 100644
> --- a/cpukit/libdl/rtl-elf.c
> +++ b/cpukit/libdl/rtl-elf.c
> @@ -178,12 +178,19 @@ rtems_rtl_elf_find_symbol (rtems_rtl_obj*  obj,
>
>/*
> * If the symbol type is STT_NOTYPE the symbol references a global
> -   * symbol. The gobal symbol table is searched to find it and that value
> +   * symbol. The global symbol table is searched to find it and that value
> * returned. If the symbol is local to the object module the section for 
> the
> * symbol is located and it's base added to the symbol's value giving an
> * absolute location.
> +   *
> +   * If the symbols type of TLS return the symbols value. It is the
> +   * offset from the thread's TLS area base. The offset is set by the
> +   * linker for the base image and by the TLS allocator for loaded
> +   * modules. There is no section and no 

Re: [rtems-tools PATCH] tester/sis: Use the RTEMS SIS command

[Gedare Bloom]

ok

On Wed, Aug 16, 2023 at 9:42 PM  wrote:
>
> From: Chris Johns 
>
> Make sis and sis-run the same as there is no SIS support in
> gdb anymore.
>
> Closes #4945
> ---
>  tester/rtems/testing/bsps/sis-run.ini | 2 +-
>  tester/rtems/testing/bsps/sis.ini | 6 ++
>  2 files changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/tester/rtems/testing/bsps/sis-run.ini 
> b/tester/rtems/testing/bsps/sis-run.ini
> index c34eae4..4861231 100644
> --- a/tester/rtems/testing/bsps/sis-run.ini
> +++ b/tester/rtems/testing/bsps/sis-run.ini
> @@ -35,4 +35,4 @@
>  bsp  = sis
>  arch = sparc
>  tester   = %{_rtscripts}/sis.cfg
> -bsp_run_opts = -a
> +bsp_run_opts =
> diff --git a/tester/rtems/testing/bsps/sis.ini 
> b/tester/rtems/testing/bsps/sis.ini
> index b5d700f..086cb45 100644
> --- a/tester/rtems/testing/bsps/sis.ini
> +++ b/tester/rtems/testing/bsps/sis.ini
> @@ -34,8 +34,6 @@
>  [sis]
>  bsp= sis
>  arch   = sparc
> -tester = %{_rtscripts}/gdb.cfg
> +tester = %{_rtscripts}/sis.cfg
>  gdb_script = bsp_gdb_script
> -bsp_gdb_script = target sim -a -nouartrx
> - load
> - run
> +bsp_run_opts =
> --
> 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: [PATCH rtems-tools v4] tester/rtemstoolkit: add renode implementation

[Gedare Bloom]

On Sun, Aug 6, 2023 at 11:05 PM Muhammad Sulthan Mazaya
 wrote:
>
> Add gpl to the prom binary file name + include the leon3 prom assembly
> source with licensing commented
>
> ---
>  .../testing/bsps/kendrytek210-renode.ini  |  38 
>  tester/rtems/testing/bsps/leon3-renode.ini|  37 
>  tester/rtems/testing/renode.cfg   |  64 ++
>  tester/rtems/testing/renode/kendrytek210.resc |  86 
>  tester/rtems/testing/renode/leon3-prom-gpl.S  | 205 ++
>  .../rtems/testing/renode/leon3-prom-gpl.bin   | Bin 0 -> 529 bytes
>  tester/rtems/testing/renode/leon3.resc|  82 +++
>  7 files changed, 512 insertions(+)
>  create mode 100644 tester/rtems/testing/bsps/kendrytek210-renode.ini
>  create mode 100644 tester/rtems/testing/bsps/leon3-renode.ini
>  create mode 100644 tester/rtems/testing/renode.cfg
>  create mode 100644 tester/rtems/testing/renode/kendrytek210.resc
>  create mode 100644 tester/rtems/testing/renode/leon3-prom-gpl.S
>  create mode 100755 tester/rtems/testing/renode/leon3-prom-gpl.bin
>  create mode 100644 tester/rtems/testing/renode/leon3.resc
>
> diff --git a/tester/rtems/testing/bsps/kendrytek210-renode.ini 
> b/tester/rtems/testing/bsps/kendrytek210-renode.ini
> new file mode 100644
> index 000..8f7f673
> --- /dev/null
> +++ b/tester/rtems/testing/bsps/kendrytek210-renode.ini
> @@ -0,0 +1,38 @@
> +#
> +# RTEMS Tools Project (http://www.rtems.org/)
> +# Copyright (C) 2023, 2023 Muhammad Sulthan Mazaya (msulthanmaz...@gmail.com)
> +# All rights reserved.
> +#
> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
> +#
> +# 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 HOLDER 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.
> +#
> +
> +#
> +# The Kendrytek210 Renode BSP
> +#
> +[kendrytek210-renode]
> +bsp = kendrytek210-renode
> +arch= riscv
> +tester  = %{_rtscripts}/renode.cfg
> +bsp_resc_script = %{_rtscripts}/renode_scripts/kendrytek210.resc
This file / directory doesn't exist. I think you mean renode/
If this works for you, I'm guessing you have a stale directory of
renode_scripts in your rtems-tools repo locally.

> diff --git a/tester/rtems/testing/bsps/leon3-renode.ini 
> b/tester/rtems/testing/bsps/leon3-renode.ini
> new file mode 100644
> index 000..d5f7c17
> --- /dev/null
> +++ b/tester/rtems/testing/bsps/leon3-renode.ini
> @@ -0,0 +1,37 @@
> +#
> +# RTEMS Tools Project (http://www.rtems.org/)
> +# Copyright (C) 2023, 2023 Muhammad Sulthan Mazaya (msulthanmaz...@gmail.com)
> +# All rights reserved.
> +#
> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
> +#
> +# 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 HOLDER 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 

Re: [PATCH rtems-tools v4] tester/rtemstoolkit: add renode implementation

[Gedare Bloom]

Daniel / Gaisler:

On Sun, Aug 6, 2023 at 11:05 PM Muhammad Sulthan Mazaya
 wrote:
>
> Add gpl to the prom binary file name + include the leon3 prom assembly
> source with licensing commented
>
> ---
>  .../testing/bsps/kendrytek210-renode.ini  |  38 
>  tester/rtems/testing/bsps/leon3-renode.ini|  37 
>  tester/rtems/testing/renode.cfg   |  64 ++
>  tester/rtems/testing/renode/kendrytek210.resc |  86 
>  tester/rtems/testing/renode/leon3-prom-gpl.S  | 205 ++
[...]
> diff --git a/tester/rtems/testing/renode/leon3-prom-gpl.S 
> b/tester/rtems/testing/renode/leon3-prom-gpl.S
> new file mode 100644
> index 000..91dc3bc
> --- /dev/null
> +++ b/tester/rtems/testing/renode/leon3-prom-gpl.S
> @@ -0,0 +1,205 @@
> +/*
> + * From 
> https://github.com/TUT-ASI/leon3-grlib-gpl-mirror/blob/master/software/leon3/prom.S
> + *
> + * GPL license, version unknown
> + */
> +

We have a GSoC student working this summer on integration of the
renode simulator. For running leon3, they found this mirrored version
of the GRLIB GPL release, and lifted the file ./software/leon3/prom.S.
I have pointed them to the appropriate location of your releases at
https://www.gaisler.com/index.php/downloads/leongrlib however since it
is just this one file with some runtime boot code, I was hoping that
you might be able to provide a 2-BSD or a GPLv2+linker exception
license for this file.

At the moment it is not such a problem because the file is only linked
for generating a boot img for testing on a simulator. But we would
prefer if we can keep the license compatible for user adoption.

> +/* Template boot-code for LEON3 test benches */
> +
> +#include "prom.h"
> +
> +#ifndef STACKSIZE
> +#define STACKSIZE 0x0002
> +#endif
> +
> +
> +   .seg"text"
> +   .proc   0
> +   .align  4
> +   .global start
> +start:
> +
> +   flush
> +   set 0x10e0, %g1 ! init IU
> +   mov %g1, %psr
> +   mov %g0, %wim
> +   mov %g0, %tbr
> +   mov %g0, %y
> +   mov %g0, %asr16
> +   nop
> +   set  0x81000f, %g1
> +   sta %g1, [%g0] 2
> +   mov %g0, %g2
> +   nop
> +   nop
> +   nop
> +   nop
> +   nop
> +   or %g2, %g2, %g0
> +   nop
> +   nop
> +   nop
> +   nop
> +   nop
> +#ifdef DSUADDR
> +   set DSUADDR, %g2
> +   st  %g0, [%g2]
> +   st  %g0, [%g2+0x08]
> +   st  %g0, [%g2+0x20]
> +   st  %g0, [%g2+0x24]
> +   st  %g0, [%g2+0x40]
> +   st  %g0, [%g2+0x44]
> +   st  %g0, [%g2+0x50]
> +   st  %g0, [%g2+0x54]
> +   st  %g0, [%g2+0x58]
> +   st  %g0, [%g2+0x5C]
> +   st  %g0, [%g2+0x54]
> +#endif
> +
> +2:
> +   mov %asr17, %g3
> +   and %g3, 0x1f, %g3
> +   mov %g0, %g4
> +   mov %g0, %g5
> +   mov %g0, %g6
> +   mov %g0, %g7
> +1:
> +   mov %g0, %l0
> +   mov %g0, %l1
> +   mov %g0, %l2
> +   mov %g0, %l3
> +   mov %g0, %l4
> +   mov %g0, %l5
> +   mov %g0, %l6
> +   mov %g0, %l7
> +   mov %g0, %o0
> +   mov %g0, %o1
> +   mov %g0, %o2
> +   mov %g0, %o3
> +   mov %g0, %o4
> +   mov %g0, %o5
> +   mov %g0, %o6
> +   mov %g0, %o7
> +   subcc %g3, 1, %g3
> +   bge 1b
> +   save
> +
> +   mov 2, %g1
> +   mov %g1, %wim
> +   set 0x10e0, %g1 ! enable traps
> +   mov %g1, %psr
> +   nop; nop; nop;
> +
> +   mov %psr, %g1
> +   srl %g1, 12, %g1
> +   andcc %g1, 1, %g0
> +   be 1f
> +   nop
> +
> +   set _fsrxx, %g3
> +   ld [%g3], %fsr
> +   ldd [%g3], %f0
> +   ldd [%g3], %f2
> +   ldd [%g3], %f4
> +   ldd [%g3], %f6
> +   ldd [%g3], %f8
> +   ldd [%g3], %f10
> +   ldd [%g3], %f12
> +   ldd [%g3], %f14
> +   ldd [%g3], %f16
> +   ldd [%g3], %f18
> +   ldd [%g3], %f20
> +   ldd [%g3], %f22
> +   ldd [%g3], %f24
> +   ldd [%g3], %f26
> +   ldd [%g3], %f28
> +   ldd [%g3], %f30
> +   nop
> +   nop
> +   nop
> +   nop
> +   nop
> +   faddd %f0, %f2, %f4
> +   nop
> +   nop
> +   nop
> +   nop
> +   ba  1f
> +   nop
> +
> +
> +.align 8
> +_fsrxx:
> +   .word 0
> +   .word 0
> +
> +1:
> +   mov %asr17, %g3
> +   srl %g3, 28, %g3
> +   andcc %g3, 0x0f, %g3
> +   bne 1f
> +nop
> +
> +#ifdef L2MCTRLIO
> +   set L2MCTRLIO, %g1
> +   set MCFG1, %g2
> +   st  %g2, [%g1]
> +   set MCFG2, %g2
> +   st  %g2, [%g1+4]
> +   set MCFG3, %g2
> +   st  %g2, [%g1+8]
> +#endif
> +!  set IRQCTRL, %g1
> +!  set 0x0, %g2
> +!  st  %g2, [%g1+0x10]
> +
> +#ifdef UARTADDR
> +set UARTADDR, %g1
> +st  %g0, [%g1+0xC]
> +set 3, %g2
> +st %g2,  [%g1+0x8]
> +#endif
> +
> +#ifdef DDR2CTRLIO
> +   set DDR2CTRLIO, %g1
> +   set DDR2CFG4, %g2
> + 

Re: Status of CAN API?

[Gedare Bloom]

Hi Phil,

On Wed, Aug 9, 2023 at 6:38 AM Philip Kirkpatrick
 wrote:
>
> Hello,
>
> Some people on our team here at Reflex are preparing to implement some CAN 
> drivers.  Specifically for TMS570 and for ZynqMP-RPU (side note my latest 
> patch for that on Jun 29th is still sitting there unreviewed).  I was 
> wondering what the current status of the CAN API is.
Feel free to ping the patch. At the moment, this email based system is
all we have, and sometimes patches may not get a lot of attention
especially if no one "owns" it -- such as new BSPs.

> I saw in August of last year and API was added and then last month was 
> reverted with this patch:
> https://lists.rtems.org/pipermail/devel/2023-July/076013.html
> The comment on the patch says the API isn't mature enough for release.  What 
> deficiencies need to be resolved in the API, is this being actively worked 
> on, and should we design against this API or is there a different API we 
> should target?
>
The implementation of that API was deficient. It did not support
multiple read/write transactions, it had a custom-built ring buffer
that was not fully vetted, and some other problems related to
threads+priorities. I expect to have some time to look at how to
provide better CAN support inside of RTEMS. This has been an ongoing
discussion I've been having with Pavel Pisa and others for many years
now (a decade?). The direction that I will prefer to go is to port
LinCAN
https://cmp.felk.cvut.cz/~pisa/can/doc/lincandoc-0.3.5.pdf

Both Pavel and I are interested in seeing this come through. So far,
we mostly do it on volunteer time or as side pieces of other work.
Pavel's group has good experience with CAN and CAN FD, and with both
TMS570 and the Zynq (non-MP) boards, with Linux, RTEMS, and NuttX. We
would be open to collaborating, subject to whatever time or resource
constraints everyone has :) Michal Lenc has been working on this topic
as a thesis, "CAN FD Support for Space Grade Real-Time RTEMS
Executive"

Regarding LinCAN itself, there is one design challenge to port it,
which has to do with the use of internal FIFOs already in LinCAN code
base, or to use RTEMS/POSIX message queue style to interface the CAN
drivers and userspace. I actually see there are good reasons to
support both ways, and may explore exactly that. We have had quite
some discussions here on the topic:
* https://lists.rtems.org/pipermail/devel/2023-March/074537.html
* https://lists.rtems.org/pipermail/devel/2022-April/071235.html
* https://lists.rtems.org/pipermail/devel/2013-April/030761.html (for
historical good measure)

Gedare

> Thank you,
> Phil
> ___
> 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] libdl: Add support to import base image TLS symbols

[Gedare Bloom]

On Mon, Aug 14, 2023 at 10:05 PM  wrote:
>
> From: Chris Johns 
>
> This change requires an rtems-tools update for symbol generation.
>
> Working architectures:
>  - aarch64
>  - arm
>  - powerpc
>  - sparc
>
> Updates #4920
> ---
>  cpukit/include/rtems/rtl/rtl-sym.h |  23 -
>  cpukit/include/rtems/rtl/rtl.h |   6 +-
>  cpukit/libdl/rtl-elf.c |  20 +++-
>  cpukit/libdl/rtl-mdreloc-aarch64.c |   6 +-
>  cpukit/libdl/rtl-mdreloc-arm.c |   3 +-
>  cpukit/libdl/rtl-mdreloc-powerpc.c |  18 +++-
>  cpukit/libdl/rtl-mdreloc-sparc.c   | 152 -
>  cpukit/libdl/rtl-sym.c |  36 ++-
>  cpukit/libdl/rtl-tls.c | 111 +
>  cpukit/libdl/rtl-tls.h |  51 ++
>  cpukit/libdl/rtl.c |   6 +-
>  spec/build/cpukit/objdl.yml|   1 +
>  testsuites/libtests/dl11/dl-load.c |  27 -
>  13 files changed, 408 insertions(+), 52 deletions(-)
>  create mode 100644 cpukit/libdl/rtl-tls.c
>  create mode 100644 cpukit/libdl/rtl-tls.h
>
> diff --git a/cpukit/include/rtems/rtl/rtl-sym.h 
> b/cpukit/include/rtems/rtl/rtl-sym.h
> index 0d29a6ae40..9eef9a1b7b 100644
> --- a/cpukit/include/rtems/rtl/rtl-sym.h
> +++ b/cpukit/include/rtems/rtl/rtl-sym.h
> @@ -62,6 +62,22 @@ typedef struct rtems_rtl_symbols
>size_t   nbuckets;
>  } rtems_rtl_symbols;
>
> +/**
> + * A TLS variable offset call. There is one per base image TLS
> + * variable.
> + */
> +typedef size_t (*rtems_tls_offset_func)(void);
> +
rtems_tls_xxx is a new naming prefix. Is this stuff only specific to
rtl? should be rtems_rtl_tls_...?

or, do we need to add a new tls header file and interface for this
stuff, in case it would be needed outside of the rtl?

> +/**
> + * A TLS symbol offset entry. It is used with an exported symbol table
> + * to find a TSL table offset for a variable at runtime.
s/TSL/TLS

> + */
> +typedef struct rtems_tls_offset
> +{
> +  size_tindex;  /** exported symbol table index */
> +  rtems_tls_offset_func offset; /** TLS offset function */
> +} rtems_tls_offset;
> +
>  /**
>   * Open a symbol table with the specified number of buckets.
>   *
> @@ -101,10 +117,15 @@ void rtems_rtl_symbol_table_close (rtems_rtl_symbols* 
> symbols);
>   * @param obj The object table the symbols are for.
>   * @param esyms The exported symbol table.
>   * @param size The size of the table in bytes.
> + * @param tls_offsets The TLS offsets table. If NULL none provided.
> + * @param tls_size The number TLS offset entries in the table..
two periods, "number of"

> +
extra blank line

>   */
>  bool rtems_rtl_symbol_global_add (rtems_rtl_obj*   obj,
>const unsigned char* esyms,
> -  unsigned int size);
> +  unsigned int size,
> +  rtems_tls_offset*tls_offsets,
> +  unsigned int tls_size);
>
>  /**
>   * Find a symbol given the symbol label in the global symbol table.
> diff --git a/cpukit/include/rtems/rtl/rtl.h b/cpukit/include/rtems/rtl/rtl.h
> index 0fd4e74cdf..aaaeb7b592 100644
> --- a/cpukit/include/rtems/rtl/rtl.h
> +++ b/cpukit/include/rtems/rtl/rtl.h
> @@ -393,9 +393,13 @@ bool rtems_rtl_path_prepend (const char* path);
>   *
>   * @param esyms The exported symbol table.
>   * @param count The size of the exported symbol table.
> + * @param tls_offsets The TLS offsets table. If NULL none provided.
> + * @param tls_size The number TLS offset entries in the table..
two periods

>   */
>  void rtems_rtl_base_sym_global_add (const unsigned char* esyms,
> -unsigned int count);
> +unsigned int count,
> +rtems_tls_offset*tls_offsets,
> +unsigned int tls_size);
>
>  /**
>   * Return the object file descriptor for the base image. The object file
> diff --git a/cpukit/libdl/rtl-elf.c b/cpukit/libdl/rtl-elf.c
> index 5754070518..b46d2ac3a0 100644
> --- a/cpukit/libdl/rtl-elf.c
> +++ b/cpukit/libdl/rtl-elf.c
> @@ -178,12 +178,19 @@ rtems_rtl_elf_find_symbol (rtems_rtl_obj*  obj,
>
>/*
> * If the symbol type is STT_NOTYPE the symbol references a global
> -   * symbol. The gobal symbol table is searched to find it and that value
> +   * symbol. The global symbol table is searched to find it and that value
> * returned. If the symbol is local to the object module the section for 
> the
> * symbol is located and it's base added to the symbol's value giving an
> * absolute location.
> +   *
> +   * If the symbols type of TLS return the symbols value. It is the
> +   * offset from the thread's TLS area base. The offset is set by the
> +   * linker for the base image and by the TLS allocator for loaded
> +   * modules. There is no 

Re: libdl support for base image TLS variables

[Gedare Bloom]

On Mon, Aug 14, 2023 at 10:05 PM  wrote:
>
> These patches add support to rtems.git and rtems-tools.git to
> provide access to TLS variables in the base from loaded code.
> The changes contain the ground work to resolving #4920 which is
> a blocker for the release of 6.
>
> This change is required due to the regression in libdl due to the
> change in newlib to use TLS variables for reneterant data.
>
> The rtems.git patch can be applied before the rtems-tools.git
> patch. If the tools are updated and the libdl code is not present
> the tests fail with linker errors. If the tools change is
> not present the test will link but it will continue to fail.
>
> The currently supported archs that build are:
>
>  - aarch64
>  - arm
>  - powerpc
>  - sparc
>
> The follow are to be completed and do not build:
>
>  - bfin
>  - i386
>  - lm32
>  - m68k
>  - mips
>  - moxie
>  - riscv
>  - v850
>
> We need to add support for these architectures if they support TLS.
>
We are deprecating v850. It might be worth considering whether some of
these other architectures should also be deprecated, especially if no
one is able/willing to add TLS for them.

> 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 0/3] Revert CAN API

[Gedare Bloom]

Thanks. I checked these in with one little change for a missed line in
a spec file.

On Thu, Jul 27, 2023 at 12:49 PM Joel Sherrill  wrote:
>
> OK to revert. I didn't catch that it was 3 commits to revert cleanly.
>
> On Thu, Jul 27, 2023 at 1:28 PM Gedare Bloom  wrote:
>>
>> The CAN API is not mature enough for a release. This patch set
>> reverts it. See #4803.
>>
>> I expect to revisit this during the 7 development cycle.
>>
>> Gedare Bloom (3):
>>   Revert "cpukit/dev/can: Resolve warnings in 64bit builds"
>>   Revert "build: Fix copyright statement format"
>>   Revert "cpukit/dev/can: Added CAN support"
>>
>>  cpukit/dev/can/can.c | 507 ---
>>  cpukit/include/dev/can/can-msg.h | 105 -
>>  cpukit/include/dev/can/can.h | 284 -
>>  cpukit/include/dev/can/canqueueimpl.h| 231 ---
>>  spec/build/cpukit/librtemscpu.yml|   5 -
>>  spec/build/testsuites/libtests/can01.yml |  20 -
>>  spec/build/testsuites/libtests/grp.yml   |   2 -
>>  testsuites/libtests/can01/can-loopback.c | 110 -
>>  testsuites/libtests/can01/init.c | 249 ---
>>  9 files changed, 1513 deletions(-)
>>  delete mode 100644 cpukit/dev/can/can.c
>>  delete mode 100644 cpukit/include/dev/can/can-msg.h
>>  delete mode 100644 cpukit/include/dev/can/can.h
>>  delete mode 100644 cpukit/include/dev/can/canqueueimpl.h
>>  delete mode 100644 spec/build/testsuites/libtests/can01.yml
>>  delete mode 100644 testsuites/libtests/can01/can-loopback.c
>>  delete mode 100644 testsuites/libtests/can01/init.c
>>
>> --
>> 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 2/3] Revert "build: Fix copyright statement format"

[Gedare Bloom]

I'm just reverting this so I can delete the file cleanly in patch 3/3.

On Thu, Jul 27, 2023 at 12:29 PM Joel Sherrill  wrote:
>
> Ok. Are there others like this?
>
> On Thu, Jul 27, 2023, 1:28 PM Gedare Bloom  wrote:
>>
>> This reverts commit 5b124432e27dd91f66f71464b586cc369e15ec99.
>> ---
>>  spec/build/testsuites/libtests/can01.yml | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/spec/build/testsuites/libtests/can01.yml 
>> b/spec/build/testsuites/libtests/can01.yml
>> index 7597b1fffd..b5c1e1ae5c 100644
>> --- a/spec/build/testsuites/libtests/can01.yml
>> +++ b/spec/build/testsuites/libtests/can01.yml
>> @@ -2,7 +2,7 @@ SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>>  build-type: test-program
>>  cflags: []
>>  copyrights:
>> -- Copyright (C) 2022 Prashanth S (fishesprasha...@gmail.com).
>> +- Copyright (c) 2022 Prashanth S (fishesprasha...@gmail.com).
>>  cppflags: []
>>  cxxflags: []
>>  enabled-by: true
>> --
>> 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: Pushing to 6.1

[Gedare Bloom]

I'm bumping the tickets related to non-functional changes (style,
copyright line / URLs, and third party tracking) until 7. I'd rather
not hold up the release on their account, although I'm getting close
it will take awhile yet to get everything in good order.

On Thu, Jul 27, 2023 at 11:56 AM Joel Sherrill  wrote:
>
> Hi
>
> The number of tickets is unfortunately not declining as I would like. This is 
> in spite of us actually closing some previous tickets.
>
> + 32 in progress
> + 10 new
>
> I do not know if the milestone for any of these can be changed but we need to 
> work on this.
>
> Please look through the tickets and see if you can resolve any or think it 
> should not be included as a blocker for 6.1. It could be moved to 6.2, 7.1, 
> or indefinite.
>
> Resolution is better than bumping the milestone.
>
> We need to get this out. It has been "almost ready" for probably over a year 
> now.
>
> Please and thank you.
>
> --joel
> ___
> 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 1/3] Revert "cpukit/dev/can: Resolve warnings in 64bit builds"

[Gedare Bloom]

This reverts commit 4c0a2d47e1dce0923f270d0206d0cb93d0d58451.
---
 cpukit/dev/can/can.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/cpukit/dev/can/can.c b/cpukit/dev/can/can.c
index 9f3fe0db98..2e6d5df65b 100644
--- a/cpukit/dev/can/can.c
+++ b/cpukit/dev/can/can.c
@@ -34,7 +34,6 @@
  * POSSIBILITY OF SUCH DAMAGE.
  */
 
-#include 
 #include 
 #include 
 
@@ -58,13 +57,13 @@
real_can_interrupt_lock_release(bus);  \
  } while (0);
 
-static int
+static ssize_t 
 can_bus_open(rtems_libio_t *iop, const char *path, int oflag, mode_t mode);
 static ssize_t 
 can_bus_read(rtems_libio_t *iop, void *buffer, size_t count);
 static ssize_t 
 can_bus_write(rtems_libio_t *iop, const void *buffer, size_t count);
-static int
+static ssize_t 
 can_bus_ioctl(rtems_libio_t *iop, ioctl_command_t request, void *buffer);
 
 static int can_xmit(struct can_bus *bus);
@@ -180,7 +179,7 @@ static int try_sem(struct can_bus *bus)
   return ret;
 }
 
-static int
+static ssize_t 
 can_bus_open(rtems_libio_t *iop, const char *path, int oflag, mode_t mode)
 {
   CAN_DEBUG("can_bus_open\n");
@@ -211,8 +210,7 @@ static ssize_t can_bus_read(rtems_libio_t *iop, void 
*buffer, size_t count)
   len = CAN_MSG_LEN(>can_rx_msg);
 
   if (count < len) {
-CAN_DEBUG("can_bus_read: buffer size is small min "
-  "sizeof(struct can_msg) = %" PRIuPTR "\n",
+CAN_DEBUG("can_bus_read: buffer size is small min sizeof(struct can_msg) = 
%u\n",
 sizeof(struct can_msg));
 return -RTEMS_INVALID_SIZE;
   }
@@ -316,8 +314,8 @@ can_bus_write(rtems_libio_t *iop, const void *buffer, 
size_t count)
 
   CAN_DEBUG_TX("can_bus_write: can_msg_size = %u\n", msg_size);
   if (msg_size > sizeof(struct can_msg)) {
-CAN_ERR("can_bus_write: can message "
-"len error msg_size = %u struct can_msg = %" PRIxPTR "\n",
+CAN_ERR("can_bus_write:"
+  "can message len error msg_size = %u struct can_msg = %u\n", 
   msg_size, sizeof(struct can_msg));
 return -RTEMS_INVALID_SIZE;
   }
@@ -365,7 +363,7 @@ release_lock_and_return:
   return ret;
 }
 
-static int
+static ssize_t 
 can_bus_ioctl(rtems_libio_t *iop, ioctl_command_t request, void *buffer)
 {
   can_bus *bus = IMFS_generic_get_context_by_iop(iop);
-- 
2.34.1

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

[PATCH 3/3] Revert "cpukit/dev/can: Added CAN support"

[Gedare Bloom]

This reverts commit cd91b37dce728b372f164355719a4e601e12e7b3.

Closes #4803.
---
 cpukit/dev/can/can.c | 505 ---
 cpukit/include/dev/can/can-msg.h | 105 -
 cpukit/include/dev/can/can.h | 284 -
 cpukit/include/dev/can/canqueueimpl.h| 231 ---
 spec/build/cpukit/librtemscpu.yml|   5 -
 spec/build/testsuites/libtests/can01.yml |  20 -
 spec/build/testsuites/libtests/grp.yml   |   2 -
 testsuites/libtests/can01/can-loopback.c | 110 -
 testsuites/libtests/can01/init.c | 249 ---
 9 files changed, 1511 deletions(-)
 delete mode 100644 cpukit/dev/can/can.c
 delete mode 100644 cpukit/include/dev/can/can-msg.h
 delete mode 100644 cpukit/include/dev/can/can.h
 delete mode 100644 cpukit/include/dev/can/canqueueimpl.h
 delete mode 100644 spec/build/testsuites/libtests/can01.yml
 delete mode 100644 testsuites/libtests/can01/can-loopback.c
 delete mode 100644 testsuites/libtests/can01/init.c

diff --git a/cpukit/dev/can/can.c b/cpukit/dev/can/can.c
deleted file mode 100644
index 2e6d5df65b..00
--- a/cpukit/dev/can/can.c
+++ /dev/null
@@ -1,505 +0,0 @@
-/* SPDX-License-Identifier: BSD-2-Clause */
-
-/**
- * @file
- *
- * @ingroup CANBus
- *
- * @brief Controller Area Network (CAN) Bus Implementation
- *
- */
-
-/*
- * Copyright (C) 2022 Prashanth S (fishesprasha...@gmail.com)
- *
- * 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.
- */
-
-#include 
-#include 
-
-#include 
-
-#include 
-#include 
-
-#include 
-#include 
-
-#define can_interrupt_lock_acquire(bus) \
-  do {  \
-   CAN_DEBUG_LOCK("acquiring lock\n");\
-   real_can_interrupt_lock_acquire(bus);  \
- } while (0);
-
-#define can_interrupt_lock_release(bus) \
-  do {  \
-   CAN_DEBUG_LOCK("releasing lock\n");\
-   real_can_interrupt_lock_release(bus);  \
- } while (0);
-
-static ssize_t 
-can_bus_open(rtems_libio_t *iop, const char *path, int oflag, mode_t mode);
-static ssize_t 
-can_bus_read(rtems_libio_t *iop, void *buffer, size_t count);
-static ssize_t 
-can_bus_write(rtems_libio_t *iop, const void *buffer, size_t count);
-static ssize_t 
-can_bus_ioctl(rtems_libio_t *iop, ioctl_command_t request, void *buffer);
-
-static int can_xmit(struct can_bus *bus);
-
-static int can_bus_create_sem(struct can_bus *);
-static int try_sem(struct can_bus *);
-static int take_sem(struct can_bus *);
-static int give_sem(struct can_bus *);
-
-
-static void can_bus_obtain(can_bus *bus)
-{
-  CAN_DEBUG("can_bus_obtain Entry\n");
-  rtems_mutex_lock(>mutex);
-  CAN_DEBUG("can_bus_obtain Exit\n");
-}
-
-static void can_bus_release(can_bus *bus)
-{
-  CAN_DEBUG("can_bus_release Entry\n");
-  rtems_mutex_unlock(>mutex);
-  CAN_DEBUG("can_bus_release Exit\n");
-}
-
-static void can_bus_destroy_mutex(struct can_bus *bus)
-{
-  rtems_mutex_destroy(>mutex);
-}
-
-static int can_bus_create_sem(struct can_bus *bus)
-{
-  int ret = 0;
-
-  ret = rtems_semaphore_create(rtems_build_name('c', 'a', 'n', bus->index), 
-  CAN_TX_BUF_COUNT, RTEMS_FIFO | RTEMS_COUNTING_SEMAPHORE | RTEMS_LOCAL, 
-  0, >tx_fifo_sem_id);
-
-  if (ret != 0) {
-CAN_ERR("can_create_sem: rtems_semaphore_create failed %d\n", ret);
-  }
-
-  return ret;
-}
-
-static void can_bus_free_tx_semaphore(struct can_bus *bus)
-{
-  rtems_semaphore_delete(bus->tx_fifo_sem_id);
-}
-
-static void real_can_interrupt_lock_acquire(struct can_bus *bus)
-{
-  bus->can_dev_ops->dev_int(bus->priv, false);
-  can_bus_obtain(bus);
-}
-
-static void 

[PATCH 2/3] Revert "build: Fix copyright statement format"

[Gedare Bloom]

This reverts commit 5b124432e27dd91f66f71464b586cc369e15ec99.
---
 spec/build/testsuites/libtests/can01.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/spec/build/testsuites/libtests/can01.yml 
b/spec/build/testsuites/libtests/can01.yml
index 7597b1fffd..b5c1e1ae5c 100644
--- a/spec/build/testsuites/libtests/can01.yml
+++ b/spec/build/testsuites/libtests/can01.yml
@@ -2,7 +2,7 @@ SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
 build-type: test-program
 cflags: []
 copyrights:
-- Copyright (C) 2022 Prashanth S (fishesprasha...@gmail.com).
+- Copyright (c) 2022 Prashanth S (fishesprasha...@gmail.com).
 cppflags: []
 cxxflags: []
 enabled-by: true
-- 
2.34.1

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

[PATCH 0/3] Revert CAN API

[Gedare Bloom]

The CAN API is not mature enough for a release. This patch set
reverts it. See #4803.

I expect to revisit this during the 7 development cycle.

Gedare Bloom (3):
  Revert "cpukit/dev/can: Resolve warnings in 64bit builds"
  Revert "build: Fix copyright statement format"
  Revert "cpukit/dev/can: Added CAN support"

 cpukit/dev/can/can.c | 507 ---
 cpukit/include/dev/can/can-msg.h | 105 -
 cpukit/include/dev/can/can.h | 284 -
 cpukit/include/dev/can/canqueueimpl.h| 231 ---
 spec/build/cpukit/librtemscpu.yml|   5 -
 spec/build/testsuites/libtests/can01.yml |  20 -
 spec/build/testsuites/libtests/grp.yml   |   2 -
 testsuites/libtests/can01/can-loopback.c | 110 -
 testsuites/libtests/can01/init.c | 249 ---
 9 files changed, 1513 deletions(-)
 delete mode 100644 cpukit/dev/can/can.c
 delete mode 100644 cpukit/include/dev/can/can-msg.h
 delete mode 100644 cpukit/include/dev/can/can.h
 delete mode 100644 cpukit/include/dev/can/canqueueimpl.h
 delete mode 100644 spec/build/testsuites/libtests/can01.yml
 delete mode 100644 testsuites/libtests/can01/can-loopback.c
 delete mode 100644 testsuites/libtests/can01/init.c

-- 
2.34.1

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

Re: [PATCH] eng: add Apache License 2.0 restriction

[Gedare Bloom]

This looks fine to me.

On Wed, Jul 26, 2023 at 10:29 AM Karel Gardas  wrote:
>
> ---
>  eng/license-requirements.rst | 26 +-
>  1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/eng/license-requirements.rst b/eng/license-requirements.rst
> index b2720f2..537b45e 100644
> --- a/eng/license-requirements.rst
> +++ b/eng/license-requirements.rst
> @@ -98,9 +98,33 @@ these guidelines:
>  * Advertising obligations are not acceptable.
>
>  * Some license restrictions may be permissible. These will be considered
> -  on a case-by-case basis.
> +  on a case-by-case basis. See below for a list of such restrictions.
>
>  In practice, these guidelines are not hard to follow. Critically,
>  they protect the freedom of the RTEMS source code and that of end users
>  to select the license and distribution terms they prefer for their
>  RTEMS-based application.
> +
> +License restrictions
> +
> +
> +* Apache License 2.0 in section 4 (b) requires modified files to carry
> +  prominent notice about performed modification. In case you modify such
> +  file and the notice is not there yet you are required to put notice
> +  below at the top of the modified file. If the notice is already
> +  there you don't need to add it second time.
> +  The notice should look:
> +
> +  .. code-block:: c
> +
> + /*
> +  * The file was modified by RTEMS contributors.
> +  */
> +
> + .. warning:: Do not import any project or files covered by the Apache
> +  License 2.0 into the RTEMS project source tree without
> +  discussing first with developers on the mailing list!
> +  Handling of Apache License 2.0 projects is a bit
> +  sensitive manner and RTEMS project is not prepared to
> +  handle one kind of those projects yet. E.g. the projects
> +  with NOTICE file present in the source tree.
> --
> 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: style patches - discuss

[Gedare Bloom]

On Tue, Jul 25, 2023 at 11:15 PM Sebastian Huber
 wrote:
>
> On 25.07.23 23:41, Gedare Bloom wrote:
> > I have sent two initial patches to begin the style reformat. The
> > clang-format file is not quite 100%, and it's also not usable by
> > anyone else (as I wait for changes to be accepted upstream).
> >
> > A few things to note:
> > * We can always manually override style with good reason. If you see
> > something like that in a patch, please let me know.
> > * I have started to avoid changing the __asm __ ... blocks, as
> > clang-format doesn't do a great job with those at the moment.
> > * clang-format also doesn't know how to indent broken if/for loops
> > like we prefer. So i may need to continue manual intervention on those
> > until I can get around to teaching it how. I believe that is doable,
> > but will take me some time to implement and get upstream.
> > * clang-format also has a preference to break function declarations
> > differently than we do. It will prefer to break after the function
> > return type/decorators, rather than in the parameter list. This may be
> > something we can tune. For now, I fix this manually.
> >
> > I may prepare a few more patches tomorrow, but I will leave these two
> > for the time being for feedback.
>
> Thanks for the samples. A good test file is
> cpukit/score/src/threadqenqueue.c.
>
> In the samples, there are a lot of changes in everything involving ()
> and []. I think we should either
>
> * aim for a configuration which performs a minimum set of changes in
> files which are close to the existing score style, or
>
> * choose a standard style.
>
I agree. i think I can get clang-format closer to that "minimum set"
but it seems to require still a few more modifications upstream.

Regarding spaces in [], I analyzed the score and found it was not
consistent, but more of the time there were not spaces:
$ grep -r "\[[^[:space:]]" | wc
   2615   17577  191765

$ grep -r "\[[[:space:]]" | wc
2231509   16393

So that one is manageable. The situation with spaces after parentheses
is trickier. There is a preference by some to avoid spaces in the
nested parentheses of arithmetic/logic expressions. This seems to be
somewhat consistent, but it is also a bit complicated to detect the
difference between:
z = ( x + y )
z = ( x + (x + y) )

Not impossible, but also not really standard anywhere that I have seen.

Gedare

> --
> 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] score/arm: style fixes

[Gedare Bloom]

On Tue, Jul 25, 2023 at 11:11 PM Sebastian Huber
 wrote:
>
> On 25.07.23 23:38, Gedare Bloom wrote:
> > diff --git a/cpukit/score/cpu/arm/aarch32-psma-init.c 
> > b/cpukit/score/cpu/arm/aarch32-psma-init.c
> > index 93a3673a98..b30cb5e308 100644
> > --- a/cpukit/score/cpu/arm/aarch32-psma-init.c
> > +++ b/cpukit/score/cpu/arm/aarch32-psma-init.c
> > @@ -46,7 +46,7 @@
> >   #include 
> >
> >   #define AARCH32_PMSA_REGION_MAX \
> > -  ( ( AARCH32_MPUIR_REGION_MASK >> AARCH32_MPUIR_REGION_SHIFT ) + 1 )
> > +  ((AARCH32_MPUIR_REGION_MASK >> AARCH32_MPUIR_REGION_SHIFT) + 1)
> >
> >   static void _AArch32_PMSA_Configure(
> > const AArch32_PMSA_Region *regions,
> > @@ -57,36 +57,36 @@ static void _AArch32_PMSA_Configure(
> > size_t   ri;
> > uint32_t sctlr;
> >
> > -  for ( ri = 0 ; ri < region_used; ++ri ) {
> > +  for ( ri = 0; ri < region_used; ++ri ) {
> >   uint32_t prbar;
> >   uint32_t prlar;
> >   uint32_t attr;
> >
> > -prbar = regions[ ri ].base;
> > -prlar = regions[ ri ].limit;
> > -attr = regions[ ri ].attributes;
> > +prbar = regions[ri].base;
> > +prlar = regions[ri].limit;
> > +attr  = regions[ri].attributes;
> >
> > -prbar |= ( attr >> 6 ) & 0x3fU;
> > +prbar |= (attr >> 6) & 0x3fU;
> >   prlar |= attr & 0x3fU;
> >
> > -_AArch32_Write_prselr( ri );
> > +_AArch32_Write_prselr(ri);
> >   _ARM_Instruction_synchronization_barrier();
> > -_AArch32_Write_prbar( prbar );
> > -_AArch32_Write_prlar( prlar );
> > +_AArch32_Write_prbar(prbar);
> > +_AArch32_Write_prlar(prlar);
> > }
>
> The existing style had the spaces which are removed here. I think this
> would lead to a lot of changes in score.
>

Yes, that is a great point. There was a brief discussion about this on
discord, and which spaces to have or not. With time, I can probably
get this handled on a case-by-case basis as needed. For example, if we
want to keep spaces inside of function arguments.

One of the examples we discussed is:
- _IO_Printf( _CPU_Put_char, , "%d", (value & mask ? 1 : 0) );
+ _IO_Printf( _CPU_Put_char, , "%d", ( value & mask ? 1 : 0 ) );

I think it should be relatively easy to add support in clang-format
for spaces that retains the original version. I'll have to sit on this
a bit longer probably to get it done.

> --
> 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] eng: add Apache License 2.0 restriction

[Gedare Bloom]

On Wed, Jul 26, 2023 at 4:28 AM Karel Gardas  wrote:
>
> ---
>  eng/license-requirements.rst | 18 +-
>  1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/eng/license-requirements.rst b/eng/license-requirements.rst
> index b2720f2..b9eea9a 100644
> --- a/eng/license-requirements.rst
> +++ b/eng/license-requirements.rst
> @@ -98,9 +98,25 @@ these guidelines:
>  * Advertising obligations are not acceptable.
>
>  * Some license restrictions may be permissible. These will be considered
> -  on a case-by-case basis.
> +  on a case-by-case basis. See below for a list of such restrictions.
>
>  In practice, these guidelines are not hard to follow. Critically,
>  they protect the freedom of the RTEMS source code and that of end users
>  to select the license and distribution terms they prefer for their
>  RTEMS-based application.
> +
> +License restrictions
> +
> +
> +* Apache License 2.0 in section 4 (b) requires modified files to carry
> +  prominent notice about performed modification. In case you modify such
> +  file and the notice is not there yet you are required to put notice
> +  below at the top of the modified file. If the notice is already
> +  there you don't need to add it second time.
> +  The notice should look:
> +
> +  .. code-block:: c
> +
> + /*
> +  * The file was modified by RTEMS contributors.
> +  */

Add a note about NOTICES (and that we currently don't have one.)

> --
> 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: [PATCH] score/arm: style fixes

[Gedare Bloom]

On Tue, Jul 25, 2023 at 5:03 PM Joel Sherrill  wrote:
>
>
>
> On Tue, Jul 25, 2023 at 5:53 PM Gedare Bloom  wrote:
>>
>> On Tue, Jul 25, 2023 at 4:48 PM Joel Sherrill  wrote:
>> >
>> > I may have missed something. Commented in one place.
>> >
>> > It looks like mostly spaces inside () and variable/parameter declaration 
>> > changes.
>> >
>> Yes, for the most part those are the least consistent so far.
>>
>> > On Tue, Jul 25, 2023 at 4:38 PM Gedare Bloom  wrote:
>> >> diff --git a/cpukit/score/cpu/arm/armv7m-isr-dispatch.c 
>> >> b/cpukit/score/cpu/arm/armv7m-isr-dispatch.c
>> >> index ea168969ba..dfc125d545 100644
>> >> --- a/cpukit/score/cpu/arm/armv7m-isr-dispatch.c
>> >> +++ b/cpukit/score/cpu/arm/armv7m-isr-dispatch.c
>> >> @@ -43,7 +43,7 @@
>> >>
>> >>  #ifdef ARM_MULTILIB_ARCH_V7M
>> >>
>> >> -static void __attribute__((naked)) _ARMV7M_Thread_dispatch( void )
>> >> +static void __attribute__((naked)) _ARMV7M_Thread_dispatch(void)
>> >>  {
>> >>__asm__ volatile (
>> >>  "bl _Thread_Dispatch\n"
>> >> @@ -53,7 +53,7 @@ static void __attribute__((naked)) 
>> >> _ARMV7M_Thread_dispatch( void )
>> >>);
>> >>  }
>> >>
>> >> -static void _ARMV7M_Trigger_lazy_floating_point_context_save( void )
>> >> +static void _ARMV7M_Trigger_lazy_floating_point_context_save(void)
>> >>  {
>> >>  #ifdef ARM_MULTILIB_VFP
>> >>__asm__ volatile (
>> >> @@ -62,7 +62,7 @@ static void 
>> >> _ARMV7M_Trigger_lazy_floating_point_context_save( void )
>> >>  #endif
>> >>  }
>> >>
>> >> -void _ARMV7M_Pendable_service_call( void )
>> >> +void _ARMV7M_Pendable_service_call(void)
>> >>  {
>> >>Per_CPU_Control *cpu_self = _Per_CPU_Get();
>> >>
>> >> @@ -73,7 +73,7 @@ void _ARMV7M_Pendable_service_call( void )
>> >> * this interrupt service may be delayed until interrupts are enable 
>> >> again.
>> >> */
>> >>if (
>> >> -( cpu_self->isr_nest_level | cpu_self->thread_dispatch_disable_level 
>> >> ) == 0
>> >> +(cpu_self->isr_nest_level | cpu_self->thread_dispatch_disable_level) 
>> >> == 0
>> >>) {
>> >
>> >
>> > Does this fit on a single line?
>> >
>> No. it's like two characters short. In fact, i had to do this one
>> manually. otherwise, it breaks as
>> if ( (...
>> ) == 0 ) {
>
>
> ! instead of == 0? :)

I'm not sure I want to nitpick on code changes during this pass. Feel
free to send a patch for code changes though ;)

>>
>>
>> > Ignoring the fact it is using bitwise operations on two integer counters. 
>> > Perhaps
>> > it should be a +?
>> >
>> separate problem I suppose. That is a little bit of a suspicious bit of 
>> logic.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] score/arm: style fixes

[Gedare Bloom]

On Tue, Jul 25, 2023 at 4:48 PM Joel Sherrill  wrote:
>
> I may have missed something. Commented in one place.
>
> It looks like mostly spaces inside () and variable/parameter declaration 
> changes.
>
Yes, for the most part those are the least consistent so far.

> On Tue, Jul 25, 2023 at 4:38 PM Gedare Bloom  wrote:
>> diff --git a/cpukit/score/cpu/arm/armv7m-isr-dispatch.c 
>> b/cpukit/score/cpu/arm/armv7m-isr-dispatch.c
>> index ea168969ba..dfc125d545 100644
>> --- a/cpukit/score/cpu/arm/armv7m-isr-dispatch.c
>> +++ b/cpukit/score/cpu/arm/armv7m-isr-dispatch.c
>> @@ -43,7 +43,7 @@
>>
>>  #ifdef ARM_MULTILIB_ARCH_V7M
>>
>> -static void __attribute__((naked)) _ARMV7M_Thread_dispatch( void )
>> +static void __attribute__((naked)) _ARMV7M_Thread_dispatch(void)
>>  {
>>__asm__ volatile (
>>  "bl _Thread_Dispatch\n"
>> @@ -53,7 +53,7 @@ static void __attribute__((naked)) 
>> _ARMV7M_Thread_dispatch( void )
>>);
>>  }
>>
>> -static void _ARMV7M_Trigger_lazy_floating_point_context_save( void )
>> +static void _ARMV7M_Trigger_lazy_floating_point_context_save(void)
>>  {
>>  #ifdef ARM_MULTILIB_VFP
>>__asm__ volatile (
>> @@ -62,7 +62,7 @@ static void 
>> _ARMV7M_Trigger_lazy_floating_point_context_save( void )
>>  #endif
>>  }
>>
>> -void _ARMV7M_Pendable_service_call( void )
>> +void _ARMV7M_Pendable_service_call(void)
>>  {
>>Per_CPU_Control *cpu_self = _Per_CPU_Get();
>>
>> @@ -73,7 +73,7 @@ void _ARMV7M_Pendable_service_call( void )
>> * this interrupt service may be delayed until interrupts are enable 
>> again.
>> */
>>if (
>> -( cpu_self->isr_nest_level | cpu_self->thread_dispatch_disable_level ) 
>> == 0
>> +(cpu_self->isr_nest_level | cpu_self->thread_dispatch_disable_level) == >> 0
>>) {
>
>
> Does this fit on a single line?
>
No. it's like two characters short. In fact, i had to do this one
manually. otherwise, it breaks as
if ( (...
) == 0 ) {

> Ignoring the fact it is using bitwise operations on two integer counters. 
> Perhaps
> it should be a +?
>
separate problem I suppose. That is a little bit of a suspicious bit of logic.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: style patches - discuss

[Gedare Bloom]

https://git.rtems.org/gedare/rtems.git/log/?h=aarch64-reformat
https://git.rtems.org/gedare/rtems.git/log/?h=arm-reformat

On Tue, Jul 25, 2023 at 3:56 PM Chris Johns  wrote:
>
> On 26/7/2023 7:41 am, Gedare Bloom wrote:
> > I have sent two initial patches to begin the style reformat. The
> > clang-format file is not quite 100%, and it's also not usable by
> > anyone else (as I wait for changes to be accepted upstream).
> >
> > A few things to note:
> > * We can always manually override style with good reason. If you see
> > something like that in a patch, please let me know.
> > * I have started to avoid changing the __asm __ ... blocks, as
> > clang-format doesn't do a great job with those at the moment.
> > * clang-format also doesn't know how to indent broken if/for loops
> > like we prefer. So i may need to continue manual intervention on those
> > until I can get around to teaching it how. I believe that is doable,
> > but will take me some time to implement and get upstream.
> > * clang-format also has a preference to break function declarations
> > differently than we do. It will prefer to break after the function
> > return type/decorators, rather than in the parameter list. This may be
> > something we can tune. For now, I fix this manually.
> >
> > I may prepare a few more patches tomorrow, but I will leave these two
> > for the time being for feedback.
>
> Is there a branch in a repo I can look at to see the files with the style 
> applied?
>
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] score/arm: style fixes

[Gedare Bloom]

On Tue, Jul 25, 2023 at 3:38 PM Gedare Bloom  wrote:
>
> ---
>  cpukit/score/cpu/arm/__aeabi_read_tp.c|   2 +-
>  cpukit/score/cpu/arm/__tls_get_addr.c |   4 +-
>  .../score/cpu/arm/aarch32-psma-init-default.c |   2 +-
>  cpukit/score/cpu/arm/aarch32-psma-init.c  |  82 -
>  cpukit/score/cpu/arm/arm-exception-default.c  |   6 +-
>  .../score/cpu/arm/arm-exception-frame-print.c | 159 --
>  cpukit/score/cpu/arm/armv4-sync-synchronize.c |   2 +-
>  cpukit/score/cpu/arm/armv7-thread-idle.c  |   4 +-
>  .../score/cpu/arm/armv7m-context-initialize.c |  14 +-
>  cpukit/score/cpu/arm/armv7m-context-restore.c |   4 +-
>  .../score/cpu/arm/armv7m-exception-default.c  |  26 +--
>  .../cpu/arm/armv7m-exception-handler-get.c|   4 +-
>  .../cpu/arm/armv7m-exception-handler-set.c|  19 +--
>  .../cpu/arm/armv7m-exception-priority-get.c   |   8 +-
>  .../arm/armv7m-exception-priority-handler.c   |   8 +-
>  .../cpu/arm/armv7m-exception-priority-set.c   |   8 +-
>  cpukit/score/cpu/arm/armv7m-initialize.c  |   2 +-
>  cpukit/score/cpu/arm/armv7m-isr-dispatch.c|  20 +--
>  cpukit/score/cpu/arm/armv7m-isr-enter-leave.c |   4 +-
>  cpukit/score/cpu/arm/armv7m-isr-level-get.c   |   2 +-
>  cpukit/score/cpu/arm/armv7m-isr-level-set.c   |   4 +-
>  .../score/cpu/arm/armv7m-isr-vector-install.c |   8 +-
>  .../cpu/arm/armv7m-multitasking-start-stop.c  |   4 +-
>  cpukit/score/cpu/arm/cpu.c|  51 +++---
>  24 files changed, 209 insertions(+), 238 deletions(-)
>
> diff --git a/cpukit/score/cpu/arm/__aeabi_read_tp.c 
> b/cpukit/score/cpu/arm/__aeabi_read_tp.c
> index 0f4eba8d9a..e3bc529f18 100644
> --- a/cpukit/score/cpu/arm/__aeabi_read_tp.c
> +++ b/cpukit/score/cpu/arm/__aeabi_read_tp.c
> @@ -37,8 +37,8 @@
>  #include "config.h"
>  #endif
>
> -#include 
>  #include 
> +#include 
>
>  #ifndef RTEMS_SMP
>
> diff --git a/cpukit/score/cpu/arm/__tls_get_addr.c 
> b/cpukit/score/cpu/arm/__tls_get_addr.c
> index 7ef42fdcb4..fe38368812 100644
> --- a/cpukit/score/cpu/arm/__tls_get_addr.c
> +++ b/cpukit/score/cpu/arm/__tls_get_addr.c
> @@ -47,8 +47,8 @@ void *__tls_get_addr(const TLS_Index *ti);
>  void *__tls_get_addr(const TLS_Index *ti)
>  {
>const Thread_Control *executing = _Thread_Get_executing();
> -  void *tls_data = (char *) executing->Registers.thread_id
> -+ _TLS_Get_thread_control_block_area_size();
> +  void *tls_data  = (char *) executing->Registers.thread_id;
This one I manually edited, as the alignment and breaking causes it to
be quite ugly. I should add a blank line here though, after the decls.
> +  tls_data += _TLS_Get_thread_control_block_area_size();
>
>assert(ti->module == 1);
>
> diff --git a/cpukit/score/cpu/arm/aarch32-psma-init-default.c 
> b/cpukit/score/cpu/arm/aarch32-psma-init-default.c
> index 615e7a528a..8ef8b5233a 100644
> --- a/cpukit/score/cpu/arm/aarch32-psma-init-default.c
> +++ b/cpukit/score/cpu/arm/aarch32-psma-init-default.c
> @@ -42,7 +42,7 @@
>
>  #if __ARM_ARCH >= 8 && __ARM_ARCH_PROFILE == 'R'
>
> -void _AArch32_PMSA_Initialize_default( void )
> +void _AArch32_PMSA_Initialize_default(void)
>  {
>_AArch32_PMSA_Initialize(
>  AARCH32_PMSA_MEM_ATTR(
> diff --git a/cpukit/score/cpu/arm/aarch32-psma-init.c 
> b/cpukit/score/cpu/arm/aarch32-psma-init.c
> index 93a3673a98..b30cb5e308 100644
> --- a/cpukit/score/cpu/arm/aarch32-psma-init.c
> +++ b/cpukit/score/cpu/arm/aarch32-psma-init.c
> @@ -46,7 +46,7 @@
>  #include 
>
>  #define AARCH32_PMSA_REGION_MAX \
> -  ( ( AARCH32_MPUIR_REGION_MASK >> AARCH32_MPUIR_REGION_SHIFT ) + 1 )
> +  ((AARCH32_MPUIR_REGION_MASK >> AARCH32_MPUIR_REGION_SHIFT) + 1)
>
>  static void _AArch32_PMSA_Configure(
>const AArch32_PMSA_Region *regions,
> @@ -57,36 +57,36 @@ static void _AArch32_PMSA_Configure(
>size_t   ri;
>uint32_t sctlr;
>
> -  for ( ri = 0 ; ri < region_used; ++ri ) {
> +  for ( ri = 0; ri < region_used; ++ri ) {
>  uint32_t prbar;
>  uint32_t prlar;
>  uint32_t attr;
>
> -prbar = regions[ ri ].base;
> -prlar = regions[ ri ].limit;
> -attr = regions[ ri ].attributes;
> +prbar = regions[ri].base;
> +prlar = regions[ri].limit;
> +attr  = regions[ri].attributes;
>
> -prbar |= ( attr >> 6 ) & 0x3fU;
> +prbar |= (attr >> 6) & 0x3fU;
>  prlar |= attr & 0x3fU;
>
> -_AArch32_Write_prselr( ri );
> +_AArch32_Write_prselr(ri);
>  _ARM_Instruction_synchronization_barrier();
> -_AArch32_Write_prbar( prbar );
> -_AArch32_Write_prlar( prlar );
> +_AArch32_Write_prbar(

style patches - discuss

[Gedare Bloom]

I have sent two initial patches to begin the style reformat. The
clang-format file is not quite 100%, and it's also not usable by
anyone else (as I wait for changes to be accepted upstream).

A few things to note:
* We can always manually override style with good reason. If you see
something like that in a patch, please let me know.
* I have started to avoid changing the __asm __ ... blocks, as
clang-format doesn't do a great job with those at the moment.
* clang-format also doesn't know how to indent broken if/for loops
like we prefer. So i may need to continue manual intervention on those
until I can get around to teaching it how. I believe that is doable,
but will take me some time to implement and get upstream.
* clang-format also has a preference to break function declarations
differently than we do. It will prefer to break after the function
return type/decorators, rather than in the parameter list. This may be
something we can tune. For now, I fix this manually.

I may prepare a few more patches tomorrow, but I will leave these two
for the time being for feedback.

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

[PATCH] score/arm: style fixes

[Gedare Bloom]

---
 cpukit/score/cpu/arm/__aeabi_read_tp.c|   2 +-
 cpukit/score/cpu/arm/__tls_get_addr.c |   4 +-
 .../score/cpu/arm/aarch32-psma-init-default.c |   2 +-
 cpukit/score/cpu/arm/aarch32-psma-init.c  |  82 -
 cpukit/score/cpu/arm/arm-exception-default.c  |   6 +-
 .../score/cpu/arm/arm-exception-frame-print.c | 159 --
 cpukit/score/cpu/arm/armv4-sync-synchronize.c |   2 +-
 cpukit/score/cpu/arm/armv7-thread-idle.c  |   4 +-
 .../score/cpu/arm/armv7m-context-initialize.c |  14 +-
 cpukit/score/cpu/arm/armv7m-context-restore.c |   4 +-
 .../score/cpu/arm/armv7m-exception-default.c  |  26 +--
 .../cpu/arm/armv7m-exception-handler-get.c|   4 +-
 .../cpu/arm/armv7m-exception-handler-set.c|  19 +--
 .../cpu/arm/armv7m-exception-priority-get.c   |   8 +-
 .../arm/armv7m-exception-priority-handler.c   |   8 +-
 .../cpu/arm/armv7m-exception-priority-set.c   |   8 +-
 cpukit/score/cpu/arm/armv7m-initialize.c  |   2 +-
 cpukit/score/cpu/arm/armv7m-isr-dispatch.c|  20 +--
 cpukit/score/cpu/arm/armv7m-isr-enter-leave.c |   4 +-
 cpukit/score/cpu/arm/armv7m-isr-level-get.c   |   2 +-
 cpukit/score/cpu/arm/armv7m-isr-level-set.c   |   4 +-
 .../score/cpu/arm/armv7m-isr-vector-install.c |   8 +-
 .../cpu/arm/armv7m-multitasking-start-stop.c  |   4 +-
 cpukit/score/cpu/arm/cpu.c|  51 +++---
 24 files changed, 209 insertions(+), 238 deletions(-)

diff --git a/cpukit/score/cpu/arm/__aeabi_read_tp.c 
b/cpukit/score/cpu/arm/__aeabi_read_tp.c
index 0f4eba8d9a..e3bc529f18 100644
--- a/cpukit/score/cpu/arm/__aeabi_read_tp.c
+++ b/cpukit/score/cpu/arm/__aeabi_read_tp.c
@@ -37,8 +37,8 @@
 #include "config.h"
 #endif
 
-#include 
 #include 
+#include 
 
 #ifndef RTEMS_SMP
 
diff --git a/cpukit/score/cpu/arm/__tls_get_addr.c 
b/cpukit/score/cpu/arm/__tls_get_addr.c
index 7ef42fdcb4..fe38368812 100644
--- a/cpukit/score/cpu/arm/__tls_get_addr.c
+++ b/cpukit/score/cpu/arm/__tls_get_addr.c
@@ -47,8 +47,8 @@ void *__tls_get_addr(const TLS_Index *ti);
 void *__tls_get_addr(const TLS_Index *ti)
 {
   const Thread_Control *executing = _Thread_Get_executing();
-  void *tls_data = (char *) executing->Registers.thread_id
-+ _TLS_Get_thread_control_block_area_size();
+  void *tls_data  = (char *) executing->Registers.thread_id;
+  tls_data += _TLS_Get_thread_control_block_area_size();
 
   assert(ti->module == 1);
 
diff --git a/cpukit/score/cpu/arm/aarch32-psma-init-default.c 
b/cpukit/score/cpu/arm/aarch32-psma-init-default.c
index 615e7a528a..8ef8b5233a 100644
--- a/cpukit/score/cpu/arm/aarch32-psma-init-default.c
+++ b/cpukit/score/cpu/arm/aarch32-psma-init-default.c
@@ -42,7 +42,7 @@
 
 #if __ARM_ARCH >= 8 && __ARM_ARCH_PROFILE == 'R'
 
-void _AArch32_PMSA_Initialize_default( void )
+void _AArch32_PMSA_Initialize_default(void)
 {
   _AArch32_PMSA_Initialize(
 AARCH32_PMSA_MEM_ATTR(
diff --git a/cpukit/score/cpu/arm/aarch32-psma-init.c 
b/cpukit/score/cpu/arm/aarch32-psma-init.c
index 93a3673a98..b30cb5e308 100644
--- a/cpukit/score/cpu/arm/aarch32-psma-init.c
+++ b/cpukit/score/cpu/arm/aarch32-psma-init.c
@@ -46,7 +46,7 @@
 #include 
 
 #define AARCH32_PMSA_REGION_MAX \
-  ( ( AARCH32_MPUIR_REGION_MASK >> AARCH32_MPUIR_REGION_SHIFT ) + 1 )
+  ((AARCH32_MPUIR_REGION_MASK >> AARCH32_MPUIR_REGION_SHIFT) + 1)
 
 static void _AArch32_PMSA_Configure(
   const AArch32_PMSA_Region *regions,
@@ -57,36 +57,36 @@ static void _AArch32_PMSA_Configure(
   size_t   ri;
   uint32_t sctlr;
 
-  for ( ri = 0 ; ri < region_used; ++ri ) {
+  for ( ri = 0; ri < region_used; ++ri ) {
 uint32_t prbar;
 uint32_t prlar;
 uint32_t attr;
 
-prbar = regions[ ri ].base;
-prlar = regions[ ri ].limit;
-attr = regions[ ri ].attributes;
+prbar = regions[ri].base;
+prlar = regions[ri].limit;
+attr  = regions[ri].attributes;
 
-prbar |= ( attr >> 6 ) & 0x3fU;
+prbar |= (attr >> 6) & 0x3fU;
 prlar |= attr & 0x3fU;
 
-_AArch32_Write_prselr( ri );
+_AArch32_Write_prselr(ri);
 _ARM_Instruction_synchronization_barrier();
-_AArch32_Write_prbar( prbar );
-_AArch32_Write_prlar( prlar );
+_AArch32_Write_prbar(prbar);
+_AArch32_Write_prlar(prlar);
   }
 
-  for ( ri = region_used ; ri < region_max; ++ri ) {
-_AArch32_Write_prselr( ri );
+  for ( ri = region_used; ri < region_max; ++ri ) {
+_AArch32_Write_prselr(ri);
 _ARM_Instruction_synchronization_barrier();
-_AArch32_Write_prbar( 0 );
-_AArch32_Write_prlar( 0 );
+_AArch32_Write_prbar(0);
+_AArch32_Write_prlar(0);
   }
 
   _ARM_Data_synchronization_barrier();
-  sctlr = _AArch32_Read_sctlr();
+  sctlr  = _AArch32_Read_sctlr();
   sctlr |= AARCH32_SCTLR_M | AARCH32_SCTLR_I | AARCH32_SCTLR_C;
-  sctlr &= ~( AARCH32_SCTLR_A | AARCH32_SCTLR_BR );
-  _AArch32_Write_sctlr( sctlr );
+  sctlr &= ~(AARCH32_SCTLR_A | AARCH32_SCTLR_BR);
+  _AArch32_Write_sctlr(sctlr);
   _ARM_Instruction_synchronization_barrier();
 }
 
@@ -109,16 

[PATCH] score/aarch64: style fixes

[Gedare Bloom]

---
 .../cpu/aarch64/aarch64-exception-default.c   |  22 +--
 .../aarch64/aarch64-exception-frame-print.c   | 155 ++
 .../score/cpu/aarch64/aarch64-thread-idle.c   |   2 +-
 cpukit/score/cpu/aarch64/cpu.c|  61 ---
 4 files changed, 132 insertions(+), 108 deletions(-)

diff --git a/cpukit/score/cpu/aarch64/aarch64-exception-default.c 
b/cpukit/score/cpu/aarch64/aarch64-exception-default.c
index f1591cbd5d..df15193996 100644
--- a/cpukit/score/cpu/aarch64/aarch64-exception-default.c
+++ b/cpukit/score/cpu/aarch64/aarch64-exception-default.c
@@ -46,9 +46,9 @@
 #include 
 #include 
 
-void _AArch64_Exception_default( CPU_Exception_frame *frame )
+void _AArch64_Exception_default(CPU_Exception_frame *frame)
 {
-  uint64_t EC = AARCH64_ESR_EL1_EC_GET( frame->register_syndrome );
+  uint64_t EC = AARCH64_ESR_EL1_EC_GET(frame->register_syndrome);
 
   /* Emulate FPSR flags for FENV if a FPU exception occurred */
   if ( EC == 0x2c ) {
@@ -59,19 +59,19 @@ void _AArch64_Exception_default( CPU_Exception_frame *frame 
)
  * functions executed in that context will need this information to be
  * accurate.
  */
-uint64_t ISS = AARCH64_ESR_EL1_EC_GET( frame->register_syndrome );
+uint64_t ISS = AARCH64_ESR_EL1_EC_GET(frame->register_syndrome);
 
 /* If the exception bits are valid, use them */
-if ( ( ISS & ( 1 << 23 ) ) != 0 ) {
+if ( (ISS & (1 << 23)) != 0 ) {
   /* The bits of the lower byte match the FPSR exception bits */
-  frame->register_fpsr |= ( ISS & 0xff );
+  frame->register_fpsr |= (ISS & 0xff);
 }
   }
 
-  rtems_fatal( RTEMS_FATAL_SOURCE_EXCEPTION, (rtems_fatal_code) frame );
+  rtems_fatal(RTEMS_FATAL_SOURCE_EXCEPTION, (rtems_fatal_code) frame);
 }
 
-void _CPU_Exception_disable_thread_dispatch( void )
+void _CPU_Exception_disable_thread_dispatch(void)
 {
   Per_CPU_Control *cpu_self = _Per_CPU_Get();
 
@@ -88,9 +88,9 @@ void _AArch64_Exception_frame_copy(
   *new_ef = *old_ef;
 }
 
-int _CPU_Exception_frame_get_signal( CPU_Exception_frame *ef )
+int _CPU_Exception_frame_get_signal(CPU_Exception_frame *ef)
 {
-  uint64_t EC = AARCH64_ESR_EL1_EC_GET( ef->register_syndrome );
+  uint64_t EC = AARCH64_ESR_EL1_EC_GET(ef->register_syndrome);
 
   switch ( EC ) {
 case 0x1:  /* WFI */
@@ -115,13 +115,13 @@ int _CPU_Exception_frame_get_signal( CPU_Exception_frame 
*ef )
   }
 }
 
-void _CPU_Exception_frame_set_resume( CPU_Exception_frame *ef, void *address )
+void _CPU_Exception_frame_set_resume(CPU_Exception_frame *ef, void *address)
 {
   ef->register_pc = address;
 }
 
 #define AARCH64_INSTRUCTION_SIZE 4
-void  _CPU_Exception_frame_make_resume_next_instruction( CPU_Exception_frame 
*ef )
+void _CPU_Exception_frame_make_resume_next_instruction(CPU_Exception_frame *ef)
 {
   ef->register_pc += AARCH64_INSTRUCTION_SIZE;
 }
diff --git a/cpukit/score/cpu/aarch64/aarch64-exception-frame-print.c 
b/cpukit/score/cpu/aarch64/aarch64-exception-frame-print.c
index c5b477c72f..e0fbab68dc 100644
--- a/cpukit/score/cpu/aarch64/aarch64-exception-frame-print.c
+++ b/cpukit/score/cpu/aarch64/aarch64-exception-frame-print.c
@@ -44,37 +44,37 @@
 
 #include 
 
+#include 
 #include 
 #include 
-#include 
 
 typedef struct {
-   char *s;
-   size_t n;
+  char  *s;
+  size_t n;
 } String_Context;
 
-static void _CPU_Put_char( int c, void *arg )
+static void _CPU_Put_char(int c, void *arg)
 {
   String_Context *sctx = arg;
-  size_t n = sctx->n;
+  size_t  n= sctx->n;
 
-  if (n > 0) {
+  if ( n > 0 ) {
 char *s = sctx->s;
-*s = (char) c;
+*s  = (char) c;
 sctx->s = s + 1;
 sctx->n = n - 1;
   }
 }
 
 static void _CPU_Binary_sprintf(
-  char *s,
-  size_t maxlen,
+  char*s,
+  size_t   maxlen,
   uint32_t num_bits,
   uint32_t value
 )
 {
   String_Context sctx;
-  uint32_t mask;
+  uint32_t   mask;
 
   sctx.s = s;
   sctx.n = maxlen;
@@ -82,14 +82,14 @@ static void _CPU_Binary_sprintf(
   mask = 1 << (num_bits - 1);
 
   while ( mask != 0 ) {
-_IO_Printf( _CPU_Put_char, , "%d", (value & mask ? 1 : 0) );
+_IO_Printf(_CPU_Put_char, , "%d", (value & mask ? 1 : 0));
 mask >>= 1;
   }
 
   s[num_bits] = '\0';
 }
 
-static const char* _CPU_Exception_class_to_string( uint16_t exception_class )
+static const char *_CPU_Exception_class_to_string(uint16_t exception_class)
 {
   /* The 80 character limit is intentionally ignored for these strings. */
   switch ( exception_class ) {
@@ -142,82 +142,107 @@ static const char* _CPU_Exception_class_to_string( 
uint16_t exception_class )
   }
 }
 
-void _CPU_Exception_frame_print( const CPU_Exception_frame *frame )
+void _CPU_Exception_frame_print(const CPU_Exception_frame *frame)
 {
-  uint32_t ec;
-  uint32_t il;
-  uint32_t iss;
-  char ec_str[7];
-  char iss_str[26];
-  int  i;
+  uint32_t ec;
+  uint32_t il;
+  uint32_t iss;
+  char ec_str[7];
+  char iss_str[26];
+  int  

Re: [PATCH 8/8] sys: Add files to Doxygen group

[Gedare Bloom]

On Tue, Jul 25, 2023 at 1:17 PM Gedare Bloom  wrote:
>
> On Tue, Jul 25, 2023 at 11:31 AM Sebastian Huber
>  wrote:
> >
> > On 25.07.23 17:55, Gedare Bloom wrote:
> > > priority.h and endian.h are imported code. We should modify with care.
> > > I'm not opposed, we just have to think twice.
> >
> > endian.h is now actually in Newlib. We should remove it at some point in
> > time.
> >
> > I synchronized a couple of files in the past and I don't think these
> > comment blocks at the begin of the file will cause issues in the future.
> >
> Agreed. Just one other thing, I think we prefer the SPDX to be the
> first line of the file where we control it.
>
nevermind, those got cut off by the patch context. ignore my noise.
This looks fine to me.

> > --
> > 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 8/8] sys: Add files to Doxygen group

[Gedare Bloom]

On Tue, Jul 25, 2023 at 11:31 AM Sebastian Huber
 wrote:
>
> On 25.07.23 17:55, Gedare Bloom wrote:
> > priority.h and endian.h are imported code. We should modify with care.
> > I'm not opposed, we just have to think twice.
>
> endian.h is now actually in Newlib. We should remove it at some point in
> time.
>
> I synchronized a couple of files in the past and I don't think these
> comment blocks at the begin of the file will cause issues in the future.
>
Agreed. Just one other thing, I think we prefer the SPDX to be the
first line of the file where we control it.

> --
> 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: Export BSP base and family via pkg-config

[Gedare Bloom]

On Tue, Jul 25, 2023 at 11:11 AM Sebastian Huber
 wrote:
>
>
>
> On 25.07.23 18:01, Gedare Bloom wrote:
> > On Tue, Jul 25, 2023 at 5:13 AM Sebastian Huber
> >   wrote:
> >> This allows application and library build systems to derive option
> >> values from the BSP base and family names.
> >> ---
> >>   spec/build/bsps/pkgconfig.yml | 2 ++
> >>   1 file changed, 2 insertions(+)
> >>
> >> diff --git a/spec/build/bsps/pkgconfig.yml b/spec/build/bsps/pkgconfig.yml
> >> index e08c83fe27..afaffbbf0f 100644
> >> --- a/spec/build/bsps/pkgconfig.yml
> >> +++ b/spec/build/bsps/pkgconfig.yml
> >> @@ -15,6 +15,8 @@ content: |
> >> ABI_FLAGS=${ABI_FLAGS}
> >> RTEMS_ARCH=${ARCH}
> >> RTEMS_BSP=${BSP_NAME}
> >> +  RTEMS_BSP_BASE=${BSP_BASE}
> >> +  RTEMS_BSP_FAMILY=${BSP_FAMILY}
> > These expose a little bit of the internal working of the build system.
> > I think it's fine, since these two fields should not change over time.
> > But, it commits us to maintain this mapping and these variables.
>
> We had the RTEMS_BSP also in the old build system, but it was actually
> what is now the RTEMS_BSP_BASE in this patch. With the user-defined BSP
> names we have for:
>
> [arch/user_bsp_name]
> INHERIT = system_bsp_name
>
> This results in:
>
> RTEMS_BSP = user_bsp_name
> RTEMS_BSP_BASE = system_bsp_name
>
> Maybe we should change this to:
>
> RTEMS_BSP = system_bsp_name
> RTEMS_BSP_NAME = user_bsp_name
>
This would make more sense. I don't know what it might break to make
this change now though, as external build tools may rely on the
current definition of RTEMS_BSP?

> The RTEMS_BSP_FAMILY is quite handy if you want to for example enable a
> network interface driver for a couple of BSPs. You don't have to
> enumerate all variants that exist now and in the future.
>
Yes, I see that. I'm fine with the addition, it makes sense.

> --
> 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] import Apache License 2.0 text file

[Gedare Bloom]

ok

On Tue, Jul 25, 2023 at 10:17 AM Karel Gardas  wrote:
>
> ---
>  LICENSE.Apache-2.0 | 202 +
>  1 file changed, 202 insertions(+)
>  create mode 100644 LICENSE.Apache-2.0
>
> diff --git a/LICENSE.Apache-2.0 b/LICENSE.Apache-2.0
> new file mode 100644
> index 00..d645695673
> --- /dev/null
> +++ b/LICENSE.Apache-2.0
> @@ -0,0 +1,202 @@
> +
> + Apache License
> +   Version 2.0, January 2004
> +http://www.apache.org/licenses/
> +
> +   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
> +
> +   1. Definitions.
> +
> +  "License" shall mean the terms and conditions for use, reproduction,
> +  and distribution as defined by Sections 1 through 9 of this document.
> +
> +  "Licensor" shall mean the copyright owner or entity authorized by
> +  the copyright owner that is granting the License.
> +
> +  "Legal Entity" shall mean the union of the acting entity and all
> +  other entities that control, are controlled by, or are under common
> +  control with that entity. For the purposes of this definition,
> +  "control" means (i) the power, direct or indirect, to cause the
> +  direction or management of such entity, whether by contract or
> +  otherwise, or (ii) ownership of fifty percent (50%) or more of the
> +  outstanding shares, or (iii) beneficial ownership of such entity.
> +
> +  "You" (or "Your") shall mean an individual or Legal Entity
> +  exercising permissions granted by this License.
> +
> +  "Source" form shall mean the preferred form for making modifications,
> +  including but not limited to software source code, documentation
> +  source, and configuration files.
> +
> +  "Object" form shall mean any form resulting from mechanical
> +  transformation or translation of a Source form, including but
> +  not limited to compiled object code, generated documentation,
> +  and conversions to other media types.
> +
> +  "Work" shall mean the work of authorship, whether in Source or
> +  Object form, made available under the License, as indicated by a
> +  copyright notice that is included in or attached to the work
> +  (an example is provided in the Appendix below).
> +
> +  "Derivative Works" shall mean any work, whether in Source or Object
> +  form, that is based on (or derived from) the Work and for which the
> +  editorial revisions, annotations, elaborations, or other modifications
> +  represent, as a whole, an original work of authorship. For the purposes
> +  of this License, Derivative Works shall not include works that remain
> +  separable from, or merely link (or bind by name) to the interfaces of,
> +  the Work and Derivative Works thereof.
> +
> +  "Contribution" shall mean any work of authorship, including
> +  the original version of the Work and any modifications or additions
> +  to that Work or Derivative Works thereof, that is intentionally
> +  submitted to Licensor for inclusion in the Work by the copyright owner
> +  or by an individual or Legal Entity authorized to submit on behalf of
> +  the copyright owner. For the purposes of this definition, "submitted"
> +  means any form of electronic, verbal, or written communication sent
> +  to the Licensor or its representatives, including but not limited to
> +  communication on electronic mailing lists, source code control systems,
> +  and issue tracking systems that are managed by, or on behalf of, the
> +  Licensor for the purpose of discussing and improving the Work, but
> +  excluding communication that is conspicuously marked or otherwise
> +  designated in writing by the copyright owner as "Not a Contribution."
> +
> +  "Contributor" shall mean Licensor and any individual or Legal Entity
> +  on behalf of whom a Contribution has been received by Licensor and
> +  subsequently incorporated within the Work.
> +
> +   2. Grant of Copyright License. Subject to the terms and conditions of
> +  this License, each Contributor hereby grants to You a perpetual,
> +  worldwide, non-exclusive, no-charge, royalty-free, irrevocable
> +  copyright license to reproduce, prepare Derivative Works of,
> +  publicly display, publicly perform, sublicense, and distribute the
> +  Work and such Derivative Works in Source or Object form.
> +
> +   3. Grant of Patent License. Subject to the terms and conditions of
> +  this License, each Contributor hereby grants to You a perpetual,
> +  worldwide, non-exclusive, no-charge, royalty-free, irrevocable
> +  (except as stated in this section) patent license to make, have made,
> +  use, offer to sell, sell, import, and otherwise transfer the Work,
> +  where such license applies only to those patent claims licensable
> +  by such 

Re: [PATCH] build: Export BSP base and family via pkg-config

[Gedare Bloom]

On Tue, Jul 25, 2023 at 5:13 AM Sebastian Huber
 wrote:
>
> This allows application and library build systems to derive option
> values from the BSP base and family names.
> ---
>  spec/build/bsps/pkgconfig.yml | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/spec/build/bsps/pkgconfig.yml b/spec/build/bsps/pkgconfig.yml
> index e08c83fe27..afaffbbf0f 100644
> --- a/spec/build/bsps/pkgconfig.yml
> +++ b/spec/build/bsps/pkgconfig.yml
> @@ -15,6 +15,8 @@ content: |
>ABI_FLAGS=${ABI_FLAGS}
>RTEMS_ARCH=${ARCH}
>RTEMS_BSP=${BSP_NAME}
> +  RTEMS_BSP_BASE=${BSP_BASE}
> +  RTEMS_BSP_FAMILY=${BSP_FAMILY}

These expose a little bit of the internal working of the build system.
I think it's fine, since these two fields should not change over time.
But, it commits us to maintain this mapping and these variables.

>RTEMS_MAJOR=${__RTEMS_MAJOR__}
>RTEMS_MINOR=${__RTEMS_MINOR__}
>RTEMS_REVISION=${__RTEMS_REVISION__}
> --
> 2.35.3
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 7/8] timecounter: Add files to Doxygen group

[Gedare Bloom]

Same thing here, these are imported files.

On Tue, Jul 25, 2023 at 2:49 AM Sebastian Huber
 wrote:
>
> Update #3707.
> ---
>  cpukit/include/machine/_timecounter.h | 2 ++
>  cpukit/include/sys/_ffcounter.h   | 9 +
>  cpukit/include/sys/timeffc.h  | 9 +
>  cpukit/include/sys/timepps.h  | 9 +
>  cpukit/include/sys/timetc.h   | 9 +
>  cpukit/include/sys/timex.h| 9 +
>  6 files changed, 47 insertions(+)
>
> diff --git a/cpukit/include/machine/_timecounter.h 
> b/cpukit/include/machine/_timecounter.h
> index 127e5f6fd3..e20e051f84 100644
> --- a/cpukit/include/machine/_timecounter.h
> +++ b/cpukit/include/machine/_timecounter.h
> @@ -3,6 +3,8 @@
>  /**
>   * @file
>   *
> + * @ingroup RTEMSScoreTimecounter
> + *
>   * @brief This header file provides timecounter definitions for the kernel 
> space
>   *   (_KERNEL is defined before including ) and RTEMS.
>   */
> diff --git a/cpukit/include/sys/_ffcounter.h b/cpukit/include/sys/_ffcounter.h
> index d83c48cd44..802c7d3224 100644
> --- a/cpukit/include/sys/_ffcounter.h
> +++ b/cpukit/include/sys/_ffcounter.h
> @@ -1,3 +1,12 @@
> +/**
> + * @file
> + *
> + * @ingroup RTEMSScoreTimecounter
> + *
> + * @brief This header file provides interfaces of the feed-forward clock
> + *   counter.
> + */
> +
>  /*-
>   * Copyright (c) 2011 The University of Melbourne
>   * All rights reserved.
> diff --git a/cpukit/include/sys/timeffc.h b/cpukit/include/sys/timeffc.h
> index c04de97f1d..13abd37a2b 100644
> --- a/cpukit/include/sys/timeffc.h
> +++ b/cpukit/include/sys/timeffc.h
> @@ -1,3 +1,12 @@
> +/**
> + * @file
> + *
> + * @ingroup RTEMSScoreTimecounter
> + *
> + * @brief This header file provides interfaces of the feed-back and
> + *   feed-forward clock implementations.
> + */
> +
>  /*-
>   * Copyright (c) 2011 The University of Melbourne
>   * All rights reserved.
> diff --git a/cpukit/include/sys/timepps.h b/cpukit/include/sys/timepps.h
> index 030c734477..502d93833e 100644
> --- a/cpukit/include/sys/timepps.h
> +++ b/cpukit/include/sys/timepps.h
> @@ -1,3 +1,12 @@
> +/**
> + * @file
> + *
> + * @ingroup RTEMSScoreTimecounter
> + *
> + * @brief This header file provides interfaces of the Pulse Per Second (PPS)
> + *   support.
> + */
> +
>  /*-
>   * 
> 
>   * "THE BEER-WARE LICENSE" (Revision 42):
> diff --git a/cpukit/include/sys/timetc.h b/cpukit/include/sys/timetc.h
> index 1ef58b378d..8f2537692c 100644
> --- a/cpukit/include/sys/timetc.h
> +++ b/cpukit/include/sys/timetc.h
> @@ -1,3 +1,12 @@
> +/**
> + * @file
> + *
> + * @ingroup RTEMSScoreTimecounter
> + *
> + * @brief This header file provides interfaces of the timecounter
> + *   implementation.
> + */
> +
>  /*-
>   * 
> 
>   * "THE BEER-WARE LICENSE" (Revision 42):
> diff --git a/cpukit/include/sys/timex.h b/cpukit/include/sys/timex.h
> index 8e763bb30f..36b1fcdb5a 100644
> --- a/cpukit/include/sys/timex.h
> +++ b/cpukit/include/sys/timex.h
> @@ -1,3 +1,12 @@
> +/**
> + * @file
> + *
> + * @ingroup RTEMSScoreTimecounter
> + *
> + * @brief This header file provides interfaces of the Network Time Protocol
> + *   (NTP) support.
> + */
> +
>  /*-
>   ***
>   **
> --
> 2.35.3
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 0/8] Add files to Doxygen groups

[Gedare Bloom]

Looks good except my comment about the cpukit/include/sys files
imported from Bsd

On Tue, Jul 25, 2023 at 2:49 AM Sebastian Huber
 wrote:
>
> Frank Kühndel (1):
>   bsps/sparc: Add files to Doxygen groups
>
> Sebastian Huber (7):
>   libtest: Place files into a Doxygen group
>   rtems: Add files to Doxygen groups
>   score: Add files to Doxygen groups
>   libcsupport: Add file to Doxygen group
>   posix: Add files to Doxygen group
>   timecounter: Add files to Doxygen group
>   sys: Add files to Doxygen group
>
>  bsps/shared/rtems-version.c   |  9 ++
>  bsps/sparc/include/bsp/gnatcommon.h   | 15 +++
>  bsps/sparc/include/bsp/gr_leon4_n2x.h | 10 +-
>  bsps/sparc/include/drvmgr/leon2_amba_bus.h| 10 +-
>  bsps/sparc/leon3/clock/ckinit.c   | 13 +--
>  bsps/sparc/leon3/console/printk_support.c | 11 ++-
>  bsps/sparc/leon3/start/bspstart.c | 14 ++-
>  bsps/sparc/leon3/start/cache.c|  8 ++
>  bsps/sparc/leon3/start/cpucounter.c   |  8 ++
>  bsps/sparc/leon3/start/eirq.c | 11 ++-
>  bsps/sparc/shared/irq/bsp_isr_handler.c   |  9 ++
>  cpukit/doxygen/top-level-groups.h |  8 ++
>  cpukit/include/machine/_timecounter.h |  2 +
>  cpukit/include/rtems/linkersets.h | 50 --
>  cpukit/include/rtems/posix/posixapi.h |  6 +-
>  cpukit/include/rtems/posix/spinlockimpl.h |  8 +-
>  cpukit/include/rtems/sysinit.h| 91 ++-
>  cpukit/include/rtems/test-info.h  |  9 ++
>  cpukit/include/rtems/test.h   | 13 ++-
>  cpukit/include/rtems/thread.h | 21 +
>  cpukit/include/sys/_ffcounter.h   |  9 ++
>  cpukit/include/sys/endian.h   |  9 ++
>  cpukit/include/sys/priority.h |  8 ++
>  cpukit/include/sys/statvfs.h  |  7 +-
>  cpukit/include/sys/timeffc.h  |  9 ++
>  cpukit/include/sys/timepps.h  |  9 ++
>  cpukit/include/sys/timetc.h   |  9 ++
>  cpukit/include/sys/timex.h|  9 ++
>  cpukit/libcsupport/src/malloc_p.h | 11 ++-
>  cpukit/libtest/t-test-busy-tick.c |  3 +-
>  cpukit/libtest/t-test-busy.c  |  3 +-
>  cpukit/libtest/t-test-checks-eno.c| 13 ++-
>  cpukit/libtest/t-test-checks-psx.c|  5 +-
>  cpukit/libtest/t-test-checks.c| 13 ++-
>  cpukit/libtest/t-test-hash-sha256.c   | 13 ++-
>  cpukit/libtest/t-test-interrupt.c |  3 +-
>  cpukit/libtest/t-test-rtems-context.c | 13 ++-
>  cpukit/libtest/t-test-rtems-fds.c | 13 ++-
>  cpukit/libtest/t-test-rtems-heap.c| 13 ++-
>  cpukit/libtest/t-test-rtems-measure.c | 13 ++-
>  cpukit/libtest/t-test-rtems-memory.c  |  9 ++
>  cpukit/libtest/t-test-rtems-objs.c|  5 +-
>  cpukit/libtest/t-test-rtems-posix-keys.c  |  5 +-
>  cpukit/libtest/t-test-rtems.c | 13 ++-
>  cpukit/libtest/t-test-rtems.h |  5 +-
>  cpukit/libtest/t-test-thread-switch.c |  3 +-
>  cpukit/libtest/t-test-time.c  | 13 ++-
>  cpukit/libtest/t-test.c   | 13 ++-
>  cpukit/libtest/testbeginend.c |  9 ++
>  cpukit/sapi/src/cpucounterconverter.c |  9 ++
>  cpukit/sapi/src/version.c |  2 +-
>  cpukit/score/cpu/no_cpu/cpuidle.c |  9 ++
>  .../cpu/sparc/include/libcpu/grlib-tn-0018.h  |  9 ++
>  cpukit/score/cpu/sparc/syscall.h  |  8 ++
>  54 files changed, 528 insertions(+), 95 deletions(-)
>
> --
> 2.35.3
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 8/8] sys: Add files to Doxygen group

[Gedare Bloom]

priority.h and endian.h are imported code. We should modify with care.
I'm not opposed, we just have to think twice.

On Tue, Jul 25, 2023 at 2:49 AM Sebastian Huber
 wrote:
>
> Canonicalize brief descriptions.
>
> Update #3707.
> ---
>  cpukit/doxygen/top-level-groups.h | 8 
>  cpukit/include/sys/endian.h   | 9 +
>  cpukit/include/sys/priority.h | 8 
>  cpukit/include/sys/statvfs.h  | 7 ---
>  4 files changed, 29 insertions(+), 3 deletions(-)
>
> diff --git a/cpukit/doxygen/top-level-groups.h 
> b/cpukit/doxygen/top-level-groups.h
> index fd32db347a..9d34b3e3dd 100644
> --- a/cpukit/doxygen/top-level-groups.h
> +++ b/cpukit/doxygen/top-level-groups.h
> @@ -40,6 +40,14 @@
>   *   RTEMS.
>   */
>
> +/**
> + * @defgroup RTEMSAPISystemLibrary System Library
> + *
> + * @ingroup RTEMSAPI
> + *
> + * @brief This group contains the system library APIs of RTEMS.
> + */
> +
>  /**
>   * @defgroup RTEMSDeviceDrivers Device Drivers
>   *
> diff --git a/cpukit/include/sys/endian.h b/cpukit/include/sys/endian.h
> index 0849a6a90b..cdd6201736 100644
> --- a/cpukit/include/sys/endian.h
> +++ b/cpukit/include/sys/endian.h
> @@ -1,3 +1,12 @@
> +/**
> + * @file
> + *
> + * @ingroup RTEMSAPISystemLibrary
> + *
> + * @brief This header file provides interfaces of the system endianness
> + *   support.
> + */
> +
>  /*-
>   * Copyright (c) 2002 Thomas Moestl 
>   * All rights reserved.
> diff --git a/cpukit/include/sys/priority.h b/cpukit/include/sys/priority.h
> index 855edb63c2..37d0d938dc 100644
> --- a/cpukit/include/sys/priority.h
> +++ b/cpukit/include/sys/priority.h
> @@ -1,3 +1,11 @@
> +/**
> + * @file
> + *
> + * @ingroup RTEMSAPISystemLibrary
> + *
> + * @brief This header file provides interfaces of the process priority 
> support.
> + */
> +
>  /*-
>   * SPDX-License-Identifier: BSD-4-Clause
>   *
> diff --git a/cpukit/include/sys/statvfs.h b/cpukit/include/sys/statvfs.h
> index 52d8e9d3fa..655f9a596c 100644
> --- a/cpukit/include/sys/statvfs.h
> +++ b/cpukit/include/sys/statvfs.h
> @@ -3,10 +3,11 @@
>  /**
>   * @file
>   *
> - * @brief Interface to the statvfs() Set of API Methods
> + * @ingroup RTEMSAPISystemLibrary
>   *
> - * This include file defines the interface to the statvfs() set of
> - * API methods. The statvfs as defined by the SUS:
> + * @brief This header file provides the statvfs() and fstatvfs() interfaces.
> + *
> + * The statvfs() is defined by the SUS:
>   *
>   * - 
> http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/statvfs.h.html
>   */
> --
> 2.35.3
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] c-user: Link task entry and global construction

[Gedare Bloom]

OK. Next time if you can just comment on the v1 that there's a v2. thanks

On Sun, Jul 23, 2023 at 11:51 PM Sebastian Huber
 wrote:
>
> ---
> v2: Mention global construction in application configuration options.
>
>  c-user/config/classic-init-task.rst  |  5 -
>  c-user/config/idle-task.rst  |  5 -
>  c-user/config/posix-init-thread.rst  |  5 -
>  c-user/glossary.rst  | 13 +
>  c-user/initialization/operations.rst | 25 +++--
>  c-user/rtems_data_types.rst  |  2 +-
>  c-user/task/directives.rst   |  6 +++---
>  7 files changed, 44 insertions(+), 17 deletions(-)
>
> diff --git a/c-user/config/classic-init-task.rst 
> b/c-user/config/classic-init-task.rst
> index 43ab95c..2f1baad 100644
> --- a/c-user/config/classic-init-task.rst
> +++ b/c-user/config/classic-init-task.rst
> @@ -405,7 +405,7 @@ initialization task is configured.
>
>  .. rubric:: NOTES:
>
> -The application shall define exactly one of the following configuration
> +The application shall define at least one of the following configuration
>  options
>
>  * ``CONFIGURE_RTEMS_INIT_TASKS_TABLE``,
> @@ -415,3 +415,6 @@ options
>  * :ref:`CONFIGURE_IDLE_TASK_INITIALIZES_APPLICATION`
>
>  otherwise a compile time error in the configuration file will occur.
> +
> +The Classic API initialization task performs the
> +:ref:`GlobalConstruction`.
> diff --git a/c-user/config/idle-task.rst b/c-user/config/idle-task.rst
> index e98ad83..793fb5c 100644
> --- a/c-user/config/idle-task.rst
> +++ b/c-user/config/idle-task.rst
> @@ -123,7 +123,7 @@ If this configuration option is defined, then it is 
> mandatory to configure a
>  user IDLE task with the :ref:`CONFIGURE_IDLE_TASK_BODY` configuration option,
>  otherwise a compile time error in the configuration file will occur.
>
> -The application shall define exactly one of the following configuration
> +The application shall define at least one of the following configuration
>  options
>
>  * :ref:`CONFIGURE_RTEMS_INIT_TASKS_TABLE`,
> @@ -134,6 +134,9 @@ options
>
>  otherwise a compile time error in the configuration file will occur.
>
> +If no Classic API initialization task and no POSIX API initialization thread
> +is configured, then no :ref:`GlobalConstruction` is performed.
> +
>  .. Generated from spec:/acfg/if/idle-task-stack-size
>
>  .. raw:: latex
> diff --git a/c-user/config/posix-init-thread.rst 
> b/c-user/config/posix-init-thread.rst
> index 8a8b9b5..d4439a6 100644
> --- a/c-user/config/posix-init-thread.rst
> +++ b/c-user/config/posix-init-thread.rst
> @@ -151,7 +151,7 @@ initialization thread is configured.
>
>  .. rubric:: NOTES:
>
> -The application shall define exactly one of the following configuration
> +The application shall define at least one of the following configuration
>  options
>
>  * :ref:`CONFIGURE_RTEMS_INIT_TASKS_TABLE`,
> @@ -162,6 +162,9 @@ options
>
>  otherwise a compile time error in the configuration file will occur.
>
> +If no Classic API initialization task is configured, then the POSIX API
> +initialization thread performs the :ref:`GlobalConstruction`.
> +
>  .. rubric:: CONSTRAINTS:
>
>  The configuration option is not included in the pre-qualified feature set of
> diff --git a/c-user/glossary.rst b/c-user/glossary.rst
> index 0962f44..8d86691 100644
> --- a/c-user/glossary.rst
> +++ b/c-user/glossary.rst
> @@ -476,6 +476,10 @@ Glossary
>  An object that has been created with the GLOBAL attribute and 
> exported to
>  all nodes in a multiprocessor system.
>
> +global construction
> +In the global construction, the C++ global constructors and 
> constructor
> +functions are invoked.  See :ref:`GlobalConstruction`.
> +
>  GNAT
>  *GNAT* is the :term:`GNU` compiler for Ada, integrated into the
>  :term:`GCC`.
> @@ -1379,6 +1383,15 @@ Glossary
>  A data structure associated with each task used by RTEMS to manage 
> that
>  task.
>
> +task entry
> +The task entry is invoked to execute the task's job.  Before the 
> task entry
> +is invoked, the thread begin :term:`user extensions` run in the 
> context of
> +the task.  After the return of the task entry, the thread exitted 
> user
> +extensions run in the context of the task.  The first user 
> initialization
> +task performs the :term:`global construction` after running the 
> thread begin
> +extensions and before the task entry is invoked.  See also
> +:ref:`InterfaceRtemsTaskStart`.
> +
>  task migration
>  Task migration happens in case a task stops execution on one 
> processor
>  and resumes execution on another processor.
> diff --git a/c-user/initialization/operations.rst 
> b/c-user/initialization/operations.rst
> index db5c94b..e7d310c 100644
> --- a/c-user/initialization/operations.rst
> +++ b/c-user/initialization/operations.rst
> @@ -285,19 +285,24 @@ Many of RTEMS actions 

Re: [PATCH] c-user: Link task entry and global construction

[Gedare Bloom]

looks good

On Sat, Jul 22, 2023 at 4:54 AM Sebastian Huber
 wrote:
>
> ---
>  c-user/glossary.rst  | 13 +
>  c-user/initialization/operations.rst | 25 +++--
>  c-user/rtems_data_types.rst  |  2 +-
>  c-user/task/directives.rst   |  6 +++---
>  4 files changed, 32 insertions(+), 14 deletions(-)
>
> diff --git a/c-user/glossary.rst b/c-user/glossary.rst
> index 0962f44..8d86691 100644
> --- a/c-user/glossary.rst
> +++ b/c-user/glossary.rst
> @@ -476,6 +476,10 @@ Glossary
>  An object that has been created with the GLOBAL attribute and 
> exported to
>  all nodes in a multiprocessor system.
>
> +global construction
> +In the global construction, the C++ global constructors and 
> constructor
> +functions are invoked.  See :ref:`GlobalConstruction`.
> +
>  GNAT
>  *GNAT* is the :term:`GNU` compiler for Ada, integrated into the
>  :term:`GCC`.
> @@ -1379,6 +1383,15 @@ Glossary
>  A data structure associated with each task used by RTEMS to manage 
> that
>  task.
>
> +task entry
> +The task entry is invoked to execute the task's job.  Before the 
> task entry
> +is invoked, the thread begin :term:`user extensions` run in the 
> context of
> +the task.  After the return of the task entry, the thread exitted 
> user
> +extensions run in the context of the task.  The first user 
> initialization
> +task performs the :term:`global construction` after running the 
> thread begin
> +extensions and before the task entry is invoked.  See also
> +:ref:`InterfaceRtemsTaskStart`.
> +
>  task migration
>  Task migration happens in case a task stops execution on one 
> processor
>  and resumes execution on another processor.
> diff --git a/c-user/initialization/operations.rst 
> b/c-user/initialization/operations.rst
> index db5c94b..e7d310c 100644
> --- a/c-user/initialization/operations.rst
> +++ b/c-user/initialization/operations.rst
> @@ -285,19 +285,24 @@ Many of RTEMS actions during initialization are based 
> upon the contents of the
>  Configuration Table.  For more information regarding the format and contents 
> of
>  this table, please refer to the chapter :ref:`Configuring a System`.
>
> +.. index:: global construction
> +
> +.. _GlobalConstruction:
> +
>  Global Construction
>  ---
>
> -The global construction is carried out by the first Classic API 
> initialization
> -task (first is defined by index zero in the Classic API initialization task
> -configuration table).  If no Classic API initialization task exists, then it 
> is
> -carried out by the first POSIX API initialization thread.  If no 
> initialization
> -task or thread exists, then no global construction is performed, see for
> -example :ref:`Specify Idle Task Performs Application Initialization`.  The
> -Classic API task or POSIX API thread which carries out global construction is
> -called the main thread.
> -
> -Global construction runs before the entry function of the main thread.  The
> +The :term:`global construction` is carried out by the Classic API
> +initialization task.  If no Classic API initialization task exists, then it 
> is
> +carried out by the POSIX API initialization thread.  If no initialization 
> task
> +or thread exists, then no global construction is performed.  The Classic API
> +task or POSIX API thread which carries out global construction is called the
> +main thread.  For configuration options related to initialization tasks, see
> +:ref:`CONFIGURE_RTEMS_INIT_TASKS_TABLE`,
> +:ref:`CONFIGURE_POSIX_INIT_THREAD_TABLE`, and
> +:ref:`CONFIGURE_IDLE_TASK_INITIALIZES_APPLICATION`.
> +
> +Global construction runs before the :term:`task entry` of the main thread.  
> The
>  configuration of the main thread must take the global construction into
>  account.  In particular, the main thread stack size, priority, attributes and
>  initial modes must be set accordingly.  Thread-local objects and POSIX key
> diff --git a/c-user/rtems_data_types.rst b/c-user/rtems_data_types.rst
> index a311509..8e4274b 100644
> --- a/c-user/rtems_data_types.rst
> +++ b/c-user/rtems_data_types.rst
> @@ -1523,7 +1523,7 @@ extension set.
>  rtems_task_entry
>  
>
> -This type defines the entry point of an RTEMS task.
> +This type defines the :term:`task entry` point of an RTEMS task.
>
>  .. Generated from spec:/rtems/userext/if/task-exitted
>
> diff --git a/c-user/task/directives.rst b/c-user/task/directives.rst
> index f4b65f5..d976905 100644
> --- a/c-user/task/directives.rst
> +++ b/c-user/task/directives.rst
> @@ -624,9 +624,9 @@ Starts the task.
>  .. rubric:: DESCRIPTION:
>
>  This directive readies the task, specified by ``id``, for execution based on
> -the priority and execution mode specified when the task was created.  The 
> entry
> -point of the task is given in ``entry_point``. The task's entry 

Re: [PATCH] membench: Add memory benchmark programs

[Gedare Bloom]

On Mon, Jul 24, 2023 at 2:01 AM Sebastian Huber
 wrote:
>
> On 21.07.23 09:43, Chris Johns wrote:
> > On 21/7/2023 3:28 pm, Sebastian Huber wrote:
> >> On 21.07.23 03:27, Chris Johns wrote:
> >>> On 21/7/2023 3:51 am, Sebastian Huber wrote:
> >>>> On 20.07.23 18:58, Gedare Bloom wrote:
> >>>>> On Thu, Jul 20, 2023 at 7:42 AM Sebastian Huber
> >>>>>   wrote:
> >>>>>> These memory benchmark programs are not supposed to run.  Instead, they
> >>>>>> can be analysed on the host system to measure the memory usage of
> >>>>>> features.  See the membench module of rtems-central.
> >>>>>>
> >>>>> This needs some kind of documentation and probably a README inside of
> >>>>> membench with that information.
> >>>>
> >>>> Ok, I can add a README.md.
> >>>>
> >>>>>
> >>>>> This appears to be about benchmarking the program size (static memory
> >>>>> usage) only? If so, make that clear in the README / log note. I think
> >>>>> it's in the doxygen already so that's helpful.
> >>>>
> >>>> Yes, it measures only the static memory size required for certain 
> >>>> operating
> >>>> system services. See 4.7 Memory Usage Benchmarks in:
> >>>>
> >>>> https://ftp.rtems.org/pub/rtems/people/sebh/rtems-6-sparc-gr740-uni-6-scf.pdf
> >>>
> >>> Should `static` be part of naming?
> >>
> >> Yes, good idea.
> >>
> >>>
> >>>>> What happens when the membench gets built, and then someone runs
> >>>>> $> rtems-test build/${ARCH}/${BSP}/testsuites
> >>>>>
> >>>>> Because I don't see anything that is filtering these executables.
> >>>>
> >>>> They are filtered out due to the *.norun.* pattern:>
> >>>> target: testsuites/membench/mem-scheduler-add-cpu.norun.exe
> >>>>
> >>>
> >>> Currently tests with `norun` assume the build fails if there is an issue 
> >>> with a
> >>> test. This is why we allow these tests and they are tagged `norun`.
> >>
> >> We already have a couple of norun tests in libtests. This filtering is 
> >> simple
> >> and works fine why would you want to change it?
> >
> > I am not asking for that to change. After a build we will have a set of 
> > norun
> > tests and in that set are some that are be used for other purposes, eg 
> > memory
> > analysis, but that information is not available in the project. The norun 
> > could
> > be extended to be .norun.memstatic.exe and so the executables that form a
> > specific subset can be found and analysed.
>
> The modules used to analyze static memory benchmarks know how to find
> them. The pattern is currently f"{path}/mem-{module}-{name}.norun.exe".
> We could of course use also a different pattern or no pattern at all,
> since the specification knows exactly which executable is associated
> with which item.
>
> >
> > The tests have been self contained for a long time and I would like that to
> > continue. ELF notes has been discussed in the past however we do not yet 
> > support
> > that so we need to find other ways to handling things.
>
> The static memory benchmarks are not useful individually. You have to
> know the relationship between them to get the results. For example, what
> is the cost of using API call X in terms of static memory usage?
>
> >
> >>> Are they suppose to be checked or are they informational? Is something 
> >>> going to
> >>> be added to the project, for example in rtems-tools.git, to allow these 
> >>> tests to
> >>> be checked?
> >>
> >> Currently, they are just informational,
> >
> > I do not understand. What information, for what purpose and for whom?
>
> I would have a look at the section 4.7 Memory Usage Benchmarks in to get
> an idea:
>
> https://ftp.rtems.org/pub/rtems/people/sebh/rtems-6-sparc-gr740-uni-6-scf.pdf
>
> This is just one application. You could also use the static memory
> benchmarks in a CI runner to catch memory usage regressions.
>
We should have a use or plan for them. Adding the output as part of
build tests is a good start. Maybe we can tie them into the build
visualization project in the future.

> >
> >> All the stuff to analyze this and work with
> >> the specification i

Re: [PATCH] validation: Improve sparc/leon3 shutdown test

[Gedare Bloom]

LGTM. If this will be repeated for other architectures in the future,
it may be worth defining an expected fatal code.

On Thu, Jul 20, 2023 at 3:57 AM Sebastian Huber
 wrote:
>
> Test the shutdown halt separately from the SMP-specific shutdown
> request.
>
> Update #3716.
> ---
>  .../bsps/fatal-sparc-leon3-shutdown.yml   |  11 +-
>  .../validation/bsps/objsparcleon3shutdown.yml |  17 +++
>  .../bsps/tc-fatal-sparc-leon3-shutdown-halt.c | 142 ++
>  ...> tc-fatal-sparc-leon3-shutdown-request.c} |  54 ++-
>  .../bsps/ts-fatal-sparc-leon3-shutdown.c  |   7 +
>  5 files changed, 182 insertions(+), 49 deletions(-)
>  create mode 100644 
> spec/build/testsuites/validation/bsps/objsparcleon3shutdown.yml
>  create mode 100644 
> testsuites/validation/bsps/tc-fatal-sparc-leon3-shutdown-halt.c
>  rename testsuites/validation/bsps/{tc-fatal-sparc-leon3-shutdown.c => 
> tc-fatal-sparc-leon3-shutdown-request.c} (75%)
>
> diff --git 
> a/spec/build/testsuites/validation/bsps/fatal-sparc-leon3-shutdown.yml 
> b/spec/build/testsuites/validation/bsps/fatal-sparc-leon3-shutdown.yml
> index e1a0f32900..a23409a4b5 100644
> --- a/spec/build/testsuites/validation/bsps/fatal-sparc-leon3-shutdown.yml
> +++ b/spec/build/testsuites/validation/bsps/fatal-sparc-leon3-shutdown.yml
> @@ -5,17 +5,16 @@ copyrights:
>  - Copyright (C) 2022 embedded brains GmbH & Co. KG
>  cppflags: []
>  cxxflags: []
> -enabled-by:
> -  and:
> -  - RTEMS_SMP
> -  - bsps/sparc/leon3
> +enabled-by: bsps/sparc/leon3
>  features: c cprogram
>  includes: []
>  ldflags:
>  - -Wl,--wrap=_CPU_Fatal_halt
> -links: []
> +links:
> +- role: build-dependency
> +  uid: objsparcleon3shutdown
>  source:
> -- testsuites/validation/bsps/tc-fatal-sparc-leon3-shutdown.c
> +- testsuites/validation/bsps/tc-fatal-sparc-leon3-shutdown-halt.c
>  - testsuites/validation/bsps/ts-fatal-sparc-leon3-shutdown.c
>  stlib: []
>  target: testsuites/validation/bsps/ts-fatal-sparc-leon3-shutdown.exe
> diff --git a/spec/build/testsuites/validation/bsps/objsparcleon3shutdown.yml 
> b/spec/build/testsuites/validation/bsps/objsparcleon3shutdown.yml
> new file mode 100644
> index 00..d6da0eafdc
> --- /dev/null
> +++ b/spec/build/testsuites/validation/bsps/objsparcleon3shutdown.yml
> @@ -0,0 +1,17 @@
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> +build-type: objects
> +cflags: []
> +copyrights:
> +- Copyright (C) 2023 embedded brains GmbH & Co. KG
> +cppflags: []
> +cxxflags: []
> +enabled-by:
> +  and:
> +  - RTEMS_SMP
> +  - bsps/sparc/leon3
> +includes: []
> +install: []
> +links: []
> +source:
> +- testsuites/validation/bsps/tc-fatal-sparc-leon3-shutdown-request.c
> +type: build
> diff --git a/testsuites/validation/bsps/tc-fatal-sparc-leon3-shutdown-halt.c 
> b/testsuites/validation/bsps/tc-fatal-sparc-leon3-shutdown-halt.c
> new file mode 100644
> index 00..0b0b5cf5b7
> --- /dev/null
> +++ b/testsuites/validation/bsps/tc-fatal-sparc-leon3-shutdown-halt.c
> @@ -0,0 +1,142 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @ingroup BspSparcLeon3ValFatalShutdownHalt
> + */
> +
> +/*
> + * Copyright (C) 2021, 2022 embedded brains GmbH & Co. KG
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
> IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +/*
> + * This file is part of the RTEMS quality process and was automatically
> + * generated.  If you find something that needs to be fixed or
> + * worded better please post a report or patch to an RTEMS mailing list
> + * or raise a bug report:
> + *
> + * https://www.rtems.org/bugs.html
> + *
> + * For information on updating and regenerating please refer to the How-To
> + * section in the Software 

Re: [PATCH] c-user: Add glossary terms for SPARC targets

[Gedare Bloom]

ok

On Thu, Jul 20, 2023 at 6:48 AM Sebastian Huber
 wrote:
>
> ---
>  c-user/glossary.rst | 30 ++
>  1 file changed, 30 insertions(+)
>
> diff --git a/c-user/glossary.rst b/c-user/glossary.rst
> index 6102d88..df3b9a3 100644
> --- a/c-user/glossary.rst
> +++ b/c-user/glossary.rst
> @@ -382,6 +382,18 @@ Glossary
>  GNU
>  This term is an acronym for `GNU's Not Unix `_.
>
> +GR712RC
> +The
> +`GR712RC 
> `_
> +is a :term:`system-on-chip` containing two processors of the 
> :term:`SPARC`
> +:term:`target architecture`.
> +
> +GR740
> +The
> +`GR740 
> `_
> +is a :term:`system-on-chip` containing four processors of the 
> :term:`SPARC`
> +:term:`target architecture`.
> +
>  handler
>  The equivalent of a manager, except that it is internal to RTEMS and
>  forms part of the core.  A handler is a collection of routines which
> @@ -905,6 +917,10 @@ Glossary
>  A thirty-two bit entity which is used to represent a task's 
> collection of
>  pending signals and the signals sent to a task.
>
> +SIS
> +This term is an acronym for Simple Instruction Simulator.  The SIS 
> is a
> +:term:`SPARC` V7/V8 and RISC-V RV32IMACFD :term:`target 
> architecture` simulator.
> +
>  SMCB
>  This term is an acronym for :term:`Semaphore Control Block`.
>
> @@ -982,6 +998,11 @@ Glossary
>  software as it is originally written (i.e., typed into a computer) 
> by a
>  human in plain text (i.e., human readable alphanumeric characters)."
>
> +SPARC
> +This term is an acronym for
> +`Scalable Processor ARChitecture 
> `_.
> +See also :term:`target architecture`.
> +
>  sporadic task
>  A task which executes at irregular intervals and must comply with a 
> hard
>  deadline.  A minimum period of time between successive iterations of 
> the
> @@ -1019,6 +1040,15 @@ Glossary
>  system call
>  In this document, this is used as an alternate term for directive.
>
> +system-on-chip
> +This project uses the `system on a chip definition of Wikipedia
> +`_: "A system on a 
> chip or
> +system-on-chip is an integrated circuit that integrates most or all
> +components of a computer or other electronic system."
> +
> +Systems on a chip are :term:`target` systems for applications using
> +:term:`RTEMS`.
> +
>  target
>  The system on which the application will ultimately execute.
>
> --
> 2.35.3
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] doxgen: Document build system provided files

[Gedare Bloom]

On Thu, Jul 20, 2023 at 7:20 AM Sebastian Huber
 wrote:
>
> Update #3707.
> ---
>  cpukit/doxygen/build.h | 82 ++
>  1 file changed, 82 insertions(+)
>  create mode 100644 cpukit/doxygen/build.h
>
> diff --git a/cpukit/doxygen/build.h b/cpukit/doxygen/build.h
> new file mode 100644
> index 00..e76c173eb8
> --- /dev/null
> +++ b/cpukit/doxygen/build.h
> @@ -0,0 +1,82 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @ingroup RTEMSImplDoxygen
> + *
> + * @brief This header file defines build system related Doxygen items.
> + */
> +
> +/*
> + * Copyright (C) 2023 embedded brains GmbH (http://www.embedded-brains.de)
> + *
> + * 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.
> + */
> +
> +/**
> + * @defgroup RTEMSImplBuild Build Options
> + *
> + * @ingroup RTEMSImpl
> + *
> + * @brief This group contains files provided by the build system.
May be better:
provided -> generated

> + */
> +
> +/**
> + * @ingroup RTEMSImplBuild
> + *
> + * @file bsps/include/bspopts.h
> + *
> + * @brief This header file provides the BSP options definitions.
> + */
> +
> +/**
> + * @ingroup RTEMSImplBuild
> + *
> + * @file cpukit/include/version-vc-key.h
> + *
> + * @brief This header file provides the version control key definitions.
> + */
> +
> +/**
> + * @ingroup RTEMSImplBuild
> + *
> + * @file cpukit/include/config.h
> + *
> + * @brief This header file provides system configuration definitions.
> + */
> +
> +/**
> + * @ingroup RTEMSImplBuild
> + *
> + * @file cpukit/include/rtems/testopts.h
> + *
> + * @brief This header file provides test program definitions.
> + */
> +
> +/**
> + * @ingroup RTEMSImplBuild
> + *
> + * @file cpukit/include/rtems/score/cpuopts.h
> + *
> + * @brief This header file provides the CPU options definitions.
> + */
> --
> 2.35.3
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 0/2] Add two unit tests

[Gedare Bloom]

Looks good with a couple minor typo/grammar fixes.

On Thu, Jul 20, 2023 at 7:40 AM Sebastian Huber
 wrote:
>
>
> Frank Kühndel (2):
>   unit: Test POSIX-specific message queue impl
>   unit: Test unlimited objects configuration
>
>  .../build/testsuites/unit/unit-no-clock-0.yml |   2 +
>  testsuites/unit/tc-config.c   | 171 +++
>  testsuites/unit/tc-score-msgq.c   | 452 ++
>  3 files changed, 625 insertions(+)
>  create mode 100644 testsuites/unit/tc-config.c
>  create mode 100644 testsuites/unit/tc-score-msgq.c
>
> --
> 2.35.3
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/2] unit: Test POSIX-specific message queue impl

[Gedare Bloom]

Minor nits.

On Thu, Jul 20, 2023 at 7:40 AM Sebastian Huber
 wrote:
>
> From: Frank Kühndel 
>
> This unit test covers code paths of the Message Handler which are only
> reached by through POSIX message queue API.
>
> Update #3716.
> ---
>  .../build/testsuites/unit/unit-no-clock-0.yml |   1 +
>  testsuites/unit/tc-score-msgq.c   | 452 ++
>  2 files changed, 453 insertions(+)
>  create mode 100644 testsuites/unit/tc-score-msgq.c
>
> diff --git a/spec/build/testsuites/unit/unit-no-clock-0.yml 
> b/spec/build/testsuites/unit/unit-no-clock-0.yml
> index 57cd279a7a..517b84284d 100644
> --- a/spec/build/testsuites/unit/unit-no-clock-0.yml
> +++ b/spec/build/testsuites/unit/unit-no-clock-0.yml
> @@ -12,6 +12,7 @@ ldflags: []
>  links: []
>  source:
>  - testsuites/unit/tc-misaligned-builtin-memcpy.c
> +- testsuites/unit/tc-score-msgq.c
>  - testsuites/unit/tc-score-rbtree.c
>  - testsuites/unit/ts-unit-no-clock-0.c
>  stlib: []
> diff --git a/testsuites/unit/tc-score-msgq.c b/testsuites/unit/tc-score-msgq.c
> new file mode 100644
> index 00..c4baa6d53e
> --- /dev/null
> +++ b/testsuites/unit/tc-score-msgq.c
> @@ -0,0 +1,452 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @ingroup ScoreMsgqUnitMsgq
> + */
> +
> +/*
> + * Copyright (C) 2021 embedded brains GmbH & Co. KG
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
> IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +/*
> + * This file is part of the RTEMS quality process and was automatically
> + * generated.  If you find something that needs to be fixed or
> + * worded better please post a report or patch to an RTEMS mailing list
> + * or raise a bug report:
> + *
> + * https://www.rtems.org/bugs.html
> + *
> + * For information on updating and regenerating please refer to the How-To
> + * section in the Software Requirements Engineering chapter of the
> + * RTEMS Software Engineering manual.  The manual is provided as a part of
> + * a release.  For development sources please refer to the online
> + * documentation at:
> + *
> + * https://docs.rtems.org
> + */
> +
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "../validation/tx-support.h"
> +
> +#include 
> +
> +/**
> + * @defgroup ScoreMsgqUnitMsgq spec:/score/msgq/unit/msgq
> + *
> + * @ingroup TestsuitesUnitNoClock0
> + *
> + * @brief Unit tests for the Message Queue Handler.
> + *
> + * Parts of the files ``cpukit/score/src/coremsginsert.c``,
> + * ``cpukit/score/src/coremsgseize.c``, and
> + * ``cpukit/score/src/coremsgsubmit.c`` are only executed by the POSIX API.
> + * Currently, the pre-qualified subset of RTEMS does not contain the POSIX 
> API.
> + * This test exercises the code parts otherwise only reached by the POSIX API
> + * to achieve full code coverage.
> + *
> + * This test case performs the following actions:
> + *
> + * - Use _CORE_message_queue_Insert_message() to insert two messages into a
> + *   message queue and use the POSIX message priority to define their order 
> in
> + *   the queue.
> + *
> + *   - Check that _CORE_message_queue_Submit() was executed successfully.
> + *
> + *   - Check that the messages are in right order in the message queue.
"in the right" or "in correct"

> + *
> + * - Submit three messages into a message queue which can only store two and
> + *   have the third submit() blocked till a seize() occurs.
> + *
> + *   - Check that the third _CORE_message_queue_Submit() did actually block
> + * till there was room for the message in the message queue.
> + *
> + * - Submit messages in the queue from within an ISR.
> + *
> + *   - Check that the 

Re: [PATCH] membench: Add memory benchmark programs

[Gedare Bloom]

On Thu, Jul 20, 2023 at 7:42 AM Sebastian Huber
 wrote:
>
> These memory benchmark programs are not supposed to run.  Instead, they
> can be analysed on the host system to measure the memory usage of
> features.  See the membench module of rtems-central.
>
This needs some kind of documentation and probably a README inside of
membench with that information.

This appears to be about benchmarking the program size (static memory
usage) only? If so, make that clear in the README / log note. I think
it's in the doxygen already so that's helpful.

What happens when the membench gets built, and then someone runs
$> rtems-test build/${ARCH}/${BSP}/testsuites

Because I don't see anything that is filtering these executables.

> Update #3716.
> ---
>  cpukit/doxygen/top-level-groups.h |   8 +
>  spec/build/testsuites/grp.yml |   2 +
>  spec/build/testsuites/membench/grp.yml| 121 +++
>  .../membench/mem-barrier-wait-rel-del.yml |  19 +++
>  .../membench/mem-barrier-wait-rel.yml |  19 +++
>  .../testsuites/membench/mem-bsp-clock.yml |  19 +++
>  .../membench/mem-clock-get-uptime.yml |  19 +++
>  .../membench/mem-clock-set-get-tod.yml|  19 +++
>  .../testsuites/membench/mem-clock-set.yml |  19 +++
>  .../testsuites/membench/mem-event-snd-rcv.yml |  19 +++
>  .../testsuites/membench/mem-fatal-fatal.yml   |  19 +++
>  .../membench/mem-message-bcst-rcv.yml |  19 +++
>  .../membench/mem-message-snd-rcv-del.yml  |  19 +++
>  .../membench/mem-message-snd-rcv.yml  |  19 +++
>  .../membench/mem-message-ugt-rcv.yml  |  19 +++
>  .../membench/mem-part-get-ret-del.yml |  19 +++
>  .../testsuites/membench/mem-part-get-ret.yml  |  19 +++
>  .../membench/mem-ratemon-period-del.yml   |  19 +++
>  .../membench/mem-ratemon-period.yml   |  19 +++
>  .../testsuites/membench/mem-rtems-basic.yml   |  19 +++
>  .../testsuites/membench/mem-rtems-smp-1.yml   |  19 +++
>  .../membench/mem-rtems-smp-global-2.yml   |  19 +++
>  .../membench/mem-rtems-smp-global-4.yml   |  19 +++
>  .../membench/mem-rtems-smp-part-2.yml |  19 +++
>  .../membench/mem-rtems-smp-part-4.yml |  19 +++
>  .../membench/mem-scheduler-add-cpu.yml|  19 +++
>  .../membench/mem-scheduler-rm-cpu.yml |  19 +++
>  .../membench/mem-sem-obt-rel-del.yml  |  19 +++
>  .../testsuites/membench/mem-sem-obt-rel.yml   |  19 +++
>  .../membench/mem-signal-catch-snd.yml |  19 +++
>  .../testsuites/membench/mem-task-delete.yml   |  19 +++
>  .../testsuites/membench/mem-task-exit.yml |  19 +++
>  .../membench/mem-task-get-affinity.yml|  19 +++
>  .../membench/mem-task-get-priority.yml|  19 +++
>  .../membench/mem-task-get-scheduler.yml   |  19 +++
>  .../testsuites/membench/mem-task-mode.yml |  19 +++
>  .../testsuites/membench/mem-task-restart.yml  |  19 +++
>  .../membench/mem-task-set-affinity.yml|  19 +++
>  .../membench/mem-task-set-priority.yml|  19 +++
>  .../membench/mem-task-set-scheduler.yml   |  19 +++
>  .../testsuites/membench/mem-task-sus-res.yml  |  19 +++
>  .../membench/mem-task-wake-after.yml  |  19 +++
>  .../membench/mem-task-wake-when.yml   |  19 +++
>  .../testsuites/membench/mem-timer-after.yml   |  19 +++
>  .../testsuites/membench/mem-timer-cancel.yml  |  19 +++
>  .../testsuites/membench/mem-timer-delete.yml  |  19 +++
>  .../testsuites/membench/mem-timer-reset.yml   |  19 +++
>  .../membench/mem-timer-srv-after.yml  |  19 +++
>  .../membench/mem-timer-srv-init.yml   |  19 +++
>  .../membench/mem-timer-srv-when.yml   |  19 +++
>  .../testsuites/membench/mem-timer-when.yml|  19 +++
>  .../membench/mem-userext-create.yml   |  19 +++
>  .../membench/mem-userext-delete.yml   |  19 +++
>  spec/build/testsuites/optmembench.yml |  16 ++
>  .../membench/mem-barrier-wait-rel-del.c   | 116 +++
>  testsuites/membench/mem-barrier-wait-rel.c| 114 ++
>  testsuites/membench/mem-bsp-clock.c   | 109 ++
>  testsuites/membench/mem-clock-get-uptime.c| 108 ++
>  testsuites/membench/mem-clock-set-get-tod.c   | 110 ++
>  testsuites/membench/mem-clock-set.c   | 108 ++
>  testsuites/membench/mem-event-snd-rcv.c   | 110 ++
>  testsuites/membench/mem-fatal-fatal.c | 108 ++
>  testsuites/membench/mem-message-bcst-rcv.c| 111 ++
>  testsuites/membench/mem-message-snd-rcv-del.c | 114 ++
>  testsuites/membench/mem-message-snd-rcv.c | 111 ++
>  testsuites/membench/mem-message-ugt-rcv.c | 111 ++
>  testsuites/membench/mem-part-get-ret-del.c| 115 ++
>  testsuites/membench/mem-part-get-ret.c| 114 ++
>  testsuites/membench/mem-ratemon-period-del.c  | 114 ++
>  

Re: Repository edit

[Gedare Bloom]

I had a local copy of the two commits that were dropped during the
rewinding. I have pushed them back. We are back to the state prior to
the accidental push. Hashes all look good. Thanks for handling this.

Gedare

On Tue, Jul 18, 2023 at 7:55 PM Amar Takhar  wrote:
>
> There was a mistaken push to the RTEMS main repository earlier.  These things
> happen so we have rewound the repository back to the latest safe commit.
>
> This is 1425735.
>
> If anyone did checkout the repository afterwards they will get an error when
> trying to update as the repository has been rewound.  You can solve this by
> doing a fresh clone -- something I always recommend
>
> Alternatively you can reset your own repository by doing
>
>   git reset --hard 1425735
>
> While on the master branch -- please keep in mind this will blow away any
> changes you have in your source tree.
>
> Sebastian, I noticed you had two commits pushed after these will need to be
> re-applied as rewinding back is the safest and best way to handle this.
>
>
> Amar.
> ___
> 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 rtems-tools] tester/rtems: add renode implementation

[Gedare Bloom]

The patch has 3 whitespace errors. I have fixed them, and I will push this soon.

On Tue, Jun 27, 2023 at 8:42 PM Muhammad Sulthan Mazaya
 wrote:
>
> Hi Joel and Chris,
>
> Yes, and I will be working on the rsb patch for renode installation next.
>
> Regards,
> Mazaya
>
> On Wed, Jun 28, 2023 at 12:34 PM Chris Johns  wrote:
>>
>> I am as well
>>
>> Chris
>>
>> On 28/6/2023 12:25 am, Joel Sherrill wrote:
>> > I'm OK with this patch.
>> >
>> > Is it assuming that you installed renode on your own -- not using the RSB?
>> >
>> > --joel
>> >
>> > On Mon, Jun 26, 2023 at 5:37 PM Muhammad Sulthan Mazaya
>> > mailto:msulthanmaz...@gmail.com>> wrote:
>> >
>> > Hi Chris,
>> >
>> > Yes they are the same. I thought there was an email error, so I 
>> > re-send it
>> > twice.
>> >
>> > On Tue, 27 Jun 2023, 07:46 Chris Johns, > > > wrote:
>> >
>> > Hi Muhammad,
>> >
>> > The patch looks good, thanks.
>> >
>> > Are the 3 posted patches the same version?
>> >
>> > Chris
>> >
>> > On 26/6/2023 2:17 pm, Muhammad Sulthan Mazaya wrote:
>> > > Patch for the implementation of renode on rtems-test. Currently, 
>> > renode
>> > > installation has not been implemented in rsb. Thus, for testing, 
>> > you can
>> > > install renode by referring to the documentation link below.
>> > >
>> > > Downloads for debian, fedora, arch, macOS, and windows:
>> > > https://renode.io/#downloads 
>> > >
>> > > Alternatively, you can access Renode's GitHub releases:
>> > > https://github.com/renode/renode/releases/tag/v1.13.3
>> > 
>> > >
>> > > You can also build it from source:
>> > >
>> > 
>> > https://renode.readthedocs.io/en/latest/advanced/building_from_sources.html#building-from-source
>> >  
>> > 
>> > >
>> > > This patch consists of changes to test kendrytek210 using 
>> > renode. To
>> > > test it, you can build the kendrytek210 test suite as instructed 
>> > in the
>> > > rtems-docs (Alan's patch here:
>> > https://lists.rtems.org/pipermail/devel/2023-April/074838.html
>> > ).
>> > > Then, use the following command to run the test suite.
>> > >
>> > > rtems-test --rtems-bsp=kendrytek210-renode [test-suite-path]
>> > >
>> > > ---
>> > >  .../testing/bsps/kendrytek210-renode.ini  | 38 +++
>> > >  tester/rtems/testing/renode.cfg   | 64 
>> > +++
>> > >  .../testing/renode_scripts/kendrytek210.resc  | 53 
>> > +++
>> > >  3 files changed, 155 insertions(+)
>> > >  create mode 100644 
>> > tester/rtems/testing/bsps/kendrytek210-renode.ini
>> > >  create mode 100644 tester/rtems/testing/renode.cfg
>> > >  create mode 100644 
>> > tester/rtems/testing/renode_scripts/kendrytek210.resc
>> > >
>> > > diff --git a/tester/rtems/testing/bsps/kendrytek210-renode.ini
>> > b/tester/rtems/testing/bsps/kendrytek210-renode.ini
>> > > new file mode 100644
>> > > index 000..95850c5
>> > > --- /dev/null
>> > > +++ b/tester/rtems/testing/bsps/kendrytek210-renode.ini
>> > > @@ -0,0 +1,38 @@
>> > > +#
>> > > +# RTEMS Tools Project (http://www.rtems.org/ 
>> > )
>> > > +# Copyright 2010-2014 Chris Johns (chr...@rtems.org
>> > )
>> > > +# All rights reserved.
>> > > +#
>> > > +# This file is part of the RTEMS Tools package in 'rtems-tools'.
>> > > +#
>> > > +# 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 
>> 

Re: [PATCH rtems-source-builder v2] bare/config: add renode rsb installation config

[Gedare Bloom]

This patch applies cleanly and builds renode for me. Thanks for making
the changes, this recipe should be much easier to maintain for version
updates of renode. i will push it if no one complains soon.

We will definitely need some documentation for building this. At the
least you should start with a blog post, but in general we should find
a good place for documenting RSB build dependencies. Maybe a new
section in https://docs.rtems.org/branches/master/user/rsb/index.html

On Ubuntu, in addition to whatever "typical" development tools I
already have installed, I had to add mono-devel and gtk-sharp2

On Wed, Jul 12, 2023 at 2:43 AM Muhammad Sulthan Mazaya
 wrote:
>
> Use the design of how qemu handle config files + add version number to
> the config file name.
>
> ---
>  bare/config/devel/renode-1.13.3-1.cfg | 11 ++
>  bare/config/devel/renode.bset |  7 
>  source-builder/config/renode-1.13.3.cfg   |  7 
>  source-builder/config/renode-common-1.cfg | 45 +++
>  4 files changed, 70 insertions(+)
>  create mode 100644 bare/config/devel/renode-1.13.3-1.cfg
>  create mode 100644 bare/config/devel/renode.bset
>  create mode 100644 source-builder/config/renode-1.13.3.cfg
>  create mode 100644 source-builder/config/renode-common-1.cfg
>
> diff --git a/bare/config/devel/renode-1.13.3-1.cfg 
> b/bare/config/devel/renode-1.13.3-1.cfg
> new file mode 100644
> index 000..ad9b0ad
> --- /dev/null
> +++ b/bare/config/devel/renode-1.13.3-1.cfg
> @@ -0,0 +1,11 @@
> +#
> +# Renode from git
> +#
> +
> +%if %{release} == %{nil}
> + %define release 1
> +%endif
> +
> +%define renode_version 1.13.3
> +
> +%include %{_configdir}/renode-1.13.3.cfg
> diff --git a/bare/config/devel/renode.bset b/bare/config/devel/renode.bset
> new file mode 100644
> index 000..f89168d
> --- /dev/null
> +++ b/bare/config/devel/renode.bset
> @@ -0,0 +1,7 @@
> +#
> +# Build set for Renode
> +#
> +
> +%define release 1
> +
> +devel/renode-1.13.3-1
> diff --git a/source-builder/config/renode-1.13.3.cfg 
> b/source-builder/config/renode-1.13.3.cfg
> new file mode 100644
> index 000..5aff341
> --- /dev/null
> +++ b/source-builder/config/renode-1.13.3.cfg
> @@ -0,0 +1,7 @@
> +#
> +# Renode 1.13.3 Version 1.
> +#
> +# This configuration file configure's, make's and install's Renode.
> +#
> +
> +%include %{_configdir}/renode-common-1.cfg
> diff --git a/source-builder/config/renode-common-1.cfg 
> b/source-builder/config/renode-common-1.cfg
> new file mode 100644
> index 000..65be946
> --- /dev/null
> +++ b/source-builder/config/renode-common-1.cfg
> @@ -0,0 +1,45 @@
> +#
> +# Renode from git
> +#
> +
> +%if %{release} == %{nil}
> + %define release 1
> +%endif
> +
> +Name:  renode-%{renode_version}-%{_host}-%{release}
> +Summary:   Renode v%{renode_version}
> +Version:   %{renode_version}
> +Release:   %{release}
> +URL:  http://www.renode.io
> +
> +#
> +# Renode source
> +#
> +%source set renode 
> https://github.com/renode/renode/releases/download/v%{renode_version}/renode_%{renode_version}_source.tar.xz
> +
> +#
> +# Prepare the source code.
> +#
> +%prep
> +  build_top=$(pwd)
> +
> +  source_dir_renode="renode_%{renode_version}_source"
> +  %source setup renode -q -n renode_%{renode_version}_source
> +
> +  cd ${build_top}
> +
> +%build
> +  build_top=$(pwd)
> +
> +  cd ${source_dir_renode}
> +  ./build.sh
> +
> +  cd ${build_top}
> +
> +%install
> +  build_top=$(pwd)
> +
> +  mkdir -p %{_bindir}
> +  cp -r ./${source_dir_renode}/* %{_bindir}
> +
> +  cd ${build_top}
> --
> 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] TMS570 console driver, SCI frame error (baudrate calculation error)

[Gedare Bloom]

No, because we don't have a reproducible test case.

On Fri, Jul 14, 2023 at 7:38 PM zack leung  wrote:
>
> hi, so do you want me make this change?
>
> On Wed, 12 Jul 2023 at 10:54, Gedare Bloom  wrote:
>>
>> On Wed, Jul 12, 2023 at 8:06 AM Joel Sherrill  wrote:
>> >
>> >
>> > Pavel this was filed as https://devel.rtems.org/ticket/4903. The ticket 
>> > submitter
>> > didn't give a patch, just a code change snippet and explanation. Zack 
>> > turned it into
>> > a patch. You will need to post that on the ticket to get the submitter's 
>> > feedback.
>> >
>> > I hope you don't mind copying that to the ticket and seeing what you think 
>> > is
>> > really up.
>> >
>> I posted it over there. Thanks Pavel and Joel.
>>
>> > Thanks.
>> >
>> > --joel
>> >
>> > On Wed, Jul 12, 2023 at 8:49 AM Pavel Pisa  wrote:
>> >>
>> >> Hello Zack and Gedare,
>> >>
>> >> On Tuesday 11 of July 2023 19:52:27 Gedare Bloom wrote:
>> >> > Thanks for the patch. Someone should probably test it, or identify in
>> >> > the documentation why this calculation was off-by-1. Pavel, any clues?
>> >> > On Sun, Jul 9, 2023 at 10:09 PM zack  wrote:
>> >> > > Fixes #4903
>> >> > > diff --git a/bsps/arm/tms570/console/tms570-sci.c
>> >> > > b/bsps/arm/tms570/console/tms570-sci.c index 768770a4c8..59a0b7e6f1
>> >> > > 100644
>> >> > > --- a/bsps/arm/tms570/console/tms570-sci.c
>> >> > > +++ b/bsps/arm/tms570/console/tms570-sci.c
>> >> > > @@ -311,7 +311,7 @@ bool tms570_sci_set_attributes(
>> >> > >/* Apply baudrate to the hardware */
>> >> > >baudrate *= 2 * 16;
>> >> > >bauddiv = (BSP_PLL_OUT_CLOCK + baudrate / 2) / baudrate;
>> >> > > -  ctx->regs->BRS = bauddiv? bauddiv - 1: 0;
>> >> > > +  ctx->regs->BRS = bauddiv? bauddiv - 2: 0;
>> >>
>> >> I think that change is not correct. The actual used values
>> >> for BSP_PLL_OUT_CLOCK and baudrate should be provided to analyze
>> >> the case. The code can result in some rounding error and can
>> >> be enhanced if fractional divider is used or even super finegrained
>> >> fractional divider. But these options are available only for
>> >> for SCI/LIN peripheral case.
>> >>
>> >> According to
>> >>
>> >> TMS570LS31x/21x 16/32-Bit RISC Flash Microcontroller
>> >> Technical Reference Manual
>> >> Literature Number: SPNU499B
>> >>
>> >> 26.2.3 SCI Baud Rate
>> >>
>> >>   SCICLK Frequency = VCLK Frequency / (P + 1 + M / 16)
>> >>
>> >>   Asynchronous baud value = SCICLK Frequency / 16
>> >>
>> >> So the substraction of one corresponds to the manual.
>> >>
>> >> Actual code does not use M part. It would be problem if it is
>> >> leftover from some boot/monitor but it is part of BRS 32-bit
>> >> register which is overwritten in the whole, so such problem
>> >> should not appear either.
>> >>
>> >> So I vote against the proposed change for now and suggest
>> >> to do analysis what happens in the computation and what
>> >> are input values and output. Change would/could affect
>> >> negatively large number of combinations of the baudrate
>> >> and clocks.
>> >>
>> >> I would consider to discuss if the rounding formula
>> >> could/should be updated, but I think that it is the best
>> >> which cane be achieved for rations which do not result
>> >> in exact ratio.
>> >>
>> >>   (BSP_PLL_OUT_CLOCK + baudrate / 2) / baudrate;
>> >>
>> >> If there is interrest then code can be enhanced by fraction
>> >> dividers for SCI/LIN peripheral case. The field with variant
>> >> should be added into tms570_sci_context and in this case
>> >> the alternative formula can be used
>> >>
>> >>   long long bauddiv;
>> >>   bauddiv = (BSP_PLL_OUT_CLOCK * 16ll + baudrate / 2) / baudrate;
>> >>   ctx->regs->BRS = ((bauddiv >> 4) & 0xff) | ((bauddiv & 0xf) << 24);
>> >>
>> >> which should be rewritten after header for SCI/LIN update to
>> >>
>> >>   ctx->regs->BRS = TMS570_LIN_BRS_P(bauddiv >> 4) | 
>> >> TMS570_LIN_BRS_M(bauddiv & 0xf);
>> >
>> >
>> >
>> >>
>> >>
>> >> Best wishes,
>> >>
>> >>
>> >> Pavel
>> >> --
>> >> Pavel Pisa
>> >> phone:  +420 603531357
>> >> e-mail: p...@cmp.felk.cvut.cz
>> >> Department of Control Engineering FEE CVUT
>> >> Karlovo namesti 13, 121 35, Prague 2
>> >> university: http://control.fel.cvut.cz/
>> >> personal:   http://cmp.felk.cvut.cz/~pisa
>> >> projects:   https://www.openhub.net/accounts/ppisa
>> >> CAN related:http://canbus.pages.fel.cvut.cz/
>> >> RISC-V education: https://comparch.edu.cvut.cz/
>> >> Open Technologies Research Education and Exchange Services
>> >> https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
>> >>
>> >> ___
>> >> 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: grlib changes Fwd: New Defects reported by Coverity Scan for RTEMS

[Gedare Bloom]

Sebastian fixed it now. The local variable was shadowed. Another good
reason to keep local variables at the start of a function ;)

On Sat, Jul 15, 2023 at 9:38 AM Joel Sherrill  wrote:
>
>
> The recent grlib changes introduced a Coverity issues.
>
> -- Forwarded message -
> From: 
> Date: Sat, Jul 15, 2023 at 12:22 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 1538314:  Uninitialized variables  (UNINIT)
> /bsps/shared/grlib/uart/apbuart_cons.c: 448 in first_open()
>
>
> 
> *** CID 1538314:  Uninitialized variables  (UNINIT)
> /bsps/shared/grlib/uart/apbuart_cons.c: 448 in first_open()
> 442 return false;
> 443 }
> 444
> 445 uart->sending = 0;
> 446
> 447 /* Turn on RX interrupts */
> >>> CID 1538314:  Uninitialized variables  (UNINIT)
> >>> Using uninitialized value "ctrl".
> 448 ctrl |= APBUART_CTRL_RI;
> 449 if (uart->cap & CAP_DI) {
> 450 /* Use RX FIFO interrupt only if delayed 
> interrupt available. */
> 451 ctrl |= (APBUART_CTRL_DI | APBUART_CTRL_RF);
> 452 }
> 453 }
>
>
> 
> To view the defects in Coverity Scan visit, 
> https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50ypUUzi-2FdSNmuyRB7BEFT8xQ4-2B8hpujh0hTgQljRGId4Dg-3D-3DHAM__EU3W9teASMK00lBXX9WT4lsogDrkCcNZLvg-2FVxwAXMo-2BfWe9y-2FQVPI3NBuKOOB9pEF0PWPhWQO6FUVOcAwwdagvzNKH7AA8SymQIigXNwofEBIHyLL-2FrZJgQDgEg0O4g4HS-2FjBhvvcGAhWWb-2FxsDZrRDyXAMAUd-2BRwY7jJKszizp8zBz7IR2apEMP0z49hqJcf-2F9hLs1Dn-2B7C8NzR5v-2Bdg-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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] TMS570 console driver, SCI frame error (baudrate calculation error)

[Gedare Bloom]

On Wed, Jul 12, 2023 at 8:06 AM Joel Sherrill  wrote:
>
>
> Pavel this was filed as https://devel.rtems.org/ticket/4903. The ticket 
> submitter
> didn't give a patch, just a code change snippet and explanation. Zack turned 
> it into
> a patch. You will need to post that on the ticket to get the submitter's 
> feedback.
>
> I hope you don't mind copying that to the ticket and seeing what you think is
> really up.
>
I posted it over there. Thanks Pavel and Joel.

> Thanks.
>
> --joel
>
> On Wed, Jul 12, 2023 at 8:49 AM Pavel Pisa  wrote:
>>
>> Hello Zack and Gedare,
>>
>> On Tuesday 11 of July 2023 19:52:27 Gedare Bloom wrote:
>> > Thanks for the patch. Someone should probably test it, or identify in
>> > the documentation why this calculation was off-by-1. Pavel, any clues?
>> > On Sun, Jul 9, 2023 at 10:09 PM zack  wrote:
>> > > Fixes #4903
>> > > diff --git a/bsps/arm/tms570/console/tms570-sci.c
>> > > b/bsps/arm/tms570/console/tms570-sci.c index 768770a4c8..59a0b7e6f1
>> > > 100644
>> > > --- a/bsps/arm/tms570/console/tms570-sci.c
>> > > +++ b/bsps/arm/tms570/console/tms570-sci.c
>> > > @@ -311,7 +311,7 @@ bool tms570_sci_set_attributes(
>> > >/* Apply baudrate to the hardware */
>> > >baudrate *= 2 * 16;
>> > >bauddiv = (BSP_PLL_OUT_CLOCK + baudrate / 2) / baudrate;
>> > > -  ctx->regs->BRS = bauddiv? bauddiv - 1: 0;
>> > > +  ctx->regs->BRS = bauddiv? bauddiv - 2: 0;
>>
>> I think that change is not correct. The actual used values
>> for BSP_PLL_OUT_CLOCK and baudrate should be provided to analyze
>> the case. The code can result in some rounding error and can
>> be enhanced if fractional divider is used or even super finegrained
>> fractional divider. But these options are available only for
>> for SCI/LIN peripheral case.
>>
>> According to
>>
>> TMS570LS31x/21x 16/32-Bit RISC Flash Microcontroller
>> Technical Reference Manual
>> Literature Number: SPNU499B
>>
>> 26.2.3 SCI Baud Rate
>>
>>   SCICLK Frequency = VCLK Frequency / (P + 1 + M / 16)
>>
>>   Asynchronous baud value = SCICLK Frequency / 16
>>
>> So the substraction of one corresponds to the manual.
>>
>> Actual code does not use M part. It would be problem if it is
>> leftover from some boot/monitor but it is part of BRS 32-bit
>> register which is overwritten in the whole, so such problem
>> should not appear either.
>>
>> So I vote against the proposed change for now and suggest
>> to do analysis what happens in the computation and what
>> are input values and output. Change would/could affect
>> negatively large number of combinations of the baudrate
>> and clocks.
>>
>> I would consider to discuss if the rounding formula
>> could/should be updated, but I think that it is the best
>> which cane be achieved for rations which do not result
>> in exact ratio.
>>
>>   (BSP_PLL_OUT_CLOCK + baudrate / 2) / baudrate;
>>
>> If there is interrest then code can be enhanced by fraction
>> dividers for SCI/LIN peripheral case. The field with variant
>> should be added into tms570_sci_context and in this case
>> the alternative formula can be used
>>
>>   long long bauddiv;
>>   bauddiv = (BSP_PLL_OUT_CLOCK * 16ll + baudrate / 2) / baudrate;
>>   ctx->regs->BRS = ((bauddiv >> 4) & 0xff) | ((bauddiv & 0xf) << 24);
>>
>> which should be rewritten after header for SCI/LIN update to
>>
>>   ctx->regs->BRS = TMS570_LIN_BRS_P(bauddiv >> 4) | TMS570_LIN_BRS_M(bauddiv 
>> & 0xf);
>
>
>
>>
>>
>> Best wishes,
>>
>>
>> Pavel
>> --
>> Pavel Pisa
>> phone:  +420 603531357
>> e-mail: p...@cmp.felk.cvut.cz
>> Department of Control Engineering FEE CVUT
>> Karlovo namesti 13, 121 35, Prague 2
>> university: http://control.fel.cvut.cz/
>> personal:   http://cmp.felk.cvut.cz/~pisa
>> projects:   https://www.openhub.net/accounts/ppisa
>> CAN related:http://canbus.pages.fel.cvut.cz/
>> RISC-V education: https://comparch.edu.cvut.cz/
>> Open Technologies Research Education and Exchange Services
>> https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
>>
>> ___
>> 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 rtems-source-builder] bare/config: add renode rsb installation config

[Gedare Bloom]

On Tue, Jul 11, 2023 at 12:01 PM Gedare Bloom  wrote:
>
> This probably requires some documentation, as it requires several
> packages that are not going to be typically installed already by RTEMS
> users/developers. Chris, is there any place to document required
> dependencies/packages for a build set?
>
> The patch has a whitespace problem
>
> +# Renode source
> +#
>  It might be a non-ASCII character, as it gets eaten by email but is
> in the patch file.
>
> Gedare
>
> On Mon, Jul 10, 2023 at 5:13 AM Muhammad Sulthan Mazaya
>  wrote:
> >
> > An implementation of renode rsb installation config. It uses renode's
> > github release as source and build the package using their build script.
> >
> > ---
> >  bare/config/devel/renode-git-1.cfg | 47 ++
> >  bare/config/devel/renode.bset  |  9 ++
> >  2 files changed, 56 insertions(+)
> >  create mode 100644 bare/config/devel/renode-git-1.cfg
> >  create mode 100644 bare/config/devel/renode.bset
> >
> > diff --git a/bare/config/devel/renode-git-1.cfg 
> > b/bare/config/devel/renode-git-1.cfg
> > new file mode 100644
> > index 000..df424a6
> > --- /dev/null
> > +++ b/bare/config/devel/renode-git-1.cfg
Probably want to put most of this file into
./source-builder/config/renode-common-1.cfg
and set parameters for it (version) from a new file
./bare/config/devel/renode-1.13.3-1.cfg

I would recommend that you follow the design for how qemu gets built.

> > @@ -0,0 +1,47 @@
> > +#
> > +# Renode from github
> > +#
> > +
> > +%if %{release} == %{nil}
> > + %define release 1
> > +%endif
> > +
> > +%define renode_version 1.13.3
> > +
> > +Name:  renode-%{renode_version}-%{_host}-%{release}
> > +Summary:   Renode v%{renode_version}
> > +Version:   %{renode_version}
> > +Release:   %{release}
> > +URL:  http://www.renode.io
> > +
> > +#
> > +# Renode source
> > +#
> > +%source set renode 
> > https://github.com/renode/renode/releases/download/v%{renode_version}/renode_%{renode_version}_source.tar.xz
> > +
> > +#
> > +# Prepare the source code.
> > +#
> > +%prep
> > +  build_top=$(pwd)
> > +
> > +  source_dir_renode="renode_%{renode_version}_source"
> > +  %source setup renode -q -n renode_%{renode_version}_source
> > +
> > +  cd ${build_top}
> > +
> > +%build
> > +  build_top=$(pwd)
> > +
> > +  cd ${source_dir_renode}
> > +  ./build.sh
This looks brittle. Does their script handle host detection, etc?

> > +
> > +  cd ${build_top}
> > +
> > +%install
> > +  build_top=$(pwd)
> > +
> > +  mkdir -p %{_bindir}
> > +  cp -r ./${source_dir_renode}/* %{_bindir}
> > +
> > +  cd ${build_top}
> > diff --git a/bare/config/devel/renode.bset b/bare/config/devel/renode.bset
> > new file mode 100644
> > index 000..d64a2a2
> > --- /dev/null
> > +++ b/bare/config/devel/renode.bset
Add the version to the build set name and pass that through to the
build instructions.

> > @@ -0,0 +1,9 @@
> > +#
> > +# Build set for Renode
> > +#
> > +
> > +%if %{release} == %{nil}
> > +%define release 1
> > +%endif
> > +
> > +devel/renode-git-1
the "-git" name is usually used to build the git head or a specific commit.
SInce you build a release version, you should prefer to use the
version numbering to identify what gets built.

> > --
> > 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 rtems-source-builder] bare/config: add renode rsb installation config

[Gedare Bloom]

This probably requires some documentation, as it requires several
packages that are not going to be typically installed already by RTEMS
users/developers. Chris, is there any place to document required
dependencies/packages for a build set?

The patch has a whitespace problem

+# Renode source
+#
 It might be a non-ASCII character, as it gets eaten by email but is
in the patch file.

Gedare

On Mon, Jul 10, 2023 at 5:13 AM Muhammad Sulthan Mazaya
 wrote:
>
> An implementation of renode rsb installation config. It uses renode's
> github release as source and build the package using their build script.
>
> ---
>  bare/config/devel/renode-git-1.cfg | 47 ++
>  bare/config/devel/renode.bset  |  9 ++
>  2 files changed, 56 insertions(+)
>  create mode 100644 bare/config/devel/renode-git-1.cfg
>  create mode 100644 bare/config/devel/renode.bset
>
> diff --git a/bare/config/devel/renode-git-1.cfg 
> b/bare/config/devel/renode-git-1.cfg
> new file mode 100644
> index 000..df424a6
> --- /dev/null
> +++ b/bare/config/devel/renode-git-1.cfg
> @@ -0,0 +1,47 @@
> +#
> +# Renode from github
> +#
> +
> +%if %{release} == %{nil}
> + %define release 1
> +%endif
> +
> +%define renode_version 1.13.3
> +
> +Name:  renode-%{renode_version}-%{_host}-%{release}
> +Summary:   Renode v%{renode_version}
> +Version:   %{renode_version}
> +Release:   %{release}
> +URL:  http://www.renode.io
> +
> +#
> +# Renode source
> +#
> +%source set renode 
> https://github.com/renode/renode/releases/download/v%{renode_version}/renode_%{renode_version}_source.tar.xz
> +
> +#
> +# Prepare the source code.
> +#
> +%prep
> +  build_top=$(pwd)
> +
> +  source_dir_renode="renode_%{renode_version}_source"
> +  %source setup renode -q -n renode_%{renode_version}_source
> +
> +  cd ${build_top}
> +
> +%build
> +  build_top=$(pwd)
> +
> +  cd ${source_dir_renode}
> +  ./build.sh
> +
> +  cd ${build_top}
> +
> +%install
> +  build_top=$(pwd)
> +
> +  mkdir -p %{_bindir}
> +  cp -r ./${source_dir_renode}/* %{_bindir}
> +
> +  cd ${build_top}
> diff --git a/bare/config/devel/renode.bset b/bare/config/devel/renode.bset
> new file mode 100644
> index 000..d64a2a2
> --- /dev/null
> +++ b/bare/config/devel/renode.bset
> @@ -0,0 +1,9 @@
> +#
> +# Build set for Renode
> +#
> +
> +%if %{release} == %{nil}
> +%define release 1
> +%endif
> +
> +devel/renode-git-1
> --
> 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] TMS570 console driver, SCI frame error (baudrate calculation error)

[Gedare Bloom]

Hi Zack,

Thanks for the patch. Someone should probably test it, or identify in
the documentation why this calculation was off-by-1. Pavel, any clues?

Gedare

On Sun, Jul 9, 2023 at 10:09 PM zack  wrote:
>
> Fixes #4903
> diff --git a/bsps/arm/tms570/console/tms570-sci.c 
> b/bsps/arm/tms570/console/tms570-sci.c
> index 768770a4c8..59a0b7e6f1 100644
> --- a/bsps/arm/tms570/console/tms570-sci.c
> +++ b/bsps/arm/tms570/console/tms570-sci.c
> @@ -311,7 +311,7 @@ bool tms570_sci_set_attributes(
>/* Apply baudrate to the hardware */
>baudrate *= 2 * 16;
>bauddiv = (BSP_PLL_OUT_CLOCK + baudrate / 2) / baudrate;
> -  ctx->regs->BRS = bauddiv? bauddiv - 1: 0;
> +  ctx->regs->BRS = bauddiv? bauddiv - 2: 0;
>
>ctx->regs->GCR1 |= TMS570_SCI_GCR1_SWnRST | TMS570_SCI_GCR1_TXENA |
>   TMS570_SCI_GCR1_RXENA;
> --
> 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: Need community suggestions for a new generic GPIO API

[Gedare Bloom]

On Tue, Jul 11, 2023 at 7:05 AM Christian MAUDERER
 wrote:
>
> Hello Utkarsh,
>
> please be a bit careful with GPIO and pin functions. That's a quite
> difficult topic.
>
> Some controller manufacturers mix these functions. One such example is
> the STM32 family. I'll take the STM32F410 as an example. That chip has a
> GPIO register block with one GPIOx_MODER where you can select whether a
> pin is a Input, GPIO, alternate function or analog mode. There is also a
> GPIOx_OSPEEDR that defines speed and some others that define pull ups /
> downs and so on.
>
> Other controllers - like a lot of the NXP ones - have two completely
> independent modules for that. I'll take the i.MXRT1050 series as an
> example: That chip has an IOMUXC where you can set a pin function for a
> pad. For example, there is a register IOMUXC_SW_MUX_CTL_PAD_GPIO_EMC_26.
> In that register, you can set a pin function of GPIO4_IO26. There is a
> related PAD_CTL register in the IOMUXC where you can set up pull ups /
> downs, drive strength and so on. The GPIO controller where you set up
> levels and interrupts for that pin is a completely unrelated module. On
> the i.MXRT1166 you can even assign some pins to two different GPIO
> controllers. So it's not possible to have a 1:1 mapping between pin and
> GPIO.
>
> If you ask me GPIO and pin function are two separate things and need two
> APIs. That should make it possible to support controllers like the STM32
> (where some of the GPIO registers would be controlled by the GPIO API
> and some by the pin function API) and for controllers like the i.MXRT
> where the two APIs would handle different hardware modules.
>
> If you take a look at Linux or FreeBSD, they usually split that up just
> like that. If you want to dig deeper into that, maybe it would be worth
> to take a look at some other embedded operating systems. For example
> Zephyr or Contiki or any of the ones in Wikipedia "Comparison of
> real-time operating systems". It can even be a good idea to create a
> compatible interface.
>
This reminds me that I think the pinmux was lifted out of libbsd and
put into RTEMS for the BBB.
* shared/freebsd/sys/arm/ti/ti_pinmux.c

This may be the right direction to go for other targets, where they
have support in FreeBSD. And where they don't, compliance to that
pinmux API may be preferable.

> Best regards
>
> Christian
>
> On 2023-07-07 21:48, Utkarsh Verma wrote:
> > Dear all,
> >
> > While working on the Raspberry Pi 4 BSP, I realized that the GPIO API
> > could be improved. It seems that last year, a GSoC student worked on
> > introducing a new GPIO API, called GPIO2 to RTEMS. However, it did not
> > get merged. Discussing this topic with my mentor and on RTEMS Discord
> > revealed that it would be a good idea to get it merged. For that, I
> > would like to ask the community the following:
> >
> > - Moving forward, will GPIO2 API be the community-preferred GPIO API?
> > - What would be the recommended way in this new API to select
> > alternate pin functions? Will that be left for the BSP to decide?
> >
> > Here are the links associated with GPIO2:
> > Git Repo: https://github.com/dtbpkmte/GSoC-2022-RTEMS
> > GPIO2 commit: 
> > https://github.com/dtbpkmte/GSoC-2022-RTEMS/commit/0aec268f1209c
> > Blog post about the API:
> > https://medium.com/@dtbpkmte/gsoc-2022-rtems-coding-period-week-4-gpio-wiki-1f10e5c4458
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
> --
> 
> embedded brains GmbH & Co. KG
> Herr Christian MAUDERER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email:  christian.maude...@embedded-brains.de
> phone:  +49-89-18 94 741 - 18
> mobile: +49-176-152 206 08
>
> 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: What Happened to _Thread_Close?

[Gedare Bloom]

Hi Joel,

_Thread_Close() was refactored into _Thread_Join() and _Thread_Cancel().

https://git.rtems.org/rtems/commit/?id=232147ddc12d45ff7872f72a790077c26fe5ca0a

-Gedare

On Fri, Jul 7, 2023 at 1:50 PM Joel Sherrill  wrote:
>
> Hi
>
> Building the rtems-examples, the test fat_ramdisk gets a failure from 
> rtems-tld because _Thread_Close is still listed in the ini files it uses.
>
> What symbols should be in the sections that currently have _Thread_Close?
>
> Small patch below my signature which just removes _Thread_Close references. I 
> am assuming something may need to be added but I don't know what changed 
> removed _Thread_Close.
>
> Thanks.
>
> ---joel
>
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] spec: Add QEMU test annotations

[Gedare Bloom]

On Thu, Jul 6, 2023 at 12:48 PM Kinsey Moore  wrote:
>
> QEMU is known to fail certain tests intermittently due to clock tick
> delivery issues. This defines those tests as intermittent for BSPs
> intended to run on QEMU alone.
>
> Updates #4922
> Updates #4072
> ---
>  spec/build/bsps/aarch64/a53/tsta53.yml| 33 +
>  spec/build/bsps/aarch64/a72/tsta72.yml| 33 +
>  .../bsps/aarch64/xilinx-versal/tstqemu.yml|  4 +-
>  .../bsps/aarch64/xilinx-zynqmp/tstqemu.yml| 33 +
>  .../arm/realview-pbx-a9/bsprealviewpbxa9.yml  |  2 +
>  spec/build/bsps/arm/xilinx-zynq/bspqemu.yml   |  2 +
>  spec/build/bsps/tstqemu.yml   | 72 +++
>  7 files changed, 88 insertions(+), 91 deletions(-)
>  create mode 100644 spec/build/bsps/tstqemu.yml
>
> diff --git a/spec/build/bsps/aarch64/a53/tsta53.yml 
> b/spec/build/bsps/aarch64/a53/tsta53.yml
> index a3d8c9810d..adf6d85ae1 100644
> --- a/spec/build/bsps/aarch64/a53/tsta53.yml
> +++ b/spec/build/bsps/aarch64/a53/tsta53.yml
> @@ -6,40 +6,13 @@ actions:
>  state: exclude
>  tests:
>  - minimum
> -- set-test-state:
> -reason: |
> -  Tests that are passing intermittently.
> -state: indeterminate
> -tests:
> -- psx12
> -- psxtimes01
> -- rtmonuse
> -- rtmonusxtimes01
> -- sp04
> -- sp20
> -- sp68
> -- sp69
> -- spcpucounter01
> -- spedfsched02
> -- spedfsched04
> -- sprmsched01
> -- sptimecounter02
> -- sptimecounter04
> -- ttest02
> -- set-test-state:
> -reason: |
> -  Tests that pass nominally, but fail under Qemu when the host is under
> -  heavy load.
> -state: indeterminate
> -tests:
> -- spintrcritical03
> -- spintrcritical04
> -- spintrcritical05
>  build-type: option
>  copyrights:
>  - Copyright (C) 2020 On-Line Applications Research (OAR)
>  default: []
>  description: ''
>  enabled-by: true
> -links: []
> +links:
> +- role: build-dependency
> +  uid: ../../tstqemu
>  type: build
> diff --git a/spec/build/bsps/aarch64/a72/tsta72.yml 
> b/spec/build/bsps/aarch64/a72/tsta72.yml
> index a3d8c9810d..adf6d85ae1 100644
> --- a/spec/build/bsps/aarch64/a72/tsta72.yml
> +++ b/spec/build/bsps/aarch64/a72/tsta72.yml
> @@ -6,40 +6,13 @@ actions:
>  state: exclude
>  tests:
>  - minimum
> -- set-test-state:
> -reason: |
> -  Tests that are passing intermittently.
> -state: indeterminate
> -tests:
> -- psx12
> -- psxtimes01
> -- rtmonuse
> -- rtmonusxtimes01
> -- sp04
> -- sp20
> -- sp68
> -- sp69
> -- spcpucounter01
> -- spedfsched02
> -- spedfsched04
> -- sprmsched01
> -- sptimecounter02
> -- sptimecounter04
> -- ttest02
> -- set-test-state:
> -reason: |
> -  Tests that pass nominally, but fail under Qemu when the host is under
> -  heavy load.
> -state: indeterminate
> -tests:
> -- spintrcritical03
> -- spintrcritical04
> -- spintrcritical05
>  build-type: option
>  copyrights:
>  - Copyright (C) 2020 On-Line Applications Research (OAR)
>  default: []
>  description: ''
>  enabled-by: true
> -links: []
> +links:
> +- role: build-dependency
> +  uid: ../../tstqemu
>  type: build
> diff --git a/spec/build/bsps/aarch64/xilinx-versal/tstqemu.yml 
> b/spec/build/bsps/aarch64/xilinx-versal/tstqemu.yml
> index 0a0ab619af..69b85cadbd 100644
> --- a/spec/build/bsps/aarch64/xilinx-versal/tstqemu.yml
> +++ b/spec/build/bsps/aarch64/xilinx-versal/tstqemu.yml
> @@ -12,5 +12,7 @@ copyrights:
>  default: []
>  description: ''
>  enabled-by: true
> -links: []
> +links:
> +- role: build-dependency
> +  uid: ../../tstqemu
>  type: build
> diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/tstqemu.yml 
> b/spec/build/bsps/aarch64/xilinx-zynqmp/tstqemu.yml
> index a3d8c9810d..adf6d85ae1 100644
> --- a/spec/build/bsps/aarch64/xilinx-zynqmp/tstqemu.yml
> +++ b/spec/build/bsps/aarch64/xilinx-zynqmp/tstqemu.yml
> @@ -6,40 +6,13 @@ actions:
>  state: exclude
>  tests:
>  - minimum
> -- set-test-state:
> -reason: |
> -  Tests that are passing intermittently.
> -state: indeterminate
> -tests:
> -- psx12
> -- psxtimes01
> -- rtmonuse
> -- rtmonusxtimes01
> -- sp04
> -- sp20
> -- sp68
> -- sp69
> -- spcpucounter01
> -- spedfsched02
> -- spedfsched04
> -- sprmsched01
> -- sptimecounter02
> -- sptimecounter04
> -- ttest02
> -- set-test-state:
> -reason: |
> -  Tests that pass nominally, but fail under Qemu when the host is under
> -  heavy load.
> -state: indeterminate
> -tests:
> -- spintrcritical03
> -- spintrcritical04
> -- spintrcritical05
>  build-type: option
>  copyrights:
>  - Copyright (C) 2020 On-Line Applications Research (OAR)
>  default: []
>  description: ''
>  enabled-by: true
> -links: []
> +links:
> +- role: build-dependency
> +  uid: ../../tstqemu
>  type: build
> diff 

Re: Add currently best clang-format configuration to repository?

[Gedare Bloom]

On Wed, Jul 5, 2023 at 5:27 PM Chris Johns  wrote:
>
> On 6/7/2023 4:21 am, Gedare Bloom wrote:
> > OK I will prepare something soon. I have my WIP version at
> > https://git.rtems.org/gedare/rtems.git/tree/_clang-format?h=test-reformat
> >
> > I think the format file itself should be just about stable. I will
> > make one more test and check of it within the next few days, and then
> > send the patch hopefully early next week.
>
> How will the version of clang-format we need be handled?
>
> Will an older version complain if our style is used with it? I am concerned I
> use and trust the output however I make a mistake and use an old clang-format
> that does not generate the correct format. I doubt I would spot that happening
> when reviewing the output.
>
Certain (new) options in the style file will/can trigger an error that
terminates the reformatting in (older) versions of clang-format that
don't support the given option. I think we would be in that territory
with our style.

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

Re: [PATCH rtems-docs v3] c-user: Update references to rtems_task_wake_after

[Gedare Bloom]

This looks good to me. The only other thing worth mentioning, that is
not mentioned, is that this directive provides an "upper bound"
(maximum sleeping time) on how long a task might be non-schedulable,
whereas other sleep directives tend to provide a "lower bound"
(minimum sleeping time). At any rate, you've captured the main point.

On Wed, Jul 5, 2023 at 2:48 PM Kinsey Moore  wrote:
>
> rtems_task_wake_after takes a parameter in terms of a count of clock
> ticks and not a measure in a subunit of seconds. This updates
> documentation to reflect that. This also makes obvious the caveat about
> the first tick wait not being a whole tick and points the user at a
> replacement for better accuracy.
>
> Updates #4772
> ---
>  c-user/scheduling-concepts/background.rst |  8 +++
>  c-user/task/directives.rst| 27 ++-
>  c-user/task/introduction.rst  |  4 ++--
>  c-user/task/operations.rst|  6 ++---
>  4 files changed, 25 insertions(+), 20 deletions(-)
>
> diff --git a/c-user/scheduling-concepts/background.rst 
> b/c-user/scheduling-concepts/background.rst
> index 1fe7089..38b77ee 100644
> --- a/c-user/scheduling-concepts/background.rst
> +++ b/c-user/scheduling-concepts/background.rst
> @@ -160,7 +160,7 @@ Manual Round-Robin
>
>  The final mechanism for altering the RTEMS scheduling algorithm is called
>  manual round-robin.  Manual round-robin is invoked by using
> -the ``rtems_task_wake_after`` directive with a time interval of
> +the ``rtems_task_wake_after`` directive with a ``ticks`` parameter of
>  ``RTEMS_YIELD_PROCESSOR``.  This allows a task to give up the processor and 
> be
>  immediately returned to the ready chain at the end of its priority group.  If
>  no other tasks of the same priority are ready to run, then the task does not
> @@ -243,7 +243,7 @@ of the following conditions:
>option and the requested semaphore is unavailable.
>
>  - The running task issues a ``rtems_task_wake_after`` directive which blocks
> -  the task for the given time interval.  If the time interval specified is
> +  the task for the given count of ticks.  If the count of ticks specified is
>zero, the task yields the processor and remains in the ready state.
>
>  - The running task issues a ``rtems_task_wake_when`` directive which blocks 
> the
> @@ -280,8 +280,8 @@ conditions:
>  - A running task issues a ``rtems_semaphore_release`` directive which 
> releases
>the semaphore on which the blocked task is waiting.
>
> -- A timeout interval expires for a task which was blocked by a call to the
> -  ``rtems_task_wake_after`` directive.
> +- The requested count of ticks has elapsed for a task which was blocked by a
> +  call to the ``rtems_task_wake_after`` directive.
>
>  - A timeout period expires for a task which blocked by a call to the
>``rtems_task_wake_when`` directive.
> diff --git a/c-user/task/directives.rst b/c-user/task/directives.rst
> index c082b51..ea2337a 100644
> --- a/c-user/task/directives.rst
> +++ b/c-user/task/directives.rst
> @@ -1475,16 +1475,16 @@ The following constraints apply to this directive:
>  \clearpage
>
>  .. index:: rtems_task_wake_after()
> -.. index:: delay a task for an interval
> -.. index:: wake up after an interval
> +.. index:: delay a task for a count of clock ticks
> +.. index:: wake up after a count of clock ticks
>
>  .. _InterfaceRtemsTaskWakeAfter:
>
>  rtems_task_wake_after()
>  ---
>
> -Wakes up after an interval in :term:`clock ticks ` or yields the
> -processor.
> +Wakes up after a count of :term:`clock ticks ` have occurred or
> +yields the processor.
>
>  .. rubric:: CALLING SEQUENCE:
>
> @@ -1495,16 +1495,16 @@ processor.
>  .. rubric:: PARAMETERS:
>
>  ``ticks``
> -This parameter is the interval in :term:`clock ticks ` to 
> delay
> +This parameter is the count of :term:`clock ticks ` to delay
>  the task or :c:macro:`RTEMS_YIELD_PROCESSOR` to yield the processor.
>
>  .. rubric:: DESCRIPTION:
>
> -This directive blocks the calling task for the specified ``ticks`` of clock
> -ticks if the value is not equal to :c:macro:`RTEMS_YIELD_PROCESSOR`.  When 
> the
> -requested interval has elapsed, the task is made ready.  The clock tick
> -directives automatically updates the delay period.  The calling task may give
> -up the processor and remain in the ready state by specifying a value of
> +This directive blocks the calling task for the specified ``ticks`` count of
> +clock ticks if the value is not equal to :c:macro:`RTEMS_YIELD_PROCESSOR`. 
> When
> +the requested count of ticks have occurred, the task is made ready.  The 
> clock
> +tick directives automatically update the delay period.  The calling task may
> +give up the processor and remain in the ready state by specifying a value of
>  :c:macro:`RTEMS_YIELD_PROCESSOR` in ``ticks``.
>
>  .. rubric:: RETURN VALUES:
> @@ -1516,7 +1516,12 @@ up the processor and remain in the ready state by 
> specifying a 

Re: Add currently best clang-format configuration to repository?

[Gedare Bloom]

OK I will prepare something soon. I have my WIP version at
https://git.rtems.org/gedare/rtems.git/tree/_clang-format?h=test-reformat

I think the format file itself should be just about stable. I will
make one more test and check of it within the next few days, and then
send the patch hopefully early next week.

On Fri, Jun 30, 2023 at 1:44 AM Sebastian Huber
 wrote:
>
> Hello,
>
> even though the clang-format support for RTEMS is not yet perfect, I
> think it would still make sense to already add the clang format file to
> the RTEMS repository. This helps to get the currently best thing
> available and for example use it for new code (BSPs).
>
> --
> 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: rtems-docs [PATCH] README: Fixing spelling and grammar errors

[Gedare Bloom]

LGTM someone can pick this up. Ping in a week if not done by then.

On Thu, Jun 15, 2023 at 7:15 PM Stanley Paulauskas  wrote:
>
> Hello, RTEMS Devs!
>
> Please find attached a patch for rtems-docs/README.txt that fixes some 
> grammatical and spelling errors. Since this is my first submission, I went 
> through the Checklist for Patches. I *think* I have everything covered. 
> Please let me know if I need any updates or changes.
>
> Best,
> Stan
> 
> Stanley Paulauskas, Ph. D., PMP
> Solutions Architect, XIA LLC
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] eng: Add guidelines for validation tests

[Gedare Bloom]

On Thu, Jun 15, 2023 at 11:09 PM Sebastian Huber
 wrote:
>
> Update #3717.
> ---
> v2:
>
> * Mention that file name should be unique.
> * Clarify file name parts.
> * Add examples for enabled-by expressions.
>
>  eng/req/howto.rst | 80 +++
>  1 file changed, 80 insertions(+)
>
> diff --git a/eng/req/howto.rst b/eng/req/howto.rst
> index 0de3c01..125dac5 100644
> --- a/eng/req/howto.rst
> +++ b/eng/req/howto.rst
> @@ -1127,6 +1127,86 @@ the following post-condition states.
>parameter in past calls to ${../if/directive:/name} shall not be
>accessed by the ${../if/directive:/name} call.
>
> +Validation Test Guidelines
> +--
> +
> +The validation test cases, test runners, and test suites are generated by the
> +``./spec2modules.py`` script from specification items.  For the placement and
> +naming of the generated sources use the following rules:
> +
> +* Place architecture-specific validation test sources and programs into the
> +  ``testsuites/validation/cpu`` directory.
> +
> +* Place BSP-specific validation test sources and programs into the
> +  ``testsuites/validation/bsps`` directory.
> +
> +* Place all other validation test sources and programs into the
> +  ``testsuites/validation`` directory.
> +
> +* Place architecture-specific unit test sources and programs into the
> +  ``testsuites/unit/cpu`` directory.
> +
> +* Place BSP-specific unit test sources and programs into the
> +  ``testsuites/unit/bsps`` directory.
> +
> +* Place all other unit test sources and programs into the
> +  ``testsuites/unit`` directory.
> +
> +* Use dashes (``-``) to separate parts of a file name.  Use only dashes, the
> +  digits ``0`` to ``9``, and the lower case characters ``a`` to ``z`` for 
> file
> +  names.  In particular, do not use underscores (``_``).
> +
> +* The parts of a file name shall be separated by dashes and ordered from most
> +  general (left) to more specific (right), for example 
> ``tc-task-construct.c``.
> +
> +* The file names associated with tests shall be unique within the system 
> since
> +  the test framework prints out only the base file names.
> +
> +* Use the prefix ``tc-`` for test case files.
> +
> +* Use the prefix ``tr-`` for test runner files.
> +
> +* Use the prefix ``ts-`` for test suite files.
> +
> +* Use the prefix ``tx-`` for test extension files (test support code).
> +
> +* Tests for fatal errors shall have ``fatal`` as the most general file part,
> +  for example ``ts-fatal-too-large-tls-size.c``.
> +
> +* Validation test suites shall have ``validation`` as the most general file
> +  part, for example ``ts-validation-no-clock-0.c``.
> +
> +* Unit test suites shall have ``unit`` as the most general file part, for
> +  example ``ts-unit-no-clock-0.c``.
> +
> +* Architecture-specific files shall have the architecture name as a file 
> part,
> +  for example ``ts-fatal-sparc-leon3-clock-initialization.c``.
> +
> +* BSP-specific files shall have the BSP family or variant name as a file 
> part,
> +  for example ``tc-sparc-gr712rc.c``.
> +
> +* Architecture-specific or BSP-specific tests shall use the ``enabled-by``
> +  attribute of the associated specification item to make the build item
> +  conditional, for example:
> +
> +  .. code-block:: yaml
> +
> +  ...
> +  build-type: objects
> +  enabled-by: arm
> +  type: build
> +  ...
> +
> +  .. code-block:: yaml
> +
> +  ...
> +  build-type: test-program
> +  enabled-by: bsps/sparc/leon3
> +  type: build
> +  ...
> +
> +
> +
I think too many new lines

Otherwise, looks good

>  Verify the Specification Items
>  --
>
> --
> 2.35.3
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: bsps/xilinx-zynqmp : Add BSP for RPU

[Gedare Bloom]

On Fri, Jun 16, 2023 at 2:17 AM Philip Kirkpatrick
 wrote:
>
>
>
> On Fri, Jun 16, 2023 at 7:14 AM Chris Johns  wrote:
>>
>> On 15/6/2023 6:16 pm, Philip Kirkpatrick wrote:
>> > Thanks for all the good feedback.
>> >
>> > RE Joel:
>> > I'll fix my sloppy formatting that you caught and submit a revised patch.  
>> > If
>> > I'm realistic about my schedule, I probably won't be able to get to it 
>> > until
>> > next week.
>> > For xttcps_hw.h, there already is one #ifndef __rtems__ around the 
>> > #includes,
>> > but on review there is another spot where I got lazy and used a #if 0.  
>> > I'll
>> > correct that too.  Other than that, the file is unmodified.
>> >
>> > On the discussion about a shared space, I'll leave that decision up to you.
>> > Tell me what you want and I can adjust as needed, or it could be done in a
>> > follow-on patch.
>>
>> Should the RPU BSP be located under bsps/arm/xilinx-rpu?
>
>
> I went back and forth on that decision and decided to keep them combined 
> since the APU and RPU share a moderate amount of code.  However, I can 
> definitely see an argument that they are different enough to split.  If you 
> want it the other way, I can make that change when I address the other items.
>
I think we should split it out. Shared code should likely be
refactored to arm/shared depending what that is.

I'm not sure that carrying forward a 32-bit arm/xilinx-zynqmp makes
sense now that we have a functional aarch64 port. Splitting the RPU
out will make it easier to make that decision.

>>
>> > For the Versal, I've never used that part and am not very familiar with 
>> > it, but
>> > the feedback from Aaron makes it sound like the core is probably pretty
>> > similar.  One other possible difference would be in the timers but it does 
>> > look
>> > like the Versal has the same TTCs.  There just may be a small bit of work 
>> > to set
>> > up the clock input to it.
>>
>> We would handle the Versal once the BSP has a home.
>>
>> 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] eng: Add guidelines for validation tests

[Gedare Bloom]

LGTM

On Thu, Jun 15, 2023 at 4:06 AM Sebastian Huber
 wrote:
>
> On 15.06.23 11:28, Frank Kühndel wrote:
> >
> >> +
> >> +* Tests for fatal errors shall have ``fatal`` as the most general
> >> file part,
> >> +  for example ``ts-fatal-too-large-tls-size.c``.
> >> +
> >> +* Validation test suites shall have ``validation`` as the most
> >> general file
> >> +  part, for example ``ts-validation-no-clock-0.c``.
> >> +
> >> +* Unit test suites shall have ``unit`` as the most general file part,
> >> for
> >> +  example ``ts-unit-no-clock-0.c``.
> >> +
> >> +* Architecture-specific files shall have the architecture name as a
> >> file part,
> >> +  for example ``ts-fatal-sparc-leon3-clock-initialization.c``.
> >
> > I wonder whether ``ts-sparc-leon3-fatal-clock-initialization.c`` would
> > be more logical?
>
> So far, by definition the test category (unit, validation, performance,
> fatal, mem) is the most general category. I don't want to move existing
> things unnecessarily around, this should stay as it is.
>
> --
> 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: BSP-Specific Testing was: [PATCH 00/34] Integrate pre-qualified LEON3 BSP

[Gedare Bloom]

On Wed, Jun 14, 2023 at 11:59 AM Sebastian Huber
 wrote:
>
> On 14.06.23 18:13, Gedare Bloom wrote:
> >>> I think we should have some of the BSP-specific tests under some other
> >>> location in testsuites, while others would be under validation where
> >>> they are used for pre-qualification?
> >>>
> >>> Maybe it is sensible to introduce testsuites/bsps/ also.
> >> For the unit tests I would use testsuites/unit/bsps and 
> >> testsuites/unit/cpu.
> >>
> > I like this.
>
> Should the test programs be placed in a "bsps", "bsp", or "cpu"
> directory also:
>
'bsps' and 'cpu' are consistent with other parts of the tree. So that
would be my preference. It can be renamed if really needed later.

> [666/671] Linking
> build/sparc/gr740/testsuites/validation/ts-validation-timecounter-0.exe
> [667/671] Linking
> build/sparc/gr740/testsuites/validation/ts-validation-timecounter-smp-0.exe
> [668/671] Linking
> build/sparc/gr740/testsuites/validation/bsps/ts-fatal-sparc-leon3-cache-snooping-disabled-boot.exe
> [669/671] Linking
> build/sparc/gr740/testsuites/validation/bsps/ts-fatal-sparc-leon3-cache-snooping-disabled-secondary.exe
> [670/671] Linking
> build/sparc/gr740/testsuites/validation/bsps/ts-fatal-sparc-leon3-clock-initialization.exe
> [671/671] Linking
> build/sparc/gr740/testsuites/validation/bsps/ts-fatal-sparc-leon3-shutdown.exe
>
> vs.
>
> [666/671] Linking
> build/sparc/gr740/testsuites/validation/ts-validation-timecounter-0.exe
> [667/671] Linking
> build/sparc/gr740/testsuites/validation/ts-validation-timecounter-smp-0.exe
> [668/671] Linking
> build/sparc/gr740/testsuites/validation/ts-fatal-sparc-leon3-cache-snooping-disabled-boot.exe
> [669/671] Linking
> build/sparc/gr740/testsuites/validation/ts-fatal-sparc-leon3-cache-snooping-disabled-secondary.exe
> [670/671] Linking
> build/sparc/gr740/testsuites/validation/ts-fatal-sparc-leon3-clock-initialization.exe
> [671/671] Linking
> build/sparc/gr740/testsuites/validation/ts-fatal-sparc-leon3-shutdown.exe
>
>
> --
> 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: BSP-Specific Testing was: [PATCH 00/34] Integrate pre-qualified LEON3 BSP

[Gedare Bloom]

On Tue, Jun 13, 2023 at 8:56 AM Sebastian Huber
 wrote:
>
>
>
> On 12.06.23 17:58, Gedare Bloom wrote:
> > On Mon, Jun 12, 2023 at 12:56 AM Sebastian Huber
> >  wrote:
> >>
> >>
> >>
> >> On 01.06.23 22:06, Gedare Bloom wrote:
> >>> On Thu, Jun 1, 2023 at 2:00 PM Gedare Bloom  wrote:
> >>>> -- Forwarded message -
> >>>> From: Sebastian Huber
> >>>> Date: Wed, May 31, 2023 at 10:31 AM
> >>>>
> >>>> The existing tests in the RTEMS test suite are basically BSP
> >>>> independent. This patch set introduces BSP-specific validation tests.
> >>>> These tests are disabled for other BSPs through the build system, for
> >>>> example:
> >>>>
> >>>> spec/build/testsuites/validation/bsp-sparc-leon3-gr712rc.yml
> >>>> [...]
> >>>> cxxflags: []
> >>>> enabled-by: sparc/gr712rc
> >>>> features: c cprogram
> >>>> [...]
> >>> The use of the enabled-by: field to control the BSP-specific tests
> >>> looks reasonable. However, we should decide where/how any BSP-specific
> >>> tests should reside. It looks to me like the current approach is to
> >>> dump all test files in a single monolithic 'validation' directory, and
> >>> let the user/script sort it out. This results in a mix of tests
> >>> intended for all targets, and some for specific targets. This is
> >>> pretty much non-maintainable from my point-of-view without some
> >>> additional tool support. Correct me if I'm wrong.
> >>
> >> Yes, this is the current approach. There is no strict one-to-one
> >> relationship of test cases and test suites. The file names are somewhat
> >> descriptive, for example:
> >>
> >> ls -l *leon3*
> >> -rw-r--r-- 1 sebastian_h domain users 3739 31. Mai 10:44
> >> tc-bsp-sparc-leon3-gr712rc.c
> >> -rw-r--r-- 1 sebastian_h domain users 6138 31. Mai 10:44
> >> tc-fatal-bsp-sparc-leon3-shutdown.c
> >> -rw-r--r-- 1 sebastian_h domain users 5135 31. Mai 10:44
> >> tr-fatal-bsp-sparc-leon3-cache-snooping-disabled-boot.c
> >> -rw-r--r-- 1 sebastian_h domain users 2723 31. Mai 10:44
> >> tr-fatal-bsp-sparc-leon3-cache-snooping-disabled-boot.h
> >> -rw-r--r-- 1 sebastian_h domain users 5406 31. Mai 10:44
> >> tr-fatal-bsp-sparc-leon3-cache-snooping-disabled-secondary.c
> >> -rw-r--r-- 1 sebastian_h domain users 2753 31. Mai 10:44
> >> tr-fatal-bsp-sparc-leon3-cache-snooping-disabled-secondary.h
> >> -rw-r--r-- 1 sebastian_h domain users 5270 31. Mai 10:44
> >> tr-fatal-bsp-sparc-leon3-clock-initialization.c
> >> -rw-r--r-- 1 sebastian_h domain users 2681 31. Mai 10:44
> >> tr-fatal-bsp-sparc-leon3-clock-initialization.h
> >> -rw-r--r-- 1 sebastian_h domain users 2488 31. Mai 10:44
> >> ts-bsp-sparc-leon3-gr712rc.c
> >> -rw-r--r-- 1 sebastian_h domain users 2845 31. Mai 10:44
> >> ts-fatal-bsp-sparc-leon3-cache-snooping-disabled-boot.c
> >> -rw-r--r-- 1 sebastian_h domain users 2919 31. Mai 10:44
> >> ts-fatal-bsp-sparc-leon3-cache-snooping-disabled-secondary.c
> >> -rw-r--r-- 1 sebastian_h domain users 2797 31. Mai 10:44
> >> ts-fatal-bsp-sparc-leon3-clock-initialization.c
> >> -rw-r--r-- 1 sebastian_h domain users 3148 31. Mai 10:45
> >> ts-fatal-bsp-sparc-leon3-shutdown-response.c
> >> -rw-r--r-- 1 sebastian_h domain users 4909 31. Mai 10:44
> >> ts-fatal-bsp-sparc-leon3-shutdown.c
> >>
> >> We could also introduce subdirectories to organize things. The test
> >> framework prints out the file name in messages, so it would be nice if
> >> they remain unique. With subdirectories this would lead to longer path
> >> names, for example
> >>
> >> testsuites/validation/sparc/leon3/tc-bsp-sparc-leon3-gr712rc.c
> >>
> > I see. Maybe it makes sense to have all BSP-specific tests in a bsps
> > subdirectory, with the unique names encoded to ensure the arch/bsp
> > combination appears in the filename, such as:
> > testsuites/validation/bsps/tc-bsp-sparc-leon3-gr712rc.c
> > If so, 'bsp-' can probably be omitted from the filename. This way,
> > architecture-specific testing may also be easily possible, like
> > tc-sparc-something.c
>
> This is a nicely balanced and easy approach. Place BSP-specific tests in
> a "bsps" directory. Place architecture-specific tests in a "cpu" directory.
>
> >
> >>&

Re: style question: breaking inline assembly lines

[Gedare Bloom]

On Tue, Jun 13, 2023 at 7:41 PM Chris Johns  wrote:
>
> On 14/6/2023 10:20 am, Joel Sherrill wrote:
> >
> >
> > On Tue, Jun 13, 2023, 4:43 PM Chris Johns  > <mailto:chr...@rtems.org>> wrote:
> >
> > On 14/6/2023 5:47 am, Joel Sherrill wrote:
> > >
> > >
> > > On Tue, Jun 13, 2023 at 9:51 AM Sebastian Huber
> > >  > <mailto:sebastian.hu...@embedded-brains.de>
> > <mailto:sebastian.hu...@embedded-brains.de
> >     <mailto:sebastian.hu...@embedded-brains.de>>>
> > > wrote:
> > >
> > > On 13.06.23 00:04, Gedare Bloom wrote:
> > > >   "b _ARM_Exception_default\n"
> > > >   :
> > > > -: [cpufsz] "i" (sizeof(CPU_Exception_frame)),
> > > > -  [cpuspoff] "i" (offsetof(CPU_Exception_frame, 
> > register_sp)),
> > > > -  [v7mlroff] "i" (offsetof(ARMV7M_Exception_frame, 
> > register_lr)),
> > > > -  [cpuvecoff] "J" (offsetof(CPU_Exception_frame, vector)),
> > > > -  [cpuvfpoff] "i" (ARM_EXCEPTION_FRAME_VFP_CONTEXT_OFFSET),
> > > > -  [cpacr] "i" (ARMV7M_CPACR),
> > > > -  [vfpsz] "i" (ARM_VFP_CONTEXT_SIZE)
> > > > +: [cpufsz] "i"( sizeof( CPU_Exception_frame ) ),
> > >
> > > If we place operators (e.g. &&, ||, ...) at the end of a broken 
> > line,
> > > then we should do this for the : as well.
> > >
> > >
> > > OK.
> > >
> > >
> > >
> > > My current preference would be to format all non-third-party 
> > sources
> > > with a standard clang-format selection. I guess in the long run, 
> > this
> > > will be the easiest approach to maintain. If we use exotic 
> > options, then
> > > we may up ending as clang-format maintainers.
> > >
> > >
> > > I think this is the thing we have to keep in mind and I even said I 
> > would
> > > go along with compromises when we started. Get as close as you can
> > > and we will have to accept that -- for now. We should definitely file 
> > tickets
> > > with clang-format and ourselves to track things we don't like. If we 
> > get an
> > > option in the future whether we or someone else implements it, we can
> > > use it and reformat again. Those hopefully are not that invasive.
> >
> > Sounds like a plan.
> >
> > I am a little concerned about the version of clang-format I need as some
> > machines I work on are no at current OS versions.
> >
> >
> > I am finding myself experimenting with it for a customer's C++ project. So 
> > far,
> > I have not matched the style. But I am now on Rocky 9 since I built it from
> > source and needed cmake 3 at least. So you can't be on an old distribution 
> > and
> > build from source.
>
> I use clang-format on a couple projects with something close the standard
> format. It works well.
>
> > And Doxygen has and three different major versions between RHEL 7, 8, and 9.
> > Using a configuration file from one on another seems to give you warnings 
> > about
> > unknown options or obsolete options.
> >
> > Mixing new and old systems is a pain.
>
> It is but we have to for reasons specific to local sites.
>
As a developer tool that can be used also by CI tools to automate
style fixes, I view the availability of clang-format as less of a
concern (than say a specific version of gcc). People can still create
and send commits without having the tool.

If someone ends up proposing a requirement for clang-format clean
patch submissions, then it becomes a problem.

> 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: style question: breaking inline assembly lines

[Gedare Bloom]

On Tue, Jun 13, 2023 at 8:51 AM Sebastian Huber
 wrote:
>
> On 13.06.23 00:04, Gedare Bloom wrote:
> >   "b _ARM_Exception_default\n"
> >   :
> > -: [cpufsz] "i" (sizeof(CPU_Exception_frame)),
> > -  [cpuspoff] "i" (offsetof(CPU_Exception_frame, register_sp)),
> > -  [v7mlroff] "i" (offsetof(ARMV7M_Exception_frame, register_lr)),
> > -  [cpuvecoff] "J" (offsetof(CPU_Exception_frame, vector)),
> > -  [cpuvfpoff] "i" (ARM_EXCEPTION_FRAME_VFP_CONTEXT_OFFSET),
> > -  [cpacr] "i" (ARMV7M_CPACR),
> > -  [vfpsz] "i" (ARM_VFP_CONTEXT_SIZE)
> > +: [cpufsz] "i"( sizeof( CPU_Exception_frame ) ),
>
> If we place operators (e.g. &&, ||, ...) at the end of a broken line,
> then we should do this for the : as well.
>
> My current preference would be to format all non-third-party sources
> with a standard clang-format selection. I guess in the long run, this
> will be the easiest approach to maintain. If we use exotic options, then
> we may up ending as clang-format maintainers.
>

The options supported since clang-16 are  what I suggested:
https://clang.llvm.org/docs/ClangFormatStyleOptions.html#breakbeforeinlineasmcolon

Breaking a newline after the : is not directly supported. It would
seem to be easy to add to clang-format if that's what we want.

I think I'm about 20% of the way toward being a clang-format maintainer already.

> --
> 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: style question: breaking inline assembly lines

[Gedare Bloom]

On Mon, Jun 12, 2023 at 4:03 PM Gedare Bloom  wrote:
>
> On Mon, Jun 12, 2023 at 3:54 PM Joel Sherrill  wrote:
> >
> >
> >
> > On Mon, Jun 12, 2023 at 4:50 PM Gedare Bloom  wrote:
> >>
> >> On Mon, Jun 12, 2023 at 2:28 PM Joel Sherrill  wrote:
> >> >
> >> >
> >> >
> >> > On Mon, Jun 12, 2023 at 3:10 PM Gedare Bloom  wrote:
> >> >>
> >> >> We have a mix of ways to write inline assembly. It would be convenient
> >> >> to choose one way. The prevailing options are based on breaking around
> >> >> the colons (reg/field separators), either to break at colons if the
> >> >> line length > 80, or to always break at colons.
> >> >>
> >> >> I personally find it is easier to read inline assembly that has broken
> >> >> at the colons. But we have these options:
> >> >> 1. Always break at the colon
> >> >> 2. Only break when the line length is exceeded
> >> >
> >> >
> >> > I lean to (1).
> >> >>
> >> >>
> >> >> With #2, we also can break as usual, or we can force breaks at the
> >> >> colons. I have seen examples of both in the source tree. Any strong
> >> >> opinions one way or another?
> >> >
> >> >
> >> > There may also be cases of multiple assembly instructions on the
> >> > same line or split across multiple with line continuation. I don't know
> >> > of one offhand though.
> >> A complicated example of that would be
> >> https://git.rtems.org/rtems/tree/cpukit/score/cpu/arm/armv7m-exception-default.c#n60
> >>
> >
> > Yikes! Does that look ok after clang-format processes it?
> >
> Yes.
>
> Below is a snippet of patch for that. One thing to note, there's
> currently no way to avoid adding the spaces inside of
> '__atribute__((naked))' as a special case. If this is desired, it will
> need to be added to clang-format probably.
>
> diff --git a/cpukit/score/cpu/arm/armv7m-exception-default.c
> b/cpukit/score/cpu/arm/armv7m-exception-default.c
> index 35dde50dc3..ff00ad2a72 100644
> --- a/cpukit/score/cpu/arm/armv7m-exception-default.c
> +++ b/cpukit/score/cpu/arm/armv7m-exception-default.c
> @@ -42,23 +42,23 @@
>
>  #ifdef ARM_MULTILIB_ARCH_V7M
>
> -void __attribute__((naked)) _ARMV7M_Exception_default( void )
> +void __attribute__( ( naked ) ) _ARMV7M_Exception_default( void )
>  {
> -/* On exception entry, ARMv7M saves context state onto a stack pointed to
> - * by either MSP or PSP. The value stored in LR indicates whether we were
> - * in Thread or Handler mode, whether we were using the FPU (if any),
> - * and which stack pointer we were using.
> - * In particular, bit 2 of LR will be 0 if we were using MSP.
> - *
> - * For a more detailed explanation, see the Exception Entry Behavior
> - * section of the ARMv7M Architecture Reference Manual.
> - */
> +  /* On exception entry, ARMv7M saves context state onto a stack pointed to
> +   * by either MSP or PSP. The value stored in LR indicates whether we were
> +   * in Thread or Handler mode, whether we were using the FPU (if any),
> +   * and which stack pointer we were using.
> +   * In particular, bit 2 of LR will be 0 if we were using MSP.
> +   *
> +   * For a more detailed explanation, see the Exception Entry Behavior
> +   * section of the ARMv7M Architecture Reference Manual.
> +   */
>
> -/* As we're in Handler mode here, we'll always operate on MSP.
> - * However, we need to store the right SP in our CPU_Exception_frame.
> - */
> -  __asm__ volatile (
> -"sub sp, %[cpufsz]\n"   /* Allocate space for a CPU_Exception_frame. */
> +  /* As we're in Handler mode here, we'll always operate on MSP.
> +   * However, we need to store the right SP in our CPU_Exception_frame.
> +   */
> +  __asm__ volatile(

One other note, there's currently no way to force a space after
volatile. Again if that's something we want to preserve, it probably
needs to be added somehow.

> +"sub sp, %[cpufsz]\n" /* Allocate space for a CPU_Exception_frame. */
>  "stm sp, {r0-r12}\n"
>  "tst lr, #4\n"  /* Check if bit 2 of LR is zero. If so,
> PSR.Z = 1 */
>  "itte eq\n" /* IF bit 2 of LR is zero... (PSR.Z == 1) */
> @@ -67,15 +67,15 @@ void __attribute__((naked))
> _ARMV7M_Exception_default( void )
>  "mrsne r3, psp\n"   /* ELSE it is not zero; we were using PSP */
>  "add r2, r3, %[v7mlroff]\

Re: style question: breaking inline assembly lines

[Gedare Bloom]

On Mon, Jun 12, 2023 at 3:54 PM Joel Sherrill  wrote:
>
>
>
> On Mon, Jun 12, 2023 at 4:50 PM Gedare Bloom  wrote:
>>
>> On Mon, Jun 12, 2023 at 2:28 PM Joel Sherrill  wrote:
>> >
>> >
>> >
>> > On Mon, Jun 12, 2023 at 3:10 PM Gedare Bloom  wrote:
>> >>
>> >> We have a mix of ways to write inline assembly. It would be convenient
>> >> to choose one way. The prevailing options are based on breaking around
>> >> the colons (reg/field separators), either to break at colons if the
>> >> line length > 80, or to always break at colons.
>> >>
>> >> I personally find it is easier to read inline assembly that has broken
>> >> at the colons. But we have these options:
>> >> 1. Always break at the colon
>> >> 2. Only break when the line length is exceeded
>> >
>> >
>> > I lean to (1).
>> >>
>> >>
>> >> With #2, we also can break as usual, or we can force breaks at the
>> >> colons. I have seen examples of both in the source tree. Any strong
>> >> opinions one way or another?
>> >
>> >
>> > There may also be cases of multiple assembly instructions on the
>> > same line or split across multiple with line continuation. I don't know
>> > of one offhand though.
>> A complicated example of that would be
>> https://git.rtems.org/rtems/tree/cpukit/score/cpu/arm/armv7m-exception-default.c#n60
>>
>
> Yikes! Does that look ok after clang-format processes it?
>
Yes.

Below is a snippet of patch for that. One thing to note, there's
currently no way to avoid adding the spaces inside of
'__atribute__((naked))' as a special case. If this is desired, it will
need to be added to clang-format probably.

diff --git a/cpukit/score/cpu/arm/armv7m-exception-default.c
b/cpukit/score/cpu/arm/armv7m-exception-default.c
index 35dde50dc3..ff00ad2a72 100644
--- a/cpukit/score/cpu/arm/armv7m-exception-default.c
+++ b/cpukit/score/cpu/arm/armv7m-exception-default.c
@@ -42,23 +42,23 @@

 #ifdef ARM_MULTILIB_ARCH_V7M

-void __attribute__((naked)) _ARMV7M_Exception_default( void )
+void __attribute__( ( naked ) ) _ARMV7M_Exception_default( void )
 {
-/* On exception entry, ARMv7M saves context state onto a stack pointed to
- * by either MSP or PSP. The value stored in LR indicates whether we were
- * in Thread or Handler mode, whether we were using the FPU (if any),
- * and which stack pointer we were using.
- * In particular, bit 2 of LR will be 0 if we were using MSP.
- *
- * For a more detailed explanation, see the Exception Entry Behavior
- * section of the ARMv7M Architecture Reference Manual.
- */
+  /* On exception entry, ARMv7M saves context state onto a stack pointed to
+   * by either MSP or PSP. The value stored in LR indicates whether we were
+   * in Thread or Handler mode, whether we were using the FPU (if any),
+   * and which stack pointer we were using.
+   * In particular, bit 2 of LR will be 0 if we were using MSP.
+   *
+   * For a more detailed explanation, see the Exception Entry Behavior
+   * section of the ARMv7M Architecture Reference Manual.
+   */

-/* As we're in Handler mode here, we'll always operate on MSP.
- * However, we need to store the right SP in our CPU_Exception_frame.
- */
-  __asm__ volatile (
-"sub sp, %[cpufsz]\n"   /* Allocate space for a CPU_Exception_frame. */
+  /* As we're in Handler mode here, we'll always operate on MSP.
+   * However, we need to store the right SP in our CPU_Exception_frame.
+   */
+  __asm__ volatile(
+"sub sp, %[cpufsz]\n" /* Allocate space for a CPU_Exception_frame. */
 "stm sp, {r0-r12}\n"
 "tst lr, #4\n"  /* Check if bit 2 of LR is zero. If so,
PSR.Z = 1 */
 "itte eq\n" /* IF bit 2 of LR is zero... (PSR.Z == 1) */
@@ -67,15 +67,15 @@ void __attribute__((naked))
_ARMV7M_Exception_default( void )
 "mrsne r3, psp\n"   /* ELSE it is not zero; we were using PSP */
 "add r2, r3, %[v7mlroff]\n"
 "add r1, sp, %[cpuspoff]\n"
-"ldm r2, {r4-r6}\n" /* Grab LR, PC and xPSR from the stack */
-"tst lr, #16\n" /* Check if we have an FP state on the frame */
+"ldm r2, {r4-r6}\n" /* Grab LR, PC and xPSR from the stack */
+"tst lr, #16\n" /* Check if we have an FP state on the frame */
 "ite eq\n"
-"addeq r3, #104\n"  /* Back to previous SP with FP state */
-"addne r3, #32\n"   /* Back to previous SP without FP state */
-"tst r6, #512\n"/* Check xPSR if the SP was aligned */
+"addeq r3, #104\n" /* Back to previous SP with

Re: style question: breaking inline assembly lines

[Gedare Bloom]

On Mon, Jun 12, 2023 at 2:28 PM Joel Sherrill  wrote:
>
>
>
> On Mon, Jun 12, 2023 at 3:10 PM Gedare Bloom  wrote:
>>
>> We have a mix of ways to write inline assembly. It would be convenient
>> to choose one way. The prevailing options are based on breaking around
>> the colons (reg/field separators), either to break at colons if the
>> line length > 80, or to always break at colons.
>>
>> I personally find it is easier to read inline assembly that has broken
>> at the colons. But we have these options:
>> 1. Always break at the colon
>> 2. Only break when the line length is exceeded
>
>
> I lean to (1).
>>
>>
>> With #2, we also can break as usual, or we can force breaks at the
>> colons. I have seen examples of both in the source tree. Any strong
>> opinions one way or another?
>
>
> There may also be cases of multiple assembly instructions on the
> same line or split across multiple with line continuation. I don't know
> of one offhand though.
A complicated example of that would be
https://git.rtems.org/rtems/tree/cpukit/score/cpu/arm/armv7m-exception-default.c#n60

>>
>>
>> here's a line broken because of line lengths, that has not split the
>> arguments at the colons:
>> https://git.rtems.org/rtems/tree/cpukit/score/cpu/arm/include/rtems/score/aarch32-system-registers.h#n69
>>
>> Here's a line broken because of line lengths:
>> https://git.rtems.org/rtems/tree/cpukit/score/cpu/arm/include/rtems/score/cpu.h#n501
>>
>> Here's a line broken always:
>> https://git.rtems.org/rtems/tree/cpukit/score/cpu/aarch64/cpu.c#n153
>>
>> And for good measure, here's an unbroken line that should be broken:
>> https://git.rtems.org/rtems/tree/cpukit/score/cpu/microblaze/include/rtems/score/cpu.h#n206
>>
>> With the newest version of clang-format we will be able to accommodate
>> always breaking the lines. It currently is inconsistent with whether
>> it puts the first argument on its own line, or keeps it with the
>> "__asm__ volatile (" that I could probably make consistent if we
>> decide we need it to be.
>>
>> Gedare
>> ___
>> 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

style question: breaking inline assembly lines

[Gedare Bloom]

We have a mix of ways to write inline assembly. It would be convenient
to choose one way. The prevailing options are based on breaking around
the colons (reg/field separators), either to break at colons if the
line length > 80, or to always break at colons.

I personally find it is easier to read inline assembly that has broken
at the colons. But we have these options:
1. Always break at the colon
2. Only break when the line length is exceeded

With #2, we also can break as usual, or we can force breaks at the
colons. I have seen examples of both in the source tree. Any strong
opinions one way or another?

here's a line broken because of line lengths, that has not split the
arguments at the colons:
https://git.rtems.org/rtems/tree/cpukit/score/cpu/arm/include/rtems/score/aarch32-system-registers.h#n69

Here's a line broken because of line lengths:
https://git.rtems.org/rtems/tree/cpukit/score/cpu/arm/include/rtems/score/cpu.h#n501

Here's a line broken always:
https://git.rtems.org/rtems/tree/cpukit/score/cpu/aarch64/cpu.c#n153

And for good measure, here's an unbroken line that should be broken:
https://git.rtems.org/rtems/tree/cpukit/score/cpu/microblaze/include/rtems/score/cpu.h#n206

With the newest version of clang-format we will be able to accommodate
always breaking the lines. It currently is inconsistent with whether
it puts the first argument on its own line, or keeps it with the
"__asm__ volatile (" that I could probably make consistent if we
decide we need it to be.

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

Re: BSP-Specific Testing was: [PATCH 00/34] Integrate pre-qualified LEON3 BSP

[Gedare Bloom]

On Mon, Jun 12, 2023 at 12:56 AM Sebastian Huber
 wrote:
>
>
>
> On 01.06.23 22:06, Gedare Bloom wrote:
> > On Thu, Jun 1, 2023 at 2:00 PM Gedare Bloom  wrote:
> >> -- Forwarded message -
> >> From: Sebastian Huber
> >> Date: Wed, May 31, 2023 at 10:31 AM
> >>
> >> The existing tests in the RTEMS test suite are basically BSP
> >> independent. This patch set introduces BSP-specific validation tests.
> >> These tests are disabled for other BSPs through the build system, for
> >> example:
> >>
> >> spec/build/testsuites/validation/bsp-sparc-leon3-gr712rc.yml
> >> [...]
> >> cxxflags: []
> >> enabled-by: sparc/gr712rc
> >> features: c cprogram
> >> [...]
> > The use of the enabled-by: field to control the BSP-specific tests
> > looks reasonable. However, we should decide where/how any BSP-specific
> > tests should reside. It looks to me like the current approach is to
> > dump all test files in a single monolithic 'validation' directory, and
> > let the user/script sort it out. This results in a mix of tests
> > intended for all targets, and some for specific targets. This is
> > pretty much non-maintainable from my point-of-view without some
> > additional tool support. Correct me if I'm wrong.
>
> Yes, this is the current approach. There is no strict one-to-one
> relationship of test cases and test suites. The file names are somewhat
> descriptive, for example:
>
> ls -l *leon3*
> -rw-r--r-- 1 sebastian_h domain users 3739 31. Mai 10:44
> tc-bsp-sparc-leon3-gr712rc.c
> -rw-r--r-- 1 sebastian_h domain users 6138 31. Mai 10:44
> tc-fatal-bsp-sparc-leon3-shutdown.c
> -rw-r--r-- 1 sebastian_h domain users 5135 31. Mai 10:44
> tr-fatal-bsp-sparc-leon3-cache-snooping-disabled-boot.c
> -rw-r--r-- 1 sebastian_h domain users 2723 31. Mai 10:44
> tr-fatal-bsp-sparc-leon3-cache-snooping-disabled-boot.h
> -rw-r--r-- 1 sebastian_h domain users 5406 31. Mai 10:44
> tr-fatal-bsp-sparc-leon3-cache-snooping-disabled-secondary.c
> -rw-r--r-- 1 sebastian_h domain users 2753 31. Mai 10:44
> tr-fatal-bsp-sparc-leon3-cache-snooping-disabled-secondary.h
> -rw-r--r-- 1 sebastian_h domain users 5270 31. Mai 10:44
> tr-fatal-bsp-sparc-leon3-clock-initialization.c
> -rw-r--r-- 1 sebastian_h domain users 2681 31. Mai 10:44
> tr-fatal-bsp-sparc-leon3-clock-initialization.h
> -rw-r--r-- 1 sebastian_h domain users 2488 31. Mai 10:44
> ts-bsp-sparc-leon3-gr712rc.c
> -rw-r--r-- 1 sebastian_h domain users 2845 31. Mai 10:44
> ts-fatal-bsp-sparc-leon3-cache-snooping-disabled-boot.c
> -rw-r--r-- 1 sebastian_h domain users 2919 31. Mai 10:44
> ts-fatal-bsp-sparc-leon3-cache-snooping-disabled-secondary.c
> -rw-r--r-- 1 sebastian_h domain users 2797 31. Mai 10:44
> ts-fatal-bsp-sparc-leon3-clock-initialization.c
> -rw-r--r-- 1 sebastian_h domain users 3148 31. Mai 10:45
> ts-fatal-bsp-sparc-leon3-shutdown-response.c
> -rw-r--r-- 1 sebastian_h domain users 4909 31. Mai 10:44
> ts-fatal-bsp-sparc-leon3-shutdown.c
>
> We could also introduce subdirectories to organize things. The test
> framework prints out the file name in messages, so it would be nice if
> they remain unique. With subdirectories this would lead to longer path
> names, for example
>
> testsuites/validation/sparc/leon3/tc-bsp-sparc-leon3-gr712rc.c
>
I see. Maybe it makes sense to have all BSP-specific tests in a bsps
subdirectory, with the unique names encoded to ensure the arch/bsp
combination appears in the filename, such as:
testsuites/validation/bsps/tc-bsp-sparc-leon3-gr712rc.c
If so, 'bsp-' can probably be omitted from the filename. This way,
architecture-specific testing may also be easily possible, like
tc-sparc-something.c

> >
> > I would like to discuss possible ways to manage the integration of
> > tests that are conditionally-built based on the arch/bsp tuple. We
> > should have clear guidance for others who want to add such tests in
> > the future, or who would modify existing tests.
>
> Yes, this makes sense. We could add a new section for BSP-specific tests to:
>
> https://docs.rtems.org/branches/master/eng/req/howto.html
>
> For a pre-qualified BSP you have to specify the fatal errors and write
> validation tests for it. Other BSP-specific specification and validation
> may be necessary for the kernel IO device driver, cache controller
> support, memory management unit initialization, memory protection unit
> initialization, etc.
>
Good, that would definitely be important to document.

I think we should have some of the BSP-specific tests under some other
location in testsuites, while others would be under validation where
they are used for pre-qualification?

M

Re: [rtems commit] xilinx-zynqmp: Include for rtems_termios_initialize()

[Gedare Bloom]

This is a reasonable workaround for now, but it seems to be overkill
and counter to the point of refactoring the termiostypes.h.

Would a better solution be
#define rtems_termios_initialize() (void)

On Tue, Jun 6, 2023 at 4:34 PM Joel Sherrill  wrote:
>
> Module:rtems
> Branch:master
> Commit:b2967081e5daa673141d714a2e53280898dce566
> Changeset: 
> http://git.rtems.org/rtems/commit/?id=b2967081e5daa673141d714a2e53280898dce566
>
> Author:Joel Sherrill 
> Date:  Tue Jun  6 17:33:08 2023 -0500
>
> xilinx-zynqmp: Include  for rtems_termios_initialize()
>
> ---
>
>  bsps/aarch64/xilinx-zynqmp/console/console.c| 1 +
>  bsps/arm/xilinx-zynqmp/console/console-config.c | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/bsps/aarch64/xilinx-zynqmp/console/console.c 
> b/bsps/aarch64/xilinx-zynqmp/console/console.c
> index 992b8a62da..e0ca14069c 100644
> --- a/bsps/aarch64/xilinx-zynqmp/console/console.c
> +++ b/bsps/aarch64/xilinx-zynqmp/console/console.c
> @@ -38,6 +38,7 @@
>  #include 
>  #include 
>  #include 
> +#include/* for rtems_termios_initialize */
>
>  #include 
>  #include 
> diff --git a/bsps/arm/xilinx-zynqmp/console/console-config.c 
> b/bsps/arm/xilinx-zynqmp/console/console-config.c
> index b164db78a5..1712073c2c 100644
> --- a/bsps/arm/xilinx-zynqmp/console/console-config.c
> +++ b/bsps/arm/xilinx-zynqmp/console/console-config.c
> @@ -33,6 +33,7 @@
>  #include 
>  #include 
>  #include 
> +#include/* for rtems_termios_initialize */
>
>  #include 
>  #include 
>
> ___
> 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: [RSB PATCH 2/2] rtems/kernel: Update kernel

[Gedare Bloom]

ok

On Mon, Jun 5, 2023 at 12:48 AM  wrote:
>
> From: Chris Johns 
>
> - Zynq ARM fixes
>
> - AARCH64 MMU fix
>
> - Updated imxrt drivers
>
> - x86_64 EFI support
>
> - Flash driver
>
> - Updated validation tests
>
> - Microblaze updates
> ---
>  rtems/config/tools/rtems-kernel-6.cfg | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/rtems/config/tools/rtems-kernel-6.cfg 
> b/rtems/config/tools/rtems-kernel-6.cfg
> index e2f1d68..f2174c7 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 5a37722b066f5792aad80fb5b32fb3c056cf1607
> +%define rtems_kernel_version a83dc4a469429e29cdd18eddbd1b9fff3f4328d8
>
>  %hash sha512 rtems-kernel-%{rtems_kernel_version}.tar.bz2 \
> -   
> UcZlhl2FZhvDKXZnPLnJSYnMQwSgWluTBGfoLII9vNbx4ypxQPE+egN4dZ06H3l5MprrJY96mgNZTfLjI2itcQ==
> +   
> baWt7QkFo2YlzV4pTnnZ8agonhdrWN4Z8yMgV6/vgZs+cRw59xRq69KfWzgqVZDpaA0l3nuiLqNaxqEh2fMXMw==
>  #
>  # The RTEMS build instructions.
>  #
> --
> 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: [RSB PATCH] rtems/net: Add net services build support

[Gedare Bloom]

Great to see, go ahead.

On Sun, Jun 4, 2023 at 11:20 PM  wrote:
>
> From: Chris Johns 
>
> ---
>  rtems/config/net/net-services-1.cfg   | 23 ++
>  rtems/config/net/net-services.bset| 15 
>  rtems/config/tools/rtems-net-services.cfg | 91 +++
>  3 files changed, 129 insertions(+)
>  create mode 100644 rtems/config/net/net-services-1.cfg
>  create mode 100644 rtems/config/net/net-services.bset
>  create mode 100644 rtems/config/tools/rtems-net-services.cfg
>
> diff --git a/rtems/config/net/net-services-1.cfg 
> b/rtems/config/net/net-services-1.cfg
> new file mode 100644
> index 000..c342547
> --- /dev/null
> +++ b/rtems/config/net/net-services-1.cfg
> @@ -0,0 +1,23 @@
> +#
> +# RTEMS Net Services
> +#
> +
> +%if %{release} == %{nil}
> + %define release 1
> +%endif
> +
> +#
> +# Net Services Version
> +#
> +%define rtems_net_services_version e35f89b6bf8170b5556a90535ed2f1f6b7473d81
> +%hash sha512 rtems-net-services-%{rtems_net_services_version}.tar.bz2 \
> +   
> CqubUTOMm3zohNpOYft5QPTqhl9qEuBo3wcQ5tOTZGRwOMzwQ+3tRyl8ZrcgdTtoV7fIZCoJt5Ty5zTeANdMCQ==
> +
> +%define rtems_waf_version 68654b4f995382765605dc16917baad4bdbf7f7c
> +%hash sha512 rtems-waf-%{rtems_waf_version}.tar.bz2 \
> +   
> NAuyFxjfSiQd6VfYZl4fJClywPrLF2fN+GjXHjq3ddceqaBrSeHZ+XpYpU3XTnk2qKICsUSTLV+CskDuWdwqvQ==
> +
> +#
> +# Net Services Build configuration
> +#
> +%include %{_configdir}/tools/rtems-net-services.cfg
> diff --git a/rtems/config/net/net-services.bset 
> b/rtems/config/net/net-services.bset
> new file mode 100644
> index 000..7d90399
> --- /dev/null
> +++ b/rtems/config/net/net-services.bset
> @@ -0,0 +1,15 @@
> +#
> +# Build set for RTEMS Net Services
> +#
> +
> +%define release 1
> +
> +#
> +# The RTEMS Package defines
> +#
> +%include rtems-package.bset
> +
> +#
> +# Build Net Services
> +#
> +net/net-services-1
> diff --git a/rtems/config/tools/rtems-net-services.cfg 
> b/rtems/config/tools/rtems-net-services.cfg
> new file mode 100644
> index 000..2acfbd8
> --- /dev/null
> +++ b/rtems/config/tools/rtems-net-services.cfg
> @@ -0,0 +1,91 @@
> +#
> +# RTEMS Net Services
> +#
> +# This configuration file configure's, build's and install's
> +# networking services libraries
> +#
> +
> +%if %{release} == %{nil}
> +%define release 1
> +%endif
> +
> +Name:  
> rtems-net-services-%{rtems_net_services_version}-%{_host}-%{release}
> +Summary:   RTEMS Net Services provides networking services for RTEMS 
> networking
> +   stacks.
> +Version:   %{rtems_net_services_version}
> +Release:   %{release}
> +URL:   https://git.rtems.org/rtems-net-services.git/
> +
> +#
> +# Net services is packaged as the release version when released.
> +#
> +%if %{rsb_released}
> + %define rtems_net_services_version %{rsb_version}
> + %define rtems_net_services_ext xz
> + %define rtems_waf_ext xz
> +%else
> + %define rtems_net_services_ext bz2
> + %define rtems_waf_ext bz2
> +%endif
> +
> +#
> +# RTEMS BSP support.
> +#
> +%include rtems-bsp.cfg
> +
> +#
> +# Net services Source.
> +#
> +#  If not a release collect and install rtems_waf as cgit snapshots to not
> +#  capture submodules.
> +#
> +#  Releases package submodules in the top level tarfile.
> +#
> +%source set rtems_net_services 
> --rsb-file=rtems-net-services-%{rtems_net_services_version}.tar.%{rtems_net_services_ext}
>  \
> +  
> https://git.rtems.org/rtems-net-services/snapshot/rtems-net-services-%{rtems_net_services_version}.tar.%{rtems_net_services_ext}
> +%if !%{rsb_released}
> + %source set rtems_waf \
> +  
> https://git.rtems.org/rtems_waf/snapshot/rtems_waf-%{rtems_waf_version}.tar.%{rtems_waf_ext}
> +%endif
> +
> +#
> +# Prepare the source code.
> +#
> +%prep
> +  build_top=$(pwd)
> +
> +  source_dir_net_services="rtems-net-services-%{rtems_net_services_version}"
> +  %source setup rtems_net_services -q -n 
> rtems-net-services-%{rtems_net_services_version}
> +  %if !%{rsb_released}
> +   %source setup rtems_waf -q -s 1 -c -a -n 
> rtems-net-services-%{rtems_net_services_version}/rtems_waf
> +  %endif
> +  cd ${build_top}
> +
> +#
> +# Build the source code.
> +#
> +%build
> +  build_top=$(pwd)
> +
> +  %{host_build_flags}
> +
> +  cd ${source_dir_net_services}
> +
> +  ./waf distclean configure \
> +--prefix=%{_prefix} \
> +%{rtems_waf_tools} \
> +%{rtems_waf_rtems} \
> +--rtems-bsp=%{rtems_bsp_arch_bsp}
> +
> +  ./waf build
> +
> +  cd ${build_top}
> +
> +%install
> +  build_top=$(pwd)
> +
> +  %{__rmdir} ${SB_BUILD_ROOT}
> +
> +  cd ${source_dir_net_services}
> +  ./waf --destdir=$SB_BUILD_ROOT%{rtems_waf_build_root_suffix} install
> +  cd ${build_top}
> --
> 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: xilinx_zynqmp_ultra96 build failures

[Gedare Bloom]

This was probably a side-effect of Sebastian's recent patch that
refactored the termiostypes.h header file to remove libio.h.  The
rtems_termios_initialize() is provided as an empty inline function in
libio.h.

It's a dead function, and its call sites should probably be removed.

Gedare

On Mon, Jun 5, 2023 at 10:00 AM Joel Sherrill  wrote:
>
> Hi
>
> The OAR build sweep turned this up from rtems-bsp-builder.
>
> [1646/4698] Compiling testsuites/fstests/fsdosfssync01/init.c
> /home/joel/rtems-work/tools/6/lib/gcc/arm-rtems6/12.2.1/../../../../arm-rtems6/bin/ld:
>  ./librtemsbsp.a(console-config.c.36.o): in function `console_initialize':
> /home/joel/rtems-work/rtems/b-xilinx_zynqmp_ultra96/arm/xilinx_zynqmp_ultra96/../../../bsps/arm/xilinx-zynqmp/console/console-config.c:62:
>  undefined reference to `rtems_termios_initialize'
>
> It impacts multiple configurations of the BSP as seen here:
>
> https://lists.rtems.org/pipermail/build/2023-June/046597.html
>
> Hopefully someone recognizes what happened.
>
> Thanks.
>
> --joel
> ___
> 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

BSP-Specific Testing was: [PATCH 00/34] Integrate pre-qualified LEON3 BSP

[Gedare Bloom]

-- Forwarded message -
From: Sebastian Huber 
Date: Wed, May 31, 2023 at 10:31 AM

The existing tests in the RTEMS test suite are basically BSP
independent. This patch set introduces BSP-specific validation tests.
These tests are disabled for other BSPs through the build system, for
example:

spec/build/testsuites/validation/bsp-sparc-leon3-gr712rc.yml
[...]
cxxflags: []
enabled-by: sparc/gr712rc
features: c cprogram
[...]
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] score: Remove CPU port atomic operations API

[Gedare Bloom]

On Wed, May 31, 2023 at 1:53 AM Sebastian Huber
 wrote:
>
> On 26.05.23 07:19, Sebastian Huber wrote:
> > Use the C/C++ standard API directly.
>
> Any comments to this patch set?
>
At a quick glance it looks fine. The changes are largely mechanical
and I did not examine all of them.

> --
> 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: BSP-Specific Testing was: [PATCH 00/34] Integrate pre-qualified LEON3 BSP

[Gedare Bloom]

On Thu, Jun 1, 2023 at 2:00 PM Gedare Bloom  wrote:
>
> -- Forwarded message -
> From: Sebastian Huber 
> Date: Wed, May 31, 2023 at 10:31 AM
>
> The existing tests in the RTEMS test suite are basically BSP
> independent. This patch set introduces BSP-specific validation tests.
> These tests are disabled for other BSPs through the build system, for
> example:
>
> spec/build/testsuites/validation/bsp-sparc-leon3-gr712rc.yml
> [...]
> cxxflags: []
> enabled-by: sparc/gr712rc
> features: c cprogram
> [...]

The use of the enabled-by: field to control the BSP-specific tests
looks reasonable. However, we should decide where/how any BSP-specific
tests should reside. It looks to me like the current approach is to
dump all test files in a single monolithic 'validation' directory, and
let the user/script sort it out. This results in a mix of tests
intended for all targets, and some for specific targets. This is
pretty much non-maintainable from my point-of-view without some
additional tool support. Correct me if I'm wrong.

I would like to discuss possible ways to manage the integration of
tests that are conditionally-built based on the arch/bsp tuple. We
should have clear guidance for others who want to add such tests in
the future, or who would modify existing tests.

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

Re: [PATCH 2/5] build: Use CSafeLoader if available

[Gedare Bloom]

On Tue, May 23, 2023 at 12:04 AM Sebastian Huber
 wrote:
>
>
>
> On 23.05.23 02:42, Chris Johns wrote:
> > On 22/5/2023 6:29 pm, Sebastian Huber wrote:
> >> On 22.05.23 01:48, Chris Johns wrote:
>  The support for the CSafeLoader is just about 60 lines of additional 
>  code.
>  It would be a nice improvement for systems supporting this feature. I 
>  don't have
>  time to work on adding PyYAML with libyaml to the RTEMS Tools right now 
>  and I
>  think this would open another maintenance issues. If someone would be 
>  unable to
>  get a yaml module with a CSafeLoader, then he would be no longer able to 
>  build
>  RTEMS.
> >>> It is not about the size of the implementation, it is about making 2 
> >>> classes of
> >>> performance, those with and those without csafe. I am a firm believer all
> >>> developers and especially core developers need to be using the exact same 
> >>> tools
> >>> and code our community users are using. We did not always do this and it
> >>> resulted in the developers being disconnected from the user experience 
> >>> and I
> >>> decided I would do what I could to avoid this happening again.
> >>
> >> I really don't see the issue here. It is just the way to load the items 
> >> from the
> >> file system. This is a very isolated task in the build and having two ways 
> >> to do
> >> this is not a big deal from my point of view.
> >
> > Great, lets not go down this path and we all use the same process.
>
> The CSafeLoader approach makes my work more efficient, so I will
> definitely use it.
>
> >
> >>> In regards to PyYAML there are a few basic issues with it that I am not 
> >>> sure
> >>> about. The package can be built without support for the C library even if 
> >>> it is
> >>> installed. I cannot tell if a pip installed version is using the C YAML 
> >>> package
> >>> or not. I would like more certainty across our supported hosts before 
> >>> agreeing
> >>> to us using it.
> >>
> >> I think it is just too complicated to make sure that the user has a PyYAML 
> >> with
> >> the CSafeLoader available when RTEMS is built. A more robust approach is a 
> >> fall
> >> back to the current implementation if needed.
> >

Without a reliable way to ensure all users can equivalently use the
tools, I see the topic as not worth fighting a lot about. I have seen
projects that brought in build/configure time optional packages for
performance tuning and optimization with fallbacks, e.g., tcmalloc
instead of malloc. In those cases, it becomes harder to help debug
problems since it introduces another branching point to determine what
might go wrong. Although I'm sure this can be resolved given time, it
doesn't sound like anyone has time currently to integrate the
CSafeLoader in a way that makes certain that users get/use what we
expect.

I would suggest we can revisit the topic later, if Sebastian is
satisfied he can carry his own local optimization around for now. I
think we have probably all done things like that in the past. I
appreciate the discussion and that the support to use it was brought,
but unless the build times become a general problem for more
developers and the user base, I don't find this debate fruitful.

Gedare

> > Maybe we move away from YAML for the build system data? Amar and I 
> > originally
> > had python and INI files.
>
> This discussion started with a proposal to switch to JSON:
>
> https://lists.rtems.org/pipermail/devel/2023-April/075082.html
>
> The INI format is a simple key-value format with no support for
> hierarchical data, so not suitable from my point of view.
>
> Using Python code could be an option, however, this gives the writer of
> the files more freedom and room for creativity. On lesson learnt from
> converting the autoconf/automake build to the new build system is, that
> this may cause some issues.
>
> --
> 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 rtems v2 00/12] bsp/imxrt: Update SDK and prepare for new variant

[Gedare Bloom]

I'm fine with the v2 now, thanks for reducing it. Do feel free to
start a separate discussion / ticket about how we should handle HALs.
I think this problem will only get worse not better.

On Tue, May 9, 2023 at 6:11 AM Christian Mauderer
 wrote:
>
> Hello,
>
> this is the second version of the patch set to update the SDK files in
> the i.MXRT BSPs. Like said in the earlier version: I plan to add a
> i.MXRT1166 based BSP soon.
>
> The changes are:
> - I now only imported the SDK files for i.MXRT1050 and i.MXRT1166. With
>   that the imported files (mainly first patch) are now only 18MB instead
>   of 90MB.
> - The script to import the files is now removed. I added a link to it in
>   the description of the import patch. I'll create a short note for the
>   documentation soon.
> - I added some minor fixes that I noted during further tests.
>
> The full version of the two big patches (1 and 3) can be found on this
> branch:
>
> https://gitlab.com/c-mauderer/rtems/-/commits/cm/20230509_imxrt/
>
> 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: cpukit/flash: Add API for Flash device

[Gedare Bloom]

Sorry for the delays. These patches look fine now other than a few
small things that can be fixed either on check-in or cleaning up
later.

On Sun, Apr 30, 2023 at 11:21 PM  wrote:
>
> Hi All,
>
> Thanks again for the feedback. I've improved the implementation of the
> bit allocator in line with your suggestions and refactored some other
> functions to reduce repeated code.
>
> Regards, Aaron.
>
>
> ___
> 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 v4 3/3] testsuites/libtests: Add test for flashdev

[Gedare Bloom]

On Sun, Apr 30, 2023 at 11:21 PM  wrote:
>
> From: Aaron Nyholm 
>
> ---
>  spec/build/testsuites/libtests/flashdev01.yml |  20 ++
>  spec/build/testsuites/libtests/grp.yml|   2 +
>  testsuites/libtests/flashdev01/flashdev01.doc |  11 +
>  testsuites/libtests/flashdev01/flashdev01.scn |   2 +
>  testsuites/libtests/flashdev01/init.c | 190 
>  .../libtests/flashdev01/test_flashdev.c   | 275 ++
>  .../libtests/flashdev01/test_flashdev.h   |  35 +++
>  7 files changed, 535 insertions(+)
>  create mode 100644 spec/build/testsuites/libtests/flashdev01.yml
>  create mode 100644 testsuites/libtests/flashdev01/flashdev01.doc
>  create mode 100644 testsuites/libtests/flashdev01/flashdev01.scn
>  create mode 100644 testsuites/libtests/flashdev01/init.c
>  create mode 100644 testsuites/libtests/flashdev01/test_flashdev.c
>  create mode 100644 testsuites/libtests/flashdev01/test_flashdev.h
>
> diff --git a/spec/build/testsuites/libtests/flashdev01.yml 
> b/spec/build/testsuites/libtests/flashdev01.yml
> new file mode 100644
> index 00..c943caa2e7
> --- /dev/null
> +++ b/spec/build/testsuites/libtests/flashdev01.yml
> @@ -0,0 +1,20 @@
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> +build-type: test-program
> +cflags: []
> +copyrights:
> +- Copyright (C) 2023 Aaron Nyholm (Southern Innovation)
> +cppflags: []
> +cxxflags: []
> +enabled-by: true
> +features: c cprogram
> +includes: []
> +ldflags: []
> +links: []
> +source:
> +- testsuites/libtests/flashdev01/init.c
> +- testsuites/libtests/flashdev01/test_flashdev.c
> +stlib: []
> +target: testsuites/libtests/flashdev01.exe
> +type: build
> +use-after: []
> +use-before: []
> diff --git a/spec/build/testsuites/libtests/grp.yml 
> b/spec/build/testsuites/libtests/grp.yml
> index 8f2cadb890..30965e5b2c 100644
> --- a/spec/build/testsuites/libtests/grp.yml
> +++ b/spec/build/testsuites/libtests/grp.yml
> @@ -124,6 +124,8 @@ links:
>uid: exit03
>  - role: build-dependency
>uid: fcntl
> +- role: build-dependency
> +  uid: flashdev01
>  - role: build-dependency
>uid: flashdisk01
>  - role: build-dependency
> diff --git a/testsuites/libtests/flashdev01/flashdev01.doc 
> b/testsuites/libtests/flashdev01/flashdev01.doc
> new file mode 100644
> index 00..0638a5a842
> --- /dev/null
> +++ b/testsuites/libtests/flashdev01/flashdev01.doc
> @@ -0,0 +1,11 @@
> +This file describes the directives and concepts testd by this test set.
> +
> +test set name: flashdev01
> +
> +directives:
> +
> +  TBD
> +
> +concepts:
> +
> +  - Ensure that the flashdev driver API works.
> diff --git a/testsuites/libtests/flashdev01/flashdev01.scn 
> b/testsuites/libtests/flashdev01/flashdev01.scn
> new file mode 100644
> index 00..809ff3cd80
> --- /dev/null
> +++ b/testsuites/libtests/flashdev01/flashdev01.scn
> @@ -0,0 +1,2 @@
> +*** BEGIN OF TEST FLASHDEV 1 ***
> +*** END OF TEST FLASHDEV 1 ***
> diff --git a/testsuites/libtests/flashdev01/init.c 
> b/testsuites/libtests/flashdev01/init.c
> new file mode 100644
> index 00..d9a5364481
> --- /dev/null
> +++ b/testsuites/libtests/flashdev01/init.c
> @@ -0,0 +1,190 @@
> +/*
> + * SPDX-License-Identifier: BSD-2-Clause
> + *
> + * Copyright (C) 2023 Aaron Nyholm
> + *
> + * 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.
> + */
> +
> +#include "tmacros.h"
> +
> +#include "test_flashdev.h"
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define TEST_NAME_LENGTH 10
> +
> +#define TEST_DATA_SIZE (PAGE_SIZE * PAGE_COUNT)
> +#define PAGE_COUNT 16
> +#define PAGE_SIZE 128
> +#define WB_SIZE 1
> +
> +const char rtems_test_name[] = "FLASHDEV 1";
> +
> +static void 

Re: [PATCH v4 2/3] libmisc/shell: Add flashdev command

[Gedare Bloom]

On Sun, Apr 30, 2023 at 11:20 PM  wrote:
>
> From: Aaron Nyholm 
>
> ---
>  cpukit/include/rtems/shellconfig.h   |   7 +
>  cpukit/libmisc/shell/main_flashdev.c | 592 +++
>  spec/build/cpukit/objshell.yml   |   1 +
>  3 files changed, 600 insertions(+)
>  create mode 100644 cpukit/libmisc/shell/main_flashdev.c
>
> diff --git a/cpukit/include/rtems/shellconfig.h 
> b/cpukit/include/rtems/shellconfig.h
> index a013840ee7..489f281400 100644
> --- a/cpukit/include/rtems/shellconfig.h
> +++ b/cpukit/include/rtems/shellconfig.h
> @@ -98,6 +98,7 @@ extern rtems_shell_cmd_t rtems_shell_MD5_Command;
>
>  extern rtems_shell_cmd_t rtems_shell_RTC_Command;
>  extern rtems_shell_cmd_t rtems_shell_SPI_Command;
> +extern rtems_shell_cmd_t rtems_shell_FLASHDEV_Command;
>  extern rtems_shell_cmd_t rtems_shell_I2CDETECT_Command;
>  extern rtems_shell_cmd_t rtems_shell_I2CGET_Command;
>  extern rtems_shell_cmd_t rtems_shell_I2CSET_Command;
> @@ -556,6 +557,12 @@ extern rtems_shell_alias_t * const 
> rtems_shell_Initial_aliases[];
>_shell_SPI_Command,
>  #endif
>
> +#if (defined(CONFIGURE_SHELL_COMMANDS_ALL) \
> +  && !defined(CONFIGURE_SHELL_NO_COMMAND_FLASHDEV)) \
> +|| defined(CONFIGURE_SHELL_COMMAND_FLASHDEV)
> +  _shell_FLASHDEV_Command,
> +#endif
> +
>  #if (defined(CONFIGURE_SHELL_COMMANDS_ALL) \
>&& !defined(CONFIGURE_SHELL_NO_COMMAND_I2CDETECT)) \
>  || defined(CONFIGURE_SHELL_COMMAND_I2CDETECT)
> diff --git a/cpukit/libmisc/shell/main_flashdev.c 
> b/cpukit/libmisc/shell/main_flashdev.c
> new file mode 100644
> index 00..5484e7d7f9
> --- /dev/null
> +++ b/cpukit/libmisc/shell/main_flashdev.c
> @@ -0,0 +1,592 @@
> +/*
> + * Copyright (C) 2023 Aaron Nyholm
> + *
> + * 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.
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#include 
> +
> +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_ioctl_value(
> +  char *dev_path,
> +  int ioctl_call,
> +  void *ret
> +);
> +
> +static int flashdev_shell_page(
> +  char *dev_path,
> +  int argc,
> +  char *argv[],
> +  int ioctl_call
> +);
> +
> +static const char rtems_flashdev_shell_usage [] =
> +  "simple flash read / write / erase\n"
> +  "\n"
> +  "flashdev  [OPTION]\n"
> +  "   -rRead at address for bytes\n"
> +  "   -w Write file to address\n"
> +  "   -eErase at address for bytes\n"
> +  "   -tPrint the flash type\n"
> +  "   -dPrint the JEDEC ID of flash device\n"
> +  "   -o   Print the page information of page at address\n"
> +  "   -i Print the page information of page at index\n"
> +  "   -pPrint the number of pages\n"
> +  "   -bPrint the write block size\n"
> +  "   -hPrint this help\n";
> +
> +
> +static int rtems_flashdev_shell_main( int argc, char *argv[] ) {
> +
> +  char *dev_path = NULL;
> +  int i;
> +
> +  for (i = 1; i < argc; ++i) {
> +if (argv[i][0] == '-') {
> +  switch (argv[i][1]) {

Re: [rtems-source-builder] devel/qemu-xilinx: Fix source URL

[Gedare Bloom]

OK

On Wed, May 10, 2023 at 2:38 PM Alex White  wrote:
>
> On Mon, May 8, 2023 at 1:28 PM Gedare Bloom  wrote:
> >
> > I think the https works though? Or does it break?
> >
> > I recall there are sometimes issues that users face based on their IT
> > site policy that prevents git protocol from working properly while
> > https almost always works (tunnels) right.
>
> Hi Gedare,
>
> The build was broken before this patch.
>
> HTTPS does work, yes, and this patch does not change the protocol. This just
> changes how the source is handled by the RSB scripts. To get the git handling 
> to
> work, the URL needs to start with 'git://'. It still uses HTTPS since it
> specifies '?protocol=https' in the URL.
>
> Thanks,
>
> Alex
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems-source-builder] devel/qemu-xilinx: Fix source URL

[Gedare Bloom]

I think the https works though? Or does it break?

I recall there are sometimes issues that users face based on their IT
site policy that prevents git protocol from working properly while
https almost always works (tunnels) right.

Gedare

On Fri, May 5, 2023 at 8:18 AM Alex White  wrote:
>
> The source URL for Xilinx QEMU appears to have been incorrect from the
> start. Since we are cloning a git repository, we should use 'git://'.
> ---
>  bare/config/devel/qemu-xilinx-v2020.2-1.cfg | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/bare/config/devel/qemu-xilinx-v2020.2-1.cfg 
> b/bare/config/devel/qemu-xilinx-v2020.2-1.cfg
> index 180b621..2c3fb94 100644
> --- a/bare/config/devel/qemu-xilinx-v2020.2-1.cfg
> +++ b/bare/config/devel/qemu-xilinx-v2020.2-1.cfg
> @@ -15,7 +15,7 @@
>  #
>  # Checkout the version tag and initialize all submodules.
>  #
> -%source set qemu 
> https://github.com/Xilinx/qemu.git?checkout=%{qemu_version}?submodule=dtc?submodule=slirp?submodule=ui/keycodemapdb?submodule=tests/fp/berkeley-softfloat-3?submodule=tests/fp/berkeley-testfloat-3
> +%source set qemu 
> git://github.com/Xilinx/qemu.git?protocol=https?checkout=%{qemu_version}?submodule=dtc?submodule=slirp?submodule=ui/keycodemapdb?submodule=tests/fp/berkeley-softfloat-3?submodule=tests/fp/berkeley-testfloat-3
>
>  #
>  # The Qemu build instructions. We use 5.x.x Release 1.
> --
> 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 rtems 00/12] bsp/imxrt: Update SDK and prepare for new variant

[Gedare Bloom]

On Fri, May 5, 2023 at 9:02 AM  wrote:
>
> Hello Gedare,
>
> thanks for taking a look at the patch set.
>
> Am 05.05.23 um 15:56 schrieb Gedare Bloom:
> > On Thu, May 4, 2023 at 9:01 AM Christian Mauderer
> >  wrote:
> >>
> >> Hello,
> >>
> >> this patch set for the arm/imxrt BSP family updates the SDK files to the
> >> latest version of the mcux-sdk from NXP and prepares the BSP for further
> >> chip variants. I plan to add a BSP that uses the IMXRT1166 soon.
> >>
> >> As a base for the mcux-sdk files, I now use the NXP git repository
> >> instead of zip files that can be downloaded from NXP. I kept the exact
> >> file system structure to make future updates simpler.
> >>
> >> To import the files, I used a script. It is not a clean script and it
> >> was only tested on a Linux machine. Despite that, I added that script to
> >> the BSP directory in case someone else ever wants to update the
> >> mcux-sdk. Updating the SDK is also possible without the script. It's
> >> just a lot more manual work. So if we don't want a script in that state
> >> in the repository, I can also just keep it on a private branch.
> >>
> > I would recommend that you document the import/update process for the
> > SDK in this BSP (or family) documentation. You could provide a stable
> > external link to the script there instead of including it in the
> > rtems.git tree. I'm not convinced that including scripts etc in the
> > same tree as the source they manipulate is a great practice. It seems
> > to violate separation of concerns.
>
> Disadvantage is that the script (and documentation) is a bit less simple
> to find. But that's not a problem for me (I know where to search) so I
> will adapt that.
>
> De we have an official preferred stable location? Otherwise, I think
> either a small repo in my https://git.rtems.org/christianm or a repo on
> github should be a good place (most likely the later one).
>
This should be fine. ftp.rtems.org should also be usable (in theory)

> >
> >> The patches that import the new SDK files (patch 0002) and remove the
> >> old ones (patch 0004) are too big for the list. I'll only send the
> >> summary. You can find the full patches here:
> >>
> >>0002: 
> >> https://gitlab.com/c-mauderer/rtems/-/commit/2a871672767a95598e5af42373bfebd3eb9440d3
> >>0004: 
> >> https://gitlab.com/c-mauderer/rtems/-/commit/2a3e104fa808d7f34a1930344d7b39d11cf39f3d
> >>
> >> The complete patch set is on this branch:
> >>
> >>https://gitlab.com/c-mauderer/rtems/-/commits/cm/20230504_imxrt/
> >>
> >> At the moment, I import the support files for all currently available
> >> i.MXRT* variants. The headers for the CPU registers are really big (a
> >> few megabytes per header) which makes the complete source tree of the
> >> mcux-sdk bigger than 90MB. If preferred, I can remove most variants and
> >> only keep the ones that are currently used or will be used soon
> >> (IMXRT1052 and IMXRT1166) to reduce the size.
> >>
> > Thanks, I think this is fine. The increase in the number of HAL/SDK
> > that we have to import is starting to concern me in general. I wonder
> > if there is a better way to manage these external sources.
> >
>
> I think I have a language problem here: Is it fine that I push 96MB or
> is it fine that I reduce the size of the patch before pushing?
>
My apologies, I missed this also. If it's not that much more work, it
might be best to remove the unused variants. We don't like to carry
around dead code in the repo as another general rule.

> In this case I only updated the existing HAL with more chips, but I
> agree that having a better solution to manage HALs than the
> clone-and-own approach would be great.
>
> One possible solutions could be to use subrepos. We can clone the lib to
> the git.rtems.org, add necessary patches and add that as a subrepo. If
> an update is necessary, patches can just be rebased on the latest
> version of the upstream lib. Another one could be something like the
> west tool that is used in Zephyr. Maybe can also make it simpler to
> include libs with vendor specific licenses.
>
> But approaches like that will have a big impact on how to handle a lot
> of tasks in RTEMS. For example you would have to init submodules before
> building BSPs. The submodules have to be handled during release. And a
> lot more. So we shouldn't discuss that as a side note to a patch set but
> rather as a new mail thread.
>
Agreed.

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

Re: [PATCH 00/12] Update documentation of specification items

[Gedare Bloom]

these look ok. I'll leave the register one for Chris to comment.

On Fri, May 5, 2023 at 2:46 AM Sebastian Huber
 wrote:
>
> Sebastian Huber (12):
>   eng: Rework performance meansurement items
>   eng: Generalize external references
>   eng: Add conditional build dependencies
>   eng: Use type refinement for validation method
>   eng: Add optional floating-point number type
>   eng: Update application configuration how-to
>   eng: Remove obsolete type listing
>   eng: Add design target item type
>   eng: Add proxy item type
>   eng: Remove ambiguous interface types
>   eng: Add an item type for not defined defines
>   eng: Make design group identifiers optional
>
>  eng/glossary.rst  |   3 +
>  eng/req/howto.rst |  54 +++
>  eng/req/items.rst | 384 --
>  3 files changed, 296 insertions(+), 145 deletions(-)
>
> --
> 2.35.3
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Update zlib to version 1.2.13

[Gedare Bloom]

Can you please add the upstream source link in the commit message
before pushing?

I don't recall if we have an accepted "standard" practice for doing
this, but we should aim to.

On Fri, May 5, 2023 at 7:58 AM Gedare Bloom  wrote:
>
> ok. thanks for making it cleaner with the #ifdef rtems
>
> On Fri, May 5, 2023 at 2:27 AM Sebastian Huber
>  wrote:
> >
> > Hello,
> >
> > I would like to update zlib to version 1.2.13. The patch is to big for
> > the mailing list:
> >
> > https://github.com/sebhub/rtems/commit/30ae8218782f69fb37b3be40689167f6637b3cbe
> >
> > --
> > 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: Update zlib to version 1.2.13

[Gedare Bloom]

ok. thanks for making it cleaner with the #ifdef rtems

On Fri, May 5, 2023 at 2:27 AM Sebastian Huber
 wrote:
>
> Hello,
>
> I would like to update zlib to version 1.2.13. The patch is to big for
> the mailing list:
>
> https://github.com/sebhub/rtems/commit/30ae8218782f69fb37b3be40689167f6637b3cbe
>
> --
> 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 rtems 00/12] bsp/imxrt: Update SDK and prepare for new variant

[Gedare Bloom]

On Thu, May 4, 2023 at 9:01 AM Christian Mauderer
 wrote:
>
> Hello,
>
> this patch set for the arm/imxrt BSP family updates the SDK files to the
> latest version of the mcux-sdk from NXP and prepares the BSP for further
> chip variants. I plan to add a BSP that uses the IMXRT1166 soon.
>
> As a base for the mcux-sdk files, I now use the NXP git repository
> instead of zip files that can be downloaded from NXP. I kept the exact
> file system structure to make future updates simpler.
>
> To import the files, I used a script. It is not a clean script and it
> was only tested on a Linux machine. Despite that, I added that script to
> the BSP directory in case someone else ever wants to update the
> mcux-sdk. Updating the SDK is also possible without the script. It's
> just a lot more manual work. So if we don't want a script in that state
> in the repository, I can also just keep it on a private branch.
>
I would recommend that you document the import/update process for the
SDK in this BSP (or family) documentation. You could provide a stable
external link to the script there instead of including it in the
rtems.git tree. I'm not convinced that including scripts etc in the
same tree as the source they manipulate is a great practice. It seems
to violate separation of concerns.

> The patches that import the new SDK files (patch 0002) and remove the
> old ones (patch 0004) are too big for the list. I'll only send the
> summary. You can find the full patches here:
>
>   0002: 
> https://gitlab.com/c-mauderer/rtems/-/commit/2a871672767a95598e5af42373bfebd3eb9440d3
>   0004: 
> https://gitlab.com/c-mauderer/rtems/-/commit/2a3e104fa808d7f34a1930344d7b39d11cf39f3d
>
> The complete patch set is on this branch:
>
>   https://gitlab.com/c-mauderer/rtems/-/commits/cm/20230504_imxrt/
>
> At the moment, I import the support files for all currently available
> i.MXRT* variants. The headers for the CPU registers are really big (a
> few megabytes per header) which makes the complete source tree of the
> mcux-sdk bigger than 90MB. If preferred, I can remove most variants and
> only keep the ones that are currently used or will be used soon
> (IMXRT1052 and IMXRT1166) to reduce the size.
>
Thanks, I think this is fine. The increase in the number of HAL/SDK
that we have to import is starting to concern me in general. I wonder
if there is a better way to manage these external sources.

> 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 2/5] build: Use CSafeLoader if available

[Gedare Bloom]

On Wed, Apr 26, 2023 at 11:46 PM Sebastian Huber
 wrote:
>
> On 27.04.23 02:11, Chris Johns wrote:
> > On 26/4/2023 6:04 pm, Sebastian Huber wrote:
> >> The CSafeLoader uses the C libyaml libary to considerably speed up the
> >> loading of YAML files.
> > No from me.
>
> What do you mean with not for me? You have the CSafeLoader available and
> it is slow? Do you have some timings before and after the patch set for
> a "./waf configure" and "./waf build"? On my systems the configure needs
> less than a second with the CSafeLoader and the waf build setup time is
> less than 100ms.
>
> > I do not agree with conditional states of operation in the build system that
> > depend on packages a host has installed. If speed is an important factor all
> > users then I suggest you find a means to have it available automatically on 
> > the
> > hosts we support (Linux, FreeBSD, MacOS, Windows MINGW64 and Cygwin.
>
> I am not sure if we should automatically install system Python packages
> on user machines.
>
> The fall back is the Python PyYAML package available through the RTEMS
> sources. This is what we use currently. For RTEMS users, this is
> acceptable since they are not supposed to touch the YAML files. For
> RTEMS maintainers, not having the cache makes working with the build
> system more efficient.
>
> If they system PyYAML package is not installed, then you get now a hint
> to install it:
>
> Setting top to   : /home/EB/sebastian_h/src/rtems
> Setting out to   :
> /home/EB/sebastian_h/src/rtems/build
> Regenerate the build specification cache.  Install the PyYAML Python
> package to avoid this.  The cache regeneration needs a couple of seconds...
> Configure board support package (BSP): arm/realview_pbx_a9_qemu
>

I have two questions, which are related to Chris's concern I think.
1. Are the output of PyYAML and C libyaml guaranteed to be consistent?

2. Why not make C libyaml part of the RTEMS toolchain?

Any dependencies that exist in the build system are (by definition)
suitable to be checked/provided by the tool buildset.

Gedare

>
> --
> 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 repo commits need approval

[Gedare Bloom]

On Thu, Apr 27, 2023 at 3:27 AM Karel Gardas  wrote:
>
> On 4/27/23 08:13, Sebastian Huber wrote:
> > Why
> > don't we use a Git pull request workflow with CI pipelines in the RTEMS
> > Project?
>
> I don't know, but certainly github.com is not available as an
> open-source solution which may be seen as a major roadblock. Am I right
> assuming that GitLab Community is the most close to that and available
> for running by anyone?
100% this is the main reason, and most likely GitLab is where we would
go. I believe the main issue to getting that in place at the moment is
appropriate mechanisms to fund the remaining server upgrades and then
installation/setup of the gitlab service on RTEMS Project
infrastructure.

> As an observer on another project with GitLab (GHC Haskell compiler)
> I've seen this solution is not free as a work free, but requires some
> man-hours investments...
>
Yes.

> So the question after "yes" to migrate (if the consensus is found!) is
> "who will pay the price and do the job"...
>
Yes. Generally speaking, we have an excellent IT support in the
background via Amar, but it can be a lot of work for him at times, and
anything beyond the usual maintenance activities definitely requires
more time/money allocations.

> Karel
> ___
> 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: Change build specification files from YAML to JSON?

[Gedare Bloom]

Is the result of this discussion to use CSafeLoader for now? Or do we
still debate the transition to JSON?

I see some quirks need to be dealt with as you mentioned with the
multi-line stuff. The yaml is pretty simple to understand and work
with. I've dealt with hand-editing JSON and it's a pain with the
quotes and brackets/braces.

Since the transition is (apparently) an implementation detail, I don't
actually see that it matters do it now or do it after releasing 6. If
it doesn't change the user experience other than build time, then it
should matter when we do it. In that case, better to be conservative
to avoid rushing to push something this major so close to a release.

On Wed, Apr 26, 2023 at 2:30 AM Sebastian Huber
 wrote:
> On 26.04.23 00:37, Chris Johns wrote:
> > On 26/4/2023 4:01 am, Sebastian Huber wrote:
> >> We have a fraction of a second if we use the CSafeLoader and no item cache.
> >> Currently we use the SafeLoader which results in about 5 seconds. I would 
> >> like
> >> to use the build system for more stuff, so this could grow to 10, 15, or 
> >> more
> >> seconds which then start to get annoying if you work frequently with it.
> > Then please outline what all you have in mind and what the long term plan is
> > then we can consider the overall direction.
>
> We work on a prototype to build libbsd, lwip, abseil-cpp, googletest,
> jsoncpp, libsodium, nats.c, protobuf, protobuf-c, utf8_range, cfs,
> zephyr, chip vendor HALs, etc. with the RTEMS build system.
>

This is interesting although it appears to be quite a bit of scope
creep. I guess the intent is to help with traceability of these
projects too?

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

Re: [PATCH v3 1/3] cpukit/flash: Add API for Flash devices

[Gedare Bloom]

 I'm satisfied with the API. I have a couple minor comments on the
implementation.

On Thu, Apr 20, 2023 at 1:23 AM  wrote:
>
> From: Aaron Nyholm 
>
> ---
>  cpukit/dev/flash/flashdev.c | 849 
>  cpukit/include/dev/flash/flashdev.h | 458 +++
>  spec/build/cpukit/librtemscpu.yml   |   4 +
>  3 files changed, 1311 insertions(+)
>  create mode 100644 cpukit/dev/flash/flashdev.c
>  create mode 100644 cpukit/include/dev/flash/flashdev.h
>
> diff --git a/cpukit/dev/flash/flashdev.c b/cpukit/dev/flash/flashdev.c
> new file mode 100644
> index 00..03343f015f
> --- /dev/null
> +++ b/cpukit/dev/flash/flashdev.c
> @@ -0,0 +1,849 @@
> +/*
> + * Copyright (C) 2023 Aaron Nyholm
> + *
> + * 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 
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define RTEMS_FLASHDEV_REGION_ALLOC_FULL 0xUL
> +#define RTEMS_FLASHDEV_REGION_UNDEFINED 0xUL
> +#define RTEMS_FLASHDEV_REGION_BITALLOC_LENGTH 32
> +
> +static int rtems_flashdev_do_init(
> +  rtems_flashdev *flash,
> +  void ( *destroy )( rtems_flashdev *flash )
> +);
> +
> +static int rtems_flashdev_ioctl_erase(
> +  rtems_flashdev *flash,
> +  rtems_libio_t *iop,
> +  void *arg
> +);
> +
> +static off_t rtems_flashdev_get_region_offset(
> +  rtems_flashdev *flash,
> +  rtems_libio_t *iop
> +);
> +
> +static size_t rtems_flashdev_get_region_size(
> +  rtems_flashdev *flash,
> +  rtems_libio_t *iop
> +);
> +
> +static int rtems_flashdev_ioctl_set_region(
> +  rtems_flashdev *flash,
> +  rtems_libio_t *iop,
> +  void *arg
> +);
> +
> +static int rtems_flashdev_ioctl_create_region(
> +  rtems_flashdev *flash,
> +  rtems_libio_t *iop,
> +  rtems_flashdev_region *region_in
> +);
> +
> +static int rtems_flashdev_ioctl_update_region(
> +  rtems_flashdev *flash,
> +  rtems_libio_t *iop,
> +  rtems_flashdev_region *region_in
> +);
> +
> +static int rtems_flashdev_ioctl_clear_region(
> +  rtems_flashdev *flash,
> +  rtems_libio_t *iop
> +);
> +
> +static uint32_t rtems_flashdev_ioctl_jedec_id(
> +  rtems_flashdev *flash
> +);
> +
> +static uint32_t rtems_flashdev_ioctl_flash_type(
> +  rtems_flashdev *flash,
> +  void *arg
> +);
> +
> +static int rtems_flashdev_ioctl_pageinfo_offset(
> +  rtems_flashdev *flash,
> +  void *arg
> +);
> +
> +static int rtems_flashdev_ioctl_pageinfo_index(
> +  rtems_flashdev *flash,
> +  void *arg
> +);
> +
> +static int rtems_flashdev_ioctl_page_count(
> +  rtems_flashdev *flash,
> +  void *arg
> +);
> +
> +static int rtems_flashdev_ioctl_write_block_size(
> +  rtems_flashdev *flash,
> +  void *arg
> +);
> +
> +static int rtems_flashdev_get_addr(
> +  rtems_flashdev *flash,
> +  rtems_libio_t *iop,
> +  size_t count,
> +  off_t *addr
> +);
> +
> +static int rtems_flashdev_update_and_return(
> +  rtems_libio_t *iop,
> +  int status,
> +  size_t count,
> +  off_t new_offset
> +);
> +
> +static uint32_t rtems_flashdev_find_unalloced_region(
> +  rtems_flashdev_region_table *region_table
> +);
> +
> +static uint32_t rtems_flashdev_set_region(
> +  rtems_flashdev_region_table *region_table,
> +  int index
> +);
> +
> +static uint32_t rtems_flashdev_unset_region(
> +  rtems_flashdev_region_table *region_table,
> +  int index
> +);
> +
> +static uint32_t rtems_flashdev_check_allocation(
> +  rtems_flashdev_region_table *region_table,
> +  int index
> +);
> +
> +static uint32_t rtems_flashdev_get_region_index(
> +  rtems_libio_t *iop
> +)
> +{
> +  return (uint32_t)iop->data0;
> +}
> +
> +static int 

Re: [PATCH v2 1/3] cpukit/flash: Add API for Flash devices

[Gedare Bloom]

On Mon, Apr 17, 2023 at 9:55 PM Chris Johns  wrote:
>
> On 18/4/2023 1:48 pm, Gedare Bloom wrote:
> > On Sun, Apr 16, 2023 at 6:48 PM Aaron Nyholm
> >  wrote:
> >> As for the RTEMS_FLASHDEV_MAX_REGIONS being set at 32 I chose the value as 
> >> it seamed a good balance between memory usage and function. I wanted to 
> >> avoid using malloc as your previous feedback suggested. If configurable 
> >> size is necessary what’s the best way to approach it without using malloc?
> >>
> > A configure-time option may be viable, e.g., spec/build/cpukit/opt*
> > You should probably elevate that question to its own email thread to
> > get other opinions.
>
> Is there an option that shows how to control a defined in an API header?
>
This has mostly been done in the past at a BSP level, so there are
plenty of examples within BSP drivers and frameworks. Whether it is
suitable to a cpukit driver framework is something I don't really
know.

A quick example could be:
BSP_CONSOLE_BAUD
used in bsps/powerpc/shared/console
define in spec/build/bsps/optconsolebaud.yml

I'm not saying this is for sure the right way to do this, but I think
it is worth thinking through.

I think you would have to avoid using the define in the header itself
to make it portable. The way it's defined in this code can be done
with a RTEMS_ZERO_LENGTH_ARRAY. Then the driver that instantiates the
structure can determine for itself the size of how many regions to
support. Even that would be an improvement to the current hard-coded
method. The size itself could be made a field of the rtems_flashdev
that the driver would setup at init time. Whether it is made
configurable in the spec/build approach, or determined by the driver
itself, is less concerning to me than the fact it is currently not
configurable at all and is assumed to be sufficient for all flash
drivers to be 32.

> I have a quick look and could not see anything.
>
> Thanks
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 1/3] cpukit/flash: Add API for Flash devices

[Gedare Bloom]

On Sun, Apr 16, 2023 at 6:48 PM Aaron Nyholm
 wrote:
>
> Hi Gedare,
>
> Thanks for the feedback you’ve provided. I have a couple questions.
>
> You suggest refactoring the callouts into another sturct, I’m happy to do so. 
> I originally chose not to as I was was basing the high level structure off 
> the i2c API already in RTEMS. Just clarifying it’s worth doing.
>
I'm not sure there's much advantage one way or the other. You can
leave it as is for now.

> > You might consider refactoring the callouts to another struct that is
> > included here (either by value or by reference), just to separate the
> > function pointers from the data storage. Not strictly necessary, but
> > it would simplify this struct greatly, and should make implementation
> > of different drivers easier by consolidating the definitions of these
> > callouts.
>
> As for the RTEMS_FLASHDEV_MAX_REGIONS being set at 32 I chose the value as it 
> seamed a good balance between memory usage and function. I wanted to avoid 
> using malloc as your previous feedback suggested. If configurable size is 
> necessary what’s the best way to approach it without using malloc?
>
A configure-time option may be viable, e.g., spec/build/cpukit/opt*
You should probably elevate that question to its own email thread to
get other opinions.

> Thanks,
> Aaron
>
>
> > On 15 Apr 2023, at 01:58, Gedare Bloom  wrote:
> >
> > I focused my review on the API. See below.
> >
> > On Thu, Apr 6, 2023 at 1:08 AM  wrote:
> >>
> >> From: Aaron Nyholm 
> >>
> > [...]
> >> diff --git a/cpukit/include/dev/flash/flashdev.h 
> >> b/cpukit/include/dev/flash/flashdev.h
> >> new file mode 100644
> >> index 00..5d53ea7b97
> >> --- /dev/null
> >> +++ b/cpukit/include/dev/flash/flashdev.h
> >> @@ -0,0 +1,437 @@
> >> +/* SPDX-License-Identifier: BSD-2-Clause */
> >> +
> >> +/**
> >> + * @file
> >> + *
> >> + * @ingroup Flash
> >> + *
> >> + * @brief Generic Flash API
> >> + */
> >> +
> >> +/*
> >> + * Copyright (C) 2023 Aaron Nyholm
> >> + *
> >> + * 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.
> >> + */
> >> +
> >> +#ifndef _DEV_FLASHDEV_H
> >> +#define _DEV_FLASHDEV_H
> >> +
> >> +#include 
> >> +#include 
> >> +
> >> +typedef struct rtems_flashdev rtems_flashdev;
> >> +
> >> +/**
> >> + * @defgroup Generic Flash API
> >> + *
> >> + * @ingroup RTEMSDeviceDrivers
> >> + *
> >> + * @brief Generic Flash API to wrap specific device drivers.
> >> + *
> >> + * @{
> >> + */
> >> +
> >> +/* IOCTL Calls */
> >> +
> >> +/**
> >> + * @brief Obtains the flash device.
> >> + *
> >> + * This command has no argument.
> >> + */
> >> +#define RTEMS_FLASHDEV_IOCTL_OBTAIN 0
> >> +/**
> >> + * @brief Releases the flash device.
> >> + *
> >> + * This command