[PATCH rtems-libbsd] ipsec-tools: Reduce allocated buffer size

2022-02-22 Thread Christian Mauderer 
By default, pfkey allocates a 2MB buffer that is used for SPD entries.
This size is a good choice for a server system where a lot of clients
should be handled. But on our embedded systems, an application with that
much clients is unlikely and 2MB is a lot of space. So reduce that to
the default value of 128kB which should be enough for a small number of
ipsec connections.

See https://bugzilla.redhat.com/show_bug.cgi?id=607361 for more details
why the upstream project originally increased the size.

If someone really needs a bigger size, there is a option in the
configuration file of pfkey called `pfkey_buffer` that can overwrite
this value.
---
 ipsec-tools/src/libipsec/pfkey.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/ipsec-tools/src/libipsec/pfkey.c b/ipsec-tools/src/libipsec/pfkey.c
index 385a21a9..cc6ad816 100644
--- a/ipsec-tools/src/libipsec/pfkey.c
+++ b/ipsec-tools/src/libipsec/pfkey.c
@@ -1836,8 +1836,18 @@ pfkey_open(void)
(void)setsockopt(so, SOL_SOCKET, SO_SNDBUF,
&bufsiz_wanted, sizeof(bufsiz_wanted));
 
+#ifndef __rtems__
/* Try to have have at least 2MB. If we have more, do not lower it. */
bufsiz_wanted = 2 * 1024 * 1024;
+#else /* __rtems__ */
+   /*
+* The bufsize_wanted has an influence on the maximum number of SPDs. We
+* don't really need that much of them on an embedded system. If some
+* application really needs it, this can be overwritten with the
+* pfkey_buffer option in the config file.
+*/
+   bufsiz_wanted = 128 * 1024;
+#endif /* __rtems__ */
len = sizeof(bufsiz_current);
ret = getsockopt(so, SOL_SOCKET, SO_RCVBUF,
&bufsiz_current, &len);
-- 
2.31.1

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

Re: Source-builder Qemu compiling / customizing

2022-02-22 Thread Karel Gardas 

On 2/22/22 04:54, Sam Price wrote:

Im on ubuntu 18 and trying to build qemu for microblaze.
I had to modify the
source-builder/defaults.mc
and change several tool paths from /usr/bin to /bin
(This is prob not a standard build process.)

Short question.  What file in rtems-source builder do I need to modify to
add --disable-docs flag to the command that calls qemu configure and
generates the do-build file.



source-builder/config/qemu-5-1.cfg

or

source-builder/config/qemu-common-2.cfg

but I would also recommend to read at least part of rsb docs: 
https://docs.rtems.org/branches/master/user/rsb/index.html to get some 
context.


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

[PATCH] c-user: Document CONFIGURE_SCHEDULER_TABLE_ENTRIES

2022-02-22 Thread Sebastian Huber 
Update #4524.
---
 c-user/config/scheduler-general.rst | 93 -
 1 file changed, 90 insertions(+), 3 deletions(-)

diff --git a/c-user/config/scheduler-general.rst 
b/c-user/config/scheduler-general.rst
index 7c42039..7169a83 100644
--- a/c-user/config/scheduler-general.rst
+++ b/c-user/config/scheduler-general.rst
@@ -1,6 +1,6 @@
 .. SPDX-License-Identifier: CC-BY-SA-4.0
 
-.. Copyright (C) 2020, 2021 embedded brains GmbH 
(http://www.embedded-brains.de)
+.. Copyright (C) 2020, 2022 embedded brains GmbH 
(http://www.embedded-brains.de)
 .. Copyright (C) 2010 Gedare Bloom
 .. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
 
@@ -198,7 +198,8 @@ scheduler to processor assignments.
 
 .. rubric:: NOTES:
 
-This configuration option is only evaluated in SMP configurations.
+Where the system was built with SMP support enabled, this configuration
+option is evaluated, otherwise it is ignored.
 
 This is an advanced configuration option, see
 :ref:`ConfigurationSchedulersClustered`.
@@ -210,10 +211,21 @@ The following constraints apply to this configuration 
option:
 * The value of the configuration option shall be a list of the following
   macros:
 
-  * ``RTEMS_SCHEDULER_ASSIGN( processor_index, attributes )``
+  * ``RTEMS_SCHEDULER_ASSIGN( scheduler_index, attributes )``
 
   * ``RTEMS_SCHEDULER_ASSIGN_NO_SCHEDULER``
 
+  The ``scheduler_index`` macro parameter shall be a valid index of the
+  scheduler table defined by the :ref:`CONFIGURE_SCHEDULER_TABLE_ENTRIES`
+  configuration option.
+
+  The ``attributes`` macro parameter shall be set to exactly one of the
+  following constants:
+
+  * ``RTEMS_SCHEDULER_ASSIGN_PROCESSOR_MANDATORY``
+
+  * ``RTEMS_SCHEDULER_ASSIGN_PROCESSOR_OPTIONAL``
+
 * The value of the configuration option shall be a list of exactly
   :ref:`CONFIGURE_MAXIMUM_PROCESSORS` elements.
 
@@ -667,6 +679,81 @@ support enabled.
 
 This scheduler algorithm is not correctly implemented.  Do not use it.
 
+.. Generated from spec:/acfg/if/scheduler-table-entries
+
+.. raw:: latex
+
+\clearpage
+
+.. index:: CONFIGURE_SCHEDULER_TABLE_ENTRIES
+
+.. _CONFIGURE_SCHEDULER_TABLE_ENTRIES:
+
+CONFIGURE_SCHEDULER_TABLE_ENTRIES
+-
+
+.. rubric:: CONSTANT:
+
+``CONFIGURE_SCHEDULER_TABLE_ENTRIES``
+
+.. rubric:: OPTION TYPE:
+
+This configuration option is an initializer define.
+
+.. rubric:: DEFAULT VALUE:
+
+The default value of this configuration option is the definition of exactly
+one table entry for the configured scheduler.
+
+.. rubric:: DESCRIPTION:
+
+The value of this configuration option is used to initialize the table of
+configured schedulers.
+
+.. rubric:: NOTES:
+
+Schedulers registered in the scheduler table by this configuration option are
+available to the application.  The scheduler table entry index defines the
+index of the scheduler.
+
+This is an advanced configuration option, see
+:ref:`ConfigurationSchedulersClustered`.
+
+.. rubric:: CONSTRAINTS:
+
+The following constraints apply to this configuration option:
+
+* The value of the configuration option shall be a list of the following
+  macros:
+
+  * ``RTEMS_SCHEDULER_TABLE_CBS( name, obj_name )``
+
+  * ``RTEMS_SCHEDULER_TABLE_EDF( name, obj_name )``
+
+  * ``RTEMS_SCHEDULER_TABLE_EDF_SMP( name, obj_name )``
+
+  * ``RTEMS_SCHEDULER_TABLE_PRIORITY_AFFINITY_SMP( name, obj_name )``
+
+  * ``RTEMS_SCHEDULER_TABLE_PRIORITY( name, obj_name )``
+
+  * ``RTEMS_SCHEDULER_TABLE_PRIORITY_SMP( name, obj_name )``
+
+  * ``RTEMS_SCHEDULER_TABLE_SIMPLE( name, obj_name )``
+
+  * ``RTEMS_SCHEDULER_TABLE_SIMPLE_SMP( name, obj_name )``
+
+  * ``RTEMS_SCHEDULER_TABLE_STRONG_APA( name, obj_name )``
+
+  The ``name`` macro parameter shall be the name associated with the scheduler
+  data structures, see :ref:`ConfigurationSchedulersClustered`.
+
+  The ``obj_name`` macro parameter shall be the scheduler object name.  It is
+  recommended to define the scheduler object name through
+  :c:func:`rtems_build_name`.
+
+* Where the system was build with SMP support enabled, the table shall have one
+  or more entries, otherwise it shall have exactly one entry.
+
 .. Generated from spec:/acfg/if/scheduler-user
 
 .. raw:: latex
-- 
2.34.1

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

[PATCH] config: Document CONFIGURE_SCHEDULER_TABLE_ENTRIES

2022-02-22 Thread Sebastian Huber 
---
 cpukit/doxygen/appl-config.h | 84 ++--
 1 file changed, 80 insertions(+), 4 deletions(-)

diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
index 4735af8766..85290fd4bc 100644
--- a/cpukit/doxygen/appl-config.h
+++ b/cpukit/doxygen/appl-config.h
@@ -1,7 +1,7 @@
 /* SPDX-License-Identifier: BSD-2-Clause */
 
 /*
- * Copyright (C) 2019, 2021 embedded brains GmbH 
(http://www.embedded-brains.de)
+ * Copyright (C) 2019, 2022 embedded brains GmbH 
(http://www.embedded-brains.de)
  * Copyright (C) 2010 Gedare Bloom
  * Copyright (C) 1988, 2021 On-Line Applications Research Corporation (OAR)
  *
@@ -4243,16 +4243,29 @@
  *
  * * It shall be a list of the following macros:
  *
- *   * ``RTEMS_SCHEDULER_ASSIGN( processor_index, attributes )``
+ *   * ``RTEMS_SCHEDULER_ASSIGN( scheduler_index, attributes )``
  *
  *   * ``RTEMS_SCHEDULER_ASSIGN_NO_SCHEDULER``
  *
- * * It shall be a list of exactly #CONFIGURE_MAXIMUM_PROCESSORS elements.
+ *   The ``scheduler_index`` macro parameter shall be a valid index of the
+ *   scheduler table defined by the #CONFIGURE_SCHEDULER_TABLE_ENTRIES
+ *   configuration option.
+ *
+ *   The ``attributes`` macro parameter shall be set to exactly one of the
+ *   following constants:
+ *
+ *   * ``RTEMS_SCHEDULER_ASSIGN_PROCESSOR_MANDATORY``
+ *
+ *   * ``RTEMS_SCHEDULER_ASSIGN_PROCESSOR_OPTIONAL``
+ *
+ * * The value of the configuration option shall be a list of exactly
+ *   #CONFIGURE_MAXIMUM_PROCESSORS elements.
  * @endparblock
  *
  * @par Notes
  * @parblock
- * This configuration option is only evaluated in SMP configurations.
+ * Where the system was built with SMP support enabled, this configuration
+ * option is evaluated, otherwise it is ignored.
  *
  * This is an advanced configuration option, see https://docs.rtems.org/branches/master/c-user/config/scheduler-clustered.html>Clustered
@@ -4585,6 +4598,69 @@
  */
 #define CONFIGURE_SCHEDULER_STRONG_APA
 
+/* Generated from spec:/acfg/if/scheduler-table-entries */
+
+/**
+ * @brief This configuration option is an initializer define.
+ *
+ * The value of this configuration option is used to initialize the table of
+ * configured schedulers.
+ *
+ * @par Default Value
+ * The default value of this configuration option is the definition of exactly
+ * one table entry for the configured scheduler.
+ *
+ * @par Constraints
+ * @parblock
+ * The following constraints apply to this configuration option:
+ *
+ * * The value of the configuration option shall be a list of the following
+ *   macros:
+ *
+ *   * ``RTEMS_SCHEDULER_TABLE_CBS( name, obj_name )``
+ *
+ *   * ``RTEMS_SCHEDULER_TABLE_EDF( name, obj_name )``
+ *
+ *   * ``RTEMS_SCHEDULER_TABLE_EDF_SMP( name, obj_name )``
+ *
+ *   * ``RTEMS_SCHEDULER_TABLE_PRIORITY_AFFINITY_SMP( name, obj_name )``
+ *
+ *   * ``RTEMS_SCHEDULER_TABLE_PRIORITY( name, obj_name )``
+ *
+ *   * ``RTEMS_SCHEDULER_TABLE_PRIORITY_SMP( name, obj_name )``
+ *
+ *   * ``RTEMS_SCHEDULER_TABLE_SIMPLE( name, obj_name )``
+ *
+ *   * ``RTEMS_SCHEDULER_TABLE_SIMPLE_SMP( name, obj_name )``
+ *
+ *   * ``RTEMS_SCHEDULER_TABLE_STRONG_APA( name, obj_name )``
+ *
+ *   The ``name`` macro parameter shall be the name associated with the
+ *   scheduler data structures, see https://docs.rtems.org/branches/master/c-user/config/scheduler-clustered.html";>Clustered
+ *   Scheduler Configuration.
+ *
+ *   The ``obj_name`` macro parameter shall be the scheduler object name.  It
+ *   is recommended to define the scheduler object name through
+ *   rtems_build_name().
+ *
+ * * Where the system was build with SMP support enabled, the table shall have
+ *   one or more entries, otherwise it shall have exactly one entry.
+ * @endparblock
+ *
+ * @par Notes
+ * @parblock
+ * Schedulers registered in the scheduler table by this configuration option
+ * are available to the application.  The scheduler table entry index defines
+ * the index of the scheduler.
+ *
+ * This is an advanced configuration option, see https://docs.rtems.org/branches/master/c-user/config/scheduler-clustered.html";>Clustered
+ * Scheduler Configuration.
+ * @endparblock
+ */
+#define CONFIGURE_SCHEDULER_TABLE_ENTRIES
+
 /* Generated from spec:/acfg/if/scheduler-user */
 
 /**
-- 
2.34.1

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

Re: NTP client recommendation for RTEMS?

2022-02-22 Thread Joel Sherrill 
Are you planning to get the NTP server side of the freebsd-org code working?

Or get it building but not testing it?

Or just focusing on building and testing JUST the client part.

Thanks.

--joel

On Fri, Feb 18, 2022 at 8:39 AM Joel Sherrill  wrote:
>
> On Fri, Feb 18, 2022 at 7:46 AM Sebastian Huber
>  wrote:
> >
> > On 18/02/2022 14:43, Joel Sherrill wrote:
> > > On Fri, Feb 18, 2022, 7:22 AM Sebastian Huber
> > >  > > > wrote:
> > >
> > > Hello,
> > >
> > > I would like to add an NTP client support for RTEMS. The ntp_adjtime()
> > > implementation is already available as a patch. For testing purposes I
> > > ported the NTP daemon from FreeBSD to libbsd. This basically works
> > > fine.
> > > I am not sure about the maintenance status of this code
> > > (https://www.ntp.org/ ). There is also
> > >
> > > https://www.ntpsec.org/ 
> > >
> > > This project has a public Git repository and seems to be more active.
> > > However, there is no standard package for openSUSE Leap 15.3. Maybe
> > > this
> > > is because most Linux users use now timesyncd from systemd. Any
> > > recommendations?
> > >
> > >
> > > I'd stick with ntp.org  without much thought. With that
> > > being what FreeBSD uses, it is icing on the cake.
> >
> > The code looks not that good. There seems to be a lot of cleanup done in
> > ntpsec.org.
>
> Yes that is true. And I will communicate my concerns offline. One of
> the main ones is that the ntpsec project was heading in a very Linux
> centric way on what APIs would be used. They did kill a lot of old platforms
> and do some clean up which is good.
>
> There were discussions about re-writing it in Go. If that happens, we
> would have issues.
>
> In general, I leaned to the freebsd.org code because we already have
> a process in place for dealing with it. And if it is good enough for FreeBSD,
> it should be a good first choice for us.
>
> If this turns out to be wrong, there is ntpsec and OpenNTP which seem
> to be derived from ntp.org. Any porting done on the freebsd.org code should
> apply to the others easily enough.
>
> No idea what to do about a full NTP client for lwip. Any thoughts?
>
> >
> > >
> > > Did you eliminate use of signals like Chris had to do with ptpd?
> >
> > Not yet, they use both select(), but this should be changed to use
> > kqueue(). I hacked away the use of signal.
>
> Great! Is this work going to land in the public in the near future?
>
> --joel
>
> > --
> > embedded brains GmbH
> > Herr Sebastian HUBER
> > Dornierstr. 4
> > 82178 Puchheim
> > Germany
> > email: sebastian.hu...@embedded-brains.de
> > phone: +49-89-18 94 741 - 16
> > fax:   +49-89-18 94 741 - 08
> >
> > Registergericht: Amtsgericht München
> > Registernummer: HRB 157899
> > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> > Unsere Datenschutzerklärung finden Sie hier:
> > https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: NTP client recommendation for RTEMS?

2022-02-22 Thread Sebastian Huber 

On 22/02/2022 19:22, Joel Sherrill wrote:

Are you planning to get the NTP server side of the freebsd-org code working?

Or get it building but not testing it?

Or just focusing on building and testing JUST the client part.


I ported the ntpd from FreeBSD to an older version of the libbsd. I only 
tested the client part and this seems to work fine after some basic tests.


--
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: NTP client recommendation for RTEMS?

2022-02-22 Thread Joel Sherrill 
On Tue, Feb 22, 2022 at 1:21 PM Sebastian Huber
 wrote:
>
> On 22/02/2022 19:22, Joel Sherrill wrote:
> > Are you planning to get the NTP server side of the freebsd-org code working?
> >
> > Or get it building but not testing it?
> >
> > Or just focusing on building and testing JUST the client part.
>
> I ported the ntpd from FreeBSD to an older version of the libbsd. I only
> tested the client part and this seems to work fine after some basic tests.

OK. That matches what I expected. Is the libbsd version to old to merge
against? Any plans to merge this?

Alternatively, is your work available to be used as the basis for updating
to 6-freebsd-12?

--joel

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

Re: NTP client recommendation for RTEMS?

2022-02-22 Thread Sebastian Huber 

On 22/02/2022 20:30, Joel Sherrill wrote:

On Tue, Feb 22, 2022 at 1:21 PM Sebastian Huber
  wrote:

On 22/02/2022 19:22, Joel Sherrill wrote:

Are you planning to get the NTP server side of the freebsd-org code working?

Or get it building but not testing it?

Or just focusing on building and testing JUST the client part.

I ported the ntpd from FreeBSD to an older version of the libbsd. I only
tested the client part and this seems to work fine after some basic tests.

OK. That matches what I expected. Is the libbsd version to old to merge
against? Any plans to merge this?

Alternatively, is your work available to be used as the basis for updating
to 6-freebsd-12?


I have a very long TODO list. Actually, I started with the current 
6-freebsd-12 branch, but it didn't work, so in principle generating 
patches for this branch should be easy.


--
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: NTP client recommendation for RTEMS?

2022-02-22 Thread Joel Sherrill 
On Tue, Feb 22, 2022, 1:45 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 22/02/2022 20:30, Joel Sherrill wrote:
> > On Tue, Feb 22, 2022 at 1:21 PM Sebastian Huber
> >   wrote:
> >> On 22/02/2022 19:22, Joel Sherrill wrote:
> >>> Are you planning to get the NTP server side of the freebsd-org code
> working?
> >>>
> >>> Or get it building but not testing it?
> >>>
> >>> Or just focusing on building and testing JUST the client part.
> >> I ported the ntpd from FreeBSD to an older version of the libbsd. I only
> >> tested the client part and this seems to work fine after some basic
> tests.
> > OK. That matches what I expected. Is the libbsd version to old to merge
> > against? Any plans to merge this?
> >
> > Alternatively, is your work available to be used as the basis for
> updating
> > to 6-freebsd-12?
>
> I have a very long TODO list. Actually, I started with the current
> 6-freebsd-12 branch, but it didn't work, so in principle generating
> patches for this branch should be easy.
>

Thanks. If we end up working on this, we will sync with you to help and
avoid duplicate work.

--joel

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

[PATCH v3 1/5] cpukit/libdebugger: Avoid missed swbreak removal

2022-02-22 Thread Kinsey Moore 
It is possible to remove software breaks without actually restoring the
original instruction to memory. When this happens, the original
instruction is lost. This ensures that the original instruction is
restored when a software break is removed.
---
 cpukit/libdebugger/rtems-debugger-target.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/cpukit/libdebugger/rtems-debugger-target.c 
b/cpukit/libdebugger/rtems-debugger-target.c
index 04b274909b..c298a62357 100644
--- a/cpukit/libdebugger/rtems-debugger-target.c
+++ b/cpukit/libdebugger/rtems-debugger-target.c
@@ -191,6 +191,22 @@ rtems_debugger_target_swbreak_control(bool insert, 
uintptr_t addr, DB_UINT kind)
 if (loc == swbreaks[i].address) {
   size_t remaining;
   if (!insert) {
+if (target->breakpoint_size > 4)
+  memcpy(loc, swbreaks[i].contents, target->breakpoint_size);
+else {
+  switch (target->breakpoint_size) {
+  case 4:
+loc[3] = swbreaks[i].contents[3];
+  case 3:
+loc[2] = swbreaks[i].contents[2];
+  case 2:
+loc[1] = swbreaks[i].contents[1];
+  case 1:
+loc[0] = swbreaks[i].contents[0];
+break;
+  }
+}
+rtems_debugger_target_cache_sync(&swbreaks[i]);
 --target->swbreaks.level;
 remaining = (target->swbreaks.level - i) * swbreak_size;
 memmove(&swbreaks[i], &swbreaks[i + 1], remaining);
-- 
2.30.2

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

[PATCH v3 0/5] Add MicroBlaze libdebugger support

2022-02-22 Thread Kinsey Moore 
Changes from v2:
* Removed interrupt hooks in favor of step and continue behavior


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

[PATCH v3 2/5] cpukit/libdebugger: Add pure swbreak capability

2022-02-22 Thread Kinsey Moore 
Add a capability that allows for implementations that operate purely
using software breaks. Due to this implementation method, software
breaks must not be restored until just before returning control to the
thread itself and will be handled by the implementation through thread
switch and interrupt hooks.
---
 cpukit/libdebugger/rtems-debugger-target.h  | 14 +++---
 cpukit/libdebugger/rtems-debugger-threads.c |  4 +++-
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/cpukit/libdebugger/rtems-debugger-target.h 
b/cpukit/libdebugger/rtems-debugger-target.h
index 1e132fb28c..7836f93bd6 100644
--- a/cpukit/libdebugger/rtems-debugger-target.h
+++ b/cpukit/libdebugger/rtems-debugger-target.h
@@ -49,9 +49,17 @@ extern "C" {
 /**
  * Target capabilities mask.
  */
-#define RTEMS_DEBUGGER_TARGET_CAP_SWBREAK   (1 << 0)
-#define RTEMS_DEBUGGER_TARGET_CAP_HWBREAK   (1 << 1)
-#define RTEMS_DEBUGGER_TARGET_CAP_HWWATCH   (1 << 2)
+#define RTEMS_DEBUGGER_TARGET_CAP_SWBREAK  (1 << 0)
+#define RTEMS_DEBUGGER_TARGET_CAP_HWBREAK  (1 << 1)
+#define RTEMS_DEBUGGER_TARGET_CAP_HWWATCH  (1 << 2)
+/*
+ * This target capability indicates that the target implementation uses a pure
+ * software break implementation which must not allow breakpoints to be
+ * inserted before the actual switch to the thread, be it in interrupt context
+ * or otherwise. Such implementations must necessarily implement a thread
+ * switch hook and interrupt hooks to handle these situations.
+ */
+#define RTEMS_DEBUGGER_TARGET_CAP_PURE_SWBREAK (1 << 3)
 
 /**
  * Types of hardware breakpoints.
diff --git a/cpukit/libdebugger/rtems-debugger-threads.c 
b/cpukit/libdebugger/rtems-debugger-threads.c
index c628c0250e..841199bfe3 100644
--- a/cpukit/libdebugger/rtems-debugger-threads.c
+++ b/cpukit/libdebugger/rtems-debugger-threads.c
@@ -355,9 +355,11 @@ rtems_debugger_thread_system_resume(bool detaching)
   current = rtems_debugger_thread_current(threads);
   if (current != NULL) {
 size_t i;
+rtems_debugger_target* target = rtems_debugger->target;
 if (rtems_debugger_verbose())
   rtems_debugger_printf("rtems-db: sys:: resuming\n");
-if (!detaching) {
+if (!detaching
+  && (target->capabilities & RTEMS_DEBUGGER_TARGET_CAP_PURE_SWBREAK) == 0) 
{
   r = rtems_debugger_target_swbreak_insert();
   if (r == 0)
 r = rtems_debugger_target_hwbreak_insert();
-- 
2.30.2

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

[PATCH v3 3/5] microblaze: Decouple exceptions from interrupts

2022-02-22 Thread Kinsey Moore 
Exception handling should be enabled at all times during execution to
ensure that exceptions are not ignored which would cause further
problems. This separates use of the exception enable bit from use of the
interrupt enable bit in the machine status register so that they can be
manipulated independently.
---
 bsps/microblaze/microblaze_fpga/start/crtinit.S   |  3 +++
 cpukit/score/cpu/microblaze/cpu.c |  6 +++---
 cpukit/score/cpu/microblaze/include/rtems/score/cpu.h | 10 +-
 3 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/bsps/microblaze/microblaze_fpga/start/crtinit.S 
b/bsps/microblaze/microblaze_fpga/start/crtinit.S
index a9779404b2..d56bee3b19 100644
--- a/bsps/microblaze/microblaze_fpga/start/crtinit.S
+++ b/bsps/microblaze/microblaze_fpga/start/crtinit.S
@@ -81,6 +81,9 @@ _crtinit:
 #ifndef __rtems__
brlid   r15, main  /* Execute 
the program */
 #else
+   mfs r3, rmsr
+   ori r3, r3, 0x100  /* Set 
Exception Enable MSR flag */
+   mts rmsr, r3
brlid   r15, boot_card
 #endif /* __rtems__ */
addir5, r0, 0
diff --git a/cpukit/score/cpu/microblaze/cpu.c 
b/cpukit/score/cpu/microblaze/cpu.c
index fe55ef5546..1e829a4714 100644
--- a/cpukit/score/cpu/microblaze/cpu.c
+++ b/cpukit/score/cpu/microblaze/cpu.c
@@ -142,9 +142,9 @@ void _CPU_ISR_Set_level( uint32_t level )
   _CPU_MSR_GET( microblaze_switch_reg );
 
   if ( level == 0 ) {
-microblaze_switch_reg |= (MICROBLAZE_MSR_IE | MICROBLAZE_MSR_EE);
+microblaze_switch_reg |= MICROBLAZE_MSR_IE;
   } else {
-microblaze_switch_reg &= ~(MICROBLAZE_MSR_IE | MICROBLAZE_MSR_EE);
+microblaze_switch_reg &= ~(MICROBLAZE_MSR_IE);
   }
 
   _CPU_MSR_SET( microblaze_switch_reg );
@@ -158,7 +158,7 @@ uint32_t _CPU_ISR_Get_level( void )
 
   /* This is unique. The MSR register contains an interrupt enable flag where
* most other architectures have an interrupt disable flag. */
-  return ( level & (MICROBLAZE_MSR_IE | MICROBLAZE_MSR_EE) ) == 0;
+  return ( level & MICROBLAZE_MSR_IE ) == 0;
 }
 
 void _CPU_ISR_install_vector(
diff --git a/cpukit/score/cpu/microblaze/include/rtems/score/cpu.h 
b/cpukit/score/cpu/microblaze/include/rtems/score/cpu.h
index 5ca0609e91..181d247c5f 100644
--- a/cpukit/score/cpu/microblaze/include/rtems/score/cpu.h
+++ b/cpukit/score/cpu/microblaze/include/rtems/score/cpu.h
@@ -212,7 +212,7 @@ typedef struct {
   { \
 unsigned int _new_msr;  \
 _CPU_MSR_GET(_isr_cookie); \
-_new_msr = (_isr_cookie) & ~(MICROBLAZE_MSR_IE | MICROBLAZE_MSR_EE); \
+_new_msr = (_isr_cookie) & ~(MICROBLAZE_MSR_IE); \
 _CPU_MSR_SET(_new_msr); \
   }
 
@@ -221,9 +221,9 @@ typedef struct {
 uint32_t _microblaze_interrupt_enable; \
 uint32_t _microblaze_switch_reg; \
 \
-_microblaze_interrupt_enable = (_isr_cookie) & (MICROBLAZE_MSR_IE | 
MICROBLAZE_MSR_EE); \
+_microblaze_interrupt_enable = (_isr_cookie) & (MICROBLAZE_MSR_IE); \
 _CPU_MSR_GET(_microblaze_switch_reg); \
-_microblaze_switch_reg &= ~(MICROBLAZE_MSR_IE | MICROBLAZE_MSR_EE); \
+_microblaze_switch_reg &= ~(MICROBLAZE_MSR_IE); \
 _microblaze_switch_reg |= _microblaze_interrupt_enable; \
 _CPU_MSR_SET(_microblaze_switch_reg); \
   }
@@ -232,7 +232,7 @@ typedef struct {
   { \
 unsigned int _new_msr;  \
 _CPU_MSR_SET(_isr_cookie); \
-_new_msr = (_isr_cookie) & ~(MICROBLAZE_MSR_IE | MICROBLAZE_MSR_EE); \
+_new_msr = (_isr_cookie) & ~(MICROBLAZE_MSR_IE); \
 _CPU_MSR_SET(_new_msr); \
   }
 
@@ -242,7 +242,7 @@ uint32_t _CPU_ISR_Get_level( void );
 
 RTEMS_INLINE_ROUTINE bool _CPU_ISR_Is_enabled( uint32_t level )
 {
-  return ( level & (MICROBLAZE_MSR_IE | MICROBLAZE_MSR_EE) ) != 0;
+  return ( level & MICROBLAZE_MSR_IE ) != 0;
 }
 
 void _CPU_Context_Initialize(
-- 
2.30.2

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

[PATCH v3 4/5] cpukit/libdebugger: Avoid cascade for interrupts

2022-02-22 Thread Kinsey Moore 
This updates behavior of libdebugger to handle debug exceptions in
interrupt context by temporarily removing a software breakpoint,
stepping, and then resuming afterward.
---
 cpukit/libdebugger/rtems-debugger-target.c | 105 +++--
 cpukit/libdebugger/rtems-debugger-target.h |   5 +
 2 files changed, 104 insertions(+), 6 deletions(-)

diff --git a/cpukit/libdebugger/rtems-debugger-target.c 
b/cpukit/libdebugger/rtems-debugger-target.c
index c298a62357..2b55c93513 100644
--- a/cpukit/libdebugger/rtems-debugger-target.c
+++ b/cpukit/libdebugger/rtems-debugger-target.c
@@ -167,6 +167,32 @@ rtems_debugger_target_reg_table_size(void)
   return 0;
 }
 
+bool
+rtems_debugger_target_swbreak_is_configured( uintptr_t addr )
+{
+  size_t i;
+  rtems_debugger_target_swbreak *swbreaks;
+  rtems_debugger_target *target = rtems_debugger->target;
+
+  if ( target == NULL ) {
+return false;
+  }
+
+  swbreaks = target->swbreaks.block;
+
+  if ( swbreaks == NULL ) {
+return false;
+  }
+
+  for ( i = 0; i < target->swbreaks.level; ++i ) {
+if ( (uintptr_t) swbreaks[ i ].address == addr ) {
+  return true;
+}
+  }
+
+  return false;
+}
+
 int
 rtems_debugger_target_swbreak_control(bool insert, uintptr_t addr, DB_UINT 
kind)
 {
@@ -323,13 +349,81 @@ rtems_debugger_target_swbreak_remove(void)
   return r;
 }
 
+uintptr_t saved_break_address = 0;
+rtems_id saved_tid = 0;
+
+static rtems_debugger_target_exc_action
+soft_step_and_continue(CPU_Exception_frame* frame)
+{
+  uintptr_t  break_address;
+  rtems_debugger_target *target = rtems_debugger->target;
+  Thread_Control*thread = _Thread_Get_executing();
+  const rtems_id tid = thread->Object.id;
+  rtems_debugger_thread  fake_debugger_thread;
+
+  /*
+   * If this was a hwbreak, cascade. If this is a swbreak replace the contents
+   * of the instruction, step then return the swbreak's contents.
+   */
+  if ((target->capabilities & RTEMS_DEBUGGER_TARGET_CAP_SWBREAK) == 0) {
+target_printk("rtems-db: exception in an interrupt, cascading\n");
+rtems_debugger_unlock();
+return rtems_debugger_target_exc_cascade;
+  }
+
+  break_address = rtems_debugger_target_frame_pc( frame );
+  if ( rtems_debugger_target_swbreak_is_configured( break_address ) == false ) 
{
+target_printk("rtems-db: exception in an interrupt, cascading\n");
+rtems_debugger_unlock();
+return rtems_debugger_target_exc_cascade;
+  }
+
+  /* Remove the current breakpoint */
+  rtems_debugger_target_swbreak_control(
+false,
+break_address,
+target->breakpoint_size
+  );
+
+  /* Save off thread ID and break address for later usage */
+  saved_tid = tid;
+  saved_break_address = break_address;
+
+  /* Populate the fake rtems_debugger_thread */
+  fake_debugger_thread.flags |= RTEMS_DEBUGGER_THREAD_FLAG_STEP;
+  fake_debugger_thread.frame = frame;
+  target_printk("rtems-db: stepping to the next instruction\n");
+  rtems_debugger_target_thread_stepping(&fake_debugger_thread);
+
+  /* rtems_debugger_unlock() not called until the step is resolved */
+  return rtems_debugger_target_exc_step;
+}
+
 rtems_debugger_target_exc_action
 rtems_debugger_target_exception(CPU_Exception_frame* frame)
 {
+  Thread_Control* thread = _Thread_Get_executing();
+  const rtems_id  tid = thread->Object.id;
+
+  /* Resolve outstanding step+continue */
+  if ( saved_break_address != 0 && tid == saved_tid ) {
+rtems_debugger_target_swbreak_control(
+  true,
+  saved_break_address,
+  rtems_debugger->target->breakpoint_size
+);
+saved_break_address = saved_tid = 0;
+
+/* Release the debugger lock now that the step+continue is complete */
+target_printk("rtems-db: resuming after step\n");
+rtems_debugger_unlock();
+return rtems_debugger_target_exc_consumed;
+  }
+
+  rtems_debugger_lock();
+
   if (!rtems_interrupt_is_in_progress()) {
 rtems_debugger_threads*  threads = rtems_debugger->threads;
-Thread_Control*  thread = _Thread_Get_executing();
-const rtems_id   tid = thread->Object.id;
 rtems_id*excludes;
 uintptr_tpc;
 const rtems_debugger_thread_stepper* stepper;
@@ -340,8 +434,6 @@ rtems_debugger_target_exception(CPU_Exception_frame* frame)
   " frame:%08" PRIxPTR "\n",
   tid, (intptr_t) thread, (intptr_t) frame);
 
-rtems_debugger_lock();
-
 /*
  * If the thread is in the debugger recover. If the access is from gdb
  * continue else shutdown and let the user know.
@@ -430,9 +522,10 @@ rtems_debugger_target_exception(CPU_Exception_frame* frame)
 return rtems_debugger_target_exc_consumed;
   }
 
-  rtems_debugger_printf("rtems-db: exception in an interrupt, cascading\n");
+  target_printk("[} tid:%08" PRIx32 ": exception in interrupt context\n", tid);
 
-  return rtems_debugger_target_exc_casc

[PATCH v3 5/5] cpukit/libdebugger: Add MicroBlaze support

2022-02-22 Thread Kinsey Moore 
Add MicroBlaze support for libdebugger. This uses only software break
type instructions to provide self-hosted GDB debugging support for
applications since internal control of debug hardware is not possible.

Also of note, this implementation for MicroBlaze would typically use the
brki instruction for software break, but instead uses an illegal opcode
to manage software breaks as exceptions. This is due to poor interaction
with the debug hardware where the debug hardware will intercept software
breaks instead of allowing the software break vector to execute.
---
 .../libdebugger/rtems-debugger-microblaze.c   | 1393 +
 .../cpu/microblaze/include/rtems/score/cpu.h  |   24 +
 spec/build/cpukit/libdebugger.yml |2 +
 spec/build/cpukit/objdbgmicroblaze.yml|   15 +
 spec/build/cpukit/optlibdebugger.yml  |1 +
 5 files changed, 1435 insertions(+)
 create mode 100644 cpukit/libdebugger/rtems-debugger-microblaze.c
 create mode 100644 spec/build/cpukit/objdbgmicroblaze.yml

diff --git a/cpukit/libdebugger/rtems-debugger-microblaze.c 
b/cpukit/libdebugger/rtems-debugger-microblaze.c
new file mode 100644
index 00..377a731664
--- /dev/null
+++ b/cpukit/libdebugger/rtems-debugger-microblaze.c
@@ -0,0 +1,1393 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSLibdebugger
+ *
+ * @brief MicroBlaze libdebugger implementation
+ */
+
+/*
+ * Copyright (C) 2022 On-Line Applications Research Corporation (OAR)
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#define TARGET_DEBUG 0
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+#include 
+#include 
+
+/* Defined by linkcmds.base */
+extern char bsp_section_text_begin[];
+extern char bsp_section_text_end[];
+extern char bsp_section_fast_text_begin[];
+extern char bsp_section_fast_text_end[];
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "rtems-debugger-target.h"
+#include "rtems-debugger-threads.h"
+
+#if TARGET_DEBUG
+#include 
+#endif
+
+/*
+ * Number of registers.
+ */
+#define RTEMS_DEBUGGER_NUMREGS 57
+
+/*
+ * Number of bytes per type of register.
+ */
+#define RTEMS_DEBUGGER_REG_BYTES4
+
+/* Debugger registers layout. See microblaze-core.xml in GDB source. */
+#define REG_R00
+#define REG_R11
+#define REG_R22
+#define REG_R33
+#define REG_R44
+#define REG_R55
+#define REG_R66
+#define REG_R77
+#define REG_R88
+#define REG_R99
+#define REG_R10   10
+#define REG_R11   11
+#define REG_R12   12
+#define REG_R13   13
+#define REG_R14   14
+#define REG_R15   15
+#define REG_R16   16
+#define REG_R17   17
+#define REG_R18   18
+#define REG_R19   19
+#define REG_R20   20
+#define REG_R21   21
+#define REG_R22   22
+#define REG_R23   23
+#define REG_R24   24
+#define REG_R25   25
+#define REG_R26   26
+#define REG_R27   27
+#define REG_R28   28
+#define REG_R29   29
+#define REG_R30   30
+#define REG_R31   31
+#define REG_PC32
+#define REG_MS33
+#define REG_EA34
+#define REG_ES35
+#define REG_FS36
+#define REG_BT37
+#define REG_PV0   38
+#define REG_PV1   39
+#define REG_PV2   40
+#define REG_PV3   41
+#define REG_PV4   42
+#define REG_PV5   43
+#define REG_PV6   44
+#define REG_PV7   45
+#define REG_PV8   46
+#define REG_PV9   47
+#define REG_PV10  48
+#define REG_PV11  49
+#define REG_ED50
+#define REG_PID   51
+#define REG_ZP52
+#define REG_TBLX  53
+#define REG_TBLSX 54
+#define REG_TBLLO 55
+#define REG_TBLHI 56
+
+/**
+ * Register offset table with the total as the last entry.
+ *
+ * Check this table in gdb with the command:
+ *
+ *   maint print registers
+ */
+static const size_t microblaze_reg_offsets[

Re: [PATCH rtems-libbsd] ipsec-tools: Reduce allocated buffer size

2022-02-22 Thread Chris Johns 
OK and thanks

Chris

On 22/2/22 7:34 pm, Christian Mauderer wrote:
> By default, pfkey allocates a 2MB buffer that is used for SPD entries.
> This size is a good choice for a server system where a lot of clients
> should be handled. But on our embedded systems, an application with that
> much clients is unlikely and 2MB is a lot of space. So reduce that to
> the default value of 128kB which should be enough for a small number of
> ipsec connections.
> 
> See https://bugzilla.redhat.com/show_bug.cgi?id=607361 for more details
> why the upstream project originally increased the size.
> 
> If someone really needs a bigger size, there is a option in the
> configuration file of pfkey called `pfkey_buffer` that can overwrite
> this value.
> ---
>  ipsec-tools/src/libipsec/pfkey.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/ipsec-tools/src/libipsec/pfkey.c 
> b/ipsec-tools/src/libipsec/pfkey.c
> index 385a21a9..cc6ad816 100644
> --- a/ipsec-tools/src/libipsec/pfkey.c
> +++ b/ipsec-tools/src/libipsec/pfkey.c
> @@ -1836,8 +1836,18 @@ pfkey_open(void)
>   (void)setsockopt(so, SOL_SOCKET, SO_SNDBUF,
>   &bufsiz_wanted, sizeof(bufsiz_wanted));
>  
> +#ifndef __rtems__
>   /* Try to have have at least 2MB. If we have more, do not lower it. */
>   bufsiz_wanted = 2 * 1024 * 1024;
> +#else /* __rtems__ */
> + /*
> +  * The bufsize_wanted has an influence on the maximum number of SPDs. We
> +  * don't really need that much of them on an embedded system. If some
> +  * application really needs it, this can be overwritten with the
> +  * pfkey_buffer option in the config file.
> +  */
> + bufsiz_wanted = 128 * 1024;
> +#endif /* __rtems__ */
>   len = sizeof(bufsiz_current);
>   ret = getsockopt(so, SOL_SOCKET, SO_RCVBUF,
>   &bufsiz_current, &len);
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v3 0/5] Add MicroBlaze libdebugger support

2022-02-22 Thread Chris Johns 
Thanks for this and OK to merge and push.

Chris

On 23/2/22 9:06 am, Kinsey Moore wrote:
> Changes from v2:
> * Removed interrupt hooks in favor of step and continue behavior
> 
> 
> ___
> 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