Re: gdb for RTEMS 5

2020-02-16 Thread Sebastian Huber 

On 16/02/2020 23:05, Chris Johns wrote:

Hi,

The builders have exposed a couple of regressions with gdb-9.1 ...

  - FreeBSD
 - bfin


On my FreeBSD 12.1 it worked:

https://lists.rtems.org/pipermail/build/2020-February/010245.html


--
Sebastian Huber, embedded brains GmbH

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

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

Re: [PATCH v3] testsuite/newlib: Check newlib does not touch an assigned std FILE pointer

2020-02-16 Thread Sebastian Huber 

On 16/02/2020 23:29, chr...@rtems.org wrote:

From: Chris Johns

Update #3870


Looks good. If you have time, please remove the #include  
before the push.


--
Sebastian Huber, embedded brains GmbH

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

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

Re: [PATCH] libmisc/shell: Fix the handling of joel scripts in telnet

2020-02-16 Thread Sebastian Huber 

On 17/02/2020 07:05, chr...@rtems.org wrote:

From: Chris Johns

- Fix the passing of std[in/out] to child threads
- Fix deleting of managed memory in the key destructor
- Only set the key in the main loop thread
- Only allocate a shell env outside of the main loop
- Work around #3970
- Fix memory leak if the task start fails
- Remove error level from shell env, it cannot be returned this way. Add
   exit_code but the API is broken so it cannot be returned.

Closes #3859


Any changes required in existing Telnet application code after this patch?

--
Sebastian Huber, embedded brains GmbH

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

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

Re: [PATCH 2/2] bsp/xen: Add xen_gicv3 target

2020-02-16 Thread Sebastian Huber 

On 23/01/2020 17:04, Jeff Kubascik wrote:

diff --git a/bsps/arm/xen/include/bsp.h b/bsps/arm/xen/include/bsp.h
index e5b23a902e..13b7592f1e 100644
--- a/bsps/arm/xen/include/bsp.h
+++ b/bsps/arm/xen/include/bsp.h
@@ -58,11 +58,21 @@
  extern "C" {
  #endif /* __cplusplus */
  
+#if USE_IRQ_GICV2


It would be good if these defines have a proper prefix, e.g. BSP_ARM_XEN_*.

--
Sebastian Huber, embedded brains GmbH

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

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

Re: .rtemsstack location on ARM

2020-02-16 Thread Sebastian Huber 

Hello Will,

I think you discovered a bug in the ARMv-7M linker command file, the 
bsp_vector_table_size should be 0.


On 09/01/2020 16:07, Will wrote:

Hi Sebastian,
The relocated vector table is also present in REGION_VECTOR as long as 
bsp_vector_table_in_start_section is not defined in the linker script. 
It sounds like this is expected behavior, though, so I'll 
adjust accordingly.


Thanks,
William

On Wed, Jan 8, 2020 at 11:58 PM Sebastian Huber 
> wrote:


Hello,

the region name REGION_VECTOR is a bit misleading. For ARMv-7M the
vector table is in the .bsp_start_text section, see
"bsps/arm/shared/start/start.S". In the REGION_VECTOR there is only the
interrupt stack.

-- 
Sebastian Huber, embedded brains GmbH


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

PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.



--
Sebastian Huber, embedded brains GmbH

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

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

[PATCH] libmisc/shell: Fix the handling of joel scripts in telnet

2020-02-16 Thread chrisj 
From: Chris Johns 

- Fix the passing of std[in/out] to child threads
- Fix deleting of managed memory in the key destructor
- Only set the key in the main loop thread
- Only allocate a shell env outside of the main loop
- Work around #3970
- Fix memory leak if the task start fails
- Remove error level from shell env, it cannot be returned this way. Add
  exit_code but the API is broken so it cannot be returned.

Closes #3859
---
 cpukit/include/rtems/shell.h   |   9 +-
 cpukit/libmisc/shell/shell.c   | 212 -
 testsuites/libtests/shell01/init.c | 121 +++-
 3 files changed, 270 insertions(+), 72 deletions(-)

diff --git a/cpukit/include/rtems/shell.h b/cpukit/include/rtems/shell.h
index 973db16605..71fc1dd8c7 100644
--- a/cpukit/include/rtems/shell.h
+++ b/cpukit/include/rtems/shell.h
@@ -217,19 +217,24 @@ extern rtems_status_code rtems_shell_script(
 /**
  *  Private environment associated with each shell instance.
  */
-typedef struct {
+typedef struct rtems_shell_env {
   /** 'S','E','N','V': Shell Environment */
   rtems_name magic;
+  bool managed;
   const char *devname;
   const char *taskname;
   bool exit_shell; /* logout */
   bool forever; /* repeat login */
-  int errorlevel;
+  int *exit_code;
+  bool exit_on_error;
   bool echo;
   char cwd[256];
   const char *input;
   const char *output;
   bool output_append;
+  FILE *parent_stdin;
+  FILE *parent_stdout;
+  FILE *parent_stderr;
   rtems_id wake_on_end;
   rtems_shell_login_check_t login_check;
 
diff --git a/cpukit/libmisc/shell/shell.c b/cpukit/libmisc/shell/shell.c
index c2ea3c4afa..208ea7cca6 100644
--- a/cpukit/libmisc/shell/shell.c
+++ b/cpukit/libmisc/shell/shell.c
@@ -20,6 +20,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -38,20 +39,35 @@
 #include 
 #include 
 
+#define SHELL_STD_DEBUG 0
+
+#if SHELL_STD_DEBUG
+static FILE* default_stdout;
+#define shell_std_debug(...) fprintf(default_stdout, __VA_ARGS__)
+#else
+#define shell_std_debug(...)
+#endif
+
 const rtems_shell_env_t rtems_global_shell_env = {
   .magic = rtems_build_name('S', 'E', 'N', 'V'),
+  .managed   = false,
   .devname   = CONSOLE_DEVICE_NAME,
   .taskname  = "SHGL",
   .exit_shell= false,
   .forever   = true,
-  .errorlevel= -1,
   .echo  = false,
   .cwd   = "/",
   .input = NULL,
   .output= NULL,
   .output_append = false,
+  .parent_stdin  = NULL,
+  .parent_stdout = NULL,
+  .parent_stderr = NULL,
   .wake_on_end   = RTEMS_ID_NONE,
-  .login_check   = NULL
+  .exit_code = NULL,
+  .login_check   = NULL,
+  .uid   = 0,
+  .gid   = 0
 };
 
 static pthread_once_t rtems_shell_once = PTHREAD_ONCE_INIT;
@@ -62,7 +78,7 @@ static pthread_key_t rtems_shell_current_env_key;
  *  Initialize the shell user/process environment information
  */
 static rtems_shell_env_t *rtems_shell_init_env(
-  rtems_shell_env_t *shell_env_p
+  rtems_shell_env_t *shell_env_parent
 )
 {
   rtems_shell_env_t *shell_env;
@@ -70,12 +86,17 @@ static rtems_shell_env_t *rtems_shell_init_env(
   shell_env = malloc(sizeof(rtems_shell_env_t));
   if ( !shell_env )
 return NULL;
-  if ( !shell_env_p ) {
+
+  if ( shell_env_parent == NULL ) {
+shell_env_parent = rtems_shell_get_current_env();
+  }
+  if ( shell_env_parent == NULL ) {
 *shell_env = rtems_global_shell_env;
-shell_env->taskname = NULL;
   } else {
-*shell_env = *shell_env_p;
+*shell_env = *shell_env_parent;
   }
+  shell_env->managed = true;
+  shell_env->taskname = NULL;
 
   return shell_env;
 }
@@ -90,14 +111,16 @@ static void rtems_shell_env_free(
   rtems_shell_env_t *shell_env;
   shell_env = (rtems_shell_env_t *) ptr;
 
-  if ( !ptr )
+  if ( ptr == NULL )
 return;
 
-  if ( shell_env->input )
-free((void *)shell_env->input);
-  if ( shell_env->output )
-free((void *)shell_env->output);
-  free( ptr );
+  if ( shell_env->managed ) {
+if ( shell_env->input )
+  free((void *)shell_env->input);
+if ( shell_env->output )
+  free((void *)shell_env->output);
+free( ptr );
+  }
 }
 
 static void rtems_shell_create_file(const char *name, const char *content)
@@ -129,6 +152,10 @@ static void rtems_shell_init_once(void)
   struct passwd pwd;
   struct passwd *pwd_res;
 
+#if SHELL_STD_DEBUG
+  default_stdout = stdout;
+#endif
+
   pthread_key_create(_shell_current_env_key, rtems_shell_env_free);
 
   /* dummy call to init /etc dir */
@@ -168,15 +195,22 @@ rtems_shell_env_t *rtems_shell_get_current_env(void)
 void rtems_shell_dup_current_env(rtems_shell_env_t *copy)
 {
   rtems_shell_env_t *env = rtems_shell_get_current_env();
-  if (env) {
+  if (env != NULL) {
 *copy = *env;
   }
   else {
-memset(copy, 0, sizeof(rtems_shell_env_t));
-copy->magic= rtems_build_name('S', 'E', 'N', 'V');
-copy->devname  = CONSOLE_DEVICE_NAME;
-copy->taskname = "RTSH";
+*copy = rtems_global_shell_env;
+

[PATCH v3] testsuite/newlib: Check newlib does not touch an assigned std FILE pointer

2020-02-16 Thread chrisj 
From: Chris Johns 

Update #3870
---
 testsuites/libtests/newlib01/init.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/testsuites/libtests/newlib01/init.c 
b/testsuites/libtests/newlib01/init.c
index 74e648799e..a9581b3570 100644
--- a/testsuites/libtests/newlib01/init.c
+++ b/testsuites/libtests/newlib01/init.c
@@ -18,11 +18,15 @@
 
 #include 
 
+#include 
+
 #include 
 #include 
 #include 
 #include 
 
+#include 
+
 #include "tmacros.h"
 
 const char rtems_test_name[] = "NEWLIB 1";
@@ -63,12 +67,24 @@ static void wait(void)
 static void worker_task(rtems_task_argument arg)
 {
   test_context *ctx = _instance;
+  struct _reent *reent = _REENT;
+  FILE *output;
   char buf[1] = { 'x' };
   size_t n;
 
-  stdout = fopen(_path[0], "r+");
+  rtems_test_assert(reent->__sdidinit == 0);
+
+  output = stdout = fopen(_path[0], "r+");
   rtems_test_assert(stdout != NULL);
 
+  /*
+   * Check newlib's __sinit does not touch our assigned file pointer.
+   */
+  rtems_test_assert(reent->__sdidinit == 0);
+  rtems_test_assert(fflush(stdout) == 0);
+  rtems_test_assert(reent->__sdidinit != 0);
+  rtems_test_assert(stdout == output);
+
   n = fwrite([0], sizeof(buf), 1, stdout);
   rtems_test_assert(n == 1);
 
-- 
2.23.0

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

Re: [PATCH v2] testsuite/newlib: Check newlib does not touch an assigned std FILE pointer

2020-02-16 Thread Chris Johns 
Please ignore this patch, it is the same patch as v1. I will create a v3.

Chris

On 17/2/20 8:58 am, chr...@rtems.org wrote:
> From: Chris Johns 
> 
> Update #3870
> ---
>  testsuites/libtests/newlib01/init.c | 16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/testsuites/libtests/newlib01/init.c 
> b/testsuites/libtests/newlib01/init.c
> index 74e648799e..1bff052363 100644
> --- a/testsuites/libtests/newlib01/init.c
> +++ b/testsuites/libtests/newlib01/init.c
> @@ -23,6 +23,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  #include "tmacros.h"
>  
>  const char rtems_test_name[] = "NEWLIB 1";
> @@ -63,12 +65,24 @@ static void wait(void)
>  static void worker_task(rtems_task_argument arg)
>  {
>test_context *ctx = _instance;
> +  struct _reent *reent = __getreent();
> +  FILE *output;
>char buf[1] = { 'x' };
>size_t n;
>  
> -  stdout = fopen(_path[0], "r+");
> +  rtems_test_assert(reent->__sdidinit == 0);
> +
> +  output = stdout = fopen(_path[0], "r+");
>rtems_test_assert(stdout != NULL);
>  
> +  /*
> +   * Check newlib's __sinit does not touch our assigned file pointer.
> +   */
> +  rtems_test_assert(reent->__sdidinit == 0);
> +  fflush(stdout);
> +  rtems_test_assert(reent->__sdidinit != 0);
> +  rtems_test_assert(stdout == output);
> +
>n = fwrite([0], sizeof(buf), 1, stdout);
>rtems_test_assert(n == 1);
>  
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2] testsuite/newlib: Check newlib does not touch an assigned std FILE pointer

2020-02-16 Thread chrisj 
From: Chris Johns 

Update #3870
---
 testsuites/libtests/newlib01/init.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/testsuites/libtests/newlib01/init.c 
b/testsuites/libtests/newlib01/init.c
index 74e648799e..1bff052363 100644
--- a/testsuites/libtests/newlib01/init.c
+++ b/testsuites/libtests/newlib01/init.c
@@ -23,6 +23,8 @@
 #include 
 #include 
 
+#include 
+
 #include "tmacros.h"
 
 const char rtems_test_name[] = "NEWLIB 1";
@@ -63,12 +65,24 @@ static void wait(void)
 static void worker_task(rtems_task_argument arg)
 {
   test_context *ctx = _instance;
+  struct _reent *reent = __getreent();
+  FILE *output;
   char buf[1] = { 'x' };
   size_t n;
 
-  stdout = fopen(_path[0], "r+");
+  rtems_test_assert(reent->__sdidinit == 0);
+
+  output = stdout = fopen(_path[0], "r+");
   rtems_test_assert(stdout != NULL);
 
+  /*
+   * Check newlib's __sinit does not touch our assigned file pointer.
+   */
+  rtems_test_assert(reent->__sdidinit == 0);
+  fflush(stdout);
+  rtems_test_assert(reent->__sdidinit != 0);
+  rtems_test_assert(stdout == output);
+
   n = fwrite([0], sizeof(buf), 1, stdout);
   rtems_test_assert(n == 1);
 
-- 
2.23.0

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

gdb for RTEMS 5

2020-02-16 Thread Chris Johns 
Hi,

The builders have exposed a couple of regressions with gdb-9.1 ...

 - FreeBSD
- bfin
 - Darwin (MacOS)
- lm32

I am planning on disabling the simulator in the bfin and switching lm32 to the
previous version on Darwin.

Is bfin building on Linux?

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

Re: [PATCH 13/18] config: Add _Thread_Idle_body

2020-02-16 Thread Chris Johns 
On 16/2/20 6:12 pm, Sebastian Huber wrote:
> On 16/02/2020 00:36, Chris Johns wrote:
> 
>> On 2020-02-15 03:02, Sebastian Huber wrote:
>>> Move the idle thread body configuration constant out of the
>>> configuration table.
>>>
>>> Provide a default definition of the idle thread body constant.
>>
>> May be I am missing something simple here. How would I provide an custom IDLE
>> task? Is it by providing something like ...
>>
>> #include 
>>
>> const Thread_Idle_body _Thread_Idle_body = My_Idle_body; 
> 
> No, definitely not. An application designer should use the documented API:
> 
> https://docs.rtems.org/branches/master/c-user/configuring_a_system.html#configure-idle-task-body
> 
> The goal of this and follow up change sets is to split this 3k LOC file
> (confdefs.h) in easier to review pieces.
> 
> The file contains also comments which should be in the Classic API Guide, e.g.
> how to configure the filesystems:
> 
> https://docs.rtems.org/branches/master/c-user/configuring_a_system.html#file-system-configuration-parameters
> 
> This is just an enumeration of the options. The user has no idea how things 
> are
> related after reading this section.
> 

Thank you for the explanation. I was reviewing the patch and not the patch and
the results of it being applied.

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

Re: [PATCH 07/18] config: Bring back RTEMS 4.11 configuration table

2020-02-16 Thread Chris Johns 
On 16/2/20 6:19 pm, Sebastian Huber wrote:
> On 16/02/2020 00:30, Chris Johns wrote:
>> On 2020-02-15 03:02, Sebastian Huber wrote:
>>> This improves API backward compatibility of RTEMS 5.1 to previous
>>> versions.
>>
>> What is the purpose of this change? How does a user wanting backward
>> compatibility use this change?
> There may be applications which used
> rtems_configuration_get_rtems_api_configuration() for diagnostic purposes.
>>
>> How long do we maintain this interface?
> As long as we have a Classic API.
>>
>> We clearly document users should not create configuration tables and you are
>> working to provide solid interfaces yet we have an interface for backwards
>> compatibility.
> We have two interfaces, one that creates the configuration, the documented
> interface for this is  and the configure option. The second
> interface is there to query the configuration. This is done through the
> rtems_configuration_*() macros/functions. This patch restores backward
> compatibility for the configuration query API.
>>
>> Why in this specific case do we have to do this? Is there an app or user in
>> mind that needs this?
> No, I just thought it is a good idea to keep the configuration query API 
> intact.

I agree. I did not pick up this change is about the query.

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

Fwd: [Hangout - NYLXS] ncurses 6.2

2020-02-16 Thread Joel Sherrill 
New ncurses release. RSB should need updating

-- Forwarded message -
From: Thomas Dickey 
Date: Sun, Feb 16, 2020, 2:35 PM
Subject: [Hangout - NYLXS] ncurses 6.2
To: 


Announcing ncurses 6.2

Overview

   The  ncurses  (new  curses)  library  is  a free software emulation of
   curses  in  System  V  Release  4.0 (SVr4), and more. It uses terminfo
   format,  supports  pads  and  color  and multiple highlights and forms
   characters and function-key mapping, and has all the other SVr4-curses
   enhancements  over  BSD curses. SVr4 curses became the basis of X/Open
   Curses.

   In  mid-June  1995,  the  maintainer of 4.4BSD curses declared that he
   considered  4.4BSD curses obsolete, and encouraged the keepers of unix
   releases such as BSD/OS, FreeBSD and NetBSD to switch over to ncurses.

   Since 1995, ncurses has been ported to many systems:
 * It is used in almost every system based on the Linux kernel (aside
   from some embedded applications).
 * It  is  used  as the system curses library on OpenBSD, FreeBSD and
   MacOS.
 * It  is used in environments such as Cygwin and MinGW. The first of
   these was EMX on OS/2 Warp.
 * It is used (though usually not as the system curses) on all of the
   vendor  unix  systems,  e.g.,  AIX,  HP-UX,  IRIX64, SCO, Solaris,
   Tru64.
 * It should work readily on any ANSI/POSIX-conforming unix.

   The distribution includes the library and support utilities, including
 * captoinfo, a termcap conversion tool
 * clear, utility for clearing the screen
 * infocmp, the terminfo decompiler
 * tabs, set tabs on a terminal
 * tic, the terminfo compiler
 * toe, list (table of) terminfo entries
 * tput,  utility  for  retrieving  terminal  capabilities  in  shell
   scripts
 * tset, to initialize the terminal

   Full manual pages are provided for the library and tools.

   The ncurses distribution is available at ncurses' homepage:

 ftp://ftp.invisible-island.net/ncurses/ or
 https://invisible-mirror.net/archives/ncurses/ .

   It is also available via anonymous FTP at the GNU distribution site

 ftp://ftp.gnu.org/gnu/ncurses/ .

Release Notes

   These notes are for ncurses 6.2, released February 12, 2020.

   This  release  is  designed  to  be source-compatible with ncurses 5.0
   through  6.1; providing extensions to the application binary interface
   (ABI).  Although  the  source  can  still be configured to support the
   ncurses  5  ABI, the reason for the release is to reflect improvements
   to the ncurses 6 ABI and the supporting utility programs.

   There  are,  of  course,  numerous  other improvements, listed in this
   announcement.

   The  most  important  bug-fixes/improvements  dealt  with user-defined
   capabilities  in terminal descriptions. The release notes also mention
   some other bug-fixes, but are focused on new features and improvements
   to existing features since ncurses 6.1 release.

  Library improvements

New features

   There are several new features:
 * O_EDGE_INSERT_STAY  tells  the  form  library  to optionally delay
   cursor movement on a field edge/boundary
 * O_INPUT_FIELD  extension to form library allows a dynamic field to
   shrink if the new limit is smaller than the current field size.
 * added  exit_curses  and  exit_terminfo to replace internal symbols
   for leak-checking.
 * added curses_trace, to replace trace().

   Additionally,  to  improve  performance other changes (and extensions)
   are provided in this release:
 * mouse  decoding  now handles shift/control/alt logic when decoding
   xterm's 1006 mode
 * ncurses  now  defines a limit for wgetnstr, wgetn_wstr when length
   is negative or "too large".
 * reordered  loop-limit checks in winsnstr in case the string has no
   terminating null and only the number of characters is used.
 * there  is  now  no  buffer-size  limit  when  reading the $TERMCAP
   variable.
 * the  $TERMCAP  variable  may  be  interpreted  as  a fallback to a
   terminfo entry
 * mvcur  now decides whether to use hard-tabs, using xt, tbc and hts
   as clues.
 * extended  colors  are  improved  by  modifying an internal call to
   vid_puts  to pass extended color pairs e.g., from tty_update.c and
   lib_mvcur.c
 * the  initialization  functions  now  avoid relying upon persistent
   data for the result from getenv
 * scrolling is improved:
  + a limit check in newline_forces_scroll handles the case where
the row is inside scroll-margins, but not at the end.
  + improved loop limits in _nc_scroll_window handle a case where
the scrolled data is a pad which is taller than the window.

Other improvements

   These are revised features:
 * used  "const"  in  some prototypes rather than NCURSES_CONST where

Re: master build failed

2020-02-16 Thread Ярослав Лещинский 
Ok, thanks. Gonna check rsb.

On Sun 16. Feb 2020 at 20:54, Joel Sherrill  wrote:

>
>
> On Sun, Feb 16, 2020, 1:44 PM Ярослав Лещинский 
> wrote:
>
>> Hello,
>>
>> I decided to update master to the latest. During the build got such error:
>>
>> ../../../../../rtems/c/src/../../cpukit/libcsupport/src/posix_devctl.c:
>> In function 'posix_devctl':
>> ../../../../../rtems/c/src/../../cpukit/libcsupport/src/posix_devctl.c:81:15:
>> error: 'SOCKCLOSE' undeclared (first use in this function)
>>if (dcmd == SOCKCLOSE ) {
>>^
>> ../../../../../rtems/c/src/../../cpukit/libcsupport/src/posix_devctl.c:81:15:
>> note: each undeclared identifier is reported only once for each function it
>> appears in
>>
>> Was running as:
>>  ./bootstrap && cd ../ && rm -rf build && mkdir build && cd build &&
>> ../rtems/configure --target=arm-rtems5 --prefix $HOME/workspace/rtems/build
>> && make -j8 RTEMS_BSP=stm32f4 && make RTEMS_BSP=stm32f4 install
>>
>> Did I miss some updates from sourcebuilder, for example or it's problem
>> with a build in general?
>>
>
> You missed an RSB update to get at least a newer newlib.
>
> SOCKCLOSE is required by the FACE Technical Standard, Edition 3.0 and
> later.
>
> Fwiw RTEMS with Deos passed verification and is conformant with Edition
> 3.0. RTEMS provides POSIX services and Deos provides ARINC 653.
>
> --joel
>
>
>
>> --
>> --
>> Kind regards,
>> *Yaroslav Leshchinsky*
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
> --
--
Kind regards,
*Yaroslav Leshchinsky*
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: master build failed

2020-02-16 Thread Joel Sherrill 
On Sun, Feb 16, 2020, 1:44 PM Ярослав Лещинский 
wrote:

> Hello,
>
> I decided to update master to the latest. During the build got such error:
>
> ../../../../../rtems/c/src/../../cpukit/libcsupport/src/posix_devctl.c: In
> function 'posix_devctl':
> ../../../../../rtems/c/src/../../cpukit/libcsupport/src/posix_devctl.c:81:15:
> error: 'SOCKCLOSE' undeclared (first use in this function)
>if (dcmd == SOCKCLOSE ) {
>^
> ../../../../../rtems/c/src/../../cpukit/libcsupport/src/posix_devctl.c:81:15:
> note: each undeclared identifier is reported only once for each function it
> appears in
>
> Was running as:
>  ./bootstrap && cd ../ && rm -rf build && mkdir build && cd build &&
> ../rtems/configure --target=arm-rtems5 --prefix $HOME/workspace/rtems/build
> && make -j8 RTEMS_BSP=stm32f4 && make RTEMS_BSP=stm32f4 install
>
> Did I miss some updates from sourcebuilder, for example or it's problem
> with a build in general?
>

You missed an RSB update to get at least a newer newlib.

SOCKCLOSE is required by the FACE Technical Standard, Edition 3.0 and
later.

Fwiw RTEMS with Deos passed verification and is conformant with Edition
3.0. RTEMS provides POSIX services and Deos provides ARINC 653.

--joel



> --
> --
> Kind regards,
> *Yaroslav Leshchinsky*
> ___
> 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

master build failed

2020-02-16 Thread Ярослав Лещинский 
Hello,

I decided to update master to the latest. During the build got such error:

../../../../../rtems/c/src/../../cpukit/libcsupport/src/posix_devctl.c: In
function 'posix_devctl':
../../../../../rtems/c/src/../../cpukit/libcsupport/src/posix_devctl.c:81:15:
error: 'SOCKCLOSE' undeclared (first use in this function)
   if (dcmd == SOCKCLOSE ) {
   ^
../../../../../rtems/c/src/../../cpukit/libcsupport/src/posix_devctl.c:81:15:
note: each undeclared identifier is reported only once for each function it
appears in

Was running as:
 ./bootstrap && cd ../ && rm -rf build && mkdir build && cd build &&
../rtems/configure --target=arm-rtems5 --prefix $HOME/workspace/rtems/build
&& make -j8 RTEMS_BSP=stm32f4 && make RTEMS_BSP=stm32f4 install

Did I miss some updates from sourcebuilder, for example or it's problem
with a build in general?

-- 
--
Kind regards,
*Yaroslav Leshchinsky*
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Ticket #3515: covoar failure while running for full testsuites

2020-02-16 Thread Bran S 
Hi Guys,

I am trying to understand and solve Ticket #3515.
https://devel.rtems.org/ticket/3515

$ /home/user45/quick-start/rtems/5/share/rtems/tester/bin/covoar -
-S 
/home/user45/quick-start/rtems/5/share/rtems/tester/rtems/testing/coverage/leon3-sis-symbols.ini
-O leon3-sis-coverage -E
/home/user45/quick-start/rtems/5/share/rtems/tester/rtems/testing/coverage/Explanations.txt
-p RTEMS-5 
/home/user45/quick-start/build/b-leon3/sparc-rtems5/c/leon3/testsuites/fstests/fsclose01.exe

The output of the above command is at:
https://gist.github.com/archsbran/7834a931d52311c7b26842c6325d8d9a

On the last line it can be seen that absence of `wait` symbol causes the error.

I made some changes in ExecutableInfo.cc to print out the symbols
being added into coverageMap.
Added symbols can be seen from line 636 to 7236 at the above link.
In those lines we can see that `wait` is not added into coverageMap.

I am new so the only thing I know about covoar is that it does
coverage analysis.
Any ideas on how to move further into solving this ?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v3 2/2] bsp/raspberrypi: Mini UART driver

2020-02-16 Thread Christian Mauderer 
Hello Niteesh,

thanks for your work. I tested the patches. I agree that it works on Pi
1 and 2. Id doesn't work for me on Pi 3 (Model B V1.2) or 4. But with
Alans test reports there is positive feedback for some additional Pis.
It's no regression for 1 and 2 so I pushed it.

Best regards

Christian

On 16/02/2020 18:44, G. S. Niteesh wrote:
> Can someone please push these patches?
> 
> Thanks,
> Niteesh
> 
> On Sun, Feb 16, 2020 at 11:05 PM Alan Cudmore  > wrote:
> 
> Awesome! The Pi Zero W is a bonus too! I think we can run RTEMS on all
> models except the Pi 4 now.
> 
> On Sun, Feb 16, 2020 at 12:30 PM G. S. Niteesh  > wrote:
> >
> > Hii Alan,
> >
> > I tested it on my Raspberry Pi 3 model b v1.2 and it works.
> > U-Boot is not required anymore :)
> >
> > Thanks,
> > Niteesh.
> >
> > On Sun, Feb 16, 2020 at 10:51 PM Alan Cudmore
> mailto:alan.cudm...@gmail.com>> wrote:
> >>
> >> I'm definitely using the kernel_address, but letting the firmware
> >> decide what image to boot. For me kernel.img is the single core ARM
> >> images. kernel7.img is used for the raspberry pi 2 and 3. With these
> >> names, I can have both images on the same SD card to test in all
> of my
> >> Pis.
> >>
> >>
> >> my config.txt:
> >> enable_uart=1
> >> kernel_address=0x20
> >>
> >>
> >> On Sun, Feb 16, 2020 at 11:44 AM Christian Mauderer
> mailto:l...@c-mauderer.de>> wrote:
> >> >
> >> > On 16/02/2020 17:31, G. S. Niteesh wrote:
> >> > > Can you please share your config.txt for Pi3.
> >> >
> >> > +1
> >> >
> >> > It's interesting that it seems to work without an adapted
> config.txt. It
> >> > should be at least necessary to define the start address.
> >> >
> >> > >
> >> > > Thanks,
> >> > > Niteesh
> >> > >
> >> > > On Sun, Feb 16, 2020 at 9:58 PM Alan Cudmore
> mailto:alan.cudm...@gmail.com>
> >> > >  >> wrote:
> >> > >
> >> > >     I tried running my raspberrypi BSP image that worked on
> the Pi Zero
> >> > >     and W, but it did not work on the Pi 3.
> >> > >
> >> > >     I built the raspberrypi2 BSP, used objcopy to copy the
> binary to my sd
> >> > >     card as kernel7.img, and it works on my Pi 3 and Pi3 A+ (
> without
> >> > >     ethernet) . Note that my config.txt file does not specify
> the kernel
> >> > >     image, so the firmware defaults to kernel.img for the
> single core
> >> > >     models and kernel7.img for the 2 and 3.
> >> > >
> >> > >     I probably wont get a chance to try u-boot until later
> today or
> >> > >     tomorrow.
> >> > >
> >> > >     But these patches are great for enabling the Pi Zero W
> and Pi 3 models!
> >> > >     Thanks,
> >> > >     Alan
> >> > >
> >> > >     On Sun, Feb 16, 2020 at 10:58 AM G. S. Niteesh
> mailto:gsnb...@gmail.com>
> >> > >     >> wrote:
> >> > >     >
> >> > >     > On Sun, Feb 16, 2020 at 8:37 PM Alan Cudmore
> >> > >     mailto:alan.cudm...@gmail.com>
> >> wrote:
> >> > >     >>
> >> > >     >> Hi Niteesh,
> >> > >     >> I can try this patch on my Pi 3. Which BSP should I
> use? Is there any
> >> > >     >> special setup or BSP configuration needed?
> >> > >     >> Thanks,
> >> > >     >> Alan
> >> > >     >
> >> > >     > Hi Alan,
> >> > >     > First of all, thank you for taking this initiative.
> >> > >     > I have tried using the default bootloader in Pi3 to
> load RTEMS but
> >> > >     it doesn't work,
> >> > >     > Can you try it?
> >> > >     > The currently use U-Boot in 32bit mode as the bootloader.
> >> > >     > You can use the below instructions to build U-Boot in
> 32bit mode
> >> > >     >
> >> > >     > git clone https://github.com/u-boot/u-boot.git u-boot
> >> > >     > cd u-boot
> >> > >     > git revert 995eab8b5b580b67394312b1621c60a71042cd18
> >> > >     > make CROSS_COMPILE=arm-linux-gnueabi- rpi_3_32b_defconfig
> >> > >     > make CROSS_COMPILE=arm-linux-gnueabi-
> >> > >     >
> >> > >     > This one uses an old version of U-Boot and I don't know
> if there is
> >> > >     > a new way to build in 32bit mode.
> >> > >     >
> >> > >     > To build the U-Boot image of RTEMS you can use the
> below instructions
> >> > >     >
> >> > >     > arm-rtems5-objcopy -Obinary hello.exe kernel.img
> >> > >     > mkimage -A arm -O linux -T kernel -a 0x20 -e
> 0x200080 -d
> >> > >     kernel.img -C none rtems.img
> >> > >     >
> >> > >     > To load

Re: [PATCH v3 2/2] bsp/raspberrypi: Mini UART driver

2020-02-16 Thread G. S. Niteesh 
Can someone please push these patches?

Thanks,
Niteesh

On Sun, Feb 16, 2020 at 11:05 PM Alan Cudmore 
wrote:

> Awesome! The Pi Zero W is a bonus too! I think we can run RTEMS on all
> models except the Pi 4 now.
>
> On Sun, Feb 16, 2020 at 12:30 PM G. S. Niteesh  wrote:
> >
> > Hii Alan,
> >
> > I tested it on my Raspberry Pi 3 model b v1.2 and it works.
> > U-Boot is not required anymore :)
> >
> > Thanks,
> > Niteesh.
> >
> > On Sun, Feb 16, 2020 at 10:51 PM Alan Cudmore 
> wrote:
> >>
> >> I'm definitely using the kernel_address, but letting the firmware
> >> decide what image to boot. For me kernel.img is the single core ARM
> >> images. kernel7.img is used for the raspberry pi 2 and 3. With these
> >> names, I can have both images on the same SD card to test in all of my
> >> Pis.
> >>
> >>
> >> my config.txt:
> >> enable_uart=1
> >> kernel_address=0x20
> >>
> >>
> >> On Sun, Feb 16, 2020 at 11:44 AM Christian Mauderer 
> wrote:
> >> >
> >> > On 16/02/2020 17:31, G. S. Niteesh wrote:
> >> > > Can you please share your config.txt for Pi3.
> >> >
> >> > +1
> >> >
> >> > It's interesting that it seems to work without an adapted config.txt.
> It
> >> > should be at least necessary to define the start address.
> >> >
> >> > >
> >> > > Thanks,
> >> > > Niteesh
> >> > >
> >> > > On Sun, Feb 16, 2020 at 9:58 PM Alan Cudmore <
> alan.cudm...@gmail.com
> >> > > > wrote:
> >> > >
> >> > > I tried running my raspberrypi BSP image that worked on the Pi
> Zero
> >> > > and W, but it did not work on the Pi 3.
> >> > >
> >> > > I built the raspberrypi2 BSP, used objcopy to copy the binary
> to my sd
> >> > > card as kernel7.img, and it works on my Pi 3 and Pi3 A+ (
> without
> >> > > ethernet) . Note that my config.txt file does not specify the
> kernel
> >> > > image, so the firmware defaults to kernel.img for the single
> core
> >> > > models and kernel7.img for the 2 and 3.
> >> > >
> >> > > I probably wont get a chance to try u-boot until later today or
> >> > > tomorrow.
> >> > >
> >> > > But these patches are great for enabling the Pi Zero W and Pi 3
> models!
> >> > > Thanks,
> >> > > Alan
> >> > >
> >> > > On Sun, Feb 16, 2020 at 10:58 AM G. S. Niteesh <
> gsnb...@gmail.com
> >> > > > wrote:
> >> > > >
> >> > > > On Sun, Feb 16, 2020 at 8:37 PM Alan Cudmore
> >> > > mailto:alan.cudm...@gmail.com>> wrote:
> >> > > >>
> >> > > >> Hi Niteesh,
> >> > > >> I can try this patch on my Pi 3. Which BSP should I use? Is
> there any
> >> > > >> special setup or BSP configuration needed?
> >> > > >> Thanks,
> >> > > >> Alan
> >> > > >
> >> > > > Hi Alan,
> >> > > > First of all, thank you for taking this initiative.
> >> > > > I have tried using the default bootloader in Pi3 to load
> RTEMS but
> >> > > it doesn't work,
> >> > > > Can you try it?
> >> > > > The currently use U-Boot in 32bit mode as the bootloader.
> >> > > > You can use the below instructions to build U-Boot in 32bit
> mode
> >> > > >
> >> > > > git clone https://github.com/u-boot/u-boot.git u-boot
> >> > > > cd u-boot
> >> > > > git revert 995eab8b5b580b67394312b1621c60a71042cd18
> >> > > > make CROSS_COMPILE=arm-linux-gnueabi- rpi_3_32b_defconfig
> >> > > > make CROSS_COMPILE=arm-linux-gnueabi-
> >> > > >
> >> > > > This one uses an old version of U-Boot and I don't know if
> there is
> >> > > > a new way to build in 32bit mode.
> >> > > >
> >> > > > To build the U-Boot image of RTEMS you can use the below
> instructions
> >> > > >
> >> > > > arm-rtems5-objcopy -Obinary hello.exe kernel.img
> >> > > > mkimage -A arm -O linux -T kernel -a 0x20 -e 0x200080 -d
> >> > > kernel.img -C none rtems.img
> >> > > >
> >> > > > To load and run in U-Boot
> >> > > >
> >> > > > fatload mmc 0 0x20 rtems.img
> >> > > > fatload mmc 0 0x1000 bcm2710-rpi-3-b.dtb
> >> > > > bootm 0x20 - 0x1000
> >> > > >
> >> > > > And to make your U-Boot build process simpler I have uploaded
> my
> >> > > u-boot.bin
> >> > > > to my github, please use it :)
> >> > > > https://github.com/gs-niteesh/rpi3_RTEMS
> >> > > >
> >> > > > And sorry for the delay, I tested all these instructions again
> >> > > before sending them.
> >> > > >
> >> > > > Thanks
> >> > > > Niteesh.
> >> > > >
> >> > > >   On Sun, Feb 16, 2020 at 2:35 AM G. S. Niteesh <
> gsnb...@gmail.com
> >> > > > wrote:
> >> > > >>
> >> > > >> >
> >> > > >> > Hii,
> >> > > >> > This is a reminder message since this patch has been
> unnoticed
> >> > > for a while.
> >> > > >> > I have tested it on Raspberry Pi 3 and it works fine.
> There is
> >> > > also another patch
> >> > > >> >
> >> > >
>

Re: [PATCH v3 2/2] bsp/raspberrypi: Mini UART driver

2020-02-16 Thread Alan Cudmore 
Awesome! The Pi Zero W is a bonus too! I think we can run RTEMS on all
models except the Pi 4 now.

On Sun, Feb 16, 2020 at 12:30 PM G. S. Niteesh  wrote:
>
> Hii Alan,
>
> I tested it on my Raspberry Pi 3 model b v1.2 and it works.
> U-Boot is not required anymore :)
>
> Thanks,
> Niteesh.
>
> On Sun, Feb 16, 2020 at 10:51 PM Alan Cudmore  wrote:
>>
>> I'm definitely using the kernel_address, but letting the firmware
>> decide what image to boot. For me kernel.img is the single core ARM
>> images. kernel7.img is used for the raspberry pi 2 and 3. With these
>> names, I can have both images on the same SD card to test in all of my
>> Pis.
>>
>>
>> my config.txt:
>> enable_uart=1
>> kernel_address=0x20
>>
>>
>> On Sun, Feb 16, 2020 at 11:44 AM Christian Mauderer  
>> wrote:
>> >
>> > On 16/02/2020 17:31, G. S. Niteesh wrote:
>> > > Can you please share your config.txt for Pi3.
>> >
>> > +1
>> >
>> > It's interesting that it seems to work without an adapted config.txt. It
>> > should be at least necessary to define the start address.
>> >
>> > >
>> > > Thanks,
>> > > Niteesh
>> > >
>> > > On Sun, Feb 16, 2020 at 9:58 PM Alan Cudmore > > > > wrote:
>> > >
>> > > I tried running my raspberrypi BSP image that worked on the Pi Zero
>> > > and W, but it did not work on the Pi 3.
>> > >
>> > > I built the raspberrypi2 BSP, used objcopy to copy the binary to my 
>> > > sd
>> > > card as kernel7.img, and it works on my Pi 3 and Pi3 A+ ( without
>> > > ethernet) . Note that my config.txt file does not specify the kernel
>> > > image, so the firmware defaults to kernel.img for the single core
>> > > models and kernel7.img for the 2 and 3.
>> > >
>> > > I probably wont get a chance to try u-boot until later today or
>> > > tomorrow.
>> > >
>> > > But these patches are great for enabling the Pi Zero W and Pi 3 
>> > > models!
>> > > Thanks,
>> > > Alan
>> > >
>> > > On Sun, Feb 16, 2020 at 10:58 AM G. S. Niteesh > > > > wrote:
>> > > >
>> > > > On Sun, Feb 16, 2020 at 8:37 PM Alan Cudmore
>> > > mailto:alan.cudm...@gmail.com>> wrote:
>> > > >>
>> > > >> Hi Niteesh,
>> > > >> I can try this patch on my Pi 3. Which BSP should I use? Is there 
>> > > any
>> > > >> special setup or BSP configuration needed?
>> > > >> Thanks,
>> > > >> Alan
>> > > >
>> > > > Hi Alan,
>> > > > First of all, thank you for taking this initiative.
>> > > > I have tried using the default bootloader in Pi3 to load RTEMS but
>> > > it doesn't work,
>> > > > Can you try it?
>> > > > The currently use U-Boot in 32bit mode as the bootloader.
>> > > > You can use the below instructions to build U-Boot in 32bit mode
>> > > >
>> > > > git clone https://github.com/u-boot/u-boot.git u-boot
>> > > > cd u-boot
>> > > > git revert 995eab8b5b580b67394312b1621c60a71042cd18
>> > > > make CROSS_COMPILE=arm-linux-gnueabi- rpi_3_32b_defconfig
>> > > > make CROSS_COMPILE=arm-linux-gnueabi-
>> > > >
>> > > > This one uses an old version of U-Boot and I don't know if there is
>> > > > a new way to build in 32bit mode.
>> > > >
>> > > > To build the U-Boot image of RTEMS you can use the below 
>> > > instructions
>> > > >
>> > > > arm-rtems5-objcopy -Obinary hello.exe kernel.img
>> > > > mkimage -A arm -O linux -T kernel -a 0x20 -e 0x200080 -d
>> > > kernel.img -C none rtems.img
>> > > >
>> > > > To load and run in U-Boot
>> > > >
>> > > > fatload mmc 0 0x20 rtems.img
>> > > > fatload mmc 0 0x1000 bcm2710-rpi-3-b.dtb
>> > > > bootm 0x20 - 0x1000
>> > > >
>> > > > And to make your U-Boot build process simpler I have uploaded my
>> > > u-boot.bin
>> > > > to my github, please use it :)
>> > > > https://github.com/gs-niteesh/rpi3_RTEMS
>> > > >
>> > > > And sorry for the delay, I tested all these instructions again
>> > > before sending them.
>> > > >
>> > > > Thanks
>> > > > Niteesh.
>> > > >
>> > > >   On Sun, Feb 16, 2020 at 2:35 AM G. S. Niteesh > > > > wrote:
>> > > >>
>> > > >> >
>> > > >> > Hii,
>> > > >> > This is a reminder message since this patch has been unnoticed
>> > > for a while.
>> > > >> > I have tested it on Raspberry Pi 3 and it works fine. There is
>> > > also another patch
>> > > >> >
>> > > https://lists.rtems.org/pipermail/devel/2020-February/057194.html,
>> > > please
>> > > >> > do have a look at these.
>> > > >> >
>> > > >> > Thank you.
>> > > >> > Niteesh
>> > > >> > On Mon, Feb 10, 2020 at 12:52 AM G S Niteesh > > > > wrote:
>> > > >> >>
>> > > >> >> This patch adds driver for Mini UART present in Raspberry Pi 3
>> > > >> >> and above, this UART is currently used as the primary UART in

Re: [PATCH v3 2/2] bsp/raspberrypi: Mini UART driver

2020-02-16 Thread G. S. Niteesh 
Hii Alan,

I tested it on my Raspberry Pi 3 model b v1.2 and it works.
U-Boot is not required anymore :)

Thanks,
Niteesh.

On Sun, Feb 16, 2020 at 10:51 PM Alan Cudmore 
wrote:

> I'm definitely using the kernel_address, but letting the firmware
> decide what image to boot. For me kernel.img is the single core ARM
> images. kernel7.img is used for the raspberry pi 2 and 3. With these
> names, I can have both images on the same SD card to test in all of my
> Pis.
>
>
> my config.txt:
> enable_uart=1
> kernel_address=0x20
>
>
> On Sun, Feb 16, 2020 at 11:44 AM Christian Mauderer 
> wrote:
> >
> > On 16/02/2020 17:31, G. S. Niteesh wrote:
> > > Can you please share your config.txt for Pi3.
> >
> > +1
> >
> > It's interesting that it seems to work without an adapted config.txt. It
> > should be at least necessary to define the start address.
> >
> > >
> > > Thanks,
> > > Niteesh
> > >
> > > On Sun, Feb 16, 2020 at 9:58 PM Alan Cudmore  > > > wrote:
> > >
> > > I tried running my raspberrypi BSP image that worked on the Pi Zero
> > > and W, but it did not work on the Pi 3.
> > >
> > > I built the raspberrypi2 BSP, used objcopy to copy the binary to
> my sd
> > > card as kernel7.img, and it works on my Pi 3 and Pi3 A+ ( without
> > > ethernet) . Note that my config.txt file does not specify the
> kernel
> > > image, so the firmware defaults to kernel.img for the single core
> > > models and kernel7.img for the 2 and 3.
> > >
> > > I probably wont get a chance to try u-boot until later today or
> > > tomorrow.
> > >
> > > But these patches are great for enabling the Pi Zero W and Pi 3
> models!
> > > Thanks,
> > > Alan
> > >
> > > On Sun, Feb 16, 2020 at 10:58 AM G. S. Niteesh  > > > wrote:
> > > >
> > > > On Sun, Feb 16, 2020 at 8:37 PM Alan Cudmore
> > > mailto:alan.cudm...@gmail.com>> wrote:
> > > >>
> > > >> Hi Niteesh,
> > > >> I can try this patch on my Pi 3. Which BSP should I use? Is
> there any
> > > >> special setup or BSP configuration needed?
> > > >> Thanks,
> > > >> Alan
> > > >
> > > > Hi Alan,
> > > > First of all, thank you for taking this initiative.
> > > > I have tried using the default bootloader in Pi3 to load RTEMS
> but
> > > it doesn't work,
> > > > Can you try it?
> > > > The currently use U-Boot in 32bit mode as the bootloader.
> > > > You can use the below instructions to build U-Boot in 32bit mode
> > > >
> > > > git clone https://github.com/u-boot/u-boot.git u-boot
> > > > cd u-boot
> > > > git revert 995eab8b5b580b67394312b1621c60a71042cd18
> > > > make CROSS_COMPILE=arm-linux-gnueabi- rpi_3_32b_defconfig
> > > > make CROSS_COMPILE=arm-linux-gnueabi-
> > > >
> > > > This one uses an old version of U-Boot and I don't know if there
> is
> > > > a new way to build in 32bit mode.
> > > >
> > > > To build the U-Boot image of RTEMS you can use the below
> instructions
> > > >
> > > > arm-rtems5-objcopy -Obinary hello.exe kernel.img
> > > > mkimage -A arm -O linux -T kernel -a 0x20 -e 0x200080 -d
> > > kernel.img -C none rtems.img
> > > >
> > > > To load and run in U-Boot
> > > >
> > > > fatload mmc 0 0x20 rtems.img
> > > > fatload mmc 0 0x1000 bcm2710-rpi-3-b.dtb
> > > > bootm 0x20 - 0x1000
> > > >
> > > > And to make your U-Boot build process simpler I have uploaded my
> > > u-boot.bin
> > > > to my github, please use it :)
> > > > https://github.com/gs-niteesh/rpi3_RTEMS
> > > >
> > > > And sorry for the delay, I tested all these instructions again
> > > before sending them.
> > > >
> > > > Thanks
> > > > Niteesh.
> > > >
> > > >   On Sun, Feb 16, 2020 at 2:35 AM G. S. Niteesh <
> gsnb...@gmail.com
> > > > wrote:
> > > >>
> > > >> >
> > > >> > Hii,
> > > >> > This is a reminder message since this patch has been unnoticed
> > > for a while.
> > > >> > I have tested it on Raspberry Pi 3 and it works fine. There is
> > > also another patch
> > > >> >
> > > https://lists.rtems.org/pipermail/devel/2020-February/057194.html,
> > > please
> > > >> > do have a look at these.
> > > >> >
> > > >> > Thank you.
> > > >> > Niteesh
> > > >> > On Mon, Feb 10, 2020 at 12:52 AM G S Niteesh <
> gsnb...@gmail.com
> > > > wrote:
> > > >> >>
> > > >> >> This patch adds driver for Mini UART present in Raspberry Pi
> 3
> > > >> >> and above, this UART is currently used as the primary UART in
> > > >> >> these models.
> > > >> >> The Mini UART is similar to ns16550, this driver is built
> > > >> >> upon libchip/ns16550.
> > > >> >> ---
> > > >> >>  bsps/arm/raspberrypi/console/console-config.c | 118
> > > --
> >

Re: [PATCH v3 2/2] bsp/raspberrypi: Mini UART driver

2020-02-16 Thread Alan Cudmore 
I'm definitely using the kernel_address, but letting the firmware
decide what image to boot. For me kernel.img is the single core ARM
images. kernel7.img is used for the raspberry pi 2 and 3. With these
names, I can have both images on the same SD card to test in all of my
Pis.


my config.txt:
enable_uart=1
kernel_address=0x20


On Sun, Feb 16, 2020 at 11:44 AM Christian Mauderer  wrote:
>
> On 16/02/2020 17:31, G. S. Niteesh wrote:
> > Can you please share your config.txt for Pi3.
>
> +1
>
> It's interesting that it seems to work without an adapted config.txt. It
> should be at least necessary to define the start address.
>
> >
> > Thanks,
> > Niteesh
> >
> > On Sun, Feb 16, 2020 at 9:58 PM Alan Cudmore  > > wrote:
> >
> > I tried running my raspberrypi BSP image that worked on the Pi Zero
> > and W, but it did not work on the Pi 3.
> >
> > I built the raspberrypi2 BSP, used objcopy to copy the binary to my sd
> > card as kernel7.img, and it works on my Pi 3 and Pi3 A+ ( without
> > ethernet) . Note that my config.txt file does not specify the kernel
> > image, so the firmware defaults to kernel.img for the single core
> > models and kernel7.img for the 2 and 3.
> >
> > I probably wont get a chance to try u-boot until later today or
> > tomorrow.
> >
> > But these patches are great for enabling the Pi Zero W and Pi 3 models!
> > Thanks,
> > Alan
> >
> > On Sun, Feb 16, 2020 at 10:58 AM G. S. Niteesh  > > wrote:
> > >
> > > On Sun, Feb 16, 2020 at 8:37 PM Alan Cudmore
> > mailto:alan.cudm...@gmail.com>> wrote:
> > >>
> > >> Hi Niteesh,
> > >> I can try this patch on my Pi 3. Which BSP should I use? Is there any
> > >> special setup or BSP configuration needed?
> > >> Thanks,
> > >> Alan
> > >
> > > Hi Alan,
> > > First of all, thank you for taking this initiative.
> > > I have tried using the default bootloader in Pi3 to load RTEMS but
> > it doesn't work,
> > > Can you try it?
> > > The currently use U-Boot in 32bit mode as the bootloader.
> > > You can use the below instructions to build U-Boot in 32bit mode
> > >
> > > git clone https://github.com/u-boot/u-boot.git u-boot
> > > cd u-boot
> > > git revert 995eab8b5b580b67394312b1621c60a71042cd18
> > > make CROSS_COMPILE=arm-linux-gnueabi- rpi_3_32b_defconfig
> > > make CROSS_COMPILE=arm-linux-gnueabi-
> > >
> > > This one uses an old version of U-Boot and I don't know if there is
> > > a new way to build in 32bit mode.
> > >
> > > To build the U-Boot image of RTEMS you can use the below instructions
> > >
> > > arm-rtems5-objcopy -Obinary hello.exe kernel.img
> > > mkimage -A arm -O linux -T kernel -a 0x20 -e 0x200080 -d
> > kernel.img -C none rtems.img
> > >
> > > To load and run in U-Boot
> > >
> > > fatload mmc 0 0x20 rtems.img
> > > fatload mmc 0 0x1000 bcm2710-rpi-3-b.dtb
> > > bootm 0x20 - 0x1000
> > >
> > > And to make your U-Boot build process simpler I have uploaded my
> > u-boot.bin
> > > to my github, please use it :)
> > > https://github.com/gs-niteesh/rpi3_RTEMS
> > >
> > > And sorry for the delay, I tested all these instructions again
> > before sending them.
> > >
> > > Thanks
> > > Niteesh.
> > >
> > >   On Sun, Feb 16, 2020 at 2:35 AM G. S. Niteesh  > > wrote:
> > >>
> > >> >
> > >> > Hii,
> > >> > This is a reminder message since this patch has been unnoticed
> > for a while.
> > >> > I have tested it on Raspberry Pi 3 and it works fine. There is
> > also another patch
> > >> >
> > https://lists.rtems.org/pipermail/devel/2020-February/057194.html,
> > please
> > >> > do have a look at these.
> > >> >
> > >> > Thank you.
> > >> > Niteesh
> > >> > On Mon, Feb 10, 2020 at 12:52 AM G S Niteesh  > > wrote:
> > >> >>
> > >> >> This patch adds driver for Mini UART present in Raspberry Pi 3
> > >> >> and above, this UART is currently used as the primary UART in
> > >> >> these models.
> > >> >> The Mini UART is similar to ns16550, this driver is built
> > >> >> upon libchip/ns16550.
> > >> >> ---
> > >> >>  bsps/arm/raspberrypi/console/console-config.c | 118
> > --
> > >> >>  bsps/arm/raspberrypi/include/bsp/usart.h  |   1 +
> > >> >>  2 files changed, 110 insertions(+), 9 deletions(-)
> > >> >>
> > >> >> diff --git a/bsps/arm/raspberrypi/console/console-config.c
> > b/bsps/arm/raspberrypi/console/console-config.c
> > >> >> index 48c4c6a3ec..62196786dd 100644
> > >> >> --- a/bsps/arm/raspberrypi/console/console-config.c
> > >> >> +++ b/bsps/arm/raspberrypi/console/console-config.c
> > >> >> @@ -24,6 +24,7 @@

Re: [PATCH v3 2/2] bsp/raspberrypi: Mini UART driver

2020-02-16 Thread Christian Mauderer 
On 16/02/2020 17:31, G. S. Niteesh wrote:
> Can you please share your config.txt for Pi3.

+1

It's interesting that it seems to work without an adapted config.txt. It
should be at least necessary to define the start address.

> 
> Thanks,
> Niteesh
> 
> On Sun, Feb 16, 2020 at 9:58 PM Alan Cudmore  > wrote:
> 
> I tried running my raspberrypi BSP image that worked on the Pi Zero
> and W, but it did not work on the Pi 3.
> 
> I built the raspberrypi2 BSP, used objcopy to copy the binary to my sd
> card as kernel7.img, and it works on my Pi 3 and Pi3 A+ ( without
> ethernet) . Note that my config.txt file does not specify the kernel
> image, so the firmware defaults to kernel.img for the single core
> models and kernel7.img for the 2 and 3.
> 
> I probably wont get a chance to try u-boot until later today or
> tomorrow.
> 
> But these patches are great for enabling the Pi Zero W and Pi 3 models!
> Thanks,
> Alan
> 
> On Sun, Feb 16, 2020 at 10:58 AM G. S. Niteesh  > wrote:
> >
> > On Sun, Feb 16, 2020 at 8:37 PM Alan Cudmore
> mailto:alan.cudm...@gmail.com>> wrote:
> >>
> >> Hi Niteesh,
> >> I can try this patch on my Pi 3. Which BSP should I use? Is there any
> >> special setup or BSP configuration needed?
> >> Thanks,
> >> Alan
> >
> > Hi Alan,
> > First of all, thank you for taking this initiative.
> > I have tried using the default bootloader in Pi3 to load RTEMS but
> it doesn't work,
> > Can you try it?
> > The currently use U-Boot in 32bit mode as the bootloader.
> > You can use the below instructions to build U-Boot in 32bit mode
> >
> > git clone https://github.com/u-boot/u-boot.git u-boot
> > cd u-boot
> > git revert 995eab8b5b580b67394312b1621c60a71042cd18
> > make CROSS_COMPILE=arm-linux-gnueabi- rpi_3_32b_defconfig
> > make CROSS_COMPILE=arm-linux-gnueabi-
> >
> > This one uses an old version of U-Boot and I don't know if there is
> > a new way to build in 32bit mode.
> >
> > To build the U-Boot image of RTEMS you can use the below instructions
> >
> > arm-rtems5-objcopy -Obinary hello.exe kernel.img
> > mkimage -A arm -O linux -T kernel -a 0x20 -e 0x200080 -d
> kernel.img -C none rtems.img
> >
> > To load and run in U-Boot
> >
> > fatload mmc 0 0x20 rtems.img
> > fatload mmc 0 0x1000 bcm2710-rpi-3-b.dtb
> > bootm 0x20 - 0x1000
> >
> > And to make your U-Boot build process simpler I have uploaded my
> u-boot.bin
> > to my github, please use it :)
> > https://github.com/gs-niteesh/rpi3_RTEMS
> >
> > And sorry for the delay, I tested all these instructions again
> before sending them.
> >
> > Thanks
> > Niteesh.
> >
> >   On Sun, Feb 16, 2020 at 2:35 AM G. S. Niteesh  > wrote:
> >>
> >> >
> >> > Hii,
> >> > This is a reminder message since this patch has been unnoticed
> for a while.
> >> > I have tested it on Raspberry Pi 3 and it works fine. There is
> also another patch
> >> >
> https://lists.rtems.org/pipermail/devel/2020-February/057194.html,
> please
> >> > do have a look at these.
> >> >
> >> > Thank you.
> >> > Niteesh
> >> > On Mon, Feb 10, 2020 at 12:52 AM G S Niteesh  > wrote:
> >> >>
> >> >> This patch adds driver for Mini UART present in Raspberry Pi 3
> >> >> and above, this UART is currently used as the primary UART in
> >> >> these models.
> >> >> The Mini UART is similar to ns16550, this driver is built
> >> >> upon libchip/ns16550.
> >> >> ---
> >> >>  bsps/arm/raspberrypi/console/console-config.c | 118
> --
> >> >>  bsps/arm/raspberrypi/include/bsp/usart.h      |   1 +
> >> >>  2 files changed, 110 insertions(+), 9 deletions(-)
> >> >>
> >> >> diff --git a/bsps/arm/raspberrypi/console/console-config.c
> b/bsps/arm/raspberrypi/console/console-config.c
> >> >> index 48c4c6a3ec..62196786dd 100644
> >> >> --- a/bsps/arm/raspberrypi/console/console-config.c
> >> >> +++ b/bsps/arm/raspberrypi/console/console-config.c
> >> >> @@ -24,6 +24,7 @@
> >> >>
> >> >>  #include 
> >> >>  #include 
> >> >> +#include 
> >> >>
> >> >>  #include 
> >> >>  #include 
> >> >> @@ -34,35 +35,103 @@
> >> >>  #include 
> >> >>  #include 
> >> >>  #include 
> >> >> +#include 
> >> >> +#include 
> >> >>
> >> >> -
> >> >> -#define UART0     "/dev/ttyS0"
> >> >> +/**
> >> >> + * UART0 - PL011
> >> >> + * UART1 - Mini UART
> >> >> + */
> >> >> +#define PL011     "/dev/ttyAMA0"
> >> >> +#define MINIUART  "/dev/ttyS0"
> >> >>  #define FBCONS    "/dev/fbcons"
> >> >>
> >> >> 

Re: [PATCH v3 2/2] bsp/raspberrypi: Mini UART driver

2020-02-16 Thread G. S. Niteesh 
Can you please share your config.txt for Pi3.

Thanks,
Niteesh

On Sun, Feb 16, 2020 at 9:58 PM Alan Cudmore  wrote:

> I tried running my raspberrypi BSP image that worked on the Pi Zero
> and W, but it did not work on the Pi 3.
>
> I built the raspberrypi2 BSP, used objcopy to copy the binary to my sd
> card as kernel7.img, and it works on my Pi 3 and Pi3 A+ ( without
> ethernet) . Note that my config.txt file does not specify the kernel
> image, so the firmware defaults to kernel.img for the single core
> models and kernel7.img for the 2 and 3.
>
> I probably wont get a chance to try u-boot until later today or tomorrow.
>
> But these patches are great for enabling the Pi Zero W and Pi 3 models!
> Thanks,
> Alan
>
> On Sun, Feb 16, 2020 at 10:58 AM G. S. Niteesh  wrote:
> >
> > On Sun, Feb 16, 2020 at 8:37 PM Alan Cudmore 
> wrote:
> >>
> >> Hi Niteesh,
> >> I can try this patch on my Pi 3. Which BSP should I use? Is there any
> >> special setup or BSP configuration needed?
> >> Thanks,
> >> Alan
> >
> > Hi Alan,
> > First of all, thank you for taking this initiative.
> > I have tried using the default bootloader in Pi3 to load RTEMS but it
> doesn't work,
> > Can you try it?
> > The currently use U-Boot in 32bit mode as the bootloader.
> > You can use the below instructions to build U-Boot in 32bit mode
> >
> > git clone https://github.com/u-boot/u-boot.git u-boot
> > cd u-boot
> > git revert 995eab8b5b580b67394312b1621c60a71042cd18
> > make CROSS_COMPILE=arm-linux-gnueabi- rpi_3_32b_defconfig
> > make CROSS_COMPILE=arm-linux-gnueabi-
> >
> > This one uses an old version of U-Boot and I don't know if there is
> > a new way to build in 32bit mode.
> >
> > To build the U-Boot image of RTEMS you can use the below instructions
> >
> > arm-rtems5-objcopy -Obinary hello.exe kernel.img
> > mkimage -A arm -O linux -T kernel -a 0x20 -e 0x200080 -d kernel.img
> -C none rtems.img
> >
> > To load and run in U-Boot
> >
> > fatload mmc 0 0x20 rtems.img
> > fatload mmc 0 0x1000 bcm2710-rpi-3-b.dtb
> > bootm 0x20 - 0x1000
> >
> > And to make your U-Boot build process simpler I have uploaded my
> u-boot.bin
> > to my github, please use it :)
> > https://github.com/gs-niteesh/rpi3_RTEMS
> >
> > And sorry for the delay, I tested all these instructions again before
> sending them.
> >
> > Thanks
> > Niteesh.
> >
> >   On Sun, Feb 16, 2020 at 2:35 AM G. S. Niteesh 
> wrote:
> >>
> >> >
> >> > Hii,
> >> > This is a reminder message since this patch has been unnoticed for a
> while.
> >> > I have tested it on Raspberry Pi 3 and it works fine. There is also
> another patch
> >> > https://lists.rtems.org/pipermail/devel/2020-February/057194.html,
> please
> >> > do have a look at these.
> >> >
> >> > Thank you.
> >> > Niteesh
> >> > On Mon, Feb 10, 2020 at 12:52 AM G S Niteesh 
> wrote:
> >> >>
> >> >> This patch adds driver for Mini UART present in Raspberry Pi 3
> >> >> and above, this UART is currently used as the primary UART in
> >> >> these models.
> >> >> The Mini UART is similar to ns16550, this driver is built
> >> >> upon libchip/ns16550.
> >> >> ---
> >> >>  bsps/arm/raspberrypi/console/console-config.c | 118
> --
> >> >>  bsps/arm/raspberrypi/include/bsp/usart.h  |   1 +
> >> >>  2 files changed, 110 insertions(+), 9 deletions(-)
> >> >>
> >> >> diff --git a/bsps/arm/raspberrypi/console/console-config.c
> b/bsps/arm/raspberrypi/console/console-config.c
> >> >> index 48c4c6a3ec..62196786dd 100644
> >> >> --- a/bsps/arm/raspberrypi/console/console-config.c
> >> >> +++ b/bsps/arm/raspberrypi/console/console-config.c
> >> >> @@ -24,6 +24,7 @@
> >> >>
> >> >>  #include 
> >> >>  #include 
> >> >> +#include 
> >> >>
> >> >>  #include 
> >> >>  #include 
> >> >> @@ -34,35 +35,103 @@
> >> >>  #include 
> >> >>  #include 
> >> >>  #include 
> >> >> +#include 
> >> >> +#include 
> >> >>
> >> >> -
> >> >> -#define UART0 "/dev/ttyS0"
> >> >> +/**
> >> >> + * UART0 - PL011
> >> >> + * UART1 - Mini UART
> >> >> + */
> >> >> +#define PL011 "/dev/ttyAMA0"
> >> >> +#define MINIUART  "/dev/ttyS0"
> >> >>  #define FBCONS"/dev/fbcons"
> >> >>
> >> >>  arm_pl011_context pl011_context;
> >> >> +ns16550_context mini_uart_context;
> >> >>
> >> >>  rpi_fb_context fb_context;
> >> >>
> >> >> -static void output_char_serial(char c)
> >> >> +static void output_char_pl011(char c)
> >> >>  {
> >> >>arm_pl011_write_polled(_context.base, c);
> >> >>  }
> >> >>
> >> >> +static void output_char_mini_uart(char c)
> >> >> +{
> >> >> +  ns16550_polled_putchar(_uart_context.base, c);
> >> >> +}
> >> >> +
> >> >>  void output_char_fb(char c)
> >> >>  {
> >> >>fbcons_write_polled(_context.base, c);
> >> >>  }
> >> >>
> >> >> +static uint8_t mini_uart_get_reg(uintptr_t port, uint8_t index)
> >> >> +{
> >> >> +  volatile uint32_t *val = (volatile uint32_t *)port + index;
> >> >> +  return (uint8_t) *val;
> >> >> +}
> >> >> +
> >> >> +static void mini_uart_set_reg(uintptr_t port, uint8_t index,
> uint8_t

Re: [PATCH v3 2/2] bsp/raspberrypi: Mini UART driver

2020-02-16 Thread Alan Cudmore 
I tried running my raspberrypi BSP image that worked on the Pi Zero
and W, but it did not work on the Pi 3.

I built the raspberrypi2 BSP, used objcopy to copy the binary to my sd
card as kernel7.img, and it works on my Pi 3 and Pi3 A+ ( without
ethernet) . Note that my config.txt file does not specify the kernel
image, so the firmware defaults to kernel.img for the single core
models and kernel7.img for the 2 and 3.

I probably wont get a chance to try u-boot until later today or tomorrow.

But these patches are great for enabling the Pi Zero W and Pi 3 models!
Thanks,
Alan

On Sun, Feb 16, 2020 at 10:58 AM G. S. Niteesh  wrote:
>
> On Sun, Feb 16, 2020 at 8:37 PM Alan Cudmore  wrote:
>>
>> Hi Niteesh,
>> I can try this patch on my Pi 3. Which BSP should I use? Is there any
>> special setup or BSP configuration needed?
>> Thanks,
>> Alan
>
> Hi Alan,
> First of all, thank you for taking this initiative.
> I have tried using the default bootloader in Pi3 to load RTEMS but it doesn't 
> work,
> Can you try it?
> The currently use U-Boot in 32bit mode as the bootloader.
> You can use the below instructions to build U-Boot in 32bit mode
>
> git clone https://github.com/u-boot/u-boot.git u-boot
> cd u-boot
> git revert 995eab8b5b580b67394312b1621c60a71042cd18
> make CROSS_COMPILE=arm-linux-gnueabi- rpi_3_32b_defconfig
> make CROSS_COMPILE=arm-linux-gnueabi-
>
> This one uses an old version of U-Boot and I don't know if there is
> a new way to build in 32bit mode.
>
> To build the U-Boot image of RTEMS you can use the below instructions
>
> arm-rtems5-objcopy -Obinary hello.exe kernel.img
> mkimage -A arm -O linux -T kernel -a 0x20 -e 0x200080 -d kernel.img -C 
> none rtems.img
>
> To load and run in U-Boot
>
> fatload mmc 0 0x20 rtems.img
> fatload mmc 0 0x1000 bcm2710-rpi-3-b.dtb
> bootm 0x20 - 0x1000
>
> And to make your U-Boot build process simpler I have uploaded my u-boot.bin
> to my github, please use it :)
> https://github.com/gs-niteesh/rpi3_RTEMS
>
> And sorry for the delay, I tested all these instructions again before sending 
> them.
>
> Thanks
> Niteesh.
>
>   On Sun, Feb 16, 2020 at 2:35 AM G. S. Niteesh  wrote:
>>
>> >
>> > Hii,
>> > This is a reminder message since this patch has been unnoticed for a while.
>> > I have tested it on Raspberry Pi 3 and it works fine. There is also 
>> > another patch
>> > https://lists.rtems.org/pipermail/devel/2020-February/057194.html, please
>> > do have a look at these.
>> >
>> > Thank you.
>> > Niteesh
>> > On Mon, Feb 10, 2020 at 12:52 AM G S Niteesh  wrote:
>> >>
>> >> This patch adds driver for Mini UART present in Raspberry Pi 3
>> >> and above, this UART is currently used as the primary UART in
>> >> these models.
>> >> The Mini UART is similar to ns16550, this driver is built
>> >> upon libchip/ns16550.
>> >> ---
>> >>  bsps/arm/raspberrypi/console/console-config.c | 118 --
>> >>  bsps/arm/raspberrypi/include/bsp/usart.h  |   1 +
>> >>  2 files changed, 110 insertions(+), 9 deletions(-)
>> >>
>> >> diff --git a/bsps/arm/raspberrypi/console/console-config.c 
>> >> b/bsps/arm/raspberrypi/console/console-config.c
>> >> index 48c4c6a3ec..62196786dd 100644
>> >> --- a/bsps/arm/raspberrypi/console/console-config.c
>> >> +++ b/bsps/arm/raspberrypi/console/console-config.c
>> >> @@ -24,6 +24,7 @@
>> >>
>> >>  #include 
>> >>  #include 
>> >> +#include 
>> >>
>> >>  #include 
>> >>  #include 
>> >> @@ -34,35 +35,103 @@
>> >>  #include 
>> >>  #include 
>> >>  #include 
>> >> +#include 
>> >> +#include 
>> >>
>> >> -
>> >> -#define UART0 "/dev/ttyS0"
>> >> +/**
>> >> + * UART0 - PL011
>> >> + * UART1 - Mini UART
>> >> + */
>> >> +#define PL011 "/dev/ttyAMA0"
>> >> +#define MINIUART  "/dev/ttyS0"
>> >>  #define FBCONS"/dev/fbcons"
>> >>
>> >>  arm_pl011_context pl011_context;
>> >> +ns16550_context mini_uart_context;
>> >>
>> >>  rpi_fb_context fb_context;
>> >>
>> >> -static void output_char_serial(char c)
>> >> +static void output_char_pl011(char c)
>> >>  {
>> >>arm_pl011_write_polled(_context.base, c);
>> >>  }
>> >>
>> >> +static void output_char_mini_uart(char c)
>> >> +{
>> >> +  ns16550_polled_putchar(_uart_context.base, c);
>> >> +}
>> >> +
>> >>  void output_char_fb(char c)
>> >>  {
>> >>fbcons_write_polled(_context.base, c);
>> >>  }
>> >>
>> >> +static uint8_t mini_uart_get_reg(uintptr_t port, uint8_t index)
>> >> +{
>> >> +  volatile uint32_t *val = (volatile uint32_t *)port + index;
>> >> +  return (uint8_t) *val;
>> >> +}
>> >> +
>> >> +static void mini_uart_set_reg(uintptr_t port, uint8_t index, uint8_t val)
>> >> +{
>> >> +  volatile uint32_t *reg = (volatile uint32_t *)port + index;
>> >> +  *reg = val;
>> >> +}
>> >> +
>> >>  static void init_ctx_arm_pl011(
>> >>const void *fdt,
>> >>int node
>> >>  )
>> >>  {
>> >>arm_pl011_context *ctx = _context;
>> >> -  rtems_termios_device_context_initialize(>base, "UART");
>> >> +  rtems_termios_device_context_initialize(>base, "PL011UART");

Re: [PATCH v3 2/2] bsp/raspberrypi: Mini UART driver

2020-02-16 Thread G. S. Niteesh 
On Sun, Feb 16, 2020 at 8:37 PM Alan Cudmore  wrote:

> Hi Niteesh,
> I can try this patch on my Pi 3. Which BSP should I use? Is there any
> special setup or BSP configuration needed?
> Thanks,
> Alan
>
Hi Alan,
First of all, thank you for taking this initiative.
I have tried using the default bootloader in Pi3 to load RTEMS but it
doesn't work,
Can you try it?
The currently use U-Boot in 32bit mode as the bootloader.
You can use the below instructions to build U-Boot in 32bit mode

git clone https://github.com/u-boot/u-boot.git u-boot
cd u-boot
git revert 995eab8b5b580b67394312b1621c60a71042cd18
make CROSS_COMPILE=arm-linux-gnueabi- rpi_3_32b_defconfig
make CROSS_COMPILE=arm-linux-gnueabi-

This one uses an old version of U-Boot and I don't know if there is
a new way to build in 32bit mode.

To build the U-Boot image of RTEMS you can use the below instructions

arm-rtems5-objcopy -Obinary hello.exe kernel.img
mkimage -A arm -O linux -T kernel -a 0x20 -e 0x200080 -d kernel.img -C
none rtems.img

To load and run in U-Boot

fatload mmc 0 0x20 rtems.img
fatload mmc 0 0x1000 bcm2710-rpi-3-b.dtb
bootm 0x20 - 0x1000

And to make your U-Boot build process simpler I have uploaded my u-boot.bin
to my github, please use it :)
https://github.com/gs-niteesh/rpi3_RTEMS

And sorry for the delay, I tested all these instructions again before
sending them.

Thanks
Niteesh.

  On Sun, Feb 16, 2020 at 2:35 AM G. S. Niteesh  wrote:

> >
> > Hii,
> > This is a reminder message since this patch has been unnoticed for a
> while.
> > I have tested it on Raspberry Pi 3 and it works fine. There is also
> another patch
> > https://lists.rtems.org/pipermail/devel/2020-February/057194.html,
> please
> > do have a look at these.
> >
> > Thank you.
> > Niteesh
> > On Mon, Feb 10, 2020 at 12:52 AM G S Niteesh  wrote:
> >>
> >> This patch adds driver for Mini UART present in Raspberry Pi 3
> >> and above, this UART is currently used as the primary UART in
> >> these models.
> >> The Mini UART is similar to ns16550, this driver is built
> >> upon libchip/ns16550.
> >> ---
> >>  bsps/arm/raspberrypi/console/console-config.c | 118 --
> >>  bsps/arm/raspberrypi/include/bsp/usart.h  |   1 +
> >>  2 files changed, 110 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/bsps/arm/raspberrypi/console/console-config.c
> b/bsps/arm/raspberrypi/console/console-config.c
> >> index 48c4c6a3ec..62196786dd 100644
> >> --- a/bsps/arm/raspberrypi/console/console-config.c
> >> +++ b/bsps/arm/raspberrypi/console/console-config.c
> >> @@ -24,6 +24,7 @@
> >>
> >>  #include 
> >>  #include 
> >> +#include 
> >>
> >>  #include 
> >>  #include 
> >> @@ -34,35 +35,103 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >> +#include 
> >>
> >> -
> >> -#define UART0 "/dev/ttyS0"
> >> +/**
> >> + * UART0 - PL011
> >> + * UART1 - Mini UART
> >> + */
> >> +#define PL011 "/dev/ttyAMA0"
> >> +#define MINIUART  "/dev/ttyS0"
> >>  #define FBCONS"/dev/fbcons"
> >>
> >>  arm_pl011_context pl011_context;
> >> +ns16550_context mini_uart_context;
> >>
> >>  rpi_fb_context fb_context;
> >>
> >> -static void output_char_serial(char c)
> >> +static void output_char_pl011(char c)
> >>  {
> >>arm_pl011_write_polled(_context.base, c);
> >>  }
> >>
> >> +static void output_char_mini_uart(char c)
> >> +{
> >> +  ns16550_polled_putchar(_uart_context.base, c);
> >> +}
> >> +
> >>  void output_char_fb(char c)
> >>  {
> >>fbcons_write_polled(_context.base, c);
> >>  }
> >>
> >> +static uint8_t mini_uart_get_reg(uintptr_t port, uint8_t index)
> >> +{
> >> +  volatile uint32_t *val = (volatile uint32_t *)port + index;
> >> +  return (uint8_t) *val;
> >> +}
> >> +
> >> +static void mini_uart_set_reg(uintptr_t port, uint8_t index, uint8_t
> val)
> >> +{
> >> +  volatile uint32_t *reg = (volatile uint32_t *)port + index;
> >> +  *reg = val;
> >> +}
> >> +
> >>  static void init_ctx_arm_pl011(
> >>const void *fdt,
> >>int node
> >>  )
> >>  {
> >>arm_pl011_context *ctx = _context;
> >> -  rtems_termios_device_context_initialize(>base, "UART");
> >> +  rtems_termios_device_context_initialize(>base, "PL011UART");
> >>ctx->regs = raspberrypi_get_reg_of_node(fdt, node);
> >>  }
> >>
> >> +static uint32_t calculate_baud_divisor(
> >> +  ns16550_context *ctx,
> >> +  uint32_t baud
> >> +)
> >> +{
> >> +  uint32_t baudDivisor = (ctx->clock / (8 * baud)) - 1;
> >> +  return baudDivisor;
> >> +}
> >> +
> >> +static void init_ctx_mini_uart(
> >> +  const void *fdt,
> >> +  int node
> >> +)
> >> +{
> >> +  const char *status;
> >> +  int len;
> >> +  ns16550_context *ctx;
> >> +
> >> +  memset(_uart_context, 0, sizeof(mini_uart_context));
> >> +  ctx = _uart_context;
> >> +
> >> +  rtems_termios_device_context_initialize(>base, "MiniUART");
> >> +
> >> +  status = fdt_getprop(fdt, node, "status", );
> >> +  if ( status == NULL || strcmp(status, "disabled" ) == 0){
> >> +return ;
> >> +  }
> >> +
> >> +  ctx->port =

Re: [PATCH v3 2/2] bsp/raspberrypi: Mini UART driver

2020-02-16 Thread Alan Cudmore 
Hi Niteesh,
I can try this patch on my Pi 3. Which BSP should I use? Is there any
special setup or BSP configuration needed?
Thanks,
Alan

On Sun, Feb 16, 2020 at 2:35 AM G. S. Niteesh  wrote:
>
> Hii,
> This is a reminder message since this patch has been unnoticed for a while.
> I have tested it on Raspberry Pi 3 and it works fine. There is also another 
> patch
> https://lists.rtems.org/pipermail/devel/2020-February/057194.html, please
> do have a look at these.
>
> Thank you.
> Niteesh
> On Mon, Feb 10, 2020 at 12:52 AM G S Niteesh  wrote:
>>
>> This patch adds driver for Mini UART present in Raspberry Pi 3
>> and above, this UART is currently used as the primary UART in
>> these models.
>> The Mini UART is similar to ns16550, this driver is built
>> upon libchip/ns16550.
>> ---
>>  bsps/arm/raspberrypi/console/console-config.c | 118 --
>>  bsps/arm/raspberrypi/include/bsp/usart.h  |   1 +
>>  2 files changed, 110 insertions(+), 9 deletions(-)
>>
>> diff --git a/bsps/arm/raspberrypi/console/console-config.c 
>> b/bsps/arm/raspberrypi/console/console-config.c
>> index 48c4c6a3ec..62196786dd 100644
>> --- a/bsps/arm/raspberrypi/console/console-config.c
>> +++ b/bsps/arm/raspberrypi/console/console-config.c
>> @@ -24,6 +24,7 @@
>>
>>  #include 
>>  #include 
>> +#include 
>>
>>  #include 
>>  #include 
>> @@ -34,35 +35,103 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +#include 
>>
>> -
>> -#define UART0 "/dev/ttyS0"
>> +/**
>> + * UART0 - PL011
>> + * UART1 - Mini UART
>> + */
>> +#define PL011 "/dev/ttyAMA0"
>> +#define MINIUART  "/dev/ttyS0"
>>  #define FBCONS"/dev/fbcons"
>>
>>  arm_pl011_context pl011_context;
>> +ns16550_context mini_uart_context;
>>
>>  rpi_fb_context fb_context;
>>
>> -static void output_char_serial(char c)
>> +static void output_char_pl011(char c)
>>  {
>>arm_pl011_write_polled(_context.base, c);
>>  }
>>
>> +static void output_char_mini_uart(char c)
>> +{
>> +  ns16550_polled_putchar(_uart_context.base, c);
>> +}
>> +
>>  void output_char_fb(char c)
>>  {
>>fbcons_write_polled(_context.base, c);
>>  }
>>
>> +static uint8_t mini_uart_get_reg(uintptr_t port, uint8_t index)
>> +{
>> +  volatile uint32_t *val = (volatile uint32_t *)port + index;
>> +  return (uint8_t) *val;
>> +}
>> +
>> +static void mini_uart_set_reg(uintptr_t port, uint8_t index, uint8_t val)
>> +{
>> +  volatile uint32_t *reg = (volatile uint32_t *)port + index;
>> +  *reg = val;
>> +}
>> +
>>  static void init_ctx_arm_pl011(
>>const void *fdt,
>>int node
>>  )
>>  {
>>arm_pl011_context *ctx = _context;
>> -  rtems_termios_device_context_initialize(>base, "UART");
>> +  rtems_termios_device_context_initialize(>base, "PL011UART");
>>ctx->regs = raspberrypi_get_reg_of_node(fdt, node);
>>  }
>>
>> +static uint32_t calculate_baud_divisor(
>> +  ns16550_context *ctx,
>> +  uint32_t baud
>> +)
>> +{
>> +  uint32_t baudDivisor = (ctx->clock / (8 * baud)) - 1;
>> +  return baudDivisor;
>> +}
>> +
>> +static void init_ctx_mini_uart(
>> +  const void *fdt,
>> +  int node
>> +)
>> +{
>> +  const char *status;
>> +  int len;
>> +  ns16550_context *ctx;
>> +
>> +  memset(_uart_context, 0, sizeof(mini_uart_context));
>> +  ctx = _uart_context;
>> +
>> +  rtems_termios_device_context_initialize(>base, "MiniUART");
>> +
>> +  status = fdt_getprop(fdt, node, "status", );
>> +  if ( status == NULL || strcmp(status, "disabled" ) == 0){
>> +return ;
>> +  }
>> +
>> +  ctx->port = (uintptr_t) raspberrypi_get_reg_of_node(fdt, node);
>> +  ctx->initial_baud = MINI_UART_DEFAULT_BAUD;
>> +  ctx->clock = BCM2835_CLOCK_FREQ;
>> +  ctx->calculate_baud_divisor = calculate_baud_divisor;
>> +  ctx->get_reg = mini_uart_get_reg;
>> +  ctx->set_reg = mini_uart_set_reg;
>> +
>> +  rtems_gpio_bsp_select_specific_io(0, 14, RPI_ALT_FUNC_5, NULL);
>> +  rtems_gpio_bsp_select_specific_io(0, 15, RPI_ALT_FUNC_5, NULL);
>> +  rtems_gpio_bsp_set_resistor_mode(0, 14, NO_PULL_RESISTOR);
>> +  rtems_gpio_bsp_set_resistor_mode(0, 15, NO_PULL_RESISTOR);
>> +
>> +  BCM2835_REG(AUX_ENABLES) |= 0x1;
>> +  ns16550_probe(>base);
>> +}
>> +
>>  static void register_fb( void )
>>  {
>>if (fbcons_probe(_context.base) == true) {
>> @@ -87,16 +156,28 @@ static void console_select( void )
>>  link(FBCONS, CONSOLE_DEVICE_NAME);
>>  return ;
>>}
>> +} else if ( strncmp( opt, MINIUART, sizeof(MINIUART) - 1 ) == 0) {
>> +  BSP_output_char = output_char_mini_uart;
>> +  link(MINIUART, CONSOLE_DEVICE_NAME);
>> +} else if ( strncmp( opt, PL011, sizeof(PL011) - 1 ) == 0) {
>> +  BSP_output_char = output_char_pl011;
>> +  link(PL011, CONSOLE_DEVICE_NAME);
>>  }
>> +  }else {
>> +/**
>> + * If no command line option was given, default to PL011.
>> + */
>> +BSP_output_char = output_char_pl011;
>> +link(PL011, CONSOLE_DEVICE_NAME);
>>}
>> -  BSP_output_char = output_char_serial;
>> -  link(UART0, CONSOLE_DEVICE_NAME);
>>  }
>>
>>

Re: [PATCH 13/18] config: Add _Thread_Idle_body

2020-02-16 Thread Gedare Bloom 
On Sun, Feb 16, 2020 at 12:30 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
> On 16/02/2020 05:31, Gedare Bloom wrote:
>
> On Sat, Feb 15, 2020 at 4:36 PM Chris Johns  wrote:
>
>> On 2020-02-15 03:02, Sebastian Huber wrote:
>> > Move the idle thread body configuration constant out of the
>> > configuration table.
>> >
>> > Provide a default definition of the idle thread body constant.
>>
>> May be I am missing something simple here. How would I provide an custom
>> IDLE task? Is it by providing something like ...
>>
>> #include 
>>
>> const Thread_Idle_body _Thread_Idle_body = My_Idle_body;
>>
>>
> I think you do it by a configure macro that confdefs picks up by this line
> added:
> +const Thread_Idle_body _Thread_Idle_body = CONFIGURE_IDLE_TASK_BODY;
>
> It needs some doco ;)
>
> Sorry, my problem is that I am so familiar with this stuff that I don't
> need documentation. What do you want to have documented and were should it
> be placed?
>
> When I see a variable/function definition and want to see the Doxygen I
> just hit an editor key and get it. I don't want to duplicate documentation
> at the variable/function definition level.
>
 Well,
https://docs.rtems.org/branches/master/c-user/configuring_a_system.html#configure-idle-task-body
hasn't
seemed to change, so maybe that is just the point to make in the commit.
When we touch things that manipulate configuration, it is important to
understand whether or not it impacts the API. Sometimes that is hard for us
to tell in patch review just by looking quickly.

In the broader sense, the method used to initialize the idle task should be
explained at
https://docs.rtems.org/branches/master/c-user/initialization.html#the-idle-task
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel