Re: How can I check if a function exists in waf?

2019-02-01 Thread Chris Johns 
On 1/2/19 8:19 pm, Sebastian Huber wrote:
> 
> So, there is no standard compile and link test for functions? If I use this
> 
>     conf.check_cc(fragment = 'int main(void) { strnlen("", 0); return 0; }',
>   header_name="string.h", features = 'c', mandatory = False)
> 
> waf outputs
> 
> Checking for header string.h  : yes
> 
> I don't want to test for string.h, I want to test for strnlen(). In config.log
> we have:
> 
> -
> Checking for header string.h
> ==>
> int main(void) { strnlen("", 0); return 0; }
> <==
> [1/1] Compiling 
> build/.conf_check_6da1e91772980301eb2528a1d150a7ab/test.c
> 
> ['/usr/bin/gcc', '../test.c', '-c',
> '-o/scratch/git-rtems-tools/build/.conf_check_6da1e91772980301eb2528a1d150a7ab/testbuild/test.c.1.o']
> 
> err: ../test.c: In function ‘main’:
> ../test.c:1:18: warning: implicit declaration of function ‘strnlen’
> [-Wimplicit-function-declaration]
>  int main(void) { strnlen("", 0); return 0; }
>   ^~~
> 
> yes
> -
> 
> So, this test uses already quite some code and still is basically useless.

You have a powerful language available. I would create a function to handle
repeated checks, for example:

https://git.rtems.org/chrisj/rtems_waf.git/tree/rtems.py?h=libbsd-libdl#n270

I think having the ability to perform checks for an RTEMS application highlights
the power available.

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

Re: RISC-V double float alignment

2019-02-01 Thread Joel Sherrill 
On Fri, Feb 1, 2019, 11:38 AM Hesham Almatary  On Fri, 1 Feb 2019 at 15:08, Jiri Gaisler  wrote:
> >
> > Hello,
> >
> > As far as I understand, RISC-V does not require any particular alignment
> > of data structures in memory. Nevertheless, the compiler automatically
> > aligns data structures on their natural sizes, i.e. ints are aligned on
> > 4-byte and doubles on 8-bytes boundaries. sis-riscv with support for
> > doubles (extension D) checks that load and store double are properly
> > aligned on 8-byte boundaries. This works fine for all compiler-generated
> > code, (e.g. paranoia) but fails for spcontext01, where the context save
> > function in riscv-exception-handler.S tries to save 64-bit floating
> > point registers on a non-aligned stack address.
> >
> > Is this an oversight in the code, or does the hardware (and simulators)
> > have to support unaligned accesses?
> >
> Spike can be built to support either aligned or unaligned accesses. This
> includes floating points and integers. It's not in the spec that a RISC-V
> implementation has to support it or not (it's up to the platform),
> but if it doesn't, it should trigger an unaligned access trap and
> should be handled.
>

Then we should ensure proper alignment since we NEVER want an unaligned
exception on any architecture if it is avoidable. No point in taking the
likely performance hit or exception.

>
> That said, I am not sure whether the intention of the RISC-V FPU
> implementation in RTEMS is assuming everything will be aligned
> (in which case some alignment checks should be added) or not.
>

The intention is to avoid unaligned exceptions so this has to be accounted
for.

>
> I had another a look at the RISC-V Context_Control struct. I assume this
> only
> happens on rv32 with D extension?
>
> > Jiri.
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RISC-V double float alignment

2019-02-01 Thread Hesham Almatary 
On Fri, 1 Feb 2019 at 15:08, Jiri Gaisler  wrote:
>
> Hello,
>
> As far as I understand, RISC-V does not require any particular alignment
> of data structures in memory. Nevertheless, the compiler automatically
> aligns data structures on their natural sizes, i.e. ints are aligned on
> 4-byte and doubles on 8-bytes boundaries. sis-riscv with support for
> doubles (extension D) checks that load and store double are properly
> aligned on 8-byte boundaries. This works fine for all compiler-generated
> code, (e.g. paranoia) but fails for spcontext01, where the context save
> function in riscv-exception-handler.S tries to save 64-bit floating
> point registers on a non-aligned stack address.
>
> Is this an oversight in the code, or does the hardware (and simulators)
> have to support unaligned accesses?
>
Spike can be built to support either aligned or unaligned accesses. This
includes floating points and integers. It's not in the spec that a RISC-V
implementation has to support it or not (it's up to the platform),
but if it doesn't, it should trigger an unaligned access trap and
should be handled.

That said, I am not sure whether the intention of the RISC-V FPU
implementation in RTEMS is assuming everything will be aligned
(in which case some alignment checks should be added) or not.

I had another a look at the RISC-V Context_Control struct. I assume this only
happens on rv32 with D extension?

> Jiri.
>
> ___
> 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: RISC-V double float alignment

2019-02-01 Thread emanuel stiebler 
On 2019-02-01 10:08, Jiri Gaisler wrote:
> Hello,
> 
> As far as I understand, RISC-V does not require any particular alignment
> of data structures in memory. [ ... ]

RISC-V explicitly states somewhere in the manuals, (?) that it supports
unaligned access to memory, but it could be emulated in software, and
accesses should/will be fastest on aligned addresses 

Actually, writing it I found it on wiki & the manual
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RISC-V double float alignment

2019-02-01 Thread Jiri Gaisler 
Hello,

As far as I understand, RISC-V does not require any particular alignment
of data structures in memory. Nevertheless, the compiler automatically
aligns data structures on their natural sizes, i.e. ints are aligned on
4-byte and doubles on 8-bytes boundaries. sis-riscv with support for
doubles (extension D) checks that load and store double are properly
aligned on 8-byte boundaries. This works fine for all compiler-generated
code, (e.g. paranoia) but fails for spcontext01, where the context save
function in riscv-exception-handler.S tries to save 64-bit floating
point registers on a non-aligned stack address.

Is this an oversight in the code, or does the hardware (and simulators)
have to support unaligned accesses?

Jiri.

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

Re: [PATCH] Coverage : Add coverage support for RISCV

2019-02-01 Thread Vijay Kumar Banerjee 
On Fri, 1 Feb 2019 at 20:23, Vijay Kumar Banerjee 
wrote:

> ---
>  tester/covoar/TargetFactory.cc   |  2 +
>  tester/covoar/Target_riscv.cc| 82 
>  tester/covoar/Target_riscv.h | 98 
>  tester/covoar/wscript|  3 +-
>  tester/rtems/testing/bsps/griscv-sis-cov.ini | 40 
>  5 files changed, 224 insertions(+), 1 deletion(-)
>  create mode 100644 tester/covoar/Target_riscv.cc
>  create mode 100644 tester/covoar/Target_riscv.h
>  create mode 100644 tester/rtems/testing/bsps/griscv-sis-cov.ini
>
> diff --git a/tester/covoar/TargetFactory.cc
> b/tester/covoar/TargetFactory.cc
> index fc9c30b..50e92a6 100644
> --- a/tester/covoar/TargetFactory.cc
> +++ b/tester/covoar/TargetFactory.cc
> @@ -23,6 +23,7 @@
>  #include "Target_powerpc.h"
>  #include "Target_lm32.h"
>  #include "Target_sparc.h"
> +#include "Target_riscv.h"
>
>  namespace Target {
>
> @@ -56,6 +57,7 @@ namespace Target {
>  { "m68k",Target_m68k_Constructor },
>  { "powerpc", Target_powerpc_Constructor },
>  { "sparc",   Target_sparc_Constructor },
> +   { "riscv",   Target_riscv_Constructor },
>  { "TBD", NULL },
>};
>
> diff --git a/tester/covoar/Target_riscv.cc b/tester/covoar/Target_riscv.cc
> new file mode 100644
> index 000..3b2e221
> --- /dev/null
> +++ b/tester/covoar/Target_riscv.cc
> @@ -0,0 +1,82 @@
> +/*
> + * RTEMS Tools Project (http://www.rtems.org/)
> + * Copyright 2019 Vijay K. Banerjee (vijaykumar9...@gmail.com)
> + * All rights reserved.
> + *
> + * This file is part of the RTEMS Tools package in 'rtems-tools'.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions are
> met:
> + *
> + * 1. Redistributions of source code must retain the above copyright
> notice,
> + * this list of conditions and the following disclaimer.
> + *
> + * 2. Redistributions in binary form must reproduce the above copyright
> notice,
> + * this list of conditions and the following disclaimer in the
> documentation
> + * and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> "AS IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
> THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS
> BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
> THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +/*! @file Target_riscv.cc
> + *  @brief Target_riscv Implementation
> + */
> +
> +#include "Target_riscv.h"
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +namespace Target {
> +
> +  Target_riscv::Target_riscv( std::string targetName ):
> +TargetBase( targetName )
> +  {
> +branchInstructions.push_back("beqz");
> +branchInstructions.push_back("bnez");
> +branchInstructions.push_back("blez");
> +branchInstructions.push_back("bgez");
> +branchInstructions.push_back("bltz");
> +branchInstructions.push_back("bgt");
> +branchInstructions.push_back("ble");
> +branchInstructions.push_back("bgtu");
> +branchInstructions.push_back("bleu");
> +
>
Do the instructions look alright ? what did I miss ?

> +branchInstructions.sort();
> +   }
> +
> +  Target_riscv::~Target_riscv()
> +  {
> +  }
> +
> +  bool Target_riscv::isNopLine(
> +const char* const line,
> +int&  size
> +)
> +  {
> +if (!strcmp( [strlen(line)-3], "nop")){
> +size = 4;
> +return true;
> +}
>>
>>
>> -- vijay
>
> +
> +  return false;
> +  }
> +
> +  TargetBase *Target_riscv_Constructor(
> +std::stringtargetName
> +)
> +{
> +  return new Target_riscv( targetName );
> +}
> +}
> diff --git a/tester/covoar/Target_riscv.h b/tester/covoar/Target_riscv.h
> new file mode 100644
> index 000..112276c
> --- /dev/null
> +++ b/tester/covoar/Target_riscv.h
> @@ -0,0 +1,98 @@
> +/*
> + * RTEMS Tools Project (http://www.rtems.org/)
> + * Copyright 2019 Vijay K. Banerjee (vijaykumar9...@gmail.com)
> + * All rights reserved.
> + *
> + * This file is part of the RTEMS Tools package in 'rtems-tools'.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions are
> met:
> + *
> + * 1. Redistributions of source code must retain the above copyright
>

[PATCH] Coverage : Add coverage support for RISCV

2019-02-01 Thread Vijay Kumar Banerjee 
---
 tester/covoar/TargetFactory.cc   |  2 +
 tester/covoar/Target_riscv.cc| 82 
 tester/covoar/Target_riscv.h | 98 
 tester/covoar/wscript|  3 +-
 tester/rtems/testing/bsps/griscv-sis-cov.ini | 40 
 5 files changed, 224 insertions(+), 1 deletion(-)
 create mode 100644 tester/covoar/Target_riscv.cc
 create mode 100644 tester/covoar/Target_riscv.h
 create mode 100644 tester/rtems/testing/bsps/griscv-sis-cov.ini

diff --git a/tester/covoar/TargetFactory.cc b/tester/covoar/TargetFactory.cc
index fc9c30b..50e92a6 100644
--- a/tester/covoar/TargetFactory.cc
+++ b/tester/covoar/TargetFactory.cc
@@ -23,6 +23,7 @@
 #include "Target_powerpc.h"
 #include "Target_lm32.h"
 #include "Target_sparc.h"
+#include "Target_riscv.h"
 
 namespace Target {
 
@@ -56,6 +57,7 @@ namespace Target {
 { "m68k",Target_m68k_Constructor },
 { "powerpc", Target_powerpc_Constructor },
 { "sparc",   Target_sparc_Constructor },
+   { "riscv",   Target_riscv_Constructor },
 { "TBD", NULL },
   };
 
diff --git a/tester/covoar/Target_riscv.cc b/tester/covoar/Target_riscv.cc
new file mode 100644
index 000..3b2e221
--- /dev/null
+++ b/tester/covoar/Target_riscv.cc
@@ -0,0 +1,82 @@
+/*
+ * RTEMS Tools Project (http://www.rtems.org/)
+ * Copyright 2019 Vijay K. Banerjee (vijaykumar9...@gmail.com)
+ * All rights reserved.
+ *
+ * This file is part of the RTEMS Tools package in 'rtems-tools'.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright notice,
+ * this list of conditions and the following disclaimer.
+ *
+ * 2. Redistributions in binary form must reproduce the above copyright notice,
+ * this list of conditions and the following disclaimer in the documentation
+ * and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/*! @file Target_riscv.cc
+ *  @brief Target_riscv Implementation
+ */
+
+#include "Target_riscv.h"
+#include 
+#include 
+#include 
+#include 
+
+namespace Target {
+
+  Target_riscv::Target_riscv( std::string targetName ):
+TargetBase( targetName )
+  {
+branchInstructions.push_back("beqz");
+branchInstructions.push_back("bnez");
+branchInstructions.push_back("blez");
+branchInstructions.push_back("bgez");
+branchInstructions.push_back("bltz");
+branchInstructions.push_back("bgt");
+branchInstructions.push_back("ble");
+branchInstructions.push_back("bgtu");
+branchInstructions.push_back("bleu");
+
+branchInstructions.sort();
+   }
+
+  Target_riscv::~Target_riscv()
+  {
+  }
+
+  bool Target_riscv::isNopLine(
+const char* const line,
+int&  size
+)
+  {
+if (!strcmp( [strlen(line)-3], "nop")){
+size = 4;
+return true;
+}
+
+  return false;
+  }
+
+  TargetBase *Target_riscv_Constructor(
+std::stringtargetName
+)
+{
+  return new Target_riscv( targetName );
+}
+}
diff --git a/tester/covoar/Target_riscv.h b/tester/covoar/Target_riscv.h
new file mode 100644
index 000..112276c
--- /dev/null
+++ b/tester/covoar/Target_riscv.h
@@ -0,0 +1,98 @@
+/*
+ * RTEMS Tools Project (http://www.rtems.org/)
+ * Copyright 2019 Vijay K. Banerjee (vijaykumar9...@gmail.com)
+ * All rights reserved.
+ *
+ * This file is part of the RTEMS Tools package in 'rtems-tools'.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright notice,
+ * this list of conditions and the following disclaimer.
+ *
+ * 2. Redistributions in binary form must reproduce the above copyright notice,
+ * this list of conditions and the following disclaimer in the documentation
+ * and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT

Re: BSP for Xilinx Zynq UltraScale+ MPSoC platform

2019-02-01 Thread Joel Sherrill 
On Fri, Feb 1, 2019, 7:04 AM Alan Cudmore  I would like to see both R5 and A53 support. Having RTEMS on the R5 could
> allow it to be used for OpenAMP communication with the A53. Normally the
> OpenAMP port for the Xilinx board uses bare metal or FreeRTOS on the R5.
>

+1


> For the A53, is there a reason for choosing Aarch32 vs Aarch64 for the
> RTEMS port?
>

The aarch64 port is not present yet. Just the tools build.

Beyond that, I don't know of a good reason.

>
> I hope we will see a future Beagle board based on the one of the Ti Sitara
> SoCs that has R5 and A53.
> http://www.ti.com/processors/sitara-arm/am6x-cortex-a53-r5/overview.html
>

:)

I expected between the government shutdown and weather, you would have
finished the aarch64 port by now. /Sarcasm

--joel

>
>
> Alan
>
>
> On Wed, Jan 23, 2019 at 11:31 AM Joel Sherrill  wrote:
>
>>
>>
>> On Wed, Jan 23, 2019 at 2:34 AM Sebastian Huber <
>> sebastian.hu...@embedded-brains.de> wrote:
>>
>>> Hello,
>>>
>>> we will very likely soon work a BSP for the Xilinx Zynq UltraScale+
>>> MPSoC platform:
>>>
>>> https://devel.rtems.org/ticket/3682
>>>
>>> Please let me know, if you are interested in support for the Cortex-R5
>>> processors or AArch64 mode.
>>>
>>
>> We are currently working on a BSP for an R52 in a custom SoC. When
>> ready, it will be submitted. There will be a public qemu repo with support
>> for the SoC. Some of the ARM IP is a bit newer than what has drivers
>> in the tree.
>>
>> --joel
>>
>>
>>>
>>> The development platform will be this evaluation kit:
>>>
>>> https://www.xilinx.com/products/boards-and-kits/zcu104.html
>>>
>>> --
>>> 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
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: BSP for Xilinx Zynq UltraScale+ MPSoC platform

2019-02-01 Thread Sebastian Huber 

On 01/02/2019 15:04, Alan Cudmore wrote:
For the A53, is there a reason for choosing Aarch32 vs Aarch64 for the 
RTEMS port?


The AArch64 is a new architecture. For the AArch32 we can hopefully use 
the existing stuff from the ARM 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

Re: BSP for Xilinx Zynq UltraScale+ MPSoC platform

2019-02-01 Thread Alan Cudmore 
I would like to see both R5 and A53 support. Having RTEMS on the R5 could
allow it to be used for OpenAMP communication with the A53. Normally the
OpenAMP port for the Xilinx board uses bare metal or FreeRTOS on the R5.

For the A53, is there a reason for choosing Aarch32 vs Aarch64 for the
RTEMS port?

I hope we will see a future Beagle board based on the one of the Ti Sitara
SoCs that has R5 and A53.
http://www.ti.com/processors/sitara-arm/am6x-cortex-a53-r5/overview.html

Alan


On Wed, Jan 23, 2019 at 11:31 AM Joel Sherrill  wrote:

>
>
> On Wed, Jan 23, 2019 at 2:34 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> Hello,
>>
>> we will very likely soon work a BSP for the Xilinx Zynq UltraScale+
>> MPSoC platform:
>>
>> https://devel.rtems.org/ticket/3682
>>
>> Please let me know, if you are interested in support for the Cortex-R5
>> processors or AArch64 mode.
>>
>
> We are currently working on a BSP for an R52 in a custom SoC. When
> ready, it will be submitted. There will be a public qemu repo with support
> for the SoC. Some of the ARM IP is a bit newer than what has drivers
> in the tree.
>
> --joel
>
>
>>
>> The development platform will be this evaluation kit:
>>
>> https://www.xilinx.com/products/boards-and-kits/zcu104.html
>>
>> --
>> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: coverage : not getting coverage for leon3-sis-cov

2019-02-01 Thread Vijay Kumar Banerjee 
On Fri, 1 Feb 2019 at 14:04, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> you need the tools from the latest RSB.
>
Thanks!
It worked. :)

>
> However, the SIS crashed using an ERC32 test program:
>
> gdb --args sparc-rtems5-sis -nouartrx -r -cov spsysinit01.exe
> GNU gdb (GDB; devel:gcc) 8.2
> Copyright (C) 2018 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-suse-linux".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
>  .
>
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> No symbol table is loaded.  Use the "file" command.
> Reading symbols from sparc-rtems5-sis...done.
> (gdb) r
> Starting program: /build/rtems/5/bin/sparc-rtems5-sis -nouartrx -r -cov
> spsysinit01.exe
> Missing separate debuginfo for /lib64/ld-linux-x86-64.so.2
> Try: zypper install -C
> "debuginfo(build-id)=4062821f420b0c3d46ea03f208cae1a710516c4e"
> Missing separate debuginfo for /lib64/libtinfo.so.6
> Try: zypper install -C
> "debuginfo(build-id)=613f86254ba17e5782301403eba051a20a0d7480"
> Missing separate debuginfo for /lib64/libdl.so.2
> Try: zypper install -C
> "debuginfo(build-id)=466795ee7b9ca76122c66d034e7f18c7593d306e"
> Missing separate debuginfo for /lib64/libm.so.6
> Try: zypper install -C
> "debuginfo(build-id)=1e8038d58788ff7546c54ef151a441567c5119dc"
> Missing separate debuginfo for /lib64/libc.so.6
> Try: zypper install -C
> "debuginfo(build-id)=95b799e45a989e22af6e9d31ec729170e2c92dd2"
>
>   SIS - SPARC/RISCV instruction simulator 2.10,  copyright Jiri Gaisler
> 1995
>   Bug-reports to j...@gaisler.se
>
>   ERC32 emulation enabled
>
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0040c0f5 in cov_start (address=33554432) at
>
> ../../../sourceware-mirror-binutils-gdb-ce73f310150418a9a1625ab60a527d959096a9e2/sim/sis/func.c:1300
> 1300
> ../../../sourceware-mirror-binutils-gdb-ce73f310150418a9a1625ab60a527d959096a9e2/sim/sis/func.c:
>
> No such file or directory.
> (gdb) bt
> #0  0x0040c0f5 in cov_start (address=33554432) at
>
> ../../../sourceware-mirror-binutils-gdb-ce73f310150418a9a1625ab60a527d959096a9e2/sim/sis/func.c:1300
> #1  run_sim (icount=icount@entry=9223372036854775807, dis=dis@entry=0)
> at
>
> ../../../sourceware-mirror-binutils-gdb-ce73f310150418a9a1625ab60a527d959096a9e2/sim/sis/func.c:1102
> #2  0x0040d36d in exec_cmd (cmd=cmd@entry=0x4a71cd "run") at
>
> ../../../sourceware-mirror-binutils-gdb-ce73f310150418a9a1625ab60a527d959096a9e2/sim/sis/func.c:330
> #3  0x00403d29 in main (argc=,
> argv=0x7fffd828) at
>
> ../../../sourceware-mirror-binutils-gdb-ce73f310150418a9a1625ab60a527d959096a9e2/sim/sis/sis.c:202
> (gdb) quit
>
> --
> 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] Coverage: Add support for TSIM format

2019-02-01 Thread Vijay Kumar Banerjee 
---
 tester/rt/coverage.py   | 28 -
 tester/rtems/testing/bsps/leon3-sis-cov.ini |  3 ++-
 2 files changed, 24 insertions(+), 7 deletions(-)

diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
index 9fc9b64..859001a 100644
--- a/tester/rt/coverage.py
+++ b/tester/rt/coverage.py
@@ -288,7 +288,13 @@ class covoar(object):
 '''
 Covoar runner
 '''
-def __init__(self, base_result_dir, config_dir, executables, 
explanations_txt, trace, prefix):
+def __init__( self,
+  base_result_dir,
+  config_dir, executables,
+  explanations_txt,
+  trace,
+  prefix,
+  bsp ):
 self.base_result_dir = base_result_dir
 self.config_dir = config_dir
 self.executables = ' '.join(executables)
@@ -296,6 +302,7 @@ class covoar(object):
 self.project_name = 'RTEMS-5'
 self.trace = trace
 self.prefix = prefix
+self.bsp = bsp
 
 def _find_covoar(self):
 covoar_exe = 'covoar'
@@ -316,10 +323,18 @@ class covoar(object):
 if not path.exists(symbol_file):
 raise error.general('coverage: no symbol set file: %s'% 
(symbol_file))
 exe = self._find_covoar()
-command = exe + ' -S ' + symbol_file + \
-  ' -O ' + covoar_result_dir + \
-  ' -E ' + self.explanations_txt + \
-  ' -p ' + self.project_name + ' ' + self.executables
+if 'qemu' in self.bsp.split('-'):
+command = exe + ' -S ' + symbol_file + \
+  ' -O ' + covoar_result_dir + \
+  ' -E ' + self.explanations_txt + \
+  ' -p ' + self.project_name + ' ' + self.executables
+else:
+command = exe + ' -S ' + symbol_file + \
+  ' -O ' + covoar_result_dir + \
+  ' -E ' + self.explanations_txt + \
+  ' -f TSIM' + \
+  ' -p ' + self.project_name + ' ' + self.executables
+
 log.notice()
 log.notice('Running coverage analysis: %s (%s)' % (set_name, 
covoar_result_dir))
 start_time = datetime.datetime.now()
@@ -382,7 +397,8 @@ class coverage_run(object):
 covoar_runner = covoar(self.test_dir, self.symbol_select_path,
self.executables, self.explanations_txt,
self.trace,
-   self.prefix)
+   self.prefix,
+   self.macros['bsp'])
 covoar_runner.run(sset, self.symbol_select_path)
 self._generate_reports(symbol_sets);
 self._summarize();
diff --git a/tester/rtems/testing/bsps/leon3-sis-cov.ini 
b/tester/rtems/testing/bsps/leon3-sis-cov.ini
index f0a2ab9..39fc159 100644
--- a/tester/rtems/testing/bsps/leon3-sis-cov.ini
+++ b/tester/rtems/testing/bsps/leon3-sis-cov.ini
@@ -32,8 +32,9 @@
 # The leon3 BSP on sis with coverage
 #
 [leon3-sis-cov]
-bsp  = leon3
+bsp  = leon3-sis
 arch = sparc
 tester   = %{_rtscripts}/run.cfg
+target   = sparc-rtems5
 bsp_run_cmd  = %{rtems_tools}/%{bsp_arch}-rtems%{rtems_version}-sis
 bsp_run_opts = -leon3 -nouartrx -r -tlim 200 s -cov
-- 
2.17.2

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

Re: coverage : not getting coverage for leon3-sis-cov

2019-02-01 Thread Jiri Gaisler 

On 2/1/19 11:17 AM, Jiri Gaisler wrote:
> On 2/1/19 9:34 AM, Sebastian Huber wrote:
>> Hello,
>>
>> you need the tools from the latest RSB.
>>
>> However, the SIS crashed using an ERC32 test program:
>
> Yes, seems like I broke erc32 emulation. Leon2/3 still works fine - I will 
> investigate...

The erc32 memory controller was not properly initialized after I increased the 
amount of RAM in the simulator. The following patch should fix it. I will 
submit a proper patch for this, and also some other fixes to the RISC-V 
emulation.


diff --git a/sim/sis/erc32.c b/sim/sis/erc32.c
index be761379fb..ceedec52ed 100644
--- a/sim/sis/erc32.c
+++ b/sim/sis/erc32.c
@@ -362,8 +362,8 @@ decode_memcfg()
 if (rom8) mec_memcfg &= ~0x2;
 else mec_memcfg |= 0x2;
 
-    mem_ramsz = (256 * 1024) << ((mec_memcfg >> 10) & 7);
-    mem_romsz = (128 * 1024) << ((mec_memcfg >> 18) & 7);
+    mem_ramsz = (1024 * 1024) << ((mec_memcfg >> 10) & 7);
+    mem_romsz = (2 *1024 * 1024) << ((mec_memcfg >> 18) & 7);
 
 mem_ramstart = RAM_START;
 mem_ramend = RAM_END;



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

Re: coverage : not getting coverage for leon3-sis-cov

2019-02-01 Thread Jiri Gaisler 

On 2/1/19 9:34 AM, Sebastian Huber wrote:
> Hello,
>
> you need the tools from the latest RSB.
>
> However, the SIS crashed using an ERC32 test program:


Yes, seems like I broke erc32 emulation. Leon2/3 still works fine - I will 
investigate...


>
> gdb --args sparc-rtems5-sis -nouartrx -r -cov spsysinit01.exe
> GNU gdb (GDB; devel:gcc) 8.2
> Copyright (C) 2018 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-suse-linux".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
>     .
>
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> No symbol table is loaded.  Use the "file" command.
> Reading symbols from sparc-rtems5-sis...done.
> (gdb) r
> Starting program: /build/rtems/5/bin/sparc-rtems5-sis -nouartrx -r -cov 
> spsysinit01.exe
> Missing separate debuginfo for /lib64/ld-linux-x86-64.so.2
> Try: zypper install -C 
> "debuginfo(build-id)=4062821f420b0c3d46ea03f208cae1a710516c4e"
> Missing separate debuginfo for /lib64/libtinfo.so.6
> Try: zypper install -C 
> "debuginfo(build-id)=613f86254ba17e5782301403eba051a20a0d7480"
> Missing separate debuginfo for /lib64/libdl.so.2
> Try: zypper install -C 
> "debuginfo(build-id)=466795ee7b9ca76122c66d034e7f18c7593d306e"
> Missing separate debuginfo for /lib64/libm.so.6
> Try: zypper install -C 
> "debuginfo(build-id)=1e8038d58788ff7546c54ef151a441567c5119dc"
> Missing separate debuginfo for /lib64/libc.so.6
> Try: zypper install -C 
> "debuginfo(build-id)=95b799e45a989e22af6e9d31ec729170e2c92dd2"
>
>  SIS - SPARC/RISCV instruction simulator 2.10,  copyright Jiri Gaisler 1995
>  Bug-reports to j...@gaisler.se
>
>  ERC32 emulation enabled
>
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0040c0f5 in cov_start (address=33554432) at 
> ../../../sourceware-mirror-binutils-gdb-ce73f310150418a9a1625ab60a527d959096a9e2/sim/sis/func.c:1300
> 1300 
> ../../../sourceware-mirror-binutils-gdb-ce73f310150418a9a1625ab60a527d959096a9e2/sim/sis/func.c:
>  No such file or directory.
> (gdb) bt
> #0  0x0040c0f5 in cov_start (address=33554432) at 
> ../../../sourceware-mirror-binutils-gdb-ce73f310150418a9a1625ab60a527d959096a9e2/sim/sis/func.c:1300
> #1  run_sim (icount=icount@entry=9223372036854775807, dis=dis@entry=0) at 
> ../../../sourceware-mirror-binutils-gdb-ce73f310150418a9a1625ab60a527d959096a9e2/sim/sis/func.c:1102
> #2  0x0040d36d in exec_cmd (cmd=cmd@entry=0x4a71cd "run") at 
> ../../../sourceware-mirror-binutils-gdb-ce73f310150418a9a1625ab60a527d959096a9e2/sim/sis/func.c:330
> #3  0x00403d29 in main (argc=, argv=0x7fffd828) at 
> ../../../sourceware-mirror-binutils-gdb-ce73f310150418a9a1625ab60a527d959096a9e2/sim/sis/sis.c:202
> (gdb) quit
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Test Framework Documentation to User Manual or Software Engineering?

2019-02-01 Thread Sebastian Huber 

Hello,

should the documentation for the new test code framework go into the 
user manual or the software engineering guide?



The user manual already has some stuff about testing, but I am not sure 
if the user manual is the right place for a test code framework description.


https://docs.rtems.org/branches/master/user/testing/index.html

--
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: How can I check if a function exists in waf?

2019-02-01 Thread Sebastian Huber 

On 01/02/2019 10:06, Vijay Kumar Banerjee wrote:


On Fri, 1 Feb 2019 at 12:13, Sebastian Huber 
> wrote:


Hello,

how can I check if a function exists in waf (similar to
AC_CHECK_FUNC)?
Currently, we get this output from the RTEMS tools waf configure
(please
note the "Invalid argument 'function_name' in test"):

Hi,

The support for 'function_name' has been removed since waf 2 as it
was broken ( see 
https://gitlab.com/ita1024/waf/blob/master/waflib/Tools/c_config.py#L420)


Nice.



I guess the best option is to just use 'header_name' or to use the 
'fragment' parameter to write a fragment that calls the desired function.


So, there is no standard compile and link test for functions? If I use this

    conf.check_cc(fragment = 'int main(void) { strnlen("", 0); return 
0; }',
  header_name="string.h", features = 'c', mandatory = 
False)


waf outputs

Checking for header string.h  : yes

I don't want to test for string.h, I want to test for strnlen(). In 
config.log we have:


-
Checking for header string.h
==>
int main(void) { strnlen("", 0); return 0; }
<==
[1/1] Compiling 
build/.conf_check_6da1e91772980301eb2528a1d150a7ab/test.c


['/usr/bin/gcc', '../test.c', '-c', 
'-o/scratch/git-rtems-tools/build/.conf_check_6da1e91772980301eb2528a1d150a7ab/testbuild/test.c.1.o']

err: ../test.c: In function ‘main’:
../test.c:1:18: warning: implicit declaration of function ‘strnlen’ 
[-Wimplicit-function-declaration]

 int main(void) { strnlen("", 0); return 0; }
  ^~~

yes
-

So, this test uses already quite some code and still is basically useless.

--
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: How can I check if a function exists in waf?

2019-02-01 Thread Vijay Kumar Banerjee 
On Fri, 1 Feb 2019 at 12:13, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> how can I check if a function exists in waf (similar to AC_CHECK_FUNC)?
> Currently, we get this output from the RTEMS tools waf configure (please
> note the "Invalid argument 'function_name' in test"):
>
> Hi,

The support for 'function_name' has been removed since waf 2 as it
was broken ( see
https://gitlab.com/ita1024/waf/blob/master/waflib/Tools/c_config.py#L420)

I guess the best option is to just use 'header_name' or to use the
'fragment' parameter to write a fragment that calls the desired function.

> ./waf configure
> Setting top to   : /scratch/git-rtems-tools
> Setting out to   : /scratch/git-rtems-tools/build
> Version  : 5.551ce0825375-modified (5)
> Checking for program 'python': /usr/bin/python
> Checking for python version >= 2.6.6 : 2.7.14
> Checking for program 'python': /usr/bin/python
> Checking for program 'python2'   : /usr/bin/python2
> Checking for program 'python3'   : /usr/bin/python3
> Checking for 'gcc' (C compiler)  : /usr/bin/gcc
> Checking for 'g++' (C++ compiler): /usr/bin/g++
> Checking for header alloca.h : yes
> Checking for header fcntl.h  : yes
> Checking for header process.h: not found
> Checking for header stdlib.h : yes
> Checking for header string.h : yes
> Checking for header strings.h: yes
> Checking for header sys/file.h   : yes
> Checking for header sys/stat.h   : yes
> Checking for header sys/time.h   : yes
> Checking for header sys/types.h  : yes
> Checking for header sys/wait.h   : yes
> Checking for header unistd.h : yes
> Checking for header vfork.h  : not found
> Invalid argument 'function_name' in test
> Checking for header sys/time.h sys/resource.h : yes
> Checking for program 'm4' : /usr/bin/m4
> Checking for header sys/wait.h: yes
> Invalid argument 'function_name' in test
> Checking for header signal.h  : yes
> Checking for 'gcc' (C compiler)   : /usr/bin/gcc
> Checking for 'g++' (C++ compiler) : /usr/bin/g++
> Checking for 'gcc' (C compiler)   : /usr/bin/gcc
> Invalid argument 'function_name' in test
> Checking for header string.h  : yes
> Checking for 'g++' (C++ compiler) : /usr/bin/g++
> Invalid argument 'function_name' in test
> Checking for header stdlib.h  : yes
> Invalid argument 'function_name' in test
> Checking for header stdlib.h  : yes
> 'configure' finished successfully (1.058s)
>
> --
> 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

Re: [PATCH v2 00/10] Rework quick start in user manual

2019-02-01 Thread Sebastian Huber 

On 28/01/2019 13:27, Sebastian Huber wrote:

This patch set reworks the quick start chapter in the user manual. You
find a PDF with this patch set here:

https://ftp.rtems.org/pub/rtems/people/sebh/user.pdf

It duplicates some information with the "Installation" chapter.  The
"Installation" chapter should be reworked to contain the details.

The "Build Your Application" is a TODO.

v2:

Fix some issues after first review from Chris.



What about this second version?

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