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

[Eshan Dhawan]

I have modified the test to print nothing if the test passes 
In this test I have removed all the compulsory print statements that described 
the cases with comments so it would be easy to world on and will not print 
anything on the screen when the test passes 

> On 23-Mar-2020, at 1:41 AM, Eshan dhawan  wrote:
> 
> ---
> testsuites/psxtests/psxfenv01/init.c| 105 +++-
> testsuites/psxtests/psxfenv01/psxfenv01.doc |   9 +-
> testsuites/psxtests/psxfenv01/psxfenv01.scn |   4 -
> 3 files changed, 85 insertions(+), 33 deletions(-)
> 
> diff --git a/testsuites/psxtests/psxfenv01/init.c 
> b/testsuites/psxtests/psxfenv01/init.c
> index cdb0fa596e..b088209d7f 100644
> --- a/testsuites/psxtests/psxfenv01/init.c
> +++ b/testsuites/psxtests/psxfenv01/init.c
> @@ -46,11 +46,12 @@
> #include 
> #include 
> #include 
> +#include 
> 
> const char rtems_test_name[] = "PSXFENV 01";
> 
> /* forward declarations to avoid warnings */
> -rtems_task Init(rtems_task_argument ignored);
> +rtems_task Init( rtems_task_argument ignored );
> 
> /* Test Function Begins */
> rtems_task Init(rtems_task_argument ignored)
> @@ -62,40 +63,90 @@ rtems_task Init(rtems_task_argument ignored)
> 
>   /*
>* 'FE_ALL_EXCEPT' will be defined only when 'feclearexcept()',
> -   * 'fegetexceptflag()', 'feraiseexcept()', 'fesetexceptflag()' and
> -   * 'fetestexcept()' functions are supported by the architecture.
> +   * fegetexceptflag() , feraiseexcept(), fesetexceptflag() and
> +   * fetestexcept() functions are supported by the architecture.
>* Hence their testcases can be wrapped under #ifdef and #endif.
>*/
>   #ifdef FE_ALL_EXCEPT /* floating-point exceptions */
> -puts( "fesetenv(FE_DFL_ENV)." );
> -r = fesetenv(FE_DFL_ENV);
> -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);
> -rtems_test_assert( r == 0 );
> -
> -/* Test 'FE_DIVBYZERO' */
> -puts( "Divide by zero and confirm fetestexcept()" );
> +r = fesetenv ( FE_DFL_ENV );
> +if ( r ) {
> +  printf( "fesetenv ==> %d\n", r);
> +}
> +rtems_test_assert ( r == 0 );
> +
> +/* Test feclearexcept() and fetestexcept() in one go. */
> +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 );
> +}
> +rtems_test_assert ( r == 0 );
> +
> +/* Test 'FE_DIVBYZERO' 
> + *Divide by zero and confirm fetestexcept() */
> a = 0.0;
> b = 1.0;
> c = b/a;
> (void) c;
> -
> -fegetexceptflag(,FE_ALL_EXCEPT);
> -
> +/* 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 separated by ifdef
> + * Since not all architectures support them 
> + * The test case gets and sets the rounding directions */
> +#ifdef FE_TONEAREST
> +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 );
> +#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
> +  
> #ifdef FE_DIVBYZERO
> -r = feraiseexcept(FE_DIVBYZERO);
> +r = feraiseexcept ( FE_DIVBYZERO ) ;
> rtems_test_assert( fetestexcept( FE_DIVBYZERO ) );
> #endif
> 
> diff --git a/testsuites/psxtests/psxfenv01/psxfenv01.doc 
> 

Re: possible sources for porting sockatmark() of sys/socket.h

[Joel Sherrill]

On Sun, Mar 22, 2020, 8:21 PM Gedare Bloom  wrote:

> On Sun, Mar 22, 2020 at 1:22 PM Eshan Dhawan 
> wrote:
> >
> > confstr() from unistd.h also shows not supported in the compliance
> status  but it has some kind of supported in newlib(libc/sys/linux)
>
> sys/linux doesn't work on rtems. that is only for linux-specific newlib
> builds
>

We would need our own implementation. That's likely an example where the
header with prototype is in newlib and the implementation is in RTEMS.

>
> > it also needs to be updated in the compliance status I think
> >
> > On Mon, Mar 23, 2020 at 12:37 AM Eshan Dhawan 
> wrote:
> >>
> >> https://lists.rtems.org/pipermail/devel/2020-March/058569.html
> >>
> >>
> >> On Mon, Mar 23, 2020 at 12:35 AM Eshan Dhawan 
> wrote:
> >>>
> >>>
> >>>
> >>> On Mon, Mar 23, 2020 at 12:27 AM Joel Sherrill  wrote:
> 
> 
> 
>  On Sun, Mar 22, 2020, 1:55 PM Eshan Dhawan 
> wrote:
> >
> > It's present there.
> > I hadn't checked there.
> 
> 
>  Does that mean the spreadsheet I uploaded yesterday needs updating
> again?
> >>>
> >>> yes , the spreadsheet shows not supported.
> >>> also, I have sent another mail related to this
> >>> for wordexp.h
> >>>
> 
>  Is there a ticket to close?
> >>>
> >>> No the ticket was closed earlier
> >>> I missed that
> 
>  Finding something got added without the tracking update is a good
> outcome
> 
> >
> > On Mon, Mar 23, 2020 at 12:19 AM Joel Sherrill 
> wrote:
> >>
> >>
> >>
> >> On Sun, Mar 22, 2020, 1:37 PM Eshan Dhawan 
> wrote:
> >>>
> >>> I have identifies 2 main sources to port sockatmark().
> >>>
> >>> NetBSD source:
> >>> https://github.com/NetBSD/src/blob/trunk/lib/libc/net/sockatmark.c
> >>>
> >>> FreeBSD Source :
> >>>
> https://github.com/lattera/freebsd/blob/master/lib/libc/net/sockatmark.c
> >>>
> >>> musl has a same implementation as in FreeBSD
> >>> which one would be better to follow.
> >>
> >>
> >> This has to be in sync with rtems-libbsd and may already be there.
> Please check if it is there. Just closing a ticket and updating the
> spreadsheet is q food result. :)
> >>>
>
> Should it also be available in "legacy" networking stack? Or do we let
> that bitrot / maintain only?
>

Minimal changes. No additions. Certainly not this I think.


> >>>
> >>> thanks
> >>> -Eshan
> >
> > ___
> > 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 0/6] Proposes fixes for RTEMS Tester documentation page

[Chris Johns]

On 2020-03-23 03:17, cl...@isep.ipp.pt wrote:

From: Cláudio Maia 

This set of patches proposes several fixes for RTEMS Tester
documentation. Namely:

- Text was reviewed and improved for clarity;
- References to 'sparc-rtems5-run' command and 'erc32-run' were removed
   from the documentation page. Now, the example uses 'erc32-sis' instead.

Further references to 'sparc-rtems5-run' are still in other parts of the
documentation (Sections 10.2 and 10.3) which also need to be updated in
the future.

In addition to this, I will send another patch in a different email
which removes 'erc32-run.ini' from 'rtems-tools' repo as this BSP
configuration uses 'sparc-rtems5-run'.
Thank you for these changes. I need to build and then read the 
documentation. Some parts are fine and some changes need a closer look 
to see if they are ok.


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

Re: possible sources for porting sockatmark() of sys/socket.h

[Gedare Bloom]

On Sun, Mar 22, 2020 at 1:22 PM Eshan Dhawan  wrote:
>
> confstr() from unistd.h also shows not supported in the compliance status  
> but it has some kind of supported in newlib(libc/sys/linux)

sys/linux doesn't work on rtems. that is only for linux-specific newlib builds

> it also needs to be updated in the compliance status I think
>
> On Mon, Mar 23, 2020 at 12:37 AM Eshan Dhawan  wrote:
>>
>> https://lists.rtems.org/pipermail/devel/2020-March/058569.html
>>
>>
>> On Mon, Mar 23, 2020 at 12:35 AM Eshan Dhawan  
>> wrote:
>>>
>>>
>>>
>>> On Mon, Mar 23, 2020 at 12:27 AM Joel Sherrill  wrote:



 On Sun, Mar 22, 2020, 1:55 PM Eshan Dhawan  wrote:
>
> It's present there.
> I hadn't checked there.


 Does that mean the spreadsheet I uploaded yesterday needs updating again?
>>>
>>> yes , the spreadsheet shows not supported.
>>> also, I have sent another mail related to this
>>> for wordexp.h
>>>

 Is there a ticket to close?
>>>
>>> No the ticket was closed earlier
>>> I missed that

 Finding something got added without the tracking update is a good outcome

>
> On Mon, Mar 23, 2020 at 12:19 AM Joel Sherrill  wrote:
>>
>>
>>
>> On Sun, Mar 22, 2020, 1:37 PM Eshan Dhawan  
>> wrote:
>>>
>>> I have identifies 2 main sources to port sockatmark().
>>>
>>> NetBSD source:
>>> https://github.com/NetBSD/src/blob/trunk/lib/libc/net/sockatmark.c
>>>
>>> FreeBSD Source :
>>> https://github.com/lattera/freebsd/blob/master/lib/libc/net/sockatmark.c
>>>
>>> musl has a same implementation as in FreeBSD
>>> which one would be better to follow.
>>
>>
>> This has to be in sync with rtems-libbsd and may already be there. 
>> Please check if it is there. Just closing a ticket and updating the 
>> spreadsheet is q food result. :)
>>>

Should it also be available in "legacy" networking stack? Or do we let
that bitrot / maintain only?

>>>
>>> thanks
>>> -Eshan
>
> ___
> 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] This patch provides usage of RTEMS cross-compiler over GCC cross-compiler

[Gedare Bloom]

On Sun, Mar 22, 2020 at 11:33 AM utkarsh.ra...@gmail.com
 wrote:
>
> Really sorry for a new patch, I somehow rm -rf'ed my machine's root
Oh no!

> ---
>  user/start/tools.rst | 16 
>  1 file changed, 16 insertions(+)
>
> diff --git a/user/start/tools.rst b/user/start/tools.rst
> index c3f039b..3bb939e 100644
> --- a/user/start/tools.rst
> +++ b/user/start/tools.rst
> @@ -76,3 +76,19 @@ source code used.
>
>
>  Add ``--verbose`` to the GCC command for the the verbose version details.
> +
> +Need for RTEMS-Specific Cross-Compiler
> +
> +  New users are often confused as to why they can't use their distribution's 
> cross-compiler for their target on rtems, e.g.,the riscv64-linux-gnu or the 
> arm-none-eabi-gcc. Below mentioned are some of the reasons for using the 
> RTEMS cross-compiler.
> +
> + ``Correct configuration of newlib`` -
> +Newlib is a C standard library implementation intended for use on 
> embedded systems. Most of the POSIX and libc support for RTEMS is derived 
> from newlib. The RTEMS cross-compiler configures newlib correctly for RTEMS.

Fix line length (text width) should be <= 80 characters.

> +
> + ``Threading in GCC support libraries`` -
> +GCC support threading libraries such as ``pthread.h`` provide threading 
> support to an application; these libraries are tailored according to RTEMS 
> using the RTEMS cross-compiler.
> +
> + ``Provide preprocessor define __rtems__`` -
> +The ``__rtems__`` preprocessor define is used to provide conditional 
> code compilation in source files that are shared with other projects e.g. in 
> newlib or imported code from freebsd.
> +
> + ``Multilib variants to match the BSP``-
> +RTEMS configures GCC to create separate runtime libraries for each 
> supported instruction set, floating point unit, vector unit, word size (e.g. 
> 32-bit and 64-bit), endianness, ABI, processor errata workarounds,and so on 
> in the architecture. These libraries are termed multilib variants. Multilibs 
> variants to match the BSP are set by selecting a specific set of machine 
> options using the RTEMS cross-compiler.
> --
> 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: Ticket #2974 Enable search.h functionality in newlib

[Gedare Bloom]

On Sun, Mar 22, 2020 at 8:46 AM Joel Sherrill  wrote:
>
>
>
> On Sun, Mar 22, 2020, 1:58 AM Vaibhav Gupta  wrote:
>>>
>>>
>>> > My very quick review shows that this may all be present and then it is a 
>>> > matter
>>> > of test cases and the compliance document. And that's a good result. 
>>> > Sometimes
>>> > people do work and don't update tickets.
>>> >
>>> My hazy recollection is that someone looked into this. Maybe in prior
>>> POSIX Compliance projects?
>>
>>
>> Last year when I was porting ndbm.h I made several queries regarding this 
>> directory.
>> Even after doing all the changes correctly, the port was not successful. 
>> Later I found
>> out that the ndbm was calling a hash function from search.h.
>>
>> The headers in this directory need to be updated first. Me and Joel even had
>> discussion about this in newlib mailing list but got no positive response 
>> from them.
>>
>> https://sourceware.org/pipermail/newlib/2019/017046.html
>>
>> https://lists.rtems.org/pipermail/devel/2019-June/026205.html
>
>
> The newlib link doesn't work after the sourceware upgrade :(
>
> Let's assume this code needs to be updated to the latest freebsd and then 
> freebsd ndbm brought over.

Vaibhav, can you help Eshan to understand what you discovered last
year, and work on a plan for this summer to address this challenge?

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

Re: [PATCH] user/gsoc: GSoC Getting Started Instructions

[Chris Johns]

On 2020-03-18 07:36, G S Niteesh Babu wrote:

---
  user/index.rst   |   1 +
  user/start/gsoc.rst  | 453 +++
  user/start/index.rst |   1 +
  3 files changed, 455 insertions(+)
  create mode 100644 user/start/gsoc.rst

diff --git a/user/index.rst b/user/index.rst
index 0e644c9..f253ea6 100644
--- a/user/index.rst
+++ b/user/index.rst
@@ -10,6 +10,7 @@ RTEMS User Manual (|version|).
  
  .. topic:: Copyrights and License
  
