Re: [PATCH] tools: Remove shgen

2018-06-11 Thread Sebastian Huber 

On 11/06/18 16:23, Gedare Bloom wrote:

On Mon, Jun 11, 2018 at 8:48 AM, Sebastian Huber
  wrote:

All tools should be removed from the RTEMS source repository at some
point in time. Tools with a BSD-style license will be moved to the RTEMS
tools repository. Unfortunately, the shgen tool is GPL licensed.

Remove all uses of this tool from the code base. Replace generated files
with stub functions. If users of this BSP still exist, they can
reimplement the functionality using a BSD-style license.


Is there a README that needs to be updated, or was the procedure for
this shgen stuff just integrated in the build process? Probably, it
should be noted in the (pending) BSP Supplemental:)



The shgen tool was not mentioned in a README or another documentation file.

--
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] Fix --show-commands.

2018-06-11 Thread Chris Johns 
On 09/06/2018 02:45, Christian Mauderer wrote:
> 
> Did you also note Gedares suggestion to move the rtems_waf.git to the
> public repos? Maybe that would be a good idea.
> 

Yes I did and it is a good idea. I have move the repo to the top level and
updated cgit's config so it is viewable.

Will need to update the repos that include this. Please consider the changes to
do that pre-approved.

I have not pushed this change so please do so as a test. :)

Thanks
Chris

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

Re: [rtems-tools commit] rtemstoolkit: Add DWARF type support.

2018-06-11 Thread Chris Johns 
On 12/06/2018 14:13, Chris Johns wrote:
> Module:rtems-tools
> Branch:dwarf-types
> Commit:2d94207f02c10da8e349eec4755b3aa2a40b2c2a
> Changeset: 
> http://git.rtems.org/rtems-tools/commit/?id=2d94207f02c10da8e349eec4755b3aa2a40b2c2a
>  

This commit is a mistake on my part and I will revert it.

It is part of a series of patches on my personal repo and I pushed to the wrong
remote. I am sorry about this.

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

Re: [PATCH 1/6] nios2gen: Import from RTEMS

2018-06-11 Thread Chris Johns 
On 11/06/2018 22:54, Sebastian Huber wrote:
> On 11/06/18 14:52, Sebastian Huber wrote:
>> What do we want to do with this tool? It uses the RTEMS GPL.
>>
> 
> This tool is not used during the BSP build. I can be removed without breaking 
> BSPs.
> 

I agree.

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

[GSoC - Tracing] Status

2018-06-11 Thread Vidushi Vashishth 
Hi!

Updating the status on the tracing project. I am working on a ctftrace
function in the main_rtrace.c file in rtems source code which will use the
libbabeltrace C API to convert the trace buffers and print the final CTF
onto the console. I am using a static metadata specific to the fileio
sample test case in this regard. I should be able to complete this in a day
or two.

I was going through a previous year student's GSoC project on tracing and
he had added metadata generation capability to the trace linker. There were
some improvements required in terms of utilizing user data types. I was
thinking I could work on these improvements next. He was a 2016 student.
Let me know if this is a good idea.

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

Re: error while building leon3 with gcov flags

2018-06-11 Thread 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?
>
>
> 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.
>>
>> I am again getting these errors. Sometimes it builds just fine and
sometimes
I get these errors with the exact same steps.

here's the command I'm using to build leon3

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

please have a look at the full error in this gist.

https://gist.github.com/thelunatic/12f3091505afe7a79dcd74c106e1a10f


-- 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: [PATCH] tools: Remove shgen

2018-06-11 Thread Gedare Bloom 
On Mon, Jun 11, 2018 at 8:48 AM, Sebastian Huber
 wrote:
> All tools should be removed from the RTEMS source repository at some
> point in time. Tools with a BSD-style license will be moved to the RTEMS
> tools repository. Unfortunately, the shgen tool is GPL licensed.
>
> Remove all uses of this tool from the code base. Replace generated files
> with stub functions. If users of this BSP still exist, they can
> reimplement the functionality using a BSD-style license.
>

Is there a README that needs to be updated, or was the procedure for
this shgen stuff just integrated in the build process? Probably, it
should be noted in the (pending) BSP Supplemental :)

