Re: MrsP Testbed

2019-09-10 Thread Sebastian Huber 

On 10/09/2019 15:56, Ricardo Gomes (1161078) wrote:


In this email I sending one test for you to review it and see if it is 
structured according to RTEMS coding conventions, that I tried to fulfill.


This test case is very simple, testing only if it is possible to set one 
priority per scheduling instance and also verifying if, when a task 
attempt to obtain a MrsP semaphore, its priority is immediately raised 
to the ceiling priority defined on its scheduler.


I am currently quite busy. Please remind me in one week. Could you 
please change the licence to:


https://git.rtems.org/rtems/tree/LICENSE.BSD-2-Clause

Please send a complete patch so that I can build your test case and run it.

--
Sebastian Huber, embedded brains GmbH

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

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] record: Add wrappers for malloc() functions

2019-09-10 Thread Chris Johns 
On 6/9/19 11:09 pm, Sebastian Huber wrote:
> On 02/09/2019 08:00, Chris Johns wrote:
>> On 2/9/19 3:37 pm, Sebastian Huber wrote:
>>> On 01/09/2019 04:29, Chris Johns wrote:
 On 30/8/19 11:07 pm, Sebastian Huber wrote:
> Introduce new library librtemsrecordwrap.a which contains wrappers for
> operating system functions which produce entry/exit events.

 Why not enhance the trace linker to handle the recorder you have 
 developed? It
 has been able to wrap malloc and friends for a while now, it is just 
 lacking
 support for your recent tracing effort.

 Currently the trace linker does not uses the DWARF information to 
 determine the
 function signature as the DWARF support was added to the tool kit after it 
 was
 created and it has not been updated. The idea is to have DWARF provide the
 signature of any suitable function so it can be wrapped.
>>>
>>> With the DWARF information at hand it should be possible to generate generic
>>> record events for function calls with up to 10 input arguments
>>> (RTEMS_RECORD_ARG_[0-9]) and up to 10 return values 
>>> (RTEMS_RECORD_RETURN_[0-9]).
>>> We need two events for generic function entry/exit:
>>>
>>> RTEMS_RECORD_FUNCTION_ENTRY
>>> RTEMS_RECORD_FUNCTION_EXIT
>>>
>>> The event data for these two is the function address.
>>>

 I do not see any upside adding this library or wrapping specific functions
 this way.
>>>
>>> The benefits are:
>>>
>>> * Slightly more compact (the event indicates the function and the data can 
>>> be
>>> used for the caller address instead, the generic function entry/exit needs 
>>> two
>>> events for this).
>>
>> Could you please explain this, sorry I am not sure what this means? If the 
>> code
>> is what needs to be generated then why not generate?
>>
>>> * It works without extra tools to build the application.
>>
>> You need a bunch of extra tools to record the data and view it. The trace 
>> linker
>> is built and installed when the tools are built and installed.
> 
> Ok, all extra RTEMS tools are installed via the RSB, so we can drop this 
> point.
> 
>>
>>> * It can be tested through the RTEMS test suite.
>>
>> We lack better tests for our external tools and adding this would be good to
>> have. If you need a way to test the template adding it to a specific test 
>> would
>> work.
>>
>>> * You don't need the ELF file to produce a report.
>>
>> I recommend all users archive the ELF image of an executable with full debug
>> info because you can look into crash dumps. Without it you can only guess.
> 
> Yes, you should archive the ELF file, so we can drop this point.
> 
>>
>>> The only strong argument is the first one. A future support in the trace 
>>> linker
>>> could use the librtemsrecordwrap.a and only generate generic stubs for other
>>> functions.
>>
>> It complicates the management of wrapping become you have some functions in a
>> special library and others being wrapped.
> 
> We have to make a trade-off between
> 
> * a slightly more complicated host tool, and
> 
> * higher memory demands on the target system.
> 
> From my point of view lower memory demands on the target system are much more
> attractive.

Yes I agree, there is no issue with the code itself, it is about the location of
the code, why we have chosen that path, and possible issues further in time when
we may want to change the implementation.

I would like to examine the use cases...

1. I see the most common use case is connecting to a system to gather interrupt
and task context switching details. The user starts a service however no
handlers are installed until a connection is made to trace.

2. A variation of this is a system with a runtime system configuration option
(eg boot option) to enable the tracing service. By default it is disabled. This
is a system integration function where something during integration is not
working and needs investigation by an engineering team. Rebuilding code and
loading it onto a system may not be easy or possible and staring at the system
offers no insight.

3. Development profiling, validation or debugging of specific pieces of code.
This is a special link to wrap and trace specific code. The wrapping is
unconditional and a development tool for development builds of an application.

4. Instrumentation of specific pieces of code where wrapping is not possible.
There are specific cases where wrapping is problematic and insertion of trace
code is needed to instrument it.

As you move from use case 1 to 4 a more detail knowledge of how trace works is
needed. I see for 1. you make a call to register a service and that enables a
transport, eg bind to a socket and listen. I would expect the various tools in
rtems-tool to work from the command with no configurations, changes or rebuilds.
Use case 2. is similar to 1. but the target trace code is resident but dormant
until needed. The key point is the target trace hooks are dynamic and not
configuration

Re: [PATCH] Add rtems_version_control_key_is_valid()

2019-09-10 Thread Chris Johns 
On 10/9/19 5:22 pm, Sebastian Huber wrote:
> ---
>  cpukit/include/rtems/version.h| 19 +--
>  testsuites/sptests/spversion01/init.c |  8 +++-
>  2 files changed, 24 insertions(+), 3 deletions(-)

+1

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

Re: rtems-addr2line not working on ARM?

2019-09-10 Thread Chris Johns 
On 9/9/19 5:12 pm, Sebastian Huber wrote:
> On 09/09/2019 07:31, Sebastian Huber wrote:
>> On 07/09/2019 16:25, Sebastian Huber wrote:
>>> - Am 6. Sep 2019 um 18:06 schrieb Sebastian Huber
>>> sebastian.hu...@embedded-brains.de:
>>>
 - Am 6. Sep 2019 um 11:09 schrieb Sebastian Huber
 sebastian.hu...@embedded-brains.de:

> On 06/09/2019 09:26, Sebastian Huber wrote:
>> On 06/09/2019 09:01, Chris Johns wrote:
>>> On 6/9/19 4:20 pm, Sebastian Huber wrote:
 Hello,

 I tried the rtems-addr2line on ARM and SPARC. On SPARC it seems to
 work fine,
 however, on ARM I get this:

 rtems-addr2line -e
 build/arm-rtems5-xilinx_zynq_a9_qemu-everything/media01.exe
 0x135a
 /home/EB/sebastian_h/git-rtems-5/c/src/lib/libbsp/arm/xilinx-zynq/../../../../../../bsps/arm/shared/irq/irq-gic.c:264




 addr2line -e
 build/arm-rtems5-xilinx_zynq_a9_qemu-everything/media01.exe 135a
 /scratch/git-rtems-libbsd/build/arm-rtems5-xilinx_zynq_a9_qemu-everything/../../testsuite/include/rtems/bsd/test/default-network-init.h:179




 The GNU tool is right. It is also considerably faster.
