Re: Question regarding newlib/libgloss

2019-10-14 Thread Sebastian Huber

Hello Andrei,

On 14/10/2019 14:13, Andrei Zisu wrote:

I am currently learning about how RSB builds the toolchain.


Although this isn't my question to the list, for context, I am looking 
at to reusing the rtems toolchain for other non-rtems-based targets we have.


you have to be careful when you use Newlib/GCC configured for RTEMS for 
other systems. For example RTEMS provides its own GCC thread model and 
Newlib lock implementation.


--
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: Arm Multilib Question

2019-10-11 Thread Sebastian Huber

On 11/10/2019 15:46, Joel Sherrill wrote:

Hi

I'm trying to find the right multilib for the ARM Deos BSP. They compile 
their native

ARINC 653 applications with these:

arm-eabi-gcc   -MP -MMD -nostdinc -gdwarf-2 -fno-exceptions 
-mabi=aapcs-linux -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 
-mthumb -mthumb-interwork   -O0  -fno-threadsafe-statics 
  -fno-use-cxa-atexit -fno-rtti


I am not sure if -mabi=aapcs-linux is a nop or dangerous. Why do they 
use this option.


The -mthumb-interwork is superfluous.

The -fno-exceptions and -fno-rtti make more sense if you build libstdc++ 
also with it.




Neither arm-eabi nor arm-rtems will link this. arm-eabi picks a variant 
for crtn0.o but doesn't seem to find a libm even though one is there in 
the same multilib path and ends up with the math function undefined. 
arm-rtems is just missing the multlib info as best I can tell.


/data/home/joel/test-gcc/install-master/bin/../lib/gcc/arm-rtems5/10.0.0/../../../../arm-rtems5/bin/ld: 
error: /tmp/cc8zsaRc.o uses VFP register arguments, armtest does not
/data/home/joel/test-gcc/install-master/bin/../lib/gcc/arm-rtems5/10.0.0/../../../../arm-rtems5/bin/ld: 
failed to merge target specific data of file /tmp/cc8zsaRc.o


I have attached my simple example. Do we have a multlib that should be 
matching this or does one need to be added?


Assistance definitely appreciated.


GCC 8, 9 and 10 are not supported by the ARM BSPs right now.

You can try this with GCC 10:

-mthumb -march=armv7-a+simd -mfloat-abi=hard

Why do they use -mfpu=vfpv3-d16? This seems to be quite a non-standard 
ARMv7-A chip.


--
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 to build multiple BSPs with waf?

2019-10-11 Thread Sebastian Huber

On 05/10/2019 01:50, Chris Johns wrote:

On 4/10/19 11:33 pm, Sebastian Huber wrote:

Hello,

I tried to figure how a standard waf build can be configured so that out-of-tree
or multiple build trees can be used. I couldn't get this working.

The Samba project seems to have support for out-of-tree builds:

https://wiki.samba.org/index.php/Waf#Out_of_tree_builds

However, this '-b' option is not present in a standard waf.


You would need to look for the additional options SAMBA must have added.


This looks like a project for the future.




The libbsd uses a common build tree for a list of arch/bsp combinations. This
seems to be quite a resource hungry solution. For example, I am not able to
build two BSPs with this approach on Windows/MSYS2.


What resources are you referring too, disk space, memory?


When I build two BSPs on Windows/MSYS2 I get this error:

[1940/1940] Linking 
build/powerpc-rtems5-qoriq_e6500_32-default/zerocopy01.exe
Waf: Leaving directory 
`/c/rtems/home/rtems-libbsd/build/powerpc-rtems5-qoriq_e6500_32-default'
'build-powerpc-rtems5-qoriq_e6500_32-default' finished successfully 
(3m17.050s)
Waf: Entering directory 
`/c/rtems/home/rtems-libbsd/build/powerpc-rtems5-qoriq_e6500_64-default'
[1/4] Creating 
build/powerpc-rtems5-qoriq_e6500_64-default/build-include/rtems/bsd/modules.h

[2/4] Compiling rtemsbsd/rtems/generate_kvm_symbols
[3/4] Compiling testsuite/include/rtems/bsd/test/network-config.h.in
[4/4] Compiling 
build/powerpc-rtems5-qoriq_e6500_64-default/rtemsbsd/rtems/rtems-kernel-kvm-symbols.c
Waf: Leaving directory 
`/c/rtems/home/rtems-libbsd/build/powerpc-rtems5-qoriq_e6500_64-default'

Build failed
Traceback (most recent call last):
  File 
"/c/rtems/home/rtems-libbsd/.waf3-2.0.13-4c5a17779813574907c253ab5418388d/waflib/Task.py", 
line 176, in process

ret=self.run()
  File "", line 27, in f
  File "/c/rtems/home/rtems-libbsd/rtems_waf/rtems.py", line 635, in 
exec_command

ret = super(self.__class__, self).exec_command(cmd, **kw)
  File "/c/rtems/home/rtems-libbsd/rtems_waf/rtems.py", line 635, in 
exec_command

ret = super(self.__class__, self).exec_command(cmd, **kw)
  File "/c/rtems/home/rtems-libbsd/rtems_waf/rtems.py", line 635, in 
exec_command

ret = super(self.__class__, self).exec_command(cmd, **kw)
  [Previous line repeated 326 more times]
  File "/c/rtems/home/rtems-libbsd/rtems_waf/rtems.py", line 624, in 
exec_command

if not isinstance(cmd, str) and len(str(cmd)) > 8192:
RecursionError: maximum recursion depth exceeded while getting the str 
of an object


Building the BSPs one after another works well.




Is there already a plan to build multiple BSPs (or one BSP with different
options) with waf?


Amar built more than one BSP, one after the other and so does rtems_waf. I have
not seen anything that would build a single BSP with different options using a
single configure command.


Ok, I figured it out more or less how you can build variants with waf.

--
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 v4] riscv: add freedom E310 Arty A7 bsp

2019-10-11 Thread Sebastian Huber

On 11/10/2019 08:18, Pragnesh Patel wrote:

  RISCV_LINKCMD([RISCV_RAM_REGION_BEGIN],[begin of the RAM region for linker 
command file (default is 0x7000 for 64-bit with -mcmodel=medlow and 
0x8000 for all other)],[${RISCV_RAM_REGION_BEGIN_DEFAULT}])
-RISCV_LINKCMD([RISCV_RAM_REGION_SIZE],[size of the RAM region for linker 
command file (default 64MiB)],[0x0400])
+RISCV_LINKCMD([RISCV_RAM_REGION_SIZE],[size of the RAM region for linker 
command file (default is 256 MiB for frdme310arty and 64 MiB for all 
other)],[${RISCV_RAM_REGION_SIZE_DEFAULT}])


No need for this change?

Arty A7 100T has a 256 MB of RAM. So,  do you want me to make
RISCV_RAM_REGION_SIZE to default 64 MB for frdme310arty?


Since we have now a BSP variant for this board I think it makes sense to 
have all RAM available by default.


--
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: Testing the interrupt extension API?

2019-10-10 Thread Sebastian Huber

On 10/10/2019 01:25, Gedare Bloom wrote:

Interrupts with cap.can_raise set and cap.has_peripheral cleared can be
safely software controlled and used for tests.

Why not just have an "is_software_triggered"?

As a replacement for has_peripheral?


yes, it seems that if an interrupt is software triggered, then it
cannot have a peripheral. I don't know if the opposite is true though,
I guess there can be interrupt lines that are not software triggered,
but don't have a peripheral attached to them, but then they are not
active lines they can't actually raise an interrupt.  I don't know if
that makes any sense.


On some controllers you can trigger every interrupt vector by software. 
On some you you can only trigger a subset. On some systems, some 
interrupt vectors are not available and cannot be triggered at all, e.g. 
chip variant A supports hardware modules M0, M1, and M2, variant B 
supports only M0, so the vectors used by M1 and M2 are not used (disabled).


--
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: Newlib updated .. x86 fenv support merged

2019-10-09 Thread Sebastian Huber
Hello Joel,

I wait for an integration of some patches for a libbsd update to the latest 
FreeBSD master branch. I would like to update the RSB once this is done.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH 1/3] rtems/confdefs.h add another initial extension set

2019-10-07 Thread Sebastian Huber

On 04/10/2019 16:05, Joel Sherrill wrote:



On Fri, Oct 4, 2019 at 12:02 AM Sebastian Huber 
<mailto:sebastian.hu...@embedded-brains.de>> wrote:


On 04/10/2019 00:08, Joel Sherrill wrote:
 > This adds back the capability for the BSP to configure an
 > initial extension that is specific to itself. The parameter
 > BSP_INITIAL_EXTENSION was taken over by having a standard
 > fatal extension installed using the same name.
 > ---
 >   cpukit/include/rtems/confdefs.h | 3 +++
 >   1 file changed, 3 insertions(+)
 >
 > diff --git a/cpukit/include/rtems/confdefs.h
b/cpukit/include/rtems/confdefs.h
 > index 5eb5425..e1a255a 100644
 > --- a/cpukit/include/rtems/confdefs.h
 > +++ b/cpukit/include/rtems/confdefs.h
 > @@ -2136,6 +2136,9 @@ extern rtems_initialization_tasks_table
Initialization_tasks[];
 >       #if defined(CONFIGURE_INITIAL_EXTENSIONS)
 >         CONFIGURE_INITIAL_EXTENSIONS,
 >       #endif
 > +    #if defined(BSP_INITIAL2_EXTENSIONS)
 > +      BSP_INITIAL2_EXTENSIONS,
 > +    #endif
 >       #if defined(BSP_INITIAL_EXTENSION)
 >         BSP_INITIAL_EXTENSION
 >       #endif
 >

I don't think this patch is necessary. A BSP is free to provide its own
initial extension. Just don't add the

#include 

to the bsp.h.


And why would I want to lose the default fatal extension? The point of 
BSP_INITIAL_EXTENSION
was for a BSP to add it's own extensions. I like the default extensions 
but the BSP should still have a

hook.

I would prefer to rename this to BSP_FATAL_EXTENSION and leave the 
BSP_INITIAL_EXTENSION

available.

I think I could fix this by for this BSP by something like this:

#include 

#undef BSP_INITIAL_EXTENSION
#define BSP_INITIAL_EXTENSION
    {
      ... switch extension ...,
     ... default fatal extension
   }

Is that what you are proposing a user should do if they want to another 
extension but still

use the default fatal extension?

FWIW other BSPs uses this default extension and just provide their 
own bsp_fatal_extension()

implementation. That seems OK and slightly different from my use case.


I think a BSP should just provide one extension via 
BSP_INITIAL_EXTENSION defined by . The declaration of 
bsp_fatal_extension() should move to a separate header file. It can then 
be used in a custom BSP extension.


--
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 2/3] Add hook for BSP to act when time is set

2019-10-07 Thread Sebastian Huber

On 04/10/2019 17:08, Joel Sherrill wrote:

I can't conceive of a use case where you would need more than one hook set.
Do you have something in mind?

The int returned may need to be an enum so there is a list of known 
failures which

can be mapped to API specific errors.

Any ideas on the new API to register with? Whether it is one hook or a 
set, we will

need an API. Is this part of the rtems_clock_ APIs? or something like
rtems_tod_register_hooks() and unregister? I'm having trouble putting a 
name on

the API.

The way I implemented this, it was not called in non-paravirtualized 
environments and
required to be provided by the BSP in paravirtualized environments. It 
was quite

simple.

I'm happy to move to a register type interface. Just want help in 
defining requirements and

API specifications.


The hook infrastructure needs to be testable. Your v1 patch added 
untestable code paths non-paravirtualized environments. A generalization 
of the API is easy and may be beneficial in the future (e.g. use in RTC 
drivers). At the moment I don't see a need for a public API. We can add 
a wrapper later if necessary.


--
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 to build start.o using waf?

2019-10-07 Thread Sebastian Huber

On 05/10/2019 01:05, Chris Johns wrote:

On 4/10/19 5:55 pm, Sebastian Huber wrote:

On 04/10/2019 09:20, Chris Johns wrote:

On 4/10/19 4:21 pm, Sebastian Huber wrote:

On 03/10/2019 04:32, Chris Johns wrote:

On 3/10/19 3:30 am, Gedare Bloom wrote:

On Wed, Oct 2, 2019 at 5:12 AM Sebastian Huber
 wrote:


On 30/09/2019 15:14, Sebastian Huber wrote:

Hello,

I would like to work on a new build system prototype. The idea is to use
specification items maintained by Doorstop (YAML files), a Python
configuration script and waf to build RTEMS and the tests. This is
similar to the libbsd build. The difference is that in libbsd the build
data is maintained directly in Python code (libbsd.py).


A key design aspect is how the configuration of RTEMS is handled and
maintained.
Amar's solution provides a specific model for managing settings and
specifically
BSP options. We need a way to add options for a BSP that lets us collect,
document and validate these settings. We need a way to query and review option
defaults. The solution needs to be able to add and remove BSPs with minimal
impact and this leads to being able to build a BSP that is external to the
RTEMS
source tree. There are BSPs that are private or export restricted. Another
issue
to consider is how we deprecate, update or alter options.

I suspect we will have an iterating design around the internal design and
implementation complexity and suitable external user work-flows.


Now is a good time to create a wish list for the new build system. I cannot
implement everything, but I can try to make a substantial initial step forward.


I agree.


Doorstop is a tool to manage a directed, acyclic graph of items. Each item has a
set of attributes (key-value pairs). Some attributes are pre-defined by Doorstop
with requirements management in mind. You can also add an arbitrary number of
custom attributes. With this data structure you can tackle a lot of problems.
The items are stored in YAML format files.


Note YAML is not part of the standard Python, it is add-on package. This means
using it would mean we would need to provide support on a number of hosts.


The libyaml package seems to be used in a lot of other packages and can be
installed with pip. If the use of YAML for the build would be a show stopper for
you, it would be good to know this early.


It is not about me saying yes or no, I am only highlighting the issue. I suggest
you check and test the different host types we support to make sure there is a
sensible realistic way to support YAML. This goes for any dependency we come
across. If you do not do this and no one comments or draws attention to any
potential issue the whole project has to live with the outcome once it is 
merged.


Ok, this makes sense, sorry for not finding this out myself. I sent a 
help request to the users list:


https://lists.rtems.org/pipermail/users/2019-October/067184.html




My approach would be to store all the data that defines the build in build item
files. The wscript file reads the build items, configures the build and performs
the build as specified also by command line options, e.g. which BSP, with tests,
etc. The build item files can be also used by other tools.

A BSP is represented by a BSP build item which links to BSP option items, object
items (start.o) and file groups for librtemsbsp.a.

A BSP is just a node in the graph, you can ask for example: if I remove this BSP
item, does it create isolated items? The isolated items can be removed if the
BSP is removed. If you change an option, you can figure out the impact, e.g.
which BSP uses this option.


I had not considered going to level but what you say seems consistent with my
thinking on how configuration should happen. With out the detail it is hard so I
will make a general statement that a change to the build system has to serve the
general RTEMS community first and this means easy to access and manage
configurations generated by RTEMS. I ask RTEMS to configure a BSP and a
configuration file is generated. I can then edit the file to alter specific
settings I need. The is what Amar did.


My approach would be to configure the build via command line options and then
the configuration is read-only for the build.


It is not clear to me what the command line options are configuring. There are
build options and target/BSP options. It you include BSP options there are far
more than could sensibly be handled on the command line.


Being able to alter an existing configuration seems a bit complex to me.


It can be simple, Amar's build used the INI format, it was easy to review and
alter and did not add any extra host dependencies. The build checked and
validated the config on each build and it did it quickly. Also the config does
not need to be generated and altered each time, it can be held in a user's
workspace used to build RTEMS.

Command line options for BSPOPT type configs is something I do not support. I do
not like what we have with configure BSPOPT_

[PATCH] Add CC-BY-SA-4.0 license text

2019-10-06 Thread Sebastian Huber
Retrieved from:

https://creativecommons.org/licenses/by-sa/4.0/legalcode.txt

This license is inteded for code which are shared with the
documentation, e.g code examples.  Such code should be dual licensed
BSD-2-Clause or CC-BY-SA-4.0 with the following license identifier:

SPDX-License-Identifier: BSD-2-Clause OR CC-BY-SA-4.0
---
 LICENSE.CC-BY-SA-4.0 | 428 +++
 1 file changed, 428 insertions(+)
 create mode 100644 LICENSE.CC-BY-SA-4.0

diff --git a/LICENSE.CC-BY-SA-4.0 b/LICENSE.CC-BY-SA-4.0
new file mode 100644
index 00..a73481c4be
--- /dev/null
+++ b/LICENSE.CC-BY-SA-4.0
@@ -0,0 +1,428 @@
+Attribution-ShareAlike 4.0 International
+
+===
+
+Creative Commons Corporation ("Creative Commons") is not a law firm and
+does not provide legal services or legal advice. Distribution of
+Creative Commons public licenses does not create a lawyer-client or
+other relationship. Creative Commons makes its licenses and related
+information available on an "as-is" basis. Creative Commons gives no
+warranties regarding its licenses, any material licensed under their
+terms and conditions, or any related information. Creative Commons
+disclaims all liability for damages resulting from their use to the
+fullest extent possible.
+
+Using Creative Commons Public Licenses
+
+Creative Commons public licenses provide a standard set of terms and
+conditions that creators and other rights holders may use to share
+original works of authorship and other material subject to copyright
+and certain other rights specified in the public license below. The
+following considerations are for informational purposes only, are not
+exhaustive, and do not form part of our licenses.
+
+ Considerations for licensors: Our public licenses are
+ intended for use by those authorized to give the public
+ permission to use material in ways otherwise restricted by
+ copyright and certain other rights. Our licenses are
+ irrevocable. Licensors should read and understand the terms
+ and conditions of the license they choose before applying it.
+ Licensors should also secure all rights necessary before
+ applying our licenses so that the public can reuse the
+ material as expected. Licensors should clearly mark any
+ material not subject to the license. This includes other CC-
+ licensed material, or material used under an exception or
+ limitation to copyright. More considerations for licensors:
+wiki.creativecommons.org/Considerations_for_licensors
+
+ Considerations for the public: By using one of our public
+ licenses, a licensor grants the public permission to use the
+ licensed material under specified terms and conditions. If
+ the licensor's permission is not necessary for any reason--for
+ example, because of any applicable exception or limitation to
+ copyright--then that use is not regulated by the license. Our
+ licenses grant only permissions under copyright and certain
+ other rights that a licensor has authority to grant. Use of
+ the licensed material may still be restricted for other
+ reasons, including because others have copyright or other
+ rights in the material. A licensor may make special requests,
+ such as asking that all changes be marked or described.
+ Although not required by our licenses, you are encouraged to
+ respect those requests where reasonable. More considerations
+ for the public:
+wiki.creativecommons.org/Considerations_for_licensees
+
+===
+
+Creative Commons Attribution-ShareAlike 4.0 International Public
+License
+
+By exercising the Licensed Rights (defined below), You accept and agree
+to be bound by the terms and conditions of this Creative Commons
+Attribution-ShareAlike 4.0 International Public License ("Public
+License"). To the extent this Public License may be interpreted as a
+contract, You are granted the Licensed Rights in consideration of Your
+acceptance of these terms and conditions, and the Licensor grants You
+such rights in consideration of benefits the Licensor receives from
+making the Licensed Material available under these terms and
+conditions.
+
+
+Section 1 -- Definitions.
+
+  a. Adapted Material means material subject to Copyright and Similar
+ Rights that is derived from or based upon the Licensed Material
+ and in which the Licensed Material is translated, altered,
+ arranged, transformed, or otherwise modified in a manner requiring
+ permission under the Copyright and Similar Rights held by the
+ Licensor. For purposes of this Public License, where the Licensed
+ Material is a musical work, performance, or sound recording,
+ Adapted Material is always produced where the Licensed Material is
+ synched in timed relation with a moving image.
+
+  b. 

Re: Adding RTEMS_INTERRUPTED

2019-10-06 Thread Sebastian Huber

Hallo Joel,

I am in favour of RTEMS_INTERRUPTED and not RTEMS_EINTER since 
abbreviations are not used in the Classic API in general.



--
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: Use YAML configuration files for the build?

2019-10-04 Thread Sebastian Huber
- Am 4. Okt 2019 um 19:41 schrieb joel j...@rtems.org:

> On Fri, Oct 4, 2019 at 12:25 PM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> 
>> - Am 4. Okt 2019 um 16:15 schrieb joel j...@rtems.org:
>>
>> > On Fri, Oct 4, 2019 at 8:29 AM Sebastian Huber <
>> > sebastian.hu...@embedded-brains.de> wrote:
>> >
>> >> Hello,
>> >>
>> >> I would like to use YAML configuration files for the new build system.
>> >>
>> >
>> > For what purpose?
>>
>> To store the items which define what and how the build is done, e.g. BSPs,
>> BSP options, libraries, file groups for libraries, test programs.
>>
> 
> pkgconfig type information?

No, not pkgconfig type information.

> 
> Would this all be generated or a manually prepared input?

The YAML files are not generated, they have to be filled manually with the help 
of Doorstop.

> 
> 
>>
>> > To achieve what end?
>>
>> Make it possible to re-use the build specification, e.g. generate
>> documentation of the BSP options for the user manual.
>>
> 
> Sounds like pkgconfig in Yaml format.
> 
> Is it different?

I don't know why you picked up pkgconfig.  The pkgconfig support for a BSP 
could be an artefact of the build process.

At the moment I just would like to know if a PyYAML dependency would be an 
issue. I will try to explain later in detail why I would like to use it.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: Use YAML configuration files for the build?

2019-10-04 Thread Sebastian Huber
- Am 4. Okt 2019 um 16:15 schrieb joel j...@rtems.org:

> On Fri, Oct 4, 2019 at 8:29 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> 
>> Hello,
>>
>> I would like to use YAML configuration files for the new build system.
>>
> 
> For what purpose?

To store the items which define what and how the build is done, e.g. BSPs, BSP 
options, libraries, file groups for libraries, test programs.

> To achieve what end?

Make it possible to re-use the build specification, e.g. generate documentation 
of the BSP options for the user manual.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


How to build multiple BSPs with waf?

2019-10-04 Thread Sebastian Huber

Hello,

I tried to figure how a standard waf build can be configured so that 
out-of-tree or multiple build trees can be used. I couldn't get this 
working.


The Samba project seems to have support for out-of-tree builds:

https://wiki.samba.org/index.php/Waf#Out_of_tree_builds

However, this '-b' option is not present in a standard waf.

The libbsd uses a common build tree for a list of arch/bsp combinations. 
This seems to be quite a resource hungry solution. For example, I am not 
able to build two BSPs with this approach on Windows/MSYS2.


Is there already a plan to build multiple BSPs (or one BSP with 
different options) with waf?


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

Use YAML configuration files for the build?

2019-10-04 Thread Sebastian Huber

Hello,

I would like to use YAML configuration files for the new build system. 
The reason for this is that Doorstop uses this file format and I would 
like to maintain the build specification with Doorstop. The problem is 
that that a YAML encoder/decoder is not included in the standard Python 
library. So, everyone building RTEMS would be required to install the 
PyYAML package. On a Linux distribution this should be easily available. 
It can be also installed via "pip install pyyaml".


--
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] ttest01: Adjust SPDX-License-Identifier

2019-10-04 Thread Sebastian Huber
Update #3199.
---
 testsuites/libtests/ttest01/test-example.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/testsuites/libtests/ttest01/test-example.c 
b/testsuites/libtests/ttest01/test-example.c
index bcbf7b33b0..0e68b014c9 100644
--- a/testsuites/libtests/ttest01/test-example.c
+++ b/testsuites/libtests/ttest01/test-example.c
@@ -24,8 +24,7 @@ T_TEST_OUTPUT(example,
 "E:example:N:5:F:4:D:0.001000\n");
 
 /*
- * SPDX-License-Identifier: BSD-2-Clause
- * SPDX-License-Identifier: CC-BY-SA-4.0
+ * SPDX-License-Identifier: BSD-2-Clause OR CC-BY-SA-4.0
  *
  * Copyright (C) 2018, 2019 embedded brains GmbH
  *
-- 
2.16.4

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


[PATCH 3/3] linkersets: Avoid use of zero-length array

2019-10-04 Thread Sebastian Huber
Use RTEMS_DEFINE_GLOBAL_SYMBOL_IN_SECTION() instead.
---
 cpukit/include/rtems/linkersets.h | 34 ++
 1 file changed, 22 insertions(+), 12 deletions(-)

diff --git a/cpukit/include/rtems/linkersets.h 
b/cpukit/include/rtems/linkersets.h
index bad046999c..4a23d7a696 100644
--- a/cpukit/include/rtems/linkersets.h
+++ b/cpukit/include/rtems/linkersets.h
@@ -28,14 +28,19 @@ extern "C" {
   _Linker_set_##set##_end
 
 #define RTEMS_LINKER_ROSET_DECLARE( set, type ) \
-  extern type const RTEMS_LINKER_SET_BEGIN( set )[0]; \
-  extern type const RTEMS_LINKER_SET_END( set )[0]
+  extern type const RTEMS_LINKER_SET_BEGIN( set )[]; \
+  extern type const RTEMS_LINKER_SET_END( set )[]
 
 #define RTEMS_LINKER_ROSET( set, type ) \
-  type const RTEMS_LINKER_SET_BEGIN( set )[0] \
-  RTEMS_SECTION( ".rtemsroset." #set ".begin" ) RTEMS_USED; \
-  type const RTEMS_LINKER_SET_END( set )[0] \
-  RTEMS_SECTION( ".rtemsroset." #set ".end" ) RTEMS_USED
+  RTEMS_LINKER_ROSET_DECLARE( set, type ); \
+  RTEMS_DEFINE_GLOBAL_SYMBOL_IN_SECTION( \
+RTEMS_LINKER_SET_BEGIN( set ), \
+".rtemsroset." #set ".begin" \
+  ); \
+  RTEMS_DEFINE_GLOBAL_SYMBOL_IN_SECTION( \
+RTEMS_LINKER_SET_END( set ), \
+".rtemsroset." #set ".end" \
+  )
 
 #define RTEMS_LINKER_ROSET_ITEM_DECLARE( set, type, item ) \
   extern type const _Linker_set_##set##_##item
@@ -59,14 +64,19 @@ extern "C" {
   RTEMS_SECTION( ".rtemsroset." #set ".content" )
 
 #define RTEMS_LINKER_RWSET_DECLARE( set, type ) \
-  extern type RTEMS_LINKER_SET_BEGIN( set )[0]; \
-  extern type RTEMS_LINKER_SET_END( set )[0]
+  extern type RTEMS_LINKER_SET_BEGIN( set )[]; \
+  extern type RTEMS_LINKER_SET_END( set )[]
 
 #define RTEMS_LINKER_RWSET( set, type ) \
-  type RTEMS_LINKER_SET_BEGIN( set )[0] \
-  RTEMS_SECTION( ".rtemsrwset." #set ".begin" ) RTEMS_USED; \
-  type RTEMS_LINKER_SET_END( set )[0] \
-  RTEMS_SECTION( ".rtemsrwset." #set ".end" ) RTEMS_USED
+  RTEMS_LINKER_RWSET_DECLARE( set, type ); \
+  RTEMS_DEFINE_GLOBAL_SYMBOL_IN_SECTION( \
+RTEMS_LINKER_SET_BEGIN( set ), \
+".rtemsrwset." #set ".begin" \
+  ); \
+  RTEMS_DEFINE_GLOBAL_SYMBOL_IN_SECTION( \
+RTEMS_LINKER_SET_END( set ), \
+".rtemsrwset." #set ".end" \
+  )
 
 #define RTEMS_LINKER_RWSET_ITEM_DECLARE( set, type, item ) \
   extern type _Linker_set_##set##_##item
-- 
2.16.4

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


[PATCH 1/3] score: Add RTEMS_DEFINE_GLOBAL_SYMBOL_IN_SECTION()

2019-10-04 Thread Sebastian Huber
Update #3799.
---
 cpukit/include/rtems/score/basedefs.h | 19 +++
 testsuites/sptests/spmisc01/init.c|  7 +++
 2 files changed, 26 insertions(+)

diff --git a/cpukit/include/rtems/score/basedefs.h 
b/cpukit/include/rtems/score/basedefs.h
index 782958920c..5f38559b6d 100644
--- a/cpukit/include/rtems/score/basedefs.h
+++ b/cpukit/include/rtems/score/basedefs.h
@@ -343,6 +343,25 @@
   #define RTEMS_DEFINE_GLOBAL_SYMBOL( _name, _value )
 #endif
 
+/**
+ * @brief Defines a global symbol with the specified name in the specified
+ * section.
+ *
+ * The name must be a valid designator.
+ */
+#if defined(__GNUC__)
+  #define RTEMS_DEFINE_GLOBAL_SYMBOL_IN_SECTION( _name, _section ) \
+__asm__( \
+  ".pushsection \"" _section "\"\n" \
+  "\t.globl " \
+  RTEMS_XSTRING( RTEMS_XCONCAT( __USER_LABEL_PREFIX__, _name ) ) "\n" \
+  RTEMS_XSTRING( RTEMS_XCONCAT( __USER_LABEL_PREFIX__, _name ) ) ":\n" \
+  "\t.popsection\n" \
+)
+#else
+  #define RTEMS_DEFINE_GLOBAL_SYMBOL_IN_SECTION( _name, section )
+#endif
+
 /**
  * @brief Returns the value of the specified integral expression and tells the
  * compiler that the predicted value is true (1).
diff --git a/testsuites/sptests/spmisc01/init.c 
b/testsuites/sptests/spmisc01/init.c
index 9090069973..8d713c4219 100644
--- a/testsuites/sptests/spmisc01/init.c
+++ b/testsuites/sptests/spmisc01/init.c
@@ -99,6 +99,10 @@ RTEMS_DECLARE_GLOBAL_SYMBOL(a_global_symbol);
 
 RTEMS_DEFINE_GLOBAL_SYMBOL(a_global_symbol, 0xabc);
 
+RTEMS_DECLARE_GLOBAL_SYMBOL(a_second_symbol);
+
+RTEMS_DEFINE_GLOBAL_SYMBOL_IN_SECTION(a_second_symbol, ".rtemsroset.dummy");
+
 RTEMS_STATIC_ASSERT(0 != 1, zero_neq_one);
 
 static int array[3];
@@ -211,6 +215,9 @@ static void Init(rtems_task_argument arg)
   rtems_test_assert(printflike_func("%i", 0) == 56);
   rtems_test_assert(obfuscate_variable(63) == 63);
   rtems_test_assert((uintptr_t)a_global_symbol == 0xabc);
+  p = a_second_symbol;
+  RTEMS_OBFUSCATE_VARIABLE(p);
+  rtems_test_assert((uintptr_t)p != 0);
   rtems_test_assert(RTEMS_ARRAY_SIZE(array) == 3);
   rtems_test_assert(sizeof(zero_length_array_struct) == 4);
   container_of();
-- 
2.16.4

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


[PATCH 2/3] config: Avoid zero-length array

2019-10-04 Thread Sebastian Huber
Use RTEMS_DEFINE_GLOBAL_SYMBOL_IN_SECTION() instead.

Close #3799.
---
 cpukit/include/rtems/confdefs.h | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/cpukit/include/rtems/confdefs.h b/cpukit/include/rtems/confdefs.h
index 5eb5425283..4e6b91ad2c 100644
--- a/cpukit/include/rtems/confdefs.h
+++ b/cpukit/include/rtems/confdefs.h
@@ -1197,8 +1197,10 @@ extern rtems_initialization_tasks_table 
Initialization_tasks[];
   ] RTEMS_ALIGNED( CPU_INTERRUPT_STACK_ALIGNMENT )
   RTEMS_SECTION( ".rtemsstack.interrupt.begin" );
 
-  const char _ISR_Stack_area_end[ 0 ]
-RTEMS_SECTION( ".rtemsstack.interrupt.end" ) = { };
+  RTEMS_DEFINE_GLOBAL_SYMBOL_IN_SECTION(
+_ISR_Stack_area_end,
+".rtemsstack.interrupt.end"
+  );
 #endif
 
 /**
-- 
2.16.4

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


Re: How to build start.o using waf?

2019-10-04 Thread Sebastian Huber

On 04/10/2019 09:20, Chris Johns wrote:

On 4/10/19 4:21 pm, Sebastian Huber wrote:

On 03/10/2019 04:32, Chris Johns wrote:

On 3/10/19 3:30 am, Gedare Bloom wrote:

On Wed, Oct 2, 2019 at 5:12 AM Sebastian Huber
 wrote:


On 30/09/2019 15:14, Sebastian Huber wrote:

Hello,

I would like to work on a new build system prototype. The idea is to use
specification items maintained by Doorstop (YAML files), a Python
configuration script and waf to build RTEMS and the tests. This is
similar to the libbsd build. The difference is that in libbsd the build
data is maintained directly in Python code (libbsd.py).


A key design aspect is how the configuration of RTEMS is handled and maintained.
Amar's solution provides a specific model for managing settings and specifically
BSP options. We need a way to add options for a BSP that lets us collect,
document and validate these settings. We need a way to query and review option
defaults. The solution needs to be able to add and remove BSPs with minimal
impact and this leads to being able to build a BSP that is external to the RTEMS
source tree. There are BSPs that are private or export restricted. Another issue
to consider is how we deprecate, update or alter options.

I suspect we will have an iterating design around the internal design and
implementation complexity and suitable external user work-flows.


Now is a good time to create a wish list for the new build system. I cannot
implement everything, but I can try to make a substantial initial step forward.


I agree.


Doorstop is a tool to manage a directed, acyclic graph of items. Each item has a
set of attributes (key-value pairs). Some attributes are pre-defined by Doorstop
with requirements management in mind. You can also add an arbitrary number of
custom attributes. With this data structure you can tackle a lot of problems.
The items are stored in YAML format files.


Note YAML is not part of the standard Python, it is add-on package. This means
using it would mean we would need to provide support on a number of hosts.


The libyaml package seems to be used in a lot of other packages and can 
be installed with pip. If the use of YAML for the build would be a show 
stopper for you, it would be good to know this early.





My approach would be to store all the data that defines the build in build item
files. The wscript file reads the build items, configures the build and performs
the build as specified also by command line options, e.g. which BSP, with tests,
etc. The build item files can be also used by other tools.

A BSP is represented by a BSP build item which links to BSP option items, object
items (start.o) and file groups for librtemsbsp.a.

A BSP is just a node in the graph, you can ask for example: if I remove this BSP
item, does it create isolated items? The isolated items can be removed if the
BSP is removed. If you change an option, you can figure out the impact, e.g.
which BSP uses this option.


I had not considered going to level but what you say seems consistent with my
thinking on how configuration should happen. With out the detail it is hard so I
will make a general statement that a change to the build system has to serve the
general RTEMS community first and this means easy to access and manage
configurations generated by RTEMS. I ask RTEMS to configure a BSP and a
configuration file is generated. I can then edit the file to alter specific
settings I need. The is what Amar did.


My approach would be to configure the build via command line options and 
then the configuration is read-only for the build. Being able to alter 
an existing configuration seems a bit complex to me.




And I do not see Doorstop as a part of the general community :)


You would not need Doorstop to build a BSP, just to maintain a BSP.




Since the build is driven by item files which just reside in a directory, you
can also point the build script to another directory with items defined
externally. The question is if waf is capable to build files outside the top
directory. Building externally defined stuff has a very low priority for me. I
just want to point out that there are no fundamental obstacles with this 
approach.


Yes this is an issue and something I would need to discuss with Thomas.


The details of BSP options can be easily managed with specialized attributes,
e.g. type, min, max, default value, etc. We can utilize the full power of

https://docs.python.org/3.6/library/optparse.html

which is a very nice Python module. We may use

https://docs.python.org/3.6/library/optparse.html#optparse-option-callbacks



Sure ...


to provide services we need for this BSP (and others):

https://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/atsam/configure.ac

The callbacks can be stored in the items files as Python code and imported with
exec(). The callbacks need an ability to install a post-processing handler which
is invoked during the waf configure(), e.g. to generate the linker command file
based on options

Re: Testing the interrupt extension API?

2019-10-04 Thread Sebastian Huber



On 03/10/2019 07:44, Chris Johns wrote:

On 2/10/19 5:28 pm, Sebastian Huber wrote:

the interrupt extension API implementation is already quite complex and not
covered by the test suite:

https://git.rtems.org/rtems/tree/bsps/shared/irq

In order to write generic tests for this we have to know which interrupt vector
can be controlled by software.


Do I assume the testsuite's tests are for hard IP resources?


The test would only use interrupts which are not connected to a peripheral.



One approach would be to add an

rtems_interrupt_get_capabilities() function:


It would be nice to be able to add and remove entries based on soft IP that can
be runtime loaded. :)


Every BSP needs to implement this function on their own.

--
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: Testing the interrupt extension API?

2019-10-04 Thread Sebastian Huber

On 02/10/2019 19:44, Gedare Bloom wrote:

On Wed, Oct 2, 2019 at 1:28 AM Sebastian Huber
 wrote:


Hello,

the interrupt extension API implementation is already quite complex and
not covered by the test suite:

https://git.rtems.org/rtems/tree/bsps/shared/irq

In order to write generic tests for this we have to know which interrupt
vector can be controlled by software. One approach would be to add an
rtems_interrupt_get_capabilities() function:

/**
   * @brief A bit field indicating interrupt capabilities.
   */

I don't care for the term 'capabilities' here, maybe 'attributes' is
OK? Can we overload these fields onto rtems_attribute?


Yes, attributes is better.




typedef struct {
/**
 * @brief Is set, if the interrupt can be enabled through
 * rtems_interrupt_vector_enable(), otherwise cleared.
 */
unsigned int can_enable : 1;

/**
 * @brief Is set, if the interrupt can be enabled through
 * rtems_interrupt_vector_enable(), otherwise cleared.

disabled / disable()

 */
unsigned int can_disable : 1;

Curious: are there vectors that can be enabled but not disabled (or vice versa)?


Probably not.





/**
 * @brief Is set, if the interrupt can be raised through
 * rtems_interrupt_raise(), otherwise cleared.
 */
unsigned int can_raise : 1;

/**
 * @brief Is set, if the interrupt can be cleared through
 * rtems_interrupt_clear(), otherwise cleared.
 */
unsigned int can_clear : 1;

/**
 * @brief Is set, if the interrupt supports a setting of its priority
through
 * rtems_interrupt_set_priority(), otherwise cleared.
 */
unsigned int can_set_priority : 1;

/**
 * @brief Is set, if the interrupt supports a setting of its processor
 * affinity through rtems_interrupt_set_affinity(), otherwise cleared.
 */
unsigned int can_set_affinity : 1;

/**
 * @brief Is set, if the interrupt has a pending state which can be
obtained
 * through rtems_interrupt_is_pending(), otherwise cleared.
 */
unsigned int has_pending_state : 1;

This is strange wording, because it implies a currently pending state.
Maybe, "can_be_pending"?



/**
 * @brief Is set, if the interrupt has an active state which can be
obtained
 * through rtems_interrupt_is_active(), otherwise cleared.
 */
unsigned int has_active_state : 1;

ditto: can_be_active?


Yes, sounds good.





/**
 * @brief Is set, if the interrupt is connected to a peripheral,
otherwise
 * cleared.
 */
unsigned int has_peripheral : 1;


I guess this one is more a statement of fact.


What do you mean by this?

We have to know if an interrupt is connected to a peripheral function. 
Since these interrupts must not be used by a generic test. The generic 
test has no idea in which state a peripheral is.





/**
 * @brief Is set, if the interrupt must be raised through
 * rtems_interrupt_raise_on(), otherwise cleared.
 */
unsigned int needs_target : 1;

/**
 * @brief Is set, if the interrupt is triggered by a raising signal edge,
 * otherwise cleared.
 */
unsigned int is_raising_edge_triggered : 1;

/**
 * @brief Is set, if the interrupt is triggered by a falling signal edge,
 * otherwise cleared.
 */
unsigned int is_falling_edge_triggered : 1;

/**
 * @brief Is set, if the interrupt is triggered by a low signal level,
 * otherwise cleared.
 */
unsigned int is_low_level_triggered : 1;

/**
 * @brief Is set, if the interrupt is triggered by a high signal level,
 * otherwise cleared.
 */
unsigned int is_high_level_triggered : 1;
} rtems_interrupt_capabilities;

/**
   * @brief Gets the capabilities of the specified interrupt.
   *
   * @retval RTEMS_SUCCESSFUL Successful operation.
   * @retval RTEMS_INVALID_ID The specified vector number is invalid.
   */
rtems_status_code rtems_interrupt_get_capabilities(
rtems_vector_number vector,
rtems_interrupt_capabilities *capabilities
);

Interrupts with cap.can_raise set and cap.has_peripheral cleared can be
safely software controlled and used for tests.

Why not just have an "is_software_triggered"?


As a replacement for has_peripheral?

--
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 2/3] Add hook for BSP to act when time is set

2019-10-04 Thread Sebastian Huber

On 04/10/2019 08:06, Chris Johns wrote:

On 4/10/19 3:10 pm, Sebastian Huber wrote:

On 04/10/2019 04:44, Chris Johns wrote:

Is this only useful for virtual BSPs and is it always a requirement to implement
this call in those environments?

Would this call be useful to a non-virtual BSP, for example one with a battery
backed RTC device?

Would a hook API along the lines of 

typedef int (*_TOD_Set_Handler)(const struct timespec *tod);
   _TOD_Set_Handler _TOD_Set_hook(_TOD_Set_Handler handler);

... be more flexible?

Yes, I think this should be generalized to allow RTC drivers to use this API as
well. I think it should be possible to install (and remove) more than one hook,
e.g.

typedef enum {
   TOD_ACTION_SET_CLOCK
} TOD_Action;

Nice.


typedef struct TOD_Hook {
   Chain_Node Node;
   int (*handler)(struct TOD_Handler *, TOD_Action, const struct timespec *);
} TOD_Hook;

I like the simpler interface of returning the current hook and specifying those
who obtain a hook call the returned hook pointer if it is not NULL. This way we
only need to hold a single pointer and there is no complexity around locking etc
to update a list as the hook holder has to deal with that locally.


We already have _TOD_Lock() which uses a full mutex. If you let the 
caller handle the potential chaining, then you may loose events.


--
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: Waf and Ada?

2019-10-04 Thread Sebastian Huber

On 04/10/2019 08:08, Chris Johns wrote:

On 4/10/19 3:17 pm, Sebastian Huber wrote:

On 03/10/2019 04:38, Chris Johns wrote:

On 2/10/19 9:21 pm, Sebastian Huber wrote:

the waf build prototype contains no examples for building Ada objects, libraries
and executables.

https://git.rtems.org/amar/waf-old.git/

Searching the internet revealed also nothing. It would be great to have an
example for building an Ada test executable (mix of C and Ada files).

The best way to handle this is to create a tool for Ada ...

https://gitlab.com/ita1024/waf/tree/master/waflib/Tools
https://github.com/BNLIF/waf-tools

I am sure Thomas would be happy to accept such a tool. He is on IRC #rtems as
ita.

Thanks for the hint. So, the Ada support for RTEMS first requires Ada support
for waf. I will probably work on this with a low priority.


It is not an absolute requirement however adding a tool upstream makes the long
term maintenance simpler for RTEMS.


Yes, this is definitely the way to go.

--
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 to build start.o using waf?

2019-10-04 Thread Sebastian Huber

On 03/10/2019 04:32, Chris Johns wrote:

On 3/10/19 3:30 am, Gedare Bloom wrote:

On Wed, Oct 2, 2019 at 5:12 AM Sebastian Huber
 wrote:


On 30/09/2019 15:14, Sebastian Huber wrote:

Hello,

I would like to work on a new build system prototype. The idea is to use
specification items maintained by Doorstop (YAML files), a Python
configuration script and waf to build RTEMS and the tests. This is
similar to the libbsd build. The difference is that in libbsd the build
data is maintained directly in Python code (libbsd.py).


A key design aspect is how the configuration of RTEMS is handled and maintained.
Amar's solution provides a specific model for managing settings and specifically
BSP options. We need a way to add options for a BSP that lets us collect,
document and validate these settings. We need a way to query and review option
defaults. The solution needs to be able to add and remove BSPs with minimal
impact and this leads to being able to build a BSP that is external to the RTEMS
source tree. There are BSPs that are private or export restricted. Another issue
to consider is how we deprecate, update or alter options.

I suspect we will have an iterating design around the internal design and
implementation complexity and suitable external user work-flows.


Now is a good time to create a wish list for the new build system. I 
cannot implement everything, but I can try to make a substantial initial 
step forward.


Doorstop is a tool to manage a directed, acyclic graph of items. Each 
item has a set of attributes (key-value pairs). Some attributes are 
pre-defined by Doorstop with requirements management in mind. You can 
also add an arbitrary number of custom attributes. With this data 
structure you can tackle a lot of problems. The items are stored in YAML 
format files.


My approach would be to store all the data that defines the build in 
build item files. The wscript file reads the build items, configures the 
build and performs the build as specified also by command line options, 
e.g. which BSP, with tests, etc. The build item files can be also used 
by other tools.


A BSP is represented by a BSP build item which links to BSP option 
items, object items (start.o) and file groups for librtemsbsp.a.


A BSP is just a node in the graph, you can ask for example: if I remove 
this BSP item, does it create isolated items? The isolated items can be 
removed if the BSP is removed. If you change an option, you can figure 
out the impact, e.g. which BSP uses this option.


Since the build is driven by item files which just reside in a 
directory, you can also point the build script to another directory with 
items defined externally. The question is if waf is capable to build 
files outside the top directory. Building externally defined stuff has a 
very low priority for me. I just want to point out that there are no 
fundamental obstacles with this approach.


The details of BSP options can be easily managed with specialized 
attributes, e.g. type, min, max, default value, etc. We can utilize the 
full power of


https://docs.python.org/3.6/library/optparse.html

which is a very nice Python module. We may use

https://docs.python.org/3.6/library/optparse.html#optparse-option-callbacks

to provide services we need for this BSP (and others):

https://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/atsam/configure.ac

The callbacks can be stored in the items files as Python code and 
imported with exec(). The callbacks need an ability to install a 
post-processing handler which is invoked during the waf configure(), 
e.g. to generate the linker command file based on options.


--
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 v2 3/3] ttest01: New test

2019-10-03 Thread Sebastian Huber

On 02/10/2019 19:48, Gedare Bloom wrote:

On Tue, Oct 1, 2019 at 10:52 PM Sebastian Huber
 wrote:


On 01/10/2019 23:40, Gedare Bloom wrote:

+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ * SPDX-License-Identifier: CC-BY-SA-4.0
+ *
+ * Copyright (C) 2018, 2019 embedded brains GmbH
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * Creative Commons Attribution-ShareAlike 4.0 International Public License as
+ * published by Creative Commons, PO Box 1866, Mountain View, CA 94042
+ * (https://creativecommons.org/licenses/by-sa/4.0/legalcode).
+ */

Is there any standing for dual-licensing 2BSD with CC-BY-SA?


diff --git a/testsuites/libtests/ttest01/ttest01.doc 
b/testsuites/libtests/ttest01/ttest01.doc
new file mode 100644
index 00..37d9ff8535
--- /dev/null
+++ b/testsuites/libtests/ttest01/ttest01.doc
@@ -0,0 +1,19 @@
+This file describes the directives and concepts tested by this test set.
+
+test set name: ttest01
+
+The test-*.c files must place the license header at the bottom of the file.
+This allows a copy and past of the test code into documentation sources and

paste


+enables a constent line numbering between the documentation code fragements and

constant ... fragments


+the actual test output.  For the same reason the T_TEST_OUTPUT() macros must be
+placed after the actual test cases.  The test source files are dual licensesd

licensed

+BSD-2-Clause and CC-BY-SA-4.0.
+

Thanks for the above explanation, it was helpful for this example. For
future tests, do you anticipate any text here such as a short
narrative description? Or this text should be deleted if it gets
copy-paste into new tests?


Everything which may end up in the documentation (such as code examples)
should be dual licensed BSD-2-Clause and CC-BY-SA-4.0 from my point of
view. Otherwise we would have to deal with BSD-2-Clause also in the
documentation set. Not every test needs this, just the one that may be
used in the documentation, e.g.

https://docs.rtems.org/branches/master/eng/test-framework.html#test-fixture


Yes, I understand, my point was that the explanation of this
dual-licensing doesn't need to exist in every dual-licensed test. It
just needs to be understood (by developers/test-writers, maybe users)


It is just in the ttest01.doc file. I think this should be enough.

Maybe we should change the

 * SPDX-License-Identifier: BSD-2-Clause
 * SPDX-License-Identifier: CC-BY-SA-4.0

in

 * SPDX-License-Identifier: BSD-2-Clause OR CC-BY-SA-4.0

since this seems to be the prevailing style in the Linux kernel for 
dual-licensed files.





I would like to add also code examples to the RTEMS Classic API Guide
for the managers (not in the next weeks).


Examples for using them? I can see this would be nice to dual-license.


Yes, examples for using them.




Another candidate for dual licensing are the interface specification
items. I would like to generate the API header files with Doxygen markup
and the API documentation from a single source - the interface
specification items.


I might have missed something. Do you mean there is plan for an
interface specification using something like an interface definition
language (IDL), and you would like to generate header files such as
include/rtems/rtems/task.h, from IDL? Or something else?


Yes, but not IDL. My proposal is to use Doorstop YAML files with 
specialized attributes (key-value pairs) for the API (e.g. 
rtems_task_create(), but not internal stuff like _Thread_Set_name()).


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 

Re: Waf and Ada?

2019-10-03 Thread Sebastian Huber

On 03/10/2019 04:38, Chris Johns wrote:

On 2/10/19 9:21 pm, Sebastian Huber wrote:


the waf build prototype contains no examples for building Ada objects, libraries
and executables.

https://git.rtems.org/amar/waf-old.git/

Searching the internet revealed also nothing. It would be great to have an
example for building an Ada test executable (mix of C and Ada files).


The best way to handle this is to create a tool for Ada ...

https://gitlab.com/ita1024/waf/tree/master/waflib/Tools
https://github.com/BNLIF/waf-tools

I am sure Thomas would be happy to accept such a tool. He is on IRC #rtems as 
ita.


Thanks for the hint. So, the Ada support for RTEMS first requires Ada 
support for waf. I will probably work on this with a low priority.


--
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 2/3] Add hook for BSP to act when time is set

2019-10-03 Thread Sebastian Huber

On 04/10/2019 04:44, Chris Johns wrote:

Is this only useful for virtual BSPs and is it always a requirement to implement
this call in those environments?

Would this call be useful to a non-virtual BSP, for example one with a battery
backed RTC device?

Would a hook API along the lines of 

typedef int (*_TOD_Set_Handler)(const struct timespec *tod);
  _TOD_Set_Handler _TOD_Set_hook(_TOD_Set_Handler handler);

... be more flexible?


Yes, I think this should be generalized to allow RTC drivers to use this 
API as well. I think it should be possible to install (and remove) more 
than one hook, e.g.


typedef enum {
  TOD_ACTION_SET_CLOCK
} TOD_Action;

typedef struct TOD_Hook {
  Chain_Node Node;
  int (*handler)(struct TOD_Handler *, TOD_Action, const struct 
timespec *);

} TOD_Hook;

--
Sebastian Huber, embedded brains GmbH

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

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

Re: [PATCH 1/3] rtems/confdefs.h add another initial extension set

2019-10-03 Thread Sebastian Huber

On 04/10/2019 00:08, Joel Sherrill wrote:

This adds back the capability for the BSP to configure an
initial extension that is specific to itself. The parameter
BSP_INITIAL_EXTENSION was taken over by having a standard
fatal extension installed using the same name.
---
  cpukit/include/rtems/confdefs.h | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/cpukit/include/rtems/confdefs.h b/cpukit/include/rtems/confdefs.h
index 5eb5425..e1a255a 100644
--- a/cpukit/include/rtems/confdefs.h
+++ b/cpukit/include/rtems/confdefs.h
@@ -2136,6 +2136,9 @@ extern rtems_initialization_tasks_table 
Initialization_tasks[];
  #if defined(CONFIGURE_INITIAL_EXTENSIONS)
CONFIGURE_INITIAL_EXTENSIONS,
  #endif
+#if defined(BSP_INITIAL2_EXTENSIONS)
+  BSP_INITIAL2_EXTENSIONS,
+#endif
  #if defined(BSP_INITIAL_EXTENSION)
BSP_INITIAL_EXTENSION
  #endif



I don't think this patch is necessary. A BSP is free to provide its own 
initial extension. Just don't add the


#include 

to the bsp.h.

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

Waf and Ada?

2019-10-02 Thread Sebastian Huber

Hello,

the waf build prototype contains no examples for building Ada objects, 
libraries and executables.


https://git.rtems.org/amar/waf-old.git/

Searching the internet revealed also nothing. It would be great to have 
an example for building an Ada test executable (mix of C and Ada files).


--
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 to build start.o using waf?

2019-10-02 Thread Sebastian Huber

On 30/09/2019 15:14, Sebastian Huber wrote:

Hello,

I would like to work on a new build system prototype. The idea is to use 
specification items maintained by Doorstop (YAML files), a Python 
configuration script and waf to build RTEMS and the tests. This is 
similar to the libbsd build. The difference is that in libbsd the build 
data is maintained directly in Python code (libbsd.py).


How do you build a singe object file (start.o) from assembly files in 
waf? An example would be great.


I think I found it in:

https://git.rtems.org/amar/waf-old.git/tree/py/waf/builder.py#n54

def start(self, source, defines=[]):
from os.path import splitext, basename

for s in source:
file = splitext(basename(s))[0]
self.ctx(
rule = '${CC} -DASM ${CFLAGS} ${CPPFLAGS} ${DEFINES_ST:DEFINES} 
${CPPPATH_ST:INCPATHS} -c -o ${TGT} ${SRC}',

source   = s,
target   = "%s.o" % file,
name = "start_%s_o" % file,
features = "c casm bld_include src_include",
defines  = defines,
    )


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

Testing the interrupt extension API?

2019-10-02 Thread Sebastian Huber

Hello,

the interrupt extension API implementation is already quite complex and 
not covered by the test suite:


https://git.rtems.org/rtems/tree/bsps/shared/irq

In order to write generic tests for this we have to know which interrupt 
vector can be controlled by software. One approach would be to add an 
rtems_interrupt_get_capabilities() function:


/**
 * @brief A bit field indicating interrupt capabilities.
 */
typedef struct {
  /**
   * @brief Is set, if the interrupt can be enabled through
   * rtems_interrupt_vector_enable(), otherwise cleared.
   */
  unsigned int can_enable : 1;

  /**
   * @brief Is set, if the interrupt can be enabled through
   * rtems_interrupt_vector_enable(), otherwise cleared.
   */
  unsigned int can_disable : 1;

  /**
   * @brief Is set, if the interrupt can be raised through
   * rtems_interrupt_raise(), otherwise cleared.
   */
  unsigned int can_raise : 1;

  /**
   * @brief Is set, if the interrupt can be cleared through
   * rtems_interrupt_clear(), otherwise cleared.
   */
  unsigned int can_clear : 1;

  /**
   * @brief Is set, if the interrupt supports a setting of its priority 
through

   * rtems_interrupt_set_priority(), otherwise cleared.
   */
  unsigned int can_set_priority : 1;

  /**
   * @brief Is set, if the interrupt supports a setting of its processor
   * affinity through rtems_interrupt_set_affinity(), otherwise cleared.
   */
  unsigned int can_set_affinity : 1;

  /**
   * @brief Is set, if the interrupt has a pending state which can be 
obtained

   * through rtems_interrupt_is_pending(), otherwise cleared.
   */
  unsigned int has_pending_state : 1;

  /**
   * @brief Is set, if the interrupt has an active state which can be 
obtained

   * through rtems_interrupt_is_active(), otherwise cleared.
   */
  unsigned int has_active_state : 1;

  /**
   * @brief Is set, if the interrupt is connected to a peripheral, 
otherwise

   * cleared.
   */
  unsigned int has_peripheral : 1;

  /**
   * @brief Is set, if the interrupt must be raised through
   * rtems_interrupt_raise_on(), otherwise cleared.
   */
  unsigned int needs_target : 1;

  /**
   * @brief Is set, if the interrupt is triggered by a raising signal edge,
   * otherwise cleared.
   */
  unsigned int is_raising_edge_triggered : 1;

  /**
   * @brief Is set, if the interrupt is triggered by a falling signal edge,
   * otherwise cleared.
   */
  unsigned int is_falling_edge_triggered : 1;

  /**
   * @brief Is set, if the interrupt is triggered by a low signal level,
   * otherwise cleared.
   */
  unsigned int is_low_level_triggered : 1;

  /**
   * @brief Is set, if the interrupt is triggered by a high signal level,
   * otherwise cleared.
   */
  unsigned int is_high_level_triggered : 1;
} rtems_interrupt_capabilities;

/**
 * @brief Gets the capabilities of the specified interrupt.
 *
 * @retval RTEMS_SUCCESSFUL Successful operation.
 * @retval RTEMS_INVALID_ID The specified vector number is invalid.
 */
rtems_status_code rtems_interrupt_get_capabilities(
  rtems_vector_number vector,
  rtems_interrupt_capabilities *capabilities
);

Interrupts with cap.can_raise set and cap.has_peripheral cleared can be 
safely software controlled and used for tests.


--
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 v3] user: Document patch review process

2019-10-02 Thread Sebastian Huber
---
v2:

* Added ticket comments to checklist for patches.

* Added checklist for patches step to figure:

http://www.plantuml.com/plantuml/uml/dL71Yjim4BthAnwcXuJYXRscXwRG7dhOiEosXq8kMdiSgskDtD4u8NzVUrH8sa0BFGYacVVUwBtPPlMYKnoSivjpcmyYdW-4Sve4JR_SCmBlsJF8vpCqGUWOw0JFxPwRr9CGAqQlJOzC4YY_MuJ6SPZHFSqgrBmE8Ikw90LN89_vc5vfWwew16j6hxNrgshfFnEtfd2j3KrewKZ3LfHYlajoCDtogK9Jx1RO_VmwzM4Wh9wiIvBHKlJSNbcxcV1-ZP2n-aPvxO3DnsG8eHzJ4BemJKN8Ay63wVH70WlrwzWkRGiXnHWKaNBsncwQ96tWmt0ks7_d1LoixV3Mx05_IH7r4MzsbgNvQAP8h2WpYebEKiIH98V4sA76lQdl-RTSkYL3toc95QkwhYiCWScK_szFC-VNRdPfxLpei7gyff-yXKIZKekNCmgFP5cFziIN1JrEkRyPlsTDfIZfEpKAeJ7be4bAtfoK8E7GgmE0XoahNWXjObgcURRoqvTF3y-8Fh3EX-JE0SIjiHqDkVpUqWsvyN8RWnaDdNDPq-ZSTdvDSVW9

v3:

* Add missing content from stray rebase commit.

 images/user/patch-review.png  | Bin 0 -> 63668 bytes
 images/user/patch-review.puml |  48 ++
 user/support/contrib.rst  | 111 --
 3 files changed, 156 insertions(+), 3 deletions(-)
 create mode 100644 images/user/patch-review.png
 create mode 100644 images/user/patch-review.puml

diff --git a/images/user/patch-review.png b/images/user/patch-review.png
new file mode 100644
index 
..40ee0a99894c03537c2f01f1296018b0f089c662
GIT binary patch
literal 63668
zcmZsDWmr^Qqqc=~2}pN?gmfby4FiaDgVN2=rF2M3Nr{w-l!!D)cMjdsL#H%+Yt-jG
z}I%gfE)Yp=cXt~KGR5Lrw#60}>lZehyHJ$-iT*6saUx9*Oh+yPg(ijzaYKg>{R
zZK#=pqo?glbLcJEm-a86O`tDdP?>sCSwf+XLL3~9wkGyaS36sFGY30dPC>F;x9+^R
zdae!q=lZSNpcs$z40UCPX-h6~MvRF4U!opiJ!^9M5%tO
zf5#d2O5?o~+a5ucQZkpCp!M5_EcOXx7}l>>)fF`~kbb(*Q79RrnLK)-P}#}0o~B<&
z_$C{sgL+fD%y$$9DUg1onxFZyF~EkljrZZ>o>pe9on4xx$?B_K|Hjo1PuAzW
z?^#Qo(aTTZd8)3sU}WS%vML0-JgUM_?OC$Dk6oT7Bwqv7
z=Bpf@D7lkqPrnDU*xaLGOoOO%S3Ga;BhG1BV-K0fi|g>wK?h`4@v3yWDloyF{8v
zGJ7+&#g-%T555Vtg8wiE79D9lRHruq05R})@z@oeb*H|>=%-`h$y=
z8V?Ml*{4shT0ClA#iLunCCIBw)wfaP6imKzrH?k#=~D^~TR+tC#@1MwTf^Vi;!Yvd
zpXz{bUx;Y)te2O66yKP$ysbX>!x&}jk@=N};~lM~wz~pPIMxk@+BC3AKj;@
z*fMPt>FSM}$H{hVtfb|=owc_5J7X8$TMCWQ9MZO%YLce>KEemm8(~KHqJ@YU)6w
zqNweM_DD=f$D81MKB9*N!X`ri?EdD5ZMW|r5FXV7#Sk=!H6yEsh)
z!!Y?L17TrN_7ggnU)@^CQL|W_-hc?*C*E!L+w>vZ+ycTurIZ9G{&=)S!RA@pj9`
z8$9Q!1IgWK-mz;+2Q3k4?RNP(g2|M`1{*
zDCYX+9_n-gd2cjou2m^V{T4(qT7
zI9*nIQ^%j{WaPBps)8}%d1W<*Uq6=nFp#)HN!tY7oTt0y?q691;I}3qZ
z#A9Ko0aT~2(;?t?>}6;G6^b8K0p2}{y}N=L3$bbZ4qo2g*u-49YB@4_3W=X}%FU<0
z+gbFzBOoMXWK+QLk$^B(E$%OMP*6~4e16Uxhv|Fq>+1SqH?I))9tSAgugdr0dwF^J
z$RZcZ^N;Ug@LX2BdxYQ*kj~D|^~v@-nu8=G1y7(+tW+oYsldq1VD4DPAfQWxN*
zbJ~nO`c&<5Z_-Onu5+^7LjBpZVHm7y>mDU2fTGIrrzCthFK?NPxDhzQHhAm7;~m5F?ijT!gue4KP_7u`K10#Lr*yri`>W8
zw?fzM`Ez{5(Yy-0r)2@@5Pa{<4mi26+tL2M$tN#KNl68Th;MEIOq#KUWo#=y{S$)jMy7-otDdf~Oj^`oV+
zBE2s7Jr%@vdwjnU+?cJcgcQE8|^5ct^`jj7t;a~4I)9}h$A2OXFm8y7c}uT1)>
zy1c2q-F@SAFt0K00pfwv+u?2(zqa$PlhnT3PR59xhoOp6QN0rDk=wfmUKm<#
zF(4x&6HO@&$~<@$ccZ*HR+P+PRNO`_g~EDeYZ^
z+a?+N=3u5*;nv2&(QvvLOD=BrE1WwUU0x^(^U2$RJ|?;*P*QIMCHs+5l>*5r8JLo=Koi&23P=UxHmq)ae;
ztpmXav3H;8^?5
zkGn%cz_sUh5Z6d$RDijE4kI94e{@L30
zo^dn0NCz@fUTlcC(4zX;2UC0jbmGcg1r=-wCNMa2b7ja>QVw2fUo|y{$}mMpZhhkB
z^jo}~55Rh1E)t)~9dJtOEVPe3j+Gg=4e1F-2bm>5nr;j>Mh=H2{k=}O_1aVu
zUJ{0HyM8q=FE@hIi>;eCuphrkV;H|Dy*Ic1$h)#c9{9l+Dt@NtBACqocll`jBPr
zbAyUl*r?*UAYQs3vt`;0E`A%UlHZ&_VuPX0-Me>bX==gXtwdz@LqUC=LwTu!W6E
z31```rLF|^Lyw(B`EY5f+~io@g9JW&;B(&?`D{I^z|1^!kS8Lo=6GI?1fhZC
znP=95HNpGJlq>b02Tk)}^IknKn*zFWWCW{g2aH`X?kkTM+mVq^)A+|kUFoJ=FU9O8
zv8By^kZ$36sZeP;I9jK_$j_jOr{kDR2|%0#(^a-n7vtHxJw|9B!R
zGUr-n963kh%v*vMp6^UnoFvR6)!rxFt9?daRI_JdsYQo}O@~Gpls8n;_#X0ec9J)K
zHT7}j3OO3s)5!FQfPAbz{;nCOgRfKsy!`vNa_tK@$k%eNb>%+muVDi
zcTV)a8A+7MAd`MVsul4xdc-5O53O_co5cnfnj*fJRUC9LxulJYnAK~YcM
z8~x@ogk|3=b`o;?Upf&!M_S9zr`Q@=BFJxCUS_gorF%i3(4Q{o*BnH>m_#O0m8YC$
zZhJoKE^9me3rSa_NO$Gxf`7JwoZoe0v)BLR?<4zJK;gM
z1P$u7m!L-TB{FZ;BT*;FKG`VsYPuxR*o=H^Mhh!wdmXRTx2HxYp+0q4m!e9B+t0NprfOVm?C0uUiRy((
zZ9%zM?w|Q9prbaf}I&!(X7{KI#ji(W|saRIN{kW4=Iza_it=rB2v
zU_$1b6aSw|{`U5}VUd4fe9fJm*zZR38{Mtq!TJkYop%TCk7Y0n;VE5XNCNXOySVCVunA
zqS3GhU#G!G2L=3J-5kZrlK^V!v9((3!hJjDW)RIZ3V5vV08Z2lc@7Mf?J
zDV6;0MA^zrb;5UBoiHO?SxI45eH^<|?9nojsEQezIFi>^q1q>{6apV$YV|Exb
zbJmZ1W+)uZ)Q%xxTv(dSPUlI;^unL
zswXQT@a>aM`Nr|)<1g_FiCb7?6VSE(xKHXvp*xSc>FH}gH}CC^79x|APp>W<
zRev>remmKob~5tiwVNn4jDQTpWE>p46ZP?+oFR9Z5g4iWz9?xlr27^D7I(%!%?SGN

[PATCH v2] user: Document patch review process

2019-10-02 Thread Sebastian Huber
---
v2:

* Added ticket comments to checklist for patches.

* Added checklist for patches step to figure:

http://www.plantuml.com/plantuml/uml/dL71Yjim4BthAnwcXuJYXRscXwRG7dhOiEosXq8kMdiSgskDtD4u8NzVUrH8sa0BFGYacVVUwBtPPlMYKnoSivjpcmyYdW-4Sve4JR_SCmBlsJF8vpCqGUWOw0JFxPwRr9CGAqQlJOzC4YY_MuJ6SPZHFSqgrBmE8Ikw90LN89_vc5vfWwew16j6hxNrgshfFnEtfd2j3KrewKZ3LfHYlajoCDtogK9Jx1RO_VmwzM4Wh9wiIvBHKlJSNbcxcV1-ZP2n-aPvxO3DnsG8eHzJ4BemJKN8Ay63wVH70WlrwzWkRGiXnHWKaNBsncwQ96tWmt0ks7_d1LoixV3Mx05_IH7r4MzsbgNvQAP8h2WpYebEKiIH98V4sA76lQdl-RTSkYL3toc95QkwhYiCWScK_szFC-VNRdPfxLpei7gyff-yXKIZKekNCmgFP5cFziIN1JrEkRyPlsTDfIZfEpKAeJ7be4bAtfoK8E7GgmE0XoahNWXjObgcURRoqvTF3y-8Fh3EX-JE0SIjiHqDkVpUqWsvyN8RWnaDdNDPq-ZSTdvDSVW9

 images/user/patch-review.png  | Bin 0 -> 63668 bytes
 images/user/patch-review.puml |  48 
 user/support/contrib.rst  |  71 +-
 3 files changed, 105 insertions(+), 14 deletions(-)
 create mode 100644 images/user/patch-review.png
 create mode 100644 images/user/patch-review.puml

diff --git a/images/user/patch-review.png b/images/user/patch-review.png
new file mode 100644
index 
..40ee0a99894c03537c2f01f1296018b0f089c662
GIT binary patch
literal 63668
zcmZsDWmr^Qqqc=~2}pN?gmfby4FiaDgVN2=rF2M3Nr{w-l!!D)cMjdsL#H%+Yt-jG
z}I%gfE)Yp=cXt~KGR5Lrw#60}>lZehyHJ$-iT*6saUx9*Oh+yPg(ijzaYKg>{R
zZK#=pqo?glbLcJEm-a86O`tDdP?>sCSwf+XLL3~9wkGyaS36sFGY30dPC>F;x9+^R
zdae!q=lZSNpcs$z40UCPX-h6~MvRF4U!opiJ!^9M5%tO
zf5#d2O5?o~+a5ucQZkpCp!M5_EcOXx7}l>>)fF`~kbb(*Q79RrnLK)-P}#}0o~B<&
z_$C{sgL+fD%y$$9DUg1onxFZyF~EkljrZZ>o>pe9on4xx$?B_K|Hjo1PuAzW
z?^#Qo(aTTZd8)3sU}WS%vML0-JgUM_?OC$Dk6oT7Bwqv7
z=Bpf@D7lkqPrnDU*xaLGOoOO%S3Ga;BhG1BV-K0fi|g>wK?h`4@v3yWDloyF{8v
zGJ7+&#g-%T555Vtg8wiE79D9lRHruq05R})@z@oeb*H|>=%-`h$y=
z8V?Ml*{4shT0ClA#iLunCCIBw)wfaP6imKzrH?k#=~D^~TR+tC#@1MwTf^Vi;!Yvd
zpXz{bUx;Y)te2O66yKP$ysbX>!x&}jk@=N};~lM~wz~pPIMxk@+BC3AKj;@
z*fMPt>FSM}$H{hVtfb|=owc_5J7X8$TMCWQ9MZO%YLce>KEemm8(~KHqJ@YU)6w
zqNweM_DD=f$D81MKB9*N!X`ri?EdD5ZMW|r5FXV7#Sk=!H6yEsh)
z!!Y?L17TrN_7ggnU)@^CQL|W_-hc?*C*E!L+w>vZ+ycTurIZ9G{&=)S!RA@pj9`
z8$9Q!1IgWK-mz;+2Q3k4?RNP(g2|M`1{*
zDCYX+9_n-gd2cjou2m^V{T4(qT7
zI9*nIQ^%j{WaPBps)8}%d1W<*Uq6=nFp#)HN!tY7oTt0y?q691;I}3qZ
z#A9Ko0aT~2(;?t?>}6;G6^b8K0p2}{y}N=L3$bbZ4qo2g*u-49YB@4_3W=X}%FU<0
z+gbFzBOoMXWK+QLk$^B(E$%OMP*6~4e16Uxhv|Fq>+1SqH?I))9tSAgugdr0dwF^J
z$RZcZ^N;Ug@LX2BdxYQ*kj~D|^~v@-nu8=G1y7(+tW+oYsldq1VD4DPAfQWxN*
zbJ~nO`c&<5Z_-Onu5+^7LjBpZVHm7y>mDU2fTGIrrzCthFK?NPxDhzQHhAm7;~m5F?ijT!gue4KP_7u`K10#Lr*yri`>W8
zw?fzM`Ez{5(Yy-0r)2@@5Pa{<4mi26+tL2M$tN#KNl68Th;MEIOq#KUWo#=y{S$)jMy7-otDdf~Oj^`oV+
zBE2s7Jr%@vdwjnU+?cJcgcQE8|^5ct^`jj7t;a~4I)9}h$A2OXFm8y7c}uT1)>
zy1c2q-F@SAFt0K00pfwv+u?2(zqa$PlhnT3PR59xhoOp6QN0rDk=wfmUKm<#
zF(4x&6HO@&$~<@$ccZ*HR+P+PRNO`_g~EDeYZ^
z+a?+N=3u5*;nv2&(QvvLOD=BrE1WwUU0x^(^U2$RJ|?;*P*QIMCHs+5l>*5r8JLo=Koi&23P=UxHmq)ae;
ztpmXav3H;8^?5
zkGn%cz_sUh5Z6d$RDijE4kI94e{@L30
zo^dn0NCz@fUTlcC(4zX;2UC0jbmGcg1r=-wCNMa2b7ja>QVw2fUo|y{$}mMpZhhkB
z^jo}~55Rh1E)t)~9dJtOEVPe3j+Gg=4e1F-2bm>5nr;j>Mh=H2{k=}O_1aVu
zUJ{0HyM8q=FE@hIi>;eCuphrkV;H|Dy*Ic1$h)#c9{9l+Dt@NtBACqocll`jBPr
zbAyUl*r?*UAYQs3vt`;0E`A%UlHZ&_VuPX0-Me>bX==gXtwdz@LqUC=LwTu!W6E
z31```rLF|^Lyw(B`EY5f+~io@g9JW&;B(&?`D{I^z|1^!kS8Lo=6GI?1fhZC
znP=95HNpGJlq>b02Tk)}^IknKn*zFWWCW{g2aH`X?kkTM+mVq^)A+|kUFoJ=FU9O8
zv8By^kZ$36sZeP;I9jK_$j_jOr{kDR2|%0#(^a-n7vtHxJw|9B!R
zGUr-n963kh%v*vMp6^UnoFvR6)!rxFt9?daRI_JdsYQo}O@~Gpls8n;_#X0ec9J)K
zHT7}j3OO3s)5!FQfPAbz{;nCOgRfKsy!`vNa_tK@$k%eNb>%+muVDi
zcTV)a8A+7MAd`MVsul4xdc-5O53O_co5cnfnj*fJRUC9LxulJYnAK~YcM
z8~x@ogk|3=b`o;?Upf&!M_S9zr`Q@=BFJxCUS_gorF%i3(4Q{o*BnH>m_#O0m8YC$
zZhJoKE^9me3rSa_NO$Gxf`7JwoZoe0v)BLR?<4zJK;gM
z1P$u7m!L-TB{FZ;BT*;FKG`VsYPuxR*o=H^Mhh!wdmXRTx2HxYp+0q4m!e9B+t0NprfOVm?C0uUiRy((
zZ9%zM?w|Q9prbaf}I&!(X7{KI#ji(W|saRIN{kW4=Iza_it=rB2v
zU_$1b6aSw|{`U5}VUd4fe9fJm*zZR38{Mtq!TJkYop%TCk7Y0n;VE5XNCNXOySVCVunA
zqS3GhU#G!G2L=3J-5kZrlK^V!v9((3!hJjDW)RIZ3V5vV08Z2lc@7Mf?J
zDV6;0MA^zrb;5UBoiHO?SxI45eH^<|?9nojsEQezIFi>^q1q>{6apV$YV|Exb
zbJmZ1W+)uZ)Q%xxTv(dSPUlI;^unL
zswXQT@a>aM`Nr|)<1g_FiCb7?6VSE(xKHXvp*xSc>FH}gH}CC^79x|APp>W<
zRev>remmKob~5tiwVNn4jDQTpWE>p46ZP?+oFR9Z5g4iWz9?xlr27^D7I(%!%?SGN

[PATCH 1/2] libtest: Add more action events

2019-10-02 Thread Sebastian Huber
This allows more control over the initialization and finalization run.

Update #3199.
---
 cpukit/include/t.h  |  6 --
 cpukit/libtest/t-test-hash-sha256.c |  4 ++--
 cpukit/libtest/t-test-rtems-fds.c   |  2 +-
 cpukit/libtest/t-test-rtems-heap.c  |  2 +-
 cpukit/libtest/t-test-rtems-objs.c  | 20 ++--
 cpukit/libtest/t-test.c | 18 ++
 6 files changed, 28 insertions(+), 24 deletions(-)

diff --git a/cpukit/include/t.h b/cpukit/include/t.h
index 5dbf1e00b5..ec806a1f68 100644
--- a/cpukit/include/t.h
+++ b/cpukit/include/t.h
@@ -2185,12 +2185,14 @@ void T_free(void *);
 void T_register(void);
 
 typedef enum {
-   T_EVENT_RUN_INITIALIZE,
+   T_EVENT_RUN_INITIALIZE_EARLY,
+   T_EVENT_RUN_INITIALIZE_LATE,
T_EVENT_CASE_EARLY,
T_EVENT_CASE_BEGIN,
T_EVENT_CASE_END,
T_EVENT_CASE_LATE,
-   T_EVENT_RUN_FINALIZE
+   T_EVENT_RUN_FINALIZE_EARLY,
+   T_EVENT_RUN_FINALIZE_LATE
 } T_event;
 
 typedef void (*T_action)(T_event, const char *);
diff --git a/cpukit/libtest/t-test-hash-sha256.c 
b/cpukit/libtest/t-test-hash-sha256.c
index c272da27ac..4793a508e5 100644
--- a/cpukit/libtest/t-test-hash-sha256.c
+++ b/cpukit/libtest/t-test-hash-sha256.c
@@ -88,10 +88,10 @@ T_report_hash_sha256(T_event event, const char *name)
(void)name;
 
switch (event) {
-   case T_EVENT_RUN_INITIALIZE:
+   case T_EVENT_RUN_INITIALIZE_EARLY:
T_report_hash_sha256_initialize();
break;
-   case T_EVENT_RUN_FINALIZE:
+   case T_EVENT_RUN_FINALIZE_LATE:
T_report_hash_sha256_finalize();
break;
default:
diff --git a/cpukit/libtest/t-test-rtems-fds.c 
b/cpukit/libtest/t-test-rtems-fds.c
index 79720a01c4..19abbd3673 100644
--- a/cpukit/libtest/t-test-rtems-fds.c
+++ b/cpukit/libtest/t-test-rtems-fds.c
@@ -71,7 +71,7 @@ T_check_file_descriptors(T_event event, const char *name)
(void)name;
 
switch (event) {
-   case T_EVENT_RUN_INITIALIZE:
+   case T_EVENT_RUN_INITIALIZE_EARLY:
T_open_fds = T_count_open_fds();
break;
case T_EVENT_CASE_END:
diff --git a/cpukit/libtest/t-test-rtems-heap.c 
b/cpukit/libtest/t-test-rtems-heap.c
index 8858f5b952..6755e886b2 100644
--- a/cpukit/libtest/t-test-rtems-heap.c
+++ b/cpukit/libtest/t-test-rtems-heap.c
@@ -100,7 +100,7 @@ T_check_heap(T_event event, const char *name)
(void)name;
 
switch (event) {
-   case T_EVENT_RUN_INITIALIZE:
+   case T_EVENT_RUN_INITIALIZE_EARLY:
T_heap_run_initialize();
break;
case T_EVENT_CASE_END:
diff --git a/cpukit/libtest/t-test-rtems-objs.c 
b/cpukit/libtest/t-test-rtems-objs.c
index dd4f2d59d2..55da1ab850 100644
--- a/cpukit/libtest/t-test-rtems-objs.c
+++ b/cpukit/libtest/t-test-rtems-objs.c
@@ -94,7 +94,7 @@ T_check_rtems_barriers(T_event event, const char *name)
(void)name;
 
switch (event) {
-   case T_EVENT_RUN_INITIALIZE:
+   case T_EVENT_RUN_INITIALIZE_EARLY:
T_rtems_barriers_run_initialize();
break;
case T_EVENT_CASE_END:
@@ -127,7 +127,7 @@ T_check_rtems_extensions(T_event event, const char *name)
(void)name;
 
switch (event) {
-   case T_EVENT_RUN_INITIALIZE:
+   case T_EVENT_RUN_INITIALIZE_EARLY:
T_rtems_extensions_run_initialize();
break;
case T_EVENT_CASE_END:
@@ -160,7 +160,7 @@ T_check_rtems_message_queues(T_event event, const char 
*name)
(void)name;
 
switch (event) {
-   case T_EVENT_RUN_INITIALIZE:
+   case T_EVENT_RUN_INITIALIZE_EARLY:
T_rtems_message_queues_run_initialize();
break;
case T_EVENT_CASE_END:
@@ -193,7 +193,7 @@ T_check_rtems_partitions(T_event event, const char *name)
(void)name;
 
switch (event) {
-   case T_EVENT_RUN_INITIALIZE:
+   case T_EVENT_RUN_INITIALIZE_EARLY:
T_rtems_partitions_run_initialize();
break;
case T_EVENT_CASE_END:
@@ -226,7 +226,7 @@ T_check_rtems_periods(T_event event, const char *name)
(void)name;
 
switch (event) {
-   case T_EVENT_RUN_INITIALIZE:
+   case T_EVENT_RUN_INITIALIZE_EARLY:
T_rtems_periods_run_initialize();
break;
case T_EVENT_CASE_END:
@@ -259,7 +259,7 @@ T_check_rtems_regions(T_event event, const char *name)
(void)name;
 
switch (event) {
-   case T_EVENT_RUN_INITIALIZE:
+   case T_EVENT_RUN_INITIALIZE_EARLY:
T_rtems_regions_run_initialize();
break;
case T_EVENT_CASE_END:
@@ -292,7 +292,7 @@ T_check_rtems_semaphores(T_event event, const char *name)
(void)name;
 
switch (event) {
-   case T_EVENT_RUN_INITIALIZE:
+   case T_EVENT_RUN_INITIALIZE_EARLY:

[PATCH 2/2] ttest01: Check init/final run output

2019-10-02 Thread Sebastian Huber
Update #3199.
---
 testsuites/libtests/ttest01/init.c | 85 ++
 1 file changed, 85 insertions(+)

diff --git a/testsuites/libtests/ttest01/init.c 
b/testsuites/libtests/ttest01/init.c
index cb4ad95829..44ffadf112 100644
--- a/testsuites/libtests/ttest01/init.c
+++ b/testsuites/libtests/ttest01/init.c
@@ -45,11 +45,20 @@ const char rtems_test_name[] = "TTEST 1";
 
 RTEMS_LINKER_ROSET(t_self_test, const char *);
 
+typedef enum {
+   CENSOR_PASS_THROUGH,
+   CENSOR_DISCARD
+} censor_state;
+
 typedef struct {
const char *c;
size_t case_begin_count;
size_t case_end_count;
struct timecounter tc;
+   T_putchar putchar;
+   void *putchar_arg;
+   const char *censor_c;
+   censor_state censor_state;
 } test_context;
 
 static test_context test_instance;
@@ -113,6 +122,76 @@ case_late(const char *name)
ctx->c = NULL;
 }
 
+static const char censored_init[] = "A:ttest01\n"
+"S:Platform:RTEMS\n"
+"S:Compiler:*"
+"S:Version:*"
+"S:BSP:*"
+"S:RTEMS_DEBUG:*"
+"S:RTEMS_MULTIPROCESSING:*"
+"S:RTEMS_POSIX_API:*"
+"S:RTEMS_PROFILING:*"
+"S:RTEMS_SMP:*";
+
+static void
+censor_putchar(int c, void *arg)
+{
+   test_context *ctx;
+
+   ctx = arg;
+
+   if (*ctx->censor_c == '\0') {
+   T_putchar discard_putchar;
+   void *discard_putchar_arg;
+
+   (*ctx->putchar)(c, ctx->putchar_arg);
+   T_set_putchar(ctx->putchar, ctx->putchar_arg, _putchar,
+  _putchar_arg);
+   return;
+   }
+
+   switch (ctx->censor_state) {
+   case CENSOR_PASS_THROUGH:
+   if (*ctx->censor_c == '*') {
+   (*ctx->putchar)('*', ctx->putchar_arg);
+   ctx->censor_state = CENSOR_DISCARD;
+   } else if (c == *ctx->censor_c) {
+   (*ctx->putchar)(c, ctx->putchar_arg);
+   ++ctx->censor_c;
+   }
+   break;
+   case CENSOR_DISCARD:
+   if (c == '\n') {
+   (*ctx->putchar)(c, ctx->putchar_arg);
+   ctx->censor_state = CENSOR_PASS_THROUGH;
+   ++ctx->censor_c;
+   }
+   break;
+   }
+}
+
+static void
+run_initialize(void)
+{
+   test_context *ctx;
+
+   ctx = _instance;
+   ctx->censor_c = censored_init;
+   T_set_putchar(censor_putchar, ctx, >putchar, >putchar_arg);
+}
+
+static const char expected_final[] = 
"Z:ttest01:C:341:N:1316:F:790:D:0.682999\n"
+"Y:ReportHash:SHA256:62d6f3b37299137932ea2c2f0505c8b8f12b95749c81d5af19570e9470203475\n";
+
+static void
+run_finalize(void)
+{
+   test_context *ctx;
+
+   ctx = _instance;
+   ctx->c = expected_final;
+}
+
 static void
 test_action(T_event event, const char *name)
 {
@@ -125,6 +204,12 @@ test_action(T_event event, const char *name)
case T_EVENT_CASE_LATE:
case_late(name);
break;
+   case T_EVENT_RUN_INITIALIZE_EARLY:
+   run_initialize();
+   break;
+   case T_EVENT_RUN_FINALIZE_EARLY:
+   run_finalize();
+   break;
default:
break;
};
-- 
2.16.4

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


Re: [PATCH v2 3/3] ttest01: New test

2019-10-01 Thread Sebastian Huber

On 01/10/2019 23:40, Gedare Bloom wrote:

+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ * SPDX-License-Identifier: CC-BY-SA-4.0
+ *
+ * Copyright (C) 2018, 2019 embedded brains GmbH
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * Creative Commons Attribution-ShareAlike 4.0 International Public License as
+ * published by Creative Commons, PO Box 1866, Mountain View, CA 94042
+ * (https://creativecommons.org/licenses/by-sa/4.0/legalcode).
+ */

Is there any standing for dual-licensing 2BSD with CC-BY-SA?


diff --git a/testsuites/libtests/ttest01/ttest01.doc 
b/testsuites/libtests/ttest01/ttest01.doc
new file mode 100644
index 00..37d9ff8535
--- /dev/null
+++ b/testsuites/libtests/ttest01/ttest01.doc
@@ -0,0 +1,19 @@
+This file describes the directives and concepts tested by this test set.
+
+test set name: ttest01
+
+The test-*.c files must place the license header at the bottom of the file.
+This allows a copy and past of the test code into documentation sources and

paste


+enables a constent line numbering between the documentation code fragements and

constant ... fragments


+the actual test output.  For the same reason the T_TEST_OUTPUT() macros must be
+placed after the actual test cases.  The test source files are dual licensesd

licensed

+BSD-2-Clause and CC-BY-SA-4.0.
+

Thanks for the above explanation, it was helpful for this example. For
future tests, do you anticipate any text here such as a short
narrative description? Or this text should be deleted if it gets
copy-paste into new tests?


Everything which may end up in the documentation (such as code examples) 
should be dual licensed BSD-2-Clause and CC-BY-SA-4.0 from my point of 
view. Otherwise we would have to deal with BSD-2-Clause also in the 
documentation set. Not every test needs this, just the one that may be 
used in the documentation, e.g.


https://docs.rtems.org/branches/master/eng/test-framework.html#test-fixture

I would like to add also code examples to the RTEMS Classic API Guide 
for the managers (not in the next weeks).


Another candidate for dual licensing are the interface specification 
items. I would like to generate the API header files with Doxygen markup 
and the API documentation from a single source - the interface 
specification items.


--
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 3/3] ttest01: Add test outputs all test cases

2019-10-01 Thread Sebastian Huber
From: Mikail Yayla 

---
 testsuites/libtests/ttest01/test-assert.c |   21 +
 testsuites/libtests/ttest01/test-checks.c | 2503 +
 testsuites/libtests/ttest01/test-destructor.c |7 +
 testsuites/libtests/ttest01/test-eno.c|   20 +
 testsuites/libtests/ttest01/test-fixture.c|   20 +
 testsuites/libtests/ttest01/test-leak.c   |   75 +
 testsuites/libtests/ttest01/test-log.c|7 +
 testsuites/libtests/ttest01/test-malloc.c |   30 +
 testsuites/libtests/ttest01/test-plan.c   |   31 +
 testsuites/libtests/ttest01/test-psx.c|   27 +
 testsuites/libtests/ttest01/test-rtems.c  |   32 +
 testsuites/libtests/ttest01/test-simple.c |8 +
 testsuites/libtests/ttest01/test-step.c   |8 +
 testsuites/libtests/ttest01/test-time.c   |   82 +
 testsuites/libtests/ttest01/test-verbosity.c  |9 +
 15 files changed, 2880 insertions(+)

diff --git a/testsuites/libtests/ttest01/test-assert.c 
b/testsuites/libtests/ttest01/test-assert.c
index 9055d37194..7bf240279f 100644
--- a/testsuites/libtests/ttest01/test-assert.c
+++ b/testsuites/libtests/ttest01/test-assert.c
@@ -56,6 +56,27 @@ T_TEST_CASE_FIXTURE(assert2, )
T_log(T_QUIET, "not reached");
 }
 
+#include "t-self-test.h"
+
+T_TEST_OUTPUT(assert,
+"B:assert\n"
+"P:0:0:UI1:test-assert.c:5\n"
+"F:1:0:UI1:test-assert.c:6:test fails and we stop the test case\n"
+"E:assert:N:2:F:1:D:0.001000\n");
+
+T_TEST_OUTPUT(assert2,
+"B:assert2\n"
+"L:setup\n"
+"P:0:0:UI1:test-assert.c:18\n"
+"P:1:0:UI1:test-assert.c:54\n"
+"F:2:0:UI1:test-assert.c:55:test fails and we stop the test case\n"
+"L:stop\n"
+"P:3:0:UI1:test-assert.c:29\n"
+"L:teardown\n"
+"P:4:0:UI1:test-assert.c:40\n"
+"P:5:0:UI1:test-assert.c:42\n"
+"E:assert2:N:6:F:1:D:0.001000\n");
+
 /*
  * SPDX-License-Identifier: BSD-2-Clause
  * SPDX-License-Identifier: CC-BY-SA-4.0
diff --git a/testsuites/libtests/ttest01/test-checks.c 
b/testsuites/libtests/ttest01/test-checks.c
index 9d5b4da548..3e2a88bb5e 100644
--- a/testsuites/libtests/ttest01/test-checks.c
+++ b/testsuites/libtests/ttest01/test-checks.c
@@ -2880,6 +2880,2509 @@ T_TEST_CASE(check_lt_sz)
T_assert_lt_sz((size_t)12, (size_t)12);
 }
 
+#include "t-self-test.h"
+
+T_TEST_OUTPUT(step_assert_true,
+"B:step_assert_true\n"
+"P:0:0:UI1:test-checks.c:8\n"
+"F:1:0:UI1:test-checks.c:9:a\n"
+"E:step_assert_true:N:2:F:1:D:0.001000\n");
+
+T_TEST_OUTPUT(check_true,
+"B:check_true\n"
+"P:0:0:UI1:test-checks.c:14\n"
+"F:1:0:UI1:test-checks.c:15:a\n"
+"F:*:0:UI1:test-checks.c:17:ab 0\n"
+"P:2:0:UI1:test-checks.c:18\n"
+"F:3:0:UI1:test-checks.c:19:abc 0\n"
+"P:4:0:UI1:test-checks.c:20\n"
+"F:5:0:UI1:test-checks.c:21:abcd 0 1 2\n"
+"E:check_true:N:6:F:4:D:0.001000\n");
+
+T_TEST_OUTPUT(step_assert_false,
+"B:step_assert_false\n"
+"P:0:0:UI1:test-checks.c:27\n"
+"F:1:0:UI1:test-checks.c:28:a\n"
+"E:step_assert_false:N:2:F:1:D:0.001000\n");
+
+T_TEST_OUTPUT(check_false,
+"B:check_false\n"
+"P:0:0:UI1:test-checks.c:33\n"
+"F:1:0:UI1:test-checks.c:34:a\n"
+"F:*:0:UI1:test-checks.c:36:ab 0\n"
+"P:2:0:UI1:test-checks.c:37\n"
+"F:3:0:UI1:test-checks.c:38:abc 0\n"
+"P:4:0:UI1:test-checks.c:39\n"
+"F:5:0:UI1:test-checks.c:40:abcd 0 1 2\n"
+"E:check_false:N:6:F:4:D:0.001000\n");
+
+T_TEST_OUTPUT(step_assert_eq,
+"B:step_assert_eq\n"
+"P:0:0:UI1:test-checks.c:46\n"
+"F:1:0:UI1:test-checks.c:47:1 == 2\n"
+"E:step_assert_eq:N:2:F:1:D:0.001000\n");
+
+T_TEST_OUTPUT(check_eq,
+"B:check_eq\n"
+"P:0:0:UI1:test-checks.c:52\n"
+"F:1:0:UI1:test-checks.c:53:1 == 2\n"
+"F:*:0:UI1:test-checks.c:55:4 == 5\n"
+"P:2:0:UI1:test-checks.c:56\n"
+"F:3:0:UI1:test-checks.c:57:7 == 8\n"
+"P:4:0:UI1:test-checks.c:58\n"
+"F:5:0:UI1:test-checks.c:59:10 == 11\n"
+"E:check_eq:N:6:F:4:D:0.001000\n");
+
+T_TEST_OUTPUT(step_assert_ne,
+"B:step_assert_ne\n"
+"P:0:0:UI1:test-checks.c:65\n"
+"F:1:0:UI1:test-checks.c:66:2 != 2\n"
+"E:step_assert_ne:N:2:F:1:D:0.001000\n");
+
+T_TEST_OUTPUT(check_ne,
+"B:check_ne\n"
+"P:0:0:UI1:test-checks.c:71\n"
+"F:1:0:UI1:test-checks.c:72:2 != 2\n"
+"F:*:0:UI1:test-checks.c:74:5 != 5\n"
+"P:2:0:UI1:test-checks.c:75\n"
+"F:3:0:UI1:test-checks.c:76:5 != 5\n"
+"P:4:0:UI1:test-checks.c:77\n"
+"F:5:0:UI1:test-checks.c:78:11 != 11\n"
+"E:check_ne:N:6:F:4:D:0.001000\n");
+
+T_TEST_OUTPUT(step_assert_eq_ptr,
+"B:step_assert_eq_ptr\n"
+"P:0:0:UI1:test-checks.c:87\n"
+"F:1:0:UI1:test-checks.c:88: == \n"
+"E:step_assert_eq_ptr:N:2:F:1:D:0.001000\n");
+
+T_TEST_OUTPUT(check_eq_ptr,
+"B:check_eq_ptr\n"
+"P:0:0:UI1:test-checks.c:96\n"
+"F:1:0:UI1:test-checks.c:97: == \n"
+"F:*:0:UI1:test-checks.c:99: == \n"
+"P:2:0:UI1:test-checks.c:100\n"
+"F:3:0:UI1:test-checks.c:101: == \n"
+"P:4:0:UI1:test-checks.c:102\n"
+"F:5:0:UI1:test-checks.c:103: == \n"
+"E:check_eq_ptr:N:6:F:4:D:0.001000\n");
+
+T_TEST_OUTPUT(step_assert_ne_ptr,
+"B:step_assert_ne_ptr\n"
+"P:0:0:UI1:test-checks.c:112\n"
+"F:1:0:UI1:test-checks.c:113: != \n"
+"E:step_assert_ne_ptr:N:2:F:1:D:0.001000\n");
+

[PATCH 2/3] ttest01: Add more test cases

2019-10-01 Thread Sebastian Huber
Update #3199.
---
 testsuites/libtests/Makefile.am   |   15 +
 testsuites/libtests/ttest01/init.c|   54 +-
 testsuites/libtests/ttest01/test-assert.c |   90 +
 testsuites/libtests/ttest01/test-checks.c | 2914 +
 testsuites/libtests/ttest01/test-destructor.c |   49 +
 testsuites/libtests/ttest01/test-eno.c|   55 +
 testsuites/libtests/ttest01/test-fixture.c|   91 +
 testsuites/libtests/ttest01/test-leak.c   |  165 ++
 testsuites/libtests/ttest01/test-log.c|   41 +
 testsuites/libtests/ttest01/test-malloc.c |   88 +
 testsuites/libtests/ttest01/test-plan.c   |   68 +
 testsuites/libtests/ttest01/test-psx.c|   70 +
 testsuites/libtests/ttest01/test-rtems.c  |  104 +
 testsuites/libtests/ttest01/test-simple.c |   48 +
 testsuites/libtests/ttest01/test-step.c   |   40 +
 testsuites/libtests/ttest01/test-time.c   |  223 ++
 testsuites/libtests/ttest01/test-verbosity.c  |   50 +
 17 files changed, 4162 insertions(+), 3 deletions(-)
 create mode 100644 testsuites/libtests/ttest01/test-assert.c
 create mode 100644 testsuites/libtests/ttest01/test-checks.c
 create mode 100644 testsuites/libtests/ttest01/test-destructor.c
 create mode 100644 testsuites/libtests/ttest01/test-eno.c
 create mode 100644 testsuites/libtests/ttest01/test-fixture.c
 create mode 100644 testsuites/libtests/ttest01/test-leak.c
 create mode 100644 testsuites/libtests/ttest01/test-log.c
 create mode 100644 testsuites/libtests/ttest01/test-malloc.c
 create mode 100644 testsuites/libtests/ttest01/test-plan.c
 create mode 100644 testsuites/libtests/ttest01/test-psx.c
 create mode 100644 testsuites/libtests/ttest01/test-rtems.c
 create mode 100644 testsuites/libtests/ttest01/test-simple.c
 create mode 100644 testsuites/libtests/ttest01/test-step.c
 create mode 100644 testsuites/libtests/ttest01/test-time.c
 create mode 100644 testsuites/libtests/ttest01/test-verbosity.c

diff --git a/testsuites/libtests/Makefile.am b/testsuites/libtests/Makefile.am
index 406961ca73..a668dda103 100644
--- a/testsuites/libtests/Makefile.am
+++ b/testsuites/libtests/Makefile.am
@@ -1513,7 +1513,22 @@ lib_tests += ttest01
 lib_screens += ttest01/ttest01.scn
 lib_docs += ttest01/ttest01.doc
 ttest01_SOURCES = ttest01/init.c
+ttest01_SOURCES += ttest01/test-assert.c
+ttest01_SOURCES += ttest01/test-checks.c
+ttest01_SOURCES += ttest01/test-destructor.c
+ttest01_SOURCES += ttest01/test-eno.c
 ttest01_SOURCES += ttest01/test-example.c
+ttest01_SOURCES += ttest01/test-fixture.c
+ttest01_SOURCES += ttest01/test-leak.c
+ttest01_SOURCES += ttest01/test-log.c
+ttest01_SOURCES += ttest01/test-malloc.c
+ttest01_SOURCES += ttest01/test-plan.c
+ttest01_SOURCES += ttest01/test-psx.c
+ttest01_SOURCES += ttest01/test-rtems.c
+ttest01_SOURCES += ttest01/test-simple.c
+ttest01_SOURCES += ttest01/test-step.c
+ttest01_SOURCES += ttest01/test-time.c
+ttest01_SOURCES += ttest01/test-verbosity.c
 ttest01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_ttest01) \
$(support_includes)
 endif
diff --git a/testsuites/libtests/ttest01/init.c 
b/testsuites/libtests/ttest01/init.c
index 135dc2b25e..cb4ad95829 100644
--- a/testsuites/libtests/ttest01/init.c
+++ b/testsuites/libtests/ttest01/init.c
@@ -32,6 +32,8 @@
 
 #include 
 #include 
+#include 
+#include 
 
 #include "t-self-test.h"
 
@@ -47,6 +49,7 @@ typedef struct {
const char *c;
size_t case_begin_count;
size_t case_end_count;
+   struct timecounter tc;
 } test_context;
 
 static test_context test_instance;
@@ -138,11 +141,44 @@ now(void)
return t * SBT_1MS;
 }
 
+static uint32_t
+get_timecount(struct timecounter *tc)
+{
+   return 0;
+}
+
+static void
+install_timecounter(void)
+{
+   test_context *ctx;
+
+   ctx = _instance;
+   ctx->tc.tc_get_timecount = get_timecount;
+   ctx->tc.tc_counter_mask = 0x;
+   ctx->tc.tc_frequency = 10;
+   ctx->tc.tc_quality = RTEMS_TIMECOUNTER_QUALITY_CLOCK_DRIVER + 1;
+   rtems_timecounter_install(>tc);
+}
+
+RTEMS_SYSINIT_ITEM(install_timecounter, RTEMS_SYSINIT_DEVICE_DRIVERS,
+RTEMS_SYSINIT_ORDER_FIRST);
+
 static char buffer[512];
 
 static const T_action actions[] = {
T_report_hash_sha256,
-   test_action
+   test_action,
+   T_check_file_descriptors,
+   T_check_rtems_barriers,
+   T_check_rtems_extensions,
+   T_check_rtems_message_queues,
+   T_check_rtems_partitions,
+   T_check_rtems_periods,
+   T_check_rtems_regions,
+   T_check_rtems_semaphores,
+   T_check_rtems_tasks,
+   T_check_rtems_timers,
+   T_check_posix_keys
 };
 
 static const T_config config = {
@@ -180,9 +216,21 @@ Init(rtems_task_argument arg)
rtems_test_exit(0);
 }
 
-#define CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER
+#define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
+
+#define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS 4
+
+#define CONFIGURE_MAXIMUM_BARRIERS 1

[PATCH 1/3] libtest: Do all output in test runner

2019-10-01 Thread Sebastian Huber
This ensures that lines are output atomically if they are produced by
different other contexts, e.g. interrupts, other processors, other
threads.

Update #3199.
---
 cpukit/include/t.h |   2 +
 cpukit/libtest/t-test.c| 138 ++---
 testsuites/libtests/ttest01/init.c |   4 ++
 3 files changed, 121 insertions(+), 23 deletions(-)

diff --git a/cpukit/include/t.h b/cpukit/include/t.h
index c5e3792ec1..5dbf1e00b5 100644
--- a/cpukit/include/t.h
+++ b/cpukit/include/t.h
@@ -2199,6 +2199,8 @@ typedef void (*T_putchar)(int, void *);
 
 typedef struct {
const char *name;
+   char *buf;
+   size_t buf_size;
T_putchar putchar;
void *putchar_arg;
T_verbosity verbosity;
diff --git a/cpukit/libtest/t-test.c b/cpukit/libtest/t-test.c
index cf3bcd6a99..881a92efb0 100644
--- a/cpukit/libtest/t-test.c
+++ b/cpukit/libtest/t-test.c
@@ -47,12 +47,16 @@
 #include "t-test-printf.h"
 #endif /* __rtems__ */
 
-#define T_LINE_SIZE 120
+#define T_LINE_SIZE 128
 
 #define T_SCOPE_SIZE 5
 
 typedef struct {
pthread_spinlock_t lock;
+   char *buf;
+   unsigned int buf_mask;
+   atomic_uint buf_head;
+   atomic_uint buf_tail;
void (*putchar)(int, void *);
void *putchar_arg;
T_verbosity verbosity;
@@ -81,18 +85,6 @@ typedef struct {
 
 static T_context T_instance;
 
-static int
-T_do_vprintf(T_context *ctx, char const *fmt, va_list ap)
-{
-   return _IO_Vprintf(ctx->putchar, ctx->putchar_arg, fmt, ap);
-}
-
-int
-T_vprintf(char const *fmt, va_list ap)
-{
-   return T_do_vprintf(_instance, fmt, ap);
-}
-
 typedef struct {
char *s;
size_t n;
@@ -101,13 +93,13 @@ typedef struct {
 static void
 T_putchar_string(int c, void *arg)
 {
-   T_putchar_string_context *ctx;
+   T_putchar_string_context *sctx;
char *s;
size_t n;
 
-   ctx = arg;
-   s = ctx->s;
-   n = ctx->n;
+   sctx = arg;
+   s = sctx->s;
+   n = sctx->n;
 
if (n == 1) {
c = '\0';
@@ -119,8 +111,8 @@ T_putchar_string(int c, void *arg)
--n;
}
 
-   ctx->s = s;
-   ctx->n = n;
+   sctx->s = s;
+   sctx->n = n;
 }
 
 int
@@ -128,17 +120,106 @@ T_snprintf(char *s, size_t n, char const *fmt, ...)
 {
va_list ap;
int len;
-   T_putchar_string_context ctx = {
+   T_putchar_string_context sctx = {
.s = s,
.n = n
};
 
va_start(ap, fmt);
-   len = _IO_Vprintf(T_putchar_string, , fmt, ap);
+   len = _IO_Vprintf(T_putchar_string, , fmt, ap);
va_end(ap);
 
-   if (ctx.n > 0) {
-   *ctx.s = '\0';
+   if (sctx.n > 0) {
+   *sctx.s = '\0';
+   }
+
+   return len;
+}
+
+static int
+T_vprintf_direct(char const *fmt, va_list ap)
+{
+   T_context *ctx;
+   unsigned int head;
+   unsigned int tail;
+
+   ctx = _instance;
+
+   head = atomic_load_explicit(>buf_head, memory_order_acquire);
+   tail = atomic_load_explicit(>buf_tail, memory_order_relaxed);
+
+   while (head != tail) {
+   (*ctx->putchar)(ctx->buf[tail], ctx->putchar_arg);
+   tail = (tail + 1) & ctx->buf_mask;
+   }
+
+   atomic_store_explicit(>buf_tail, tail, memory_order_relaxed);
+
+   return _IO_Vprintf(ctx->putchar, ctx->putchar_arg, fmt, ap);
+}
+
+static int
+T_vprintf_buffered(char const *fmt, va_list ap)
+{
+   unsigned int len;
+   T_context *ctx;
+   char buf[T_LINE_SIZE];
+   T_putchar_string_context sctx = {
+   .s = buf,
+   .n = sizeof(buf)
+   };
+   unsigned int head;
+   unsigned int tail;
+   unsigned int mask;
+   unsigned int capacity;
+
+   len = (unsigned int)_IO_Vprintf(T_putchar_string, , fmt, ap);
+
+   if (len >= sizeof(buf)) {
+   len = sizeof(buf) - 1;
+   }
+
+   ctx = _instance;
+   pthread_spin_lock(>lock);
+   head = atomic_load_explicit(>buf_head, memory_order_relaxed);
+   tail = atomic_load_explicit(>buf_tail, memory_order_relaxed);
+   mask = ctx->buf_mask;
+   capacity = (tail - head - 1) & mask;
+
+   if (len <= capacity) {
+   unsigned int todo;
+   char *c;
+
+   todo = len;
+   c = buf;
+
+   while (todo > 0) {
+   ctx->buf[head] = *c;
+   head = (head + 1) & mask;
+   --todo;
+   ++c;
+   }
+
+   atomic_store_explicit(>buf_head, head,
+   memory_order_release);
+   } else {
+   /* If it does not fit into the buffer, discard everything */
+   len = 0;
+   }
+
+   pthread_spin_unlock(>lock);
+   return (int)len;
+}
+
+int
+T_vprintf(char const *fmt, va_list ap)
+{
+   int len;
+
+   if 

[PATCH 1/3] score: Remove superfluous timecounter members

2019-10-01 Thread Sebastian Huber
---
 cpukit/include/sys/timetc.h   |  4 +++-
 cpukit/score/src/kern_tc.c| 10 +++---
 testsuites/sptests/sptimecounter01/init.c |  4 ++--
 3 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/cpukit/include/sys/timetc.h b/cpukit/include/sys/timetc.h
index 347a140ed9..5cdfdfe9b3 100644
--- a/cpukit/include/sys/timetc.h
+++ b/cpukit/include/sys/timetc.h
@@ -45,12 +45,14 @@ typedef uint32_t timecounter_fill_vdso_timehands32_t(struct 
vdso_timehands32 *,
 
 struct timecounter {
timecounter_get_t   *tc_get_timecount;
+#ifndef __rtems__
/*
 * This function reads the counter.  It is not required to
 * mask any unimplemented bits out, as long as they are
 * constant.
 */
timecounter_pps_t   *tc_poll_pps;
+#endif /* __rtems__ */
/*
 * This function is optional.  It will be called whenever the
 * timecounter is rewound, and is intended to check for PPS
@@ -64,6 +66,7 @@ struct timecounter {
const char  *tc_name;
/* Name of the timecounter. */
int tc_quality;
+#ifndef __rtems__
/*
 * Used to determine if this timecounter is better than
 * another timecounter higher means better.  Negative
@@ -80,7 +83,6 @@ struct timecounter {
/* Pointer to the timecounter's private parts. */
struct timecounter  *tc_next;
/* Pointer to the next timecounter. */
-#ifndef __rtems__
timecounter_fill_vdso_timehands_t *tc_fill_vdso_timehands;
timecounter_fill_vdso_timehands32_t *tc_fill_vdso_timehands32;
 #endif /* __rtems__ */
diff --git a/cpukit/score/src/kern_tc.c b/cpukit/score/src/kern_tc.c
index d705b59a4c..082cb9f7d7 100644
--- a/cpukit/score/src/kern_tc.c
+++ b/cpukit/score/src/kern_tc.c
@@ -146,7 +146,11 @@ dummy_get_timecount(struct timecounter *tc)
 }
 
 static struct timecounter dummy_timecounter = {
+#ifndef __rtems__
dummy_get_timecount, 0, ~0u, 100, "dummy", -100
+#else /* __rtems__ */
+   dummy_get_timecount, ~(uint32_t)0, 100, "dummy", -100
+#endif /* __rtems__ */
 };
 
 struct timehands {
@@ -195,9 +199,9 @@ static struct timehands th0 = {
 
 static struct timehands *volatile timehands = 
 struct timecounter *timecounter = _timecounter;
+#ifndef __rtems__
 static struct timecounter *timecounters = _timecounter;
 
-#ifndef __rtems__
 int tc_min_ticktock_freq = 1;
 #endif /* __rtems__ */
 
@@ -1359,11 +1363,9 @@ tc_init(struct timecounter *tc)
tc->tc_name, (uintmax_t)tc->tc_frequency,
tc->tc_quality);
}
-#endif /* __rtems__ */
 
tc->tc_next = timecounters;
timecounters = tc;
-#ifndef __rtems__
/*
 * Set up sysctl tree for this counter.
 */
@@ -1566,6 +1568,7 @@ _Timecounter_Windup(struct bintime *new_boottimebin,
}
bintime_addx(>th_offset, th->th_scale * delta);
 
+#ifndef __rtems__
/*
 * Hardware latching timecounters may not generate interrupts on
 * PPS events, so instead we poll them.  There is a finite risk that
@@ -1576,6 +1579,7 @@ _Timecounter_Windup(struct bintime *new_boottimebin,
 */
if (tho->th_counter->tc_poll_pps)
tho->th_counter->tc_poll_pps(tho->th_counter);
+#endif /* __rtems__ */
 
/*
 * Deal with NTP second processing.  The for loop normally
diff --git a/testsuites/sptests/sptimecounter01/init.c 
b/testsuites/sptests/sptimecounter01/init.c
index 6976f7bc80..9fc36583c4 100644
--- a/testsuites/sptests/sptimecounter01/init.c
+++ b/testsuites/sptests/sptimecounter01/init.c
@@ -38,8 +38,9 @@ static test_context test_instance;
 
 static uint32_t test_get_timecount_soft(struct timecounter *tc)
 {
-  test_context *ctx = tc->tc_priv;
+  test_context *ctx;
 
+  ctx = RTEMS_CONTAINER_OF(tc, test_context, tc_soft);
   ++ctx->tc_soft_counter;
 
   return ctx->tc_soft_counter;
@@ -124,7 +125,6 @@ void boot_card(const char *cmdline)
   tc_soft->tc_counter_mask = 0x0fff;
   tc_soft->tc_frequency = soft_freq;
   tc_soft->tc_quality = 1234;
-  tc_soft->tc_priv = ctx;
   _Timecounter_Install(tc_soft);
   assert(ctx->tc_soft_counter == 3);
 
-- 
2.16.4

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


[PATCH 3/3] score: Install timecounter according to quality

2019-10-01 Thread Sebastian Huber
This makes it possible to install higher quality timecounter in
plug-and-play systems and helps to override the clock driver provided
timecounter in some test scenarios.
---
 cpukit/score/src/kern_tc.c|   2 +
 testsuites/sptests/sptimecounter01/init.c | 101 +++---
 2 files changed, 81 insertions(+), 22 deletions(-)

diff --git a/cpukit/score/src/kern_tc.c b/cpukit/score/src/kern_tc.c
index e550b22580..1b65cf41ee 100644
--- a/cpukit/score/src/kern_tc.c
+++ b/cpukit/score/src/kern_tc.c
@@ -1394,11 +1394,13 @@ tc_init(struct timecounter *tc)
return;
if (tc->tc_quality < 0)
return;
+#endif /* __rtems__ */
if (tc->tc_quality < timecounter->tc_quality)
return;
if (tc->tc_quality == timecounter->tc_quality &&
tc->tc_frequency < timecounter->tc_frequency)
return;
+#ifndef __rtems__
(void)tc->tc_get_timecount(tc);
(void)tc->tc_get_timecount(tc);
 #endif /* __rtems__ */
diff --git a/testsuites/sptests/sptimecounter01/init.c 
b/testsuites/sptests/sptimecounter01/init.c
index 8928c5e051..c949244dc4 100644
--- a/testsuites/sptests/sptimecounter01/init.c
+++ b/testsuites/sptests/sptimecounter01/init.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2015 embedded brains GmbH.  All rights reserved.
+ * Copyright (c) 2015, 2019 embedded brains GmbH.  All rights reserved.
  *
  *  embedded brains GmbH
  *  Dornierstr. 4
@@ -29,32 +29,87 @@
 
 const char rtems_test_name[] = "SPTIMECOUNTER 1";
 
+#define TEST_QUAL 1234
+
+#define TEST_FREQ 100
+
 typedef struct {
-  struct timecounter tc_soft;
-  u_int tc_soft_counter;
+  struct timecounter tc;
+  uint32_t counter;
+  struct timecounter tc_2;
+  uint32_t counter_2;
 } test_context;
 
 static test_context test_instance;
 
-static uint32_t test_get_timecount_soft(struct timecounter *tc)
+static uint32_t test_get_timecount(struct timecounter *tc)
+{
+  test_context *ctx;
+
+  ctx = RTEMS_CONTAINER_OF(tc, test_context, tc);
+  ++ctx->counter;
+
+  return ctx->counter;
+}
+
+static uint32_t test_get_timecount_2(struct timecounter *tc)
 {
   test_context *ctx;
 
-  ctx = RTEMS_CONTAINER_OF(tc, test_context, tc_soft);
-  ++ctx->tc_soft_counter;
+  ctx = RTEMS_CONTAINER_OF(tc, test_context, tc_2);
+  ++ctx->counter_2;
+
+  return ctx->counter_2;
+}
 
-  return ctx->tc_soft_counter;
+static void test_install(test_context *ctx)
+{
+  struct timecounter *tc;
+  struct timecounter *tc_2;
+  uint32_t c;
+  uint32_t c_2;
+
+  tc = >tc;
+  tc_2 = >tc_2;
+  c = ctx->counter;
+  c_2 = ctx->counter_2;
+
+  tc_2->tc_get_timecount = test_get_timecount_2;
+  tc_2->tc_counter_mask = 0x0fff;
+  tc_2->tc_frequency = TEST_FREQ - 1;
+  tc_2->tc_quality = TEST_QUAL;
+  _Timecounter_Install(tc_2);
+  assert(ctx->counter == c);
+  assert(ctx->counter_2 == c_2);
+
+  tc_2->tc_get_timecount = test_get_timecount_2;
+  tc_2->tc_counter_mask = 0x0fff;
+  tc_2->tc_frequency = TEST_FREQ - 1;
+  tc_2->tc_quality = TEST_QUAL + 1;
+  _Timecounter_Install(tc_2);
+  assert(ctx->counter == c + 1);
+  assert(ctx->counter_2 == c_2 + 1);
+
+  tc->tc_get_timecount = test_get_timecount;
+  tc->tc_counter_mask = 0x0fff;
+  tc->tc_frequency = TEST_FREQ;
+  tc->tc_quality = TEST_QUAL + 1;
+  _Timecounter_Install(tc);
+  assert(ctx->counter == c + 2);
+  assert(ctx->counter_2 == c_2 + 2);
 }
 
 void boot_card(const char *cmdline)
 {
-  test_context *ctx = _instance;
-  struct timecounter *tc_soft = >tc_soft;
-  uint64_t soft_freq = 100;
+  test_context *ctx;
+  struct timecounter *tc;
   struct bintime bt;
   struct timeval tv;
   struct timespec ts;
 
+  ctx = _instance;
+  tc = >tc;
+
   TEST_BEGIN();
 
   assert(time(NULL) == TOD_SECONDS_1970_THROUGH_1988);
@@ -120,34 +175,36 @@ void boot_card(const char *cmdline)
   assert(bt.sec == 1);
   assert(bt.frac == 0);
 
-  ctx->tc_soft_counter = 0;
-  tc_soft->tc_get_timecount = test_get_timecount_soft;
-  tc_soft->tc_counter_mask = 0x0fff;
-  tc_soft->tc_frequency = soft_freq;
-  tc_soft->tc_quality = 1234;
-  _Timecounter_Install(tc_soft);
-  assert(ctx->tc_soft_counter == 1);
+  ctx->counter = 0;
+  tc->tc_get_timecount = test_get_timecount;
+  tc->tc_counter_mask = 0x0fff;
+  tc->tc_frequency = TEST_FREQ;
+  tc->tc_quality = TEST_QUAL;
+  _Timecounter_Install(tc);
+  assert(ctx->counter == 1);
 
   rtems_bsd_binuptime();
-  assert(ctx->tc_soft_counter == 2);
+  assert(ctx->counter == 2);
 
   assert(bt.sec == 1);
   assert(bt.frac == 18446744073708);
 
-  ctx->tc_soft_counter = 0xf000 | 1;
+  ctx->counter = 0xf000 | 1;
   rtems_bsd_binuptime();
-  assert(ctx->tc_soft_counter == (0xf000 | 2));
+  assert(ctx->counter == (0xf000 | 2));
 
   assert(bt.sec == 1);
   assert(bt.frac == 18446744073708);
 
   /* Ensure that the fraction overflows and the second remains constant */
-  ctx->tc_soft_counter = (0xf000 | 1) + soft_freq;
+  ctx->counter = (0xf000 | 1) + TEST_FREQ;
   

[PATCH 2/3] score: Remove strange timecounter init step

2019-10-01 Thread Sebastian Huber
The double call of the timecounter get method was added to FreeBSD in
2002 without a comment.  It is not clear why this is needed.
---
 cpukit/score/src/kern_tc.c|  2 +-
 testsuites/sptests/sptimecounter01/init.c | 12 ++--
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/cpukit/score/src/kern_tc.c b/cpukit/score/src/kern_tc.c
index 082cb9f7d7..e550b22580 100644
--- a/cpukit/score/src/kern_tc.c
+++ b/cpukit/score/src/kern_tc.c
@@ -1399,9 +1399,9 @@ tc_init(struct timecounter *tc)
if (tc->tc_quality == timecounter->tc_quality &&
tc->tc_frequency < timecounter->tc_frequency)
return;
-#endif /* __rtems__ */
(void)tc->tc_get_timecount(tc);
(void)tc->tc_get_timecount(tc);
+#endif /* __rtems__ */
timecounter = tc;
 #ifdef __rtems__
tc_windup(NULL);
diff --git a/testsuites/sptests/sptimecounter01/init.c 
b/testsuites/sptests/sptimecounter01/init.c
index 9fc36583c4..8928c5e051 100644
--- a/testsuites/sptests/sptimecounter01/init.c
+++ b/testsuites/sptests/sptimecounter01/init.c
@@ -126,25 +126,25 @@ void boot_card(const char *cmdline)
   tc_soft->tc_frequency = soft_freq;
   tc_soft->tc_quality = 1234;
   _Timecounter_Install(tc_soft);
-  assert(ctx->tc_soft_counter == 3);
+  assert(ctx->tc_soft_counter == 1);
 
   rtems_bsd_binuptime();
-  assert(ctx->tc_soft_counter == 4);
+  assert(ctx->tc_soft_counter == 2);
 
   assert(bt.sec == 1);
   assert(bt.frac == 18446744073708);
 
-  ctx->tc_soft_counter = 0xf000 | 3;
+  ctx->tc_soft_counter = 0xf000 | 1;
   rtems_bsd_binuptime();
-  assert(ctx->tc_soft_counter == (0xf000 | 4));
+  assert(ctx->tc_soft_counter == (0xf000 | 2));
 
   assert(bt.sec == 1);
   assert(bt.frac == 18446744073708);
 
   /* Ensure that the fraction overflows and the second remains constant */
-  ctx->tc_soft_counter = (0xf000 | 3) + soft_freq;
+  ctx->tc_soft_counter = (0xf000 | 1) + soft_freq;
   rtems_bsd_binuptime();
-  assert(ctx->tc_soft_counter == (0xf000 | 4) + soft_freq);
+  assert(ctx->tc_soft_counter == (0xf000 | 2) + soft_freq);
   assert(bt.sec == 1);
   assert(bt.frac == 18446742522092);
 
-- 
2.16.4

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


Re: [PATCH] user: Document patch review process

2019-10-01 Thread Sebastian Huber



On 01/10/2019 09:22, Chris Johns wrote:

On 1/10/19 3:50 pm, Sebastian Huber wrote:

On 01/10/2019 01:40, Chris Johns wrote:

On 30/9/19 10:45 pm, Sebastian Huber wrote:

[...]

+* The patch builds.  All RTEMS tests link with this patch.
+
+* The patch does not introduce new compiler warnings.


This step is not in the figure.


You mean there should be a step mentioning this checklist?


Sorry, I missed by a line, I meant the patch builds. I am wondering if building
should be in the figure, that is the figure and this text match. I think it is
important to point out in a bold manner patches need to build and need to work.
I know this is common sense but 


What about this figure:

http://www.plantuml.com/plantuml/png/dLDXQnf14Fr-ls8u2bNAIHBwfVP3JKrf0ur8RA41lwntSzuqjxFNsJd5Vz-zNK5ReOK8WZlptfktRzoPLoFQspPx3QlbtO_YAvN87elx2bcf9fGfpEV5nwTYTLkydLnb0JXttK5esoYCvcEukRf-1sWtM5LOmKOCiOVFTlCb2vyedsNJMn73MuI3wmNAPlZjWNZDXW6DFu0w4DmHxi5mjURIDIZ82ftHiW6FGkZV3q9TrmPqWq45o-UMl4Bj9E4Iv9vtxXcdaETRYarhj8ZzF1_wA-GgAfnh3mOgt64x4qNh9qwsKJUPIZI5nG2x2QTzGot2w35sKNpWsc3yx6eN4pwCWJoCdj2FCu3fdOi8mLyz2PwOKKNGA881nltV2GJgzwuAxHI2ivOKB7fl8hiidLJ4s_QGiF_F2-0VYK6nWrUBc5lqNFOMMOzwoN0jpi8EnPFZ5D02ti3rcl_8e1xoChMYn69U54KEBJ56vLEuaHjhBzjJu1ntit3ZBACQHijp-jx4aB3JuSzwEF9GXlM4MNnQqBBtpSNuDQjBHN4_iTJ0xvmdTPBoPgS8yMs40y13xnKs29LZ7AOPZkN7RvyULc0DiOOloYHKW_78ph3roNrCd7nfv3A6U56gXmVckcmM3k4D_mO0

@startuml

start

:Arrange your changes in\nan easy to review and\ncoherent patch series;

:Apply the checklist for patches;

:Invoke: ""git format-patch"";

:Send the patch series to devel@rtems.org for review;

:Set N to 2;

while (Reviewers demand changes in the patch series?) is (Yes)
  :Do the required changes and create a new patch series;

  :Update the commit messages accordingly;

  :Apply the checklist for patches;

  :Invoke: ""git format-patch -v $N"";

  :Document the changes from version N to N + 1\nin the patch file 
after the "---" line;


  :Set N to N + 1;

  :Send the patch series to devel@rtems.org for review;
endwhile (No)

if (Patch series was accepted by reviewers?) then (Yes)
  :Push the patch series\nto the project repository;

  note right
Must be done by an
RTEMS maintainer.
  end note
else (No)
  :Discard the patch series;
endif

stop

@enduml





Built against which BSPs?


This is for the user manual. I think at least one arbitrary BSP which is
affected by the patch should be sufficient.



Joel and I now have the BSP builder building on a regular basis because we found
things broke in weird ways across archs and bsps. If we had a patch smoke test
tool available it would help but we do not.


Yes, this is the long term goal.






+* The patch does not introduce new test failures in existing tests.


This step is not in the figure.

Again which BSPs? This assumes expected fails are valid for the bsps being
tested.


I think we should not add to many details to the figure.


The list of steps here does not matching the figure is a potential source of
user problems if the user inspects the figure and skims the written text.



What about tickets and the "Closes ...", "Updates ..." etc tags?


Yes, this is missing. What should be checked as well?


What does "checked" mean?


I mean items (individual checks) for the Checklist for Patches.

--
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] dosfs: Fix format with media block sizes > 512

2019-10-01 Thread Sebastian Huber
---
 cpukit/libfs/src/dosfs/msdos_format.c | 93 +--
 1 file changed, 46 insertions(+), 47 deletions(-)

diff --git a/cpukit/libfs/src/dosfs/msdos_format.c 
b/cpukit/libfs/src/dosfs/msdos_format.c
index 42f1d74575..326040f004 100644
--- a/cpukit/libfs/src/dosfs/msdos_format.c
+++ b/cpukit/libfs/src/dosfs/msdos_format.c
@@ -65,6 +65,7 @@ typedef struct {
   bool VolLabel_present;
   uint32_t vol_id;
   bool skip_alignment;
+  char*sec;
 }  msdos_format_param_t;
 
 /*
@@ -180,11 +181,11 @@ static int msdos_format_fill_sectors
 +---+
 | Input Parameters: |
 \*-*/
+ msdos_format_param_t *fmt_params,
  const msdos_format_request_param_t *rqdata,
  int fd,   /* file descriptor index*/
  uint32_tstart_sector, /* sector number to fill to */
  uint32_tsector_cnt,   /* number of sectors to fill to */
- uint32_tsector_size,  /* size of sector   */
  const char  fill_byte /* byte to fill into sectors*/
  )
 /*-*\
@@ -193,22 +194,14 @@ static int msdos_format_fill_sectors
 \*=*/
 {
   int ret_val = 0;
-  char *fill_buffer = NULL;
   uint32_t total_sectors = sector_cnt;
   int last_percent = -1;
 
   /*
-   * allocate and fill buffer
+   * fill buffer
*/
   if (ret_val == 0) {
-fill_buffer = malloc(sector_size);
-if (fill_buffer == NULL) {
-  errno = ENOMEM;
-  ret_val = -1;
-}
-else {
-  memset(fill_buffer,fill_byte,sector_size);
-}
+memset(fmt_params->sec,fill_byte,fmt_params->bytes_per_sector);
   }
 
   msdos_format_printf (rqdata, MSDOS_FMT_INFO_LEVEL_DETAIL,
@@ -224,7 +217,9 @@ static int msdos_format_fill_sectors
 msdos_format_printf (rqdata, MSDOS_FMT_INFO_LEVEL_DETAIL, ".");
   last_percent = percent;
 }
-ret_val = msdos_format_write_sec(fd,start_sector,sector_size,fill_buffer);
+ret_val = msdos_format_write_sec(fd,start_sector,
+ fmt_params->bytes_per_sector,
+ fmt_params->sec);
 start_sector++;
 sector_cnt--;
   }
@@ -235,13 +230,6 @@ static int msdos_format_fill_sectors
 msdos_format_printf (rqdata, MSDOS_FMT_INFO_LEVEL_INFO,
  "filling error on sector: %d\n", start_sector);
 
-  /*
-   * cleanup
-   */
-  if (fill_buffer != NULL) {
-free(fill_buffer);
-fill_buffer = NULL;
-  }
   return ret_val;
 }
 
@@ -1016,13 +1004,14 @@ int msdos_format
 |0, if success, -1 and errno if failed  |
 \*=*/
 {
-  char tmp_sec[FAT_TOTAL_MBR_SIZE];
   struct stat  stat_buf;
   int  ret_val   = 0;
   int  fd= -1;
   int  i;
   msdos_format_param_t fmt_params;
 
+  memset(_params, 0, sizeof(fmt_params));
+
   /*
* open device for writing
*/
@@ -1055,6 +1044,14 @@ int msdos_format
   if (ret_val == 0) {
 ret_val = msdos_format_determine_fmt_params(fd,rqdata,_params);
   }
+
+  if (ret_val == 0) {
+fmt_params.sec = malloc(fmt_params.bytes_per_sector);
+if (fmt_params.sec == NULL) {
+  ret_val = -1;
+}
+  }
+
   /*
* if requested, write whole disk/partition with 0xe5
*/
@@ -1062,11 +1059,11 @@ int msdos_format
   (rqdata != NULL) &&
   !(rqdata->quick_format)) {
 ret_val = msdos_format_fill_sectors
-  (rqdata,
+  (_params,
+   rqdata,
fd,
0,/* start sector */
fmt_params.totl_sector_cnt,   /* sector count */
-   fmt_params.bytes_per_sector,
0xe5);
   }
 
@@ -1082,11 +1079,11 @@ int msdos_format
 ret_val = msdos_format_read_sec(fd,
 0,
 fmt_params.bytes_per_sector,
-tmp_sec);
+fmt_params.sec);
 if (ret_val == 0) {
   msdos_format_printf (rqdata, MSDOS_FMT_INFO_LEVEL_DETAIL,
"generate MRB sector\n");
-  ret_val = msdos_format_gen_mbr(tmp_sec,_params);
+  ret_val = msdos_format_gen_mbr(fmt_params.sec,_params);
 }
 
 /*
@@ -1099,7 +1096,7 @@ int msdos_format
   ret_val = msdos_format_write_sec(fd,
0,
fmt_params.bytes_per_sector,
-   tmp_sec);
+   fmt_params.sec);
 }
 if ((ret_val 

[PATCH] bsp/erc32: Improve pseudo-SMP support

2019-10-01 Thread Sebastian Huber
Add support for _SMP_Send_message() to the own processor.  This is
required by the smpmulticast01 test program.
---
 bsps/sparc/erc32/start/bspsmp.c  | 84 
 c/src/lib/libbsp/sparc/erc32/Makefile.am |  3 +-
 2 files changed, 85 insertions(+), 2 deletions(-)
 create mode 100644 bsps/sparc/erc32/start/bspsmp.c

diff --git a/bsps/sparc/erc32/start/bspsmp.c b/bsps/sparc/erc32/start/bspsmp.c
new file mode 100644
index 00..35ed2bd0d0
--- /dev/null
+++ b/bsps/sparc/erc32/start/bspsmp.c
@@ -0,0 +1,84 @@
+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (C) 2019 embedded brains GmbH
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#define IPI_VECTOR SPARC_SYNCHRONOUS_TRAP( 0x90 )
+
+uint32_t _CPU_SMP_Get_current_processor( void )
+{
+  return 0;
+}
+
+uint32_t _CPU_SMP_Initialize( void )
+{
+  return 1;
+}
+
+bool _CPU_SMP_Start_processor( uint32_t cpu_index )
+{
+  (void) cpu_index;
+  return true;
+}
+
+void _CPU_SMP_Finalize_initialization( uint32_t cpu_count )
+{
+  _Assert( cpu_count == 1 );
+  (void) cpu_count;
+}
+
+void _CPU_SMP_Prepare_start_multitasking( void )
+{
+}
+
+void _CPU_SMP_Send_interrupt( uint32_t target_processor_index )
+{
+  _Assert( target_processor_index == 0 );
+  (void) target_processor_index;
+  __asm__ volatile( "ta 0x10; nop " );
+}
+
+static rtems_isr bsp_inter_processor_interrupt(
+  rtems_vector_number vector
+)
+{
+  _SMP_Inter_processor_interrupt_handler( _Per_CPU_Get() );
+}
+
+static void erc32_install_inter_processor_interrupt( void )
+{
+  set_vector( bsp_inter_processor_interrupt, IPI_VECTOR, 1 );
+}
+
+RTEMS_SYSINIT_ITEM(
+  erc32_install_inter_processor_interrupt,
+  RTEMS_SYSINIT_BSP_PRE_DRIVERS,
+  RTEMS_SYSINIT_ORDER_LAST
+);
diff --git a/c/src/lib/libbsp/sparc/erc32/Makefile.am 
b/c/src/lib/libbsp/sparc/erc32/Makefile.am
index 994e55cc40..8cdd4581bf 100644
--- a/c/src/lib/libbsp/sparc/erc32/Makefile.am
+++ b/c/src/lib/libbsp/sparc/erc32/Makefile.am
@@ -55,8 +55,7 @@ librtemsbsp_a_SOURCES += 
../../../../../../bsps/sparc/shared/irq/bsp_isr_handler
 librtemsbsp_a_SOURCES += 
../../../../../../bsps/shared/irq/irq-default-handler.c
 
 if HAS_SMP
-librtemsbsp_a_SOURCES += ../../../../../../bsps/shared/start/bspsmp-dummy.c
-librtemsbsp_a_SOURCES += 
../../../../../../bsps/shared/start/getcurrentprocessor-zero.c
+librtemsbsp_a_SOURCES += ../../../../../../bsps/sparc/erc32/start/bspsmp.c
 endif
 
 if HAS_NETWORKING
-- 
2.16.4

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


Re: [PATCH] user: Document patch review process

2019-09-30 Thread Sebastian Huber

On 01/10/2019 01:40, Chris Johns wrote:

On 30/9/19 10:45 pm, Sebastian Huber wrote:

---
  images/user/patch-review.png  | Bin 0 -> 57130 bytes
  images/user/patch-review.puml |  44 +++
  user/support/contrib.rst  |  67 +-
  3 files changed, 97 insertions(+), 14 deletions(-)
  create mode 100644 images/user/patch-review.png
  create mode 100644 images/user/patch-review.puml



If you want to review the figure it is ...

http://www.plantuml.com/plantuml/png/dP0_ZzDC4CRx_HGZwoqIlSf9K8Q28451ST7f3WgaD7lsutZ1EsjcnuxoxLcFWt9790gAbNR-_6QUUNPPlUWOU-VivzpsWuZd8-YSHg6wc_-P0X_OCy7dCsaYmHHm8i_DWUlKGS1AWzUwemm9oE_AeCyyfH_OKbKTWrAR97hTM5DLpVKdS4FQuHKuJsymeT-98kQx9CSPlMnSCANztFQsHASkzA3LerKXkR2ng7gX-sR3-pM5JAjlo6j7jFsOh4FmSmo2AsbJ15v1dXYdFyyhwDUXcSjrYZ4eHUJiZQph94tWOt-slhyOGPk9_jkR7IQb7YDOJT1l7QsaI1CaXyJBtNlwdzuS-DLfxMo3RnLYoMgpsLJK1uPDDi-khEN-pVx2N2pVfxLpeQNLmqlyvEr-38g6diyN3b9SdtVnrVU7CNStwm-iQKbA-evQIJ2a73J9OYKd1KauTbe2elinAps3ciIOjtcszEENJ_TF57rWBGzoLxBWncY7FY_gpV6GQo-tDjYXeNKkQngSsvLeZFql


Nice, you can use it for new images here:

http://www.plantuml.com/plantuml/uml/SyfFKj2rKt3CoKnELR1Io4ZDoSa7

[...]

+* The patch builds.  All RTEMS tests link with this patch.
+
+* The patch does not introduce new compiler warnings.


This step is not in the figure.


You mean there should be a step mentioning this checklist?



Built against which BSPs?


This is for the user manual. I think at least one arbitrary BSP which is 
affected by the patch should be sufficient.





+* The patch does not introduce new test failures in existing tests.


This step is not in the figure.

Again which BSPs? This assumes expected fails are valid for the bsps being 
tested.


I think we should not add to many details to the figure.



What about tickets and the "Closes ...", "Updates ..." etc tags?


Yes, this is missing. What should be checked as well?

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

How to build start.o using waf?

2019-09-30 Thread Sebastian Huber

Hello,

I would like to work on a new build system prototype. The idea is to use 
specification items maintained by Doorstop (YAML files), a Python 
configuration script and waf to build RTEMS and the tests. This is 
similar to the libbsd build. The difference is that in libbsd the build 
data is maintained directly in Python code (libbsd.py).


How do you build a singe object file (start.o) from assembly files in 
waf? An example would be great.


--
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] eng: Add Software Requirements Engineering chapter

2019-09-30 Thread Sebastian Huber

On 24/07/2019 15:44, Sebastian Huber wrote:

+Requirement Traceability
+
+
+The standard |E10-06| demands that requirements shall be under configuration
+management, backwards-traceable and forward-traceable.
+
+History of Requirements
+---
+
+The RTEMS requirements should placed in the RTEMS sources using Git for version
+control.  The history of requirements can be traced with Git.  Special commit
+procedures for changes in requirement files should be established.  For
+example, it should be allowed to change only one requirement per commit.  A
+dedicated Git commit message format may be used as well, e.g. use of
+``Approved-by:`` or ``Reviewed-by:`` lines which indicate an agreed statement
+(similar to the
+`Linux kernel patch submission 
guidelines<https://www.kernel.org/doc/html/latest//process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes>`_).


In the first version of this patch, the proposal was to use Git to track 
the history of specification items (requirements are a specialization 
them). I think it would be better to add the revision and the 
description of a change directly to the files, e.g. add a custom 
attribute "changes" which contains a list of "revision" and 
"description" tuples.  Revision 1 items do not need this attribute. 
Example:


changes:
- description: The description of the change from revision 1 (initial) to 2.
  revision: 2
- description: The description of the change from revision 2 to 3.
  revision: 3
- description: The description of the change from revision 3 to 4.
  revision: 4

This information can be used to add the change log of each specification 
item to a human readable document for example.  The documentation 
generator program does not need a Git repository in this case to extract 
the information.


Also this way the revision of a specification item is independent of the 
current version control system. This makes it easier to reference items 
of a specific revision. For example: "With ABC-001 in revision 1 we 
could meet our system requirements, however the change to revision 2 is 
a problem, due to ...".


--
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] user: Document patch review process

2019-09-30 Thread Sebastian Huber
---
 images/user/patch-review.png  | Bin 0 -> 57130 bytes
 images/user/patch-review.puml |  44 +++
 user/support/contrib.rst  |  67 +-
 3 files changed, 97 insertions(+), 14 deletions(-)
 create mode 100644 images/user/patch-review.png
 create mode 100644 images/user/patch-review.puml

diff --git a/images/user/patch-review.png b/images/user/patch-review.png
new file mode 100644
index 
..eadb7735eeb907f4dfecd2bcdca9fe000388cf32
GIT binary patch
literal 57130
zcma%jbzGEN*S3n%A=1)aGJq%O;YAtl}23?QwfbPEVbgMxIofOJSmcQZ87{cVn(
z^PKm2-#@j
zW9-Uk0RCZyi>bj4Y;0XDjf~;9B#f+$?DgPAhE)14RHksaEtH+z)>6+J?r3ERF|e`1
z<=`W`b?eSMGbJ_n-{0T54Q}%$Dfv|sZ1UOtdW{82aRr>f2sZ9aW_z5h`=6zw@8dqp
zjp^18U$olNa(1%nm~|e3p)##!p>%KT)$#1lY$j#k7T-bh}x6o=Y;h0IqLO_Y<215k>YWO7y%s>#TrupVVOOaHLDb_;U=z
za>%tFVh{+u7q`e?R2ZS})5^#9$jZ=kt7$TqKh>vNj;vz#M>Wg+GiNL0C?ogI>3YO<
zYFFHCCXCAzQxu8Y(C1Usaktahu+reD51!-+^>@w%upFWVGRvr_roU7-(OKwxGujB;R)6MJ^uP!8e}4O5n@n9>ZuU
zLh&1{TJ$V06x+$T=E6d@+Db`$XQD`QKx9Mm$;jfKN|=Yogk{doc8DWca#&!ePT(jfXHVWnL)^_;O@DGr%hS-J|6TNK7aqs)P(Z)o~xIM;Qez0nvr
z@Tr7ab8?D_Tb73fPp*AZudO)mb!)`g+<;o4bMQmwF(VWYja+eYvG}0OpF2?T7
zN%I7S9I4V*xg>4jwPoyj?~FYN)Ogqax_y7FoWSS)fYcKxAx&9%YtiTL61d6Yi;}+V
zCX0Jax)f1iHtdghKA2FpC?U@1tF*SI#3PAI%Gg{x9=GcSC49volC9z4i6?Hn%PBCW
z6JXL5Q)u6Nj$69ll%+>f7C1jCwo9}vZJUUS*&%Z4*4tZBFGQ5yXm2K?y}>*tZKt;u
zc~6V#NU1E599Z?hdFrRKRX
zS_i`SMMq~RVkDn*b{4s)qGG1brBo%ax2LD4uWyAtnCcOsJ(L=Er6-|-Bq`r=vV$h>v_$I+5-;r<`@A_HY
zQBhIx^z{5X@83R6)%%TlDLqceT-@M;jPIUOvo;#}eo~w)~o2!(0
zEQaz-O-+4(XmyQ|Juva@BSain-x7TY-U0EJg|ysBQBm>5ix=|p_ua|M`ZW~NOBXg`
zL%Lq4wJe784}{Fji~aR-|GQ<`F-d*l{pZZ?nQ(MD9SZl$teUhX>Em2Z3Y$!0W{
z*VoUlX~oXY*)=mV_iGSV$47wVoc?d=%41;L}9
z=%G8kG^9zoD%DT%M^Xx#Amh@vh%R;_CanuMM+D-_k0^6dTtKd?6>;Fdh#qMvWv
zFB`8hSm01+770iL
zd`X^W%0;=ds(#8QA*(#}sAe}?C1u%Nj5~bJoDXe5+QhU_dD41Ekb%oTYO3eF
z-{BCsR&1-=giLNNXPD$Z7Q~gjr
z8KN@7SN0|lEFTS*NjPts<6d25cnI5^f@ZEc{Z>*7ZfG=LOnbY6Wnq$fqf<-DeJm
zBlAk#y?eMAa|Z@3LU^!})H$Z5DYtLJ0(YsA`I6@xJZ1x9m}g(`Vd`F+`s!l`ejR3a
zX>JyNj5((YkH{r|irAUj{7|gh6$*bNj
z7^8j46x1LWJ0}Wb{FI`VTG(%nnCswcKAbZ+^#3n|inu!E~mt?CqBXaki!q_)^$!
z;z3=8+}gA6+%_NYkEHBWAB`6Vynhh7mjuSZYfi$p-AHlLB_McI4EeFGRDN-CG&|r5L
zhT~xZv$V97mJR~pwky3dwv))d=4+t6?W^!)>YsO8OYDnQ&(j>wSn-2E94sp<1HQ*H
zY=pt5)gVxP{p@-bVuARf^+;${upVC}>>d9_b8~Z4RMeA)Sh4FR;H`8@Ag1#N!lIRE
zW#;#ID$efn*mhi@nISK8Z~hn`*T%fgRo|I`m4J4<1qWHYT0MzPhTvB{6zc)!i5>M~gJ!}#uQ3#ZGo@`T8}y@q@Zo-dl?
z$Xh!zg3ViPzGyyikjr?Iu=i?1g*rr-FT@Kx_Iv$fS;jFbrY7p>VQ;U<03-9}
z#3F@0(%_EX!YMV(hVhi44{*S64tCK|QRTlVp`oEY4E6V_Lvwisi(}8`y=?MX^T42L(A#;g+nIQ<`i@^k!K)B=qHJy|wZofVOY^8h%9JV9
z;S^t1d)*psbQqtohJ;R(cjr0p^m$!6ZvI-1S1-@i6R%L!%)wCAV_JgWIFpX7T}|V4
zWs85c?k#Q!#K(vt<+z*<^I^*bFXr^aVLztAQ`24Gtm
z9aP$7v`0`2#zz*JBL=fdO65v0+>bWl^{z*aR}aHJrQUDw;I~`ulAE4J;e4gwkrC$q
z42w@|Olr;k#8!2i7+!AtlHZt@k5B%DEIXB(g~eQJYht+4^7Z#A4civS8e0N?5De5h
z5WiaSb25@1HN9izO6*M#_m*)lyRzu)}2%h8Swc71E#j*z6+Ni=DA+NSS$Yr12y}
z7$+R3YU9r5@8k4bSR6zn9ZLNv?vFk97MM4c-d`c~Bx?;
z+uUKnFv$48o)U}g)C%b2v>TeQMWNH;juSKLVQ)|!0beMO0i?5seERo%j
zJA>!-rT)d*mSBKY_yc0cvz^8rLC>ke*QIAY9lN{3Ux_as|_J-`+#0oh?>*ALe
zrMa(iD*OG(pTiin@qq7kjv}rY4lza_w!T`j(J82rJfS8-)gw6&}i!1s*UMy7Sii41>J&
z;k>Du*l&+A73mX^P`GCsz2IjD1O0;H#)jYHAX?~G^>?(XT9MVb}XVE@N3Izqg;y
z)W#ibRdONYY(v%$n#Y)c6@rNLJ!f%iGO(}D3Rtp5h3XP~;VE@acbt3jOo>rO#C@A>
zVx<_Xi6>8&4lG8ozsY}Io-DUWlRt@JRb^n^h^OYUny#q=7Q$;i-;6`DPjh}`WjUOS
z_TlaN;myC;y#KPQm<*AM|d<@6VU&9<&~AXUN#Y3Hea(9laSdTP>n
z3skWUTB5>mBHoV28!Q~zF~}rx3Dnix^N0Ml
zifKAjBdU4(Y
z(|xb?dx=qZX12dB@yzw%sI600x&~uSoafbRKb(-o_RAuO`%%PDVDnoLntnM#dD?WO
zI>Zm2`lff|HYCcQtcW>5em^PEZnlwWB02y^?prR1?|ZMk(H{~TCqpJYcV@79ESPJZ
zZFrn4g%6JUl3TDI{?r@o2;Qqdn0Dr}V{Z=mJ`EBjCd}WlCGkXBl-pnXIg@4>Y;)ST
zj)%QOFBx(M5kHdHJ}1IDG(1>qn5<++LsxIB`xfk2W9rsHPRYf`#|*4@y4V1bDfOI|
zW<)me=m&=5IBF#f?>it*iikWH`pO$utQOWzjtV0^nMT|0PFbQkEtLzu7{)x
ziYVn0FxAhxsPt;by5BATE7rs-gZ#6KyT<`t()CnAGQ^J>i2ci5R#xEqUi<0e{(pR?
znlJfR7swNw)&{@q2DdZ~5`r}?4*!-UGBTCJGBzYH2W-h4e=h9D(iiE(h)_?YnJ+WY0a1uk{_@6_Q{mNdQE
z1L4Q}=sFJZJ8pQdzH6IwcreqJ8a~;WINWlcC6_PIBr#d7h+}W(SoGVGSnBJZBz!(?
zOyh24*q{O59D~sozQNbh6#;+wPjz-)RS@d>#6vVCz-{+`)ohw5N2
z;e0L9b*An(LACsS!wSdjF~j5Fh59~uHH(ad*w|s7Sy>65l|J&>dN=;$cgM6P`{F3AGV%I|!U?&5C
z^?%=S#s7Fhasb<*@;z`XnfW^|d2Y#|$|d}L!ZEQV5DfxrW=sD}CiZ*HUphn2AM69C
zPlW~0h|Pv~^s!D64p?KfG;k}HwM?<;1M^m_dN!Y_iv1^EyC+|*rkt~?Rs@D0*E_Q#
zCT^(#F9oNwBqI%S>k$Bh}xP_%s-Eqlo+D)A_rb-T8ObvrFNqJ
z;<-Kk@9leNe|F-f)71epAM3wO%c}DAtu==i4(*xei|x8PE6$%*4C!F+oYa0I(%Hm_
z)a0w}I9}`=h|PdR?RR-V?fqAIptmx=9`9}H<8H@<2*=3jMgm->aJs;OY(oIHD7+t}DB4DhU+?vG1oI${
z15%d+s)Mk;OT4bZzAnAe4#al{`mik50s6
zMxIqEc)dtq!S>CsG~)^F*D%ES)!(L(|4Ti^j%LEVCcnYrWWCJb4`y1?zg+
zfbQ4);|Dtj2gjpFkC>UI@`itfKcU9yK-i;Xxw=an@0u5c7c}g4;Rl_r*5wchg%d2U
zW=P_op}iaO@%E;nq4{a&@xJc90-;8Oh#>t4M>dui|IE%AQwd
zTbY}jXrdC4*oiF&4mVJ`sjI6S8#7#U{B_xy6jqSpI6T~pcUN1zOr8?IRQf2{;7kHS
z4`p@pOr0XQlZJwV;y_tv`sCx+uaB-c8J2GICHMPi+!Ug*TI@#5Ib11k{m#h4US@{Is9-136@L+xx87Rg2

[PATCH] MAINTAINERS: Remove Martin Galvan

2019-09-30 Thread Sebastian Huber
Remove Martin Galvan due to inactivity from the Write After Approval
list.
---
 MAINTAINERS | 1 -
 1 file changed, 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 2732d773c4..68137a80d9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -48,7 +48,6 @@ Write After Approval
 
 Daniel Hellstrom   dan...@gaisler.com
 Ben Gras   b...@rtems.org
-Martin Galvan  martin.gal...@tallertechnologies.com
 Pavel Pisa pp...@pikron.com
 Christian Mauderer christian.maude...@embedded-brains.de
 
-- 
2.16.4

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


[PATCH 1/2] Move contributing content from eng to user

2019-09-30 Thread Sebastian Huber
en you are finished. If you wait until you think you are done
-to begin interacting with the RTEMS team, you might find that you did
-some things wrong and you may have to rewrite parts of your RTEMS port,
-which is a waste of your valuable time.
-
-''Why should we care if our port is integrated into the official
-RTEMS sources? We can distribute it ourselves to whoever is interested.''
-
-Yes, the GNU GPL allows you to do that. But by doing so, you end up
-having to maintain that code yourself; this can be a significant
-effort over time as the RTEMS sources change rapidly.
-
-You also lose the advantage of wider exposure by including your port
-in the official RTEMS sources maintained by the RTEMS Project.
-The wider exposure in the RTEMS developer and tester community will
-help keep your work up to date with the current sources. You may even
-find that volunteers will run the ever-growing test suite on your port
-and fix problems during the development cycle -- sometimes without your
-intervention.
-
-It has been our experience that integrated ports tend to ultimately
-be of better quality and stay up to date from release to release.
-
-''Why should we communicate up front? We're happy to let the
-RTEMS developers integrate our stuff later.''
-
-See above. It will save work for you over both the short and the
-long term, and it is the right thing to do.
-
-''Aspects of my target environment that my application exploits
-are still under NDA.''
-
-Nevertheless, if the target hardware is built of any commercial parts
-that are generally available including, but not limited to, the CPU
-or peripherals, then that portion of your work is still of general use.
-Similarly, if you have written software that adheres to existing API or
-interface standards, then that portion is also of general use.
-Our experience is that most embedded applications do utilize a custom
-mix of hardware and application, but they are built upon layers of hardware
-and software components that are in no way unique to the project.
-
-If you are porting to an unreleased CPU family or model, then just
-announcing it is important because other RTEMS users may be planning
-to use it and some of them may already be trying to port RTEMS on
-their own. Your customers might be happier to know that your port
-will eventually be available. Also, there is no requirement that RTEMS
-include all features or ports at any particular time, so you are encouraged
-to submit discrete pieces of functionality in stages.
-
-Assume that your processor has some new functionality or peripherals.
-However that functionality is still covered by NDA, but the basic core
-architecture is not. It is still to your advantage to go ahead and work
-with the developers early to provide a "base port" for the CPU family.
-That base port would only use the publicly available specifications
-until such time as the NDA is lifted. Once the NDA is lifted you can
-work with the developers to provide the code necessary to take
-advantage of the new functionality.
-
-Ultimately, cooperating with the free software community as early as
-possible helps you by decreasing your development cycle, decreasing
-your long term maintenance costs and may help raise interest in your
-processor by having a free compiler implementation available to
-anyone who wants to take a look.
-
-Finally, please note that GPL-covered code may not be distributed
-under an NDA, as explained by Richard Stallman in
-http://gcc.gnu.org/ml/gcc/2001-07/msg01342.html.
diff --git a/user/support/contrib.rst b/user/support/contrib.rst
index 29c554d..fb95e34 100644
--- a/user/support/contrib.rst
+++ b/user/support/contrib.rst
@@ -2,6 +2,7 @@
 
 .. Copyright (C) 2019 embedded brains GmbH
 .. Copyright (C) 2019 Sebastian Huber
+.. Copyright (C) 2018 Joel Sherill
 .. Copyright (C) 2016 Chris Johns 
 
 .. index:: community; developers
@@ -15,3 +16,148 @@ Developers can find help and support on the :r:list:`devel`.
 
 Technical documents including design, :r:url:`gsoc`, :r:url:`socis` can be
 found on the :r:url:`devel`.
+
+Why Contribute?
+===
+
+If you are writing a major extension to RTEMS, such as a port
+to a new CPU family or model, a new target board, a major rewrite
+of some existing component, or adding some missing functionality,
+please keep in mind the importance of keeping other developers informed.
+Part of being a good cooperating member of the RTEMS development team is the
+responsibility to consider what the other developers need in order
+to work effectively.
+
+Nobody likes to do a lot of work and find it was duplicated effort.
+So when you work on a major new feature, you should tell
+rtems-us...@www.rtems.com what you are working on, and give
+occasional reports of how far you have come and how confident
+you are that you will finish the job. This way, other developers
+(if they are paying attention) will be aware which projects would
+duplicate your effort, and can either join up with y

[PATCH 2/2] user: Update contributing section

2019-09-30 Thread Sebastian Huber
---
 user/support/contrib.rst | 41 +++--
 1 file changed, 19 insertions(+), 22 deletions(-)

diff --git a/user/support/contrib.rst b/user/support/contrib.rst
index fb95e34..04c5dd8 100644
--- a/user/support/contrib.rst
+++ b/user/support/contrib.rst
@@ -21,8 +21,8 @@ Why Contribute?
 ===
 
 If you are writing a major extension to RTEMS, such as a port
-to a new CPU family or model, a new target board, a major rewrite
-of some existing component, or adding some missing functionality,
+to a new CPU family (processor architecture) or model, a new target board, a
+major rewrite of some existing component, or adding some missing functionality,
 please keep in mind the importance of keeping other developers informed.
 Part of being a good cooperating member of the RTEMS development team is the
 responsibility to consider what the other developers need in order
@@ -30,7 +30,7 @@ to work effectively.
 
 Nobody likes to do a lot of work and find it was duplicated effort.
 So when you work on a major new feature, you should tell
-rtems-us...@www.rtems.com what you are working on, and give
+:r:list:`users` what you are working on, and give
 occasional reports of how far you have come and how confident
 you are that you will finish the job. This way, other developers
 (if they are paying attention) will be aware which projects would
@@ -38,11 +38,12 @@ duplicate your effort, and can either join up with you, or 
at
 least avoid spending time on something that will be unnecessary
 because of your work. If, for whatever reason, you are not in a
 position to publicly discuss your work, please at least privately
-let a Steering Committee member know about it so they can look
-out for duplicated effort or possible collaborators.
+let an
+`RTEMS maintainer `_
+know about it so they can look out for duplicated effort or possible
+collaborators.
 
-You should also monitor the
-`RTEMS Mailing Lists 
`_.
+You should also monitor the :r:list:`users` and :r:list:`devel`
 to see if someone else mentions working on a similar
 project to yours. If that happens, speak up!
 
@@ -58,7 +59,7 @@ Someone else may be able to finish the job.
 Many people have done RTEMS ports or BSPs on their own, to a wide
 variety of processors, without much communication with the RTEMS
 development team. However, much of this work has been lost over
-time, or have proven very hard to integrate. So, what we're asking
+time, or have proven very hard to integrate. So, what we are asking
 is that, to the maximum extent possible, you communicate with us
 as early on and as much as possible.
 
@@ -70,9 +71,9 @@ them. While the focus here is on new ports and BSPs, we 
believe that
 the issues are similar for other RTEMS development efforts including
 student efforts to implement new algorithmic optimizations.
 
-''Our engineers understand our target environment better than anyone
-else, and we have a tight schedule. Why should we work with the RTEMS
-developers, when we can get the code out faster by whacking it out on our 
own?''
+Our engineers understand our target environment better than anyone else, 
and
+we have a tight schedule. Why should we work with the RTEMS developers, 
when
+we can get the code out faster by whacking it out on our own?
 
 You understand your target environment better than anyone else.
 However, the RTEMS developers understand RTEMS better than anyone
@@ -99,10 +100,10 @@ to begin interacting with the RTEMS team, you might find 
that you did
 some things wrong and you may have to rewrite parts of your RTEMS port,
 which is a waste of your valuable time.
 
-''Why should we care if our port is integrated into the official
-RTEMS sources? We can distribute it ourselves to whoever is interested.''
+Why should we care if our port is integrated into the official RTEMS
+sources? We can distribute it ourselves to whoever is interested.
 
-Yes, the GNU GPL allows you to do that. But by doing so, you end up
+Yes, the RTEMS licenses allows you to do that. But by doing so, you end up
 having to maintain that code yourself; this can be a significant
 effort over time as the RTEMS sources change rapidly.
 
@@ -117,14 +118,14 @@ intervention.
 It has been our experience that integrated ports tend to ultimately
 be of better quality and stay up to date from release to release.
 
-''Why should we communicate up front? We're happy to let the
-RTEMS developers integrate our stuff later.''
+Why should we communicate up front? We are happy to let the RTEMS 
developers
+integrate our stuff later.
 
 See above. It will save work for you over both the short and the
 long term, and it is the right thing to do.
 
-''Aspects of my target environment that my application exploits
-are still under NDA.''
+Aspects of my target environment that my application exploits are still
+

[PATCH] eng: Update issue tracking section

2019-09-30 Thread Sebastian Huber
---
 eng/issue-tracking.rst | 21 -
 1 file changed, 8 insertions(+), 13 deletions(-)

diff --git a/eng/issue-tracking.rst b/eng/issue-tracking.rst
index 62c8a28..1039b41 100644
--- a/eng/issue-tracking.rst
+++ b/eng/issue-tracking.rst
@@ -1,21 +1,16 @@
 .. SPDX-License-Identifier: CC-BY-SA-4.0
 
-.. Copyright (C) 2018.
-.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
+.. Copyright (C) 2019 embedded brains GmbH
+.. Copyright (C) 2019 Sebastian Huber
+.. Copyright (C) 2018 Joel Sherill
 
 Issue Tracking
 **
 
-TBD Review process, workflows, etc
-
-TBD - This covers Issue Tracking and Trac usage
-Need instructions which weave useful URLs including ones like these
-https://devel.rtems.org/query
-https://devel.rtems.org/wiki/NewTicket
+The RTEMS Project uses Trac to manage all change requests and problem reports
+and refers to either as a ticket.
 
-Filing a Change Request or Problem Report
-=
+The bug reporting procedure is documented in the
+`RTEMS User Manual 
<https://docs.rtems.org/branches/master/user/support/bugs.html>`_.
 
-The RTEMS Project uses Trac to manage all change requests and problem reports
-and refers to either as a ticket.  Ticket may be filed or viewed at
-https://devel.rtems.org/wiki/Release
+TBD Review process, workflows, etc.
-- 
2.16.4

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


Re: [PATCH v3] riscv: add freedom E310 Arty A7 bsp

2019-09-30 Thread Sebastian Huber

Hello Pragnesh Patel,

could you please use this license for new code:

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

It would be nice if you could use a coding style close to the existing 
code in this BSP (only if you have time).


Please don't change the default values in configure.ac and do not assume 
by default you build the BSP for the E310. You can add a BSP variant, e.g.


bsps/riscv/riscv/config/e310arty.cfg

In the BSP options macros you can use the BSP name to change the 
defaults, see


c/src/lib/libbsp/powerpc/qoriq/configure.ac

The riscv_console_probe() iterates over all nodes of the device tree, 
please add the support for your driver to this loop.


--
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: Help on Newlib x86_64 fenv.h

2019-09-29 Thread Sebastian Huber

Hello Joel,

why did you omit the USE_LIBTOOL in

newlib/libm/machine/x86_64/Makefile.am

which is present in

newlib/libm/machine/i386/Makefile.am

?

If it is not needed any more, then maybe it should get removed everywhere.

--
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: libbsd update of master branch

2019-09-25 Thread Sebastian Huber

On 25/09/2019 13:10, mko wrote:



On 25/09/2019, at 11:07 PM, Sebastian Huber 
 wrote:

On 25/09/2019 13:00, Sebastian Huber wrote:

On 25/09/2019 12:37, mko wrote:

I just checked the freebsd branch, it’s on Freebsd-12-Stable. Have you consider 
using the coming FreeBSD-12.1-Release? It’s in Beta, and the official release 
will be on November.

I track the stable/12 branch so that I can use a git rebase to update the 
libbsd.

There are two branches in libbsd, the 5-freebsd-12 branch tracks stable/12 and 
the master tracks trunk.


Cool, I hope the new CAM based SDIO stack will bring sdio wifi support to rtems


It is feasible to port it, however, I don't know anyone working on 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: libbsd update of master branch

2019-09-25 Thread Sebastian Huber

On 25/09/2019 13:00, Sebastian Huber wrote:

On 25/09/2019 12:37, mko wrote:
I just checked the freebsd branch, it’s on Freebsd-12-Stable. Have you 
consider using the coming FreeBSD-12.1-Release? It’s in Beta, and the 
official release will be on November.


I track the stable/12 branch so that I can use a git rebase to update 
the libbsd.


There are two branches in libbsd, the 5-freebsd-12 branch tracks 
stable/12 and the master tracks trunk.


--
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: libbsd update of master branch

2019-09-25 Thread Sebastian Huber

On 25/09/2019 12:37, mko wrote:

I just checked the freebsd branch, it’s on Freebsd-12-Stable. Have you consider 
using the coming FreeBSD-12.1-Release? It’s in Beta, and the official release 
will be on November.


I track the stable/12 branch so that I can use a git rebase to update 
the libbsd.


--
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: libbsd update of master branch

2019-09-25 Thread Sebastian Huber

On 20/09/2019 06:55, Sebastian Huber wrote:

Hello,

are there any pending patches for the libbsd master branch? I would like 
to update to the latest FreeBSD trunk early next week.


I am done with the update and wait currently for some Newlib patch 
integrations.


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

Newlib update?

2019-09-25 Thread Sebastian Huber

Hello,

I would like to update Newlib soon to update the libbsd. What is the 
status of the fenv.h support which is broken on i386 and x86_64?


--
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: BSD licensed Picolibc 1.0 released

2019-09-25 Thread Sebastian Huber

On 24/09/2019 17:03, Gedare Bloom wrote:

RTEMS has a fairly strong relationship (dependency) with newlib, and
that has been working well for a long time. Although the prospect of
having a way to 'drop-in' alternative libc could be nice for small
targets, it would be of more interest to us to see ways to optimize
newlib to shrink it if needed. The use of stripped-down libc for
low-resource targets usually means a feature-rich RTOS like RTEMS will
not be needed either. These kinds of libc are more interesting for
baremetal or low-complexity RTOSs, and some hypervisor-like systems
that want an extremely small, trusted code base.

But, thanks for the heads up about the picolibc.


This is also my point of view. I would spend my time in improving 
Newlib. For example, the struct _reent could be replaced with 
thread-local storage. I also think that we should get rid of the C 
locale support.


--
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] implementation of smp test smpmrsp02

2019-09-25 Thread Sebastian Huber

On 24/09/2019 19:08, Ricardo Gomes (1161078) wrote:

---
  testsuites/smptests/Makefile.am |  16 ++
  testsuites/smptests/configure.ac|   2 +
  testsuites/smptests/smpmrsp02/init.c| 231 
  testsuites/smptests/smpmrsp02/smpmrsp02.doc |  15 ++
  4 files changed, 264 insertions(+)
  create mode 100755 testsuites/smptests/smpmrsp02/init.c
  create mode 100644 testsuites/smptests/smpmrsp02/smpmrsp02.doc

diff --git a/testsuites/smptests/Makefile.am b/testsuites/smptests/Makefile.am
index 38cc87e3c5..edb6478b8f 100644
--- a/testsuites/smptests/Makefile.am
+++ b/testsuites/smptests/Makefile.am
@@ -314,6 +314,18 @@ smpmrsp01_CPPFLAGS = $(AM_CPPFLAGS) 
$(TEST_FLAGS_smpmrsp01) \
  endif
  endif
  
+if HAS_SMP

+if TEST_smpmrsp02
+smp_tests += smpmrsp02
+smp_screens += smpmrsp02/smpmrsp02.scn
+smp_docs += smpmrsp02/smpmrsp02.doc
+smpmrsp02_SOURCES = smpmrsp02/init.c
+smpmrsp02_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_smpmrsp02) \
+   $(support_includes)
+endif
+endif
+
+


Please avoid extra blank lines.


  if HAS_SMP
  if TEST_smpmulticast01
  smp_tests += smpmulticast01
@@ -670,4 +682,8 @@ smpwakeafter01_CPPFLAGS = $(AM_CPPFLAGS) 
$(TEST_FLAGS_smpwakeafter01) \
  endif
  endif
  
+

+
+
  noinst_PROGRAMS = $(smp_tests)
+


Here also.


diff --git a/testsuites/smptests/configure.ac b/testsuites/smptests/configure.ac
index 83b5b9fe41..6336b4e481 100644
--- a/testsuites/smptests/configure.ac
+++ b/testsuites/smptests/configure.ac
@@ -60,6 +60,7 @@ RTEMS_TEST_CHECK([smplock01])
  RTEMS_TEST_CHECK([smpmigration01])
  RTEMS_TEST_CHECK([smpmigration02])
  RTEMS_TEST_CHECK([smpmrsp01])
+RTEMS_TEST_CHECK([smpmrsp02])
  RTEMS_TEST_CHECK([smpmulticast01])
  RTEMS_TEST_CHECK([smpmutex01])
  RTEMS_TEST_CHECK([smpmutex02])
@@ -93,5 +94,6 @@ RTEMS_TEST_CHECK([smpthreadpin01])
  RTEMS_TEST_CHECK([smpunsupported01])
  RTEMS_TEST_CHECK([smpwakeafter01])
  
+

  AC_CONFIG_FILES([Makefile])
  AC_OUTPUT
diff --git a/testsuites/smptests/smpmrsp02/init.c 
b/testsuites/smptests/smpmrsp02/init.c
new file mode 100755
index 00..c097fde50b
--- /dev/null
+++ b/testsuites/smptests/smpmrsp02/init.c
@@ -0,0 +1,231 @@
+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (C) 2019 Ricardo Gomes
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */


License looks good. I hope you are actually the copyright owner and not 
the university.



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


Please try to reduce the number of includes, e.g. why do you need 
, , and ?



+#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);
+}


How much time to you have left for this integration work? Would it be 
possible to re-write the tests to use the new RTEMS Test Framework?


https://docs.rtems.org/branches/master/eng/test-framework.html#the-rtems-test-framework

Is it possible to place all the test cases into one test program?

The coding style is not really in line with what is already present in 
the test suite, but this would be not an issue for me.


Please make sure that the tests compile without warnings (I didn't chec

Re: What opens stdout? printf() fails after rtems-tester printf() succeeds.

2019-09-24 Thread Sebastian Huber

Hello Peter,

did you configure the console driver?

https://docs.rtems.org/branches/master/c-user/configuring_a_system.html#configure-application-needs-console-driver

--
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: [rtems-libbsd commit] Add pselect()

2019-09-24 Thread Sebastian Huber

On 24/09/2019 15:34, Joel Sherrill wrote:

Before I update the compliance tracking to add pselect(), have any other
POSIX methods been added recently which I have missed?


This is only a partial implementation. The signal mask stuff is not 
supported. I needed it for the new ping/ping6 commands.


--
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: LLVM on openSUSE 15.1

2019-09-24 Thread Sebastian Huber

Hello,

with the libedit development package mentioned by Gedare, I got a bit 
further in the build:


onfig: tools/rtems-llvm-8.0.1.cfg
package: rtems-llvm-8.0.1-x86_64-linux-gnu-1
building: rtems-llvm-8.0.1-x86_64-linux-gnu-1
error: building rtems-llvm-8.0.1-x86_64-linux-gnu-1
Build FAILED
error: failure to create error report
Build Set: Time 0:34:28.127871
Traceback (most recent call last):
  File "../source-builder/sb/cmd-set-builder.py", line 26, in 
setbuilder.run()
  File 
"/scratch/git-rtems-source-builder/source-builder/sb/setbuilder.py", 
line 732, in run

b.build(deps, mail = mail)
  File 
"/scratch/git-rtems-source-builder/source-builder/sb/setbuilder.py", 
line 473, in build

self.build_package(configs[s], b)
  File 
"/scratch/git-rtems-source-builder/source-builder/sb/setbuilder.py", 
line 258, in build_package

_build.make()
  File "/scratch/git-rtems-source-builder/source-builder/sb/build.py", 
line 579, in make

self._generate_report_('Build: %s' % (gerr))
  File "/scratch/git-rtems-source-builder/source-builder/sb/build.py", 
line 126, in _generate_report_

self.opts, header, footer)
  File 
"/scratch/git-rtems-source-builder/source-builder/sb/ereport.py", line 
56, in generate

l.write(os.linesep.join(r))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 
156: ordinal not in range(128)


The build error was:

/scratch/git-rtems-source-builder/rtems/build/rtems-llvm-8.0.1-x86_64-linux-gnu-1/llvm-8.0.1/tools/lldb/source/Core/IOHandler.cpp:14:10: 
fatal error: panel.h: No such file or directory

 #include 
  ^
compilation terminated.

This looks like an openSUSE problem:

https://build.opensuse.org/package/view_file/openSUSE:Leap:42.2/llvm/lldb-cmake.patch?expand=0

--
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: libbsd build problem on powerpc

2019-09-20 Thread Sebastian Huber

On 20/09/2019 12:54, Chris Johns wrote:

On 20 Sep 2019, at 5:38 pm, Sebastian Huber 
 wrote:
I get the following build error on powerpc with the libbsd:


Is this with master?


No, the 5-freebsd-12 branch.




/scratch/git-rtems-libbsd (5-freebsd-12) > ./waf -j 1
Waf: Entering directory 
`/scratch/git-rtems-libbsd/build/powerpc-rtems5-qoriq_e500-default'
[1794/1909] Linking build/powerpc-rtems5-qoriq_e500-default/debugger01.exe
/build/rtems/5/lib/gcc/powerpc-rtems5/7.4.1/../../../../powerpc-rtems5/bin/ld: 
cannot find -ldebugger
collect2: error: ld returned 1 exit status


The library has been built?


No:

# Filter debugger to only build for architectures that have a target backend
AC_MSG_CHECKING([whether CPU supports libdebugger])
case $RTEMS_CPU in
  arm | i386)
   HAVE_LIBDEBUGGER=yes ;;
  *)
   HAVE_LIBDEBUGGER=no ;;
esac
AM_CONDITIONAL(LIBDEBUGGER,[test x"$HAVE_LIBDEBUGGER" = x"yes"])
AC_MSG_RESULT([$HAVE_LIBDEBUGGER])

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

libbsd build problem on powerpc

2019-09-20 Thread Sebastian Huber

Hello,

I get the following build error on powerpc with the libbsd:

/scratch/git-rtems-libbsd (5-freebsd-12) > ./waf -j 1
Waf: Entering directory 
`/scratch/git-rtems-libbsd/build/powerpc-rtems5-qoriq_e500-default'

[1794/1909] Linking build/powerpc-rtems5-qoriq_e500-default/debugger01.exe
/build/rtems/5/lib/gcc/powerpc-rtems5/7.4.1/../../../../powerpc-rtems5/bin/ld: 
cannot find -ldebugger

collect2: error: ld returned 1 exit status

Waf: Leaving directory 
`/scratch/git-rtems-libbsd/build/powerpc-rtems5-qoriq_e500-default'

Build failed
 -> task in 'debugger01.exe' failed with exit status 1 (run with -v to 
display more information)


I tried to understand how the TestIfHeaderComposer() works, but I did't 
figure out what the purpose of the "define_keys" is.


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

libbsd update of master branch

2019-09-19 Thread Sebastian Huber

Hello,

are there any pending patches for the libbsd master branch? I would like 
to update to the latest FreeBSD trunk early next week.


--
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: LLVM on openSUSE 15.1

2019-09-18 Thread Sebastian Huber

On 19/09/2019 01:52, Chris Johns wrote:

On 18/9/19 6:56 pm, Chris Johns wrote:

Building the unstable RTEMS 6 toolchain results in an endless build of automake
with this patch on FreeBSD 12.


OK. I will have a look tomorrow.


The copy of the patch from rtems/config/tools/rtems-automake-1.12.6-1.cfg to the
bare/devel resulted in the patch being duplicated and this broken the build
because the second patch resulted in patch asking we want to reverse the patch.
The include at the end of the rtems automake config is to the bare/devel
automake config.

I have pushed patches to detect duplicate adds in a simple way and remove the
duplicate patch.

Note, the detection can be easily be beaten if the arguments are not the same in
same order.


Thanks for fixing this. I didn't take into account that the RTEMS file 
includes the bare/devel file.


--
Sebastian Huber, embedded brains GmbH

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

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

Re: LLVM on openSUSE 15.1

2019-09-18 Thread Sebastian Huber

On 18/09/2019 10:29, Chris Johns wrote:

On 18/9/19 4:09 pm, Sebastian Huber wrote:

On 18/09/2019 07:40, Chris Johns wrote:

On 18/9/19 3:36 pm, Sebastian Huber wrote:

On 17/09/2019 08:07, Sebastian Huber wrote:



On 17/09/2019 08:07, Chris Johns wrote:

On 17/9/19 3:32 pm, Sebastian Huber wrote:

Hello,

I didn't get far:

config.status: creating t/wrap/automake-1.12
+ make -j 12 all
     GEN  automake
     GEN  aclocal
     GEN  t/ax/shell-no-trail-bslash
     GEN  doc/aclocal.1
     GEN  doc/automake.1
     GEN  runtest
     GEN  t/ax/test-defs.sh
     GEN  lib/Automake/Config.pm
     GEN  doc/aclocal-1.12.1
     GEN  doc/automake-1.12.1
help2man: can't get `--help' info from automake-1.12
Try `--no-discard-stderr' if option outputs to stderr
make: *** [Makefile:4114: doc/automake-1.12.1] Error 255

That is weird because this is what we build for gcc as we need autoconf to
boot
strap RTEMS.


This is indeed quite weird, I never had problems building automake before. I
will try to figure out what went wrong here.


We have configuration files for Automake 1.12.6. I fixed it like this:

https://git.rtems.org/rtems-source-builder/commit/?id=bf7b4ad68f0faa9a35e52ca1baafb6f72c0fb673



This change breaks the build of the RTEMS toolchain on FreeBSD 12.



I do not understand ...
https://lists.rtems.org/pipermail/build/2019-September/003517.html ?


Building the unstable RTEMS 6 toolchain results in an endless build of 
automake with this patch on FreeBSD 12.


--
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: LLVM on openSUSE 15.1

2019-09-18 Thread Sebastian Huber

On 18/09/2019 07:40, Chris Johns wrote:

On 18/9/19 3:36 pm, Sebastian Huber wrote:

On 17/09/2019 08:07, Sebastian Huber wrote:



On 17/09/2019 08:07, Chris Johns wrote:

On 17/9/19 3:32 pm, Sebastian Huber wrote:

Hello,

I didn't get far:

config.status: creating t/wrap/automake-1.12
+ make -j 12 all
    GEN  automake
    GEN  aclocal
    GEN  t/ax/shell-no-trail-bslash
    GEN  doc/aclocal.1
    GEN  doc/automake.1
    GEN  runtest
    GEN  t/ax/test-defs.sh
    GEN  lib/Automake/Config.pm
    GEN  doc/aclocal-1.12.1
    GEN  doc/automake-1.12.1
help2man: can't get `--help' info from automake-1.12
Try `--no-discard-stderr' if option outputs to stderr
make: *** [Makefile:4114: doc/automake-1.12.1] Error 255

That is weird because this is what we build for gcc as we need autoconf to boot
strap RTEMS.


This is indeed quite weird, I never had problems building automake before. I
will try to figure out what went wrong here.


We have configuration files for Automake 1.12.6. I fixed it like this:

https://git.rtems.org/rtems-source-builder/commit/?id=bf7b4ad68f0faa9a35e52ca1baafb6f72c0fb673


This change breaks the build of the RTEMS toolchain on FreeBSD 12.

--
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: LLVM on openSUSE 15.1

2019-09-17 Thread Sebastian Huber

On 17/09/2019 08:07, Sebastian Huber wrote:



On 17/09/2019 08:07, Chris Johns wrote:

On 17/9/19 3:32 pm, Sebastian Huber wrote:

Hello,

I didn't get far:

config.status: creating t/wrap/automake-1.12
+ make -j 12 all
   GEN  automake
   GEN  aclocal
   GEN  t/ax/shell-no-trail-bslash
   GEN  doc/aclocal.1
   GEN  doc/automake.1
   GEN  runtest
   GEN  t/ax/test-defs.sh
   GEN  lib/Automake/Config.pm
   GEN  doc/aclocal-1.12.1
   GEN  doc/automake-1.12.1
help2man: can't get `--help' info from automake-1.12
Try `--no-discard-stderr' if option outputs to stderr
make: *** [Makefile:4114: doc/automake-1.12.1] Error 255
That is weird because this is what we build for gcc as we need 
autoconf to boot

strap RTEMS.


This is indeed quite weird, I never had problems building automake 
before. I will try to figure out what went wrong here.


We have configuration files for Automake 1.12.6. I fixed it like this:

https://git.rtems.org/rtems-source-builder/commit/?id=bf7b4ad68f0faa9a35e52ca1baafb6f72c0fb673

--
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: LLVM on openSUSE 15.1

2019-09-17 Thread Sebastian Huber

On 17/09/2019 08:07, Sebastian Huber wrote:



On 17/09/2019 08:07, Chris Johns wrote:

On 17/9/19 3:32 pm, Sebastian Huber wrote:

Hello,

I didn't get far:

config.status: creating t/wrap/automake-1.12
+ make -j 12 all
   GEN  automake
   GEN  aclocal
   GEN  t/ax/shell-no-trail-bslash
   GEN  doc/aclocal.1
   GEN  doc/automake.1
   GEN  runtest
   GEN  t/ax/test-defs.sh
   GEN  lib/Automake/Config.pm
   GEN  doc/aclocal-1.12.1
   GEN  doc/automake-1.12.1
help2man: can't get `--help' info from automake-1.12
Try `--no-discard-stderr' if option outputs to stderr
make: *** [Makefile:4114: doc/automake-1.12.1] Error 255
That is weird because this is what we build for gcc as we need 
autoconf to boot

strap RTEMS.


This is indeed quite weird, I never had problems building automake 
before. I will try to figure out what went wrong here.


Building it for a normal RTEMS package works fine:

../source-builder/sb-set-builder --prefix=/build/rtems/5 5/rtems-riscv 
--no-install

RTEMS Source Builder - Set Builder, 5 (4b7af073000d modified)
warning: exe: absolute exe found in path: (__chown) /usr/sbin/chown
Build Set: 5/rtems-riscv
Build Set: 5/rtems-autotools.bset
Build Set: 5/rtems-autotools-internal.bset
config: tools/rtems-autoconf-2.69-1.cfg
package: autoconf-2.69-x86_64-linux-gnu-1
building: autoconf-2.69-x86_64-linux-gnu-1
sizes: autoconf-2.69-x86_64-linux-gnu-1: 7.497MB (installed: 0.000B)
cleaning: autoconf-2.69-x86_64-linux-gnu-1
config: tools/rtems-automake-1.12.6-1.cfg
package: automake-1.12.6-x86_64-linux-gnu-1
building: automake-1.12.6-x86_64-linux-gnu-1
sizes: automake-1.12.6-x86_64-linux-gnu-1: 8.088MB (installed: 0.000B)
cleaning: automake-1.12.6-x86_64-linux-gnu-1
cleaning: autoconf-2.69-x86_64-linux-gnu-1
cleaning: automake-1.12.6-x86_64-linux-gnu-1
Build Sizes: usage: 8.088MB total: 7.774GB (sources: 7.772GB, patches: 
1.957MB, installed 0.000B)


--
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: LLVM on openSUSE 15.1

2019-09-17 Thread Sebastian Huber



On 17/09/2019 08:07, Chris Johns wrote:

On 17/9/19 3:32 pm, Sebastian Huber wrote:

Hello,

I didn't get far:

config.status: creating t/wrap/automake-1.12
+ make -j 12 all
   GEN  automake
   GEN  aclocal
   GEN  t/ax/shell-no-trail-bslash
   GEN  doc/aclocal.1
   GEN  doc/automake.1
   GEN  runtest
   GEN  t/ax/test-defs.sh
   GEN  lib/Automake/Config.pm
   GEN  doc/aclocal-1.12.1
   GEN  doc/automake-1.12.1
help2man: can't get `--help' info from automake-1.12
Try `--no-discard-stderr' if option outputs to stderr
make: *** [Makefile:4114: doc/automake-1.12.1] Error 255

That is weird because this is what we build for gcc as we need autoconf to boot
strap RTEMS.


This is indeed quite weird, I never had problems building automake 
before. I will try to figure out what went wrong here.


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

LLVM on openSUSE 15.1

2019-09-16 Thread Sebastian Huber

Hello,

I didn't get far:

config.status: creating t/wrap/automake-1.12
+ make -j 12 all
  GEN  automake
  GEN  aclocal
  GEN  t/ax/shell-no-trail-bslash
  GEN  doc/aclocal.1
  GEN  doc/automake.1
  GEN  runtest
  GEN  t/ax/test-defs.sh
  GEN  lib/Automake/Config.pm
  GEN  doc/aclocal-1.12.1
  GEN  doc/automake-1.12.1
help2man: can't get `--help' info from automake-1.12
Try `--no-discard-stderr' if option outputs to stderr
make: *** [Makefile:4114: doc/automake-1.12.1] Error 255

I removed the swig build and ended up here:

CMake Error: The following variables are used in this project, but they 
are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the 
CMake files:

/scratch/git-rtems-source-builder/rtems/build/rtems-llvm-8.0.1-x86_64-linux-gnu-1/llvm-8.0.1/tools/lldb/scripts/Python/modules/readline/libedit_INCLUDE_DIRS
   used as include directory in directory 
/scratch/git-rtems-source-builder/rtems/build/rtems-llvm-8.0.1-x86_64-linux-gnu-1/llvm-8.0.1/tools/lldb/scripts/Python/modules/readline

/scratch/git-rtems-source-builder/rtems/build/rtems-llvm-8.0.1-x86_64-linux-gnu-1/llvm-8.0.1/tools/lldb/source/Core/libedit_INCLUDE_DIRS
   used as include directory in directory 
/scratch/git-rtems-source-builder/rtems/build/rtems-llvm-8.0.1-x86_64-linux-gnu-1/llvm-8.0.1/tools/lldb/source/Core

/scratch/git-rtems-source-builder/rtems/build/rtems-llvm-8.0.1-x86_64-linux-gnu-1/llvm-8.0.1/tools/lldb/source/Host/libedit_INCLUDE_DIRS
   used as include directory in directory 
/scratch/git-rtems-source-builder/rtems/build/rtems-llvm-8.0.1-x86_64-linux-gnu-1/llvm-8.0.1/tools/lldb/source/Host

/scratch/git-rtems-source-builder/rtems/build/rtems-llvm-8.0.1-x86_64-linux-gnu-1/llvm-8.0.1/tools/lldb/source/Interpreter/libedit_INCLUDE_DIRS
   used as include directory in directory 
/scratch/git-rtems-source-builder/rtems/build/rtems-llvm-8.0.1-x86_64-linux-gnu-1/llvm-8.0.1/tools/lldb/source/Interpreter

libedit_LIBRARIES (ADVANCED)
linked by target "readline" in directory 
/scratch/git-rtems-source-builder/rtems/build/rtems-llvm-8.0.1-x86_64-linux-gnu-1/llvm-8.0.1/tools/lldb/scripts/Python/modules/readline


I guess I will stick to the openSUSE package for LLVM.

--
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: Add chapter for newib build in RTEMS Docs

2019-09-12 Thread Sebastian Huber

On 13/09/2019 03:34, Chris Johns wrote:

On 13/9/19 8:42 am, Joel Sherrill wrote:

On Thu, Sep 12, 2019 at 2:09 PM Gedare Bloom  wrote:

Hello Vaibhav,

It would be nice to provide such documentation, but I don't know that
we have an existing location that would be an ideal fit. I think the
topic is out of scope for User Manual. If you are motivated to write
something though, you could prepare it first as a standalone guide.

If we have a name for the document like "Maintainers Guide" or something,
it could have a focus on procedures that only core developers would need.

+ bootstrapping newlib and building it independently
+ modifying gcc, running tests,
+ submitting Coverity runs
+ running Doxygen
+ ...

These are all valid and important however can these reside in the Software
Engineering manual?

We current have ...

  1. RTEMS Software Engineering
  2. RTEMS Filesystem Design Guide
  3. RTEMS Development Environment Guide
  4. RTEMS BSP and Driver Guide

plus 'RTEMS BSP and Driver Guide' which I am not sure about. All these cover
some aspect of maintaining and developing RTEMS. Should we be considering
consolidation rather than expansion?


Yes, we should definitely aim to consolidate the documentation set and 
not add new documents. I would put this topic into the RTEMS Software 
Engineering.


--
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 v2] Correct initial POSIX signals mask

2019-09-12 Thread Sebastian Huber

On 12/09/2019 16:41, Joel Sherrill wrote:

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


Looks good.

--
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] Correct initial POSIX signals mask

2019-09-12 Thread Sebastian Huber

On 11/09/2019 01:11, Joel Sherrill wrote:

+  if (!_System_state_Is_up(_System_state_Get())) {
+if (_Objects_Get_API(created->Object.id) == OBJECTS_INTERNAL_API) {


You have to add a couple of spaces to meet the coding style.

I would not use the system state, this could be a bit brittle on SMP 
systems. Can't you use the executing thread instead, e.g. if 
_Objects_Get_API( executing->Object.id ) == OBJECTS_INTERNAL_API, then 
api->signals_unblocked = SIGNAL_ALL_MASK?


--
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: [RTEMS][PATCH v2 0/2] riscv: add freedom E310 Arty A7

2019-09-11 Thread Sebastian Huber

On 11/09/2019 15:07, Pragnesh Patel wrote:

Fredom E310 Arty has a support for FDT but right now, u-boot (or any
bootloader) will not copy FDT address into CPU register (a1 for RISCV)
instead we have given FDT address manually as shown below:


Qemu does this an I guess U-Boot does it also. How would Linux know 
about the device tree? The bootloader must provide this information.


--
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: [RTEMS][PATCH v2 0/2] riscv: add freedom E310 Arty A7

2019-09-11 Thread Sebastian Huber

On 11/09/2019 10:43, Pragnesh Patel wrote:

Ok understood.
If i will add Freedom E310 related code in bsp/riscv/riscv directory
then there are some code changes related to "console, btimer and other
minor things" so can i add this changes under new #define let's say
#define RISCV_ENABLE_FRDME310_SUPPORT ?


Please don't add a new btimer driver. This is a legacy driver. For this 
BSP we can switch to the btimer-cpucounter.c variant.




I am planning to add this #define in configure.ac through
RTEMS_BSPOPTS_SET([RISCV_ENABLE_FRDME310_SUPPORT],[*],[1]), By default
it is disabled.
what's your suggestion on this?


Yes, this sounds good. If there are to many places with this define, 
then we have to think again how to proceed.


--
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: [RTEMS][PATCH v2 0/2] riscv: add freedom E310 Arty A7

2019-09-11 Thread Sebastian Huber

On 11/09/2019 09:27, Pragnesh Patel wrote:

Thanks for the clarification. i am also agree with your comments but
let's say in future, we want to add I2C and SPI for Freedom E310 then
what's your suggestion?


Future I2C and SPI drivers should be added to:

https://git.rtems.org/rtems/tree/cpukit/dev

They should be initialized in a BSP for example through the device tree. 
Currently, we lack a proper generic initialization via the device tree.


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


Re: rtems-addr2line not working on ARM?

2019-09-09 Thread Sebastian Huber

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.


--
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: rtems-addr2line not working on ARM?

2019-09-08 Thread Sebastian Huber

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

real0m0.425s
user0m0.293s
sys 0m0.132s

addr2line based solution on Linux:

real0m11.944s
user0m5.334s
sys 0m6.593s

LLVM has also an API to access the DWARF debug information:

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

llvm-dwarfdump media.exe | grep '\<_Workspace_Allocate\>' -B 10 -A 40
0x0163bea5:   DW_TAG_subprogram
DW_AT_external  (true)
DW_AT_name  ("_Workspace_Allocate")
DW_AT_decl_file ("wkspace.c")
DW_AT_decl_line (232)
DW_AT_prototyped(true)
DW_AT_type  (0x016388fd "*")
DW_AT_low_pc(0x00746092)
DW_AT_high_pc   (0x007460b4)
DW_AT_frame_base(DW_OP_call_frame_cfa)
DW_AT_unknown_2116  (true)
DW_AT_sibling   (0x0163bedb)

0x0163bebe: DW_TAG_formal_parameter
  DW_AT_name("size")
  DW_AT_decl_file   ("wkspace.c")
  DW_AT_decl_line   (233)
  DW_AT_type(0x01638817 "size_t")
  DW_AT_location(DW_OP_fbreg -20)

This could be used to generate wrapper functions and generic record 
function entry/exit consumers.


--
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: rtems-addr2line not working on ARM?

2019-09-07 Thread Sebastian Huber
- 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.From 3245f52d5f1cf8496daf53acc921e8b7594b375c Mon Sep 17 00:00:00 2001
From: Sebastian Huber 
Date: Fri, 6 Sep 2019 09:29:12 +0200
Subject: [PATCH] record: Use LLVM to link to the source code

Update #3665.
---
 trace/record/record-main-lttng.cc | 213 ++
 trace/wscript |   7 +-
 2 files changed, 175 insertions(+), 45 deletions(-)

diff --git a/trace/record/record-main-lttng.cc b/trace/record/record-main-lttng.cc
index dda57ef..d921143 100644
--- a/trace/record/record-main-lttng.cc
+++ b/trace/record/record-main-lttng.cc
@@ -31,9 +31,16 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
 
 #define CTF_MAGIC 0xC1FC1FC1
 #define TASK_RUNNING 0x
@@ -83,6 +90,9 @@ struct EventHeaderCompact {
   uint64_t ns;
 } __attribute__((__packed__));
 
+static const size_t kEventHeaderBits =
+sizeof(EventHeaderCompact) * BITS_PER_CHAR;
+
 struct EventRecordItem {
   EventHeaderCompact header;
   uint64_t data;
@@ -160,6 +170,8 @@ class LTTNGClient : public Client {
 }
   }
 
+  voi

Re: rtems-addr2line not working on ARM?

2019-09-06 Thread Sebastian Huber
- 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.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


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

2019-09-06 Thread Sebastian Huber

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.


If we add DWARF support to the RTEMS Trace Linker, then the 
configuration interface will drastically change since you no longer need 
the bits an pieces to construct the wrapper code. The question is on 
which API do we base this on, directly the libdwarf or instead 
rld::dwarf::file? To me this looks like a complex multi week project.


Adding pre-defined wrappers for standard functions can be done by a 
student if an example is available. They are also highly desirable due 
to the more compact format on the target. Also the consumer side is 
simplified (just a case in a switch, otherwise you have to go from an 
address to a function name to the output handler), e.g. to translate 
record items to LTTNG system call events.


I am not sure if the generator definition via configuration files is the 
right thing to do. I am more in favour of doing this in C++ via subclasses.


--
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] rtems: Make rtems_version_control_key() safer

2019-09-06 Thread Sebastian Huber
Return the empty string instead of a NULL pointer if no version key is
available.
---
 cpukit/include/rtems/version.h | 9 ++---
 cpukit/sapi/src/version.c  | 2 +-
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/cpukit/include/rtems/version.h b/cpukit/include/rtems/version.h
index d8c1206d91..30dd70cc21 100644
--- a/cpukit/include/rtems/version.h
+++ b/cpukit/include/rtems/version.h
@@ -60,10 +60,13 @@ int rtems_version_revision( void );
 
 /**
  * @brief Returns the version control key for the current version of code that
- * has been built. The key is specific to the version control system being used
- * and allows the built version to be identified.
+ * has been built.
  *
- * @retval int The version's version control key.
+ * 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.
  */
 const char *rtems_version_control_key( void );
 
diff --git a/cpukit/sapi/src/version.c b/cpukit/sapi/src/version.c
index e1e7705863..065a45c005 100644
--- a/cpukit/sapi/src/version.c
+++ b/cpukit/sapi/src/version.c
@@ -58,6 +58,6 @@ const char *rtems_version_control_key( void )
 #ifdef RTEMS_VERSION_VC_KEY
   return RTEMS_VERSION_VC_KEY;
 #else
-  return NULL;
+  return "";
 #endif
 }
-- 
2.16.4

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


Re: [PATCH] record: Use addr2line to link to the source code

2019-09-06 Thread Sebastian Huber
Using the native GNU "addr2line" tool delivers different results if I 
use the same input on Linux and MSYS2. So, this a approach is not really 
great.


--
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: rtems-addr2line not working on ARM?

2019-09-06 Thread Sebastian Huber

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.


--
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] record: Use addr2line to link to the source code

2019-09-06 Thread Sebastian Huber
Update #3665.
---
 trace/record/record-main-lttng.cc | 221 ++
 trace/wscript |  12 ++-
 2 files changed, 188 insertions(+), 45 deletions(-)

diff --git a/trace/record/record-main-lttng.cc 
b/trace/record/record-main-lttng.cc
index dda57ef..4f7b5df 100644
--- a/trace/record/record-main-lttng.cc
+++ b/trace/record/record-main-lttng.cc
@@ -28,12 +28,18 @@
 
 #include "client.h"
 
+#include 
+
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #define CTF_MAGIC 0xC1FC1FC1
 #define TASK_RUNNING 0x
@@ -83,6 +89,9 @@ struct EventHeaderCompact {
   uint64_t ns;
 } __attribute__((__packed__));
 
+static const size_t kEventHeaderBits =
+sizeof(EventHeaderCompact) * BITS_PER_CHAR;
+
 struct EventRecordItem {
   EventHeaderCompact header;
   uint64_t data;
@@ -160,6 +169,8 @@ class LTTNGClient : public Client {
 }
   }
 
+  void OpenDebug(const char* elf_file);
+
   void Destroy() {
 Client::Destroy();
 CloseStreamFiles();
@@ -180,6 +191,14 @@ class LTTNGClient : public Client {
 
   size_t cpu_count_ = 0;
 
+  std::string elf_file_;
+
+  bool resolve_address_ = false;
+
+  typedef std::map> AddressToLineMap;
+
+  AddressToLineMap address_to_line_;
+
   static rtems_record_client_status HandlerCaller(uint64_t bt,
   uint32_t cpu,
   rtems_record_event event,
@@ -213,6 +232,10 @@ class LTTNGClient : public Client {
   void OpenStreamFiles(uint64_t data);
 
   void CloseStreamFiles();
+
+  AddressToLineMap::iterator AddAddressAsHexNumber(const ClientItem& item);
+
+  AddressToLineMap::iterator ResolveAddress(const ClientItem& item);
 };
 
 static uint32_t GetAPIIndexOfID(uint32_t id) {
@@ -236,6 +259,11 @@ static const uint8_t 
kCPUPostfix[RTEMS_RECORD_CLIENT_MAXIMUM_CPU_COUNT][2] = {
 {'2', '5'},  {'2', '6'},  {'2', '7'},  {'2', '8'},  {'2', '9'},
 {'3', '0'},  {'3', '1'}};
 
+void LTTNGClient::OpenDebug(const char* elf_file) {
+  elf_file_ = elf_file;
+  resolve_address_ = true;
+}
+
 void LTTNGClient::CopyThreadName(const ClientItem& item,
  size_t api_index,
  uint8_t* dst) const {
@@ -260,15 +288,91 @@ void LTTNGClient::CopyThreadName(const ClientItem& item,
   }
 }
 
+static bool IsCodeEvent(rtems_record_event event) {
+  switch (event) {
+default:
+  return false;
+case RTEMS_RECORD_CALLER:
+case RTEMS_RECORD_LINE:
+  return true;
+  }
+}
+
+LTTNGClient::AddressToLineMap::iterator LTTNGClient::AddAddressAsHexNumber(
+const ClientItem& item) {
+  char hex[19];
+  int n = std::snprintf(hex, sizeof(hex), "0x%" PRIx64, item.data);
+  assert(static_cast(n) < sizeof(hex));
+  std::vector code(hex, hex + n + 1);
+  return address_to_line_.emplace(item.data, std::move(code)).first;
+}
+
+LTTNGClient::AddressToLineMap::iterator LTTNGClient::ResolveAddress(
+const ClientItem& item) {
+  AddressToLineMap::iterator it;
+
+  if (resolve_address_) {
+rld::process::arg_container args;
+args.push_back("addr2line");
+args.push_back("-e");
+args.push_back(elf_file_);
+args.push_back("-f");
+args.push_back("-p");
+args.push_back("-s");
+char hex[19];
+int n = std::snprintf(hex, sizeof(hex), "0x%" PRIx64, item.data);
+assert(static_cast(n) < sizeof(hex));
+args.push_back(hex);
+
+rld::process::tempfile out;
+rld::process::tempfile err;
+rld::process::status status =
+rld::process::execute(args[0], args, out.name(), err.name());
+
+if (status.type == rld::process::status::normal && status.code == 0) {
+  std::string str;
+  out.open();
+  out.read(str);
+  std::vector code(str.begin(), str.end());
+  code.push_back('\0');
+  it = address_to_line_.emplace(item.data, std::move(code)).first;
+} else {
+  it = AddAddressAsHexNumber(item);
+}
+  } else {
+it = AddAddressAsHexNumber(item);
+  }
+
+  return it;
+}
+
 void LTTNGClient::WriteRecordItem(PerCPUContext* pcpu, const ClientItem& item) 
{
-  pcpu->size_in_bits += kEventRecordItemBits;
+  if (IsCodeEvent(item.event)) {
+EventHeaderCompact header;
+header.id = COMPACT_HEADER_ID;
+header.event_id = item.event;
+header.ns = item.ns;
+
+auto it = address_to_line_.find(item.data);
+if (it == address_to_line_.end()) {
+  it = ResolveAddress(item);
+}
+
+pcpu->size_in_bits += (sizeof(header) + it->second.size()) * BITS_PER_CHAR;
 
-  EventRecordItem& ri = pcpu->record_item;
-  ri.header.ns = item.ns;
-  ri.header.event_id = item.event;
-  ri.data = item.data;
+std::fwrite(, sizeof(header), 1, pcpu->event_stream);
+std::fwrite(&(*it->second.begin()), it->second.size(), 1,
+pcpu->event_stream);
+  } else {
+pcpu->size_in_bits += kEventRecordItemBits;
+
+EventRecordItem& ri = pcpu->record_item;
+

Re: rtems-addr2line not working on ARM?

2019-09-06 Thread Sebastian Huber

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().

I know you don't like to use boost, but it has also a process support 
library:


https://www.boost.org/doc/libs/1_71_0/doc/html/process.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

rtems-addr2line not working on ARM?

2019-09-06 Thread Sebastian Huber

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. The mapping to 
the function (-f option) get both tools right.


I don't understand the logic here:

bool
file::get_source (const unsigned int addr,
  std::string&   source_file,
  int&   source_line)
{
[...]
  address match;

  for (auto& cu : cus)
  {
address line;
r = cu.get_source (addr, line);
if (r)
{

<-- Why is there a "match = line" in both cases?

  if (match.valid () &&
  (match.is_an_end_sequence () || !!line.is_an_end_sequence 
()))

  {
match = line;
  }
  else
  {
match = line;
  }
    }
  }
--
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: [rtems commit] Add a parallel bootstrap command.

2019-09-05 Thread Sebastian Huber
Hello Joel,

I may have time to work on a new build system later this year. So, I would not 
put too much work into the existing solutions.

- Am 5. Sep 2019 um 14:51 schrieb joel j...@rtems.org:

> Hi
> 
> Any chance, the parallel version will ever functionally replace bootstrap?
> It needs -c to clean and -H for headers.am.
> 
> If we want to support exactly the same arguments (I don't care beyond
> functionality).
> 
> usage: bootstrap [-c|-h|-H] [-q][-v]
> 
> options:
>-c .. clean, remove all aclocal/autoconf/automake generated files
>-h .. display this message and exit
>-H .. regenerate headers.am files
>-q .. quiet, don't display directories
>-v .. verbose, pass -v to autotools
> 
> It would be nice to reduce the bootstrap programs.
[...]
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH] record: Add support for interrupt handlers

2019-09-05 Thread Sebastian Huber



- Am 5. Sep 2019 um 7:29 schrieb Chris Johns chr...@rtems.org:

> On 5/9/19 2:42 pm, Sebastian Huber wrote:
>> - Am 5. Sep 2019 um 0:28 schrieb Chris Johns chr...@rtems.org:
>> 
>>> On 4/9/19 9:46 pm, Sebastian Huber wrote:
[...]
>>> Also it should be `std::fwrite`.
>> 
>> Ok, it seems  was included via . I will fix this.
>> 
> 
> I think we can take C++ development styles offline and chat personally, maybe 
> in
> person soon. :)

How far do you want to go with this std:: stuff, e.g. what about std::size_t? 
Maybe we should just place a "using namespace std;" in *.cc files (this would 
violate also a Google rule).
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: Wrap Interrupt Handlers for Recording?

2019-09-04 Thread Sebastian Huber
- Am 5. Sep 2019 um 7:25 schrieb Chris Johns chr...@rtems.org:

> On 5/9/19 2:25 pm, Sebastian Huber wrote:
>> - Am 4. Sep 2019 um 23:41 schrieb Chris Johns chr...@rtems.org:
>> 
>>> On 5/9/19 2:09 am, Sebastian Huber wrote:
>>>> Hello,
>>>>
>>>> I would like to wrap calls to interrupt handlers which use the generic 
>>>> interrupt
>>>> framework () to get RTEMS_RECORD_INTERRUPT_ENTRY and
>>>> RTEMS_RECORD_INTERRUPT_EXIT events. This cannot be done by the linker 
>>>> since the
>>>> loop to call the handlers is inlined due to performance reasons. I would 
>>>> like
>>>> to add some sort of a callback mechanism which is invoked in
>>>> rtems_interrupt_handler_install() and rtems_interrupt_handler_remove()
>>>> operations (similar to the user extensions). There are some options to do 
>>>> this.
>>>>
>>>> 1. A new linker set with functions.
>>>>
>>>> 2. A new user extension, maybe a generic:
>>>>
>>>>   void (*event)(rtems_extension_event event, void *arg);
>>>>
>>>> 3. An API to install/remove a specific callback for this purpose.
>>>>
>>>
>>> 4. Update or add a new API call to return the currently installed
>>>handler. This way interrupts can be chained.
>> 
>> This API already exists:
>> 
>> https://docs.rtems.org/doxygen/branches/master/group__rtems__interrupt__extension.html#ga31d23275b676018c06e13c7bedc87983
>> 
>> The problem with this approach is that it doesn't wrap new handlers and if 
>> you
>> remove a wrapped handler, then a memory leak or worse may happen.
> 
> Yes care needs to be taken with this approach.
> 
>> 
>>>
>>>> I am in favour of 1. I also would like to hide it from the user for now.
>>>
>>> Does 1. allow runtime installing and then tracing of an interrupt? I know 3.
>>> would.
>> 
>> Yes, 1., 2., and 3. do the same, the difference is how you install the 
>> wrapper
>> functionality and maybe how many you can install.
> 
> It is difficult because you may want to trace one of a number of interrupt
> sources or you may want to trigger tracing of another event due to system
> issues.

For this complex scenario the proposed approach is not the right tool. To trace 
individual interrupts, you can wrap the specific interrupt handler and do your 
complex stuff.

> 
>> 
>> 5. Use a weak function.
>> 
> 
> Would this mean the overhead of the weak function happens all the time?

I mean weak functions which are called during interrupt handler install/remove. 
The interrupt dispatching should remain as is with absolutely no overhead if 
recording is disabled.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: MrsP Testbed

2019-09-04 Thread Sebastian Huber
Hello Ricardo,

- Am 4. Sep 2019 um 15:52 schrieb Ricardo Gomes (1161078) 
1161...@isep.ipp.pt:

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

> 
> 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.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

  1   2   3   4   5   6   7   8   9   10   >