Re: fenv on RISC-V

2019-08-15 Thread Joel Sherrill
OK. I am going to through an issue out and then paste another email
from Jim Wilson. Let's see if we can figure this one out portably.

(1) Every architecture now will have an implementation of fenv. It may
be a stub, non-functional fenv implementation. If this is the case, many
methods return "-ENOTSUP". If the test first checks for fegetenv()
returning this, then the architecture has no support. The test could detect
this as a first step and exit.

(2) RISC-V is the only architecture currently with an implementation. It
has very limited support (return 0 mostly) when there is no hardware
floating point. __riscv_flen is defined to 0 for no HW FP, 4 for single
support and 4 for double support (8 coming for 128 bit). RTEMS'
CPU_HARDWARE_FP is always false on this architecture since
this trips code in the cpukit. I don't know how to flag whether the test
should be run or not on this architecture.

(3) According to Jim, there are allowed variations on the exception
method behavior. We may have to account for that.

My first thought is that embedding logic to know if the test applies
or not is a bad idea since we could end up with multiple tests.

Second thought is to add a .h file which contains the architecture
specific logic and a static inline method which reports if the test
should be attempted. Then any test which needs fenv can all it.
The question is would this be good in the cpukit like "rtems/test_fenv.h"?
That way an application could ask questions.

Email from Jim below my signature. I suspect this should migrate to
the CPU Supplement. I'm open to comments on this also.

Thoughts?

--joel

=

We have __riscv_float_abi_soft, __riscv_float_abi_single, and
__riscv_float_abi_double which indicate the size of FP registers being
used for argument passing, which can be none, single-float only, or
single-float and double.  We also have __riscv_flen which can be zero
for no float, 32 for single float only, and 64 for single and double
float.  So each one of these has 3 values.  And there is already a
formal 128-bit FP proposal, so at some point each of these will have 4
possible values.  The hardware FP reg size does not have to match the
ABI arg passing FP reg size.  It just needs to be greater than or
equal to it.  So you can have a rv64gc target using the lp64 ABI,
where we have FP regs that can hold double, but we don't use FP regs
for argument passing.  This can be useful for upward compatibility,
e.g. if the first version of the project has no FP regs, and then they
are added later, and you want new code to be ABI compatible with old
code.  So there are 6 different valid combinations of FP hardware reg
size and FP ABI reg size currently, which will grow to 10 when 128-bit
FP support is added.

Note that if you have a single float target, then you will use soft
float support for double, and hard float support for single.  If you
have a single float target, and use the soft float ABI, and have code
that uses float, then you will get code that uses the FP registers for
arithmetic, but not for argument passing.  Also, another interesting
bit here is that the libgcc soft-float code has a check for
__riscv_flen, and will use fcsr for exceptions.  This case triggers if
you have a single float target, and need soft-float double code, in
which case the soft-float double routines will use fcsr to signal
exceptions because it exists.  It will also use it for rounding modes.
But if you have a target with no FP hardware, and need soft-float
double code, then fcsr does not exist, and you get no rounding mode
support and no exception support, though maybe that can be implemented
in the future.  So the soft-float double support may or may not
support rounding and exceptions depending on the target it is compiled
for.

=


On Thu, Aug 15, 2019 at 4:31 PM Chris Johns  wrote:
>
> On 16/8/19 1:38 am, Gedare Bloom wrote:
> > On Wed, Aug 14, 2019 at 12:44 PM Joel Sherrill  wrote:
> >>
> >> Hi
> >>
> >> I emailed Jim Wilson of SiFive and got a quick response. Much thanks
> >> to him and this is his reply:
> >>
> >> ==
> >> I don't have any embedded hardware that I can use for testing.  I just
> >> have linux and simulators (qemu, gdb sim).  I haven't seen gcc
> >> testsuite failures related to fenv, but not sure if those tests are
> >> being run for embedded elf targets.  The testcase doesn't work with
> >> gdb sim, probably a gdb sim bug.  It does work with qemu, but only if
> >> I use a -march that has FP support.  Checking the code, it looks
> >> pretty obvious, fegetexceptflag for instance is
> >>
> >> int fegetexceptflag(fexcept_t *flagp, int excepts)
> >> {
> >> #if __riscv_flen
> >> ...
> >> #endif
> >>   return 0;
> >> }
> >>
> >> __riscv_flen is the number of bits (bytes?) in the FP registers, and
> >> is zero if this is target has no FP support.  So fenv for soft-float
> >> targets hasn't been implemented.  Was probably implemented for hard
> 

Re: [PATCH] dtc.bset: update to 1.4.1 to match qemu

2019-08-15 Thread Chris Johns
On 16/8/19 1:24 am, Gedare Bloom wrote:
> FWIW: I had to build dtc by hand recently. It might be worth it to
> work up an RSB script for host tooling to help users/developers work
> with DT.

There is support ...

https://git.rtems.org/rtems-source-builder/tree/bare/config/devel/dtc.bset

The version in the buildset is not 1.4.1. To use ...

 cd bare
 ../source-builder/sb-setbuilder --prefix=/x/y/z devel/dtc

The issue I had was building it on Windows. In the end I settled on using the
msys2 (cygwin) build.

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


Re: fenv on RISC-V

2019-08-15 Thread Chris Johns
On 16/8/19 1:38 am, Gedare Bloom wrote:
> On Wed, Aug 14, 2019 at 12:44 PM Joel Sherrill  wrote:
>>
>> Hi
>>
>> I emailed Jim Wilson of SiFive and got a quick response. Much thanks
>> to him and this is his reply:
>>
>> ==
>> I don't have any embedded hardware that I can use for testing.  I just
>> have linux and simulators (qemu, gdb sim).  I haven't seen gcc
>> testsuite failures related to fenv, but not sure if those tests are
>> being run for embedded elf targets.  The testcase doesn't work with
>> gdb sim, probably a gdb sim bug.  It does work with qemu, but only if
>> I use a -march that has FP support.  Checking the code, it looks
>> pretty obvious, fegetexceptflag for instance is
>>
>> int fegetexceptflag(fexcept_t *flagp, int excepts)
>> {
>> #if __riscv_flen
>> ...
>> #endif
>>   return 0;
>> }
>>
>> __riscv_flen is the number of bits (bytes?) in the FP registers, and
>> is zero if this is target has no FP support.  So fenv for soft-float
>> targets hasn't been implemented.  Was probably implemented for hard
>> float targets because it is easy, we just directly read/write the fp
>> status register.
>>
>> feraiseexcept isn't fully supported, but that seems to be a standards
>> interpretation question.  RISC-V hardware doesn't have a way to
>> automatically trap when an exception is raised.  We can only set a bit
>> in the fp status register and something else needs to check that and
>> trap.  So is feraiseexcept full implemented if we set the bit but
>> don't trap?  Newlib says no.  Glibc says yes.  But glibc has
>> feenableexcept and FE_NOMASK_ENV.  Newlib does not.  So on RISC-V, all
>> exceptions are masked, and that can't be changed.
>> ==
>>
>> This test (and fenv in general) is unlikely to work on an target with
>> soft float per Jim and some newlib discussions. On those BSPs,
>> it may have to be marked as NA with a comment about soft float.
>> Unless the test is automatically disabled if the CPU_HARDWARE_FP
>> define in RTEMS is false. But this is always defined to FALSE on risc-v.
>>
>> Q: Is hardware FP even supported right now on RISC-V? I don't see the
>> context switch code assuming there are registers to switch.
>>
>> And as Jim notes, even on some hardware targets (yes RISC-V), some
>> things don't work.
>>
>> So let's try this on a HW FP target and see if the works.
>>
>> Then address how to automatically disable this test with fall back to
>> updating a lot of .tcfg files.
>>
> 
> The test should not be disabled. The test should report a failure,
> because the functionality is not implemented *but it could be.*
> 
> We should not be using the tcfg filtering simply to disable tests that
> we know fail. As I understand it, the filter mechanism is mainly there
> to help us with tests that can't be executed on the target due to some
> missing resources e.g., insufficient memory, no cache, etc. Even
> though no one implemented the support for soft-float, it could be
> done, and a user might want to know that these tests fail for this
> target.
> 
> This is not the first time I've noticed it mentioned to exclude tests
> that we know fail, but there is a difference between something we know
> is missing/never-to-be-implemented versus something that is impossible
> to implement. We should exclude the latter, but fail on the former.

Well said and 100% correct.

I am considering a tool that helps us manage these settings. My hope is that may
generate some more activity in this area.

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


Re: RTEMS Source Builder failed for MX Linux

2019-08-15 Thread Chris Johns
On 16/8/19 4:48 am, Himanshu Sekhar Nayak wrote:
> Hi Chris,
> 
> Finally RTEMS build run for MX Linux.

That is great news. Well done.

> I will soon release the patch after testing it.

A patch to the user manual adding this distro would be nice.

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


Re: [PATCH v1] Remove back-slash in 'pacman' command in 'PDF' section under Arch Linux (installation of Sphinx).

2019-08-15 Thread Joel Sherrill
Pushed. Thanks.

On Thu, Aug 15, 2019 at 2:34 PM Vaibhav Gupta  wrote:
>
> I apologize for this , will follow the given instructions from next time.
>
> - Vaibhav
>
> On Thu, Aug 15, 2019 at 8:52 PM Gedare Bloom  wrote:
>>
>> Please don't send multiple identical patches to the mailing list. You
>> may reply to a patch to 'ping' it if you want to get it some attention
>> after it sits for a few days.
>>
>> On Wed, Aug 14, 2019 at 11:44 PM Vaibhav Gupta  
>> wrote:
>> >
>> > ---
>> >  README.txt | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/README.txt b/README.txt
>> > index 3679d1d..1567be6 100644
>> > --- a/README.txt
>> > +++ b/README.txt
>> > @@ -247,7 +247,7 @@ Sphinx:
>> >
>> >  PDF:
>> >
>> > -  # pacman -S texlive-bin texlive-core texlive-latexextra 
>> > texlive-fontsextra \
>> > +  # pacman -S texlive-bin texlive-core texlive-latexextra 
>> > texlive-fontsextra
>> >
>> >  openSUSE
>> >  
>> > --
>> > 2.21.0
>> >
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: Beagle: FDT support in BSP as a GSoC project?

2019-08-15 Thread Joel Sherrill
All I meant by "not all drivers" and "small" is that we currently do
not include code that
the application doesn't have a need for. I don't want that to change.
If the application
doesn't use i2c or the frame buffer, then those drivers shouldn't' be
there. I wasn't
attempting to create a new requirement -- just emphasize what we already do
shouldn't change.

--joel

On Thu, Aug 15, 2019 at 1:49 PM Christian Mauderer  wrote:
>
> On 12/08/2019 08:18, Chris Johns wrote:
> > On 12/8/19 3:51 pm, Christian Mauderer wrote:
> >>
> >> On 12/08/2019 03:33, Chris Johns wrote:
> >>> On 12/8/19 9:22 am, Joel Sherrill wrote:
> 
> 
>  On Sun, Aug 11, 2019, 5:47 PM Chris Johns   > wrote:
> 
>  On 12/8/19 3:28 am, Joel Sherrill wrote:
>  > On Sun, Aug 11, 2019, 10:59 AM Christian Mauderer 
>    
>  > >> wrote:
>  >
>  > Hello,
>  >
>  > while mentoring Vijays GSoC project this year I noted that 
>  some drivers
>  > in the Beagle BSPs have quite horrible hard coded values for 
>  things like
>  > pinmux initialization. Maybe it would be a nice GSoC project 
>  for next
>  > year to replace this stuff with a fdt based initialization. I 
>  would like
>  > to ask for feedback before creating a ticket for it because it 
>  would
>  > mean a quite big change for the BSP (maybe even the name - see 
>  below).
>  >
>  > Basically such a project would include the following parts:
>  >
>  > - Parse the pinmux settings from FDT and create a two part 
>  driver for a
>  > 'pinctrl-single' compatible FDT entry. One part generic, one 
>  device
>  > specific (similar to FreeBSD or Linux).
>  >
>  > - Remove pinmux initialization from all drivers.
>  >
>  > - Initialize drivers based on the FDT (instead of functions 
>  like
>  > bbb_register_i2c_1(...))
>  >
>  > - Taking a more detailed look at the FDT what else could be 
>  initialized
>  > from it (maybe clocks?)
>  >
>  > It could be a quite nice project for a RTEMS beginner. Due to 
>  the
>  > distributed initialization a lot of drivers have to be touched 
>  (at least
>  > i2c, spi and pwm). So a potential student would get a nice 
>  overview over
>  > the parts.
>  >
>  > Note that this would be a big change for the BSP. Currently 
>  the BSP can
>  > be used without an FDT (as far as I know). Only libbsd needs 
>  one. After
>  > that a FDT would be mandatory. Despite that, I think that it 
>  would be an
>  > improvement.
>  >
>  > Maybe it would be possible to merge the four beagle* BSPs that 
>  we have
>  > into only one "beagle" or "am33xx" BSP with that change. That 
>  would
>  > allow to support new Beagle variants like the Pocket Beagle 
>  without much
>  > effort (most likely only a change in the FDT).
>  >
>  > What do you think? Should I create a ticket for it?
>  >
> 
>  I love it. Yes please create a ticket.
> >>
> >> OK. I'll create one in the next days.
> >>
> 
>  > I think this is a good idea if we can still avoid bloating apps 
>  with all
>  > drivers. Make sure it has the right tags and shows up on the 
>  project page.
> 
>  The beagle has a lot of RAM. Is this as important for this BSP?
> >>
> >> Most likely that's true for a lot of other FDT based BSPs too. Most of
> >> the time FDT is used together with Linux systems.
> >>
> 
>  Not really but we don't want bad patterns starting.
> >
> >>> How does a user then configure a build to get the minimal set for them?
> >>>
> >>> Without dynamically loading does mean we need a bunch of build options? Is
> >>> building for dynamic loading something we should consider?
> >>
> >> I think there would be two possibilities:
> >>
> >> 1. Introduce a module system similar to FreeBSD / libbsd. You
> >> explicitely have to create a module reference if you want a driver.
> >>
> >> 2. Do it the other way round: Take care that device drivers are only
> >> referenced via one init function. If a user wants a small config, he can
> >> overwrite the function in his application which removes the driver.
> >>
> >> I would prefer 2 because:
> >>
> >> - Most likely it's simpler for the average user to just have everything
> >> available without a special configuration.
> >
> > I agree.
> >
> >> - It's simpler to implement.
> >>
> >> - A user that really needs the last few bytes on a system like 

Re: [PATCH v1] Remove back-slash in 'pacman' command in 'PDF' section under Arch Linux (installation of Sphinx).

2019-08-15 Thread Vaibhav Gupta
I apologize for this , will follow the given instructions from next time.

- Vaibhav

On Thu, Aug 15, 2019 at 8:52 PM Gedare Bloom  wrote:

> Please don't send multiple identical patches to the mailing list. You
> may reply to a patch to 'ping' it if you want to get it some attention
> after it sits for a few days.
>
> On Wed, Aug 14, 2019 at 11:44 PM Vaibhav Gupta 
> wrote:
> >
> > ---
> >  README.txt | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/README.txt b/README.txt
> > index 3679d1d..1567be6 100644
> > --- a/README.txt
> > +++ b/README.txt
> > @@ -247,7 +247,7 @@ Sphinx:
> >
> >  PDF:
> >
> > -  # pacman -S texlive-bin texlive-core texlive-latexextra
> texlive-fontsextra \
> > +  # pacman -S texlive-bin texlive-core texlive-latexextra
> texlive-fontsextra
> >
> >  openSUSE
> >  
> > --
> > 2.21.0
> >
> > ___
> > 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 v1] Add steps to test Newlib patch.

2019-08-15 Thread Vaibhav Gupta
On Thu, Aug 15, 2019 at 8:51 PM Gedare Bloom  wrote:

> Is this a duplicate of the other "patch v1 Add steps to test Newlib
> patch." or this one replaces it?
>
This one replaces it. Actually I replaced all the previous ones with mine.
The commands, steps I have written are based on what worked for me for
number of times.
I build the toolchain twice when RSB got updated, but my changes were not
pushed so had to
use patches in RSB. And these steps worked perfectly both times.

-Vaibhav

>
> On Wed, Aug 14, 2019 at 11:45 PM Vaibhav Gupta 
> wrote:
>
>> Update the checksum to be used for the Newlib patches.
>> Earlier it was msd5, but it is depreciated for security
>> reasons. Now RSB accepts sha512.
>> ---
>>  user/rsb/project-sets.rst | 41 +--
>>  1 file changed, 35 insertions(+), 6 deletions(-)
>>
>> diff --git a/user/rsb/project-sets.rst b/user/rsb/project-sets.rst
>> index 5ffce26..b01857e 100644
>> --- a/user/rsb/project-sets.rst
>> +++ b/user/rsb/project-sets.rst
>> @@ -261,17 +261,46 @@ in the ``source-builder/config`` template
>> configuration files.
>>  To test a patch simply copy it to your local ``patches`` directory. The
>> RSB
>>  will see the patch is present and will not attempt to download it. Once
>> you are
>>  happy with the patch submit it to the project and a core developer will
>> review
>> -it and add it to the RTEMS Tools git repository.  For example, to test a
>> local
>> -patch for newlib, add the following two lines to the .cfg file in
>> -``rtems/config/tools/`` that is included by the bset you use:
>> +it and add it to the RTEMS Tools git repository.
>> +
>> +Testing a Newlib Patch
>> +~~
>> +
>> +To test a local patch for newlib, you need to add the following
>> +two lines to the ``.cfg`` file in ``rsb/rtems/config/tools/`` that is
>> included
>> +by the bset you use:
>> +
>> +.. topic:: Steps:
>> +
>> +  1. Create patches for the changes you want to test. (Note: For RSB,
>> before
>> + creating Newlib patch, you must run ``autoreconf -fvi`` in the
>> required
>> + directory after you make changes to the code. This is not required
>> when
>> + you create patch to send to ``newlib-devel``. But if you want RSB
>> to
>> + address your changes, your patch should also include regenerated
>> files.)
>> +
>> +  2. Calculate ``sha512`` of your patch.
>> +
>> +  3. Place the patches in ``rsb/rtems/patches`` directory.
>> +
>> +  4. Open the ``.bset`` file used by your BSP in ``rsb/rtems/config``.
>> + For example, for ``rtems5``, ``SPARC``, the file will be
>> + ``rsb/rtems/config/5/rtems-sparc.bset``.
>> +
>> +  5. Inside it you will find the name of ``.cfg`` file for Newlib, used
>> by
>> + your BSP.
>> + For example, I found ``tools/rtems-gcc-7.4.0-newlib-1d35a003f``.
>> +
>> +  6. Edit your ``.cfg`` file. In my case it will be,
>> + ``rsb/rtems/config/tools/rtems-gcc-7.4.0-newlib-1d35a003f.cfg``. And
>> + add the information about your patch as mentioned below.
>>
>>  .. code-block:: spec
>>
>> -%patch add newlib file://0001-this-is-a-newlib-patch.patch   <1>
>> -%hash md5 0001-this-is-a-newlib-patch.diff
>> 77d070878112783292461bd6e7db17fb <2>
>> +%patch add newlib -p1 file://0001-Port-ndbm.patch <1>
>> +%hash sha512 0001-Port-ndbm.patch
>> 7d999ceeea4f3dc82e8e0aadc09d983a7a68b44470da8a3d61ab6fc558fdba6f2c2de3acc2f32c0b0b97fcc9ab799c27e87afe046544a69519881f947e7881d1
>> <2>
>>
>>  .. topic:: Items:
>>
>>1. The diff file prepended with ``file://`` to tell RSB this is a
>> local file.
>>
>> -  2. The output from md5sum on the diff file.
>> +  2. The output from sha512sum on the patch file.
>>
>> --
>> 2.21.0
>> ___
>> 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

GSoC 2019 : POSIX Compliance - Final Report

2019-08-15 Thread Vaibhav Gupta
Hello,
I have made the draft of my project report on google docs.
I have mentioned about each and every task completed
and which are in progress.
.
It would be very helpful for me If I can get reviews on this,
will also make required changes.
.
https://docs.google.com/document/d/1I3FsA0whd2AcLKdagUzins-JmWv1QTC6-0v0uvS1_7k/edit?usp=sharing
.
.
Thank You
Vaibhav Gupta
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Beagle: FDT support in BSP as a GSoC project?

2019-08-15 Thread Christian Mauderer
On 12/08/2019 08:18, Chris Johns wrote:
> On 12/8/19 3:51 pm, Christian Mauderer wrote:
>>
>> On 12/08/2019 03:33, Chris Johns wrote:
>>> On 12/8/19 9:22 am, Joel Sherrill wrote:


 On Sun, Aug 11, 2019, 5:47 PM Chris Johns >>> > wrote:

 On 12/8/19 3:28 am, Joel Sherrill wrote:
 > On Sun, Aug 11, 2019, 10:59 AM Christian Mauderer >>> 
 > >> wrote:
 >
 >     Hello,
 >
 >     while mentoring Vijays GSoC project this year I noted that some 
 drivers
 >     in the Beagle BSPs have quite horrible hard coded values for 
 things like
 >     pinmux initialization. Maybe it would be a nice GSoC project for 
 next
 >     year to replace this stuff with a fdt based initialization. I 
 would like
 >     to ask for feedback before creating a ticket for it because it 
 would
 >     mean a quite big change for the BSP (maybe even the name - see 
 below).
 >
 >     Basically such a project would include the following parts:
 >
 >     - Parse the pinmux settings from FDT and create a two part 
 driver for a
 >     'pinctrl-single' compatible FDT entry. One part generic, one 
 device
 >     specific (similar to FreeBSD or Linux).
 >
 >     - Remove pinmux initialization from all drivers.
 >
 >     - Initialize drivers based on the FDT (instead of functions like
 >     bbb_register_i2c_1(...))
 >
 >     - Taking a more detailed look at the FDT what else could be 
 initialized
 >     from it (maybe clocks?)
 >
 >     It could be a quite nice project for a RTEMS beginner. Due to the
 >     distributed initialization a lot of drivers have to be touched 
 (at least
 >     i2c, spi and pwm). So a potential student would get a nice 
 overview over
 >     the parts.
 >
 >     Note that this would be a big change for the BSP. Currently the 
 BSP can
 >     be used without an FDT (as far as I know). Only libbsd needs 
 one. After
 >     that a FDT would be mandatory. Despite that, I think that it 
 would be an
 >     improvement.
 >
 >     Maybe it would be possible to merge the four beagle* BSPs that 
 we have
 >     into only one "beagle" or "am33xx" BSP with that change. That 
 would
 >     allow to support new Beagle variants like the Pocket Beagle 
 without much
 >     effort (most likely only a change in the FDT).
 >
 >     What do you think? Should I create a ticket for it?
 >

 I love it. Yes please create a ticket.