>>> I would hope it is faster and exact. It has had many years of work on 
>>> it,
>>> written in C and not a means to test a C++ framework so we can grow an
>>> ecosystem. I have stated its purpose before. I am perplexed by the
>>> intent of
>>> this statement.
>>>
>>> If you want to compare performance I suggest you try the elftools one?
>>> There is
>>> one. It is not built because GNU provides one and good one.
>>>
>>> Also be-careful as the exec call is not as fast as Linux on all the
>>> hosts we
>>> support.
>>
>> That the GNU tool is faster was just an observation.
>>
>> Do we have a working library solution to get from an address to the
>> source line/function? I don't have time to debug the DWARF support code
>> at the moment.
>>
>> I have a working solution using "addr2line" and rld::process::execute().
>
> Thanks for the hint to the elftoolchain:
>
> https://github.com/elftoolchain/elftoolchain/blob/trunk/addr2line/addr2line.c
>
> To me it looks pretty complicated. It should be possible to refactor
> this code to use it as a library, e.g. call translate() for each address
> you need the source information.
>
> I tried to debug the rld get_source() problem for more than two hours
> and the elftoolchain code looks similar. I am not sure what to do.

 Another option is to use the LLVM infrastructure:

 https://github.com/llvm-mirror/llvm/blob/master/tools/llvm-symbolizer/llvm-symbolizer.cpp


  From a first glance, this looks like the way to go.
