[PATCH] 5: Use a specific RTEMS tools version

[Sebastian Huber]

Download via HTTPS RTEMS file server.

Close 3241.
---
 rtems/config/tools/rtems-tools-5-1.cfg | 28 ++--
 1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/rtems/config/tools/rtems-tools-5-1.cfg 
b/rtems/config/tools/rtems-tools-5-1.cfg
index 6efc4e3..e0178f0 100644
--- a/rtems/config/tools/rtems-tools-5-1.cfg
+++ b/rtems/config/tools/rtems-tools-5-1.cfg
@@ -7,9 +7,33 @@
 #
 %if %{rsb_released}
  %define rtems_tools_version %{rsb_version}
+%else
+ %define rtems_tools_version ec419a05ee52869a7d5b8712ea8e7a7d74fde096
 %endif
 
 #
-# The RTEMS Tools build instructions. We use tools 1.
+# Optionally enable/disable building the RTEMS Tools via the command line.
 #
-%include tools/rtems-tools-1.cfg
+%if %{defined with_rtems_tools}
+ %define rtems_tools_build 1
+%endif
+%if %{defined without_rtems_tools}
+ %define rtems_tools_build 0
+%endif
+
+#
+# Build by default.
+#
+%if ! %{defined rtems_tools_build}
+ %define rtems_tools_build 1
+%endif
+
+%if %{rtems_tools_build}
+ %source set rtems-tools 
https://ftp.rtems.org/pub/rtems/people/sebh/rtems-tools-%{rtems_tools_version}.tar.bz2
+ %hash sha512 rtems-tools-%{rtems_tools_version}.tar.bz2 
af1cda88144583bd9471056291d0a19e8ace0e45efded01e7d32014919a8e57e8a47a58497b2c9201dff925316a8b9cfd0d0e6000f4755471fdf5468b5daa517
+
+ #
+ # The RTEMS Tools build instructions.
+ #
+ %include tools/rtems-tools-common-1.cfg
+%endif
-- 
2.12.3

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

Re: [PATCH] 5: Use a specific RTEMS tools version

[Chris Johns]

On 17/04/2018 18:21, Sebastian Huber wrote:
> Download via HTTPS RTEMS file server.
> 
> Close 3241.

Can you please explain why this solves the issue in the ticket? I do not see how
they relate.

There can be issues with a sequence of git commands if you are switching
branches. This can be resolved by improving the sequence used.

> ---
>  rtems/config/tools/rtems-tools-5-1.cfg | 28 ++--
>  1 file changed, 26 insertions(+), 2 deletions(-)
> 
> diff --git a/rtems/config/tools/rtems-tools-5-1.cfg 
> b/rtems/config/tools/rtems-tools-5-1.cfg
> index 6efc4e3..e0178f0 100644
> --- a/rtems/config/tools/rtems-tools-5-1.cfg
> +++ b/rtems/config/tools/rtems-tools-5-1.cfg
> @@ -7,9 +7,33 @@
>  #
>  %if %{rsb_released}
>   %define rtems_tools_version %{rsb_version}
> +%else
> + %define rtems_tools_version ec419a05ee52869a7d5b8712ea8e7a7d74fde096
>  %endif

Sorry, this is not the right place for this sort of detail. Version details need
to be in the release defaults or overridden in a an arch specific file.

Why this version?

I do not follow or understand the purpose of the change and with a lack of
specific detail it appears to solve a local problem. It may appear to solve the
problem because it side steps an issue related to switching branches.

>  #
> -# The RTEMS Tools build instructions. We use tools 1.
> +# Optionally enable/disable building the RTEMS Tools via the command line.

Why?

I do not understand the use case?

Chris

>  #
> -%include tools/rtems-tools-1.cfg
> +%if %{defined with_rtems_tools}
> + %define rtems_tools_build 1
> +%endif
> +%if %{defined without_rtems_tools}
> + %define rtems_tools_build 0
> +%endif
> +
> +#
> +# Build by default.
> +#
> +%if ! %{defined rtems_tools_build}
> + %define rtems_tools_build 1
> +%endif
> +
> +%if %{rtems_tools_build}
> + %source set rtems-tools 
> https://ftp.rtems.org/pub/rtems/people/sebh/rtems-tools-%{rtems_tools_version}.tar.bz2
> + %hash sha512 rtems-tools-%{rtems_tools_version}.tar.bz2 
> af1cda88144583bd9471056291d0a19e8ace0e45efded01e7d32014919a8e57e8a47a58497b2c9201dff925316a8b9cfd0d0e6000f4755471fdf5468b5daa517
> +
> + #
> + # The RTEMS Tools build instructions.
> + #
> + %include tools/rtems-tools-common-1.cfg
> +%endif
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: multiple definition of __getreent (in newlib's crt0.c and RTEMS' confdefs.h)

[Amaan Cheval]

Great tips, thank you for the help!
Updating the bsp_specs to replace startfile with crtbegin.o did let me get
past the the __getreent problems. It seems like I'll need to learn much
more about linker scripts and the GCC spec syntax than I currently know to
do this right - I've currently only worked around issues in those regards
with guesses / copying blindly from other archs and testing.

I'll read the scripts used for other architectures and the following
resources in the meantime to better understand how this ought to be
structured to be correct. Let me know if you have any other resources you'd
recommend!

- https://dev.gentoo.org/~vapier/crt.txt
- https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html
- https://docs.rtems.org/branches/master/bsp-howto/linker_script.html
-
https://docs.rtems.org/branches/master/bsp-howto/miscellanous_support.html#gcc-compiler-specifications-file
-
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Using_ld_the_GNU_Linker/simple-example.html
On Tue, Apr 17, 2018 at 12:13 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,

> you found a nasty piece in the RTEMS Newlib/GCC configuration. Newlib
> provides a crt0.o file which contains a bunch of global symbols suitable
> enough to make the GCC link-time configure tests happy. This file must
> never be used for a real RTEMS application. The default startfile of GCC
> (which is this Newlib ctr0.o) must be overruled.  This is usually done
> be the bsp_specs.  See also

> https://lists.rtems.org/pipermail/devel/2017-December/019780.html

> --
> Sebastian Huber, embedded brains GmbH

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

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

Re: [PATCH] 5: Use a specific RTEMS tools version

[Sebastian Huber]

On 17/04/18 10:30, Chris Johns wrote:

On 17/04/2018 18:21, Sebastian Huber wrote:

Download via HTTPS RTEMS file server.

Close 3241.

Can you please explain why this solves the issue in the ticket? I do not see how
they relate.


This solves the ticket since git is no longer involved.



There can be issues with a sequence of git commands if you are switching
branches. This can be resolved by improving the sequence used.


---
  rtems/config/tools/rtems-tools-5-1.cfg | 28 ++--
  1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/rtems/config/tools/rtems-tools-5-1.cfg 
b/rtems/config/tools/rtems-tools-5-1.cfg
index 6efc4e3..e0178f0 100644
--- a/rtems/config/tools/rtems-tools-5-1.cfg
+++ b/rtems/config/tools/rtems-tools-5-1.cfg
@@ -7,9 +7,33 @@
  #
  %if %{rsb_released}
   %define rtems_tools_version %{rsb_version}
+%else
+ %define rtems_tools_version ec419a05ee52869a7d5b8712ea8e7a7d74fde096
  %endif

Sorry, this is not the right place for this sort of detail. Version details need
to be in the release defaults or overridden in a an arch specific file.


Sorry, I didn't understand the logic for the rtems_tools_version 
definition at all. Why is it dependent on rsb_released?




Why this version?


It is the latest commit. So, just the thing that would have been picked 
by the current RSB.


The use of a random HEAD is a major problem from my point of view. It 
makes the RSB outcome build time dependent and irreproducible.




I do not follow or understand the purpose of the change and with a lack of
specific detail it appears to solve a local problem. It may appear to solve the
problem because it side steps an issue related to switching branches.


There are some reports on the mailing list related to the rtems-tools 
download via git. It has at least two problems:


1. It fails sporadically.

2. You need internet access during the build.




  #
