Re: rtems-test not running tests for leon3

[Richi Dubey]

The test does not execute TEST_END() and exits just like that:
https://git.rtems.org/rtems/tree/testsuites/samples/minimum/init.c#n31,
hence it is always flagged as a failure in rtems-test.

On Wed, Mar 24, 2021 at 2:55 AM Chris Johns  wrote:

> On 24/3/21 1:18 am, Richi Dubey wrote:
> > Afaik minimum tests are supposed to fail.
>
> This is something I am not sure about. It is minimal by definition and as a
> result does not print anything so it is impossible to determine if the
> test runs
> of fails. As an example to show how small RTEMS can be it is fine however
> as a
> test in a strict theoretical sense it is like a cat in a box. Maybe it
> should
> flagged no run however if it does crash we will never know because we do
> not run
> it  and so we circle the loop.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] bsps/sparc: Remove INI files using SIS in GBD

[Chris Johns]

On 24/3/21 6:46 am, Gedare Bloom wrote:
> On Tue, Mar 23, 2021 at 1:45 PM Ryan Long  wrote:
>>
>> Removed the INI files that use the "target sim" option
>> since the SIS sparc simulator in GBD is no longer used
> GDB
> 
>> with RTEMS. A newer version of SIS is built seperately.
> while you're at it, separately
> 
> This can be pushed with the typo changes, also GDB in the first line
> of the commit msg.

  [ Just following up the discord chat ... ]

I am not so sure. This breaks the eco-system user interface the community may
depend on. If I wish to test the erc32 or leon2 then that is all I should use.
The original idea is the default or standard test name is the BSP name.

As discussed in discord the approach is not perfect because things change as
these patches show and it does not handle aliased BSPs (not sure how to handle
that). We need to find ways to handle these things.

I suggest we try the INI include support the rtemstoolkit provides to see if
these top level BSP test configs can reference the preferred implementation.

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

Re: rtems-test not running tests for leon3

[Chris Johns]

On 24/3/21 1:18 am, Richi Dubey wrote:
> Afaik minimum tests are supposed to fail.

This is something I am not sure about. It is minimal by definition and as a
result does not print anything so it is impossible to determine if the test runs
of fails. As an example to show how small RTEMS can be it is fine however as a
test in a strict theoretical sense it is like a cat in a box. Maybe it should
flagged no run however if it does crash we will never know because we do not run
it  and so we circle the loop.

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

Re: [PATCH rtems-docs v2] networking: Rename to legacy networking

[Vijay Kumar Banerjee]

On Tue, Mar 23, 2021 at 3:16 PM Chris Johns  wrote:
>
> On 24/3/21 7:08 am, Vijay Kumar Banerjee wrote:
> > Hi,
> >
> > Thanks for the review.
> >
> > On Tue, Mar 23, 2021 at 12:56 PM Joel Sherrill  wrote:
> >>
> >> I'm OK with this.
> >>
> >> Does this move the manual to near the bottom of the manual list?
> >>
> > No, it doesn't.
>
> The order is set by the order in this list ...
>
Hi Chris,

> https://git.rtems.org/rtems-docs/tree/wscript#n25
>
Thanks for the reference. I figured it out by trial-and-error and sent
a v3 of this patch.

Best regards,
Vijay

> This list us used to create the XML catalogue that is read downby the JS code
> loaded when you visit the web page.
>
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-docs v2] networking: Rename to legacy networking

[Chris Johns]

On 24/3/21 7:08 am, Vijay Kumar Banerjee wrote:
> Hi,
> 
> Thanks for the review.
> 
> On Tue, Mar 23, 2021 at 12:56 PM Joel Sherrill  wrote:
>>
>> I'm OK with this.
>>
>> Does this move the manual to near the bottom of the manual list?
>>
> No, it doesn't. 

The order is set by the order in this list ...

https://git.rtems.org/rtems-docs/tree/wscript#n25

This list us used to create the XML catalogue that is read downby the JS code
loaded when you visit the web page.

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

RTEMS Discord Server Available

[Joel Sherrill]

Hi

RTEMS now has a Discord server (https://discord.gg/6SrpDfBF).

Feel free to drop by and chat.

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

[PATCH v6] cpukit/aarch64: Add ESR register decoding

[Alex White]

---
 .../aarch64/aarch64-exception-frame-print.c   | 135 --
 1 file changed, 125 insertions(+), 10 deletions(-)

diff --git a/cpukit/score/cpu/aarch64/aarch64-exception-frame-print.c 
b/cpukit/score/cpu/aarch64/aarch64-exception-frame-print.c
index 59b5d06032..e207a5a81d 100644
--- a/cpukit/score/cpu/aarch64/aarch64-exception-frame-print.c
+++ b/cpukit/score/cpu/aarch64/aarch64-exception-frame-print.c
@@ -45,10 +45,113 @@
 #include 
 
 #include 
+#include 
 #include 
 
+typedef struct {
+   char *s;
+   size_t n;
+} String_Context;
+
+static void _CPU_Put_char( int c, void *arg )
+{
+  String_Context *sctx = arg;
+  size_t n = sctx->n;
+
+  if (n > 0) {
+char *s = sctx->s;
+*s = (char) c;
+sctx->s = s + 1;
+sctx->n = n - 1;
+  }
+}
+
+static void _CPU_Binary_sprintf(
+  char *s,
+  size_t maxlen,
+  uint32_t num_bits,
+  uint32_t value
+)
+{
+  String_Context sctx;
+  uint32_t mask;
+
+  sctx.s = s;
+  sctx.n = maxlen;
+
+  mask = 1 << (num_bits - 1);
+
+  while ( mask != 0 ) {
+_IO_Printf( _CPU_Put_char, , "%d", (value & mask ? 1 : 0) );
+mask >>= 1;
+  }
+
+  s[num_bits] = '\0';
+}
+
+static const char* _CPU_Exception_class_to_string( uint16_t exception_class )
+{
+  /* The 80 character limit is intentionally ignored for these strings. */
+  switch ( exception_class ) {
+case 0x01:
+  return "Trapped WFI or WFE instruction";
+case 0x03:
+  return "Trapped MCR or MRC access with (coproc==0b)";
+case 0x04:
+  return "Trapped MCRR or MRRC access with (coproc==0b)";
+case 0x05:
+  return "Trapped MCR or MRC access with (coproc==0b1110)";
+case 0x06:
+  return "Trapped LDC or STC access";
+case 0x0c:
+  return "Trapped MRRC access with (coproc==0b1110)";
+case 0x0e:
+  return "Illegal Execution state";
+case 0x18:
+  return "Trapped MSR, MRS, or System instruction";
+case 0x20:
+  return "Instruction Abort from a lower Exception level";
+case 0x21:
+  return "Instruction Abort taken without a change in Exception level";
+case 0x22:
+  return "PC alignment fault";
+case 0x24:
+  return "Data Abort from a lower Exception level";
+case 0x25:
+  return "Data Abort taken without a change in Exception level";
+case 0x26:
+  return "SP alignment fault";
+case 0x30:
+  return "Breakpoint exception from a lower Exception level";
+case 0x31:
+  return "Breakpoint exception taken without a change in Exception level";
+case 0x32:
+  return "Software Step exception from a lower Exception level";
+case 0x33:
+  return "Software Step exception taken without a change in Exception 
level";
+case 0x34:
+  return "Watchpoint exception from a lower Exception level";
+case 0x35:
+  return "Watchpoint exception taken without a change in Exception level";
+case 0x38:
+  return "BKPT instruction execution in AArch32 state";
+case 0x3c:
+  return "BRK instruction execution in AArch64 state";
+default:
+  return "Unknown";
+  }
+}
+
 void _CPU_Exception_frame_print( const CPU_Exception_frame *frame )
 {
+  uint32_t ec;
+  uint32_t il;
+  uint32_t iss;
+  char ec_str[7];
+  char iss_str[26];
+  int  i;
+  const uint128_t *qx;
+
   printk(
 "\n"
 "X0   = 0x%016" PRIx64  " X17  = 0x%016" PRIx64 "\n"
@@ -68,8 +171,7 @@ void _CPU_Exception_frame_print( const CPU_Exception_frame 
*frame )
 "X14  = 0x%016" PRIx64  " SP   = 0x%016" PRIxPTR "\n"
 "X15  = 0x%016" PRIx64  " PC   = 0x%016" PRIxPTR "\n"
 "X16  = 0x%016" PRIx64  " DAIF = 0x%016" PRIx64 "\n"
-"VEC  = 0x%016" PRIxPTR " CPSR = 0x%016" PRIx64 "\n"
-"ESR  = 0x%016" PRIx64  " FAR  = 0x%016" PRIx64 "\n",
+"VEC  = 0x%016" PRIxPTR " CPSR = 0x%016" PRIx64 "\n",
 frame->register_x0, frame->register_x17,
 frame->register_x1, frame->register_x18,
 frame->register_x2, frame->register_x19,
@@ -83,23 +185,36 @@ void _CPU_Exception_frame_print( const CPU_Exception_frame 
*frame )
 frame->register_x10, frame->register_x27,
 frame->register_x11, frame->register_x28,
 frame->register_x12, frame->register_fp,
-frame->register_x13, (intptr_t)frame->register_lr,
-frame->register_x14, (intptr_t)frame->register_sp,
-frame->register_x15, (intptr_t)frame->register_pc,
+frame->register_x13, (intptr_t) frame->register_lr,
+frame->register_x14, (intptr_t) frame->register_sp,
+frame->register_x15, (intptr_t) frame->register_pc,
 frame->register_x16, frame->register_daif,
-(intptr_t) frame->vector, frame->register_cpsr,
-frame->register_syndrome, frame->register_fault_address
+(intptr_t) frame->vector, frame->register_cpsr
   );
 
-  const uint128_t *qx = >register_q0;
-  int i;
+  ec = frame->register_syndrome >> 26 & 0x3f;
+  il = frame->register_syndrome >> 25 & 0x1;
+  iss = frame->register_syndrome & 0x1ff;
+
+  _CPU_Binary_sprintf( ec_str, sizeof( ec_str ), 

Re: Standalone repository for libnetworking stack

[Vijay Kumar Banerjee]

On Tue, Mar 23, 2021 at 1:10 PM Gedare Bloom  wrote:
>
> On Tue, Mar 23, 2021 at 12:34 PM Joel Sherrill  wrote:
> >
> >
> >
> > On Tue, Mar 23, 2021 at 11:27 AM Vijay Kumar Banerjee  
> > wrote:
> >>
> >> Hi,
> >>
> >> I have prepared and rebased all the patches to the current master. Please 
> >> review the commits.
> >>
> >> RTEMS patches: https://git.rtems.org/vijay/rtems.git/log/?h=devel-no-libnet
> >> RTEMS net-legacy patch to pull recent changes: 
> >> https://git.rtems.org/vijay/rtems-net-legacy.git/commit/?id=2b4738734f9d678a458b64278c0ff95dea588b1e
> >> RTEMS libbsd patch to add telnetd: 
> >> https://git.rtems.org/vijay/rtems-libbsd.git/commit/?id=6bda703964e8cbbf73cb21f52fb7ceeb3cb3a541
> >>
> >> With these patches, the relocation work would be complete. I have tested 
> >> all these patches are building with all the RTEMS bsps in bsp_defaults 
> >> using waf.
> >
> >
> > Great! Is there any reason not to move the repo to the top level and delete 
> > the networking from the main rtems repository?
> >
> It is: https://git.rtems.org/rtems-net-legacy/  -- I think he is
> asking to merge/update the repos. Vijay, I think you could send the
> net-legacy patch by itself to the list.
>
Thanks, sent it separately.

> I think  the big one is the RTEMS patches, and I'm not sure if the
> libbsd patches have been seen yet? @Vijay Can those be sent as an
> emailed patchset?
>
Sent just now. Thanks.

> > And to make a news announcements.
> >
> I think we had the announcement that it was pending, but yes it will
> be good to finalize that thread on the relevant mailing lists (users,
> EPICS-core). We think we hit most of the 'downstream' with those.
>
> > --joel
> >>
> >>
> >>
> >> Best regards,
> >> Vijay
> >>
> >>
> >> On Wed, Mar 10, 2021 at 11:43 AM Chris Johns  wrote:
> >>>
> >>>
> >>>
> >>> On 11/3/21 5:14 am, Joel Sherrill wrote:
> >>> >
> >>> >
> >>> > On Wed, Mar 10, 2021 at 11:48 AM Chris Johns  >>> > > wrote:
> >>> >
> >>> >
> >>> >
> >>> > On 11/3/21 1:11 am, Joel Sherrill wrote:
> >>> > > On Tue, Mar 9, 2021 at 11:00 PM Vijay Kumar Banerjee 
> >>> >  >>> > 
> >>> > > >> wrote:
> >>> > >
> >>> > > On Tue, Mar 9, 2021 at 9:56 PM Chris Johns  >>> > 
> >>> > > >> wrote:
> >>> > > >
> >>> > > > On 10/3/21 3:51 pm, Gedare Bloom wrote:
> >>> > > > > On Tue, Mar 9, 2021 at 6:58 PM Joel Sherrill 
> >>> >  >>> > 
> >>> > > >> wrote:
> >>> > > > >> On Tue, Mar 9, 2021, 3:28 PM Vijay Kumar Banerjee
> >>> > mailto:vi...@rtems.org>
> >>> > > >> wrote:
> >>> > > > >>> On Fri, Mar 5, 2021 at 10:03 AM Vijay Kumar Banerjee
> >>> > mailto:vi...@rtems.org>
> >>> > > >> wrote:
> >>> > > > >>> In this proposed set of patches, I have removed telnetd 
> >>> > from
> >>> > RTEMS and
> >>> > > > >>> have placed it in the net-legacy repo, it seems like 
> >>> > libbsd uses
> >>> > > > >>> telnetd as well. Do we want to keep it in RTEMS and 
> >>> > remove it
> >>> > from the
> >>> > > > >>> legacy net repo?  There are checks in for 
> >>> > RTEMS_NETWORKING in
> >>> > telnetd,
> >>> > > > >>> to add rtems_bsdnet.h, how do we want to deal with 
> >>> > that? In the
> >>> > legacy
> >>> > > > >>> repo, we can just remove these checks and let them 
> >>> > build.
> >>> > > > >>
> >>> > > > >>
> >>> > > > >> Move it and remove rtems networking conditional. Freezes 
> >>> > it with
> >>> > legacy
> >>> > > stack.
> >>> > > > >>
> >>> > > > >> Just my opinion
> >>> > > > >>
> >>> > > > > Is there a different telnetd in libbsd?
> >>> > > >
> >>> > > > Yes ...
> >>> > > >
> >>> > > > https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/telnetd
> >>> > 
> >>> > >  >>> > >
> >>> > > >
> >>> > > This seems to include rtems/telnetd.h
> >>> > > Does the libbsd telnetd depend on the cpukit/telnetd?
> >>> > >
> >>> > > > > The longer term pseudo-goal of being able to 
> >>> > (potentially) build
> >>> > > > > multiple networking stacks and pick which one to link 
> >>> > against may also
> >>> > > > > be a consideration at this stage.
> >>> > > >
> >>> > > > Are there issues? If there are issues do we know what they 
> >>> > are?
> >>> > >
> >>> > >
> >>> > > I guess the 

[PATCH rtems-libbsd] Import telnetd from RTEMS repository

[Vijay Kumar Banerjee]

The files have been taken from RTEMS repository with head commit at
bd9e45d91f77657445400bc2c814f251c9e37cef
---
 libbsd.py|  22 +-
 rtemsbsd/include/rtems/telnetd.h | 137 +
 rtemsbsd/telnetd/README  |  23 +
 rtemsbsd/telnetd/check_passwd.c  | 106 
 rtemsbsd/telnetd/des.c   | 873 +++
 rtemsbsd/telnetd/des.h   |   1 +
 rtemsbsd/telnetd/genpw.c |  79 +++
 rtemsbsd/telnetd/pty.c   | 401 ++
 rtemsbsd/telnetd/telnetd-init.c  |  18 +
 rtemsbsd/telnetd/telnetd.c   | 449 
 10 files changed, 2100 insertions(+), 9 deletions(-)
 create mode 100644 rtemsbsd/include/rtems/telnetd.h
 create mode 100644 rtemsbsd/telnetd/README
 create mode 100644 rtemsbsd/telnetd/check_passwd.c
 create mode 100644 rtemsbsd/telnetd/des.c
 create mode 100644 rtemsbsd/telnetd/des.h
 create mode 100644 rtemsbsd/telnetd/genpw.c
 create mode 100644 rtemsbsd/telnetd/pty.c
 create mode 100644 rtemsbsd/telnetd/telnetd-init.c
 create mode 100644 rtemsbsd/telnetd/telnetd.c

diff --git a/libbsd.py b/libbsd.py
index a2056f36..f7efda43 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -293,6 +293,12 @@ class rtems(builder.Module):
 'pppd/upap.c',
 'pppd/utils.c',
 'telnetd/telnetd-service.c',
+'telnetd/check_passwd.c',
+'telnetd/des.c',
+'telnetd/pty.c',
+'telnetd/genpw.c',
+'telnetd/telnetd-init.c',
+'telnetd/telnetd.c',
 ],
 mm.generator['source']()
 )
@@ -5368,8 +5374,7 @@ class tests(builder.Module):
 self.addTest(mm.generator['test']('arphole', ['test_main'],
   runTest = False, netTest = True))
 self.addTest(mm.generator['test']('telnetd01', ['test_main'],
-  runTest = False, netTest = True,
-  extraLibs = ['telnetd']))
+  runTest = False, netTest = True))
 self.addTest(mm.generator['test']('unix01', ['test_main']))
 self.addTest(mm.generator['test']('ftpd01', ['test_main'],
   netTest = True,
@@ -5397,27 +5402,26 @@ class tests(builder.Module):
 self.addTest(mm.generator['test']('mutex01', ['test_main']))
 self.addTest(mm.generator['test']('condvar01', ['test_main']))
 self.addTest(mm.generator['test']('ppp01', ['test_main'], runTest = 
False,
-  extraLibs = ['ftpd', 'telnetd']))
+  extraLibs = ['ftpd']))
 self.addTest(mm.generator['test']('zerocopy01', ['test_main'],
-  runTest = False, netTest = True,
-  extraLibs = ['telnetd']))
+  runTest = False, netTest = True))
 self.addTest(mm.generator['test']('smp01', ['test_main'], extraLibs = 
['rtemstest']))
 self.addTest(mm.generator['test']('media01', ['test_main'],
   runTest = False,
-  extraLibs = ['ftpd', 'telnetd']))
+  extraLibs = ['ftpd']))
 self.addTest(mm.generator['test']('mcast01', ['test_main']))
 self.addTest(mm.generator['test']('vlan01', ['test_main'], netTest = 
True))
 self.addTest(mm.generator['test']('lagg01', ['test_main'], netTest = 
True))
 self.addTest(mm.generator['test']('log01', ['test_main']))
 self.addTest(mm.generator['test']('rcconf01', ['test_main']))
 self.addTest(mm.generator['test']('rcconf02', ['test_main'],
-  extraLibs = ['ftpd', 'telnetd']))
+  extraLibs = ['ftpd']))
 self.addTest(mm.generator['test']('cdev01', ['test_main', 
'test_cdev']))
 self.addTest(mm.generator['test']('pf01', ['test_main'],
-  extraLibs = ['ftpd', 'telnetd']))
+  extraLibs = ['ftpd']))
 self.addTest(mm.generator['test']('pf02', ['test_main'],
   runTest = False,
-  extraLibs = ['ftpd', 'telnetd']))
+  extraLibs = ['ftpd']))
 self.addTest(mm.generator['test']('termios', ['test_main',
   'test_termios_driver',
   
'test_termios_utilities']))
diff --git a/rtemsbsd/include/rtems/telnetd.h b/rtemsbsd/include/rtems/telnetd.h
new file mode 100644
index ..1f8e1c55
--- /dev/null
+++ b/rtemsbsd/include/rtems/telnetd.h
@@ -0,0 +1,137 @@
+/*
+ *  

[PATCH rtems-net-legacy 2/2] greth.c: Pull RTEMS commit for variable size descriptor

[Vijay Kumar Banerjee]

RTEMS commit hash: 053b17ce8e3f710167e9ec3f44b37756cbdcbec0
---
 bsps/shared/grlib/net/greth.c | 22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/bsps/shared/grlib/net/greth.c b/bsps/shared/grlib/net/greth.c
index 8b19b48..84efcd7 100644
--- a/bsps/shared/grlib/net/greth.c
+++ b/bsps/shared/grlib/net/greth.c
@@ -187,6 +187,7 @@ struct greth_softc
unsigned int advmodes; /* advertise ethernet speed modes. 0 = all modes. */
struct timespec auto_neg_time;
int mc_available;
+   int num_descs;
 
/*
 * Statistics
@@ -423,7 +424,7 @@ greth_initialize_hardware (struct greth_softc *sc)
 int tmp2;
 struct timespec tstart, tnow;
 greth_regs *regs;
-unsigned int advmodes, speed;
+unsigned int advmodes, speed, tabsize;
 
 regs = sc->regs;
 
@@ -617,8 +618,9 @@ auto_neg_done:
 /* Initialize rx/tx descriptor table pointers. Due to alignment we 
  * always allocate maximum table size.
  */
-sc->txdesc = (greth_rxtxdesc *) almalloc(0x800, 0x400);
-sc->rxdesc = (greth_rxtxdesc *) >txdesc[128];
+tabsize = sc->num_descs * 8;
+sc->txdesc = (greth_rxtxdesc *) almalloc(tabsize * 2, tabsize);
+sc->rxdesc = (greth_rxtxdesc *) (tabsize + (void *)sc->txdesc);
 sc->tx_ptr = 0;
 sc->tx_dptr = 0;
 sc->tx_cnt = 0;
@@ -632,8 +634,8 @@ auto_neg_done:
 CPUMEM_TO_DMA,
 (void *)sc->txdesc,
 (void **)>txdesc_remote,
-0x800);
-sc->rxdesc_remote = sc->txdesc_remote + 0x400;
+tabsize * 2);
+sc->rxdesc_remote = sc->txdesc_remote + tabsize;
 regs->txdesc = (int) sc->txdesc_remote;
 regs->rxdesc = (int) sc->rxdesc_remote;
 
@@ -1555,6 +1557,7 @@ int greth_device_init(struct greth_softc *sc)
 struct ambapp_core *pnpinfo;
 union drvmgr_key_value *value;
 unsigned int speed;
+int i, nrd;
 
 /* Get device information from AMBA PnP information */
 ambadev = (struct amba_dev_info *)sc->dev->businfo;
@@ -1608,12 +1611,17 @@ int greth_device_init(struct greth_softc *sc)
 sc->rxbufs = 32;
 sc->phyaddr = -1;
 
+/* Probe the number of descriptors available the */
+nrd = (sc->regs->status & GRETH_STATUS_NRD) >> 24;
+for (sc->num_descs = 128, i = 0; i < nrd; i++)
+sc->num_descs = sc->num_descs * 2;
+
 value = drvmgr_dev_key_get(sc->dev, "txDescs", DRVMGR_KT_INT);
-if ( value && (value->i <= 128) )
+if ( value && (value->i <= sc->num_descs) )
 sc->txbufs = value->i;
 
 value = drvmgr_dev_key_get(sc->dev, "rxDescs", DRVMGR_KT_INT);
-if ( value && (value->i <= 128) )
+if ( value && (value->i <= sc->num_descs) )
 sc->rxbufs = value->i;
 
 value = drvmgr_dev_key_get(sc->dev, "phyAdr", DRVMGR_KT_INT);
-- 
2.26.2

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

[PATCH rtems-net-legacy 1/2] Remove RTEMS_NETWORKING checks

[Vijay Kumar Banerjee]

* Remove nfsclient wscript and build from netlegacy.py
---
 bsps/powerpc/mpc55xxevb/net/smsc9218i.c |  4 +--
 libmisc/dummy-networking.c  | 44 -
 netlegacy.py| 17 +-
 nfsclient/wscript   |  1 +
 telnetd/telnetd.c   |  4 ---
 wscript |  2 +-
 6 files changed, 41 insertions(+), 31 deletions(-)

diff --git a/bsps/powerpc/mpc55xxevb/net/smsc9218i.c 
b/bsps/powerpc/mpc55xxevb/net/smsc9218i.c
index d88aa8a..384f9cd 100644
--- a/bsps/powerpc/mpc55xxevb/net/smsc9218i.c
+++ b/bsps/powerpc/mpc55xxevb/net/smsc9218i.c
@@ -24,7 +24,7 @@
 
 #include 
 
-#if defined(RTEMS_NETWORKING) && defined(MPC55XX_HAS_SIU)
+#if defined(MPC55XX_HAS_SIU)
 
 #include 
 
@@ -2121,4 +2121,4 @@ int smsc9218i_attach_detach(
   return 0;
 }
 
-#endif /* defined(RTEMS_NETWORKING) && defined(MPC55XX_HAS_SIU) */
+#endif /* defined(MPC55XX_HAS_SIU) */
diff --git a/libmisc/dummy-networking.c b/libmisc/dummy-networking.c
index 379e23e..b7f15c8 100644
--- a/libmisc/dummy-networking.c
+++ b/libmisc/dummy-networking.c
@@ -16,27 +16,25 @@
 #include 
 
 /* Loopback Network Configuration */
-#if defined(RTEMS_NETWORKING)
-  #include 
-  #include 
-  #include 
+#include 
+#include 
+#include 
 