> Close #3443.
> ---
>  bsps/sh/gensh1/console/sci.c|   8 +-
>  bsps/sh/gensh1/console/scitab.c |  38 
>  bsps/sh/gensh1/include/bsp.h|   4 +-
>  bsps/sh/gensh2/console/sci.c|   3 +-
>  bsps/sh/gensh2/console/scitab.c |  38 
>  bsps/sh/gensh2/include/bsp.h|   5 +-
>  c/src/lib/libbsp/sh/gensh1/Makefile.am  |   9 +-
>  c/src/lib/libbsp/sh/gensh1/configure.ac |   7 +-
>  c/src/lib/libbsp/sh/gensh2/Makefile.am  |   9 +-
>  c/src/lib/libbsp/sh/gensh2/configure.ac |   6 +-
>  tools/cpu/configure.ac  |   1 -
>  tools/cpu/sh/AUTHORS|   3 -
>  tools/cpu/sh/COPYING| 340 
> 
>  tools/cpu/sh/Makefile.am|  14 --
>  tools/cpu/sh/TODO   |  13 --
>  tools/cpu/sh/configure.ac   |  25 ---
>  tools/cpu/sh/sci.c  | 177 -
>  tools/cpu/sh/sci.h  |  11 --
>  tools/cpu/sh/shgen.c| 114 ---
>  19 files changed, 87 insertions(+), 738 deletions(-)
>  create mode 100644 bsps/sh/gensh1/console/scitab.c
>  create mode 100644 bsps/sh/gensh2/console/scitab.c
>  delete mode 100644 tools/cpu/sh/AUTHORS
>  delete mode 100644 tools/cpu/sh/COPYING
>  delete mode 100644 tools/cpu/sh/Makefile.am
>  delete mode 100644 tools/cpu/sh/TODO
>  delete mode 100644 tools/cpu/sh/configure.ac
>  delete mode 100644 tools/cpu/sh/sci.c
>  delete mode 100644 tools/cpu/sh/sci.h
>  delete mode 100644 tools/cpu/sh/shgen.c
>
> diff --git a/bsps/sh/gensh1/console/sci.c b/bsps/sh/gensh1/console/sci.c
> index 04d9ca5c70..fedfa30b51 100644
> --- a/bsps/sh/gensh1/console/sci.c
> +++ b/bsps/sh/gensh1/console/sci.c
> @@ -18,7 +18,7 @@
>   *  http://www.rtems.org/license/LICENSE.
>   */
>
> -#include 
> +#include 
>
>  #include 
>
> @@ -53,12 +53,6 @@ struct scidev_t {
>{ "/dev/sci1", SH_SCI_BASE_1, 1, 0, CS8, B9600 }
>  } ;
>
> -/*  imported from scitab.rel */
> -extern int _sci_get_brparms(
> -  speed_t   spd,
> -  unsigned char *smr,
> -  unsigned char *brr );
> -
>  /* Translate termios' tcflag_t into sci settings */
>  static int _sci_set_cflags(
>struct scidev_t  *sci_dev,
> diff --git a/bsps/sh/gensh1/console/scitab.c b/bsps/sh/gensh1/console/scitab.c
> new file mode 100644
> index 00..3c698f8100
> --- /dev/null
> +++ b/bsps/sh/gensh1/console/scitab.c
> @@ -0,0 +1,38 @@
> +/*
> + * Copyright (c) 2018 embedded brains GmbH.  All rights reserved.
> + *
> + *  embedded brains GmbH
> + *  Dornierstr. 4
> + *  82178 Puchheim
> + *  Germany
> + *  
> + *
> + * The license and distribution terms for this file may be
> + * found in the file LICENSE in this distribution or at
> + * http://www.rtems.org/license/LICENSE.
> + */
> +
> +/*
> + * The content of this file was previously generated by the GPL licensed 
> shgen
> + * tool during the BSP build for a configured clock frequency
> + * (CPU_CLOCK_RATE_HZ). All tools were removed from the RTEMS source 
> repository
> + * at some point in time. Tools with a BSD-style license were moved to the
> + * RTEMS tools repository.
> + */
> +
> +#include 
> +
> +int _sci_get_brparms(
> +  unsigned int   spd,
> +  unsigned char *smr,
> +  unsigned char *brr
> +)
> +{
> +  if (spd != 9600) {
> +return -1;
> +  }
> +
> +  *smr = 0x00;
> +  *brr = 0x40;
> +  return 0;
> +}
> diff --git a/bsps/sh/gensh1/include/bsp.h b/bsps/sh/gensh1/include/bsp.h
> index f3f7c028cd..b757a010d6 100644
> --- a/bsps/sh/gensh1/include/bsp.h
> +++ b/bsps/sh/gensh1/include/bsp.h
> @@ -60,8 +60,8 @@ extern void *CPU_Interrupt_stack_high;
>   */
>  void bsp_hw_init(void);
>
> -extern int _sci_get_brparms(
> -  tcflag_t  cflag,
> +int _sci_get_brparms(
> +  unsigned int   spd,
>unsigned char *smr,
>unsigned char *brr
>  );
> diff --git a/bsps/sh/gensh2/console/sci.c b/bsps/sh/gensh2/console/sci.c
> index 143fc1bb94..e02049cbf3 100644
> --- a/bsps/sh/gensh2/console/sci.c
> +++ b/bsps/sh/gensh2/console/sci.c
> @@ -73,8 +73,7 @@
>  #define SH_SCI_BASE_1   SCI_SMR1
>
>  #define SH_SCI_DEF_COMM_0   CS8, B9600
> -#define SH_SCI_DEF_COMM_1   CS8, B38400
> -/*  #define SH_SCI_DEF_COMM_1   CS8, B9600 */
> +#define SH_SCI_DEF_COMM_1   CS8, B9600
>
>  struct scidev_t {
>char *

Re: [PATCH 1/6] nios2gen: Import from RTEMS

2018-06-11 Thread Sebastian Huber 

On 11/06/18 14:52, Sebastian Huber wrote:

What do we want to do with this tool? It uses the RTEMS GPL.



This tool is not used during the BSP build. I can be removed without 
breaking 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 1/6] nios2gen: Import from RTEMS

2018-06-11 Thread Sebastian Huber 

What do we want to do with this tool? It uses the RTEMS GPL.

--
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] tools: Remove shgen

2018-06-11 Thread Sebastian Huber 
All tools should be removed from the RTEMS source repository at some
point in time. Tools with a BSD-style license will be moved to the RTEMS
tools repository. Unfortunately, the shgen tool is GPL licensed.

Remove all uses of this tool from the code base. Replace generated files
with stub functions. If users of this BSP still exist, they can
reimplement the functionality using a BSD-style license.

Close #3443.
---
 bsps/sh/gensh1/console/sci.c|   8 +-
 bsps/sh/gensh1/console/scitab.c |  38 
 bsps/sh/gensh1/include/bsp.h|   4 +-
 bsps/sh/gensh2/console/sci.c|   3 +-
 bsps/sh/gensh2/console/scitab.c |  38 
 bsps/sh/gensh2/include/bsp.h|   5 +-
 c/src/lib/libbsp/sh/gensh1/Makefile.am  |   9 +-
 c/src/lib/libbsp/sh/gensh1/configure.ac |   7 +-
 c/src/lib/libbsp/sh/gensh2/Makefile.am  |   9 +-
 c/src/lib/libbsp/sh/gensh2/configure.ac |   6 +-
 tools/cpu/configure.ac  |   1 -
 tools/cpu/sh/AUTHORS|   3 -
 tools/cpu/sh/COPYING| 340 
 tools/cpu/sh/Makefile.am|  14 --
 tools/cpu/sh/TODO   |  13 --
 tools/cpu/sh/configure.ac   |  25 ---
 tools/cpu/sh/sci.c  | 177 -
 tools/cpu/sh/sci.h  |  11 --
 tools/cpu/sh/shgen.c| 114 ---
 19 files changed, 87 insertions(+), 738 deletions(-)
 create mode 100644 bsps/sh/gensh1/console/scitab.c
 create mode 100644 bsps/sh/gensh2/console/scitab.c
 delete mode 100644 tools/cpu/sh/AUTHORS
 delete mode 100644 tools/cpu/sh/COPYING
 delete mode 100644 tools/cpu/sh/Makefile.am
 delete mode 100644 tools/cpu/sh/TODO
 delete mode 100644 tools/cpu/sh/configure.ac
 delete mode 100644 tools/cpu/sh/sci.c
 delete mode 100644 tools/cpu/sh/sci.h
 delete mode 100644 tools/cpu/sh/shgen.c

diff --git a/bsps/sh/gensh1/console/sci.c b/bsps/sh/gensh1/console/sci.c
index 04d9ca5c70..fedfa30b51 100644
--- a/bsps/sh/gensh1/console/sci.c
+++ b/bsps/sh/gensh1/console/sci.c
@@ -18,7 +18,7 @@
  *  http://www.rtems.org/license/LICENSE.
  */
 
-#include 
+#include 
 
 #include 
 
@@ -53,12 +53,6 @@ struct scidev_t {
   { "/dev/sci1", SH_SCI_BASE_1, 1, 0, CS8, B9600 }
 } ;
 
-/*  imported from scitab.rel */
-extern int _sci_get_brparms(
-  speed_t   spd,
-  unsigned char *smr,
-  unsigned char *brr );
-
 /* Translate termios' tcflag_t into sci settings */
 static int _sci_set_cflags(
   struct scidev_t  *sci_dev,
diff --git a/bsps/sh/gensh1/console/scitab.c b/bsps/sh/gensh1/console/scitab.c
new file mode 100644
index 00..3c698f8100
--- /dev/null
+++ b/bsps/sh/gensh1/console/scitab.c
@@ -0,0 +1,38 @@
+/*
+ * Copyright (c) 2018 embedded brains GmbH.  All rights reserved.
+ *
+ *  embedded brains GmbH
+ *  Dornierstr. 4
+ *  82178 Puchheim
+ *  Germany
+ *  
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ * http://www.rtems.org/license/LICENSE.
+ */
+
+/*
+ * The content of this file was previously generated by the GPL licensed shgen
+ * tool during the BSP build for a configured clock frequency
+ * (CPU_CLOCK_RATE_HZ). All tools were removed from the RTEMS source repository
+ * at some point in time. Tools with a BSD-style license were moved to the
+ * RTEMS tools repository.
+ */
+
+#include 
+
+int _sci_get_brparms(
+  unsigned int   spd,
+  unsigned char *smr,
+  unsigned char *brr
+)
+{
+  if (spd != 9600) {
+return -1;
+  }
+
+  *smr = 0x00;
+  *brr = 0x40;
+  return 0;
+}
diff --git a/bsps/sh/gensh1/include/bsp.h b/bsps/sh/gensh1/include/bsp.h
index f3f7c028cd..b757a010d6 100644
--- a/bsps/sh/gensh1/include/bsp.h
+++ b/bsps/sh/gensh1/include/bsp.h
@@ -60,8 +60,8 @@ extern void *CPU_Interrupt_stack_high;
  */
 void bsp_hw_init(void);
 
-extern int _sci_get_brparms(
-  tcflag_t  cflag,
+int _sci_get_brparms(
+  unsigned int   spd,
   unsigned char *smr,
   unsigned char *brr
 );
diff --git a/bsps/sh/gensh2/console/sci.c b/bsps/sh/gensh2/console/sci.c
index 143fc1bb94..e02049cbf3 100644
--- a/bsps/sh/gensh2/console/sci.c
+++ b/bsps/sh/gensh2/console/sci.c
@@ -73,8 +73,7 @@
 #define SH_SCI_BASE_1   SCI_SMR1
 
 #define SH_SCI_DEF_COMM_0   CS8, B9600
-#define SH_SCI_DEF_COMM_1   CS8, B38400
-/*  #define SH_SCI_DEF_COMM_1   CS8, B9600 */
+#define SH_SCI_DEF_COMM_1   CS8, B9600
 
 struct scidev_t {
   char * name;
diff --git a/bsps/sh/gensh2/console/scitab.c b/bsps/sh/gensh2/console/scitab.c
new file mode 100644
index 00..ca253df573
--- /dev/null
+++ b/bsps/sh/gensh2/console/scitab.c
@@ -0,0 +1,38 @@
+/*
+ * Copyright (c) 2018 embedded brains GmbH.  All rights reserved.
+ *
+ *  embedded brains GmbH
+ *  Dornierstr. 4
+ *  82178 Puchheim
+ *  Germany
+ *  
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ *

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

2018-06-11 Thread Chris Johns 
On 11/6/18 7:48 pm, Sebastian Huber wrote:
> On 11/06/18 11:35, Chris Johns wrote:
>>> 3. Remove the gensh1 and gensh2 BSPs.
>>>
>> What is in the generated file?
>>
>> We use weak symbols in the Zynq BSP to allow us to override defaults. Could 
>> this
>> approach be used?
> 
> The generated file provides a function _sci_get_brparms() and an array with
> generated data items used by this function. Its not really much stuff.
> 

Could this function be added, tagged weak and it calls raises a fatal error?

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

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

2018-06-11 Thread Sebastian Huber 

On 11/06/18 11:35, Chris Johns wrote:

3. Remove the gensh1 and gensh2 BSPs.


What is in the generated file?

We use weak symbols in the Zynq BSP to allow us to override defaults. Could this
approach be used?


The generated file provides a function _sci_get_brparms() and an array 
with generated data items used by this function. Its not really much stuff.


--
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 3/6] shgen: Import from RTEMS

2018-06-11 Thread Chris Johns 
On 11/6/18 5:49 pm, Sebastian Huber wrote:
> On 11/06/18 08:22, Joel Sherrill wrote:
>>
>>
>>     >
>>     >     >
>>     >     >>> Does this tool need to move over?
>>     >     >> I would like to move all host tools out of the RTEMS
>>     repository
>>     >     to simplify the
>>     >     >> build. If we get rid of the host tools, then we have only to
>>     >     deal with the
>>     >     >> cross-build tools.
>>     >     > This is a good thing to do, thank you.
>>     >     >
>>     >     >>>    Is the sh arch active?
>>     >     >> I don't know.
>>     >     > I suggest we remove this code until someone needs it and can
>>     >     resolve this issue.
>>     >     > The code is in the 4.11 releases so is easy to find.
>>     >
>>     >     The shgen tool is used to build the gensh1 and gensh2 BSPs to
>>     >     generate
>>     >     the scitab.c source file.
>>
>>
>> Sorry..I missed this.
>>
>>     >
>>     >     One option to get rid of the shgen tool would be to remove the
>>     >     CPU_CLOCK_RATE_HZ BSP option.
>>
>>
>> Ok. Or retroactively deprecate in 4.11
> 
> The tool generates a scitab.c with this header:
> 
> /*
>  * DO NOT EDIT - this file is automatically generated by shgen
> 5.07adc7f7e37a_modified
>  * Copyright (c) 1998,1999,2000 Ralf Corsepius (corse...@faw.uni-ulm.de)
>  */
> 
> /* This file is not copyrighted */
> 
> Files with such a header are not acceptable for an import into the RTEMS 
> sources
> repository  from my point of view. 

I agree.

> We have three options now:
> 
> 1. Keep the tools in the RTEMS source repository.

I prefer they are moved out.

> 2. Add GPL software to rtems-tools.

I prefer this not happen. I have worked hard over the life of repo to be careful
not to have GPL in the repo.

> 
> 3. Remove the gensh1 and gensh2 BSPs.
> 

What is in the generated file?

We use weak symbols in the Zynq BSP to allow us to override defaults. Could this
approach be used?

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

Re: RISC-V tool chain

2018-06-11 Thread Chris Johns 
On 11/6/18 6:33 pm, Sebastian Huber wrote:
> 
> Please review also this comment:
> 
> https://devel.rtems.org/ticket/3448#comment:1
> 

Done.

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

Re: RISC-V tool chain

2018-06-11 Thread Sebastian Huber 

On 11/06/18 07:08, Sebastian Huber wrote:



On 08/06/18 07:54, Chris Johns wrote:

On 06/06/2018 19:57, 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.

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.

Yes.


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.

What would be involved in making it automatic?

You could add cron a job on dispatch.rtems.org once a day. It would 
be a nice

server to have it close to current.:)


Ok, I will try to create a cron job.

Do we want to mirror all branches or just the ones we use?



Please review also this comment:

https://devel.rtems.org/ticket/3448#comment:1

--
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] x86_64/binutils: Add PEI target to build UEFI application images

2018-06-11 Thread Amaan Cheval 
Bump :)
On Tue, Jun 5, 2018 at 10:54 PM Amaan Cheval  wrote:
>
> Original commit in binutils:
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=421acf18739edb54111b64d2b328ea2e7bf19889
>
> Update #2898
> ---
>  rtems/config/5/rtems-x86_64.bset | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/rtems/config/5/rtems-x86_64.bset 
> b/rtems/config/5/rtems-x86_64.bset
> index 9b92538..6041971 100644
> --- a/rtems/config/5/rtems-x86_64.bset
> +++ b/rtems/config/5/rtems-x86_64.bset
> @@ -14,4 +14,9 @@
>  %patch add gcc --rsb-file=gcc-f8fd78279d353f6959e75ac25571c1b7b2dec110.patch 
> https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff_plain;f=libgcc/config.host;h=f8fd78279d353f6959e75ac25571c1b7b2dec110;hp=11b4acaff55e00ee6bd3c182e9da5dc597ac57c4;hb=ab55f7db3694293e4799d58f7e1a556c0eae863a;hpb=344c180cca810c50f38fd545bb9a102fb39306b7
>  %hash sha512 gcc-f8fd78279d353f6959e75ac25571c1b7b2dec110.patch 
> aef76f9d45a53096a021521375fc302a907f78545cc57683a7a00ec61608b8818115720f605a6b1746f479c8568963b380138520e259cbb9e8951882c2f1567f
>
> +#
> +# Binutils PEI target for UEFI support
> +#
> +%patch add binutils 
> --rsb-file=binutils-f8ca72b332396939c7c04a8774ce4c54f5a82d42.patch 
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blobdiff_plain;f=bfd/config.bfd;h=f8ca72b332396939c7c04a8774ce4c54f5a82d42;hp=0db8ed4562b2c11ce51e6a3b138c317f4014a1aa;hb=421acf18739edb54111b64d2b328ea2e7bf19889;hpb=f7c6f42310233479ea6339430b7c1ca1f9ec68e1
> +%hash sha512 binutils-f8ca72b332396939c7c04a8774ce4c54f5a82d42.patch 
> f8af6906871a95a6fb234d0c72c44e9b1823ed835ec91bd84b466aad1f2f5f021ff5fb37835e6132899dcaa6c7e52e3e73f5a2dc9f0efab97aa6fffce2f06d9e
>  %include 5/rtems-default.bset
> --
> 2.16.0.rc0
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

2018-06-11 Thread Sebastian Huber 

On 11/06/18 08:22, Joel Sherrill wrote:



>
>     >
>     >>> Does this tool need to move over?
>     >> I would like to move all host tools out of the RTEMS
repository
>     to simplify the
>     >> build. If we get rid of the host tools, then we have only to
>     deal with the
>     >> cross-build tools.
>     > This is a good thing to do, thank you.
>     >
>     >>>    Is the sh arch active?
>     >> I don't know.
>     > I suggest we remove this code until someone needs it and can
>     resolve this issue.
>     > The code is in the 4.11 releases so is easy to find.
>
>     The shgen tool is used to build the gensh1 and gensh2 BSPs to
>     generate
>     the scitab.c source file.


Sorry..I missed this.

>
>     One option to get rid of the shgen tool would be to remove the
>     CPU_CLOCK_RATE_HZ BSP option.


Ok. Or retroactively deprecate in 4.11


The tool generates a scitab.c with this header:

/*
 * DO NOT EDIT - this file is automatically generated by shgen 
5.07adc7f7e37a_modified

 * Copyright (c) 1998,1999,2000 Ralf Corsepius (corse...@faw.uni-ulm.de)
 */

/* This file is not copyrighted */

Files with such a header are not acceptable for an import into the RTEMS 
sources repository  from my point of view. We have three options now:


1. Keep the tools in the RTEMS source repository.

2. Add GPL software to rtems-tools.

3. Remove the gensh1 and gensh2 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: [GSoC - x86_64 BSP] Using fPIC to compile RTEMS as a shared library

2018-06-11 Thread Amaan Cheval 
Minor update: I'll work on Chris' suggestion of using FreeBSD's
loader.efi and having that load our static hello.exe - it ought to be
a quicker test that way.
On Sun, Jun 10, 2018 at 9:34 PM Amaan Cheval  wrote:
>
> On Sun, Jun 10, 2018 at 12:38 AM Joel Sherrill  wrote:
> >
> >
> >
> > On Fri, Jun 8, 2018 at 7:45 PM, Chris Johns  wrote:
> >>
> >> On 9/6/18 10:00 am, Joel Sherrill wrote:
> >> > On Thu, Jun 7, 2018, 9:01 PM Chris Johns  >> > > wrote:
> >> > > and what
> >> > > discussions we need to have to decide between the "bundled 
> >> > kernel.so approach"
> >> > > (the one implemented here) vs. the "FreeBSD loader.efi+hello.exe"
> >> > approach. Let
> >> > > me know!
> >> > >
> >> >
> >> > I do not think I can help too much here. I understand the 
> >> > loader.efi+exe
> >> > solution and it should work because all RTEMS applications we have 
> >> > are
> >> > statically linked (I am assuming it is here). I have not looked at 
> >> > the details
> >> > being used with the -fPIC and .so solution so I cannot comment. I do 
> >> > have some
> >> > concerns the relocatable exe might expose some dark corners and 
> >> > issues in the
> >> > host tools we have, for example how does GDB find the base address 
> >> > of the image
> >> > so you can debug it? and is this just working or is it really 
> >> > suppose to work
> >> > this way?
> >> >
> >> >
> >> > All I can say is that with Deos/RTEMS, we use PIC on arm, PowerPC, and 
> >> > x86.
> >>
> >> I would hope a solution like Deos did provide a seamless way to do this 
> >> and I
> >> would also hope they support you.
> >
> >
> > I am not using their normal recommended tool setup for users. This is normal
> > RTEMS tools building our test executables. At one point, it was our gdb with
> > their qemu build. They use something like this strictly internally.
> >
> > These executables are statically linked EXCEPT for references to, in
> > the minimum case, two .so's from their environment. I set an argument to
> > ld to ensure all symbols are resolved at link time. Their boot process 
> > associates
> > the .so files with the partitions. It is dynamic loading but it is 
> > statically configured
> > and not touched after boot.
> >
> > I haven't had any special help from them in this area except figuring out 
> > the
> > arguments and linker scripts. When I have access to a build log, I am happy
> > to post the build of hello world for comparison.
> >
> > I have no idea how this compares to UEFI booting except to say that PIC
> > hasn't introduced any tool issues in our GNU tools. libdl may have issues
> > but we aren't using it yet. I can check if the tests pass or are disabled. I
> > don't remember. But that may be illuminating.
> >
> >>
> >>
> >> > We
> >> > have spent a lot of time debugging with gdb attached to qemu.
> >> How does GDB get the relocatable load address to map to the symbol table?
> >>
> >> The libdl code supports the same protocol/design as NetBSD and other 
> >> systems in
> >> informing GDB about the address of loaded modules. There is a series of 
> >> symbols
> >> and tables maintained that GDB knows to examine to find the load addresses 
> >> of
> >> object files.
> >>
> >> > I haven't seen any tools issues yet.
> >>
> >> Yet?  Once the path is settled it will be difficult to change so all I am 
> >> asking
> >> is the detail be checked and understood. RTEMS does not support shared 
> >> libraries
> >> the same way Linux or other Unix systems do. I do not understand enough of 
> >> the
> >> low level and the standards all this is based on to help decide.
> >>
> >> An example of an issue where a relocatable kernel with an unknown load 
> >> address
> >> creates a problem is libdl. The testsuite uses the 2-pass approach 
> >> (rtems-syms
> >> --embed) which should be OK however the other approach where the symbol 
> >> table is
> >> not embedded and built on the host would fail. It is a small issue but it 
> >> shows
> >> how things can subtly break.
> >
> >
> > I'm not relocating any RTEMS code with Deos. Our code is linked to a static 
> > address
> > ranges and invokes Deos methods in the shared libbary.
> >
> > I know this doesn't prove anything concretely about the UEFI exe  but it is 
> > the closest
> > example we have. PIC is likely OK. The .so magic could be problematic as it 
> > looks
> > like I effectively build a static exe.
>
> The Bsymbolic flag isn't a requirement for this system to work - it
> just helps eliminate the use of the GOT/PLT unnecessarily. Personally,
> I don't think I have the clarity to be able to say whether this is or
> isn't safe - I think the only way to be able to tell will be to
> continue with my work on it and to prove that it either does or
> doesn't, at least in the general case.
>
> What we aim with the hello.so method is the same as you said -
> effectively building a static fully resolved exe, with the difference
>

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

2018-06-11 Thread Joel Sherrill 
On Mon, Jun 11, 2018, 8:14 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 11/06/18 08:10, Joel Sherrill wrote:
> >
> >
> > On Mon, Jun 11, 2018, 7:53 AM Sebastian Huber
> >  > > wrote:
> >
> > On 08/06/18 04:19, Chris Johns wrote:
> > > On 07/06/2018 16:11, Sebastian Huber wrote:
> > >> On 07/06/18 07:53, Chris Johns wrote:
> > >>> 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.
> > >> The nios2gen is also GPL (the RTEMS GPL with linking
> > exception). Is this a
> > >> problem?
> > > We are moving to a BSD-2 license so I assumed this is part of
> > that change?
> >
> > Did someone ask Kolja Waschk if he is all right with a license
> change?
> >
> >
> > Not that I know of.
> >
> >
> > >
> > >> The GCC, GDB and Binutils are also GPL.
> > > They are not in this repo. It is about our repos and the
> > compliance obligations
> > > users have with our code base.
> >
> > Ok, then we have a problem with the tools in the RTEMS sources
> > repository. The shgen is GPL, the nios2gen is RTEMS GPL and the
> > rtems-bin2c has no license at all.
> >
> >
> > If shgen is not used in the build now, then it hasn't been used for
> > over a decade. I say kill it to solve that problem.
>
> It is used by the build, see blow in my previous e-mail.
>
> >
> > Rtems-bin2c is old but from OAR. Marked it as 2 paragraph BSD and oar
> > please. I think it dates back to the original RTEMS CVS date of May 1995.
> >
> > I still have a flight and a train left. Please mark bin2c and move
> > that one along.
>
> Sorry, yes, the rtems-bin2c is all right:
>
>   * 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.
>
> I really meant the packhex tool, which has this file header:
>
> /*  P A C K H E X . C 
>   *
>   *   Packhex is a hex-file compaction utility.  It attempts to concatenate
>   *   hex records to produce more size-efficient packaging.
>   *
>   *   Limitations: Input files must be correctly formatted.  This utility
>   *is not robust enough to detect hex-record formatting
>   *errors.
>   *
>   *   Published:   May 1993 Embedded Systems Programming magazine
>   *"Creating Faster Hex Files"
>   *
>   *   URL: ESP magazine: http://www.embedded.com
>   *Source Code:
> ftp://ftp.mfi.com/pub/espmag/1993/pakhex.zip
>   *
>   *   Author:  Mark Gringrich
>   *
>   *   Compiler:Microsoft C 6.0
>   *cl /F 1000 packhex.c
>   *
>
>   **/
>


I always assumed providing.code in a magazine like that was an acceptable
license but we are pickier now.

I have

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

2018-06-11 Thread Sebastian Huber 

On 11/06/18 08:10, Joel Sherrill wrote:



On Mon, Jun 11, 2018, 7:53 AM Sebastian Huber 
> wrote:


On 08/06/18 04:19, Chris Johns wrote:
> On 07/06/2018 16:11, Sebastian Huber wrote:
>> On 07/06/18 07:53, Chris Johns wrote:
>>> 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.
>> The nios2gen is also GPL (the RTEMS GPL with linking
exception). Is this a
>> problem?
> We are moving to a BSD-2 license so I assumed this is part of
that change?

Did someone ask Kolja Waschk if he is all right with a license change?


Not that I know of.


>
>> The GCC, GDB and Binutils are also GPL.
> They are not in this repo. It is about our repos and the
compliance obligations
> users have with our code base.

Ok, then we have a problem with the tools in the RTEMS sources
repository. The shgen is GPL, the nios2gen is RTEMS GPL and the
rtems-bin2c has no license at all.


If shgen is not used in the build now, then it hasn't been used for 
over a decade. I say kill it to solve that problem.


It is used by the build, see blow in my previous e-mail.



Rtems-bin2c is old but from OAR. Marked it as 2 paragraph BSD and oar 
please. I think it dates back to the original RTEMS CVS date of May 1995.


I still have a flight and a train left. Please mark bin2c and move 
that one along.


Sorry, yes, the rtems-bin2c is all right:

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

I really meant the packhex tool, which has this file header:

/*  P A C K H E X . C 
 *
 *   Packhex is a hex-file compaction utility.  It attempts to concatenate
 *   hex records to produce more size-efficient packaging.
 *
 *   Limitations: Input files must be correctly formatted.  This utility
 *    is not robust enough to detect hex-record formatting
 *    errors.
 *
 *   Published:   May 1993 Embedded Systems Programming magazine
 *    "Creating Faster Hex Files"
 *
 *   URL: ESP magazine: http://www.embedded.com
 *    Source Code: ftp://ftp.mfi.com/pub/espmag/1993/pakhex.zip
 *
 *   Author:  Mark Gringrich
 *
 *   Compiler:    Microsoft C 6.0
 *    cl /F 1000 packhex.c
 *
 **/




>
>>> Does this tool need to move over?
>> I would like to move all host tools out of the RTEMS repository
to simplify the
>> build. If we get rid of the host tools, then we have only to
deal with the
>> cross-build tools.
> This is a good thing to do, thank you.
>
>>>    Is the sh arch active?
>> I don't know.
> I suggest we remove this code until someone needs it and can
resolve this issue.
> The code is in the 4.11 releases so is easy to find.

The shgen tool is used to build the gensh1 and gensh2 BSPs to
generate
the scitab.c source file.

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

2018-06-11 Thread Joel Sherrill 
On Mon, Jun 11, 2018, 7:53 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 08/06/18 04:19, Chris Johns wrote:
> > On 07/06/2018 16:11, Sebastian Huber wrote:
> >> On 07/06/18 07:53, Chris Johns wrote:
> >>> 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.
> >> The nios2gen is also GPL (the RTEMS GPL with linking exception). Is
> this a
> >> problem?
> > We are moving to a BSD-2 license so I assumed this is part of that
> change?
>
> Did someone ask Kolja Waschk if he is all right with a license change?
>

Not that I know of.

>
> >
> >> The GCC, GDB and Binutils are also GPL.
> > They are not in this repo. It is about our repos and the compliance
> obligations
> > users have with our code base.
>
> Ok, then we have a problem with the tools in the RTEMS sources
> repository. The shgen is GPL, the nios2gen is RTEMS GPL and the
> rtems-bin2c has no license at all.
>

If shgen is not used in the build now, then it hasn't been used for over a
decade. I say kill it to solve that problem.

Rtems-bin2c is old but from OAR. Marked it as 2 paragraph BSD and oar
please. I think it dates back to the original RTEMS CVS date of May 1995.

I still have a flight and a train left. Please mark bin2c and move that one
along.

>
> >
> >>> Does this tool need to move over?
> >> I would like to move all host tools out of the RTEMS repository to
> simplify the
> >> build. If we get rid of the host tools, then we have only to deal with
> the
> >> cross-build tools.
> > This is a good thing to do, thank you.
> >
> >>>Is the sh arch active?
> >> I don't know.
> > I suggest we remove this code until someone needs it and can resolve
> this issue.
> > The code is in the 4.11 releases so is easy to find.
>
> The shgen tool is used to build the gensh1 and gensh2 BSPs to generate
> the scitab.c source file.
>
> One option to get rid of the shgen tool would be to remove the
> CPU_CLOCK_RATE_HZ BSP option.
>
> >
> >> There was some activity on this architecture in GCC and Binutils
> >> recently. Some patents expired. This seemed to resurrect this
> architecture.
> >>
> >> https://en.wikipedia.org/wiki/SuperH
> >>
> > I saw this. Until there is some activity it is impossible to know where
> this
> > will lead.
>
> The intention of my tool moves was not to obsolete a complete RTEMS port.
>
> --
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel