Re: rtems-addr2line not working on ARM?

2019-09-05 Thread Chris Johns 
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.

> The mapping to the function (-f option) get both tools right.

Sorry I do not understand this sentence.

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

Looks like a bug and related to the comment not posted but present in the code 
...

  /*
   * Search the CU's collecting the addresses. An address can appear in
   * more than one CU. It may be the last address and the first.
   */

>   if (match.valid () &&
>   (match.is_an_end_sequence () || !!line.is_an_end_sequence ()))
>   {
>     match = line;
>   }
>   else
>   {

I think this is suppose to happen if match is not valid ...

>     match = line;

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

rtems-addr2line not working on ARM?

2019-09-05 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: [PATCH] record: Add support for interrupt handlers

2019-09-05 Thread Peter Dufault 
Don’t take it too far off-line, I want to follow.  But do take it out of 
“support for interrupt handlers…”.

> On Sep 5, 2019, at 01:29 , Chris Johns  wrote:
> 
> I think we can take C++ development styles offline and chat personally, maybe 
> in
> person soon. :)

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

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

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

Re: [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: [rtems commit] Add a parallel bootstrap command.

2019-09-05 Thread Joel Sherrill 
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.

--joel

On Wed, Sep 4, 2019 at 11:29 PM Chris Johns  wrote:
>
> Module:rtems
> Branch:master
> Commit:02ed0b802bb49cb380bc1387dc85adca059babee
> Changeset: 
> http://git.rtems.org/rtems/commit/?id=02ed0b802bb49cb380bc1387dc85adca059babee
>
> Author:Chris Johns 
> Date:  Tue Sep  3 10:40:46 2019 +1000
>
> Add a parallel bootstrap command.
>
> ---
>
>  rtems-bootstrap | 246 
> 
>  1 file changed, 246 insertions(+)
>
> diff --git a/rtems-bootstrap b/rtems-bootstrap
> new file mode 100755
> index 000..6519710
> --- /dev/null
> +++ b/rtems-bootstrap
> @@ -0,0 +1,246 @@
> +#! /usr/bin/env python
> +
> +#
> +# SPDX-License-Identifier: BSD-2-Clause
> +#
> +# Copyright (C) 2013-2019 Chris Johns (chr...@rtems.org)
> +# All rights reserved.
> +#
> +# 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.
> +#
> +
> +#
> +# RTEMS Tools Project (http://www.rtems.org/)
> +#
> +
> +from __future__ import print_function
> +
> +import argparse
> +import datetime
> +import multiprocessing
> +import os
> +import re
> +import sys
> +import threading
> +import time
> +
> +version = "1.0"
> +
> +class error(Exception):
> +"""Base class for Builder exceptions."""
> +def set_output(self, msg):
> +self.msg = msg
> +def __str__(self):
> +return self.msg
> +
> +class general_error(error):
> +"""Raise for a general error."""
> +def __init__(self, what):
> +self.set_output('error: ' + str(what))
> +
> +def _collect(path_, file):
> +confs = []
> +for root, dirs, files in os.walk(path_, topdown = True):
> +for f in files:
> +if f == file:
> +confs += [os.path.join(root, f)]
> +return confs
> +
> +def _grep(file, pattern):
> +rege = re.compile(pattern)
> +try:
> +f = open(file, 'r')
> +matches = [rege.match(l) != None for l in f.readlines()]
> +f.close()
> +except IOError as err:
> +raise general_error('reading: %s' % (file))
> +return True in matches
> +
> +class command:
> +
> +def __init__(self, cmd, cwd):
> +self.exit_code = 0
> +self.thread = None
> +self.output = None
> +self.cmd = cmd
> +self.cwd = cwd
> +self.result = None
> +
> +def runner(self):
> +
> +import subprocess
> +
> +#
> +# Support Python 2.6
> +#
> +if "check_output" not in dir(subprocess):
> +def f(*popenargs, **kwargs):
> +if 'stdout' in kwargs:
> +raise ValueError('stdout argument not allowed, it will 
> be overridden.')
> +process = subprocess.Popen(stdout=subprocess.PIPE, 
> *popenargs, **kwargs)
> +output, unused_err = process.communicate()
> +retcode = process.poll()
> +if retcode:
> +cmd = kwargs.get("args")
> +if cmd is None:
> +cmd = popenargs[0]
> +raise subprocess.CalledProcessError(retcode, cmd)
> +return output
> +su

Re: [PATCH] update rtems_waf

2019-09-05 Thread Vijay Kumar Banerjee 
On Thu, Sep 5, 2019 at 3:00 PM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> Hello Vijay,
>
> from the content I assume that's for rtems-examples.
>
> Out of curiosity: Is there some specific problem that is solved with
> that patch or is it just to be on the latest version? If there is a
> problem, it would be good to mention that in the commit message. If
> someone else has the same problem, he might be able to find the message
> and see that the commit solves it.
>
> Hi Christian,

The current build works fine, the intention behind updating is to use the
rtems_bsd checks that are present in the latest HEAD of rtems_waf. I was
using the new features in the lvgl example, but since that one has a pending
discussion, I sent a separate patch to just update the rtems_waf.

Best regards,
Vijay

> To be honest: I haven't really built the examples yet (maybe sometimes
> way back). So I won't be able to do a test of the patch in the next
> days. I hope that someone else will be able to test it till then so that
> it can be commited.
>
> Best regards
>
> Christian
>
> On 03/09/2019 15:33, Vijay Kumar Banerjee wrote:
> > ---
> >  file_io/crc/wscript| 6 +++---
> >  filesystem/fat_ramdisk/wscript | 6 +++---
> >  rtems_waf  | 2 +-
> >  3 files changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/file_io/crc/wscript b/file_io/crc/wscript
> > index f7b0f5b..531da20 100644
> > --- a/file_io/crc/wscript
> > +++ b/file_io/crc/wscript
> > @@ -26,9 +26,9 @@ def build(bld):
> >  #
> >  # Package the root file system as a C file.
> >  #
> > -rootfs.build(bld,
> > - name = 'fs-root',
> > - root = 'rootfs')
> > +rootfs.build_from_src_root(bld,
> > +   name = 'fs-root',
> > +   root = 'rootfs')
> >
> >  bld(features = 'c cprogram',
> >  target = 'crc.exe',
> > diff --git a/filesystem/fat_ramdisk/wscript
> b/filesystem/fat_ramdisk/wscript
> > index de806c1..a980187 100644
> > --- a/filesystem/fat_ramdisk/wscript
> > +++ b/filesystem/fat_ramdisk/wscript
> > @@ -26,9 +26,9 @@ def build(bld):
> >  #
> >  # Package the root file system as a C file.
> >  #
> > -rootfs.build(bld,
> > - name = 'fs-root',
> > - root = 'rootfs')
> > +rootfs.build_from_src_root(bld,
> > +   name = 'fs-root',
> > +   root = 'rootfs')
> >
> >  bld(features = 'c cprogram',
> >  target = 'fat_ramdisk.exe',
> > diff --git a/rtems_waf b/rtems_waf
> > index 1b89636..ad6c6e8 16
> > --- a/rtems_waf
> > +++ b/rtems_waf
> > @@ -1 +1 @@
> > -Subproject commit 1b896361d302aeda0145af90972aea863e28898f
> > +Subproject commit ad6c6e8771b95dffa73a7dc1167d98d208f17cb0
> >
>
> --
> 
> embedded brains GmbH
> Herr Christian Mauderer
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> Phone: +49-89-18 94 741 - 18
> Fax:   +49-89-18 94 741 - 08
> 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] Add lvgl_hello: Sample Hello world app using littleVGL and libbsd

2019-09-05 Thread Christian Mauderer 
Sorry for the late reply. This mail slipped my attention.

On 03/09/2019 08:22, Chris Johns wrote:
> On 3/9/19 3:30 pm, Christian Mauderer wrote:
>> On 03/09/2019 01:46, Chris Johns wrote:
>>> On 2/9/19 5:42 pm, Vijay Kumar Banerjee wrote:
 On Mon, Sep 2, 2019 at 4:34 AM Chris Johns >>> > wrote:
 > +     puts("\nRTEMS I2C TEST\n");
 > +     exit_code = bbb_register_i2c_0();
 > +     assert(exit_code == 0);

 Is this needed for the display to work?

 Yes. We need to register the rtems i2c device in order to work with the 
 TDA driver
 as libbsd uses rtems i2c driver. The bbb_register_* is making it bbb 
 specific, what
 do you suggest to make it more generic? 
>>>
>>> Should the I2C be registered during the BSP initalisation? This would 
>>> remove the
>>> need for this type of call being spread across all applications on the BBB. 
>>> The
>>> BBB has a lot of resources and the I2C is part of the SoC and so always 
>>> present.
>>>
>>> I cannot think of a way to have a sysinit entry that installs the driver 
>>> when
>>> the I2C bus used.
>>>
>>> Chris
>>
>> Hello Chris,
>>
>> I would also prefer that the I2C is initialized during BSP init. But
>> note that this opens the same discussion we had with Joel when I
>> suggested the FDT support as a project: It links in the Support for
>> every BSP. I don't really think it hurts for a small driver like I2C on
>> a big target like BBB but we should make sure that everyone is OK with that.
> 
> I suggest the I2C driver init is part of the BBB BSP and not part of every 
> BSP.
> I do not see this as the same as the FDT code then again I have not looked at
> the detail.

Clearly I used the wrong terms. Sorry for the confusion. I meant that it
will link in the I2C support for every application regardless whether
I2C is used or not. Joel mentioned that he would prefer it if not all
drivers are linked in automatically during the FDT support discussion. See:

https://lists.rtems.org/pipermail/devel/2019-August/027265.html

Joel wrote there: "I think this is a good idea if we can still avoid
bloating apps with all drivers."

Like I said: I wouldn't mind a small driver like I2C but we should have
all agree to it.

> 
>> What might could be a problem: Is there something in the initialization
>> that might is application specific? The still bad solution for pin
>> config for example? (@Vijay: Bad because it's hard coded in I2C driver
>> and not due to the double init.)
> 
> Maybe I am not understanding the issue. I thought there is I2C code is present
> in libbsd for the BBB frame buffer so when the frame buffer is initialised 
> some
> I2C activity happens. If the BBB I2C is not initialised the driver will fail 
> or
> the display will not be initialised and this is why the example has the code 
> to
> initialise the bus.

Right.

> 
> Examples should not contain BSP specific initialisations or we have to manage
> specific builds of the examples and that is problematic.

Fully agreed. Just not sure how that could be solved (without adding the
I2C driver).

> 
> Chris
> 

Best regards

Christian
-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
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] update rtems_waf

2019-09-05 Thread Christian Mauderer 
Hello Vijay,

from the content I assume that's for rtems-examples.

Out of curiosity: Is there some specific problem that is solved with
that patch or is it just to be on the latest version? If there is a
problem, it would be good to mention that in the commit message. If
someone else has the same problem, he might be able to find the message
and see that the commit solves it.

To be honest: I haven't really built the examples yet (maybe sometimes
way back). So I won't be able to do a test of the patch in the next
days. I hope that someone else will be able to test it till then so that
it can be commited.