-  struct rtems_bsdnet_config rtems_bsdnet_config = {
-  NULL,   /* Network interface */
-  NULL,   /* Use fixed network configuration */
-  0,  /* Default network task priority */
-  0,  /* Default mbuf capacity */
-  0,  /* Default mbuf cluster capacity */
-  "testSystem",   /* Host name */
-  "nowhere.com",  /* Domain name */
-  "127.0.0.1",/* Gateway */
-  "127.0.0.1",/* Log host */
-  {"127.0.0.1" }, /* Name server(s) */
-  {"127.0.0.1" }, /* NTP server(s) */
-  1,  /* sb_efficiency */
-  0,  /* udp_tx_buf_size */
-  0,  /* udp_rx_buf_size */
-  0,  /* tcp_tx_buf_size */
-  0   /* tcp_rx_buf_size */
-  };
-#endif
+struct rtems_bsdnet_config rtems_bsdnet_config = {
+NULL,   /* Network interface */
+NULL,   /* Use fixed network configuration */
+0,  /* Default network task priority */
+0,  /* Default mbuf capacity */
+0,  /* Default mbuf cluster capacity */
+"testSystem",   /* Host name */
+"nowhere.com",  /* Domain name */
+"127.0.0.1",/* Gateway */
+"127.0.0.1",/* Log host */
+{"127.0.0.1" }, /* Name server(s) */
+{"127.0.0.1" }, /* NTP server(s) */
+1,  /* sb_efficiency */
+0,  /* udp_tx_buf_size */
+0,  /* udp_rx_buf_size */
+0,  /* tcp_tx_buf_size */
+0   /* tcp_rx_buf_size */
+};
diff --git a/netlegacy.py b/netlegacy.py
index 0889548..0e69076 100644
--- a/netlegacy.py
+++ b/netlegacy.py
@@ -54,6 +54,12 @@ def build(bld):
for s in os.listdir('./pppd') if s[-2:] == '.c']
 telnetd_source = [os.path.join('./telnetd', s)
   for s in os.listdir('telnetd') if s[-2:] == '.c']
+nfs_source = []
+for root, dirs, files in os.walk('./nfsclient'):
+for name in files:
+if name[-2:] == '.c':
+src_root = root.split('/')[2]
+nfs_source.append(os.path.join('./nfsclient', src_root, name))
 
 bsp_dirs, bsp_sources = bsp_drivers.bsp_files(bld)
 
@@ -66,6 +72,7 @@ def build(bld):
  './bsps/include'])
 arch_lib_path = rtems.arch_bsp_lib_path(bld.env.RTEMS_VERSION,
 bld.env.RTEMS_ARCH_BSP)
+lib_path = os.path.join(bld.env.PREFIX, arch_lib_path)
 include_path.append(os.path.relpath(os.path.join(bld.env.PREFIX,
  arch_lib_path)))
 include_path.append(os.path.relpath(os.path.join(bld.env.PREFIX,
@@ -73,6 +80,8 @@ def build(bld):
  'include')))
 include_path.append('./bsps/include/libchip')
 
+bld.read_stlib('rtemsbsp', paths=[lib_path])
+
 if bsp in bsp_dirs:
 include_path.extend(bsp_dirs[bsp])
 
@@ -107,8 +116,14 @@ def build(bld):
   use='networking',
   source=telnetd_source)
 
+bld.stlib(target='nfs',
+  features='c',
+  includes=ip,
+  use=['rtemsbsp', 'networking'],
+  source=nfs_source)
+
 bld.install_files(os.path.join('${PREFIX}', arch_lib_path),
-  ["libnetworking.a", 'libpppd.a', 'libtelnetd.a'])
+

Re: [PATCH rtems-docs v2] networking: Rename to legacy networking

[Vijay Kumar Banerjee]

Hi,

Thanks for the review.

On Tue, Mar 23, 2021 at 12:56 PM Joel Sherrill  wrote:
>
> I'm OK with this.
>
> Does this move the manual to near the bottom of the manual list?
>
No, it doesn't. I just sent a v3 to add this. I have also sent a patch
to fix the docs build for python 3.5 and up.

> I suspect some content is needed somewhere in the Users Guide
> to point out how you have a choice of network stacks and building
> one of them. Beyond this patch but looking forward, we have some
> explaining to do.
>
Yes, I'm planning to write documentation about the different network
stack available in rtems and how would a user select between them.
This can be a section in the user manual.

Best regards,
Vijay
> --joel
>
> On Tue, Mar 23, 2021 at 1:48 PM Vijay Kumar Banerjee  wrote:
>>
>> Ping :)
>>
>> On Tue, Mar 9, 2021 at 9:59 AM Vijay Kumar Banerjee  wrote:
>> >
>> > ---
>> >  book/index_book.rst   | 2 +-
>> >  {networking => legacy-networking}/command.rst | 0
>> >  {networking => legacy-networking}/conf.py | 4 ++--
>> >  {networking => legacy-networking}/dec_21140.rst   | 0
>> >  {networking => legacy-networking}/index.rst   | 2 +-
>> >  {networking => legacy-networking}/network_servers.rst | 0
>> >  {networking => legacy-networking}/network_task_structure.rst  | 0
>> >  {networking => legacy-networking}/networking_driver.rst   | 0
>> >  {networking => legacy-networking}/preface.rst | 0
>> >  {networking => legacy-networking}/testing_the_driver.rst  | 0
>> >  .../using_networking_rtems_app.rst| 0
>> >  {networking => legacy-networking}/wscript | 0
>> >  wscript   | 2 +-
>> >  13 files changed, 5 insertions(+), 5 deletions(-)
>> >  rename {networking => legacy-networking}/command.rst (100%)
>> >  rename {networking => legacy-networking}/conf.py (68%)
>> >  rename {networking => legacy-networking}/dec_21140.rst (100%)
>> >  rename {networking => legacy-networking}/index.rst (92%)
>> >  rename {networking => legacy-networking}/network_servers.rst (100%)
>> >  rename {networking => legacy-networking}/network_task_structure.rst (100%)
>> >  rename {networking => legacy-networking}/networking_driver.rst (100%)
>> >  rename {networking => legacy-networking}/preface.rst (100%)
>> >  rename {networking => legacy-networking}/testing_the_driver.rst (100%)
>> >  rename {networking => legacy-networking}/using_networking_rtems_app.rst 
>> > (100%)
>> >  rename {networking => legacy-networking}/wscript (100%)
>> >
>> > diff --git a/book/index_book.rst b/book/index_book.rst
>> > index 8282006..3fc67d2 100644
>> > --- a/book/index_book.rst
>> > +++ b/book/index_book.rst
>> > @@ -23,7 +23,7 @@ Table of Contents
>> > cpu_supplement/index.rst
>> > develenv/index.rst
>> > filesystem/index.rst
>> > -   networking/index.rst
>> > +   legacy_networking/index.rst
>> > porting/index.rst
>> > posix1003_1/index.rst
>> > posix_users/index.rst
>> > diff --git a/networking/command.rst b/legacy-networking/command.rst
>> > similarity index 100%
>> > rename from networking/command.rst
>> > rename to legacy-networking/command.rst
>> > diff --git a/networking/conf.py b/legacy-networking/conf.py
>> > similarity index 68%
>> > rename from networking/conf.py
>> > rename to legacy-networking/conf.py
>> > index 1c129bc..6cc01bc 100644
>> > --- a/networking/conf.py
>> > +++ b/legacy-networking/conf.py
>> > @@ -3,12 +3,12 @@ sys.path.insert(0, os.path.abspath('../common/'))
>> >
>> >  from conf import *
>> >
>> > -project = "RTEMS Networking User Manual"
>> > +project = "RTEMS Legacy Networking User Manual"
>> >
>> >  latex_documents = [
>> >  ('index',
>> >   'networking.tex',
>> > - u'RTEMS Networking User Manual',
>> > + u'RTEMS Legacy Networking User Manual',
>> >   u'RTEMS Documentation Project',
>> >   'manual'),
>> >  ]
>> > diff --git a/networking/dec_21140.rst b/legacy-networking/dec_21140.rst
>> > similarity index 100%
>> > rename from networking/dec_21140.rst
>> > rename to legacy-networking/dec_21140.rst
>> > diff --git a/networking/index.rst b/legacy-networking/index.rst
>> > similarity index 92%
>> > rename from networking/index.rst
>> > rename to legacy-networking/index.rst
>> > index f56a60d..b85119d 100644
>> > --- a/networking/index.rst
>> > +++ b/legacy-networking/index.rst
>> > @@ -5,7 +5,7 @@
>> >  .. highlight:: c
>> >
>> >  ==
>> > -RTEMS Network User Manual (|version|).
>> > +RTEMS Legacy Network User Manual (|version|).
>> >  ==
>> >
>> >  .. topic:: Copyrights and License
>> > diff --git a/networking/network_servers.rst 
>> > b/legacy-networking/network_servers.rst
>> > similarity index 100%
>> > rename from networking/network_servers.rst
>> > 

[PATCH rtems-docs] common/latex.py: use distro module for python3.5 and up

[Vijay Kumar Banerjee]

---
 common/latex.py | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/common/latex.py b/common/latex.py
index a042510..a1b3917 100644
--- a/common/latex.py
+++ b/common/latex.py
@@ -3,8 +3,11 @@
 #
 
 import os
-import platform
 import re
+try:
+from distro import linux_distribution
+except:
+from platform import linux_distribution
 
 package_test_preamble = ['\\newif\\ifsphinxKeepOldNames 
\\sphinxKeepOldNamestrue',
  '\documentclass[a4paper,11pt,english]{report}']
@@ -82,7 +85,7 @@ def tex_test(test):
 def host_name():
 uname = os.uname()
 if uname[0] == 'Linux':
-distro = platform.dist()
+distro = linux_distribution()
 name = '%s/%s' % (uname[0], distro[0])
 version = distro[1]
 else:
-- 
2.26.2

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

[PATCH rtems-docs v3] networking: Rename to legacy networking

[Vijay Kumar Banerjee]

---
 book/index_book.rst | 2 +-
 {networking => legacy-networking}/command.rst   | 0
 {networking => legacy-networking}/conf.py   | 6 +++---
 {networking => legacy-networking}/dec_21140.rst | 0
 {networking => legacy-networking}/index.rst | 2 +-
 {networking => legacy-networking}/network_servers.rst   | 0
 .../network_task_structure.rst  | 0
 {networking => legacy-networking}/networking_driver.rst | 0
 {networking => legacy-networking}/preface.rst   | 0
 {networking => legacy-networking}/testing_the_driver.rst| 0
 .../using_networking_rtems_app.rst  | 0
 {networking => legacy-networking}/wscript   | 0
 wscript | 4 ++--
 13 files changed, 7 insertions(+), 7 deletions(-)
 rename {networking => legacy-networking}/command.rst (100%)
 rename {networking => legacy-networking}/conf.py (58%)
 rename {networking => legacy-networking}/dec_21140.rst (100%)
 rename {networking => legacy-networking}/index.rst (92%)
 rename {networking => legacy-networking}/network_servers.rst (100%)
 rename {networking => legacy-networking}/network_task_structure.rst (100%)
 rename {networking => legacy-networking}/networking_driver.rst (100%)
 rename {networking => legacy-networking}/preface.rst (100%)
 rename {networking => legacy-networking}/testing_the_driver.rst (100%)
 rename {networking => legacy-networking}/using_networking_rtems_app.rst (100%)
 rename {networking => legacy-networking}/wscript (100%)

diff --git a/book/index_book.rst b/book/index_book.rst
index 8282006..afe15a1 100644
--- a/book/index_book.rst
+++ b/book/index_book.rst
@@ -23,7 +23,7 @@ Table of Contents
cpu_supplement/index.rst
develenv/index.rst
filesystem/index.rst
-   networking/index.rst
porting/index.rst
posix1003_1/index.rst
posix_users/index.rst
+   legacy_networking/index.rst
diff --git a/networking/command.rst b/legacy-networking/command.rst
similarity index 100%
rename from networking/command.rst
rename to legacy-networking/command.rst
diff --git a/networking/conf.py b/legacy-networking/conf.py
similarity index 58%
rename from networking/conf.py
rename to legacy-networking/conf.py
index 1c129bc..98a06b6 100644
--- a/networking/conf.py
+++ b/legacy-networking/conf.py
@@ -3,12 +3,12 @@ sys.path.insert(0, os.path.abspath('../common/'))
 
 from conf import *
 
-project = "RTEMS Networking User Manual"
+project = "RTEMS Legacy Networking User Manual"
 
 latex_documents = [
 ('index',
- 'networking.tex',
- u'RTEMS Networking User Manual',
+ 'legacy-networking.tex',
+ u'RTEMS Legacy Networking User Manual',
  u'RTEMS Documentation Project',
  'manual'),
 ]
diff --git a/networking/dec_21140.rst b/legacy-networking/dec_21140.rst
similarity index 100%
rename from networking/dec_21140.rst
rename to legacy-networking/dec_21140.rst
diff --git a/networking/index.rst b/legacy-networking/index.rst
similarity index 92%
rename from networking/index.rst
rename to legacy-networking/index.rst
index f56a60d..b85119d 100644
--- a/networking/index.rst
+++ b/legacy-networking/index.rst
@@ -5,7 +5,7 @@
 .. highlight:: c
 
 ==
-RTEMS Network User Manual (|version|).
+RTEMS Legacy Network User Manual (|version|).
 ==
 
 .. topic:: Copyrights and License
diff --git a/networking/network_servers.rst 
b/legacy-networking/network_servers.rst
similarity index 100%
rename from networking/network_servers.rst
rename to legacy-networking/network_servers.rst
diff --git a/networking/network_task_structure.rst 
b/legacy-networking/network_task_structure.rst
similarity index 100%
rename from networking/network_task_structure.rst
rename to legacy-networking/network_task_structure.rst
diff --git a/networking/networking_driver.rst 
b/legacy-networking/networking_driver.rst
similarity index 100%
rename from networking/networking_driver.rst
rename to legacy-networking/networking_driver.rst
diff --git a/networking/preface.rst b/legacy-networking/preface.rst
similarity index 100%
rename from networking/preface.rst
rename to legacy-networking/preface.rst
diff --git a/networking/testing_the_driver.rst 
b/legacy-networking/testing_the_driver.rst
similarity index 100%
rename from networking/testing_the_driver.rst
rename to legacy-networking/testing_the_driver.rst
diff --git a/networking/using_networking_rtems_app.rst 
b/legacy-networking/using_networking_rtems_app.rst
similarity index 100%
rename from networking/using_networking_rtems_app.rst
rename to legacy-networking/using_networking_rtems_app.rst
diff --git a/networking/wscript b/legacy-networking/wscript
similarity index 100%
rename from networking/wscript
rename to legacy-networking/wscript
diff --git a/wscript b/wscript
index ce644f8..0b1c368 100644
--- 

Re: [PATCH v2] bsps/sparc: Remove INI files using SIS in GBD

[Gedare Bloom]

On Tue, Mar 23, 2021 at 1:45 PM Ryan Long  wrote:
>
> Removed the INI files that use the "target sim" option
> since the SIS sparc simulator in GBD is no longer used
GDB

> with RTEMS. A newer version of SIS is built seperately.
while you're at it, separately

This can be pushed with the typo changes, also GDB in the first line
of the commit msg.
>
> Closes #4355
> ---
>  tester/rtems/testing/bsps/erc32.ini | 41 
> -
>  tester/rtems/testing/bsps/leon2.ini | 41 
> -
>  tester/rtems/testing/bsps/leon3.ini | 41 
> -
>  3 files changed, 123 deletions(-)
>  delete mode 100644 tester/rtems/testing/bsps/erc32.ini
>  delete mode 100644 tester/rtems/testing/bsps/leon2.ini
>  delete mode 100644 tester/rtems/testing/bsps/leon3.ini
>
> diff --git a/tester/rtems/testing/bsps/erc32.ini 
> b/tester/rtems/testing/bsps/erc32.ini
> deleted file mode 100644
> index 7911a2f..000
> --- a/tester/rtems/testing/bsps/erc32.ini
> +++ /dev/null
> @@ -1,41 +0,0 @@
> -#
> -# RTEMS Tools Project (http://www.rtems.org/)
> -# Copyright 2015 On-Line Applications Research Corporation (OAR).
> -# All rights reserved.
> -#
> -# This file is part of the RTEMS Tools package in 'rtems-tools'.
> -#
> -# Redistribution and use in source and binary forms, with or without
> -# modification, are permitted provided that the following conditions are met:
> -#
> -# 1. Redistributions of source code must retain the above copyright notice,
> -# this list of conditions and the following disclaimer.
> -#
> -# 2. Redistributions in binary form must reproduce the above copyright 
> notice,
> -# this list of conditions and the following disclaimer in the documentation
> -# and/or other materials provided with the distribution.
> -#
> -# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
> -# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> -# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> -# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
> -# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> -# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> -# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> -# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> -# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> -# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> -# POSSIBILITY OF SUCH DAMAGE.
> -#
> -
> -#
> -# The erc32 BSP
> -#
> -[erc32]
> -bsp= erc32
> -arch   = sparc
> -tester = %{_rtscripts}/gdb.cfg
> -gdb_script = bsp_gdb_script
> -bsp_gdb_script = target sim
> - load
> - run
> diff --git a/tester/rtems/testing/bsps/leon2.ini 
> b/tester/rtems/testing/bsps/leon2.ini
> deleted file mode 100644
> index 77fed49..000
> --- a/tester/rtems/testing/bsps/leon2.ini
> +++ /dev/null
> @@ -1,41 +0,0 @@
> -#
> -# RTEMS Tools Project (http://www.rtems.org/)
> -# Copyright 2015 On-Line Applications Research Corporation (OAR).
> -# All rights reserved.
> -#
> -# This file is part of the RTEMS Tools package in 'rtems-tools'.
> -#
> -# Redistribution and use in source and binary forms, with or without
> -# modification, are permitted provided that the following conditions are met:
> -#
> -# 1. Redistributions of source code must retain the above copyright notice,
> -# this list of conditions and the following disclaimer.
> -#
> -# 2. Redistributions in binary form must reproduce the above copyright 
> notice,
> -# this list of conditions and the following disclaimer in the documentation
> -# and/or other materials provided with the distribution.
> -#
> -# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
> -# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> -# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> -# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
> -# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> -# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> -# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> -# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> -# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> -# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> -# POSSIBILITY OF SUCH DAMAGE.
> -#
> -
> -#
> -# The leon2 BSP
> -#
> -[leon2]
> -bsp= leon2
> -arch   = sparc
> -tester = %{_rtscripts}/gdb.cfg
> -gdb_script = bsp_gdb_script
> -bsp_gdb_script = target sim -leon2
> - load
> - run
> diff --git a/tester/rtems/testing/bsps/leon3.ini 
> 

[PATCH v2] bsps/sparc: Remove INI files using SIS in GBD

[Ryan Long]

Removed the INI files that use the "target sim" option
since the SIS sparc simulator in GBD is no longer used
with RTEMS. A newer version of SIS is built seperately.

Closes #4355
---
 tester/rtems/testing/bsps/erc32.ini | 41 -
 tester/rtems/testing/bsps/leon2.ini | 41 -
 tester/rtems/testing/bsps/leon3.ini | 41 -
 3 files changed, 123 deletions(-)
 delete mode 100644 tester/rtems/testing/bsps/erc32.ini
 delete mode 100644 tester/rtems/testing/bsps/leon2.ini
 delete mode 100644 tester/rtems/testing/bsps/leon3.ini

diff --git a/tester/rtems/testing/bsps/erc32.ini 
b/tester/rtems/testing/bsps/erc32.ini
deleted file mode 100644
index 7911a2f..000
--- a/tester/rtems/testing/bsps/erc32.ini
+++ /dev/null
@@ -1,41 +0,0 @@
-#
-# RTEMS Tools Project (http://www.rtems.org/)
-# Copyright 2015 On-Line Applications Research Corporation (OAR).
-# All rights reserved.
-#
-# This file is part of the RTEMS Tools package in 'rtems-tools'.
-#
-# Redistribution and use in source and binary forms, with or without
-# modification, are permitted provided that the following conditions are met:
-#
-# 1. Redistributions of source code must retain the above copyright notice,
-# this list of conditions and the following disclaimer.
-#
-# 2. Redistributions in binary form must reproduce the above copyright notice,
-# this list of conditions and the following disclaimer in the documentation
-# and/or other materials provided with the distribution.
-#
-# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
-# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
-# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
-# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
-# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
-# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
-# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
-# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
-# POSSIBILITY OF SUCH DAMAGE.
-#
-
-#
-# The erc32 BSP
-#
-[erc32]
-bsp= erc32
-arch   = sparc
-tester = %{_rtscripts}/gdb.cfg
-gdb_script = bsp_gdb_script
-bsp_gdb_script = target sim
- load
- run
diff --git a/tester/rtems/testing/bsps/leon2.ini 
b/tester/rtems/testing/bsps/leon2.ini
deleted file mode 100644
index 77fed49..000
--- a/tester/rtems/testing/bsps/leon2.ini
+++ /dev/null
@@ -1,41 +0,0 @@
-#
-# RTEMS Tools Project (http://www.rtems.org/)
-# Copyright 2015 On-Line Applications Research Corporation (OAR).
-# All rights reserved.
-#
-# This file is part of the RTEMS Tools package in 'rtems-tools'.
-#
-# Redistribution and use in source and binary forms, with or without
-# modification, are permitted provided that the following conditions are met:
-#
-# 1. Redistributions of source code must retain the above copyright notice,
-# this list of conditions and the following disclaimer.
-#
-# 2. Redistributions in binary form must reproduce the above copyright notice,
-# this list of conditions and the following disclaimer in the documentation
-# and/or other materials provided with the distribution.
-#
-# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
-# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
-# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
-# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
-# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
-# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
-# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
-# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
-# POSSIBILITY OF SUCH DAMAGE.
-#
-
-#
-# The leon2 BSP
-#
-[leon2]
-bsp= leon2
-arch   = sparc
-tester = %{_rtscripts}/gdb.cfg
-gdb_script = bsp_gdb_script
-bsp_gdb_script = target sim -leon2
- load
- run
diff --git a/tester/rtems/testing/bsps/leon3.ini 
b/tester/rtems/testing/bsps/leon3.ini
deleted file mode 100644
index 74eafb7..000
--- a/tester/rtems/testing/bsps/leon3.ini
+++ /dev/null
@@ -1,41 +0,0 @@
-#
-# RTEMS Tools Project (http://www.rtems.org/)
-# Copyright 2015 On-Line Applications Research Corporation (OAR).
-# All rights reserved.
-#
-# This file is part of the RTEMS Tools package in 'rtems-tools'.
-#
-# Redistribution and use in source and 

Re: [PATCH 1/2] Added FAQ page

[Gedare Bloom]

Did you build the docs and verify they look good?

On Tue, Mar 23, 2021 at 12:44 PM Ayushman Mishra
 wrote:
>
> ---
>  user/bld/index.rst   |   4 +-
>  user/overview/index.rst  |   2 +
>  user/start/faq.rst   | 255 +++
>  user/start/index.rst |   1 +
>  user/support/support-project.rst |   2 +
>  5 files changed, 263 insertions(+), 1 deletion(-)
>  create mode 100644 user/start/faq.rst
>
> diff --git a/user/bld/index.rst b/user/bld/index.rst
> index ebedf5a..a8a8a4f 100644
> --- a/user/bld/index.rst
> +++ b/user/bld/index.rst
> @@ -82,7 +82,7 @@ specifies paths to build specification items.  It is an 
> advanced option and
>  there is normally no need to use it.  It may be used to customize the build 
> at
>  the level of the build specification.  For more information see the
>  `Build System` chapter of the
> -`RTEMS Software Engineering 
> `_
> +`RTEMS Software Engineering 
> `_
>  guide.
>
>  Help
> @@ -283,6 +283,8 @@ example configuration file, building of the tests is 
> enabled for the
>  [sparc/erc32]
>
>  [riscv/griscv]
> +
> +.. _Autoconf_migration:
this looks like something should be a cleanup separate submission.

I think the tags are usually directly translated from the section
names with camelcase?
_Migration_from_AutoconfAutomake
or so? check other docs for consistency/guidance.

>
>  Migration from Autoconf/Automake
>  
> diff --git a/user/overview/index.rst b/user/overview/index.rst
> index 550724a..0703ede 100644
> --- a/user/overview/index.rst
> +++ b/user/overview/index.rst
> @@ -20,6 +20,8 @@ You are someone looking for a real-time operating system.  
> This document
>
>  - helps you to build an example application on top of RTEMS.
>
> +.. _Features:
> +
>  Features
>  
>
> diff --git a/user/start/faq.rst b/user/start/faq.rst
> new file mode 100644
> index 000..da11ca4
> --- /dev/null
> +++ b/user/start/faq.rst
> @@ -0,0 +1,255 @@
> +Frequently Asked Questions
> +==
> +
> +What is RTEMS ?
> +---
> +
> +RTEMS is an open source real-time executive which provides a high performance
> +environment for embedded real-time applications including many features.
> +
> +The RTEMS Project is the umbrella term used to describe the collection of
> +individuals, companies, universities, and research institutions that 
> collectively
> +maintain and enhance the RTEMS software base.
> +
> +RTEMS is designed to support applications with the most stringent real-time
> +requirements while being compatible with open standards such as POSIX.
> +RTEMS includes optional functional features such as TCP/IP and various file
> +systems while still offering minimum executable sizes under 20 KB in useful
> +configurations.
> +
> +:ref:`More Features`
> +
> +Where can I get RTEMS ?
> +-
> +
> +:ref:`Downloading RTEMS`
> +
> +
> +What does RTEMS stand for ?
> +-
> +
> +RTEMS is an an acronym for the Real-Time Executive for Multiprocessor 
> Systems.
an an

> +
> +Initially RTEMS stood for the Real-Time Executive for Missile Systems but as 
> it
> +became clear that the application domains that could use RTEMS extended far
> +beyond missiles, the "M" changed to mean Military. When maintenance of RTEMS
> +transferred to OAR, the "M" was changed again to Multiprocessor.
> +
> +At one point, there were both Ada and C implementations of RTEMS.
> +Version 3.2.1 was the last RTEMS version to have implementations in both
> +languages. Supporting the Classic API Ada implementation was painful and 
> fraught
> +with compiler specific pitfalls. With version 3.5.x, the POSIX API was added 
> as
> +the means to support the GNU Ada Translator (GNAT). This effectively 
> eliminated
> +the need for an implementation in Ada as the C implementation could 
> effectively
> +support both languages.
> +
> +
> +Are there restrictions on the RTEMS License ?
> +
> +
> +RTEMS is licensed under a modified version of the GNU General Public License 
> (GPL).
> +The modification places no restrictions on the applications which use RTEMS 
> but
> +protects the interests of those who work on RTEMS.
> +
This needs to be updated at least to mention 2-clause BSD.

RTEMS is licensed under a combination of permissive licenses and
a modified version of the GNU General Public License (GPL).

> +`License in RTEMS
> + +license-requirements.html>`__
> +
> +
I think just 1 blank space?

> +What standards are supported by RTEMS?
> +-
> +
> +The original "Classic" RTEMS API is based on the Real-Time Executive 

Re: Policy for return by reference values in error cases

[Gedare Bloom]

On Tue, Mar 23, 2021 at 1:21 PM Gedare Bloom  wrote:
>
> On Tue, Mar 23, 2021 at 12:37 PM Joel Sherrill  wrote:
> >
> >
> >
> > On Tue, Mar 23, 2021 at 12:58 PM Sebastian Huber 
> >  wrote:
> >>
> >> On 23/03/2021 18:48, Joel Sherrill wrote:
> >>
> >> > My first thought is that I don't like covering up for applications
> >> > that do the wrong thing.
> +.5
>
> >> This topic just came up recently in a discussion about defensive
> >> programming. We also test for NULL pointers.
> +1
>
> >> >
> >> > I'm overall rather ambiguous. It is possible that setting the value at
> >> > the top of the function could lead to overridden before used issues
> >> > with warnings and static analysis.
> >>
> >> You mean code like this:
> >>
> >> void (int *x, int y)
> >>
> >> {
> >>
> >>*x = 0;
> >>
> >>   if (y) {
> >>
> >> *x = 1;
> >>
> >> } else {
> >>
> >>   *x = 2;
> >>
> >> }
> >>
> >> ?
> >
> >
> > Yep. That's a pretty clear case.
> >
> > Others should speak up but I just don't want the solution pattern
> > to introduce warnings or static analysis reports. It easily could.
> >
>
> Generally, the error-producing path should allow the static analysis
> to find that the value gets set. In fact, I'm a bit surprised the
> static analysis doesn't complain about the original problem, that some
> variable can be used uninitialized when for example
> rtems_event_receive() returns before updating its pointer argument.
> Probably, the points-to analysis is complicated to find this case, but
> it seems like a good case to reduce and bring to some expert in static
> analysis.
>
I guess we don't have this kind of bad example in our testsuite though. :)

> So I don't see a fundamental problem with a pattern that initializes
> these out parameters at the top of the function to a default value.
>
> >
> >>
> >> > I don't want to see every error case assign a value to an output
> >> > parameter though.
> >> Yes, I don't like this also.
> >
> >
> > I have my own wish list for error paths eventually if we ever get bored. :)
> >
> >
> > --joel
> >
> >>
> >>
> >> --
> >> embedded brains GmbH
> >> Herr Sebastian HUBER
> >> Dornierstr. 4
> >> 82178 Puchheim
> >> Germany
> >> email: sebastian.hu...@embedded-brains.de
> >> phone: +49-89-18 94 741 - 16
> >> fax:   +49-89-18 94 741 - 08
> >>
> >> Registergericht: Amtsgericht München
> >> Registernummer: HRB 157899
> >> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> >> Unsere Datenschutzerklärung finden Sie hier:
> >> https://embedded-brains.de/datenschutzerklaerung/
> >>
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Policy for return by reference values in error cases

[Gedare Bloom]

On Tue, Mar 23, 2021 at 12:37 PM Joel Sherrill  wrote:
>
>
>
> On Tue, Mar 23, 2021 at 12:58 PM Sebastian Huber 
>  wrote:
>>
>> On 23/03/2021 18:48, Joel Sherrill wrote:
>>
>> > My first thought is that I don't like covering up for applications
>> > that do the wrong thing.
+.5

>> This topic just came up recently in a discussion about defensive
>> programming. We also test for NULL pointers.
+1

>> >
>> > I'm overall rather ambiguous. It is possible that setting the value at
>> > the top of the function could lead to overridden before used issues
>> > with warnings and static analysis.
>>
>> You mean code like this:
>>
>> void (int *x, int y)
>>
>> {
>>
>>*x = 0;
>>
>>   if (y) {
>>
>> *x = 1;
>>
>> } else {
>>
>>   *x = 2;
>>
>> }
>>
>> ?
>
>
> Yep. That's a pretty clear case.
>
> Others should speak up but I just don't want the solution pattern
> to introduce warnings or static analysis reports. It easily could.
>

Generally, the error-producing path should allow the static analysis
to find that the value gets set. In fact, I'm a bit surprised the
static analysis doesn't complain about the original problem, that some
variable can be used uninitialized when for example
rtems_event_receive() returns before updating its pointer argument.
Probably, the points-to analysis is complicated to find this case, but
it seems like a good case to reduce and bring to some expert in static
analysis.

So I don't see a fundamental problem with a pattern that initializes
these out parameters at the top of the function to a default value.

>
>>
>> > I don't want to see every error case assign a value to an output
>> > parameter though.
>> Yes, I don't like this also.
>
>
> I have my own wish list for error paths eventually if we ever get bored. :)
>
>
> --joel
>
>>
>>
>> --
>> embedded brains GmbH
>> Herr Sebastian HUBER
>> Dornierstr. 4
>> 82178 Puchheim
>> Germany
>> email: sebastian.hu...@embedded-brains.de
>> phone: +49-89-18 94 741 - 16
>> fax:   +49-89-18 94 741 - 08
>>
>> Registergericht: Amtsgericht München
>> Registernummer: HRB 157899
>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>> Unsere Datenschutzerklärung finden Sie hier:
>> https://embedded-brains.de/datenschutzerklaerung/
>>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH] bsps: Removed INI files using outdated options

[Ryan Long]

There are replacements to run these on sis. They just have -sis.ini on the end 
of them.

-Original Message-
From: Gedare Bloom  
Sent: Tuesday, March 23, 2021 2:07 PM
To: Joel Sherrill 
Cc: Ryan Long ; rtems-de...@rtems.org 
Subject: Re: [PATCH] bsps: Removed INI files using outdated options

On Tue, Mar 23, 2021 at 12:30 PM Joel Sherrill  wrote:
>
> bsps: Removed INI files using outdated options
>
> Better would be
>
> sparc bsps: Remove INI files using SIS in GDB
>

actually, bsps/sparc is preferred.

I don't know that we have this documented though.

> On Tue, Mar 23, 2021 at 1:13 PM Ryan Long  wrote:
>>
>> Removed the INI files that use the "target sim" option in gdb since 
>> this is no longer supported.
>
>
> This needs to be more accurate.
>
> Specifically, the sis sparc simulator in gdb is no longer used with 
> RTEMS and we use a newer version of SIS built separately.
>
> This ONLY impacts the SPARC.
>
> --joel
>
>>
>>
>> Closes #4355
>> ---
>>  tester/rtems/testing/bsps/erc32.ini | 41 
>> -
>>  tester/rtems/testing/bsps/leon2.ini | 41 
>> -
>>  tester/rtems/testing/bsps/leon3.ini | 41 
>> -
>>  3 files changed, 123 deletions(-)
>>  delete mode 100644 tester/rtems/testing/bsps/erc32.ini
>>  delete mode 100644 tester/rtems/testing/bsps/leon2.ini
>>  delete mode 100644 tester/rtems/testing/bsps/leon3.ini
>>

i haven't looked, but are there replacements (to run these on sis directly?)

>> diff --git a/tester/rtems/testing/bsps/erc32.ini 
>> b/tester/rtems/testing/bsps/erc32.ini
>> deleted file mode 100644
>> index 7911a2f..000
>> --- a/tester/rtems/testing/bsps/erc32.ini
>> +++ /dev/null
>> @@ -1,41 +0,0 @@
>> -#
>> -# RTEMS Tools Project (http://www.rtems.org/) -# Copyright 2015 
>> On-Line Applications Research Corporation (OAR).
>> -# All rights reserved.
>> -#
>> -# This file is part of the RTEMS Tools package in 'rtems-tools'.
>> -#
>> -# Redistribution and use in source and binary forms, with or without 
>> -# modification, are permitted provided that the following conditions are 
>> met:
>> -#
>> -# 1. Redistributions of source code must retain the above copyright 
>> notice, -# this list of conditions and the following disclaimer.
>> -#
>> -# 2. Redistributions in binary form must reproduce the above 
>> copyright notice, -# this list of conditions and the following 
>> disclaimer in the documentation -# and/or other materials provided with the 
>> distribution.
>> -#
>> -# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
>> IS"
>> -# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED 
>> TO, THE -# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A 
>> PARTICULAR PURPOSE -# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 
>> HOLDER OR CONTRIBUTORS BE -# LIABLE FOR ANY DIRECT, INDIRECT, 
>> INCIDENTAL, SPECIAL, EXEMPLARY, OR -# CONSEQUENTIAL DAMAGES 
>> (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF -# SUBSTITUTE GOODS OR 
>> SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS -# INTERRUPTION) 
>> HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN -# 
>> CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR 
>> OTHERWISE) -# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF 
>> ADVISED OF THE -# POSSIBILITY OF SUCH DAMAGE.
>> -#
>> -
>> -#
>> -# The erc32 BSP
>> -#
>> -[erc32]
>> -bsp= erc32
>> -arch   = sparc
>> -tester = %{_rtscripts}/gdb.cfg
>> -gdb_script = bsp_gdb_script
>> -bsp_gdb_script = target sim
>> - load
>> - run
>> diff --git a/tester/rtems/testing/bsps/leon2.ini 
>> b/tester/rtems/testing/bsps/leon2.ini
>> deleted file mode 100644
>> index 77fed49..000
>> --- a/tester/rtems/testing/bsps/leon2.ini
>> +++ /dev/null
>> @@ -1,41 +0,0 @@
>> -#
>> -# RTEMS Tools Project (http://www.rtems.org/) -# Copyright 2015 
>> On-Line Applications Research Corporation (OAR).
>> -# All rights reserved.
>> -#
>> -# This file is part of the RTEMS Tools package in 'rtems-tools'.
>> -#
>> -# Redistribution and use in source and binary forms, with or without 
>> -# modification, are permitted provided that the following conditions are 
>> met:
>> -#
>> -# 1. Redistributions of source code must retain the above copyright 
>> notice, -# this list of conditions and the following disclaimer.
>> -#
>> -# 2. Redistributions in binary form must reproduce the above 
>> copyright notice, -# this list of conditions and the following 
>> disclaimer in the documentation -# and/or other materials provided with the 
>> distribution.
>> -#
>> -# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
>> IS"
>> -# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED 
>> TO, THE -# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A 
>> PARTICULAR PURPOSE -# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 
>> HOLDER OR 

Re: Standalone repository for libnetworking stack

[Gedare Bloom]

On Tue, Mar 23, 2021 at 12:34 PM Joel Sherrill  wrote:
>
>
>
> On Tue, Mar 23, 2021 at 11:27 AM Vijay Kumar Banerjee  wrote:
>>
>> Hi,
>>
>> I have prepared and rebased all the patches to the current master. Please 
>> review the commits.
>>
>> RTEMS patches: https://git.rtems.org/vijay/rtems.git/log/?h=devel-no-libnet
>> RTEMS net-legacy patch to pull recent changes: 
>> https://git.rtems.org/vijay/rtems-net-legacy.git/commit/?id=2b4738734f9d678a458b64278c0ff95dea588b1e
>> RTEMS libbsd patch to add telnetd: 
>> https://git.rtems.org/vijay/rtems-libbsd.git/commit/?id=6bda703964e8cbbf73cb21f52fb7ceeb3cb3a541
>>
>> With these patches, the relocation work would be complete. I have tested all 
>> these patches are building with all the RTEMS bsps in bsp_defaults using waf.
>
>
> Great! Is there any reason not to move the repo to the top level and delete 
> the networking from the main rtems repository?
>
It is: https://git.rtems.org/rtems-net-legacy/  -- I think he is
asking to merge/update the repos. Vijay, I think you could send the
net-legacy patch by itself to the list.

I think  the big one is the RTEMS patches, and I'm not sure if the
libbsd patches have been seen yet? @Vijay Can those be sent as an
emailed patchset?

> And to make a news announcements.
>
I think we had the announcement that it was pending, but yes it will
be good to finalize that thread on the relevant mailing lists (users,
EPICS-core). We think we hit most of the 'downstream' with those.

> --joel
>>
>>
>>
>> Best regards,
>> Vijay
>>
>>
>> On Wed, Mar 10, 2021 at 11:43 AM Chris Johns  wrote:
>>>
>>>
>>>
>>> On 11/3/21 5:14 am, Joel Sherrill wrote:
>>> >
>>> >
>>> > On Wed, Mar 10, 2021 at 11:48 AM Chris Johns >> > > wrote:
>>> >
>>> >
>>> >
>>> > On 11/3/21 1:11 am, Joel Sherrill wrote:
>>> > > On Tue, Mar 9, 2021 at 11:00 PM Vijay Kumar Banerjee 
>>> > >> > 
>>> > > >> wrote:
>>> > >
>>> > > On Tue, Mar 9, 2021 at 9:56 PM Chris Johns >> > 
>>> > > >> wrote:
>>> > > >
>>> > > > On 10/3/21 3:51 pm, Gedare Bloom wrote:
>>> > > > > On Tue, Mar 9, 2021 at 6:58 PM Joel Sherrill >> > 
>>> > > >> wrote:
>>> > > > >> On Tue, Mar 9, 2021, 3:28 PM Vijay Kumar Banerjee
>>> > mailto:vi...@rtems.org>
>>> > > >> wrote:
>>> > > > >>> On Fri, Mar 5, 2021 at 10:03 AM Vijay Kumar Banerjee
>>> > mailto:vi...@rtems.org>
>>> > > >> wrote:
>>> > > > >>> In this proposed set of patches, I have removed telnetd 
>>> > from
>>> > RTEMS and
>>> > > > >>> have placed it in the net-legacy repo, it seems like 
>>> > libbsd uses
>>> > > > >>> telnetd as well. Do we want to keep it in RTEMS and 
>>> > remove it
>>> > from the
>>> > > > >>> legacy net repo?  There are checks in for 
>>> > RTEMS_NETWORKING in
>>> > telnetd,
>>> > > > >>> to add rtems_bsdnet.h, how do we want to deal with that? 
>>> > In the
>>> > legacy
>>> > > > >>> repo, we can just remove these checks and let them build.
>>> > > > >>
>>> > > > >>
>>> > > > >> Move it and remove rtems networking conditional. Freezes 
>>> > it with
>>> > legacy
>>> > > stack.
>>> > > > >>
>>> > > > >> Just my opinion
>>> > > > >>
>>> > > > > Is there a different telnetd in libbsd?
>>> > > >
>>> > > > Yes ...
>>> > > >
>>> > > > https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/telnetd
>>> > 
>>> > > >> > >
>>> > > >
>>> > > This seems to include rtems/telnetd.h
>>> > > Does the libbsd telnetd depend on the cpukit/telnetd?
>>> > >
>>> > > > > The longer term pseudo-goal of being able to (potentially) 
>>> > build
>>> > > > > multiple networking stacks and pick which one to link 
>>> > against may also
>>> > > > > be a consideration at this stage.
>>> > > >
>>> > > > Are there issues? If there are issues do we know what they 
>>> > are?
>>> > >
>>> > >
>>> > > I guess the bigger question is what network services should remain 
>>> > in
>>> > > rtems itself and work with any stack.
>>> > >
>>> > > We have at least telnetd and the web server. If they build against 
>>> > the
>>> > > standard network headers, then they should work any stack that uses
>>> > > those.
>>> > >
>>> > > For maintenance, it would be preferable to 

Re: [PATCH] bsps: Removed INI files using outdated options

[Gedare Bloom]

On Tue, Mar 23, 2021 at 12:30 PM Joel Sherrill  wrote:
>
> bsps: Removed INI files using outdated options
>
> Better would be
>
> sparc bsps: Remove INI files using SIS in GDB
>

actually, bsps/sparc is preferred.

I don't know that we have this documented though.

> On Tue, Mar 23, 2021 at 1:13 PM Ryan Long  wrote:
>>
>> Removed the INI files that use the "target sim" option in gdb
>> since this is no longer supported.
>
>
> This needs to be more accurate.
>
> Specifically, the sis sparc simulator in gdb is no longer used with RTEMS and
> we use a newer version of SIS built separately.
>
> This ONLY impacts the SPARC.
>
> --joel
>
>>
>>
>> Closes #4355
>> ---
>>  tester/rtems/testing/bsps/erc32.ini | 41 
>> -
>>  tester/rtems/testing/bsps/leon2.ini | 41 
>> -
>>  tester/rtems/testing/bsps/leon3.ini | 41 
>> -
>>  3 files changed, 123 deletions(-)
>>  delete mode 100644 tester/rtems/testing/bsps/erc32.ini
>>  delete mode 100644 tester/rtems/testing/bsps/leon2.ini
>>  delete mode 100644 tester/rtems/testing/bsps/leon3.ini
>>

i haven't looked, but are there replacements (to run these on sis directly?)

>> diff --git a/tester/rtems/testing/bsps/erc32.ini 
>> b/tester/rtems/testing/bsps/erc32.ini
>> deleted file mode 100644
>> index 7911a2f..000
>> --- a/tester/rtems/testing/bsps/erc32.ini
>> +++ /dev/null
>> @@ -1,41 +0,0 @@
>> -#
>> -# RTEMS Tools Project (http://www.rtems.org/)
>> -# Copyright 2015 On-Line Applications Research Corporation (OAR).
>> -# All rights reserved.
>> -#
>> -# This file is part of the RTEMS Tools package in 'rtems-tools'.
>> -#
>> -# Redistribution and use in source and binary forms, with or without
>> -# modification, are permitted provided that the following conditions are 
>> met:
>> -#
>> -# 1. Redistributions of source code must retain the above copyright notice,
>> -# this list of conditions and the following disclaimer.
>> -#
>> -# 2. Redistributions in binary form must reproduce the above copyright 
>> notice,
>> -# this list of conditions and the following disclaimer in the documentation
>> -# and/or other materials provided with the distribution.
>> -#
>> -# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
>> IS"
>> -# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
>> -# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
>> -# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
>> -# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
>> -# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
>> -# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
>> -# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
>> -# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
>> -# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
>> -# POSSIBILITY OF SUCH DAMAGE.
>> -#
>> -
>> -#
>> -# The erc32 BSP
>> -#
>> -[erc32]
>> -bsp= erc32
>> -arch   = sparc
>> -tester = %{_rtscripts}/gdb.cfg
>> -gdb_script = bsp_gdb_script
>> -bsp_gdb_script = target sim
>> - load
>> - run
>> diff --git a/tester/rtems/testing/bsps/leon2.ini 
>> b/tester/rtems/testing/bsps/leon2.ini
>> deleted file mode 100644
>> index 77fed49..000
>> --- a/tester/rtems/testing/bsps/leon2.ini
>> +++ /dev/null
>> @@ -1,41 +0,0 @@
>> -#
>> -# RTEMS Tools Project (http://www.rtems.org/)
>> -# Copyright 2015 On-Line Applications Research Corporation (OAR).
>> -# All rights reserved.
>> -#
>> -# This file is part of the RTEMS Tools package in 'rtems-tools'.
>> -#
>> -# Redistribution and use in source and binary forms, with or without
>> -# modification, are permitted provided that the following conditions are 
>> met:
>> -#
>> -# 1. Redistributions of source code must retain the above copyright notice,
>> -# this list of conditions and the following disclaimer.
>> -#
>> -# 2. Redistributions in binary form must reproduce the above copyright 
>> notice,
>> -# this list of conditions and the following disclaimer in the documentation
>> -# and/or other materials provided with the distribution.
>> -#
>> -# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
>> IS"
>> -# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
>> -# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
>> -# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
>> -# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
>> -# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
>> -# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
>> -# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
>> -# CONTRACT, STRICT 

Re: GSoC Project : Package Micro-python

[Gedare Bloom]

On Tue, Mar 23, 2021 at 12:16 PM Eshan Dhawan  wrote:
>
>
> Apologies for the late reply.
>
> On Mon, Mar 22, 2021 at 10:27 PM Joel Sherrill  wrote:
>>
>>
>>
>> On Mon, Mar 22, 2021 at 11:55 AM Gedare Bloom  wrote:
>>>
>>> On Mon, Mar 22, 2021 at 10:50 AM Joel Sherrill  wrote:
>>> >
>>> >
>>> >
>>> > On Mon, Mar 22, 2021 at 11:30 AM Gedare Bloom  wrote:
>>> >>
>>> >> On Sat, Mar 20, 2021 at 12:33 PM Eshan Dhawan  
>>> >> wrote:
>>> >> >
>>> >> > Hello Everyone,
>>> >> > I wanted to take Packaging Micro Python up as GSOC project this summer 
>>> >> > and the project will also include packaging LUA and picoC
>>> >> > The ticket for Micro Python  : https://devel.rtems.org/ticket/4349
>>> >> > What would be the complete Scope of the project?
>>> >> > And what would be a good starting point?
>>> >> >
>>> >>
>>> >> Well, I guess Joel must have described the task, so I'll leave it to
>>> >> him to fill in some more details.
>>> >>
>>> >> Adding RSB packages may be not sufficient coding work for GSoC. It is
>>> >> important in the proposal to identify what would be the coding
>>> >> activities involved in this project. For example, we know from
>>> >> experience that Lua can just be built from some minor tailoring of its
>>> >> Makefile, so the package is very straightforward. However, the
>>> >> projects you mention are scripting environments, so maybe creating a
>>> >> framework in RTEMS for a "shell/intepreter" that can be built as an
>>> >> add-on by RSB would be a proper way to scope this effort
>
> Packaging might not be a lot of coding part but adding its documentation and 
> its example would be a very iterative and time consuming process.

Remember that code is what counts, while we expect the other stuff to
come along too, you don't want to be doing 90% doco and 10% code. Just
keep it in mind.

>>>
>>> >
>>> >
>>> > I agree that Lua and Micropython should build easy but I had more
>>> > in mind.
>>> >
>>> > The full project was language stacks for RTEMS with a better user
>>> > experience for Micropython, Lua, Tcl, etc although I am not sure what
>>> > etc would entail. I am not sure all three can be completed in the new
>>> > GSoC timeframe. All would follow the same pattern:
>
> Etc can be managed while framing the proposal according to how time is being 
> managed.
>>>
>>> >
>>> > + RSB package offering a reasonable default and access to configuration
>>> > + Examples including at least bare embedded, use of custom commands,
>>> > and integrating with RTEMS shell commands Perhaps  interactive use with
>>> > command line history and editing integrated if we have that as a library 
>>> > now.
>>> > + Documentation specific to RTEMS and the examples
>>> >
>>> > I imagined completely parallel kits for each embedded language we wanted
>>> > to support.
>>> >
>>> > Does that help? Should he plan on Micropython and Lua?
>>> >
>>>
>>> Sure. Lua should be easy way to get started and develop the
>>> framework/infrastructure side in Phase 1. Phase 2 could be extension
>>> to micropython / other scripting languages.
>
> Since all the languages will have a similar pattern complex work can be put 
> in phase 2.
> From my past experience, it is the part when most work is done :)

True, but for repeat students, we do expect a bit more acceleration in
the first phase. Usually, we want to see code merged in phase 1 by
repeat students. Just a reminder that the bar is higher :)

>>
>>
>> OK.
>>>
>>>
>>> I'm not sure about the RSB design of things, and whether they should
>>> be parallel or capable of integration. Would anyone want to use
>>> multiple interpreters in the same application? If so, they should
>>> build together to avoid conflicts. If not, parallel is fine.
>
> building them can be set to build flags,
> but there still needs to be a way if we want to build the package other than 
> the default way.
> (any ideas on how to do that )
>>
>>
>> I don't see any reason on our side why that shouldn't work but we
>> can't guarantee they don't have symbol conflicts. And I'm not sure
>> it would make much sense to integrate both at the same time.
>>
>> I'd think you could install both but we'd focus on only using one
>> at a time.
>>
>> --joel
>>>
>>>
>>> > --joel
>>> >
>>> >>
>>> >> > Thanks
>>> >> > - Eshan
>>> >> > ___
>>> >> > devel mailing list
>>> >> > devel@rtems.org
>>> >> > http://lists.rtems.org/mailman/listinfo/devel
>>> >> ___
>>> >> devel mailing list
>>> >> devel@rtems.org
>>> >> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-docs v2] networking: Rename to legacy networking

[Joel Sherrill]

I'm OK with this.

Does this move the manual to near the bottom of the manual list?

I suspect some content is needed somewhere in the Users Guide
to point out how you have a choice of network stacks and building
one of them. Beyond this patch but looking forward, we have some
explaining to do.

--joel

On Tue, Mar 23, 2021 at 1:48 PM Vijay Kumar Banerjee 
wrote:

> Ping :)
>
> On Tue, Mar 9, 2021 at 9:59 AM Vijay Kumar Banerjee 
> wrote:
> >
> > ---
> >  book/index_book.rst   | 2 +-
> >  {networking => legacy-networking}/command.rst | 0
> >  {networking => legacy-networking}/conf.py | 4 ++--
> >  {networking => legacy-networking}/dec_21140.rst   | 0
> >  {networking => legacy-networking}/index.rst   | 2 +-
> >  {networking => legacy-networking}/network_servers.rst | 0
> >  {networking => legacy-networking}/network_task_structure.rst  | 0
> >  {networking => legacy-networking}/networking_driver.rst   | 0
> >  {networking => legacy-networking}/preface.rst | 0
> >  {networking => legacy-networking}/testing_the_driver.rst  | 0
> >  .../using_networking_rtems_app.rst| 0
> >  {networking => legacy-networking}/wscript | 0
> >  wscript   | 2 +-
> >  13 files changed, 5 insertions(+), 5 deletions(-)
> >  rename {networking => legacy-networking}/command.rst (100%)
> >  rename {networking => legacy-networking}/conf.py (68%)
> >  rename {networking => legacy-networking}/dec_21140.rst (100%)
> >  rename {networking => legacy-networking}/index.rst (92%)
> >  rename {networking => legacy-networking}/network_servers.rst (100%)
> >  rename {networking => legacy-networking}/network_task_structure.rst
> (100%)
> >  rename {networking => legacy-networking}/networking_driver.rst (100%)
> >  rename {networking => legacy-networking}/preface.rst (100%)
> >  rename {networking => legacy-networking}/testing_the_driver.rst (100%)
> >  rename {networking => legacy-networking}/using_networking_rtems_app.rst
> (100%)
> >  rename {networking => legacy-networking}/wscript (100%)
> >
> > diff --git a/book/index_book.rst b/book/index_book.rst
> > index 8282006..3fc67d2 100644
> > --- a/book/index_book.rst
> > +++ b/book/index_book.rst
> > @@ -23,7 +23,7 @@ Table of Contents
> > cpu_supplement/index.rst
> > develenv/index.rst
> > filesystem/index.rst
> > -   networking/index.rst
> > +   legacy_networking/index.rst
> > porting/index.rst
> > posix1003_1/index.rst
> > posix_users/index.rst
> > diff --git a/networking/command.rst b/legacy-networking/command.rst
> > similarity index 100%
> > rename from networking/command.rst
> > rename to legacy-networking/command.rst
> > diff --git a/networking/conf.py b/legacy-networking/conf.py
> > similarity index 68%
> > rename from networking/conf.py
> > rename to legacy-networking/conf.py
> > index 1c129bc..6cc01bc 100644
> > --- a/networking/conf.py
> > +++ b/legacy-networking/conf.py
> > @@ -3,12 +3,12 @@ sys.path.insert(0, os.path.abspath('../common/'))
> >
> >  from conf import *
> >
> > -project = "RTEMS Networking User Manual"
> > +project = "RTEMS Legacy Networking User Manual"
> >
> >  latex_documents = [
> >  ('index',
> >   'networking.tex',
> > - u'RTEMS Networking User Manual',
> > + u'RTEMS Legacy Networking User Manual',
> >   u'RTEMS Documentation Project',
> >   'manual'),
> >  ]
> > diff --git a/networking/dec_21140.rst b/legacy-networking/dec_21140.rst
> > similarity index 100%
> > rename from networking/dec_21140.rst
> > rename to legacy-networking/dec_21140.rst
> > diff --git a/networking/index.rst b/legacy-networking/index.rst
> > similarity index 92%
> > rename from networking/index.rst
> > rename to legacy-networking/index.rst
> > index f56a60d..b85119d 100644
> > --- a/networking/index.rst
> > +++ b/legacy-networking/index.rst
> > @@ -5,7 +5,7 @@
> >  .. highlight:: c
> >
> >  ==
> > -RTEMS Network User Manual (|version|).
> > +RTEMS Legacy Network User Manual (|version|).
> >  ==
> >
> >  .. topic:: Copyrights and License
> > diff --git a/networking/network_servers.rst
> b/legacy-networking/network_servers.rst
> > similarity index 100%
> > rename from networking/network_servers.rst
> > rename to legacy-networking/network_servers.rst
> > diff --git a/networking/network_task_structure.rst
> b/legacy-networking/network_task_structure.rst
> > similarity index 100%
> > rename from networking/network_task_structure.rst
> > rename to legacy-networking/network_task_structure.rst
> > diff --git a/networking/networking_driver.rst
> b/legacy-networking/networking_driver.rst
> > similarity index 100%
> > rename from networking/networking_driver.rst
> > rename to legacy-networking/networking_driver.rst
> > 

Re: [PATCH rtems-docs v2] networking: Rename to legacy networking

[Vijay Kumar Banerjee]

Ping :)

On Tue, Mar 9, 2021 at 9:59 AM Vijay Kumar Banerjee  wrote:
>
> ---
>  book/index_book.rst   | 2 +-
>  {networking => legacy-networking}/command.rst | 0
>  {networking => legacy-networking}/conf.py | 4 ++--
>  {networking => legacy-networking}/dec_21140.rst   | 0
>  {networking => legacy-networking}/index.rst   | 2 +-
>  {networking => legacy-networking}/network_servers.rst | 0
>  {networking => legacy-networking}/network_task_structure.rst  | 0
>  {networking => legacy-networking}/networking_driver.rst   | 0
>  {networking => legacy-networking}/preface.rst | 0
>  {networking => legacy-networking}/testing_the_driver.rst  | 0
>  .../using_networking_rtems_app.rst| 0
>  {networking => legacy-networking}/wscript | 0
>  wscript   | 2 +-
>  13 files changed, 5 insertions(+), 5 deletions(-)
>  rename {networking => legacy-networking}/command.rst (100%)
>  rename {networking => legacy-networking}/conf.py (68%)
>  rename {networking => legacy-networking}/dec_21140.rst (100%)
>  rename {networking => legacy-networking}/index.rst (92%)
>  rename {networking => legacy-networking}/network_servers.rst (100%)
>  rename {networking => legacy-networking}/network_task_structure.rst (100%)
>  rename {networking => legacy-networking}/networking_driver.rst (100%)
>  rename {networking => legacy-networking}/preface.rst (100%)
>  rename {networking => legacy-networking}/testing_the_driver.rst (100%)
>  rename {networking => legacy-networking}/using_networking_rtems_app.rst 
> (100%)
>  rename {networking => legacy-networking}/wscript (100%)
>
> diff --git a/book/index_book.rst b/book/index_book.rst
> index 8282006..3fc67d2 100644
> --- a/book/index_book.rst
> +++ b/book/index_book.rst
> @@ -23,7 +23,7 @@ Table of Contents
> cpu_supplement/index.rst
> develenv/index.rst
> filesystem/index.rst
> -   networking/index.rst
> +   legacy_networking/index.rst
> porting/index.rst
> posix1003_1/index.rst
> posix_users/index.rst
> diff --git a/networking/command.rst b/legacy-networking/command.rst
> similarity index 100%
> rename from networking/command.rst
> rename to legacy-networking/command.rst
> diff --git a/networking/conf.py b/legacy-networking/conf.py
> similarity index 68%
> rename from networking/conf.py
> rename to legacy-networking/conf.py
> index 1c129bc..6cc01bc 100644
> --- a/networking/conf.py
> +++ b/legacy-networking/conf.py
> @@ -3,12 +3,12 @@ sys.path.insert(0, os.path.abspath('../common/'))
>
>  from conf import *
>
> -project = "RTEMS Networking User Manual"
> +project = "RTEMS Legacy Networking User Manual"
>
>  latex_documents = [
>  ('index',
>   'networking.tex',
> - u'RTEMS Networking User Manual',
> + u'RTEMS Legacy Networking User Manual',
>   u'RTEMS Documentation Project',
>   'manual'),
>  ]
> diff --git a/networking/dec_21140.rst b/legacy-networking/dec_21140.rst
> similarity index 100%
> rename from networking/dec_21140.rst
> rename to legacy-networking/dec_21140.rst
> diff --git a/networking/index.rst b/legacy-networking/index.rst
> similarity index 92%
> rename from networking/index.rst
> rename to legacy-networking/index.rst
> index f56a60d..b85119d 100644
> --- a/networking/index.rst
> +++ b/legacy-networking/index.rst
> @@ -5,7 +5,7 @@
>  .. highlight:: c
>
>  ==
> -RTEMS Network User Manual (|version|).
> +RTEMS Legacy Network User Manual (|version|).
>  ==
>
>  .. topic:: Copyrights and License
> diff --git a/networking/network_servers.rst 
> b/legacy-networking/network_servers.rst
> similarity index 100%
> rename from networking/network_servers.rst
> rename to legacy-networking/network_servers.rst
> diff --git a/networking/network_task_structure.rst 
> b/legacy-networking/network_task_structure.rst
> similarity index 100%
> rename from networking/network_task_structure.rst
> rename to legacy-networking/network_task_structure.rst
> diff --git a/networking/networking_driver.rst 
> b/legacy-networking/networking_driver.rst
> similarity index 100%
> rename from networking/networking_driver.rst
> rename to legacy-networking/networking_driver.rst
> diff --git a/networking/preface.rst b/legacy-networking/preface.rst
> similarity index 100%
> rename from networking/preface.rst
> rename to legacy-networking/preface.rst
> diff --git a/networking/testing_the_driver.rst 
> b/legacy-networking/testing_the_driver.rst
> similarity index 100%
> rename from networking/testing_the_driver.rst
> rename to legacy-networking/testing_the_driver.rst
> diff --git a/networking/using_networking_rtems_app.rst 
> b/legacy-networking/using_networking_rtems_app.rst
> similarity index 100%
> rename from 

Re: Question regarding an open project and documentation enhancement

[Ayushman Mishra]

I have send patches regarding addition of FAQ page in user/quick-start
section of docs . Here I had to make extra links in 7.5
autoconf-migrations ,1.2 features,3.1 project support and corrected
the link in https://docs.rtems.org/branches/master/user/bld/index.html#commands
. In 2nd patch I moved questions of
https://docs.rtems.org/branches/master/user/support/contrib.html#common-questions-and-answers
from 3.3 Contributing section to FAQ page.

On Thu, Mar 18, 2021 at 9:46 PM Gedare Bloom  wrote:
>
> On Thu, Mar 18, 2021 at 10:08 AM Ayushman Mishra
>  wrote:
> >
> > Sorry for the delay (actually I was little busy due to my semester
> > examination) and extremely sorry for my previous behaviour
> >
> > I have created a frequently asked questions (FAQ) page under
> > quick-start section in user guide according to the ticket
> > https://devel.rtems.org/ticket/3958 . I have attached an image of how
> > the page looks after build up, and will send a patch for it as soon as
> > possible ( currently some links are not working correctly) . Most of
> > the questions are from https://devel.rtems.org/wiki/TBR/Website/FAQ
> > but I am also writing a few questions of my own (like about .waf and
> > autoconf build up)
> >
> Great. Maybe, start with the patch to add the new FAQ section to the
> docs, and a second patch to migrate the contents from the Trac, and
> then a third patch to add some more questions.
>
> > Also I wanted to take https://devel.rtems.org/ticket/4334 (Replace
> > Mongoose with Civitweb) as a GSOC project as I have huge interest in
> > networking related projects but lack experience in it. I would be very
> > grateful to know more about this project.
> >
> This is a good project also. Note there is a typo in the ticket title,
> the project is called Civetweb; I fixed the ticket typos. For this
> project, during the proposal preparation phase you should get RTEMS
> working with a networking stack and able to run the existing mongoose
> webserver (mghttpd) would be a very good start. I would suggest you
> start a new thread to discuss this project, and to ask for more
> guidance there.
>
> Gedare
>
> >
> > On Tue, Mar 2, 2021 at 10:28 PM Gedare Bloom  wrote:
> > >
> > > On Tue, Mar 2, 2021 at 9:11 AM Joel Sherrill  wrote:
> > > >
> > > >
> > > >
> > > > On Tue, Mar 2, 2021 at 9:08 AM Ayushman Mishra 
> > > >  wrote:
> > > >>
> > > >> 1. Hello everyone, I went through open ticket "Code Formatting and
> > > >> Style Check for RTEMS score"  (https://devel.rtems.org/ticket/3860) as
> > > >> a possible GSOC project and discussion thread on it
> > > >> https://lists.rtems.org/pipermail/devel/2020-February/057246.html,
> > > >> https://lists.rtems.org/pipermail/devel/2020-February/057057.html .
> > > >> But most of the threads on this project are almost a year old , I
> > > >> wanted to know has there been any recent development on this project
> > > >> and is there any specific tool developed/under-development for it. I
> > > >> would be grateful to connect with mentor of this project in-order to
> > > >> know more about the complexity involved and resources available for
> > > >> it.
> > > >
> > > >
> > > > As Sebastian said, it hasn't had any recent work but still needs 
> > > > attention.
> > > > I think we have a first candidate style description and tool but it has 
> > > > not
> > > > been checked against the code to see what differences exist between the
> > > > RTEMS style and the generated style. These differences could be because
> > > > the formatting specification to the tool needs tweaking, the input 
> > > > RTEMS code
> > > > didn't follow the rules before, or we could need to consider changing 
> > > > our style
> > > > rules.
> > > >
> > > > The score/src directory is thought to be the one of the ones which would
> > > > follow the RTEMS style most consistently. Focusing there should help
> > > > establish a baseline style, scripts, and change recommendations.
> > > >
> > > > Style adherence also has to be accounted for as part of the patch review
> > > > and git commit process. Hopefully it can be automated.
> > > >
> > > > Taking a broad view of this could be a good GSoC project. At least I
> > > > think there is enough programming in it to count as one.
> > > >
> > > Yes, this can be a GSoC project.
> > >
> > > >>
> > > >>
> > > >> 2. Also I checked the issue #3958 https://devel.rtems.org/ticket/3958
> > > >> , fixed some of the broken links of FAQ page but few of the answers I
> > > >> got were from sites other than user guide. I would like to create a
> > > >> separate FAQ page in user-guide having some of answers available there
> > > >> only and some available as links.
> > > >
> > > >
> > > > As a general rule, a lot of what is in the Wiki should be in regular 
> > > > documentation
> > > > at docs.rtems.org. A lot has been converted, some in the wiki is 
> > > > already in the
> > > > documentation but has not been checked for consistency in the 
> > > > conversion.
> > > >
> > > > 

[PATCH 2/2] moved common questions and answers to faq

[Ayushman Mishra]

---
 user/start/faq.rst   | 87 
 user/support/contrib.rst | 95 
 2 files changed, 87 insertions(+), 95 deletions(-)

diff --git a/user/start/faq.rst b/user/start/faq.rst
index da11ca4..4558bce 100644
--- a/user/start/faq.rst
+++ b/user/start/faq.rst
@@ -246,6 +246,93 @@ system initialization although task stacks and message 
buffer areas are also
 allocated from here.
 
 
+Why should we work with the RTEMS developers
+---
+
+Our engineers understand our target environment better than anyone else, and 
+we have a tight schedule. Why should we work with the RTEMS developers, when 
+we can get the code out faster by whacking it out on our own?
+
+
+You understand your target environment better than anyone else.
+However, the RTEMS developers understand RTEMS better than anyone
+else; furthermore, the RTEMS developers tend to have a wide breadth
+of experience across a large number of processors, boards, peripherals,
+and application domains. It has been our experience that few problems
+encountered in embedded systems development are unique to a particular
+processor or application. The vast majority of the time an issue that
+arises in one project has also shown up in other projects.
+
+The intimate knowledge of RTEMS internals as well as a wide breadth of
+embedded systems knowledge means that there is a good chance that at
+least one RTEMS developer has already addressed issues you are likely
+to face when doing your port, BSP, or application. The developers can
+help guide you towards a workable long term solution, possibly saving
+you significant time in your development cycle.
+
+If getting the sources into the official RTEMS distributions is one of
+your goals, then engaging other RTEMS developers early will also likely
+shorten your development time. By interacting as early as possible you
+are more likely to write code which can be easily accepted into the official
+sources when you are finished. If you wait until you think you are done
+to begin interacting with the RTEMS team, you might find that you did
+some things wrong and you may have to rewrite parts of your RTEMS port,
+which is a waste of your valuable time.
+
+
+Why should we integrate our port into the official RTEMS sources? 
+--
+
+Why should we care if our port is integrated into the official RTEMS sources? 
+We can distribute it ourselves to whoever is interested.
+
+
+
+Yes, the RTEMS licenses allows you to do that. But by doing so, you end up
+having to maintain that code yourself; this can be a significant
+effort over time as the RTEMS sources change rapidly.
+
+You also lose the advantage of wider exposure by including your port
+in the official RTEMS sources maintained by the RTEMS Project.
+The wider exposure in the RTEMS developer and tester community will
+help keep your work up to date with the current sources. You may even
+find that volunteers will run the ever-growing test suite on your port
+and fix problems during the development cycle -- sometimes without your
+intervention.
+
+It has been our experience that integrated ports tend to ultimately
+be of better quality and stay up to date from release to release.
+
+
+Aspects of my target environment that my application exploits are still under 
NDA
+-
+
+Nevertheless, if the target hardware is built of any commercial parts
+that are generally available including, but not limited to, the CPU
+or peripherals, then that portion of your work is still of general use.
+Similarly, if you have written software that adheres to existing API or
+interface standards, then that portion is also of general use.
+Our experience is that most embedded applications do utilize a custom
+mix of hardware and application, but they are built upon layers of hardware
+and software components that are in no way unique to the project.
+
+If you are porting to an unreleased CPU family or model, then just
+announcing it is important because other RTEMS users may be planning
+to use it and some of them may already be trying to port RTEMS on
+their own. Your customers might be happier to know that your port
+will eventually be available. Also, there is no requirement that RTEMS
+include all features or ports at any particular time, so you are encouraged
+to submit discrete pieces of functionality in stages.
+
+Assume that your processor has some new functionality or peripherals.
+However that functionality is still covered by NDA, but the basic core
+architecture is not. It is still to your advantage to go ahead and work
+with the developers early to provide a "base port" for the CPU family.
+That base port would only use the publicly available specifications
+until such time as the NDA is lifted. Once the NDA 

[PATCH 1/2] Added FAQ page

[Ayushman Mishra]

---
 user/bld/index.rst   |   4 +-
 user/overview/index.rst  |   2 +
 user/start/faq.rst   | 255 +++
 user/start/index.rst |   1 +
 user/support/support-project.rst |   2 +
 5 files changed, 263 insertions(+), 1 deletion(-)
 create mode 100644 user/start/faq.rst

diff --git a/user/bld/index.rst b/user/bld/index.rst
index ebedf5a..a8a8a4f 100644
--- a/user/bld/index.rst
+++ b/user/bld/index.rst
@@ -82,7 +82,7 @@ specifies paths to build specification items.  It is an 
advanced option and
 there is normally no need to use it.  It may be used to customize the build at
 the level of the build specification.  For more information see the
 `Build System` chapter of the
-`RTEMS Software Engineering 
`_
+`RTEMS Software Engineering 
`_
 guide.
 
 Help
@@ -283,6 +283,8 @@ example configuration file, building of the tests is 
enabled for the
 [sparc/erc32]
 
 [riscv/griscv]
+
+.. _Autoconf_migration:
 
 Migration from Autoconf/Automake
 
diff --git a/user/overview/index.rst b/user/overview/index.rst
index 550724a..0703ede 100644
--- a/user/overview/index.rst
+++ b/user/overview/index.rst
@@ -20,6 +20,8 @@ You are someone looking for a real-time operating system.  
This document
 
 - helps you to build an example application on top of RTEMS.
 
+.. _Features:
+
 Features
 
 
diff --git a/user/start/faq.rst b/user/start/faq.rst
new file mode 100644
index 000..da11ca4
--- /dev/null
+++ b/user/start/faq.rst
@@ -0,0 +1,255 @@
+Frequently Asked Questions
+==
+
+What is RTEMS ?
+---
+
+RTEMS is an open source real-time executive which provides a high performance 
+environment for embedded real-time applications including many features.
+
+The RTEMS Project is the umbrella term used to describe the collection of 
+individuals, companies, universities, and research institutions that 
collectively
+maintain and enhance the RTEMS software base.
+
+RTEMS is designed to support applications with the most stringent real-time 
+requirements while being compatible with open standards such as POSIX. 
+RTEMS includes optional functional features such as TCP/IP and various file 
+systems while still offering minimum executable sizes under 20 KB in useful 
+configurations.
+
+:ref:`More Features`
+
+Where can I ​get RTEMS ?
+-
+
+:ref:`Downloading RTEMS`
+
+
+What does RTEMS stand for ?
+-
+
+RTEMS is an an acronym for the Real-Time Executive for Multiprocessor Systems.
+
+Initially RTEMS stood for the Real-Time Executive for Missile Systems but as it
+became clear that the application domains that could use RTEMS extended far 
+beyond missiles, the "M" changed to mean Military. When maintenance of RTEMS 
+transferred to OAR, the "M" was changed again to Multiprocessor.
+
+At one point, there were both Ada and C implementations of RTEMS. 
+Version 3.2.1 was the last RTEMS version to have implementations in both 
+languages. Supporting the Classic API Ada implementation was painful and 
fraught
+with compiler specific pitfalls. With version 3.5.x, the POSIX API was added as
+the means to support the GNU Ada Translator (GNAT). This effectively 
eliminated 
+the need for an implementation in Ada as the C implementation could 
effectively 
+support both languages.
+
+
+Are there restrictions on the ​RTEMS License ?
+
+
+RTEMS is licensed under a modified version of the GNU General Public License 
(GPL).
+The modification places no restrictions on the applications which use RTEMS but
+protects the interests of those who work on RTEMS.
+
+`License in RTEMS
+`__
+
+
+What standards are supported by RTEMS?
+-
+
+The original "Classic" RTEMS API is based on the Real-Time Executive Interface 
+Definition (RTEID) and the Open Real-Time Kernel Interface Definition (ORKID). 
+RTEMS also includes support for POSIX threads and real-time extensions.
+
+With the addition of file system infrastructure, RTEMS supports approximately 
+80% of the POSIX 1003.1b-1996 standard. This standard defines the programming 
+interfaces of standard UNIX. This means that much source code that works on 
+UNIX, also works on RTEMS.RTEMS includes a port of the FreeBSD TCP/IP stack and
+thus supports BSD sockets. It also includes support for numerous networking 
+clients (DHCP, TFTP, NFS, etc.) and servers (FTPD, HTTPD, etc.).
+
+
+What processors is RTEMS available for ?
+--
+
+:ref:`Architectures in RTEMS`
+
+
+
+Are there similar 

Re: Policy for return by reference values in error cases

[Joel Sherrill]

On Tue, Mar 23, 2021 at 12:58 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 23/03/2021 18:48, Joel Sherrill wrote:
>
> > My first thought is that I don't like covering up for applications
> > that do the wrong thing.
> This topic just came up recently in a discussion about defensive
> programming. We also test for NULL pointers.
> >
> > I'm overall rather ambiguous. It is possible that setting the value at
> > the top of the function could lead to overridden before used issues
> > with warnings and static analysis.
>
> You mean code like this:
>
> void (int *x, int y)
>
> {
>
>*x = 0;
>
>   if (y) {
>
> *x = 1;
>
> } else {
>
>   *x = 2;
>
> }
>
> ?
>

Yep. That's a pretty clear case.

Others should speak up but I just don't want the solution pattern
to introduce warnings or static analysis reports. It easily could.



> > I don't want to see every error case assign a value to an output
> > parameter though.
> Yes, I don't like this also.
>

I have my own wish list for error paths eventually if we ever get bored. :)


--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: Standalone repository for libnetworking stack

[Joel Sherrill]

On Tue, Mar 23, 2021 at 11:27 AM Vijay Kumar Banerjee 
wrote:

> Hi,
>
> I have prepared and rebased all the patches to the current master. Please
> review the commits.
>
> RTEMS patches:
> https://git.rtems.org/vijay/rtems.git/log/?h=devel-no-libnet
> RTEMS net-legacy patch to pull recent changes:
> https://git.rtems.org/vijay/rtems-net-legacy.git/commit/?id=2b4738734f9d678a458b64278c0ff95dea588b1e
> RTEMS libbsd patch to add telnetd:
> https://git.rtems.org/vijay/rtems-libbsd.git/commit/?id=6bda703964e8cbbf73cb21f52fb7ceeb3cb3a541
>
> With these patches, the relocation work would be complete. I have tested
> all these patches are building with all the RTEMS bsps in bsp_defaults
> using waf.
>

Great! Is there any reason not to move the repo to the top level and delete
the networking from the main rtems repository?

And to make a news announcements.

--joel

>
>
> Best regards,
> Vijay
>
>
> On Wed, Mar 10, 2021 at 11:43 AM Chris Johns  wrote:
>
>>
>>
>> On 11/3/21 5:14 am, Joel Sherrill wrote:
>> >
>> >
>> > On Wed, Mar 10, 2021 at 11:48 AM Chris Johns > > > wrote:
>> >
>> >
>> >
>> > On 11/3/21 1:11 am, Joel Sherrill wrote:
>> > > On Tue, Mar 9, 2021 at 11:00 PM Vijay Kumar Banerjee <
>> vi...@rtems.org
>> > 
>> > > >> wrote:
>> > >
>> > > On Tue, Mar 9, 2021 at 9:56 PM Chris Johns > > 
>> > > >> wrote:
>> > > >
>> > > > On 10/3/21 3:51 pm, Gedare Bloom wrote:
>> > > > > On Tue, Mar 9, 2021 at 6:58 PM Joel Sherrill <
>> j...@rtems.org
>> > 
>> > > >> wrote:
>> > > > >> On Tue, Mar 9, 2021, 3:28 PM Vijay Kumar Banerjee
>> > mailto:vi...@rtems.org>
>> > > >> wrote:
>> > > > >>> On Fri, Mar 5, 2021 at 10:03 AM Vijay Kumar Banerjee
>> > mailto:vi...@rtems.org>
>> > > >> wrote:
>> > > > >>> In this proposed set of patches, I have removed telnetd
>> from
>> > RTEMS and
>> > > > >>> have placed it in the net-legacy repo, it seems like
>> libbsd uses
>> > > > >>> telnetd as well. Do we want to keep it in RTEMS and
>> remove it
>> > from the
>> > > > >>> legacy net repo?  There are checks in for
>> RTEMS_NETWORKING in
>> > telnetd,
>> > > > >>> to add rtems_bsdnet.h, how do we want to deal with
>> that? In the
>> > legacy
>> > > > >>> repo, we can just remove these checks and let them
>> build.
>> > > > >>
>> > > > >>
>> > > > >> Move it and remove rtems networking conditional. Freezes
>> it with
>> > legacy
>> > > stack.
>> > > > >>
>> > > > >> Just my opinion
>> > > > >>
>> > > > > Is there a different telnetd in libbsd?
>> > > >
>> > > > Yes ...
>> > > >
>> > > > https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/telnetd
>> > 
>> > > > > >
>> > > >
>> > > This seems to include rtems/telnetd.h
>> > > Does the libbsd telnetd depend on the cpukit/telnetd?
>> > >
>> > > > > The longer term pseudo-goal of being able to
>> (potentially) build
>> > > > > multiple networking stacks and pick which one to link
>> against may also
>> > > > > be a consideration at this stage.
>> > > >
>> > > > Are there issues? If there are issues do we know what they
>> are?
>> > >
>> > >
>> > > I guess the bigger question is what network services should
>> remain in
>> > > rtems itself and work with any stack.
>> > >
>> > > We have at least telnetd and the web server. If they build
>> against the
>> > > standard network headers, then they should work any stack that
>> uses
>> > > those.
>> > >
>> > > For maintenance, it would be preferable to only have one which all
>> > > stacks use. But this means rtems itself could be built with
>> network
>> > > services and no stack. I guess this is preferable to having:our
>> own
>> > > cross stack network services package.
>> > >
>> > > + RTEMS kernel
>> > > + pick your stack
>> > > + RTEMS specific network services
>> > > + Ports of standard network services (SNMP, NTP, ACE/TAO, etc)
>> > >
>> > > At this point, it concerns me to add more and more packages
>> because we
>> > > tend to not have automation to build/test as many beyond the core
>> RTEMS
>> > > as we should.
>> > >
>> > > Based on that alone, I'd prefer to unify "RTEMS specific 

Re: GSoC project: Memory protection (Ticket no: 2904)

[Hesham Almatary]

On Tue, 23 Mar 2021 at 17:14, Gedare Bloom  wrote:
>
> CC: Hesham
> CC: devel
>
> On Tue, Mar 23, 2021 at 6:34 AM Rajiv Vaidyanathan
>  wrote:
> >
> > Dear Gedare,
> >
> > Thank you for providing information regarding the project. For risk-v MMU 
> > support, will I require to have hardware?
> >
> That's a good question. I don't know if the current risc-v simulators
> support the risc-v mmu. maybe, another expert could advise. I have
> CC'd someone with experience in both risc-v and memory protection.
>
Yes, both Spike and QEMU have MMU and PMP support.

> Let's keep technical discussions on the mailing list. Thanks.
>
> > Thanks and regards,
> > Rajiv
> >
> > On Mon, 22 Mar 2021 at 21:54, Gedare Bloom  wrote:
> >>
> >> Hi Rajiv,
> >>
> >> On Sat, Mar 20, 2021 at 12:40 AM Rajiv Vaidyanathan
> >>  wrote:
> >> >
> >> > Hello RTEMS community,
> >> >
> >> > I am interested in the ticket: Memory protection. I saw that this topic 
> >> > has been pursued a few times in GSoC. It would be great if someone can 
> >> > let me know the current status of this project and guide me about what 
> >> > are the contributions that can be done this year.
> >> >
> >> Yes, this is a frequently attempted project that slowly makes progress
> >> over time. I think that Utkarsh has gotten somewhat close to a
> >> workable solution, but there were some design flaws in his approach
> >> for task stack protection (mainly, iterating over all the tasks) that
> >> are still lingering.
> >>
> >> There could be enough work here to pick up from his progress. The
> >> major issue would be figuring out what  the final state of his code is
> >> in, and to dig in to the design and implementation details to write a
> >> concrete proposal how to bring task stack protection to a production
> >> state. There may be other directions to consider as well, such as
> >> improving the risc-v MMU support perhaps.
> >>
> >> > Thanks and regards,
> >> > Rajiv
> >> > ___
> >> > devel mailing list
> >> > devel@rtems.org
> >> > http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps: Removed INI files using outdated options

[Joel Sherrill]

bsps: Removed INI files using outdated options

Better would be

sparc bsps: Remove INI files using SIS in GDB

On Tue, Mar 23, 2021 at 1:13 PM Ryan Long  wrote:

> Removed the INI files that use the "target sim" option in gdb
> since this is no longer supported.
>

This needs to be more accurate.

Specifically, the sis sparc simulator in gdb is no longer used with RTEMS
and
we use a newer version of SIS built separately.

This ONLY impacts the SPARC.

--joel


>
> Closes #4355
> ---
>  tester/rtems/testing/bsps/erc32.ini | 41
> -
>  tester/rtems/testing/bsps/leon2.ini | 41
> -
>  tester/rtems/testing/bsps/leon3.ini | 41
> -
>  3 files changed, 123 deletions(-)
>  delete mode 100644 tester/rtems/testing/bsps/erc32.ini
>  delete mode 100644 tester/rtems/testing/bsps/leon2.ini
>  delete mode 100644 tester/rtems/testing/bsps/leon3.ini
>
> diff --git a/tester/rtems/testing/bsps/erc32.ini
> b/tester/rtems/testing/bsps/erc32.ini
> deleted file mode 100644
> index 7911a2f..000
> --- a/tester/rtems/testing/bsps/erc32.ini
> +++ /dev/null
> @@ -1,41 +0,0 @@
> -#
> -# RTEMS Tools Project (http://www.rtems.org/)
> -# Copyright 2015 On-Line Applications Research Corporation (OAR).
> -# All rights reserved.
> -#
> -# This file is part of the RTEMS Tools package in 'rtems-tools'.
> -#
> -# Redistribution and use in source and binary forms, with or without
> -# modification, are permitted provided that the following conditions are
> met:
> -#
> -# 1. Redistributions of source code must retain the above copyright
> notice,
> -# this list of conditions and the following disclaimer.
> -#
> -# 2. Redistributions in binary form must reproduce the above copyright
> notice,
> -# this list of conditions and the following disclaimer in the
> documentation
> -# and/or other materials provided with the distribution.
> -#
> -# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
> IS"
> -# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
> THE
> -# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> -# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS
> BE
> -# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> -# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> -# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> -# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> -# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> -# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
> THE
> -# POSSIBILITY OF SUCH DAMAGE.
> -#
> -
> -#
> -# The erc32 BSP
> -#
> -[erc32]
> -bsp= erc32
> -arch   = sparc
> -tester = %{_rtscripts}/gdb.cfg
> -gdb_script = bsp_gdb_script
> -bsp_gdb_script = target sim
> - load
> - run
> diff --git a/tester/rtems/testing/bsps/leon2.ini
> b/tester/rtems/testing/bsps/leon2.ini
> deleted file mode 100644
> index 77fed49..000
> --- a/tester/rtems/testing/bsps/leon2.ini
> +++ /dev/null
> @@ -1,41 +0,0 @@
> -#
> -# RTEMS Tools Project (http://www.rtems.org/)
> -# Copyright 2015 On-Line Applications Research Corporation (OAR).
> -# All rights reserved.
> -#
> -# This file is part of the RTEMS Tools package in 'rtems-tools'.
> -#
> -# Redistribution and use in source and binary forms, with or without
> -# modification, are permitted provided that the following conditions are
> met:
> -#
> -# 1. Redistributions of source code must retain the above copyright
> notice,
> -# this list of conditions and the following disclaimer.
> -#
> -# 2. Redistributions in binary form must reproduce the above copyright
> notice,
> -# this list of conditions and the following disclaimer in the
> documentation
> -# and/or other materials provided with the distribution.
> -#
> -# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
> IS"
> -# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
> THE
> -# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> -# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS
> BE
> -# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> -# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> -# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> -# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> -# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> -# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
> THE
> -# POSSIBILITY OF SUCH DAMAGE.
> -#
> -
> -#
> -# The leon2 BSP
> -#
> -[leon2]
> -bsp= leon2
> -arch   = sparc
> -tester = %{_rtscripts}/gdb.cfg
> -gdb_script = 

Re: GSoC Project : Package Micro-python

[Eshan Dhawan]

Apologies for the late reply.

On Mon, Mar 22, 2021 at 10:27 PM Joel Sherrill  wrote:

>
>
> On Mon, Mar 22, 2021 at 11:55 AM Gedare Bloom  wrote:
>
>> On Mon, Mar 22, 2021 at 10:50 AM Joel Sherrill  wrote:
>> >
>> >
>> >
>> > On Mon, Mar 22, 2021 at 11:30 AM Gedare Bloom  wrote:
>> >>
>> >> On Sat, Mar 20, 2021 at 12:33 PM Eshan Dhawan 
>> wrote:
>> >> >
>> >> > Hello Everyone,
>> >> > I wanted to take Packaging Micro Python up as GSOC project this
>> summer and the project will also include packaging LUA and picoC
>> >> > The ticket for Micro Python  : https://devel.rtems.org/ticket/4349
>> >> > What would be the complete Scope of the project?
>> >> > And what would be a good starting point?
>> >> >
>> >>
>> >> Well, I guess Joel must have described the task, so I'll leave it to
>> >> him to fill in some more details.
>> >>
>> >> Adding RSB packages may be not sufficient coding work for GSoC. It is
>> >> important in the proposal to identify what would be the coding
>> >> activities involved in this project. For example, we know from
>> >> experience that Lua can just be built from some minor tailoring of its
>> >> Makefile, so the package is very straightforward. However, the
>> >> projects you mention are scripting environments, so maybe creating a
>> >> framework in RTEMS for a "shell/intepreter" that can be built as an
>> >> add-on by RSB would be a proper way to scope this effort
>>
> Packaging might not be a lot of coding part but adding its documentation
and its example would be a very iterative and time consuming process.

> >
>> >
>> > I agree that Lua and Micropython should build easy but I had more
>> > in mind.
>> >
>> > The full project was language stacks for RTEMS with a better user
>> > experience for Micropython, Lua, Tcl, etc although I am not sure what
>> > etc would entail. I am not sure all three can be completed in the new
>> > GSoC timeframe. All would follow the same pattern:
>>
> Etc can be managed while framing the proposal according to how time is
being managed.

> >
>> > + RSB package offering a reasonable default and access to configuration
>> > + Examples including at least bare embedded, use of custom commands,
>> > and integrating with RTEMS shell commands Perhaps  interactive use with
>> > command line history and editing integrated if we have that as a
>> library now.
>> > + Documentation specific to RTEMS and the examples
>> >
>> > I imagined completely parallel kits for each embedded language we wanted
>> > to support.
>> >
>> > Does that help? Should he plan on Micropython and Lua?
>> >
>>
>> Sure. Lua should be easy way to get started and develop the
>> framework/infrastructure side in Phase 1. Phase 2 could be extension
>> to micropython / other scripting languages.
>>
> Since all the languages will have a similar pattern complex work can be
put in phase 2.
>From my past experience, it is the part when most work is done :)

>
> OK.
>
>>
>> I'm not sure about the RSB design of things, and whether they should
>> be parallel or capable of integration. Would anyone want to use
>> multiple interpreters in the same application? If so, they should
>> build together to avoid conflicts. If not, parallel is fine.
>>
> building them can be set to build flags,
but there still needs to be a way if we want to build the package other
than the default way.
(any ideas on how to do that )

>
> I don't see any reason on our side why that shouldn't work but we
> can't guarantee they don't have symbol conflicts. And I'm not sure
> it would make much sense to integrate both at the same time.
>
> I'd think you could install both but we'd focus on only using one
> at a time.
>
> --joel
>
>>
>> > --joel
>> >
>> >>
>> >> > Thanks
>> >> > - Eshan
>> >> > ___
>> >> > 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] bsps: Removed INI files using outdated options

[Ryan Long]

Removed the INI files that use the "target sim" option in gdb
since this is no longer supported.

Closes #4355
---
 tester/rtems/testing/bsps/erc32.ini | 41 -
 tester/rtems/testing/bsps/leon2.ini | 41 -
 tester/rtems/testing/bsps/leon3.ini | 41 -
 3 files changed, 123 deletions(-)
 delete mode 100644 tester/rtems/testing/bsps/erc32.ini
 delete mode 100644 tester/rtems/testing/bsps/leon2.ini
 delete mode 100644 tester/rtems/testing/bsps/leon3.ini

diff --git a/tester/rtems/testing/bsps/erc32.ini 
b/tester/rtems/testing/bsps/erc32.ini
deleted file mode 100644
index 7911a2f..000
--- a/tester/rtems/testing/bsps/erc32.ini
+++ /dev/null
@@ -1,41 +0,0 @@
-#
-# RTEMS Tools Project (http://www.rtems.org/)
-# Copyright 2015 On-Line Applications Research Corporation (OAR).
-# All rights reserved.
-#
-# This file is part of the RTEMS Tools package in 'rtems-tools'.
-#
-# Redistribution and use in source and binary forms, with or without
-# modification, are permitted provided that the following conditions are met:
-#
-# 1. Redistributions of source code must retain the above copyright notice,
-# this list of conditions and the following disclaimer.
-#
-# 2. Redistributions in binary form must reproduce the above copyright notice,
-# this list of conditions and the following disclaimer in the documentation
-# and/or other materials provided with the distribution.
-#
-# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
-# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
-# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
-# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
-# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
-# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
-# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
-# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
-# POSSIBILITY OF SUCH DAMAGE.
-#
-
-#
-# The erc32 BSP
-#
-[erc32]
-bsp= erc32
-arch   = sparc
-tester = %{_rtscripts}/gdb.cfg
-gdb_script = bsp_gdb_script
-bsp_gdb_script = target sim
- load
- run
diff --git a/tester/rtems/testing/bsps/leon2.ini 
b/tester/rtems/testing/bsps/leon2.ini
deleted file mode 100644
index 77fed49..000
--- a/tester/rtems/testing/bsps/leon2.ini
+++ /dev/null
@@ -1,41 +0,0 @@
-#
-# RTEMS Tools Project (http://www.rtems.org/)
-# Copyright 2015 On-Line Applications Research Corporation (OAR).
-# All rights reserved.
-#
-# This file is part of the RTEMS Tools package in 'rtems-tools'.
-#
-# Redistribution and use in source and binary forms, with or without
-# modification, are permitted provided that the following conditions are met:
-#
-# 1. Redistributions of source code must retain the above copyright notice,
-# this list of conditions and the following disclaimer.
-#
-# 2. Redistributions in binary form must reproduce the above copyright notice,
-# this list of conditions and the following disclaimer in the documentation
-# and/or other materials provided with the distribution.
-#
-# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
-# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
-# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
-# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
-# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
-# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
-# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
-# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
-# POSSIBILITY OF SUCH DAMAGE.
-#
-
-#
-# The leon2 BSP
-#
-[leon2]
-bsp= leon2
-arch   = sparc
-tester = %{_rtscripts}/gdb.cfg
-gdb_script = bsp_gdb_script
-bsp_gdb_script = target sim -leon2
- load
- run
diff --git a/tester/rtems/testing/bsps/leon3.ini 
b/tester/rtems/testing/bsps/leon3.ini
deleted file mode 100644
index 74eafb7..000
--- a/tester/rtems/testing/bsps/leon3.ini
+++ /dev/null
@@ -1,41 +0,0 @@
-#
-# RTEMS Tools Project (http://www.rtems.org/)
-# Copyright 2015 On-Line Applications Research Corporation (OAR).
-# All rights reserved.
-#
-# This file is part of the RTEMS Tools package in 'rtems-tools'.
-#
-# Redistribution and use in source and binary forms, with or without
-# modification, are permitted provided 

Re: Policy for return by reference values in error cases

[Sebastian Huber]

On 23/03/2021 18:48, Joel Sherrill wrote:

My first thought is that I don't like covering up for applications 
that do the wrong thing.
This topic just came up recently in a discussion about defensive 
programming. We also test for NULL pointers.


I'm overall rather ambiguous. It is possible that setting the value at 
the top of the function could lead to overridden before used issues 
with warnings and static analysis.


You mean code like this:

void (int *x, int y)

{

  *x = 0;

 if (y) {

   *x = 1;

} else {

 *x = 2;

}

?

I don't want to see every error case assign a value to an output 
parameter though.

Yes, I don't like this also.

--
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 v5] cpukit/aarch64: Add ESR register decoding

[Sebastian Huber]

On 23/03/2021 18:42, Joel Sherrill wrote:


> > +  mask = 1 << (num_bits - 1);
> > +
> > +  while ( mask != 0 ) {
> > +    _IO_Printf( _CPU_Put_char, , "%d", (value & mask ? 1 : 0) );
> > +    mask >>= 1;
> > +  }


The _IO_Vprintf() is a port from the FreeBSD kvprintf(). I removed the 
support for this:


/*
 * Scaled down version of printf(3).
 *
 * Two additional formats:
 *
 * The format %b is supported to decode error registers.
 * Its usage is:
 *
 *    printf("reg=%b\n", regval, "*");
 *
 * where  is the output base expressed as a control character, e.g.
 * \10 gives octal; \20 gives hex.  Each arg is a sequence of characters,
 * the first of which gives the bit number to be inspected (origin 1), and
 * the next characters (up to a control character, i.e. a character <= 32),
 * give the name of the register.  Thus:
 *
 *    kvprintf("reg=%b\n", 3, "\10\2BITTWO\1BITONE");

We could also a a special %B specifier to produce 0b0100 stuff.

--
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: Policy for return by reference values in error cases

[Joel Sherrill]

On Tue, Mar 23, 2021, 12:30 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> for the RTEMS pre-qualification project I review currently most parts of
> the Classic API. It seems we have an unwritten rule that directives
> should not write to variables referenced by directive parameters if an
> error occurs. Examples:
>
> * rtems_task_mode(previous_mode)
>
> * rtems_task_set_priority(previous_priority)
>
> * rtems_message_queue_receive(message_size)
>
> * rtems_event_receive(received_events)
>
> We should think about changing this rule to instead return "safe" values
> in error conditions. For example, lets have an application bug I
> encountered this year. The code originally looked like this:
>
> #define APP_TIMEOUT RTEMS_NO_TIMEOUT
>
> rtems_event_set events;
>
> (void) rtems_event_receive(
>
>  RTEMS_ALL_EVENTS,
>  RTEMS_EVENT_ANY | RTEMS_WAIT,
>  APP_TIMEOUT,
>  
>);
>
> if (event & X) != 0) {
>
> ...
>
> }
>
> Ok, you should check the return value, but ...
>
> Something didn't go well and someone changed APP_TIMEOUT:
>
> #define APP_TIMEOUT 1000
>
> Now, sometimes the rtems_event_receive() timed out and the application
> worked with events produced by the stack frame and not
> rtems_event_receive(). In the case of rtems_message_queue_receive() it
> would be the message size.
>
> In order to let broken applications fail a bit more gracefully, it would
> help to set the events and the message size to zero if the directive
> returns with an error. The modes could be set to the defaults, the
> priority to some invalid value, etc.
>
> What do you think?
>

My first thought is that I don't like covering up for applications that do
the wrong thing.

I'm overall rather ambiguous. It is possible that setting the value at the
top of the function could lead to overridden before used issues with
warnings and static analysis. I don't want to see every error case assign a
value to an output parameter though.

--joel


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

Re: NULL for return by reference values: error or ignore?

[Joel Sherrill]

On Tue, Mar 23, 2021, 12:36 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> we have a couple of directives which set something and return the
> previous value, for example rtems_task_mode() and
> rtems_task_set_priority(). The value is returned through a pointer
> parameter. If this pointer is NULL, then the directives do nothing and
> just returns an error status. Why don't we simply not return a value in
> this case, so that you can set the task priority via
> rtems_task_set_priority(id, priority, NULL)?
>

I'm okay with this. It seems more in keeping with the POSIX behavior.

--joel

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

Re: [PATCH v5] cpukit/aarch64: Add ESR register decoding

[Joel Sherrill]

On Tue, Mar 23, 2021, 12:26 PM Alex White  wrote:

> On Tue, Mar 23, 2021 at 11:46 AM Gedare Bloom  wrote:
> >
> > On Tue, Mar 23, 2021 at 10:31 AM Alex White 
> wrote:
> > >
> > > ---
> > >  .../aarch64/aarch64-exception-frame-print.c   | 133 --
> > >  1 file changed, 123 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/cpukit/score/cpu/aarch64/aarch64-exception-frame-print.c
> b/cpukit/score/cpu/aarch64/aarch64-exception-frame-print.c
> > > index 59b5d06032..a8c492b1da 100644
> > > --- a/cpukit/score/cpu/aarch64/aarch64-exception-frame-print.c
> > > +++ b/cpukit/score/cpu/aarch64/aarch64-exception-frame-print.c
> > > @@ -45,10 +45,111 @@
> > >  #include 
> > >
> > >  #include 
> > > +#include 
> > >  #include 
> > >
> > > +typedef struct {
> > > +   char *s;
> > > +   size_t n;
> > > +} String_Context;
> > > +
> > > +static void _CPU_Put_char( int c, void *arg )
> > > +{
> > > +  String_Context *sctx = arg;
> > > +  size_t n = sctx->n;
> > > +
> > > +  if (n > 0) {
> > > +char *s = sctx->s;
> > > +*s = (char) c;
> > > +sctx->s = s + 1;
> > > +sctx->n = n - 1;
> > > +  }
> > > +}
> > > +
> > > +static void _CPU_Binary_sprintf(
> > > +  char *s,
> > > +  size_t maxlen,
> > > +  uint32_t num_bits,
> > > +  uint32_t value
> > > +)
> > > +{
> > > +  String_Context sctx;
> > > +  uint32_t mask;
> > > +
> > > +  sctx.s = s;
> > > +  sctx.n = maxlen;
> > > +
> > > +  mask = 1 << (num_bits - 1);
> > > +
> > > +  while ( mask != 0 ) {
> > > +_IO_Printf( _CPU_Put_char, , "%d", (value & mask ? 1 : 0) );
> > > +mask >>= 1;
> > > +  }
> >
> > should this function default to NUL-terminate s?
> >
> > I'm not totally familiar with the usage, but usually that is the
> > expectation of an sprintf() kind of function.
>
> I decided that the function should not NULL-terminate in this case
> because it is only used in two places, and I zero-initialize the
> character buffers before both calls.
>
> I realize that NULL-termination would make the function more generally
> useful, but I only wrote it as a quick static helper for this file.
>
> Is it worth NULL-terminating to avoid a possible bug being introduced
> in the future if someone assumes that it is NULL-terminating?
>

Yeah.  I've been around long enough where not null terminating it will
actually cause someone a problem. And you should never have to zero
something out if you fill it out properly. :)



> >
> > > +}
> > > +
> > > +static const char* _CPU_Exception_class_to_string( uint16_t
> exception_class )
> > > +{
> > > +  switch ( exception_class ) {
> > > +case 0x01:
> > > +  return "Trapped WFI or WFE instruction";
> > > +case 0x03:
> > > +  return "Trapped MCR or MRC access with (coproc==0b)";
> > > +case 0x04:
> > > +  return "Trapped MCRR or MRRC access with (coproc==0b)";
> > > +case 0x05:
> > > +  return "Trapped MCR or MRC access with (coproc==0b1110)";
> > > +case 0x06:
> > > +  return "Trapped LDC or STC access";
> > > +case 0x0c:
> > > +  return "Trapped MRRC access with (coproc==0b1110)";
> > > +case 0x0e:
> > > +  return "Illegal Execution state";
> > > +case 0x18:
> > > +  return "Trapped MSR, MRS, or System instruction";
> > > +case 0x20:
> > > +  return "Instruction Abort from a lower Exception level";
> > > +case 0x21:
> > > +  return "Instruction Abort taken without a change in Exception
> level";
> > > +case 0x22:
> > > +  return "PC alignment fault";
> > > +case 0x24:
> > > +  return "Data Abort from a lower Exception level";
> > > +case 0x25:
> > > +  return "Data Abort taken without a change in Exception level";
> > > +case 0x26:
> > > +  return "SP alignment fault";
> > > +case 0x30:
> > > +  return "Breakpoint exception from a lower Exception level";
> > > +case 0x31:
> > > +  return "Breakpoint exception taken without a change in
> Exception level";
> > > +case 0x32:
> > > +  return "Software Step exception from a lower Exception level";
> > > +case 0x33:
> > > +  return "Software Step exception taken without a change in
> Exception "
> > > + "level";
> >
> > This is a case where I would say allowing the string to spill over the
> > 80c is better. I think that having a long string (say 40+ characters)
> > can justify violating this 80c limit. It would be best for someone to
> > agree with me though :)
>
> I agree that it would look better if I allowed this line to exceed the
> 80 character limit. Those darn coding conventions...
>
> Hopefully others agree to an exception here.
>

I agree. Put a comment above the switch that it is deliberately violated.

Seeing the values in makes it clear that there are categories to these
values based on the first nibble. I don't know that there's any value to
taking advantage of that but the pattern is there. Perhaps if more the
message can be common but only if the first nibble is used to 

NULL for return by reference values: error or ignore?

[Sebastian Huber]

Hello,

we have a couple of directives which set something and return the 
previous value, for example rtems_task_mode() and 
rtems_task_set_priority(). The value is returned through a pointer 
parameter. If this pointer is NULL, then the directives do nothing and 
just returns an error status. Why don't we simply not return a value in 
this case, so that you can set the task priority via 
rtems_task_set_priority(id, priority, NULL)?


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

Policy for return by reference values in error cases

[Sebastian Huber]

Hello,

for the RTEMS pre-qualification project I review currently most parts of 
the Classic API. It seems we have an unwritten rule that directives 
should not write to variables referenced by directive parameters if an 
error occurs. Examples:


* rtems_task_mode(previous_mode)

* rtems_task_set_priority(previous_priority)

* rtems_message_queue_receive(message_size)

* rtems_event_receive(received_events)

We should think about changing this rule to instead return "safe" values 
in error conditions. For example, lets have an application bug I 
encountered this year. The code originally looked like this:


#define APP_TIMEOUT RTEMS_NO_TIMEOUT

rtems_event_set events;

(void) rtems_event_receive(

    RTEMS_ALL_EVENTS,
    RTEMS_EVENT_ANY | RTEMS_WAIT,
    APP_TIMEOUT,
    
  );

if (event & X) != 0) {

...

}

Ok, you should check the return value, but ...

Something didn't go well and someone changed APP_TIMEOUT:

#define APP_TIMEOUT 1000

Now, sometimes the rtems_event_receive() timed out and the application 
worked with events produced by the stack frame and not 
rtems_event_receive(). In the case of rtems_message_queue_receive() it 
would be the message size.


In order to let broken applications fail a bit more gracefully, it would 
help to set the events and the message size to zero if the directive 
returns with an error. The modes could be set to the defaults, the 
priority to some invalid value, etc.


What do you think?

--
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 v5] cpukit/aarch64: Add ESR register decoding

[Alex White]

On Tue, Mar 23, 2021 at 11:46 AM Gedare Bloom  wrote:
>
> On Tue, Mar 23, 2021 at 10:31 AM Alex White  wrote:
> >
> > ---
> >  .../aarch64/aarch64-exception-frame-print.c   | 133 --
> >  1 file changed, 123 insertions(+), 10 deletions(-)
> >
> > diff --git a/cpukit/score/cpu/aarch64/aarch64-exception-frame-print.c 
> > b/cpukit/score/cpu/aarch64/aarch64-exception-frame-print.c
> > index 59b5d06032..a8c492b1da 100644
> > --- a/cpukit/score/cpu/aarch64/aarch64-exception-frame-print.c
> > +++ b/cpukit/score/cpu/aarch64/aarch64-exception-frame-print.c
> > @@ -45,10 +45,111 @@
> >  #include 
> >
> >  #include 
> > +#include 
> >  #include 
> >
> > +typedef struct {
> > +       char *s;
> > +       size_t n;
> > +} String_Context;
> > +
> > +static void _CPU_Put_char( int c, void *arg )
> > +{
> > +  String_Context *sctx = arg;
> > +  size_t n = sctx->n;
> > +
> > +  if (n > 0) {
> > +    char *s = sctx->s;
> > +    *s = (char) c;
> > +    sctx->s = s + 1;
> > +    sctx->n = n - 1;
> > +  }
> > +}
> > +
> > +static void _CPU_Binary_sprintf(
> > +  char *s,
> > +  size_t maxlen,
> > +  uint32_t num_bits,
> > +  uint32_t value
> > +)
> > +{
> > +  String_Context sctx;
> > +  uint32_t mask;
> > +
> > +  sctx.s = s;
> > +  sctx.n = maxlen;
> > +
> > +  mask = 1 << (num_bits - 1);
> > +
> > +  while ( mask != 0 ) {
> > +    _IO_Printf( _CPU_Put_char, , "%d", (value & mask ? 1 : 0) );
> > +    mask >>= 1;
> > +  }
>
> should this function default to NUL-terminate s?
>
> I'm not totally familiar with the usage, but usually that is the
> expectation of an sprintf() kind of function.

I decided that the function should not NULL-terminate in this case
because it is only used in two places, and I zero-initialize the
character buffers before both calls.

I realize that NULL-termination would make the function more generally
useful, but I only wrote it as a quick static helper for this file.

Is it worth NULL-terminating to avoid a possible bug being introduced
in the future if someone assumes that it is NULL-terminating?

>
> > +}
> > +
> > +static const char* _CPU_Exception_class_to_string( uint16_t 
> > exception_class )
> > +{
> > +  switch ( exception_class ) {
> > +    case 0x01:
> > +      return "Trapped WFI or WFE instruction";
> > +    case 0x03:
> > +      return "Trapped MCR or MRC access with (coproc==0b)";
> > +    case 0x04:
> > +      return "Trapped MCRR or MRRC access with (coproc==0b)";
> > +    case 0x05:
> > +      return "Trapped MCR or MRC access with (coproc==0b1110)";
> > +    case 0x06:
> > +      return "Trapped LDC or STC access";
> > +    case 0x0c:
> > +      return "Trapped MRRC access with (coproc==0b1110)";
> > +    case 0x0e:
> > +      return "Illegal Execution state";
> > +    case 0x18:
> > +      return "Trapped MSR, MRS, or System instruction";
> > +    case 0x20:
> > +      return "Instruction Abort from a lower Exception level";
> > +    case 0x21:
> > +      return "Instruction Abort taken without a change in Exception level";
> > +    case 0x22:
> > +      return "PC alignment fault";
> > +    case 0x24:
> > +      return "Data Abort from a lower Exception level";
> > +    case 0x25:
> > +      return "Data Abort taken without a change in Exception level";
> > +    case 0x26:
> > +      return "SP alignment fault";
> > +    case 0x30:
> > +      return "Breakpoint exception from a lower Exception level";
> > +    case 0x31:
> > +      return "Breakpoint exception taken without a change in Exception 
> > level";
> > +    case 0x32:
> > +      return "Software Step exception from a lower Exception level";
> > +    case 0x33:
> > +      return "Software Step exception taken without a change in Exception "
> > +             "level";
>
> This is a case where I would say allowing the string to spill over the
> 80c is better. I think that having a long string (say 40+ characters)
> can justify violating this 80c limit. It would be best for someone to
> agree with me though :)

I agree that it would look better if I allowed this line to exceed the
80 character limit. Those darn coding conventions...

Hopefully others agree to an exception here.

>
> Address the NUL termination, and decide how you want to proceed with
> the line length for string breaks. It's a gray area in the rules.
>
> > +    case 0x34:
> > +      return "Watchpoint exception from a lower Exception level";
> > +    case 0x35:
> > +      return "Watchpoint exception taken without a change in Exception 
> > level";
> > +    case 0x38:
> > +      return "BKPT instruction execution in AArch32 state";
> > +    case 0x3c:
> > +      return "BRK instruction execution in AArch64 state";
> > +    default:
> > +      return "Unknown";
> > +  }
> > +}
> > +
> >  void _CPU_Exception_frame_print( const CPU_Exception_frame *frame )
> >  {
> > +  uint32_t ec;
> > +  uint32_t il;
> > +  uint32_t iss;
> > +  char     ec_str[7] = { 0 };
> > +  char     iss_str[26] = { 0 };
> > +  int      i;
> > +  const uint128_t 

Re: GSoC Project - Beagle BSP Projects

[Utkarsh Rai]

On Tue, Mar 23, 2021 at 9:36 PM Nils Hölscher  wrote:

> Hi,
>
> Regarding the PRU.
> I was able to load code to the PRU.
> However I wasn't able to map IRQ interrupts to the PRU, thus unable to
> communicate with it in a meaningful way
>


Just a small addition, AFAIK the issue with this was the fact that mmap()
would always fail.


> .
> Also I don't think that this project should be continued without a full
> DEBUGGING Setup.
>

+1, without a proper debugging setup I found it hard to precisely pin point
the problem when I initially took up this task.


>
>
Best,
> Nils
>
> On Tue, 23 Mar 2021 at 17:00, Christian MAUDERER <
> christian.maude...@embedded-brains.de> wrote:
>
>> Hello Gedare,
>>
>> Am 23.03.21 um 16:48 schrieb Gedare Bloom:
>> > CC: Nils, Utkarsh
>> >
>> > On Tue, Mar 23, 2021 at 9:17 AM Christian MAUDERER
>> >  wrote:
>> >>
>> >> Hello Ahamed,
>> >>
>> >> Am 23.03.21 um 11:24 schrieb Ahamed Husni:
>> >>> Hi everyone,
>> >>>
>> >>> I'm really interested to work on the *Beagle BSP Projects* [#2891
>> >>> ]. *
>> >>> *
>> >>> *Adding PRU Support* [#3730 ]
>> >>> project seems really interesting to me.
>> >>> This project is partially done during GSoC 2019
>> >>> by Nils Hölscher .
>> >>> Is this a good project for the GSoC?
>> >>>
>> >>> Up to now I have,
>> >>>
>> >>>   1. Completed the GSoC prerequisite task
>> >>>   2. Got the required hardware and tested it. (Beagleboard Black, USB
>> to
>> >>>  TTL Converter)
>> >>>   3. Installed RTEMS on the Beagleboard and tested. (Screenshot
>> attached
>> >>>  below)
>> >>>
>> >>>
>> >>> I need guidance to define the scope of the project.
>> >>> I'm currently thinking of ,
>> >>>
>> >>>   1. First finish the remaining work from GSoC 2019 on the PRU.
>> >>>  (What is the status of current implementation of the PRU?)
>> >>
>> >> I'm really not sure what the state of the PRU is. I didn't follow that
>> >> project closely. Maybe one of the mentors of that project can say
>> >> anything regarding that.
>> >>
>> > Some more background:
>> > https://lists.rtems.org/pipermail/devel/2019-December/056478.html
>> > https://lists.rtems.org/pipermail/devel/2020-January/056958.html
>> >
>> > Maybe Utkarsh or Nils have more to say.
>> >
>> >>>   2. Implement additional peripheral support.
>> >>>  What would be most useful?
>> >>>  (USB OTG, CAN, ...).
>> >>
>> >> I think CAN is a bit hard without some CAN analyzer hardware as a peer.
>> >>
>> >> USB OTG would be a nice area. But that will be less writing a driver
>> for
>> >> Beagle but more finding out how that works with libbsd and finding a
>> >> good way to configure it. I once put a few hours into it didn't take
>> too
>> >> much time till a PC detected an USB device (see
>> >> https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce).
>> >> Basically it's about importing the "usb_template" stuff and finding a
>> >> way to configure it in libbsd.
>> >>
>> >> I think that topic would have to be a bit of an open one: You might
>> work
>> >> only a day on it and have a working CDC Ethernet afterwards or you can
>> >> need weeks for that. So you should add an open list of possible
>> advanced
>> >> targets. An OTG device can be:
>> >>
>> >> - Ethernet
>> >> - Serial port
>> >> - Mass storage
>> >> - Keyboard / Mouse
>> >> - Modem
>> >> - Audio
>> >> - ...
>> >>
>> >> The simplest one will most likely be Ethernet followed by serial port.
>> I
>> >> would add some of the others (like mass storage) as an extended
>> targets.
>> >>
>> > Yes, this seems like an area that can be chipped away at, with a
>> > strong plan of activities. My concern would be whether it is about
>> > writing code or not?
>> >
>>
>> It won't produce a lot of code. But it will produce relevant one:
>>
>> 1. Interface for configuration (if necessary)
>>
>> 2. Example application
>>
>> 3. Documentation
>>
>> For Ethernet and serial port that's most likely it. For Mass storage
>> there might be some more code. Without a too detailed look: I would
>> expect that the mass storage either implements some access to a raw
>> block device - in which case it would be necessary to add the access to
>> block devices. Or it implements something like the PTP stuff used on
>> smartphones in which case there will be most likely some code that
>> accesses the file system using POSIX functions instead of FreeBSD kernel
>> functions.
>>
>> Best regards
>>
>> Christian
>>
>> >> Best regards
>> >>
>> >> Christian
>> >>
>> >>>
>> >>>  The builtin USB is NOT functional other than for power under
>> RTEMS.
>> >>>  (USB OTG would have to be implemented in RTEMS to get rid of USB
>> to
>> >>>  TTL Converter.)
>> >>>  - Ben Gras
>> >>>  <
>> http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html
>> >
>> >>>  (Blog post)
>> >>>
>> >>>
>> >>> Thanks,
>> >>> 

Re: [PATCH v5] cpukit/aarch64: Add ESR register decoding

[Gedare Bloom]

On Tue, Mar 23, 2021 at 10:31 AM Alex White  wrote:
>
> ---
>  .../aarch64/aarch64-exception-frame-print.c   | 133 --
>  1 file changed, 123 insertions(+), 10 deletions(-)
>
> diff --git a/cpukit/score/cpu/aarch64/aarch64-exception-frame-print.c 
> b/cpukit/score/cpu/aarch64/aarch64-exception-frame-print.c
> index 59b5d06032..a8c492b1da 100644
> --- a/cpukit/score/cpu/aarch64/aarch64-exception-frame-print.c
> +++ b/cpukit/score/cpu/aarch64/aarch64-exception-frame-print.c
> @@ -45,10 +45,111 @@
>  #include 
>
>  #include 
> +#include 
>  #include 
>
> +typedef struct {
> +   char *s;
> +   size_t n;
> +} String_Context;
> +
> +static void _CPU_Put_char( int c, void *arg )
> +{
> +  String_Context *sctx = arg;
> +  size_t n = sctx->n;
> +
> +  if (n > 0) {
> +char *s = sctx->s;
> +*s = (char) c;
> +sctx->s = s + 1;
> +sctx->n = n - 1;
> +  }
> +}
> +
> +static void _CPU_Binary_sprintf(
> +  char *s,
> +  size_t maxlen,
> +  uint32_t num_bits,
> +  uint32_t value
> +)
> +{
> +  String_Context sctx;
> +  uint32_t mask;
> +
> +  sctx.s = s;
> +  sctx.n = maxlen;
> +
> +  mask = 1 << (num_bits - 1);
> +
> +  while ( mask != 0 ) {
> +_IO_Printf( _CPU_Put_char, , "%d", (value & mask ? 1 : 0) );
> +mask >>= 1;
> +  }

should this function default to NUL-terminate s?

I'm not totally familiar with the usage, but usually that is the
expectation of an sprintf() kind of function.

> +}
> +
> +static const char* _CPU_Exception_class_to_string( uint16_t exception_class )
> +{
> +  switch ( exception_class ) {
> +case 0x01:
> +  return "Trapped WFI or WFE instruction";
> +case 0x03:
> +  return "Trapped MCR or MRC access with (coproc==0b)";
> +case 0x04:
> +  return "Trapped MCRR or MRRC access with (coproc==0b)";
> +case 0x05:
> +  return "Trapped MCR or MRC access with (coproc==0b1110)";
> +case 0x06:
> +  return "Trapped LDC or STC access";
> +case 0x0c:
> +  return "Trapped MRRC access with (coproc==0b1110)";
> +case 0x0e:
> +  return "Illegal Execution state";
> +case 0x18:
> +  return "Trapped MSR, MRS, or System instruction";
> +case 0x20:
> +  return "Instruction Abort from a lower Exception level";
> +case 0x21:
> +  return "Instruction Abort taken without a change in Exception level";
> +case 0x22:
> +  return "PC alignment fault";
> +case 0x24:
> +  return "Data Abort from a lower Exception level";
> +case 0x25:
> +  return "Data Abort taken without a change in Exception level";
> +case 0x26:
> +  return "SP alignment fault";
> +case 0x30:
> +  return "Breakpoint exception from a lower Exception level";
> +case 0x31:
> +  return "Breakpoint exception taken without a change in Exception 
> level";
> +case 0x32:
> +  return "Software Step exception from a lower Exception level";
> +case 0x33:
> +  return "Software Step exception taken without a change in Exception "
> + "level";

This is a case where I would say allowing the string to spill over the
80c is better. I think that having a long string (say 40+ characters)
can justify violating this 80c limit. It would be best for someone to
agree with me though :)

Address the NUL termination, and decide how you want to proceed with
the line length for string breaks. It's a gray area in the rules.

> +case 0x34:
> +  return "Watchpoint exception from a lower Exception level";
> +case 0x35:
> +  return "Watchpoint exception taken without a change in Exception 
> level";
> +case 0x38:
> +  return "BKPT instruction execution in AArch32 state";
> +case 0x3c:
> +  return "BRK instruction execution in AArch64 state";
> +default:
> +  return "Unknown";
> +  }
> +}
> +
>  void _CPU_Exception_frame_print( const CPU_Exception_frame *frame )
>  {
> +  uint32_t ec;
> +  uint32_t il;
> +  uint32_t iss;
> +  char ec_str[7] = { 0 };
> +  char iss_str[26] = { 0 };
> +  int  i;
> +  const uint128_t *qx;
> +
>printk(
>  "\n"
>  "X0   = 0x%016" PRIx64  " X17  = 0x%016" PRIx64 "\n"
> @@ -68,8 +169,7 @@ void _CPU_Exception_frame_print( const CPU_Exception_frame 
> *frame )
>  "X14  = 0x%016" PRIx64  " SP   = 0x%016" PRIxPTR "\n"
>  "X15  = 0x%016" PRIx64  " PC   = 0x%016" PRIxPTR "\n"
>  "X16  = 0x%016" PRIx64  " DAIF = 0x%016" PRIx64 "\n"
> -"VEC  = 0x%016" PRIxPTR " CPSR = 0x%016" PRIx64 "\n"
> -"ESR  = 0x%016" PRIx64  " FAR  = 0x%016" PRIx64 "\n",
> +"VEC  = 0x%016" PRIxPTR " CPSR = 0x%016" PRIx64 "\n",
>  frame->register_x0, frame->register_x17,
>  frame->register_x1, frame->register_x18,
>  frame->register_x2, frame->register_x19,
> @@ -83,23 +183,36 @@ void _CPU_Exception_frame_print( const 
> CPU_Exception_frame *frame )
>  frame->register_x10, frame->register_x27,
>  frame->register_x11, frame->register_x28,
>  frame->register_x12, frame->register_fp,
> -

Re: GSoC project: Memory protection (Ticket no: 2904)

[Utkarsh Rai]

On Tue, Mar 23, 2021 at 5:49 PM Rajiv Vaidyanathan <
rajiv.vaidyanath...@gmail.com> wrote:

> Dear Utkarsh,
>
> Thank you for providing these links. I would like to know if these pending
> tasks are long enough to take it up as a GSoC project.
>
>
Resolving the issues related to user extension iterators and then making it
compatible with existing testsuites should be a long enough task. You can
also take up the task of thread stack sharing
if this is resolved early.



> Thanks and regards,
> Rajiv
>
> On Tue, 23 Mar 2021 at 16:15, Utkarsh Rai  wrote:
>
>>
>>
>> On Mon, Mar 22, 2021 at 9:54 PM Gedare Bloom  wrote:
>>
>>> Hi Rajiv,
>>>
>>> On Sat, Mar 20, 2021 at 12:40 AM Rajiv Vaidyanathan
>>>  wrote:
>>> >
>>> > Hello RTEMS community,
>>>
>>
>> Hello Rajiv,
>>
>>
>>> >
>>> > I am interested in the ticket: Memory protection. I saw that this
>>> topic has been pursued a few times in GSoC. It would be great if someone
>>> can let me know the current status of this project and guide me about what
>>> are the contributions that can be done this year.
>>> >
>>> Yes, this is a frequently attempted project that slowly makes progress
>>> over time. I think that Utkarsh has gotten somewhat close to a
>>> workable solution, but there were some design flaws in his approach
>>> for task stack protection (mainly, iterating over all the tasks) that
>>> are still lingering.
>>
>>
>> If you want to work on thread stack protection using MMU you can look at
>> this
>> thread
>>  for
>> the issues with my solution and possible resolutions to them.
>> You can clone the 'Final-release' branch of this
>>  repo to get an idea of the
>> changes/additions that I had done and refer to this blog
>> 
>>  for
>> a brief description of my idea
>> behind making those changes/additions.
>> Ideally, I would have liked to complete them for myself, this summer, but
>> I am not sure
>> if the time constraints that I have would allow me to pursue this right
>> now.
>>
>>
>>> There could be enough work here to pick up from his progress. The
>>> major issue would be figuring out what  the final state of his code is
>>> in, and to dig in to the design and implementation details to write a
>>> concrete proposal how to bring task stack protection to a production
>>> state. There may be other directions to consider as well, such as
>>> improving the risc-v MMU support perhaps.
>>>
>>> > Thanks and regards,
>>> > Rajiv
>>> > ___
>>> > 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 v5] cpukit/aarch64: Add ESR register decoding

[Alex White]

---
 .../aarch64/aarch64-exception-frame-print.c   | 133 --
 1 file changed, 123 insertions(+), 10 deletions(-)

diff --git a/cpukit/score/cpu/aarch64/aarch64-exception-frame-print.c 
b/cpukit/score/cpu/aarch64/aarch64-exception-frame-print.c
index 59b5d06032..a8c492b1da 100644
--- a/cpukit/score/cpu/aarch64/aarch64-exception-frame-print.c
+++ b/cpukit/score/cpu/aarch64/aarch64-exception-frame-print.c
@@ -45,10 +45,111 @@
 #include 
 
 #include 
+#include 
 #include 
 
+typedef struct {
+   char *s;
+   size_t n;
+} String_Context;
+
+static void _CPU_Put_char( int c, void *arg )
+{
+  String_Context *sctx = arg;
+  size_t n = sctx->n;
+
+  if (n > 0) {
+char *s = sctx->s;
+*s = (char) c;
+sctx->s = s + 1;
+sctx->n = n - 1;
+  }
+}
+
+static void _CPU_Binary_sprintf(
+  char *s,
+  size_t maxlen,
+  uint32_t num_bits,
+  uint32_t value
+)
+{
+  String_Context sctx;
+  uint32_t mask;
+
+  sctx.s = s;
+  sctx.n = maxlen;
+
+  mask = 1 << (num_bits - 1);
+
+  while ( mask != 0 ) {
+_IO_Printf( _CPU_Put_char, , "%d", (value & mask ? 1 : 0) );
+mask >>= 1;
+  }
+}
+
+static const char* _CPU_Exception_class_to_string( uint16_t exception_class )
+{
+  switch ( exception_class ) {
+case 0x01:
+  return "Trapped WFI or WFE instruction";
+case 0x03:
+  return "Trapped MCR or MRC access with (coproc==0b)";
+case 0x04:
+  return "Trapped MCRR or MRRC access with (coproc==0b)";
+case 0x05:
+  return "Trapped MCR or MRC access with (coproc==0b1110)";
+case 0x06:
+  return "Trapped LDC or STC access";
+case 0x0c:
+  return "Trapped MRRC access with (coproc==0b1110)";
+case 0x0e:
+  return "Illegal Execution state";
+case 0x18:
+  return "Trapped MSR, MRS, or System instruction";
+case 0x20:
+  return "Instruction Abort from a lower Exception level";
+case 0x21:
+  return "Instruction Abort taken without a change in Exception level";
+case 0x22:
+  return "PC alignment fault";
+case 0x24:
+  return "Data Abort from a lower Exception level";
+case 0x25:
+  return "Data Abort taken without a change in Exception level";
+case 0x26:
+  return "SP alignment fault";
+case 0x30:
+  return "Breakpoint exception from a lower Exception level";
+case 0x31:
+  return "Breakpoint exception taken without a change in Exception level";
+case 0x32:
+  return "Software Step exception from a lower Exception level";
+case 0x33:
+  return "Software Step exception taken without a change in Exception "
+ "level";
+case 0x34:
+  return "Watchpoint exception from a lower Exception level";
+case 0x35:
+  return "Watchpoint exception taken without a change in Exception level";
+case 0x38:
+  return "BKPT instruction execution in AArch32 state";
+case 0x3c:
+  return "BRK instruction execution in AArch64 state";
+default:
+  return "Unknown";
+  }
+}
+
 void _CPU_Exception_frame_print( const CPU_Exception_frame *frame )
 {
+  uint32_t ec;
+  uint32_t il;
+  uint32_t iss;
+  char ec_str[7] = { 0 };
+  char iss_str[26] = { 0 };
+  int  i;
+  const uint128_t *qx;
+
   printk(
 "\n"
 "X0   = 0x%016" PRIx64  " X17  = 0x%016" PRIx64 "\n"
@@ -68,8 +169,7 @@ void _CPU_Exception_frame_print( const CPU_Exception_frame 
*frame )
 "X14  = 0x%016" PRIx64  " SP   = 0x%016" PRIxPTR "\n"
 "X15  = 0x%016" PRIx64  " PC   = 0x%016" PRIxPTR "\n"
 "X16  = 0x%016" PRIx64  " DAIF = 0x%016" PRIx64 "\n"
-"VEC  = 0x%016" PRIxPTR " CPSR = 0x%016" PRIx64 "\n"
-"ESR  = 0x%016" PRIx64  " FAR  = 0x%016" PRIx64 "\n",
+"VEC  = 0x%016" PRIxPTR " CPSR = 0x%016" PRIx64 "\n",
 frame->register_x0, frame->register_x17,
 frame->register_x1, frame->register_x18,
 frame->register_x2, frame->register_x19,
@@ -83,23 +183,36 @@ void _CPU_Exception_frame_print( const CPU_Exception_frame 
*frame )
 frame->register_x10, frame->register_x27,
 frame->register_x11, frame->register_x28,
 frame->register_x12, frame->register_fp,
-frame->register_x13, (intptr_t)frame->register_lr,
-frame->register_x14, (intptr_t)frame->register_sp,
-frame->register_x15, (intptr_t)frame->register_pc,
+frame->register_x13, (intptr_t) frame->register_lr,
+frame->register_x14, (intptr_t) frame->register_sp,
+frame->register_x15, (intptr_t) frame->register_pc,
 frame->register_x16, frame->register_daif,
-(intptr_t) frame->vector, frame->register_cpsr,
-frame->register_syndrome, frame->register_fault_address
+(intptr_t) frame->vector, frame->register_cpsr
   );
 
-  const uint128_t *qx = >register_q0;
-  int i;
+  ec = frame->register_syndrome >> 26 & 0x3f;
+  il = frame->register_syndrome >> 25 & 0x1;
+  iss = frame->register_syndrome & 0x1ff;
+
+  _CPU_Binary_sprintf( ec_str, sizeof( ec_str ), sizeof( ec_str ) - 1, ec );
+  _CPU_Binary_sprintf( iss_str, sizeof( 

Re: Standalone repository for libnetworking stack

[Vijay Kumar Banerjee]

Hi,

I have prepared and rebased all the patches to the current master. Please
review the commits.

RTEMS patches: https://git.rtems.org/vijay/rtems.git/log/?h=devel-no-libnet
RTEMS net-legacy patch to pull recent changes:
https://git.rtems.org/vijay/rtems-net-legacy.git/commit/?id=2b4738734f9d678a458b64278c0ff95dea588b1e
RTEMS libbsd patch to add telnetd:
https://git.rtems.org/vijay/rtems-libbsd.git/commit/?id=6bda703964e8cbbf73cb21f52fb7ceeb3cb3a541

With these patches, the relocation work would be complete. I have tested
all these patches are building with all the RTEMS bsps in bsp_defaults
using waf.


Best regards,
Vijay


On Wed, Mar 10, 2021 at 11:43 AM Chris Johns  wrote:

>
>
> On 11/3/21 5:14 am, Joel Sherrill wrote:
> >
> >
> > On Wed, Mar 10, 2021 at 11:48 AM Chris Johns  > > wrote:
> >
> >
> >
> > On 11/3/21 1:11 am, Joel Sherrill wrote:
> > > On Tue, Mar 9, 2021 at 11:00 PM Vijay Kumar Banerjee <
> vi...@rtems.org
> > 
> > > >> wrote:
> > >
> > > On Tue, Mar 9, 2021 at 9:56 PM Chris Johns  > 
> > > >> wrote:
> > > >
> > > > On 10/3/21 3:51 pm, Gedare Bloom wrote:
> > > > > On Tue, Mar 9, 2021 at 6:58 PM Joel Sherrill <
> j...@rtems.org
> > 
> > > >> wrote:
> > > > >> On Tue, Mar 9, 2021, 3:28 PM Vijay Kumar Banerjee
> > mailto:vi...@rtems.org>
> > > >> wrote:
> > > > >>> On Fri, Mar 5, 2021 at 10:03 AM Vijay Kumar Banerjee
> > mailto:vi...@rtems.org>
> > > >> wrote:
> > > > >>> In this proposed set of patches, I have removed telnetd
> from
> > RTEMS and
> > > > >>> have placed it in the net-legacy repo, it seems like
> libbsd uses
> > > > >>> telnetd as well. Do we want to keep it in RTEMS and
> remove it
> > from the
> > > > >>> legacy net repo?  There are checks in for
> RTEMS_NETWORKING in
> > telnetd,
> > > > >>> to add rtems_bsdnet.h, how do we want to deal with that?
> In the
> > legacy
> > > > >>> repo, we can just remove these checks and let them build.
> > > > >>
> > > > >>
> > > > >> Move it and remove rtems networking conditional. Freezes
> it with
> > legacy
> > > stack.
> > > > >>
> > > > >> Just my opinion
> > > > >>
> > > > > Is there a different telnetd in libbsd?
> > > >
> > > > Yes ...
> > > >
> > > > https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/telnetd
> > 
> > >  > >
> > > >
> > > This seems to include rtems/telnetd.h
> > > Does the libbsd telnetd depend on the cpukit/telnetd?
> > >
> > > > > The longer term pseudo-goal of being able to (potentially)
> build
> > > > > multiple networking stacks and pick which one to link
> against may also
> > > > > be a consideration at this stage.
> > > >
> > > > Are there issues? If there are issues do we know what they
> are?
> > >
> > >
> > > I guess the bigger question is what network services should remain
> in
> > > rtems itself and work with any stack.
> > >
> > > We have at least telnetd and the web server. If they build against
> the
> > > standard network headers, then they should work any stack that uses
> > > those.
> > >
> > > For maintenance, it would be preferable to only have one which all
> > > stacks use. But this means rtems itself could be built with
> network
> > > services and no stack. I guess this is preferable to having:our
> own
> > > cross stack network services package.
> > >
> > > + RTEMS kernel
> > > + pick your stack
> > > + RTEMS specific network services
> > > + Ports of standard network services (SNMP, NTP, ACE/TAO, etc)
> > >
> > > At this point, it concerns me to add more and more packages
> because we
> > > tend to not have automation to build/test as many beyond the core
> RTEMS
> > > as we should.
> > >
> > > Based on that alone, I'd prefer to unify "RTEMS specific network
> services"
> > > under rtems.git for now. If the service is specific to the stack,
> put it
> > with it,
> > > If it is a third party package, it is an RSB issue.
> >
> > I think this should be "where they can". For example the NFSv2
> client depends on
> > RPC and that is different. I suspect this is why we need a copy with
> each
> > networking 

Re: [PATCH v4] pwdgrp.c: Remove _Assert. /etc may already exist

[Sebastian Huber]

On 23/03/2021 17:25, Ryan Long wrote:


Removed the _Assert_unused_variable_equals macro due to /etc
having already been created by the network stack initialization
or an initial filesystem image.

Thanks, looks good.

--
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 v4] pwdgrp.c: Remove _Assert. /etc may already exist

[Ryan Long]

Removed the _Assert_unused_variable_equals macro due to /etc
having already been created by the network stack initialization
or an initial filesystem image.

Closes #4282
---
 cpukit/libcsupport/src/pwdgrp.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/cpukit/libcsupport/src/pwdgrp.c b/cpukit/libcsupport/src/pwdgrp.c
index f4a10f7..154a92a 100644
--- a/cpukit/libcsupport/src/pwdgrp.c
+++ b/cpukit/libcsupport/src/pwdgrp.c
@@ -67,9 +67,13 @@ static void pwdgrp_init(void)
 
   /*
* Do the best to create this directory.
+   *
+   * /etc could be created by the network stack initialization or an initial
+   * filesystem image. Deliberately ignore the return value.
*/
   sc = mkdir("/etc", S_IRWXU | S_IRGRP | S_IXGRP | S_IROTH | S_IXOTH);
-  _Assert_Unused_variable_equals(sc, 0);
+  _Assert((sc == 0) || (sc == -1 && errno == EEXIST));
+  (void) sc;
 
   /*
*  Initialize /etc/passwd
-- 
1.8.3.1

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

[PATCH v4] Fix pwdgrp.c

[Ryan Long]

Hi,

Joel made a seperate issue (#4354) to address the architecture issues
that Chris brought up. This patch is just to fix the previous commit to
pwdgrp.c that caused some issues when running the shell.

Thanks,
Ryan

Ryan Long (1):
  pwdgrp.c: Remove _Assert. /etc may already exist

 cpukit/libcsupport/src/pwdgrp.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

-- 
1.8.3.1

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

Re: [PATCH v4] cpukit/aarch64: Add ESR register decoding

[Gedare Bloom]

On Tue, Mar 23, 2021 at 9:57 AM Joel Sherrill  wrote:
>
>
>
> On Tue, Mar 23, 2021 at 10:49 AM Sebastian Huber 
>  wrote:
>>
>> Hello Alex,
>>
>> this file has little in common with the RTEMS coding style. This is
>> quite understandable since the style is very exotic. I don't think we
>> will have a formatting tool which is able to produce the RTEMS style in
>> the near future. This gives raise to some general questions.
>>
>> 1. Do we care about the coding style?
>
>
> Yes.
>>
>>
>> 2. Who wants to enforce the coding style?
>
>
> I hope we all catch these when we spot them.
>
> Alex will reformat it.
>
>>
>>
>> 3. Should new files use a new style understood by a well known tool and
>> a well known coding style?
>
>
> That would be preferable but like the license change and SPDX markers, this
> is down the list.
>
> You have something that is close. If you want to add it to rtems-tools as a 
> starting
> point that is accessible, we can start to use it and see how it goes.
>
>>
>>
>> I see a lot of
>>
>> type var = initial_value;
>>
>> Maybe we should drop the stone age variable declarations at block begin
>> if we choose a new style and declare and initialize local variables upon
>> first use.
>
>
> I don't know when this was started but it was never part of the original
> RTEMS style.
>
> Personally I have never liked it.
>

It is a holdover from K and the gcc -ansi flag would complain if you
didn't do it. (For older compiler writers, it made it a lot easier to
parse and generate the code if you could pass over all the stack
allocations in one group.)

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

Re: GSoC Project - Beagle BSP Projects

[Christian MAUDERER]

Hello Gedare,

Am 23.03.21 um 16:48 schrieb Gedare Bloom:

CC: Nils, Utkarsh

On Tue, Mar 23, 2021 at 9:17 AM Christian MAUDERER
 wrote:


Hello Ahamed,

Am 23.03.21 um 11:24 schrieb Ahamed Husni:

Hi everyone,

I'm really interested to work on the *Beagle BSP Projects* [#2891
]. *
*
*Adding PRU Support* [#3730 ]
project seems really interesting to me.
This project is partially done during GSoC 2019
by Nils Hölscher .
Is this a good project for the GSoC?

Up to now I have,

  1. Completed the GSoC prerequisite task
  2. Got the required hardware and tested it. (Beagleboard Black, USB to
 TTL Converter)
  3. Installed RTEMS on the Beagleboard and tested. (Screenshot attached
 below)


I need guidance to define the scope of the project.
I'm currently thinking of ,

  1. First finish the remaining work from GSoC 2019 on the PRU.
 (What is the status of current implementation of the PRU?)


I'm really not sure what the state of the PRU is. I didn't follow that
project closely. Maybe one of the mentors of that project can say
anything regarding that.


Some more background:
https://lists.rtems.org/pipermail/devel/2019-December/056478.html
https://lists.rtems.org/pipermail/devel/2020-January/056958.html

Maybe Utkarsh or Nils have more to say.


  2. Implement additional peripheral support.
 What would be most useful?
 (USB OTG, CAN, ...).


I think CAN is a bit hard without some CAN analyzer hardware as a peer.

USB OTG would be a nice area. But that will be less writing a driver for
Beagle but more finding out how that works with libbsd and finding a
good way to configure it. I once put a few hours into it didn't take too
much time till a PC detected an USB device (see
https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce).
Basically it's about importing the "usb_template" stuff and finding a
way to configure it in libbsd.

I think that topic would have to be a bit of an open one: You might work
only a day on it and have a working CDC Ethernet afterwards or you can
need weeks for that. So you should add an open list of possible advanced
targets. An OTG device can be:

- Ethernet
- Serial port
- Mass storage
- Keyboard / Mouse
- Modem
- Audio
- ...

The simplest one will most likely be Ethernet followed by serial port. I
would add some of the others (like mass storage) as an extended targets.


Yes, this seems like an area that can be chipped away at, with a
strong plan of activities. My concern would be whether it is about
writing code or not?



It won't produce a lot of code. But it will produce relevant one:

1. Interface for configuration (if necessary)

2. Example application

3. Documentation

For Ethernet and serial port that's most likely it. For Mass storage 
there might be some more code. Without a too detailed look: I would 
expect that the mass storage either implements some access to a raw 
block device - in which case it would be necessary to add the access to 
block devices. Or it implements something like the PTP stuff used on 
smartphones in which case there will be most likely some code that 
accesses the file system using POSIX functions instead of FreeBSD kernel 
functions.


Best regards

Christian


Best regards

Christian



 The builtin USB is NOT functional other than for power under RTEMS.
 (USB OTG would have to be implemented in RTEMS to get rid of USB to
 TTL Converter.)
 - Ben Gras
 

 (Blog post)


Thanks,
Husni Faiz.


BBB_Serial_Out.png


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



--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
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


--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
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

Re: [PATCH v4] cpukit/aarch64: Add ESR register decoding

[Joel Sherrill]

On Tue, Mar 23, 2021 at 10:49 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Alex,
>
> this file has little in common with the RTEMS coding style. This is
> quite understandable since the style is very exotic. I don't think we
> will have a formatting tool which is able to produce the RTEMS style in
> the near future. This gives raise to some general questions.
>
> 1. Do we care about the coding style?
>

Yes.

>
> 2. Who wants to enforce the coding style?
>

I hope we all catch these when we spot them.

Alex will reformat it.


>
> 3. Should new files use a new style understood by a well known tool and
> a well known coding style?
>

That would be preferable but like the license change and SPDX markers, this
is down the list.

You have something that is close. If you want to add it to rtems-tools as a
starting
point that is accessible, we can start to use it and see how it goes.


>
> I see a lot of
>
> type var = initial_value;
>
> Maybe we should drop the stone age variable declarations at block begin
> if we choose a new style and declare and initialize local variables upon
> first use.
>

I don't know when this was started but it was never part of the original
RTEMS style.

Personally I have never liked it.

--joel


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

Re: [PATCH v4] cpukit/aarch64: Add ESR register decoding

[Sebastian Huber]

Hello Alex,

this file has little in common with the RTEMS coding style. This is 
quite understandable since the style is very exotic. I don't think we 
will have a formatting tool which is able to produce the RTEMS style in 
the near future. This gives raise to some general questions.


1. Do we care about the coding style?

2. Who wants to enforce the coding style?

3. Should new files use a new style understood by a well known tool and 
a well known coding style?


I see a lot of

type var = initial_value;

Maybe we should drop the stone age variable declarations at block begin 
if we choose a new style and declare and initialize local variables upon 
first use.


--
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 Project - Beagle BSP Projects

[Gedare Bloom]

CC: Nils, Utkarsh

On Tue, Mar 23, 2021 at 9:17 AM Christian MAUDERER
 wrote:
>
> Hello Ahamed,
>
> Am 23.03.21 um 11:24 schrieb Ahamed Husni:
> > Hi everyone,
> >
> > I'm really interested to work on the *Beagle BSP Projects* [#2891
> > ]. *
> > *
> > *Adding PRU Support* [#3730 ]
> > project seems really interesting to me.
> > This project is partially done during GSoC 2019
> > by Nils Hölscher .
> > Is this a good project for the GSoC?
> >
> > Up to now I have,
> >
> >  1. Completed the GSoC prerequisite task
> >  2. Got the required hardware and tested it. (Beagleboard Black, USB to
> > TTL Converter)
> >  3. Installed RTEMS on the Beagleboard and tested. (Screenshot attached
> > below)
> >
> >
> > I need guidance to define the scope of the project.
> > I'm currently thinking of ,
> >
> >  1. First finish the remaining work from GSoC 2019 on the PRU.
> > (What is the status of current implementation of the PRU?)
>
> I'm really not sure what the state of the PRU is. I didn't follow that
> project closely. Maybe one of the mentors of that project can say
> anything regarding that.
>
Some more background:
https://lists.rtems.org/pipermail/devel/2019-December/056478.html
https://lists.rtems.org/pipermail/devel/2020-January/056958.html

Maybe Utkarsh or Nils have more to say.

> >  2. Implement additional peripheral support.
> > What would be most useful?
> > (USB OTG, CAN, ...).
>
> I think CAN is a bit hard without some CAN analyzer hardware as a peer.
>
> USB OTG would be a nice area. But that will be less writing a driver for
> Beagle but more finding out how that works with libbsd and finding a
> good way to configure it. I once put a few hours into it didn't take too
> much time till a PC detected an USB device (see
> https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce).
> Basically it's about importing the "usb_template" stuff and finding a
> way to configure it in libbsd.
>
> I think that topic would have to be a bit of an open one: You might work
> only a day on it and have a working CDC Ethernet afterwards or you can
> need weeks for that. So you should add an open list of possible advanced
> targets. An OTG device can be:
>
> - Ethernet
> - Serial port
> - Mass storage
> - Keyboard / Mouse
> - Modem
> - Audio
> - ...
>
> The simplest one will most likely be Ethernet followed by serial port. I
> would add some of the others (like mass storage) as an extended targets.
>
Yes, this seems like an area that can be chipped away at, with a
strong plan of activities. My concern would be whether it is about
writing code or not?

> Best regards
>
> Christian
>
> >
> > The builtin USB is NOT functional other than for power under RTEMS.
> > (USB OTG would have to be implemented in RTEMS to get rid of USB to
> > TTL Converter.)
> > - Ben Gras
> > 
> > 
> > (Blog post)
> >
> >
> > Thanks,
> > Husni Faiz.
> >
> >
> > BBB_Serial_Out.png
> >
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> >
>
> --
> 
> embedded brains GmbH
> Herr Christian MAUDERER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> phone: +49-89-18 94 741 - 18
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-docs v3 1/6] prefixes: Update installation prefix

[Gedare Bloom]

On Tue, Mar 23, 2021 at 9:28 AM Joel Sherrill  wrote:
>
>
>
> On Tue, Mar 23, 2021 at 10:16 AM Gedare Bloom  wrote:
>>
>> On Mon, Mar 22, 2021 at 3:12 PM Chris Johns  wrote:
>> >
>> > On 23/3/21 4:41 am, Gedare Bloom wrote:> I wonder what is your opinion, 
>> > should
>> > we bump these tutorials with
>> > > every version? And, is the find/replace of the commands the best way
>> > > to do this?
>> > >
>> > > I feel like this topic comes up now and again. Maintaining these
>> > > examples is a little fragile.
>> >
>> > It is fragile and I have in the past invested some time looking for a way 
>> > to
>> > automatically manage these version based blocks of documentation however 
>> > subtle
>> > change happen so making it automatic is difficult. Arguments to commands 
>> > change
>> > and if there is captured output it needs to change.
>> >
>> > > @Ida: Thanks for the patches,
>> >
>> > Yes, thank you. The patches are great.
>> >
>> > > now we'll need to determine if we want
>> > > to bump these examples like this, and whether we should consider a
>> > > better way to maintain this stuff in the future.
>> >
>> > I am open to solutions. A few ideas are:
>> >
>> > 1. Group commands we consider as stable interfaces and see if the RTEMS 
>> > version
>> > can be supplied via a conf variable passed in by waf. This would lower the
>> > number of changes.
>> >
>> > 2. Tag version specific blocks with something in a comment. Making a 
>> > change is
>> > part of the solution however I find knowing there is a change to make is 
>> > harder.
>> > If we can grep the sources we could see. For example:
>> >
>> I like tagging.
>>
>> > .. rtems-version-block: 5
>> >
>
>
> Texinfo had variables. Looking at Sphinx docs, I see this:
>
> https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html#substitutions
>
> Does that work? Could we have
>
> .. |rtems-version| replace:: 6
>
> This should work in text without doing any magic. It looks like example
> and code blocks may need a special block for this to work. I think this
> page has a solution to that
>
>  
> https://stackoverflow.com/questions/42158111/variable-substitution-not-working-properly-in-sphinx
>
> This won't help when command line arguments change and things like the
> transition from the sis to erc32 BSP will still need work.
>
It also doesn't address that example output changes with each version.
That's the bigger problem here.

>> > The version number is updated when changed so we can see what needs to be 
>> > done.
>> > This would be helpful when making releases.
>> >
>> > 3. Other ideas ...
>> >
>> A script/tutorial to regenerate these parts could work also. Kind of a
>> guide how to update for a new version, and what needs to be
>> run/captured as output examples.
>>
>> > Chris
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v4] cpukit/aarch64: Add ESR register decoding

[Gedare Bloom]

On Mon, Mar 22, 2021 at 3:32 PM Alex White  wrote:
>
> ---
>  .../aarch64/aarch64-exception-frame-print.c   | 105 +-
>  1 file changed, 101 insertions(+), 4 deletions(-)
>
> diff --git a/cpukit/score/cpu/aarch64/aarch64-exception-frame-print.c 
> b/cpukit/score/cpu/aarch64/aarch64-exception-frame-print.c
> index 59b5d06032..348151a468 100644
> --- a/cpukit/score/cpu/aarch64/aarch64-exception-frame-print.c
> +++ b/cpukit/score/cpu/aarch64/aarch64-exception-frame-print.c
> @@ -45,8 +45,90 @@
>  #include 
>
>  #include 
> +#include 
>  #include 
>
> +static const char* _exception_class_to_string( uint16_t exception_class );

static symbol shouldn't need an _. An _ generally is reserved. I don't
know what our rules say about this, but anyway it is not needed here.

> +
> +static void _binary_sprintf(
ditto.

> +  char *s,
> +  size_t maxlen,
> +  uint32_t num_bits,
> +  uint32_t value
> +);
> +
> +static const char* _exception_class_to_string( uint16_t exception_class )
> +{
> +  switch (exception_class)
> +  {
> +  case 0x01: return "Trapped WFI or WFE instruction";
indent two spaces, put the return on a newline, to adhere to score style.

> +  case 0x03: return "Trapped MCR or MRC access with (coproc==0b)";
> +  case 0x04: return "Trapped MCRR or MRRC access with (coproc==0b)";
> +  case 0x05: return "Trapped MCR or MRC access with (coproc==0b1110)";
> +  case 0x06: return "Trapped LDC or STC access";
> +  case 0x0c: return "Trapped MRRC access with (coproc==0b1110)";
> +  case 0x0e: return "Illegal Execution state";
> +  case 0x18: return "Trapped MSR, MRS, or System instruction";
> +  case 0x20: return "Instruction Abort from a lower Exception level";
> +  case 0x21: return "Instruction Abort taken without a change in Exception "
> +"level";
> +  case 0x22: return "PC alignment fault";
> +  case 0x24: return "Data Abort from a lower Exception level";
> +  case 0x25: return "Data Abort taken without a change in Exception level";
> +  case 0x26: return "SP alignment fault";
> +  case 0x30: return "Breakpoint exception from a lower Exception level";
> +  case 0x31: return "Breakpoint exception taken without a change in "
> +"Exception level";
> +  case 0x32: return "Software Step exception from a lower Exception level";
> +  case 0x33: return "Software Step exception taken without a change in "
> +"Exception level";
> +  case 0x34: return "Watchpoint exception from a lower Exception level";
> +  case 0x35: return "Watchpoint exception taken without a change in "
> +"Exception level";
> +  case 0x38: return "BKPT instruction execution in AArch32 state";
> +  case 0x3c: return "BRK instruction execution in AArch64 state";
> +  default: return "Unknown";
> +  }
> +}
> +
> +typedef struct {
> +   char *s;
> +   size_t n;
> +} string_context;
> +
> +static void put_char(int c, void *arg)
> +{
> +  string_context *sctx = arg;
> +  size_t n = sctx->n;
> +
> +  if (n > 0) {
> +char *s = sctx->s;
> +*s = (char)c;
> +sctx->s = s + 1;
> +sctx->n = n - 1;
> +  }
> +}
> +
> +static void _binary_sprintf(
> +  char *s,
> +  size_t maxlen,
> +  uint32_t num_bits,
> +  uint32_t value
> +)
> +{
> +  string_context sctx = {
> +.s = s,
> +.n = maxlen
> +  };
> +  uint32_t mask = 1<<(num_bits-1);
> +  int cx = 0;
> +
> +  while ( mask != 0 ) {
> +cx += _IO_Printf(put_char, , "%d", (value & mask ? 1 : 0));
> +mask >>= 1;
> +  }
> +}
> +
>  void _CPU_Exception_frame_print( const CPU_Exception_frame *frame )
>  {
>printk(
> @@ -68,8 +150,7 @@ void _CPU_Exception_frame_print( const CPU_Exception_frame 
> *frame )
>  "X14  = 0x%016" PRIx64  " SP   = 0x%016" PRIxPTR "\n"
>  "X15  = 0x%016" PRIx64  " PC   = 0x%016" PRIxPTR "\n"
>  "X16  = 0x%016" PRIx64  " DAIF = 0x%016" PRIx64 "\n"
> -"VEC  = 0x%016" PRIxPTR " CPSR = 0x%016" PRIx64 "\n"
> -"ESR  = 0x%016" PRIx64  " FAR  = 0x%016" PRIx64 "\n",
> +"VEC  = 0x%016" PRIxPTR " CPSR = 0x%016" PRIx64 "\n",
>  frame->register_x0, frame->register_x17,
>  frame->register_x1, frame->register_x18,
>  frame->register_x2, frame->register_x19,
> @@ -87,10 +168,26 @@ void _CPU_Exception_frame_print( const 
> CPU_Exception_frame *frame )
>  frame->register_x14, (intptr_t)frame->register_sp,
>  frame->register_x15, (intptr_t)frame->register_pc,
>  frame->register_x16, frame->register_daif,
> -(intptr_t) frame->vector, frame->register_cpsr,
> -frame->register_syndrome, frame->register_fault_address
> +(intptr_t) frame->vector, frame->register_cpsr
>);
>
> +  uint32_t ec = (frame->register_syndrome >> 26) & 0x3f;
> +  uint32_t il = (frame->register_syndrome >> 25) & 0x1;
> +  uint32_t iss = frame->register_syndrome & 0x1ff;
> +  char ec_str[7] = {0};
> +  char iss_str[26] = {0};
> +
> +  _binary_sprintf(ec_str, 7, 6, ec);
> +  _binary_sprintf(iss_str, 26, 25, iss);
> +
> +  printk(
> +"ESR 

Re: rtems-test not running tests for leon3

[Joel Sherrill]

On Tue, Mar 23, 2021 at 10:32 AM Ryan Long  wrote:

> I’m on the master branch of rtems-tools, but the output is the same when I
> run it from the rtems-test included in tools/bin.
>
>
Just checking. sis was originally built into gdb. It was separated out and
this tester configuration just got missed. It needs to be removed.


>
>
> I got it to run with sparc-rtems6-sis, though.
>

That's what you should be using (or qemu)

--joel



>
>
> *From:* Joel Sherrill 
> *Sent:* Tuesday, March 23, 2021 9:22 AM
> *To:* Ryan Long 
> *Cc:* rtems-de...@rtems.org 
> *Subject:* Re: rtems-test not running tests for leon3
>
>
>
> Are you sure this is the master for RTEMS test?
>
>
>
> The sis simulator has been out of gdb for a while. I would hope the tester
> configuration is gone. But apparently it isn't. You shouldn't use leon3. It
> needs to be removed.
>
>
>
> Use leon3-sis or leon3-qemu
>
> On Tue, Mar 23, 2021, 9:07 AM Ryan Long  wrote:
>
> Hi,
>
>
>
> I’ve been trying to run the tests for leon3, but the only test that runs
> properly is the minimum test. All  of the others produce output like so in
> the log file.
>
>
>
> [334/597] p:0   f:0   u:0   e:0   I:0   B:0   t:0   L:0   i:329 W:0   |
> sparc/leon3: nsecs.exe
>
> Result: invalidTime: 0:00:02.754956
> nsecs.exe
>
> =>  gdb: /home/rlong/rtems-work/tools/bin/sparc-rtems6-gdb -i=mi --nx
> --quiet rtems/build/sparc/leon3/testsuites/samples/nsecs.exe
>
> =>  Reading symbols from
> rtems/build/sparc/leon3/testsuites/samples/nsecs.exe...
>
> =>  target sim
> -leon3
>
> =>  Undefined target command: "sim -leon3".  Try "help
> target".
>
> =>  quit
>
>
>
> Does anyone know how to run these?
>
>
>
> And should I file a ticket for this and fix it in rtems-test?
>
>
>
> Thanks,
>
> Ryan
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: rtems-test not running tests for leon3

[Ryan Long]

I’m on the master branch of rtems-tools, but the output is the same when I run 
it from the rtems-test included in tools/bin.

I got it to run with sparc-rtems6-sis, though.

From: Joel Sherrill 
Sent: Tuesday, March 23, 2021 9:22 AM
To: Ryan Long 
Cc: rtems-de...@rtems.org 
Subject: Re: rtems-test not running tests for leon3

Are you sure this is the master for RTEMS test?

The sis simulator has been out of gdb for a while. I would hope the tester 
configuration is gone. But apparently it isn't. You shouldn't use leon3. It 
needs to be removed.

Use leon3-sis or leon3-qemu
On Tue, Mar 23, 2021, 9:07 AM Ryan Long 
mailto:ryan.l...@oarcorp.com>> wrote:
Hi,

I’ve been trying to run the tests for leon3, but the only test that runs 
properly is the minimum test. All  of the others produce output like so in the 
log file.

[334/597] p:0   f:0   u:0   e:0   I:0   B:0   t:0   L:0   i:329 W:0   | 
sparc/leon3: nsecs.exe
Result: invalidTime: 0:00:02.754956 nsecs.exe
=>  gdb: /home/rlong/rtems-work/tools/bin/sparc-rtems6-gdb -i=mi --nx --quiet 
rtems/build/sparc/leon3/testsuites/samples/nsecs.exe
=>  Reading symbols from rtems/build/sparc/leon3/testsuites/samples/nsecs.exe...
=>  target sim -leon3
=>  Undefined target command: "sim -leon3".  Try "help target".
=>  quit

Does anyone know how to run these?

And should I file a ticket for this and fix it in rtems-test?

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

Re: [PATCH rtems-docs v3 1/6] prefixes: Update installation prefix

[Joel Sherrill]

On Tue, Mar 23, 2021 at 10:16 AM Gedare Bloom  wrote:

> On Mon, Mar 22, 2021 at 3:12 PM Chris Johns  wrote:
> >
> > On 23/3/21 4:41 am, Gedare Bloom wrote:> I wonder what is your opinion,
> should
> > we bump these tutorials with
> > > every version? And, is the find/replace of the commands the best way
> > > to do this?
> > >
> > > I feel like this topic comes up now and again. Maintaining these
> > > examples is a little fragile.
> >
> > It is fragile and I have in the past invested some time looking for a
> way to
> > automatically manage these version based blocks of documentation however
> subtle
> > change happen so making it automatic is difficult. Arguments to commands
> change
> > and if there is captured output it needs to change.
> >
> > > @Ida: Thanks for the patches,
> >
> > Yes, thank you. The patches are great.
> >
> > > now we'll need to determine if we want
> > > to bump these examples like this, and whether we should consider a
> > > better way to maintain this stuff in the future.
> >
> > I am open to solutions. A few ideas are:
> >
> > 1. Group commands we consider as stable interfaces and see if the RTEMS
> version
> > can be supplied via a conf variable passed in by waf. This would lower
> the
> > number of changes.
> >
> > 2. Tag version specific blocks with something in a comment. Making a
> change is
> > part of the solution however I find knowing there is a change to make is
> harder.
> > If we can grep the sources we could see. For example:
> >
> I like tagging.
>
> > .. rtems-version-block: 5
> >
>

Texinfo had variables. Looking at Sphinx docs, I see this:

https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html#substitutions

Does that work? Could we have

.. |rtems-version| replace:: 6

This should work in text without doing any magic. It looks like example
and code blocks may need a special block for this to work. I think this
page has a solution to that


https://stackoverflow.com/questions/42158111/variable-substitution-not-working-properly-in-sphinx

This won't help when command line arguments change and things like the
transition from the sis to erc32 BSP will still need work.

> The version number is updated when changed so we can see what needs to be
> done.
> > This would be helpful when making releases.
> >
> > 3. Other ideas ...
> >
> A script/tutorial to regenerate these parts could work also. Kind of a
> guide how to update for a new version, and what needs to be
> run/captured as output examples.
>
> > Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v3] cpukit/aarch64: Add ESR register decoding

[Gedare Bloom]

On Mon, Mar 22, 2021 at 11:35 PM Sebastian Huber
 wrote:
>
> On 22/03/2021 21:43, Alex White wrote:
>
> >>> +static void _binary_sprintf(
> >>> +  char *s,
> >>> +  size_t maxlen,
> >>> +  uint32_t num_bits,
> >>> +  uint32_t value
> >>> +)
> >>> +{
> >>> +  string_context sctx = {
> >>> +.s = s,
> >>> +.n = maxlen
> >>> +  };
> >>> +  uint32_t mask = 1<<(num_bits-1);
> >>> +  int cx = 0;
> >>> +
> >>> +  while ( mask != 0 ) {
> >>> +cx += _IO_Printf(put_char, , "%d", (value & mask ? 1 : 0));
> >>> +//cx += snprintf(s + cx, maxlen - cx, "%d", (value ? 1 : 0));
> >> Commented out.
> > Will fix.
> It would be nice if this cpukit file could follow the score coding style.
>
+1

I would kindly request that the file be reformatted.

> --
> 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: GSoC Project - Beagle BSP Projects

[Christian MAUDERER]

Hello Ahamed,

Am 23.03.21 um 11:24 schrieb Ahamed Husni:

Hi everyone,

I'm really interested to work on the *Beagle BSP Projects* [#2891 
]. *

*
*Adding PRU Support* [#3730 ] 
project seems really interesting to me.
This project is partially done during GSoC 2019 
by Nils Hölscher .

Is this a good project for the GSoC?

Up to now I have,

 1. Completed the GSoC prerequisite task
 2. Got the required hardware and tested it. (Beagleboard Black, USB to
TTL Converter)
 3. Installed RTEMS on the Beagleboard and tested. (Screenshot attached
below)


I need guidance to define the scope of the project.
I'm currently thinking of ,

 1. First finish the remaining work from GSoC 2019 on the PRU.
(What is the status of current implementation of the PRU?)


I'm really not sure what the state of the PRU is. I didn't follow that 
project closely. Maybe one of the mentors of that project can say 
anything regarding that.



 2. Implement additional peripheral support.
What would be most useful?
(USB OTG, CAN, ...).


I think CAN is a bit hard without some CAN analyzer hardware as a peer.

USB OTG would be a nice area. But that will be less writing a driver for 
Beagle but more finding out how that works with libbsd and finding a 
good way to configure it. I once put a few hours into it didn't take too 
much time till a PC detected an USB device (see 
https://gitlab.com/c-mauderer/rtems-libbsd/-/tree/20170707-cdce). 
Basically it's about importing the "usb_template" stuff and finding a 
way to configure it in libbsd.


I think that topic would have to be a bit of an open one: You might work 
only a day on it and have a working CDC Ethernet afterwards or you can 
need weeks for that. So you should add an open list of possible advanced 
targets. An OTG device can be:


- Ethernet
- Serial port
- Mass storage
- Keyboard / Mouse
- Modem
- Audio
- ...

The simplest one will most likely be Ethernet followed by serial port. I 
would add some of the others (like mass storage) as an extended targets.


Best regards

Christian



The builtin USB is NOT functional other than for power under RTEMS.
(USB OTG would have to be implemented in RTEMS to get rid of USB to
TTL Converter.)
- Ben Gras


(Blog post)


Thanks,
Husni Faiz.


BBB_Serial_Out.png


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



--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741 - 08

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

Re: [PATCH rtems-docs v3 1/6] prefixes: Update installation prefix

[Gedare Bloom]

On Mon, Mar 22, 2021 at 3:12 PM Chris Johns  wrote:
>
> On 23/3/21 4:41 am, Gedare Bloom wrote:> I wonder what is your opinion, should
> we bump these tutorials with
> > every version? And, is the find/replace of the commands the best way
> > to do this?
> >
> > I feel like this topic comes up now and again. Maintaining these
> > examples is a little fragile.
>
> It is fragile and I have in the past invested some time looking for a way to
> automatically manage these version based blocks of documentation however 
> subtle
> change happen so making it automatic is difficult. Arguments to commands 
> change
> and if there is captured output it needs to change.
>
> > @Ida: Thanks for the patches,
>
> Yes, thank you. The patches are great.
>
> > now we'll need to determine if we want
> > to bump these examples like this, and whether we should consider a
> > better way to maintain this stuff in the future.
>
> I am open to solutions. A few ideas are:
>
> 1. Group commands we consider as stable interfaces and see if the RTEMS 
> version
> can be supplied via a conf variable passed in by waf. This would lower the
> number of changes.
>
> 2. Tag version specific blocks with something in a comment. Making a change is
> part of the solution however I find knowing there is a change to make is 
> harder.
> If we can grep the sources we could see. For example:
>
I like tagging.

> .. rtems-version-block: 5
>
> The version number is updated when changed so we can see what needs to be 
> done.
> This would be helpful when making releases.
>
> 3. Other ideas ...
>
A script/tutorial to regenerate these parts could work also. Kind of a
guide how to update for a new version, and what needs to be
run/captured as output examples.

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

Re: GSoC project: Memory protection (Ticket no: 2904)

[Gedare Bloom]

CC: Hesham
CC: devel

On Tue, Mar 23, 2021 at 6:34 AM Rajiv Vaidyanathan
 wrote:
>
> Dear Gedare,
>
> Thank you for providing information regarding the project. For risk-v MMU 
> support, will I require to have hardware?
>
That's a good question. I don't know if the current risc-v simulators
support the risc-v mmu. maybe, another expert could advise. I have
CC'd someone with experience in both risc-v and memory protection.

Let's keep technical discussions on the mailing list. Thanks.

> Thanks and regards,
> Rajiv
>
> On Mon, 22 Mar 2021 at 21:54, Gedare Bloom  wrote:
>>
>> Hi Rajiv,
>>
>> On Sat, Mar 20, 2021 at 12:40 AM Rajiv Vaidyanathan
>>  wrote:
>> >
>> > Hello RTEMS community,
>> >
>> > I am interested in the ticket: Memory protection. I saw that this topic 
>> > has been pursued a few times in GSoC. It would be great if someone can let 
>> > me know the current status of this project and guide me about what are the 
>> > contributions that can be done this year.
>> >
>> Yes, this is a frequently attempted project that slowly makes progress
>> over time. I think that Utkarsh has gotten somewhat close to a
>> workable solution, but there were some design flaws in his approach
>> for task stack protection (mainly, iterating over all the tasks) that
>> are still lingering.
>>
>> There could be enough work here to pick up from his progress. The
>> major issue would be figuring out what  the final state of his code is
>> in, and to dig in to the design and implementation details to write a
>> concrete proposal how to bring task stack protection to a production
>> state. There may be other directions to consider as well, such as
>> improving the risc-v MMU support perhaps.
>>
>> > Thanks and regards,
>> > Rajiv
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-test not running tests for leon3

[Joel Sherrill]

Are you sure this is the master for RTEMS test?

The sis simulator has been out of gdb for a while. I would hope the tester
configuration is gone. But apparently it isn't. You shouldn't use leon3. It
needs to be removed.

Use leon3-sis or leon3-qemu

On Tue, Mar 23, 2021, 9:07 AM Ryan Long  wrote:

> Hi,
>
>
>
> I’ve been trying to run the tests for leon3, but the only test that runs
> properly is the minimum test. All  of the others produce output like so in
> the log file.
>
>
>
> [334/597] p:0   f:0   u:0   e:0   I:0   B:0   t:0   L:0   i:329 W:0   |
> sparc/leon3: nsecs.exe
>
> Result: invalidTime: 0:00:02.754956
> nsecs.exe
>
> =>  gdb: /home/rlong/rtems-work/tools/bin/sparc-rtems6-gdb -i=mi --nx
> --quiet rtems/build/sparc/leon3/testsuites/samples/nsecs.exe
>
> =>  Reading symbols from
> rtems/build/sparc/leon3/testsuites/samples/nsecs.exe...
>
> =>  target sim
> -leon3
>
> =>  Undefined target command: "sim -leon3".  Try "help
> target".
>
> =>  quit
>
>
>
> Does anyone know how to run these?
>
>
>
> And should I file a ticket for this and fix it in rtems-test?
>
>
>
> Thanks,
>
> Ryan
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-test not running tests for leon3

[Richi Dubey]

Afaik minimum tests are supposed to fail.

On Tue, Mar 23, 2021 at 7:37 PM Ryan Long  wrote:

> Hi,
>
>
>
> I’ve been trying to run the tests for leon3, but the only test that runs
> properly is the minimum test. All  of the others produce output like so in
> the log file.
>
>
>
> [334/597] p:0   f:0   u:0   e:0   I:0   B:0   t:0   L:0   i:329 W:0   |
> sparc/leon3: nsecs.exe
>
> Result: invalidTime: 0:00:02.754956
> nsecs.exe
>
> =>  gdb: /home/rlong/rtems-work/tools/bin/sparc-rtems6-gdb -i=mi --nx
> --quiet rtems/build/sparc/leon3/testsuites/samples/nsecs.exe
>
> =>  Reading symbols from
> rtems/build/sparc/leon3/testsuites/samples/nsecs.exe...
>
> =>  target sim
> -leon3
>
> =>  Undefined target command: "sim -leon3".  Try "help
> target".
>
> =>  quit
>
>
>
> Does anyone know how to run these?
>
>
>
> And should I file a ticket for this and fix it in rtems-test?
>
>
>
> Thanks,
>
> Ryan
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

rtems-test not running tests for leon3

[Ryan Long]

Hi,

I've been trying to run the tests for leon3, but the only test that runs 
properly is the minimum test. All  of the others produce output like so in the 
log file.

[334/597] p:0   f:0   u:0   e:0   I:0   B:0   t:0   L:0   i:329 W:0   | 
sparc/leon3: nsecs.exe
Result: invalidTime: 0:00:02.754956 nsecs.exe
=>  gdb: /home/rlong/rtems-work/tools/bin/sparc-rtems6-gdb -i=mi --nx --quiet 
rtems/build/sparc/leon3/testsuites/samples/nsecs.exe
=>  Reading symbols from rtems/build/sparc/leon3/testsuites/samples/nsecs.exe...
=>  target sim -leon3
=>  Undefined target command: "sim -leon3".  Try "help target".
=>  quit

Does anyone know how to run these?

And should I file a ticket for this and fix it in rtems-test?

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

Issue in Recent Beagle Patch was Fwd: New Defects reported by Coverity Scan for RTEMS

[Joel Sherrill]

-- Forwarded message -
From: 
Date: Tue, Mar 23, 2021 at 12:22 AM
Subject: New Defects reported by Coverity Scan for RTEMS
To: 


Hi,

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

3 new defect(s) introduced to RTEMS found with Coverity Scan.


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


** CID 1474437:  Memory - corruptions  (ARRAY_VS_SINGLETON)



*** CID 1474437:  Memory - corruptions  (ARRAY_VS_SINGLETON)
/bsps/shared/freebsd/sys/arm/ti/ti_pinmux.c: 480 in
beagle_pinctrl_configure_children()
474 int len;
475 uint32_t phandle;
476
477 for (node = OF_child(parent); node != 0; node =
OF_peer(node)) {
478 if (rtems_ofw_node_status(node)) {
479 beagle_pinctrl_configure_children(sc, node);
>>> CID 1474437:  Memory - corruptions  (ARRAY_VS_SINGLETON)
>>> Passing "" to function "rtems_ofw_get_enc_prop" which uses
it as an array. This might corrupt or misinterpret adjacent memory
locations.
480 len = OF_getencprop(node, "pinctrl-0",
, sizeof(phandle));
481 if (len == sizeof(phandle)) {
482 ti_pinmux_configure_pins(sc,
phandle);
483 }
484 }
485 }

** CID 1474436:  Memory - corruptions  (ARRAY_VS_SINGLETON)



*** CID 1474436:  Memory - corruptions  (ARRAY_VS_SINGLETON)
/bsps/shared/freebsd/sys/arm/ti/ti_pinmux.c: 545 in beagle_pinmux_init()
539 break;
540 default:
541 printk("Unknown CPU in pinmux\n");
542 return ;
543 }
544
>>> CID 1474436:  Memory - corruptions  (ARRAY_VS_SINGLETON)
>>> Passing "" to function "rtems_ofw_get_reg" which uses it as an
array. This might corrupt or misinterpret adjacent memory locations.
545 rv = rtems_ofw_get_reg(node, , sizeof(reg));
546 if (rv == -1) {
547 printk("pinmux_init: rtems_ofw_get_reg failed
%d\n", rv);
548 return ;
549 }
550 pinmux_softc.sc_bsh = reg.start;

** CID 1474435:(RESOURCE_LEAK)
/bsps/shared/freebsd/sys/arm/ti/ti_pinmux.c: 408 in
ti_pinmux_configure_pins()
/bsps/shared/freebsd/sys/arm/ti/ti_pinmux.c: 405 in
ti_pinmux_configure_pins()



*** CID 1474435:(RESOURCE_LEAK)
/bsps/shared/freebsd/sys/arm/ti/ti_pinmux.c: 408 in
ti_pinmux_configure_pins()
402 sizeof(*cfgtuples), (void **));
403
404 if (ntuples < 0)
405 return (ENOENT);
406
407 if (ntuples == 0)
>>> CID 1474435:(RESOURCE_LEAK)
>>> Variable "cfgtuples" going out of scope leaks the storage it points
to.
408 return (0); /* Empty property is not an error. */
409
410 for (i = 0, cfg = cfgtuples; i < ntuples; i++, cfg++) {
411 #ifndef __rtems__
412 if (bootverbose) {
413 char name[32];
/bsps/shared/freebsd/sys/arm/ti/ti_pinmux.c: 405 in
ti_pinmux_configure_pins()
399 #endif /* __rtems__ */
400 cfgnode = OF_node_from_xref(cfgxref);
401 ntuples = OF_getencprop_alloc_multi(cfgnode,
"pinctrl-single,pins",
402 sizeof(*cfgtuples), (void **));
403
404 if (ntuples < 0)
>>> CID 1474435:(RESOURCE_LEAK)
>>> Variable "cfgtuples" going out of scope leaks the storage it points
to.
405 return (ENOENT);
406
407 if (ntuples == 0)
408 return (0); /* Empty property is not an error. */
409
410 for (i = 0, cfg = cfgtuples; i < ntuples; i++, cfg++) {



To view the defects in Coverity Scan visit,
https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50ypUUzi-2FdSNmuyRB7BEFT8xQ4-2B8hpujh0hTgQljRGId4Dg-3D-3DZ9JC_EU3W9teASMK00lBXX9WT4lsogDrkCcNZLvg-2FVxwAXMrRpCRwRnwhWe3mGbZhfe5TEhVIZWqvzu-2BkK7GzWu18aemlzIGVqBnjE1VG1WYYnqAUylIIGsDE-2BbTTVBzIJdmJneUsK-2BEaTP8-2FdYkzR0L3nGksetaEs-2BWFiyM7otFz-2B3Jlvd7kkQjkZQhm78Hs6VA2e-2BgdMc6t9S3bFnOSaz2HAgqXpiOSsmtmoifKj8QLZB0-3D

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

Re: GSoC project: Memory protection (Ticket no: 2904)

[Rajiv Vaidyanathan]

Dear Utkarsh,

Thank you for providing these links. I would like to know if these pending
tasks are long enough to take it up as a GSoC project.

Thanks and regards,
Rajiv

On Tue, 23 Mar 2021 at 16:15, Utkarsh Rai  wrote:

>
>
> On Mon, Mar 22, 2021 at 9:54 PM Gedare Bloom  wrote:
>
>> Hi Rajiv,
>>
>> On Sat, Mar 20, 2021 at 12:40 AM Rajiv Vaidyanathan
>>  wrote:
>> >
>> > Hello RTEMS community,
>>
>
> Hello Rajiv,
>
>
>> >
>> > I am interested in the ticket: Memory protection. I saw that this topic
>> has been pursued a few times in GSoC. It would be great if someone can let
>> me know the current status of this project and guide me about what are the
>> contributions that can be done this year.
>> >
>> Yes, this is a frequently attempted project that slowly makes progress
>> over time. I think that Utkarsh has gotten somewhat close to a
>> workable solution, but there were some design flaws in his approach
>> for task stack protection (mainly, iterating over all the tasks) that
>> are still lingering.
>
>
> If you want to work on thread stack protection using MMU you can look at
> this
> thread  for
> the issues with my solution and possible resolutions to them.
> You can clone the 'Final-release' branch of this
>  repo to get an idea of the
> changes/additions that I had done and refer to this blog
> 
>  for
> a brief description of my idea
> behind making those changes/additions.
> Ideally, I would have liked to complete them for myself, this summer, but
> I am not sure
> if the time constraints that I have would allow me to pursue this right
> now.
>
>
>> There could be enough work here to pick up from his progress. The
>> major issue would be figuring out what  the final state of his code is
>> in, and to dig in to the design and implementation details to write a
>> concrete proposal how to bring task stack protection to a production
>> state. There may be other directions to consider as well, such as
>> improving the risc-v MMU support perhaps.
>>
>> > Thanks and regards,
>> > Rajiv
>> > ___
>> > 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 project: Memory protection (Ticket no: 2904)

[Utkarsh Rai]

On Mon, Mar 22, 2021 at 9:54 PM Gedare Bloom  wrote:

> Hi Rajiv,
>
> On Sat, Mar 20, 2021 at 12:40 AM Rajiv Vaidyanathan
>  wrote:
> >
> > Hello RTEMS community,
>

Hello Rajiv,


> >
> > I am interested in the ticket: Memory protection. I saw that this topic
> has been pursued a few times in GSoC. It would be great if someone can let
> me know the current status of this project and guide me about what are the
> contributions that can be done this year.
> >
> Yes, this is a frequently attempted project that slowly makes progress
> over time. I think that Utkarsh has gotten somewhat close to a
> workable solution, but there were some design flaws in his approach
> for task stack protection (mainly, iterating over all the tasks) that
> are still lingering.


If you want to work on thread stack protection using MMU you can look at
this
thread  for
the issues with my solution and possible resolutions to them.
You can clone the 'Final-release' branch of this
 repo to get an idea of the
changes/additions that I had done and refer to this blog

for
a brief description of my idea
behind making those changes/additions.
Ideally, I would have liked to complete them for myself, this summer, but I
am not sure
if the time constraints that I have would allow me to pursue this right
now.


> There could be enough work here to pick up from his progress. The
> major issue would be figuring out what  the final state of his code is
> in, and to dig in to the design and implementation details to write a
> concrete proposal how to bring task stack protection to a production
> state. There may be other directions to consider as well, such as
> improving the risc-v MMU support perhaps.
>
> > Thanks and regards,
> > Rajiv
> > ___
> > 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

GSoC Project - Beagle BSP Projects

[Ahamed Husni]

Hi everyone,

I'm really interested to work on the * Beagle BSP Projects* [#2891
].
*Adding PRU Support* [#3730 ] project
seems really interesting to me.
This project is partially done during GSoC 2019
by Nils Hölscher .
Is this a good project for the GSoC?

Up to now I have,

   1. Completed the GSoC prerequisite task
   2. Got the required hardware and tested it. (Beagleboard Black, USB to
   TTL Converter)
   3. Installed RTEMS on the Beagleboard and tested. (Screenshot attached
   below)


I need guidance to define the scope of the project.
I'm currently thinking of ,

   1. First finish the remaining work from GSoC 2019 on the PRU.
   (What is the status of current implementation of the PRU?)
   2. Implement additional peripheral support.
   What would be most useful?
   (USB OTG, CAN, ...).

The builtin USB is NOT functional other than for power under RTEMS.
> (USB OTG would have to be implemented in RTEMS to get rid of USB to TTL
> Converter.)
> - Ben Gras
> 
> (Blog post)
>

Thanks,
Husni Faiz.


[image: BBB_Serial_Out.png]
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH v2 1/1] bsps/riscv: Add per cpu clock interrupt

[Jan.Sommer]

> -Original Message-
> From: Gedare Bloom 
> Sent: Monday, March 22, 2021 5:52 PM
> To: Sebastian Huber 
> Cc: Sommer, Jan ; devel@rtems.org
> Subject: Re: [PATCH v2 1/1] bsps/riscv: Add per cpu clock interrupt
> 
> On Mon, Mar 22, 2021 at 10:28 AM Sebastian Huber
>  wrote:
> >
> >
> > On 22/03/2021 16:56, Jan Sommer wrote:
> > > diff --git a/bsps/riscv/riscv/clock/clockdrv.c
> > > b/bsps/riscv/riscv/clock/clockdrv.c
> > > index d085b6bd95..e8a39c8591 100644
> > > --- a/bsps/riscv/riscv/clock/clockdrv.c
> > > +++ b/bsps/riscv/riscv/clock/clockdrv.c
> > > @@ -41,6 +41,7 @@
> > >   #include 
> > >   #include 
> > >   #include 
> > > +#include 
> > >
> > >   #include 
> > >
> > > @@ -92,13 +93,18 @@ static void riscv_clock_at_tick(riscv_timecounter
> *tc)
> > >   {
> > > volatile RISCV_CLINT_regs *clint;
> > > uint64_t value;
> > > +  uint32_t cpu = 0;
> > > +
> > > +#if defined(RTEMS_SMP)
> > > +  cpu = _CPU_SMP_Get_current_processor(); #endif
> > You can use rtems_scheduler_get_processor() to get rid of this include
> > of an implementation header and the #if.
> >
> 
> Nice catch. Jan, you can push it with the modification to use the API function
> instead. (Note: BSPs are in a gray area, but generally considered as
> "application" layer, so we should prefer they use the APIs, and if they need
> to poke into the internals of RTEMS, we need to consider why and what can
> be done to avoid violation of the
> layer/encapsulation.)
> 

Thanks. Pushed to master with the changes applied.

> > --
> > 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/riscv: Add per cpu clock interrupt

[Jan.Sommer]

> -Original Message-
> From: Sebastian Huber 
> Sent: Monday, March 22, 2021 5:28 PM
> To: Sommer, Jan ; devel@rtems.org
> Subject: Re: [PATCH v2 1/1] bsps/riscv: Add per cpu clock interrupt
> 
> 
> On 22/03/2021 16:56, Jan Sommer wrote:
> > diff --git a/bsps/riscv/riscv/clock/clockdrv.c
> > b/bsps/riscv/riscv/clock/clockdrv.c
> > index d085b6bd95..e8a39c8591 100644
> > --- a/bsps/riscv/riscv/clock/clockdrv.c
> > +++ b/bsps/riscv/riscv/clock/clockdrv.c
> > @@ -41,6 +41,7 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >
> >   #include 
> >
> > @@ -92,13 +93,18 @@ static void riscv_clock_at_tick(riscv_timecounter
> *tc)
> >   {
> > volatile RISCV_CLINT_regs *clint;
> > uint64_t value;
> > +  uint32_t cpu = 0;
> > +
> > +#if defined(RTEMS_SMP)
> > +  cpu = _CPU_SMP_Get_current_processor(); #endif
> You can use rtems_scheduler_get_processor() to get rid of this include of an
> implementation header and the #if.
> 

Great. I was looking for that, but thought the function should be used by 
higher level applications because of the scheduler in the name.
Should have looked closer to see that it will end up 
_CPU_SMP_Get_current_processor in the end anyways.

Thanks, 

Jan

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