>>
>> OK. I'll create one in the next days.
>>

 > I think this is a good idea if we can still avoid bloating apps with 
 all
 > drivers. Make sure it has the right tags and shows up on the project 
 page.

 The beagle has a lot of RAM. Is this as important for this BSP?
>>
>> Most likely that's true for a lot of other FDT based BSPs too. Most of
>> the time FDT is used together with Linux systems.
>>

 Not really but we don't want bad patterns starting. 
>
>>> How does a user then configure a build to get the minimal set for them?
>>>
>>> Without dynamically loading does mean we need a bunch of build options? Is
>>> building for dynamic loading something we should consider?
>>
>> I think there would be two possibilities:
>>
>> 1. Introduce a module system similar to FreeBSD / libbsd. You
>> explicitely have to create a module reference if you want a driver.
>>
>> 2. Do it the other way round: Take care that device drivers are only
>> referenced via one init function. If a user wants a small config, he can
>> overwrite the function in his application which removes the driver.
>>
>> I would prefer 2 because:
>>
>> - Most likely it's simpler for the average user to just have everything
>> available without a special configuration.
> 
> I agree.
> 
>> - It's simpler to implement.
>>
>> - A user that really needs the last few bytes on a system like Beagle is
>> unlikely.
>>
>> - If someone really needs the bytes, most likely he knew that when
>> creating the draft of the system. I would expect that this is a more
>> experienced user who either knows of the tricks or asks on the mailing list.
>>
> 
> This is reasonable.
> 
> Thanks
> Chris
> 

I created a ticket for it: https://devel.rtems.org/ticket/3784
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS Source Builder failed for MX Linux

2019-08-15 Thread Himanshu Sekhar Nayak
Hi Chris,

Finally RTEMS build run for MX Linux. I will soon release the patch after
testing it.

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

Re: RTEMS Muilti-I/O lib is missing

2019-08-15 Thread Gedare Bloom
On Thu, Aug 15, 2019 at 9:33 AM Joel Sherrill  wrote:
>
>
>
> On Thu, Aug 15, 2019, 10:25 AM Wendell Silva  wrote:
>>
>> Although git://git.rtems.org/multiio.git is clonable, this repository is not 
>> listed as an official RTEMS git repo at git.rtems.org.
>>
>> Seems that multiio lib is not a first class citizen from RTEMS development 
>> any more. Why
>
>
> It never was a first class citizen. I always hoped it would provide a model 
> and guide for application level discrete and analog IO interface. OAR used 
> this library and interface successfully on multiple applications.
>
> Is anyone up for evaluating and championing this?
>
*holds up a mirror*

It sounds like you're the champion for it, Joel. :)

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


Re: fenv on RISC-V

2019-08-15 Thread Gedare Bloom
On Wed, Aug 14, 2019 at 12:44 PM Joel Sherrill  wrote:
>
> Hi
>
> I emailed Jim Wilson of SiFive and got a quick response. Much thanks
> to him and this is his reply:
>
> ==
> I don't have any embedded hardware that I can use for testing.  I just
> have linux and simulators (qemu, gdb sim).  I haven't seen gcc
> testsuite failures related to fenv, but not sure if those tests are
> being run for embedded elf targets.  The testcase doesn't work with
> gdb sim, probably a gdb sim bug.  It does work with qemu, but only if
> I use a -march that has FP support.  Checking the code, it looks
> pretty obvious, fegetexceptflag for instance is
>
> int fegetexceptflag(fexcept_t *flagp, int excepts)
> {
> #if __riscv_flen
> ...
> #endif
>   return 0;
> }
>
> __riscv_flen is the number of bits (bytes?) in the FP registers, and
> is zero if this is target has no FP support.  So fenv for soft-float
> targets hasn't been implemented.  Was probably implemented for hard
> float targets because it is easy, we just directly read/write the fp
> status register.
>
> feraiseexcept isn't fully supported, but that seems to be a standards
> interpretation question.  RISC-V hardware doesn't have a way to
> automatically trap when an exception is raised.  We can only set a bit
> in the fp status register and something else needs to check that and
> trap.  So is feraiseexcept full implemented if we set the bit but
> don't trap?  Newlib says no.  Glibc says yes.  But glibc has
> feenableexcept and FE_NOMASK_ENV.  Newlib does not.  So on RISC-V, all
> exceptions are masked, and that can't be changed.
> ==
>
> This test (and fenv in general) is unlikely to work on an target with
> soft float per Jim and some newlib discussions. On those BSPs,
> it may have to be marked as NA with a comment about soft float.
> Unless the test is automatically disabled if the CPU_HARDWARE_FP
> define in RTEMS is false. But this is always defined to FALSE on risc-v.
>
> Q: Is hardware FP even supported right now on RISC-V? I don't see the
> context switch code assuming there are registers to switch.
>
> And as Jim notes, even on some hardware targets (yes RISC-V), some
> things don't work.
>
> So let's try this on a HW FP target and see if the works.
>
> Then address how to automatically disable this test with fall back to
> updating a lot of .tcfg files.
>

The test should not be disabled. The test should report a failure,
because the functionality is not implemented *but it could be.*

We should not be using the tcfg filtering simply to disable tests that
we know fail. As I understand it, the filter mechanism is mainly there
to help us with tests that can't be executed on the target due to some
missing resources e.g., insufficient memory, no cache, etc. Even
though no one implemented the support for soft-float, it could be
done, and a user might want to know that these tests fail for this
target.

This is not the first time I've noticed it mentioned to exclude tests
that we know fail, but there is a difference between something we know
is missing/never-to-be-implemented versus something that is impossible
to implement. We should exclude the latter, but fail on the former.

Gedare

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


Re: RTEMS Muilti-I/O lib is missing

2019-08-15 Thread Joel Sherrill
On Thu, Aug 15, 2019, 10:25 AM Wendell Silva  wrote:

> Although git://git.rtems.org/multiio.git is clonable, this repository is
> not listed as an official RTEMS git repo at git.rtems.org.
>
> Seems that multiio lib is not a first class citizen from RTEMS development
> any more. Why
>

It never was a first class citizen. I always hoped it would provide a model
and guide for application level discrete and analog IO interface. OAR used
this library and interface successfully on multiple applications.

Is anyone up for evaluating and championing this?


> --Wendell
> ___
> 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] dtc.bset: update to 1.4.1 to match qemu

2019-08-15 Thread Gedare Bloom
FWIW: I had to build dtc by hand recently. It might be worth it to
work up an RSB script for host tooling to help users/developers work
with DT.

On Wed, Aug 14, 2019 at 5:40 PM Joel Sherrill  wrote:
>
>
>
> On Wed, Aug 14, 2019, 6:02 PM Chris Johns  wrote:
>>
>> On 15/8/19 8:50 am, Joel Sherrill wrote:
>> > On Wed, Aug 14, 2019 at 5:27 PM Chris Johns  wrote:
>> >>
>> >> On 15/8/19 8:08 am, Joel Sherrill wrote:
>> >>> qemu-couverture.bset explicitly has 1.4.1.
>> >>
>> >> OK.
>> >>
>> >>> qemu.bset doesn't list dtc at all. No idea why not.
>> >>
>> >> Because you cannot build dtc on MinGW and I doubt you ever will be able 
>> >> to. Here
>> >> the MSYS2 package is used. I cannot remember the specifics.
>> >>
>> >>> But qemu-git-1.cfg has a dtc submodule of qemu pulled out of git so I
>> >>> guess qemu.bset is implicitly getting that.
>> >>
>> >> Yes, qemu's release cycle did not carry changes we needed.
>> >>
>> >>> Clear as mud to me.
>> >>
>> >> Be careful here because it a rather deep hole and time consuming to get 
>> >> all this
>> >> to work on all hosts. The qemu.bset did build on all hosts we support at 
>> >> one
>> >> point in time.
>> >
>> > Should I punt and use the native provided dtc? Or try to build it by hand 
>> > as a
>> > singleton using the RSB?
>> >
>> > I think updating to 1.4.1 vs 1.2 is OK but am happy to drop it from
>> > the qemu set.
>>
>> Yeap.
>>
>> > But we can defer this and I will try dtc 1.2 as an RSB singleton, then 
>> > host DTC.
>> > It is needed by spike.
>>
>> I do not know as I cannot remember the specific now and things may have 
>> changed.
>>
>> Maybe add it and then try and see what breaks?
>
>
> I'll take the baby step of building it from the rsb manually until we get all 
> the testing hosts online.
>>
>>
>> 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