+| |copy| 2020 Niteesh Babu

  | |copy| 2019 Vijay Kumar Banerjee
  | |copy| 2018 Amaan Cheval
  | |copy| 2018 Marçal Comajoan Cara
diff --git a/user/start/gsoc.rst b/user/start/gsoc.rst
new file mode 100644
index 000..071c1cc
--- /dev/null
+++ b/user/start/gsoc.rst
@@ -0,0 +1,453 @@
+.. comment: SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. comment: Copyright (C) 2020 Niteesh Babu 
+.. comment: All rights reserved.
+
+
+.. _QuickStartGSoC:
+
+GSoC Getting Started
+
+
+The goal of this page is to help you get RTEMS compiled and running so you can
+start with the real work.
+
+Please join the :r:list:`users` and :r:list:`devel` mailing lists and ask 
questions.
+Help correct any deficiencies in the code or documentation you spot, including
+those on the wiki. The ultimate goal of GSoC is to help you become part of the
+open source community.
+
+.. _QuickStartConfigureComputer:
+
+Configure a Development Computer > +
+
+You will be best served by using a GNU/Linux environment,


This should reference the Host section and ask the student to select one 
of the supported hosts. Recommending a Unix host is fine.



which could be in a
+virtual machine, for example that uses `​Virtualbox 
`_


This is fine.


+and should run on most modern desktop systems. You should also be able to work
+with a MacOS or Windows system, but might encounter more difficulty than a *nix
+environment.


For some people Unix is more difficult.


+
+Feel free to ask questions on the rtems-users mailing list in case you face
+trouble with the steps. If you want tools for another architecture, replace
+sparc in the RSB directions with another architecture, such as arm or mips. You
+can also use the RSB to build RTEMS directly, but we recommend that you learn
+how to build RTEMS by itself with the compiler tools generated by RSB.
+
+As you will be compiling a lot of code, it is recommended to have a reasonably
+fast development machine.
+
+The instructions in this chapter will help you in quickly setting up a
+development environment. For a detailed set of instruction please refer to the
+:ref:`QuickStart` chapter.
+
+You need tools for your host’s operating system to build the RTEMS tool suite
+from source. Please have a look at the :ref:`host-computer` chapter for the
+instructions to install the tools.
+
+Choosing an Installation Prefix
+---


From here on I would prefer references to the existing documentation 
with any GSoC details list here. I would prefer we avoid duplicating 
prefix, sources and building anywhere in the documentaion as it will 
only confuse search engines, normal users and GSoC students. The Quick 
Start Guide has taken a long time to get to where it is. If there is 
something in the Quick Start guide that needs fixing please let me know.


I am sorry I have not commented before now, I have been distracked.

Thanks
Chris


+
+The term ``prefix`` refers to the path on your computer where the software is 
to
+be installed.
+In this case, we choose the home directory ``$HOME/rtems`` as our prefix.
+
+.. code-block:: none
+
+  mkdir $HOME/rtems
+
+Getting Sources
+---
+
+We obtain the source code for the :ref:`RTEMS Source Builder (RSB) ` and
+RTEMS from the RTEMS :r:url:`git`.
+
+The :ref:`RTEMS Source Builder (RSB) ` is the tool used to build RTEMS
+packages from source. We will be using the RSB to build RTEMS the source.
+Please have a look at the :ref:`RTEMS Source Builder (RSB) ` for more
+information.
+
+We'll clone to the repositories to ``$HOME/rtems/src``.
+
+.. code-block:: none
+
+  mkdir -p $HOME/rtems/src
+  cd $HOME/rtems/src
+  git clone git://git.rtems.org/rtems-source-builder.git rsb
+  git clone git://git.rtems.org/rtems.git
+
+Building the Tool suite
+---
+
+Once you have cloned the repositories and installed the required tools for
+your host operating system. You can start building the tools suite for your 
BSP.
+The tools suite is the collection of compiler, debugger, Assembler and other
+tools required for developing the software.
+
+You can check if your host is set up correctly using ``sb-check`` tool provided
+in the RSB repository.
+
+.. code-block:: none
+
+  cd $HOME/rtems/src/rsb/source-builder
+  ./sb-check
+
+If you installed all the required tools you should have the following output.
+
+.. code-block:: none
+
+  RTEMS Source Builder - Check, 5 (0b7e87143b76)
+  

Re: [PATCH v2] bsp/beagle: Update console to new Termios device API.

[Christian Mauderer]

Hello Niteesh,


On 15/03/2020 20:44, G S Niteesh Babu wrote:
> This patch updates the console to use new Termios device API.
> Update #3034
> ---
>  bsps/arm/beagle/console/console-config.c | 66 +++-
>  1 file changed, 41 insertions(+), 25 deletions(-)
> 
> diff --git a/bsps/arm/beagle/console/console-config.c 
> b/bsps/arm/beagle/console/console-config.c
> index 78af5f6a93..860a44cb00 100644
> --- a/bsps/arm/beagle/console/console-config.c
> +++ b/bsps/arm/beagle/console/console-config.c
> @@ -41,6 +41,8 @@
>  #define TX_FIFO_E (1<<5)
>  #define RX_FIFO_E (1<<0)
>  
> +#define UART0 "/dev/ttyS0"
> +

I'm not a big fan of such a generic name for a define. It's quite
possible that it conflicts with another define in the future.

I would suggest BEAGLE_UART0 or similar.

>  static uint8_t beagle_uart_get_register(uintptr_t addr, uint8_t i)
>  {
>uint8_t v;
> @@ -65,34 +67,27 @@ static void beagle_uart_set_register(uintptr_t addr, 
> uint8_t i, uint8_t val)
>reg [i] = val;
>  }
>  
> -console_tbl Console_Configuration_Ports [] = {
> -{
> -  .sDeviceName = "/dev/ttyS0",
> -  .deviceType = SERIAL_NS16550,
> -#if CONSOLE_POLLED   /* option to facilitate running the tests */
> -  .pDeviceFns = _fns_polled,
> -#else
> -  .pDeviceFns = _fns,
> -#endif
> -  .ulMargin = 16,
> -  .ulHysteresis = 8,
> -  .pDeviceParams = (void *) CONSOLE_BAUD,
> -  .ulCtrlPort1 = BSP_CONSOLE_UART_BASE,
> -  .ulDataPort = BSP_CONSOLE_UART_BASE,
> -  .ulIntVector = BSP_CONSOLE_UART_IRQ,
> -  .getRegister = beagle_uart_get_register,
> -  .setRegister = beagle_uart_set_register,
> -  .ulClock = UART_CLOCK,  /* 48MHz base clock */
> -},
> -};
> -
> -unsigned long Console_Configuration_Count = 1;
> +ns16550_context uart_context;
>  
>  static int init_needed = 1; // don't rely on bss being 0
>  
>  static void beagle_console_init(void)
>  {
>if(init_needed) {
> +ns16550_context *ctx;
> +
> +/*
> +   *  Don't rely on BSS being 0
> +*/
> +memset(_context, 0, sizeof(uart_context));
> +ctx = _context;
> +
> +ctx->port = BSP_CONSOLE_UART_BASE;
> +ctx->get_reg = beagle_uart_get_register;
> +ctx->set_reg = beagle_uart_set_register;
> +ctx->clock = UART_CLOCK;
> +ctx->initial_baud = CONSOLE_BAUD;
> +
>  const uint32_t div = UART_CLOCK / 16 / CONSOLE_BAUD;
>  CONSOLE_SYSC = 2;
>  while ((CONSOLE_SYSS & 1) == 0)
> @@ -120,6 +115,8 @@ static void beagle_console_init(void)
>  CONSOLE_LCR = 0x03;
>  CONSOLE_ACR = 0x00;
>  init_needed = 0;
> +
> +BSP_output_char = uart_write_polled;
>}
>  }
>  
> @@ -127,15 +124,17 @@ static void beagle_console_init(void)
>  
>  static void uart_write_polled( char c )
>  {
> -  if(init_needed) beagle_console_init();
> -
>while( ( CONSOLE_LSR & TX_FIFO_E ) == 0 )
>  ;
>CONSOLE_THR8 = c;
>  }
>  
>  static void _BSP_put_char( char c ) {
> -   uart_write_polled( c );
> +
> +  if ( init_needed ) {
> +beagle_console_init();
> +  }
> +  uart_write_polled( c );

Why did you have to move the "if (init_needed)" from uart_write_polled
to _BSP_put_char? It seems that it does the same as long as
_BSP_put_char is called first. But if uart_write_polled is called first,
it will lead to an unitialised hardware, wouldn't it?

By the way: Did you have a look whether there are two functions? They
are both static and it seems that only _BSP_put_char is used. So it
seems a bit odd...

>  }
>  
>  static int _BSP_get_char(void)
> @@ -147,6 +146,23 @@ static int _BSP_get_char(void)
>}
>  }
>  
> +rtems_status_code console_initialize(
> +  rtems_device_major_number major,
> +  rtems_device_minor_number minor,
> +  void *arg
> +)
> +{
> +  rtems_termios_initialize();
> +  rtems_termios_device_install(
> +UART0,
> +_handler_polled,
> +NULL,
> +_context.base
> +  );
> +
> +  return RTEMS_SUCCESSFUL;
> +}
> +
>  BSP_output_char_function_type BSP_output_char = _BSP_put_char;
>  
>  BSP_polling_getchar_function_type BSP_poll_char = _BSP_get_char;
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v8] tests for fenv.h functions

[Eshan dhawan]

---
 testsuites/psxtests/psxfenv01/init.c| 105 +++-
 testsuites/psxtests/psxfenv01/psxfenv01.doc |   9 +-
 testsuites/psxtests/psxfenv01/psxfenv01.scn |   4 -
 3 files changed, 85 insertions(+), 33 deletions(-)

diff --git a/testsuites/psxtests/psxfenv01/init.c 
b/testsuites/psxtests/psxfenv01/init.c
index cdb0fa596e..b088209d7f 100644
--- a/testsuites/psxtests/psxfenv01/init.c
+++ b/testsuites/psxtests/psxfenv01/init.c
@@ -46,11 +46,12 @@
 #include 
 #include 
 #include 
+#include 
 
 const char rtems_test_name[] = "PSXFENV 01";
 
 /* forward declarations to avoid warnings */
-rtems_task Init(rtems_task_argument ignored);
+rtems_task Init( rtems_task_argument ignored );
 
 /* Test Function Begins */
 rtems_task Init(rtems_task_argument ignored)
@@ -62,40 +63,90 @@ rtems_task Init(rtems_task_argument ignored)
 
   /*
* 'FE_ALL_EXCEPT' will be defined only when 'feclearexcept()',
-   * 'fegetexceptflag()', 'feraiseexcept()', 'fesetexceptflag()' and
-   * 'fetestexcept()' functions are supported by the architecture.
+   * fegetexceptflag() , feraiseexcept(), fesetexceptflag() and
+   * fetestexcept() functions are supported by the architecture.
* Hence their testcases can be wrapped under #ifdef and #endif.
*/
   #ifdef FE_ALL_EXCEPT /* floating-point exceptions */
-puts( "fesetenv(FE_DFL_ENV)." );
-r = fesetenv(FE_DFL_ENV);
-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);
-rtems_test_assert( r == 0 );
-
-/* Test 'FE_DIVBYZERO' */
-puts( "Divide by zero and confirm fetestexcept()" );
+r = fesetenv ( FE_DFL_ENV );
+if ( r ) {
+  printf( "fesetenv ==> %d\n", r);
+}
+rtems_test_assert ( r == 0 );
+
+/* Test feclearexcept() and fetestexcept() in one go. */
+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 );
+}
+rtems_test_assert ( r == 0 );
+
+/* Test 'FE_DIVBYZERO' 
+ *Divide by zero and confirm fetestexcept() */
 a = 0.0;
 b = 1.0;
 c = b/a;
 (void) c;
-
-fegetexceptflag(,FE_ALL_EXCEPT);
-
+/* 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 separated by ifdef
+ * Since not all architectures support them 
+ * The test case gets and sets the rounding directions */
+#ifdef FE_TONEAREST
+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 );
+#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
+  
 #ifdef FE_DIVBYZERO
-r = feraiseexcept(FE_DIVBYZERO);
+r = feraiseexcept ( FE_DIVBYZERO ) ;
 rtems_test_assert( fetestexcept( FE_DIVBYZERO ) );
 #endif
 
diff --git a/testsuites/psxtests/psxfenv01/psxfenv01.doc 
b/testsuites/psxtests/psxfenv01/psxfenv01.doc
index 3aa7757496..0238372013 100644
--- a/testsuites/psxtests/psxfenv01/psxfenv01.doc
+++ b/testsuites/psxtests/psxfenv01/psxfenv01.doc
@@ -1,4 +1,4 @@
-#  COPYRIGHT (c) 2019
+#  COPYRIGHT (c) 2019
 #  On-Line Applications Research Corporation (OAR).
 #
 # SPDX-License-Identifier: BSD-2-Clause
@@ -12,8 +12,13 @@ Directives:
   fesetenv
   feclearexcept
   fetestexcept
-  texceptflag
   feraiseexcept
+  fesetexeptflag
+  fegetexeptflag
+  fegetround
+  fesetround
+  
+
 
 Concepts:
 
diff --git a/testsuites/psxtests/psxfenv01/psxfenv01.scn 

Re: rtems-boot-image tool: Raspberry Pi

[Christian Mauderer]

Hello Niteesh,

thanks for the (private) remainder. This thread really stopped quite
some time ago. A lot of us are quite busy right now but that shouldn't
happen. If you don't get a response for some question: Please give it
about a week of time and then just ping the thread.

