Re: [PATCH rtems] bsps/imxrt: Add attribution in file headers

2021-07-20 Thread Sebastian Huber 

On 21/07/2021 02:46, Chris Johns wrote:

On 21/7/21 6:47 am, Gedare Bloom wrote:

This seems fine to me. We don't have any standard way to document this
kind of attribution. However, we have had individual authors add their
names below their company's copyright. It might make sense to put the
sponsorship part beneath the copyright of the sponsored
company/person?


Make sense. The copyright block should be limited to just copyrights and sponsor
acknowledgements should in a separate block, maybe after the license block.


Yes, I also think it should be outside the license comment block.




Not a big deal, but it might help for some kind of
consistent guidance if we do this more in the future.


I think we need some guidelines. I do not agree with URL links, email addresses,
phone numbers or street addreses appearing in the source. I also think a sponsor
acknowledgement is never updated or changed even if a company changes name. What
I am not sure about is the areas of the source we allow this to happen in, ie
score ...?


We could add some text here:

https://docs.rtems.org/branches/master/eng/coding-file-hdr.html

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

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

Re: [PATCH] bsp: Remove fatal from exit(0). Add extended heap error output

2021-07-20 Thread Sebastian Huber 

Hello Chris,

thanks, this is a nice improvement.

On 21/07/2021 07:17, chr...@rtems.org wrote:

--- a/bsps/shared/start/bspfatal-default.c
+++ b/bsps/shared/start/bspfatal-default.c
@@ -22,15 +22,24 @@ void bsp_fatal_extension(
  {
#if BSP_VERBOSE_FATAL_EXTENSION
  Thread_Control *executing;
+const char* TYPE = "*** FATAL ***\n";
+const char* type = "fatal";
+
+if ( source == RTEMS_FATAL_SOURCE_EXIT ) {
+  TYPE = "";


It would be good to still have a unique pattern which starts the fatal 
extension message.  The "***" is also used for the test begin/end 
marker. What about "*** SYSTEM TERMINATED ***"?


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

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

[PATCH] bsp: Remove fatal from exit(0). Add extended heap error output

2021-07-20 Thread chrisj 
From: Chris Johns 

---
 bsps/shared/start/bspfatal-default.c | 53 +---
 1 file changed, 49 insertions(+), 4 deletions(-)

diff --git a/bsps/shared/start/bspfatal-default.c 
b/bsps/shared/start/bspfatal-default.c
index 0289dbda63..5e93b21b04 100644
--- a/bsps/shared/start/bspfatal-default.c
+++ b/bsps/shared/start/bspfatal-default.c
@@ -22,15 +22,24 @@ void bsp_fatal_extension(
 {
   #if BSP_VERBOSE_FATAL_EXTENSION
 Thread_Control *executing;
+const char* TYPE = "*** FATAL ***\n";
+const char* type = "fatal";
+
+if ( source == RTEMS_FATAL_SOURCE_EXIT ) {
+  TYPE = "";
+  type = "exit";
+}
 
 printk(
   "\n"
-  "*** FATAL ***\n"
-  "fatal source: %i (%s)\n"
+  "%s"
+  "%s source: %i (%s)\n"
   #ifdef RTEMS_SMP
 "CPU: %" PRIu32 "\n"
   #endif
   ,
+  TYPE,
+  type,
   source,
   rtems_fatal_source_text( source )
   #ifdef RTEMS_SMP
@@ -48,13 +57,49 @@ void bsp_fatal_extension(
   #if BSP_VERBOSE_FATAL_EXTENSION
 else if ( source == INTERNAL_ERROR_CORE ) {
   printk(
-"fatal code: %ju (%s)\n",
+"%s code: %ju (%s)\n",
+type,
 (uintmax_t) code,
 rtems_internal_error_text( code )
   );
+} else if ( source == RTEMS_FATAL_SOURCE_HEAP ) {
+  Heap_Error_context *error_context = (Heap_Error_context*) code;
+  const char* reasons[] = {
+"HEAP_ERROR_BROKEN_PROTECTOR",
+"HEAP_ERROR_FREE_PATTERN",
+"HEAP_ERROR_DOUBLE_FREE",
+"HEAP_ERROR_BAD_USED_BLOCK",
+"HEAP_ERROR_BAD_FREE_BLOCK"
+  };
+  const char* reason = "invalid reason";
+  if ( error_context->reason <= (int) HEAP_ERROR_BAD_FREE_BLOCK ) {
+reason = reasons[(int) error_context->reason];
+  }
+  printk(
+"heap error: heap=%p block=%p reason=%s(%d)",
+error_context->heap,
+error_context->block,
+reason,
+error_context->reason
+  );
+  if ( error_context->reason == HEAP_ERROR_BROKEN_PROTECTOR ) {
+uintptr_t *pb0 = _context->block->Protection_begin.protector [0];
+uintptr_t *pb1 = _context->block->Protection_begin.protector [1];
+uintptr_t *pe0 = _context->block->Protection_end.protector [0];
+uintptr_t *pe1 = _context->block->Protection_end.protector [1];
+printk(
+  "=[%p,%p,%p,%p]",
+  *pb0 != HEAP_BEGIN_PROTECTOR_0 ? pb0 : NULL,
+  *pb1 != HEAP_BEGIN_PROTECTOR_1 ? pb1 : NULL,
+  *pe0 != HEAP_END_PROTECTOR_0 ? pe0 : NULL,
+  *pe1 != HEAP_END_PROTECTOR_1 ? pe1 : NULL
+);
+printk( "\n" );
+  }
 } else {
   printk(
-"fatal code: %ju (0x%08jx)\n",
+"%s code: %ju (0x%08jx)\n",
+type,
 (uintmax_t) code,
 (uintmax_t) code
   );
-- 
2.24.1

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

Re: LwIP for RTEMS state querry Was: [PATCH rtems-lwip v2] STM32 lwIP addition

2021-07-20 Thread Vijay Kumar Banerjee 
Hi Pavel,


On Tue, Jul 20, 2021 at 1:13 PM Pavel Pisa  wrote:
>
> Hello everybody,
>
> I have no technical stuff to share for now,
> but I am happy that work on LwIP alternative
> stack for RTEMS continues on.
>
> I have question which repo is considered as
> mainline (integration point) for this work.
> Is it devel branch of  Vijay Kumar Banerjee's
> repo
>
>   https://git.rtems.org/vijay/rtems-lwip.git/
>
Right now yes. Once this is mature, it will probably be pushed to the
top directory.

> If so, it would worth to put that on the top
> of LwIP RTEMS info page to guide people interested
> to live work and not lose time in another
> abandonned attempts
>
>   https://devel.rtems.org/wiki/Packages/LWIP
>
Thanks, I'll add a note there.

> Addition of pointers to STM WIP to some
> central place would worth too with
> pointer to the instructions or instructions
> included...
>
I haven't tested it myself. Robin is working on this one and might be
able to add the instructions. But this is supposed to be merged into
the repo you mentioned above.

> In the longer term horizon, it would worth
> to get rid of twisted translation layer I have
> introduced initially
>
>   
> https://git.rtems.org/vijay/rtems-lwip.git/tree/lwip/src/api/rtems_lwip_sysdefs.c?h=devel
>
> The best option would be if mainline LwIP provides
> configurable option to use external types, enums,
> structures (struct sockaddr) prototypes from libc
> (i.e. NewLib) which would remove this translation.
> I still think that move to LWIP_NETCONN only
> and disable of LWIP_SOCKET could be the way
> forward, but would require to implement own
> layer to switch right NetCon base according
> to socket AF domain, and type. So it would not be
> easy task and solution based on actual FD to LwIP FD
> translation could be used until then.
>
> Generally I am curious what works and where
> are problems. I do not expect to have time or
> find students this summer but I try to offer
> project as theses and next summer and there
> chance (small) that I find some studnet
> to participate.
>
I am currently actively working on the lwip port to get it working
with at least a few boards, along with a streamlined build system. I
could only get the BBB running with a telnetd application that I added
in the test/ directory in the rtems-lwip repository. I used the
drivers from TI for BBB.

> This summer is my main interrest with studnets
> work focused on pysimCoder to boost usability.
>
>   https://github.com/robertobucher/pysimCoder
>
> It is usable with preemptive GNU/Linux
> on more targets, NuttX and adding support
> for RTEMS would be easy as well.
> Some demo with NuttX
>
>   https://youtu.be/6HlGk3ecPNQ
>
> Same targets are supported by our support
> for Matlab/Simulink, RTEMS is on my list
> for this projet for many years as well,
> so if somebody have interrest, I would help
> by advice or some prototype (which I have
> for RTEMS in some hacked state in the past)
>
>   https://github.com/aa4cc/ert_linux/
>
> Best wishes,
>
> Pavel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 1/5] rtems-utils.h: Create ostream_guard

2021-07-20 Thread Chris Johns 
Close, some minor formatting issues 

On 21/7/21 1:06 am, Ryan Long wrote:
> ---
>  rtemstoolkit/rtems-utils.h | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/rtemstoolkit/rtems-utils.h b/rtemstoolkit/rtems-utils.h
> index 4ce9c68..c4a262e 100644
> --- a/rtemstoolkit/rtems-utils.h
> +++ b/rtemstoolkit/rtems-utils.h
> @@ -47,6 +47,24 @@ namespace rtems
> boolreal = false,
> size_t  line_length = 16,
> uint32_toffset = 0);
> +
> +/*
> + * Save and restore the output stream's settings.
> + */
> +struct ostream_guard {
> +  std::ostream&   o;
> +  std::ios_base::fmtflags flags;
> +
> +  ostream_guard ( std::ostream& o_ ) : o( o_ ), flags( o_.flags() )

The syntax I use and posted is:

   ostream_guard (std::ostream& o_)
 : o (o_),
   flags (o_.flags ())
   {
   }

First the spaces are what the toolkit uses, there are no extra spaces but the
initialiser list is the important piece so I will explain why it is the way it 
is.

The way I have written the code lets you make changes to a struct (or class)
without impacting a single line. This struct is pretty simple but more complex
structs can have many initialisers and they need to be in order in the
initialiser list and if you add or move members the order needs to change. Being
able to visually inspect the struct and the list is important. Considers these
constructors 

https://git.rtems.org/rtems-tools/tree/rtemstoolkit/rld-symbols.cpp#n72

> +  {
> +  }
> +
> +  ~ostream_guard ()
> +  {
> +  o.flags( flags );

2 spaces please.

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

Re: [PATCH] build: Add the BSP family to the enable set

2021-07-20 Thread Chris Johns 


On 20/7/21 8:25 pm, Sebastian Huber wrote:
> On 15/07/2021 08:19, Sebastian Huber wrote:
>> This makes it possible to use the BSP family in expressions of the enabled-by
>> attribute.
>> ---
>>   wscript | 7 ++-
>>   1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/wscript b/wscript
>> index 487951fdba..1331ae149e 100755
>> --- a/wscript
>> +++ b/wscript
>> @@ -1387,7 +1387,12 @@ def configure_variant(conf, cp, bsp_map, path_list,
>> top_group, variant):
>>     # For the enabled-by evaluation we have to use the base BSP defined 
>> by
>> the
>>   # build specification and not the BSP name provided by the user.
>> -    conf.env["ENABLE"] = [get_compiler(conf, cp, variant), arch, arch_bsp]
>> +    conf.env["ENABLE"] = [
>> +    get_compiler(conf, cp, variant),
>> +    arch,
>> +    arch_family,
>> +    arch_bsp,
>> +    ]
>>     conf.env["TOP"] = conf.path.abspath()
>>   conf.env["TOPGROUP"] = top_group
> 
> This actually broke some riscv BSPs which do not support SMP. We have
> 
> cat spec/build/cpukit/optsmp.yml
> SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> actions:
> - get-boolean: null
> - env-enable: null
> - define-condition: null
> build-type: option
> copyrights:
> - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> default: false
> default-by-family: []
> default-by-variant: []
> description: |
>   Enable the Symmetric Multiprocessing (SMP) support
> enabled-by:
> - arm/altcycv_devkit
> - arm/fvp_cortex_r52
> - arm/imx7
> - arm/raspberrypi2
> - arm/realview_pbx_a9_qemu
> - arm/xilinx_zynq_a9_qemu
> - arm/xilinx_zynqmp_ultra96
> - arm/xilinx_zynq_zc702
> - arm/xilinx_zynq_zc706
> - arm/xilinx_zynq_zedboard
> - powerpc/qoriq_e500
> - powerpc/qoriq_e6500_32
> - powerpc/qoriq_e6500_64
> - riscv/griscv
> - riscv/grv32imac
> - riscv/grv32imafdc
> - riscv/rv32iac
> - riscv/rv32imac
> - riscv/rv32imafc
> - riscv/rv32imafd
> - riscv/rv32imafdc
> - riscv/rv64imac
> - riscv/rv64imac_medany
> - riscv/rv64imafd
> - riscv/rv64imafdc
> - riscv/rv64imafdc_medany
> - riscv/rv64imafd_medany
> - sparc/erc32
> - sparc/gr712rc
> - sparc/gr740
> - sparc/leon3
> links: []
> name: RTEMS_SMP
> type: build
> 
> The problem is that one BSP which supports SMP "riscv/griscv" is identical to
> the family "riscv/griscv" which contains BSPs which do not support SMP
> ("riscv/grv32i" and riscv/grv32im").

Hmm, tricky. Can the BSPs that do not support SMP disable SMP in the BSP
specific config, ie override/specialise in the BSP?

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

Re: [PATCH rtems] bsps/imxrt: Add attribution in file headers

2021-07-20 Thread Chris Johns 
On 21/7/21 6:47 am, Gedare Bloom wrote:
> This seems fine to me. We don't have any standard way to document this
> kind of attribution. However, we have had individual authors add their
> names below their company's copyright. It might make sense to put the
> sponsorship part beneath the copyright of the sponsored
> company/person? 

Make sense. The copyright block should be limited to just copyrights and sponsor
acknowledgements should in a separate block, maybe after the license block.

> Not a big deal, but it might help for some kind of
> consistent guidance if we do this more in the future.

I think we need some guidelines. I do not agree with URL links, email addresses,
phone numbers or street addreses appearing in the source. I also think a sponsor
acknowledgement is never updated or changed even if a company changes name. What
I am not sure about is the areas of the source we allow this to happen in, ie
score ...?

Chris

> 
> On Tue, Jul 20, 2021 at 8:20 AM Christian Mauderer
>  wrote:
>>
>> Onto Innovations Incorporated originally sponsored the development of
>> this BSP. This patch adds the attribution for it.
>>
>> The patch also fixes an old license header in bspstarthooks.c that was
>> accidentally copied into that file.
>> ---
>>  bsps/arm/imxrt/console/console.c  |  1 +
>>  bsps/arm/imxrt/dts/imxrt1050-evkb.dts |  2 ++
>>  bsps/arm/imxrt/i2c/imxrt-lpi2c.c  |  1 +
>>  bsps/arm/imxrt/include/bsp.h  |  1 +
>>  bsps/arm/imxrt/include/bsp/flash-headers.h|  1 +
>>  bsps/arm/imxrt/include/bsp/irq.h  |  1 +
>>  bsps/arm/imxrt/include/fsl_device_registers.h |  1 +
>>  .../imxrt/include/imxrt/imxrt1050-pinfunc.h   |  1 +
>>  bsps/arm/imxrt/include/imxrt/imxrt1050.dtsi   |  2 ++
>>  bsps/arm/imxrt/include/imxrt/lpspi.h  |  1 +
>>  bsps/arm/imxrt/include/imxrt/memory.h |  1 +
>>  bsps/arm/imxrt/include/imxrt/mpu-config.h |  1 +
>>  bsps/arm/imxrt/spi/imxrt-lpspi.c  |  1 +
>>  bsps/arm/imxrt/start/bspstart.c   |  1 +
>>  bsps/arm/imxrt/start/bspstarthooks.c  | 32 +--
>>  bsps/arm/imxrt/start/clock-arm-pll-config.c   |  1 +
>>  bsps/arm/imxrt/start/flash-boot-data.c|  1 +
>>  bsps/arm/imxrt/start/flash-flexspi-config.c   |  1 +
>>  bsps/arm/imxrt/start/flash-ivt.c  |  1 +
>>  bsps/arm/imxrt/start/imxrt-ffec-init.c|  1 +
>>  bsps/arm/imxrt/start/mpu-config.c |  1 +
>>  21 files changed, 45 insertions(+), 9 deletions(-)
>>
>> diff --git a/bsps/arm/imxrt/console/console.c 
>> b/bsps/arm/imxrt/console/console.c
>> index 05320f2c4c..ab278b9d22 100644
>> --- a/bsps/arm/imxrt/console/console.c
>> +++ b/bsps/arm/imxrt/console/console.c
>> @@ -1,6 +1,7 @@
>>  /* SPDX-License-Identifier: BSD-2-Clause */
>>
>>  /*
>> + * i.MX RT port sponsored by Onto Innovation Incorporated
>>   * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
>>   *
>>   * Redistribution and use in source and binary forms, with or without
>> diff --git a/bsps/arm/imxrt/dts/imxrt1050-evkb.dts 
>> b/bsps/arm/imxrt/dts/imxrt1050-evkb.dts
>> index 9310371428..bf24762d86 100644
>> --- a/bsps/arm/imxrt/dts/imxrt1050-evkb.dts
>> +++ b/bsps/arm/imxrt/dts/imxrt1050-evkb.dts
>> @@ -1,7 +1,9 @@
>>  /* SPDX-License-Identifier: BSD-2-Clause */
>>
>>  /*
>> + * i.MX RT port sponsored by Onto Innovation Incorporated
>>   * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
>> + *
>>   * Redistribution and use in source and binary forms, with or without
>>   * modification, are permitted provided that the following conditions
>>   * are met:
>> diff --git a/bsps/arm/imxrt/i2c/imxrt-lpi2c.c 
>> b/bsps/arm/imxrt/i2c/imxrt-lpi2c.c
>> index 783c6e18e6..0873499a24 100644
>> --- a/bsps/arm/imxrt/i2c/imxrt-lpi2c.c
>> +++ b/bsps/arm/imxrt/i2c/imxrt-lpi2c.c
>> @@ -1,6 +1,7 @@
>>  /* SPDX-License-Identifier: BSD-2-Clause */
>>
>>  /*
>> + * i.MX RT port sponsored by Onto Innovation Incorporated
>>   * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
>>   *
>>   * Redistribution and use in source and binary forms, with or without
>> diff --git a/bsps/arm/imxrt/include/bsp.h b/bsps/arm/imxrt/include/bsp.h
>> index f93c28aee0..78fa6a42e1 100644
>> --- a/bsps/arm/imxrt/include/bsp.h
>> +++ b/bsps/arm/imxrt/include/bsp.h
>> @@ -7,6 +7,7 @@
>>   */
>>
>>  /*
>> + * i.MX RT port sponsored by Onto Innovation Incorporated
>>   * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
>>   *
>>   * Redistribution and use in source and binary forms, with or without
>> diff --git a/bsps/arm/imxrt/include/bsp/flash-headers.h 
>> b/bsps/arm/imxrt/include/bsp/flash-headers.h
>> index 6575b1c21b..a50ae68d58 100644
>> --- a/bsps/arm/imxrt/include/bsp/flash-headers.h
>> +++ b/bsps/arm/imxrt/include/bsp/flash-headers.h
>> @@ -9,6 +9,7 @@
>>   */
>>
>>  /*
>> + * i.MX RT port sponsored by Onto Innovation Incorporated
>>   * Copyright (C)

[PATCH] linker_set.h: Add alignof implementation for when not C11 or C++11

2021-07-20 Thread Joel Sherrill 
The default implementation was completely broken. Use the GCC specific
__alignof__ if compiling for C99 or C++03. If not C++11, C11, or
GCC, then it is an error.
---
 freebsd/sys/sys/linker_set.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/freebsd/sys/sys/linker_set.h b/freebsd/sys/sys/linker_set.h
index baa5ae4..9af5307 100755
--- a/freebsd/sys/sys/linker_set.h
+++ b/freebsd/sys/sys/linker_set.h
@@ -73,8 +73,10 @@
   #define RTEMS_BSD_ALIGNOF( _type_name ) alignof( _type_name )
 #elif __STDC_VERSION__ >= 201112L
   #define RTEMS_BSD_ALIGNOF( _type_name ) _Alignof( _type_name )
+#elif defined(__GNUC__)
+  #define RTEMS_BSD_ALIGNOF( _type_name ) __alignof__( _type_name )
 #else
-  #define RTEMS_BSD_ALIGNOF( _type_name ) sizeof( _type_name )
+  #error "FIX ME! Implement RTEMS_BSD_ALIGNOF() for this environment"
 #endif
 
 #define RTEMS_BSD_SET_ALIGN( type )\
-- 
1.8.3.1

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

Re: [PATCH rtems] bsps/imxrt: Add attribution in file headers

2021-07-20 Thread Gedare Bloom 
This seems fine to me. We don't have any standard way to document this
kind of attribution. However, we have had individual authors add their
names below their company's copyright. It might make sense to put the
sponsorship part beneath the copyright of the sponsored
company/person? Not a big deal, but it might help for some kind of
consistent guidance if we do this more in the future.

On Tue, Jul 20, 2021 at 8:20 AM Christian Mauderer
 wrote:
>
> Onto Innovations Incorporated originally sponsored the development of
> this BSP. This patch adds the attribution for it.
>
> The patch also fixes an old license header in bspstarthooks.c that was
> accidentally copied into that file.
> ---
>  bsps/arm/imxrt/console/console.c  |  1 +
>  bsps/arm/imxrt/dts/imxrt1050-evkb.dts |  2 ++
>  bsps/arm/imxrt/i2c/imxrt-lpi2c.c  |  1 +
>  bsps/arm/imxrt/include/bsp.h  |  1 +
>  bsps/arm/imxrt/include/bsp/flash-headers.h|  1 +
>  bsps/arm/imxrt/include/bsp/irq.h  |  1 +
>  bsps/arm/imxrt/include/fsl_device_registers.h |  1 +
>  .../imxrt/include/imxrt/imxrt1050-pinfunc.h   |  1 +
>  bsps/arm/imxrt/include/imxrt/imxrt1050.dtsi   |  2 ++
>  bsps/arm/imxrt/include/imxrt/lpspi.h  |  1 +
>  bsps/arm/imxrt/include/imxrt/memory.h |  1 +
>  bsps/arm/imxrt/include/imxrt/mpu-config.h |  1 +
>  bsps/arm/imxrt/spi/imxrt-lpspi.c  |  1 +
>  bsps/arm/imxrt/start/bspstart.c   |  1 +
>  bsps/arm/imxrt/start/bspstarthooks.c  | 32 +--
>  bsps/arm/imxrt/start/clock-arm-pll-config.c   |  1 +
>  bsps/arm/imxrt/start/flash-boot-data.c|  1 +
>  bsps/arm/imxrt/start/flash-flexspi-config.c   |  1 +
>  bsps/arm/imxrt/start/flash-ivt.c  |  1 +
>  bsps/arm/imxrt/start/imxrt-ffec-init.c|  1 +
>  bsps/arm/imxrt/start/mpu-config.c |  1 +
>  21 files changed, 45 insertions(+), 9 deletions(-)
>
> diff --git a/bsps/arm/imxrt/console/console.c 
> b/bsps/arm/imxrt/console/console.c
> index 05320f2c4c..ab278b9d22 100644
> --- a/bsps/arm/imxrt/console/console.c
> +++ b/bsps/arm/imxrt/console/console.c
> @@ -1,6 +1,7 @@
>  /* SPDX-License-Identifier: BSD-2-Clause */
>
>  /*
> + * i.MX RT port sponsored by Onto Innovation Incorporated
>   * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
>   *
>   * Redistribution and use in source and binary forms, with or without
> diff --git a/bsps/arm/imxrt/dts/imxrt1050-evkb.dts 
> b/bsps/arm/imxrt/dts/imxrt1050-evkb.dts
> index 9310371428..bf24762d86 100644
> --- a/bsps/arm/imxrt/dts/imxrt1050-evkb.dts
> +++ b/bsps/arm/imxrt/dts/imxrt1050-evkb.dts
> @@ -1,7 +1,9 @@
>  /* SPDX-License-Identifier: BSD-2-Clause */
>
>  /*
> + * i.MX RT port sponsored by Onto Innovation Incorporated
>   * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> + *
>   * Redistribution and use in source and binary forms, with or without
>   * modification, are permitted provided that the following conditions
>   * are met:
> diff --git a/bsps/arm/imxrt/i2c/imxrt-lpi2c.c 
> b/bsps/arm/imxrt/i2c/imxrt-lpi2c.c
> index 783c6e18e6..0873499a24 100644
> --- a/bsps/arm/imxrt/i2c/imxrt-lpi2c.c
> +++ b/bsps/arm/imxrt/i2c/imxrt-lpi2c.c
> @@ -1,6 +1,7 @@
>  /* SPDX-License-Identifier: BSD-2-Clause */
>
>  /*
> + * i.MX RT port sponsored by Onto Innovation Incorporated
>   * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
>   *
>   * Redistribution and use in source and binary forms, with or without
> diff --git a/bsps/arm/imxrt/include/bsp.h b/bsps/arm/imxrt/include/bsp.h
> index f93c28aee0..78fa6a42e1 100644
> --- a/bsps/arm/imxrt/include/bsp.h
> +++ b/bsps/arm/imxrt/include/bsp.h
> @@ -7,6 +7,7 @@
>   */
>
>  /*
> + * i.MX RT port sponsored by Onto Innovation Incorporated
>   * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
>   *
>   * Redistribution and use in source and binary forms, with or without
> diff --git a/bsps/arm/imxrt/include/bsp/flash-headers.h 
> b/bsps/arm/imxrt/include/bsp/flash-headers.h
> index 6575b1c21b..a50ae68d58 100644
> --- a/bsps/arm/imxrt/include/bsp/flash-headers.h
> +++ b/bsps/arm/imxrt/include/bsp/flash-headers.h
> @@ -9,6 +9,7 @@
>   */
>
>  /*
> + * i.MX RT port sponsored by Onto Innovation Incorporated
>   * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
>   *
>   * Redistribution and use in source and binary forms, with or without
> diff --git a/bsps/arm/imxrt/include/bsp/irq.h 
> b/bsps/arm/imxrt/include/bsp/irq.h
> index 6fcd055f03..52de519471 100644
> --- a/bsps/arm/imxrt/include/bsp/irq.h
> +++ b/bsps/arm/imxrt/include/bsp/irq.h
> @@ -7,6 +7,7 @@
>   */
>
>  /*
> + * i.MX RT port sponsored by Onto Innovation Incorporated
>   * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
>   *
>   * Redistribution and use in source and binary forms, with or without
> diff --git a/bsps/arm/imxrt/include/fsl_device_registers.h

RE: Help with RTEMS Tester Results for uC5282

2021-07-20 Thread gerberhe11 
If you’d like I can send over the Git repo that has the Qemu that I’ve been 
working on that includes the current state of the uC5282 emulation! Let me know 
if this would be good, and I’ll make sure it is completely up to date with what 
I have working locally. I’ll continue to look into some of the other tests soon 
to see what I can find based on the advice given!



Thanks so much,



Harrison Gerber

  gerberh...@gmail.com

From: Joel Sherrill 
Sent: Tuesday, July 20, 2021 9:16 AM
To: Sebastian Huber 
Cc: Harrison Edward Gerber ; rtems-de...@rtems.org 

Subject: Re: Help with RTEMS Tester Results for uC5282





On Tue, Jul 20, 2021, 12:22 AM Sebastian Huber 
mailto:sebastian.hu...@embedded-brains.de> 
> wrote:

Hello,

On 20/07/2021 00:43, gerberh...@gmail.com   wrote:
> Dr. Bloom mentioned that some of these results could likely be due to
> flawed TLS implementation of m68k.

this could be also an issue with the linker command file. If I can run
the test myself on Qemu I could try to debug the sptls02.



It would be good to know what is needed to work for each of the TLS tests. We 
just went through this on the new Microblaze port and this one may also be 
failing there.



--joel


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de 

phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

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



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: LwIP for RTEMS state querry Was: [PATCH rtems-lwip v2] STM32 lwIP addition

2021-07-20 Thread Pavel Pisa 
Hello everybody,

I have no technical stuff to share for now,
but I am happy that work on LwIP alternative
stack for RTEMS continues on.

I have question which repo is considered as
mainline (integration point) for this work.
Is it devel branch of  Vijay Kumar Banerjee's
repo

  https://git.rtems.org/vijay/rtems-lwip.git/

If so, it would worth to put that on the top
of LwIP RTEMS info page to guide people interested
to live work and not lose time in another
abandonned attempts 

  https://devel.rtems.org/wiki/Packages/LWIP

Addition of pointers to STM WIP to some
central place would worth too with
pointer to the instructions or instructions
included...

In the longer term horizon, it would worth
to get rid of twisted translation layer I have
introduced initially

  
https://git.rtems.org/vijay/rtems-lwip.git/tree/lwip/src/api/rtems_lwip_sysdefs.c?h=devel

The best option would be if mainline LwIP provides
configurable option to use external types, enums,
structures (struct sockaddr) prototypes from libc
(i.e. NewLib) which would remove this translation.
I still think that move to LWIP_NETCONN only
and disable of LWIP_SOCKET could be the way
forward, but would require to implement own
layer to switch right NetCon base according
to socket AF domain, and type. So it would not be
easy task and solution based on actual FD to LwIP FD
translation could be used until then.

Generally I am curious what works and where
are problems. I do not expect to have time or
find students this summer but I try to offer
project as theses and next summer and there
chance (small) that I find some studnet
to participate.

This summer is my main interrest with studnets
work focused on pysimCoder to boost usability.

  https://github.com/robertobucher/pysimCoder

It is usable with preemptive GNU/Linux
on more targets, NuttX and adding support
for RTEMS would be easy as well.
Some demo with NuttX

  https://youtu.be/6HlGk3ecPNQ

Same targets are supported by our support
for Matlab/Simulink, RTEMS is on my list
for this projet for many years as well,
so if somebody have interrest, I would help
by advice or some prototype (which I have
for RTEMS in some hacked state in the past)

  https://github.com/aa4cc/ert_linux/

Best wishes,

Pavel

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

Re: Help with RTEMS Tester Results for uC5282

2021-07-20 Thread Joel Sherrill 
On Tue, Jul 20, 2021, 12:22 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> On 20/07/2021 00:43, gerberh...@gmail.com wrote:
> > Dr. Bloom mentioned that some of these results could likely be due to
> > flawed TLS implementation of m68k.
>
> this could be also an issue with the linker command file. If I can run
> the test myself on Qemu I could try to debug the sptls02.
>

It would be good to know what is needed to work for each of the TLS tests.
We just went through this on the new Microblaze port and this one may also
be failing there.

--joel

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

[PATCH v2 2/5] rtems-exeinfo.cpp: Restore ostream format

2021-07-20 Thread Ryan Long 
CID 1503006: Not restoring ostream format
CID 1503007: Not restoring ostream format

Used a variable to store the format of the ostream before any changes,
and copied what was originally there back into the stream before
returning from the function.

Closes #4469
---
 linkers/rtems-exeinfo.cpp | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/linkers/rtems-exeinfo.cpp b/linkers/rtems-exeinfo.cpp
index 6e92206..9857e47 100644
--- a/linkers/rtems-exeinfo.cpp
+++ b/linkers/rtems-exeinfo.cpp
@@ -31,6 +31,7 @@
 #endif
 
 #include 
+#include 
 #include 
 
 #include 
@@ -47,11 +48,14 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifndef HAVE_KILL
 #define kill(p,s) raise(s)
 #endif
 
+typedef rtems::utils::ostream_guard ostream_guard;
+
 namespace rld
 {
   namespace exeinfo
@@ -366,6 +370,7 @@ namespace rld
*/
 
   rld::strings all_flags;
+  ostream_guard old_state( std::cout );
 
   size_t source_max = 0;
 
@@ -632,6 +637,8 @@ namespace rld
 
 void image::output_tls ()
 {
+  ostream_guard old_state( std::cout );
+
   symbols::symbol* tls_data_begin = symbols.find_global("_TLS_Data_begin");
   symbols::symbol* tls_data_end = symbols.find_global("_TLS_Data_end");
   symbols::symbol* tls_data_size = symbols.find_global("_TLS_Data_size");
-- 
1.8.3.1

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

[PATCH v2 5/5] ReportsText.cc: Restore ostream format

2021-07-20 Thread Ryan Long 
CID 1505940: Not restoring ostream format

Save format of stream before changing it, and change it back before returning.

Closes #4472
---
 tester/covoar/ReportsText.cc | 5 +
 1 file changed, 5 insertions(+)

diff --git a/tester/covoar/ReportsText.cc b/tester/covoar/ReportsText.cc
index 146fc35..c4a5dbc 100644
--- a/tester/covoar/ReportsText.cc
+++ b/tester/covoar/ReportsText.cc
@@ -10,6 +10,9 @@
 #include "Explanations.h"
 #include "ObjdumpProcessor.h"
 
+#include 
+
+typedef rtems::utils::ostream_guard ostream_guard;
 
 namespace Coverage {
 
@@ -145,6 +148,8 @@ bool ReportsText::PutCoverageLine(
 {
   const Coverage::Explanation* explanation;
 
+  ostream_guard oldState( report );
+
   report << "" << std::endl
  << "Index: " << range.id << std::endl
  << "Symbol   : " << symbolName
-- 
1.8.3.1

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

[PATCH v2 4/5] ReportsHtml.cc: Restore ostream format

2021-07-20 Thread Ryan Long 
CID 1505939: Not restoring ofstream format

Save format of stream before changing it, and change it back before returning.

Closes #4471
---
 tester/covoar/ReportsHtml.cc | 5 +
 1 file changed, 5 insertions(+)

diff --git a/tester/covoar/ReportsHtml.cc b/tester/covoar/ReportsHtml.cc
index 53ee0c1..e276732 100644
--- a/tester/covoar/ReportsHtml.cc
+++ b/tester/covoar/ReportsHtml.cc
@@ -6,6 +6,7 @@
 #include 
 
 #include 
+#include 
 
 #include "ReportsHtml.h"
 #include "app_common.h"
@@ -13,6 +14,8 @@
 #include "DesiredSymbols.h"
 #include "ObjdumpProcessor.h"
 
+typedef rtems::utils::ostream_guard ostream_guard;
+
 #if 0
 #define TABLE_HEADER_CLASS \
   " table-autopage:10 table-page-number:pagenum table-page-count:pages "
@@ -724,6 +727,7 @@ namespace Coverage {
 const SymbolInformation& symbolInfo
   )
   {
+ostream_guard old_state( report );
 
 // Mark the background color different for odd and even lines.
 if ( ( count % 2 ) != 0 ) {
@@ -818,6 +822,7 @@ namespace Coverage {
 }
 
 report << "" << std::endl;
+
 return true;
   }
 
-- 
1.8.3.1

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

[PATCH v2 3/5] CoverageMapBase.cc: Restore ostream format

2021-07-20 Thread Ryan Long 
CID 1503022: Not restoring ostream format

Save format of stream before changing it, and change it back before returning.

Closes #4470
---
 tester/covoar/CoverageMapBase.cc | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/tester/covoar/CoverageMapBase.cc b/tester/covoar/CoverageMapBase.cc
index f0b5890..4de9307 100644
--- a/tester/covoar/CoverageMapBase.cc
+++ b/tester/covoar/CoverageMapBase.cc
@@ -12,9 +12,12 @@
 #include 
 
 #include 
+#include 
 
 #include "CoverageMapBase.h"
 
+typedef rtems::utils::ostream_guard ostream_guard;
+
 namespace Coverage {
 
   AddressInfo::AddressInfo ()
@@ -75,6 +78,8 @@ namespace Coverage {
 
   void AddressRange::dump (std::ostream& out, bool show_slots) const
   {
+ostream_guard old_state( out );
+
 out << std::hex << std::setfill('0')
 << "Address range: low = " << std::setw(8) << lowAddress
 << " high = " << std::setw(8) << highAddress
@@ -99,6 +104,7 @@ namespace Coverage {
 << std::endl;
   }
 }
+
   }
 
   CoverageMapBase::CoverageMapBase(
-- 
1.8.3.1

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

[PATCH v2 0/5] Fix ostream format Coverity issues

2021-07-20 Thread Ryan Long 
Hi,

This patchset has Chris's recommended fix for these issues.

Thanks,
Ryan

Ryan Long (5):
  rtems-utils.h: Create ostream_guard
  rtems-exeinfo.cpp: Restore ostream format
  CoverageMapBase.cc: Restore ostream format
  ReportsHtml.cc: Restore ostream format
  ReportsText.cc: Restore ostream format

 linkers/rtems-exeinfo.cpp|  7 +++
 rtemstoolkit/rtems-utils.h   | 18 ++
 tester/covoar/CoverageMapBase.cc |  6 ++
 tester/covoar/ReportsHtml.cc |  5 +
 tester/covoar/ReportsText.cc |  5 +
 5 files changed, 41 insertions(+)

-- 
1.8.3.1

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

[PATCH v2 1/5] rtems-utils.h: Create ostream_guard

2021-07-20 Thread Ryan Long 
---
 rtemstoolkit/rtems-utils.h | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/rtemstoolkit/rtems-utils.h b/rtemstoolkit/rtems-utils.h
index 4ce9c68..c4a262e 100644
--- a/rtemstoolkit/rtems-utils.h
+++ b/rtemstoolkit/rtems-utils.h
@@ -47,6 +47,24 @@ namespace rtems
boolreal = false,
size_t  line_length = 16,
uint32_toffset = 0);
+
+/*
+ * Save and restore the output stream's settings.
+ */
+struct ostream_guard {
+  std::ostream&   o;
+  std::ios_base::fmtflags flags;
+
+  ostream_guard ( std::ostream& o_ ) : o( o_ ), flags( o_.flags() )
+  {
+  }
+
+  ~ostream_guard ()
+  {
+  o.flags( flags );
+  }
+};
+
   }
 }
 
-- 
1.8.3.1

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

[PATCH rtems] bsps/imxrt: Add attribution in file headers

2021-07-20 Thread Christian Mauderer 
Onto Innovations Incorporated originally sponsored the development of
this BSP. This patch adds the attribution for it.

The patch also fixes an old license header in bspstarthooks.c that was
accidentally copied into that file.
---
 bsps/arm/imxrt/console/console.c  |  1 +
 bsps/arm/imxrt/dts/imxrt1050-evkb.dts |  2 ++
 bsps/arm/imxrt/i2c/imxrt-lpi2c.c  |  1 +
 bsps/arm/imxrt/include/bsp.h  |  1 +
 bsps/arm/imxrt/include/bsp/flash-headers.h|  1 +
 bsps/arm/imxrt/include/bsp/irq.h  |  1 +
 bsps/arm/imxrt/include/fsl_device_registers.h |  1 +
 .../imxrt/include/imxrt/imxrt1050-pinfunc.h   |  1 +
 bsps/arm/imxrt/include/imxrt/imxrt1050.dtsi   |  2 ++
 bsps/arm/imxrt/include/imxrt/lpspi.h  |  1 +
 bsps/arm/imxrt/include/imxrt/memory.h |  1 +
 bsps/arm/imxrt/include/imxrt/mpu-config.h |  1 +
 bsps/arm/imxrt/spi/imxrt-lpspi.c  |  1 +
 bsps/arm/imxrt/start/bspstart.c   |  1 +
 bsps/arm/imxrt/start/bspstarthooks.c  | 32 +--
 bsps/arm/imxrt/start/clock-arm-pll-config.c   |  1 +
 bsps/arm/imxrt/start/flash-boot-data.c|  1 +
 bsps/arm/imxrt/start/flash-flexspi-config.c   |  1 +
 bsps/arm/imxrt/start/flash-ivt.c  |  1 +
 bsps/arm/imxrt/start/imxrt-ffec-init.c|  1 +
 bsps/arm/imxrt/start/mpu-config.c |  1 +
 21 files changed, 45 insertions(+), 9 deletions(-)

diff --git a/bsps/arm/imxrt/console/console.c b/bsps/arm/imxrt/console/console.c
index 05320f2c4c..ab278b9d22 100644
--- a/bsps/arm/imxrt/console/console.c
+++ b/bsps/arm/imxrt/console/console.c
@@ -1,6 +1,7 @@
 /* SPDX-License-Identifier: BSD-2-Clause */
 
 /*
+ * i.MX RT port sponsored by Onto Innovation Incorporated
  * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
  *
  * Redistribution and use in source and binary forms, with or without
diff --git a/bsps/arm/imxrt/dts/imxrt1050-evkb.dts 
b/bsps/arm/imxrt/dts/imxrt1050-evkb.dts
index 9310371428..bf24762d86 100644
--- a/bsps/arm/imxrt/dts/imxrt1050-evkb.dts
+++ b/bsps/arm/imxrt/dts/imxrt1050-evkb.dts
@@ -1,7 +1,9 @@
 /* SPDX-License-Identifier: BSD-2-Clause */
 
 /*
+ * i.MX RT port sponsored by Onto Innovation Incorporated
  * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+ *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
  * are met:
diff --git a/bsps/arm/imxrt/i2c/imxrt-lpi2c.c b/bsps/arm/imxrt/i2c/imxrt-lpi2c.c
index 783c6e18e6..0873499a24 100644
--- a/bsps/arm/imxrt/i2c/imxrt-lpi2c.c
+++ b/bsps/arm/imxrt/i2c/imxrt-lpi2c.c
@@ -1,6 +1,7 @@
 /* SPDX-License-Identifier: BSD-2-Clause */
 
 /*
+ * i.MX RT port sponsored by Onto Innovation Incorporated
  * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
  *
  * Redistribution and use in source and binary forms, with or without
diff --git a/bsps/arm/imxrt/include/bsp.h b/bsps/arm/imxrt/include/bsp.h
index f93c28aee0..78fa6a42e1 100644
--- a/bsps/arm/imxrt/include/bsp.h
+++ b/bsps/arm/imxrt/include/bsp.h
@@ -7,6 +7,7 @@
  */
 
 /*
+ * i.MX RT port sponsored by Onto Innovation Incorporated
  * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
  *
  * Redistribution and use in source and binary forms, with or without
diff --git a/bsps/arm/imxrt/include/bsp/flash-headers.h 
b/bsps/arm/imxrt/include/bsp/flash-headers.h
index 6575b1c21b..a50ae68d58 100644
--- a/bsps/arm/imxrt/include/bsp/flash-headers.h
+++ b/bsps/arm/imxrt/include/bsp/flash-headers.h
@@ -9,6 +9,7 @@
  */
 
 /*
+ * i.MX RT port sponsored by Onto Innovation Incorporated
  * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
  *
  * Redistribution and use in source and binary forms, with or without
diff --git a/bsps/arm/imxrt/include/bsp/irq.h b/bsps/arm/imxrt/include/bsp/irq.h
index 6fcd055f03..52de519471 100644
--- a/bsps/arm/imxrt/include/bsp/irq.h
+++ b/bsps/arm/imxrt/include/bsp/irq.h
@@ -7,6 +7,7 @@
  */
 
 /*
+ * i.MX RT port sponsored by Onto Innovation Incorporated
  * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
  *
  * Redistribution and use in source and binary forms, with or without
diff --git a/bsps/arm/imxrt/include/fsl_device_registers.h 
b/bsps/arm/imxrt/include/fsl_device_registers.h
index 00c3fc7036..6a57397789 100644
--- a/bsps/arm/imxrt/include/fsl_device_registers.h
+++ b/bsps/arm/imxrt/include/fsl_device_registers.h
@@ -9,6 +9,7 @@
  */
 
 /*
+ * i.MX RT port sponsored by Onto Innovation Incorporated
  * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
  *
  * Redistribution and use in source and binary forms, with or without
diff --git a/bsps/arm/imxrt/include/imxrt/imxrt1050-pinfunc.h 
b/bsps/arm/imxrt/include/imxrt/imxrt1050-pinfunc.h
index 16ebfae5b3..439b0c5384 100644
--- a/bsps/arm/imxrt/include/imxrt/imxrt1050-pinfunc.h
+++

AW: Building a library for use with RTEMS via CMake

2021-07-20 Thread Andre.Nahrwold 
Hey guys,

that was so far very helpful in understanding the problem in more depth.
Putting in the right flags at least reduced the linker errors by nearly 99% or 
so, Thanks.
Maybe I am on the right path now and just need to tweak it a bit to make it 
work.

The rtems-cmake repository looks also very promising to me, I surely have to 
dig deeper into the processes going on there.
Problem is that I should (ideally) not change the CMakeLists.txt from the 
library so it stays independent.
Do you have any thoughts on that Robin?
Do you think wrapping the library CMakeLists.txt in another one which then uses 
the repository might work?

But I realized that I have missed some information while explaining this issue.
The RTEMS application itself is built with SCons and therefore the desired 
build environment (flags and so forth) is already defined within a python 
dictionary.
Now we need to somehow build the library via CMake using the established 
environment, install and link against it via SCons.
Do you have worked with something  like this before?

Best regards
André

Von: devel  Im Auftrag von Robin Müller
Gesendet: Dienstag, 20. Juli 2021 11:46
An: Michael Davidsaver ; devel@rtems.org
Betreff: Re: Building a library for use with RTEMS via CMake

I managed to compile our project with CMake, using this repository: 
https://github.com/spacefisch/rtems-cmake
It uses the pkg-config files to set up the cross compiler given the BSP and 
RTEMS prefix information.

Maybe this can help you

Kind Regards
Robin

On Tue, 20 Jul 2021 at 00:50, Michael Davidsaver 
mailto:mdavidsa...@gmail.com>> wrote:
On 7/19/21 6:17 AM, andre.nahrw...@dlr.de wrote:
> Hello,
>
> I have built RTEMS 5 and its tools for the Xilinx Zynq Zedboard and installed 
> the BSP and tools at a certain position on my machine.
> The tools are added to the PATH variable and RTEMS_BSPS is also available in 
> the environment.
>
> Now we need to build a library for the use with RTEMS via CMake.
> For this we wanted to use the toolchain files.
> Does anybody know how to correctly setup such a toolchain file using the 
> RTEMS compiler?
>
> We managed to get a toolchain file working which at least built the library.
> But when we wanted to link to this library during compilation of a RTEMS 
> application we got a bunch of errors due to undefined references to standard 
> library functions.
> Does anybody has a clue where this might origin from?

As it happens, I went through this exercise recently with libevent.
The main obstacle for me was that the CMake try_compile() command
actually tries to link an executable.  With RTEMS 5 this can't be
done generically without also adding '-lrtemsdefaultconfig'.

eg.

> string(APPEND CMAKE_EXE_LINKER_FLAGS_INIT " -lrtemsdefaultconfig")

Also, if you use networking you might want to add.

> set(CMAKE_REQUIRED_LIBRARIES "-lbsd")

for eg. CheckFunctionExists.cmake to work correctly.


The (fairly complex) result of this all can be found here:

https://github.com/mdavidsaver/pvxs/tree/master/bundle

The essential parts are:

- cmake/RTEMS.cmake@

Template toolchain file.  (expand using definitions from RTEMS makefiles)

- cmake/Platform/

Hooks into the CMake startup process.  The exact interplay between
Platform/ and toolchain file is... quite involved.  Also not well
documented.  The best I've found is:

https://github.com/Kitware/CMake/blob/f86d8009c6a4482c81221114a2b04b375564cc94/Source/cmGlobalGenerator.cxx#L461-L504



> Building a RTEMS application which does not use the own library works fine.
>
> Our toolchain file looks like this:
>
> # CMake toolchain file for ARM
> # The compiler is based on
> # The RTEMS_BSPS environment variable is expected to be set.
> set(ARCH arm)
> set(CMAKE_SYSTEM_NAME RTEMS5)
>
> set(CMAKE_CXX_FLAGS "" CACHE STRING "ARM RTEMS5 gcc additional compiler 
> flags" FORCE)
>
> set(RTEMS_TOOLS_PATH $ENV{RTEMS_BSPS}/../../tools/bin)
>
> set(CMAKE_C_COMPILER ${RTEMS_TOOLS_PATH}/arm-rtems5-gcc CACHE PATH "ARM 
> RTEMS5 gcc" FORCE)
> set(CMAKE_CXX_COMPILER ${RTEMS_TOOLS_PATH}/arm-rtems5-gcc CACHE PATH "ARM 
> RTEMS5 gcc" FORCE)
> set(CMAKE_CXX_COMPILER_AR ${RTEMS_TOOLS_PATH}/arm-rtems5-gcc-ar CACHE PATH 
> "ARM RTEMS5 ar" FORCE)
> set(CMAKE_CXX_COMPILER_RANLIB ${RTEMS_TOOLS_PATH}/arm-rtems5-gcc-ranlib CACHE 
> PATH "ARM RTEMS5 gcc ranlib" FORCE)
> set(CMAKE_RANLIB ${RTEMS_TOOLS_PATH}/arm-rtems5-ranlib CACHE PATH "ARM RTEMS5 
> ranlib" FORCE)
> set(CMAKE_READELF ${RTEMS_TOOLS_PATH}/arm-rtems5-readelf CACHE PATH "ARM 
> RTEMS5 readelf" FORCE)
> set(CMAKE_STRIP ${RTEMS_TOOLS_PATH}/arm-rtems5-strip CACHE PATH "ARM RTEMS5 
> strip" FORCE)
> set(CMAKE_ADDR2LINE ${RTEMS_TOOLS_PATH}/arm-rtems5-addr2line CACHE PATH "ARM 
> RTEMS5 addr2line" FORCE)
> set(CMAKE_LINKER ${RTEMS_TOOLS_PATH}/arm-rtems5-ld CACHE PATH "ARM RTEMS5 ld" 
> FORCE)
> set(CMAKE_NM ${RTEMS_TOOLS_PATH}/arm-rtems5-nm CACHE PATH "ARM RTEMS5 nm" 
> FORCE)
> set(CMAKE_OBJCOPY

Re: [PATCH] Fixes for TMS570 BSP

2021-07-20 Thread Sebastian Huber 

On 16/07/2021 13:59, Robin Müller wrote:

  I think this patch was forgotten. Pushing it up :-)


Thanks, I checked it in.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

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

Re: [PATCH] STM32H7 ethernet pin corrections

2021-07-20 Thread Sebastian Huber 

On 16/07/2021 14:32, Robin Mueller wrote:

These patches were submitted a few months ago, but it was found out
that the default-by-family: [] were missing in the GPIO .yml lines.
This was fixed in this patch.

This patch accounts for different pins for the ETH peripheral
on STM32H7 devices. For example, the Nucleo H743ZI has slightly
different pins than other STM32H7 boards.


Thanks, I checked it in.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

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

Re: [PATCH] build: Add the BSP family to the enable set

2021-07-20 Thread Sebastian Huber 

On 15/07/2021 08:19, Sebastian Huber wrote:

This makes it possible to use the BSP family in expressions of the enabled-by
attribute.
---
  wscript | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/wscript b/wscript
index 487951fdba..1331ae149e 100755
--- a/wscript
+++ b/wscript
@@ -1387,7 +1387,12 @@ def configure_variant(conf, cp, bsp_map, path_list, 
top_group, variant):
  
  # For the enabled-by evaluation we have to use the base BSP defined by the

  # build specification and not the BSP name provided by the user.
-conf.env["ENABLE"] = [get_compiler(conf, cp, variant), arch, arch_bsp]
+conf.env["ENABLE"] = [
+get_compiler(conf, cp, variant),
+arch,
+arch_family,
+arch_bsp,
+]
  
  conf.env["TOP"] = conf.path.abspath()

  conf.env["TOPGROUP"] = top_group


This actually broke some riscv BSPs which do not support SMP. We have

cat spec/build/cpukit/optsmp.yml
SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
actions:
- get-boolean: null
- env-enable: null
- define-condition: null
build-type: option
copyrights:
- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
default: false
default-by-family: []
default-by-variant: []
description: |
  Enable the Symmetric Multiprocessing (SMP) support
enabled-by:
- arm/altcycv_devkit
- arm/fvp_cortex_r52
- arm/imx7
- arm/raspberrypi2
- arm/realview_pbx_a9_qemu
- arm/xilinx_zynq_a9_qemu
- arm/xilinx_zynqmp_ultra96
- arm/xilinx_zynq_zc702
- arm/xilinx_zynq_zc706
- arm/xilinx_zynq_zedboard
- powerpc/qoriq_e500
- powerpc/qoriq_e6500_32
- powerpc/qoriq_e6500_64
- riscv/griscv
- riscv/grv32imac
- riscv/grv32imafdc
- riscv/rv32iac
- riscv/rv32imac
- riscv/rv32imafc
- riscv/rv32imafd
- riscv/rv32imafdc
- riscv/rv64imac
- riscv/rv64imac_medany
- riscv/rv64imafd
- riscv/rv64imafdc
- riscv/rv64imafdc_medany
- riscv/rv64imafd_medany
- sparc/erc32
- sparc/gr712rc
- sparc/gr740
- sparc/leon3
links: []
name: RTEMS_SMP
type: build

The problem is that one BSP which supports SMP "riscv/griscv" is 
identical to the family "riscv/griscv" which contains BSPs which do not 
support SMP ("riscv/grv32i" and riscv/grv32im").


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

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

Re: Building a library for use with RTEMS via CMake

2021-07-20 Thread Robin Müller 
I managed to compile our project with CMake, using this repository:
https://github.com/spacefisch/rtems-cmake
It uses the pkg-config files to set up the cross compiler given the BSP and
RTEMS prefix information.

Maybe this can help you

Kind Regards
Robin

On Tue, 20 Jul 2021 at 00:50, Michael Davidsaver 
wrote:

> On 7/19/21 6:17 AM, andre.nahrw...@dlr.de wrote:
> > Hello,
> >
> > I have built RTEMS 5 and its tools for the Xilinx Zynq Zedboard and
> installed the BSP and tools at a certain position on my machine.
> > The tools are added to the PATH variable and RTEMS_BSPS is also
> available in the environment.
> >
> > Now we need to build a library for the use with RTEMS via CMake.
> > For this we wanted to use the toolchain files.
> > Does anybody know how to correctly setup such a toolchain file using the
> RTEMS compiler?
> >
> > We managed to get a toolchain file working which at least built the
> library.
> > But when we wanted to link to this library during compilation of a RTEMS
> application we got a bunch of errors due to undefined references to
> standard library functions.
> > Does anybody has a clue where this might origin from?
>
> As it happens, I went through this exercise recently with libevent.
> The main obstacle for me was that the CMake try_compile() command
> actually tries to link an executable.  With RTEMS 5 this can't be
> done generically without also adding '-lrtemsdefaultconfig'.
>
> eg.
>
> > string(APPEND CMAKE_EXE_LINKER_FLAGS_INIT " -lrtemsdefaultconfig")
>
> Also, if you use networking you might want to add.
>
> > set(CMAKE_REQUIRED_LIBRARIES "-lbsd")
>
> for eg. CheckFunctionExists.cmake to work correctly.
>
>
> The (fairly complex) result of this all can be found here:
>
> https://github.com/mdavidsaver/pvxs/tree/master/bundle
>
> The essential parts are:
>
> - cmake/RTEMS.cmake@
>
> Template toolchain file.  (expand using definitions from RTEMS makefiles)
>
> - cmake/Platform/
>
> Hooks into the CMake startup process.  The exact interplay between
> Platform/ and toolchain file is... quite involved.  Also not well
> documented.  The best I've found is:
>
>
> https://github.com/Kitware/CMake/blob/f86d8009c6a4482c81221114a2b04b375564cc94/Source/cmGlobalGenerator.cxx#L461-L504
>
>
>
> > Building a RTEMS application which does not use the own library works
> fine.
> >
> > Our toolchain file looks like this:
> >
> > # CMake toolchain file for ARM
> > # The compiler is based on
> > # The RTEMS_BSPS environment variable is expected to be set.
> > set(ARCH arm)
> > set(CMAKE_SYSTEM_NAME RTEMS5)
> >
> > set(CMAKE_CXX_FLAGS "" CACHE STRING "ARM RTEMS5 gcc additional compiler
> flags" FORCE)
> >
> > set(RTEMS_TOOLS_PATH $ENV{RTEMS_BSPS}/../../tools/bin)
> >
> > set(CMAKE_C_COMPILER ${RTEMS_TOOLS_PATH}/arm-rtems5-gcc CACHE PATH "ARM
> RTEMS5 gcc" FORCE)
> > set(CMAKE_CXX_COMPILER ${RTEMS_TOOLS_PATH}/arm-rtems5-gcc CACHE PATH
> "ARM RTEMS5 gcc" FORCE)
> > set(CMAKE_CXX_COMPILER_AR ${RTEMS_TOOLS_PATH}/arm-rtems5-gcc-ar CACHE
> PATH "ARM RTEMS5 ar" FORCE)
> > set(CMAKE_CXX_COMPILER_RANLIB ${RTEMS_TOOLS_PATH}/arm-rtems5-gcc-ranlib
> CACHE PATH "ARM RTEMS5 gcc ranlib" FORCE)
> > set(CMAKE_RANLIB ${RTEMS_TOOLS_PATH}/arm-rtems5-ranlib CACHE PATH "ARM
> RTEMS5 ranlib" FORCE)
> > set(CMAKE_READELF ${RTEMS_TOOLS_PATH}/arm-rtems5-readelf CACHE PATH "ARM
> RTEMS5 readelf" FORCE)
> > set(CMAKE_STRIP ${RTEMS_TOOLS_PATH}/arm-rtems5-strip CACHE PATH "ARM
> RTEMS5 strip" FORCE)
> > set(CMAKE_ADDR2LINE ${RTEMS_TOOLS_PATH}/arm-rtems5-addr2line CACHE PATH
> "ARM RTEMS5 addr2line" FORCE)
> > set(CMAKE_LINKER ${RTEMS_TOOLS_PATH}/arm-rtems5-ld CACHE PATH "ARM
> RTEMS5 ld" FORCE)
> > set(CMAKE_NM ${RTEMS_TOOLS_PATH}/arm-rtems5-nm CACHE PATH "ARM RTEMS5
> nm" FORCE)
> > set(CMAKE_OBJCOPY ${RTEMS_TOOLS_PATH}/arm-rtems5-objcopy CACHE PATH "ARM
> RTEMS5 objcopy" FORCE)
> > set(CMAKE_OBJDUMP ${RTEMS_TOOLS_PATH}/arm-rtems5-objdump CACHE PATH "ARM
> RTEMS5 objdump" FORCE)
> >
> > set(CMAKE_TARGET_CONFIG_POSTFIX .rtems5_gcc_arm)
> >
> > Best regards
> > Andre Nahrwold
> > --
> > Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR)
> > German Aerospace Center
> > Institute for Software Technolog | SRV-OSS BS | Lilienthalpl. 7 | 38108
> Braunschweig | Geb. 112C Raum 001
> > M.Sc. Andre Nahrwold | Telephone +49 531 295-3834 |
> andre.nahrw...@dlr.de
> > DLR.de
> >
> > ___
> > users mailing list
> > us...@rtems.org
> > http://lists.rtems.org/mailman/listinfo/users
> >
>
> ___
> users mailing list
> us...@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel