Re: [PATCH v3] tests for fenv.h functions

[Eshan Dhawan]

If you want I would set the case in that manner.

On Thu, Mar 5, 2020 at 12:46 PM Eshan Dhawan 
wrote:

>
>
> On Thu, Mar 5, 2020 at 4:37 AM Gedare Bloom  wrote:
>
>> On Wed, Mar 4, 2020 at 11:12 AM Eshan dhawan 
>> wrote:
>> >
>> > ---
>> >  testsuites/psxtests/psxfenv01/init.c | 72 ++--
>> >  1 file changed, 68 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/testsuites/psxtests/psxfenv01/init.c
>> b/testsuites/psxtests/psxfenv01/init.c
>> > index cdb0fa596e..40c29e4fac 100644
>> > --- a/testsuites/psxtests/psxfenv01/init.c
>> > +++ b/testsuites/psxtests/psxfenv01/init.c
>> > @@ -46,6 +46,10 @@
>> >  #include 
>> >  #include 
>> >  #include 
>> > +#include 
>> I don't think this include is necessary?
>>
>> > +#include 
>> > +
>> > +
>> Don't add extra vertical space unnecessarily. In general, there should
>> never be more than 1 blank line consecutively anywhere.
>> >
>> >  const char rtems_test_name[] = "PSXFENV 01";
>> >
>> > @@ -69,20 +73,23 @@ rtems_task Init(rtems_task_argument ignored)
>> >#ifdef FE_ALL_EXCEPT /* floating-point exceptions */
>> >  puts( "fesetenv(FE_DFL_ENV)." );
>> >  r = fesetenv(FE_DFL_ENV);
>> > -if (r)
>> > +if (r){
>> Almost, need some more spaces around 'r' and between '){', like this:
>> "if ( r ) {"
>>
>> >printf("fesetenv ==> %d\n", r);
>> > +}
>> >  rtems_test_assert( r == 0 );
>> >
>> >  /* Test 'feclearexcept()' and 'fetestexcept()' in one go. */
>> >  puts( "feclearexcept(FE_ALL_EXCEPT)." );
>> >  r = feclearexcept(FE_ALL_EXCEPT);
>> > -if (r)
>> > +if (r){
>> >printf("feclearexcept ==> 0x%x\n", r);
>> > +}
>> >  rtems_test_assert( r == 0 );
>> >
>> >  r = fetestexcept( FE_ALL_EXCEPT );
>> > -if (r)
>> > +if (r){
>> >printf("fetestexcept ==> 0x%x\n", r);
>> > +}
>> >  rtems_test_assert( r == 0 );
>> >
>> >  /* Test 'FE_DIVBYZERO' */
>> > @@ -91,8 +98,63 @@ rtems_task Init(rtems_task_argument ignored)
>> >  b = 1.0;
>> >  c = b/a;
>> >  (void) c;
>> > +/* Test 'fegetexceptflag()' and 'fesetexceptflag()' */
>> > +r = fegetexceptflag(,FE_ALL_EXCEPT);
>> also need to add whitespace after commas.
>>
>> > +if(r){
>> > +  printf("fegetexceptflag ==> 0x%x\n", r);
>> > +}
>> > +rtems_test_assert(r == 0);
>> > +
>> > +r = fesetexceptflag(, FE_ALL_EXCEPT);
>> spaces between ( ).
>> > +if(r){
>> > +  printf("fesetexceptflag ==> 0x%x\n", r);
>> > +}
>> > +rtems_test_assert(r == 0);
>> ditto
>>
>> > +
>> > +
>> 2 blanks
>>
>> > +/* Test for 'fegetround()' and 'fesetround()' */
>> > +/* They have four main macros to be tested seperated by ifdef*/
>> > +/* Since not all architectures support them */
>> > +/* The test case gets and sets the rounding directions */
>> Merge multiline comments with a single comment block
>> /* Test for ...
>>  * They have ...
>>  * Since not ...
>>  * The test case ...
>>  */
>>
>> > +#ifdef FE_TONEAREST
>> > +r = fegetround();
>> > +if(r){
>> > +  printf("fegetround ==> 0x%x\n", r);
>> > +}
>> > +rtems_test_assert(r == FE_TONEAREST) ;
>> Is FE_TONEAREST expected to be the default behavior without any calls
>> to fesetround?
>>
> No, We have to define the rounding direction flag in the function call.
> FE_TONEAREST is the default rounding direction if nothing is specified.
>
>> Why not do something like you did below, with rtems_test_assert(
>> fegetround() == FE_TONEAREST );?
>>
> I have used this way only in this test case because if there is an error
> with fegetround(),
> we could get the error code.
>
>> > +#endif
>> > +#ifdef FE_TOWARDZERO
>> > +  r = fesetround(FE_TOWARDZERO);
>> > +  if(r){
>> > +  printf("fesetround ==> 0x%x\n", r);
>> > +}
>> > +  rtems_test_assert(r == 0) ;
>> > +  rtems_test_assert(fegetround() == FE_TOWARDZERO) ;
>> This is a nice, concise way to test the rounding condition. Why not do
>> the same above with FE_TONEAREST?
>>
>  we wouldn't get any error code sent by the function in this method.
> So, if there is an error in the default then I would want it to be
> displayed.
>
>> > +#endif
>> > +#ifdef FE_DOWNWARD
>> > +  r = fesetround(FE_DOWNWARD);
>> > +  if(r){
>> > +  printf("fesetround ==> 0x%x\n", r);
>> > +}
>> > +  rtems_test_assert(r == 0) ;
>> > +  rtems_test_assert(fegetround() == FE_DOWNWARD) ;
>> > +#endif
>> > +#ifdef FE_UPWARD
>> > +  r = fesetround(FE_UPWARD);
>> > +  if(r){
>> > +  printf("fesetround ==> 0x%x\n", r);
>> > +}
>> > +  rtems_test_assert(r == 0) ;
>> > +  rtems_test_assert(fegetround() == FE_UPWARD) ;
>> > +#endif
>> > +#ifdef FE_TONEAREST
>> > +  r = fesetround(FE_TONEAREST);
>> > +  if(r){
>> > +  printf("fesetround ==> 0x%x\n", r);
>> > +}
>> > +  rtems_test_assert(r == 0) ;
>> > +#endif
>> >
>> > -fegetexceptflag(,FE_ALL_EXCEPT);
>> >
>> >  #ifdef FE_DIVBYZERO
>> >  r = feraiseexcept(FE_DIVBYZERO);
>> > @@ -125,3 +187,5 @@ 

Re: [PATCH 4/4] Add print statement similar to the original mkimage.

[Amar Takhar]

On 2020-03-04 19:43 -0700, Gedare Bloom wrote:
> Reviewing on my phone: I see added blank lines, try to avoid unnecessary
> whitespace/format changes with functional changes in same commit. Although we
> haven't settled in a style, none of the proposed ones use more than 2 blank
> lines between global definitions.

Yes, those should not have made it in.  My whitespace changes were a separate 
commit.

Thank you.


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

Re: [PATCH 2/4] Convert optparse to argparse.

[Amar Takhar]

On 2020-03-04 19:37 -0700, Gedare Bloom wrote:
> Quick note sort copyright lines??earlier years below later years.

Whoops, I know this already I'll fix it thanks.


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

Re: [PATCH 4/4] Add print statement similar to the original mkimage.

[Gedare Bloom]

Reviewing on my phone: I see added blank lines, try to avoid unnecessary
whitespace/format changes with functional changes in same commit. Although
we haven't settled in a style, none of the proposed ones use more than 2
blank lines between global definitions.

On Wed, Mar 4, 2020, 4:10 PM Amar Takhar  wrote:

> This is limited to Python 2.6+
> ---
>  misc/tools/mkimage.py | 17 +++--
>  1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/misc/tools/mkimage.py b/misc/tools/mkimage.py
> index 38ed11e..fd75f0a 100755
> --- a/misc/tools/mkimage.py
> +++ b/misc/tools/mkimage.py
> @@ -27,6 +27,8 @@
>  # ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
> THE
>  # POSSIBILITY OF SUCH DAMAGE.
>
> +# We support Python 2.6+ so this is okay.
> +from __future__ import print_function
>
>  import argparse
>  from struct import *
> @@ -35,6 +37,8 @@ import os.path
>  import time
>  import binascii
>
> +
> +
>  MAGIC = 0x27051956
>  IMG_NAME_LENGTH = 32
>
> @@ -125,14 +129,16 @@ while True:
>
>  inputcrc = inputcrc & 0x
>
> -structdata = struct.pack(MAGIC, 0, int(time.time()), inputsize,
> +timestamp = int(time.time())
> +
> +structdata = struct.pack(MAGIC, 0, timestamp, inputsize,
>  int(options.addr,16), int(options.ep,16), inputcrc,
>  oss[options.os], archs[options.arch], types[options.type],
>  comps[options.comp], options.name.encode("utf-8"))
>
>  headercrc = binascii.crc32(structdata) & 0x
>
> -structdata =  struct.pack(MAGIC, headercrc, int(time.time()), inputsize,
> +structdata =  struct.pack(MAGIC, headercrc, timestamp, inputsize,
>  int(options.addr,16), int(options.ep,16), inputcrc,
>  oss[options.os], archs[options.arch], types[options.type],
>  comps[options.comp], options.name.encode("utf-8"))
> @@ -141,3 +147,10 @@ outputfile.seek(0)
>  outputfile.write(structdata)
>  outputfile.close()
>  inputfile.close()
> +
> +print("Image Name:   ", options.name)
> +print("Created:  ", time.ctime(timestamp))
> +print("Image Type:   ", options.comp)
> +print("Data Size:", inputsize)
> +print("Load Address: ", options.addr)
> +print("Entry Point:  ", options.ep)
> --
> 2.25.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 2/4] Convert optparse to argparse.

[Gedare Bloom]

Quick note sort copyright lines earlier years below later years.

On Wed, Mar 4, 2020, 4:09 PM Amar Takhar  wrote:

>  * Fix exceptions and print exception message.
>  * Also add myself to copyright.
> ---
>  misc/tools/mkimage.py | 42 ++
>  1 file changed, 22 insertions(+), 20 deletions(-)
>
> diff --git a/misc/tools/mkimage.py b/misc/tools/mkimage.py
> index 2b1524c..0845ee4 100755
> --- a/misc/tools/mkimage.py
> +++ b/misc/tools/mkimage.py
> @@ -3,6 +3,7 @@
>  # A quickly bashed together replacement for u-boot's mkimage written in
> python
>  #
>  # Copyright 2010 Craig Barker
> +# Copyright 2020 Amar Takhar 
>  #
>  # Redistribution and use in source and binary forms, with or without
>  # modification, are permitted provided that the following conditions are
> met:
> @@ -27,7 +28,7 @@
>  # POSSIBILITY OF SUCH DAMAGE.
>
>
> -from optparse import OptionParser
> +import argparse
>  from struct import *
>  import sys
>  import os.path
> @@ -53,30 +54,31 @@ types = {'invalid':0, 'standalone':1, 'kernel':2,
> 'ramdisk':3, 'multi':4,
>
>  comps = {'none':0, 'bzip2':2, 'gzip':1, 'lzma':3 }
>
> -usage = "usage: %prog [options] image"
> -parser = OptionParser(usage=usage)
> -parser.add_option("-A","--arch", dest="arch", default="powerpc",
> +parser = argparse.ArgumentParser()
> +
> +parser.add_argument("-A","--arch", dest="arch", default="powerpc",
>help="set architecture to 'arch'", metavar="ARCH")
> -parser.add_option("-O","--os", dest="os", default="linux",
> +parser.add_argument("-O","--os", dest="os", default="linux",
>help="set operating system to 'os'", metavar="OS")
> -parser.add_option("-T","--type", dest="type", default="kernel",
> +parser.add_argument("-T","--type", dest="type", default="kernel",
>help="set image type to 'type'", metavar="TYPE")
> -parser.add_option("-C","--comp", dest="comp", default="gzip",
> +parser.add_argument("-C","--comp", dest="comp", default="gzip",
>help="set compression type 'comp'", metavar="COMP")
> -parser.add_option("-a","--addr", dest="addr", default="0",
> +parser.add_argument("-a","--addr", dest="addr", default="0",
>help="set load address to 'addr' (hex)", metavar="ADDR")
> -parser.add_option("-e","--ep", dest="ep", default="0",
> +parser.add_argument("-e","--ep", dest="ep", default="0",
>help="set entry point to 'ep' (hex)", metavar="EP")
> -parser.add_option("-n","--name", dest="name", default="",
> +parser.add_argument("-n","--name", dest="name", default="",
>help="set image name to 'name'", metavar="NAME")
> -parser.add_option("-d","--datafile", dest="datafile",
> -  help="use image data from 'datafile'",
> metavar="DATAFILE")
> -parser.add_option("-x","--xip", action="store_true", dest="xip",
> default=False,
> +parser.add_argument("-d","--datafile", dest="datafile",
> +  help="use image data from 'datafile'",
> metavar="DATAFILE", required=True)
> +parser.add_argument("-x","--xip", action="store_true", dest="xip",
> default=False,
>help="set XIP (execute in place)")
> +parser.add_argument("outputfile",
> +  help="Output file.", metavar="OUTPUTFILE")
>
> -(options, args) = parser.parse_args()
>
> -if len(args) != 1: parser.print_help()
> +options = parser.parse_args()
>
>  if options.arch not in archs:
>  print "Invalid architecture specified, aborting"
> @@ -98,15 +100,15 @@ try:
>  inputsize = os.path.getsize(options.datafile)
>  inputfile = open(options.datafile, 'rb')
>
> -except IOError:
> -print "Invalid datafile specified, aborting"
> +except OSError as e:
> +print "Invalid datafile specified, aborting: %s" % e
>  sys.exit(2)
>
>  try:
> -outputfile = open(args[0],'wb')
> +outputfile = open(options.outputfile,'wb')
>
> -except IOError:
> -print "Error opening output file for writing, aborting"
> +except IOError as e:
> +print "Error opening output file for writing, aborting: %s" % e
>  sys.exit(1)
>
>  struct = Struct("!III"+str(IMG_NAME_LENGTH)+"s")
> --
> 2.25.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] Bump RSB to the latest rtems-tools to get mkimage.py

[Amar Takhar]

On 2020-03-04 18:02 -0600, Joel Sherrill wrote:
> I think this is OK.??
> 
> I will bump the newlib hash as soon as my patch to newlib is merged.

Great, thanks!


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

Re: [PATCH] Bump RSB to the latest rtems-tools to get mkimage.py

[Joel Sherrill]

I think this is OK.

I will bump the newlib hash as soon as my patch to newlib is merged.

--joel

On Wed, Mar 4, 2020 at 6:01 PM Amar Takhar  wrote:

> ---
>  rtems/config/tools/rtems-tools-5-1.cfg | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/rtems/config/tools/rtems-tools-5-1.cfg
> b/rtems/config/tools/rtems-tools-5-1.cfg
> index da22b4c..0c67901 100644
> --- a/rtems/config/tools/rtems-tools-5-1.cfg
> +++ b/rtems/config/tools/rtems-tools-5-1.cfg
> @@ -10,14 +10,14 @@
>   %define rtems_tools_source rtems-tools-%{rtems_tools_version}
>   %define rtems_tools_ext xz
>  %else
> - %define rtems_tools_version 4a2f3e5a58978458aabb5098c2c9dd0cc6d25c68
> + %define rtems_tools_version 2444acb0ad35d9f6abd7cf0c1ed8e18a7546a4f6
>   %define rtems_tools_ext bz2
>  %endif
>
>  %define rtems_tools_source rtems-tools-%{rtems_tools_version}
>  %source set rtems-tools
> https://git.rtems.org/rtems-tools/snapshot/%{rtems_tools_source}.tar.%{rtems_tools_ext}
>  %hash   sha512 rtems-tools-%{rtems_tools_version}.tar.bz2 \
> -
>  
> 273a517be396823bec1e9ff5faf52db5f39e4901d8f9bc9fa4724f883a3683ffe2e51004df00bf205b8461f662902d4f1043026bbd88bdd2e2badd0bb0dd8425
> +
>  
> 59ed8573b250356f0bb5ac3810f228426855bc916fb0ede1e8d2b67556267e062fcc92e0bbed7967fdcd546d39d0ef220e5c681f4c5821d3db58b335b696
>
>  #
>  # Optionally enable/disable building the RTEMS Tools via the command line.
> --
> 2.25.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

[PATCH] Bump RSB to the latest rtems-tools to get mkimage.py

[Amar Takhar]

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

diff --git a/rtems/config/tools/rtems-tools-5-1.cfg 
b/rtems/config/tools/rtems-tools-5-1.cfg
index da22b4c..0c67901 100644
--- a/rtems/config/tools/rtems-tools-5-1.cfg
+++ b/rtems/config/tools/rtems-tools-5-1.cfg
@@ -10,14 +10,14 @@
  %define rtems_tools_source rtems-tools-%{rtems_tools_version}
  %define rtems_tools_ext xz
 %else
- %define rtems_tools_version 4a2f3e5a58978458aabb5098c2c9dd0cc6d25c68
+ %define rtems_tools_version 2444acb0ad35d9f6abd7cf0c1ed8e18a7546a4f6
  %define rtems_tools_ext bz2
 %endif
 
 %define rtems_tools_source rtems-tools-%{rtems_tools_version}
 %source set rtems-tools 
https://git.rtems.org/rtems-tools/snapshot/%{rtems_tools_source}.tar.%{rtems_tools_ext}
 %hash   sha512 rtems-tools-%{rtems_tools_version}.tar.bz2 \
- 
273a517be396823bec1e9ff5faf52db5f39e4901d8f9bc9fa4724f883a3683ffe2e51004df00bf205b8461f662902d4f1043026bbd88bdd2e2badd0bb0dd8425
+ 
59ed8573b250356f0bb5ac3810f228426855bc916fb0ede1e8d2b67556267e062fcc92e0bbed7967fdcd546d39d0ef220e5c681f4c5821d3db58b335b696
 
 #
 # Optionally enable/disable building the RTEMS Tools via the command line.
-- 
2.25.0

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

Re: [PATCH 1/4] Remove EOL whitespace.

[Chris Johns]

I am ok for these to be pushed. Thank you for adding this command. It is a big
help for hosts that are not Linux.

Please consider a change to update the RSB's tool commit reference and checksum
as approved. The file is ...

https://git.rtems.org/rtems-source-builder/tree/rtems/config/tools/rtems-tools-5-1.cfg

Chris

On 5/3/20 10:09 am, Amar Takhar wrote:
> ---
>  misc/tools/mkimage.py | 42 +-
>  1 file changed, 21 insertions(+), 21 deletions(-)
> 
> diff --git a/misc/tools/mkimage.py b/misc/tools/mkimage.py
> index 39a12a0..2b1524c 100755
> --- a/misc/tools/mkimage.py
> +++ b/misc/tools/mkimage.py
> @@ -2,28 +2,28 @@
>  
>  # A quickly bashed together replacement for u-boot's mkimage written in 
> python
>  #
> -# Copyright 2010 Craig Barker 
> +# Copyright 2010 Craig Barker
>  #
> -# Redistribution and use in source and binary forms, with or without 
> +# 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, 
> +# 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 HOLDER 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 
> +# 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 HOLDER 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.
>  
>  
> @@ -55,7 +55,7 @@ comps = {'none':0, 'bzip2':2, 'gzip':1, 'lzma':3 }
>  
>  usage = "usage: %prog [options] image"
>  parser = OptionParser(usage=usage)
> -parser.add_option("-A","--arch", dest="arch", default="powerpc", 
> +parser.add_option("-A","--arch", dest="arch", default="powerpc",
>help="set architecture to 'arch'", metavar="ARCH")
>  parser.add_option("-O","--os", dest="os", default="linux",
>help="set operating system to 'os'", metavar="OS")
> @@ -78,21 +78,21 @@ parser.add_option("-x","--xip", action="store_true", 
> dest="xip", default=False,
>  
>  if len(args) != 1: parser.print_help()
>  
> -if options.arch not in archs: 
> +if options.arch not in archs:
>  print "Invalid architecture specified, aborting"
>  sys.exit(2)
>  
>  if options.os not in oss:
>  print "Invalid operating system specified, aborting"
> -sys.exit(2) 
> +sys.exit(2)
>  
>  if options.comp not in comps:
>  print "Invalid compression specified, aborting"
> -sys.exit(2) 
> +sys.exit(2)
>  
>  if options.type not in types:
>  print "Invalid image type specified, aborting"
> -sys.exit(2) 
> +sys.exit(2)
>  
>  try:
>  inputsize = os.path.getsize(options.datafile)
> @@ -123,9 +123,9 @@ while True:
>  
>  inputcrc = inputcrc & 0x
>  
> -structdata = struct.pack(MAGIC, 0, int(time.time()), inputsize, 
> -int(options.addr,16), int(options.ep,16), inputcrc, 
> -oss[options.os], archs[options.arch], types[options.type], 
> +structdata = struct.pack(MAGIC, 0, int(time.time()), inputsize,
> +int(options.addr,16), int(options.ep,16), inputcrc,
> +oss[options.os], archs[options.arch], types[options.type],
>  comps[options.comp], 

[PATCH 1/4] Remove EOL whitespace.

[Amar Takhar]

---
 misc/tools/mkimage.py | 42 +-
 1 file changed, 21 insertions(+), 21 deletions(-)

diff --git a/misc/tools/mkimage.py b/misc/tools/mkimage.py
index 39a12a0..2b1524c 100755
--- a/misc/tools/mkimage.py
+++ b/misc/tools/mkimage.py
@@ -2,28 +2,28 @@
 
 # A quickly bashed together replacement for u-boot's mkimage written in python
 #
-# Copyright 2010 Craig Barker 
+# Copyright 2010 Craig Barker
 #
-# Redistribution and use in source and binary forms, with or without 
+# 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, 
+# 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 HOLDER 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 
+# 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 HOLDER 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.
 
 
@@ -55,7 +55,7 @@ comps = {'none':0, 'bzip2':2, 'gzip':1, 'lzma':3 }
 
 usage = "usage: %prog [options] image"
 parser = OptionParser(usage=usage)
-parser.add_option("-A","--arch", dest="arch", default="powerpc", 
+parser.add_option("-A","--arch", dest="arch", default="powerpc",
   help="set architecture to 'arch'", metavar="ARCH")
 parser.add_option("-O","--os", dest="os", default="linux",
   help="set operating system to 'os'", metavar="OS")
@@ -78,21 +78,21 @@ parser.add_option("-x","--xip", action="store_true", 
dest="xip", default=False,
 
 if len(args) != 1: parser.print_help()
 
-if options.arch not in archs: 
+if options.arch not in archs:
 print "Invalid architecture specified, aborting"
 sys.exit(2)
 
 if options.os not in oss:
 print "Invalid operating system specified, aborting"
-sys.exit(2) 
+sys.exit(2)
 
 if options.comp not in comps:
 print "Invalid compression specified, aborting"
-sys.exit(2) 
+sys.exit(2)
 
 if options.type not in types:
 print "Invalid image type specified, aborting"
-sys.exit(2) 
+sys.exit(2)
 
 try:
 inputsize = os.path.getsize(options.datafile)
@@ -123,9 +123,9 @@ while True:
 
 inputcrc = inputcrc & 0x
 
-structdata = struct.pack(MAGIC, 0, int(time.time()), inputsize, 
-int(options.addr,16), int(options.ep,16), inputcrc, 
-oss[options.os], archs[options.arch], types[options.type], 
+structdata = struct.pack(MAGIC, 0, int(time.time()), inputsize,
+int(options.addr,16), int(options.ep,16), inputcrc,
+oss[options.os], archs[options.arch], types[options.type],
 comps[options.comp], options.name)
 
 headercrc = binascii.crc32(structdata) & 0x
-- 
2.25.0

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

[PATCH 3/4] Fix to work under Pyhon 2 and Python 3.

[Amar Takhar]

Also changed 'python2' to 'python' in the shebang.
---
 misc/tools/mkimage.py | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/misc/tools/mkimage.py b/misc/tools/mkimage.py
index 0845ee4..38ed11e 100755
--- a/misc/tools/mkimage.py
+++ b/misc/tools/mkimage.py
@@ -1,4 +1,4 @@
-#!/usr/bin/env python2
+#!/usr/bin/env python
 
 # A quickly bashed together replacement for u-boot's mkimage written in python
 #
@@ -81,19 +81,19 @@ parser.add_argument("outputfile",
 options = parser.parse_args()
 
 if options.arch not in archs:
-print "Invalid architecture specified, aborting"
+print("Invalid architecture specified, aborting")
 sys.exit(2)
 
 if options.os not in oss:
-print "Invalid operating system specified, aborting"
+print("Invalid operating system specified, aborting")
 sys.exit(2)
 
 if options.comp not in comps:
-print "Invalid compression specified, aborting"
+print("Invalid compression specified, aborting")
 sys.exit(2)
 
 if options.type not in types:
-print "Invalid image type specified, aborting"
+print("Invalid image type specified, aborting")
 sys.exit(2)
 
 try:
@@ -101,14 +101,14 @@ try:
 inputfile = open(options.datafile, 'rb')
 
 except OSError as e:
-print "Invalid datafile specified, aborting: %s" % e
+print("Invalid datafile specified, aborting: %s" % e)
 sys.exit(2)
 
 try:
 outputfile = open(options.outputfile,'wb')
 
 except IOError as e:
-print "Error opening output file for writing, aborting: %s" % e
+print("Error opening output file for writing, aborting: %s" % e)
 sys.exit(1)
 
 struct = Struct("!III"+str(IMG_NAME_LENGTH)+"s")
@@ -128,14 +128,14 @@ inputcrc = inputcrc & 0x
 structdata = struct.pack(MAGIC, 0, int(time.time()), inputsize,
 int(options.addr,16), int(options.ep,16), inputcrc,
 oss[options.os], archs[options.arch], types[options.type],
-comps[options.comp], options.name)
+comps[options.comp], options.name.encode("utf-8"))
 
 headercrc = binascii.crc32(structdata) & 0x
 
 structdata =  struct.pack(MAGIC, headercrc, int(time.time()), inputsize,
 int(options.addr,16), int(options.ep,16), inputcrc,
 oss[options.os], archs[options.arch], types[options.type],
-comps[options.comp], options.name)
+comps[options.comp], options.name.encode("utf-8"))
 
 outputfile.seek(0)
 outputfile.write(structdata)
-- 
2.25.0

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

[PATCH 2/4] Convert optparse to argparse.

[Amar Takhar]

 * Fix exceptions and print exception message.
 * Also add myself to copyright.
---
 misc/tools/mkimage.py | 42 ++
 1 file changed, 22 insertions(+), 20 deletions(-)

diff --git a/misc/tools/mkimage.py b/misc/tools/mkimage.py
index 2b1524c..0845ee4 100755
--- a/misc/tools/mkimage.py
+++ b/misc/tools/mkimage.py
@@ -3,6 +3,7 @@
 # A quickly bashed together replacement for u-boot's mkimage written in python
 #
 # Copyright 2010 Craig Barker
+# Copyright 2020 Amar Takhar 
 #
 # Redistribution and use in source and binary forms, with or without
 # modification, are permitted provided that the following conditions are met:
@@ -27,7 +28,7 @@
 # POSSIBILITY OF SUCH DAMAGE.
 
 
-from optparse import OptionParser
+import argparse
 from struct import *
 import sys
 import os.path
@@ -53,30 +54,31 @@ types = {'invalid':0, 'standalone':1, 'kernel':2, 
'ramdisk':3, 'multi':4,
 
 comps = {'none':0, 'bzip2':2, 'gzip':1, 'lzma':3 }
 
-usage = "usage: %prog [options] image"
-parser = OptionParser(usage=usage)
-parser.add_option("-A","--arch", dest="arch", default="powerpc",
+parser = argparse.ArgumentParser()
+
+parser.add_argument("-A","--arch", dest="arch", default="powerpc",
   help="set architecture to 'arch'", metavar="ARCH")
-parser.add_option("-O","--os", dest="os", default="linux",
+parser.add_argument("-O","--os", dest="os", default="linux",
   help="set operating system to 'os'", metavar="OS")
-parser.add_option("-T","--type", dest="type", default="kernel",
+parser.add_argument("-T","--type", dest="type", default="kernel",
   help="set image type to 'type'", metavar="TYPE")
-parser.add_option("-C","--comp", dest="comp", default="gzip",
+parser.add_argument("-C","--comp", dest="comp", default="gzip",
   help="set compression type 'comp'", metavar="COMP")
-parser.add_option("-a","--addr", dest="addr", default="0",
+parser.add_argument("-a","--addr", dest="addr", default="0",
   help="set load address to 'addr' (hex)", metavar="ADDR")
-parser.add_option("-e","--ep", dest="ep", default="0",
+parser.add_argument("-e","--ep", dest="ep", default="0",
   help="set entry point to 'ep' (hex)", metavar="EP")
-parser.add_option("-n","--name", dest="name", default="",
+parser.add_argument("-n","--name", dest="name", default="",
   help="set image name to 'name'", metavar="NAME")
-parser.add_option("-d","--datafile", dest="datafile",
-  help="use image data from 'datafile'", metavar="DATAFILE")
-parser.add_option("-x","--xip", action="store_true", dest="xip", default=False,
+parser.add_argument("-d","--datafile", dest="datafile",
+  help="use image data from 'datafile'", metavar="DATAFILE", 
required=True)
+parser.add_argument("-x","--xip", action="store_true", dest="xip", 
default=False,
   help="set XIP (execute in place)")
+parser.add_argument("outputfile",
+  help="Output file.", metavar="OUTPUTFILE")
 
-(options, args) = parser.parse_args()
 
-if len(args) != 1: parser.print_help()
+options = parser.parse_args()
 
 if options.arch not in archs:
 print "Invalid architecture specified, aborting"
@@ -98,15 +100,15 @@ try:
 inputsize = os.path.getsize(options.datafile)
 inputfile = open(options.datafile, 'rb')
 
-except IOError:
-print "Invalid datafile specified, aborting"
+except OSError as e:
+print "Invalid datafile specified, aborting: %s" % e
 sys.exit(2)
 
 try:
-outputfile = open(args[0],'wb')
+outputfile = open(options.outputfile,'wb')
 
-except IOError:
-print "Error opening output file for writing, aborting"
+except IOError as e:
+print "Error opening output file for writing, aborting: %s" % e
 sys.exit(1)
 
 struct = Struct("!III"+str(IMG_NAME_LENGTH)+"s")
-- 
2.25.0

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

[PATCH 4/4] Add print statement similar to the original mkimage.

[Amar Takhar]

This is limited to Python 2.6+
---
 misc/tools/mkimage.py | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/misc/tools/mkimage.py b/misc/tools/mkimage.py
index 38ed11e..fd75f0a 100755
--- a/misc/tools/mkimage.py
+++ b/misc/tools/mkimage.py
@@ -27,6 +27,8 @@
 # ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 # POSSIBILITY OF SUCH DAMAGE.
 
+# We support Python 2.6+ so this is okay.
+from __future__ import print_function
 
 import argparse
 from struct import *
@@ -35,6 +37,8 @@ import os.path
 import time
 import binascii
 
+
+
 MAGIC = 0x27051956
 IMG_NAME_LENGTH = 32
 
@@ -125,14 +129,16 @@ while True:
 
 inputcrc = inputcrc & 0x
 
-structdata = struct.pack(MAGIC, 0, int(time.time()), inputsize,
+timestamp = int(time.time())
+
+structdata = struct.pack(MAGIC, 0, timestamp, inputsize,
 int(options.addr,16), int(options.ep,16), inputcrc,
 oss[options.os], archs[options.arch], types[options.type],
 comps[options.comp], options.name.encode("utf-8"))
 
 headercrc = binascii.crc32(structdata) & 0x
 
-structdata =  struct.pack(MAGIC, headercrc, int(time.time()), inputsize,
+structdata =  struct.pack(MAGIC, headercrc, timestamp, inputsize,
 int(options.addr,16), int(options.ep,16), inputcrc,
 oss[options.os], archs[options.arch], types[options.type],
 comps[options.comp], options.name.encode("utf-8"))
@@ -141,3 +147,10 @@ outputfile.seek(0)
 outputfile.write(structdata)
 outputfile.close()
 inputfile.close()
+
+print("Image Name:   ", options.name)
+print("Created:  ", time.ctime(timestamp))
+print("Image Type:   ", options.comp)
+print("Data Size:", inputsize)
+print("Load Address: ", options.addr)
+print("Entry Point:  ", options.ep)
-- 
2.25.0

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

Re: [PATCH v3] tests for fenv.h functions

[Gedare Bloom]

On Wed, Mar 4, 2020 at 11:12 AM Eshan dhawan  wrote:
>
> ---
>  testsuites/psxtests/psxfenv01/init.c | 72 ++--
>  1 file changed, 68 insertions(+), 4 deletions(-)
>
> diff --git a/testsuites/psxtests/psxfenv01/init.c 
> b/testsuites/psxtests/psxfenv01/init.c
> index cdb0fa596e..40c29e4fac 100644
> --- a/testsuites/psxtests/psxfenv01/init.c
> +++ b/testsuites/psxtests/psxfenv01/init.c
> @@ -46,6 +46,10 @@
>  #include 
>  #include 
>  #include 
> +#include 
I don't think this include is necessary?

> +#include 
> +
> +
Don't add extra vertical space unnecessarily. In general, there should
never be more than 1 blank line consecutively anywhere.
>
>  const char rtems_test_name[] = "PSXFENV 01";
>
> @@ -69,20 +73,23 @@ rtems_task Init(rtems_task_argument ignored)
>#ifdef FE_ALL_EXCEPT /* floating-point exceptions */
>  puts( "fesetenv(FE_DFL_ENV)." );
>  r = fesetenv(FE_DFL_ENV);
> -if (r)
> +if (r){
Almost, need some more spaces around 'r' and between '){', like this:
"if ( r ) {"

>printf("fesetenv ==> %d\n", r);
> +}
>  rtems_test_assert( r == 0 );
>
>  /* Test 'feclearexcept()' and 'fetestexcept()' in one go. */
>  puts( "feclearexcept(FE_ALL_EXCEPT)." );
>  r = feclearexcept(FE_ALL_EXCEPT);
> -if (r)
> +if (r){
>printf("feclearexcept ==> 0x%x\n", r);
> +}
>  rtems_test_assert( r == 0 );
>
>  r = fetestexcept( FE_ALL_EXCEPT );
> -if (r)
> +if (r){
>printf("fetestexcept ==> 0x%x\n", r);
> +}
>  rtems_test_assert( r == 0 );
>
>  /* Test 'FE_DIVBYZERO' */
> @@ -91,8 +98,63 @@ rtems_task Init(rtems_task_argument ignored)
>  b = 1.0;
>  c = b/a;
>  (void) c;
> +/* Test 'fegetexceptflag()' and 'fesetexceptflag()' */
> +r = fegetexceptflag(,FE_ALL_EXCEPT);
also need to add whitespace after commas.

> +if(r){
> +  printf("fegetexceptflag ==> 0x%x\n", r);
> +}
> +rtems_test_assert(r == 0);
> +
> +r = fesetexceptflag(, FE_ALL_EXCEPT);
spaces between ( ).
> +if(r){
> +  printf("fesetexceptflag ==> 0x%x\n", r);
> +}
> +rtems_test_assert(r == 0);
ditto

> +
> +
2 blanks

> +/* Test for 'fegetround()' and 'fesetround()' */
> +/* They have four main macros to be tested seperated by ifdef*/
> +/* Since not all architectures support them */
> +/* The test case gets and sets the rounding directions */
Merge multiline comments with a single comment block
/* Test for ...
 * They have ...
 * Since not ...
 * The test case ...
 */

> +#ifdef FE_TONEAREST
> +r = fegetround();
> +if(r){
> +  printf("fegetround ==> 0x%x\n", r);
> +}
> +rtems_test_assert(r == FE_TONEAREST) ;
Is FE_TONEAREST expected to be the default behavior without any calls
to fesetround?
Why not do something like you did below, with rtems_test_assert(
fegetround() == FE_TONEAREST );?
> +#endif
> +#ifdef FE_TOWARDZERO
> +  r = fesetround(FE_TOWARDZERO);
> +  if(r){
> +  printf("fesetround ==> 0x%x\n", r);
> +}
> +  rtems_test_assert(r == 0) ;
> +  rtems_test_assert(fegetround() == FE_TOWARDZERO) ;
This is a nice, concise way to test the rounding condition. Why not do
the same above with FE_TONEAREST?
> +#endif
> +#ifdef FE_DOWNWARD
> +  r = fesetround(FE_DOWNWARD);
> +  if(r){
> +  printf("fesetround ==> 0x%x\n", r);
> +}
> +  rtems_test_assert(r == 0) ;
> +  rtems_test_assert(fegetround() == FE_DOWNWARD) ;
> +#endif
> +#ifdef FE_UPWARD
> +  r = fesetround(FE_UPWARD);
> +  if(r){
> +  printf("fesetround ==> 0x%x\n", r);
> +}
> +  rtems_test_assert(r == 0) ;
> +  rtems_test_assert(fegetround() == FE_UPWARD) ;
> +#endif
> +#ifdef FE_TONEAREST
> +  r = fesetround(FE_TONEAREST);
> +  if(r){
> +  printf("fesetround ==> 0x%x\n", r);
> +}
> +  rtems_test_assert(r == 0) ;
> +#endif
>
> -fegetexceptflag(,FE_ALL_EXCEPT);
>
>  #ifdef FE_DIVBYZERO
>  r = feraiseexcept(FE_DIVBYZERO);
> @@ -125,3 +187,5 @@ rtems_task Init(rtems_task_argument ignored)
>  #define CONFIGURE_INIT
>  #include 
>  /* end of file */
> +
> +
Don't add blank lines randomly.

> --
> 2.17.1
>
> ___
> 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 Release Notes Generator - GSoC Project

[Chris Johns]

On 5/3/20 2:59 am, Denil Verghese wrote:
> Thanks, I'll check it out. 

Great

> On Wed, 4 Mar, 2020, 7:54 AM Chris Johns,  > wrote:
> 
> On 4/3/20 1:04 pm, Denil Verghese wrote:
> > I've read the ticket page at https://devel.rtems.org/ticket/3314, but 
> it was
> > last modified a couple of years ago. I would like to know if there are 
> any
> > changes or information that are missing from the ticket.
> >
> > I have intermediate knowledge on python, have a good grasp on both HTML
> and CSS
> > and basic level on XML.
> 
> Thank you for the interest.
> 
> I have updated the ticket. The existing work can be found in this repo ...
> 
> https://github.com/dh0072/ReleaseNotesGenerator
> 
> 
> 
> There is working code to fetch the tickets from Trac. The next stage is to
> generate ReST output from the data that can built into HTML or PDF by 
> Sphinx
> 
>  
> I will complete the remaining task.Will the project good enough for GSoC or
> should I do some additional work?
> 
> There is existing MarkDown support but it not right or suitable for use. 
> I am
> not sure how usable that part of the code is.
> 
> Chris
> 
> 
> Since, I knows how to scrape web-pages could I use that to get comments
> associated with each ticket?

The tickets are not downloaded as HTML. I think we use XML or comma limited
text. If you look at the bottom of a ticket you can see links to other formats.
This is what is used.

I think scraping web pages is fragile as a change in the formatting can break
the parsing.

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

[PATCH] i386/fenv.c: Include fenv.c implementation shared with x86_64, not stub

[Joel Sherrill]

---
 newlib/libm/machine/i386/fenv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/newlib/libm/machine/i386/fenv.c b/newlib/libm/machine/i386/fenv.c
index 8cbee77..1a97f56 100644
--- a/newlib/libm/machine/i386/fenv.c
+++ b/newlib/libm/machine/i386/fenv.c
@@ -4,4 +4,4 @@
  * (c) Copyright 2019 Joel Sherrill 
  */
 
-#include "../../fenv/fenv_stub.c"
+#include "../x86_64/fenv.c"
-- 
1.8.3.1

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

[PATCH] Fix i386 fenv support

[Joel Sherrill]

In removing the symbolic links, I accidentally ended up with the
i386 not having an fenv.h implementation. All the files linked to
the stub.

This patch addresses this.

--joel

Joel Sherrill (1):
  i386/fenv.c: Include fenv.c implementation shared with x86_64, not
stub

 newlib/libm/machine/i386/fenv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
1.8.3.1

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

[PATCH v3] tests for fenv.h functions

[Eshan dhawan]

---
 testsuites/psxtests/psxfenv01/init.c | 72 ++--
 1 file changed, 68 insertions(+), 4 deletions(-)

diff --git a/testsuites/psxtests/psxfenv01/init.c 
b/testsuites/psxtests/psxfenv01/init.c
index cdb0fa596e..40c29e4fac 100644
--- a/testsuites/psxtests/psxfenv01/init.c
+++ b/testsuites/psxtests/psxfenv01/init.c
@@ -46,6 +46,10 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+
+
 
 const char rtems_test_name[] = "PSXFENV 01";
 
@@ -69,20 +73,23 @@ rtems_task Init(rtems_task_argument ignored)
   #ifdef FE_ALL_EXCEPT /* floating-point exceptions */
 puts( "fesetenv(FE_DFL_ENV)." );
 r = fesetenv(FE_DFL_ENV);
-if (r)
+if (r){
   printf("fesetenv ==> %d\n", r);
+}
 rtems_test_assert( r == 0 );
 
 /* Test 'feclearexcept()' and 'fetestexcept()' in one go. */
 puts( "feclearexcept(FE_ALL_EXCEPT)." );
 r = feclearexcept(FE_ALL_EXCEPT);
-if (r)
+if (r){
   printf("feclearexcept ==> 0x%x\n", r);
+}
 rtems_test_assert( r == 0 );
 
 r = fetestexcept( FE_ALL_EXCEPT );
-if (r)
+if (r){
   printf("fetestexcept ==> 0x%x\n", r);
+}
 rtems_test_assert( r == 0 );
 
 /* Test 'FE_DIVBYZERO' */
@@ -91,8 +98,63 @@ rtems_task Init(rtems_task_argument ignored)
 b = 1.0;
 c = b/a;
 (void) c;
+/* Test 'fegetexceptflag()' and 'fesetexceptflag()' */
+r = fegetexceptflag(,FE_ALL_EXCEPT);
+if(r){
+  printf("fegetexceptflag ==> 0x%x\n", r);
+}
+rtems_test_assert(r == 0);
+
+r = fesetexceptflag(, FE_ALL_EXCEPT);
+if(r){
+  printf("fesetexceptflag ==> 0x%x\n", r);
+}
+rtems_test_assert(r == 0);
+
+
+/* Test for 'fegetround()' and 'fesetround()' */
+/* They have four main macros to be tested seperated by ifdef*/
+/* Since not all architectures support them */
+/* The test case gets and sets the rounding directions */
+#ifdef FE_TONEAREST
+r = fegetround();
+if(r){
+  printf("fegetround ==> 0x%x\n", r);
+}
+rtems_test_assert(r == FE_TONEAREST) ;   
+#endif
+#ifdef FE_TOWARDZERO
+  r = fesetround(FE_TOWARDZERO);
+  if(r){
+  printf("fesetround ==> 0x%x\n", r); 
+} 
+  rtems_test_assert(r == 0) ;
+  rtems_test_assert(fegetround() == FE_TOWARDZERO) ;
+#endif
+#ifdef FE_DOWNWARD
+  r = fesetround(FE_DOWNWARD);
+  if(r){
+  printf("fesetround ==> 0x%x\n", r); 
+} 
+  rtems_test_assert(r == 0) ;
+  rtems_test_assert(fegetround() == FE_DOWNWARD) ;
+#endif
+#ifdef FE_UPWARD
+  r = fesetround(FE_UPWARD);
+  if(r){
+  printf("fesetround ==> 0x%x\n", r); 
+}   
+  rtems_test_assert(r == 0) ;
+  rtems_test_assert(fegetround() == FE_UPWARD) ;
+#endif
+#ifdef FE_TONEAREST
+  r = fesetround(FE_TONEAREST);
+  if(r){
+  printf("fesetround ==> 0x%x\n", r);
+} 
+  rtems_test_assert(r == 0) ;
+#endif
 
-fegetexceptflag(,FE_ALL_EXCEPT);
 
 #ifdef FE_DIVBYZERO
 r = feraiseexcept(FE_DIVBYZERO);
@@ -125,3 +187,5 @@ rtems_task Init(rtems_task_argument ignored)
 #define CONFIGURE_INIT
 #include 
 /* end of file */
+
+
-- 
2.17.1

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

Re: [PATCH v2 1/4] added fesetexeptflag() test to the psxfenv test

[Eshan Dhawan]

This is an old patch 


> On 04-Mar-2020, at 10:11 PM, Gedare Bloom  wrote:
> 
> On Tue, Mar 3, 2020 at 12:50 PM Eshan dhawan  wrote:
>> 
>> ---
>> testsuites/psxtests/psxfenv01/init.c | 36 
>> 1 file changed, 31 insertions(+), 5 deletions(-)
>> 
>> diff --git a/testsuites/psxtests/psxfenv01/init.c 
>> b/testsuites/psxtests/psxfenv01/init.c
>> index cdb0fa596e..8ffb9395b9 100644
>> --- a/testsuites/psxtests/psxfenv01/init.c
>> +++ b/testsuites/psxtests/psxfenv01/init.c
>> @@ -46,6 +46,9 @@
>> #include 
>> #include 
>> #include 
>> +#include 
>> +
>> +#define rtems_test_assert(x) assert(x)
>> 
> Why do you add this? It should be coming in from tmacros.h already.
> 
>> const char rtems_test_name[] = "PSXFENV 01";
>> 
>> @@ -71,19 +74,19 @@ rtems_task Init(rtems_task_argument ignored)
>> r = fesetenv(FE_DFL_ENV);
>> if (r)
>>   printf("fesetenv ==> %d\n", r);
>> -rtems_test_assert( r == 0 );
>> +assert( r == 0 );
> Why do you change this?
> 
>> 
>> /* Test 'feclearexcept()' and 'fetestexcept()' in one go. */
>> puts( "feclearexcept(FE_ALL_EXCEPT)." );
>> r = feclearexcept(FE_ALL_EXCEPT);
>> if (r)
>>   printf("feclearexcept ==> 0x%x\n", r);
>> -rtems_test_assert( r == 0 );
>> +assert( r == 0 );
>> 
>> r = fetestexcept( FE_ALL_EXCEPT );
>> if (r)
>>   printf("fetestexcept ==> 0x%x\n", r);
>> -rtems_test_assert( r == 0 );
>> +assert( r == 0 );
>> 
>> /* Test 'FE_DIVBYZERO' */
>> puts( "Divide by zero and confirm fetestexcept()" );
>> @@ -91,12 +94,22 @@ rtems_task Init(rtems_task_argument ignored)
>> b = 1.0;
>> c = b/a;
>> (void) c;
>> +/* Test fegetexceptflag() and fesetexceptflag().*/
>> +r=fegetexceptflag(,FE_ALL_EXCEPT);
> white space is still wrong. please reread the coding conventions, it
> should be more like
> r = fegetexceptflag( , FE_ALL_EXCEPT );
> 
> 
>> +if(r)
>> +  printf("fegetexceptflag ==> 0x%x\n", r);
>> +assert(r == 0);
>> +
>> +r=fesetexceptflag(, FE_ALL_EXCEPT);
>> +if(r)
>> +  printf("fesetexceptflag ==> 0x%x\n", r);
>> +assert(r == 0);
>> +
>> 
>> -fegetexceptflag(,FE_ALL_EXCEPT);
>> 
>> #ifdef FE_DIVBYZERO
>> r = feraiseexcept(FE_DIVBYZERO);
>> -rtems_test_assert( fetestexcept( FE_DIVBYZERO ) );
>> +assert( fetestexcept( FE_DIVBYZERO ) );
>> #endif
>> 
>> /* Test 'FE_INEXACT' */
>> @@ -125,3 +138,16 @@ rtems_task Init(rtems_task_argument ignored)
>> #define CONFIGURE_INIT
>> #include 
>> /* end of file */
>> +
>> +
>> +/*
> Why is this added here?
> 
> It is also odd to have stuff after a comment that says "end of file"?
> 
>> +fegetenv()
>> +
>> +fegetround()
>> +feholdexcept()
>> +
>> +fesetexceptflag()
>> +fesetround()
>> +
>> +feupdateenv()
>> +*/
>> --
>> 2.17.1
>> 
>> ___
>> 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 v2 4/4] test for fenv.h functions

[Gedare Bloom]

On Tue, Mar 3, 2020 at 12:50 PM Eshan dhawan  wrote:
>
> ---
>  testsuites/psxtests/psxfenv01/init.c | 75 +---
>  1 file changed, 46 insertions(+), 29 deletions(-)
>
> diff --git a/testsuites/psxtests/psxfenv01/init.c 
> b/testsuites/psxtests/psxfenv01/init.c
> index 4339139c58..dc9ec3c766 100644
> --- a/testsuites/psxtests/psxfenv01/init.c
> +++ b/testsuites/psxtests/psxfenv01/init.c
> @@ -74,19 +74,25 @@ rtems_task Init(rtems_task_argument ignored)
>  puts( "fesetenv(FE_DFL_ENV)." );
>  r = fesetenv(FE_DFL_ENV);
>  if (r)
> -  printf("fesetenv ==> %d\n", r);
> +  {
The opening bracket goes on the same line as the closing parenthesis
of the conditional statement:
if ( r ) {
...
}

> +printf("fesetenv ==> %d\n", r);
> +  }
>  rtems_test_assert( r == 0 );
>
>  /* Test 'feclearexcept()' and 'fetestexcept()' in one go. */
>  puts( "feclearexcept(FE_ALL_EXCEPT)." );
>  r = feclearexcept(FE_ALL_EXCEPT);
>  if (r)
> +{
>printf("feclearexcept ==> 0x%x\n", r);
> +}
>  rtems_test_assert( r == 0 );
>
>  r = fetestexcept( FE_ALL_EXCEPT );
>  if (r)
> -  printf("fetestexcept ==> 0x%x\n", r);
> + {
> +printf("fetestexcept ==> 0x%x\n", r);
> + }
>  rtems_test_assert( r == 0 );
>
>  /* Test 'FE_DIVBYZERO' */
> @@ -95,56 +101,67 @@ rtems_task Init(rtems_task_argument ignored)
>  b = 1.0;
>  c = b/a;
>  (void) c;
> -/* Test fegetexceptflag() and fesetexceptflag().*/
> -r=fegetexceptflag(,FE_ALL_EXCEPT);
> -if(r)
> -  printf("fegetexceptflag ==> 0x%x\n", r);
> +/* Test 'fegetexceptflag()' and 'fesetexceptflag()'. */
> +r = fegetexceptflag(,FE_ALL_EXCEPT);
> +if (r)
> +{
> +   printf("fegetexceptflag ==> 0x%x\n", r);
> +}
>  rtems_test_assert(r == 0);
>
> -r=fesetexceptflag(, FE_ALL_EXCEPT);
> -if(r)
> +r = fesetexceptflag(, FE_ALL_EXCEPT);
> +if (r)
> +{
>printf("fesetexceptflag ==> 0x%x\n", r);
> +}
>  rtems_test_assert(r == 0);
>
>
> -/*test for fegetround() and fesetround()*/
> -/*they have four main macros to be tested seperated by ifdef*/
> -/* since all the architectures dont support them */
> -/*the test cases gets and sets the rounding directions */
> +/* Test for 'fegetround()' and 'fesetround()' */
> +/*They have four main macros to be tested separated by ifdef */
> +/*  since not all architectures support them */
> +/* the test case gets and sets the rounding directions */
>  #ifdef FE_TONEAREST
> -
> -r=fegetround();
> -if(r)
> +r = fegetround();
> +if (r)
> +{
> printf("fegetround ==> 0x%x\n", r);
> +}
>  rtems_test_assert(r == FE_TONEAREST) ;
>  #endif
>  #ifdef FE_TOWARDZERO
> -
> -  r=fesetround(FE_TOWARDZERO);
> -  if(r)
> -   printf("fesetround ==> 0x%x\n", r);
> +  r = fesetround(FE_TOWARDZERO);
> +  if (r)
> + {
> + printf("fesetround ==> 0x%x\n", r);
> + }
>rtems_test_assert(r == 0) ;
>rtems_test_assert(fegetround() == FE_TOWARDZERO) ;
>  #endif
>  #ifdef FE_DOWNWARD
> -
> -  r=fesetround(FE_DOWNWARD);
> -  if(r)
> -   printf("fesetround ==> 0x%x\n", r);
> +  r = fesetround(FE_DOWNWARD);
> +  if (r)
> + {
> +   printf("fesetround ==> 0x%x\n", r);
> + }
>rtems_test_assert(r == 0) ;
>rtems_test_assert(fegetround() == FE_DOWNWARD) ;
>  #endif
>  #ifdef FE_UPWARD
> -  r=fesetround(FE_UPWARD);
> -  if(r)
> -   printf("fesetround ==> 0x%x\n", r);
> +  r = fesetround(FE_UPWARD);
> +  if (r)
> + {
> +   printf("fesetround ==> 0x%x\n", r);
> + }
>rtems_test_assert(r == 0) ;
>rtems_test_assert(fegetround() == FE_UPWARD) ;
>  #endif
>  #ifdef FE_TONEAREST
> -  r=fesetround(FE_TONEAREST);
> -  if(r)
> -   printf("fesetround ==> 0x%x\n", r);
> +  r = fesetround(FE_TONEAREST);
> +  if (r)
> +  {
> +printf("fesetround ==> 0x%x\n", r);
> +  }
>rtems_test_assert(r == 0) ;
>  #endif
>
> --
> 2.17.1
>
> ___
> 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 v2 2/4] added test for fegetexeptflag and fesetexeptflag

[Gedare Bloom]

I see you fixed some of the problems in this patch from the previous
patch.   Please "squash" the two patches together. Read about git
interactive rebase (fixup or squash options) to do this. You should
not include in one patch things that are broken and that you fix in
another patch in the same series. Go back and correct what was wrong
in the first place.

On Tue, Mar 3, 2020 at 12:50 PM Eshan dhawan  wrote:
>
> ---
>  testsuites/psxtests/psxfenv01/init.c | 27 +--
>  1 file changed, 9 insertions(+), 18 deletions(-)
>
> diff --git a/testsuites/psxtests/psxfenv01/init.c 
> b/testsuites/psxtests/psxfenv01/init.c
> index 8ffb9395b9..05f3cdc880 100644
> --- a/testsuites/psxtests/psxfenv01/init.c
> +++ b/testsuites/psxtests/psxfenv01/init.c
> @@ -47,8 +47,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +
>
> -#define rtems_test_assert(x) assert(x)
>
>  const char rtems_test_name[] = "PSXFENV 01";
>
> @@ -74,19 +75,19 @@ rtems_task Init(rtems_task_argument ignored)
>  r = fesetenv(FE_DFL_ENV);
>  if (r)
>printf("fesetenv ==> %d\n", r);
> -assert( r == 0 );
> +rtems_test_assert( r == 0 );
>
>  /* Test 'feclearexcept()' and 'fetestexcept()' in one go. */
>  puts( "feclearexcept(FE_ALL_EXCEPT)." );
>  r = feclearexcept(FE_ALL_EXCEPT);
>  if (r)
>printf("feclearexcept ==> 0x%x\n", r);
> -assert( r == 0 );
> +rtems_test_assert( r == 0 );
>
>  r = fetestexcept( FE_ALL_EXCEPT );
>  if (r)
>printf("fetestexcept ==> 0x%x\n", r);
> -assert( r == 0 );
> +rtems_test_assert( r == 0 );
>
>  /* Test 'FE_DIVBYZERO' */
>  puts( "Divide by zero and confirm fetestexcept()" );
> @@ -98,18 +99,19 @@ rtems_task Init(rtems_task_argument ignored)
>  r=fegetexceptflag(,FE_ALL_EXCEPT);
>  if(r)
>printf("fegetexceptflag ==> 0x%x\n", r);
> -assert(r == 0);
> +rtems_test_assert(r == 0);
>
>  r=fesetexceptflag(, FE_ALL_EXCEPT);
>  if(r)
>printf("fesetexceptflag ==> 0x%x\n", r);
> -assert(r == 0);
> +rtems_test_assert(r == 0);
>
> +
>
>
>  #ifdef FE_DIVBYZERO
>  r = feraiseexcept(FE_DIVBYZERO);
> -assert( fetestexcept( FE_DIVBYZERO ) );
> +rtems_test_assert( fetestexcept( FE_DIVBYZERO ) );
>  #endif
>
>  /* Test 'FE_INEXACT' */
> @@ -140,14 +142,3 @@ rtems_task Init(rtems_task_argument ignored)
>  /* end of file */
>
>
> -/*
> -fegetenv()
> -
> -fegetround()
> -feholdexcept()
> -
> -fesetexceptflag()
> -fesetround()
> -
> -feupdateenv()
> -*/
> --
> 2.17.1
>
> ___
> 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 v2 1/4] added fesetexeptflag() test to the psxfenv test

[Gedare Bloom]

On Tue, Mar 3, 2020 at 12:50 PM Eshan dhawan  wrote:
>
> ---
>  testsuites/psxtests/psxfenv01/init.c | 36 
>  1 file changed, 31 insertions(+), 5 deletions(-)
>
> diff --git a/testsuites/psxtests/psxfenv01/init.c 
> b/testsuites/psxtests/psxfenv01/init.c
> index cdb0fa596e..8ffb9395b9 100644
> --- a/testsuites/psxtests/psxfenv01/init.c
> +++ b/testsuites/psxtests/psxfenv01/init.c
> @@ -46,6 +46,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +
> +#define rtems_test_assert(x) assert(x)
>
Why do you add this? It should be coming in from tmacros.h already.

>  const char rtems_test_name[] = "PSXFENV 01";
>
> @@ -71,19 +74,19 @@ rtems_task Init(rtems_task_argument ignored)
>  r = fesetenv(FE_DFL_ENV);
>  if (r)
>printf("fesetenv ==> %d\n", r);
> -rtems_test_assert( r == 0 );
> +assert( r == 0 );
Why do you change this?

>
>  /* Test 'feclearexcept()' and 'fetestexcept()' in one go. */
>  puts( "feclearexcept(FE_ALL_EXCEPT)." );
>  r = feclearexcept(FE_ALL_EXCEPT);
>  if (r)
>printf("feclearexcept ==> 0x%x\n", r);
> -rtems_test_assert( r == 0 );
> +assert( r == 0 );
>
>  r = fetestexcept( FE_ALL_EXCEPT );
>  if (r)
>printf("fetestexcept ==> 0x%x\n", r);
> -rtems_test_assert( r == 0 );
> +assert( r == 0 );
>
>  /* Test 'FE_DIVBYZERO' */
>  puts( "Divide by zero and confirm fetestexcept()" );
> @@ -91,12 +94,22 @@ rtems_task Init(rtems_task_argument ignored)
>  b = 1.0;
>  c = b/a;
>  (void) c;
> +/* Test fegetexceptflag() and fesetexceptflag().*/
> +r=fegetexceptflag(,FE_ALL_EXCEPT);
white space is still wrong. please reread the coding conventions, it
should be more like
r = fegetexceptflag( , FE_ALL_EXCEPT );


> +if(r)
> +  printf("fegetexceptflag ==> 0x%x\n", r);
> +assert(r == 0);
> +
> +r=fesetexceptflag(, FE_ALL_EXCEPT);
> +if(r)
> +  printf("fesetexceptflag ==> 0x%x\n", r);
> +assert(r == 0);
> +
>
> -fegetexceptflag(,FE_ALL_EXCEPT);
>
>  #ifdef FE_DIVBYZERO
>  r = feraiseexcept(FE_DIVBYZERO);
> -rtems_test_assert( fetestexcept( FE_DIVBYZERO ) );
> +assert( fetestexcept( FE_DIVBYZERO ) );
>  #endif
>
>  /* Test 'FE_INEXACT' */
> @@ -125,3 +138,16 @@ rtems_task Init(rtems_task_argument ignored)
>  #define CONFIGURE_INIT
>  #include 
>  /* end of file */
> +
> +
> +/*
Why is this added here?

It is also odd to have stuff after a comment that says "end of file"?

> +fegetenv()
> +
> +fegetround()
> +feholdexcept()
> +
> +fesetexceptflag()
> +fesetround()
> +
> +feupdateenv()
> +*/
> --
> 2.17.1
>
> ___
> 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 Release Notes Generator - GSoC Project

[Gedare Bloom]

On Wed, Mar 4, 2020 at 8:59 AM Denil Verghese  wrote:
>
> Thanks, I'll check it out.
>
> On Wed, 4 Mar, 2020, 7:54 AM Chris Johns,  wrote:
>>
>> On 4/3/20 1:04 pm, Denil Verghese wrote:
>> > I've read the ticket page at https://devel.rtems.org/ticket/3314, but it 
>> > was
>> > last modified a couple of years ago. I would like to know if there are any
>> > changes or information that are missing from the ticket.
>> >
>> > I have intermediate knowledge on python, have a good grasp on both HTML 
>> > and CSS
>> > and basic level on XML.
>>
>> Thank you for the interest.
>>
>> I have updated the ticket. The existing work can be found in this repo ...
>>
>> https://github.com/dh0072/ReleaseNotesGenerator
>>
>>
>>
>> There is working code to fetch the tickets from Trac. The next stage is to
>> generate ReST output from the data that can built into HTML or PDF by Sphinx
>
>
> I will complete the remaining task.Will the project good enough for GSoC or 
> should I do some additional work?
>
It doesn't quite sound like enough work.  You will want to identify a
set of tasks that you can work on either incrementally to continue
improving the release notes generator. One idea could be around
license compliance such as auditing license information and creating a
manifest for a release, which might be useful

>> There is existing MarkDown support but it not right or suitable for use. I am
>> not sure how usable that part of the code is.
>>
And evaluating/fixing the MD support or other possible output formats
for release notes. (Plaintext? Structured/Parseable Document e.g.,
XML?)

As you write the proposal you may come up with some more ideas, and so
might the potential mentors/community members.

>> Chris
>
>
> Since, I knows how to scrape web-pages could I use that to get comments 
> associated with each ticket?
>
> Denil Verghese
> ___
> 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: Introducing myself and HelloWorld completion.

[Gedare Bloom]

On Wed, Mar 4, 2020 at 12:41 AM Sebastian Huber
 wrote:
>
> On 04/03/2020 06:28, Gedare Bloom wrote:
> > On Tue, Mar 3, 2020 at 6:02 PM Denil Verghese  wrote:
> >> Hi,
> >>>
> >>> Great. Those are two quite distinct projects. The "Improve the SMP
> >>> Scheduler" will require strong C programming skills. The "Release
> >>> Notes Generator" would involve Python programming. Depending on which
> >>> language you are stronger in, you might choose to pursue one of them.
> >>
> >> How can I acquire the required skills to do projects like 'Improve the SMP 
> >> Scheduler'. If there is a way that I can learn and work on it, then I 
> >> would prefer it over the ' Release Notes Generator' project.
> >> Meanwhile, I have entered to work with the later on GSoC Tracking page.
> >>
> > You need to have pretty good C programming skills before the summer
> > even begins. More of a concern is whether anyone is able to mentor
> > that project this year.
>
> Improving an SMP scheduler this year is not in my focus. I am quite
> happy with the current SMP EDF scheduler.
>
Yes, and I don't know yet if/what I might decide to mentor. That means
it is highly unlikely to have a mentor for a scheduling project.

> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/2] Add a pure Python clone of mkimage written by Craig Barker.

[Gedare Bloom]

On Wed, Mar 4, 2020 at 8:39 AM Amar Takhar  wrote:
>
> On 2020-03-04 20:02 +1100, Chris Johns wrote:
> >
> > I am wondering how a user runs just the mkimake.py file once install. The
> > rtems-tools repo normally packages a command in a wrapper that has has
> > `/usr/bin/env python` and so $PATH etc works.
>
> I added a python2 shebang in the 2nd commit it can be run directly I don't 
> see a
> need for a wrapper.  I do plan on eventually fixing this so it works in both
> python2 and 3 right now it's 2 only.
>
> Should I add these commits so I can work on the rest?
>
Yes it looks fine as a starting point.

>
> Amar.
> ___
> 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 Release Notes Generator - GSoC Project

[Denil Verghese]

Thanks, I'll check it out.

On Wed, 4 Mar, 2020, 7:54 AM Chris Johns,  wrote:

> On 4/3/20 1:04 pm, Denil Verghese wrote:
> > I've read the ticket page at https://devel.rtems.org/ticket/3314, but
> it was
> > last modified a couple of years ago. I would like to know if there are
> any
> > changes or information that are missing from the ticket.
> >
> > I have intermediate knowledge on python, have a good grasp on both HTML
> and CSS
> > and basic level on XML.
>
> Thank you for the interest.
>
> I have updated the ticket. The existing work can be found in this repo ...
>
> https://github.com/dh0072/ReleaseNotesGenerator


>
> There is working code to fetch the tickets from Trac. The next stage is to
> generate ReST output from the data that can built into HTML or PDF by
> Sphinx


I will complete the remaining task.Will the project good enough for GSoC or
should I do some additional work?

There is existing MarkDown support but it not right or suitable for use. I
> am
> not sure how usable that part of the code is.
>
> Chris
>

Since, I knows how to scrape web-pages could I use that to get comments
associated with each ticket?

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

Re: [PATCH 1/2] Add a pure Python clone of mkimage written by Craig Barker.

[Amar Takhar]

On 2020-03-04 20:02 +1100, Chris Johns wrote:
> 
> I am wondering how a user runs just the mkimake.py file once install. The
> rtems-tools repo normally packages a command in a wrapper that has has
> `/usr/bin/env python` and so $PATH etc works.

I added a python2 shebang in the 2nd commit it can be run directly I don't see 
a 
need for a wrapper.  I do plan on eventually fixing this so it works in both 
python2 and 3 right now it's 2 only.

Should I add these commits so I can work on the rest?


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

Re: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

On 04/03/2020 07:07, Sebastian Huber wrote:
> On 04/03/2020 05:55, Chris Johns wrote:
>>> I think for Boards that normally run a Linux it is a sane approach to
>>> just replace the Linux Kernel with a RTEMS binary and otherwise keep the
>>> boot process with for example U-Boot. Everything else is a lot of extra
>>> effort to implement and not necessary in a lot of situations.
>> Is there documentation about that shows this process for an existing
>> board?
>>
>> I get what you are saying and it make prefect sense and it would be no
>> issue for
>> me to do this however there are a number of steps involved and there is a
>> certain amount of assumed knowledge here. How do we establish a
>> framework or
>> template that lets are capture this so it is useful and usable to our
>> users?
> 
> My approach would be to use the devices trees shipped by the hardware
> vendor and fix our drivers if necessary. For example, I had to adjust
> the Altera Cyclone V BSP for these modules:
> 
> https://www.enclustra.com/en/products/system-on-chip-modules/mars-ma3/
> 
> The device tree has a different clock structure compared to the Altera
> Development Kit, so the update_clocks() function supports both:
> 
> https://git.rtems.org/rtems/tree/bsps/arm/altera-cyclone-v/start/bspstart.c#n79
> 
> 

Hello Sebastian,

note that the version delivered with a board is very undefined and it is
not necessarily the same for two boards with a different production
date. So it's quite hard to reproduce a special FDT that works together
with a special version of a BSP. So some method to archive them and say
"that BSP works with this FDT" isn't a bad idea.

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: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

Hello Chris,

On 04/03/2020 05:55, Chris Johns wrote:
> Sorry about delay in getting back to this. I have been focused on getting the
> release into something close to what we want for RC1.

No problem. The release is relevant for all of us.

> 
> On 28/2/20 9:48 pm, Christian Mauderer wrote:
>> Hello Gedare and Chris,
>>
>> On 27/02/2020 23:14, Gedare Bloom wrote:
>>> On Thu, Feb 27, 2020 at 3:01 PM Chris Johns  wrote:

 On 28/2/20 7:23 am, Alan Cudmore wrote:
> I noticed that the Zephyr RTOS (https://www.zephyrproject.org) uses a
> device tree based initialization for all of its BSPs.
> For example, here is the top level device tree source for the Adafruit
> Trinket M0, which is a very small Atmel Cortex M0 based board:
> https://github.com/zephyrproject-rtos/zephyr/blob/master/boards/arm/adafruit_trinket_m0/adafruit_trinket_m0.dts
>
> The rest of the device tree source for common processors and devices are 
> here:
> https://github.com/zephyrproject-rtos/zephyr/tree/master/dts
>
> To me, it looks like they have to develop (or port) and maintain
> device trees for each board and device that is supported.
>
> Does that look like a model that RTEMS could use? I'm not sure I
> understand everything that deploying such a model implies, or if it
> just makes more sense to use the existing FreeBSD or linux device
> trees.

 This is where I was heading in my thinking but I am not sure. I am 
 settling on
 having a dts tree in rtems.git and we may just have to manually manage the
 files. I am not sure there are enough files to warrant a system like 
 libbsd and
 FreeBSD at this point in time. That may change with the new build system 
 and
 python being available however until then manual is fine. Let me explain 
 ...

 I have been looking beyond the internal development aspects and to how we 
 use
 FDT blobs and I am wondering if the approach we have with the shared FDT 
 BSP
 support is the right fit for RTEMS and a statically linked executable.

 I believe currently we need a suitable bootloader, ie u-boot, to load a 
 blob.
 This is the Linux way of doing things and this may be the right approach 
 for
 Linux but I am not so sure it is for us. It means you need u-boot and a 
 suitable
 file system plus you have a lot more items to configuration manage in 
 production
 systems and a lot more complexity for self upgrading.
>>
>> I think for Boards that normally run a Linux it is a sane approach to
>> just replace the Linux Kernel with a RTEMS binary and otherwise keep the
>> boot process with for example U-Boot. Everything else is a lot of extra
>> effort to implement and not necessary in a lot of situations.
> 
> Is there documentation about that shows this process for an existing board?

To be honest: I don't know. Basically the description for the raspberry,
for BBB, for imx results in this. I haven't looked at the other BSPs
yet. But it isn't documented with this words.

> 
> I get what you are saying and it make prefect sense and it would be no issue 
> for
> me to do this however there are a number of steps involved and there is a
> certain amount of assumed knowledge here. How do we establish a framework or
> template that lets are capture this so it is useful and usable to our users?
> 

Basically the boot process should always be documented in the BSP
section of the manual. We maybe add some default cases:

1. Boards that normally run Linux: Suggestion: Use the same boot process
as Linux. For device trees: Use one delivered with the board (which only
maybe works) or use the one provided by the repository we are discussing
now (which should always work).

2. Boards that are not running Linux but want to use a FDT: I think we
currently don't have any. But if we would have ones, they most likely
have a small hand written FDT or one generated for example together with
a FPGA. Here it might would be a sane approach to link the FDT into the
application. Again: We don't have a BSP yet that is in that category so
not relevant for the release.

3. Boards that are not using an FDT. Most BSPs. The boot is very target
dependent. Not relevant for our current discussion.

>>

 Why do we have a bootloader load the FDT files when we statically link
 everything else?>>
 Why not link them into the executable and register them? It s easy to do.

>>
>> One BSP where it is a disadvantage to statically link is Raspberry Pi.
>> With the recent work you currently can use the same binary for RPi2 and
>> 3 with only a different FDT. Same for RPi1 and RPi Zero / Zero W.
> 
> Great example and a good point.
> 
>> I'm not against the possibility to link the FDT. But we should be open
>> to use both methods.
> 
> OK
> 
 The flow on from doing this has some real advantages. FDT files that are 
 linked
 into an executable 

Re: Waf Build System Status in RTEMS?

[Hesham Almatary]

On Wed, 4 Mar 2020 at 08:55, Sebastian Huber
 wrote:
>
> On 25/02/2020 12:54, Sebastian Huber wrote:
> > On 25/02/2020 11:00, Hesham Almatary wrote:
> >> On Mon, 24 Feb 2020 at 22:50, Chris Johns  wrote:
> >>> On 21/2/20 11:11 pm, Sebastian Huber wrote:
>  On 21/02/2020 12:26, Hesham Almatary wrote:
> > On Fri, 21 Feb 2020 at 11:07, Sebastian Huber
> >wrote:
> >> Hello Hesham,
> >>
> >> On 20/02/2020 16:40, Hesham Almatary wrote:
> >>> Hello,
> >>>
> >>> Are there any progress updates to the Waf build system
> >>> integration in RTEMS?
> >>>
> >>> I have pulled [1] and it seems like it hasn't got many updates since
> >>> December. I wonder what's still remaining/blocking to merge it,
> >>> or at
> >>> least push it as a development branch (without re-writing history)
> >>> that others, including me, can use it and submit patches against.
> >>>
> >>> [1] git://git.rtems.org/sebh/rtems.git
> >> technically, the new build system is ready for integration into the
> >> master branch. I would need about one day to rebase and test it
> >> before
> >> the push. The integration is currently blocked since Chris and
> >> Joel had
> >> no time to look at it.
> >>
> > Thanks for your input, Sebastian. Is there a recommended branch I
> > should be based on? I noticed there's "build" and "build-next".
>  The "build" branch contains the state of the first review. I updated
>  "build-next" a couple of times to integrate the changes on the RTEMS
>  master.
> 
> > Do you intend to re-write git history in either?
>  Yes, when I started with the build system work I didn't expect a
>  more than two
>  months review period.
> >>> I have discussed this merge with Joel. We have decided to release
> >>> RTEMS 5 before
> >>> we merge a new build system. A release with parallel build systems is
> >>> confusing
> >>> and distracting.
> >>>
> >> That makes sense to me. I think we should both try to push for an
> >> RTEMS release soon, and make the waf/build
> >> branch more stable and/or in the view (e.g., push as an experimental
> >> branch) for developer to use until a release comes out. I understand
> >> another branch would incur more maintaibility efforts, but it will
> >> also help make the the new build system more usable.
> >
> > I can do a forced update of the "build" branch with my latest version
> > based on rebase of the current master by the end of the week.
> > Afterwards, I can do merges from the master instead of forced pushes.
> > This should enable you to base your work on this branch. You can also
> > send me patches.
> >
> > Before the new build system is integrated in the master, I will do a
> > final rebase to the master and squash commits.
>
> I did a forced push to the build branch today. It is based on the master
> branch commit:
>
> https://git.rtems.org/rtems/commit/?id=fa3005f6c1ddb99347acb70cbaecd155ed0356ed
>
> I will not do another forced push to the build branch in the future and
> instead do merges from the master to the build branch. I hope this helps
> to use it for experimental work. After the RTEMS 5 release when the new
> build system is ready to get integrated I will do a rebase and squash
> the commits before I push them to the master.
>
That will definitely make my life easier. Thanks, Sebastian!

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



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

Re: [PATCH 1/2] Add a pure Python clone of mkimage written by Craig Barker.

[Chris Johns]

On 4/3/20 4:58 pm, Sebastian Huber wrote:
> On 04/03/2020 02:46, Amar Takhar wrote:
>> I emailed Craig Barker to ask if he would release his mkimage Python rewrite
>> as 2BSD.  He graciously accepted and you can see his work here:
>>
>>    https://github.com/cmbarker83/pythonmkimage
>>
>> This is a verbatim commit of 35d6d from his repository.
> 
> This is really nice. Getting mkimage for Windows was always a pain.
> 

I agree.

I am wondering how a user runs just the mkimake.py file once install. The
rtems-tools repo normally packages a command in a wrapper that has has
`/usr/bin/env python` and so $PATH etc works.

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

Re: Waf Build System Status in RTEMS?

[Sebastian Huber]

On 25/02/2020 12:54, Sebastian Huber wrote:

On 25/02/2020 11:00, Hesham Almatary wrote:

On Mon, 24 Feb 2020 at 22:50, Chris Johns  wrote:

On 21/2/20 11:11 pm, Sebastian Huber wrote:

On 21/02/2020 12:26, Hesham Almatary wrote:

On Fri, 21 Feb 2020 at 11:07, Sebastian Huber
   wrote:

Hello Hesham,

On 20/02/2020 16:40, Hesham Almatary wrote:

Hello,

Are there any progress updates to the Waf build system 
integration in RTEMS?


I have pulled [1] and it seems like it hasn't got many updates since
December. I wonder what's still remaining/blocking to merge it, 
or at

least push it as a development branch (without re-writing history)
that others, including me, can use it and submit patches against.

[1] git://git.rtems.org/sebh/rtems.git

technically, the new build system is ready for integration into the
master branch. I would need about one day to rebase and test it 
before
the push. The integration is currently blocked since Chris and 
Joel had

no time to look at it.


Thanks for your input, Sebastian. Is there a recommended branch I
should be based on? I noticed there's "build" and "build-next".

The "build" branch contains the state of the first review. I updated
"build-next" a couple of times to integrate the changes on the RTEMS 
master.



Do you intend to re-write git history in either?
Yes, when I started with the build system work I didn't expect a 
more than two

months review period.
I have discussed this merge with Joel. We have decided to release 
RTEMS 5 before
we merge a new build system. A release with parallel build systems is 
confusing

and distracting.


That makes sense to me. I think we should both try to push for an
RTEMS release soon, and make the waf/build
branch more stable and/or in the view (e.g., push as an experimental
branch) for developer to use until a release comes out. I understand
another branch would incur more maintaibility efforts, but it will
also help make the the new build system more usable.


I can do a forced update of the "build" branch with my latest version 
based on rebase of the current master by the end of the week. 
Afterwards, I can do merges from the master instead of forced pushes. 
This should enable you to base your work on this branch. You can also 
send me patches.


Before the new build system is integrated in the master, I will do a 
final rebase to the master and squash commits.


I did a forced push to the build branch today. It is based on the master 
branch commit:


https://git.rtems.org/rtems/commit/?id=fa3005f6c1ddb99347acb70cbaecd155ed0356ed

I will not do another forced push to the build branch in the future and 
instead do merges from the master to the build branch. I hope this helps 
to use it for experimental work. After the RTEMS 5 release when the new 
build system is ready to get integrated I will do a rebase and squash 
the commits before I push them to the master.


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