RTEMS Muilti-I/O lib is missing

2019-08-15 Thread Wendell Silva
Although git://git.rtems.org/multiio.git is clonable, this repository is
not listed as an official RTEMS git repo at git.rtems.org.

Seems that multiio lib is not a first class citizen from RTEMS development
any more. Why?

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

Re: [PATCH v1] Remove back-slash in 'pacman' command in 'PDF' section under Arch Linux (installation of Sphinx).

2019-08-15 Thread Gedare Bloom
Please don't send multiple identical patches to the mailing list. You
may reply to a patch to 'ping' it if you want to get it some attention
after it sits for a few days.

On Wed, Aug 14, 2019 at 11:44 PM Vaibhav Gupta  wrote:
>
> ---
>  README.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/README.txt b/README.txt
> index 3679d1d..1567be6 100644
> --- a/README.txt
> +++ b/README.txt
> @@ -247,7 +247,7 @@ Sphinx:
>
>  PDF:
>
> -  # pacman -S texlive-bin texlive-core texlive-latexextra texlive-fontsextra 
> \
> +  # pacman -S texlive-bin texlive-core texlive-latexextra texlive-fontsextra
>
>  openSUSE
>  
> --
> 2.21.0
>
> ___
> 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 v1] Add steps to test Newlib patch.

2019-08-15 Thread Gedare Bloom
Is this a duplicate of the other "patch v1 Add steps to test Newlib patch."
or this one replaces it?

On Wed, Aug 14, 2019 at 11:45 PM Vaibhav Gupta 
wrote:

> Update the checksum to be used for the Newlib patches.
> Earlier it was msd5, but it is depreciated for security
> reasons. Now RSB accepts sha512.
> ---
>  user/rsb/project-sets.rst | 41 +--
>  1 file changed, 35 insertions(+), 6 deletions(-)
>
> diff --git a/user/rsb/project-sets.rst b/user/rsb/project-sets.rst
> index 5ffce26..b01857e 100644
> --- a/user/rsb/project-sets.rst
> +++ b/user/rsb/project-sets.rst
> @@ -261,17 +261,46 @@ in the ``source-builder/config`` template
> configuration files.
>  To test a patch simply copy it to your local ``patches`` directory. The
> RSB
>  will see the patch is present and will not attempt to download it. Once
> you are
>  happy with the patch submit it to the project and a core developer will
> review
> -it and add it to the RTEMS Tools git repository.  For example, to test a
> local
> -patch for newlib, add the following two lines to the .cfg file in
> -``rtems/config/tools/`` that is included by the bset you use:
> +it and add it to the RTEMS Tools git repository.
> +
> +Testing a Newlib Patch
> +~~
> +
> +To test a local patch for newlib, you need to add the following
> +two lines to the ``.cfg`` file in ``rsb/rtems/config/tools/`` that is
> included
> +by the bset you use:
> +
> +.. topic:: Steps:
> +
> +  1. Create patches for the changes you want to test. (Note: For RSB,
> before
> + creating Newlib patch, you must run ``autoreconf -fvi`` in the
> required
> + directory after you make changes to the code. This is not required
> when
> + you create patch to send to ``newlib-devel``. But if you want RSB to
> + address your changes, your patch should also include regenerated
> files.)
> +
> +  2. Calculate ``sha512`` of your patch.
> +
> +  3. Place the patches in ``rsb/rtems/patches`` directory.
> +
> +  4. Open the ``.bset`` file used by your BSP in ``rsb/rtems/config``.
> + For example, for ``rtems5``, ``SPARC``, the file will be
> + ``rsb/rtems/config/5/rtems-sparc.bset``.
> +
> +  5. Inside it you will find the name of ``.cfg`` file for Newlib, used by
> + your BSP.
> + For example, I found ``tools/rtems-gcc-7.4.0-newlib-1d35a003f``.
> +
> +  6. Edit your ``.cfg`` file. In my case it will be,
> + ``rsb/rtems/config/tools/rtems-gcc-7.4.0-newlib-1d35a003f.cfg``. And
> + add the information about your patch as mentioned below.
>
>  .. code-block:: spec
>
> -%patch add newlib file://0001-this-is-a-newlib-patch.patch   <1>
> -%hash md5 0001-this-is-a-newlib-patch.diff
> 77d070878112783292461bd6e7db17fb <2>
> +%patch add newlib -p1 file://0001-Port-ndbm.patch <1>
> +%hash sha512 0001-Port-ndbm.patch
> 7d999ceeea4f3dc82e8e0aadc09d983a7a68b44470da8a3d61ab6fc558fdba6f2c2de3acc2f32c0b0b97fcc9ab799c27e87afe046544a69519881f947e7881d1
> <2>
>
>  .. topic:: Items:
>
>1. The diff file prepended with ``file://`` to tell RSB this is a local
> file.
>
> -  2. The output from md5sum on the diff file.
> +  2. The output from sha512sum on the patch file.
>
> --
> 2.21.0
> ___
> 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: GSoC 2019: POSIX Compliance - FENV Environment probably not working properly in RISCV

2019-08-15 Thread Vaibhav Gupta
On Wed, Aug 14, 2019 at 8:56 PM Hesham Almatary 
wrote:

> On Wed, 14 Aug 2019 at 16:18, Vaibhav Gupta 
> wrote:
> >
> >
> >
> > On Wed, Aug 14, 2019, 8:09 PM Joel Sherrill  wrote:
> >>
> >> On Wed, Aug 14, 2019 at 9:35 AM Vaibhav Gupta 
> wrote:
> >> >
> >> > You are also getting same error :(
> >> > I thought problem is with my system/laptop and was trying to correct
> things.
> >> > Should we take the discussion to newlib?
> >>
> >> I would like Jiri and Hesham to chime in on the next step. I don't
> >> know the RISC-V
> >> well enough to say if this is a bug in risc-v fenv or not.
> >
> > Okay
>
> Can you try to build a BSP with FPU instructions? rv32imafdc? and test
> again? I assume this will eventually do FPU calculations that will
> emit FPU instructions in the case of rv32imafdc or softfloat in the
> case of rv32imac.
>
Hello, I tried with rv32imafdc too, same problem. I have sent a more proper
report on
devel with the patch for code I was working on.
It seems to be riscv specific issue.

-- Vaibhav Gupta

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

GSoC 2019 : POSIX Complaince - Fenv methods not returning expected outputs.

2019-08-15 Thread Vaibhav Gupta
Hello,
In yesterday's weekly meeting I mentioned about fenv problems I faced while
developing testsuite.
.
Here is a very raw patch of my code as testsuite is still in development.
.
==
Error 1
==
I took three float values:
a = 0.0
b = 1.0
c = b/a
This should have automatically raised FE_DIVBYZERO exception, which does
not happens.
No exception flag is set.
.
.
==
Error 2
==
Then I tried to raise an exception manually using feraiseexcept(), but this
operation was also unsuccessful .
The method returned 1 on execution, but it should return 0 on successful
operation.
.
.
==
Warning
==
As mentioned in opengroup I tried to define a pragma
https://pubs.opengroup.org/onlinepubs/009696799/basedefs/fenv.h.html
.
#pragma STDC FENV_ACCESS ON
.
But this pragma is ignored while 'make -j 2'
/home/varodek/development/rtems/kernel/rtems/c/src/../../testsuites/psxtests/psxfenv01/init.c:50:
warning: ignoring #pragma STDC FENV_ACCESS [-Wunknown-pragmas]

.
.

--Vaibhav Gupta
From 3ed1e005dd7629c2b0501cac457a758f3103b1fe Mon Sep 17 00:00:00 2001
From: Vaibhav Gupta 
Date: Thu, 15 Aug 2019 15:09:28 +0530
Subject: [PATCH] Trial 10

---
 testsuites/psxtests/Makefile.am  |   8 ++
 testsuites/psxtests/configure.ac |   1 +
 testsuites/psxtests/psxfenv01/init.c | 121 +++
 3 files changed, 130 insertions(+)
 create mode 100644 testsuites/psxtests/psxfenv01/init.c

diff --git a/testsuites/psxtests/Makefile.am b/testsuites/psxtests/Makefile.am
index c12b03636d..f6ab42fab5 100755
--- a/testsuites/psxtests/Makefile.am
+++ b/testsuites/psxtests/Makefile.am
@@ -415,6 +415,14 @@ psxfchx01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxfchx01) \
 	$(support_includes) -I$(top_srcdir)/include
 endif
 