-# The RTEMS Tools build instructions. We use tools 1.
+# Optionally enable/disable building the RTEMS Tools via the command line.

Why?

I do not understand the use case?


This is just a copy and paste from:

%include tools/rtems-tools-1.cfg

--
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: multiple definition of __getreent (in newlib's crt0.c and RTEMS' confdefs.h)

[Sebastian Huber]

On 17/04/18 10:35, Amaan Cheval wrote:

- https://docs.rtems.org/branches/master/bsp-howto/linker_script.html


You have to be careful with the BSP guilde. It is a bit out of date. For 
a reference linker command file I would use this:


https://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/shared/startup/linkcmds.base

Use this to get the default linker command file:

x86_64-rtems5-ld --verbose

--
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] 5: Use a specific RTEMS tools version

[Sebastian Huber]

On 17/04/18 10:21, Sebastian Huber wrote:

Download via HTTPS RTEMS file server.

Close 3241.
---
  rtems/config/tools/rtems-tools-5-1.cfg | 28 ++--
  1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/rtems/config/tools/rtems-tools-5-1.cfg 
b/rtems/config/tools/rtems-tools-5-1.cfg
index 6efc4e3..e0178f0 100644
[...]
+%if %{rtems_tools_build}
+ %source set rtems-tools 
https://ftp.rtems.org/pub/rtems/people/sebh/rtems-tools-%{rtems_tools_version}.tar.bz2
[...]


The download location is currently my FTP server area. This is not 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] cpu-supplement: Add ARM BSPs chapter

[Sebastian Huber]

On 26/03/18 10:09, Sebastian Huber wrote:

On 26/03/18 00:50, Chris Johns wrote:

On 14/03/2018 17:20, Sebastian Huber wrote:

On 13/03/18 22:58, Chris Johns wrote:

On 09/03/2018 19:55, Sebastian Huber wrote:

On 06/11/17 10:03, Sebastian Huber wrote:

On 26/10/17 08:22, Sebastian Huber wrote:
Please review this patch carefully. It adds a new chapter "ARM 
Board Support
Packages" following the "ARM Specific Information" chapter. It 
adds a

template structure for other BSPs.

Where should we place common BSP configuration options like
BSP_PRESS_KEY_FOR_RESET? We probably don't want to add a copy 
and paste

version to every BSP section.

Any comments with respect to the BSP documentation? It makes 
little sense to

start with this work if the general direction is unclear.

The insufficient and user unfriendly BSP documentation is still a 
big issue from
my point of view. I think it is one of be biggest obstacles to get 
started with
RTEMS. The BSP documentation should be part of a sphinx based 
rtems-docs manual.


How do we get the large number of BSP_OPTS parameters out of the 
BSPs and into
suitable documentation? I am reluctant to support fragmented or 
partial
approaches to solving this problem, I feel the "project" or effect 
needs to
accept _all_ BSPs need to be covered. This is a community effort 
that needs some

leadership and ownership.

It is a difficult area because:

1. The overlap to device TRMs and yet wanting to provide some self 
contained

information for a device knowledgeable user.

2. How is it maintained and checked? Reviews of patches require 
related doc

patches?

3. Changing the build system, the waf build Amar created changes 
the way
BSP_OPTS are handled requiring clear definition with ranges and 
other factors
and that could be annotated with suitable documentation allowing 
automatic
generation. Do we push for funding for this effort and deal with it 
then?
For BSP documentation you need to know the hardware and the BSP in 
detail. I
think we can only do this step by step and should focus on the BSPs 
that are

still in use and maintained. We need a clear concept of the desired BSP
documentation, so that it is easy for new contributors to fix the 
documentation
of their BSP of interest. A build configuration command line help 
for BSP
options would be nice, but I think this is optional. I would remove 
the BSP
options documentation in configure.ac for BSPs which document the 
options in a
manual. If we want to provide build configuration command line help, 
then we
should generate it from some documentation master and use it for the 
command
line help and the manual. This is some extra effort. It is probably 
in the range

of several man weeks to update the documentation of all BSPs.
Agreed and this will need to change any way. A waf build system would 
bring all
these option out to the top level which is a important. They are 
hidden at the

moment which is painful.

The manual should have one level for the architectures, one level 
for the BSPs
and one for the BSP details. I would not use more than three levels 
in a PDF
document. Do we want to create a dedicated BSP manual or merge it 
into an

existing manual (which one and how)?
Can the BSP and Driver Guide be used or do you think we need 
something new?


The BSP and Driver Guide contains mostly information for a BSP and 
driver developer.


If we use four levels, we could add this to the User Manual (it uses 
already four levels), e.g.


Board Support Packages (BSPs)
    -> Architecture
        -> BSP
            -> Some stuff

See attached file.


Could we please eventually decide on a place for BSP documentation.

--
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] bsp-howto: Update BSP source code structure

[Sebastian Huber]

This patch is a part of the BSP source reorganization.

Update #3285.
---
 bsp-howto/target_dependant_files.rst | 104 +--
 1 file changed, 38 insertions(+), 66 deletions(-)

diff --git a/bsp-howto/target_dependant_files.rst 
b/bsp-howto/target_dependant_files.rst
index fdfe5d2..bbd13ae 100644
--- a/bsp-howto/target_dependant_files.rst
+++ b/bsp-howto/target_dependant_files.rst
@@ -165,69 +165,41 @@ appropriate subdirectories for the specific CPU model 
your BSP has.
 Board Support Package Structure
 ===
 
-The BSPs are all under the ``c/src/lib/libbsp`` directory.  Below this
-directory, there is a subdirectory for each CPU family.  Each BSP is found
-under the subdirectory for the appropriate processor family (arm, powerpc,
-sparc, etc.).  In addition, there is source code available which may be shared
-across all BSPs regardless of the CPU family or just across BSPs within a
-single CPU family.  This results in a BSP using the following directories:
-
-.. code-block:: c
-
-c/src/lib/libbsp/shared
-c/src/lib/libbsp//shared
-c/src/lib/libbsp//
-
-Under each BSP specific directory, there is a collection of subdirectories.
-For commonly provided functionality, the BSPs follow a convention on
-subdirectory naming.  The following list describes the commonly found
-subdirectories under each BSP.
-
-- ``console``:
-  is technically the serial driver for the BSP rather than just a console
-  driver, it deals with the board UARTs (i.e. serial devices).
-
-- ``clock``:
-  support for the clock tick - a regular time basis to the kernel.
-
-- ``timer``:
-  support of timer devices.
-
-- ``rtc`` or ``tod``:
-  support for the hardware real-time clock.
-
-- ``nvmem``:
-  support for non-volatile memory such as EEPROM or Flash.
-
-- ``network``:
-  the Ethernet driver.
-
-- ``shmsupp``:
-  support of shared memory driver MPCI layer in a multiprocessor system,
-
-- ``include``:
-  include files for this BSP.
-
-- ``gnatsupp``:
-  BSP specific support for the GNU Ada run-time.  Each BSP that wishes to have
-  the possibility to map faults or exceptions into Ada language exceptions or
-  hardware interrupts into Ada interrupt tasks must provide this support.
-
-There may be other directories in the BSP tree and the name should be
-indicative of the functionality of the code within that directory.
-
-The build order of the BSP is determined by the Makefile structure.  This
-structure is discussed in more detail in the :ref:`Makefiles` chapter.
-
-.. sidebar:
-
-This manual refers to the gen68340 BSP for numerous concrete examples.  You
-should have a copy of the gen68340 BSP available while reading this piece of
-documentation.  This BSP is located in the following directory:
-
-.. code-block:: c
-
-c/src/lib/libbsp/m68k/gen68340
-
-Later in this document, the $BSP340_ROOT label will be used to refer to this
-directory.
+The BSPs are all under the `bsps `_
+directory.  The structure in the source subtree is:
+
+* :file:`bsps/shared`
+* :file:`bsps/@RTEMS_CPU@/shared`
+* :file:`bsps/@RTEMS_CPU@/@RTEMS_BSP_FAMILY@`
+
+The ``@RTEMS_CPU@`` is a particular architecture, e.g. arm,
+powerpc, sparc, etc.  The ``@RTEMS_BSP_FAMILY@`` directories
+contain BSPs for a particular system on chip (SoC) or processor family.
+
+Use the following structure under the 
:file:`bsps/@RTEMS_CPU@/@RTEMS_BSP_FAMILY@`:
+
+* :file:`ata` - the legacy ATA/IDE driver.
+* :file:`cache` - cache controller support.
+* :file:`clock` - the clock driver.
+* :file:`config` - build system configuration files.
+* :file:`console` - the console driver.
+* :file:`contrib` - imports of external sources.
+
+  * The layout of external sources should be used as is if possible.
+
+* :file:`i2c` - the I2C driver.
+* :file:`include` - public header files.
+* :file:`irq` - the interrupt controller support.
+* :file:`mpci` - support for heterogeneous multiprocessing
+  (``RTEMS_MULTIPROCESSING``).
+* :file:`net` - legacy network stack drivers.
+* :file:`rtc` - the RTC driver.
+* :file:`spi` - the SPI driver.
+* :file:`start` - everything required to run a minimal application without
+  devices.
+
+  * :file:`start.S` - lowest level startup code.
+  * :file:`bspstart.c` - low level startup code.
+  * :file:`bspsmp.c` - SMP support.
+  * :file:`linkcmds` - the linker command file.
+* :file:`btimer` - the benchmark timer driver.
-- 
2.12.3

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

Re: [PATCH] 5: Use a specific RTEMS tools version

[Chris Johns]

On 17/4/18 6:49 pm, Sebastian Huber wrote:
> On 17/04/18 10:30, Chris Johns wrote:
>> On 17/04/2018 18:21, Sebastian Huber wrote:
>>> Download via HTTPS RTEMS file server.
>>>
>>> Close 3241.
>> Can you please explain why this solves the issue in the ticket? I do not see 
>> how
>> they relate.
> 
> This solves the ticket since git is no longer involved.
> 
>>
>> There can be issues with a sequence of git commands if you are switching
>> branches. This can be resolved by improving the sequence used.
>>
>>> ---
>>>   rtems/config/tools/rtems-tools-5-1.cfg | 28 ++--
>>>   1 file changed, 26 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/rtems/config/tools/rtems-tools-5-1.cfg
>>> b/rtems/config/tools/rtems-tools-5-1.cfg
>>> index 6efc4e3..e0178f0 100644
>>> --- a/rtems/config/tools/rtems-tools-5-1.cfg
>>> +++ b/rtems/config/tools/rtems-tools-5-1.cfg
>>> @@ -7,9 +7,33 @@
>>>   #
>>>   %if %{rsb_released}
>>>    %define rtems_tools_version %{rsb_version}
>>> +%else
>>> + %define rtems_tools_version ec419a05ee52869a7d5b8712ea8e7a7d74fde096
>>>   %endif
>> Sorry, this is not the right place for this sort of detail. Version details 
>> need
>> to be in the release defaults or overridden in a an arch specific file.
> 
> Sorry, I didn't understand the logic for the rtems_tools_version definition at
> all. Why is it dependent on rsb_released?

If the RSB is released the RTEMS ftp server is used for downloads and the
version is the RTEMS release verson. The RTEMS tools do not have a separate
release cycle from RTEMS and use the same version numbers.

>>
>> Why this version?
> 
> It is the latest commit. So, just the thing that would have been picked by the
> current RSB.
> 
> The use of a random HEAD is a major problem from my point of view. It makes 
> the
> RSB outcome build time dependent and irreproducible.

Releases are matched. I do not follow how this resolves any dependence issue
that may appear such as the dl06 and rtems-ld.

>> I do not follow or understand the purpose of the change and with a lack of
>> specific detail it appears to solve a local problem. It may appear to solve 
>> the
>> problem because it side steps an issue related to switching branches.
> 
> There are some reports on the mailing list related to the rtems-tools download
> via git. It has at least two problems:
> 
> 1. It fails sporadically.

The real issue in the way git is being sequenced should be fix.

> 2. You need internet access during the build.

If you updated RTEMS and have disconnected and not updated the RSB with a new
hash version downloaded from your home ftp area you have stuffed anyway.

>>
>>>   #
>>> -# The RTEMS Tools build instructions. We use tools 1.
>>> +# Optionally enable/disable building the RTEMS Tools via the command line.
>> Why?
>>
>> I do not understand the use case?
> 
> This is just a copy and paste from:
> 
> %include tools/rtems-tools-1.cfg
> 

Ah ok, thanks.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] 5: Use a specific RTEMS tools version

[Chris Johns]

On 17/4/18 7:03 pm, Sebastian Huber wrote:
> On 17/04/18 10:21, Sebastian Huber wrote:
>> Download via HTTPS RTEMS file server.
>>
>> Close 3241.
>> ---
>>   rtems/config/tools/rtems-tools-5-1.cfg | 28 ++--
>>   1 file changed, 26 insertions(+), 2 deletions(-)
>>
>> diff --git a/rtems/config/tools/rtems-tools-5-1.cfg
>> b/rtems/config/tools/rtems-tools-5-1.cfg
>> index 6efc4e3..e0178f0 100644
>> [...]
>> +%if %{rtems_tools_build}
>> + %source set rtems-tools
>> https://ftp.rtems.org/pub/rtems/people/sebh/rtems-tools-%{rtems_tools_version}.tar.bz2
>>
>> [...]
> 
> The download location is currently my FTP server area. This is not great.
> 

Thanks, I had missed this. I would prefer the issue with git be fixed than head
down this path.

Also I do not want to hack around on dispatch.rtems.org to update this file.

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

Re: [PATCH] 5: Use a specific RTEMS tools version

[Chris Johns]

On 17/4/18 8:14 pm, Chris Johns wrote:
> 
> Also I do not want to hack around on dispatch.rtems.org to update this file.
> 

This link seems to work ...

https://git.rtems.org/rtems-tools/snapshot/rtems-tools-ec419a05ee52869a7d5b8712ea8e7a7d74fde096.tar.bz2

Must be a feature of cgit.

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

Re: [PATCH] cpu-supplement: Add ARM BSPs chapter

[Chris Johns]

On 26/3/18 7:09 pm, Sebastian Huber wrote:
> On 26/03/18 00:50, Chris Johns wrote:
>> On 14/03/2018 17:20, Sebastian Huber wrote:
>>> On 13/03/18 22:58, Chris Johns wrote:
 On 09/03/2018 19:55, Sebastian Huber wrote:
> On 06/11/17 10:03, Sebastian Huber wrote:
>> On 26/10/17 08:22, Sebastian Huber wrote:
>>> Please review this patch carefully. It adds a new chapter "ARM Board 
>>> Support
>>> Packages" following the "ARM Specific Information" chapter. It adds a
>>> template structure for other BSPs.
>>>
>>> Where should we place common BSP configuration options like
>>> BSP_PRESS_KEY_FOR_RESET? We probably don't want to add a copy and paste
>>> version to every BSP section.
>>>
>> Any comments with respect to the BSP documentation? It makes little 
>> sense to
>> start with this work if the general direction is unclear.
>>
> The insufficient and user unfriendly BSP documentation is still a big 
> issue
> from
> my point of view. I think it is one of be biggest obstacles to get started
> with
> RTEMS. The BSP documentation should be part of a sphinx based rtems-docs
> manual.
>
 How do we get the large number of BSP_OPTS parameters out of the BSPs and 
 into
 suitable documentation? I am reluctant to support fragmented or partial
 approaches to solving this problem, I feel the "project" or effect needs to
 accept _all_ BSPs need to be covered. This is a community effort that needs
 some
 leadership and ownership.

 It is a difficult area because:

 1. The overlap to device TRMs and yet wanting to provide some self 
 contained
 information for a device knowledgeable user.

 2. How is it maintained and checked? Reviews of patches require related doc
 patches?

 3. Changing the build system, the waf build Amar created changes the way
 BSP_OPTS are handled requiring clear definition with ranges and other 
 factors
 and that could be annotated with suitable documentation allowing automatic
 generation. Do we push for funding for this effort and deal with it then?
>>> For BSP documentation you need to know the hardware and the BSP in detail. I
>>> think we can only do this step by step and should focus on the BSPs that are
>>> still in use and maintained. We need a clear concept of the desired BSP
>>> documentation, so that it is easy for new contributors to fix the 
>>> documentation
>>> of their BSP of interest. A build configuration command line help for BSP
>>> options would be nice, but I think this is optional. I would remove the BSP
>>> options documentation in configure.ac for BSPs which document the options 
>>> in a
>>> manual. If we want to provide build configuration command line help, then we
>>> should generate it from some documentation master and use it for the command
>>> line help and the manual. This is some extra effort. It is probably in the 
>>> range
>>> of several man weeks to update the documentation of all BSPs.
>> Agreed and this will need to change any way. A waf build system would bring 
>> all
>> these option out to the top level which is a important. They are hidden at 
>> the
>> moment which is painful.
>>
>>> The manual should have one level for the architectures, one level for the 
>>> BSPs
>>> and one for the BSP details. I would not use more than three levels in a PDF
>>> document. Do we want to create a dedicated BSP manual or merge it into an
>>> existing manual (which one and how)?
>> Can the BSP and Driver Guide be used or do you think we need something new?
> 
> The BSP and Driver Guide contains mostly information for a BSP and driver
> developer.
> 
> If we use four levels, we could add this to the User Manual (it uses already
> four levels), e.g.
> 
> Board Support Packages (BSPs)
>     -> Architecture
>         -> BSP
>             -> Some stuff
> 
> See attached file.
> 

The PDF file looks good. I am OK with this but I would like Joel to respond.

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

Re: [PATCH] 5: Use a specific RTEMS tools version

[Sebastian Huber]

On 17/04/18 12:12, Chris Johns wrote:

On 17/4/18 6:49 pm, Sebastian Huber wrote:

On 17/04/18 10:30, Chris Johns wrote:

On 17/04/2018 18:21, Sebastian Huber wrote:

Download via HTTPS RTEMS file server.

Close 3241.

Can you please explain why this solves the issue in the ticket? I do not see how
they relate.

This solves the ticket since git is no longer involved.


There can be issues with a sequence of git commands if you are switching
branches. This can be resolved by improving the sequence used.


---
   rtems/config/tools/rtems-tools-5-1.cfg | 28 ++--
   1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/rtems/config/tools/rtems-tools-5-1.cfg
b/rtems/config/tools/rtems-tools-5-1.cfg
index 6efc4e3..e0178f0 100644
--- a/rtems/config/tools/rtems-tools-5-1.cfg
+++ b/rtems/config/tools/rtems-tools-5-1.cfg
@@ -7,9 +7,33 @@
   #
   %if %{rsb_released}
    %define rtems_tools_version %{rsb_version}
+%else
+ %define rtems_tools_version ec419a05ee52869a7d5b8712ea8e7a7d74fde096
   %endif

Sorry, this is not the right place for this sort of detail. Version details need
to be in the release defaults or overridden in a an arch specific file.

Sorry, I didn't understand the logic for the rtems_tools_version definition at
all. Why is it dependent on rsb_released?

If the RSB is released the RTEMS ftp server is used for downloads and the
version is the RTEMS release verson. The RTEMS tools do not have a separate
release cycle from RTEMS and use the same version numbers.


Why this version?

It is the latest commit. So, just the thing that would have been picked by the
current RSB.

The use of a random HEAD is a major problem from my point of view. It makes the
RSB outcome build time dependent and irreproducible.

Releases are matched. I do not follow how this resolves any dependence issue
that may appear such as the dl06 and rtems-ld.


For the latest test suite you need an up to date rtems-ld. If you built 
the tools with RSB 703532cb04c6990fb21e97cb7347a16e9df11108 two months 
ago, then it will not work. If you build with RSB 
703532cb04c6990fb21e97cb7347a16e9df11108 today, then everything is fine. 
This is a serious defect from my point of view.





I do not follow or understand the purpose of the change and with a lack of
specific detail it appears to solve a local problem. It may appear to solve the
problem because it side steps an issue related to switching branches.

There are some reports on the mailing list related to the rtems-tools download
via git. It has at least two problems:

1. It fails sporadically.

The real issue in the way git is being sequenced should be fix.


2. You need internet access during the build.

If you updated RTEMS and have disconnected and not updated the RSB with a new
hash version downloaded from your home ftp area you have stuffed anyway.



You should be able to

../source-builder/sb-set-builder --dry-run --with-download ...

and then disconnect from the internet to build the tools.

--
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] 5: Use a specific RTEMS tools version

[Sebastian Huber]

On 17/04/18 12:26, Chris Johns wrote:

On 17/4/18 8:14 pm, Chris Johns wrote:

Also I do not want to hack around on dispatch.rtems.org to update this file.


This link seems to work ...

https://git.rtems.org/rtems-tools/snapshot/rtems-tools-ec419a05ee52869a7d5b8712ea8e7a7d74fde096.tar.bz2

Must be a feature of cgit.


I think we should reduce the dependencies for source downloads in the 
RSB and maybe download everything from an RTEMS file server. Will we 
still use cgit or trac or whatever in 5 years in 10 years? A simple 
download location for all files is easer to adjust if we move 
infrastructure.


--
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: multiple definition of __getreent (in newlib's crt0.c and RTEMS' confdefs.h)

[Joel Sherrill]

On Tue, Apr 17, 2018 at 3:35 AM, Amaan Cheval 
wrote:

> Great tips, thank you for the help!
> Updating the bsp_specs to replace startfile with crtbegin.o did let me get
> past the the __getreent problems. It seems like I'll need to learn much
> more about linker scripts and the GCC spec syntax than I currently know to
> do this right - I've currently only worked around issues in those regards
> with guesses / copying blindly from other archs and testing.
>


startfile needs to be the equivalent of crt0. In RTEMS parlance, this is
usually
start.o and it does thing like setup the stack, required registers, etc.


>
> I'll read the scripts used for other architectures and the following
> resources in the meantime to better understand how this ought to be
> structured to be correct. Let me know if you have any other resources you'd
> recommend!
>
> - https://dev.gentoo.org/~vapier/crt.txt
> - https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html
> - https://docs.rtems.org/branches/master/bsp-howto/linker_script.html
> -
> https://docs.rtems.org/branches/master/bsp-howto/
> miscellanous_support.html#gcc-compiler-specifications-file
> -
> https://access.redhat.com/documentation/en-US/Red_Hat_
> Enterprise_Linux/4/html/Using_ld_the_GNU_Linker/simple-example.html
> On Tue, Apr 17, 2018 at 12:13 PM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
> > Hello,
>
> > you found a nasty piece in the RTEMS Newlib/GCC configuration. Newlib
> > provides a crt0.o file which contains a bunch of global symbols suitable
> > enough to make the GCC link-time configure tests happy. This file must
> > never be used for a real RTEMS application. The default startfile of GCC
> > (which is this Newlib ctr0.o) must be overruled.  This is usually done
> > be the bsp_specs.  See also
>
> > https://lists.rtems.org/pipermail/devel/2017-December/019780.html
>
> > --
> > Sebastian Huber, embedded brains GmbH
>
> > Address : Dornierstr. 4, D-82178 Puchheim, Germany
> > Phone   : +49 89 189 47 41-16
> > Fax : +49 89 189 47 41-09
> > E-Mail  : sebastian.hu...@embedded-brains.de
> > PGP : Public key available on request.
>
> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: the generated coverage report doesn't contain any data

[Vijay Kumar Banerjee]

The report is showing some data !!

I merged a lot of changes form coverage-merge , it's showing some data now
, but I'm still getting a set of errors. I'll paste them below.

I have attached a screenshot of the report.html

errors :

INFO: DesiredSymbols::createCoverageMap - Attempt to create unified
coverage maps for _Workspace_Allocate_or_fatal_error with different sizes
(/home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/capture/capture.exe/84
!=
/home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/base_sp/base_sp.exe/60)

INFO: DesiredSymbols::mergeCoverageMap - Unable to merge coverage map for
_Workspace_Allocate_or_fatal_error because the sizes are different


On 17 April 2018 at 11:59, Cillian O'Donnell  wrote:

> Also if there's any file in covoar directory of coverage-merge branch
> that's called symbol-set.c symbol_set_reader.h or any variation of that,
> that you don't already have pull all of them into your current branch.
>
> On Tue, 17 Apr 2018, 07:19 Cillian O'Donnell, 
> wrote:
>
>> Some things are definitely missing there. Git checkout main.c
>> coverage-merge. If you have that branch lying around, that definitely has
>> everything in it. I must of missed of some things updating to current
>> master. Fingers crossed this solves our problems
>>
>>
>> On Mon, 16 Apr 2018, 22:52 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>>
>>>
>>> On Tue, 17 Apr 2018, 03:19 Joel Sherrill,  wrote:
>>>


 On Mon, Apr 16, 2018 at 4:47 PM, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

>
>
> On 17 April 2018 at 01:43, Cillian O'Donnell 
> wrote:
>
>>
>>
>> On 16 April 2018 at 17:46, Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Mon, Apr 16, 2018 at 2:33 AM, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 current status :
 the coverage is running now with rtems-test and generating the
 report, however, the report doesn't show any data.

>>>
>>> I've been lurking as you have been making progress. Now you have
>>> crossed
>>> into something you probably need some hints at. Some things to check:
>>>
>>> + Obviously, check output for signs that something didn't happen
>>> right.
>>> Anything from a path wrong, etc. The configuration has to be right to
>>> point to the source code, object code, executables, etc.
>>>
>>> + A lot of source code has moved around since last summer. Check
>>> that it is looking in the right places inside RTEMS.
>>>
>>> + Does the mechanism to get debug information actually work? Cillian?
>>>
>>
>> The covoar debug option just disables the cleaning of the tempfiles
>> to take a look, so it's not as powerful as it might seem :)... I always
>> used gdb here so that's probably the way to go.
>>
>>>
>>> + There is a utility named trace-converter. Make sure your qemu
>>> traces
>>> have information in them.
>>>
>>> + Cillian probably has guidance on running it just on one test (say
>>> ticker)
>>> so you can see every step.
>>>
>>> + Check that the executables have symbolic information. "file" should
>>> show if they are stripped or not.
>>>
>>> I recall covoar has a verbose mode which should be of use.
>>>
>>> Cillian .. do you have instructions on running covoar in gdb?
>>>
>>
>> Alright so run rtems-test with --no-clean option to leave the
>> coverage files lying around
>>
>> $HOME/development/rtems/test/test/rtems-tools/tester/rtems-test
>> --rtems-tools=$HOME/development/rtems/5 --log=coverage-analysis.log
>> --rtems-bsp=leon3_qemu --coverage --no-clean 
>> --rtems-builddir=$HOME/development/rtems/leon3
>> sparc-rtems5/c/leon3/testsuites/samples
>>
>> Then run
>>
>> gdb covoar
>>
>> from gdb prompt
>>
>> run -S /home/cpod/coverage_test/leon3/coverage/score.symcfg -O
>> /home/cpod/coverage_test/leon3/test/score -fQEMU -Tsparc-rtems5
>> -E/home/cpod/development/rtems/test/test/vijay/rtems-
>> tools/tester/rtems/testing/coverage/Explanations.txt -c.cov -eexe
>> -pRTEMS-5 /home/cpod/development/rtems/leon3/sparc-rtems5/c/leon3/
>> testsuites/samples/base_sp/base_sp.exe
>>
>> The options there are ( if you're wondering )
>>
>>  -c COVERAGEFILE_EXTENSION EXECUTABLE1 ... EXECUTABLE2
>>
>>  -v  - verbose output
>>  -T TARGET   - architecture target name
>>  -f FORMAT   - simulator format
>> (RTEMS, QEMU, TSIM or Skyeye)
>>  -E EXPLANATIONS - file of explanations
>>  -s SYMBOLS_FILE - symbols of interest
>>  -S SYMBOL_SET_FILE  - path to symbol_sets.cfg
>>  -1 EXECUTABLE   - executable to get symbols from
>>  -e EXE_EXTENSION- suffix for execut

Re: the generated coverage report doesn't contain any data

[Vijay Kumar Banerjee]

On 18 April 2018 at 00:57, Vijay Kumar Banerjee 
wrote:

> The report is showing some data !!
>
> I merged a lot of changes form coverage-merge , it's showing some data now
> , but I'm still getting a set of errors. I'll paste them below.
>
> I have attached a screenshot of the report.html
>
> errors :
> 
> INFO: DesiredSymbols::createCoverageMap - Attempt to create unified
> coverage maps for _Workspace_Allocate_or_fatal_error with different sizes
> (/home/lunatic/development/rtems/kernel/leon3/sparc-
> rtems5/c/leon3/testsuites/samples/capture/capture.exe/84 !=
> /home/lunatic/development/rtems/kernel/leon3/sparc-
> rtems5/c/leon3/testsuites/samples/base_sp/base_sp.exe/60)
>
> INFO: DesiredSymbols::mergeCoverageMap - Unable to merge coverage map for
> _Workspace_Allocate_or_fatal_error because the sizes are different
>
> Am I still possibly missing something ?

>
>
On 17 April 2018 at 11:59, Cillian O'Donnell  wrote:
>
>> Also if there's any file in covoar directory of coverage-merge branch
>> that's called symbol-set.c symbol_set_reader.h or any variation of that,
>> that you don't already have pull all of them into your current branch.
>>
>> On Tue, 17 Apr 2018, 07:19 Cillian O'Donnell, 
>> wrote:
>>
>>> Some things are definitely missing there. Git checkout main.c
>>> coverage-merge. If you have that branch lying around, that definitely has
>>> everything in it. I must of missed of some things updating to current
>>> master. Fingers crossed this solves our problems
>>>
>>>
>>> On Mon, 16 Apr 2018, 22:52 Vijay Kumar Banerjee, <
>>> vijaykumar9...@gmail.com> wrote:
>>>


 On Tue, 17 Apr 2018, 03:19 Joel Sherrill,  wrote:

>
>
> On Mon, Apr 16, 2018 at 4:47 PM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>>
>>
>> On 17 April 2018 at 01:43, Cillian O'Donnell 
>> wrote:
>>
>>>
>>>
>>> On 16 April 2018 at 17:46, Joel Sherrill  wrote:
>>>


 On Mon, Apr 16, 2018 at 2:33 AM, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> current status :
> the coverage is running now with rtems-test and generating the
> report, however, the report doesn't show any data.
>

 I've been lurking as you have been making progress. Now you have
 crossed
 into something you probably need some hints at. Some things to
 check:

 + Obviously, check output for signs that something didn't happen
 right.
 Anything from a path wrong, etc. The configuration has to be right
 to
 point to the source code, object code, executables, etc.

 + A lot of source code has moved around since last summer. Check
 that it is looking in the right places inside RTEMS.

 + Does the mechanism to get debug information actually work?
 Cillian?

>>>
>>> The covoar debug option just disables the cleaning of the tempfiles
>>> to take a look, so it's not as powerful as it might seem :)... I always
>>> used gdb here so that's probably the way to go.
>>>

 + There is a utility named trace-converter. Make sure your qemu
 traces
 have information in them.

 + Cillian probably has guidance on running it just on one test (say
 ticker)
 so you can see every step.

 + Check that the executables have symbolic information. "file"
 should
 show if they are stripped or not.

 I recall covoar has a verbose mode which should be of use.

 Cillian .. do you have instructions on running covoar in gdb?

>>>
>>> Alright so run rtems-test with --no-clean option to leave the
>>> coverage files lying around
>>>
>>> $HOME/development/rtems/test/test/rtems-tools/tester/rtems-test
>>> --rtems-tools=$HOME/development/rtems/5 --log=coverage-analysis.log
>>> --rtems-bsp=leon3_qemu --coverage --no-clean 
>>> --rtems-builddir=$HOME/development/rtems/leon3
>>> sparc-rtems5/c/leon3/testsuites/samples
>>>
>>> Then run
>>>
>>> gdb covoar
>>>
>>> from gdb prompt
>>>
>>> run -S /home/cpod/coverage_test/leon3/coverage/score.symcfg -O
>>> /home/cpod/coverage_test/leon3/test/score -fQEMU -Tsparc-rtems5
>>> -E/home/cpod/development/rtems/test/test/vijay/rtems-tools/
>>> tester/rtems/testing/coverage/Explanations.txt -c.cov -eexe
>>> -pRTEMS-5 /home/cpod/development/rtems/l
>>> eon3/sparc-rtems5/c/leon3/testsuites/samples/base_sp/base_sp.exe
>>>
>>> The options there are ( if you're wondering )
>>>
>>>  -c COVERAGEFILE_EXTENSION EXECUTABLE1 ... EXECUTABLE2
>>>
>>>  -v  - verbose output
>>>  -T TARGET   - architecture target name
>>>  -f FORMAT   - simulator format
>>> (RTEMS, 

Re: the generated coverage report doesn't contain any data

[Cillian O'Donnell]

Could be still missing something, try using the whole covoar directory from
coverage-merge. I spent a good bit of time fixing errors like that, would
be strange if it popped back up again but it could be right. Either way
we're in pretty good shape now. Report looks good, try and run it with the
full testsuite to see what happens, it takes a while, a hour-ish.

On 17 April 2018 at 20:32, Vijay Kumar Banerjee 
wrote:

>
>
>
> On 18 April 2018 at 00:57, Vijay Kumar Banerjee 
> wrote:
>
>> The report is showing some data !!
>>
>> I merged a lot of changes form coverage-merge , it's showing some data
>> now , but I'm still getting a set of errors. I'll paste them below.
>>
>> I have attached a screenshot of the report.html
>>
>> errors :
>> 
>> INFO: DesiredSymbols::createCoverageMap - Attempt to create unified
>> coverage maps for _Workspace_Allocate_or_fatal_error with different
>> sizes (/home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/
>> c/leon3/testsuites/samples/capture/capture.exe/84 !=
>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/
>> leon3/testsuites/samples/base_sp/base_sp.exe/60)
>>
>> INFO: DesiredSymbols::mergeCoverageMap - Unable to merge coverage map
>> for _Workspace_Allocate_or_fatal_error because the sizes are different
>>
>> Am I still possibly missing something ?
>
>>
>>
> On 17 April 2018 at 11:59, Cillian O'Donnell 
>> wrote:
>>
>>> Also if there's any file in covoar directory of coverage-merge branch
>>> that's called symbol-set.c symbol_set_reader.h or any variation of that,
>>> that you don't already have pull all of them into your current branch.
>>>
>>> On Tue, 17 Apr 2018, 07:19 Cillian O'Donnell, 
>>> wrote:
>>>
 Some things are definitely missing there. Git checkout main.c
 coverage-merge. If you have that branch lying around, that definitely has
 everything in it. I must of missed of some things updating to current
 master. Fingers crossed this solves our problems


 On Mon, 16 Apr 2018, 22:52 Vijay Kumar Banerjee, <
 vijaykumar9...@gmail.com> wrote:

>
>
> On Tue, 17 Apr 2018, 03:19 Joel Sherrill,  wrote:
>
>>
>>
>> On Mon, Apr 16, 2018 at 4:47 PM, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>>
>>>
>>> On 17 April 2018 at 01:43, Cillian O'Donnell 
>>> wrote:
>>>


 On 16 April 2018 at 17:46, Joel Sherrill  wrote:

>
>
> On Mon, Apr 16, 2018 at 2:33 AM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> current status :
>> the coverage is running now with rtems-test and generating the
>> report, however, the report doesn't show any data.
>>
>
> I've been lurking as you have been making progress. Now you have
> crossed
> into something you probably need some hints at. Some things to
> check:
>
> + Obviously, check output for signs that something didn't happen
> right.
> Anything from a path wrong, etc. The configuration has to be right
> to
> point to the source code, object code, executables, etc.
>
> + A lot of source code has moved around since last summer. Check
> that it is looking in the right places inside RTEMS.
>
> + Does the mechanism to get debug information actually work?
> Cillian?
>

 The covoar debug option just disables the cleaning of the tempfiles
 to take a look, so it's not as powerful as it might seem :)... I always
 used gdb here so that's probably the way to go.

>
> + There is a utility named trace-converter. Make sure your qemu
> traces
> have information in them.
>
> + Cillian probably has guidance on running it just on one test
> (say ticker)
> so you can see every step.
>
> + Check that the executables have symbolic information. "file"
> should
> show if they are stripped or not.
>
> I recall covoar has a verbose mode which should be of use.
>
> Cillian .. do you have instructions on running covoar in gdb?
>

 Alright so run rtems-test with --no-clean option to leave the
 coverage files lying around

 $HOME/development/rtems/test/test/rtems-tools/tester/rtems-test
 --rtems-tools=$HOME/development/rtems/5
 --log=coverage-analysis.log --rtems-bsp=leon3_qemu --coverage 
 --no-clean
 --rtems-builddir=$HOME/development/rtems/leon3
 sparc-rtems5/c/leon3/testsuites/samples

 Then run

 gdb covoar

 from gdb prompt

 run -S /home/cpod/coverage_test/leon3/coverage/score.symcfg -O
 /home/cpod/coverage_test/leon3/test/score -fQEMU -Tsparc-r

Re: [PATCH] 5: Use a specific RTEMS tools version

[Chris Johns]

On 17/04/2018 21:18, Sebastian Huber wrote:
> On 17/04/18 12:12, Chris Johns wrote:
>> On 17/4/18 6:49 pm, Sebastian Huber wrote:
>>> On 17/04/18 10:30, Chris Johns wrote:
 On 17/04/2018 18:21, Sebastian Huber wrote:
> Download via HTTPS RTEMS file server.
>
> Close 3241.
 Can you please explain why this solves the issue in the ticket? I do not 
 see
 how
 they relate.
>>> This solves the ticket since git is no longer involved.
>>>
 There can be issues with a sequence of git commands if you are switching
 branches. This can be resolved by improving the sequence used.

> ---
>    rtems/config/tools/rtems-tools-5-1.cfg | 28 
> ++--
>    1 file changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/rtems/config/tools/rtems-tools-5-1.cfg
> b/rtems/config/tools/rtems-tools-5-1.cfg
> index 6efc4e3..e0178f0 100644
> --- a/rtems/config/tools/rtems-tools-5-1.cfg
> +++ b/rtems/config/tools/rtems-tools-5-1.cfg
> @@ -7,9 +7,33 @@
>    #
>    %if %{rsb_released}
>     %define rtems_tools_version %{rsb_version}
> +%else
> + %define rtems_tools_version ec419a05ee52869a7d5b8712ea8e7a7d74fde096
>    %endif
 Sorry, this is not the right place for this sort of detail. Version details
 need
 to be in the release defaults or overridden in a an arch specific file.
>>> Sorry, I didn't understand the logic for the rtems_tools_version definition 
>>> at
>>> all. Why is it dependent on rsb_released?
>> If the RSB is released the RTEMS ftp server is used for downloads and the
>> version is the RTEMS release verson. The RTEMS tools do not have a separate
>> release cycle from RTEMS and use the same version numbers.
>>
 Why this version?
>>> It is the latest commit. So, just the thing that would have been picked by 
>>> the
>>> current RSB.
>>>
>>> The use of a random HEAD is a major problem from my point of view. It makes 
>>> the
>>> RSB outcome build time dependent and irreproducible.
>> Releases are matched. I do not follow how this resolves any dependence issue
>> that may appear such as the dl06 and rtems-ld.
> 
> For the latest test suite you need an up to date rtems-ld. If you built the
> tools with RSB 703532cb04c6990fb21e97cb7347a16e9df11108 two months ago, then 
> it
> will not work. If you build with RSB 703532cb04c6990fb21e97cb7347a16e9df11108
> today, then everything is fine. This is a serious defect from my point of 
> view.

How is this any different from all the newlib changes you made? To me it is the
same.

Lets not get to too tangled up here it is development. I clearly stated in the
cover email a tools update was needed and in future I will send a single
specific email to the list to say an update is needed.

>>
 I do not follow or understand the purpose of the change and with a lack of
 specific detail it appears to solve a local problem. It may appear to 
 solve the
 problem because it side steps an issue related to switching branches.
>>> There are some reports on the mailing list related to the rtems-tools 
>>> download
>>> via git. It has at least two problems:
>>>
>>> 1. It fails sporadically.
>> The real issue in the way git is being sequenced should be fix.
>>
>>> 2. You need internet access during the build.
>> If you updated RTEMS and have disconnected and not updated the RSB with a new
>> hash version downloaded from your home ftp area you have stuffed anyway.
>>
> 
> You should be able to
> 
> ../source-builder/sb-set-builder --dry-run --with-download ...
> 
> and then disconnect from the internet to build the tools.
> 

The ability to create an archive directory is something I would welcome. I side
step around it in the release scripts at the moment but this functionality
should be moved into the RBS. It will happen when I find the time.

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

Re: [PATCH] 5: Use a specific RTEMS tools version

[Joel Sherrill]

On Tue, Apr 17, 2018, 7:27 PM Chris Johns  wrote:

> On 17/04/2018 21:18, Sebastian Huber wrote:
> > On 17/04/18 12:12, Chris Johns wrote:
> >> On 17/4/18 6:49 pm, Sebastian Huber wrote:
> >>> On 17/04/18 10:30, Chris Johns wrote:
>  On 17/04/2018 18:21, Sebastian Huber wrote:
> > Download via HTTPS RTEMS file server.
> >
> > Close 3241.
>  Can you please explain why this solves the issue in the ticket? I do
> not see
>  how
>  they relate.
> >>> This solves the ticket since git is no longer involved.
> >>>
>  There can be issues with a sequence of git commands if you are
> switching
>  branches. This can be resolved by improving the sequence used.
> 
> > ---
> >rtems/config/tools/rtems-tools-5-1.cfg | 28
> ++--
> >1 file changed, 26 insertions(+), 2 deletions(-)
> >
> > diff --git a/rtems/config/tools/rtems-tools-5-1.cfg
> > b/rtems/config/tools/rtems-tools-5-1.cfg
> > index 6efc4e3..e0178f0 100644
> > --- a/rtems/config/tools/rtems-tools-5-1.cfg
> > +++ b/rtems/config/tools/rtems-tools-5-1.cfg
> > @@ -7,9 +7,33 @@
> >#
> >%if %{rsb_released}
> > %define rtems_tools_version %{rsb_version}
> > +%else
> > + %define rtems_tools_version
> ec419a05ee52869a7d5b8712ea8e7a7d74fde096
> >%endif
>  Sorry, this is not the right place for this sort of detail. Version
> details
>  need
>  to be in the release defaults or overridden in a an arch specific
> file.
> >>> Sorry, I didn't understand the logic for the rtems_tools_version
> definition at
> >>> all. Why is it dependent on rsb_released?
> >> If the RSB is released the RTEMS ftp server is used for downloads and
> the
> >> version is the RTEMS release verson. The RTEMS tools do not have a
> separate
> >> release cycle from RTEMS and use the same version numbers.
> >>
>  Why this version?
> >>> It is the latest commit. So, just the thing that would have been
> picked by the
> >>> current RSB.
> >>>
> >>> The use of a random HEAD is a major problem from my point of view. It
> makes the
> >>> RSB outcome build time dependent and irreproducible.
> >> Releases are matched. I do not follow how this resolves any dependence
> issue
> >> that may appear such as the dl06 and rtems-ld.
> >
> > For the latest test suite you need an up to date rtems-ld. If you built
> the
> > tools with RSB 703532cb04c6990fb21e97cb7347a16e9df11108 two months ago,
> then it
> > will not work. If you build with RSB
> 703532cb04c6990fb21e97cb7347a16e9df11108
> > today, then everything is fine. This is a serious defect from my point
> of view.
>
> How is this any different from all the newlib changes you made? To me it
> is the
> same.
>

+1

Newlib, GCC and binutils bumps have broken things in the past and will
continue to do so. This is a development master and things have to break
periodically.

The next newlib bump picks up at least two corrections to pthread.h which
will break builds. When we update, I will.have to push my changes
correcting the prootoypes in our source.

Plus I have on my to do list to move what I think are the last three POSIX
.h files to newlib. That also is a hard break when newlib bumps.

>
> Lets not get to too tangled up here it is development. I clearly stated in
> the
> cover email a tools update was needed and in future I will send a single
> specific email to the list to say an update is needed.
>
> >>
>  I do not follow or understand the purpose of the change and with a
> lack of
>  specific detail it appears to solve a local problem. It may appear to
> solve the
>  problem because it side steps an issue related to switching branches.
> >>> There are some reports on the mailing list related to the rtems-tools
> download
> >>> via git. It has at least two problems:
> >>>
> >>> 1. It fails sporadically.
> >> The real issue in the way git is being sequenced should be fix.
> >>
> >>> 2. You need internet access during the build.
> >> If you updated RTEMS and have disconnected and not updated the RSB with
> a new
> >> hash version downloaded from your home ftp area you have stuffed anyway.
> >>
> >
> > You should be able to
> >
> > ../source-builder/sb-set-builder --dry-run --with-download ...
> >
> > and then disconnect from the internet to build the tools.
> >
>
> The ability to create an archive directory is something I would welcome. I
> side
> step around it in the release scripts at the moment but this functionality
> should be moved into the RBS. It will happen when I find the time.
>
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] 5: Use a specific RTEMS tools version

[Chris Johns]

On 17/04/2018 21:36, Sebastian Huber wrote:
> On 17/04/18 12:26, Chris Johns wrote:
>> On 17/4/18 8:14 pm, Chris Johns wrote:
>>> Also I do not want to hack around on dispatch.rtems.org to update this file.
>>>
>> This link seems to work ...
>>
>> https://git.rtems.org/rtems-tools/snapshot/rtems-tools-ec419a05ee52869a7d5b8712ea8e7a7d74fde096.tar.bz2
>>
>>
>> Must be a feature of cgit.
> 
> I think we should reduce the dependencies for source downloads in the RSB and
> maybe download everything from an RTEMS file server. 

The RSB does not stop you doing this locally. I think an RSB source archive
option would help make things simpler for anyone wanting to this.

There are means within the RSB to aid deployment for those users or companies
wanting to better manage configurations and dependent resources.

> Will we still use cgit or
> trac or whatever in 5 years in 10 years? A simple download location for all
> files is easer to adjust if we move infrastructure.

I am sorry you have lost me. The URL I posted is pretty similar to the URL
needed to fetch a file from our FTP so if we can easily adjust one we can adjust
the other. It is no different to an FTP being closed down, a project's home
directory moving, or a project's tree being moved, we need to adjust the paths 
used.

In relation to creating archives of files to store on our FTP server, we do not
have enough resources and funds to maintain what we have and I currently have no
interest in expanding what we do there. The URL I posted exists, works and takes
no extra effort to maintain.

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

Re: [PATCH] 5: Use a specific RTEMS tools version

[Sebastian Huber]

On 18/04/18 02:27, Chris Johns wrote:

On 17/04/2018 21:18, Sebastian Huber wrote:

On 17/04/18 12:12, Chris Johns wrote:

On 17/4/18 6:49 pm, Sebastian Huber wrote:

On 17/04/18 10:30, Chris Johns wrote:

On 17/04/2018 18:21, Sebastian Huber wrote:

Download via HTTPS RTEMS file server.

Close 3241.

Can you please explain why this solves the issue in the ticket? I do not see
how
they relate.

This solves the ticket since git is no longer involved.


There can be issues with a sequence of git commands if you are switching
branches. This can be resolved by improving the sequence used.


---
    rtems/config/tools/rtems-tools-5-1.cfg | 28 ++--
    1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/rtems/config/tools/rtems-tools-5-1.cfg
b/rtems/config/tools/rtems-tools-5-1.cfg
index 6efc4e3..e0178f0 100644
--- a/rtems/config/tools/rtems-tools-5-1.cfg
+++ b/rtems/config/tools/rtems-tools-5-1.cfg
@@ -7,9 +7,33 @@
    #
    %if %{rsb_released}
     %define rtems_tools_version %{rsb_version}
+%else
+ %define rtems_tools_version ec419a05ee52869a7d5b8712ea8e7a7d74fde096
    %endif

Sorry, this is not the right place for this sort of detail. Version details
need
to be in the release defaults or overridden in a an arch specific file.

Sorry, I didn't understand the logic for the rtems_tools_version definition at
all. Why is it dependent on rsb_released?

If the RSB is released the RTEMS ftp server is used for downloads and the
version is the RTEMS release verson. The RTEMS tools do not have a separate
release cycle from RTEMS and use the same version numbers.


Why this version?

It is the latest commit. So, just the thing that would have been picked by the
current RSB.

The use of a random HEAD is a major problem from my point of view. It makes the
RSB outcome build time dependent and irreproducible.

Releases are matched. I do not follow how this resolves any dependence issue
that may appear such as the dl06 and rtems-ld.

For the latest test suite you need an up to date rtems-ld. If you built the
tools with RSB 703532cb04c6990fb21e97cb7347a16e9df11108 two months ago, then it
will not work. If you build with RSB 703532cb04c6990fb21e97cb7347a16e9df11108
today, then everything is fine. This is a serious defect from my point of view.

How is this any different from all the newlib changes you made? To me it is the
same.

Lets not get to too tangled up here it is development. I clearly stated in the
cover email a tools update was needed and in future I will send a single
specific email to the list to say an update is needed.


Sorry, for the confusion, but the tool update is not an issue for me.

My issue is the irreproducible tool chain build. With this time 
dependent rtems-tools selection you cannot say RSB commit XYZ works with 
RTEMS commit ABC. In addition you have to say build the RSB after date 
LMN (and not after IJK?). You build with the same RSB today and tomorrow 
and potentially get two different tool sets? This is a serious defect 
from my point of view.


--
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] 5: Use a specific RTEMS tools version

[Chris Johns]

On 18/04/2018 15:07, Sebastian Huber wrote:> Sorry, for the confusion, but the
tool update is not an issue for me.

No problem.

> My issue is the irreproducible tool chain build.

Thanks for the specific task, this is an important issue.

> With this time dependent
> rtems-tools selection you cannot say RSB commit XYZ works with RTEMS commit 
> ABC.
> In addition you have to say build the RSB after date LMN (and not after IJK?).
> You build with the same RSB today and tomorrow and potentially get two 
> different
> tool sets? This is a serious defect from my point of view.

OK, this makes sense.

Let me look at the rtems-tools config in the RSB and get back you. I think the
cgit URL is the simplest approach to consider.

Chris

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

Re: [PATCH] 5: Use a specific RTEMS tools version

[Sebastian Huber]

On 18/04/18 07:22, Chris Johns wrote:

With this time dependent
rtems-tools selection you cannot say RSB commit XYZ works with RTEMS commit ABC.
In addition you have to say build the RSB after date LMN (and not after IJK?).
You build with the same RSB today and tomorrow and potentially get two different
tool sets? This is a serious defect from my point of view.

OK, this makes sense.

Let me look at the rtems-tools config in the RSB and get back you. I think the
cgit URL is the simplest approach to consider.


I currently work on an update of the patch to use this URL.

--
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 v2] 5: Use a specific RTEMS tools version

[Sebastian Huber]

Download via cgit archive.

Close #3403.
---
 rtems/config/tools/rtems-tools-5-1.cfg  | 28 ++--
 rtems/config/tools/rtems-tools-common-1.cfg | 12 
 2 files changed, 34 insertions(+), 6 deletions(-)

diff --git a/rtems/config/tools/rtems-tools-5-1.cfg 
b/rtems/config/tools/rtems-tools-5-1.cfg
index 6efc4e3..19c809d 100644
--- a/rtems/config/tools/rtems-tools-5-1.cfg
+++ b/rtems/config/tools/rtems-tools-5-1.cfg
@@ -7,9 +7,33 @@
 #
 %if %{rsb_released}
  %define rtems_tools_version %{rsb_version}
+%else
+ %define rtems_tools_version ec419a05ee52869a7d5b8712ea8e7a7d74fde096
+ %define rtems_tools_source rtems-tools-%{rtems_tools_version}
+ %source set rtems-tools 
https://git.rtems.org/rtems-tools/snapshot/%{rtems_tools_source}.tar.bz2
+ %hash sha512 rtems-tools-%{rtems_tools_version}.tar.bz2 
af1cda88144583bd9471056291d0a19e8ace0e45efded01e7d32014919a8e57e8a47a58497b2c9201dff925316a8b9cfd0d0e6000f4755471fdf5468b5daa517
 %endif
 
 #
-# The RTEMS Tools build instructions. We use tools 1.
+# Optionally enable/disable building the RTEMS Tools via the command line.
 #
-%include tools/rtems-tools-1.cfg
+%if %{defined with_rtems_tools}
+ %define rtems_tools_build 1
+%endif
+%if %{defined without_rtems_tools}
+ %define rtems_tools_build 0
+%endif
+
+#
+# Build by default.
+#
+%if ! %{defined rtems_tools_build}
+ %define rtems_tools_build 1
+%endif
+
+%if %{rtems_tools_build}
+ #
+ # The RTEMS Tools build instructions.
+ #
+ %include tools/rtems-tools-common-1.cfg
+%endif
diff --git a/rtems/config/tools/rtems-tools-common-1.cfg 
b/rtems/config/tools/rtems-tools-common-1.cfg
index 9474ad1..d4bbc3b 100644
--- a/rtems/config/tools/rtems-tools-common-1.cfg
+++ b/rtems/config/tools/rtems-tools-common-1.cfg
@@ -21,13 +21,17 @@ License:   BSD-2-Clause + GPL-2.0
   # target location and 'cd ..' fails.
   build_top=$(pwd)
 
-  %if %{rsb_released}
-rtems_tools_source="rtems-tools-%{rtems_tools_version}"
+  %if ! %{defined rtems_tools_source}
+%if %{rsb_released}
+  rtems_tools_source="rtems-tools-%{rtems_tools_version}"
+%else
+  rtems_tools_source="rtems-tools.git"
+%endif
   %else
-rtems_tools_source="rtems-tools.git"
+rtems_tools_source=%{rtems_tools_source}
   %endif
-  source_dir_rtems_tools=${rtems_tools_source}
 
+  source_dir_rtems_tools=${rtems_tools_source}
   %source setup rtems-tools -q -n ${rtems_tools_source}
   %patch setup rtems-tools -p1
 
-- 
2.12.3

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

Re: [PATCH v2] 5: Use a specific RTEMS tools version

[Chris Johns]

On 18/04/2018 15:51, Sebastian Huber wrote:
> Download via cgit archive.
> 
> Close #3403.

OK to push.

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

Re: [PATCH v2] 5: Use a specific RTEMS tools version

[Sebastian Huber]

On 18/04/18 07:51, Sebastian Huber wrote:

Download via cgit archive.

Close #3403.


The rtems-tools-common-1.cfg seems to be only used by 
rtems-tools-5-1.cfg. Maybe we can merge these two files. The 
%{rsb_released} stuff makes the logic a bit complicated.


--
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] 5: Use a specific RTEMS tools version

[Chris Johns]

On 18/04/2018 15:53, Sebastian Huber wrote:
> On 18/04/18 07:51, Sebastian Huber wrote:
>> Download via cgit archive.
>>
>> Close #3403.
> 
> The rtems-tools-common-1.cfg seems to be only used by rtems-tools-5-1.cfg. 
> Maybe
> we can merge these two files. The %{rsb_released} stuff makes the logic a bit
> complicated.
> 

It would be best to push as much common logic down to `rtems-tools-common-1.cfg`
so `rtems-tools-5-1.cfg` is simple so `rtems-tools-6-1.cfg` is simple to make.
Carrying the logic in `rtems-tools-5-1.cfg` means the change history is lost in
the next release.

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