RE: [PATCH 2/5] Modify termios to support dedicated input and output baud rates for termios structure

2017-03-14 Thread Kirspel, Kevin
I'll send new patches without the name change.

Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
235 Hembree Park Drive
Roswell GA 30076
Tel: (770)-510- ext. 81642
Direct: (770)-688-1642
Fax: (770)-510-4445

-Original Message-
From: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de] 
Sent: Tuesday, March 14, 2017 2:35 AM
To: devel@rtems.org
Cc: Kirspel, Kevin 
Subject: Re: [PATCH 2/5] Modify termios to support dedicated input and output 
baud rates for termios structure

On 13/03/17 17:00, Kevin Kirspel wrote:
> -  case RTEMS_IO_SNDWAKEUP:
> +  case TIOCSNDWU:
>   tty->tty_snd = *wakeup;
>   break;
>   
> -  case RTEMS_IO_RCVWAKEUP:
> +  case TIOCRCVWU:
>   tty->tty_rcv = *wakeup;
>   break;

Since they are RTEMS-specific and probably a (undocumented) part of the user 
API, could you please not change the IO control name.

--
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 3/5] Updated BSPs to use dedicated input and output baud rates in termios structure

2017-03-14 Thread Kevin Kirspel
---
 c/src/lib/libbsp/arm/csb336/console/uart.c |  2 +-
 c/src/lib/libbsp/arm/lpc32xx/console/hsu.c |  2 +-
 c/src/lib/libbsp/i386/shared/comm/tty_drv.c|  2 +-
 .../libbsp/lm32/shared/milkymist_console/console.c |  2 +-
 c/src/lib/libbsp/m68k/av5282/console/console.c |  6 ++---
 c/src/lib/libbsp/m68k/gen68340/console/console.c   | 18 --
 c/src/lib/libbsp/m68k/gen68360/console/console.c   |  2 +-
 c/src/lib/libbsp/m68k/genmcf548x/console/console.c |  2 +-
 c/src/lib/libbsp/m68k/mcf52235/console/console.c   |  8 ---
 c/src/lib/libbsp/m68k/mcf5225x/console/console.c   | 24 ++-
 c/src/lib/libbsp/m68k/mcf5235/console/console.c|  8 ---
 c/src/lib/libbsp/m68k/mcf5329/console/console.c|  8 ---
 c/src/lib/libbsp/m68k/mrm332/console/sci.c |  2 +-
 c/src/lib/libbsp/m68k/mvme167/console/console.c|  8 +++
 c/src/lib/libbsp/m68k/uC5282/console/console.c |  4 ++--
 c/src/lib/libbsp/powerpc/acinclude.m4  |  4 ++--
 c/src/lib/libbsp/powerpc/gen5200/console/console.c |  2 +-
 c/src/lib/libbsp/powerpc/shared/console/console.c  |  2 +-
 c/src/lib/libbsp/powerpc/tqm8xx/console/console.c  |  2 +-
 c/src/lib/libbsp/shared/console.c  |  4 ++--
 c/src/lib/libbsp/sparc/shared/uart/apbuart_cons.c  |  8 +++
 c/src/lib/libcpu/arm/at91rm9200/usart/usart.c  |  2 +-
 c/src/lib/libcpu/bfin/serial/uart.c|  4 ++--
 c/src/lib/libcpu/powerpc/mpc55xx/esci/esci.c   |  2 +-
 .../mpc5xx/console-generic/console-generic.c   |  2 +-
 .../mpc8260/console-generic/console-generic.c  |  4 ++--
 .../mpc8xx/console-generic/console-generic.c   |  4 ++--
 c/src/lib/libcpu/powerpc/ppc403/console/console.c  |  2 +-
 .../lib/libcpu/powerpc/ppc403/console/console405.c |  2 +-
 c/src/lib/libcpu/powerpc/ppc403/tty_drv/tty_drv.c  |  2 +-
 c/src/lib/libcpu/sh/sh7032/sci/sci.c   |  8 +++
 c/src/lib/libcpu/sh/sh7045/sci/sci.c   |  6 ++---
 c/src/lib/libcpu/sh/sh7045/sci/sci_termios.c   |  8 +++
 c/src/libchip/serial/mc68681.c |  2 +-
 c/src/libchip/serial/mc68681_baud.c| 28 ++
 c/src/libchip/serial/z85c30.c  |  2 +-
 36 files changed, 108 insertions(+), 90 deletions(-)

diff --git a/c/src/lib/libbsp/arm/csb336/console/uart.c 
b/c/src/lib/libbsp/arm/csb336/console/uart.c
index 1f3a4a1..e2e6bc2 100644
--- a/c/src/lib/libbsp/arm/csb336/console/uart.c
+++ b/c/src/lib/libbsp/arm/csb336/console/uart.c
@@ -322,7 +322,7 @@ static int imx_uart_set_attrs(int minor, const struct 
termios *t)
 {
 int baud;
 
-baud = rtems_termios_baud_to_number(t->c_cflag & CBAUD);
+baud = rtems_termios_baud_to_number(t->c_ospeed);
 imx_uart_set_baud(minor, baud);
 
 return 0;
diff --git a/c/src/lib/libbsp/arm/lpc32xx/console/hsu.c 
b/c/src/lib/libbsp/arm/lpc32xx/console/hsu.c
index 8bf..b2044e0 100644
--- a/c/src/lib/libbsp/arm/lpc32xx/console/hsu.c
+++ b/c/src/lib/libbsp/arm/lpc32xx/console/hsu.c
@@ -178,7 +178,7 @@ static bool lpc32xx_hsu_set_attributes(
 {
   lpc32xx_hsu_context *ctx = (lpc32xx_hsu_context *) base;
   volatile lpc32xx_hsu *hsu = ctx->hsu;
-  int baud_flags = term->c_cflag & CBAUD;
+  int baud_flags = term->c_ospeed;
 
   if (baud_flags != 0) {
 int32_t baud = rtems_termios_baud_to_number(baud_flags);
diff --git a/c/src/lib/libbsp/i386/shared/comm/tty_drv.c 
b/c/src/lib/libbsp/i386/shared/comm/tty_drv.c
index 2152dec..e15edbd 100644
--- a/c/src/lib/libbsp/i386/shared/comm/tty_drv.c
+++ b/c/src/lib/libbsp/i386/shared/comm/tty_drv.c
@@ -227,7 +227,7 @@ conSetAttr(int port, int minor, const struct termios *t)
 {
   unsigned long baud, databits, parity, stopbits;
 
-  baud = rtems_termios_baud_to_number(t->c_cflag & CBAUD);
+  baud = rtems_termios_baud_to_number(t->c_ospeed);
   if ( baud > 115200 )
 rtems_fatal_error_occurred (RTEMS_INTERNAL_ERROR);
 
diff --git a/c/src/lib/libbsp/lm32/shared/milkymist_console/console.c 
b/c/src/lib/libbsp/lm32/shared/milkymist_console/console.c
index 3558e33..de87233 100644
--- a/c/src/lib/libbsp/lm32/shared/milkymist_console/console.c
+++ b/c/src/lib/libbsp/lm32/shared/milkymist_console/console.c
@@ -41,7 +41,7 @@ static int mmconsole_set_attributes(int minor, const struct 
termios *t)
 {
   int baud;
 
-  switch (t->c_cflag & CBAUD) {
+  switch (t->c_ospeed) {
 case B0:
   baud = 0;
   break;
diff --git a/c/src/lib/libbsp/m68k/av5282/console/console.c 
b/c/src/lib/libbsp/m68k/av5282/console/console.c
index 07a1569..f56305a 100644
--- a/c/src/lib/libbsp/m68k/av5282/console/console.c
+++ b/c/src/lib/libbsp/m68k/av5282/console/console.c
@@ -179,7 +179,7 @@ static int IntUartSetAttributes(
   /* check to see if input is valid */
   if ( t != (const struct termios *)0 ) {
 /* determine baud rate index */
-baud = rtems_termios_baud_to_number(t->c_cflag & CBAUD);
+baud = rtems_termios_baud_to_number(t->c_ospeed);
 
 /* 

[PATCH 5/5] Updated termios testsuites to use dedicated input and output baud rates in termios structure

2017-03-14 Thread Kevin Kirspel
---
 testsuites/libtests/termios/init.c | 341 +
 testsuites/libtests/termios01/init.c   | 143 +++--
 testsuites/libtests/termios01/termios01.scn| 270 
 testsuites/libtests/termios01/termios_testdriver.c |   6 +-
 testsuites/libtests/termios02/termios02.scn|   4 +-
 testsuites/libtests/termios03/termios03.scn|   6 +-
 testsuites/libtests/termios04/termios04.scn|   8 +-
 testsuites/libtests/termios05/termios05.scn|   8 +-
 testsuites/libtests/termios06/init.c   |   2 +-
 testsuites/libtests/termios06/termios06.scn|  20 +-
 testsuites/libtests/termios07/termios07.scn|  21 +-
 testsuites/libtests/termios08/termios08.scn|  19 +-
 12 files changed, 592 insertions(+), 256 deletions(-)

diff --git a/testsuites/libtests/termios/init.c 
b/testsuites/libtests/termios/init.c
index fcb586b..d8ac60a 100644
--- a/testsuites/libtests/termios/init.c
+++ b/testsuites/libtests/termios/init.c
@@ -46,6 +46,7 @@ void print_c_oflag(struct termios * tp);
 void print_c_lflag(struct termios * tp);
 void print_c_cflag(struct termios * tp);
 void print_c_cc(struct termios * tp);
+void print_baud(const char* name, speed_t spd);
 void print_termios(struct termios *tp);
 unsigned long get_baud_rate(void);
 unsigned long get_parity(void);
@@ -118,6 +119,9 @@ void print_c_oflag( struct termios * tp )
   if( tp->c_oflag & ONLCR )
 printf( "ONLCR " );
 
+  if( tp->c_oflag & ONOEOT )
+printf( "ONOEOT " );
+
   if( tp->c_oflag & OCRNL )
 printf( "OCRNL " );
 
@@ -215,27 +219,38 @@ void print_c_oflag( struct termios * tp )
 void print_c_lflag( struct termios * tp )
 {
   char * c_lflag_bits [] = {
-"ISIG",/* 001 */
-"ICANON",  /* 002 */
-"XCASE",   /* 004 */
-"ECHO",/* 010 */
-"ECHOE",   /* 020 */
-"ECHOK",   /* 040 */
-"ECHONL",  /* 100 */
-"NOFLSH",  /* 200 */
-"TOSTOP",  /* 400 */
-"ECHOCTL", /* 0001000 */
-"ECHOPRT", /* 0002000 */
-"ECHOKE",  /* 0004000 */
-"FLUSHO",  /* 001 */
-"unknown", /* 002 */
-"PENDIN",  /* 004 */
-"IEXTEN",  /* 010 */
-"unknown", /* 020 */
-"unknown", /* 040 */
-"unknown", /* 100 */
-"unknown", /* 200 */
-"unknown", /* 400 */
+"ECHOKE",  /* 0x0001 */
+"ECHOE",   /* 0x0002 */
+"ECHOK",   /* 0x0004 */
+"ECHO",/* 0x0008 */
+"ECHONL",  /* 0x0010 */
+"ECHOPRT", /* 0x0020 */
+"ECHOCTL", /* 0x0040 */
+"ISIG",/* 0x0080 */
+"ICANON",  /* 0x0100 */
+"ALTWERASE",   /* 0x0200 */
+"IEXTEN",  /* 0x0400 */
+"EXTPROC", /* 0x0800 */
+"XCASE",   /* 0x1000 */
+"unknown", /* 0x2000 */
+"unknown", /* 0x4000 */
+"unknown", /* 0x8000 */
+"unknown", /* 0x0001 */
+"unknown", /* 0x0002 */
+"unknown", /* 0x0004 */
+"unknown", /* 0x0008 */
+"unknown", /* 0x0010 */
+"unknown", /* 0x0020 */
+"TOSTOP",  /* 0x0040 */
+"FLUSHO",  /* 0x0080 */
+"unknown", /* 0x0100 */
+"NOKERNINFO",  /* 0x0200 */
+"unknown", /* 0x0400 */
+"unknown", /* 0x0800 */
+"unknown", /* 0x1000 */
+"PENDIN",  /* 0x2000 */
+"unknown", /* 0x4000 */
+"NOFLSH",  /* 0x8000 */
   };
 
   printf( "c_lflag = 0x%08x\n\t", tp->c_lflag );
@@ -246,98 +261,8 @@ void print_c_lflag( struct termios * tp )
 
 void print_c_cflag( struct termios * tp )
 {
-  unsigned int baud;
-
   printf( "c_cflag = 0x%08x\n", tp->c_cflag );
 
-  baud = (tp->c_cflag & CBAUD) ;
-  if ( tp->c_cflag & CBAUDEX )
-  switch( baud ) {
-case B0:
-  printf( "\tCBAUD =\tB0\n" );
-  break;
-
-case B50:
-  printf( "\tCBAUD =\tB50\n" );
-  break;
-
-case B75:
-  printf( "\tCBAUD =\tB75\n" );
-  break;
-
-case B110:
-  printf( "\tCBAUD =\tB110\n" );
-  break;
-
-case B134:
-  printf( "\tCBAUD =\tB134\n" );
-  break;
-
-case B150:
-  printf( "\tCBAUD =\tB150\n" );
-  break;
-
-case B200:
-  printf( "\tCBAUD =\tB200\n" );
-  break;
-
-case B300:
-  printf( "\tCBAUD =\tB300\n" );
-  break;
-
-case B600:
-  printf( "\tCBAUD =\tB600\n" );
-  break;
-
-case B1200:
-  printf( "\tCBAUD =\tB1200\n" );
-  break;
-
-case B1800:
-  printf( "\tCBAUD =\tB1800\n" );
-  break;
-
-case B2400:
-  printf( "\tCBAUD =\tB2400\n" );
-  break;
-
-case B4800:
-  printf( "\tCBAUD =\tB4800\n" );
-  break;
-
-case B9600:
-  printf( "\tCBAUD =\tB9600\n" );
-  break;
-
-case B19200:
-  printf( "\tCBAUD =\tB1

[PATCH 2/5] Modify termios to support dedicated input and output baud rates for termios structure

2017-03-14 Thread Kevin Kirspel
---
 cpukit/libcsupport/Makefile.am  |   2 +-
 cpukit/libcsupport/include/rtems/termiostypes.h |   8 +-
 cpukit/libcsupport/include/sys/ioccom.h |  11 -
 cpukit/libcsupport/include/sys/termios.h| 280 +++-
 cpukit/libcsupport/include/sys/ttycom.h |   6 +-
 cpukit/libcsupport/src/cfgetispeed.c|   2 +-
 cpukit/libcsupport/src/cfgetospeed.c|   2 +-
 cpukit/libcsupport/src/cfmakeraw.c  |  10 +-
 cpukit/libcsupport/src/cfsetispeed.c|   7 +-
 cpukit/libcsupport/src/cfsetospeed.c|   7 +-
 cpukit/libcsupport/src/cfsetspeed.c |   3 +-
 cpukit/libcsupport/src/tcdrain.c|   2 +-
 cpukit/libcsupport/src/tcflush.c|  23 +-
 cpukit/libcsupport/src/tcgetattr.c  |   2 +-
 cpukit/libcsupport/src/tcsetattr.c  |  35 +--
 cpukit/libcsupport/src/termios.c|  44 ++--
 cpukit/libcsupport/src/termios_baud2index.c |  13 +-
 cpukit/libcsupport/src/termios_baud2num.c   |   6 +-
 cpukit/libcsupport/src/termios_baudtable.c  |   5 +
 cpukit/libcsupport/src/termios_setbestbaud.c|  10 +-
 cpukit/libcsupport/src/termios_setinitialbaud.c |   9 +-
 cpukit/libnetworking/net/ppp_tty.c  |  15 +-
 cpukit/preinstall.am|   8 +
 23 files changed, 217 insertions(+), 293 deletions(-)

diff --git a/cpukit/libcsupport/Makefile.am b/cpukit/libcsupport/Makefile.am
index 43d34c4..14b3b5a 100644
--- a/cpukit/libcsupport/Makefile.am
+++ b/cpukit/libcsupport/Makefile.am
@@ -54,7 +54,7 @@ TERMIOS_C_FILES = src/cfgetispeed.c src/cfgetospeed.c 
src/cfsetispeed.c \
 src/tcsetpgrp.c src/termios.c src/termiosinitialize.c \
 src/termios_baud2index.c src/termios_baud2num.c src/termios_num2baud.c \
 src/termios_setinitialbaud.c src/termios_baudtable.c src/cfsetspeed.c \
-src/cfmakeraw.c src/termios_setbestbaud.c
+src/cfmakeraw.c src/cfmakesane.c src/termios_setbestbaud.c
 
 SYSTEM_CALL_C_FILES = src/open.c src/close.c src/read.c src/write.c \
 src/write_r.c \
diff --git a/cpukit/libcsupport/include/rtems/termiostypes.h 
b/cpukit/libcsupport/include/rtems/termiostypes.h
index 5240b85..f68de0c 100644
--- a/cpukit/libcsupport/include/rtems/termiostypes.h
+++ b/cpukit/libcsupport/include/rtems/termiostypes.h
@@ -527,7 +527,7 @@ extern const rtems_assoc_t rtems_termios_baud_table [];
  *  @retval B0 Invalid baud value or a baud value of 0.
  *  @retval other Baud constant according to @a baud.
  */
-tcflag_t rtems_termios_number_to_baud(rtems_termios_baud_t baud);
+speed_t rtems_termios_number_to_baud(rtems_termios_baud_t baud);
 
 /**
  *  @brief Convert Baud Part of Termios control flags to an integral Baud Value
@@ -537,10 +537,10 @@ tcflag_t 
rtems_termios_number_to_baud(rtems_termios_baud_t baud);
  *  @retval 0 Invalid baud value or a baud value of @c B0.
  *  @retval other Integral baud value.
  */
-rtems_termios_baud_t rtems_termios_baud_to_number(tcflag_t c_cflag);
+rtems_termios_baud_t rtems_termios_baud_to_number(speed_t c_cflag);
 
-/** 
- *  @brief Convert Bxxx Constant to Index 
+/**
+ *  @brief Convert Bxxx Constant to Index
  */
 int  rtems_termios_baud_to_index(rtems_termios_baud_t termios_baud);
 
diff --git a/cpukit/libcsupport/include/sys/ioccom.h 
b/cpukit/libcsupport/include/sys/ioccom.h
index 1699fc9..393702d 100644
--- a/cpukit/libcsupport/include/sys/ioccom.h
+++ b/cpukit/libcsupport/include/sys/ioccom.h
@@ -69,17 +69,6 @@ typedef uint32_t ioctl_command_t;
 /* this should be _IORW, but stdio got there first */
 #define_IOWR(g,n,t)_IOC(IOC_INOUT, (g), (n), sizeof(t))
 
-/*
- *  IOCTL values
- */
-
-#define   RTEMS_IO_GET_ATTRIBUTES 1
-#define   RTEMS_IO_SET_ATTRIBUTES 2
-#define   RTEMS_IO_TCDRAIN3
-#define   RTEMS_IO_RCVWAKEUP  4
-#define   RTEMS_IO_SNDWAKEUP  5
-#define   RTEMS_IO_TCFLUSH6
-
 #ifdef _KERNEL
 
 #if defined(COMPAT_FREEBSD6) || defined(COMPAT_FREEBSD5) || \
diff --git a/cpukit/libcsupport/include/sys/termios.h 
b/cpukit/libcsupport/include/sys/termios.h
index 648e3a2..7568b96 100644
--- a/cpukit/libcsupport/include/sys/termios.h
+++ b/cpukit/libcsupport/include/sys/termios.h
@@ -1,221 +1,101 @@
-/**
- * @file
+/*-
+ * Copyright (c) 1988, 1989, 1993, 1994
+ * The Regents of the University of California.  All rights reserved.
  *
- * @brief POSIX Termios Implementation for RTEMS Console Device Driver
+ * 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 d

[PATCH 1/5] Adding modified FREEBSD headers to sync RTEMS termios with FREEBSD

2017-03-14 Thread Kevin Kirspel
---
 cpukit/libcsupport/include/sys/_termios.h| 264 +++
 cpukit/libcsupport/include/sys/ttydefaults.h | 111 +++
 cpukit/libcsupport/src/cfmakesane.c  |  66 +++
 3 files changed, 441 insertions(+)
 create mode 100644 cpukit/libcsupport/include/sys/_termios.h
 create mode 100644 cpukit/libcsupport/include/sys/ttydefaults.h
 create mode 100644 cpukit/libcsupport/src/cfmakesane.c

diff --git a/cpukit/libcsupport/include/sys/_termios.h 
b/cpukit/libcsupport/include/sys/_termios.h
new file mode 100644
index 000..32d9b24
--- /dev/null
+++ b/cpukit/libcsupport/include/sys/_termios.h
@@ -0,0 +1,264 @@
+/*-
+ * Copyright (c) 1988, 1989, 1993, 1994
+ * The Regents of the University of California.  All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of the University nor the names of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE REGENTS 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 REGENTS 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.
+ *
+ * @(#)termios.h   8.3 (Berkeley) 3/28/94
+ * $FreeBSD: head/sys/sys/_termios.h 314436 2017-02-28 23:42:47Z imp $
+ */
+
+#ifndef _SYS__TERMIOS_H_
+#define_SYS__TERMIOS_H_
+
+/*
+ * Special Control Characters
+ *
+ * Index into c_cc[] character array.
+ *
+ * Name Subscript  Enabled by
+ */
+#defineVEOF0   /* ICANON */
+#defineVEOL1   /* ICANON */
+#if !_POSIX_SOURCE || __rtems__
+#defineVEOL2   2   /* ICANON together with IEXTEN */
+#endif
+#defineVERASE  3   /* ICANON */
+#if !_POSIX_SOURCE || __rtems__
+#defineVWERASE 4   /* ICANON together with IEXTEN */
+#endif
+#defineVKILL   5   /* ICANON */
+#if !_POSIX_SOURCE || __rtems__
+#defineVREPRINT6   /* ICANON together with IEXTEN */
+#defineVERASE2 7   /* ICANON */
+#endif
+/* 7  ex-spare 1 */
+#defineVINTR   8   /* ISIG */
+#defineVQUIT   9   /* ISIG */
+#defineVSUSP   10  /* ISIG */
+#if !_POSIX_SOURCE || __rtems__
+#defineVDSUSP  11  /* ISIG together with IEXTEN */
+#endif
+#defineVSTART  12  /* IXON, IXOFF */
+#defineVSTOP   13  /* IXON, IXOFF */
+#if !_POSIX_SOURCE || __rtems__
+#defineVLNEXT  14  /* IEXTEN */
+#defineVDISCARD15  /* IEXTEN */
+#endif
+#defineVMIN16  /* !ICANON */
+#defineVTIME   17  /* !ICANON */
+#if !_POSIX_SOURCE || __rtems__
+#defineVSTATUS 18  /* ICANON together with IEXTEN */
+/* 19 spare 2 */
+#endif
+#defineNCCS20
+
+#define_POSIX_VDISABLE 0xff
+
+/*
+ * Input flags - software input processing
+ */
+#defineIGNBRK  0x0001  /* ignore BREAK condition */
+#defineBRKINT  0x0002  /* map BREAK to SIGINTR */
+#defineIGNPAR  0x0004  /* ignore (discard) parity 
errors */
+#definePARMRK  0x0008  /* mark parity and framing 
errors */
+#defineINPCK   0x0010  /* enable checking of parity 
errors */
+#defineISTRIP  0x0020  /* strip 8th bit off chars */
+#defineINLCR   0x0040  /* map NL into CR */
+#defineIGNCR   0x0080  /* ignore CR */
+#defineICRNL   0x0100  /* map CR to NL (ala CRMOD) */
+#defineIXON0x0200  /* enable output flow control */
+#defineIXOFF  

[PATCH 4/5] Updated tools to use dedicated input and output baud rates in termios structure

2017-03-14 Thread Kevin Kirspel
---
 tools/cpu/sh/sci.c | 29 -
 1 file changed, 20 insertions(+), 9 deletions(-)

diff --git a/tools/cpu/sh/sci.c b/tools/cpu/sh/sci.c
index a092bce..2b68612 100644
--- a/tools/cpu/sh/sci.c
+++ b/tools/cpu/sh/sci.c
@@ -43,10 +43,15 @@ static unsigned int bitrate [] = {
   9600,
   19200,
   38400,
+  7200,
+  14400,
+  28800,
   57600,
+  76800,
   115200,
   230400,
-  460800
+  460800,
+  921600
 };
 
 static sci_tab_t test_array[4] ;
@@ -123,8 +128,9 @@ int shgen_gensci(
 "static struct sci_bitrate_t {\n"
 "  unsigned char n ;\n"
 "  unsigned char N ;\n"
+"  speed_t   B ;\n"
 "} _sci_bitrates[] = {\n"
-"/*  nN  error */\n" );
+"/*  nN  B  error */\n" );
 
   for ( i = 0 ; i < sizeof(bitrate)/sizeof(int) ; i++ )
   {
@@ -132,9 +138,10 @@ int shgen_gensci(
 
 if ( i > 0 )
   fprintf( file, ",\n" );
-fprintf( file, "  { %1d, %3d } /* %+7.2f%% ; B%d ",
+  fprintf( file, "  { %1d, %3d, %d } /* %+7.2f%% ; B%d ",
   best->n,
   best->N,
+  best->B,
   best->err,
   best->B );
 if ( best->n > 3 )
@@ -146,15 +153,19 @@ int shgen_gensci(
 
   fprintf( file,
 "int _sci_get_brparms( \n"
-"  tcflag_t  cflag,\n"
+"  speed_tspd,\n"
 "  unsigned char *smr,\n"
 "  unsigned char *brr )\n"
 "{\n"
-"  unsigned int offset ;\n\n"
-"  offset = ( cflag & ( CBAUD & ~CBAUDEX ) )\n"
-"+ ( ( cflag & CBAUDEX ) ? B38400 : 0 );\n"
-"  if ( offset == 0 ) return -1 ;\n"
-"  offset-- ;\n\n"
+"  int offset = -1;\n"
+"  int i;\n\n"
+"  for(i = 0; i < sizeof(_sci_bitrates)/sizeof(_sci_bitrates[0]); i++) {\n"
+"if( _sci_bitrates[i].B == spd ) {\n"
+"  offset = i;\n"
+"  break;\n"
+"}\n"
+"  }\n"
+"  if ( offset == -1 ) return -1 ;\n"
 "  if ( _sci_bitrates[offset].n > 3 )  return -1;\n\n"
 "  *smr &= ~0x03;\n"
 "  *smr |= _sci_bitrates[offset].n;\n"
-- 
1.9.1

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


[PATCH 2/7] dosfs: Fix msdos_utf8_normalize_and_fold()

2017-03-14 Thread Sebastian Huber
It is all right in case the result uses the full destination buffer.
Without this fix the handling of a maximum 8.3 short file name is
broken.

Update #2928.
---
 cpukit/libfs/src/dosfs/msdos_conv_utf8.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/cpukit/libfs/src/dosfs/msdos_conv_utf8.c 
b/cpukit/libfs/src/dosfs/msdos_conv_utf8.c
index ddf2fdb..cc5c027 100644
--- a/cpukit/libfs/src/dosfs/msdos_conv_utf8.c
+++ b/cpukit/libfs/src/dosfs/msdos_conv_utf8.c
@@ -222,10 +222,10 @@ static int msdos_utf8_normalize_and_fold(
   );
 
   if ( result >= 0 ) {
-if ( result < unicode_buf_size ) {
+if ( result <= unicode_buf_size ) {
   unicodes_to_reencode = result;
 } else {
-  unicodes_to_reencode = unicode_buf_size - 1;
+  unicodes_to_reencode = unicode_buf_size;
   eno = ENOMEM;
 }
 
-- 
1.8.4.5

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


[PATCH 1/7] dosfs: Fix fat_file_write()

2017-03-14 Thread Sebastian Huber
Remove forced overwrite which leads to file data corruption.  The logic
to determine a forced overwrite was fundamentally broken.  For simplity,
disable this feature.

Update #2622.
---
 cpukit/libfs/src/dosfs/fat.c | 15 +--
 cpukit/libfs/src/dosfs/fat.h |  3 +--
 cpukit/libfs/src/dosfs/fat_file.c| 23 +--
 testsuites/fstests/fsdosfswrite01/init.c | 26 --
 4 files changed, 31 insertions(+), 36 deletions(-)

diff --git a/cpukit/libfs/src/dosfs/fat.c b/cpukit/libfs/src/dosfs/fat.c
index 2176ff3..a0475d4 100644
--- a/cpukit/libfs/src/dosfs/fat.c
+++ b/cpukit/libfs/src/dosfs/fat.c
@@ -200,13 +200,12 @@ _fat_block_read(
 }
 
 static ssize_t
- fat_block_write(
+fat_block_write(
 fat_fs_info_t*fs_info,
 const uint32_tstart_blk,
 const uint32_toffset,
 const uint32_tcount,
-const void   *buf,
-const booloverwrite_block)
+const void   *buf)
 {
 int rc = RC_OK;
 uint32_tbytes_to_write = MIN(count, 
(fs_info->vol.bytes_per_block - offset));
@@ -215,8 +214,7 @@ static ssize_t
 
 if (0 < bytes_to_write)
 {
-if (   overwrite_block
-|| (bytes_to_write == fs_info->vol.bytes_per_block))
+if (bytes_to_write == fs_info->vol.bytes_per_block)
 {
 rc = fat_buf_access(fs_info, sec_num, FAT_OP_TYPE_GET, &blk_buf);
 }
@@ -399,7 +397,6 @@ _fat_block_release(fat_fs_info_t *fs_info)
  * offset - offset inside cluster 'start'
  * count  - count of bytes to write
  * buff   - buffer provided by user
- * overwrite_cluster  - true if cluster can get overwritten, false if 
cluster content must be kept
  *
  * RETURNS:
  * bytes written on success, or -1 if error occured
@@ -411,8 +408,7 @@ fat_cluster_write(
 const uint32_tstart_cln,
 const uint32_toffset,
 const uint32_tcount,
-const void   *buff,
-const booloverwrite_cluster)
+const void   *buff)
 {
 ssize_t rc   = RC_OK;
 uint32_tbytes_to_write   = MIN(count, (fs_info->vol.bpc - 
offset));
@@ -436,8 +432,7 @@ fat_cluster_write(
   cur_blk,
   ofs_blk,
   c,
-  &buffer[bytes_written],
-  overwrite_cluster);
+  &buffer[bytes_written]);
   if (c != ret)
 rc = -1;
   else
diff --git a/cpukit/libfs/src/dosfs/fat.h b/cpukit/libfs/src/dosfs/fat.h
index 8fcd17f..1cbf9a7 100644
--- a/cpukit/libfs/src/dosfs/fat.h
+++ b/cpukit/libfs/src/dosfs/fat.h
@@ -503,8 +503,7 @@ fat_cluster_write(fat_fs_info_t*fs_info,
 uint32_t  start_cln,
 uint32_t  offset,
 uint32_t  count,
-const void   *buff,
-bool  overwrite_cluster);
+const void   *buff);
 
 ssize_t
 fat_sector_write(fat_fs_info_t*fs_info,
diff --git a/cpukit/libfs/src/dosfs/fat_file.c 
b/cpukit/libfs/src/dosfs/fat_file.c
index af71ee2..cbc0ab3 100644
--- a/cpukit/libfs/src/dosfs/fat_file.c
+++ b/cpukit/libfs/src/dosfs/fat_file.c
@@ -403,20 +403,18 @@ static bool
  * start- offset(in bytes) to write from
  * count- count
  * buf  - buffer provided by user
- * file_cln_initial - initial current cluster number of the file
  *
  * RETURNS:
  * number of bytes actually written to the file on success, or -1 if
  * error occured (errno set appropriately)
  */
 static ssize_t
- fat_file_write_fat32_or_non_root_dir(
+fat_file_write_fat32_or_non_root_dir(
  fat_fs_info_t*fs_info,
  fat_file_fd_t*fat_fd,
  const uint32_tstart,
  const uint32_tcount,
- const uint8_t*buf,
- const uint32_tfile_cln_initial)
+ const uint8_t*buf)
 {
 intrc = RC_OK;
 uint32_t   cmpltd = 0;
@@ -426,35 +424,27 @@ static ssize_t
 uint32_t   ofs_cln = start - (start_cln << fs_info->vol.bpc_log2);
 uint32_t   ofs_cln_save = ofs_cln;
 uint32_t   bytes_to_write = count;
-uint32_t   file_cln_cnt;
 ssize_tret;
 uint32_t   c;
-bool   overwrite_cluster = false;
 
 rc = fat_file_lseek(fs_info, fat_fd, start_cln, &cur_cln);
 if (RC_

[PATCH 4/7] dosfs: Simplify fat_file_open()

2017-03-14 Thread Sebastian Huber
Update #2929.
---
 cpukit/libfs/src/dosfs/fat_file.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/cpukit/libfs/src/dosfs/fat_file.c 
b/cpukit/libfs/src/dosfs/fat_file.c
index cbc0ab3..c65c758 100644
--- a/cpukit/libfs/src/dosfs/fat_file.c
+++ b/cpukit/libfs/src/dosfs/fat_file.c
@@ -110,12 +110,10 @@ fat_file_open(
 /* access "removed-but-still-open" hash table */
 rc = _hash_search(fs_info, fs_info->rhash, key, key, &lfat_fd);
 
-lfat_fd = (*fat_fd) = (fat_file_fd_t*)malloc(sizeof(fat_file_fd_t));
+lfat_fd = (*fat_fd) = (fat_file_fd_t*)calloc(1, sizeof(fat_file_fd_t));
 if ( lfat_fd == NULL )
 rtems_set_errno_and_return_minus_one( ENOMEM );
 
-memset(lfat_fd, 0, sizeof(fat_file_fd_t));
-
 lfat_fd->links_num = 1;
 lfat_fd->flags &= ~FAT_FILE_REMOVED;
 lfat_fd->map.last_cln = FAT_UNDEFINED_VALUE;
-- 
1.8.4.5

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


[PATCH 3/7] dosfs: Simplify msdos_creat_node()

2017-03-14 Thread Sebastian Huber
Update #2929.
---
 cpukit/libfs/src/dosfs/msdos_create.c | 35 ++-
 1 file changed, 14 insertions(+), 21 deletions(-)

diff --git a/cpukit/libfs/src/dosfs/msdos_create.c 
b/cpukit/libfs/src/dosfs/msdos_create.c
index eba6417..5f594bf 100644
--- a/cpukit/libfs/src/dosfs/msdos_create.c
+++ b/cpukit/libfs/src/dosfs/msdos_create.c
@@ -179,6 +179,8 @@ msdos_creat_node(const rtems_filesystem_location_info_t  
*parent_loc,
  */
 if (type == FAT_DIRECTORY)
 {
+uint32_t unused;
+
 /* open new directory as fat-file */
 rc = fat_file_open(&fs_info->fat, &dir_pos, &fat_fd);
 if (rc != RC_OK)
@@ -188,11 +190,19 @@ msdos_creat_node(const rtems_filesystem_location_info_t  
*parent_loc,
  * we opened fat-file for node we just created, so initialize fat-file
  * descritor
  */
-fat_fd->fat_file_size = 0;
 fat_fd->fat_file_type = FAT_DIRECTORY;
 fat_fd->size_limit = MSDOS_MAX_DIR_LENGTH;
 fat_file_set_ctime_mtime(fat_fd, now);
 
+/* extend it to contain exactly one cluster */
+rc = fat_file_extend(&fs_info->fat,
+ fat_fd,
+ true,
+ fs_info->fat.vol.bpc,
+ &unused);
+if (rc != RC_OK)
+goto err;
+
 /*
  * dot and dotdot entries are identical to new node except the
  * names
@@ -226,33 +236,16 @@ msdos_creat_node(const rtems_filesystem_location_info_t  
*parent_loc,
 CT_LE_W((uint16_t  )(((parent_fat_fd->cln) & 0x)>>16));
 }
 
-/*
- * write dot and dotdot entries to new fat-file: currently fat-file
- * correspondes to a new node is zero length, so it will be extended
- * by one cluster and entries will be written
- */
-ret = fat_file_write(&fs_info->fat, fat_fd, 0,
- MSDOS_DIRECTORY_ENTRY_STRUCT_SIZE * 2,
- (uint8_t *)dot_dotdot);
-if (ret < 0)
-{
-rc = -1;
-goto error;
-}
-
-/* increment fat-file size by cluster size */
-fat_fd->fat_file_size += fs_info->fat.vol.bpc;
-
 /* set up cluster num for dot entry */
 *MSDOS_DIR_FIRST_CLUSTER_LOW(DOT_NODE_P(dot_dotdot)) =
 CT_LE_W((uint16_t  )((fat_fd->cln) & 0x));
 *MSDOS_DIR_FIRST_CLUSTER_HI(DOT_NODE_P(dot_dotdot)) =
 CT_LE_W((uint16_t  )(((fat_fd->cln) & 0x) >> 16));
 
-/* rewrite dot entry */
+/* write dot and dotdot entries */
 ret = fat_file_write(&fs_info->fat, fat_fd, 0,
- MSDOS_DIRECTORY_ENTRY_STRUCT_SIZE,
- (uint8_t *)DOT_NODE_P(dot_dotdot));
+ MSDOS_DIRECTORY_ENTRY_STRUCT_SIZE * 2,
+ (uint8_t *)dot_dotdot);
 if (ret < 0)
 {
 rc = -1;
-- 
1.8.4.5

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


[PATCH 6/7] dosfs: Simplify msdos_add_file()

2017-03-14 Thread Sebastian Huber
Update #2929.
---
 cpukit/libfs/src/dosfs/msdos_misc.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/cpukit/libfs/src/dosfs/msdos_misc.c 
b/cpukit/libfs/src/dosfs/msdos_misc.c
index 5c16f4a..d1d0181 100644
--- a/cpukit/libfs/src/dosfs/msdos_misc.c
+++ b/cpukit/libfs/src/dosfs/msdos_misc.c
@@ -1650,8 +1650,8 @@ msdos_add_file (
 const char   *name_dir_entry,
 fat_dir_pos_t*dir_pos,
 const uint32_tdir_offset,
-const uint32_tempty_space_offset_param,
-const uint32_tempty_space_entry_param,
+uint32_t  empty_space_offset,
+uint32_t  empty_space_entry,
 const uint32_tempty_space_count
 
 )
@@ -1659,8 +1659,6 @@ msdos_add_file (
 int  ret= 0;
 ssize_t  bytes_written  = 0;
 uint8_t  lfn_checksum   = 0;
-uint32_t empty_space_offset = empty_space_offset_param;
-uint32_t empty_space_entry  = empty_space_entry_param;
 bool read_cluster   = false;
 int  lfn_entry  = 0;
 fat_pos_tlfn_start;
-- 
1.8.4.5

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


[PATCH 7/7] dosfs: Fix msdos_add_file()

2017-03-14 Thread Sebastian Huber
Make sure that long file names work accross cluster boundaries.

Update #2929.
---
 cpukit/libfs/src/dosfs/msdos_misc.c | 400 ++--
 1 file changed, 155 insertions(+), 245 deletions(-)

diff --git a/cpukit/libfs/src/dosfs/msdos_misc.c 
b/cpukit/libfs/src/dosfs/msdos_misc.c
index d1d0181..09029e7 100644
--- a/cpukit/libfs/src/dosfs/msdos_misc.c
+++ b/cpukit/libfs/src/dosfs/msdos_misc.c
@@ -116,7 +116,7 @@ msdos_is_valid_name_char(const char ch)
  *
  */
 static void
-msdos_short_name_hex(char* sfn, int num)
+msdos_short_name_hex(char* sfn, uint32_t num)
 {
 static const char* hex = "0123456789ABCDEF";
 char* c = MSDOS_DIR_NAME(sfn);
@@ -1019,7 +1019,7 @@ msdos_on_entry_found (
 char *name_dir_entry,
 char *entry,
 fat_dir_pos_t*dir_pos,
-uint32_t *dir_offset,
+uint32_t  dir_offset,
 const uint32_tdir_entry,
 const fat_pos_t  *lfn_start
 )
@@ -1035,7 +1035,7 @@ msdos_on_entry_found (
 rc = fat_file_ioctl(&fs_info->fat,
 fat_fd,
 F_CLU_NUM,
-*dir_offset * bts2rd,
+dir_offset * bts2rd,
 &dir_pos->sname.cln);
 if (rc == RC_OK) {
 dir_pos->sname.ofs = dir_entry;
@@ -1300,10 +1300,8 @@ msdos_find_file_in_directory (
 const unsigned intfat_entries,
 char *name_dir_entry,
 fat_dir_pos_t*dir_pos,
-uint32_t *dir_offset,
-uint32_t *empty_space_offset,
-uint32_t *empty_space_entry,
-uint32_t *empty_space_count)
+uint32_t *empty_file_offset,
+uint32_t *empty_entry_count)
 {
 int   rc= RC_OK;
 ssize_t   bytes_read;
@@ -1319,6 +1317,7 @@ msdos_find_file_in_directory (
 bool  filename_matched  = false;
 ssize_t   filename_size_remaining = name_len_for_compare;
 rtems_dosfs_convert_control *converter = fs_info->converter;
+uint32_t  dir_offset = 0;
 
 /*
  * Scan the directory seeing if the file is present. While
@@ -1328,13 +1327,13 @@ msdos_find_file_in_directory (
 
 lfn_start.cln = lfn_start.ofs = FAT_FILE_SHORT_NAME;
 
-while (   (bytes_read = fat_file_read (&fs_info->fat, fat_fd, (*dir_offset 
* bts2rd),
+while (   (bytes_read = fat_file_read (&fs_info->fat, fat_fd, (dir_offset 
* bts2rd),
  bts2rd, fs_info->cl_buf)) != 
FAT_EOF
&& rc == RC_OK)
 {
 bool remainder_empty = false;
 #if MSDOS_FIND_PRINT
-printf ("MSFS:[2] dir_offset:%li\n", *dir_offset);
+printf ("MSFS:[2] dir_offset:%li\n", dir_offset);
 #endif
 
 if (bytes_read < MSDOS_DIRECTORY_ENTRY_STRUCT_SIZE)
@@ -1359,20 +1358,19 @@ msdos_find_file_in_directory (
MSDOS_THIS_DIR_ENTRY_AND_REST_EMPTY);
 #if MSDOS_FIND_PRINT
 printf ("MSFS:[3] re:%i ee:%i do:%li de:%li(%ld)\n",
-remainder_empty, entry_empty, *dir_offset,
+remainder_empty, entry_empty, dir_offset,
 dir_entry, (dir_entry / 
MSDOS_DIRECTORY_ENTRY_STRUCT_SIZE));
 #endif
 /*
  * Remember where the we are, ie the start, so we can come back
  * to here and write the long file name if this is the start of
- * a series of empty entries. If empty_space_count is 0 then
+ * a series of empty entries. If empty_entry_count is 0 then
  * we are currently not inside an empty series of entries. It
  * is a count of empty entries.
  */
-if (*empty_space_count == 0)
+if (*empty_entry_count == 0)
 {
-*empty_space_entry = dir_entry;
-*empty_space_offset = *dir_offset;
+*empty_file_offset = dir_offset * bts2rd + dir_entry;
 }
 
 if (remainder_empty)
@@ -1396,11 +1394,11 @@ msdos_find_file_in_directory (
 if (   !empty_space_found
 && rc == RC_OK )
 {
-*empty_space_count +=
+*empty_entry_count +=
 entries_per_block - (dir_entry / 
MSDOS_DIRECTORY_ENTRY_STRUCT_SIZE);
 empty_space_found = true;
 #if MSDOS_FIND_PRINT
-printf ( "MSFS:[3.2] esf:%i esc%"PRIu32"\n", 
empty_space_found, *empty_space_count );
+printf ( "MSFS:[3.2] esf:%i esc%"PRIu32"\n", 
empty_space_found, *empty_entry_count );
 #endif

[PATCH 5/7] dosfs: Add and use msdos_lfn_checksum()

2017-03-14 Thread Sebastian Huber
Update #2929.
---
 cpukit/libfs/src/dosfs/msdos.h  |  2 ++
 cpukit/libfs/src/dosfs/msdos_dir.c  | 10 ++
 cpukit/libfs/src/dosfs/msdos_misc.c | 35 +--
 3 files changed, 25 insertions(+), 22 deletions(-)

diff --git a/cpukit/libfs/src/dosfs/msdos.h b/cpukit/libfs/src/dosfs/msdos.h
index d5c48d7..abfede8 100644
--- a/cpukit/libfs/src/dosfs/msdos.h
+++ b/cpukit/libfs/src/dosfs/msdos.h
@@ -482,6 +482,8 @@ int msdos_get_dotdot_dir_info_cluster_num_and_offset(
 
 int msdos_sync(rtems_libio_t *iop);
 
+uint8_t msdos_lfn_checksum(const void *entry);
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/cpukit/libfs/src/dosfs/msdos_dir.c 
b/cpukit/libfs/src/dosfs/msdos_dir.c
index b10ed9e..577dc4d 100644
--- a/cpukit/libfs/src/dosfs/msdos_dir.c
+++ b/cpukit/libfs/src/dosfs/msdos_dir.c
@@ -281,14 +281,8 @@ msdos_dir_read(rtems_libio_t *iop, void *buffer, size_t 
count)
  */
 if (lfn_start != FAT_FILE_SHORT_NAME)
 {
-uint8_t  cs = 0;
-uint8_t* p = (uint8_t*) entry;
-int  i;
-
-for (i = 0; i < 11; i++, p++)
-cs = ((cs & 1) ? 0x80 : 0) + (cs >> 1) + *p;
-
-if (lfn_entries || (lfn_checksum != cs))
+if (lfn_entries ||
+lfn_checksum != msdos_lfn_checksum(entry))
 lfn_start = FAT_FILE_SHORT_NAME;
 
 eno = (*convert_handler->utf16_to_utf8) (
diff --git a/cpukit/libfs/src/dosfs/msdos_misc.c 
b/cpukit/libfs/src/dosfs/msdos_misc.c
index 464c981..5c16f4a 100644
--- a/cpukit/libfs/src/dosfs/msdos_misc.c
+++ b/cpukit/libfs/src/dosfs/msdos_misc.c
@@ -55,6 +55,23 @@
 const char *const MSDOS_DOT_NAME= ".  ";
 const char *const MSDOS_DOTDOT_NAME = ".. ";
 
+uint8_t
+msdos_lfn_checksum(const void *entry)
+{
+const uint8_t *name;
+uint8_tcs;
+inti;
+
+name = (const uint8_t *) MSDOS_DIR_NAME(entry);
+cs = 0;
+
+for (i = 0; i < MSDOS_SHORT_NAME_LEN; ++i) {
+cs = ((cs & 1) ? 0x80 : 0) + (cs >> 1) + name[i];
+}
+
+return cs;
+}
+
 /* msdos_is_valid_name_char --
  * Routine to check the character in a file or directory name.
  * The characters support in the short file name are letters,
@@ -1535,14 +1552,8 @@ msdos_find_file_in_directory (
  */
 if (entry_matched)
 {
-uint8_t  cs = 0;
-uint8_t* p = (uint8_t*) MSDOS_DIR_NAME(entry);
-int  i;
-
-for (i = 0; i < MSDOS_SHORT_NAME_LEN; i++, p++)
-cs = ((cs & 1) ? 0x80 : 0) + (cs >> 1) + *p;
-
-if (lfn_entry || (lfn_checksum != cs))
+if (lfn_entry ||
+lfn_checksum != msdos_lfn_checksum(entry))
 entry_matched = false;
 else if (filename_size_remaining == 0) {
 filename_matched = true;
@@ -1561,7 +1572,7 @@ msdos_find_file_in_directory (
 
 #if MSDOS_FIND_PRINT
 printf ("MSFS:[9.2] checksum, entry_matched:%i, 
lfn_entry:%i, lfn_checksum:%02x/%02x\n",
-entry_matched, lfn_entry, lfn_checksum, cs);
+entry_matched, lfn_entry, lfn_checksum, 
msdos_lfn_checksum(entry));
 #endif
 } else {
 bytes_in_entry = MSDOS_SHORT_NAME_LEN + 1;
@@ -1670,11 +1681,7 @@ msdos_add_file (
 
 if (fat_entries)
 {
-uint8_t* p = (uint8_t*) MSDOS_DIR_NAME(name_dir_entry);
-int  i;
-for (i = 0; i < 11; i++, p++)
-lfn_checksum =
-((lfn_checksum & 1) ? 0x80 : 0) + (lfn_checksum >> 1) + *p;
+lfn_checksum = msdos_lfn_checksum(name_dir_entry);
 }
 
 /*
-- 
1.8.4.5

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


Re: [PATCH 1/5] Adding modified FREEBSD headers to sync RTEMS termios with FREEBSD

2017-03-14 Thread Sebastian Huber
The patch set looks good after a rough review. I will check this in in 
two or three days if nobody objects.


--
Sebastian Huber, embedded brains GmbH

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

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

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


RE: [PATCH 1/5] Adding modified FREEBSD headers to sync RTEMS termios with FREEBSD

2017-03-14 Thread Kirspel, Kevin
I tested it against xilinx_zynq_a9_qemu.  I'm not sure it exists, but if there 
is a way to compile the patch against every (or most) BSP then we could ensure 
no BSP is broken.

Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
235 Hembree Park Drive
Roswell GA 30076
Tel: (770)-510- ext. 81642
Direct: (770)-688-1642
Fax: (770)-510-4445

-Original Message-
From: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de] 
Sent: Tuesday, March 14, 2017 9:42 AM
To: Kirspel, Kevin ; devel@rtems.org
Subject: Re: [PATCH 1/5] Adding modified FREEBSD headers to sync RTEMS termios 
with FREEBSD

The patch set looks good after a rough review. I will check this in in two or 
three days if nobody objects.

--
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: IoT Protocol in RTEMS

2017-03-14 Thread Gedare Bloom
On Tue, Mar 14, 2017 at 1:26 AM, punit vara  wrote:
> Hi
>
> I think RTEMS don't have any IoT protocol so I propose we should
> implement at least two important IoT protocols
>
> 1. MQTT (http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html)
> 2. CoAP  (http://coap.technology/)
>
Why are these 2 important?

The problem to avoid is adopting a network protocol too early, because
there is always a bunch of competing ones, and in the end only a
handful will survive in the long term.

>
> What's your opinion on this ? :)
>
This may be a good idea. What is the state of industry and of
standardization in this space? Are there open-source reference
implementations with a useful (BSD/MIT) license?

Gedare

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


Re: [GSoC] RTEMS Tester Improvements

2017-03-14 Thread Gedare Bloom
On Tue, Mar 14, 2017 at 1:50 AM, Chris Johns  wrote:
> On 14/3/17 9:18 am, Chris Johns wrote:
>>
>> The follow is the work I see needing to be done.
>>
>
> I have created a ticket for this project. Please update and add
> BSP/Simulator section to track those tasks.
>
>  https://devel.rtems.org/ticket/2927
>
Does this supersede https://devel.rtems.org/ticket/2919

> Thanks
> 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: [GSoC] RTEMS Tester Improvements

2017-03-14 Thread Gedare Bloom
On Tue, Mar 14, 2017 at 9:58 AM, Gedare Bloom  wrote:
> On Tue, Mar 14, 2017 at 1:50 AM, Chris Johns  wrote:
>> On 14/3/17 9:18 am, Chris Johns wrote:
>>>
>>> The follow is the work I see needing to be done.
>>>
>>
>> I have created a ticket for this project. Please update and add
>> BSP/Simulator section to track those tasks.
>>
>>  https://devel.rtems.org/ticket/2927
>>
> Does this supersede https://devel.rtems.org/ticket/2919
>

Note: I classify Testing Tool Improvements as part of improving our
Developer Ecosystem rather than as a Testing project. A subtle
distinction perhaps, but I feel it is important to understand where we
draw these kinds of lines.

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


[PATCH] modify punitvara's works on BBB i2c, and now can read the eeprom info.

2017-03-14 Thread Sichen Zhao
---
 c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c | 684 --
 c/src/lib/libbsp/arm/beagle/include/i2c.h |  18 +-
 cpukit/dev/i2c/eeprom.c   |  24 +-
 testsuites/samples/i2c0/init.c|  98 -
 4 files changed, 777 insertions(+), 47 deletions(-)

diff --git a/c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c 
b/c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c
index 6b790e5..6a22125 100644
--- a/c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c
+++ b/c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c
@@ -21,11 +21,23 @@
 #include 
 #include 
 
+#define u16 unsigned int
+
+static int am335x_i2c_set_clock(i2c_bus *base, unsigned long clock);
+static void omap24_i2c_init(i2c_bus *base);
+static void flush_fifo(i2c_bus *base);
+static int wait_for_bb(i2c_bus *base);
+static int omap24_i2c_probe(i2c_bus *base);
+static u16 wait_for_event(i2c_bus *base);
+static int am335x_i2c_read(i2c_bus *base, unsigned char chip, uint addr, int 
alen, unsigned char *buffer, 
+   int len);
+static int read_eeprom(i2c_bus *base,struct am335x_baseboard_id *header);
+static int am335x_i2c_write(i2c_bus *base, unsigned char chip, uint addr,int 
alen, unsigned char *buffer, 
+int len);
 /*
 static bool am335x_i2c_pinmux(bbb_i2c_bus *bus)
 {
   bool status =true;
-
 // We will check i2c_bus_id in am335x_i2c_bus_register
 // Apart from mode and pull_up register what about SCREWCTRL & RXACTIVE ??
   if (bus->i2c_bus_id == I2C1) {
@@ -48,9 +60,7 @@ static bool am335x_i2c_pinmux(bbb_i2c_bus *bus)
 /* ref. Table 21-4 I2C Clock Signals */
 /* 
  For I2C1/2
-
  Interface clock - 100MHz - CORE_LKOUTM4 / 2 - pd_per_l4ls_gclk
-
  Functional clock - 48MHz - PER_CLKOUTM2 / 4 - pd_per_ic2_fclk
 */
 
@@ -74,7 +84,6 @@ state. Functional clocks are guarantied to stay present. As 
long as in
 this configuration, power domain sleep transition cannot happen.*/
  /* REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_L4LS_CLKCTRL) |=
 AM335X_CM_PER_L4LS_CLKCTRL_MODULEMODE_ENABLE;
-
   while((REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_L4LS_CLKCTRL) &
   AM335X_CM_PER_L4LS_CLKCTRL_MODULEMODE) != 
AM335X_CM_PER_L4LS_CLKCTRL_MODULEMODE_ENABLE);
 */
@@ -86,30 +95,29 @@ this configuration, power domain sleep transition cannot 
happen.*/
   if (bus->i2c_bus_id == I2C1) {
   REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_I2C1_CLKCTRL) |=
  AM335X_CM_PER_I2C1_CLKCTRL_MODULEMODE_ENABLE;
-
   while(REG((AM335X_CM_PER_ADDR + AM335X_CM_PER_I2C1_CLKCTRL) &
  AM335X_CM_PER_I2C1_CLKCTRL_MODULEMODE) != 
AM335X_CM_PER_I2C1_CLKCTRL_MODULEMODE_ENABLE);
   } else if (bus->i2c_bus_id == I2C2) {
   REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_I2C2_CLKCTRL) |=
  AM335X_CM_PER_I2C2_CLKCTRL_MODULEMODE_ENABLE;
-
   while(REG((AM335X_CM_PER_ADDR + AM335X_CM_PER_I2C2_CLKCTRL) &
  AM335X_CM_PER_I2C2_CLKCTRL_MODULEMODE) != 
AM335X_CM_PER_I2C2_CLKCTRL_MODULEMODE_ENABLE);
-
   while(!(REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_L4LS_CLKSTCTRL) &
(AM335X_CM_PER_L4LS_CLKSTCTRL_CLKACTIVITY_L4LS_GCLK |
 AM335X_CM_PER_L4LS_CLKSTCTRL_CLKACTIVITY_I2C_FCLK)));
-
   }
 }
 */
 
 static void am335x_i2c0_pinmux(bbb_i2c_bus *bus)
 {
-  REG(bus->regs + AM335X_CONF_I2C0_SDA) =
+  printf("0x44e1 + AM335X_CONF_I2C0_SDA:%x\n",0x44e1 + 
AM335X_CONF_I2C0_SDA);
+  printf("bus->regs:%x\n", bus->regs);
+ 
+  REG(0x44e1 + AM335X_CONF_I2C0_SDA) =
   (BBB_RXACTIVE | BBB_SLEWCTRL | BBB_PU_EN);
 
-  REG(bus->regs + AM335X_CONF_I2C0_SCL) =
+  REG(0x44e1 + AM335X_CONF_I2C0_SCL) =
   (BBB_RXACTIVE | BBB_SLEWCTRL | BBB_PU_EN); 
 }
 
@@ -314,14 +322,29 @@ void am335x_i2c_init(bbb_i2c_bus *bus, uint32_t 
input_clock)
 static bool am335x_i2c_busbusy(volatile bbb_i2c_regs *regs)
 {
   bool status;
-
-  if (REG(®s->BBB_I2C_IRQSTATUS_RAW) & AM335X_I2C_IRQSTATUS_RAW_BB)
+  unsigned short stat;
+  int timeout = I2C_TIMEOUT;
+
+  REG(®s->BBB_I2C_IRQSTATUS)=0x;
+  
printf("REG(®s->BBB_I2C_IRQSTATUS_RAW):%x\n",REG(®s->BBB_I2C_IRQSTATUS_RAW)
 );
+ // printf("%x\n",0x1400 & 0x1000 );
+ printf("REG(®s->BBB_I2C_IRQSTATUS_RAW) & 
AM335X_I2C_IRQSTATUS_RAW_BB:%x\n",(REG(®s->BBB_I2C_IRQSTATUS_RAW) & 
AM335X_I2C_IRQSTATUS_RAW_BB));
+while(stat =( REG(®s->BBB_I2C_IRQSTATUS_RAW) & AM335X_I2C_IRQSTATUS_RAW_BB) 
&& timeout--)
   {
-status = true; 
-  } else {
-status = false;
+
+REG(®s->BBB_I2C_IRQSTATUS)=stat;
+udelay(20);
+
+  }
+
+  if (timeout <= 0) {
+printf("Timed out in wait_for_bb: status=%04x\n",
+   stat);
+return 1;
   }
-  return status; 
+  REG(®s->BBB_I2C_IRQSTATUS)=0x;   /* clear delayed stuff*/
+  return 0;
+
 }
 
 static void am335x_i2c_reset(bbb_i2c_bus *bus)
@@ -330,9 +353,27 @@ static void am335x_i2c_reset(bbb_i2c_bus *bus)
   printk("reset bus->reg is %x \n",bus->regs);
   /* Disable I2C module at the time of initialization*/
   /*Should I use write32 ?? I guess mmio_clear is correct choice here*/
+  REG(®s->BBB_I

Re: IoT Protocol in RTEMS

2017-03-14 Thread Joel Sherrill
On Tue, Mar 14, 2017 at 8:56 AM, Gedare Bloom  wrote:

> On Tue, Mar 14, 2017 at 1:26 AM, punit vara  wrote:
> > Hi
> >
> > I think RTEMS don't have any IoT protocol so I propose we should
> > implement at least two important IoT protocols
> >
> > 1. MQTT (http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html)
> > 2. CoAP  (http://coap.technology/)
> >
> Why are these 2 important?
>
> The problem to avoid is adopting a network protocol too early, because
> there is always a bunch of competing ones, and in the end only a
> handful will survive in the long term.
>

MQTT is an OASIS standard which is a good sign. It also has multiple
implementations
already with this one from the Eclipse Foundation looking very promising and
appropriate for RTEMS.

https://www.eclipse.org/paho/clients/c/embedded/

CoAP also looks promising since it has an RFC. And promising implementations
to investigate.

http://coap.technology/impls.html

https://github.com/obgm/libcoap is dual licensed as GPL and BSD (why?).


>
> >
> > What's your opinion on this ? :)
> >
> This may be a good idea. What is the state of industry and of
> standardization in this space? Are there open-source reference
> implementations with a useful (BSD/MIT) license?
>
>
I think those two are worth porting. There are already other ports to
embedded
environments so RTEMS should join the list.

The effort would have to get the RTEMS specific configuration and adaptation
code upstream, add RSB recipes, and examples with documentation. I would
honestly expect the ports to be easy enough where more work needs to be
identified. :)

--joel


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

Re: [PATCH] modify punitvara's works on BBB i2c, and now can read the eeprom info.

2017-03-14 Thread Sebastian Huber



On 14/03/17 15:05, Sichen Zhao wrote:

---
  c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c | 684 --
  c/src/lib/libbsp/arm/beagle/include/i2c.h |  18 +-
  cpukit/dev/i2c/eeprom.c   |  24 +-


What is the problem with the generic EEPROM driver?


  testsuites/samples/i2c0/init.c|  98 -


The test suite should contain nothing BSP-specific.


  4 files changed, 777 insertions(+), 47 deletions(-)


--
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: IoT Protocol in RTEMS

2017-03-14 Thread punit vara
On Tue, Mar 14, 2017 at 7:26 PM, Gedare Bloom  wrote:
> On Tue, Mar 14, 2017 at 1:26 AM, punit vara  wrote:
>> Hi
>>
>> I think RTEMS don't have any IoT protocol so I propose we should
>> implement at least two important IoT protocols
>>
>> 1. MQTT (http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html)
>> 2. CoAP  (http://coap.technology/)
>>
> Why are these 2 important?
These two are currently latest protocol some IoT devices use. MQTT is
specially for small footprint devices and I believe RTEMS has
potential to run on small foot print devices. Both protocol will good
addition to show RTEMS as IoT OS.

>
> The problem to avoid is adopting a network protocol too early, because
> there is always a bunch of competing ones, and in the end only a
> handful will survive in the long term.
>
>>
>> What's your opinion on this ? :)
>>
> This may be a good idea. What is the state of industry and of
> standardization in this space? Are there open-source reference
> implementations with a useful (BSD/MIT) license?
>
> Gedare
>
>>
>> Regards
>> Punit Vara
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: IoT Protocol in RTEMS

2017-03-14 Thread punit vara
Can I port MQTT from here ?

https://github.com/zephyrproject-rtos/zephyr/tree/master/subsys/net/lib/mqtt

It has Apache licence. Where do I possibly need to add files ?  Any suggestion ?

-- PV

On Tue, Mar 14, 2017 at 7:50 PM, Joel Sherrill  wrote:
>
>
> On Tue, Mar 14, 2017 at 8:56 AM, Gedare Bloom  wrote:
>>
>> On Tue, Mar 14, 2017 at 1:26 AM, punit vara  wrote:
>> > Hi
>> >
>> > I think RTEMS don't have any IoT protocol so I propose we should
>> > implement at least two important IoT protocols
>> >
>> > 1. MQTT (http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html)
>> > 2. CoAP  (http://coap.technology/)
>> >
>> Why are these 2 important?
>>
>> The problem to avoid is adopting a network protocol too early, because
>> there is always a bunch of competing ones, and in the end only a
>> handful will survive in the long term.
>
>
> MQTT is an OASIS standard which is a good sign. It also has multiple
> implementations
> already with this one from the Eclipse Foundation looking very promising and
> appropriate for RTEMS.
>
> https://www.eclipse.org/paho/clients/c/embedded/
>
> CoAP also looks promising since it has an RFC. And promising implementations
> to investigate.
>
> http://coap.technology/impls.html
>
> https://github.com/obgm/libcoap is dual licensed as GPL and BSD (why?).
>
>>
>>
>> >
>> > What's your opinion on this ? :)
>> >
>> This may be a good idea. What is the state of industry and of
>> standardization in this space? Are there open-source reference
>> implementations with a useful (BSD/MIT) license?
>>
>
> I think those two are worth porting. There are already other ports to
> embedded
> environments so RTEMS should join the list.
>
> The effort would have to get the RTEMS specific configuration and adaptation
> code upstream, add RSB recipes, and examples with documentation. I would
> honestly expect the ports to be easy enough where more work needs to be
> identified. :)
>
> --joel
>
>>
>> Gedare
>>
>> >
>> > Regards
>> > Punit Vara
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: IoT Protocol in RTEMS

2017-03-14 Thread Joel Sherrill
On Tue, Mar 14, 2017 at 10:22 AM, punit vara  wrote:

> Can I port MQTT from here ?
>
> https://github.com/zephyrproject-rtos/zephyr/tree/master/subsys/net/lib/
> mqtt
>
> It has Apache licence. Where do I possibly need to add files ?  Any
> suggestion ?
>
> Why would Zephyr want their code to support multiple RTOSes? Would
we end up with something that has long-term life as an RTEMS option?


> -- PV
>
> On Tue, Mar 14, 2017 at 7:50 PM, Joel Sherrill  wrote:
> >
> >
> > On Tue, Mar 14, 2017 at 8:56 AM, Gedare Bloom  wrote:
> >>
> >> On Tue, Mar 14, 2017 at 1:26 AM, punit vara 
> wrote:
> >> > Hi
> >> >
> >> > I think RTEMS don't have any IoT protocol so I propose we should
> >> > implement at least two important IoT protocols
> >> >
> >> > 1. MQTT (http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html
> )
> >> > 2. CoAP  (http://coap.technology/)
> >> >
> >> Why are these 2 important?
> >>
> >> The problem to avoid is adopting a network protocol too early, because
> >> there is always a bunch of competing ones, and in the end only a
> >> handful will survive in the long term.
> >
> >
> > MQTT is an OASIS standard which is a good sign. It also has multiple
> > implementations
> > already with this one from the Eclipse Foundation looking very promising
> and
> > appropriate for RTEMS.
> >
> > https://www.eclipse.org/paho/clients/c/embedded/
> >
> > CoAP also looks promising since it has an RFC. And promising
> implementations
> > to investigate.
> >
> > http://coap.technology/impls.html
> >
> > https://github.com/obgm/libcoap is dual licensed as GPL and BSD (why?).
> >
> >>
> >>
> >> >
> >> > What's your opinion on this ? :)
> >> >
> >> This may be a good idea. What is the state of industry and of
> >> standardization in this space? Are there open-source reference
> >> implementations with a useful (BSD/MIT) license?
> >>
> >
> > I think those two are worth porting. There are already other ports to
> > embedded
> > environments so RTEMS should join the list.
> >
> > The effort would have to get the RTEMS specific configuration and
> adaptation
> > code upstream, add RSB recipes, and examples with documentation. I would
> > honestly expect the ports to be easy enough where more work needs to be
> > identified. :)
> >
> > --joel
> >
> >>
> >> Gedare
> >>
> >> >
> >> > Regards
> >> > Punit Vara
> >
> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] modify punitvara's works on BBB i2c, and now can read the eeprom info.

2017-03-14 Thread Gedare Bloom
We eventually need all of the combined patches at once in order to
merge. If this is functionally working, then it is time to focus on
cleaning up.

It would be good to separate the testsuite change from the others. I'm
not sure the testsuite is mergeable.

It would also be best to separate the eeprom.c change from the others,
since it is modifying more shared code and should be reviewed/merged
separately from the BB changes.

I have a few comments for you to improve below.

On Tue, Mar 14, 2017 at 10:05 AM, Sichen Zhao <1473996...@qq.com> wrote:
> ---
>  c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c | 684 
> --
>  c/src/lib/libbsp/arm/beagle/include/i2c.h |  18 +-
>  cpukit/dev/i2c/eeprom.c   |  24 +-
>  testsuites/samples/i2c0/init.c|  98 -
>  4 files changed, 777 insertions(+), 47 deletions(-)
>
> diff --git a/c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c 
> b/c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c
> index 6b790e5..6a22125 100644
> --- a/c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c
> +++ b/c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c
> @@ -21,11 +21,23 @@
>  #include 
>  #include 
>
> +#define u16 unsigned int
If this is just for your convenience, prefer to use the standard and
available uint16_t instead. Is there an advantage to use the 16 bit
versus 32 bit? (As you have it, the u16 is going to be 32 bit.)

> +
> +static int am335x_i2c_set_clock(i2c_bus *base, unsigned long clock);
> +static void omap24_i2c_init(i2c_bus *base);
> +static void flush_fifo(i2c_bus *base);
> +static int wait_for_bb(i2c_bus *base);
> +static int omap24_i2c_probe(i2c_bus *base);
> +static u16 wait_for_event(i2c_bus *base);
> +static int am335x_i2c_read(i2c_bus *base, unsigned char chip, uint addr, int 
> alen, unsigned char *buffer,
> +   int len);
> +static int read_eeprom(i2c_bus *base,struct am335x_baseboard_id *header);
> +static int am335x_i2c_write(i2c_bus *base, unsigned char chip, uint addr,int 
> alen, unsigned char *buffer,
> +int len);
>  /*
Eventually need to remove/fix the commented-out code.

>  static bool am335x_i2c_pinmux(bbb_i2c_bus *bus)
>  {
>bool status =true;
> -
>  // We will check i2c_bus_id in am335x_i2c_bus_register
>  // Apart from mode and pull_up register what about SCREWCTRL & RXACTIVE 
> ??
>if (bus->i2c_bus_id == I2C1) {
> @@ -48,9 +60,7 @@ static bool am335x_i2c_pinmux(bbb_i2c_bus *bus)
>  /* ref. Table 21-4 I2C Clock Signals */
>  /*
>   For I2C1/2
> -
>   Interface clock - 100MHz - CORE_LKOUTM4 / 2 - pd_per_l4ls_gclk
> -
>   Functional clock - 48MHz - PER_CLKOUTM2 / 4 - pd_per_ic2_fclk
>  */
>
> @@ -74,7 +84,6 @@ state. Functional clocks are guarantied to stay present. As 
> long as in
>  this configuration, power domain sleep transition cannot happen.*/
>   /* REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_L4LS_CLKCTRL) |=
>  AM335X_CM_PER_L4LS_CLKCTRL_MODULEMODE_ENABLE;
> -
>while((REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_L4LS_CLKCTRL) &
>AM335X_CM_PER_L4LS_CLKCTRL_MODULEMODE) != 
> AM335X_CM_PER_L4LS_CLKCTRL_MODULEMODE_ENABLE);
>  */
> @@ -86,30 +95,29 @@ this configuration, power domain sleep transition cannot 
> happen.*/
>if (bus->i2c_bus_id == I2C1) {
>REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_I2C1_CLKCTRL) |=
>   AM335X_CM_PER_I2C1_CLKCTRL_MODULEMODE_ENABLE;
> -
>while(REG((AM335X_CM_PER_ADDR + AM335X_CM_PER_I2C1_CLKCTRL) &
>   AM335X_CM_PER_I2C1_CLKCTRL_MODULEMODE) != 
> AM335X_CM_PER_I2C1_CLKCTRL_MODULEMODE_ENABLE);
>} else if (bus->i2c_bus_id == I2C2) {
>REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_I2C2_CLKCTRL) |=
>   AM335X_CM_PER_I2C2_CLKCTRL_MODULEMODE_ENABLE;
> -
>while(REG((AM335X_CM_PER_ADDR + AM335X_CM_PER_I2C2_CLKCTRL) &
>   AM335X_CM_PER_I2C2_CLKCTRL_MODULEMODE) != 
> AM335X_CM_PER_I2C2_CLKCTRL_MODULEMODE_ENABLE);
> -
>while(!(REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_L4LS_CLKSTCTRL) &
> (AM335X_CM_PER_L4LS_CLKSTCTRL_CLKACTIVITY_L4LS_GCLK |
>  AM335X_CM_PER_L4LS_CLKSTCTRL_CLKACTIVITY_I2C_FCLK)));
> -
>}
>  }
>  */
>
>  static void am335x_i2c0_pinmux(bbb_i2c_bus *bus)
>  {
> -  REG(bus->regs + AM335X_CONF_I2C0_SDA) =
> +  printf("0x44e1 + AM335X_CONF_I2C0_SDA:%x\n",0x44e1 + 
> AM335X_CONF_I2C0_SDA);
This line exceeds 80 char. Please have a read through
https://devel.rtems.org/wiki/Developer/Coding/Conventions

debug prints should be wrapped in an ifdef controlled by a define flag
either at the top of the file (preferred, to localize debug output) or
from RTEMS_DEBUG.

> +  printf("bus->regs:%x\n", bus->regs);
> +
> +  REG(0x44e1 + AM335X_CONF_I2C0_SDA) =
Replacing a variable with a hard-coded value (here, 0x44e1) is not
good for maintainability or readability. Please provide/use a proper
variable or macro.

>(BBB_RXACTIVE | BBB_SLEWCTRL | BBB_PU_EN);
>
> -  REG(bus->regs + AM335X_CONF_I2C0_SCL) =
> +  REG

Re: IoT Protocol in RTEMS

2017-03-14 Thread Gedare Bloom
On Tue, Mar 14, 2017 at 12:08 PM, Joel Sherrill  wrote:
>
>
> On Tue, Mar 14, 2017 at 10:22 AM, punit vara  wrote:
>>
>> Can I port MQTT from here ?
>>
>>
>> https://github.com/zephyrproject-rtos/zephyr/tree/master/subsys/net/lib/mqtt
>>
>> It has Apache licence. Where do I possibly need to add files ?  Any
>> suggestion ?
>>
> Why would Zephyr want their code to support multiple RTOSes? Would
> we end up with something that has long-term life as an RTEMS option?
>
Apache License is a bit of a pain to use if we need to modify the
upstream source, especially if the upstream will not accept changes.
I, like Joel, am  more concerned about the latter in case we need to
adapt the upstream for easier porting and maintenance.

>>
>> -- PV
>>
>> On Tue, Mar 14, 2017 at 7:50 PM, Joel Sherrill  wrote:
>> >
>> >
>> > On Tue, Mar 14, 2017 at 8:56 AM, Gedare Bloom  wrote:
>> >>
>> >> On Tue, Mar 14, 2017 at 1:26 AM, punit vara 
>> >> wrote:
>> >> > Hi
>> >> >
>> >> > I think RTEMS don't have any IoT protocol so I propose we should
>> >> > implement at least two important IoT protocols
>> >> >
>> >> > 1. MQTT
>> >> > (http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html)
>> >> > 2. CoAP  (http://coap.technology/)
>> >> >
>> >> Why are these 2 important?
>> >>
>> >> The problem to avoid is adopting a network protocol too early, because
>> >> there is always a bunch of competing ones, and in the end only a
>> >> handful will survive in the long term.
>> >
>> >
>> > MQTT is an OASIS standard which is a good sign. It also has multiple
>> > implementations
>> > already with this one from the Eclipse Foundation looking very promising
>> > and
>> > appropriate for RTEMS.
>> >
>> > https://www.eclipse.org/paho/clients/c/embedded/
>> >
>> > CoAP also looks promising since it has an RFC. And promising
>> > implementations
>> > to investigate.
>> >
>> > http://coap.technology/impls.html
>> >
>> > https://github.com/obgm/libcoap is dual licensed as GPL and BSD (why?).
>> >
>> >>
>> >>
>> >> >
>> >> > What's your opinion on this ? :)
>> >> >
>> >> This may be a good idea. What is the state of industry and of
>> >> standardization in this space? Are there open-source reference
>> >> implementations with a useful (BSD/MIT) license?
>> >>
>> >
>> > I think those two are worth porting. There are already other ports to
>> > embedded
>> > environments so RTEMS should join the list.
>> >
>> > The effort would have to get the RTEMS specific configuration and
>> > adaptation
>> > code upstream, add RSB recipes, and examples with documentation. I would
>> > honestly expect the ports to be easy enough where more work needs to be
>> > identified. :)
>> >
>> > --joel
>> >
>> >>
>> >> Gedare
>> >>
>> >> >
>> >> > Regards
>> >> > Punit Vara
>> >
>> >
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [GSoC] RTEMS Tester Improvements

2017-03-14 Thread Chris Johns
On 15/3/17 12:58 am, Gedare Bloom wrote:
> On Tue, Mar 14, 2017 at 1:50 AM, Chris Johns  wrote:
>> On 14/3/17 9:18 am, Chris Johns wrote:
>>>
>>> The follow is the work I see needing to be done.
>>>
>>
>> I have created a ticket for this project. Please update and add
>> BSP/Simulator section to track those tasks.
>>
>>  https://devel.rtems.org/ticket/2927
>>
> Does this supersede https://devel.rtems.org/ticket/2919
> 

I suppose it does or the other ticket's content can be pasted back here.

I am sorry I did not see this ticket.

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


Re: [GSoC] RTEMS Tester Improvements

2017-03-14 Thread Chris Johns
On 15/3/17 1:02 am, Gedare Bloom wrote:
> On Tue, Mar 14, 2017 at 9:58 AM, Gedare Bloom  wrote:
>> On Tue, Mar 14, 2017 at 1:50 AM, Chris Johns  wrote:
>>> On 14/3/17 9:18 am, Chris Johns wrote:

 The follow is the work I see needing to be done.

>>>
>>> I have created a ticket for this project. Please update and add
>>> BSP/Simulator section to track those tasks.
>>>
>>>  https://devel.rtems.org/ticket/2927
>>>
>> Does this supersede https://devel.rtems.org/ticket/2919
>>
> 
> Note: I classify Testing Tool Improvements as part of improving our
> Developer Ecosystem rather than as a Testing project. A subtle
> distinction perhaps, but I feel it is important to understand where we
> draw these kinds of lines.
> 

I agree, one side is what a test is and how to create a test executable
and as you say this project is about the ecosystem used to execute these
tests and manage the results.

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


[PATCH] user: Add tool commands to the user manual.

2017-03-14 Thread Chris Johns
---
 common/_static/my-styles.css |   9 ++
 user/index.rst   |   2 +
 user/tools/bsp-builder.rst   | 200 ++
 user/tools/build.rst |  17 
 user/tools/exeinfo.rst   | 204 +++
 user/tools/index.rst |  24 +++--
 user/tools/linker.rst|  14 +++
 user/tools/symbols.rst   | 174 
 8 files changed, 621 insertions(+), 23 deletions(-)
 create mode 100644 user/tools/bsp-builder.rst
 delete mode 100644 user/tools/build.rst
 create mode 100644 user/tools/exeinfo.rst
 create mode 100644 user/tools/linker.rst
 create mode 100644 user/tools/symbols.rst

diff --git a/common/_static/my-styles.css b/common/_static/my-styles.css
index 1fee616..3ab5cb0 100644
--- a/common/_static/my-styles.css
+++ b/common/_static/my-styles.css
@@ -111,6 +111,15 @@ table.rtems-table.docutils td {
 }
 
 /*
+ * Option description name.
+ */
+.rst-content dl:not(.docutils) dt {
+background: transparent;
+color: #;
+border-top: 0px;
+}
+
+/*
  * Nav side-bar in RTEMS colours.
  */
 .wy-nav-top, .wy-nav-top a {
diff --git a/user/index.rst b/user/index.rst
index 7241d3f..3363b17 100644
--- a/user/index.rst
+++ b/user/index.rst
@@ -28,6 +28,8 @@ Table of Contents
 
hardware/index
 
+   tools/index
+
support/index
additional/index
glossary/index
diff --git a/user/tools/bsp-builder.rst b/user/tools/bsp-builder.rst
new file mode 100644
index 000..f27cb68
--- /dev/null
+++ b/user/tools/bsp-builder.rst
@@ -0,0 +1,200 @@
+.. comment SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. comment: Copyright (c) 2017 Chris Johns 
+.. comment: All rights reserved.
+
+RTEMS BSP Builder
+=
+
+.. index:: Tools, rtems-bsp-builder
+
+The RTEMS BSP Builder is an RTEMS developer tool to build RTEMS in ways users
+do not to test changes to RTEMS. RTEMS has large number of architectures, board
+support packages and configuration options. This tool provides a standard way
+to test a change.
+
+Developer Workflows
+---
+
+There are a number of RTEMS developers each with a different view or expertise
+in RTEMS. Developer can work in the generic areas such as scheduling, file
+systems or the shell, then there are users turned developers adding a new BSP,
+or even a new port to a new architecture. A common approach for all these
+developers is to select a BSP and to work with that BSP. Developers working in
+a generic areas of RTEMS tend to select a BSP that has good simulator support
+with good debugging such as QEMU, while developers of a new BSP or a new port
+tend to work on target hardware. This type of development does not check the
+other architectures, BSP, and build options and a change may change the number
+of warnings or introduce build errors. It is important for the RTEMS project to
+have developers fix these issues before pushing the changes to master
+repository to avoid breaking the code for other developers. It is best for a
+developer to resolve as many issues as they work on changes because comming
+back to a problem often proves difficult.
+
+The RTEMS BSP Builder forms part of a developers workflow where patches are
+tested before being pushed to the repository.
+
+Build Characteristics
+-
+
+Build characteristic are the various parts of a build that can varied changing
+what is built. RTEMS can vary builds based on:
+
+#. Architecture
+
+#. Board Support Package (BSP)
+
+#. Build Configuration options
+
+#. BSP Options
+
+The BSP Builder provides a template of build variation to try and reduce the
+possble combinations to something manageable. It is not realistic to build all
+possible combinations on a single machine in reasonible time.
+
+The RTEMS BSP Builder specifies it builds in terms of:
+
+#. Profiles
+
+#. Builds
+
+The RTEMS BSP Builder will build a list of builds for a profile of board
+support packages.
+
+Profiles
+
+
+A profile is named collection of architectures and board support packages. When
+the RTEMS BSP Builder is asked to build a specific profile it builds the BSPs
+in the specified architectures.
+
+The default configuration provides standard profiles based on
+:ref:`Tiers`. They are:
+
+#. ``tier-1`` (default)
+
+#. ``tier-2``
+
+#. ``tier-3``
+
+#. ``tier-4``
+
+Builds
+^^
+
+A build is a list of builds and each BSP in a profiles is built using each
+build in the builds list.
+
+The default configuration provides standard builds based around the commonly
+varied configure options.
+
+The builds are:
+
+#. ``all`` (default)
+
+#. ``basic``
+
+A ``basic`` build is the ``standard`` or default set configure options.
+
+The ``all`` build is:
+
+ 
+---+-+
+ | Label | Configure Options   
|
+ 
+---+---