+if TEST_psxfenv01
+psx_tests += psxfenv01
+psxfenv01_SOURCES = psxfenv01/init.c
+psxfenv01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxfenv01) \
+   $(support_includes)
+psxfenv01_LDADD = -lm $(LDADD)
+endif
+
 if TEST_psxfile01
 psx_tests += psxfile01
 psx_screens += psxfile01/psxfile01.scn
diff --git a/testsuites/psxtests/configure.ac b/testsuites/psxtests/configure.ac
index bb44bb8883..92d3543acb 100644
--- a/testsuites/psxtests/configure.ac
+++ b/testsuites/psxtests/configure.ac
@@ -83,6 +83,7 @@ RTEMS_TEST_CHECK([psxenosys])
 RTEMS_TEST_CHECK([psxfatal01])
 RTEMS_TEST_CHECK([psxfatal02])
 RTEMS_TEST_CHECK([psxfchx01])
+RTEMS_TEST_CHECK([psxfenv01])
 RTEMS_TEST_CHECK([psxfile01])
 RTEMS_TEST_CHECK([psxfile02])
 RTEMS_TEST_CHECK([psxfilelock01])
diff --git a/testsuites/psxtests/psxfenv01/init.c b/testsuites/psxtests/psxfenv01/init.c
new file mode 100644
index 00..eae02da22e
--- /dev/null
+++ b/testsuites/psxtests/psxfenv01/init.c
@@ -0,0 +1,121 @@
+/*
+ *  @file
+ *  @brief Test suite for fenv.h methods
+ */
+
+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (C) 2019 Vaibhav Gupta
+ *
+ * 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.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+/* header files are listed in lexical/lexicographical/alphabetical order */
+
+#include 
+#include 
+#include 
+#include/* contains declarations of fenv methods */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#pragma STDC FENV_ACCESS ON
+
+const char rtems_test_name[] = "PSXFENV 01";
+
+/* forward declarations to avoid warnings */
+rtems_task Init(rtems_task_argument ignored);
+
+/* Test Function Begins */
+rtems_task 

Re: LibBSD master vs 5-freebsd12 TI frame buffer patches

2019-08-15 Thread Chris Johns
On 15/8/19 10:36 am, Chris Johns wrote:
> Currently the RSB libbsd package is building and installing LibBSD `master` 
> and
> I was looking to move this to `5-freebsd12` to align it with the needs of a 
> release.

The curl package does not build with 5-freebsd12. It fails a simple link test
during it's configure. I am seeing ..

/opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/rtems-libbsd-vfd86c091b97759106da7355ce1dd81ebe030e285-x86_64-freebsd12.0-1/rtems-libbsd-fd86c091b97759106da7355ce1dd81ebe030e285/build/arm-rtems5-beagleboneblack-default/../../freebsd/sys/vm/uma_core.c:4073:
undefined reference to `atomic_load_long'

This is building the BBB bsp so the latest tools and kernel.

I build this yesterday on MacOS with master without error and it fails on
FreeBSD using 5-freebsd12.

Is something missing or is it something I am doing?

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


Re: [PATCH v2] rtems-record: New program

2019-08-15 Thread Chris Johns
On 15/8/19 5:33 pm, Sebastian Huber wrote:>
> I don't think it is worth to add this switch. 

OK.

> I will work on this program in August and September.
> 

Thank you.

I have no other specific issues with the code.

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


Re: GSoC Final report review

2019-08-15 Thread Christian Mauderer
On 14/08/2019 18:41, Vijay Kumar Banerjee wrote:
> Hello all,
> 
> I have prepared a draft for the GSoC final report. It would be nice to have
> some review on it before I push it to the blog. The google docs link [1]
> contains a paste from the .md file that will be converted to html for the
> blog so the formatting got messed up in the word file and the links are
> also there. If it's difficult to read it this way then I'll post it to
> the blog and
> then make changes according to the review on the blog.
> 
> Note: I haven't added littleVGL port to RSB in this draft. If I complete
> it before deadline, I'll include it in the report. Also, I'll post the
> blog link
> here before submitting to Google, for any last changes needed.
> 
> [1]: 
> https://docs.google.com/document/d/1ZEU3uP1Tx51lnmvwDOZzc861c_YpS6Zu6RsR8jqk56k/edit?usp=sharing
> 
> Thanks,
> Vijay
> 

Hello Vijay,

thanks for already sharing the draft. It's good to have time for review.

I added a number of comments to the document.

Best regards

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

Re: [PATCH v2] rtems-record: New program

2019-08-15 Thread Sebastian Huber
- Am 15. Aug 2019 um 8:26 schrieb Chris Johns chr...@rtems.org:

> On 15/8/19 4:05 pm, Sebastian Huber wrote:
>> - Am 15. Aug 2019 um 2:09 schrieb Chris Johns chr...@rtems.org:
>> 
>>> On 14/8/19 3:19 pm, Sebastian Huber wrote:
 On 14/08/2019 03:57, Chris Johns wrote:
> On 13/8/19 3:10 pm, Sebastian Huber wrote:
>> sorry for the rush,
>
> Sorry for the delay, I have a client demo this week I am helping with.
>
>> but what do you think of this patch?
>
> Why not C++? The rtems-tools repo has strong support for C++ and it 
> brings a
> range of benefits, for example no need to code call handlers at a low 
> level,
> containers so no need for us to include and maintain trace/record/tree.h, 
> and
> more. When I see us adding code like `tree.h` I have in the back of my 
> mind the
> long term support issues it brings while a `std::map` is maintained for 
> us.

 Originally, the program should be able to filter live traces with about 
 20MiB/s.
 The std::map is simply too slow.
>>>
>>> It is difficult to comment without us heading into detail and I do not think
>>> there is any value in doing that.
>>>
 Boost.Intrusive would be an option (it is
 slower than tree.h in my tests too: https://github.com/sebhub/rb-bench). 
 The
 tree.h is a copy from Newlib, so it doesn't introduce new maintenance 
 issues.
 Anyway, for the CTF conversion the map is unnecessary and could be 
 optimized
 away. We didn't had the time to do this in the GSoC project.
>>>
>>> So performance is not an issue here and the code's presence is historical?
>> 
>> Ravindra needs this patch to integrate his work on top of it. I posted this
>> patch on January and at this time using C was not an issue:
>> 
>> https://lists.rtems.org/pipermail/devel/2019-January/024640.html
>> 
> 
> Yes and I am sorry I did not raise this in that specific case.
> 
>> His integration is now blocked because of something he didn't cause.
> 
> Yes and I would to avoid there being a block.
> 
>>>
> GNU projects like gdb and gcc have moved to C++ and of course llvm is C++ 
> and
> this is for good reason. I provide these examples in the hope this does 
> not
> start a C vs C++ debate.
>
>> I would like to
>> integrate the tracing work of the GSoC project and this patch is a 
>> blocking
>> point.
>
> I understand. I am excited by the work that has been done here and what 
> you are
> doing. It is taking all my will power to not read the ARM debug trace 
> section of
> an ARM TRM as I think that hardware is ripe for integration with this 
> code base
> and set of tools. A C++ framework in rtemstoolkit would be really helpful 
> if I
> do as it would grow what we have rather than us collecting isolated C 
> programs.
>
> I also understand and appreciate the limited time we all have so I am 
> happy to
> hear how you see the host side progressing over time and how it fits into 
> our
> ecosystem. I would also like to hear what others think.

 I don't have a problem with C++ in general. However, I don't think that 
 the use
 of C in this small program is a blocking point to integrate the GSoC work.
 This is work in progress anyway. This program only scratches the surface.
>>>
>>> What parts are to be added that depend on this tool? Maybe it would help if 
>>> this
>>> is presented.
>>>
>>> Work in progress pieces are fine if there is a progression however I did 
>>> state
>>> at the start of GSoC we currently use python and C++. I am weary of isolated
>>> tools that become unclear if we need to keep or we can remove after a 
>>> period of
>>> time.
>> 
>> Sorry, but you should have stated that C++ is mandatory a bit earlier.
> 
> I did ...
> 
> https://lists.rtems.org/pipermail/devel/2019-May/025957.html
> 
> There is C code in rtems-tools, ie elftools and bin2c and I am sure there will
> be others. In the case of trace there is a history of C++ and I think this 
> work
> is important enough that we consider the long term use cases. I have attempted
> to avoid stating C++ is mandatory because that places us in a corner.
> 
>> Now it is difficult to change. Ravindra did his work on top of a C program. 
>> We
>> can easily convert it to C++, but only after the integration of Ravindra's
>> work. The tool is already useful, it converts the RTEMS record stream into a
>> CTF stream which can be read by Trace Compass to display the thread switches 
>> on
>> multiple CPUs and the CPU utilization.
> 
> Great. This is all I am asking for. I would prefer we resolve what happens
> before we merge and we avoid a misunderstanding.

My approach would be to merge it as is. I can then simplify it and remove the 
tree.h. Currently, the tool merges record items streams per-CPU into one 
ordered record stream, then this merged stream is again 

Re: [PATCH] user/index: Add myself to the list of copyrights

2019-08-15 Thread Christian Mauderer
Thanks. I just pushed it.

On 13/08/2019 10:15, Vijay Kumar Banerjee wrote:
> ---
>  user/index.rst | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/user/index.rst b/user/index.rst
> index eff85f3..0e644c9 100644
> --- a/user/index.rst
> +++ b/user/index.rst
> @@ -10,6 +10,7 @@ RTEMS User Manual (|version|).
>  
>  .. topic:: Copyrights and License
>  
> +| |copy| 2019 Vijay Kumar Banerjee
>  | |copy| 2018 Amaan Cheval
>  | |copy| 2018 Marçal Comajoan Cara
>  | |copy| 2018 Vidushi Vashishth
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS 5 gcc-fb371a33fa6 vs gcc-9.2.0

2019-08-15 Thread Chris Johns
On 15/8/19 4:10 pm, Sebastian Huber wrote:
> - Am 15. Aug 2019 um 0:43 schrieb Chris Johns chr...@rtems.org:
> 
>> On 14/8/19 5:38 pm, Sebastian Huber wrote:
>>> On 14/08/2019 09:25, Sebastian Huber wrote:

 On 14/08/2019 09:09, Chris Johns wrote:
> On 14/8/19 4:52 pm, Sebastian Huber wrote:
>> On 14/08/2019 08:52, Chris Johns wrote:
> [...]
>> 4. Update the ARM BSPs to use the new machine options.
> Is there something that documents the changes we need to make?

 No, you have to compare the multilib configurations in GCC 7 and 9.
>>
>> I was after something that says change `xxx` to `yyy`. I am happy to do the
>> change, I do not have the time to figure which options are which.
> 
> I can do that. I don't know the mapping off hand. I have to look at the new 
> multilib options.
> 

Thank you, I would feel more comfortable following your lead.

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


Re: [PATCH v2] rtems-record: New program

2019-08-15 Thread Chris Johns



On 15/8/19 4:05 pm, Sebastian Huber wrote:
> - Am 15. Aug 2019 um 2:09 schrieb Chris Johns chr...@rtems.org:
> 
>> On 14/8/19 3:19 pm, Sebastian Huber wrote:
>>> On 14/08/2019 03:57, Chris Johns wrote:
 On 13/8/19 3:10 pm, Sebastian Huber wrote:
> sorry for the rush,

 Sorry for the delay, I have a client demo this week I am helping with.

> but what do you think of this patch?

 Why not C++? The rtems-tools repo has strong support for C++ and it brings 
 a
 range of benefits, for example no need to code call handlers at a low 
 level,
 containers so no need for us to include and maintain trace/record/tree.h, 
 and
 more. When I see us adding code like `tree.h` I have in the back of my 
 mind the
 long term support issues it brings while a `std::map` is maintained for us.
>>>
>>> Originally, the program should be able to filter live traces with about 
>>> 20MiB/s.
>>> The std::map is simply too slow.
>>
>> It is difficult to comment without us heading into detail and I do not think
>> there is any value in doing that.
>>
>>> Boost.Intrusive would be an option (it is
>>> slower than tree.h in my tests too: https://github.com/sebhub/rb-bench). The
>>> tree.h is a copy from Newlib, so it doesn't introduce new maintenance 
>>> issues.
>>> Anyway, for the CTF conversion the map is unnecessary and could be optimized
>>> away. We didn't had the time to do this in the GSoC project.
>>
>> So performance is not an issue here and the code's presence is historical?
> 
> Ravindra needs this patch to integrate his work on top of it. I posted this 
> patch on January and at this time using C was not an issue:
> 
> https://lists.rtems.org/pipermail/devel/2019-January/024640.html
> 

Yes and I am sorry I did not raise this in that specific case.

> His integration is now blocked because of something he didn't cause.

Yes and I would to avoid there being a block.

>>
 GNU projects like gdb and gcc have moved to C++ and of course llvm is C++ 
 and
 this is for good reason. I provide these examples in the hope this does not
 start a C vs C++ debate.

> I would like to
> integrate the tracing work of the GSoC project and this patch is a 
> blocking
> point.

 I understand. I am excited by the work that has been done here and what 
 you are
 doing. It is taking all my will power to not read the ARM debug trace 
 section of
 an ARM TRM as I think that hardware is ripe for integration with this code 
 base
 and set of tools. A C++ framework in rtemstoolkit would be really helpful 
 if I
 do as it would grow what we have rather than us collecting isolated C 
 programs.

 I also understand and appreciate the limited time we all have so I am 
 happy to
 hear how you see the host side progressing over time and how it fits into 
 our
 ecosystem. I would also like to hear what others think.
>>>
>>> I don't have a problem with C++ in general. However, I don't think that the 
>>> use
>>> of C in this small program is a blocking point to integrate the GSoC work.
>>> This is work in progress anyway. This program only scratches the surface.
>>
>> What parts are to be added that depend on this tool? Maybe it would help if 
>> this
>> is presented.
>>
>> Work in progress pieces are fine if there is a progression however I did 
>> state
>> at the start of GSoC we currently use python and C++. I am weary of isolated
>> tools that become unclear if we need to keep or we can remove after a period 
>> of
>> time.
> 
> Sorry, but you should have stated that C++ is mandatory a bit earlier.

I did ...

 https://lists.rtems.org/pipermail/devel/2019-May/025957.html

There is C code in rtems-tools, ie elftools and bin2c and I am sure there will
be others. In the case of trace there is a history of C++ and I think this work
is important enough that we consider the long term use cases. I have attempted
to avoid stating C++ is mandatory because that places us in a corner.

> Now it is difficult to change. Ravindra did his work on top of a C program. 
> We can easily convert it to C++, but only after the integration of Ravindra's 
> work. The tool is already useful, it converts the RTEMS record stream into a 
> CTF stream which can be read by Trace Compass to display the thread switches 
> on multiple CPUs and the CPU utilization.

Great. This is all I am asking for. I would prefer we resolve what happens
before we merge and we avoid a misunderstanding.

>> Tools added to rtems-tools and installed are public facing user interfaces to
>> our users. By installing the RTEMS project is agreeing to provide and support
>> the interface provided. I am fine with tools being add if they serve other
>> roles, for example as a means to test rtemstoolkit code, ie regression and
>> development test tools. It is unclear to me where this tool fits.
>>
>> Maybe we need an option to rtems-tools's 

Re: SPE Support

2019-08-15 Thread Sebastian Huber
- Am 15. Aug 2019 um 0:55 schrieb joel j...@rtems.org:

> Hi
> 
> Just thinking out loud.
> 
> If the SPE continues to be supported by GCC, why can't we just have
> spe as a separate CPU in the tree with all the build infrastructure
> just reference PowerPC files as needed in their current location?
> 
> I can see a need to copy/move a bsp.h and perhaps,
> score/cpu/spe/include would have to be populated.
> 
> Just thinking there has to be a relatively straightforward hack to
> make this work.

The GCC powerpcspe target was removed in GCC 9:

https://github.com/RTEMS/gnu-mirror-gcc/commit/b31d0348ddada49453e3edaaf93a423fdc61dc79
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: RTEMS 5 gcc-fb371a33fa6 vs gcc-9.2.0

2019-08-15 Thread Sebastian Huber
- Am 15. Aug 2019 um 0:43 schrieb Chris Johns chr...@rtems.org:

> On 14/8/19 5:38 pm, Sebastian Huber wrote:
>> On 14/08/2019 09:25, Sebastian Huber wrote:
>>>
>>> On 14/08/2019 09:09, Chris Johns wrote:
 On 14/8/19 4:52 pm, Sebastian Huber wrote:
> On 14/08/2019 08:52, Chris Johns wrote:
[...]
> 4. Update the ARM BSPs to use the new machine options.
 Is there something that documents the changes we need to make?
>>>
>>> No, you have to compare the multilib configurations in GCC 7 and 9.
> 
> I was after something that says change `xxx` to `yyy`. I am happy to do the
> change, I do not have the time to figure which options are which.

I can do that. I don't know the mapping off hand. I have to look at the new 
multilib options.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH v2] rtems-record: New program

2019-08-15 Thread Sebastian Huber
- Am 15. Aug 2019 um 2:09 schrieb Chris Johns chr...@rtems.org:

> On 14/8/19 3:19 pm, Sebastian Huber wrote:
>> On 14/08/2019 03:57, Chris Johns wrote:
>>> On 13/8/19 3:10 pm, Sebastian Huber wrote:
 sorry for the rush,
>>>
>>> Sorry for the delay, I have a client demo this week I am helping with.
>>>
 but what do you think of this patch?
>>>
>>> Why not C++? The rtems-tools repo has strong support for C++ and it brings a
>>> range of benefits, for example no need to code call handlers at a low level,
>>> containers so no need for us to include and maintain trace/record/tree.h, 
>>> and
>>> more. When I see us adding code like `tree.h` I have in the back of my mind 
>>> the
>>> long term support issues it brings while a `std::map` is maintained for us.
>> 
>> Originally, the program should be able to filter live traces with about 
>> 20MiB/s.
>> The std::map is simply too slow.
> 
> It is difficult to comment without us heading into detail and I do not think
> there is any value in doing that.
> 
>> Boost.Intrusive would be an option (it is
>> slower than tree.h in my tests too: https://github.com/sebhub/rb-bench). The
>> tree.h is a copy from Newlib, so it doesn't introduce new maintenance issues.
>> Anyway, for the CTF conversion the map is unnecessary and could be optimized
>> away. We didn't had the time to do this in the GSoC project.
> 
> So performance is not an issue here and the code's presence is historical?

Ravindra needs this patch to integrate his work on top of it. I posted this 
patch on January and at this time using C was not an issue:

https://lists.rtems.org/pipermail/devel/2019-January/024640.html

His integration is now blocked because of something he didn't cause.

> 
>>> GNU projects like gdb and gcc have moved to C++ and of course llvm is C++ 
>>> and
>>> this is for good reason. I provide these examples in the hope this does not
>>> start a C vs C++ debate.
>>>
 I would like to
 integrate the tracing work of the GSoC project and this patch is a blocking
 point.
>>>
>>> I understand. I am excited by the work that has been done here and what you 
>>> are
>>> doing. It is taking all my will power to not read the ARM debug trace 
>>> section of
>>> an ARM TRM as I think that hardware is ripe for integration with this code 
>>> base
>>> and set of tools. A C++ framework in rtemstoolkit would be really helpful 
>>> if I
>>> do as it would grow what we have rather than us collecting isolated C 
>>> programs.
>>>
>>> I also understand and appreciate the limited time we all have so I am happy 
>>> to
>>> hear how you see the host side progressing over time and how it fits into 
>>> our
>>> ecosystem. I would also like to hear what others think.
>> 
>> I don't have a problem with C++ in general. However, I don't think that the 
>> use
>> of C in this small program is a blocking point to integrate the GSoC work.
>> This is work in progress anyway. This program only scratches the surface.
> 
> What parts are to be added that depend on this tool? Maybe it would help if 
> this
> is presented.
> 
> Work in progress pieces are fine if there is a progression however I did state
> at the start of GSoC we currently use python and C++. I am weary of isolated
> tools that become unclear if we need to keep or we can remove after a period 
> of
> time.

Sorry, but you should have stated that C++ is mandatory a bit earlier. Now it 
is difficult to change. Ravindra did his work on top of a C program. We can 
easily convert it to C++, but only after the integration of Ravindra's work. 
The tool is already useful, it converts the RTEMS record stream into a CTF 
stream which can be read by Trace Compass to display the thread switches on 
multiple CPUs and the CPU utilization.

> 
> Tools added to rtems-tools and installed are public facing user interfaces to
> our users. By installing the RTEMS project is agreeing to provide and support
> the interface provided. I am fine with tools being add if they serve other
> roles, for example as a means to test rtemstoolkit code, ie regression and
> development test tools. It is unclear to me where this tool fits.
> 
> Maybe we need an option to rtems-tools's configure such as --experimental that
> builds and installs tools that are a work in progress but are not a public
> interface?

Ok, sorry, I should have started with the integration planning of the GSoC work 
a bit earlier.

Ravindara, I added a now branch to your repository:

https://github.com/rmeena840/rtems-tools/tree/ravindra-record-ctf

It is a rebase of your work to the current rtems-tools master with all your 
commits squashed into one.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel