Re: [PATCH 3/6] shgen: Import from RTEMS

[Chris Johns]

On 07/06/2018 15:39, Sebastian Huber wrote:
> Corresponding RTEMS commit is 75933d5d25cd50f80162b7a0d2f66a5534e1763f.
> 
> Update #3443.
> ---
>  misc/shgen/AUTHORS |   3 +
>  misc/shgen/COPYING | 340 
> +
>  misc/shgen/TODO|  13 ++
>  misc/shgen/sci.c   | 177 
>  misc/shgen/sci.h   |  11 ++
>  misc/shgen/shgen.c | 114 ++
>  misc/wscript   |   9 ++
>  7 files changed, 667 insertions(+)
>  create mode 100644 misc/shgen/AUTHORS
>  create mode 100644 misc/shgen/COPYING
>  create mode 100644 misc/shgen/TODO
>  create mode 100644 misc/shgen/sci.c
>  create mode 100644 misc/shgen/sci.h
>  create mode 100644 misc/shgen/shgen.c
> 
> diff --git a/misc/shgen/AUTHORS b/misc/shgen/AUTHORS
> new file mode 100644
> index 000..225c2fa
> --- /dev/null
> +++ b/misc/shgen/AUTHORS
> @@ -0,0 +1,3 @@
> +Ralf Corsepius (corse...@faw.uni-ulm.de)
> + * Initial implementation
> + * generator for sci bitrate table
> diff --git a/misc/shgen/COPYING b/misc/shgen/COPYING
> new file mode 100644
> index 000..8cc2ef7
> --- /dev/null
> +++ b/misc/shgen/COPYING
> @@ -0,0 +1,340 @@
> +
> + GNU GENERAL PUBLIC LICENSE

The RTEMS tools is almost clean of GPL code. There is a small piece in the
rtemstoolkit I would to replace but I have not done that yet.

Does this tool need to move over? Is the sh arch active?

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

[PATCH 1/6] nios2gen: Import from RTEMS

[Sebastian Huber]

Corresponding RTEMS commit is 75933d5d25cd50f80162b7a0d2f66a5534e1763f.

Update #3444.
---
 misc/nios2gen/LICENSE|  20 ++
 misc/nios2gen/README | 146 
 misc/nios2gen/bridges.c  | 112 +++
 misc/nios2gen/bridges.h  |  29 ++
 misc/nios2gen/clocks.c   |  75 +
 misc/nios2gen/clocks.h   |  26 ++
 misc/nios2gen/devices.c  | 130 +++
 misc/nios2gen/devices.h  |  30 ++
 misc/nios2gen/linkcmds.c | 120 +++
 misc/nios2gen/linkcmds.h |  23 ++
 misc/nios2gen/memory.c   | 101 ++
 misc/nios2gen/memory.h   |  27 ++
 misc/nios2gen/nios2gen.c | 492 +++
 misc/nios2gen/output.c   | 193 +++
 misc/nios2gen/output.h   |  25 ++
 misc/nios2gen/ptf.c  | 857 +++
 misc/nios2gen/ptf.h  |  69 
 misc/nios2gen/sample.ptf | 462 +
 misc/wscript |  70 
 wscript  |   1 +
 20 files changed, 3008 insertions(+)
 create mode 100644 misc/nios2gen/LICENSE
 create mode 100644 misc/nios2gen/README
 create mode 100644 misc/nios2gen/bridges.c
 create mode 100644 misc/nios2gen/bridges.h
 create mode 100644 misc/nios2gen/clocks.c
 create mode 100644 misc/nios2gen/clocks.h
 create mode 100644 misc/nios2gen/devices.c
 create mode 100644 misc/nios2gen/devices.h
 create mode 100644 misc/nios2gen/linkcmds.c
 create mode 100644 misc/nios2gen/linkcmds.h
 create mode 100644 misc/nios2gen/memory.c
 create mode 100644 misc/nios2gen/memory.h
 create mode 100644 misc/nios2gen/nios2gen.c
 create mode 100644 misc/nios2gen/output.c
 create mode 100644 misc/nios2gen/output.h
 create mode 100644 misc/nios2gen/ptf.c
 create mode 100644 misc/nios2gen/ptf.h
 create mode 100644 misc/nios2gen/sample.ptf
 create mode 100644 misc/wscript

diff --git a/misc/nios2gen/LICENSE b/misc/nios2gen/LICENSE
new file mode 100644
index 000..1d85bbf
--- /dev/null
+++ b/misc/nios2gen/LICENSE
@@ -0,0 +1,20 @@
+  LICENSE INFORMATION
+
+RTEMS is free software; you can redistribute it and/or modify it under
+terms of the GNU General Public License as published by the
+Free Software Foundation; either version 2, or (at your option) any
+later version.  RTEMS is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+General Public License for more details. You should have received
+a copy of the GNU General Public License along with RTEMS; see
+file COPYING. If not, write to the Free Software Foundation, 675
+Mass Ave, Cambridge, MA 02139, USA.
+
+As a special exception, including RTEMS header files in a file,
+instantiating RTEMS generics or templates, or linking other files
+with RTEMS objects to produce an executable application, does not
+by itself cause the resulting executable application to be covered
+by the GNU General Public License. This exception does not
+however invalidate any other reasons why the executable file might be
+covered by the GNU Public License.
diff --git a/misc/nios2gen/README b/misc/nios2gen/README
new file mode 100644
index 000..1edcdb6
--- /dev/null
+++ b/misc/nios2gen/README
@@ -0,0 +1,146 @@
+nios2gen:
+  Tool to generate BSP data for boards utilizing NIOS2 soft core processor.
+
+=
+What it does
+
+It creates a sopc.h and linkcmds file for RTEMS nios2 BSPs from one or more 
inputs:
+
+1. SOPC System Description PTF
+
+As an output from SOPC Builder you get a file with extension ".ptf" that fully
+describes the SOPC, including all CPUs, memory and integrated peripherals.
+(PTF simply means "plain-text file").
+
+2. BSP Configuration PTF
+
+This file, using the same format as the SOPC System Description PTF, describes
+which components of the SOPC shall be used by the BSP. For example, there may
+be several timers, but a BSP wants at least one named "CLOCK" and optionally
+another named "TIMER". This mapping can be specified in the BSP.
+
+=
+Contents of the configuration PTF
+
+There can be definitions of ...
+
+HEADER: This is written to sopc.h before anything else. Example:
+
+  HEADER = "
+  #ifndef __SOPC_H
+  #define __SOPC_H 1
+  ";
+
+EPILOG: This is written to sopc.h after anything else. Example:
+
+  EPILOG = "
+  #endif
+  ";
+
+CLOCKS section: Used to specify names for clocks to be used in definitions in 
+the sopc.h. The default name (if none is specified here) is the uppercased name
+as in the system description PTF. Specify the name you want on the left, the
+name in the sopc PTF on the right! Example:
+
+  CLOCKS
+  {
+GLOBAL_CLOCK = "sys_clk";
+  }
+
+MODULES section: Same as clocks but for modules / peripherals. As a special 
definition,
+if the PTF contains more than one nios2 CPU, it /must/ define a CPU to use. 
Example to
+select cpu_0 and rename timer_0 to CLOCK and timer_1 to TIMER:
+
+  MODULES
+  {
+CPU = "cpu_0";
+CLOCK = "timer_0";
+

[PATCH 3/6] shgen: Import from RTEMS

[Sebastian Huber]

Corresponding RTEMS commit is 75933d5d25cd50f80162b7a0d2f66a5534e1763f.

Update #3443.
---
 misc/shgen/AUTHORS |   3 +
 misc/shgen/COPYING | 340 +
 misc/shgen/TODO|  13 ++
 misc/shgen/sci.c   | 177 
 misc/shgen/sci.h   |  11 ++
 misc/shgen/shgen.c | 114 ++
 misc/wscript   |   9 ++
 7 files changed, 667 insertions(+)
 create mode 100644 misc/shgen/AUTHORS
 create mode 100644 misc/shgen/COPYING
 create mode 100644 misc/shgen/TODO
 create mode 100644 misc/shgen/sci.c
 create mode 100644 misc/shgen/sci.h
 create mode 100644 misc/shgen/shgen.c

diff --git a/misc/shgen/AUTHORS b/misc/shgen/AUTHORS
new file mode 100644
index 000..225c2fa
--- /dev/null
+++ b/misc/shgen/AUTHORS
@@ -0,0 +1,3 @@
+Ralf Corsepius (corse...@faw.uni-ulm.de)
+   * Initial implementation
+   * generator for sci bitrate table
diff --git a/misc/shgen/COPYING b/misc/shgen/COPYING
new file mode 100644
index 000..8cc2ef7
--- /dev/null
+++ b/misc/shgen/COPYING
@@ -0,0 +1,340 @@
+
+   GNU GENERAL PUBLIC LICENSE
+  Version 2, June 1991
+
+ Copyright (C) 1989, 1991 Free Software Foundation, Inc.
+ 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+   Preamble
+
+  The licenses for most software are designed to take away your
+freedom to share and change it.  By contrast, the GNU General Public
+License is intended to guarantee your freedom to share and change free
+software--to make sure the software is free for all its users.  This
+General Public License applies to most of the Free Software
+Foundation's software and to any other program whose authors commit to
+using it.  (Some other Free Software Foundation software is covered by
+the GNU Library General Public License instead.)  You can apply it to
+your programs, too.
+
+  When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+this service if you wish), that you receive source code or can get it
+if you want it, that you can change the software or use pieces of it
+in new free programs; and that you know you can do these things.
+
+  To protect your rights, we need to make restrictions that forbid
+anyone to deny you these rights or to ask you to surrender the rights.
+These restrictions translate to certain responsibilities for you if you
+distribute copies of the software, or if you modify it.
+
+  For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must give the recipients all the rights that
+you have.  You must make sure that they, too, receive or can get the
+source code.  And you must show them these terms so they know their
+rights.
+
+  We protect your rights with two steps: (1) copyright the software, and
+(2) offer you this license which gives you legal permission to copy,
+distribute and/or modify the software.
+
+  Also, for each author's protection and ours, we want to make certain
+that everyone understands that there is no warranty for this free
+software.  If the software is modified by someone else and passed on, we
+want its recipients to know that what they have is not the original, so
+that any problems introduced by others will not reflect on the original
+authors' reputations.
+
+  Finally, any free program is threatened constantly by software
+patents.  We wish to avoid the danger that redistributors of a free
+program will individually obtain patent licenses, in effect making the
+program proprietary.  To prevent this, we have made it clear that any
+patent must be licensed for everyone's free use or not licensed at all.
+
+  The precise terms and conditions for copying, distribution and
+modification follow.
+
+   GNU GENERAL PUBLIC LICENSE
+   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+  0. This License applies to any program or other work which contains
+a notice placed by the copyright holder saying it may be distributed
+under the terms of this General Public License.  The "Program", below,
+refers to any such program or work, and a "work based on the Program"
+means either the Program or any derivative work under copyright law:
+that is to say, a work containing the Program or a portion of it,
+either verbatim or with modifications and/or translated into another
+language.  (Hereinafter, translation is included without limitation in
+the term "modification".)  Each licensee is addressed as "you".
+
+Activities other than copying, distribution and modification are not
+covered by this License; they are outside its scope.  The act of
+running the Program is not restricted, and the output from the Program
+is covered only if its 

[PATCH 2/6] nios2gen: Fix warnings

[Sebastian Huber]

Update #3444.
---
 misc/nios2gen/bridges.c  |  5 ++---
 misc/nios2gen/clocks.c   |  5 ++---
 misc/nios2gen/devices.c  |  4 ++--
 misc/nios2gen/linkcmds.c | 14 ++
 misc/nios2gen/memory.c   |  4 +---
 misc/nios2gen/nios2gen.c | 12 ++--
 misc/nios2gen/output.c   |  6 +++---
 misc/nios2gen/ptf.c  |  4 +---
 8 files changed, 23 insertions(+), 31 deletions(-)

diff --git a/misc/nios2gen/bridges.c b/misc/nios2gen/bridges.c
index feb90f9..cfd43d3 100644
--- a/misc/nios2gen/bridges.c
+++ b/misc/nios2gen/bridges.c
@@ -38,7 +38,6 @@ int is_bridged(
   char *dev_master,
   bus_bridge_pair *bridges)
 {
-  char *curr_master;
   bus_bridge_pair *bbp;
 
   if(strcmp(cpu_master, dev_master) == 0) return 1; /* cpu directly masters 
dev */
@@ -74,7 +73,7 @@ void add_bridge_master(struct ptf_item *pi, void *arg)
 void add_bridge_dest(struct ptf_item *pi, void *arg)
 {
 struct ptf maby_section = { section, "MASTERED_BY", 0, 0, 0 };
-struct ptf_item maby = { 1, _section };
+struct ptf_item maby = { 1, { _section } };
 
 char *bridge_name = pi->item[1]->value;
 char *bridge_dest = pi->item[pi->level]->value;
@@ -100,7 +99,7 @@ bus_bridge_pair *find_bridges(struct ptf *p)
 struct ptf slave  = { section, "SLAVE",  0, 0, 0 };
 struct ptf syb= { section, "SYSTEM_BUILDER_INFO", 0, 0, 0 };
 struct ptf to = { item,"Bridges_To", 0, 0, 0 };
-struct ptf_item brdg  = { 5, , , , ,  };
+struct ptf_item brdg  = { 5, { , , , ,  } };
 
 ptf_match(p, , add_bridge_dest, );
 
diff --git a/misc/nios2gen/clocks.c b/misc/nios2gen/clocks.c
index cb2befa..2b38e3f 100644
--- a/misc/nios2gen/clocks.c
+++ b/misc/nios2gen/clocks.c
@@ -15,7 +15,6 @@ void add_clock_spec(struct ptf_item *pi, void *arg)
 {
   clock_desc **clocks = arg;
   clock_desc *new_clock;
-  unsigned long freq;
 
   new_clock = (clock_desc*)malloc(sizeof(clock_desc));
   if(new_clock == NULL) return;
@@ -45,10 +44,10 @@ clock_desc *find_clocks( struct ptf *sopc, struct ptf *cfg )
 struct ptf all   = { section, "CLOCKS", 0, 0, 0 };
 struct ptf clock = { section, "CLOCK", 0, 0, 0 };
 struct ptf freq  = { item,"frequency", 0, 0, 0 };
-struct ptf_item clk_spec = { 5, , , , ,  };
+struct ptf_item clk_spec = { 5, { , , , ,  } 
};
 
 struct ptf named = { item, 0, 0, 0, 0 };
-struct ptf_item clk_cfg = { 2, ,  };
+struct ptf_item clk_cfg = { 2, { ,  } };
 
 clocks = NULL;
 ptf_match(sopc, _spec, add_clock_spec, );
diff --git a/misc/nios2gen/devices.c b/misc/nios2gen/devices.c
index 7894294..037c987 100644
--- a/misc/nios2gen/devices.c
+++ b/misc/nios2gen/devices.c
@@ -73,11 +73,11 @@ device_desc *find_devices(
 struct ptf slave  = { section, "SLAVE",  0, 0, 0 };
 struct ptf syb= { section, "SYSTEM_BUILDER_INFO", 0, 0, 0 };
 struct ptf maby   = { section, "MASTERED_BY", 0, 0, 0 };
-struct ptf_item brdg  = { 5, , , , ,  };
+struct ptf_item brdg  = { 5, { , , , ,  } };
 
 struct ptf modules= { section, "MODULES", 0, 0, 0 };
 struct ptf named  = { item, 0, 0, 0, 0};
-struct ptf_item devcf = { 2, ,  };
+struct ptf_item devcf = { 2, { ,  } };
 
 struct { char *dm; char *im; device_desc **dl; bus_bridge_pair *bridges; } 
dinfo;
 
diff --git a/misc/nios2gen/linkcmds.c b/misc/nios2gen/linkcmds.c
index 8ed0ddb..3a56165 100644
--- a/misc/nios2gen/linkcmds.c
+++ b/misc/nios2gen/linkcmds.c
@@ -71,22 +71,20 @@ void fwrite_lcmds_section(struct ptf_item *pi, void *arg)
 
 void fwrite_linkcmds_file(FILE *file, struct ptf *cfg, struct ptf *cpu, 
device_desc *devices, memory_desc *memory)
 {
-  struct ptf *p;
-  struct ptf_item pi;
   memory_desc *tmd;
   lcmd_desc linfo;
 
   struct ptf ptlink = { section, "LINKCMDS", 0, 0, 0 };
   struct ptf ptleadtext = { item,"LEADTEXT", 0, 0, 0 };
   struct ptf ptepilog = { item,"EPILOG", 0, 0, 0 };
-  struct ptf_item malihead = { 2, ,  };
-  struct ptf_item maliepil = { 2, ,  };
+  struct ptf_item malihead = { 2, { ,  } };
+  struct ptf_item maliepil = { 2, { ,  } };
 
   struct ptf ptsect = { section, "SECTION", 0, 0, 0 };
   struct ptf ptcmds = { item, "COMMANDS", 0, 0, 0 };
   struct ptf ptstabs = { item, "STABS", 0, 0, 0 };
-  struct ptf_item malisect = { 3, , ,  };
-  struct ptf_item malistabs = { 2, ,  };
+  struct ptf_item malisect = { 3, { , ,  } };
+  struct ptf_item malistabs = { 2, { ,  } };
 
   linfo.cfg = cfg;
   linfo.cpu = cpu;
@@ -99,7 +97,7 @@ void fwrite_linkcmds_file(FILE *file, struct ptf *cfg, struct 
ptf *cpu, device_d
   fprintf(file, "MEMORY\n{\n");
   for(tmd = linfo.memory; tmd; tmd = tmd->next)
   {
-fprintf(file, "%s : ORIGIN = 0x%08X, LENGTH = 0x%08X\n", 
tmd->dev->cfgname, tmd->base, tmd->size);
+fprintf(file, "%s : ORIGIN = 0x%08lX, LENGTH = 0x%08lX\n", 
tmd->dev->cfgname, tmd->base, tmd->size);
   }
   fprintf(file, "}\n\nSECTIONS\n{\n");
 
@@ -108,7 +106,7 @@ void 

[PATCH 5/6] bin2c: Import from RTEMS

[Sebastian Huber]

Corresponding RTEMS commit is 75933d5d25cd50f80162b7a0d2f66a5534e1763f.

Update #3380.
---
 misc/bin2c/compat.c  |  44 +++
 misc/bin2c/rtems-bin2c.c | 330 +++
 misc/wscript |  12 ++
 3 files changed, 386 insertions(+)
 create mode 100644 misc/bin2c/compat.c
 create mode 100644 misc/bin2c/rtems-bin2c.c

diff --git a/misc/bin2c/compat.c b/misc/bin2c/compat.c
new file mode 100644
index 000..9c6eb10
--- /dev/null
+++ b/misc/bin2c/compat.c
@@ -0,0 +1,44 @@
+/*
+ * Copyright (c) 2014 embedded brains GmbH.  All rights reserved.
+ *
+ *  embedded brains GmbH
+ *  Dornierstr. 4
+ *  82178 Puchheim
+ *  Germany
+ *  
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+
+#include "config.h"
+
+#include 
+
+#if !HAVE_STRNLEN
+size_t strnlen(const char *s, size_t maxlen)
+{
+  const char *n = memchr(s, '\0', maxlen);
+
+  return n != NULL ? n - s : maxlen;
+}
+#endif
diff --git a/misc/bin2c/rtems-bin2c.c b/misc/bin2c/rtems-bin2c.c
new file mode 100644
index 000..53caf27
--- /dev/null
+++ b/misc/bin2c/rtems-bin2c.c
@@ -0,0 +1,330 @@
+/*
+ * bin2c.c
+ *
+ * convert a binary file into a C source array.
+ *
+ * THE "BEER-WARE LICENSE" (Revision 3.1415):
+ * sandro AT sigala DOT it wrote this file. As long as you retain this
+ * notice you can do whatever you want with this stuff.  If we meet some
+ * day, and you think this stuff is worth it, you can buy me a beer in
+ * return.  Sandro Sigala
+ *
+ * Subsequently modified by Joel Sherrill 
+ * to add a number of capabilities not in the original.
+ *
+ * syntax:  bin2c [-c] [-z]  
+ *
+ *-cdo NOT add the "const" keyword to definition
+ *-sadd the "static" keywork to definition
+ *-vverbose
+ *-zterminate the array with a zero (useful for embedded C strings)
+ *
+ * examples:
+ * bin2c -c myimage.png myimage_png.cpp
+ * bin2c -z sometext.txt sometext_txt.cpp
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifndef PATH_MAX
+#define PATH_MAX 1024
+#endif
+
+int useconst = 1;
+int usestatic = 0;
+int verbose = 0;
+int zeroterminated = 0;
+int createC = 1;
+int createH = 1;
+
+int myfgetc(FILE *f)
+{
+  int c = fgetc(f);
+  if (c == EOF && zeroterminated) {
+zeroterminated = 0;
+return 0;
+  }
+  return c;
+}
+
+void process(const char *ifname, const char *ofname, const char *forced_name)
+{
+  FILE *ifile, *ocfile, *ohfile;
+  char buf[PATH_MAX+1], *p;
+  char obasename[PATH_MAX+1];
+  char ocname[PATH_MAX+1];
+  char ohname[PATH_MAX+1];
+  const char *cp;
+  size_t len;
+
+  ocfile = NULL;
+  ohfile = NULL;
+
+  /* Error check */
+  if ( !ifname || !ofname ) {
+fprintf(stderr, "process has NULL filename\n");
+exit(1);
+  }
+
+  strncpy( obasename, ofname, PATH_MAX );
+  len = strnlen( obasename, PATH_MAX );
+  if ( len >= 2 ) {
+if ( obasename[len-2] == '.' ) {
+  if ( (obasename[len-1] == 'c') || (obasename[len-1] == 'h') )
+obasename[len-2] = '\0';
+}
+  }
+
+  sprintf( ocname, "%s.c", obasename );
+  sprintf( ohname, "%s.h", obasename );
+
+  if ( verbose ) {
+fprintf(
+  stderr,
+  "in file: %s\n"
+  "c file: %s\n"
+  "h file: %s\n",
+  ifname,
+  ocname,
+  ohname
+);
+  }
+
+  /* Open input and output files */
+  ifile = fopen(ifname, "rb");
+  if (ifile == NULL) {
+fprintf(stderr, "cannot open %s for reading\n", ifname);
+exit(1);
+  }
+
+  if ( createC ) {
+ocfile = fopen(ocname, "wb");
+if (ocfile == NULL) {
+  fprintf(stderr, "cannot open %s for writing\n", ocname);
+  exit(1);
+}
+  }
+
+  if ( createH ) {
+ohfile = fopen(ohname, "wb");
+if (ohfile == NULL) {
+  

[PATCH 6/6] bin2c: Fix warnings

[Sebastian Huber]

Update #3380.
---
 misc/bin2c/rtems-bin2c.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/misc/bin2c/rtems-bin2c.c b/misc/bin2c/rtems-bin2c.c
index 53caf27..6381766 100644
--- a/misc/bin2c/rtems-bin2c.c
+++ b/misc/bin2c/rtems-bin2c.c
@@ -59,7 +59,6 @@ void process(const char *ifname, const char *ofname, const 
char *forced_name)
   char obasename[PATH_MAX+1];
   char ocname[PATH_MAX+1];
   char ohname[PATH_MAX+1];
-  const char *cp;
   size_t len;
 
   ocfile = NULL;
-- 
2.13.7

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

[PATCH 4/6] shgen: Fix warnings

[Sebastian Huber]

Update #3443.
---
 misc/shgen/sci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/misc/shgen/sci.c b/misc/shgen/sci.c
index 2b68612..3a093c0 100644
--- a/misc/shgen/sci.c
+++ b/misc/shgen/sci.c
@@ -138,7 +138,7 @@ int shgen_gensci(
 
 if ( i > 0 )
   fprintf( file, ",\n" );
-  fprintf( file, "  { %1d, %3d, %d } /* %+7.2f%% ; B%d ",
+fprintf( file, "  { %1d, %3d, %d } /* %+7.2f%% ; B%d ",
   best->n,
   best->N,
   best->B,
-- 
2.13.7

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

Re: (release notes generator) How to convert python dictionary to release notes using sphinx?

[Chris Johns]

On 07/06/2018 13:40, Dannie Huang wrote:
> 
> Currently data from milestone page and ticket page is stored in python
> dictionary, 

This is great. Where is the code so it can be reviewed?

> how can I convert python dictionary to release notes using sphinx? I
> have checked sphinx documentation but not exactly sure how to do it.

I am not yet sure ReST and Sphinx is the best solution. We need to decide.

We could use Markdown and get a similar result. The RSB has a Markdown
implementation ...

https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/markdown

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

(release notes generator) How to convert python dictionary to release notes using sphinx?

[Dannie Huang]

Hi,

Currently data from milestone page and ticket page is stored in python
dictionary, how can I convert python dictionary to release notes using
sphinx? I have checked sphinx documentation but not exactly sure how to do
it.

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

Re: configure/make with multiple jobs error?

[Chris Johns]

On 07/06/2018 03:55, Gedare Bloom wrote:
> On Tue, Jun 5, 2018 at 9:02 PM, Chris Johns  wrote:
>> On 31/5/18 2:56 am, Gedare Bloom wrote:
>>
>> Is this still only with a concurrent build?
>>
> 
> I think this was without concurrent build.
> 

Then I suspect this is the space in the path.

>>> make[4]: Entering directory '/media/gedare/Seagate Expansion
>>> Drive/work/rtems/builds/b-erc32-5/sparc-rtems5/c/erc32/lib/libbsp'
>>
>> I wonder if some of the internal shell script processing we have is safe 
>> with a
>> space in a path?
>>
> 
> It is possible. I've had problems before with spaces in the path using
> RSB and rtems-test tools. I haven't had trouble before with
> configure/make though.
> 

The base autoconf and automake should be clean but we have a range of scripts
and m4 fragments that may not be.

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

Re: [Tracing] Deciding the Yaml configuration for barectf input

[Vidushi Vashishth]

Hey Guillaume!

>I am wondering what tools are currently used for visualizing the resulting
RTEMS trace, if any. And what are your plan on this aspect once you can
output CTF traces with >RTEMS?

RTEMS wiki pages do suggest using trace compass for the purpose of
visualization of traces [1]. It seems like a good choice.

>There is currently interest in providing support for generic RTOS support
in Trace Compass [1], which I'll be working on soon. If we could coordinate
on this aspect >regarding traced events, I think we could achieve
interesting things.

For sure! I look forward to it.

>Also, my two cent for your question is that you are much better
integrating CTF gen directly in RTEMS if modification to babeltrace source
code would be required. I think it >would be simpler to upstream your
changes that way.

Yes that would be simpler. But at some point in time I will have to decide
on a CTF structure for the output traces. I suspect this knowledge will
also be used when changing the babeltrace source code for RTEMS trace
format conversion. And hence the urgent need for advice :p

Thanks for the input:)

Vidushi

On Wed, Jun 6, 2018 at 11:16 PM, Guillaume Champagne <
guillaume.champa...@polymtl.ca> wrote:

> Hi Vidushi,
>
> I am not answering on the mailing list, because I am not sure if my
> questions were already answered previously.
>
> If I understand correctly, the first part of your GSOC project is to
> integrate CTF traces to kernel level event in RTEMS?
> I am wondering what tools are currently used for visualizing the resulting
> RTEMS trace, if any. And what are your plan on this aspect once you can
> output CTF traces with RTEMS?
>
> There is currently interest in providing support for generic RTOS support
> in Trace Compass [1], which I'll be working on soon. If we could coordinate
> on this aspect regarding traced events, I think we could achieve
> interesting things.
>
> Also, my two cent for your question is that you are much better
> integrating CTF gen directly in RTEMS if modification to babeltrace source
> code would be required. I think it would be simpler to upstream your
> changes that way.
>
> [1] http://tracecompass.org/
>
> Guillaume
>
> Vidushi Vashishth  a écrit :
>
>
> Hi!
>>
>> I have written a blog post  (https://vidushivashishth.gith
>> ub.io/sixthpost/)
>> summarizing two approaches to CTF generation that I can employ at this
>> point. I prefer on working with the barectf approach. The only blocker
>> that
>> exists with this approach is deciding on a YAML configuration [1] for
>> defining the structure of the CTF traces. This will be the input to the
>> barectf. I needed advice on how to go about this.
>>
>> References:
>> [1]
>> https://github.com/efficios/barectf/wiki/Writing-the-YAML-co
>> nfiguration-file
>>
>> Thanks,
>> Vidushi
>>
>
>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: error while building leon3 with gcov flags

[Vijay Kumar Banerjee]

On Thu, 7 Jun 2018, 02:39 Joel Sherrill,  wrote:

>
>
> On Wed, Jun 6, 2018, 3:56 PM Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> On 7 June 2018 at 01:48, Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Wed, Jun 6, 2018, 2:07 PM Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 On 6 June 2018 at 20:49, Joel Sherrill  wrote:

> I can't duplicate this. My configure command was:
>
> ../rtems/configure --target=sparc-rtems5 --enable-rtemsbsp=leon3
> --prefix=/home/joel/rtems-work/tools/5 \
>--disable-networking --enable-posix --disable-smp
> --disable-multiprocessing \
>--enable-tests --enable-cxx --enable-maintainer-mode
>
> What was yours?
>
> I didn't have --enable-cxx and --enable-maintainer-more.

 I made some tries and somehow it's perfectly working now.

 I am trying to find out now how covoar generates the reports.
 I made a file with a list of all gcno in score/ and run with -g argument
 now I'mg seeing the following error while running covoar

 ==
 Generating Gcov reports...
 Processing file: libscore_a-allocatormutex.gcno
 Unable to open libscore_a-allocatormutex.gcno
 Processing file: libscore_a-apimutexisowner.gcno
 Unable to open libscore_a-apimutexisowner.gcno
 Processing file: libscore_a-apimutexlock.gcno
 Unable to open libscore_a-apimutexlock.gcno
 Processing file: libscore_a-apimutexunlock.gcno
 Unable to open libscore_a-apimutexunlock.gcno
 Processing file: libscore_a-chain.gcno
 Unable to open libscore_a-chain.gcno
 Processing file: libscore_a-chainnodecount.gcno
 .
 .
 .
 ==

>>>
>>> I suspect this is another instance of the path issues inside the build
>>> tree you and Cillian fixed earlier.
>>>
>>> correcting the path worked.
>>
>
> Submit a patch for this. It needs fixing to get 5onyour next issue.
>
It just needed the absolute path to be fed.
here's what I did.
I manually 'find' all the gcno files under score.
wrote it all in a file separated by newlines.
fed that file as an argument to covoar.
and that brought me here.

So when we write script, these are the
things that will be done by the script.

Once everything strats running manually,
we can proceed to write scripts.

>
>> Now I'm getting this error.
>>
>> Generating Gcov reports...
>> Processing file:
>> sparc-rtems5/c/leon3/cpukit/score/src/libscore_a-kern_tc.gcno
>> ERROR: Unable to read string from gcov file
>> ERROR: Unable to read string length from gcov file
>> ERROR: Unable to read Function starting line number
>> Segmentation fault (core dumped)
>>
>
> Welcome to GSoC! You are now in new territory. :)
>
So here the real work begins!

>
> Dig in and see what went wrong. Be aware.that GCC file formats may (or may
> not) be subject to.changing over time and this could just be bitrot.
>
I got started with it.

>
> Gcov-dump is installed with the compiler.
>
> You should check it we have a .h file describing the file and it is out of
> date.
>
I'll look into it.

>
> Also I think we now should bring the gsov maintainer in.
>
The covoar's gcov support needs to be reworked.
We can get the help of the expert here.

>
> Good job!
>
Thanks. :)

>
>
>>
> On Wed, Jun 6, 2018 at 9:40 AM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> Hello,
>>
>> I have added the following changes in the
>> bsps/sparc/leon3/config/leon3.cfg
>>
>> --
>> CFLAGS_OPTIMIZE_V = -Os -g
>> CFLAGS_OPTIMIZE_V += -ftest-coverage
>> ---
>>
>> While trying to build with these flags, I got a bunch of
>> the following errors:
>>
>> ==
>> {standard input}: Assembler messages:
>> {standard input}:6510: Error: can't resolve `.data._SPARC_Counter'
>> {.data._SPARC_Counter section} - `.LLtext0' {.text section}
>> {standard input}:6511: Error: can't resolve `.data._SPARC_Counter'
>> {.data._SPARC_Counter section} - `.LLtext0' {.text section}
>>
>> ===
>>
>> after the `make install` I do get a lot of .gcno files, and no
>> executables.
>>
>> -- vijay
>>
>> ___
>> 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: error while building leon3 with gcov flags

[Joel Sherrill]

On Wed, Jun 6, 2018, 3:56 PM Vijay Kumar Banerjee 
wrote:

> On 7 June 2018 at 01:48, Joel Sherrill  wrote:
>
>>
>>
>> On Wed, Jun 6, 2018, 2:07 PM Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 6 June 2018 at 20:49, Joel Sherrill  wrote:
>>>
 I can't duplicate this. My configure command was:

 ../rtems/configure --target=sparc-rtems5 --enable-rtemsbsp=leon3
 --prefix=/home/joel/rtems-work/tools/5 \
--disable-networking --enable-posix --disable-smp
 --disable-multiprocessing \
--enable-tests --enable-cxx --enable-maintainer-mode

 What was yours?

 I didn't have --enable-cxx and --enable-maintainer-more.
>>>
>>> I made some tries and somehow it's perfectly working now.
>>>
>>> I am trying to find out now how covoar generates the reports.
>>> I made a file with a list of all gcno in score/ and run with -g argument
>>> now I'mg seeing the following error while running covoar
>>>
>>> ==
>>> Generating Gcov reports...
>>> Processing file: libscore_a-allocatormutex.gcno
>>> Unable to open libscore_a-allocatormutex.gcno
>>> Processing file: libscore_a-apimutexisowner.gcno
>>> Unable to open libscore_a-apimutexisowner.gcno
>>> Processing file: libscore_a-apimutexlock.gcno
>>> Unable to open libscore_a-apimutexlock.gcno
>>> Processing file: libscore_a-apimutexunlock.gcno
>>> Unable to open libscore_a-apimutexunlock.gcno
>>> Processing file: libscore_a-chain.gcno
>>> Unable to open libscore_a-chain.gcno
>>> Processing file: libscore_a-chainnodecount.gcno
>>> .
>>> .
>>> .
>>> ==
>>>
>>
>> I suspect this is another instance of the path issues inside the build
>> tree you and Cillian fixed earlier.
>>
>> correcting the path worked.
>

Submit a patch for this. It needs fixing to get 5onyour next issue.

>
> Now I'm getting this error.
>
> Generating Gcov reports...
> Processing file:
> sparc-rtems5/c/leon3/cpukit/score/src/libscore_a-kern_tc.gcno
> ERROR: Unable to read string from gcov file
> ERROR: Unable to read string length from gcov file
> ERROR: Unable to read Function starting line number
> Segmentation fault (core dumped)
>

Welcome to GSoC! You are now in new territory. :)

Dig in and see what went wrong. Be aware.that GCC file formats may (or may
not) be subject to.changing over time and this could just be bitrot.

Gcov-dump is installed with the compiler.

You should check it we have a .h file describing the file and it is out of
date.

Also I think we now should bring the gsov maintainer in.

Good job!


>
 On Wed, Jun 6, 2018 at 9:40 AM, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> Hello,
>
> I have added the following changes in the
> bsps/sparc/leon3/config/leon3.cfg
>
> --
> CFLAGS_OPTIMIZE_V = -Os -g
> CFLAGS_OPTIMIZE_V += -ftest-coverage
> ---
>
> While trying to build with these flags, I got a bunch of
> the following errors:
>
> ==
> {standard input}: Assembler messages:
> {standard input}:6510: Error: can't resolve `.data._SPARC_Counter'
> {.data._SPARC_Counter section} - `.LLtext0' {.text section}
> {standard input}:6511: Error: can't resolve `.data._SPARC_Counter'
> {.data._SPARC_Counter section} - `.LLtext0' {.text section}
>
> ===
>
> after the `make install` I do get a lot of .gcno files, and no
> executables.
>
> -- vijay
>
> ___
> 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: error while building leon3 with gcov flags

[Vijay Kumar Banerjee]

On 7 June 2018 at 01:48, Joel Sherrill  wrote:

>
>
> On Wed, Jun 6, 2018, 2:07 PM Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> On 6 June 2018 at 20:49, Joel Sherrill  wrote:
>>
>>> I can't duplicate this. My configure command was:
>>>
>>> ../rtems/configure --target=sparc-rtems5 --enable-rtemsbsp=leon3
>>> --prefix=/home/joel/rtems-work/tools/5 \
>>>--disable-networking --enable-posix --disable-smp
>>> --disable-multiprocessing \
>>>--enable-tests --enable-cxx --enable-maintainer-mode
>>>
>>> What was yours?
>>>
>>> I didn't have --enable-cxx and --enable-maintainer-more.
>>
>> I made some tries and somehow it's perfectly working now.
>>
>> I am trying to find out now how covoar generates the reports.
>> I made a file with a list of all gcno in score/ and run with -g argument
>> now I'mg seeing the following error while running covoar
>>
>> ==
>> Generating Gcov reports...
>> Processing file: libscore_a-allocatormutex.gcno
>> Unable to open libscore_a-allocatormutex.gcno
>> Processing file: libscore_a-apimutexisowner.gcno
>> Unable to open libscore_a-apimutexisowner.gcno
>> Processing file: libscore_a-apimutexlock.gcno
>> Unable to open libscore_a-apimutexlock.gcno
>> Processing file: libscore_a-apimutexunlock.gcno
>> Unable to open libscore_a-apimutexunlock.gcno
>> Processing file: libscore_a-chain.gcno
>> Unable to open libscore_a-chain.gcno
>> Processing file: libscore_a-chainnodecount.gcno
>> .
>> .
>> .
>> ==
>>
>
> I suspect this is another instance of the path issues inside the build
> tree you and Cillian fixed earlier.
>
> correcting the path worked.

Now I'm getting this error.

Generating Gcov reports...
Processing file:
sparc-rtems5/c/leon3/cpukit/score/src/libscore_a-kern_tc.gcno
ERROR: Unable to read string from gcov file
ERROR: Unable to read string length from gcov file
ERROR: Unable to read Function starting line number
Segmentation fault (core dumped)


>>> On Wed, Jun 6, 2018 at 9:40 AM, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 Hello,

 I have added the following changes in the bsps/sparc/leon3/config/leon3.
 cfg

 --
 CFLAGS_OPTIMIZE_V = -Os -g
 CFLAGS_OPTIMIZE_V += -ftest-coverage
 ---

 While trying to build with these flags, I got a bunch of
 the following errors:

 ==
 {standard input}: Assembler messages:
 {standard input}:6510: Error: can't resolve `.data._SPARC_Counter'
 {.data._SPARC_Counter section} - `.LLtext0' {.text section}
 {standard input}:6511: Error: can't resolve `.data._SPARC_Counter'
 {.data._SPARC_Counter section} - `.LLtext0' {.text section}

 ===

 after the `make install` I do get a lot of .gcno files, and no
 executables.

 -- vijay

 ___
 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: error while building leon3 with gcov flags

[Joel Sherrill]

On Wed, Jun 6, 2018, 2:07 PM Vijay Kumar Banerjee 
wrote:

> On 6 June 2018 at 20:49, Joel Sherrill  wrote:
>
>> I can't duplicate this. My configure command was:
>>
>> ../rtems/configure --target=sparc-rtems5 --enable-rtemsbsp=leon3
>> --prefix=/home/joel/rtems-work/tools/5 \
>>--disable-networking --enable-posix --disable-smp
>> --disable-multiprocessing \
>>--enable-tests --enable-cxx --enable-maintainer-mode
>>
>> What was yours?
>>
>> I didn't have --enable-cxx and --enable-maintainer-more.
>
> I made some tries and somehow it's perfectly working now.
>
> I am trying to find out now how covoar generates the reports.
> I made a file with a list of all gcno in score/ and run with -g argument
> now I'mg seeing the following error while running covoar
>
> ==
> Generating Gcov reports...
> Processing file: libscore_a-allocatormutex.gcno
> Unable to open libscore_a-allocatormutex.gcno
> Processing file: libscore_a-apimutexisowner.gcno
> Unable to open libscore_a-apimutexisowner.gcno
> Processing file: libscore_a-apimutexlock.gcno
> Unable to open libscore_a-apimutexlock.gcno
> Processing file: libscore_a-apimutexunlock.gcno
> Unable to open libscore_a-apimutexunlock.gcno
> Processing file: libscore_a-chain.gcno
> Unable to open libscore_a-chain.gcno
> Processing file: libscore_a-chainnodecount.gcno
> .
> .
> .
> ==
>

I suspect this is another instance of the path issues inside the build tree
you and Cillian fixed earlier.


>> On Wed, Jun 6, 2018 at 9:40 AM, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I have added the following changes in the
>>> bsps/sparc/leon3/config/leon3.cfg
>>>
>>> --
>>> CFLAGS_OPTIMIZE_V = -Os -g
>>> CFLAGS_OPTIMIZE_V += -ftest-coverage
>>> ---
>>>
>>> While trying to build with these flags, I got a bunch of
>>> the following errors:
>>>
>>> ==
>>> {standard input}: Assembler messages:
>>> {standard input}:6510: Error: can't resolve `.data._SPARC_Counter'
>>> {.data._SPARC_Counter section} - `.LLtext0' {.text section}
>>> {standard input}:6511: Error: can't resolve `.data._SPARC_Counter'
>>> {.data._SPARC_Counter section} - `.LLtext0' {.text section}
>>>
>>> ===
>>>
>>> after the `make install` I do get a lot of .gcno files, and no
>>> executables.
>>>
>>> -- vijay
>>>
>>> ___
>>> 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: error while building leon3 with gcov flags

[Vijay Kumar Banerjee]

On 6 June 2018 at 20:49, Joel Sherrill  wrote:

> I can't duplicate this. My configure command was:
>
> ../rtems/configure --target=sparc-rtems5 --enable-rtemsbsp=leon3
> --prefix=/home/joel/rtems-work/tools/5 \
>--disable-networking --enable-posix --disable-smp
> --disable-multiprocessing \
>--enable-tests --enable-cxx --enable-maintainer-mode
>
> What was yours?
>
> I didn't have --enable-cxx and --enable-maintainer-more.

I made some tries and somehow it's perfectly working now.

I am trying to find out now how covoar generates the reports.
I made a file with a list of all gcno in score/ and run with -g argument
now I'mg seeing the following error while running covoar

==
Generating Gcov reports...
Processing file: libscore_a-allocatormutex.gcno
Unable to open libscore_a-allocatormutex.gcno
Processing file: libscore_a-apimutexisowner.gcno
Unable to open libscore_a-apimutexisowner.gcno
Processing file: libscore_a-apimutexlock.gcno
Unable to open libscore_a-apimutexlock.gcno
Processing file: libscore_a-apimutexunlock.gcno
Unable to open libscore_a-apimutexunlock.gcno
Processing file: libscore_a-chain.gcno
Unable to open libscore_a-chain.gcno
Processing file: libscore_a-chainnodecount.gcno
.
.
.
==

>
> On Wed, Jun 6, 2018 at 9:40 AM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> Hello,
>>
>> I have added the following changes in the bsps/sparc/leon3/config/leon3.
>> cfg
>>
>> --
>> CFLAGS_OPTIMIZE_V = -Os -g
>> CFLAGS_OPTIMIZE_V += -ftest-coverage
>> ---
>>
>> While trying to build with these flags, I got a bunch of
>> the following errors:
>>
>> ==
>> {standard input}: Assembler messages:
>> {standard input}:6510: Error: can't resolve `.data._SPARC_Counter'
>> {.data._SPARC_Counter section} - `.LLtext0' {.text section}
>> {standard input}:6511: Error: can't resolve `.data._SPARC_Counter'
>> {.data._SPARC_Counter section} - `.LLtext0' {.text section}
>>
>> ===
>>
>> after the `make install` I do get a lot of .gcno files, and no
>> executables.
>>
>> -- vijay
>>
>> ___
>> 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: configure/make with multiple jobs error?

[Gedare Bloom]

On Tue, Jun 5, 2018 at 9:02 PM, Chris Johns  wrote:
> On 31/5/18 2:56 am, Gedare Bloom wrote:
>> On Wed, May 30, 2018 at 12:15 PM, Gedare Bloom  wrote:
>>> On Wed, May 30, 2018 at 12:10 PM, Gedare Bloom  wrote:
 Hello all,

 I got a strange error just now with a fresh toolchain and current master.

 I did:
 $ ../../rtems/configure --target=sparc-rtems5 --enable-rtemsbsp=erc32
 --enable-tests
 This was OK.

 $ make -j4
 This errored out with:
 checking for gawk... gawk
 checking whether make sets $(MAKE)... yes
 checking whether to enable maintainer-specific portions of Makefiles... no
 checking for RTEMS_BSP... erc32
 checking for perl... /usr/bin/perl
 configure: error: Invalid BSP
 configure: error:
 ../../../../../../../../rtems/c/src/lib/libbsp/sparc/configure failed
 for lib/libbsp/sparc
 Makefile:731: recipe for target 'erc32' failed
 make[2]: *** [erc32] Error 1
 make[2]: Leaving directory '/media/gedare/Seagate Expansion
 Drive/work/rtems/builds/b-erc32-5/sparc-rtems5/c'
 Makefile:289: recipe for target 'all-recursive' failed
 make[1]: *** [all-recursive] Error 1
 make[1]: Leaving directory '/media/gedare/Seagate Expansion
 Drive/work/rtems/builds/b-erc32-5/sparc-rtems5/c'
 Makefile:414: recipe for target 'all-recursive' failed
 make: *** [all-recursive] Error 1

>>
>> This error about Invalid BSP still occurs for me with a cleaned local
>> repo where I removed all the old files/directories. Maybe I missed a
>> change in developer workflow, but I think I am tripped a concurrency
>> bug in configure script still, because 'make' proceeds
>>
 $ make
 This works.

>>>
>>> Actually, this did not work all the way, it broke later. I think I
>>> have leftover files/directories in my libbsp (I haven't built since
>>> the cleanup/move was done) that could be causing me problems. I'll
>>> report back in a bit after I clean this stuff out.
>>>
>>
>> But I still get an error eventually here, too:
>
> Is this still only with a concurrent build?
>

I think this was without concurrent build.

>> make[4]: Entering directory '/media/gedare/Seagate Expansion
>> Drive/work/rtems/builds/b-erc32-5/sparc-rtems5/c/erc32/lib/libbsp'
>
> I wonder if some of the internal shell script processing we have is safe with 
> a
> space in a path?
>

It is possible. I've had problems before with spaces in the path using
RSB and rtems-test tools. I haven't had trouble before with
configure/make though.

> What type of bus is this drive connected too?
>

This is a USB external drive.


> Is this a VM or native on a host?
>

Native.

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

[Tracing] Deciding the Yaml configuration for barectf input

[Vidushi Vashishth]

Hi!

I have written a blog post  (https://vidushivashishth.github.io/sixthpost/)
summarizing two approaches to CTF generation that I can employ at this
point. I prefer on working with the barectf approach. The only blocker that
exists with this approach is deciding on a YAML configuration [1] for
defining the structure of the CTF traces. This will be the input to the
barectf. I needed advice on how to go about this.

References:
[1]
https://github.com/efficios/barectf/wiki/Writing-the-YAML-configuration-file

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

Thoughts on Reusing FreeBSD msun tests

[Joel Sherrill]

Hi

I can't find this on FreeBSD head but it looks like a decent
set of tests for fenv and other libm functionality.

http://web.mit.edu/freebsd/head/tools/regression/lib/msun/

Thoughts on incorporating this into our tests?

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

Re: (release notes generator) Do we need to worry about attachment?

[Dannie Huang]

The attachment problem has been solved, thank you so much!

-Dannie

On Tue, Jun 5, 2018 at 8:43 PM, Chris Johns  wrote:

> Hi,
>
> For the record this topic was resolved in our meeting.
>
> Attachments will not be inlined in the release notes and a link where
> possible
> will be provided. Expansion of links to inline them is problematic because
> of
> dependencies, size and varying formats, for example how do you place a
> compressed tar file in release notes.
>
> Chris
>
> On 31/5/18 6:17 am, Joel Sherrill wrote:
> >
> >
> > On Wed, May 30, 2018 at 9:00 AM, Gedare Bloom  > > wrote:
> >
> > On Tue, May 29, 2018 at 5:14 PM, Chris Johns  > > wrote:
> > > On 30/5/18 5:30 am, Dannie Huang wrote:
> > >> I am now able to grab most of needed information from ticket's
> page by using
> > >> python (like ticket id, description, comments, etc).
> > >
> > > Fantastic.
> > >
> > >> There is a place for
> > >> attachment on a ticket's page, do we also need to get the
> information of
> > >> attached files? If we need to, how can I implement?
> > >
> > > I suggest we include a link a reader of the Release Notes can
> click on. I
> > > suppose this means recording a link when parsing the data from the
> feed.
> > >
> >
> > Usually, the attachment is a patch. If the ticket is closed, it
> should
> > mean there is a commit available correspondingly. I'm not sure what
> > use the attachment would be in release notes. Making it a link
> > shouldn't hurt anything though, I suppose.
> >
> >
> > Putting on my user hat, I wouldn't want a patch itself in the release
> notes.
> > A link would be more useful.
> >
> > I am thinking there are at least four URL patterns.
> >
> > A URL included in the text like a link to the Open Group.
> > One is a git hash that's a clickable link
> > Another is {{...}} with some git stuff in it.
> > And links to attachments.
> >
> > Are there other places URLs show up?
> >
> > --joel
> >
> >
> >
> > > 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
> > 
> >
> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: error while building leon3 with gcov flags

[Joel Sherrill]

I can't duplicate this. My configure command was:

../rtems/configure --target=sparc-rtems5 --enable-rtemsbsp=leon3
--prefix=/home/joel/rtems-work/tools/5 \
   --disable-networking --enable-posix --disable-smp
--disable-multiprocessing \
   --enable-tests --enable-cxx --enable-maintainer-mode

What was yours?


On Wed, Jun 6, 2018 at 9:40 AM, Vijay Kumar Banerjee <
vijaykumar9...@gmail.com> wrote:

> Hello,
>
> I have added the following changes in the bsps/sparc/leon3/config/leon3.
> cfg
>
> --
> CFLAGS_OPTIMIZE_V = -Os -g
> CFLAGS_OPTIMIZE_V += -ftest-coverage
> ---
>
> While trying to build with these flags, I got a bunch of
> the following errors:
>
> ==
> {standard input}: Assembler messages:
> {standard input}:6510: Error: can't resolve `.data._SPARC_Counter'
> {.data._SPARC_Counter section} - `.LLtext0' {.text section}
> {standard input}:6511: Error: can't resolve `.data._SPARC_Counter'
> {.data._SPARC_Counter section} - `.LLtext0' {.text section}
>
> ===
>
> after the `make install` I do get a lot of .gcno files, and no
> executables.
>
> -- vijay
>
> ___
> 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

error while building leon3 with gcov flags

[Vijay Kumar Banerjee]

Hello,

I have added the following changes in the bsps/sparc/leon3/config/leon3.cfg

--
CFLAGS_OPTIMIZE_V = -Os -g
CFLAGS_OPTIMIZE_V += -ftest-coverage
---

While trying to build with these flags, I got a bunch of
the following errors:

==
{standard input}: Assembler messages:
{standard input}:6510: Error: can't resolve `.data._SPARC_Counter'
{.data._SPARC_Counter section} - `.LLtext0' {.text section}
{standard input}:6511: Error: can't resolve `.data._SPARC_Counter'
{.data._SPARC_Counter section} - `.LLtext0' {.text section}

===

after the `make install` I do get a lot of .gcno files, and no
executables.

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

Re: [GSoC - x86_64 BSP] Using fPIC to compile RTEMS as a shared library

[Amaan Cheval]

Chris, I've blogged a summary of the 2 approaches we can take in
integrating gnu-efi in case you missed the discussions earlier, btw.
The FreeBSD approach isn't as fleshed out, but I'll let you all know
what I find there.

https://blog.whatthedude.com/post/gnu-efi-kernel-so/

On Wed, Jun 6, 2018 at 2:30 PM, Amaan Cheval  wrote:
> I don't know yet, but I'll look into it. I'll pause the "hello.efi" approach
> work until we settle on a direction, yes? For now, primarily improving the
> stub, looking into the FreeBSD ld-elf.so, etc. Sound good?
>
> On Wed, Jun 6, 2018, 1:01 PM Chris Johns  wrote:
>>
>> On 6/6/18 5:22 pm, Amaan Cheval wrote:
>> > On Wed, Jun 6, 2018 at 12:45 PM, Chris Johns  wrote:
>> >> On 6/6/18 5:06 pm, Amaan Cheval wrote:
>> >>> On Wed, Jun 6, 2018 at 6:55 AM, Chris Johns  wrote:
>>  On 4/6/18 7:49 pm, Amaan Cheval wrote:
>> > Please let me know if that approach doesn't make sense - given that
>> > there is no dynamic loader in the RTEMS kernel as far as I know,
>> 
>>  There is a dynamic loader in RTEMS called libdl. It is not based
>>  around the ELF
>>  standard loader used for shared libraries and will not be. GOT and
>>  PLT do not
>>  add value to RTEMS because we do not have an active virtual address
>>  space with
>>  paging.
>> 
>>  The libdl code is currently supported with the i386 static builds. I
>>  would hope
>>  this would continue to be supported without major refactoring of that
>>  code.
>>  There are tests in the testsuite under libtests.
>> >>>
>> >>> Hm, so libdl can load static ELFs and handle those relocations itself?
>> >>> In that case we could go the "FreeBSD" way more easily as I outlined
>> >>> earlier; a loader UEFI application image (loader.efi) + the
>> >>> application image to be found on the filesystem and loaded through
>> >>> libdl, which we somehow call through loader.efi.
>> >>>
>> >>> loader.efi -> libdl -> hello.exe (static executable ELF now)
>> >>>
>> >>
>> >> libdl is not designed to do this and do not think it could be made too.
>> >> It needs
>> >> a full RTEMS kernel located to run.
>> >
>> > Ah, I see. In that case porting FreeBSD's ELF loader is the only
>> > viable option in this direction, I believe, since the ELF to be loaded
>> > would be the RTEMS kernel+the user app.
>> >
>>
>> Do we need to port it or can we use a released version from an installed
>> FreeBSD?
>>
>> >>
>> 
>> > what
>> > we really want _is_ a static file, but for it to be a relocatable
>> > PE,
>> > we need to convince GCC to spit out a relocatable but fully resolved
>> > shared library.
>> 
>>  It is not clear to me yet making the kernel relocatable is free of
>>  other
>>  possible issues. I will need to find time to review all the low level
>>  parts here
>>  and my time is currently limited.
>> 
>>  Does this UEFI work effect the score context switcher, interrupts,
>>  etc? If is
>>  does we will need to resolve what happens and if not should we
>>  consider leaving
>>  it if we can?
>> >>>
>> >>> It affects it in the sense that it's all compiled with fPIC, yes. It
>> >>> needs to be if we're bundling it all together (creating hello.efi,
>> >>> which includes the UEFI boot code, all of RTEMS, and the user app).
>> >>>
>>  For example can iPXE chain load a multiboot image?
>> >>>
>> >>> Yes, we could just use Multiboot too. One thing to note, though -
>> >>> Multiboot will drop us in 32-bit protected mode, whereas 64-bit UEFI
>> >>> firmware will load is into 64-bit protected mode.
>> >>
>> >> Ah OK this is a good point and boards like a Minnow have a 32bit or
>> >> 64bit BIOS
>> >> or what ever it is called on those boards so this may not work.
>> >>
>> >>> Supporting Multiboot
>> >>> too will involve adding some code to move to 64-bit mode before
>> >>> actually calling into the generalized 64-bit mode code.
>> >>
>> >> Can it be used as a step towards another solution?
>> >
>> > Not sure what you mean - like if it would be useful anywhere outside
>> > of the Multiboot work? If so, no, likely not, unless we also want
>> > legacy BIOS support eventually, in which case it could be part of the
>> > real mode->protected mode->long mode transition chain, but that's
>> > unlikely :P
>> >
>>
>> I was just wondering if a temporary short cut can be taken so we do not
>> spend
>> all our time on booting an image.
>>
>> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v3] tester: Add script to generate html coverage report from covoar output

[Vijay Kumar Banerjee]

On 6 June 2018 at 17:48, Joel Sherrill  wrote:

>
>
> On Wed, Jun 6, 2018, 1:16 AM Cillian O'Donnell 
> wrote:
>
>>
>>
>> On Wed, 6 Jun 2018, 01:52 Joel Sherrill,  wrote:
>>
>>>
>>>
>>> On Tue, Jun 5, 2018, 7:22 PM Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 On 6 June 2018 at 03:57, Joel Sherrill  wrote:

> I think everything is pushed. Is there any patch outstanding?
>

> Thank you.
 No outstanding patch, everything on my side is squashed into it. :)

>>>
>>> So we can (finally) switch to the RTEMS.org repos to as the baseline?
>>>
>>
>> That's everything! Started summer 2014 and now it's all merged, it's
>> great to see. Well done Vijay.
>>
>
> Thank you! Thanks to all the mentors for all the support and guidance. :)

> Agreed! Now to finish this GSoC's goals and define the near term things to
> work on.
>
> I have started filing the tickets.

P.S: It's great to be a part of such a wonderful community. :)

>
>>> On Mon, Jun 4, 2018 at 3:44 PM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> Add support in tester to run covoar and generate an html report to
>> display
>> the summary of the coverage reports generated from covoar.
>>
>> Co-authored-by : Cillian O'Donnell 
>> ---
>>  .gitignore|   1 +
>>  tester/rt/coverage.py | 385
>> ++
>>  tester/rt/test.py |  34 ++-
>>  tester/rtems/testing/bsps/leon3-qemu-cov.ini  |   3 +-
>>  tester/rtems/testing/coverage/symbol-sets.ini |  36 +++
>>  tester/rtems/testing/qemu.cfg |   4 +-
>>  6 files changed, 450 insertions(+), 13 deletions(-)
>>  create mode 100644 tester/rt/coverage.py
>>  create mode 100644 tester/rtems/testing/coverage/symbol-sets.ini
>>
>> diff --git a/.gitignore b/.gitignore
>> index 6ab3709..93cb5d2 100644
>> --- a/.gitignore
>> +++ b/.gitignore
>> @@ -9,3 +9,4 @@ waf3-*
>>  .lock-waf*
>>  build
>>  VERSION*
>> +*symbols.ini
>> diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
>> new file mode 100644
>> index 000..54933d5
>> --- /dev/null
>> +++ b/tester/rt/coverage.py
>> @@ -0,0 +1,385 @@
>> +#
>> +# RTEMS Tools Project (http://www.rtems.org/)
>> +# Copyright 2014 Krzysztof Miesowicz (krzysztof.miesow...@gmail.com)
>> +# All rights reserved.
>> +#
>> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
>> +#
>> +# Redistribution and use in source and binary forms, with or without
>> +# modification, are permitted provided that the following conditions
>> are met:
>> +#
>> +# 1. Redistributions of source code must retain the above copyright
>> notice,
>> +# this list of conditions and the following disclaimer.
>> +#
>> +# 2. Redistributions in binary form must reproduce the above
>> copyright notice,
>> +# this list of conditions and the following disclaimer in the
>> documentation
>> +# and/or other materials provided with the distribution.
>> +#
>> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
>> CONTRIBUTORS 'AS IS'
>> +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
>> TO, THE
>> +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
>> PURPOSE
>> +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
>> CONTRIBUTORS BE
>> +# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
>> +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
>> OF
>> +# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
>> BUSINESS
>> +# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
>> WHETHER IN
>> +# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
>> OTHERWISE)
>> +# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
>> ADVISED OF THE
>> +# POSSIBILITY OF SUCH DAMAGE.
>> +#
>> +
>> +from rtemstoolkit import error
>> +from rtemstoolkit import path
>> +from rtemstoolkit import log
>> +from rtemstoolkit import execute
>> +from rtemstoolkit import macros
>> +
>> +from datetime import datetime
>> +
>> +from . import options
>> +
>> +import shutil
>> +import os
>> +
>> +try:
>> +import configparser
>> +except:
>> +import ConfigParser as configparser
>> +
>> +class summary:
>> +def __init__(self, p_summary_dir):
>> +self.summary_file_path = path.join(p_summary_dir,
>> 'summary.txt')
>> +self.index_file_path = path.join(p_summary_dir, 'index.html')
>> +self.bytes_analyzed = 0
>> +self.bytes_not_executed = 0
>> +self.percentage_executed = 0.0
>> +

Re: [PATCH v3] tester: Add script to generate html coverage report from covoar output

[Joel Sherrill]

On Wed, Jun 6, 2018, 1:16 AM Cillian O'Donnell 
wrote:

>
>
> On Wed, 6 Jun 2018, 01:52 Joel Sherrill,  wrote:
>
>>
>>
>> On Tue, Jun 5, 2018, 7:22 PM Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 6 June 2018 at 03:57, Joel Sherrill  wrote:
>>>
 I think everything is pushed. Is there any patch outstanding?

>>>
 Thank you.
>>> No outstanding patch, everything on my side is squashed into it. :)
>>>
>>
>> So we can (finally) switch to the RTEMS.org repos to as the baseline?
>>
>
> That's everything! Started summer 2014 and now it's all merged, it's great
> to see. Well done Vijay.
>

Agreed! Now to finish this GSoC's goals and define the near term things to
work on.


>> On Mon, Jun 4, 2018 at 3:44 PM, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> Add support in tester to run covoar and generate an html report to
> display
> the summary of the coverage reports generated from covoar.
>
> Co-authored-by : Cillian O'Donnell 
> ---
>  .gitignore|   1 +
>  tester/rt/coverage.py | 385
> ++
>  tester/rt/test.py |  34 ++-
>  tester/rtems/testing/bsps/leon3-qemu-cov.ini  |   3 +-
>  tester/rtems/testing/coverage/symbol-sets.ini |  36 +++
>  tester/rtems/testing/qemu.cfg |   4 +-
>  6 files changed, 450 insertions(+), 13 deletions(-)
>  create mode 100644 tester/rt/coverage.py
>  create mode 100644 tester/rtems/testing/coverage/symbol-sets.ini
>
> diff --git a/.gitignore b/.gitignore
> index 6ab3709..93cb5d2 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -9,3 +9,4 @@ waf3-*
>  .lock-waf*
>  build
>  VERSION*
> +*symbols.ini
> diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
> new file mode 100644
> index 000..54933d5
> --- /dev/null
> +++ b/tester/rt/coverage.py
> @@ -0,0 +1,385 @@
> +#
> +# RTEMS Tools Project (http://www.rtems.org/)
> +# Copyright 2014 Krzysztof Miesowicz (krzysztof.miesow...@gmail.com)
> +# All rights reserved.
> +#
> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
> +#
> +# Redistribution and use in source and binary forms, with or without
> +# modification, are permitted provided that the following conditions
> are met:
> +#
> +# 1. Redistributions of source code must retain the above copyright
> notice,
> +# this list of conditions and the following disclaimer.
> +#
> +# 2. Redistributions in binary form must reproduce the above
> copyright notice,
> +# this list of conditions and the following disclaimer in the
> documentation
> +# and/or other materials provided with the distribution.
> +#
> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> 'AS IS'
> +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
> TO, THE
> +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
> CONTRIBUTORS BE
> +# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> +# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> BUSINESS
> +# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
> WHETHER IN
> +# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> OTHERWISE)
> +# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
> OF THE
> +# POSSIBILITY OF SUCH DAMAGE.
> +#
> +
> +from rtemstoolkit import error
> +from rtemstoolkit import path
> +from rtemstoolkit import log
> +from rtemstoolkit import execute
> +from rtemstoolkit import macros
> +
> +from datetime import datetime
> +
> +from . import options
> +
> +import shutil
> +import os
> +
> +try:
> +import configparser
> +except:
> +import ConfigParser as configparser
> +
> +class summary:
> +def __init__(self, p_summary_dir):
> +self.summary_file_path = path.join(p_summary_dir,
> 'summary.txt')
> +self.index_file_path = path.join(p_summary_dir, 'index.html')
> +self.bytes_analyzed = 0
> +self.bytes_not_executed = 0
> +self.percentage_executed = 0.0
> +self.percentage_not_executed = 100.0
> +self.ranges_uncovered = 0
> +self.branches_uncovered = 0
> +self.branches_total = 0
> +self.branches_always_taken = 0
> +self.branches_never_taken = 0
> +self.percentage_branches_covered = 0.0
> +self.is_failure = False
> +
> +def parse(self):
> + 

Re: RISC-V tool chain

[Sebastian Huber]

On 06/06/18 07:16, Sebastian Huber wrote:

We could use an unofficial mirror on Github, e.g.

https://codeload.github.com/bminor/binutils-gdb/tar.gz/c61b06a19a34baab66e3809c7b41b0c31009ed9f 



My main concern with using all these different download sources is 
that this will likely not work if we want to use it in five or ten 
years due to URL changes.


A proof of concept patch series is here:

https://lists.rtems.org/pipermail/devel/2018-June/021951.html

One problem with the using Binutils/GDB Git snapshots is that they share 
a repository. I uses currently the Git mirror of some random user 
("bminor"). I will try to set up a Binutils Git mirror for RTEMS. We 
don't need an automatic synchronization. We just have to do this for an 
RSB update.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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

[PATCH 4/4] 5: Add GDB for RISC-V

[Sebastian Huber]

Mainline GDB support for RISC-V is not yet in a released GDB version.
---
 rtems/config/5/rtems-riscv32.bset  |  1 +
 rtems/config/5/rtems-riscv64.bset  |  1 +
 .../rtems-gdb-773ff7907c05313aebbcd5e8319e5b869ac4f792.cfg | 14 ++
 3 files changed, 16 insertions(+)
 create mode 100644 
rtems/config/tools/rtems-gdb-773ff7907c05313aebbcd5e8319e5b869ac4f792.cfg

diff --git a/rtems/config/5/rtems-riscv32.bset 
b/rtems/config/5/rtems-riscv32.bset
index f19adcd..3f3cb8d 100644
--- a/rtems/config/5/rtems-riscv32.bset
+++ b/rtems/config/5/rtems-riscv32.bset
@@ -12,5 +12,6 @@
 devel/expat-2.1.0-1
 tools/rtems-binutils-773ff7907c05313aebbcd5e8319e5b869ac4f792
 tools/rtems-gcc-7.3.0-newlib-3.0.0
+tools/rtems-gdb-773ff7907c05313aebbcd5e8319e5b869ac4f792
 tools/rtems-tools-5-1
 tools/rtems-kernel-5
diff --git a/rtems/config/5/rtems-riscv64.bset 
b/rtems/config/5/rtems-riscv64.bset
index feb693e..1bc9440 100644
--- a/rtems/config/5/rtems-riscv64.bset
+++ b/rtems/config/5/rtems-riscv64.bset
@@ -12,5 +12,6 @@
 devel/expat-2.1.0-1
 tools/rtems-binutils-773ff7907c05313aebbcd5e8319e5b869ac4f792
 tools/rtems-gcc-7.3.0-newlib-3.0.0
+tools/rtems-gdb-773ff7907c05313aebbcd5e8319e5b869ac4f792
 tools/rtems-tools-5-1
 tools/rtems-kernel-5
diff --git 
a/rtems/config/tools/rtems-gdb-773ff7907c05313aebbcd5e8319e5b869ac4f792.cfg 
b/rtems/config/tools/rtems-gdb-773ff7907c05313aebbcd5e8319e5b869ac4f792.cfg
new file mode 100644
index 000..a8e4671
--- /dev/null
+++ b/rtems/config/tools/rtems-gdb-773ff7907c05313aebbcd5e8319e5b869ac4f792.cfg
@@ -0,0 +1,14 @@
+#
+# GDB
+#
+
+%include %{_configdir}/checks.cfg
+%include %{_configdir}/base.cfg
+
+%define gdb_version 773ff7907c05313aebbcd5e8319e5b869ac4f792
+%define gdb_external 1
+%define gdb_expand_name binutils-gdb-%{gdb_version}
+%source set gdb --rsb-file=%{gdb_expand_name}.tar.gz 
https://github.com/bminor/binutils-gdb/archive/%{gdb_version}.tar.gz
+%hash sha512 %{gdb_expand_name}.tar.gz 
64ae16e9da89f0e150c1d95cf0aa2c1ff5df4fe9ecefcf9ed702f2fffe66fb194ae50642b13f4e3724db3dfd598710b1f1877ed39d06cb6c5903dad9ddcddcc3
+
+%include %{_configdir}/gdb-7-1.cfg
-- 
2.13.7

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

[PATCH 3/4] 5: Update RISC-V Binutils

[Sebastian Huber]

This includes the following bug fix:

https://sourceware.org/bugzilla/show_bug.cgi?id=23244
---
 rtems/config/5/rtems-riscv32.bset  |  2 +-
 rtems/config/5/rtems-riscv64.bset  |  2 +-
 ...ls-773ff7907c05313aebbcd5e8319e5b869ac4f792.cfg | 29 ++
 3 files changed, 31 insertions(+), 2 deletions(-)
 create mode 100644 
rtems/config/tools/rtems-binutils-773ff7907c05313aebbcd5e8319e5b869ac4f792.cfg

diff --git a/rtems/config/5/rtems-riscv32.bset 
b/rtems/config/5/rtems-riscv32.bset
index c4e99f2..f19adcd 100644
--- a/rtems/config/5/rtems-riscv32.bset
+++ b/rtems/config/5/rtems-riscv32.bset
@@ -10,7 +10,7 @@
 5/rtems-autotools
 
 devel/expat-2.1.0-1
-tools/rtems-binutils-2.30
+tools/rtems-binutils-773ff7907c05313aebbcd5e8319e5b869ac4f792
 tools/rtems-gcc-7.3.0-newlib-3.0.0
 tools/rtems-tools-5-1
 tools/rtems-kernel-5
diff --git a/rtems/config/5/rtems-riscv64.bset 
b/rtems/config/5/rtems-riscv64.bset
index c2fb727..feb693e 100644
--- a/rtems/config/5/rtems-riscv64.bset
+++ b/rtems/config/5/rtems-riscv64.bset
@@ -10,7 +10,7 @@
 5/rtems-autotools
 
 devel/expat-2.1.0-1
-tools/rtems-binutils-2.30
+tools/rtems-binutils-773ff7907c05313aebbcd5e8319e5b869ac4f792
 tools/rtems-gcc-7.3.0-newlib-3.0.0
 tools/rtems-tools-5-1
 tools/rtems-kernel-5
diff --git 
a/rtems/config/tools/rtems-binutils-773ff7907c05313aebbcd5e8319e5b869ac4f792.cfg
 
b/rtems/config/tools/rtems-binutils-773ff7907c05313aebbcd5e8319e5b869ac4f792.cfg
new file mode 100644
index 000..cc045a3
--- /dev/null
+++ 
b/rtems/config/tools/rtems-binutils-773ff7907c05313aebbcd5e8319e5b869ac4f792.cfg
@@ -0,0 +1,29 @@
+#
+# Binutils
+#
+
+%include %{_configdir}/checks.cfg
+%include %{_configdir}/base.cfg
+
+%define binutils_version 773ff7907c05313aebbcd5e8319e5b869ac4f792
+%define binutils_external 1
+%define binutils_expand_name binutils-gdb-%{binutils_version}
+%source set binutils --rsb-file=%{binutils_expand_name}.tar.gz 
https://github.com/bminor/binutils-gdb/archive/%{binutils_version}.tar.gz
+%hash sha512 %{binutils_expand_name}.tar.gz 
64ae16e9da89f0e150c1d95cf0aa2c1ff5df4fe9ecefcf9ed702f2fffe66fb194ae50642b13f4e3724db3dfd598710b1f1877ed39d06cb6c5903dad9ddcddcc3
+
+#
+# Enable deterministic archives by default. This will be the default
+# there all tools using this binutils will create deterministic
+# archives.
+#
+%define with_deterministic_archives 1
+
+#
+# Enable 64-bit BFD support
+#
+%define with_64_bit_bfd 1
+
+#
+# The binutils build instructions. We use 2.xx Release 1.
+#
+%include %{_configdir}/binutils-2-1.cfg
-- 
2.13.7

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

[PATCH 1/4] Build only the Binutils

[Sebastian Huber]

The Binutils and GDB share a repository.  In order to build the Binutils
from a repository snapshot some components must be disabled.
---
 source-builder/config/binutils-2-1.cfg | 1 +
 1 file changed, 1 insertion(+)

diff --git a/source-builder/config/binutils-2-1.cfg 
b/source-builder/config/binutils-2-1.cfg
index 0b4101d..5eefd0f 100644
--- a/source-builder/config/binutils-2-1.cfg
+++ b/source-builder/config/binutils-2-1.cfg
@@ -69,6 +69,7 @@ BuildRoot: %{_tmppath}/%{name}-root-%(%{__id_u} -n)
 --build=%{_build} --host=%{_host} \
 --target=%{_target} \
 --verbose --disable-nls \
+--disable-gdb --disable-libdecnumber --disable-readline --disable-sim \
 %{?with_deterministic_archives:--enable-deterministic-archives} \
 %{?with_64_bit_bfd:--enable-64-bit-bfd} \
 %{?with_gold:--enable-gold=yes} \
-- 
2.13.7

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

[PATCH 2/4] Build only the GDB

[Sebastian Huber]

The Binutils and GDB share a repository.  In order to build the GDB
from a repository snapshot some components must be disabled.
---
 source-builder/config/gdb-7-1.cfg | 1 +
 1 file changed, 1 insertion(+)

diff --git a/source-builder/config/gdb-7-1.cfg 
b/source-builder/config/gdb-7-1.cfg
index a045c3b..d13d536 100644
--- a/source-builder/config/gdb-7-1.cfg
+++ b/source-builder/config/gdb-7-1.cfg
@@ -111,6 +111,7 @@ BuildRoot: %{_tmppath}/%{name}-root-%(%{__id_u} -n)
 --build=%{_build} --host=%{_host} \
 --target=%{_target} \
 --verbose --disable-nls \
+--disable-gas --disable-binutils --disable-ld --disable-gold 
--disable-gprof \
 %{?with_system_readline:--with-system-readline} \
 --without-included-gettext \
 --disable-win32-registry \
-- 
2.13.7

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

Re: RISC-V tool chain

[Hesham Almatary]

If pulling from external GitHub repos (i.e. not GNU) is an option,
then [1, 2]  are very well-maintained and have any cutting-edge
changes that are supposed to be merged with GNU repos. SiFive's SDK,
FreeBSD and seL4 rely on riscv-tools and I always use it.


[1] https://github.com/riscv/riscv-gnu-toolchain
[2] https://github.com/riscv/riscv-tools

On Wed, Jun 6, 2018 at 8:35 AM, Chris Johns  wrote:
> On 6/6/18 5:30 pm, Sebastian Huber wrote:
>> On 06/06/18 07:16, Sebastian Huber wrote:
>>>
>>> We could use an unofficial mirror on Github, e.g.
>>>
>>> https://codeload.github.com/bminor/binutils-gdb/tar.gz/c61b06a19a34baab66e3809c7b41b0c31009ed9f
>>>
>>>
>>> My main concern with using all these different download sources is that this
>>> will likely not work if we want to use it in five or ten years due to URL
>>> changes.
>>
>> Maybe we should add mirrors of GCC, Newlib, and Binutils to the RTEMS Github 
>> site?
>>
>> https://github.com/rtems
>>
>
> Yes, I just posted the same suggestion :)
>
> It should be a sub-folder.
>
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel



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

Re: [PATCH] Adding tracing documentation in user manual

[Vidushi Vashishth]

I am just sending a revised version with incorporations of your
>> suggestions. I will create a fresh version 2 patch after everyone has
>> reviewed.
>>
>
> If you send revised version, then please send them as a separate patch
> with a new version. You can mention in the commit message what you changed
> in a particular version of the patch. For example:
>
> https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg06269.html
>
> There should be a section which tells me which tools I have to install.
>
> The new files need a proper copyright message mentioning the copyright
> owner.
>

Okay I will make these changes.

In contrast to the other documents the stuff in user uses subdirectories
> and separate files at a low section level. Is this practical?
>

I didn't quite understand this.

Also what are you thoughts on my idea of accomplishing function tracing
using CTF? Do you think its a viable approach? This is written in the
function tracing use case below:

+Requirements
+
+
+The current tracing framework provides this functionality with
:ref:`tracebuffering`. The output is
+provided in the form of printing on console or saving the buffer in the
form of a bin file. In order to
+develop this use case using CTF we need to be able to convert either the
bin file or console output to CTF.
+The saved bin file must also first be transported to the host from the
target for this purpose. On the other
+hand console output could be written to a text file which can then be
converted to CTF.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSoC - x86_64 BSP] Using fPIC to compile RTEMS as a shared library

[Amaan Cheval]

I don't know yet, but I'll look into it. I'll pause the "hello.efi"
approach work until we settle on a direction, yes? For now, primarily
improving the stub, looking into the FreeBSD ld-elf.so, etc. Sound good?

On Wed, Jun 6, 2018, 1:01 PM Chris Johns  wrote:

> On 6/6/18 5:22 pm, Amaan Cheval wrote:
> > On Wed, Jun 6, 2018 at 12:45 PM, Chris Johns  wrote:
> >> On 6/6/18 5:06 pm, Amaan Cheval wrote:
> >>> On Wed, Jun 6, 2018 at 6:55 AM, Chris Johns  wrote:
>  On 4/6/18 7:49 pm, Amaan Cheval wrote:
> > Please let me know if that approach doesn't make sense - given that
> > there is no dynamic loader in the RTEMS kernel as far as I know,
> 
>  There is a dynamic loader in RTEMS called libdl. It is not based
> around the ELF
>  standard loader used for shared libraries and will not be. GOT and
> PLT do not
>  add value to RTEMS because we do not have an active virtual address
> space with
>  paging.
> 
>  The libdl code is currently supported with the i386 static builds. I
> would hope
>  this would continue to be supported without major refactoring of that
> code.
>  There are tests in the testsuite under libtests.
> >>>
> >>> Hm, so libdl can load static ELFs and handle those relocations itself?
> >>> In that case we could go the "FreeBSD" way more easily as I outlined
> >>> earlier; a loader UEFI application image (loader.efi) + the
> >>> application image to be found on the filesystem and loaded through
> >>> libdl, which we somehow call through loader.efi.
> >>>
> >>> loader.efi -> libdl -> hello.exe (static executable ELF now)
> >>>
> >>
> >> libdl is not designed to do this and do not think it could be made too.
> It needs
> >> a full RTEMS kernel located to run.
> >
> > Ah, I see. In that case porting FreeBSD's ELF loader is the only
> > viable option in this direction, I believe, since the ELF to be loaded
> > would be the RTEMS kernel+the user app.
> >
>
> Do we need to port it or can we use a released version from an installed
> FreeBSD?
>
> >>
> 
> > what
> > we really want _is_ a static file, but for it to be a relocatable PE,
> > we need to convince GCC to spit out a relocatable but fully resolved
> > shared library.
> 
>  It is not clear to me yet making the kernel relocatable is free of
> other
>  possible issues. I will need to find time to review all the low level
> parts here
>  and my time is currently limited.
> 
>  Does this UEFI work effect the score context switcher, interrupts,
> etc? If is
>  does we will need to resolve what happens and if not should we
> consider leaving
>  it if we can?
> >>>
> >>> It affects it in the sense that it's all compiled with fPIC, yes. It
> >>> needs to be if we're bundling it all together (creating hello.efi,
> >>> which includes the UEFI boot code, all of RTEMS, and the user app).
> >>>
>  For example can iPXE chain load a multiboot image?
> >>>
> >>> Yes, we could just use Multiboot too. One thing to note, though -
> >>> Multiboot will drop us in 32-bit protected mode, whereas 64-bit UEFI
> >>> firmware will load is into 64-bit protected mode.
> >>
> >> Ah OK this is a good point and boards like a Minnow have a 32bit or
> 64bit BIOS
> >> or what ever it is called on those boards so this may not work.
> >>
> >>> Supporting Multiboot
> >>> too will involve adding some code to move to 64-bit mode before
> >>> actually calling into the generalized 64-bit mode code.
> >>
> >> Can it be used as a step towards another solution?
> >
> > Not sure what you mean - like if it would be useful anywhere outside
> > of the Multiboot work? If so, no, likely not, unless we also want
> > legacy BIOS support eventually, in which case it could be part of the
> > real mode->protected mode->long mode transition chain, but that's
> > unlikely :P
> >
>
> I was just wondering if a temporary short cut can be taken so we do not
> spend
> all our time on booting an image.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] Fix --show-commands.

[Christian Mauderer]

In the current version of libbsd, if the --show-commands option is used,
the cwd is passed as a Nod3. Popen does not work with that. Therefore
create a string from cwd if it isn't already.
---
 rtems.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/rtems.py b/rtems.py
index 6907709..a88c679 100644
--- a/rtems.py
+++ b/rtems.py
@@ -579,6 +579,8 @@ def output_command_line():
 else:
 cmdstr = ' '.join(cmd)
 Logs.info('(%d) %s' % (len(cmdstr), cmdstr)) # here is the change
+if not isinstance(kw['cwd'], str):
+kw['cwd'] = str(kw['cwd'])
 Logs.debug('runner_env: kw=%s' % kw)
 try:
 if self.logger:
-- 
2.13.6

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

Re: RISC-V tool chain

[Chris Johns]

On 6/6/18 5:30 pm, Sebastian Huber wrote:
> On 06/06/18 07:16, Sebastian Huber wrote:
>>
>> We could use an unofficial mirror on Github, e.g.
>>
>> https://codeload.github.com/bminor/binutils-gdb/tar.gz/c61b06a19a34baab66e3809c7b41b0c31009ed9f
>>
>>
>> My main concern with using all these different download sources is that this
>> will likely not work if we want to use it in five or ten years due to URL
>> changes. 
> 
> Maybe we should add mirrors of GCC, Newlib, and Binutils to the RTEMS Github 
> site?
> 
> https://github.com/rtems
> 

Yes, I just posted the same suggestion :)

It should be a sub-folder.

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

Re: RISC-V tool chain

[Chris Johns]

On 6/6/18 3:16 pm, Sebastian Huber wrote:
> 
> The Git checkouts have the problem that you need an internet connection during
> the build (as far as I remember).

Yes you cannot take a repo offline like an archive.

I suppose I could change the way we handle git repos with an archive
configuration setting that is basically a compressed tar file of the repo and if
it validates a hash checksum we do not touch the repo. It assumes a repo hash
will always create the same tar file which it should do.

> I tried to use a snapshot download via the Git
> web access, e.g.
> 
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=snapshot;h=773ff7907c05313aebbcd5e8319e5b869ac4f792;sf=tgz
> 
> This resulted in a "403 - Snapshots not allowed".
>

I wonder if it uses a lot of resources in the server.

> We could use an unofficial mirror on Github, e.g.
> 
> https://codeload.github.com/bminor/binutils-gdb/tar.gz/c61b06a19a34baab66e3809c7b41b0c31009ed9f
> 
> 
> My main concern with using all these different download sources is that this
> will likely not work if we want to use it in five or ten years due to URL 
> changes.
> 

What if we mirror gcc in github in a tools folder?

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

Re: [GSoC - x86_64 BSP] Using fPIC to compile RTEMS as a shared library

[Chris Johns]

On 6/6/18 5:22 pm, Amaan Cheval wrote:
> On Wed, Jun 6, 2018 at 12:45 PM, Chris Johns  wrote:
>> On 6/6/18 5:06 pm, Amaan Cheval wrote:
>>> On Wed, Jun 6, 2018 at 6:55 AM, Chris Johns  wrote:
 On 4/6/18 7:49 pm, Amaan Cheval wrote:
> Please let me know if that approach doesn't make sense - given that
> there is no dynamic loader in the RTEMS kernel as far as I know,

 There is a dynamic loader in RTEMS called libdl. It is not based around 
 the ELF
 standard loader used for shared libraries and will not be. GOT and PLT do 
 not
 add value to RTEMS because we do not have an active virtual address space 
 with
 paging.

 The libdl code is currently supported with the i386 static builds. I would 
 hope
 this would continue to be supported without major refactoring of that code.
 There are tests in the testsuite under libtests.
>>>
>>> Hm, so libdl can load static ELFs and handle those relocations itself?
>>> In that case we could go the "FreeBSD" way more easily as I outlined
>>> earlier; a loader UEFI application image (loader.efi) + the
>>> application image to be found on the filesystem and loaded through
>>> libdl, which we somehow call through loader.efi.
>>>
>>> loader.efi -> libdl -> hello.exe (static executable ELF now)
>>>
>>
>> libdl is not designed to do this and do not think it could be made too. It 
>> needs
>> a full RTEMS kernel located to run.
> 
> Ah, I see. In that case porting FreeBSD's ELF loader is the only
> viable option in this direction, I believe, since the ELF to be loaded
> would be the RTEMS kernel+the user app.
> 

Do we need to port it or can we use a released version from an installed 
FreeBSD?

>>

> what
> we really want _is_ a static file, but for it to be a relocatable PE,
> we need to convince GCC to spit out a relocatable but fully resolved
> shared library.

 It is not clear to me yet making the kernel relocatable is free of other
 possible issues. I will need to find time to review all the low level 
 parts here
 and my time is currently limited.

 Does this UEFI work effect the score context switcher, interrupts, etc? If 
 is
 does we will need to resolve what happens and if not should we consider 
 leaving
 it if we can?
>>>
>>> It affects it in the sense that it's all compiled with fPIC, yes. It
>>> needs to be if we're bundling it all together (creating hello.efi,
>>> which includes the UEFI boot code, all of RTEMS, and the user app).
>>>
 For example can iPXE chain load a multiboot image?
>>>
>>> Yes, we could just use Multiboot too. One thing to note, though -
>>> Multiboot will drop us in 32-bit protected mode, whereas 64-bit UEFI
>>> firmware will load is into 64-bit protected mode.
>>
>> Ah OK this is a good point and boards like a Minnow have a 32bit or 64bit 
>> BIOS
>> or what ever it is called on those boards so this may not work.
>>
>>> Supporting Multiboot
>>> too will involve adding some code to move to 64-bit mode before
>>> actually calling into the generalized 64-bit mode code.
>>
>> Can it be used as a step towards another solution?
> 
> Not sure what you mean - like if it would be useful anywhere outside
> of the Multiboot work? If so, no, likely not, unless we also want
> legacy BIOS support eventually, in which case it could be part of the
> real mode->protected mode->long mode transition chain, but that's
> unlikely :P
> 

I was just wondering if a temporary short cut can be taken so we do not spend
all our time on booting an image.

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

Re: RISC-V tool chain

[Sebastian Huber]

On 06/06/18 07:16, Sebastian Huber wrote:


We could use an unofficial mirror on Github, e.g.

https://codeload.github.com/bminor/binutils-gdb/tar.gz/c61b06a19a34baab66e3809c7b41b0c31009ed9f 



My main concern with using all these different download sources is 
that this will likely not work if we want to use it in five or ten 
years due to URL changes. 


Maybe we should add mirrors of GCC, Newlib, and Binutils to the RTEMS 
Github site?


https://github.com/rtems

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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

Re: [GSoC - x86_64 BSP] Using fPIC to compile RTEMS as a shared library

[Amaan Cheval]

On Wed, Jun 6, 2018 at 12:45 PM, Chris Johns  wrote:
> On 6/6/18 5:06 pm, Amaan Cheval wrote:
>> On Wed, Jun 6, 2018 at 6:55 AM, Chris Johns  wrote:
>>> On 4/6/18 7:49 pm, Amaan Cheval wrote:
 Please let me know if that approach doesn't make sense - given that
 there is no dynamic loader in the RTEMS kernel as far as I know,
>>>
>>> There is a dynamic loader in RTEMS called libdl. It is not based around the 
>>> ELF
>>> standard loader used for shared libraries and will not be. GOT and PLT do 
>>> not
>>> add value to RTEMS because we do not have an active virtual address space 
>>> with
>>> paging.
>>>
>>> The libdl code is currently supported with the i386 static builds. I would 
>>> hope
>>> this would continue to be supported without major refactoring of that code.
>>> There are tests in the testsuite under libtests.
>>
>> Hm, so libdl can load static ELFs and handle those relocations itself?
>> In that case we could go the "FreeBSD" way more easily as I outlined
>> earlier; a loader UEFI application image (loader.efi) + the
>> application image to be found on the filesystem and loaded through
>> libdl, which we somehow call through loader.efi.
>>
>> loader.efi -> libdl -> hello.exe (static executable ELF now)
>>
>
> libdl is not designed to do this and do not think it could be made too. It 
> needs
> a full RTEMS kernel located to run.

Ah, I see. In that case porting FreeBSD's ELF loader is the only
viable option in this direction, I believe, since the ELF to be loaded
would be the RTEMS kernel+the user app.

>
>>>
 what
 we really want _is_ a static file, but for it to be a relocatable PE,
 we need to convince GCC to spit out a relocatable but fully resolved
 shared library.
>>>
>>> It is not clear to me yet making the kernel relocatable is free of other
>>> possible issues. I will need to find time to review all the low level parts 
>>> here
>>> and my time is currently limited.
>>>
>>> Does this UEFI work effect the score context switcher, interrupts, etc? If 
>>> is
>>> does we will need to resolve what happens and if not should we consider 
>>> leaving
>>> it if we can?
>>
>> It affects it in the sense that it's all compiled with fPIC, yes. It
>> needs to be if we're bundling it all together (creating hello.efi,
>> which includes the UEFI boot code, all of RTEMS, and the user app).
>>
>>> For example can iPXE chain load a multiboot image?
>>
>> Yes, we could just use Multiboot too. One thing to note, though -
>> Multiboot will drop us in 32-bit protected mode, whereas 64-bit UEFI
>> firmware will load is into 64-bit protected mode.
>
> Ah OK this is a good point and boards like a Minnow have a 32bit or 64bit BIOS
> or what ever it is called on those boards so this may not work.
>
>> Supporting Multiboot
>> too will involve adding some code to move to 64-bit mode before
>> actually calling into the generalized 64-bit mode code.
>
> Can it be used as a step towards another solution?

Not sure what you mean - like if it would be useful anywhere outside
of the Multiboot work? If so, no, likely not, unless we also want
legacy BIOS support eventually, in which case it could be part of the
real mode->protected mode->long mode transition chain, but that's
unlikely :P

>
>>
>>>
>>> Sorry to have disappeared for a period at a critical time in this 
>>> discussion, it
>>> was beyond my control.
>>
>> No worries! Hope everything's okay!
>>
>
> Thanks and yes.
>
>> I'll look into libdl further in the meantime and continue to polish up
>> the stub to reflect more of the x64 features, while we figure out our
>> boot direction.
>
> Great. I hope to be back full time next week and I can have a look.
>
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSoC - x86_64 BSP] Using fPIC to compile RTEMS as a shared library

[Chris Johns]

On 6/6/18 5:06 pm, Amaan Cheval wrote:
> On Wed, Jun 6, 2018 at 6:55 AM, Chris Johns  wrote:
>> On 4/6/18 7:49 pm, Amaan Cheval wrote:
>>> Please let me know if that approach doesn't make sense - given that
>>> there is no dynamic loader in the RTEMS kernel as far as I know,
>>
>> There is a dynamic loader in RTEMS called libdl. It is not based around the 
>> ELF
>> standard loader used for shared libraries and will not be. GOT and PLT do not
>> add value to RTEMS because we do not have an active virtual address space 
>> with
>> paging.
>>
>> The libdl code is currently supported with the i386 static builds. I would 
>> hope
>> this would continue to be supported without major refactoring of that code.
>> There are tests in the testsuite under libtests.
> 
> Hm, so libdl can load static ELFs and handle those relocations itself?
> In that case we could go the "FreeBSD" way more easily as I outlined
> earlier; a loader UEFI application image (loader.efi) + the
> application image to be found on the filesystem and loaded through
> libdl, which we somehow call through loader.efi.
> 
> loader.efi -> libdl -> hello.exe (static executable ELF now)
> 

libdl is not designed to do this and do not think it could be made too. It needs
a full RTEMS kernel located to run.

>>
>>> what
>>> we really want _is_ a static file, but for it to be a relocatable PE,
>>> we need to convince GCC to spit out a relocatable but fully resolved
>>> shared library.
>>
>> It is not clear to me yet making the kernel relocatable is free of other
>> possible issues. I will need to find time to review all the low level parts 
>> here
>> and my time is currently limited.
>>
>> Does this UEFI work effect the score context switcher, interrupts, etc? If is
>> does we will need to resolve what happens and if not should we consider 
>> leaving
>> it if we can?
> 
> It affects it in the sense that it's all compiled with fPIC, yes. It
> needs to be if we're bundling it all together (creating hello.efi,
> which includes the UEFI boot code, all of RTEMS, and the user app).
> 
>> For example can iPXE chain load a multiboot image?
> 
> Yes, we could just use Multiboot too. One thing to note, though -
> Multiboot will drop us in 32-bit protected mode, whereas 64-bit UEFI
> firmware will load is into 64-bit protected mode.

Ah OK this is a good point and boards like a Minnow have a 32bit or 64bit BIOS
or what ever it is called on those boards so this may not work.

> Supporting Multiboot
> too will involve adding some code to move to 64-bit mode before
> actually calling into the generalized 64-bit mode code.

Can it be used as a step towards another solution?

> 
>>
>> Sorry to have disappeared for a period at a critical time in this 
>> discussion, it
>> was beyond my control.
> 
> No worries! Hope everything's okay!
> 

Thanks and yes.

> I'll look into libdl further in the meantime and continue to polish up
> the stub to reflect more of the x64 features, while we figure out our
> boot direction.

Great. I hope to be back full time next week and I can have a look.

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

Re: [PATCH] Adding tracing documentation in user manual

[Sebastian Huber]

On 05/06/18 22:39, Vidushi Vashishth wrote:
I am just sending a revised version with incorporations of your 
suggestions. I will create a fresh version 2 patch after everyone has 
reviewed.


If you send revised version, then please send them as a separate patch 
with a new version. You can mention in the commit message what you 
changed in a particular version of the patch. For example:


https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg06269.html

There should be a section which tells me which tools I have to install.

The new files need a proper copyright message mentioning the copyright 
owner.


In contrast to the other documents the stuff in user uses subdirectories 
and separate files at a low section level. Is this practical?


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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

Re: [GSoC - x86_64 BSP] Using fPIC to compile RTEMS as a shared library

[Amaan Cheval]

On Wed, Jun 6, 2018 at 6:55 AM, Chris Johns  wrote:
> On 4/6/18 7:49 pm, Amaan Cheval wrote:
>> Please let me know if that approach doesn't make sense - given that
>> there is no dynamic loader in the RTEMS kernel as far as I know,
>
> There is a dynamic loader in RTEMS called libdl. It is not based around the 
> ELF
> standard loader used for shared libraries and will not be. GOT and PLT do not
> add value to RTEMS because we do not have an active virtual address space with
> paging.
>
> The libdl code is currently supported with the i386 static builds. I would 
> hope
> this would continue to be supported without major refactoring of that code.
> There are tests in the testsuite under libtests.

Hm, so libdl can load static ELFs and handle those relocations itself?
In that case we could go the "FreeBSD" way more easily as I outlined
earlier; a loader UEFI application image (loader.efi) + the
application image to be found on the filesystem and loaded through
libdl, which we somehow call through loader.efi.

loader.efi -> libdl -> hello.exe (static executable ELF now)

>
>> what
>> we really want _is_ a static file, but for it to be a relocatable PE,
>> we need to convince GCC to spit out a relocatable but fully resolved
>> shared library.
>
> It is not clear to me yet making the kernel relocatable is free of other
> possible issues. I will need to find time to review all the low level parts 
> here
> and my time is currently limited.
>
> Does this UEFI work effect the score context switcher, interrupts, etc? If is
> does we will need to resolve what happens and if not should we consider 
> leaving
> it if we can?

It affects it in the sense that it's all compiled with fPIC, yes. It
needs to be if we're bundling it all together (creating hello.efi,
which includes the UEFI boot code, all of RTEMS, and the user app).

> For example can iPXE chain load a multiboot image?

Yes, we could just use Multiboot too. One thing to note, though -
Multiboot will drop us in 32-bit protected mode, whereas 64-bit UEFI
firmware will load is into 64-bit protected mode. Supporting Multiboot
too will involve adding some code to move to 64-bit mode before
actually calling into the generalized 64-bit mode code.

>
> Sorry to have disappeared for a period at a critical time in this discussion, 
> it
> was beyond my control.

No worries! Hope everything's okay!

I'll look into libdl further in the meantime and continue to polish up
the stub to reflect more of the x64 features, while we figure out our
boot direction.

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

Re: [PATCH] cpu-supplement: Add ARM BSPs chapter

[Sebastian Huber]

On 05/06/18 16:28, Joel Sherrill wrote:

Not sure why I haven't weighed in yet.

On Tue, Jun 5, 2018 at 8:56 AM, Gedare Bloom > wrote:


Hi Sebastian, Joel:

I am unsure about the placement of BSP guidance in the User Manual. I
like the change overall it is positive to create high-quality BSP
documentation. 



Someone mentioned duplicating the TRM for the CPU or board. That's
a bit unavoidable on a topic level when you have an option which is
the initial value for a specific IO register or clock. You have to 
describe
that option well enough for a user to be able to set it. This will 
necessarily

duplicate some information. We can reference the appropriate documentation
and source files.

This also applies at a board level when it comes to jumper, DIP switch,
or ROM monitor settings.

Since we leave U-Boot mkimage invocation to the user's imagination that's
another piece of the puzzle which the user needs to know.

Advice and set up on debug HW or target agents known to work.

The goal should be that they get all the info they need to configure their
hardware and RTEMS to match expectations. We don't have to duplicate
third party manuals but we should give the user a roadmap to get things
working.


Yes, I would like to have a single documentation location to get started 
with RTEMS on a particular board.



I have 2 concerns:
1. It should be clearly labelled as an incomplete set of the BSPs
however. Right now, if someone picks up this example user.pdf, it
would seem we have only one BSP in RTEMS if you only look at this new
chapter. Maybe it makes sense to merge the text from 8.3 Board Support
Packages (BSP) into the new chapter dedicated toward BSPs.


One solution to this is to fill in the outline with TBDs for at least 
all the

architectures.


Yes, once we have a location for the BSP documentation we can add TBDs.



We need to figure out how to deal with BSP variants.

We also need to assume that core developers will have to write the
sections on simulator BSPs. I expect a fairly standard template for a
qemu or gdb based simulator.

I have wondered if we need a tracking spreadsheet for BSPs to show
what we think is missing or needs updating. For example, some BSPs
still don't have the linkcmds sections for per-function linking. Some 
older

BSPs are still in use and perhaps by pinging people we can get sections
filled in. But on the other hand, this could indicate a BSP is on a 
path to

deprecation. The lack of documentation is another brick in this wall.

2. The size of this Chapter 9 BSPs eventually is going to become much
larger compared to the rest of the manual. It might make better sense
to create it as a supplemental document that you refer to from 8.3
Board Support Packages (BSP). As you say, it is different from the BSP
Developer's Guide, but I think it will be sensible to create an "RTEMS
User Manual BSP Supplement".


Depends on the length per BSP family or BSP variant. Five pages per
variant will end up in the 800-1000 page range. That would be a lovely
problem to have.

I hesitate to start another document that is tiny but if we start it with
a complete outline with TBD sections, it makes sense. It will be fairly
hefty even with TBDs.


My original proposal was a "RTEMS Hardware Manual" which contains the 
architecture documentation (CPU Supplement) and the BSPs.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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

Re: [PATCH v3] tester: Add script to generate html coverage report from covoar output

[Cillian O'Donnell]

On Wed, 6 Jun 2018, 01:52 Joel Sherrill,  wrote:

>
>
> On Tue, Jun 5, 2018, 7:22 PM Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> On 6 June 2018 at 03:57, Joel Sherrill  wrote:
>>
>>> I think everything is pushed. Is there any patch outstanding?
>>>
>>
>>> Thank you.
>> No outstanding patch, everything on my side is squashed into it. :)
>>
>
> So we can (finally) switch to the RTEMS.org repos to as the baseline?
>

That's everything! Started summer 2014 and now it's all merged, it's great
to see. Well done Vijay.

>
> On Mon, Jun 4, 2018 at 3:44 PM, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 Add support in tester to run covoar and generate an html report to
 display
 the summary of the coverage reports generated from covoar.

 Co-authored-by : Cillian O'Donnell 
 ---
  .gitignore|   1 +
  tester/rt/coverage.py | 385
 ++
  tester/rt/test.py |  34 ++-
  tester/rtems/testing/bsps/leon3-qemu-cov.ini  |   3 +-
  tester/rtems/testing/coverage/symbol-sets.ini |  36 +++
  tester/rtems/testing/qemu.cfg |   4 +-
  6 files changed, 450 insertions(+), 13 deletions(-)
  create mode 100644 tester/rt/coverage.py
  create mode 100644 tester/rtems/testing/coverage/symbol-sets.ini

 diff --git a/.gitignore b/.gitignore
 index 6ab3709..93cb5d2 100644
 --- a/.gitignore
 +++ b/.gitignore
 @@ -9,3 +9,4 @@ waf3-*
  .lock-waf*
  build
  VERSION*
 +*symbols.ini
 diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
 new file mode 100644
 index 000..54933d5
 --- /dev/null
 +++ b/tester/rt/coverage.py
 @@ -0,0 +1,385 @@
 +#
 +# RTEMS Tools Project (http://www.rtems.org/)
 +# Copyright 2014 Krzysztof Miesowicz (krzysztof.miesow...@gmail.com)
 +# All rights reserved.
 +#
 +# This file is part of the RTEMS Tools package in 'rtems-tools'.
 +#
 +# Redistribution and use in source and binary forms, with or without
 +# modification, are permitted provided that the following conditions
 are met:
 +#
 +# 1. Redistributions of source code must retain the above copyright
 notice,
 +# this list of conditions and the following disclaimer.
 +#
 +# 2. Redistributions in binary form must reproduce the above copyright
 notice,
 +# this list of conditions and the following disclaimer in the
 documentation
 +# and/or other materials provided with the distribution.
 +#
 +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 'AS IS'
 +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
 TO, THE
 +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 PURPOSE
 +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
 CONTRIBUTORS BE
 +# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
 +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
 +# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
 BUSINESS
 +# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
 IN
 +# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
 OTHERWISE)
 +# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
 OF THE
 +# POSSIBILITY OF SUCH DAMAGE.
 +#
 +
 +from rtemstoolkit import error
 +from rtemstoolkit import path
 +from rtemstoolkit import log
 +from rtemstoolkit import execute
 +from rtemstoolkit import macros
 +
 +from datetime import datetime
 +
 +from . import options
 +
 +import shutil
 +import os
 +
 +try:
 +import configparser
 +except:
 +import ConfigParser as configparser
 +
 +class summary:
 +def __init__(self, p_summary_dir):
 +self.summary_file_path = path.join(p_summary_dir,
 'summary.txt')
 +self.index_file_path = path.join(p_summary_dir, 'index.html')
 +self.bytes_analyzed = 0
 +self.bytes_not_executed = 0
 +self.percentage_executed = 0.0
 +self.percentage_not_executed = 100.0
 +self.ranges_uncovered = 0
 +self.branches_uncovered = 0
 +self.branches_total = 0
 +self.branches_always_taken = 0
 +self.branches_never_taken = 0
 +self.percentage_branches_covered = 0.0
 +self.is_failure = False
 +
 +def parse(self):
 +if(not path.exists(self.summary_file_path)):
 +log.notice('summary file %s does not exist!' %
 (self.summary_file_path))
 +self.is_failure = True
 +return
 +
 +with open(self.summary_file_path,'r') as 

Re: [PATCH] Generate coverage analysis Report

[Cillian O'Donnell]

On Wed, 6 Jun 2018, 05:07 Vijay Kumar Banerjee, 
wrote:

> On Wed, 6 Jun 2018, 08:31 Joel Sherrill,  wrote:
>
>>
>>
>> On Tue, Jun 5, 2018, 9:54 PM Chris Johns  wrote:
>>
>>>
>>> On 31/5/18 6:44 am, Vijay Kumar Banerjee wrote:
>>> > On 31 May 2018 at 02:02, Joel Sherrill >> j...@rtems.org>>
>>> > wrote:
>>> > On Wed, May 30, 2018 at 3:29 PM, Vijay Kumar Banerjee
>>> > mailto:vijaykumar9...@gmail.com>>
>>> wrote:
>>> >
>>> > On 31 May 2018 at 00:28, Joel Sherrill >> > > wrote:
>>> > I may not understand correctly but there is test_run and
>>> > coverage_run. Someone
>>> > suggested making coverage_running an option to test_run.
>>> If that's
>>> > what's being
>>> > asked for, then I think doing it in a follow up patch is
>>> OK.
>>> >
>>> > If that's the intended request, perhaps a ticket should be
>>> filed.
>>> >
>>> >
>>> > Sorry for all the confusion.
>>> > This patch doesn't change the way test works. It only adds an
>>> option to run
>>> > the coverage script. coverage_run just runs the
>>> coverage.coverage_run
>>> >
>>> >
>>> > :) And I am saying if we want to have one test_run with an
>>> argument, do it as
>>> > a future work iteration. File a ticket.
>>> >
>>> > We need to get the code working on the master.
>>> >
>>> > Okay, we can keep that as a future work (I haven't thought about it
>>> though). :)
>>> > Getting it to work on master is our primary objective.
>>> >
>>>
>>> Was a ticket raised to removing 'coverage_run' and to use 'test_run'?
>>>
>>
>> I haven't seen tickets for any of the issues we identified.
>>
> was there supposed to be tickets for each issue?
>

So trawl back over the emails and make a ticket for anything that hasn't
been done, any suggestions for improvements related to the project. Include
things that might not be for gsoc but related to the project. They can
assigned to people and the priority determined after you've collected them
all.

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