On 05/03/2020 11:06, G. S. Niteesh wrote:
> On Wed, Feb 26, 2020 at 8:39 AM Chris Johns  > wrote:
> 
> On 22/2/20 1:45 am, G. S. Niteesh wrote:
> > Hi,
> >
> > This is regarding adding RPi support to the boot image generation
> tool.
> >
> > The boot process for Raspberry Pi is very unconventional. The GPU
> starts
> > first, initializes RAM, other hardware, loads the bootloaders and
> then starts
> > the ARM CPU.
> >
> > The minimum files that are required to boot an RPi are
> > bootcode.bin, startx.elf, fixup.dat, kernel.img, config.txt
> > There are also other variants of startx.elf and fixup.dat.
> > Please have a look
> >
> at 
> https://www.raspberrypi.org/documentation/configuration/config-txt/boot.md
> > for information on the variants.
> >
> > From what I have tried on my Rpi3 model b v1.2 the minimum files
> that are
> > required are start_x.elf, fixup_x.dat, bootcode.bin, kernel.img,
> config.txt
> > But for this to work, we must add start_x=1 to config.txt because
> by default
> > start.elf is loaded.
> 
> Hello Chris,
>  
> 
> I would have look at how the tool maps to RPi to know if it needs
> more work :)
> 
> 
> Did you take a look at it?

Chris is most likely too busy with the release right now.

> 
> In my opinion, there are two ways to do it.
> The first would be to modify the U-Boot bootloader object to have a
> files field
> to make sure the user provides all the necessary files(fixup.dat,
> startx.elf, config.txt).
> So after this change the rtems-boot.ini for RPI should look something
> like this
> [u-boot-raspberrypi]
> uses = u-boot-arm-raspberrypi
> ..
> ..
> first_stage = %{ubootdir}/bootcode.bin
> boot_device = mmc 0
> second_stage = uboot or startx
> files = [config.txt, fixup.dat etc]
> But also please keep in mind that if we want to support RPi4 then the
> first_stage
> will start4x.elf since bootcode.bin is now replaced by code in the
> EEPROM in RPi4 SOC.

As far as I understand that approach it more or less tells: To start a
raspberry you need U-Boot. U-Boot needs the fixup.dat, startx.elf and
config.txt to boot. But that sounds a bit wrong. On Raspberry U-Boot is
purely optional, isn't it? So from a high-level view it would be more a

- Raspberry needs fixup.dat, startx.elf and config.txt
- That can start either:
  - an application or
  - an U-Boot which can then start an application (or do other things)

> 
> Another approach will be to create the default Raspberry Pi bootloader
> object. But having
> support for U-Boot is important since it will allow for automatic testing.

That approach sounds more correct. But I don't really know the
rtems-boot-image tool. That makes it a lot harder for me to tell whether
that approach works well. From that ignorant position I would say that
it would be nice to have a boot-image command that can be called with or
without a option (like --with-u-boot). Alternatively maybe two targets
would be possible. One raspiboot-u-boot-pi1 and one raspiboot-raw-pi1.

But your best bet might is to wait for Chris to get free again and
answer that question. He knows the boot image tool and can tell you a
lot better which concept works best.

Best regards

Christian

> 
> Which one do you think is a better approach?
> 
> Thank you.
> 
> 
> >
> > So, what should be the values for the first and second stages in
> rtems-boot.ini
> > for Rpi?
> 
> Would this be bootcode.bin?
> 
> > And also wouldn't it be nice if we could add a files field, which
> will copy the
> > specified files to the image? This would save a lot of typing in
> case of RPi
> 
> Do you have an example?
> 
> Chris
> 
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: possible sources for porting sockatmark() of sys/socket.h

[Eshan Dhawan]

confstr() from unistd.h also shows not supported in the compliance status
but it has some kind of supported in newlib(libc/sys/linux)
it also needs to be updated in the compliance status I think

On Mon, Mar 23, 2020 at 12:37 AM Eshan Dhawan 
wrote:

> https://lists.rtems.org/pipermail/devel/2020-March/058569.html
>
>
> On Mon, Mar 23, 2020 at 12:35 AM Eshan Dhawan 
> wrote:
>
>>
>>
>> On Mon, Mar 23, 2020 at 12:27 AM Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Sun, Mar 22, 2020, 1:55 PM Eshan Dhawan 
>>> wrote:
>>>
 It's present there.
 I hadn't checked there.

>>>
>>> Does that mean the spreadsheet I uploaded yesterday needs updating
>>> again?
>>>
>> yes , the spreadsheet shows not supported.
>> also, I have sent another mail related to this
>> for wordexp.h
>>
>>
>>> Is there a ticket to close?
>>>
>> No the ticket was closed earlier
>> I missed that
>>
>>> Finding something got added without the tracking update is a good outcome
>>>
>>>
 On Mon, Mar 23, 2020 at 12:19 AM Joel Sherrill  wrote:

>
>
> On Sun, Mar 22, 2020, 1:37 PM Eshan Dhawan 
> wrote:
>
>> I have identifies 2 main sources to port sockatmark().
>>
>> NetBSD source:
>> https://github.com/NetBSD/src/blob/trunk/lib/libc/net/sockatmark.c
>>
>> FreeBSD Source :
>>
>> https://github.com/lattera/freebsd/blob/master/lib/libc/net/sockatmark.c
>>
>> musl has a same implementation as in FreeBSD
>> which one would be better to follow.
>>
>
> This has to be in sync with rtems-libbsd and may already be there.
> Please check if it is there. Just closing a ticket and updating the
> spreadsheet is q food result. :)
>
>>
>> thanks
>> -Eshan
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Update POSIX compliance guide

[Eshan Dhawan]

I have also checked wordexp.h is completely present in newlib (libc/include)
the implementation of the functions wordexp.c and wordfree.c  is in
(libc/posix)
But the compliance status shows not supported.


On Sat, Mar 21, 2020 at 11:31 PM Joel Sherrill  wrote:

>
>
>
> On Sat, Mar 21, 2020, 8:47 AM Eshan Dhawan 
> wrote:
>
>> Hello everyone
>>
>> I went through the POSIX Compliance guide and it showed that
>> wcsncasecmp_l () was not supported in wchar.h
>> But when I checked newlib it had been implemented in libc/string
>> so I think it needs to be updated in the docs.
>>
>
> Thanks for spotting this. I did a spot check and think there were a few
> more wc* methods that were not in the spreadsheet. I am going to post a
> patch in a bit.  Please check it.
>
> Obviously, this is a csv file maintained externally in a spreadsheet. If
> you put it in a spreadsheet, you can turn on data filtering based on the
> top row. Then you can do "queries" to do things like filter down to what's
> in a single header file. Or what's required in one standard but not in
> another.
>
> FWIW this turned into a bit of a rat hole. I tried to double check the
> newlib git repo and the link on their website is wrong after the upgrade of
> sourceware.org. Then checked gdb and it had the same issue. This resulted
> in also reporting some leftover cleanup from the recent upgrade of
> sourceware.org.
>
>>
>> Thanks
>> Eshan
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: possible sources for porting sockatmark() of sys/socket.h

[Eshan Dhawan]

It's present there.
I hadn't checked there.

On Mon, Mar 23, 2020 at 12:19 AM Joel Sherrill  wrote:

>
>
> On Sun, Mar 22, 2020, 1:37 PM Eshan Dhawan 
> wrote:
>
>> I have identifies 2 main sources to port sockatmark().
>>
>> NetBSD source:
>> https://github.com/NetBSD/src/blob/trunk/lib/libc/net/sockatmark.c
>>
>> FreeBSD Source :
>> https://github.com/lattera/freebsd/blob/master/lib/libc/net/sockatmark.c
>>
>> musl has a same implementation as in FreeBSD
>> which one would be better to follow.
>>
>
> This has to be in sync with rtems-libbsd and may already be there. Please
> check if it is there. Just closing a ticket and updating the spreadsheet is
> q food result. :)
>
>>
>> thanks
>> -Eshan
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: possible sources for porting sockatmark() of sys/socket.h

[Joel Sherrill]

On Sun, Mar 22, 2020, 1:37 PM Eshan Dhawan  wrote:

> I have identifies 2 main sources to port sockatmark().
>
> NetBSD source:
> https://github.com/NetBSD/src/blob/trunk/lib/libc/net/sockatmark.c
>
> FreeBSD Source :
> https://github.com/lattera/freebsd/blob/master/lib/libc/net/sockatmark.c
>
> musl has a same implementation as in FreeBSD
> which one would be better to follow.
>

This has to be in sync with rtems-libbsd and may already be there. Please
check if it is there. Just closing a ticket and updating the spreadsheet is
q food result. :)

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

possible sources for porting sockatmark() of sys/socket.h

[Eshan Dhawan]

I have identifies 2 main sources to port sockatmark().

NetBSD source:
https://github.com/NetBSD/src/blob/trunk/lib/libc/net/sockatmark.c

FreeBSD Source :
https://github.com/lattera/freebsd/blob/master/lib/libc/net/sockatmark.c

musl has a same implementation as in FreeBSD
which one would be better to follow.

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

[PATCH] This patch provides usage of RTEMS cross-compiler over GCC cross-compiler

[utkarsh.ra...@gmail.com]

Really sorry for a new patch, I somehow rm -rf'ed my machine's root
---
 user/start/tools.rst | 16 
 1 file changed, 16 insertions(+)

diff --git a/user/start/tools.rst b/user/start/tools.rst
index c3f039b..3bb939e 100644
--- a/user/start/tools.rst
+++ b/user/start/tools.rst
@@ -76,3 +76,19 @@ source code used.
 
 
 Add ``--verbose`` to the GCC command for the the verbose version details.
+
+Need for RTEMS-Specific Cross-Compiler
+
+  New users are often confused as to why they can't use their distribution's 
cross-compiler for their target on rtems, e.g.,the riscv64-linux-gnu or the 
arm-none-eabi-gcc. Below mentioned are some of the reasons for using the RTEMS 
cross-compiler.
+
+ ``Correct configuration of newlib`` -
+Newlib is a C standard library implementation intended for use on embedded 
systems. Most of the POSIX and libc support for RTEMS is derived from newlib. 
The RTEMS cross-compiler configures newlib correctly for RTEMS.
+
+ ``Threading in GCC support libraries`` -
+GCC support threading libraries such as ``pthread.h`` provide threading 
support to an application; these libraries are tailored according to RTEMS 
using the RTEMS cross-compiler.
+   
+ ``Provide preprocessor define __rtems__`` -
+The ``__rtems__`` preprocessor define is used to provide conditional code 
compilation in source files that are shared with other projects e.g. in newlib 
or imported code from freebsd.
+
+ ``Multilib variants to match the BSP``-
+RTEMS configures GCC to create separate runtime libraries for each 
supported instruction set, floating point unit, vector unit, word size (e.g. 
32-bit and 64-bit), endianness, ABI, processor errata workarounds,and so on in 
the architecture. These libraries are termed multilib variants. Multilibs 
variants to match the BSP are set by selecting a specific set of machine 
options using the RTEMS cross-compiler.
-- 
2.17.1

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

[PATCH 1/1] bsps: Deletes erc32-run.ini

[clrrm]

From: Cláudio Maia 

---
 tester/rtems/testing/bsps/erc32-run.ini | 38 -
 1 file changed, 38 deletions(-)
 delete mode 100644 tester/rtems/testing/bsps/erc32-run.ini

diff --git a/tester/rtems/testing/bsps/erc32-run.ini 
b/tester/rtems/testing/bsps/erc32-run.ini
deleted file mode 100644
index 3dc5f60..000
--- a/tester/rtems/testing/bsps/erc32-run.ini
+++ /dev/null
@@ -1,38 +0,0 @@
-#
-# RTEMS Tools Project (http://www.rtems.org/)
-# Copyright 2015 On-Line Applications Research Corporation (OAR).
-# All rights reserved.
-#
-# This file is part of the RTEMS Tools package in 'rtems-tools'.
-#
-# 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 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.
-#
-
-#
-# The erc32 BSP
-#
-[erc32-run]
-bsp  = erc32
-arch = sparc
-tester   = %{_rtscripts}/run.cfg
-bsp_run_cmd  = %{rtems_tools}/%{bsp_arch}-rtems%{rtems_version}-run
-- 
2.17.1

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

[PATCH 0/1] Removes erc32-run.ini from rtems-tools repo

[clrrm]

From: Cláudio Maia 

This BSP uses 'sparc-rtems5-run' which is not being generated anymore after 
compiling the toolchain. Consequently, its execution fails when being used
(i.e., when using '--rtems-bsp=erc32-run'). Thus, to make things consistent
I propose to remove this file. 

Cláudio Maia (1):
  bsps: Deletes erc32-run.ini

 tester/rtems/testing/bsps/erc32-run.ini | 38 -
 1 file changed, 38 deletions(-)
 delete mode 100644 tester/rtems/testing/bsps/erc32-run.ini

-- 
2.17.1

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

Re: Python Standardization

[Amar Takhar]

Hello Anmol.

Gedare covered essentially what this project covers.

To add a little further we want to push all the tools behind a common 
accessible 
API with the frontend tools being a thin wrapper.

This will allow us to have better testing of our tools as well as easing 
maintenance by encouraging more self consumption and standard Python methods 
for 
CLI console, logging and file access -- not limited to just these however.


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

[PATCH 3/6] user/tools/tester.rst: Clarifies the need of --rtems-tools in rtems-test command line

[clrrm]

From: Cláudio Maia 

---
 user/tools/tester.rst | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/user/tools/tester.rst b/user/tools/tester.rst
index 96e32ed..32e1ca2 100644
--- a/user/tools/tester.rst
+++ b/user/tools/tester.rst
@@ -281,7 +281,6 @@ BSP build tree:
 $ ~/development/rtems/test/rtems-tools.git/tester/rtems-test \
  --log=log_erc32_run \
  --rtems-bsp=erc32-run \
- --rtems-tools=$HOME/development/rtems/5 \
  sparc-rtems5/c/erc32/testsuites/samples
 RTEMS Testing - Tester, 5.not_released
 [ 1/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  | sparc/erc32: base_sp.exe
@@ -317,7 +316,6 @@ appearance above, we have the following:
 * The ``--log`` option sends the output to a log file. By default only failed
   tests log the complete output.
 * The ``--rtems-bsp`` option selects the erc32 BSP.
-* The path to the RTEMS tools so GDB can be found.
 * The path to the erc32 BSP tests to run. If you add subdirectories
   to the path specific tests can be run.
 * The test results so far. See details below.
@@ -333,10 +331,13 @@ appearance above, we have the following:
   ``sparc-rtems5/c/erc32/testsuites/samples`` then all the executables
   would have been tested and not just those in samples.
 
-This BSP requires the ``--rtems-tools`` option because the SPARC GDB is the
-``sparc-rtems4.11-gdb`` command that is part of the RTEMS tools. Not every BSP
-will require this option so you will need to check the specifics of the BSP
-configuration to determine if it is needed.
+.. note:: Some BSPs require the use of the specific target architecture GDB
+  command (e.g. RTEMS 5 SPARC GDB command is ``sparc-rtems5-gdb``).
+  As this command is part of the RTEMS tools, the ``--rtems-tools``
+  option should be added to the ``rtems-test`` command line, e.g.
+  ``--rtems-tools=$HOME/development/rtems/5``.
+  Not every BSP requires this option so you will need to check the
+  specifics of the BSP configuration to determine if this option is 
needed.
 
 An output line is printed for each test that is executed. The 
:program:`rtems-test`
 command by default runs multiple tests in parallel so you will see a number
-- 
2.17.1

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

[PATCH 6/6] user/tools/tester.rst: Removes text references to 'erc32-run' and replaces the example with 'erc32-sis'

[clrrm]

From: Cláudio Maia 

---
 user/tools/tester.rst | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/user/tools/tester.rst b/user/tools/tester.rst
index 5147f3d..5548ad9 100644
--- a/user/tools/tester.rst
+++ b/user/tools/tester.rst
@@ -62,11 +62,9 @@ You can list the available BSP testers with:
   project.
 
 Some of the BSPs may appear more than once in the list. These are aliased BSP
-configurations that may use a different back-end. An example is the erc32 BSP.
-There is the erc32 tester which uses the GDB back-end and the
-``erc32-run`` tester which uses the ``run`` command for erc32. We will show
-how to use :program:`rtems-test` command with the erc32 BSP because it is easy
-to build an use.
+configurations that may use a different back ends. We will show how to use
+:program:`rtems-test` command with the erc32 BSP because it is easy to build
+and use.
 
 .. _BuildingRTEMSTests:
 
@@ -267,8 +265,8 @@ BSP build tree:
 .. code-block:: none
 
 $ ~/development/rtems/test/rtems-tools.git/tester/rtems-test \
- --log=log_erc32_run \
- --rtems-bsp=erc32-run \
+ --log=log_erc32_sis \
+ --rtems-bsp=erc32-sis \
  sparc-rtems5/c/erc32/testsuites/samples
 RTEMS Testing - Tester, 5.not_released
 [ 1/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  | sparc/erc32: base_sp.exe
-- 
2.17.1

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

[PATCH 4/6] user/tools/tester.rst: Rephrase last sentence

[clrrm]

From: Cláudio Maia 

---
 user/tools/tester.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/user/tools/tester.rst b/user/tools/tester.rst
index 32e1ca2..a95651e 100644
--- a/user/tools/tester.rst
+++ b/user/tools/tester.rst
@@ -586,6 +586,6 @@ review the available options by using the ``--help`` option:
 --trace  : Trace the execution
 --warn-all   : Generate warnings
 
-.. note:: The list of options is growing according to the needs of each 
release.
-  Please see the available options for the release you are using for 
-  more information.
+.. note:: The list of options may be different for each release. For more
+  information, please see the available options for the release
+  you are using.
-- 
2.17.1

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

[PATCH 1/6] user/tools/tester.rst: Cleans up text

[clrrm]

From: Cláudio Maia 

---
 user/tools/tester.rst | 153 ++
 1 file changed, 82 insertions(+), 71 deletions(-)

diff --git a/user/tools/tester.rst b/user/tools/tester.rst
index c3c3fe2..44263da 100644
--- a/user/tools/tester.rst
+++ b/user/tools/tester.rst
@@ -10,26 +10,26 @@ RTEMS Tester and Run
 .. index:: Tools, rtems-test, rtems-run
 
 The RTEMS Tester is a test tool that provides a command line interface to run
-test executable on supported targets. The tool provides back-end support for
+test executables on supported targets. The tool provides back-end support for
 common simulators, debuggers and boot loaders. Board support package (BSP)
 configurations for RTEMS are provided and can be used to run all the tests in
-the RTEMS test suite. The tool and it's framework is not specific to RTEMS and
+the RTEMS test suite. The tool and its framework is not specific to RTEMS and
 can be configured to run any suitable application.
 
 RTEMS is an embedded operating system and is cross-compiled on a range of host
-machines. The executables run on the target hardware and this can vary widely
+machines. The executables run on hardware which can vary widely
 from open source simulators, commercial simulators, debuggers with simulators,
-debuggers with hardware specific pods and devices to targe boot
-loaders. Testing RTEMS requires the cross-compiled test executable is
-transferred to the target hardware, executed and the output captured and
+debuggers with hardware specific pods and devices, and target boot
+loaders. Testing RTEMS requires that the cross-compiled test executable is
+transferred to the target hardware, executed, the output captured and
 returned to the test host where it is analyzed to determine the test
 result.
 
 Running the RTEMS tests on your target is very important. It provides you with
 a traceable record showing that your RTEMS version and its tools are working at
 the level the RTEMS development team expect when releasing RTEMS. Being able to
-easily run the tests and verify the results is critical in maintaining a high
-standard.
+easily run the tests and verify the results is critical in maintaining high
+standards.
 
 Available BSP testers
 -
@@ -63,7 +63,7 @@ You can list the available BSP testers with:
 
 Some of the BSPs may appear more than once in the list. These are aliased BSP
 configurations that may use a different back-end. An example is the erc32 BSP.
-There is the ``erc32`` tester which uses the GDB back-end and the
+There is the erc32 tester which uses the GDB back-end and the
 ``erc32-run`` tester which uses the ``run`` command for erc32. We will show
 how to use :program:`rtems-test` command with the erc32 BSP because it is easy
 to build an use.
@@ -84,19 +84,20 @@ configure after running ``bootstrap``.
 --enable-tests --enable-rtemsbsp=erc32
 $ make
 
-Add the `-j` option to the make command with the number of cores to run a
-parallel build.
+Add the `-j` option to the make command with the number of parallel jobs to 
run a
+parallel build (e.g. `-j 8`).
 
 Building all the tests takes time and it uses more disk so be patient. When
-finished all the tests will have been built. Some BSPs may require a post-build
-process to be run on the RTEMS ELF executable to create an image suitable for
-execution. This can be built into the configuration script and the tester will
-perform a pre-test command to covert the executable to a suitable format for
-your target.
+make finishes, all the tests will have been built. 
+
+.. note:: Some BSPs may require a post-build process to be run on the RTEMS 
ELF 
+  executable to create an image suitable for execution. This can be 
built
+  into the configuration script and the tester will perform a pre-test 
+  command to covert the executable to a suitable format for your 
target.
 
 Before running all the tests it is a good idea to run the ``hello`` test. The
 ``hello`` test is an RTEMS version of the classic "Hello World" example and
-running it shows you have a working tool chain and build of RTEMS ready to run
+running it shows you have a working toolchain and build of RTEMS ready to run
 the tests. Using the run with the ERC32 BSP the command is:
 
 .. code-block:: none
@@ -145,14 +146,14 @@ Running the example using SIS:
 
 sis> q
 
-The examples can also be run using GDB with SIS as the backend. SIS can be 
connected to
+The examples can also be run using GDB with SIS as the back end. SIS can be 
connected to
 gdb through a network socket using the gdb remote interface.
 
-Either start SIS with ``-gdb``, or issue the ``gdb`` command inside SIS, and 
connect
+Either start SIS with ``-gdb`` or issue the ``gdb`` command inside SIS, and 
connect
 gdb with ``target remote:1234``. The default port is ``1234``, the port can be 
changed
 using the ``-port`` option.
 
-Open a terminal and issue the command:
+Open a terminal 

[PATCH 2/6] user/tools/tester.rst: Removes wrong reference to GDB break points

[clrrm]

From: Cláudio Maia 

---
 user/tools/tester.rst | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/user/tools/tester.rst b/user/tools/tester.rst
index 44263da..96e32ed 100644
--- a/user/tools/tester.rst
+++ b/user/tools/tester.rst
@@ -260,9 +260,6 @@ You can see your executable running in the first terminal.
 
 For more information on the sis simulator refer to this doc: 
https://gaisler.se/sis/sis.pdf
 
-The command ``r`` is used to debug set break points before issuing the GDB
-``run`` command.
-
 There are currently close to 500 separate tests and you can run them all with a
 single RTEMS Tester command.
 
-- 
2.17.1

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

[PATCH 5/6] user/tools/tester.rst: Removes example using 'sparc-rtems5-run'

[clrrm]

From: Cláudio Maia 

---
 user/tools/tester.rst | 14 +-
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/user/tools/tester.rst b/user/tools/tester.rst
index a95651e..5147f3d 100644
--- a/user/tools/tester.rst
+++ b/user/tools/tester.rst
@@ -98,19 +98,7 @@ make finishes, all the tests will have been built.
 Before running all the tests it is a good idea to run the ``hello`` test. The
 ``hello`` test is an RTEMS version of the classic "Hello World" example and
 running it shows you have a working toolchain and build of RTEMS ready to run
-the tests. Using the run with the ERC32 BSP the command is:
-
-.. code-block:: none
-
-$ sparc-rtems5-run sparc-rtems5/c/erc32/testsuites/samples/hello/hello.exe
-
-*** BEGIN OF TEST HELLO WORLD ***
-Hello World
-*** END OF TEST HELLO WORLD ***
-
-The run command is the GDB simulator without the GDB part.
-
-Running the example using SIS:
+the tests. Running the example using SIS:
 
 .. code-block:: none
 
-- 
2.17.1

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

Re: [PATCH] user/gsoc: GSoC Getting Started Instructions

[Niteesh G. S.]

On Sun, Mar 22, 2020 at 7:42 PM Gedare Bloom  wrote:

> Hi Niteesh,
>
> Did you build the docs with this change
>
Yes, I did. Did you face any issues?
I am sorry for typos and grammatical mistakes. I checked a couple of times
but still
missed them.

> The rewrite is nice. I do have several comments below to address:
>
> On Tue, Mar 17, 2020 at 2:36 PM G S Niteesh Babu 
> wrote:
> >
> > ---
> >  user/index.rst   |   1 +
> >  user/start/gsoc.rst  | 453 +++
> >  user/start/index.rst |   1 +
> >  3 files changed, 455 insertions(+)
> >  create mode 100644 user/start/gsoc.rst
> >
> > diff --git a/user/index.rst b/user/index.rst
> > index 0e644c9..f253ea6 100644
> > --- a/user/index.rst
> > +++ b/user/index.rst
> > @@ -10,6 +10,7 @@ RTEMS User Manual (|version|).
> >
> >  .. topic:: Copyrights and License
> >
> > +| |copy| 2020 Niteesh Babu
> >  | |copy| 2019 Vijay Kumar Banerjee
> >  | |copy| 2018 Amaan Cheval
> >  | |copy| 2018 Marçal Comajoan Cara
> > diff --git a/user/start/gsoc.rst b/user/start/gsoc.rst
> > new file mode 100644
> > index 000..071c1cc
> > --- /dev/null
> > +++ b/user/start/gsoc.rst
> > @@ -0,0 +1,453 @@
> > +.. comment: SPDX-License-Identifier: CC-BY-SA-4.0
> > +
> > +.. comment: Copyright (C) 2020 Niteesh Babu 
> > +.. comment: All rights reserved.
> We don't really use this phrase.
>
This was inspired by this source. Should I change that also?
https://devel.rtems.org/wiki/Docs/New_Chapter#License

> > +
> > +
> only 1 blank
>
> > +.. _QuickStartGSoC:
> > +
> > +GSoC Getting Started
> > +
> > +
> > +The goal of this page is to help you get RTEMS compiled and running so
> you can
> I think the intro at least will be better in the 3rd person for the
> manual version. Replace first "you" with "new users, especially
> students, " and replace second "you" with "they"
>
> > +start with the real work.
> > +
> > +Please join the :r:list:`users` and :r:list:`devel` mailing lists and
> ask questions.
> > +Help correct any deficiencies in the code or documentation you spot,
> including
> > +those on the wiki. The ultimate goal of GSoC is to help you become part
> of the
> replace "you" with "students"
>
> You can keep it in second-person below that is fine for now.
>
> > +open source community.
> > +
> > +.. _QuickStartConfigureComputer:
> > +
> > +Configure a Development Computer
> > +
> > +
> > +You will be best served by using a GNU/Linux environment, which could
> be in a
> > +virtual machine, for example that uses `Virtualbox <
> https://www.virtualbox.org/>`_
> > +and should run on most modern desktop systems. You should also be able
> to work
> > +with a MacOS or Windows system, but might encounter more difficulty
> than a *nix
> > +environment.
> > +
> > +Feel free to ask questions on the rtems-users mailing list in case you
> face
> :r:list:`users`
>
> > +trouble with the steps. If you want tools for another architecture,
> replace
> > +sparc in the RSB directions with another architecture, such as arm or
> mips. You
> s/another/that
>
> > +can also use the RSB to build RTEMS directly, but we recommend that you
> learn
> > +how to build RTEMS by itself with the compiler tools generated by RSB.
> > +
> > +As you will be compiling a lot of code, it is recommended to have a
> reasonably
> > +fast development machine.
> > +
> > +The instructions in this chapter will help you in quickly setting up a
> > +development environment. For a detailed set of instruction please refer
> to the
> typo: instructions
>
> > +:ref:`QuickStart` chapter.
> > +
> > +You need tools for your host’s operating system to build the RTEMS tool
> suite
> > +from source. Please have a look at the :ref:`host-computer` chapter for
> the
> > +instructions to install the tools.
> > +
> After the chapter by Utkarsh about cross-compilers is merged, it would
> be good to add a sentence here with a ref.
>

I'll send in a patch once his work gets merged.


> > +Choosing an Installation Prefix
> > +---
> > +
> > +The term ``prefix`` refers to the path on your computer where the
> software is to
> > +be installed.
> > +In this case, we choose the home directory ``$HOME/rtems`` as our
> prefix.
> > +
> > +.. code-block:: none
> > +
> > +  mkdir $HOME/rtems
> > +
> > +Getting Sources
> > +---
> > +
> > +We obtain the source code for the :ref:`RTEMS Source Builder (RSB)
> ` and
> > +RTEMS from the RTEMS :r:url:`git`.
> > +
> > +The :ref:`RTEMS Source Builder (RSB) ` is the tool used to build
> RTEMS
> > +packages from source. We will be using the RSB to build RTEMS the
> source.
> "from" missing?
>
> > +Please have a look at the :ref:`RTEMS Source Builder (RSB) ` for
> more
> > +information.
> > +
> > +We'll clone to the repositories to ``$HOME/rtems/src``.
> "to the" -> "the"
>
> > +
> > +.. code-block:: none
> > +
> > +  mkdir -p $HOME/rtems/src
> > +  cd $HOME/rtems/src
> > +  git 

[PATCH 0/6] Proposes fixes for RTEMS Tester documentation page

[clrrm]

From: Cláudio Maia 

This set of patches proposes several fixes for RTEMS Tester
documentation. Namely:

- Text was reviewed and improved for clarity;
- References to 'sparc-rtems5-run' command and 'erc32-run' were removed
  from the documentation page. Now, the example uses 'erc32-sis' instead.

Further references to 'sparc-rtems5-run' are still in other parts of the
documentation (Sections 10.2 and 10.3) which also need to be updated in
the future.

In addition to this, I will send another patch in a different email
which removes 'erc32-run.ini' from 'rtems-tools' repo as this BSP
configuration uses 'sparc-rtems5-run'.

Cláudio Maia (6):
  user/tools/tester.rst: Cleans up text
  user/tools/tester.rst: Removes wrong reference to GDB break points
  user/tools/tester.rst: Clarifies the need of --rtems-tools in
rtems-test command line
  user/tools/tester.rst: Rephrase last sentence
  user/tools/tester.rst: Removes example using 'sparc-rtems5-run'
  user/tools/tester.rst: Removes text references to 'erc32-run' and
replaces the example with 'erc32-sis'

 user/tools/tester.rst | 191 --
 1 file changed, 93 insertions(+), 98 deletions(-)

-- 
2.17.1

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

Re: riscv BSPs on Spike due to weird RSB side-effect

[Joel Sherrill]

I got feedback on this issue with the Spike project and just sent them a
pull request to fix this and add more files to their .gitignore.

Once those are settled, I will update the RSB and close our ticket (I hope).

--joel

On Sat, Mar 21, 2020 at 1:56 PM Gedare Bloom  wrote:

> On Sat, Mar 21, 2020 at 12:19 PM Joel Sherrill  wrote:
> >
> >
> >
> > On Fri, Mar 20, 2020 at 8:14 PM Joel Sherrill  wrote:
> >>
> >>
> >>
> >> On Fri, Mar 20, 2020 at 7:56 PM Joel Sherrill  wrote:
> >>>
> >>> Hi
> >>>
> >>> I think something is wrong with the build of spike that ends up with
> >>> a hard-coded path to inside a build tree:
> >>>
> >>> Result: invalidTime: 0:00:01.197748 mimfs_fslink.exe
> >>> =>  run: spike --isa=RV32IAC
> ./riscv-rtems5/c/rv32iac/testsuites/fstests/mimfs_fslink.exe
> >>> ] Failed to run
> /home/joel/rtems-cron-5/rtems-source-builder/bare/build/tmp/sb-1001/devel/spike/home/joel/rtems-cron-5/tools/5/bin/dtc:
> No such file or directory
> >>> ] Child dtb process failed
> >>>
> >>> https://lists.rtems.org/pipermail/build/2020-March/02.html
> >>>
> >>> Does spike work if there isn't this problem?
> >>>
> >>> I can poke at the host exes to see if the dtc path is hard-coded.
> Otherwise, this seems very strange.
> >>
> >>
> >> I can confirm that spike built with the RSB has the hard-coded
> >> path to dtc that is in the temporary RSB build/staging directories.
> >>
> >> $ strings spike | grep dtc
> >>
> /home/joel/rtems-cron-5/rtems-source-builder/bare/build/tmp/sb-1001/devel/spike/home/joel/rtems-cron-5/tools/5/bin/dtc
> >> Failed to run
> /home/joel/rtems-cron-5/rtems-source-builder/bare/build/tmp/sb-1001/devel/spike/home/joel/rtems-cron-5/tools/5/bin/dtc:
> >
> >
> > Picking more, its configure.ac script is putting the full path of DTC
> in config.h. :(
> >
> > * Path to the device-tree-compiler */
> > #define DTC "/home/joel/rtems-work/tools/5/bin/dtc"
> >
> > This seems horribly stupid. The fix seems to be that it should not have
> a fully qualified path.
> >
> > Anyone want to comment on the specific root cause?
>
> autotools
>
> >>>
> >>> Any ideas?
> >>>
> >>> --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: Python Standardization

[Sebastian Huber]

On 22/03/2020 14:33, Gedare Bloom wrote:


On Sun, Mar 22, 2020 at 7:07 AM Anmol Mishra  wrote:

Hello,
Since you clarified the motivation for API, I need to ask a few questions which 
will help me.

1. By API, Do you mean a wrapper or a common access point to test/access all 
the utilities? If yes, Is REST API is expected like a dashboard?

2. Is there any active API?

I know this question may seem to be naive but I need to discuss it and 
clarification is better than any wrong interpretation. All dev members can help 
me, I will really appreciate it.


To get better participation you might want to use a more specific
subject line and provide some extra context to your question.

The project idea is about defining a uniform/consistent interface for
using different products located primarily in rtems-tools.git The
project idea ticket says:
  * A general RTEMS tool library with a standard API to handle common tasks.
  * All utilities callable as a function within the API with the tool
itself being a thin layer.
  * Testing on all API commands under both Python 2.x and 3.x.
API is taken as the original meaning of "application programming
interface" to mean how applications will use the tool library. This
has nothing to do with web services. I hope that helps with some of
your confusion.

Many of the "home-grown" RTEMS tools have relatively consistent
command line interfaces (CLI), but I can't speak to their API; a lot
of them were designed to be used on the command line, which could also
be used as an API but it is not efficient because you generally have
to invoke the tool in a subprocess in such cases.


To identify which modules in rtems-tools are intended to be reusable 
components you can grep for import statements. This shows for example 
that the rtemstoolkit is intended to be reused, e.g.


grep -r --include='*.py' 'import\s' -h . | grep rtems | sort | uniq -c
  5 from rtemstoolkit import check
  1 from rtemstoolkit import config
  4 from rtemstoolkit import configuration
  1 from rtemstoolkit import configuration as configuration_
 30 from rtemstoolkit import error
 15 from rtemstoolkit import execute
  3 from rtemstoolkit import git
  8 from rtemstoolkit import host
 17 from rtemstoolkit import log
  1 from rtemstoolkit import macros
  4 from rtemstoolkit import macros
  2 from rtemstoolkit import mailer
  1 from rtemstoolkit import options
  5 from rtemstoolkit import options
 23 from rtemstoolkit import path
  2 from rtemstoolkit import reraise
  2 from rtemstoolkit import rtems
  4 from rtemstoolkit import stacktraces
  2 from rtemstoolkit import textbox
  1 from rtemstoolkit import version
  9 from rtemstoolkit import version
  2 import rtems

For example rtemstoolkit.error is imported in 30 other modules. This 
looks like a good candidate to get started with unit testing.


Testing the command line tools is also important. We need a good testing 
framework for this. This usually involves setting up a temporary 
directory with some defined content. Starting command line tools as 
subprocesses, capturing the stdout and stderror, inspecting the 
directory, etc.


All this testing work should be accompanied by updates of the Python 
Guidelines.


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

Re: Ticket #2974 Enable search.h functionality in newlib

[Joel Sherrill]

On Sun, Mar 22, 2020, 1:58 AM Vaibhav Gupta 
wrote:

>
>> > My very quick review shows that this may all be present and then it is
>> a matter
>> > of test cases and the compliance document. And that's a good result.
>> Sometimes
>> > people do work and don't update tickets.
>> >
>> My hazy recollection is that someone looked into this. Maybe in prior
>> POSIX Compliance projects?
>>
>
> Last year when I was porting ndbm.h I made several queries regarding this
> directory.
> Even after doing all the changes correctly, the port was not successful.
> Later I found
> out that the ndbm was calling a hash function from search.h.
>
> The headers in this directory need to be updated first. Me and Joel even
> had
> discussion about this in newlib mailing list but got no positive response
> from them.
>
> https://sourceware.org/pipermail/newlib/2019/017046.html
>
> https://lists.rtems.org/pipermail/devel/2019-June/026205.html
>

The newlib link doesn't work after the sourceware upgrade :(

Let's assume this code needs to be updated to the latest freebsd and then
freebsd ndbm brought over.

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

Re: Adding GDB BSPs to rtems-tester

[Joel Sherrill]

On Sun, Mar 22, 2020, 8:43 AM Gedare Bloom  wrote:

> On Sun, Mar 22, 2020 at 1:40 AM Niteesh G. S. 
> wrote:
> >
> > I built mips jmr3904. I was able to run rtems-run and rtems-test on it.
> > But cdtest.exe fails.
> > *** TESTING C++ EXCEPTIONS ***
> > mips-core: 1 byte read to unmapped address 0x2ed31 at 0x880290a4
> > Program received signal SIGBUS, Bus error.
> > 0x88028fe4 in strlen ()
> > What is causing this error?
> This shows that the strlen function is accessing a bad address
> (0x2ed31). In fact, this is part of the value of the jmr3904 simulator
> and why we want to get it working for routine testing, because it can
> catch bad memory errors.
>
> > I tried running this manually on GDB. On forcefully continuing.
> The next step is not to forcefully continue, but to work backwards
> from the failure in GDB. print a stack backtrace ('bt' command) to see
> how it got to strlen. Look at the values of the registers you can
> observe. Compare with the code in the example and trace the example
> code forward along the path shown by the backtrace. Use GDB to
> investigate the stack frames ('up' and 'down' commands).
>
> > Warning, resuming with mismatched exception signal (7 vs 10)
> After an unmapped address access, nothing else that executes is going
> to be valid.
>
> > Unhandled exception 7
> > sr: 0x536936196  cause: 0x00029724 --> Data Bus Error
> >
> > *** FATAL ***
> > fatal source: 1 (INTERNAL_ERROR_RTEMS_API)
> > fatal code: 9800724312699699200 (0x1)
> > RTEMS version: 5.0.0.37e7cc5f4ce7ed46b5ea2de56d9066d121d851cb-modified
> > RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB 5 (0b7e87143b76), Newlib
> fbaa096)
> > executing thread ID: 0x08a010001
> > executing thread name: CTOR
> >
> > Is this problem with the BSP or simulator? And how can I fix this?
>
> Most likely it is a problem with newlib.
>

Random guess. A section, stack, or malloced memory is not properly aligned.

--joel

>
> >
> > On Sat, Mar 21, 2020 at 11:33 PM Joel Sherrill  wrote:
> >>
> >>
> >>
> >> On Sat, Mar 21, 2020 at 10:38 AM Niteesh G. S. 
> wrote:
> >>>
> >>> Which architecture should I try then? Maybe powerpc or mips? If you
> have any
> >>> of them already built can you please try them out? Building everything
> from
> >>> source takes a lot of time in my dev machine.
> >>>
> >>> On Sat, Mar 21, 2020 at 6:41 PM Gedare Bloom  wrote:
> 
>  On Sat, Mar 21, 2020 at 12:54 AM Niteesh G. S. 
> wrote:
>  >
>  > On Thu, Mar 19, 2020 at 11:43 PM Gedare Bloom 
> wrote:
>  >>
>  >> On Thu, Mar 19, 2020 at 11:56 AM Niteesh G. S. <
> niteesh...@gmail.com> wrote:
>  >> >
>  >> > Hello,
>  >> >
>  >> > While looking for small tasks to take up, Gedare mentioned about
> adding GDB BSPs
>  >> > to rtems-tester. Can some please explain a bit more of what has
> to be done? I guess
>  >> > we have to write configuration files for BSPs that support
> simulation in GDB. If so, how
>  >> > could I find those BSPs, do I have to individually look at all
> the BSPs?
>  >> >
>  >> As I said off-list, I don't know if there's a list of GDB BSPs,
> but I
>  >> know of at least:
>  >> powerpc/psim
>  >> mips/jmr3904
>  >> moxie/moxiesim
>  >> arm/gdbarmsim
>  >> sh/shsim
>  >>
>  >> I have no idea what any of their statuses are or if they are
> expected
>  >> to work. The first step would be building them and see if they run
>  >> anything. After that, you should look at the existing tester
> scripts for
>  >> some targets:
>  >>   rtems-tools.git/tester/rtems/testing/bsps
>  >> I see scripts for most of what I listed above, so the next step
> would
>  >> be trying to run them via tester and see if it works.
>  >
>  >
>  > I built the simsh1 BSP but couldn't get it running. Before trying
> it with rtems-run
>  > and rtems-test I tried manually loading it in the simulator. But
> gdb doesn't respond
>  > as soon as I execute the run command. The only way to exit it was
> using ctrl-c and GDB
>  > responds with
>  > sim_events_schedule_after_signal - buffer overflow
>  > Quit
>  > Aborted (core dumped)
>  > I tried setting breakpoints within GDB but it never seems to hit
> them. I tried running the
>  > examples through rtems-test results in ta imeout.
>  >
>  > Due to the slow internet connection and slow development machine, I
> could only build
>  > and test a few BSPs. In case if anyone has an already built tool
> suite and BSP for the
>  > mentioned arch please try them out.
>  >
>  I don't know that anyone uses this architecture. Don't spend too much
>  effort trying to debug the simulator :)
> >>
> >>
> >> mips jmr3904 and powerpc psim should work well.
> >>
> >> I agree with Gedare, spending a lot of time on the SH isn't high payoff.
> >> I'm glad for the report but there could be bitrot in the simulator or
> BSP.
> >>
> 
> 
>  >> BTW: Did I 

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

[Gedare Bloom]

On Sun, Mar 22, 2020 at 3:59 AM Eshan Dhawan  wrote:
>
>
>
> On Sun, Mar 22, 2020 at 12:21 AM Gedare Bloom  wrote:
>>
>> I liked it better before, when the test prints nothing if it is
>> successful. I think this is the trend we are heading toward in rtems
>> tests.
>>
> I will incorporate more changes to the test so there is minimal printing if 
> the test is successful
> The test is originally written by @Vaibhav Gupta
> it would require to do minor changes in the previous parts of the test as well
> should i do that ??
Yes that would be good.

>>
>> On Sat, Mar 21, 2020 at 11:46 AM Eshan Dhawan  
>> wrote:
>> >
>> > I ran the code using qemu for risc-v architecture.
>> > The value of r = 0 for the function to run without error
>> > while the error is raised when the value is not matched with the correct 
>> > value defined in
>> > rtems_test_assert().
>> >
>> > ___
>> > 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] user/gsoc: GSoC Getting Started Instructions

[Gedare Bloom]

Hi Niteesh,

Did you build the docs with this change?

The rewrite is nice. I do have several comments below to address:

On Tue, Mar 17, 2020 at 2:36 PM G S Niteesh Babu  wrote:
>
> ---
>  user/index.rst   |   1 +
>  user/start/gsoc.rst  | 453 +++
>  user/start/index.rst |   1 +
>  3 files changed, 455 insertions(+)
>  create mode 100644 user/start/gsoc.rst
>
> diff --git a/user/index.rst b/user/index.rst
> index 0e644c9..f253ea6 100644
> --- a/user/index.rst
> +++ b/user/index.rst
> @@ -10,6 +10,7 @@ RTEMS User Manual (|version|).
>
>  .. topic:: Copyrights and License
>
> +| |copy| 2020 Niteesh Babu
>  | |copy| 2019 Vijay Kumar Banerjee
>  | |copy| 2018 Amaan Cheval
>  | |copy| 2018 Marçal Comajoan Cara
> diff --git a/user/start/gsoc.rst b/user/start/gsoc.rst
> new file mode 100644
> index 000..071c1cc
> --- /dev/null
> +++ b/user/start/gsoc.rst
> @@ -0,0 +1,453 @@
> +.. comment: SPDX-License-Identifier: CC-BY-SA-4.0
> +
> +.. comment: Copyright (C) 2020 Niteesh Babu 
> +.. comment: All rights reserved.
We don't really use this phrase.

> +
> +
only 1 blank

> +.. _QuickStartGSoC:
> +
> +GSoC Getting Started
> +
> +
> +The goal of this page is to help you get RTEMS compiled and running so you 
> can
I think the intro at least will be better in the 3rd person for the
manual version. Replace first "you" with "new users, especially
students, " and replace second "you" with "they"

> +start with the real work.
> +
> +Please join the :r:list:`users` and :r:list:`devel` mailing lists and ask 
> questions.
> +Help correct any deficiencies in the code or documentation you spot, 
> including
> +those on the wiki. The ultimate goal of GSoC is to help you become part of 
> the
replace "you" with "students"

You can keep it in second-person below that is fine for now.

> +open source community.
> +
> +.. _QuickStartConfigureComputer:
> +
> +Configure a Development Computer
> +
> +
> +You will be best served by using a GNU/Linux environment, which could be in a
> +virtual machine, for example that uses `Virtualbox 
> `_
> +and should run on most modern desktop systems. You should also be able to 
> work
> +with a MacOS or Windows system, but might encounter more difficulty than a 
> *nix
> +environment.
> +
> +Feel free to ask questions on the rtems-users mailing list in case you face
:r:list:`users`

> +trouble with the steps. If you want tools for another architecture, replace
> +sparc in the RSB directions with another architecture, such as arm or mips. 
> You
s/another/that

> +can also use the RSB to build RTEMS directly, but we recommend that you learn
> +how to build RTEMS by itself with the compiler tools generated by RSB.
> +
> +As you will be compiling a lot of code, it is recommended to have a 
> reasonably
> +fast development machine.
> +
> +The instructions in this chapter will help you in quickly setting up a
> +development environment. For a detailed set of instruction please refer to 
> the
typo: instructions

> +:ref:`QuickStart` chapter.
> +
> +You need tools for your host’s operating system to build the RTEMS tool suite
> +from source. Please have a look at the :ref:`host-computer` chapter for the
> +instructions to install the tools.
> +
After the chapter by Utkarsh about cross-compilers is merged, it would
be good to add a sentence here with a ref.

> +Choosing an Installation Prefix
> +---
> +
> +The term ``prefix`` refers to the path on your computer where the software 
> is to
> +be installed.
> +In this case, we choose the home directory ``$HOME/rtems`` as our prefix.
> +
> +.. code-block:: none
> +
> +  mkdir $HOME/rtems
> +
> +Getting Sources
> +---
> +
> +We obtain the source code for the :ref:`RTEMS Source Builder (RSB) ` and
> +RTEMS from the RTEMS :r:url:`git`.
> +
> +The :ref:`RTEMS Source Builder (RSB) ` is the tool used to build RTEMS
> +packages from source. We will be using the RSB to build RTEMS the source.
"from" missing?

> +Please have a look at the :ref:`RTEMS Source Builder (RSB) ` for more
> +information.
> +
> +We'll clone to the repositories to ``$HOME/rtems/src``.
"to the" -> "the"

> +
> +.. code-block:: none
> +
> +  mkdir -p $HOME/rtems/src
> +  cd $HOME/rtems/src
> +  git clone git://git.rtems.org/rtems-source-builder.git rsb
> +  git clone git://git.rtems.org/rtems.git
> +
> +Building the Tool suite
> +---
> +
> +Once you have cloned the repositories and installed the required tools for
> +your host operating system. You can start building the tools suite for your 
> BSP.
> +The tools suite is the collection of compiler, debugger, Assembler and other
lower case assembler

> +tools required for developing the software.
> +
> +You can check if your host is set up correctly using ``sb-check`` tool 
> provided
"using the"

> +in the RSB repository.
> +
> +.. 

Re: Sources to port fenv.h to ARM and AARCH64

[Eshan Dhawan]

It seems we can't follow a single platform
We will be needing to take the preferred architectures from both FreeBSD as
well as NetBSD
What would you all suggest
Also I musl has implementation structure similar to that in NetBSD and has
some sort of support present for architectures that are not supported by
NetBSD
So, can we take that into considerationfor adding fenv ?

On Sun, Mar 22, 2020 at 3:15 PM Eshan Dhawan 
wrote:

>
>
> On Sun, Mar 22, 2020 at 2:49 AM Joel Sherrill  wrote:
>
>>
>>
>> On Sat, Mar 21, 2020 at 4:05 PM Aditya Upadhyay 
>> wrote:
>>
>>> On Sun, Mar 22, 2020 at 1:56 AM Joel Sherrill  wrote:
>>> >
>>> >
>>> >
>>> > On Sat, Mar 21, 2020, 3:16 PM Aditya Upadhyay 
>>> wrote:
>>> >>
>>> >> On Sun, Mar 22, 2020 at 1:30 AM Joel Sherrill  wrote:
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Sat, Mar 21, 2020 at 3:03 AM Aditya Upadhyay <
>>> aadit0...@gmail.com> wrote:
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> On Sat, 21 Mar 2020, 10:29 Eshan Dhawan, 
>>> wrote:
>>> >> >>>
>>> >> >>> I went through the FreeBSD and NetBSD sources for implementation
>>> >> >>> In FreeBSD there is an architecture-specific implementation with
>>> different header file for each architecture it supports .
>>> >> >>> Whereas in NetBSD there is a single fenv.h defined but each
>>> architecture has its own C file to implement the functions.
>>> >> >>> Also FreeBSD has soft-float for ARM
>>> >> >>> So, I think FreeBSD would be a better option.
>>> >> >>
>>> >> >>
>>> >> >> Look into this discussion on mail thread:
>>> >> >> https://sourceware.org/legacy-ml/newlib/2017/msg00818.html
>>> >> >>
>>> >> >> and this patch series on newlib mailing list.
>>> >> >>
>>> >> >> https://sourceware.org/legacy-ml/newlib/2019/msg00418.html .
>>> >> >>
>>> >> >> It will help to understand the fenv-stub code.
>>> >> >
>>> >> >
>>> >> > I am having trouble finding the implementation of any fenv method
>>> in the NetBSD code. I only am finding the weak alias mappings. Where is an
>>> example of the body of one of the methods in any architecture?
>>> >> >
>>> >>
>>> >> I have cloned this NetBSD Sources. As I can see those
>>> >> architecture-specific implemented methods here. Please correct me if I
>>> >> am looking into different than what you are looking for.
>>> >>
>>> >> ./lib/libm/arch/powerpc/fenv.c
>>> >> ./lib/libm/arch/sh/fenv.c
>>> >> ./lib/libm/arch/mips64/fenv.c
>>> >> ./lib/libm/arch/amd64/fenv.c
>>> >> ./lib/libm/arch/arm/fenv.c
>>> >> ./lib/libm/arch/i387/fenv.c
>>> >> ./lib/libm/arch/hppa/fenv.c
>>> >> ./lib/libm/arch/m88k/fenv.c
>>> >> ./lib/libm/arch/alpha/fenv.c
>>> >> ./lib/libm/arch/sparc64/fenv.c
>>> >> ./lib/libm/arch/aarch64/fenv.c
>>> >> ./regress/lib/libm/fenv/fenv.c
>>> >
>>> >
>>> > That's what I see browsing the repo.
>>> >
>>> > The single file NetBSD looks easy to integrate. Would be similar to
>>> the x86_64 or i386 there now on file layout.
>>> >
>>> > Does the freebsd support more hardware variants?
>>>
>>> FreeBSD does not have fenv support for some architecture like RISCV,
>>> M88k, alpha architecture, I can see netbsd support more
>>> hardware variants. NetBSD includes fenv support for these architecture
>>> also.
>>>
>>
>> +1
>>
>> NetBSD has more architectures and looks easier to integrate. But we need
>> to be
>> sure the NetBSD implementation for an specific architecture covers all
>> the cases
>> that FreeBSD does. If equal, pick the more that is easier to integrate.
>>
>>
> I went through the FreeBSD and NetBSD repositories
> NetBSD has support for :
> aarch64
> arm
> i387
> sparc 
> x86_64
> alpha
> hppa
> riscv
>
> while lacks the support for :
> sh3
> powerpc
> mips
> m68k
> ia64 (incomplete implementation)
>
> where as FreeBSD has an added support for mips and powerpc other than
> supported in NetBSD
>
> list of supported architectures in FreeBSD :
> aarch64
> amd64
> arm
> i387
> MIPS
> PowerPC
> RISC-V
> sparc64
> X86
>
> --Eshan
>
> --joel
>>
>>
>>>
>>> >>
>>> >>
>>> >> > --joel
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >>>
>>> >> >>> On Sat, Mar 21, 2020 at 2:37 AM Joel Sherrill 
>>> wrote:
>>> >> 
>>> >> 
>>> >> 
>>> >>  On Fri, Mar 20, 2020 at 3:33 PM Eshan Dhawan <
>>> eshandhawa...@gmail.com> wrote:
>>> >> >
>>> >> > thanks, dr Joel
>>> >> >
>>> >> > I had gone through the musl-libc library but it doesn't have
>>> much architecture specific support for ARM as well as AARCH64
>>> >> > It has support for s390x, m68k, powerpc64
>>> >> 
>>> >> 
>>> >>  This type of evaluation is important.  The architecture may be
>>> supported in only one implementation or one may be more complete than
>>> another.
>>> >> 
>>> >>  Ignoring the license requirements of course.
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Sat, Mar 21, 2020 at 1:32 AM Joel Sherrill 
>>> wrote:
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> On Fri, Mar 20, 2020 at 2:43 PM Eshan Dhawan <
>>> eshandhawa...@gmail.com> wrote:
>>> >> >>>
>>> >> >>> What would be 

Re: Adding GDB BSPs to rtems-tester

[Gedare Bloom]

On Sun, Mar 22, 2020 at 1:40 AM Niteesh G. S.  wrote:
>
> I built mips jmr3904. I was able to run rtems-run and rtems-test on it.
> But cdtest.exe fails.
> *** TESTING C++ EXCEPTIONS ***
> mips-core: 1 byte read to unmapped address 0x2ed31 at 0x880290a4
> Program received signal SIGBUS, Bus error.
> 0x88028fe4 in strlen ()
> What is causing this error?
This shows that the strlen function is accessing a bad address
(0x2ed31). In fact, this is part of the value of the jmr3904 simulator
and why we want to get it working for routine testing, because it can
catch bad memory errors.

> I tried running this manually on GDB. On forcefully continuing.
The next step is not to forcefully continue, but to work backwards
from the failure in GDB. print a stack backtrace ('bt' command) to see
how it got to strlen. Look at the values of the registers you can
observe. Compare with the code in the example and trace the example
code forward along the path shown by the backtrace. Use GDB to
investigate the stack frames ('up' and 'down' commands).

> Warning, resuming with mismatched exception signal (7 vs 10)
After an unmapped address access, nothing else that executes is going
to be valid.

> Unhandled exception 7
> sr: 0x536936196  cause: 0x00029724 --> Data Bus Error
>
> *** FATAL ***
> fatal source: 1 (INTERNAL_ERROR_RTEMS_API)
> fatal code: 9800724312699699200 (0x1)
> RTEMS version: 5.0.0.37e7cc5f4ce7ed46b5ea2de56d9066d121d851cb-modified
> RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB 5 (0b7e87143b76), Newlib fbaa096)
> executing thread ID: 0x08a010001
> executing thread name: CTOR
>
> Is this problem with the BSP or simulator? And how can I fix this?

Most likely it is a problem with newlib.

>
> On Sat, Mar 21, 2020 at 11:33 PM Joel Sherrill  wrote:
>>
>>
>>
>> On Sat, Mar 21, 2020 at 10:38 AM Niteesh G. S.  wrote:
>>>
>>> Which architecture should I try then? Maybe powerpc or mips? If you have any
>>> of them already built can you please try them out? Building everything from
>>> source takes a lot of time in my dev machine.
>>>
>>> On Sat, Mar 21, 2020 at 6:41 PM Gedare Bloom  wrote:

 On Sat, Mar 21, 2020 at 12:54 AM Niteesh G. S.  
 wrote:
 >
 > On Thu, Mar 19, 2020 at 11:43 PM Gedare Bloom  wrote:
 >>
 >> On Thu, Mar 19, 2020 at 11:56 AM Niteesh G. S.  
 >> wrote:
 >> >
 >> > Hello,
 >> >
 >> > While looking for small tasks to take up, Gedare mentioned about 
 >> > adding GDB BSPs
 >> > to rtems-tester. Can some please explain a bit more of what has to be 
 >> > done? I guess
 >> > we have to write configuration files for BSPs that support simulation 
 >> > in GDB. If so, how
 >> > could I find those BSPs, do I have to individually look at all the 
 >> > BSPs?
 >> >
 >> As I said off-list, I don't know if there's a list of GDB BSPs, but I
 >> know of at least:
 >> powerpc/psim
 >> mips/jmr3904
 >> moxie/moxiesim
 >> arm/gdbarmsim
 >> sh/shsim
 >>
 >> I have no idea what any of their statuses are or if they are expected
 >> to work. The first step would be building them and see if they run
 >> anything. After that, you should look at the existing tester scripts for
 >> some targets:
 >>   rtems-tools.git/tester/rtems/testing/bsps
 >> I see scripts for most of what I listed above, so the next step would
 >> be trying to run them via tester and see if it works.
 >
 >
 > I built the simsh1 BSP but couldn't get it running. Before trying it 
 > with rtems-run
 > and rtems-test I tried manually loading it in the simulator. But gdb 
 > doesn't respond
 > as soon as I execute the run command. The only way to exit it was using 
 > ctrl-c and GDB
 > responds with
 > sim_events_schedule_after_signal - buffer overflow
 > Quit
 > Aborted (core dumped)
 > I tried setting breakpoints within GDB but it never seems to hit them. I 
 > tried running the
 > examples through rtems-test results in ta imeout.
 >
 > Due to the slow internet connection and slow development machine, I 
 > could only build
 > and test a few BSPs. In case if anyone has an already built tool suite 
 > and BSP for the
 > mentioned arch please try them out.
 >
 I don't know that anyone uses this architecture. Don't spend too much
 effort trying to debug the simulator :)
>>
>>
>> mips jmr3904 and powerpc psim should work well.
>>
>> I agree with Gedare, spending a lot of time on the SH isn't high payoff.
>> I'm glad for the report but there could be bitrot in the simulator or BSP.
>>


 >> BTW: Did I mention adding these to tester, or did I mention creating
 >> build sets for them? Anyway, I think the GDB simulator builds by
 >> default with the toolchain, so there is no difference between a BSP
 >> buildset (such as for jmr3904) and one that supports running on GDB.
 >> At least, I think so. It is 

Re: Python Standardization

[Gedare Bloom]

On Sun, Mar 22, 2020 at 7:07 AM Anmol Mishra  wrote:
>
> Hello,
> Since you clarified the motivation for API, I need to ask a few questions 
> which will help me.
>
> 1. By API, Do you mean a wrapper or a common access point to test/access all 
> the utilities? If yes, Is REST API is expected like a dashboard?
>
> 2. Is there any active API?
>
> I know this question may seem to be naive but I need to discuss it and 
> clarification is better than any wrong interpretation. All dev members can 
> help me, I will really appreciate it.
>
To get better participation you might want to use a more specific
subject line and provide some extra context to your question.

The project idea is about defining a uniform/consistent interface for
using different products located primarily in rtems-tools.git The
project idea ticket says:
 * A general RTEMS tool library with a standard API to handle common tasks.
 * All utilities callable as a function within the API with the tool
itself being a thin layer.
 * Testing on all API commands under both Python 2.x and 3.x.
API is taken as the original meaning of "application programming
interface" to mean how applications will use the tool library. This
has nothing to do with web services. I hope that helps with some of
your confusion.

Many of the "home-grown" RTEMS tools have relatively consistent
command line interfaces (CLI), but I can't speak to their API; a lot
of them were designed to be used on the command line, which could also
be used as an API but it is not efficient because you generally have
to invoke the tool in a subprocess in such cases.

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

Python Standardization

[Anmol Mishra]

Hello,
Since you clarified the motivation for API, I need to ask a few questions
which will help me.

1. By API, Do you mean a wrapper or a common access point to test/access
all the utilities? If yes, Is REST API is expected like a dashboard?

2. Is there any active API?

I know this question may seem to be naive but I need to discuss it and
clarification is better than any wrong interpretation. All dev members can
help me, I will really appreciate it.

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

Re: [PATCH] This patch provides usage of RTEMS cross-compiler over GCC cross-compiler

[Gedare Bloom]

Thanks Utkarsh,

I have comments below.

On Sun, Mar 22, 2020 at 4:53 AM utkarsh.ra...@gmail.com
 wrote:
>
> ---
>  user/start/tools.rst | 25 +
>  1 file changed, 25 insertions(+)
>
> diff --git a/user/start/tools.rst b/user/start/tools.rst
> index c3f039b..8a1f393 100644
> --- a/user/start/tools.rst
> +++ b/user/start/tools.rst
> @@ -76,3 +76,28 @@ source code used.
>
>
>  Add ``--verbose`` to the GCC command for the the verbose version details.
> +
> +RTEMS cross-compiler over GCC cross-compiler
It is still a gcc cross compiler. I don't know that I like the heading
here. Maybe "Need for RTEMS-Specific Cross-Compiler" is better?

> +
> +The new users are often confused as to why they can't use their 
> distributions cross-compiler for their target on rtems, e.g.,
Line length. Please limit to 80 characters. This is a general comment
that I won't repeat below.

Remove "The", start with "New users"
distributions -> distribution's

> +the riscv64-linux-gnu or the arm-none-eabi-gcc.Below mentioned are some 
> the reasons for using the RTEMS cross-compiler.
add space in "gcc.Below"
"some the" -> "some of the"

> +
> + ``Correct configuration of newlib`` -
> +Newlib is a C standard library implementation intended
Rebalance line lengths. You can probably set up your editor to do this
automatically. That is the best choice when working with narrative
text. (With code, you should deal with line breaks manually.)

> +for use on embedded systems. Most of the POSIX and libc support for 
> RTEMS is derived from newlib.
> +The RTEMS cross-compiler configures newlib correctly for RTEMS.
> +
> + ``Threading in GCC supported libraries`` -
supported -> support

> +GCC supported threading libraries such as ``pthread.h``
ditto

> +provide threading support to an application,these libraries are tailored 
> according to RTEMS using
add space after comma
Replace comma with period or semicolon

> +the RTEMS cross-compiler.
> +
> + ``Provide preprocessor define _rtems_`` -
Two underscores __rtems__ here.

> +The ``_rtems_`` preprocessor define is genarally used to include rtems
typo: generally

> +specific libraries.This preprocessor define is provided by the RTEMS 
> cross-compiler at the compile time.

It is used to provide conditional code compilation in source files
that are shared with other projects, e.g., in newlib or imported code
from freebsd.


> +
> + ``Multilib variants to match the BSP``-
> +RTEMS configures GCC to create separate runtime libraries for
> +each   supported instruction set, floating point unit, vector unit, word 
> size (e.g. 32-bit and 64-bit), endianess,
too  many spaces after "each"
typo: endianness has two 'n'

> +code model, ABI, processor errata workarounds, and so on in the 
> architecture. This is termed multilib.
what is "code model"?

"This is term multilib." -> "These libraries are termed multilib variants."

> +Multilibs variants to match the BSP are set by selecting a specific set 
> of machine options using the RTEMS cross-compiler.
> --
> 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: BSP Buildset for EPICS GSOC 2020 Proposal

[Mritunjay Sharma]

Hello everyone,

After the suggestions of Dr @Gedare Bloom  and other
members of both the communities, I have modified my draft proposal
for the ticket #3855 (BSP Buildset for EPICS). I would request
you all to please review and help with further suggestions
and improvements to make the proposal much more
refined and crisp.

Here's the link:
https://docs.google.com/document/d/1G0rA1Ri6qxfiMlCC6JKpCAIq1tvpgUNoM6rCoXdeUPk/edit?usp=sharing

Also, Stay Healthy and Stay Safe all!

Thanks,
Mritunjay


On Sat, Mar 14, 2020 at 1:14 AM Mritunjay Sharma <
mritunjaysharma...@gmail.com> wrote:

> Hello everyone,
>
> This is to inform that I have updated my first draft link to the proposal
> on https://devel.rtems.org/wiki/GSoC/2020.
> It is the first draft of the proposal and needs a lot of refinement and
> suggestions from the mentors to improve it and make it presentable for the
> GSoC 2020 proposal.
>
> Link to the proposal:
>
> https://docs.google.com/document/d/1G0rA1Ri6qxfiMlCC6JKpCAIq1tvpgUNoM6rCoXdeUPk/edit?usp=sharing
>
> With deep regrets, I would also like to share with you all that my
> grandfather passed away on 12th March 2020 after his long battle with
> cancer and so I might be less active for a couple of days, however, I will
> try to move on and fulfil his aspirations and keep on contributing :(
>
> Thanks,
> Mritunjay
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] This patch provides usage of RTEMS cross-compiler over GCC cross-compiler

[utkarsh.ra...@gmail.com]

---
 user/start/tools.rst | 25 +
 1 file changed, 25 insertions(+)

diff --git a/user/start/tools.rst b/user/start/tools.rst
index c3f039b..8a1f393 100644
--- a/user/start/tools.rst
+++ b/user/start/tools.rst
@@ -76,3 +76,28 @@ source code used.
 
 
 Add ``--verbose`` to the GCC command for the the verbose version details.
+
+RTEMS cross-compiler over GCC cross-compiler
+
+The new users are often confused as to why they can't use their 
distributions cross-compiler for their target on rtems, e.g., 
+the riscv64-linux-gnu or the arm-none-eabi-gcc.Below mentioned are some 
the reasons for using the RTEMS cross-compiler.
+
+ ``Correct configuration of newlib`` - 
+Newlib is a C standard library implementation intended 
+for use on embedded systems. Most of the POSIX and libc support for RTEMS 
is derived from newlib.
+The RTEMS cross-compiler configures newlib correctly for RTEMS.
+
+ ``Threading in GCC supported libraries`` -
+GCC supported threading libraries such as ``pthread.h`` 
+provide threading support to an application,these libraries are tailored 
according to RTEMS using
+the RTEMS cross-compiler.
+
+ ``Provide preprocessor define _rtems_`` -
+The ``_rtems_`` preprocessor define is genarally used to include rtems 
+specific libraries.This preprocessor define is provided by the RTEMS 
cross-compiler at the compile time.
+
+ ``Multilib variants to match the BSP``- 
+RTEMS configures GCC to create separate runtime libraries for
+each   supported instruction set, floating point unit, vector unit, word 
size (e.g. 32-bit and 64-bit), endianess,
+code model, ABI, processor errata workarounds, and so on in the 
architecture. This is termed multilib.
+Multilibs variants to match the BSP are set by selecting a specific set of 
machine options using the RTEMS cross-compiler.
-- 
2.17.1

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

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

[Eshan Dhawan]

On Sun, Mar 22, 2020 at 12:21 AM Gedare Bloom  wrote:

> I liked it better before, when the test prints nothing if it is
> successful. I think this is the trend we are heading toward in rtems
> tests.
>
> I will incorporate more changes to the test so there is minimal printing
if the test is successful
The test is originally written by @Vaibhav Gupta 

it would require to do minor changes in the previous parts of the test as
well
should i do that ??

> On Sat, Mar 21, 2020 at 11:46 AM Eshan Dhawan 
> wrote:
> >
> > I ran the code using qemu for risc-v architecture.
> > The value of r = 0 for the function to run without error
> > while the error is raised when the value is not matched with the correct
> value defined in
> > rtems_test_assert().
> >
> > ___
> > 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: Sources to port fenv.h to ARM and AARCH64

[Eshan Dhawan]

On Sun, Mar 22, 2020 at 2:49 AM Joel Sherrill  wrote:

>
>
> On Sat, Mar 21, 2020 at 4:05 PM Aditya Upadhyay 
> wrote:
>
>> On Sun, Mar 22, 2020 at 1:56 AM Joel Sherrill  wrote:
>> >
>> >
>> >
>> > On Sat, Mar 21, 2020, 3:16 PM Aditya Upadhyay 
>> wrote:
>> >>
>> >> On Sun, Mar 22, 2020 at 1:30 AM Joel Sherrill  wrote:
>> >> >
>> >> >
>> >> >
>> >> > On Sat, Mar 21, 2020 at 3:03 AM Aditya Upadhyay 
>> wrote:
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Sat, 21 Mar 2020, 10:29 Eshan Dhawan, 
>> wrote:
>> >> >>>
>> >> >>> I went through the FreeBSD and NetBSD sources for implementation
>> >> >>> In FreeBSD there is an architecture-specific implementation with
>> different header file for each architecture it supports .
>> >> >>> Whereas in NetBSD there is a single fenv.h defined but each
>> architecture has its own C file to implement the functions.
>> >> >>> Also FreeBSD has soft-float for ARM
>> >> >>> So, I think FreeBSD would be a better option.
>> >> >>
>> >> >>
>> >> >> Look into this discussion on mail thread:
>> >> >> https://sourceware.org/legacy-ml/newlib/2017/msg00818.html
>> >> >>
>> >> >> and this patch series on newlib mailing list.
>> >> >>
>> >> >> https://sourceware.org/legacy-ml/newlib/2019/msg00418.html .
>> >> >>
>> >> >> It will help to understand the fenv-stub code.
>> >> >
>> >> >
>> >> > I am having trouble finding the implementation of any fenv method in
>> the NetBSD code. I only am finding the weak alias mappings. Where is an
>> example of the body of one of the methods in any architecture?
>> >> >
>> >>
>> >> I have cloned this NetBSD Sources. As I can see those
>> >> architecture-specific implemented methods here. Please correct me if I
>> >> am looking into different than what you are looking for.
>> >>
>> >> ./lib/libm/arch/powerpc/fenv.c
>> >> ./lib/libm/arch/sh/fenv.c
>> >> ./lib/libm/arch/mips64/fenv.c
>> >> ./lib/libm/arch/amd64/fenv.c
>> >> ./lib/libm/arch/arm/fenv.c
>> >> ./lib/libm/arch/i387/fenv.c
>> >> ./lib/libm/arch/hppa/fenv.c
>> >> ./lib/libm/arch/m88k/fenv.c
>> >> ./lib/libm/arch/alpha/fenv.c
>> >> ./lib/libm/arch/sparc64/fenv.c
>> >> ./lib/libm/arch/aarch64/fenv.c
>> >> ./regress/lib/libm/fenv/fenv.c
>> >
>> >
>> > That's what I see browsing the repo.
>> >
>> > The single file NetBSD looks easy to integrate. Would be similar to the
>> x86_64 or i386 there now on file layout.
>> >
>> > Does the freebsd support more hardware variants?
>>
>> FreeBSD does not have fenv support for some architecture like RISCV,
>> M88k, alpha architecture, I can see netbsd support more
>> hardware variants. NetBSD includes fenv support for these architecture
>> also.
>>
>
> +1
>
> NetBSD has more architectures and looks easier to integrate. But we need
> to be
> sure the NetBSD implementation for an specific architecture covers all the
> cases
> that FreeBSD does. If equal, pick the more that is easier to integrate.
>
>
I went through the FreeBSD and NetBSD repositories
NetBSD has support for :
aarch64
arm
i387
sparc 
x86_64
alpha
hppa
riscv

while lacks the support for :
sh3
powerpc
mips
m68k
ia64 (incomplete implementation)

where as FreeBSD has an added support for mips and powerpc other than
supported in NetBSD

list of supported architectures in FreeBSD :
aarch64
amd64
arm
i387
MIPS
PowerPC
RISC-V
sparc64
X86

--Eshan

--joel
>
>
>>
>> >>
>> >>
>> >> > --joel
>> >> >>
>> >> >>
>> >> >>
>> >> >>>
>> >> >>> On Sat, Mar 21, 2020 at 2:37 AM Joel Sherrill 
>> wrote:
>> >> 
>> >> 
>> >> 
>> >>  On Fri, Mar 20, 2020 at 3:33 PM Eshan Dhawan <
>> eshandhawa...@gmail.com> wrote:
>> >> >
>> >> > thanks, dr Joel
>> >> >
>> >> > I had gone through the musl-libc library but it doesn't have
>> much architecture specific support for ARM as well as AARCH64
>> >> > It has support for s390x, m68k, powerpc64
>> >> 
>> >> 
>> >>  This type of evaluation is important.  The architecture may be
>> supported in only one implementation or one may be more complete than
>> another.
>> >> 
>> >>  Ignoring the license requirements of course.
>> >> >
>> >> >
>> >> >
>> >> > On Sat, Mar 21, 2020 at 1:32 AM Joel Sherrill 
>> wrote:
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Fri, Mar 20, 2020 at 2:43 PM Eshan Dhawan <
>> eshandhawa...@gmail.com> wrote:
>> >> >>>
>> >> >>> What would be the preferred source to port fenv.h to ARM and
>> AARCH64
>> >> >>> its implementation is present in both FreeBSD as well AS NetBSD
>> >> >>> -> ARM
>> >> >>> ---FreeBSD Source
>> >> >>> # https://github.com/freebsd/freebsd/tree/master/lib/msun/arm
>> >> >>> ---NetBSD Source
>> >> >>> # https://github.com/NetBSD/src/tree/trunk/lib/libm/arch/arm
>> >> >>>
>> >> >>> ->AARCH64
>> >> >>> ---FreeBSD Source
>> >> >>> #
>> https://github.com/freebsd/freebsd/tree/master/lib/msun/aarch64
>> >> >>> ---NetBSD Source
>> >> >>> #
>> https://github.com/NetBSD/src/tree/trunk/lib/libm/arch/aarch64
>> >> >>
>> 

Re: Adding GDB BSPs to rtems-tester

[Niteesh G. S.]

I built mips jmr3904. I was able to run rtems-run and rtems-test on it.
But cdtest.exe fails.
*** TESTING C++ EXCEPTIONS ***
mips-core: 1 byte read to unmapped address 0x2ed31 at 0x880290a4
Program received signal SIGBUS, Bus error.
0x88028fe4 in strlen ()
What is causing this error?
I tried running this manually on GDB. On forcefully continuing.
Warning, resuming with mismatched exception signal (7 vs 10)
Unhandled exception 7
sr: 0x536936196  cause: 0x00029724 --> Data Bus Error

*** FATAL ***
fatal source: 1 (INTERNAL_ERROR_RTEMS_API)
fatal code: 9800724312699699200 (0x1)
RTEMS version: 5.0.0.37e7cc5f4ce7ed46b5ea2de56d9066d121d851cb-modified
RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB 5 (0b7e87143b76), Newlib fbaa096)
executing thread ID: 0x08a010001
executing thread name: CTOR

Is this problem with the BSP or simulator? And how can I fix this?

On Sat, Mar 21, 2020 at 11:33 PM Joel Sherrill  wrote:

>
>
> On Sat, Mar 21, 2020 at 10:38 AM Niteesh G. S. 
> wrote:
>
>> Which architecture should I try then? Maybe powerpc or mips? If you have
>> any
>> of them already built can you please try them out? Building everything
>> from
>> source takes a lot of time in my dev machine.
>>
>> On Sat, Mar 21, 2020 at 6:41 PM Gedare Bloom  wrote:
>>
>>> On Sat, Mar 21, 2020 at 12:54 AM Niteesh G. S. 
>>> wrote:
>>> >
>>> > On Thu, Mar 19, 2020 at 11:43 PM Gedare Bloom 
>>> wrote:
>>> >>
>>> >> On Thu, Mar 19, 2020 at 11:56 AM Niteesh G. S. 
>>> wrote:
>>> >> >
>>> >> > Hello,
>>> >> >
>>> >> > While looking for small tasks to take up, Gedare mentioned about
>>> adding GDB BSPs
>>> >> > to rtems-tester. Can some please explain a bit more of what has to
>>> be done? I guess
>>> >> > we have to write configuration files for BSPs that support
>>> simulation in GDB. If so, how
>>> >> > could I find those BSPs, do I have to individually look at all the
>>> BSPs?
>>> >> >
>>> >> As I said off-list, I don't know if there's a list of GDB BSPs, but I
>>> >> know of at least:
>>> >> powerpc/psim
>>> >> mips/jmr3904
>>> >> moxie/moxiesim
>>> >> arm/gdbarmsim
>>> >> sh/shsim
>>> >>
>>> >> I have no idea what any of their statuses are or if they are expected
>>> >> to work. The first step would be building them and see if they run
>>> >> anything. After that, you should look at the existing tester scripts
>>> for
>>> >> some targets:
>>> >>   rtems-tools.git/tester/rtems/testing/bsps
>>> >> I see scripts for most of what I listed above, so the next step would
>>> >> be trying to run them via tester and see if it works.
>>> >
>>> >
>>> > I built the simsh1 BSP but couldn't get it running. Before trying it
>>> with rtems-run
>>> > and rtems-test I tried manually loading it in the simulator. But gdb
>>> doesn't respond
>>> > as soon as I execute the run command. The only way to exit it was
>>> using ctrl-c and GDB
>>> > responds with
>>> > sim_events_schedule_after_signal - buffer overflow
>>> > Quit
>>> > Aborted (core dumped)
>>> > I tried setting breakpoints within GDB but it never seems to hit them.
>>> I tried running the
>>> > examples through rtems-test results in ta imeout.
>>> >
>>> > Due to the slow internet connection and slow development machine, I
>>> could only build
>>> > and test a few BSPs. In case if anyone has an already built tool suite
>>> and BSP for the
>>> > mentioned arch please try them out.
>>> >
>>> I don't know that anyone uses this architecture. Don't spend too much
>>> effort trying to debug the simulator :)
>>>
>>
> mips jmr3904 and powerpc psim should work well.
>
> I agree with Gedare, spending a lot of time on the SH isn't high payoff.
> I'm glad for the report but there could be bitrot in the simulator or BSP.
>
>
>>
>>> >> BTW: Did I mention adding these to tester, or did I mention creating
>>> >> build sets for them? Anyway, I think the GDB simulator builds by
>>> >> default with the toolchain, so there is no difference between a BSP
>>> >> buildset (such as for jmr3904) and one that supports running on GDB.
>>> >> At least, I think so. It is worth verifying.
>>> >>
>>> >> Gedare
>>> >>
>>> >> > Thank you,
>>> >> > Niteesh.
>>> >> > ___
>>> >> > 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: Sources to port fenv.h to ARM and AARCH64

[Vaibhav Gupta]

>
> >>
>> >> I have cloned this NetBSD Sources. As I can see those
>> >> architecture-specific implemented methods here. Please correct me if I
>> >> am looking into different than what you are looking for.
>> >>
>> >> ./lib/libm/arch/powerpc/fenv.c
>> >> ./lib/libm/arch/sh/fenv.c
>> >> ./lib/libm/arch/mips64/fenv.c
>> >> ./lib/libm/arch/amd64/fenv.c
>> >> ./lib/libm/arch/arm/fenv.c
>> >> ./lib/libm/arch/i387/fenv.c
>> >> ./lib/libm/arch/hppa/fenv.c
>> >> ./lib/libm/arch/m88k/fenv.c
>> >> ./lib/libm/arch/alpha/fenv.c
>> >> ./lib/libm/arch/sparc64/fenv.c
>> >> ./lib/libm/arch/aarch64/fenv.c
>> >> ./regress/lib/libm/fenv/fenv.c
>> >
>> >
>> > That's what I see browsing the repo.
>> >
>> > The single file NetBSD looks easy to integrate. Would be similar to the
>> x86_64 or i386 there now on file layout.
>> >
>> > Does the freebsd support more hardware variants?
>>
>> FreeBSD does not have fenv support for some architecture like RISCV,
>> M88k, alpha architecture, I can see netbsd support more
>> hardware variants. NetBSD includes fenv support for these architecture
>> also.
>>
>
> +1
>
> NetBSD has more architectures and looks easier to integrate. But we need
> to be
> sure the NetBSD implementation for an specific architecture covers all the
> cases
> that FreeBSD does. If equal, pick the more that is easier to integrate.
>
> --joel
>
Last year I found various sources:
https://lists.rtems.org/pipermail/devel/2019-July/026580.html

https://lists.rtems.org/pipermail/devel/2019-July/054391.html

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

Re: Ticket #2974 Enable search.h functionality in newlib

[Vaibhav Gupta]

>
>
> > My very quick review shows that this may all be present and then it is a
> matter
> > of test cases and the compliance document. And that's a good result.
> Sometimes
> > people do work and don't update tickets.
> >
> My hazy recollection is that someone looked into this. Maybe in prior
> POSIX Compliance projects?
>

Last year when I was porting ndbm.h I made several queries regarding this
directory.
Even after doing all the changes correctly, the port was not successful.
Later I found
out that the ndbm was calling a hash function from search.h.

The headers in this directory need to be updated first. Me and Joel even had
discussion about this in newlib mailing list but got no positive response
from them.

https://sourceware.org/pipermail/newlib/2019/017046.html

https://lists.rtems.org/pipermail/devel/2019-June/026205.html

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

Re: GSoC Students: Submit Draft Applications

[suyash singh]

I have submitted the draft proposal and proof of enrollment

On Sat, Mar 21, 2020 at 4:20 PM Eshan Dhawan 
wrote:

> Will do it ASAP..
>
> Thanks for the heads up
> > On 21-Mar-2020, at 3:55 AM, Gedare Bloom  wrote:
> >
> > Hello Aspiring Students,
> >
> > I wanted to let you know that you can submit and revise your
> > application including your "Final" proposal as many times as you like
> > in the Official website, and that you should do so now and update it
> > periodically until the deadline. If you don't submit it then you can't
> > get picked. "Final" is not final. :)
> >
> > Gedare
> ___
> 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

Review for gsoc proposal

[suyash singh]

I have incorporated the valuable suggestions of Dr Bloom in my proposal.
Looking forward for any further suggestions.

https://docs.google.com/document/d/1OerM8Iix7PbDUCyb_J_KEzcMgLbvdqxd4FnK_BqI7XI/edit


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