Re: New API directives to enable/disable interrupt vectors

[Sebastian Huber]

On 16/06/2021 20:36, Gedare Bloom wrote:

Looks like the existing irq-extension.h uses 'vector', so
rtems_interrupt_disable_vector() is a possibility, or else
rtems_interrupt_controller_disable_vector() is more wordy but if we
want to treat 'interrupt controller' as its own category of API
separate from 'interrupt'.


Yes, mixing "vector" into the name a good idea.  What about 
rtems_interrupt_vector_enable() and rtems_interrupt_vector_disable()?


I am not that fond of using "interrupt controller" since I don't want to 
change the existing API and it would result in very long directive names.


--
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 v2] covoar: Store address-to-line info outside of DWARF

[Alex White]

On Mon, Jun 7, 2021 at 8:14 PM Chris Johns  wrote:
>
> On 8/6/21 1:44 am, Joel Sherrill wrote:
> >
> >
> > On Mon, Jun 7, 2021 at 7:00 AM Alex White  > > wrote:
> >
> >
> > On Wed, Jun 2, 2021 at 7:37 PM Chris Johns  > > wrote:
> > >
> > > Looking good with a single comment below ...
> > >
> > > On 3/6/21 6:08 am, Alex White wrote:
> > > > This adds the AddressToLineMapper class and supporting classes to
> > > > assume responsibility of tracking address-to-line information.
> > > >
> > > > This allows the DWARF library to properly cleanup all of its 
> > resources
> > > > and leads to significant memory savings.
> > > >
> > > > Closes #4383
> > > > ---
> > > >  rtemstoolkit/rld-dwarf.cpp   |   5 +
> > > >  rtemstoolkit/rld-dwarf.h |   5 +
> > > >  tester/covoar/AddressToLineMapper.cc | 104 +
> > > >  tester/covoar/AddressToLineMapper.h  | 211 
> > +++
> > > >  tester/covoar/ExecutableInfo.cc  |  73 +
> > > >  tester/covoar/ExecutableInfo.h   |  11 +-
> > > >  tester/covoar/wscript|   1 +
> > > >  7 files changed, 368 insertions(+), 42 deletions(-)
> > > >  create mode 100644 tester/covoar/AddressToLineMapper.cc
> > > >  create mode 100644 tester/covoar/AddressToLineMapper.h
> > > >
> > > > diff --git a/rtemstoolkit/rld-dwarf.cpp b/rtemstoolkit/rld-dwarf.cpp
> > > > index 2fce0e4..1eae50c 100644
> > > > --- a/rtemstoolkit/rld-dwarf.cpp
> > > > +++ b/rtemstoolkit/rld-dwarf.cpp
> > > > @@ -1893,6 +1893,11 @@ namespace rld
> > > >return false;
> > > >  }
> > > >
> > > > +const addresses& compilation_unit::get_addresses () const
> > > > +{
> > > > +  return addr_lines_;
> > > > +}
> > > > +
> > > >  functions&
> > > >  compilation_unit::get_functions ()
> > > >  {
> > > > diff --git a/rtemstoolkit/rld-dwarf.h b/rtemstoolkit/rld-dwarf.h
> > > > index 1210813..eadb50d 100644
> > > > --- a/rtemstoolkit/rld-dwarf.h
> > > > +++ b/rtemstoolkit/rld-dwarf.h
> > > > @@ -707,6 +707,11 @@ namespace rld
> > > > */
> > > >unsigned int pc_high () const;
> > > >
> > > > +  /**
> > > > +   * The addresses associated with this compilation unit.
> > > > +   */
> > > > +  const addresses& get_addresses () const;
> > > > +
> > > >/**
> > > > * Get the source and line for an address. If the address 
> > does
> > not match
> > > > * false is returned the file is set to 'unknown' and the 
> > line is
> > set to
> > > > diff --git a/tester/covoar/AddressToLineMapper.cc
> > b/tester/covoar/AddressToLineMapper.cc
> > > > new file mode 100644
> > > > index 000..c305e3b
> > > > --- /dev/null
> > > > +++ b/tester/covoar/AddressToLineMapper.cc
> > > > @@ -0,0 +1,104 @@
> > > > +/*! @file AddressToLineMapper.cc
> > > > + *  @brief AddressToLineMapper Implementation
> > > > + *
> > > > + *  This file contains the implementation of the functionality
> > > > + *  of the AddressToLineMapper class.
> > > > + */
> > > > +
> > > > +#include "AddressToLineMapper.h"
> > > > +
> > > > +namespace Coverage {
> > > > +
> > > > +  uint64_t SourceLine::location() const
> > > > +  {
> > > > +return address;
> > > > +  }
> > > > +
> > > > +  bool SourceLine::is_an_end_sequence() const
> > > > +  {
> > > > +return is_end_sequence;
> > > > +  }
> > > > +
> > > > +  const std::string& SourceLine::path() const
> > > > +  {
> > > > +return path_;
> > > > +  }
> > > > +
> > > > +  int SourceLine::line() const
> > > > +  {
> > > > +return line_num;
> > > > +  }
> > > > +
> > > > +  void AddressLineRange::addSourceLine(const rld::dwarf::address& 
> > address)
> > > > +  {
> > > > +auto insertResult = sourcePaths.insert(address.path());
> > > > +
> > > > +sourceLines.emplace_back(
> > > > +  SourceLine (
> > > > +address.location(),
> > > > +*insertResult.first,
> > > > +address.line(),
> > > > +address.is_an_end_sequence()
> > > > +  )
> > > > +);
> > > > +  }
> > > > +
> > > > +  const SourceLine& AddressLineRange::getSourceLine(uint32_t 
> > address) const
> > > > +  {
> > > > +if (address < lowAddress || address > highAddress) {
> > > > +  throw SourceNotFoundError(std::to_string(address));
> > > > +}
> > > > +
> > > > +const SourceLine* last_line = nullptr;
> > > > +for (const auto  : sourceLines) {
> > > > +  if (address <= line.location())
> > > > +  

Re: [PATCH] libc: Added sig2str/str2sig prototypes

[Eshan Dhawan]

Hi Matt,
Since you are making changes only to a header file you don’t need to run 
autoreconf.
You can directly apply the patch to RSB and it should work 
You need to run autoreconf when u make changes in makefile 
That is when u add a .c file 

> On 17-Jun-2021, at 1:53 AM, Matt Joyce  wrote:
> 
> ***As Requested: For Review Only. Does Not Compile***
> 
> Added definition of SIG2STR_MAX and function prototypes for sig2str
> and str2sig in sys/signal.h in order to improve POSIX compliance.
> ---
> newlib/libc/include/sys/signal.h | 12 
> 1 file changed, 12 insertions(+)
> 
> diff --git a/newlib/libc/include/sys/signal.h 
> b/newlib/libc/include/sys/signal.h
> index 45cc0366c..fd2b3c672 100644
> --- a/newlib/libc/include/sys/signal.h
> +++ b/newlib/libc/include/sys/signal.h
> @@ -238,6 +238,18 @@ int sigqueue (pid_t, int, const union sigval);
> 
> #endif /* __POSIX_VISIBLE >= 199309 */
> 
> +#if __GNU_VISIBLE
> +
> +/* 202x_d2-POSIX-Issue-8, p. 327 adds SIG2STR_MAX, p. 332 adds sig2str()
> +   and str2sig(). */
> +
> +#define SIG2STR_MAX 4294967295
> +
> +int sig2str(int, char *);
> +int str2sig(const char *restrict, int *restrict);
> +
> +#endif /* __GNU_VISIBLE  */
> +
> #if defined(___AM29K__)
> /* These all need to be defined for ANSI C, but I don't think they are
>meaningful.  */
> -- 
> 2.31.1
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] libc: Added sig2str/str2sig prototypes

[Matt Joyce]

***As Requested: For Review Only. Does Not Compile***

Added definition of SIG2STR_MAX and function prototypes for sig2str
and str2sig in sys/signal.h in order to improve POSIX compliance.
---
 newlib/libc/include/sys/signal.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/newlib/libc/include/sys/signal.h b/newlib/libc/include/sys/signal.h
index 45cc0366c..fd2b3c672 100644
--- a/newlib/libc/include/sys/signal.h
+++ b/newlib/libc/include/sys/signal.h
@@ -238,6 +238,18 @@ int sigqueue (pid_t, int, const union sigval);
 
 #endif /* __POSIX_VISIBLE >= 199309 */
 
+#if __GNU_VISIBLE
+
+/* 202x_d2-POSIX-Issue-8, p. 327 adds SIG2STR_MAX, p. 332 adds sig2str()
+   and str2sig(). */
+
+#define SIG2STR_MAX 4294967295
+
+int sig2str(int, char *);
+int str2sig(const char *restrict, int *restrict);
+
+#endif /* __GNU_VISIBLE  */
+
 #if defined(___AM29K__)
 /* These all need to be defined for ANSI C, but I don't think they are
meaningful.  */
-- 
2.31.1

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

Re: New API directives to enable/disable interrupt vectors

[Gedare Bloom]

On Wed, Jun 16, 2021 at 12:34 PM Gedare Bloom  wrote:
>
> On Wed, Jun 16, 2021 at 5:23 AM Sebastian Huber
>  wrote:
> >
> > Hello,
> >
> > I work currently on an extension of the interrupt manager API:
> >
> > https://devel.rtems.org/ticket/3269
> >
> > This API is not related to the interrupt handling at processor level. It
> > is related to the management of interrupts at the interrupt controller
> > level.
> >
> What happens in case there's no controller?
>
> > We need directives to enable and disable interrupt vectors.
> > Unfortunately, rtems_interrupt_enable() and rtems_interrupt_disable()
> > are already occupied. My first approach was to use
> > rtems_interrupt_mask() and rtems_interrupt_unmask(), however, I noticed
> > that rtems_interrupt_mask is already used. What about
> >
> > rtems_interrupt_permit()
> >
> > and
> >
> > rtems_interrupt_forbid()
> >
> > ?
> >
> Implicitly, rtems_interrupt_* means a directive oriented toward the
> CPU side of the interrupt management? It seems there should be an
> explicit indicator of API calls that target the controller side, like
> rtems_interrupt_controller_xxx()?
>
> Then you can reuse directive names, like
> rtems_interrupt_controller_disable(). Unless there's a possibility to
> enable/disable the controller itself. in which case, we'd need
> something else like rtems_interrupt_controller_disable_irq(int irq) or
> whatever, and perhaps rtems_interrupt_controller_disable_irqs().
>
Looks like the existing irq-extension.h uses 'vector', so
rtems_interrupt_disable_vector() is a possibility, or else
rtems_interrupt_controller_disable_vector() is more wordy but if we
want to treat 'interrupt controller' as its own category of API
separate from 'interrupt'.

> > --
> > 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: New API directives to enable/disable interrupt vectors

[Gedare Bloom]

On Wed, Jun 16, 2021 at 5:23 AM Sebastian Huber
 wrote:
>
> Hello,
>
> I work currently on an extension of the interrupt manager API:
>
> https://devel.rtems.org/ticket/3269
>
> This API is not related to the interrupt handling at processor level. It
> is related to the management of interrupts at the interrupt controller
> level.
>
What happens in case there's no controller?

> We need directives to enable and disable interrupt vectors.
> Unfortunately, rtems_interrupt_enable() and rtems_interrupt_disable()
> are already occupied. My first approach was to use
> rtems_interrupt_mask() and rtems_interrupt_unmask(), however, I noticed
> that rtems_interrupt_mask is already used. What about
>
> rtems_interrupt_permit()
>
> and
>
> rtems_interrupt_forbid()
>
> ?
>
Implicitly, rtems_interrupt_* means a directive oriented toward the
CPU side of the interrupt management? It seems there should be an
explicit indicator of API calls that target the controller side, like
rtems_interrupt_controller_xxx()?

Then you can reuse directive names, like
rtems_interrupt_controller_disable(). Unless there's a possibility to
enable/disable the controller itself. in which case, we'd need
something else like rtems_interrupt_controller_disable_irq(int irq) or
whatever, and perhaps rtems_interrupt_controller_disable_irqs().

> --
> 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 v2 1/1] bsps/i386: Update calibration of TSC to be more accurate

[Joel Sherrill]

Me too. Just needs separate tickets for 5 and 6 so the release notes are
generated correctly.

On Wed, Jun 16, 2021 at 12:51 PM Gedare Bloom  wrote:

> I'm good with it for master and 5.
>
> On Wed, Jun 16, 2021 at 4:18 AM Jan Sommer  wrote:
> >
> > Closes #4455
> > ---
> >  bsps/i386/pc386/clock/ckinit.c | 71 ++
> >  1 file changed, 38 insertions(+), 33 deletions(-)
> >
> > diff --git a/bsps/i386/pc386/clock/ckinit.c
> b/bsps/i386/pc386/clock/ckinit.c
> > index 09afe73cde..2df1818dd3 100644
> > --- a/bsps/i386/pc386/clock/ckinit.c
> > +++ b/bsps/i386/pc386/clock/ckinit.c
> > @@ -104,48 +104,60 @@ static uint32_t pc386_get_timecount_i8254(struct
> timecounter *tc)
> >
> >  /*
> >   * Calibrate CPU cycles per tick. Interrupts should be disabled.
> > + * Will also set the PIT, so call this before registering the
> > + * periodic timer for rtems tick generation
> >   */
> >  static void calibrate_tsc(void)
> >  {
> >uint64_t  begin_time;
> > -  uint8_t   then_lsb, then_msb, now_lsb, now_msb;
> > -  uint32_t  i;
> > -
> > -  /*
> > -   * We just reset the timer, so we know we're at the beginning of a
> tick.
> > -   */
> > -
> > -  /*
> > -   * Count cycles. Watching the timer introduces a several microsecond
> > -   * uncertaintity, so let it cook for a while and divide by the number
> of
> > -   * ticks actually executed.
> > -   */
> > +  uint8_t   lsb, msb;
> > +  uint32_t  max_timer_value;
> > +  uint32_t  last_tick, cur_tick;
> > +  int32_t   diff, remaining;
> > +
> > +  /* Set the timer to free running mode */
> > +  outport_byte(TIMER_MODE, TIMER_SEL0 | TIMER_16BIT | TIMER_INTTC);
> > +  /* Reset the 16 timer reload value, first LSB, then MSB */
> > +  outport_byte(TIMER_CNTR0, 0);
> > +  outport_byte(TIMER_CNTR0, 0);
> > +  /* We use the full 16 bit */
> > +  max_timer_value = 0x;
> > +  /* Calibrate for 1s, i.e. TIMER_TICK PIT ticks */
> > +  remaining = TIMER_TICK;
> >
> >begin_time = rdtsc();
> > -
> > -  for (i = rtems_clock_get_ticks_per_second() * pc386_isrs_per_tick;
> > -   i != 0; --i ) {
> > -/* We know we've just completed a tick when timer goes from low to
> high */
> > -then_lsb = then_msb = 0xff;
> > -do {
> > -  READ_8254(now_lsb, now_msb);
> > -  if ((then_msb < now_msb) ||
> > -  ((then_msb == now_msb) && (then_lsb < now_lsb)))
> > -break;
> > -  then_lsb = now_lsb;
> > -  then_msb = now_msb;
> > -} while (1);
> > +  READ_8254(lsb, msb);
> > +  last_tick = (msb << 8) | lsb;
> > +  while(remaining > 0) {
> > +READ_8254(lsb, msb);
> > +cur_tick = (msb << 8) | lsb;
> > +/* PIT counts down, so subtract cur from last */
> > +diff = last_tick - cur_tick;
> > +last_tick = cur_tick;
> > +if (diff < 0) {
> > +diff += max_timer_value;
> > +}
> > +remaining -= diff;
> >}
> >
> >pc586_tsc_frequency = rdtsc() - begin_time;
> >
> >  #if 0
> > -  printk( "CPU clock at %u MHz\n", (uint32_t)(pc586_tsc_frequency /
> 100));
> > +  printk( "CPU clock at %u Hz\n", (uint32_t)(pc586_tsc_frequency ));
> >  #endif
> >  }
> >
> >  static void clockOn(void)
> >  {
> > +
> > +  /*
> > +   * First calibrate the TSC. Do this every time we
> > +   * turn the clock on in case the CPU clock speed has changed.
> > +   */
> > +  if ( x86_has_tsc() ) {
> > +calibrate_tsc();
> > +  }
> > +
> >rtems_interrupt_lock_context lock_context;
> >pc386_isrs_per_tick= 1;
> >pc386_microseconds_per_isr =
> rtems_configuration_get_microseconds_per_tick();
> > @@ -171,13 +183,6 @@ static void clockOn(void)
> >rtems_interrupt_lock_release(_i386_i8254_access_lock,
> _context);
> >
> >bsp_interrupt_vector_enable( BSP_PERIODIC_TIMER );
> > -
> > -  /*
> > -   * Now calibrate cycles per tick. Do this every time we
> > -   * turn the clock on in case the CPU clock speed has changed.
> > -   */
> > -  if ( x86_has_tsc() )
> > -calibrate_tsc();
> >  }
> >
> >  bool Clock_isr_enabled = false;
> > --
> > 2.17.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH rtems-libbsd v3 4/4] rtemsbsd: Added a test for the TTCP command.

[Stephen Clark]

Added a new test for the TTCP command. Modified default-network-init.h
to conditionally build the shell with TTCP. Modified libbsd.py to build
the new TTCP test.
---
 libbsd.py |  1 +
 .../rtems/bsd/test/default-network-init.h |  7 +++
 testsuite/ttcpshell01/test_main.c | 55 +++
 3 files changed, 63 insertions(+)
 create mode 100644 testsuite/ttcpshell01/test_main.c

diff --git a/libbsd.py b/libbsd.py
index 2badfdee..cb310770 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -5189,6 +5189,7 @@ class tests(builder.Module):
 
 def generate(self):
 mm = self.manager
+self.addTest(mm.generator['test']('ttcpshell01', ['test_main'], 
netTest = True, runTest = False))
 self.addTest(mm.generator['test']('epoch01', ['test_main'], extraLibs 
= ['rtemstest']))
 self.addTest(mm.generator['test']('nfs01', ['test_main'],
   netTest = True, modules = ['nfsv2']))
diff --git a/testsuite/include/rtems/bsd/test/default-network-init.h 
b/testsuite/include/rtems/bsd/test/default-network-init.h
index b367d956..20c0b2e7 100644
--- a/testsuite/include/rtems/bsd/test/default-network-init.h
+++ b/testsuite/include/rtems/bsd/test/default-network-init.h
@@ -318,9 +318,16 @@ Init(rtems_task_argument arg)
   #define SHELL_WPA_SUPPLICANT_COMMAND
 #endif
 
+#ifdef SHELL_TTCP_COMMAND_ENABLE
+  #define SHELL_TTCP_COMMAND _shell_TTCP_Command,
+#else
+  #define SHELL_TTCP_COMMAND 
+#endif
+
 #define CONFIGURE_SHELL_USER_COMMANDS \
   SHELL_WLANSTATS_COMMAND \
   SHELL_WPA_SUPPLICANT_COMMAND \
+  SHELL_TTCP_COMMAND \
   _interrupt_shell_command, \
   _shell_ARP_Command, \
   _shell_HOSTNAME_Command, \
diff --git a/testsuite/ttcpshell01/test_main.c 
b/testsuite/ttcpshell01/test_main.c
new file mode 100644
index ..c7631d14
--- /dev/null
+++ b/testsuite/ttcpshell01/test_main.c
@@ -0,0 +1,55 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @brief RTEMS shell is started with DHCP client. It is possible to run TTCP.
+ */
+
+/*
+ * COPYRIGHT (c) 2021. On-Line Applications Research Corporation (OAR).
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR 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 AUTHOR 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 
+
+#define TEST_NAME "LIBBSD TTCP 1"
+#define TEST_STATE_USER_INPUT 1
+
+static void
+test_main(void)
+{
+   rtems_task_delete(RTEMS_SELF);
+   assert(0);
+}
+
+#define SHELL_TTCP_COMMAND_ENABLE
+#define DEFAULT_NETWORK_DHCPCD_ENABLE
+#define DEFAULT_NETWORK_SHELL
+
+#include 
-- 
2.27.0

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

[PATCH rtems-libbsd v3 3/4] rtemsbsd: Made TTCP command build for RTEMS

[Stephen Clark]

Updated ttcp.c to build clean for RTEMS 6 and the machines it
originally built for. Also fixed ttcp.c to close network
sockets after completion. Defined a shell command for TTCP in
rtems-bsd-shell-ttcp.c. Added TTCP to the list of RTEMS network
commands in netcmds-config.h. Added declaration of the TTCP shell
command to rtems-bsd-commands.h. Modified libbsd.py to make waf
build TTCP and its shell command.
---
 libbsd.py |   2 +
 rtemsbsd/include/machine/rtems-bsd-commands.h |   2 +
 rtemsbsd/include/rtems/netcmds-config.h   |   2 +
 rtemsbsd/rtems/rtems-bsd-shell-ttcp.c |  39 +++
 rtemsbsd/ttcp/README  |  11 +-
 rtemsbsd/ttcp/ttcp.c  | 279 ++
 6 files changed, 272 insertions(+), 63 deletions(-)
 create mode 100644 rtemsbsd/rtems/rtems-bsd-shell-ttcp.c

diff --git a/libbsd.py b/libbsd.py
index b367d94e..2badfdee 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -269,6 +269,7 @@ class rtems(builder.Module):
 'rtems/rtems-bsd-shell-tcpdump.c',
 'rtems/rtems-bsd-shell-vmstat.c',
 'rtems/rtems-bsd-shell-wlanstats.c',
+'rtems/rtems-bsd-shell-ttcp.c',
 'rtems/rtems-kvm.c',
 'rtems/rtems-program.c',
 'rtems/rtems-program-socket.c',
@@ -292,6 +293,7 @@ class rtems(builder.Module):
 'pppd/upap.c',
 'pppd/utils.c',
 'telnetd/telnetd-service.c',
+'ttcp/ttcp.c',
 ],
 mm.generator['source']()
 )
diff --git a/rtemsbsd/include/machine/rtems-bsd-commands.h 
b/rtemsbsd/include/machine/rtems-bsd-commands.h
index d314471f..d82c274c 100644
--- a/rtemsbsd/include/machine/rtems-bsd-commands.h
+++ b/rtemsbsd/include/machine/rtems-bsd-commands.h
@@ -84,6 +84,8 @@ int rtems_bsd_command_setkey(int argc, char **argv);
 
 int rtems_bsd_command_openssl(int argc, char **argv);
 
+int rtems_shell_main_ttcp(int argc, char **argv);
+
 __END_DECLS
 
 #endif /* _RTEMS_BSD_MACHINE_RTEMS_BSD_COMMANDS_H_ */
diff --git a/rtemsbsd/include/rtems/netcmds-config.h 
b/rtemsbsd/include/rtems/netcmds-config.h
index bc493af4..c1d56eb3 100644
--- a/rtemsbsd/include/rtems/netcmds-config.h
+++ b/rtemsbsd/include/rtems/netcmds-config.h
@@ -29,6 +29,8 @@ extern rtems_shell_cmd_t rtems_shell_PFCTL_Command;
 extern rtems_shell_cmd_t rtems_shell_PING_Command;
 extern rtems_shell_cmd_t rtems_shell_PING6_Command;
 
+extern rtems_shell_cmd_t rtems_shell_TTCP_Command;
+
 extern rtems_shell_cmd_t rtems_shell_IFCONFIG_Command;
 
 extern rtems_shell_cmd_t rtems_shell_IFMCSTAT_Command;
diff --git a/rtemsbsd/rtems/rtems-bsd-shell-ttcp.c 
b/rtemsbsd/rtems/rtems-bsd-shell-ttcp.c
new file mode 100644
index ..babaa011
--- /dev/null
+++ b/rtemsbsd/rtems/rtems-bsd-shell-ttcp.c
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * COPYRIGHT (c) 2021. On-Line Applications Research Corporation (OAR).
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR 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 AUTHOR 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 
+
+rtems_shell_cmd_t rtems_shell_TTCP_Command = {
+  "ttcp",   /* name */
+  "ttcp -h # to get help",  /* usage */
+  "net",/* topic */
+  rtems_shell_main_ttcp,/* command */
+  NULL, /* alias */
+  NULL  /* next */
+};
diff --git a/rtemsbsd/ttcp/README b/rtemsbsd/ttcp/README
index 215ddacc..8a9bf017 100644
--- a/rtemsbsd/ttcp/README
+++ b/rtemsbsd/ttcp/README
@@ -7,14 +7,9 @@ but please do 

[PATCH rtems-libbsd v3 1/4] rtemsbsd: Added original TTCP code

[Stephen Clark]

Added the original Test TCP (TTCP) program in unmodified form.
Also added the original README for TTCP. Both the README and the
TTCP program were sourced from the first commit in the RTEMS
network demos repository.
---
 rtemsbsd/ttcp/README |  27 ++
 rtemsbsd/ttcp/ttcp.c | 841 +++
 2 files changed, 868 insertions(+)
 create mode 100644 rtemsbsd/ttcp/README
 create mode 100644 rtemsbsd/ttcp/ttcp.c

diff --git a/rtemsbsd/ttcp/README b/rtemsbsd/ttcp/README
new file mode 100644
index ..215ddacc
--- /dev/null
+++ b/rtemsbsd/ttcp/README
@@ -0,0 +1,27 @@
+TTCP is a benchmarking tool for determining TCP and UDP performance
+between 2 systems.
+
+The program was created at the US Army Ballistics Research Lab (BRL)
+and is in the public domain. Feel free to distribute this program
+but please do leave the credit notices in the source and man page intact.
+
+Contents of this directory:
+
+ttcp.c  Source that runs on IRIX 3.3.x and 4.0.x systems
+and BSD-based systems.  This version also uses getopt(3)
+and has 2 new options: -f and -T.
+
+ttcp.c-brl  Original source from BRL.
+
+ttcp.1  Manual page (describes ttcp.c options, which are a
+superset of the other version).
+
+
+How to get TCP performance numbers:
+
+receiversender
+
+host1%  ttcp -r -s  host2% ttcp -t -s host1
+
+-n and -l options change the number and size of the buffers.
+
diff --git a/rtemsbsd/ttcp/ttcp.c b/rtemsbsd/ttcp/ttcp.c
new file mode 100644
index ..305a7c7d
--- /dev/null
+++ b/rtemsbsd/ttcp/ttcp.c
@@ -0,0 +1,841 @@
+/*
+ * T T C P . C
+ *
+ * Test TCP connection.  Makes a connection on port 5001
+ * and transfers fabricated buffers or data copied from stdin.
+ *
+ * Usable on 4.2, 4.3, and 4.1a systems by defining one of
+ * BSD42 BSD43 (BSD41a)
+ * Machines using System V with BSD sockets should define SYSV.
+ *
+ * Modified for operation under 4.2BSD, 18 Dec 84
+ *  T.C. Slattery, USNA
+ * Minor improvements, Mike Muuss and Terry Slattery, 16-Oct-85.
+ * Modified in 1989 at Silicon Graphics, Inc.
+ * catch SIGPIPE to be able to print stats when receiver has died 
+ * for tcp, don't look for sentinel during reads to allow small transfers
+ * increased default buffer size to 8K, nbuf to 2K to transfer 16MB
+ * moved default port to 5001, beyond IPPORT_USERRESERVED
+ * make sinkmode default because it is more popular, 
+ * -s now means don't sink/source 
+ * count number of read/write system calls to see effects of 
+ * blocking from full socket buffers
+ * for tcp, -D option turns off buffered writes (sets TCP_NODELAY sockopt)
+ * buffer alignment options, -A and -O
+ * print stats in a format that's a bit easier to use with grep & awk
+ * for SYSV, mimic BSD routines to use most of the existing timing code
+ * Modified by Steve Miller of the University of Maryland, College Park
+ * -b sets the socket buffer size (SO_SNDBUF/SO_RCVBUF)
+ * Modified Sept. 1989 at Silicon Graphics, Inc.
+ * restored -s sense at request of tcs@brl
+ * Modified Oct. 1991 at Silicon Graphics, Inc.
+ * use getopt(3) for option processing, add -f and -T options.
+ * SGI IRIX 3.3 and 4.0 releases don't need #define SYSV.
+ *
+ * Distribution Status -
+ *  Public Domain.  Distribution Unlimited.
+ */
+#ifndef lint
+static char RCSid[] = "ttcp.c $Revision$";
+#endif
+
+#define BSD43
+/* #define BSD42 */
+/* #define BSD41a */
+/* #define SYSV */ /* required on SGI IRIX releases before 3.3 */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include   /* struct timeval */
+
+#if defined(SYSV)
+#include 
+#include 
+struct rusage {
+struct timeval ru_utime, ru_stime;
+};
+#define RUSAGE_SELF 0
+#else
+#include 
+#endif
+
+struct sockaddr_in sinme;
+struct sockaddr_in sinhim;
+struct sockaddr_in frominet;
+
+int domain, fromlen;
+int fd;/* fd of network socket */
+
+int buflen = 8 * 1024; /* length of buffer */
+char *buf; /* ptr to dynamic buffer */
+int nbuf = 2 * 1024;   /* number of buffers to send in sinkmode */
+
+int bufoffset = 0; /* align buffer to this */
+int bufalign = 16*1024;/* modulo this */
+
+int udp = 0;   /* 0 = tcp, !0 = udp */
+int options = 0;   /* socket options */
+int one = 1;/* for 4.3 BSD style setsockopt() */
+short port = 5001; /* TCP port number */
+char *host;/* ptr to name of host */
+int trans; /* 0=receive, !0=transmit mode */
+int sinkmode = 0;  /* 0=normal I/O, !0=sink/source mode */
+int verbose = 0;   /* 0=print basic info, 1=print cpu rate, proc
+ 

[PATCH rtems-libbsd v3 2/4] rtemsbsd:Updated TTCP code with network demo code

[Stephen Clark]

Updated the TTCP code to match the ttcp.c in RTEMS network-demos
repository (https://git.rtems.org/network-demos/).
---
 rtemsbsd/ttcp/ttcp.c | 91 +++-
 1 file changed, 65 insertions(+), 26 deletions(-)

diff --git a/rtemsbsd/ttcp/ttcp.c b/rtemsbsd/ttcp/ttcp.c
index 305a7c7d..dc62c64b 100644
--- a/rtemsbsd/ttcp/ttcp.c
+++ b/rtemsbsd/ttcp/ttcp.c
@@ -35,8 +35,9 @@
  * Distribution Status -
  *  Public Domain.  Distribution Unlimited.
  */
+
 #ifndef lint
-static char RCSid[] = "ttcp.c $Revision$";
+/* static char RCSid[] = "ttcp.c $Revision$"; */
 #endif
 
 #define BSD43
@@ -44,6 +45,8 @@ static char RCSid[] = "ttcp.c $Revision$";
 /* #define BSD41a */
 /* #define SYSV */ /* required on SGI IRIX releases before 3.3 */
 
+#define ENABLE_NANOSLEEP_DELAY
+
 #include 
 #include 
 #include 
@@ -54,8 +57,12 @@ static char RCSid[] = "ttcp.c $Revision$";
 #include 
 #include 
 #include 
+#include 
 #include   /* struct timeval */
 
+#include 
+#include 
+
 #if defined(SYSV)
 #include 
 #include 
@@ -71,7 +78,13 @@ struct sockaddr_in sinme;
 struct sockaddr_in sinhim;
 struct sockaddr_in frominet;
 
-int domain, fromlen;
+/* these make it easier to avoid warnings */
+struct sockaddr *sinhim_p = (struct sockaddr *) 
+struct sockaddr *sinme_p = (struct sockaddr *) 
+struct sockaddr *frominet_p = (struct sockaddr *) 
+
+int domain;
+socklen_t fromlen;
 int fd;/* fd of network socket */
 
 int buflen = 8 * 1024; /* length of buffer */
@@ -97,6 +110,7 @@ char fmt = 'K';  /* output format: k = 
kilobits, K = kilobytes,
 *  m = megabits, M = megabytes, 
 *  g = gigabits, G = gigabytes */
 int touchdata = 0; /* access data after reading */
+long milliseconds = 0;  /* delay in milliseconds */
 
 struct hostent *addr;
 extern int errno;
@@ -124,6 +138,7 @@ Options specific to -t:\n\
 Options specific to -r:\n\
-B  for -s, only output full blocks as specified by -l (for TAR)\n\
-T  \"touch\": access each byte as it's read\n\
+   -m ##   delay for specified milliseconds between each write\n\
 "; 
 
 char stats[128];
@@ -133,7 +148,7 @@ double cput, realt; /* user, real time (seconds) */
 
 void err();
 void mes();
-int pattern();
+void pattern();
 void prep_timer();
 double read_timer();
 int Nread();
@@ -147,7 +162,18 @@ sigpipe()
 {
 }
 
-main(argc,argv)
+void millisleep(long msec)
+{
+#if defined(ENABLE_NANOSLEEP_DELAY)
+  struct timespec req;
+
+  req.tv_sec = msec / 1000;
+  req.tv_nsec = (msec % 1000) * 100;
+
+  nanosleep( , NULL );
+#endif
+}
+int main(argc,argv)
 int argc;
 char **argv;
 {
@@ -156,7 +182,7 @@ char **argv;
 
if (argc < 2) goto usage;
 
-   while ((c = getopt(argc, argv, "drstuvBDTb:f:l:n:p:A:O:")) != -1) {
+   while ((c = getopt(argc, argv, "drstuvBDTb:f:l:m:n:p:A:O:")) != -1) {
switch (c) {
 
case 'B':
@@ -179,6 +205,12 @@ char **argv;
"ttcp: -D option ignored: TCP_NODELAY socket option not supported\n");
 #endif
break;
+   case 'm':
+   milliseconds = atoi(optarg);
+   #if !defined(ENABLE_NANOSLEEP_DELAY)
+   fprintf(stderr, "millisecond delay disabled\n");
+   #endif
+   break;
case 'n':
nbuf = atoi(optarg);
break;
@@ -285,7 +317,7 @@ char **argv;
err("socket");
mes("socket");
 
-   if (bind(fd, , sizeof(sinme)) < 0)
+   if (bind(fd, sinme_p, sizeof(sinme)) < 0)
err("bind");
 
 #if defined(SO_SNDBUF) || defined(SO_RCVBUF)
@@ -305,7 +337,9 @@ char **argv;
 #endif
 
if (!udp)  {
+#if !defined(__rtems__)
signal(SIGPIPE, sigpipe);
+#endif
if (trans) {
/* We are the client if transmitting */
if (options)  {
@@ -326,7 +360,7 @@ char **argv;
mes("nodelay");
}
 #endif
-   if(connect(fd, , sizeof(sinhim) ) < 0)
+   if(connect(fd, sinhim_p, sizeof(sinhim) ) < 0)
err("connect");
mes("connect");
} else {
@@ -348,11 +382,11 @@ char **argv;
}
fromlen = sizeof(frominet);
domain = AF_INET;
-   if((fd=accept(fd, , ) ) < 0)
+   if((fd=accept(fd, frominet_p, ) ) < 0)
err("accept");
{ struct sockaddr_in peer;
- int peerlen = sizeof(peer);
- if (getpeername(fd, (struct sockaddr_in *) , 
+ socklen_t peerlen = sizeof(peer);
+ if (getpeername(fd, (struct sockaddr *) , 
) < 0) {
 

Re: [PATCH v2 1/1] bsps/i386: Update calibration of TSC to be more accurate

[Gedare Bloom]

I'm good with it for master and 5.

On Wed, Jun 16, 2021 at 4:18 AM Jan Sommer  wrote:
>
> Closes #4455
> ---
>  bsps/i386/pc386/clock/ckinit.c | 71 ++
>  1 file changed, 38 insertions(+), 33 deletions(-)
>
> diff --git a/bsps/i386/pc386/clock/ckinit.c b/bsps/i386/pc386/clock/ckinit.c
> index 09afe73cde..2df1818dd3 100644
> --- a/bsps/i386/pc386/clock/ckinit.c
> +++ b/bsps/i386/pc386/clock/ckinit.c
> @@ -104,48 +104,60 @@ static uint32_t pc386_get_timecount_i8254(struct 
> timecounter *tc)
>
>  /*
>   * Calibrate CPU cycles per tick. Interrupts should be disabled.
> + * Will also set the PIT, so call this before registering the
> + * periodic timer for rtems tick generation
>   */
>  static void calibrate_tsc(void)
>  {
>uint64_t  begin_time;
> -  uint8_t   then_lsb, then_msb, now_lsb, now_msb;
> -  uint32_t  i;
> -
> -  /*
> -   * We just reset the timer, so we know we're at the beginning of a tick.
> -   */
> -
> -  /*
> -   * Count cycles. Watching the timer introduces a several microsecond
> -   * uncertaintity, so let it cook for a while and divide by the number of
> -   * ticks actually executed.
> -   */
> +  uint8_t   lsb, msb;
> +  uint32_t  max_timer_value;
> +  uint32_t  last_tick, cur_tick;
> +  int32_t   diff, remaining;
> +
> +  /* Set the timer to free running mode */
> +  outport_byte(TIMER_MODE, TIMER_SEL0 | TIMER_16BIT | TIMER_INTTC);
> +  /* Reset the 16 timer reload value, first LSB, then MSB */
> +  outport_byte(TIMER_CNTR0, 0);
> +  outport_byte(TIMER_CNTR0, 0);
> +  /* We use the full 16 bit */
> +  max_timer_value = 0x;
> +  /* Calibrate for 1s, i.e. TIMER_TICK PIT ticks */
> +  remaining = TIMER_TICK;
>
>begin_time = rdtsc();
> -
> -  for (i = rtems_clock_get_ticks_per_second() * pc386_isrs_per_tick;
> -   i != 0; --i ) {
> -/* We know we've just completed a tick when timer goes from low to high 
> */
> -then_lsb = then_msb = 0xff;
> -do {
> -  READ_8254(now_lsb, now_msb);
> -  if ((then_msb < now_msb) ||
> -  ((then_msb == now_msb) && (then_lsb < now_lsb)))
> -break;
> -  then_lsb = now_lsb;
> -  then_msb = now_msb;
> -} while (1);
> +  READ_8254(lsb, msb);
> +  last_tick = (msb << 8) | lsb;
> +  while(remaining > 0) {
> +READ_8254(lsb, msb);
> +cur_tick = (msb << 8) | lsb;
> +/* PIT counts down, so subtract cur from last */
> +diff = last_tick - cur_tick;
> +last_tick = cur_tick;
> +if (diff < 0) {
> +diff += max_timer_value;
> +}
> +remaining -= diff;
>}
>
>pc586_tsc_frequency = rdtsc() - begin_time;
>
>  #if 0
> -  printk( "CPU clock at %u MHz\n", (uint32_t)(pc586_tsc_frequency / 
> 100));
> +  printk( "CPU clock at %u Hz\n", (uint32_t)(pc586_tsc_frequency ));
>  #endif
>  }
>
>  static void clockOn(void)
>  {
> +
> +  /*
> +   * First calibrate the TSC. Do this every time we
> +   * turn the clock on in case the CPU clock speed has changed.
> +   */
> +  if ( x86_has_tsc() ) {
> +calibrate_tsc();
> +  }
> +
>rtems_interrupt_lock_context lock_context;
>pc386_isrs_per_tick= 1;
>pc386_microseconds_per_isr = 
> rtems_configuration_get_microseconds_per_tick();
> @@ -171,13 +183,6 @@ static void clockOn(void)
>rtems_interrupt_lock_release(_i386_i8254_access_lock, _context);
>
>bsp_interrupt_vector_enable( BSP_PERIODIC_TIMER );
> -
> -  /*
> -   * Now calibrate cycles per tick. Do this every time we
> -   * turn the clock on in case the CPU clock speed has changed.
> -   */
> -  if ( x86_has_tsc() )
> -calibrate_tsc();
>  }
>
>  bool Clock_isr_enabled = false;
> --
> 2.17.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: GSOC POSIX Compliance: Stuck trying to build Newlib

[Matthew Joyce]

Ok, thanks!

I'm about to sign off for dinner,  but I'll send the patch (with
disclaimer) tonight.  So since the code fails to compile, I need to
start making some changes. Do I need to rebuild the rtems tool chain
each time? I'm averaging about 1.33 hours on that :-( . Is that where
some of the scripts you sent help out?

Sorry we didn't connect tonight, but please let me know if there's
another day this week you could chat!

Thanks so much for everybody's patience and support!

Sincerely,

Matt

On Wed, Jun 16, 2021 at 6:43 PM Joel Sherrill  wrote:
>
>
>
> On Wed, Jun 16, 2021 at 11:37 AM Matthew Joyce  wrote:
>>
>> I hate to ask, but where should the build binaries be if "make all"
>> was actually successful?
>
>
> For newlib, there should be various libc.a and libm.a files in the build 
> directory.
>
> Use find to locate them: find . -name libc.a
>
> And use "nm" to find out if the symbol is there.
>
> sparc-rtems6-nm .../libc.a
>
> You can save that output or pipe it to less.
>
> Note: paths need to be adjusted to the files.
>
> --joel
>>
>>
>> Thanks!
>>
>> Matt
>>
>> On Wed, Jun 16, 2021 at 6:16 PM Eshan Dhawan  wrote:
>> >
>> > Hi Matt,
>> > > On 16-Jun-2021, at 9:27 PM, Matthew Joyce  wrote:
>> > >
>> > > Hi Dr. Joel,
>> > >
>> > > I tried that in newlib/libc and there were at least no errors.
>> > > (Nothing leading me to believe it was successful either!)
>> > >
>> > > However I still got the same error when I sudo make install.
>> > > (sparc-rtems-ranlib: command not found) (among others!)
>> > >
>> > I make works then there is no need to run make install it just copies the 
>> > build binaries to the root folders.
>> >
>> > If make is build with the changes u made and the symbols that you added 
>> > appear in the binaries you generated.
>> > Then congratulations :)
>> > Now you just need to test those changes in the RSB to test they don’t 
>> > break anything in the RTEMS ecosystem.
>> > > Thanks again!
>> > >
>> > > Sincerely,
>> > >
>> > > Matt
>> > >
>> > >
>> > >
>> > >> On Wed, Jun 16, 2021 at 3:06 PM Joel Sherrill  wrote:
>> > >>
>> > >> Does adding --no-recursive and running it only from the directory you 
>> > >> touched a build system file in help?
>> > >>
>> > >> It is regenerating a lot you don't want to touch anyway.
>> > >>
>> > >> --joel
>> > >>
>> > >>> On Wed, Jun 16, 2021, 5:32 AM Matthew Joyce  
>> > >>> wrote:
>> > >>>
>> > >>> Hi Eshan,
>> > >>>
>> > >>> Thanks very much for your follow up! Ok, I see now that if I go into
>> > >>> development/newlib/newlib-cygwin/newlib and run autoreconf -fvi with
>> > >>> the v2.69 using the PATH that Dr. Joel just showed, it starts to run.
>> > >>> It always eventually exits with an error though. (please see attached
>> > >>> .txt). I hope you can read that...I used the command "script" to
>> > >>> output everything to a text file.
>> > >>>
>> > >>> Do you have any idea where I might be going wrong?
>> > >>>
>> > >>> Thank you!
>> > >>>
>> > >>> Sincerely,
>> > >>>
>> > >>> Matt
>> > >>>
>> > >>> On Tue, Jun 15, 2021 at 8:23 PM Eshan Dhawan  
>> > >>> wrote:
>> > 
>> >  Hi matt
>> >  It would work if run inside newlib instead of newlib-cygwin
>> >  run command inside of ../newlib-cygwin/newlib
>> >  instead of ../newlib-cygwin
>> > 
>> > 
>> >  On Tue, Jun 15, 2021 at 10:59 PM Matthew Joyce 
>> >   wrote:
>> > >
>> > > Ah, ok will do! Thank you for the tip.
>> > >
>> > > On Tue, Jun 15, 2021 at 7:17 PM Gedare Bloom  
>> > > wrote:
>> > >>
>> > >> Just a note, it's more efficient to capture your terminal dump into 
>> > >> a
>> > >> text file and attach that, rather than put a screenshot up.
>> > >>
>> > >> On Tue, Jun 15, 2021 at 11:14 AM Matthew Joyce 
>> > >>  wrote:
>> > >>>
>> > >>> Hi Gentlemen,
>> > >>>
>> > >>> Thanks very much for your quick replies!
>> > >>>
>> > >>> I just tried both, but perhaps I'm misinterpreting your 
>> > >>> suggestions.
>> > >>> (Could you please see the attached commands / errors!)
>> > >>>
>> > >>> Eshan,
>> > >>>
>> > >>> I did see that link, but it wasn't clear to me what the solution 
>> > >>> was...Sorry!
>> > >>>
>> > >>> Sincerely,
>> > >>>
>> > >>> Matt
>> > >>>
>> > >>> On Tue, Jun 15, 2021 at 6:52 PM Eshan Dhawan 
>> > >>>  wrote:
>> > 
>> >  Hi Matt,
>> >  Try running the command with autoconf version 2.69 that's shipped 
>> >  with RTEMS in the rtems bin
>> >  That works as well.
>> > 
>> >  Also From a quick google search this is what I found : 
>> >  https://superuser.com/questions/617872/cant-locate-autom4te-channeldefs-pm-in-inc-when-it-definitely-is-there
>> > 
>> >  On Tue, Jun 15, 2021 at 9:12 PM Matthew Joyce 
>> >   wrote:
>> > >
>> > > Hello Dr. Joel and Eshan,
>> > >
>> > > I have a patch ready to 

Coverity Scan News

[Joel Sherrill]

Hi

A few news items about RTEMS and Coverity Scan.

We now have automated cron analysis runs for RTEMS, RTEMS Tools and Newlib
available. When one of those changes, new results should be available
shortly after they are committed.

Some progress has been made at nibbling down on the issues. More remain and
help is appreciated.

I updated to the latest version and switched from a custom gcc 9 to the
normal RSB built gcc 10 for analysis runs.

Gedare has had some of his students pitch in on the issues and that's
really appreciated.

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

Re: GSOC POSIX Compliance: Stuck trying to build Newlib

[Joel Sherrill]

On Wed, Jun 16, 2021 at 11:37 AM Matthew Joyce 
wrote:

> I hate to ask, but where should the build binaries be if "make all"
> was actually successful?
>

For newlib, there should be various libc.a and libm.a files in the build
directory.

Use find to locate them: find . -name libc.a

And use "nm" to find out if the symbol is there.

sparc-rtems6-nm .../libc.a

You can save that output or pipe it to less.

Note: paths need to be adjusted to the files.

--joel

>
> Thanks!
>
> Matt
>
> On Wed, Jun 16, 2021 at 6:16 PM Eshan Dhawan 
> wrote:
> >
> > Hi Matt,
> > > On 16-Jun-2021, at 9:27 PM, Matthew Joyce 
> wrote:
> > >
> > > Hi Dr. Joel,
> > >
> > > I tried that in newlib/libc and there were at least no errors.
> > > (Nothing leading me to believe it was successful either!)
> > >
> > > However I still got the same error when I sudo make install.
> > > (sparc-rtems-ranlib: command not found) (among others!)
> > >
> > I make works then there is no need to run make install it just copies
> the build binaries to the root folders.
> >
> > If make is build with the changes u made and the symbols that you added
> appear in the binaries you generated.
> > Then congratulations :)
> > Now you just need to test those changes in the RSB to test they don’t
> break anything in the RTEMS ecosystem.
> > > Thanks again!
> > >
> > > Sincerely,
> > >
> > > Matt
> > >
> > >
> > >
> > >> On Wed, Jun 16, 2021 at 3:06 PM Joel Sherrill  wrote:
> > >>
> > >> Does adding --no-recursive and running it only from the directory you
> touched a build system file in help?
> > >>
> > >> It is regenerating a lot you don't want to touch anyway.
> > >>
> > >> --joel
> > >>
> > >>> On Wed, Jun 16, 2021, 5:32 AM Matthew Joyce 
> wrote:
> > >>>
> > >>> Hi Eshan,
> > >>>
> > >>> Thanks very much for your follow up! Ok, I see now that if I go into
> > >>> development/newlib/newlib-cygwin/newlib and run autoreconf -fvi with
> > >>> the v2.69 using the PATH that Dr. Joel just showed, it starts to run.
> > >>> It always eventually exits with an error though. (please see attached
> > >>> .txt). I hope you can read that...I used the command "script" to
> > >>> output everything to a text file.
> > >>>
> > >>> Do you have any idea where I might be going wrong?
> > >>>
> > >>> Thank you!
> > >>>
> > >>> Sincerely,
> > >>>
> > >>> Matt
> > >>>
> > >>> On Tue, Jun 15, 2021 at 8:23 PM Eshan Dhawan <
> eshandhawa...@gmail.com> wrote:
> > 
> >  Hi matt
> >  It would work if run inside newlib instead of newlib-cygwin
> >  run command inside of ../newlib-cygwin/newlib
> >  instead of ../newlib-cygwin
> > 
> > 
> >  On Tue, Jun 15, 2021 at 10:59 PM Matthew Joyce <
> mfjoyce2...@gmail.com> wrote:
> > >
> > > Ah, ok will do! Thank you for the tip.
> > >
> > > On Tue, Jun 15, 2021 at 7:17 PM Gedare Bloom 
> wrote:
> > >>
> > >> Just a note, it's more efficient to capture your terminal dump
> into a
> > >> text file and attach that, rather than put a screenshot up.
> > >>
> > >> On Tue, Jun 15, 2021 at 11:14 AM Matthew Joyce <
> mfjoyce2...@gmail.com> wrote:
> > >>>
> > >>> Hi Gentlemen,
> > >>>
> > >>> Thanks very much for your quick replies!
> > >>>
> > >>> I just tried both, but perhaps I'm misinterpreting your
> suggestions.
> > >>> (Could you please see the attached commands / errors!)
> > >>>
> > >>> Eshan,
> > >>>
> > >>> I did see that link, but it wasn't clear to me what the solution
> was...Sorry!
> > >>>
> > >>> Sincerely,
> > >>>
> > >>> Matt
> > >>>
> > >>> On Tue, Jun 15, 2021 at 6:52 PM Eshan Dhawan <
> eshandhawa...@gmail.com> wrote:
> > 
> >  Hi Matt,
> >  Try running the command with autoconf version 2.69 that's
> shipped with RTEMS in the rtems bin
> >  That works as well.
> > 
> >  Also From a quick google search this is what I found :
> https://superuser.com/questions/617872/cant-locate-autom4te-channeldefs-pm-in-inc-when-it-definitely-is-there
> > 
> >  On Tue, Jun 15, 2021 at 9:12 PM Matthew Joyce <
> mfjoyce2...@gmail.com> wrote:
> > >
> > > Hello Dr. Joel and Eshan,
> > >
> > > I have a patch ready to send to Newlib for the sig function
> prototypes
> > > and STR2SIG_MAX.
> > >
> > > But to do that, I think I need to have Newlib built, which I
> must
> > > still be doing wrong. The error that I am getting is attached
> below.
> > >
> > > I’ve been trying to follow the steps here:
> > >
> https://medium.com/my-gsoc-2019-journey/apply-newlib-patch-to-rtems-source-builder-6873b0fb31b8
> > > and
> https://medium.com/my-gsoc-2019-journey/build-newlib-for-sparc-and-arm-architecture-6b3287d4c6f2
> > >
> > > I even had rebuilt everything from scratch to see if that
> would help,
> > > but I still get the same error. Maybe I cloned 

Re: GSOC POSIX Compliance: Stuck trying to build Newlib

[Matthew Joyce]

I hate to ask, but where should the build binaries be if "make all"
was actually successful?

Thanks!

Matt

On Wed, Jun 16, 2021 at 6:16 PM Eshan Dhawan  wrote:
>
> Hi Matt,
> > On 16-Jun-2021, at 9:27 PM, Matthew Joyce  wrote:
> >
> > Hi Dr. Joel,
> >
> > I tried that in newlib/libc and there were at least no errors.
> > (Nothing leading me to believe it was successful either!)
> >
> > However I still got the same error when I sudo make install.
> > (sparc-rtems-ranlib: command not found) (among others!)
> >
> I make works then there is no need to run make install it just copies the 
> build binaries to the root folders.
>
> If make is build with the changes u made and the symbols that you added 
> appear in the binaries you generated.
> Then congratulations :)
> Now you just need to test those changes in the RSB to test they don’t break 
> anything in the RTEMS ecosystem.
> > Thanks again!
> >
> > Sincerely,
> >
> > Matt
> >
> >
> >
> >> On Wed, Jun 16, 2021 at 3:06 PM Joel Sherrill  wrote:
> >>
> >> Does adding --no-recursive and running it only from the directory you 
> >> touched a build system file in help?
> >>
> >> It is regenerating a lot you don't want to touch anyway.
> >>
> >> --joel
> >>
> >>> On Wed, Jun 16, 2021, 5:32 AM Matthew Joyce  wrote:
> >>>
> >>> Hi Eshan,
> >>>
> >>> Thanks very much for your follow up! Ok, I see now that if I go into
> >>> development/newlib/newlib-cygwin/newlib and run autoreconf -fvi with
> >>> the v2.69 using the PATH that Dr. Joel just showed, it starts to run.
> >>> It always eventually exits with an error though. (please see attached
> >>> .txt). I hope you can read that...I used the command "script" to
> >>> output everything to a text file.
> >>>
> >>> Do you have any idea where I might be going wrong?
> >>>
> >>> Thank you!
> >>>
> >>> Sincerely,
> >>>
> >>> Matt
> >>>
> >>> On Tue, Jun 15, 2021 at 8:23 PM Eshan Dhawan  
> >>> wrote:
> 
>  Hi matt
>  It would work if run inside newlib instead of newlib-cygwin
>  run command inside of ../newlib-cygwin/newlib
>  instead of ../newlib-cygwin
> 
> 
>  On Tue, Jun 15, 2021 at 10:59 PM Matthew Joyce  
>  wrote:
> >
> > Ah, ok will do! Thank you for the tip.
> >
> > On Tue, Jun 15, 2021 at 7:17 PM Gedare Bloom  wrote:
> >>
> >> Just a note, it's more efficient to capture your terminal dump into a
> >> text file and attach that, rather than put a screenshot up.
> >>
> >> On Tue, Jun 15, 2021 at 11:14 AM Matthew Joyce  
> >> wrote:
> >>>
> >>> Hi Gentlemen,
> >>>
> >>> Thanks very much for your quick replies!
> >>>
> >>> I just tried both, but perhaps I'm misinterpreting your suggestions.
> >>> (Could you please see the attached commands / errors!)
> >>>
> >>> Eshan,
> >>>
> >>> I did see that link, but it wasn't clear to me what the solution 
> >>> was...Sorry!
> >>>
> >>> Sincerely,
> >>>
> >>> Matt
> >>>
> >>> On Tue, Jun 15, 2021 at 6:52 PM Eshan Dhawan 
> >>>  wrote:
> 
>  Hi Matt,
>  Try running the command with autoconf version 2.69 that's shipped 
>  with RTEMS in the rtems bin
>  That works as well.
> 
>  Also From a quick google search this is what I found : 
>  https://superuser.com/questions/617872/cant-locate-autom4te-channeldefs-pm-in-inc-when-it-definitely-is-there
> 
>  On Tue, Jun 15, 2021 at 9:12 PM Matthew Joyce 
>   wrote:
> >
> > Hello Dr. Joel and Eshan,
> >
> > I have a patch ready to send to Newlib for the sig function 
> > prototypes
> > and STR2SIG_MAX.
> >
> > But to do that, I think I need to have Newlib built, which I must
> > still be doing wrong. The error that I am getting is attached below.
> >
> > I’ve been trying to follow the steps here:
> > https://medium.com/my-gsoc-2019-journey/apply-newlib-patch-to-rtems-source-builder-6873b0fb31b8
> > and 
> > https://medium.com/my-gsoc-2019-journey/build-newlib-for-sparc-and-arm-architecture-6b3287d4c6f2
> >
> > I even had rebuilt everything from scratch to see if that would 
> > help,
> > but I still get the same error. Maybe I cloned the newlib source 
> > into
> > the wrong directory?
> >
> > I was hoping to get the patch off to Newlib for review as a first 
> > step
> > while I work on writing the actual methods. When you get a moment,
> > could you please advise? Thank you very much!
> >
> > Sincerely,
> >
> > Matt
> >>> ___
> >>> devel mailing list
> >>> devel@rtems.org
> >>> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org

Re: GSOC POSIX Compliance: Stuck trying to build Newlib

[Joel Sherrill]

On Wed, Jun 16, 2021 at 11:16 AM Eshan Dhawan 
wrote:

> Hi Matt,
> > On 16-Jun-2021, at 9:27 PM, Matthew Joyce  wrote:
> >
> > Hi Dr. Joel,
> >
> > I tried that in newlib/libc and there were at least no errors.
> > (Nothing leading me to believe it was successful either!)
> >
> > However I still got the same error when I sudo make install.
> > (sparc-rtems-ranlib: command not found) (among others!)
> >
> I make works then there is no need to run make install it just copies the
> build binaries to the root folders.
>
> If make is build with the changes u made and the symbols that you added
> appear in the binaries you generated.
> Then congratulations :)
> Now you just need to test those changes in the RSB to test they don’t
> break anything in the RTEMS ecosystem.


Or use the same prefix as you did with the RSB installed tools and begin to
add a test to RTEMS for the method.

When you add to newlib and need a test in RTEMS for that functionality, you
end up with a pair of patches. First the newlib one has to be merged, then
your test can be added to RTEMS.

--joel


>
> > Thanks again!
> >
> > Sincerely,
> >
> > Matt
> >
> >
> >
> >> On Wed, Jun 16, 2021 at 3:06 PM Joel Sherrill  wrote:
> >>
> >> Does adding --no-recursive and running it only from the directory you
> touched a build system file in help?
> >>
> >> It is regenerating a lot you don't want to touch anyway.
> >>
> >> --joel
> >>
> >>> On Wed, Jun 16, 2021, 5:32 AM Matthew Joyce 
> wrote:
> >>>
> >>> Hi Eshan,
> >>>
> >>> Thanks very much for your follow up! Ok, I see now that if I go into
> >>> development/newlib/newlib-cygwin/newlib and run autoreconf -fvi with
> >>> the v2.69 using the PATH that Dr. Joel just showed, it starts to run.
> >>> It always eventually exits with an error though. (please see attached
> >>> .txt). I hope you can read that...I used the command "script" to
> >>> output everything to a text file.
> >>>
> >>> Do you have any idea where I might be going wrong?
> >>>
> >>> Thank you!
> >>>
> >>> Sincerely,
> >>>
> >>> Matt
> >>>
> >>> On Tue, Jun 15, 2021 at 8:23 PM Eshan Dhawan 
> wrote:
> 
>  Hi matt
>  It would work if run inside newlib instead of newlib-cygwin
>  run command inside of ../newlib-cygwin/newlib
>  instead of ../newlib-cygwin
> 
> 
>  On Tue, Jun 15, 2021 at 10:59 PM Matthew Joyce 
> wrote:
> >
> > Ah, ok will do! Thank you for the tip.
> >
> > On Tue, Jun 15, 2021 at 7:17 PM Gedare Bloom 
> wrote:
> >>
> >> Just a note, it's more efficient to capture your terminal dump into
> a
> >> text file and attach that, rather than put a screenshot up.
> >>
> >> On Tue, Jun 15, 2021 at 11:14 AM Matthew Joyce <
> mfjoyce2...@gmail.com> wrote:
> >>>
> >>> Hi Gentlemen,
> >>>
> >>> Thanks very much for your quick replies!
> >>>
> >>> I just tried both, but perhaps I'm misinterpreting your
> suggestions.
> >>> (Could you please see the attached commands / errors!)
> >>>
> >>> Eshan,
> >>>
> >>> I did see that link, but it wasn't clear to me what the solution
> was...Sorry!
> >>>
> >>> Sincerely,
> >>>
> >>> Matt
> >>>
> >>> On Tue, Jun 15, 2021 at 6:52 PM Eshan Dhawan <
> eshandhawa...@gmail.com> wrote:
> 
>  Hi Matt,
>  Try running the command with autoconf version 2.69 that's shipped
> with RTEMS in the rtems bin
>  That works as well.
> 
>  Also From a quick google search this is what I found :
> https://superuser.com/questions/617872/cant-locate-autom4te-channeldefs-pm-in-inc-when-it-definitely-is-there
> 
>  On Tue, Jun 15, 2021 at 9:12 PM Matthew Joyce <
> mfjoyce2...@gmail.com> wrote:
> >
> > Hello Dr. Joel and Eshan,
> >
> > I have a patch ready to send to Newlib for the sig function
> prototypes
> > and STR2SIG_MAX.
> >
> > But to do that, I think I need to have Newlib built, which I must
> > still be doing wrong. The error that I am getting is attached
> below.
> >
> > I’ve been trying to follow the steps here:
> >
> https://medium.com/my-gsoc-2019-journey/apply-newlib-patch-to-rtems-source-builder-6873b0fb31b8
> > and
> https://medium.com/my-gsoc-2019-journey/build-newlib-for-sparc-and-arm-architecture-6b3287d4c6f2
> >
> > I even had rebuilt everything from scratch to see if that would
> help,
> > but I still get the same error. Maybe I cloned the newlib source
> into
> > the wrong directory?
> >
> > I was hoping to get the patch off to Newlib for review as a
> first step
> > while I work on writing the actual methods. When you get a
> moment,
> > could you please advise? Thank you very much!
> >
> > Sincerely,
> >
> > Matt
> >>> ___
> >>> devel mailing list
> >>> 

Re: GSOC POSIX Compliance: Stuck trying to build Newlib

[Eshan Dhawan]

Hi Matt,
> On 16-Jun-2021, at 9:27 PM, Matthew Joyce  wrote:
> 
> Hi Dr. Joel,
> 
> I tried that in newlib/libc and there were at least no errors.
> (Nothing leading me to believe it was successful either!)
> 
> However I still got the same error when I sudo make install.
> (sparc-rtems-ranlib: command not found) (among others!)
> 
I make works then there is no need to run make install it just copies the build 
binaries to the root folders.

If make is build with the changes u made and the symbols that you added appear 
in the binaries you generated.
Then congratulations :) 
Now you just need to test those changes in the RSB to test they don’t break 
anything in the RTEMS ecosystem. 
> Thanks again!
> 
> Sincerely,
> 
> Matt
> 
> 
> 
>> On Wed, Jun 16, 2021 at 3:06 PM Joel Sherrill  wrote:
>> 
>> Does adding --no-recursive and running it only from the directory you 
>> touched a build system file in help?
>> 
>> It is regenerating a lot you don't want to touch anyway.
>> 
>> --joel
>> 
>>> On Wed, Jun 16, 2021, 5:32 AM Matthew Joyce  wrote:
>>> 
>>> Hi Eshan,
>>> 
>>> Thanks very much for your follow up! Ok, I see now that if I go into
>>> development/newlib/newlib-cygwin/newlib and run autoreconf -fvi with
>>> the v2.69 using the PATH that Dr. Joel just showed, it starts to run.
>>> It always eventually exits with an error though. (please see attached
>>> .txt). I hope you can read that...I used the command "script" to
>>> output everything to a text file.
>>> 
>>> Do you have any idea where I might be going wrong?
>>> 
>>> Thank you!
>>> 
>>> Sincerely,
>>> 
>>> Matt
>>> 
>>> On Tue, Jun 15, 2021 at 8:23 PM Eshan Dhawan  
>>> wrote:
 
 Hi matt
 It would work if run inside newlib instead of newlib-cygwin
 run command inside of ../newlib-cygwin/newlib
 instead of ../newlib-cygwin
 
 
 On Tue, Jun 15, 2021 at 10:59 PM Matthew Joyce  
 wrote:
> 
> Ah, ok will do! Thank you for the tip.
> 
> On Tue, Jun 15, 2021 at 7:17 PM Gedare Bloom  wrote:
>> 
>> Just a note, it's more efficient to capture your terminal dump into a
>> text file and attach that, rather than put a screenshot up.
>> 
>> On Tue, Jun 15, 2021 at 11:14 AM Matthew Joyce  
>> wrote:
>>> 
>>> Hi Gentlemen,
>>> 
>>> Thanks very much for your quick replies!
>>> 
>>> I just tried both, but perhaps I'm misinterpreting your suggestions.
>>> (Could you please see the attached commands / errors!)
>>> 
>>> Eshan,
>>> 
>>> I did see that link, but it wasn't clear to me what the solution 
>>> was...Sorry!
>>> 
>>> Sincerely,
>>> 
>>> Matt
>>> 
>>> On Tue, Jun 15, 2021 at 6:52 PM Eshan Dhawan  
>>> wrote:
 
 Hi Matt,
 Try running the command with autoconf version 2.69 that's shipped with 
 RTEMS in the rtems bin
 That works as well.
 
 Also From a quick google search this is what I found : 
 https://superuser.com/questions/617872/cant-locate-autom4te-channeldefs-pm-in-inc-when-it-definitely-is-there
 
 On Tue, Jun 15, 2021 at 9:12 PM Matthew Joyce  
 wrote:
> 
> Hello Dr. Joel and Eshan,
> 
> I have a patch ready to send to Newlib for the sig function prototypes
> and STR2SIG_MAX.
> 
> But to do that, I think I need to have Newlib built, which I must
> still be doing wrong. The error that I am getting is attached below.
> 
> I’ve been trying to follow the steps here:
> https://medium.com/my-gsoc-2019-journey/apply-newlib-patch-to-rtems-source-builder-6873b0fb31b8
> and 
> https://medium.com/my-gsoc-2019-journey/build-newlib-for-sparc-and-arm-architecture-6b3287d4c6f2
> 
> I even had rebuilt everything from scratch to see if that would help,
> but I still get the same error. Maybe I cloned the newlib source into
> the wrong directory?
> 
> I was hoping to get the patch off to Newlib for review as a first step
> while I work on writing the actual methods. When you get a moment,
> could you please advise? Thank you very much!
> 
> Sincerely,
> 
> Matt
>>> ___
>>> 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: GSOC POSIX Compliance: Stuck trying to build Newlib

[Matthew Joyce]

Hi Dr. Joel,

I used the following, based on Vaibhav's blog:

$ export PATH=$HOME/development/rtems/6/bin:$PATH

$ ../newlib-cygwin/configure --target=sparc-rtems6 --disable-shared
--disable-nls --enable-werror --enable-newlib-supplied-syscalls
--enable-interwork --enable-multilib --with-gnu-as --with-gnu-ld

When I enter "type sparc-rtems6-gcc" (I hope I'm understanding that
correctly!), I get sparc-rtems6-gcc is hashed...and then my PATH.

Thanks again!

V/r,

Matt

On Wed, Jun 16, 2021 at 6:06 PM Joel Sherrill  wrote:
>
>
>
> On Wed, Jun 16, 2021 at 10:57 AM Matthew Joyce  wrote:
>>
>> Hi Dr. Joel,
>>
>> I tried that in newlib/libc and there were at least no errors.
>> (Nothing leading me to believe it was successful either!)
>>
>> However I still got the same error when I sudo make install.
>> (sparc-rtems-ranlib: command not found) (among others!)
>
>
> The target should be sparc-rtems6 when you configure newlib.
> This should mean invoking the script like "./j-newlib sparc-rtems6"
>
>
> And the RTEMS tools should be in your PATH.
>
> type sparc-rtems6-gcc
>
> To be sure.
>
> --joel
>>
>>
>> Thanks again!
>>
>> Sincerely,
>>
>> Matt
>>
>>
>>
>> On Wed, Jun 16, 2021 at 3:06 PM Joel Sherrill  wrote:
>> >
>> > Does adding --no-recursive and running it only from the directory you 
>> > touched a build system file in help?
>> >
>> > It is regenerating a lot you don't want to touch anyway.
>> >
>> > --joel
>> >
>> > On Wed, Jun 16, 2021, 5:32 AM Matthew Joyce  wrote:
>> >>
>> >> Hi Eshan,
>> >>
>> >> Thanks very much for your follow up! Ok, I see now that if I go into
>> >> development/newlib/newlib-cygwin/newlib and run autoreconf -fvi with
>> >> the v2.69 using the PATH that Dr. Joel just showed, it starts to run.
>> >> It always eventually exits with an error though. (please see attached
>> >> .txt). I hope you can read that...I used the command "script" to
>> >> output everything to a text file.
>> >>
>> >> Do you have any idea where I might be going wrong?
>> >>
>> >> Thank you!
>> >>
>> >> Sincerely,
>> >>
>> >> Matt
>> >>
>> >> On Tue, Jun 15, 2021 at 8:23 PM Eshan Dhawan  
>> >> wrote:
>> >> >
>> >> > Hi matt
>> >> > It would work if run inside newlib instead of newlib-cygwin
>> >> > run command inside of ../newlib-cygwin/newlib
>> >> > instead of ../newlib-cygwin
>> >> >
>> >> >
>> >> > On Tue, Jun 15, 2021 at 10:59 PM Matthew Joyce  
>> >> > wrote:
>> >> >>
>> >> >> Ah, ok will do! Thank you for the tip.
>> >> >>
>> >> >> On Tue, Jun 15, 2021 at 7:17 PM Gedare Bloom  wrote:
>> >> >> >
>> >> >> > Just a note, it's more efficient to capture your terminal dump into a
>> >> >> > text file and attach that, rather than put a screenshot up.
>> >> >> >
>> >> >> > On Tue, Jun 15, 2021 at 11:14 AM Matthew Joyce 
>> >> >> >  wrote:
>> >> >> > >
>> >> >> > > Hi Gentlemen,
>> >> >> > >
>> >> >> > > Thanks very much for your quick replies!
>> >> >> > >
>> >> >> > > I just tried both, but perhaps I'm misinterpreting your 
>> >> >> > > suggestions.
>> >> >> > > (Could you please see the attached commands / errors!)
>> >> >> > >
>> >> >> > > Eshan,
>> >> >> > >
>> >> >> > > I did see that link, but it wasn't clear to me what the solution 
>> >> >> > > was...Sorry!
>> >> >> > >
>> >> >> > > Sincerely,
>> >> >> > >
>> >> >> > > Matt
>> >> >> > >
>> >> >> > > On Tue, Jun 15, 2021 at 6:52 PM Eshan Dhawan 
>> >> >> > >  wrote:
>> >> >> > > >
>> >> >> > > > Hi Matt,
>> >> >> > > > Try running the command with autoconf version 2.69 that's 
>> >> >> > > > shipped with RTEMS in the rtems bin
>> >> >> > > > That works as well.
>> >> >> > > >
>> >> >> > > > Also From a quick google search this is what I found : 
>> >> >> > > > https://superuser.com/questions/617872/cant-locate-autom4te-channeldefs-pm-in-inc-when-it-definitely-is-there
>> >> >> > > >
>> >> >> > > > On Tue, Jun 15, 2021 at 9:12 PM Matthew Joyce 
>> >> >> > > >  wrote:
>> >> >> > > >>
>> >> >> > > >> Hello Dr. Joel and Eshan,
>> >> >> > > >>
>> >> >> > > >> I have a patch ready to send to Newlib for the sig function 
>> >> >> > > >> prototypes
>> >> >> > > >> and STR2SIG_MAX.
>> >> >> > > >>
>> >> >> > > >> But to do that, I think I need to have Newlib built, which I 
>> >> >> > > >> must
>> >> >> > > >> still be doing wrong. The error that I am getting is attached 
>> >> >> > > >> below.
>> >> >> > > >>
>> >> >> > > >> I’ve been trying to follow the steps here:
>> >> >> > > >> https://medium.com/my-gsoc-2019-journey/apply-newlib-patch-to-rtems-source-builder-6873b0fb31b8
>> >> >> > > >> and 
>> >> >> > > >> https://medium.com/my-gsoc-2019-journey/build-newlib-for-sparc-and-arm-architecture-6b3287d4c6f2
>> >> >> > > >>
>> >> >> > > >> I even had rebuilt everything from scratch to see if that would 
>> >> >> > > >> help,
>> >> >> > > >> but I still get the same error. Maybe I cloned the newlib 
>> >> >> > > >> source into
>> >> >> > > >> the wrong directory?
>> >> >> > > >>
>> >> >> > > >> I was hoping to get the patch off to Newlib for review as a 
>> >> >> > 

Re: GSOC POSIX Compliance: Stuck trying to build Newlib

[Joel Sherrill]

On Wed, Jun 16, 2021 at 10:57 AM Matthew Joyce 
wrote:

> Hi Dr. Joel,
>
> I tried that in newlib/libc and there were at least no errors.
> (Nothing leading me to believe it was successful either!)
>
> However I still got the same error when I sudo make install.
> (sparc-rtems-ranlib: command not found) (among others!)
>

The target should be sparc-rtems6 when you configure newlib.
This should mean invoking the script like "./j-newlib sparc-rtems6"


And the RTEMS tools should be in your PATH.

type sparc-rtems6-gcc

To be sure.

--joel

>
> Thanks again!
>
> Sincerely,
>
> Matt
>
>
>
> On Wed, Jun 16, 2021 at 3:06 PM Joel Sherrill  wrote:
> >
> > Does adding --no-recursive and running it only from the directory you
> touched a build system file in help?
> >
> > It is regenerating a lot you don't want to touch anyway.
> >
> > --joel
> >
> > On Wed, Jun 16, 2021, 5:32 AM Matthew Joyce 
> wrote:
> >>
> >> Hi Eshan,
> >>
> >> Thanks very much for your follow up! Ok, I see now that if I go into
> >> development/newlib/newlib-cygwin/newlib and run autoreconf -fvi with
> >> the v2.69 using the PATH that Dr. Joel just showed, it starts to run.
> >> It always eventually exits with an error though. (please see attached
> >> .txt). I hope you can read that...I used the command "script" to
> >> output everything to a text file.
> >>
> >> Do you have any idea where I might be going wrong?
> >>
> >> Thank you!
> >>
> >> Sincerely,
> >>
> >> Matt
> >>
> >> On Tue, Jun 15, 2021 at 8:23 PM Eshan Dhawan 
> wrote:
> >> >
> >> > Hi matt
> >> > It would work if run inside newlib instead of newlib-cygwin
> >> > run command inside of ../newlib-cygwin/newlib
> >> > instead of ../newlib-cygwin
> >> >
> >> >
> >> > On Tue, Jun 15, 2021 at 10:59 PM Matthew Joyce 
> wrote:
> >> >>
> >> >> Ah, ok will do! Thank you for the tip.
> >> >>
> >> >> On Tue, Jun 15, 2021 at 7:17 PM Gedare Bloom 
> wrote:
> >> >> >
> >> >> > Just a note, it's more efficient to capture your terminal dump
> into a
> >> >> > text file and attach that, rather than put a screenshot up.
> >> >> >
> >> >> > On Tue, Jun 15, 2021 at 11:14 AM Matthew Joyce <
> mfjoyce2...@gmail.com> wrote:
> >> >> > >
> >> >> > > Hi Gentlemen,
> >> >> > >
> >> >> > > Thanks very much for your quick replies!
> >> >> > >
> >> >> > > I just tried both, but perhaps I'm misinterpreting your
> suggestions.
> >> >> > > (Could you please see the attached commands / errors!)
> >> >> > >
> >> >> > > Eshan,
> >> >> > >
> >> >> > > I did see that link, but it wasn't clear to me what the solution
> was...Sorry!
> >> >> > >
> >> >> > > Sincerely,
> >> >> > >
> >> >> > > Matt
> >> >> > >
> >> >> > > On Tue, Jun 15, 2021 at 6:52 PM Eshan Dhawan <
> eshandhawa...@gmail.com> wrote:
> >> >> > > >
> >> >> > > > Hi Matt,
> >> >> > > > Try running the command with autoconf version 2.69 that's
> shipped with RTEMS in the rtems bin
> >> >> > > > That works as well.
> >> >> > > >
> >> >> > > > Also From a quick google search this is what I found :
> https://superuser.com/questions/617872/cant-locate-autom4te-channeldefs-pm-in-inc-when-it-definitely-is-there
> >> >> > > >
> >> >> > > > On Tue, Jun 15, 2021 at 9:12 PM Matthew Joyce <
> mfjoyce2...@gmail.com> wrote:
> >> >> > > >>
> >> >> > > >> Hello Dr. Joel and Eshan,
> >> >> > > >>
> >> >> > > >> I have a patch ready to send to Newlib for the sig function
> prototypes
> >> >> > > >> and STR2SIG_MAX.
> >> >> > > >>
> >> >> > > >> But to do that, I think I need to have Newlib built, which I
> must
> >> >> > > >> still be doing wrong. The error that I am getting is attached
> below.
> >> >> > > >>
> >> >> > > >> I’ve been trying to follow the steps here:
> >> >> > > >>
> https://medium.com/my-gsoc-2019-journey/apply-newlib-patch-to-rtems-source-builder-6873b0fb31b8
> >> >> > > >> and
> https://medium.com/my-gsoc-2019-journey/build-newlib-for-sparc-and-arm-architecture-6b3287d4c6f2
> >> >> > > >>
> >> >> > > >> I even had rebuilt everything from scratch to see if that
> would help,
> >> >> > > >> but I still get the same error. Maybe I cloned the newlib
> source into
> >> >> > > >> the wrong directory?
> >> >> > > >>
> >> >> > > >> I was hoping to get the patch off to Newlib for review as a
> first step
> >> >> > > >> while I work on writing the actual methods. When you get a
> moment,
> >> >> > > >> could you please advise? Thank you very much!
> >> >> > > >>
> >> >> > > >> Sincerely,
> >> >> > > >>
> >> >> > > >> Matt
> >> >> > > ___
> >> >> > > 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: GSOC POSIX Compliance: Stuck trying to build Newlib

[Matthew Joyce]

Hi Dr. Joel,

I tried that in newlib/libc and there were at least no errors.
(Nothing leading me to believe it was successful either!)

However I still got the same error when I sudo make install.
(sparc-rtems-ranlib: command not found) (among others!)

Thanks again!

Sincerely,

Matt



On Wed, Jun 16, 2021 at 3:06 PM Joel Sherrill  wrote:
>
> Does adding --no-recursive and running it only from the directory you touched 
> a build system file in help?
>
> It is regenerating a lot you don't want to touch anyway.
>
> --joel
>
> On Wed, Jun 16, 2021, 5:32 AM Matthew Joyce  wrote:
>>
>> Hi Eshan,
>>
>> Thanks very much for your follow up! Ok, I see now that if I go into
>> development/newlib/newlib-cygwin/newlib and run autoreconf -fvi with
>> the v2.69 using the PATH that Dr. Joel just showed, it starts to run.
>> It always eventually exits with an error though. (please see attached
>> .txt). I hope you can read that...I used the command "script" to
>> output everything to a text file.
>>
>> Do you have any idea where I might be going wrong?
>>
>> Thank you!
>>
>> Sincerely,
>>
>> Matt
>>
>> On Tue, Jun 15, 2021 at 8:23 PM Eshan Dhawan  wrote:
>> >
>> > Hi matt
>> > It would work if run inside newlib instead of newlib-cygwin
>> > run command inside of ../newlib-cygwin/newlib
>> > instead of ../newlib-cygwin
>> >
>> >
>> > On Tue, Jun 15, 2021 at 10:59 PM Matthew Joyce  
>> > wrote:
>> >>
>> >> Ah, ok will do! Thank you for the tip.
>> >>
>> >> On Tue, Jun 15, 2021 at 7:17 PM Gedare Bloom  wrote:
>> >> >
>> >> > Just a note, it's more efficient to capture your terminal dump into a
>> >> > text file and attach that, rather than put a screenshot up.
>> >> >
>> >> > On Tue, Jun 15, 2021 at 11:14 AM Matthew Joyce  
>> >> > wrote:
>> >> > >
>> >> > > Hi Gentlemen,
>> >> > >
>> >> > > Thanks very much for your quick replies!
>> >> > >
>> >> > > I just tried both, but perhaps I'm misinterpreting your suggestions.
>> >> > > (Could you please see the attached commands / errors!)
>> >> > >
>> >> > > Eshan,
>> >> > >
>> >> > > I did see that link, but it wasn't clear to me what the solution 
>> >> > > was...Sorry!
>> >> > >
>> >> > > Sincerely,
>> >> > >
>> >> > > Matt
>> >> > >
>> >> > > On Tue, Jun 15, 2021 at 6:52 PM Eshan Dhawan 
>> >> > >  wrote:
>> >> > > >
>> >> > > > Hi Matt,
>> >> > > > Try running the command with autoconf version 2.69 that's shipped 
>> >> > > > with RTEMS in the rtems bin
>> >> > > > That works as well.
>> >> > > >
>> >> > > > Also From a quick google search this is what I found : 
>> >> > > > https://superuser.com/questions/617872/cant-locate-autom4te-channeldefs-pm-in-inc-when-it-definitely-is-there
>> >> > > >
>> >> > > > On Tue, Jun 15, 2021 at 9:12 PM Matthew Joyce 
>> >> > > >  wrote:
>> >> > > >>
>> >> > > >> Hello Dr. Joel and Eshan,
>> >> > > >>
>> >> > > >> I have a patch ready to send to Newlib for the sig function 
>> >> > > >> prototypes
>> >> > > >> and STR2SIG_MAX.
>> >> > > >>
>> >> > > >> But to do that, I think I need to have Newlib built, which I must
>> >> > > >> still be doing wrong. The error that I am getting is attached 
>> >> > > >> below.
>> >> > > >>
>> >> > > >> I’ve been trying to follow the steps here:
>> >> > > >> https://medium.com/my-gsoc-2019-journey/apply-newlib-patch-to-rtems-source-builder-6873b0fb31b8
>> >> > > >> and 
>> >> > > >> https://medium.com/my-gsoc-2019-journey/build-newlib-for-sparc-and-arm-architecture-6b3287d4c6f2
>> >> > > >>
>> >> > > >> I even had rebuilt everything from scratch to see if that would 
>> >> > > >> help,
>> >> > > >> but I still get the same error. Maybe I cloned the newlib source 
>> >> > > >> into
>> >> > > >> the wrong directory?
>> >> > > >>
>> >> > > >> I was hoping to get the patch off to Newlib for review as a first 
>> >> > > >> step
>> >> > > >> while I work on writing the actual methods. When you get a moment,
>> >> > > >> could you please advise? Thank you very much!
>> >> > > >>
>> >> > > >> Sincerely,
>> >> > > >>
>> >> > > >> Matt
>> >> > > ___
>> >> > > 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: GSOC POSIX Compliance: Stuck trying to build Newlib

[Joel Sherrill]

Does adding --no-recursive and running it only from the directory you
touched a build system file in help?

It is regenerating a lot you don't want to touch anyway.

--joel

On Wed, Jun 16, 2021, 5:32 AM Matthew Joyce  wrote:

> Hi Eshan,
>
> Thanks very much for your follow up! Ok, I see now that if I go into
> development/newlib/newlib-cygwin/newlib and run autoreconf -fvi with
> the v2.69 using the PATH that Dr. Joel just showed, it starts to run.
> It always eventually exits with an error though. (please see attached
> .txt). I hope you can read that...I used the command "script" to
> output everything to a text file.
>
> Do you have any idea where I might be going wrong?
>
> Thank you!
>
> Sincerely,
>
> Matt
>
> On Tue, Jun 15, 2021 at 8:23 PM Eshan Dhawan 
> wrote:
> >
> > Hi matt
> > It would work if run inside newlib instead of newlib-cygwin
> > run command inside of ../newlib-cygwin/newlib
> > instead of ../newlib-cygwin
> >
> >
> > On Tue, Jun 15, 2021 at 10:59 PM Matthew Joyce 
> wrote:
> >>
> >> Ah, ok will do! Thank you for the tip.
> >>
> >> On Tue, Jun 15, 2021 at 7:17 PM Gedare Bloom  wrote:
> >> >
> >> > Just a note, it's more efficient to capture your terminal dump into a
> >> > text file and attach that, rather than put a screenshot up.
> >> >
> >> > On Tue, Jun 15, 2021 at 11:14 AM Matthew Joyce 
> wrote:
> >> > >
> >> > > Hi Gentlemen,
> >> > >
> >> > > Thanks very much for your quick replies!
> >> > >
> >> > > I just tried both, but perhaps I'm misinterpreting your suggestions.
> >> > > (Could you please see the attached commands / errors!)
> >> > >
> >> > > Eshan,
> >> > >
> >> > > I did see that link, but it wasn't clear to me what the solution
> was...Sorry!
> >> > >
> >> > > Sincerely,
> >> > >
> >> > > Matt
> >> > >
> >> > > On Tue, Jun 15, 2021 at 6:52 PM Eshan Dhawan <
> eshandhawa...@gmail.com> wrote:
> >> > > >
> >> > > > Hi Matt,
> >> > > > Try running the command with autoconf version 2.69 that's shipped
> with RTEMS in the rtems bin
> >> > > > That works as well.
> >> > > >
> >> > > > Also From a quick google search this is what I found :
> https://superuser.com/questions/617872/cant-locate-autom4te-channeldefs-pm-in-inc-when-it-definitely-is-there
> >> > > >
> >> > > > On Tue, Jun 15, 2021 at 9:12 PM Matthew Joyce <
> mfjoyce2...@gmail.com> wrote:
> >> > > >>
> >> > > >> Hello Dr. Joel and Eshan,
> >> > > >>
> >> > > >> I have a patch ready to send to Newlib for the sig function
> prototypes
> >> > > >> and STR2SIG_MAX.
> >> > > >>
> >> > > >> But to do that, I think I need to have Newlib built, which I must
> >> > > >> still be doing wrong. The error that I am getting is attached
> below.
> >> > > >>
> >> > > >> I’ve been trying to follow the steps here:
> >> > > >>
> https://medium.com/my-gsoc-2019-journey/apply-newlib-patch-to-rtems-source-builder-6873b0fb31b8
> >> > > >> and
> https://medium.com/my-gsoc-2019-journey/build-newlib-for-sparc-and-arm-architecture-6b3287d4c6f2
> >> > > >>
> >> > > >> I even had rebuilt everything from scratch to see if that would
> help,
> >> > > >> but I still get the same error. Maybe I cloned the newlib source
> into
> >> > > >> the wrong directory?
> >> > > >>
> >> > > >> I was hoping to get the patch off to Newlib for review as a
> first step
> >> > > >> while I work on writing the actual methods. When you get a
> moment,
> >> > > >> could you please advise? Thank you very much!
> >> > > >>
> >> > > >> Sincerely,
> >> > > >>
> >> > > >> Matt
> >> > > ___
> >> > > 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

New API directives to enable/disable interrupt vectors

[Sebastian Huber]

Hello,

I work currently on an extension of the interrupt manager API:

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

This API is not related to the interrupt handling at processor level. It 
is related to the management of interrupts at the interrupt controller 
level.


We need directives to enable and disable interrupt vectors. 
Unfortunately, rtems_interrupt_enable() and rtems_interrupt_disable() 
are already occupied. My first approach was to use 
rtems_interrupt_mask() and rtems_interrupt_unmask(), however, I noticed 
that rtems_interrupt_mask is already used. What about


rtems_interrupt_permit()

and

rtems_interrupt_forbid()

?

--
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: GSOC POSIX Compliance: Stuck trying to build Newlib

[Matthew Joyce]

Hi Eshan,

Thanks very much for your follow up! Ok, I see now that if I go into
development/newlib/newlib-cygwin/newlib and run autoreconf -fvi with
the v2.69 using the PATH that Dr. Joel just showed, it starts to run.
It always eventually exits with an error though. (please see attached
.txt). I hope you can read that...I used the command "script" to
output everything to a text file.

Do you have any idea where I might be going wrong?

Thank you!

Sincerely,

Matt

On Tue, Jun 15, 2021 at 8:23 PM Eshan Dhawan  wrote:
>
> Hi matt
> It would work if run inside newlib instead of newlib-cygwin
> run command inside of ../newlib-cygwin/newlib
> instead of ../newlib-cygwin
>
>
> On Tue, Jun 15, 2021 at 10:59 PM Matthew Joyce  wrote:
>>
>> Ah, ok will do! Thank you for the tip.
>>
>> On Tue, Jun 15, 2021 at 7:17 PM Gedare Bloom  wrote:
>> >
>> > Just a note, it's more efficient to capture your terminal dump into a
>> > text file and attach that, rather than put a screenshot up.
>> >
>> > On Tue, Jun 15, 2021 at 11:14 AM Matthew Joyce  
>> > wrote:
>> > >
>> > > Hi Gentlemen,
>> > >
>> > > Thanks very much for your quick replies!
>> > >
>> > > I just tried both, but perhaps I'm misinterpreting your suggestions.
>> > > (Could you please see the attached commands / errors!)
>> > >
>> > > Eshan,
>> > >
>> > > I did see that link, but it wasn't clear to me what the solution 
>> > > was...Sorry!
>> > >
>> > > Sincerely,
>> > >
>> > > Matt
>> > >
>> > > On Tue, Jun 15, 2021 at 6:52 PM Eshan Dhawan  
>> > > wrote:
>> > > >
>> > > > Hi Matt,
>> > > > Try running the command with autoconf version 2.69 that's shipped with 
>> > > > RTEMS in the rtems bin
>> > > > That works as well.
>> > > >
>> > > > Also From a quick google search this is what I found : 
>> > > > https://superuser.com/questions/617872/cant-locate-autom4te-channeldefs-pm-in-inc-when-it-definitely-is-there
>> > > >
>> > > > On Tue, Jun 15, 2021 at 9:12 PM Matthew Joyce  
>> > > > wrote:
>> > > >>
>> > > >> Hello Dr. Joel and Eshan,
>> > > >>
>> > > >> I have a patch ready to send to Newlib for the sig function prototypes
>> > > >> and STR2SIG_MAX.
>> > > >>
>> > > >> But to do that, I think I need to have Newlib built, which I must
>> > > >> still be doing wrong. The error that I am getting is attached below.
>> > > >>
>> > > >> I’ve been trying to follow the steps here:
>> > > >> https://medium.com/my-gsoc-2019-journey/apply-newlib-patch-to-rtems-source-builder-6873b0fb31b8
>> > > >> and 
>> > > >> https://medium.com/my-gsoc-2019-journey/build-newlib-for-sparc-and-arm-architecture-6b3287d4c6f2
>> > > >>
>> > > >> I even had rebuilt everything from scratch to see if that would help,
>> > > >> but I still get the same error. Maybe I cloned the newlib source into
>> > > >> the wrong directory?
>> > > >>
>> > > >> I was hoping to get the patch off to Newlib for review as a first step
>> > > >> while I work on writing the actual methods. When you get a moment,
>> > > >> could you please advise? Thank you very much!
>> > > >>
>> > > >> Sincerely,
>> > > >>
>> > > >> Matt
>> > > ___
>> > > devel mailing list
>> > > devel@rtems.org
>> > > http://lists.rtems.org/mailman/listinfo/devel
Script started on 2021-06-16 11:49:24+02:00 [TERM="xterm-256color" 
TTY="/dev/pts/0" COLUMNS="129" LINES="33"]
]777;notify;Command 
completed;exit\]777;precmd\]0;mj@fedora:~/development/newlib/newlib-cygwin/newlib\]7;file://fedora/home/mj/development/newlib/newlib-cygwin/newlib\[mj@localhost
 newlib]$ cd ~/development/newlib/newlib-cygwin/newlib/
]777;preexec\]777;notify;Command completed;cd 
~/development/newlib/newlib-cygwin/newlib/\]777;precmd\]0;mj@fedora:~/development/newlib/newlib-cygwin/newlib\]7;file://fedora/home/mj/development/newlib/newlib-cygwin/newlib\[mj@localhost
 newlib]$ autoconf -V
]777;preexec\autoconf (GNU Autoconf) 2.64
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David J. MacKenzie and Akim Demaille.
]777;notify;Command completed;autoconf 
-V\]777;precmd\]0;mj@fedora:~/development/newlib/newlib-cygwin/newlib\]7;file://fedora/home/mj/development/newlib/newlib-cygwin/newlib\[mj@localhost
 newlib]$ echo $PATH
]777;preexec\/opt/autoconf-2.64/bin:/home/mj/.local/bin:/home/mj/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin
]777;notify;Command completed;echo 
$PATH\]777;precmd\]0;mj@fedora:~/development/newlib/newlib-cygwin/newlib\]7;file://fedora/home/mj/development/newlib/newlib-cygwin/newlib\[mj@localhost
 newlib]$ autoreconf =-fvi
]777;preexec\Can't locate Autom4te/ChannelDefs.pm in @INC (you may need to 
install the Autom4te::ChannelDefs module) (@INC contains: 
/usr/local/share/autoconf /usr/local/lib64/perl5/5.32 
/usr/local/share/perl5/5.32 

[PATCH v2 1/1] bsps/i386: Update calibration of TSC to be more accurate

[Jan Sommer]

Closes #4455
---
 bsps/i386/pc386/clock/ckinit.c | 71 ++
 1 file changed, 38 insertions(+), 33 deletions(-)

diff --git a/bsps/i386/pc386/clock/ckinit.c b/bsps/i386/pc386/clock/ckinit.c
index 09afe73cde..2df1818dd3 100644
--- a/bsps/i386/pc386/clock/ckinit.c
+++ b/bsps/i386/pc386/clock/ckinit.c
@@ -104,48 +104,60 @@ static uint32_t pc386_get_timecount_i8254(struct 
timecounter *tc)
 
 /*
  * Calibrate CPU cycles per tick. Interrupts should be disabled.
+ * Will also set the PIT, so call this before registering the 
+ * periodic timer for rtems tick generation
  */
 static void calibrate_tsc(void)
 {
   uint64_t  begin_time;
-  uint8_t   then_lsb, then_msb, now_lsb, now_msb;
-  uint32_t  i;
-
-  /*
-   * We just reset the timer, so we know we're at the beginning of a tick.
-   */
-
-  /*
-   * Count cycles. Watching the timer introduces a several microsecond
-   * uncertaintity, so let it cook for a while and divide by the number of
-   * ticks actually executed.
-   */
+  uint8_t   lsb, msb;
+  uint32_t  max_timer_value;
+  uint32_t  last_tick, cur_tick;
+  int32_t   diff, remaining;
+
+  /* Set the timer to free running mode */
+  outport_byte(TIMER_MODE, TIMER_SEL0 | TIMER_16BIT | TIMER_INTTC);
+  /* Reset the 16 timer reload value, first LSB, then MSB */
+  outport_byte(TIMER_CNTR0, 0);
+  outport_byte(TIMER_CNTR0, 0);
+  /* We use the full 16 bit */
+  max_timer_value = 0x;
+  /* Calibrate for 1s, i.e. TIMER_TICK PIT ticks */
+  remaining = TIMER_TICK;
 
   begin_time = rdtsc();
-
-  for (i = rtems_clock_get_ticks_per_second() * pc386_isrs_per_tick;
-   i != 0; --i ) {
-/* We know we've just completed a tick when timer goes from low to high */
-then_lsb = then_msb = 0xff;
-do {
-  READ_8254(now_lsb, now_msb);
-  if ((then_msb < now_msb) ||
-  ((then_msb == now_msb) && (then_lsb < now_lsb)))
-break;
-  then_lsb = now_lsb;
-  then_msb = now_msb;
-} while (1);
+  READ_8254(lsb, msb);
+  last_tick = (msb << 8) | lsb;
+  while(remaining > 0) {
+READ_8254(lsb, msb);
+cur_tick = (msb << 8) | lsb;
+/* PIT counts down, so subtract cur from last */
+diff = last_tick - cur_tick;
+last_tick = cur_tick;
+if (diff < 0) {
+diff += max_timer_value;
+}
+remaining -= diff;
   }
 
   pc586_tsc_frequency = rdtsc() - begin_time;
 
 #if 0
-  printk( "CPU clock at %u MHz\n", (uint32_t)(pc586_tsc_frequency / 100));
+  printk( "CPU clock at %u Hz\n", (uint32_t)(pc586_tsc_frequency ));
 #endif
 }
 
 static void clockOn(void)
 {
+
+  /*
+   * First calibrate the TSC. Do this every time we
+   * turn the clock on in case the CPU clock speed has changed.
+   */
+  if ( x86_has_tsc() ) {
+calibrate_tsc();
+  }
+
   rtems_interrupt_lock_context lock_context;
   pc386_isrs_per_tick= 1;
   pc386_microseconds_per_isr = rtems_configuration_get_microseconds_per_tick();
@@ -171,13 +183,6 @@ static void clockOn(void)
   rtems_interrupt_lock_release(_i386_i8254_access_lock, _context);
 
   bsp_interrupt_vector_enable( BSP_PERIODIC_TIMER );
-
-  /*
-   * Now calibrate cycles per tick. Do this every time we
-   * turn the clock on in case the CPU clock speed has changed.
-   */
-  if ( x86_has_tsc() )
-calibrate_tsc();
 }
 
 bool Clock_isr_enabled = false;
-- 
2.17.1

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

[PATCH v2 0/1] bsps/i386: Update calibration of TSC to be more accurate

[Jan Sommer]

Updated the patch with the suggestions by Gedare.
Tests on real hardware yield the same frequency results
as returned by FreeBSD on the same hardware.
Also, subsequent calibrations only differ by <1 kHz.

I would like to backport this fix to RTEMS5.
The corresponding ticket is here: https://devel.rtems.org/ticket/4456

Best regards,

Jan

Jan Sommer (1):
  bsps/i386: Update calibration of TSC to be more accurate

 bsps/i386/pc386/clock/ckinit.c | 71 ++
 1 file changed, 38 insertions(+), 33 deletions(-)

-- 
2.17.1

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

Re: GSOC POSIX Compliance: Stuck trying to build Newlib

[Matthew Joyce]

Hi Vaibhav,

Thanks very much for your note!  Fantastic job on your blogs. I read
the entry on managing the two versions of autoconf and have been
trying to follow it carefully. Could you please see the attached txt
file?

I'm in development/newlib/newlib-cygwin. I get the error where it
tells me to use exactly autoconf 2.64 and not 2.69. I change the $PATH
to make sure it is checking the opt/autoconf-2.64/bin first.

I check the autoconf version and confirm that it is now using 2.64.
But then when I try to run autoreconf -fvi, I get the same error as I
had yesterday.

Do you have any ideas as to what I'm doing wrong?

Thanks again!

Sincerely,

Matt

On Wed, Jun 16, 2021 at 4:36 AM Vaibhav Gupta  wrote:
>
> Hello Matthew,
>
> On Wed, Jun 16, 2021 at 12:58 AM Joel Sherrill  wrote:
> >
> > @RTEMS_TOOLS_BIN@ should have been replaced with the real directory where 
> > your RTEMS tools are located. Something like this:
>
> Exactly. I was wondering the same when I saw his output of 'echo $PATH'.
> Matthew, the newlib and autoconf relationship is a bit messy. But you
> can simplify it if you use $PATH carefully.
> Have a look at this
> https://medium.com/my-gsoc-2019-journey/how-to-handle-two-versions-of-autoconf-b1e28de8617b,
> the path should expand and should point to the correct binaries.
>
> The blog should give you an idea of how the $PATH works and how it
> should be modified.
>
>
> -- Vaibhav Gupta
> >
> > $ export PATH=${HOME}/rtems-work/tools/6/bin:$PATH
> >
> > And to check you have the PATH right, do something like this:
> >
> > $ type sparc-rtems6-gcc
> > sparc-rtems6-gcc is /home/joel/rtems-work/tools/6/bin/sparc-rtems6-gcc
> >
> > On Tue, Jun 15, 2021 at 1:23 PM Eshan Dhawan  
> > wrote:
> >>
> >> Hi matt
> >> It would work if run inside newlib instead of newlib-cygwin
> >> run command inside of ../newlib-cygwin/newlib
> >> instead of ../newlib-cygwin
> >>
> >>
> >> On Tue, Jun 15, 2021 at 10:59 PM Matthew Joyce  
> >> wrote:
> >>>
> >>> Ah, ok will do! Thank you for the tip.
> >>>
> >>> On Tue, Jun 15, 2021 at 7:17 PM Gedare Bloom  wrote:
> >>> >
> >>> > Just a note, it's more efficient to capture your terminal dump into a
> >>> > text file and attach that, rather than put a screenshot up.
> >>> >
> >>> > On Tue, Jun 15, 2021 at 11:14 AM Matthew Joyce  
> >>> > wrote:
> >>> > >
> >>> > > Hi Gentlemen,
> >>> > >
> >>> > > Thanks very much for your quick replies!
> >>> > >
> >>> > > I just tried both, but perhaps I'm misinterpreting your suggestions.
> >>> > > (Could you please see the attached commands / errors!)
> >>> > >
> >>> > > Eshan,
> >>> > >
> >>> > > I did see that link, but it wasn't clear to me what the solution 
> >>> > > was...Sorry!
> >>> > >
> >>> > > Sincerely,
> >>> > >
> >>> > > Matt
> >>> > >
> >>> > > On Tue, Jun 15, 2021 at 6:52 PM Eshan Dhawan 
> >>> > >  wrote:
> >>> > > >
> >>> > > > Hi Matt,
> >>> > > > Try running the command with autoconf version 2.69 that's shipped 
> >>> > > > with RTEMS in the rtems bin
> >>> > > > That works as well.
> >>> > > >
> >>> > > > Also From a quick google search this is what I found : 
> >>> > > > https://superuser.com/questions/617872/cant-locate-autom4te-channeldefs-pm-in-inc-when-it-definitely-is-there
> >>> > > >
> >>> > > > On Tue, Jun 15, 2021 at 9:12 PM Matthew Joyce 
> >>> > > >  wrote:
> >>> > > >>
> >>> > > >> Hello Dr. Joel and Eshan,
> >>> > > >>
> >>> > > >> I have a patch ready to send to Newlib for the sig function 
> >>> > > >> prototypes
> >>> > > >> and STR2SIG_MAX.
> >>> > > >>
> >>> > > >> But to do that, I think I need to have Newlib built, which I must
> >>> > > >> still be doing wrong. The error that I am getting is attached 
> >>> > > >> below.
> >>> > > >>
> >>> > > >> I’ve been trying to follow the steps here:
> >>> > > >> https://medium.com/my-gsoc-2019-journey/apply-newlib-patch-to-rtems-source-builder-6873b0fb31b8
> >>> > > >> and 
> >>> > > >> https://medium.com/my-gsoc-2019-journey/build-newlib-for-sparc-and-arm-architecture-6b3287d4c6f2
> >>> > > >>
> >>> > > >> I even had rebuilt everything from scratch to see if that would 
> >>> > > >> help,
> >>> > > >> but I still get the same error. Maybe I cloned the newlib source 
> >>> > > >> into
> >>> > > >> the wrong directory?
> >>> > > >>
> >>> > > >> I was hoping to get the patch off to Newlib for review as a first 
> >>> > > >> step
> >>> > > >> while I work on writing the actual methods. When you get a moment,
> >>> > > >> could you please advise? Thank you very much!
> >>> > > >>
> >>> > > >> Sincerely,
> >>> > > >>
> >>> > > >> Matt
> >>> > > ___
> >>> > > 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
> > 

RE: [PATCH v1] bsps/i386: Update calibration of TSC to be more accurate

[Jan.Sommer]

> -Original Message-
> From: Gedare Bloom 
> Sent: Tuesday, June 15, 2021 5:01 PM
> To: Sommer, Jan 
> Cc: devel@rtems.org
> Subject: Re: [PATCH v1] bsps/i386: Update calibration of TSC to be more
> accurate
> 
> On Fri, Jun 11, 2021 at 1:44 AM Jan Sommer  wrote:
> >
> > Closes #4455
> > ---
> >  bsps/i386/pc386/clock/ckinit.c | 72
> > ++
> >  1 file changed, 39 insertions(+), 33 deletions(-)
> >
> > diff --git a/bsps/i386/pc386/clock/ckinit.c
> > b/bsps/i386/pc386/clock/ckinit.c index 09afe73cde..cbd2360fde 100644
> > --- a/bsps/i386/pc386/clock/ckinit.c
> > +++ b/bsps/i386/pc386/clock/ckinit.c
> > @@ -104,48 +104,61 @@ static uint32_t pc386_get_timecount_i8254(struct
> > timecounter *tc)
> >
> >  /*
> >   * Calibrate CPU cycles per tick. Interrupts should be disabled.
> > + * Will also set the PIT, so call this before registering the
> > + * periodic timer for rtems tick generation
> >   */
> >  static void calibrate_tsc(void)
> >  {
> >uint64_t  begin_time;
> > -  uint8_t   then_lsb, then_msb, now_lsb, now_msb;
> > -  uint32_t  i;
> > -
> > -  /*
> > -   * We just reset the timer, so we know we're at the beginning of a tick.
> > -   */
> > -
> > -  /*
> > -   * Count cycles. Watching the timer introduces a several microsecond
> > -   * uncertaintity, so let it cook for a while and divide by the number of
> > -   * ticks actually executed.
> > -   */
> > +  uint8_t   lsb, msb;
> > +  uint32_t  max_timer_value;
> > +  uint32_t  last_tick, cur_tick;
> > +  int32_t   diff, remaining;
> > +
> > +  /* Set the timer to free running mode */  outport_byte(TIMER_MODE,
> > + TIMER_SEL0|TIMER_16BIT|TIMER_INTTC);
> Please add spaces between the OR'd values |.
> 

Was just moved from the existing code, but you are right that I can fix it, if 
I touch it.
Will send an update with this and your other formatting suggestions.

> > +  outport_byte(TIMER_CNTR0, 0);
> > +  outport_byte(TIMER_CNTR0, 0);
> I suppose it is needed to write two 0's, but it may be worth a comment why.
> 

Yes, you need to first set the lsb and then the msb of the 16bit reload 
register.
I will add a comment.

> > +  /* 16 bit counter */
> > +  max_timer_value = 0x;
> > +  /* Calibrate for 1s */
> > +  remaining = TIMER_TICK;
> >
> >begin_time = rdtsc();
> > -
> > -  for (i = rtems_clock_get_ticks_per_second() * pc386_isrs_per_tick;
> > -   i != 0; --i ) {
> > -/* We know we've just completed a tick when timer goes from low to
> high */
> > -then_lsb = then_msb = 0xff;
> > -do {
> > -  READ_8254(now_lsb, now_msb);
> > -  if ((then_msb < now_msb) ||
> > -  ((then_msb == now_msb) && (then_lsb < now_lsb)))
> > -break;
> > -  then_lsb = now_lsb;
> > -  then_msb = now_msb;
> > -} while (1);
> > +  READ_8254(lsb,msb);
> space after comma
> 
> > +  last_tick = (msb << 8) | lsb;
> > +  while(remaining > 0) {
> > +READ_8254(lsb,msb);
> > +cur_tick = (msb << 8) | lsb;
> > +/* PIT counts down, so subtract cur from last */
> > +diff = last_tick - cur_tick;
> > +last_tick = cur_tick;
> > +if (diff < 0) {
> > +diff += max_timer_value;
> > +}
> > +remaining -= diff;
> >}
> >
> >pc586_tsc_frequency = rdtsc() - begin_time;
> >
> >  #if 0
> > -  printk( "CPU clock at %u MHz\n", (uint32_t)(pc586_tsc_frequency /
> > 100));
> > +  printk( "CPU clock at %u Hz\n", (uint32_t)(pc586_tsc_frequency ));
> >  #endif
> >  }
> >
> >  static void clockOn(void)
> >  {
> > +
> > +  /*
> > +   * First calibrate the TSC. Do this every time we
> > +   * turn the clock on in case the CPU clock speed has changed.
> > +   */
> > +  for (int i = 0; i<5; ++i)
> > +  {
> > +  if ( x86_has_tsc() )
> > +calibrate_tsc();
> 
> What's the reason to do this 5 times? I don't see any averaging, so just the
> last one is being taken as "correct"
> 

Left overs from debugging.
I removed the print, but forgot to remove the loop as well...

Best regards,

Jan

> > +  }
> > +
> >rtems_interrupt_lock_context lock_context;
> >pc386_isrs_per_tick= 1;
> >pc386_microseconds_per_isr =
> > rtems_configuration_get_microseconds_per_tick();
> > @@ -171,13 +184,6 @@ static void clockOn(void)
> >rtems_interrupt_lock_release(_i386_i8254_access_lock,
> > _context);
> >
> >bsp_interrupt_vector_enable( BSP_PERIODIC_TIMER );
> > -
> > -  /*
> > -   * Now calibrate cycles per tick. Do this every time we
> > -   * turn the clock on in case the CPU clock speed has changed.
> > -   */
> > -  if ( x86_has_tsc() )
> > -calibrate_tsc();
> >  }
> >
> >  bool Clock_isr_enabled = false;
> > --
> > 2.17.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org

Re: [PATCH rtems-libbsd 2/2] builder.py: Only disable tests if they are there

[Christian Mauderer]

On 15/06/2021 17:11, Gedare Bloom wrote:

ok


Thanks.



On Fri, Jun 11, 2021 at 6:20 AM Christian Mauderer  wrote:


For checking the dependencies, the tests are removed. But if the tests
are not enabled at all, that triggers a python exception.
---
  builder.py | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/builder.py b/builder.py
index cbe5dc59..a34a1518 100755
--- a/builder.py
+++ b/builder.py
@@ -1062,7 +1062,8 @@ class ModuleManager(object):

  def _checkDependencies(self):
  enabled_modules = self.getEnabledModules()
-enabled_modules.remove('tests')
+if 'tests' in enabled_modules:
+enabled_modules.remove('tests')
  for mod in enabled_modules:
  if mod not in self.modules:
  raise KeyError('enabled module not found: %s' % (mod))
--
2.32.0

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



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

[PATCH v6 2/2] Update smpstrongapa01; Add smpstrongapa02,smpstrongapa03

[Richi Dubey]

Update smpstrongapa01 to account for task shifting.
---
 spec/build/testsuites/smptests/grp.yml|   4 +
 .../testsuites/smptests/smpstrongapa02.yml|  21 +
 .../testsuites/smptests/smpstrongapa03.yml|  21 +
 testsuites/smptests/smpstrongapa01/init.c |  72 ++--
 testsuites/smptests/smpstrongapa02/init.c | 373 ++
 .../smpstrongapa02/smpstrongapa02.doc |  11 +
 .../smpstrongapa02/smpstrongapa02.scn |   2 +
 testsuites/smptests/smpstrongapa03/init.c | 358 +
 .../smpstrongapa03/smpstrongapa03.doc |  11 +
 .../smpstrongapa03/smpstrongapa03.scn |   2 +
 10 files changed, 846 insertions(+), 29 deletions(-)
 create mode 100644 spec/build/testsuites/smptests/smpstrongapa02.yml
 create mode 100644 spec/build/testsuites/smptests/smpstrongapa03.yml
 create mode 100644 testsuites/smptests/smpstrongapa02/init.c
 create mode 100644 testsuites/smptests/smpstrongapa02/smpstrongapa02.doc
 create mode 100644 testsuites/smptests/smpstrongapa02/smpstrongapa02.scn
 create mode 100644 testsuites/smptests/smpstrongapa03/init.c
 create mode 100644 testsuites/smptests/smpstrongapa03/smpstrongapa03.doc
 create mode 100644 testsuites/smptests/smpstrongapa03/smpstrongapa03.scn

diff --git a/spec/build/testsuites/smptests/grp.yml 
b/spec/build/testsuites/smptests/grp.yml
index 771708503e..14b575e058 100644
--- a/spec/build/testsuites/smptests/grp.yml
+++ b/spec/build/testsuites/smptests/grp.yml
@@ -125,6 +125,10 @@ links:
   uid: smpsignal01
 - role: build-dependency
   uid: smpstrongapa01
+- role: build-dependency
+  uid: smpstrongapa02
+- role: build-dependency
+  uid: smpstrongapa03
 - role: build-dependency
   uid: smpswitchextension01
 - role: build-dependency
diff --git a/spec/build/testsuites/smptests/smpstrongapa02.yml 
b/spec/build/testsuites/smptests/smpstrongapa02.yml
new file mode 100644
index 00..56673c1cf0
--- /dev/null
+++ b/spec/build/testsuites/smptests/smpstrongapa02.yml
@@ -0,0 +1,21 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+build-type: test-program
+cflags: []
+copyrights:
+- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+- Copyright (C) 2020 Richi Dubey (richidu...@gmail.com)
+cppflags: []
+cxxflags: []
+enabled-by:
+- RTEMS_SMP
+features: c cprogram
+includes: []
+ldflags: []
+links: []
+source:
+- testsuites/smptests/smpstrongapa02/init.c
+stlib: []
+target: testsuites/smptests/smpstrongapa02.exe
+type: build
+use-after: []
+use-before: []
diff --git a/spec/build/testsuites/smptests/smpstrongapa03.yml 
b/spec/build/testsuites/smptests/smpstrongapa03.yml
new file mode 100644
index 00..50d08216b8
--- /dev/null
+++ b/spec/build/testsuites/smptests/smpstrongapa03.yml
@@ -0,0 +1,21 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+build-type: test-program
+cflags: []
+copyrights:
+- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+- Copyright (C) 2020 Richi Dubey (richidu...@gmail.com)
+cppflags: []
+cxxflags: []
+enabled-by:
+- RTEMS_SMP
+features: c cprogram
+includes: []
+ldflags: []
+links: []
+source:
+- testsuites/smptests/smpstrongapa03/init.c
+stlib: []
+target: testsuites/smptests/smpstrongapa03.exe
+type: build
+use-after: []
+use-before: []
diff --git a/testsuites/smptests/smpstrongapa01/init.c 
b/testsuites/smptests/smpstrongapa01/init.c
index bf8bc05231..e7abacd519 100644
--- a/testsuites/smptests/smpstrongapa01/init.c
+++ b/testsuites/smptests/smpstrongapa01/init.c
@@ -1,4 +1,5 @@
 /*
+ * Copyright (c) 2020 Richi Dubey ( richidu...@gmail.com )
  * Copyright (c) 2016, 2017 embedded brains GmbH.  All rights reserved.
  *
  *  embedded brains GmbH
@@ -16,23 +17,28 @@
 #include "config.h"
 #endif
 
-#include "tmacros.h"
+#include 
 
 #include 
 
 const char rtems_test_name[] = "SMPSTRONGAPA 1";
 
-#define CPU_COUNT 4
+#define CPU_COUNT 2
 
-#define TASK_COUNT (3 * CPU_COUNT)
+#define TASK_COUNT 3
 
 #define P(i) (UINT32_C(2) + i)
 
 #define ALL ((UINT32_C(1) << CPU_COUNT) - 1)
 
-#define IDLE UINT8_C(255)
+#define A(cpu0, cpu1) ( (cpu1 << 1) | cpu0 )
 
-#define NAME rtems_build_name('S', 'A', 'P', 'A')
+typedef enum {
+  T0,
+  T1,
+  T2,
+  IDLE
+} task_index;
 
 typedef struct {
   enum {
@@ -43,7 +49,7 @@ typedef struct {
 KIND_UNBLOCK
   } kind;
 
-  size_t index;
+  task_index index;
 
   struct {
 rtems_task_priority priority;
@@ -65,54 +71,59 @@ typedef struct {
 KIND_RESET, \
 0, \
 { 0 }, \
-{ IDLE, IDLE, IDLE, IDLE } \
+{ IDLE, IDLE} \
   }
 
-#define SET_PRIORITY(index, prio, cpu0, cpu1, cpu2, cpu3) \
+#define SET_PRIORITY(index, prio, cpu0, cpu1) \
   { \
 KIND_SET_PRIORITY, \
 index, \
 { .priority = prio }, \
-{ cpu0, cpu1, cpu2, cpu3 } \
+{ cpu0, cpu1} \
   }
 
-#define SET_AFFINITY(index, aff, cpu0, cpu1, cpu2, cpu3) \
+#define SET_AFFINITY(index, aff, cpu0, cpu1) \
   { \
 KIND_SET_AFFINITY, \
 index, \
 { .cpu_set = aff }, \
-{ cpu0, cpu1, cpu2, 

[PATCH v6 1/2] Update Strong APA Scheduler

[Richi Dubey]

This change allows for the migration of higher priority tasks on the
arrival of a lower priority task limited by affinity constraints.

Change license to BSD-2-Clause according to file history and
re-licensing agreement.
---
 cpukit/include/rtems/scheduler.h  |  10 +-
 .../include/rtems/score/schedulerstrongapa.h  | 162 ++-
 cpukit/score/src/schedulerstrongapa.c | 991 ++
 3 files changed, 929 insertions(+), 234 deletions(-)

diff --git a/cpukit/include/rtems/scheduler.h b/cpukit/include/rtems/scheduler.h
index 955a83cfb4..76d84fd787 100644
--- a/cpukit/include/rtems/scheduler.h
+++ b/cpukit/include/rtems/scheduler.h
@@ -251,22 +251,24 @@
 #ifdef CONFIGURE_SCHEDULER_STRONG_APA
   #include 
 
+  #ifndef CONFIGURE_MAXIMUM_PROCESSORS
+#error "CONFIGURE_MAXIMUM_PROCESSORS must be defined to configure the 
Strong APA scheduler"
+  #endif
+
   #define SCHEDULER_STRONG_APA_CONTEXT_NAME( name ) \
 SCHEDULER_CONTEXT_NAME( strong_APA_ ## name )
 
   #define RTEMS_SCHEDULER_STRONG_APA( name, prio_count ) \
 static struct { \
   Scheduler_strong_APA_Context Base; \
-  Chain_ControlReady[ ( prio_count ) ]; \
+  Scheduler_strong_APA_CPU CPU[ CONFIGURE_MAXIMUM_PROCESSORS ]; \
 } SCHEDULER_STRONG_APA_CONTEXT_NAME( name )
 
   #define RTEMS_SCHEDULER_TABLE_STRONG_APA( name, obj_name ) \
 { \
   _STRONG_APA_CONTEXT_NAME( name ).Base.Base.Base, \
   SCHEDULER_STRONG_APA_ENTRY_POINTS, \
-  RTEMS_ARRAY_SIZE( \
-SCHEDULER_STRONG_APA_CONTEXT_NAME( name ).Ready \
-  ) - 1, \
+  SCHEDULER_STRONG_APA_MAXIMUM_PRIORITY, \
   ( obj_name ) \
   SCHEDULER_CONTROL_IS_NON_PREEMPT_MODE_SUPPORTED( false ) \
 }
diff --git a/cpukit/include/rtems/score/schedulerstrongapa.h 
b/cpukit/include/rtems/score/schedulerstrongapa.h
index 530eadc279..acbeb7893a 100644
--- a/cpukit/include/rtems/score/schedulerstrongapa.h
+++ b/cpukit/include/rtems/score/schedulerstrongapa.h
@@ -8,30 +8,46 @@
  */
 
 /*
- * Copyright (c) 2013, 2018 embedded brains GmbH.  All rights reserved.
+ * SPDX-License-Identifier: BSD-2-Clause
  *
- *  embedded brains GmbH
- *  Dornierstr. 4
- *  82178 Puchheim
- *  Germany
- *  
+ * Copyright (C) 2020 Richi Dubey
+ * Copyright (c) 2013, 2018 embedded brains GmbH
  *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
+ * 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 _RTEMS_SCORE_SCHEDULERSTRONGAPA_H
 #define _RTEMS_SCORE_SCHEDULERSTRONGAPA_H
 
 #include 
-#include 
 #include 
 
 #ifdef __cplusplus
 extern "C" {
 #endif /* __cplusplus */
 
+/* Forward Declaration of Per_CPU_Control */
+struct Per_CPU_Control;
+
 /**
  * @defgroup RTEMSScoreSchedulerStrongAPA Strong APA Scheduler
  *
@@ -39,42 +55,95 @@ extern "C" {
  *
  * @brief This group contains the Strong APA Scheduler implementation.
  *
- * This is an implementation of the global fixed priority scheduler (G-FP).  It
- * uses one ready chain per priority to ensure constant time insert operations.
- * The scheduled chain uses linear insert operations and has at most processor
- * count entries.  Since the processor and priority count are constants all
- * scheduler operations complete in a bounded execution time.
- *
- * The the_thread preempt mode will be ignored.
+ * This is an implementation of the Strong APA scheduler defined by
+ * Cerqueira et al. in Linux's Processor Affinity API, Refined:
+ * Shifting Real-Time Tasks Towards Higher Schedulability.
  *
+ * The scheduled and ready nodes are accessed via the
+ * Scheduler_strong_APA_Context::Ready which helps in backtracking when a
+