Best regards

Christian

On 03/09/2019 15:33, Vijay Kumar Banerjee wrote:
> ---
>  file_io/crc/wscript| 6 +++---
>  filesystem/fat_ramdisk/wscript | 6 +++---
>  rtems_waf  | 2 +-
>  3 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/file_io/crc/wscript b/file_io/crc/wscript
> index f7b0f5b..531da20 100644
> --- a/file_io/crc/wscript
> +++ b/file_io/crc/wscript
> @@ -26,9 +26,9 @@ def build(bld):
>  #
>  # Package the root file system as a C file.
>  #
> -rootfs.build(bld,
> - name = 'fs-root',
> - root = 'rootfs')
> +rootfs.build_from_src_root(bld,
> +   name = 'fs-root',
> +   root = 'rootfs')
>  
>  bld(features = 'c cprogram',
>  target = 'crc.exe',
> diff --git a/filesystem/fat_ramdisk/wscript b/filesystem/fat_ramdisk/wscript
> index de806c1..a980187 100644
> --- a/filesystem/fat_ramdisk/wscript
> +++ b/filesystem/fat_ramdisk/wscript
> @@ -26,9 +26,9 @@ def build(bld):
>  #
>  # Package the root file system as a C file.
>  #
> -rootfs.build(bld,
> - name = 'fs-root',
> - root = 'rootfs')
> +rootfs.build_from_src_root(bld,
> +   name = 'fs-root',
> +   root = 'rootfs')
>  
>  bld(features = 'c cprogram',
>  target = 'fat_ramdisk.exe',
> diff --git a/rtems_waf b/rtems_waf
> index 1b89636..ad6c6e8 16
> --- a/rtems_waf
> +++ b/rtems_waf
> @@ -1 +1 @@
> -Subproject commit 1b896361d302aeda0145af90972aea863e28898f
> +Subproject commit ad6c6e8771b95dffa73a7dc1167d98d208f17cb0
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

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

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

2019-09-05 Thread Chris Johns 
On 5/9/19 5:53 pm, Sebastian Huber wrote:
> - 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? 

Just calls, classes, etc so it shows where something comes from? I did not know
std::size_t worked. For example with `fwrite` I had to check if this was locally
provided in a class. For C++ I use `std::cout` and for C I use `::memset`.

I have got in the habit of doing this as some options give warnings when 
missing.

Maybe we should just place a "using namespace std;" in *.cc files (this would
violate also a Google rule).

I agree please do not do this. It undermines the readability of the code.

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