>>>
>>> Attached is a patch which uses the LLVM library to get an addr2line
>>> functionality. The code to resolve an address is very easy (item.data is the
>>> address):
>>>
>>>  auto res_or_err = symbolizer_.symbolizeCode(elf_file_, item.data);
>>>
>>>  if (res_or_err) {
>>>    auto info = res_or_err.get();
>>>    std::string fn = info.FunctionName;
>>>    std::string str;
>>>
>>>    if (fn != "") {
>>>  str += fn;
>>>  str += " at ";
>>>    }
>>>
>>>    str += llvm::sys::path::filename(info.FileName);
>>>    str += ":";
>>>    str += std::to_string(info.Line);
>>>
>>> LLVM has also support for command line arguments, file handling, etc.
>>
>> The LLVM solution is also the fastest so far:
>>
>> time ../build/trace/rtems-record-lttng -e media01.exe records.bin
>>
>> real    0m0.425s
>> user    0m0.293s
>> sys 0m0.132s
>>
>> addr2line based solution on Linux:
>>
>> real    0m11.944s
>> user    0m5.334s
>> sys 0m6.593s
> 
> Compiling this on Windows using mingw64 was a bit difficult. I had to install:
> 
> mingw-w64-x86_64-llvm
> mingw-w64-x86_64-clang
> 
> I used clang to build the tool by hand. I had to remove the use of the POSIX
> open/connect/socket/etc. and replace it with fopen().
> 
> The CTF stream files generated on Linux and Windows were identical using LLVM.
> 

I think LLVM is a great idea for us moving forward but it has some hurdles we
need to overcome. I like the idea of a maintained code base that is fast and has
working 64bit support, something that is not tested or working in the
rtemstoolkit code.

Does LLVM as used in trace have support for all of the current RTEMS
architectures? If it does not what do we do?

We have been avoiding depending on packages on hosts because of our past
experiences ..

1. getting a stable consistent version across all hosts can be difficult and
with environments like cygwin and msys having a floating head and no release
things age and break which makes long term support harder.

2. A more complicated set up process for users.

Re: [rtems-tools commit] record: Optionally use LLVM to resolve addresses

2019-09-10 Thread Chris Johns 
On 10/9/19 7:01 pm, Sebastian Huber wrote:
> Module:rtems-tools
> Branch:master
> Commit:5d80d0b2e1de9decb24c2d7ef481e4b63525595e
> Changeset: 
> http://git.rtems.org/rtems-tools/commit/?id=5d80d0b2e1de9decb24c2d7ef481e4b63525595e
> 
> Author:Sebastian Huber 
> Date:  Fri Sep  6 09:29:12 2019 +0200
> 
> record: Optionally use LLVM to resolve addresses

Just wondering ... if the RSB could build LLVM and clang as an RTEMS compiler
would it resolve the uniform availability for all supported hosts? It would add
weight to the need for us to look at LLVM support. I believe it uses a lot of
resources to build.

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

missing tests cases for clock_nanosleep?

2019-09-10 Thread Joel Sherrill 
Hi

I was looking for test cases for clock_nanosleep(CLOCK_MONOTONIC,...)
and I don't think we have any.

I think psxclockrealtime01 could be repurposed and conditionally
compiled to use either timer.except for the timeout finite case since
you can't set CLOCK_MONOTONIC.

Thoughts?

Thanks.

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

[PATCH] Correct initial POSIX signals mask

2019-09-10 Thread Joel Sherrill 
+ Modify POSIX thread create extension to ensure expected
  initial signal mask is provided to system threads, initial
  tasks and threads, and inheritied by tasks and threads.
+ Adds psxsignal07 to verify functionality when using a POSIX
  Initialization thread and POSIX threads.
+ Adds psxsignal08 to verify functionality when using a Classic API
  Initialization task and Classic API tasks.

Closes #3794.
---
 cpukit/posix/src/pthreadcreate.c|  50 +++-
 testsuites/psxtests/Makefile.am |  22 
 testsuites/psxtests/configure.ac|   2 +
 testsuites/psxtests/psxsignal01/init.c  |  14 ++
 testsuites/psxtests/psxsignal02/init.c  |  14 ++
 testsuites/psxtests/psxsignal03/init.c  |  14 ++
 testsuites/psxtests/psxsignal07/main.c  | 136 
 testsuites/psxtests/psxsignal07/psxsignal07.doc |  23 
 testsuites/psxtests/psxsignal07/psxsignal07.scn |   7 +
 testsuites/psxtests/psxsignal07/rtems_config.c  |  44 +++
 testsuites/psxtests/psxsignal08/main.c  | 163 
 testsuites/psxtests/psxsignal08/psxsignal08.doc |  22 
 testsuites/psxtests/psxsignal08/psxsignal08.scn |   7 +
 testsuites/psxtests/psxsignal08/rtems_config.c  |  45 +++
 14 files changed, 558 insertions(+), 5 deletions(-)
 create mode 100644 testsuites/psxtests/psxsignal07/main.c
 create mode 100644 testsuites/psxtests/psxsignal07/psxsignal07.doc
 create mode 100644 testsuites/psxtests/psxsignal07/psxsignal07.scn
 create mode 100644 testsuites/psxtests/psxsignal07/rtems_config.c
 create mode 100644 testsuites/psxtests/psxsignal08/main.c
 create mode 100644 testsuites/psxtests/psxsignal08/psxsignal08.doc
 create mode 100644 testsuites/psxtests/psxsignal08/psxsignal08.scn
 create mode 100644 testsuites/psxtests/psxsignal08/rtems_config.c

diff --git a/cpukit/posix/src/pthreadcreate.c b/cpukit/posix/src/pthreadcreate.c
index 211b2cf..fefa526 100644
--- a/cpukit/posix/src/pthreadcreate.c
+++ b/cpukit/posix/src/pthreadcreate.c
@@ -86,7 +86,6 @@ int pthread_create(
   int low_prio;
   Priority_Controlcore_low_prio;
   POSIX_API_Control  *api;
-  const POSIX_API_Control*executing_api;
 #endif
 
   if ( !start_routine )
@@ -260,9 +259,6 @@ int pthread_create(
*  finish initializing the per API structure
*/
   api = the_thread->API_Extensions[ THREAD_API_POSIX ];
-  executing_api = executing->API_Extensions[ THREAD_API_POSIX ];
-
-  api->signals_unblocked = executing_api->signals_unblocked;
 
   _Priority_Node_set_priority( >Sporadic.Low_priority, core_low_prio );
   api->Sporadic.sched_ss_repl_period =
@@ -376,7 +372,7 @@ void _POSIX_Threads_Sporadic_budget_callout( Thread_Control 
*the_thread )
 }
 
 static bool _POSIX_Threads_Create_extension(
-  Thread_Control *executing RTEMS_UNUSED,
+  Thread_Control *executing,
   Thread_Control *created
 )
 {
@@ -389,6 +385,50 @@ static bool _POSIX_Threads_Create_extension(
   _Watchdog_Initialize( >Sporadic.Timer, _POSIX_Threads_Sporadic_timer );
   _Priority_Node_set_inactive( >Sporadic.Low_priority );
 
+#if defined(RTEMS_POSIX_API)
+  /*
+   * There are some subtle rules which need to be followed for
+   * the value of the created thread's signal mask. Because signals
+   * are part of C99 and enhanced by POSIX, both Classic API tasks
+   * and POSIX threads have to have them enabled.
+   *
+   * + Internal system threads should have no signals enabled. They
+   *   have no business executing user signal handlers -- especially IDLE.
+   * + The initial signal mask for other threads needs to follow the
+   *   implication of a pure C99 environment which only has the methods
+   *   raise() and signal(). This implies that all signals are unmasked
+   *   until the thread explicitly uses a POSIX methods to block some.
+   *   This applies to both Classic tasks and POSIX threads created
+   *   as initalization tasks/threads (e.g. before the system is up).
+   * + After the initial threads are created, the signal mask should
+   *   be inherited from the creator.
+   *
+   * NOTE: The default signal mask does not matter for any application
+   *   that does not use POSIX signals.
+   */
+  if (!_System_state_Is_up(_System_state_Get())) {
+if (_Objects_Get_API(created->Object.id) == OBJECTS_INTERNAL_API) {
+  /*
+   * Block signals for all internal threads -- especially IDLE.
+   */
+  api->signals_unblocked = 0;
+} else {
+  /*
+   * Default state (signals unblocked) for all Initialization tasks
+   * and POSIX threads. We should not inherit from IDLE which is
+   * what appears to be executing during initialization.
+   */
+  api->signals_unblocked = SIGNAL_ALL_MASK;
+}
+  } else {
+const POSIX_API_Control*executing_api;
+/*
+ * RTEMS is running so follow

Re: [PATCH] rtems: Make rtems_version_control_key() safer

2019-09-10 Thread Peter Dufault 



> On Sep 9, 2019, at 22:00 , Chris Johns  wrote:
> 
> I would prefer we provide an interface to say the version control key has been
> set rather than exposing how we manage it. I think the change to not return 
> NULL
> is the correct one. What about adding ..
> 
> bool rtems_version_control_key_valid( void )
> {
>  return strlen( rtems_version_control_key( ) ) != 0;
> }
> 
> I have a feeling we may wedge ourselves in the future with users having code 
> to
> check the length.
> 
> Chris

I usually want both, that is, I always want the consistent error code interface 
(0 vs !0) and I frequently want more convenient interfaces.

Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering

This email is delivered through the public internet using protocols subject to 
interception and tampering.

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

Re: Trying to interrupt a blocking read...

2019-09-10 Thread Joel Sherrill 
On Tue, Sep 10, 2019 at 12:09 AM Benjamin Ellsworth
<2gigspambuc...@gmail.com> wrote:
>
> Hello,
>
> The code I'm working with currently does a read() on a device that has
> been opened with an open() call (a UART if that matters).  It nicely
> blocks waiting for a character (potentially forever).
>
> I now need that read to be interrupted...  I looked for pselect() so it
> can block until I tell it to stop (via signal from another thread), but
> that doesn't seem to be supported.  I looked at the classic work-around
> using a pipe in a select call, but pipe() isn't supported and select
> apparently only works on sockets (and the comments in the select header
> make it sound like even that is a bad idea).

What version? I thought select() on termios devices was added at least
to the master.

You are right that it historically hasn't worked.

pipe() is supported. psxpipe01 is the test. Not sure about the use case
you have in mind.

> I can probably make things work with timeouts--basically making it into
> a polling loop, but I can't see a way to make the read timeout.  I dug
> down into the rtems read functions, but didn't see any way to make them
> timeout, nor did I see a way to cleanly interrupt them.

read() on a UART should be able to do non-blocking or timeout on read()
with the VMIN and VTIME support from termios. There should be examples
of this around the net.

> If anyone has any suggestions/ideas/pointers, I'd appreciate them.

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

Re: RTEMS qualification and code annotations

2019-09-10 Thread Joel Sherrill 
I don't like to top post but in this case I hope this is OK.

This is a very challenging area from a project integration
perspective. There are a handful
of issues which we will have to figure out how to address. I think
these also apply to other
annotations like requirements and licensing annotation

+ Annotation
   - Standards based?
 - For example, will we add annotation for a scanner like Coverity?
   - Invasive/Intruding/Bulk
   - In source file or separate

+ Supporting Tools
   - Free, Libre and Open Source Software
   - Upstream Project not dead
   - Wide Host Support
  - On other cases, have accepted that not all hosts can run the tool

+ Maintenance
  - Availability of Knowledgeable Developers
  - Running Checks as part of Continuous Integration (pre-check ideal)
  - Automated notification of need to update and tracking system

I suggested some guidance in the Software Engineering Guide on broad
tool review
criteria (FLOSS, etc) with a section/chapter on each type of tool we
use (e.g. requirements
for source code control and why git).

I  am pretty sure someone has already used Frama-C on RTEMS. Perhaps
contact the Frama-C
folks and ask. I met one of their core folks at a conference a few
years and he mentioned it.
Perhaps asking their community about this may turn up something.

I'm just trying to make sure we ask all the right questions. Andrew
covered some of them
in great detail.

My first thoughts are:
   - Frama-C seems to be fairly well accepted and meets FLOSS requirement
   - Is ACSL standard?  Supported by anything besides Frama-C?
   -  Annotation needs to be in the source files or it is
unmaintainable IMO. I don't want a
  special tool to merge source. There will end up being annotation
in the source file anyway.
   - Any tool like this has to be part of the currently immature
pre-commit checks and Continuous
 Integration Testing at rtems.org.
   - I don't like that it has issues on other hosts but if the Frama-C
community is willing
 to help address that, it can be worked. I suspect that any of
these special purpose,
 relatively low user base tools will have great cross host support
unless we work with them.

--joel


On Tue, Sep 10, 2019 at 5:45 AM Andrew Butterfield
 wrote:
>
> Dear Chris,
>
>   first, thanks for trying to install it !
>
>  Frama-C is one of a number of tools we are considering, so it's not a done 
> deal.
>
>  If used, it would only be applied to a small part of the codebase:
>   typically code that is very critical, but hard to test reliably.
>  I would expect that this code would be unlikely to change much, if at all.
>
> The contents of the annotations would have to be maintained by those familiar 
> with
> the annotation  language(ACSL*) and how it should be used.
>
> They would also be responsible
> for ensuring that any loop annotations in .c files would be revised if there 
> was any significant
> code refactoring that altered the number or purpose of those loops.
>
> The annotation in the .h files capture  the specification of what the code 
> should do,
> as pre/post-condition pairs - once setup and validated, they shouldn't change 
> much.
>
> Frama-C has two main components:
>  ` frama-c`  :  a command line tool that does all the work, and is highly 
> automatable
>   `frama-c-gui` : a nice GUI that interacts with `frama-c`, and produces 
> verification results
> that can be re-run from the command line.
>
> The plan is that the GUI might be used to develop/debug/validate the various 
> annotations,
> but that the day-to-day use of Frama-C as part of the qualification toolset 
> would simply
> involve re-running the verifications using the command-line tool, all 
> automated. It would
> only be if this reported some verification failure that any action would need 
> to be taken.
> This would mean that only the command-line tool would need to be installed, 
> which might
> reduce the package count somewhat.
>
> A quick potted history of Frama-C was that it was developed, starting in 2010,
> by CEA (http://www-list.cea.fr/en/) on top of a previous tool called CAVEAT 
> they had
> that was used internally by Airbus. It was designed specifically to automate 
> formal
> verification of  Airbus C code, and then made available to the community at 
> large.
>
> An issue with it is that it handles C99, but not C11, which may be a 
> show-stopper for us.
>
>  Regards, Andrew
>
> * ACSL = "ANSI C Specification Language"
>
>
>
> On 10 Sep 2019, at 02:36, Chris Johns  wrote:
>
> On 6/9/19 9:40 pm, Andrew Butterfield wrote:
>
> However, if the implementation code contains loops, then we need annotations 
> in
> the code at those loops. The following, from the Frama-C ACSL Tutorial
> (https://frama-c.com/acsl_tutorial_index.html) shows the annotations required 
> to
> verify the correctness of a function that finds the maximum of a sequence of
> integers.
>
>
> Am I to assume Frama-C is the analysis tool for this work?
>
> I have taken a

MrsP Testbed

2019-09-10 Thread Ricardo Gomes (1161078) 
Hello Sebastian,

>>  Greetings,
>>
>>  During the last six months, I have been studying RTEMS as part of my final
>>  project to complete my degree, more specifically analysing the MrsP 
>> protocol in
>>  order to perform an evaluation of its implementation on RTEMS.

> I would be great if you can publish the evaluation once it is finished. 
> Please let me know if you need a > reviewer.

>>  In order to accomplish this analysis, I developed a set of samples that 
>> allows
>>  one to test several properties of MrsP, based its own rules, as described in
>>  [1],  including the use of nested resources, presented in [2]. Beyond that, 
>> I
>>  have also adapted those test cases, using OMIP instead of MrsP, in order to
>>  establish comparisons between both protocols.
>>
>>  So far the set of develop test cases were executed using QEMU, as up to now 
>> I’m
>>  not able to execute SMP code in a Raspberry PI 2 (I will address this topic
>>  with more detail later on another thread).
>>
>>  I wanted to know if:
>>
>>  1- there is any interest from the community for me to submit these tests to 
>> the
>> RTEMS repository, or at least the ones considered relevant
>>
>>  2- In case the answer to 1 is affirmative, If I should create a new ticket 
>> and
>> submit the test cases as individual patches.

> an independent set of test cases would be good. Currently, the tests and the 
> implementation are from > the  same person. SMP test code in the test suite 
> must compile and link on all SMP targets. If you plan > to submit the code, 
> please plan with enough time for some review/change iterations.

In first place, yes I want to submit my tests, although how may I assert if my 
tests compile and link on every SMP targets?

>>
>> Thank you for your attention.
>>
>> Best Regards,
>
>> Ricardo Gomes
>>
>>
>> P.S. After I complete my final report I can make it available if someone is
>> interested.

>  Yes, I am definitely interested.

In this email I sending one test for you to review it and see if it is 
structured according to RTEMS coding conventions, that I tried to fulfill.

This test case is very simple, testing only if it is possible to set one 
priority per scheduling instance and also verifying if, when a task attempt to 
obtain a MrsP semaphore, its priority is immediately raised to the ceiling 
priority defined on its scheduler.

Best regards,
Ricardo Gomes

<>
/*
* Copyright (c) 2019 Ricardo Gomes - CISTER
*
* The license and distribution terms for this file may be
* found in the file LICENSE in this distribution or at
* https://www.rtems.org/license/LICENSE.
*/

#ifdef HAVE_CONFIG_H
#include "config.h"
#endif

#include 
#include 
#include 
#include 
#include 
#include 
#include "tmacros.h"

const char rtems_test_name[] = "SMPMRSP 2";

#define CPU_COUNT 2

typedef struct
{
  rtems_id init_id;
  rtems_id scheduler_ids[CPU_COUNT];
  rtems_id mrsp_id;
  rtems_id task_id;
} test_context;

static test_context test_instance;

static void assert_priority(rtems_id task_id, rtems_task_priority priority)
{
  rtems_status_code sc;
  rtems_task_priority prio;

  sc = rtems_task_set_priority(task_id, RTEMS_CURRENT_PRIORITY, );
  rtems_test_assert(sc == RTEMS_SUCCESSFUL);

  rtems_test_assert(priority == prio);
}

static void create_mrsp_semaphore(test_context *ctx, rtems_id *id, 
rtems_task_priority prio)
{
  uint32_t cpu_count = rtems_get_processor_count();
  uint32_t index;
  rtems_status_code sc;

  sc = rtems_semaphore_create(
  rtems_build_name('M', 'R', 'S', 'P'),
  1,
  RTEMS_MULTIPROCESSOR_RESOURCE_SHARING | RTEMS_BINARY_SEMAPHORE,
  prio,
  id);
  rtems_test_assert(sc == RTEMS_SUCCESSFUL);

  rtems_task_priority old_prio;

  old_prio = 1;
  sc = rtems_semaphore_set_priority(
  *id,
  ctx->scheduler_ids[1],
  prio + 1,
  _prio);
  rtems_test_assert(sc == RTEMS_SUCCESSFUL);

  prio = 2;
  for (index = 0; index < cpu_count; index++)
  {
rtems_task_priority pr = RTEMS_CURRENT_PRIORITY;
sc = rtems_semaphore_set_priority(*id, ctx->scheduler_ids[index], pr, );
rtems_test_assert(sc == RTEMS_SUCCESSFUL);
rtems_test_assert(prio == pr);
printf("CPU %d ceiling priority = %" PRIu32 "\n", index, pr);
prio++;
  }
}

static void test_prio_per_proc(test_context *ctx)
{
  printf("\n\n--TESTING IF THERE IS ONE CEILING PER PROCESSOR--\n\n");
  rtems_task_priority prio = 2;

  create_mrsp_semaphore(ctx, >mrsp_id, prio);

  printf("\n-\n");
}

static void high_task_prio_obtain(rtems_task_argument arg)
{
  test_context *ctx = _instance;

  printf("TASK - before obtain should the prio should be 6\n");
  assert_priority(RTEMS_SELF, 6);

  rtems_status_code sc = rtems_semaphore_obtain(ctx->mrsp_id, RTEMS_WAIT, 
RTEMS_NO_TIMEOUT);
  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
  printf("TASK - after obtain should the prio should be 3\n");
  assert_priority(RTEMS_SELF, 3);

  sc = rtems_semaphore_release(ctx->mrsp_id);

Re: RTEMS qualification and code annotations

2019-09-10 Thread Andrew Butterfield 
Dear Chris,

  first, thanks for trying to install it ! 

 Frama-C is one of a number of tools we are considering, so it's not a done 
deal.

 If used, it would only be applied to a small part of the codebase: 
  typically code that is very critical, but hard to test reliably.
 I would expect that this code would be unlikely to change much, if at all.

The contents of the annotations would have to be maintained by those familiar 
with
the annotation  language(ACSL*) and how it should be used.

They would also be responsible
for ensuring that any loop annotations in .c files would be revised if there 
was any significant
code refactoring that altered the number or purpose of those loops.

The annotation in the .h files capture  the specification of what the code 
should do,
as pre/post-condition pairs - once setup and validated, they shouldn't change 
much.

Frama-C has two main components: 
 ` frama-c`  :  a command line tool that does all the work, and is highly 
automatable
  `frama-c-gui` : a nice GUI that interacts with `frama-c`, and produces 
verification results
that can be re-run from the command line.

The plan is that the GUI might be used to develop/debug/validate the various 
annotations,
but that the day-to-day use of Frama-C as part of the qualification toolset 
would simply
involve re-running the verifications using the command-line tool, all 
automated. It would
only be if this reported some verification failure that any action would need 
to be taken.
This would mean that only the command-line tool would need to be installed, 
which might
reduce the package count somewhat.

A quick potted history of Frama-C was that it was developed, starting in 2010,
by CEA (http://www-list.cea.fr/en/ ) on top of a 
previous tool called CAVEAT they had
that was used internally by Airbus. It was designed specifically to automate 
formal
verification of  Airbus C code, and then made available to the community at 
large.

An issue with it is that it handles C99, but not C11, which may be a 
show-stopper for us.

 Regards, Andrew

* ACSL = "ANSI C Specification Language"



> On 10 Sep 2019, at 02:36, Chris Johns  wrote:
> 
> On 6/9/19 9:40 pm, Andrew Butterfield wrote:
>> However, if the implementation code contains loops, then we need annotations 
>> in
>> the code at those loops. The following, from the Frama-C ACSL Tutorial
>> (https://frama-c.com/acsl_tutorial_index.html) shows the annotations 
>> required to
>> verify the correctness of a function that finds the maximum of a sequence of
>> integers.
> 
> Am I to assume Frama-C is the analysis tool for this work?
> 
> I have taken a look at this tool however it would be nice to get some
> understanding of its history and how you see it fitting in to the RTEMS 
> project
> and how we as a project take these annotations and maintained them.
> 
> I see on the Frama-C website Linux is supported and so I decided see how 
> FreeBSD
> goes. I installed ocaml for FreeBSD as a result of some configure errors with 
> ..
> 
> $ pkg install ocaml ocaml-findlib
> 
> however configure returned ...
> 
> checking for ocamlgraph... ocamlfind: Package `ocamlgraph' not found
> 
> This one package wants to install 118 packages some dependent on gnome,
> gnome-theme, docbook, gstreamer, bash and more so I have said no to installing
> them and I have decided to give up for now. The box I am using is a headless
> build server.
> 
> Chris


Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204
Lero@TCD, Head of Foundations & Methods Research Group
School of Computer Science and Statistics,
Room G.39, O'Reilly Institute, Trinity College, University of Dublin
 http://www.scss.tcd.ie/Andrew.Butterfield/


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

Re: [RTEMS][PATCH v2 0/2] riscv: add freedom E310 Arty A7

2019-09-10 Thread Hesham Almatary 
Hi Pragnesh,

Thanks for the v2 update. I guess our question/comment on the previous
v1 patch was about the addition of bsps/riscv/frdme310arty/ directory
at all. That is, you might be able to just use  bsps/riscv/riscv
already. Are there any significant changes that prevent you from just
using "bsps/riscv/riscv"? For example, griscv doesn't have FDT, and
has its own way of managing (external) interrupts, so a new gricv bsp
is added. On the other hand, it looks to me that frdme310arty has FDT
and the same PLIC/CLINT drivers that riscv/riscv already uses, which
doesn't really need any special handling or additions. I managed, for
example, to get bsps/riscv/riscv running on Piccolo [1] on a Xilinx
FPGA (with FDT, PLIC, CLINT and 16550 Xilinx UART IP) without having
to do anything (except for just two lines of FDT handling code that I
submitted patches for).

[1] https://github.com/bluespec/Piccolo

Cheers,
Hesham

On Tue, 10 Sep 2019 at 07:34, Pragnesh Patel  wrote:
>
> This series added a support for RISCV freedom E310 Arty A7 bsp
> and add bsps/riscv/shared code for reusability
>
> Changes in v2:
>
>   bsps/riscv/frdme310arty/btimer/btimer.c
> - Remove the read_csr() function from btimer.c
> - Remove CONFIG_BTIMER_RISCV_GET_MCYCLES macro to get time in
>   microseconds
>
>   bsps/riscv/frdme310arty/clock/clockdrv.c
>   bsps/riscv/riscv/clock/clockdrv.c
> - Delete both files and Add bsps/riscv/shared/clock/clockdrv.c
> - riscv_clock_get_timebase_frequency(): Get timebase-frequency from
>   cpus or cpu@0 devicetree node because riscv uses "cpus" node and
>   frdme310arty uses "cpu@0" node to look for timebase-frequency
> - Remove rtems_counter_initialize_converter() and
>   rtems_timecounter_simple_install() functions
>
>   bsps/riscv/frdme310arty/include/bsp/riscv.h
> - Remove unused frdme310arty_l2c_base;
>
>   bsps/riscv/frdme310arty/start/bsp_fatal_halt.c
>   bsps/riscv/riscv/start/bsp_fatal_halt.c
> - Delete this file and Add bsps/riscv/shared/start/bsp_fatal_halt.c
>
>   bsps/riscv/frdme310arty/start/bspstart.c
> - Remove unused function riscv_get_node_byname()
>
>   bsps/riscv/frdme310arty/start/linkcmds.in
> - Use @RISCV_RAM_REGION_BEGIN@ and @RISCV_RAM_REGION_SIZE@ instead of
>   hard coded values
>
>   c/src/lib/libbsp/riscv/frdme310arty/Makefile.am
> - librtemsbsp_a_SOURCES -> bsps/riscv/shared/start/bsp_fatal_halt.c
> - librtemsbsp_a_SOURCES -> bsps/riscv/shared/clock/clockdrv.c
>
>   c/src/lib/libbsp/riscv/frdme310arty/configure.ac
> - change RISCV_RAM_REGION_SIZE to default 256MiB
>
>   bsps/riscv/riscv/irq/irq.c
> - Delete this irq.c and it will now use bsps/riscv/shared/irq/irq.c
>
>   c/src/lib/libbsp/riscv/riscv/Makefile.am
> - librtemsbsp_a_SOURCES -> bsps/riscv/shared/start/bsp_fatal_halt.c
> - librtemsbsp_a_SOURCES -> bsps/riscv/shared/clock/clockdrv.c
> - librtemsbsp_a_SOURCES -> bsps/riscv/shared/irq/irq.c
>
> Pragnesh Patel (2):
>   riscv: add freedom E310 Arty A7 bsp
>   bsp/riscv:  Remove duplicate files
>
>  bsps/include/bsp/fatal.h   |   6 +-
>  bsps/riscv/frdme310arty/btimer/btimer.c| 104 ++
>  bsps/riscv/frdme310arty/config/frdme310arty.cfg|  11 +
>  bsps/riscv/frdme310arty/console/console-config.c   | 146 
>  bsps/riscv/frdme310arty/console/uart.c | 100 ++
>  bsps/riscv/frdme310arty/dts/frdme310arty.dts   | 130 +++
>  .../frdme310arty/dts/frdme310arty_dtb_array.c  | 259 ++
>  bsps/riscv/frdme310arty/headers.am |  15 +
>  bsps/riscv/frdme310arty/include/bsp.h  |  57 
>  bsps/riscv/frdme310arty/include/bsp/fe310_uart.h   |  42 +++
>  bsps/riscv/frdme310arty/include/bsp/irq.h  |  73 
>  bsps/riscv/frdme310arty/include/bsp/riscv.h|  59 
>  bsps/riscv/frdme310arty/include/tm27.h | 334 ++
>  bsps/riscv/frdme310arty/start/bsp_specs|   9 +
>  bsps/riscv/frdme310arty/start/bspstart.c   | 204 +++
>  bsps/riscv/frdme310arty/start/linkcmds.in  |  49 +++
>  bsps/riscv/frdme310arty/start/start.S  | 147 
>  bsps/riscv/riscv/clock/clockdrv.c  | 212 
>  bsps/riscv/riscv/irq/irq.c | 379 
> -
>  bsps/riscv/riscv/start/bsp_fatal_halt.c|  53 ---
>  bsps/riscv/shared/clock/clockdrv.c | 231 +
>  bsps/riscv/shared/irq/irq.c| 379 
> +
>  bsps/riscv/shared/start/bsp_fatal_halt.c   |  53 +++
>  c/src/lib/libbsp/riscv/acinclude.m4|   2 +
>  c/src/lib/libbsp/riscv/frdme310arty/Makefile.am|  75 
>  c/src/lib/libbsp/riscv/frdme310arty/configure.ac   |  68 
>  c/src/lib/libbsp/riscv/riscv/Makefile.am   |   6 +-
>  27 files changed, 2555 insertions(+), 648 deletions(-)
>  create mode 100644

Re: rtems-addr2line not working on ARM?

2019-09-10 Thread Sebastian Huber 

Hello,

I checked in the variant using LLVM:

https://git.rtems.org/rtems-tools/commit/?id=5d80d0b2e1de9decb24c2d7ef481e4b63525595e

I hope that I got the waf configure stuff right to only use LLVM if it 
is installed. I tested on Linux, msys2 and mingw64.


--
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] Add rtems_version_control_key_is_valid()

2019-09-10 Thread Sebastian Huber 
---
 cpukit/include/rtems/version.h| 19 +--
 testsuites/sptests/spversion01/init.c |  8 +++-
 2 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/cpukit/include/rtems/version.h b/cpukit/include/rtems/version.h
index 30dd70cc21..a8aff732f3 100644
--- a/cpukit/include/rtems/version.h
+++ b/cpukit/include/rtems/version.h
@@ -16,6 +16,8 @@
 #ifndef _RTEMS_VERSION_H
 #define _RTEMS_VERSION_H
 
+#include 
+
 #ifdef __cplusplus
 extern "C" {
 #endif
@@ -65,11 +67,24 @@ int rtems_version_revision( void );
  * The key is specific to the version control system being used and allows the
  * built version to be identified.
  *
- * @return The version control key or the empty string if no version control
- * key is available.
+ * Use rtems_version_control_key_is_valid() to check if the version control key
+ * is valid.
+ *
+ * @return The version control key.
  */
 const char *rtems_version_control_key( void );
 
+/**
+ * @brief Returns true, if the version control key is valid, otherwise false.
+ *
+ * @retval true The version control key is valid.
+ * @retval false Otherwise.
+ */
+static inline bool rtems_version_control_key_is_valid( const char *key )
+{
+  return key[ 0 ] != '\0';
+}
+
 /**
  * @brief Returns the board support package name.
  *
diff --git a/testsuites/sptests/spversion01/init.c 
b/testsuites/sptests/spversion01/init.c
index fc38577691..9db3143d39 100644
--- a/testsuites/sptests/spversion01/init.c
+++ b/testsuites/sptests/spversion01/init.c
@@ -22,13 +22,19 @@ static rtems_task Init(
   rtems_task_argument argument
 )
 {
+  const char *key;
+  const char *valid;
+
   TEST_BEGIN();
 
+  key = rtems_version_control_key();
+  valid = rtems_version_control_key_is_valid(key) ? "valid" : "invalid";
+
   printf("Release  : %s\n", rtems_version());
   printf("Major: %d\n", rtems_version_major());
   printf("Minor: %d\n", rtems_version_minor());
   printf("Revision : %d\n", rtems_version_revision());
-  printf("VC Key   : %s\n", rtems_version_control_key());
+  printf("VC Key   : %s (%s)\n", key, valid);
   printf("BSP  : %s\n", rtems_board_support_package());
 
   TEST_END();
-- 
2.16.4

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

[RTEMS][PATCH v2 0/2] riscv: add freedom E310 Arty A7

2019-09-10 Thread Pragnesh Patel 
This series added a support for RISCV freedom E310 Arty A7 bsp
and add bsps/riscv/shared code for reusability

Changes in v2:
  
  bsps/riscv/frdme310arty/btimer/btimer.c
- Remove the read_csr() function from btimer.c
- Remove CONFIG_BTIMER_RISCV_GET_MCYCLES macro to get time in
  microseconds

  bsps/riscv/frdme310arty/clock/clockdrv.c
  bsps/riscv/riscv/clock/clockdrv.c
- Delete both files and Add bsps/riscv/shared/clock/clockdrv.c
- riscv_clock_get_timebase_frequency(): Get timebase-frequency from
  cpus or cpu@0 devicetree node because riscv uses "cpus" node and
  frdme310arty uses "cpu@0" node to look for timebase-frequency
- Remove rtems_counter_initialize_converter() and
  rtems_timecounter_simple_install() functions

  bsps/riscv/frdme310arty/include/bsp/riscv.h
- Remove unused frdme310arty_l2c_base;

  bsps/riscv/frdme310arty/start/bsp_fatal_halt.c
  bsps/riscv/riscv/start/bsp_fatal_halt.c
- Delete this file and Add bsps/riscv/shared/start/bsp_fatal_halt.c

  bsps/riscv/frdme310arty/start/bspstart.c
- Remove unused function riscv_get_node_byname()

  bsps/riscv/frdme310arty/start/linkcmds.in
- Use @RISCV_RAM_REGION_BEGIN@ and @RISCV_RAM_REGION_SIZE@ instead of
  hard coded values

  c/src/lib/libbsp/riscv/frdme310arty/Makefile.am
- librtemsbsp_a_SOURCES -> bsps/riscv/shared/start/bsp_fatal_halt.c
- librtemsbsp_a_SOURCES -> bsps/riscv/shared/clock/clockdrv.c

  c/src/lib/libbsp/riscv/frdme310arty/configure.ac
- change RISCV_RAM_REGION_SIZE to default 256MiB

  bsps/riscv/riscv/irq/irq.c
- Delete this irq.c and it will now use bsps/riscv/shared/irq/irq.c

  c/src/lib/libbsp/riscv/riscv/Makefile.am
- librtemsbsp_a_SOURCES -> bsps/riscv/shared/start/bsp_fatal_halt.c
- librtemsbsp_a_SOURCES -> bsps/riscv/shared/clock/clockdrv.c
- librtemsbsp_a_SOURCES -> bsps/riscv/shared/irq/irq.c

Pragnesh Patel (2):
  riscv: add freedom E310 Arty A7 bsp
  bsp/riscv:  Remove duplicate files

 bsps/include/bsp/fatal.h   |   6 +-
 bsps/riscv/frdme310arty/btimer/btimer.c| 104 ++
 bsps/riscv/frdme310arty/config/frdme310arty.cfg|  11 +
 bsps/riscv/frdme310arty/console/console-config.c   | 146 
 bsps/riscv/frdme310arty/console/uart.c | 100 ++
 bsps/riscv/frdme310arty/dts/frdme310arty.dts   | 130 +++
 .../frdme310arty/dts/frdme310arty_dtb_array.c  | 259 ++
 bsps/riscv/frdme310arty/headers.am |  15 +
 bsps/riscv/frdme310arty/include/bsp.h  |  57 
 bsps/riscv/frdme310arty/include/bsp/fe310_uart.h   |  42 +++
 bsps/riscv/frdme310arty/include/bsp/irq.h  |  73 
 bsps/riscv/frdme310arty/include/bsp/riscv.h|  59 
 bsps/riscv/frdme310arty/include/tm27.h | 334 ++
 bsps/riscv/frdme310arty/start/bsp_specs|   9 +
 bsps/riscv/frdme310arty/start/bspstart.c   | 204 +++
 bsps/riscv/frdme310arty/start/linkcmds.in  |  49 +++
 bsps/riscv/frdme310arty/start/start.S  | 147 
 bsps/riscv/riscv/clock/clockdrv.c  | 212 
 bsps/riscv/riscv/irq/irq.c | 379 -
 bsps/riscv/riscv/start/bsp_fatal_halt.c|  53 ---
 bsps/riscv/shared/clock/clockdrv.c | 231 +
 bsps/riscv/shared/irq/irq.c| 379 +
 bsps/riscv/shared/start/bsp_fatal_halt.c   |  53 +++
 c/src/lib/libbsp/riscv/acinclude.m4|   2 +
 c/src/lib/libbsp/riscv/frdme310arty/Makefile.am|  75 
 c/src/lib/libbsp/riscv/frdme310arty/configure.ac   |  68 
 c/src/lib/libbsp/riscv/riscv/Makefile.am   |   6 +-
 27 files changed, 2555 insertions(+), 648 deletions(-)
 create mode 100644 bsps/riscv/frdme310arty/btimer/btimer.c
 create mode 100644 bsps/riscv/frdme310arty/config/frdme310arty.cfg
 create mode 100644 bsps/riscv/frdme310arty/console/console-config.c
 create mode 100644 bsps/riscv/frdme310arty/console/uart.c
 create mode 100644 bsps/riscv/frdme310arty/dts/frdme310arty.dts
 create mode 100644 bsps/riscv/frdme310arty/dts/frdme310arty_dtb_array.c
 create mode 100644 bsps/riscv/frdme310arty/headers.am
 create mode 100644 bsps/riscv/frdme310arty/include/bsp.h
 create mode 100644 bsps/riscv/frdme310arty/include/bsp/fe310_uart.h
 create mode 100644 bsps/riscv/frdme310arty/include/bsp/irq.h
 create mode 100644 bsps/riscv/frdme310arty/include/bsp/riscv.h
 create mode 100644 bsps/riscv/frdme310arty/include/tm27.h
 create mode 100644 bsps/riscv/frdme310arty/start/bsp_specs
 create mode 100644 bsps/riscv/frdme310arty/start/bspstart.c
 create mode 100644 bsps/riscv/frdme310arty/start/linkcmds.in
 create mode 100644 bsps/riscv/frdme310arty/start/start.S
 delete mode 100644 bsps/riscv/riscv/clock/clockdrv.c
 delete mode 100644 bsps/riscv/riscv/irq/irq.c
 delete mode 100644 bsps/riscv/riscv/start/bsp_fatal_halt.c

[RTEMS][PATCH v2 2/2] bsp/riscv: Remove duplicate files

2019-09-10 Thread Pragnesh Patel 
Delete clockdrv.c, irq.c and bsp_fatal_halt.c and
Makefile.am now points to bsps/riscv/shared directory

Update #3785.

Signed-off-by: Pragnesh Patel 
---
 bsps/riscv/riscv/clock/clockdrv.c| 212 -
 bsps/riscv/riscv/irq/irq.c   | 379 ---
 bsps/riscv/riscv/start/bsp_fatal_halt.c  |  53 -
 c/src/lib/libbsp/riscv/riscv/Makefile.am |   6 +-
 4 files changed, 3 insertions(+), 647 deletions(-)
 delete mode 100644 bsps/riscv/riscv/clock/clockdrv.c
 delete mode 100644 bsps/riscv/riscv/irq/irq.c
 delete mode 100644 bsps/riscv/riscv/start/bsp_fatal_halt.c

diff --git a/bsps/riscv/riscv/clock/clockdrv.c 
b/bsps/riscv/riscv/clock/clockdrv.c
deleted file mode 100644
index 7e6034d..000
--- a/bsps/riscv/riscv/clock/clockdrv.c
+++ /dev/null
@@ -1,212 +0,0 @@
-/**
- * @file
- *
- * @ingroup bsp_clock
- *
- * @brief riscv clock support.
- */
-
-/*
- * Copyright (c) 2018 embedded brains GmbH
- * COPYRIGHT (c) 2015 Hesham Alatary 
- *
- * 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 AUTHOR 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 AUTHOR OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-#include 
-#include 
-
-#include 
-
-/* This is defined in dev/clock/clockimpl.h */
-void Clock_isr(void *arg);
-
-typedef struct {
-  struct timecounter base;
-  volatile RISCV_CLINT_regs *clint;
-  uint32_t interval;
-} riscv_timecounter;
-
-static riscv_timecounter riscv_clock_tc;
-
-static void riscv_clock_write_mtimecmp(
-  volatile RISCV_CLINT_timer_reg *mtimecmp,
-  uint64_t value
-)
-{
-#if __riscv_xlen == 32
-  mtimecmp->val_32[0] = 0x;
-  mtimecmp->val_32[1] = (uint32_t) (value >> 32);
-  mtimecmp->val_32[0] = (uint32_t) value;
-#elif __riscv_xlen == 64
-  mtimecmp->val_64 = value;
-#endif
-}
-
-static uint64_t riscv_clock_read_mtime(volatile RISCV_CLINT_timer_reg *mtime)
-{
-#if __riscv_xlen == 32
-  uint32_t low;
-  uint32_t high_0;
-  uint32_t high_1;
-
-  do {
-high_0 = mtime->val_32[1];
-low = mtime->val_32[0];
-high_1 = mtime->val_32[1];
-  } while (high_0 != high_1);
-
-  return (((uint64_t) high_0) << 32) | low;
-#elif __riscv_xlen == 64
-  return mtime->val_64;
-#endif
-}
-
-static void riscv_clock_at_tick(riscv_timecounter *tc)
-{
-  volatile RISCV_CLINT_regs *clint;
-  uint64_t value;
-
-  clint = tc->clint;
-
-  value = clint->mtimecmp[0].val_64;
-  value += tc->interval;
-
-  riscv_clock_write_mtimecmp(>mtimecmp[0], value);
-}
-
-static void riscv_clock_handler_install(void)
-{
-  rtems_status_code sc;
-
-  sc = rtems_interrupt_handler_install(
-RISCV_INTERRUPT_VECTOR_TIMER,
-"Clock",
-RTEMS_INTERRUPT_UNIQUE,
-(rtems_interrupt_handler) Clock_isr,
-NULL
-  );
-  if (sc != RTEMS_SUCCESSFUL) {
-bsp_fatal(RISCV_FATAL_CLOCK_IRQ_INSTALL);
-  }
-}
-
-static uint32_t riscv_clock_get_timecount(struct timecounter *base)
-{
-  riscv_timecounter *tc;
-  volatile RISCV_CLINT_regs *clint;
-
-  tc = (riscv_timecounter *) base;
-  clint = tc->clint;
-  return clint->mtime.val_32[0];
-}
-
-static uint32_t riscv_clock_get_timebase_frequency(const void *fdt)
-{
-  int node;
-  const uint32_t *val;
-  int len;
-
-  node = fdt_path_offset(fdt, "/cpus");
-  val = fdt_getprop(fdt, node, "timebase-frequency", );
-  if (val == NULL || len < 4) {
-bsp_fatal(RISCV_FATAL_NO_TIMEBASE_FREQUENCY_IN_DEVICE_TREE);
-  }
-
-  return fdt32_to_cpu(*val);
-}
-
-static void riscv_clock_initialize(void)
-{
-  const char *fdt;
-  riscv_timecounter *tc;
-  volatile RISCV_CLINT_regs *clint;
-  uint32_t tb_freq;
-  uint64_t us_per_tick;
-  uint32_t interval;
-
-  fdt = bsp_fdt_get();
-  tb_freq = riscv_clock_get_timebase_frequency(fdt);
-  us_per_tick = rtems_configuration_get_microseconds_per_tick();
-  interval = (uint32_t) ((tb_freq *

[RTEMS][PATCH v2 1/2] riscv: add freedom E310 Arty A7 bsp

2019-09-10 Thread Pragnesh Patel 
Update #3785.

Signed-off-by: Pragnesh Patel 
---
 bsps/include/bsp/fatal.h   |   6 +-
 bsps/riscv/frdme310arty/btimer/btimer.c| 104 ++
 bsps/riscv/frdme310arty/config/frdme310arty.cfg|  11 +
 bsps/riscv/frdme310arty/console/console-config.c   | 146 
 bsps/riscv/frdme310arty/console/uart.c | 100 ++
 bsps/riscv/frdme310arty/dts/frdme310arty.dts   | 130 +++
 .../frdme310arty/dts/frdme310arty_dtb_array.c  | 259 ++
 bsps/riscv/frdme310arty/headers.am |  15 +
 bsps/riscv/frdme310arty/include/bsp.h  |  57 
 bsps/riscv/frdme310arty/include/bsp/fe310_uart.h   |  42 +++
 bsps/riscv/frdme310arty/include/bsp/irq.h  |  73 
 bsps/riscv/frdme310arty/include/bsp/riscv.h|  59 
 bsps/riscv/frdme310arty/include/tm27.h | 334 ++
 bsps/riscv/frdme310arty/start/bsp_specs|   9 +
 bsps/riscv/frdme310arty/start/bspstart.c   | 204 +++
 bsps/riscv/frdme310arty/start/linkcmds.in  |  49 +++
 bsps/riscv/frdme310arty/start/start.S  | 147 
 bsps/riscv/shared/clock/clockdrv.c | 231 +
 bsps/riscv/shared/irq/irq.c| 379 +
 bsps/riscv/shared/start/bsp_fatal_halt.c   |  53 +++
 c/src/lib/libbsp/riscv/acinclude.m4|   2 +
 c/src/lib/libbsp/riscv/frdme310arty/Makefile.am|  75 
 c/src/lib/libbsp/riscv/frdme310arty/configure.ac   |  68 
 23 files changed, 2552 insertions(+), 1 deletion(-)
 create mode 100644 bsps/riscv/frdme310arty/btimer/btimer.c
 create mode 100644 bsps/riscv/frdme310arty/config/frdme310arty.cfg
 create mode 100644 bsps/riscv/frdme310arty/console/console-config.c
 create mode 100644 bsps/riscv/frdme310arty/console/uart.c
 create mode 100644 bsps/riscv/frdme310arty/dts/frdme310arty.dts
 create mode 100644 bsps/riscv/frdme310arty/dts/frdme310arty_dtb_array.c
 create mode 100644 bsps/riscv/frdme310arty/headers.am
 create mode 100644 bsps/riscv/frdme310arty/include/bsp.h
 create mode 100644 bsps/riscv/frdme310arty/include/bsp/fe310_uart.h
 create mode 100644 bsps/riscv/frdme310arty/include/bsp/irq.h
 create mode 100644 bsps/riscv/frdme310arty/include/bsp/riscv.h
 create mode 100644 bsps/riscv/frdme310arty/include/tm27.h
 create mode 100644 bsps/riscv/frdme310arty/start/bsp_specs
 create mode 100644 bsps/riscv/frdme310arty/start/bspstart.c
 create mode 100644 bsps/riscv/frdme310arty/start/linkcmds.in
 create mode 100644 bsps/riscv/frdme310arty/start/start.S
 create mode 100644 bsps/riscv/shared/clock/clockdrv.c
 create mode 100644 bsps/riscv/shared/irq/irq.c
 create mode 100644 bsps/riscv/shared/start/bsp_fatal_halt.c
 create mode 100644 c/src/lib/libbsp/riscv/frdme310arty/Makefile.am
 create mode 100644 c/src/lib/libbsp/riscv/frdme310arty/configure.ac

diff --git a/bsps/include/bsp/fatal.h b/bsps/include/bsp/fatal.h
index fae5461..5193943 100644
--- a/bsps/include/bsp/fatal.h
+++ b/bsps/include/bsp/fatal.h
@@ -152,7 +152,11 @@ typedef enum {
   RISCV_FATAL_INVALID_PLIC_NDEV_IN_DEVICE_TREE,
   RISCV_FATAL_TOO_LARGE_PLIC_NDEV_IN_DEVICE_TREE,
   RISCV_FATAL_INVALID_INTERRUPT_AFFINITY,
-  RISCV_FATAL_NO_NS16550_INTERRUPTS_IN_DEVICE_TREE
+  RISCV_FATAL_NO_NS16550_INTERRUPTS_IN_DEVICE_TREE,
+  /*SIFIVE FRDM310 codes*/
+  FRDM310_RISCV_FATAL_NO_NODE_IN_DEVICE_TREE,
+  FRDM310_RISCV_FATAL_NO_L2C_REG_IN_DEVICE_TREE,
+  FRDM310_RISCV_FATAL_TM27_IRQ_INSTALL
 } bsp_fatal_code;
 
 RTEMS_NO_RETURN static inline void
diff --git a/bsps/riscv/frdme310arty/btimer/btimer.c 
b/bsps/riscv/frdme310arty/btimer/btimer.c
new file mode 100644
index 000..b03c245
--- /dev/null
+++ b/bsps/riscv/frdme310arty/btimer/btimer.c
@@ -0,0 +1,104 @@
+/**
+ * @file
+ * @brief Freedom E310 Timer driver
+ *
+ */
+
+/*
+ *  Copyright (c) 2019 by Sachin Ghadi 
+ *  Copyright (c) 2019 by Pragnesh Patel 
+ *
+ *  The license and distribution terms for this file may be
+ *  found in the file LICENSE in this distribution or at
+ *  http://www.rtems.org/license/LICENSE.
+ */
+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+bool benchmark_timer_find_average_overhead;
+
+//#define CONFIG_BTIMER_RISCV_GET_MCYCLES
+
+#ifdef CONFIG_BTIMER_RISCV_GET_MCYCLES
+uint64_t   Begin_Time;
+uint64_t   End_Time;
+#else
+long   Begin_Time;
+long   End_Time;
+
+#endif
+
+static unsigned long get_cpu_freq()
+{
+   return riscv_get_core_frequency();
+}
+
+static unsigned long get_timer_freq()
+{
+   return get_cpu_freq();
+}
+
+static uint64_t get_timer_value()
+{
+#if __riscv_xlen == 32
+   while (1) {
+   uint32_t hi = read_csr(mcycleh);
+   uint32_t lo = read_csr(mcycle);
+   if (hi == read_csr(mcycleh))
+   return ((uint64_t)hi << 32) | lo;
+   }
+#else
+   return read_csr(mcycle);
+#endif
+}
+
+/*Returns time in microseconds*/
+static long