Re: [PATCH 2/2] bsp/xilinx-zynq: Add device configuration driver

2017-04-19 Thread Chris Johns 

Thanks for submitting this driver. My comments are below.

Chris

On 20/04/2017 13:08, Patrick Gauvin wrote:

---
 c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am   |   5 +
 .../libbsp/arm/xilinx-zynq/devcfg/zynq-devcfg.c| 770 +
 .../arm/xilinx-zynq/include/zynq-devcfg-regs.h | 194 ++
 .../libbsp/arm/xilinx-zynq/include/zynq-devcfg.h   | 160 +
 c/src/lib/libbsp/arm/xilinx-zynq/preinstall.am |   8 +
 5 files changed, 1137 insertions(+)
 create mode 100644 c/src/lib/libbsp/arm/xilinx-zynq/devcfg/zynq-devcfg.c
 create mode 100644 c/src/lib/libbsp/arm/xilinx-zynq/include/zynq-devcfg-regs.h
 create mode 100644 c/src/lib/libbsp/arm/xilinx-zynq/include/zynq-devcfg.h

diff --git a/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am 
b/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
index 08024b9..439399b 100644
--- a/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
+++ b/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
@@ -49,6 +49,8 @@ include_bsp_HEADERS += include/i2c.h
 include_bsp_HEADERS += include/irq.h
 include_bsp_HEADERS += include/zynq-uart.h
 include_bsp_HEADERS += include/zynq-uart-regs.h
+include_bsp_HEADERS += include/zynq-devcfg.h
+include_bsp_HEADERS += include/zynq-devcfg-regs.h
 include_bsp_HEADERS += include/zynq-slcr.h
 include_bsp_HEADERS += include/zynq-slcr-regs.h

@@ -120,6 +122,9 @@ libbsp_a_SOURCES += ../shared/arm-a9mpcore-clock-config.c
 # I2C
 libbsp_a_SOURCES += i2c/cadence-i2c.c

+# Device Config
+libbsp_a_SOURCES += devcfg/zynq-devcfg.c
+
 # System Level Control Registers
 libbsp_a_SOURCES += slcr/zynq-slcr.c

diff --git a/c/src/lib/libbsp/arm/xilinx-zynq/devcfg/zynq-devcfg.c 
b/c/src/lib/libbsp/arm/xilinx-zynq/devcfg/zynq-devcfg.c
new file mode 100644
index 000..5610545
--- /dev/null
+++ b/c/src/lib/libbsp/arm/xilinx-zynq/devcfg/zynq-devcfg.c
@@ -0,0 +1,770 @@
+/*
+ * Xilinx Zynq7000 Device Configuration Driver Implementation
+ *
+ * Notes:
+ * - There will only ever be 1 of these controllers in the Zynq, so this driver
+ *   is designed to be run as a single instance.
+ * - Even if an interrupt bit is already asserted, unmasking it will lead to
+ *   triggering the interrupt. In several areas operations are started before
+ *   unmasking an interrupt which could be triggered by those operations; this
+ *   interrupt behavior allows for such code to not be racy.
+ *
+ * Copyright (c) 2016
+ *  NSF Center for High-Performance Reconfigurable Computing (CHREC),
+ *  University of Florida.  All rights reserved.
+ * Copyright (c) 2017
+ *  NSF Center for High-Performance Reconfigurable Computing (CHREC),
+ *  University of Pittsburgh.  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.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
+ * IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
+ * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
+ * PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER
+ * OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * The views and conclusions contained in the software and documentation
+ * are those of the authors and should not be interpreted as representing
+ * official policies, either expressed or implied, of CHREC.
+ *
+ * Author: Patrick Gauvin 
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define WARN( msg ) printf( "%s:%s: %s", __FILE__, __func__, msg )
+/* Timeout for interrupt waits, 2 seconds should be enough for any operation.
+ */
+#define INT_TIMEOUT ( 2 * rtems_clock_get_ticks_per_second() )
+
+typedef struct {
+  volatile zynq_devcfg_regs *regs;
+  rtems_id   sem_id_open;
+  rtems_id   sem_id_internal;
+  rtems_id   sem_id_int_wait;
+  /* Indicates if the PCAP will be used for a secure bitstream. Secure
+   * bitstreams are untested with this driver. Defaults to false.
+   */
+  bool   secure;
+} drvdata;
+
+static drvdata data;
+/* TODO: Abstract DMA buffer

Re: [PATCH 1/2] bsp/xilinx-zynq: Add SLCR driver

2017-04-19 Thread Chris Johns 

Thanks for submitting this driver. My comments are below.

Chris

On 20/04/2017 13:06, Patrick Gauvin wrote:

---
 c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am   |  5 ++
 .../arm/xilinx-zynq/include/zynq-slcr-regs.h   | 84 
 .../lib/libbsp/arm/xilinx-zynq/include/zynq-slcr.h | 70 +
 c/src/lib/libbsp/arm/xilinx-zynq/preinstall.am |  8 ++
 c/src/lib/libbsp/arm/xilinx-zynq/slcr/zynq-slcr.c  | 90 ++
 5 files changed, 257 insertions(+)
 create mode 100644 c/src/lib/libbsp/arm/xilinx-zynq/include/zynq-slcr-regs.h
 create mode 100644 c/src/lib/libbsp/arm/xilinx-zynq/include/zynq-slcr.h
 create mode 100644 c/src/lib/libbsp/arm/xilinx-zynq/slcr/zynq-slcr.c

diff --git a/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am 
b/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
index 1f9ed59..08024b9 100644
--- a/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
+++ b/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
@@ -49,6 +49,8 @@ include_bsp_HEADERS += include/i2c.h
 include_bsp_HEADERS += include/irq.h
 include_bsp_HEADERS += include/zynq-uart.h
 include_bsp_HEADERS += include/zynq-uart-regs.h
+include_bsp_HEADERS += include/zynq-slcr.h
+include_bsp_HEADERS += include/zynq-slcr-regs.h

 include_libcpu_HEADERS = ../../../libcpu/arm/shared/include/arm-cp15.h

@@ -118,6 +120,9 @@ libbsp_a_SOURCES += ../shared/arm-a9mpcore-clock-config.c
 # I2C
 libbsp_a_SOURCES += i2c/cadence-i2c.c

+# System Level Control Registers
+libbsp_a_SOURCES += slcr/zynq-slcr.c
+
 # Cache
 libbsp_a_SOURCES += ../../../libcpu/shared/src/cache_manager.c
 libbsp_a_SOURCES += ../shared/include/arm-cache-l1.h
diff --git a/c/src/lib/libbsp/arm/xilinx-zynq/include/zynq-slcr-regs.h 
b/c/src/lib/libbsp/arm/xilinx-zynq/include/zynq-slcr-regs.h
new file mode 100644
index 000..a4c8fdf
--- /dev/null
+++ b/c/src/lib/libbsp/arm/xilinx-zynq/include/zynq-slcr-regs.h
@@ -0,0 +1,84 @@
+/**
+ * @file
+ * @ingroup zynq_slcr
+ * @brief SLCR register definitions.
+ */
+
+/*
+ * Copyright (c) 2017
+ *  NSF Center for High-Performance Reconfigurable Computing (CHREC),
+ *  University of Pittsburgh.  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.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
+ * IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
+ * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
+ * PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER
+ * OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * The views and conclusions contained in the software and documentation
+ * are those of the authors and should not be interpreted as representing
+ * official policies, either expressed or implied, of CHREC.
+ *
+ * Author: Patrick Gauvin 
+ */
+
+/**
+ * @defgroup zynq_slcr_regs SLCR Register Definitions
+ * @ingroup zynq_slcr
+ * @brief SLCR Register Definitions
+ */
+
+#ifndef LIBBSP_ARM_XILINX_ZYNQ_SLCR_REGS_H
+#define LIBBSP_ARM_XILINX_ZYNQ_SLCR_REGS_H
+
+#include 
+
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
+#define ZYNQ_SLCR_BASE_ADDR ( 0xF800 )
+/* NOTE: QEMU gives a value of 0 for the pss_idcode. */
+#define ZYNQ_SLCR_PSS_IDCODE_OFF ( 0x530 )
+#define ZYNQ_SLCR_PSS_IDCODE_DEVICE_GET( reg ) BSP_FLD32GET( reg, 12, 16 )
+#define ZYNQ_SLCR_LVL_SHFTR_EN_OFF ( 0x900 )
+#define ZYNQ_SLCR_LVL_SHFTR_EN_DISABLE ( 0 )
+#define ZYNQ_SLCR_LVL_SHFTR_EN_PS_TO_PL ( 0xA )
+#define ZYNQ_SLCR_LVL_SHFTR_EN_ALL ( 0xF )
+#define ZYNQ_SLCR_LOCK_OFF ( 0x4 )
+#define ZYNQ_SLCR_LOCK_KEY ( 0x767b )
+#define ZYNQ_SLCR_UNLOCK_OFF ( 0x8 )
+#define ZYNQ_SLCR_UNLOCK_KEY ( 0xdf0d )
+#define ZYNQ_SLCR_FPGA_RST_CTRL_OFF ( 0x240 )


Can I please suggest the offsets for the registers be grouped together 
and then the values, offsets etc for each register grouped together? It 
makes it easier to extend what you have started to define here.



+
+#define ZYNQ_SLCR_PSS_IDCODE_DEVICE_7z007s ( 0x03 )
+#define ZYNQ_SLCR_PSS_IDCODE_DEVICE_7z012s ( 0x1c )
+#define ZYNQ_SLCR_PSS_IDCODE_DEVICE_7z014s ( 0x08

Re: GSOC 2017 RTEMS-libbsd issue

2017-04-19 Thread Christian Mauderer 
Am 20.04.2017 um 04:02 schrieb Sichen Zhao:
> Hi Christian Mauderer,
> 
> Ok, i got your idea,I will try it.
> 
> Thank you for your patient for my problem.
> 
> 
> Best regards
> 
> Sichen Zhao
> 

Hello Sichen Zhao,

no problem. Don't hesitate to ask if there are any further questions or
problems.

Kind regards

Christian Mauderer

-- 

embedded brains GmbH
Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

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

[PATCH 2/2] bsp/xilinx-zynq: Add device configuration driver

2017-04-19 Thread Patrick Gauvin 
---
 c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am   |   5 +
 .../libbsp/arm/xilinx-zynq/devcfg/zynq-devcfg.c| 770 +
 .../arm/xilinx-zynq/include/zynq-devcfg-regs.h | 194 ++
 .../libbsp/arm/xilinx-zynq/include/zynq-devcfg.h   | 160 +
 c/src/lib/libbsp/arm/xilinx-zynq/preinstall.am |   8 +
 5 files changed, 1137 insertions(+)
 create mode 100644 c/src/lib/libbsp/arm/xilinx-zynq/devcfg/zynq-devcfg.c
 create mode 100644 c/src/lib/libbsp/arm/xilinx-zynq/include/zynq-devcfg-regs.h
 create mode 100644 c/src/lib/libbsp/arm/xilinx-zynq/include/zynq-devcfg.h

diff --git a/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am 
b/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
index 08024b9..439399b 100644
--- a/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
+++ b/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
@@ -49,6 +49,8 @@ include_bsp_HEADERS += include/i2c.h
 include_bsp_HEADERS += include/irq.h
 include_bsp_HEADERS += include/zynq-uart.h
 include_bsp_HEADERS += include/zynq-uart-regs.h
+include_bsp_HEADERS += include/zynq-devcfg.h
+include_bsp_HEADERS += include/zynq-devcfg-regs.h
 include_bsp_HEADERS += include/zynq-slcr.h
 include_bsp_HEADERS += include/zynq-slcr-regs.h
 
@@ -120,6 +122,9 @@ libbsp_a_SOURCES += ../shared/arm-a9mpcore-clock-config.c
 # I2C
 libbsp_a_SOURCES += i2c/cadence-i2c.c
 
+# Device Config
+libbsp_a_SOURCES += devcfg/zynq-devcfg.c
+
 # System Level Control Registers
 libbsp_a_SOURCES += slcr/zynq-slcr.c
 
diff --git a/c/src/lib/libbsp/arm/xilinx-zynq/devcfg/zynq-devcfg.c 
b/c/src/lib/libbsp/arm/xilinx-zynq/devcfg/zynq-devcfg.c
new file mode 100644
index 000..5610545
--- /dev/null
+++ b/c/src/lib/libbsp/arm/xilinx-zynq/devcfg/zynq-devcfg.c
@@ -0,0 +1,770 @@
+/*
+ * Xilinx Zynq7000 Device Configuration Driver Implementation
+ *
+ * Notes:
+ * - There will only ever be 1 of these controllers in the Zynq, so this driver
+ *   is designed to be run as a single instance.
+ * - Even if an interrupt bit is already asserted, unmasking it will lead to
+ *   triggering the interrupt. In several areas operations are started before
+ *   unmasking an interrupt which could be triggered by those operations; this
+ *   interrupt behavior allows for such code to not be racy.
+ *
+ * Copyright (c) 2016
+ *  NSF Center for High-Performance Reconfigurable Computing (CHREC),
+ *  University of Florida.  All rights reserved.
+ * Copyright (c) 2017
+ *  NSF Center for High-Performance Reconfigurable Computing (CHREC),
+ *  University of Pittsburgh.  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.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
+ * IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
+ * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
+ * PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER
+ * OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * The views and conclusions contained in the software and documentation
+ * are those of the authors and should not be interpreted as representing
+ * official policies, either expressed or implied, of CHREC.
+ *
+ * Author: Patrick Gauvin 
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define WARN( msg ) printf( "%s:%s: %s", __FILE__, __func__, msg )
+/* Timeout for interrupt waits, 2 seconds should be enough for any operation.
+ */
+#define INT_TIMEOUT ( 2 * rtems_clock_get_ticks_per_second() )
+
+typedef struct {
+  volatile zynq_devcfg_regs *regs;
+  rtems_id   sem_id_open;
+  rtems_id   sem_id_internal;
+  rtems_id   sem_id_int_wait;
+  /* Indicates if the PCAP will be used for a secure bitstream. Secure
+   * bitstreams are untested with this driver. Defaults to false.
+   */
+  bool   secure;
+} drvdata;
+
+static drvdata data;
+/* TODO: Abstract DMA buffer retrieval better */
+static uint8_t *dma_buf = NULL;
+
+/* Check if bit is set in reg (and not masked by ma

[PATCH 1/2] bsp/xilinx-zynq: Add SLCR driver

2017-04-19 Thread Patrick Gauvin 
---
 c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am   |  5 ++
 .../arm/xilinx-zynq/include/zynq-slcr-regs.h   | 84 
 .../lib/libbsp/arm/xilinx-zynq/include/zynq-slcr.h | 70 +
 c/src/lib/libbsp/arm/xilinx-zynq/preinstall.am |  8 ++
 c/src/lib/libbsp/arm/xilinx-zynq/slcr/zynq-slcr.c  | 90 ++
 5 files changed, 257 insertions(+)
 create mode 100644 c/src/lib/libbsp/arm/xilinx-zynq/include/zynq-slcr-regs.h
 create mode 100644 c/src/lib/libbsp/arm/xilinx-zynq/include/zynq-slcr.h
 create mode 100644 c/src/lib/libbsp/arm/xilinx-zynq/slcr/zynq-slcr.c

diff --git a/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am 
b/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
index 1f9ed59..08024b9 100644
--- a/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
+++ b/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
@@ -49,6 +49,8 @@ include_bsp_HEADERS += include/i2c.h
 include_bsp_HEADERS += include/irq.h
 include_bsp_HEADERS += include/zynq-uart.h
 include_bsp_HEADERS += include/zynq-uart-regs.h
+include_bsp_HEADERS += include/zynq-slcr.h
+include_bsp_HEADERS += include/zynq-slcr-regs.h
 
 include_libcpu_HEADERS = ../../../libcpu/arm/shared/include/arm-cp15.h
 
@@ -118,6 +120,9 @@ libbsp_a_SOURCES += ../shared/arm-a9mpcore-clock-config.c
 # I2C
 libbsp_a_SOURCES += i2c/cadence-i2c.c
 
+# System Level Control Registers
+libbsp_a_SOURCES += slcr/zynq-slcr.c
+
 # Cache
 libbsp_a_SOURCES += ../../../libcpu/shared/src/cache_manager.c
 libbsp_a_SOURCES += ../shared/include/arm-cache-l1.h
diff --git a/c/src/lib/libbsp/arm/xilinx-zynq/include/zynq-slcr-regs.h 
b/c/src/lib/libbsp/arm/xilinx-zynq/include/zynq-slcr-regs.h
new file mode 100644
index 000..a4c8fdf
--- /dev/null
+++ b/c/src/lib/libbsp/arm/xilinx-zynq/include/zynq-slcr-regs.h
@@ -0,0 +1,84 @@
+/**
+ * @file
+ * @ingroup zynq_slcr
+ * @brief SLCR register definitions.
+ */
+
+/*
+ * Copyright (c) 2017
+ *  NSF Center for High-Performance Reconfigurable Computing (CHREC),
+ *  University of Pittsburgh.  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.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
+ * IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
+ * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
+ * PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER
+ * OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * The views and conclusions contained in the software and documentation
+ * are those of the authors and should not be interpreted as representing
+ * official policies, either expressed or implied, of CHREC.
+ *
+ * Author: Patrick Gauvin 
+ */
+
+/**
+ * @defgroup zynq_slcr_regs SLCR Register Definitions
+ * @ingroup zynq_slcr
+ * @brief SLCR Register Definitions
+ */
+
+#ifndef LIBBSP_ARM_XILINX_ZYNQ_SLCR_REGS_H
+#define LIBBSP_ARM_XILINX_ZYNQ_SLCR_REGS_H
+
+#include 
+
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
+#define ZYNQ_SLCR_BASE_ADDR ( 0xF800 )
+/* NOTE: QEMU gives a value of 0 for the pss_idcode. */
+#define ZYNQ_SLCR_PSS_IDCODE_OFF ( 0x530 )
+#define ZYNQ_SLCR_PSS_IDCODE_DEVICE_GET( reg ) BSP_FLD32GET( reg, 12, 16 )
+#define ZYNQ_SLCR_LVL_SHFTR_EN_OFF ( 0x900 )
+#define ZYNQ_SLCR_LVL_SHFTR_EN_DISABLE ( 0 )
+#define ZYNQ_SLCR_LVL_SHFTR_EN_PS_TO_PL ( 0xA )
+#define ZYNQ_SLCR_LVL_SHFTR_EN_ALL ( 0xF )
+#define ZYNQ_SLCR_LOCK_OFF ( 0x4 )
+#define ZYNQ_SLCR_LOCK_KEY ( 0x767b )
+#define ZYNQ_SLCR_UNLOCK_OFF ( 0x8 )
+#define ZYNQ_SLCR_UNLOCK_KEY ( 0xdf0d )
+#define ZYNQ_SLCR_FPGA_RST_CTRL_OFF ( 0x240 )
+
+#define ZYNQ_SLCR_PSS_IDCODE_DEVICE_7z007s ( 0x03 )
+#define ZYNQ_SLCR_PSS_IDCODE_DEVICE_7z012s ( 0x1c )
+#define ZYNQ_SLCR_PSS_IDCODE_DEVICE_7z014s ( 0x08 )
+#define ZYNQ_SLCR_PSS_IDCODE_DEVICE_7z010 ( 0x02 )
+#define ZYNQ_SLCR_PSS_IDCODE_DEVICE_7z015 ( 0x1b )
+#define ZYNQ_SLCR_PSS_IDCODE_DEVICE_7z020 ( 0x07 )
+#define ZYNQ_SLCR_PSS_IDCODE_DEVICE_7z030 ( 0x0c )
+#define ZYNQ_SLCR_PSS_IDCODE_DEVICE_7z035 ( 0x12 )
+#define ZYNQ_SLCR_PSS_IDCODE_DEVICE_7z045 ( 0x11 )
+#define

[PATCH 1/2] bsp/xilinx-zynq: Add SLCR driver

2017-04-19 Thread Patrick Gauvin 
---
 c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am   |  5 ++
 .../arm/xilinx-zynq/include/zynq-slcr-regs.h   | 84 
 .../lib/libbsp/arm/xilinx-zynq/include/zynq-slcr.h | 70 +
 c/src/lib/libbsp/arm/xilinx-zynq/preinstall.am |  8 ++
 c/src/lib/libbsp/arm/xilinx-zynq/slcr/zynq-slcr.c  | 90 ++
 5 files changed, 257 insertions(+)
 create mode 100644 c/src/lib/libbsp/arm/xilinx-zynq/include/zynq-slcr-regs.h
 create mode 100644 c/src/lib/libbsp/arm/xilinx-zynq/include/zynq-slcr.h
 create mode 100644 c/src/lib/libbsp/arm/xilinx-zynq/slcr/zynq-slcr.c

diff --git a/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am 
b/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
index 1f9ed59..08024b9 100644
--- a/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
+++ b/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
@@ -49,6 +49,8 @@ include_bsp_HEADERS += include/i2c.h
 include_bsp_HEADERS += include/irq.h
 include_bsp_HEADERS += include/zynq-uart.h
 include_bsp_HEADERS += include/zynq-uart-regs.h
+include_bsp_HEADERS += include/zynq-slcr.h
+include_bsp_HEADERS += include/zynq-slcr-regs.h
 
 include_libcpu_HEADERS = ../../../libcpu/arm/shared/include/arm-cp15.h
 
@@ -118,6 +120,9 @@ libbsp_a_SOURCES += ../shared/arm-a9mpcore-clock-config.c
 # I2C
 libbsp_a_SOURCES += i2c/cadence-i2c.c
 
+# System Level Control Registers
+libbsp_a_SOURCES += slcr/zynq-slcr.c
+
 # Cache
 libbsp_a_SOURCES += ../../../libcpu/shared/src/cache_manager.c
 libbsp_a_SOURCES += ../shared/include/arm-cache-l1.h
diff --git a/c/src/lib/libbsp/arm/xilinx-zynq/include/zynq-slcr-regs.h 
b/c/src/lib/libbsp/arm/xilinx-zynq/include/zynq-slcr-regs.h
new file mode 100644
index 000..a4c8fdf
--- /dev/null
+++ b/c/src/lib/libbsp/arm/xilinx-zynq/include/zynq-slcr-regs.h
@@ -0,0 +1,84 @@
+/**
+ * @file
+ * @ingroup zynq_slcr
+ * @brief SLCR register definitions.
+ */
+
+/*
+ * Copyright (c) 2017
+ *  NSF Center for High-Performance Reconfigurable Computing (CHREC),
+ *  University of Pittsburgh.  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.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
+ * IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
+ * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
+ * PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER
+ * OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * The views and conclusions contained in the software and documentation
+ * are those of the authors and should not be interpreted as representing
+ * official policies, either expressed or implied, of CHREC.
+ *
+ * Author: Patrick Gauvin 
+ */
+
+/**
+ * @defgroup zynq_slcr_regs SLCR Register Definitions
+ * @ingroup zynq_slcr
+ * @brief SLCR Register Definitions
+ */
+
+#ifndef LIBBSP_ARM_XILINX_ZYNQ_SLCR_REGS_H
+#define LIBBSP_ARM_XILINX_ZYNQ_SLCR_REGS_H
+
+#include 
+
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
+#define ZYNQ_SLCR_BASE_ADDR ( 0xF800 )
+/* NOTE: QEMU gives a value of 0 for the pss_idcode. */
+#define ZYNQ_SLCR_PSS_IDCODE_OFF ( 0x530 )
+#define ZYNQ_SLCR_PSS_IDCODE_DEVICE_GET( reg ) BSP_FLD32GET( reg, 12, 16 )
+#define ZYNQ_SLCR_LVL_SHFTR_EN_OFF ( 0x900 )
+#define ZYNQ_SLCR_LVL_SHFTR_EN_DISABLE ( 0 )
+#define ZYNQ_SLCR_LVL_SHFTR_EN_PS_TO_PL ( 0xA )
+#define ZYNQ_SLCR_LVL_SHFTR_EN_ALL ( 0xF )
+#define ZYNQ_SLCR_LOCK_OFF ( 0x4 )
+#define ZYNQ_SLCR_LOCK_KEY ( 0x767b )
+#define ZYNQ_SLCR_UNLOCK_OFF ( 0x8 )
+#define ZYNQ_SLCR_UNLOCK_KEY ( 0xdf0d )
+#define ZYNQ_SLCR_FPGA_RST_CTRL_OFF ( 0x240 )
+
+#define ZYNQ_SLCR_PSS_IDCODE_DEVICE_7z007s ( 0x03 )
+#define ZYNQ_SLCR_PSS_IDCODE_DEVICE_7z012s ( 0x1c )
+#define ZYNQ_SLCR_PSS_IDCODE_DEVICE_7z014s ( 0x08 )
+#define ZYNQ_SLCR_PSS_IDCODE_DEVICE_7z010 ( 0x02 )
+#define ZYNQ_SLCR_PSS_IDCODE_DEVICE_7z015 ( 0x1b )
+#define ZYNQ_SLCR_PSS_IDCODE_DEVICE_7z020 ( 0x07 )
+#define ZYNQ_SLCR_PSS_IDCODE_DEVICE_7z030 ( 0x0c )
+#define ZYNQ_SLCR_PSS_IDCODE_DEVICE_7z035 ( 0x12 )
+#define ZYNQ_SLCR_PSS_IDCODE_DEVICE_7z045 ( 0x11 )
+#define

[PATCH 0/2] Zynq7000 series device configuration driver

2017-04-19 Thread Patrick Gauvin 
Hello,

I'm submitting this device configuration driver to be reviewed and
hopefully to be accepted into the RTEMS source tree. In its current state, it
is able to send PCAP command sequences, successfully program the FPGA, and
also use the PCAP to read internal registers.

The SLCR patch is only for the pieces used during FPGA configuration (level
shifter control and clock resets).

I've tried to mimic the Doxygen usage found in the Zynq BSP, please let me
know if I missed anything or should elaborate more.

I intend to merge the test programs into the tree as well, but have not had
the time yet. The platform I have been using to test is the ZedBoard.

Thank you,

Patrick

Patrick Gauvin (2):
  bsp/xilinx-zynq: Add SLCR driver
  bsp/xilinx-zynq: Add device configuration driver

 c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am   |  10 +
 .../libbsp/arm/xilinx-zynq/devcfg/zynq-devcfg.c| 770 +
 .../arm/xilinx-zynq/include/zynq-devcfg-regs.h | 194 ++
 .../libbsp/arm/xilinx-zynq/include/zynq-devcfg.h   | 160 +
 .../arm/xilinx-zynq/include/zynq-slcr-regs.h   |  84 +++
 .../lib/libbsp/arm/xilinx-zynq/include/zynq-slcr.h |  70 ++
 c/src/lib/libbsp/arm/xilinx-zynq/preinstall.am |  16 +
 c/src/lib/libbsp/arm/xilinx-zynq/slcr/zynq-slcr.c  |  90 +++
 8 files changed, 1394 insertions(+)
 create mode 100644 c/src/lib/libbsp/arm/xilinx-zynq/devcfg/zynq-devcfg.c
 create mode 100644 c/src/lib/libbsp/arm/xilinx-zynq/include/zynq-devcfg-regs.h
 create mode 100644 c/src/lib/libbsp/arm/xilinx-zynq/include/zynq-devcfg.h
 create mode 100644 c/src/lib/libbsp/arm/xilinx-zynq/include/zynq-slcr-regs.h
 create mode 100644 c/src/lib/libbsp/arm/xilinx-zynq/include/zynq-slcr.h
 create mode 100644 c/src/lib/libbsp/arm/xilinx-zynq/slcr/zynq-slcr.c

-- 
2.7.4

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

Re: GSOC 2017 RTEMS-libbsd issue

2017-04-19 Thread Sichen Zhao 
Hi Christian Mauderer,

Ok, i got your idea,I will try it.

Thank you for your patient for my problem.


Best regards

Sichen Zhao



From: Christian Mauderer 
Sent: Wednesday, April 19, 2017 11:05 PM
To: 赵 思晨
Cc: RTEMS
Subject: Re: GSOC 2017 RTEMS-libbsd issue



- Ursprüngliche Mail -
> Von: "赵 思晨" 
> An: "Christian Mauderer" , "RTEMS" 
> 
> Gesendet: Mittwoch, 19. April 2017 16:41:20
> Betreff: Re: GSOC 2017 RTEMS-libbsd issue

> Hi Christian Mauderer,
>
> 1. I haven't put these change in my git repo yet.
>
> 2.Yes, i verified that by the console output , the below snapshot :
>
>
> including some debug info. just forget it.
>
>
> [cid:4fb54908-2ff4-4098-9f94-6f2aa529babf]
>
>
> 3.The application i use is testsuite/usb01, i debug it, and it loop at the
> uhub_explore function in usb_hub.c, and didn't reach the umass_probe function.
>
>
> 4. I noticed that the pin USB1_DRVVBUS and USBx_VBUSIN is always low, so i 
> think
> it can't detect the new device.
>
>
> Best Regards
>
> Sichen Zhao
>
>

Hello Sichen Zhao,

point 4 sounds like you found your problem. According to the schematics, there 
is a TPS2051 on the BBB to switch the power of the USB. This chip has an active 
high enable input. So USB1_DRVVBUS should be high.

For a quick try, you could connect a self powered hub. But sooner or later, you 
should just switch the pin on. Please note that it might would be a good idea 
to use it to reset the connected devices on a reboot.

Kind regards

Christian

--

embedded brains GmbH
Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

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

Re: [PATCH] Added declaration of method pthread_getname_np

2017-04-19 Thread Joel Sherrill 
On Wed, Apr 19, 2017 at 2:02 PM, Gedare Bloom  wrote:

> Hi Tanu,
>
> This comes into RTEMS through newlib. You have to clone newlib and
> search in newlib.git/newlib.
>


It is installed as part of your tools by the RSB.

You can #define _GNU_SOURCE before you include any .h files
or add it to the Makefile or whatever you use.

>
> Side-note: Please ensure to use a properly configured git user.name
> and user.email so that git-send-email and git-format-patch will
> preserve the correct authorship information.
>
> Gedare
>
> On Wed, Apr 19, 2017 at 2:59 PM, Tanu Hari Dixit 
> wrote:
> > Hello Joel,
> >
> > I git grepped for the above lines in src/rtems but couldn't find it. I
> > couldn't find it in
> > /src/rtems/cpukit/posix/include/rtems/posix/pthread.h. I don't know
> > how to define _GNU_SOURCE. Can you please help me with this?
> >
> > Thank you,
> > Tanu Hari Dixit.
> >
> > On Wed, Apr 19, 2017 at 9:38 PM, Joel Sherrill  wrote:
> >> Hi,
> >>
> >> This is prototyped in pthread.h in the current tools:
> >>
> >>  #if __GNU_VISIBLE
> >> int pthread_getname_np(pthread_t, char *, size_t) __nonnull(2);
> >>
> >> int pthread_setname_np(pthread_t, const char *) __nonnull(2);
> >> #endif
> >>
> >> Do you have current tools? Did you define _GNU_SOURCE so this
> >> prototype is visible?
> >>
> >> --joel
> >>
> >>
> >> Are you sure your to
> >>
> >> On Wed, Apr 19, 2017 at 10:00 AM, tokencolour 
> wrote:
> >>>
> >>> Gets rid of 1 warning -->
> >>> warning: no previous prototype for 'pthread_getname_np'
> >>> [-Wmissing-prototypes]
> >>> ---
> >>>  cpukit/posix/include/rtems/posix/pthreadimpl.h | 5 +
> >>>  cpukit/posix/src/pthreadgetnamenp.c| 1 +
> >>>  2 files changed, 6 insertions(+)
> >>>
> >>> diff --git a/cpukit/posix/include/rtems/posix/pthreadimpl.h
> >>> b/cpukit/posix/include/rtems/posix/pthreadimpl.h
> >>> index 90a60b6..51a1a2a 100644
> >>> --- a/cpukit/posix/include/rtems/posix/pthreadimpl.h
> >>> +++ b/cpukit/posix/include/rtems/posix/pthreadimpl.h
> >>> @@ -111,6 +111,11 @@ int rtems_pthread_attribute_compare(
> >>>const pthread_attr_t *attr2
> >>>  );
> >>>
> >>> +/*
> >>> + * pthread_getname_np
> >>> + */
> >>> +int pthread_getname_np( pthread_t thread, char *name, size_t len );
> >>> +
> >>>  RTEMS_INLINE_ROUTINE Thread_Control *_POSIX_Threads_Allocate(void)
> >>>  {
> >>>_Objects_Allocator_lock();
> >>> diff --git a/cpukit/posix/src/pthreadgetnamenp.c
> >>> b/cpukit/posix/src/pthreadgetnamenp.c
> >>> index e753823..b1a99f0 100644
> >>> --- a/cpukit/posix/src/pthreadgetnamenp.c
> >>> +++ b/cpukit/posix/src/pthreadgetnamenp.c
> >>> @@ -16,6 +16,7 @@
> >>>  #include 
> >>>
> >>>  #include 
> >>> +#include 
> >>>
> >>>  int pthread_getname_np( pthread_t thread, char *name, size_t len )
> >>>  {
> >>> --
> >>> 2.1.4
> >>>
> >>> ___
> >>> devel mailing list
> >>> devel@rtems.org
> >>> http://lists.rtems.org/mailman/listinfo/devel
> >>
> >>
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Added declaration of method pthread_getname_np

2017-04-19 Thread Gedare Bloom 
Hi Tanu,

This comes into RTEMS through newlib. You have to clone newlib and
search in newlib.git/newlib.

Side-note: Please ensure to use a properly configured git user.name
and user.email so that git-send-email and git-format-patch will
preserve the correct authorship information.

Gedare

On Wed, Apr 19, 2017 at 2:59 PM, Tanu Hari Dixit  wrote:
> Hello Joel,
>
> I git grepped for the above lines in src/rtems but couldn't find it. I
> couldn't find it in
> /src/rtems/cpukit/posix/include/rtems/posix/pthread.h. I don't know
> how to define _GNU_SOURCE. Can you please help me with this?
>
> Thank you,
> Tanu Hari Dixit.
>
> On Wed, Apr 19, 2017 at 9:38 PM, Joel Sherrill  wrote:
>> Hi,
>>
>> This is prototyped in pthread.h in the current tools:
>>
>>  #if __GNU_VISIBLE
>> int pthread_getname_np(pthread_t, char *, size_t) __nonnull(2);
>>
>> int pthread_setname_np(pthread_t, const char *) __nonnull(2);
>> #endif
>>
>> Do you have current tools? Did you define _GNU_SOURCE so this
>> prototype is visible?
>>
>> --joel
>>
>>
>> Are you sure your to
>>
>> On Wed, Apr 19, 2017 at 10:00 AM, tokencolour  wrote:
>>>
>>> Gets rid of 1 warning -->
>>> warning: no previous prototype for 'pthread_getname_np'
>>> [-Wmissing-prototypes]
>>> ---
>>>  cpukit/posix/include/rtems/posix/pthreadimpl.h | 5 +
>>>  cpukit/posix/src/pthreadgetnamenp.c| 1 +
>>>  2 files changed, 6 insertions(+)
>>>
>>> diff --git a/cpukit/posix/include/rtems/posix/pthreadimpl.h
>>> b/cpukit/posix/include/rtems/posix/pthreadimpl.h
>>> index 90a60b6..51a1a2a 100644
>>> --- a/cpukit/posix/include/rtems/posix/pthreadimpl.h
>>> +++ b/cpukit/posix/include/rtems/posix/pthreadimpl.h
>>> @@ -111,6 +111,11 @@ int rtems_pthread_attribute_compare(
>>>const pthread_attr_t *attr2
>>>  );
>>>
>>> +/*
>>> + * pthread_getname_np
>>> + */
>>> +int pthread_getname_np( pthread_t thread, char *name, size_t len );
>>> +
>>>  RTEMS_INLINE_ROUTINE Thread_Control *_POSIX_Threads_Allocate(void)
>>>  {
>>>_Objects_Allocator_lock();
>>> diff --git a/cpukit/posix/src/pthreadgetnamenp.c
>>> b/cpukit/posix/src/pthreadgetnamenp.c
>>> index e753823..b1a99f0 100644
>>> --- a/cpukit/posix/src/pthreadgetnamenp.c
>>> +++ b/cpukit/posix/src/pthreadgetnamenp.c
>>> @@ -16,6 +16,7 @@
>>>  #include 
>>>
>>>  #include 
>>> +#include 
>>>
>>>  int pthread_getname_np( pthread_t thread, char *name, size_t len )
>>>  {
>>> --
>>> 2.1.4
>>>
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Added declaration of method pthread_getname_np

2017-04-19 Thread Tanu Hari Dixit 
Hello Joel,

I git grepped for the above lines in src/rtems but couldn't find it. I
couldn't find it in
/src/rtems/cpukit/posix/include/rtems/posix/pthread.h. I don't know
how to define _GNU_SOURCE. Can you please help me with this?

Thank you,
Tanu Hari Dixit.

On Wed, Apr 19, 2017 at 9:38 PM, Joel Sherrill  wrote:
> Hi,
>
> This is prototyped in pthread.h in the current tools:
>
>  #if __GNU_VISIBLE
> int pthread_getname_np(pthread_t, char *, size_t) __nonnull(2);
>
> int pthread_setname_np(pthread_t, const char *) __nonnull(2);
> #endif
>
> Do you have current tools? Did you define _GNU_SOURCE so this
> prototype is visible?
>
> --joel
>
>
> Are you sure your to
>
> On Wed, Apr 19, 2017 at 10:00 AM, tokencolour  wrote:
>>
>> Gets rid of 1 warning -->
>> warning: no previous prototype for 'pthread_getname_np'
>> [-Wmissing-prototypes]
>> ---
>>  cpukit/posix/include/rtems/posix/pthreadimpl.h | 5 +
>>  cpukit/posix/src/pthreadgetnamenp.c| 1 +
>>  2 files changed, 6 insertions(+)
>>
>> diff --git a/cpukit/posix/include/rtems/posix/pthreadimpl.h
>> b/cpukit/posix/include/rtems/posix/pthreadimpl.h
>> index 90a60b6..51a1a2a 100644
>> --- a/cpukit/posix/include/rtems/posix/pthreadimpl.h
>> +++ b/cpukit/posix/include/rtems/posix/pthreadimpl.h
>> @@ -111,6 +111,11 @@ int rtems_pthread_attribute_compare(
>>const pthread_attr_t *attr2
>>  );
>>
>> +/*
>> + * pthread_getname_np
>> + */
>> +int pthread_getname_np( pthread_t thread, char *name, size_t len );
>> +
>>  RTEMS_INLINE_ROUTINE Thread_Control *_POSIX_Threads_Allocate(void)
>>  {
>>_Objects_Allocator_lock();
>> diff --git a/cpukit/posix/src/pthreadgetnamenp.c
>> b/cpukit/posix/src/pthreadgetnamenp.c
>> index e753823..b1a99f0 100644
>> --- a/cpukit/posix/src/pthreadgetnamenp.c
>> +++ b/cpukit/posix/src/pthreadgetnamenp.c
>> @@ -16,6 +16,7 @@
>>  #include 
>>
>>  #include 
>> +#include 
>>
>>  int pthread_getname_np( pthread_t thread, char *name, size_t len )
>>  {
>> --
>> 2.1.4
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Added declaration of method pthread_getname_np

2017-04-19 Thread Joel Sherrill 
Hi,

This is prototyped in pthread.h in the current tools:

 #if __GNU_VISIBLE
int pthread_getname_np(pthread_t, char *, size_t) __nonnull(2);

int pthread_setname_np(pthread_t, const char *) __nonnull(2);
#endif

Do you have current tools? Did you define _GNU_SOURCE so this
prototype is visible?

--joel


Are you sure your to

On Wed, Apr 19, 2017 at 10:00 AM, tokencolour  wrote:

> Gets rid of 1 warning -->
> warning: no previous prototype for 'pthread_getname_np'
> [-Wmissing-prototypes]
> ---
>  cpukit/posix/include/rtems/posix/pthreadimpl.h | 5 +
>  cpukit/posix/src/pthreadgetnamenp.c| 1 +
>  2 files changed, 6 insertions(+)
>
> diff --git a/cpukit/posix/include/rtems/posix/pthreadimpl.h
> b/cpukit/posix/include/rtems/posix/pthreadimpl.h
> index 90a60b6..51a1a2a 100644
> --- a/cpukit/posix/include/rtems/posix/pthreadimpl.h
> +++ b/cpukit/posix/include/rtems/posix/pthreadimpl.h
> @@ -111,6 +111,11 @@ int rtems_pthread_attribute_compare(
>const pthread_attr_t *attr2
>  );
>
> +/*
> + * pthread_getname_np
> + */
> +int pthread_getname_np( pthread_t thread, char *name, size_t len );
> +
>  RTEMS_INLINE_ROUTINE Thread_Control *_POSIX_Threads_Allocate(void)
>  {
>_Objects_Allocator_lock();
> diff --git a/cpukit/posix/src/pthreadgetnamenp.c b/cpukit/posix/src/
> pthreadgetnamenp.c
> index e753823..b1a99f0 100644
> --- a/cpukit/posix/src/pthreadgetnamenp.c
> +++ b/cpukit/posix/src/pthreadgetnamenp.c
> @@ -16,6 +16,7 @@
>  #include 
>
>  #include 
> +#include 
>
>  int pthread_getname_np( pthread_t thread, char *name, size_t len )
>  {
> --
> 2.1.4
>
> ___
> 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 2017 RTEMS-libbsd issue

2017-04-19 Thread Christian Mauderer 


- Ursprüngliche Mail -
> Von: "赵 思晨" 
> An: "Christian Mauderer" , "RTEMS" 
> 
> Gesendet: Mittwoch, 19. April 2017 16:41:20
> Betreff: Re: GSOC 2017 RTEMS-libbsd issue

> Hi Christian Mauderer,
> 
> 1. I haven't put these change in my git repo yet.
> 
> 2.Yes, i verified that by the console output , the below snapshot :
> 
> 
> including some debug info. just forget it.
> 
> 
> [cid:4fb54908-2ff4-4098-9f94-6f2aa529babf]
> 
> 
> 3.The application i use is testsuite/usb01, i debug it, and it loop at the
> uhub_explore function in usb_hub.c, and didn't reach the umass_probe function.
> 
> 
> 4. I noticed that the pin USB1_DRVVBUS and USBx_VBUSIN is always low, so i 
> think
> it can't detect the new device.
> 
> 
> Best Regards
> 
> Sichen Zhao
> 
> 

Hello Sichen Zhao,

point 4 sounds like you found your problem. According to the schematics, there 
is a TPS2051 on the BBB to switch the power of the USB. This chip has an active 
high enable input. So USB1_DRVVBUS should be high.

For a quick try, you could connect a self powered hub. But sooner or later, you 
should just switch the pin on. Please note that it might would be a good idea 
to use it to reset the connected devices on a reboot.

Kind regards

Christian

-- 

embedded brains GmbH
Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

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

Re: [PATCH] Added declaration of method pthread_getname_np

2017-04-19 Thread Tanu Hari Dixit 
Hello all,

Please let me know if this is okay.

Thanks,
Tanu Hari Dixit.

On Wed, Apr 19, 2017 at 8:30 PM, tokencolour  wrote:
> Gets rid of 1 warning -->
> warning: no previous prototype for 'pthread_getname_np' [-Wmissing-prototypes]
> ---
>  cpukit/posix/include/rtems/posix/pthreadimpl.h | 5 +
>  cpukit/posix/src/pthreadgetnamenp.c| 1 +
>  2 files changed, 6 insertions(+)
>
> diff --git a/cpukit/posix/include/rtems/posix/pthreadimpl.h 
> b/cpukit/posix/include/rtems/posix/pthreadimpl.h
> index 90a60b6..51a1a2a 100644
> --- a/cpukit/posix/include/rtems/posix/pthreadimpl.h
> +++ b/cpukit/posix/include/rtems/posix/pthreadimpl.h
> @@ -111,6 +111,11 @@ int rtems_pthread_attribute_compare(
>const pthread_attr_t *attr2
>  );
>
> +/*
> + * pthread_getname_np
> + */
> +int pthread_getname_np( pthread_t thread, char *name, size_t len );
> +
>  RTEMS_INLINE_ROUTINE Thread_Control *_POSIX_Threads_Allocate(void)
>  {
>_Objects_Allocator_lock();
> diff --git a/cpukit/posix/src/pthreadgetnamenp.c 
> b/cpukit/posix/src/pthreadgetnamenp.c
> index e753823..b1a99f0 100644
> --- a/cpukit/posix/src/pthreadgetnamenp.c
> +++ b/cpukit/posix/src/pthreadgetnamenp.c
> @@ -16,6 +16,7 @@
>  #include 
>
>  #include 
> +#include 
>
>  int pthread_getname_np( pthread_t thread, char *name, size_t len )
>  {
> --
> 2.1.4
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] Added declaration of method pthread_getname_np

2017-04-19 Thread tokencolour 
Gets rid of 1 warning -->
warning: no previous prototype for 'pthread_getname_np' [-Wmissing-prototypes]
---
 cpukit/posix/include/rtems/posix/pthreadimpl.h | 5 +
 cpukit/posix/src/pthreadgetnamenp.c| 1 +
 2 files changed, 6 insertions(+)

diff --git a/cpukit/posix/include/rtems/posix/pthreadimpl.h 
b/cpukit/posix/include/rtems/posix/pthreadimpl.h
index 90a60b6..51a1a2a 100644
--- a/cpukit/posix/include/rtems/posix/pthreadimpl.h
+++ b/cpukit/posix/include/rtems/posix/pthreadimpl.h
@@ -111,6 +111,11 @@ int rtems_pthread_attribute_compare(
   const pthread_attr_t *attr2
 );
 
+/*
+ * pthread_getname_np
+ */
+int pthread_getname_np( pthread_t thread, char *name, size_t len );
+
 RTEMS_INLINE_ROUTINE Thread_Control *_POSIX_Threads_Allocate(void)
 {
   _Objects_Allocator_lock();
diff --git a/cpukit/posix/src/pthreadgetnamenp.c 
b/cpukit/posix/src/pthreadgetnamenp.c
index e753823..b1a99f0 100644
--- a/cpukit/posix/src/pthreadgetnamenp.c
+++ b/cpukit/posix/src/pthreadgetnamenp.c
@@ -16,6 +16,7 @@
 #include 
 
 #include 
+#include 
 
 int pthread_getname_np( pthread_t thread, char *name, size_t len )
 {
-- 
2.1.4

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

Re: GSOC 2017 RTEMS-libbsd issue

2017-04-19 Thread Sichen Zhao 
Hi Christian Mauderer,

1. I haven't put these change in my git repo yet.

2.Yes, i verified that by the console output , the below snapshot :


including some debug info. just forget it.


[cid:4fb54908-2ff4-4098-9f94-6f2aa529babf]


3.The application i use is testsuite/usb01, i debug it, and it loop at the 
uhub_explore function in usb_hub.c, and didn't reach the umass_probe function.


4. I noticed that the pin USB1_DRVVBUS and USBx_VBUSIN is always low, so i 
think it can't detect the new device.


Best Regards

Sichen Zhao










From: Christian Mauderer 
Sent: Wednesday, April 19, 2017 8:36 PM
To: RTEMS; 赵 思晨
Subject: Re: GSOC 2017 RTEMS-libbsd issue

Hello Sichen Zhao,

Sorry for the delayed response. Somehow the mail must have been lost.
I only received it through the answer from Kevin Kirspel. I slightly
changed my mailing list settings so the next time it will (hopefully)
work.

>
> Hi Christian Mauderer, Hi all,
>
>
>
> I understand what you mean, i will update my RTEMS-libbsd to the newest
> branch.
>

Good.

> I already pull over the host controller driver files（am335x_musb.c
> am335x_usbss.c umass.c）from freebsd and make them compilable in
> rtems-libbsd. The umass.c is driver for storage device.
>
> And i already add the host controller and driver to
> nexus-devices.h(RTEMS_BSD_DEFINE_NEXUS_DEVICE(musbotg,0 ,
> RTEMS_ARRAY_SIZE(musbotg_res), &musbotg_res[0]);).
>

Sounds good. Did you put these changes on some working branch in your
github repository so it would be possible to have a look?

>
>
> Now uhub usbus and musbotg can mount on nexus bus.
>

OK. Sounds good. I expect you have verified that by some console output?

> the issue is: it can not find the new device(such as U disk)
>

Which application did you use to test this. Do you have some kind of
debugger so you could check whether the code reaches the umass_probe
function?

> So i compare with the FreeBSD boot log info, and the only difference is
> FreeBSD enable the USB_HAVE_UGEN, so i guess if it is necessary
>
> to enable the macro USB_HAVE_UGEN.
>

As far as I can tell neither the am335x_musb nor the umass driver does
something different based on this macro. And till now, the macro hasn't
been necessary for supporting mass storage devices. It is possible that
something changed and that this specific host needs USB_HAVE_UGEN for
some reason to support any device but I would think it is rather unlikely.

@Kevin Kirspel: It seems that you need UGEN for keyboards. Does a USB
mass storage work on your target without UGEN? This might could give a
hint whether the dependency is device-specific or host-specific.

I'm currently not sure if any other USB device (like a hub) produces any
messages on the console. But it might would be worth a try. If you have
upgraded to the last libbsd, you could also try some USB-wifi-dongles. I
tested with a rtl8192 based one and that did put some messages on the
console. For this wifi dongle You would have to add the following
drivers in nexus-devices.h:

  SYSINIT_MODULE_REFERENCE(wlan_ratectl_none);
  SYSINIT_MODULE_REFERENCE(wlan_sta);
  SYSINIT_MODULE_REFERENCE(wlan_amrr);
  SYSINIT_DRIVER_REFERENCE(rtwn_usb, uhub);
  SYSINIT_REFERENCE(rtwn_rtl8192cfwT);

Kind regards

Christian

>
>
> Thank you for your suggestions.
>
>
>
> Best regards
>
> Sichen Zhao
>

--

embedded brains GmbH
Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

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

RE: GSOC 2017 RTEMS-libbsd issue

2017-04-19 Thread Kirspel, Kevin 
My USB mass storage works without UGEN.

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: devel [mailto:devel-boun...@rtems.org] On Behalf Of Christian Mauderer
Sent: Wednesday, April 19, 2017 8:37 AM
To: RTEMS ; 赵 思晨 
Subject: Re: GSOC 2017 RTEMS-libbsd issue

Hello Sichen Zhao,

Sorry for the delayed response. Somehow the mail must have been lost.
I only received it through the answer from Kevin Kirspel. I slightly changed my 
mailing list settings so the next time it will (hopefully) work.

> 
> Hi Christian Mauderer, Hi all,
> 
>  
> 
> I understand what you mean, i will update my RTEMS-libbsd to the 
> newest branch.
> 

Good.

> I already pull over the host controller driver files（am335x_musb.c
> am335x_usbss.c umass.c）from freebsd and make them compilable in 
> rtems-libbsd. The umass.c is driver for storage device.
> 
> And i already add the host controller and driver to
> nexus-devices.h(RTEMS_BSD_DEFINE_NEXUS_DEVICE(musbotg,0 , 
> RTEMS_ARRAY_SIZE(musbotg_res), &musbotg_res[0]);).
>

Sounds good. Did you put these changes on some working branch in your github 
repository so it would be possible to have a look?

>  
> 
> Now uhub usbus and musbotg can mount on nexus bus.
> 

OK. Sounds good. I expect you have verified that by some console output?

> the issue is: it can not find the new device(such as U disk)
> 

Which application did you use to test this. Do you have some kind of debugger 
so you could check whether the code reaches the umass_probe function?

> So i compare with the FreeBSD boot log info, and the only difference 
> is FreeBSD enable the USB_HAVE_UGEN, so i guess if it is necessary
> 
> to enable the macro USB_HAVE_UGEN.
>

As far as I can tell neither the am335x_musb nor the umass driver does 
something different based on this macro. And till now, the macro hasn't been 
necessary for supporting mass storage devices. It is possible that something 
changed and that this specific host needs USB_HAVE_UGEN for some reason to 
support any device but I would think it is rather unlikely.

@Kevin Kirspel: It seems that you need UGEN for keyboards. Does a USB mass 
storage work on your target without UGEN? This might could give a hint whether 
the dependency is device-specific or host-specific.

I'm currently not sure if any other USB device (like a hub) produces any 
messages on the console. But it might would be worth a try. If you have 
upgraded to the last libbsd, you could also try some USB-wifi-dongles. I tested 
with a rtl8192 based one and that did put some messages on the console. For 
this wifi dongle You would have to add the following drivers in nexus-devices.h:

  SYSINIT_MODULE_REFERENCE(wlan_ratectl_none);
  SYSINIT_MODULE_REFERENCE(wlan_sta);
  SYSINIT_MODULE_REFERENCE(wlan_amrr);
  SYSINIT_DRIVER_REFERENCE(rtwn_usb, uhub);
  SYSINIT_REFERENCE(rtwn_rtl8192cfwT);

Kind regards

Christian

>  
> 
> Thank you for your suggestions.
> 
>  
> 
> Best regards
> 
> Sichen Zhao
> 

--

embedded brains GmbH
Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_mailman_listinfo_devel&d=DwIGaQ&c=2do6VJGs3LvEOe4OFFM1bA&r=dbavT-WIJ4nBfQFKYnKdAD52Vyq3ZXSzrL9TAm21lZI&m=Q8S3rpUyeSbiq1V5AzVD0QJJ5ypQn7wLkP6RTEXMQ74&s=pQp4ZgQRsq1syKIGw8uNyQ2LmAt7lXijDxWXn3rtkYc&e=
 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSOC 2017 RTEMS-libbsd issue

2017-04-19 Thread Christian Mauderer 
Hello Sichen Zhao,

Sorry for the delayed response. Somehow the mail must have been lost.
I only received it through the answer from Kevin Kirspel. I slightly
changed my mailing list settings so the next time it will (hopefully)
work.

> 
> Hi Christian Mauderer, Hi all,
> 
>  
> 
> I understand what you mean, i will update my RTEMS-libbsd to the newest
> branch.
> 

Good.

> I already pull over the host controller driver files（am335x_musb.c
> am335x_usbss.c umass.c）from freebsd and make them compilable in
> rtems-libbsd. The umass.c is driver for storage device.
> 
> And i already add the host controller and driver to
> nexus-devices.h(RTEMS_BSD_DEFINE_NEXUS_DEVICE(musbotg,0 ,
> RTEMS_ARRAY_SIZE(musbotg_res), &musbotg_res[0]);).
>

Sounds good. Did you put these changes on some working branch in your
github repository so it would be possible to have a look?

>  
> 
> Now uhub usbus and musbotg can mount on nexus bus.
> 

OK. Sounds good. I expect you have verified that by some console output?

> the issue is: it can not find the new device(such as U disk)
> 

Which application did you use to test this. Do you have some kind of
debugger so you could check whether the code reaches the umass_probe
function?

> So i compare with the FreeBSD boot log info, and the only difference is
> FreeBSD enable the USB_HAVE_UGEN, so i guess if it is necessary
> 
> to enable the macro USB_HAVE_UGEN.
>

As far as I can tell neither the am335x_musb nor the umass driver does
something different based on this macro. And till now, the macro hasn't
been necessary for supporting mass storage devices. It is possible that
something changed and that this specific host needs USB_HAVE_UGEN for
some reason to support any device but I would think it is rather unlikely.

@Kevin Kirspel: It seems that you need UGEN for keyboards. Does a USB
mass storage work on your target without UGEN? This might could give a
hint whether the dependency is device-specific or host-specific.

I'm currently not sure if any other USB device (like a hub) produces any
messages on the console. But it might would be worth a try. If you have
upgraded to the last libbsd, you could also try some USB-wifi-dongles. I
tested with a rtl8192 based one and that did put some messages on the
console. For this wifi dongle You would have to add the following
drivers in nexus-devices.h:

  SYSINIT_MODULE_REFERENCE(wlan_ratectl_none);
  SYSINIT_MODULE_REFERENCE(wlan_sta);
  SYSINIT_MODULE_REFERENCE(wlan_amrr);
  SYSINIT_DRIVER_REFERENCE(rtwn_usb, uhub);
  SYSINIT_REFERENCE(rtwn_rtl8192cfwT);

Kind regards

Christian

>  
> 
> Thank you for your suggestions.
> 
>  
> 
> Best regards
> 
> Sichen Zhao
> 

-- 

embedded brains GmbH
Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

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

Re: Issue with 'rtems_shell_wait_for_input' function

2017-04-19 Thread vivek kukreja 
Hello Chris,

Inside rtems_shell_wait_for_input we call the change_serial_settings
function which is returning RTEMS_UNSUCCESSFUL so the test doesn't start on
qemu. I tried the tests on gdb for other bsps and they work. I'm still
looking into this issue so I can start working on transports. If you have
any idea about this error, please suggest any docs to help solve it until
Sebastian is away. Thank you.

Regards,
Vivek
On Apr 19, 2017 6:03 AM, "Chris Johns"  wrote:

> On 18/04/2017 20:12, vivek kukreja wrote:
>
>> Hello Sebastian, all,
>>
>> Sir as you said the uart_set_attributes function for xilinx serial
>> driver simply returns false. I'm reffering the following file:
>> /c/src/lib/libbsp/arm/xilinx-zynq/console/zynq-uart.c where the
>> tcsetattr function fails. I'm looking at the older implementations of
>> uart for xilinx and your recent commits to solve this issue. I'm also
>> studying the new Termios driver and it would be helpful if you can
>> refer some approach or other guidelines for this exercise.
>>
>>
> I do not think any termios attributes have been supported in the Zynq
> driver. I think Sebastian has made the call return false which is an error
> which is correct.
>
> 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 2017 RTEMS-libbsd issue

2017-04-19 Thread Kirspel, Kevin 
I have recently posted patches for TTY and USB serial support for FREEBSD.  I 
was going to take a stab at supporting UGEN as well.  The USB mouse and 
keyboard drivers need it as well.  The TTY patches contain some support needed 
for UGEN but there is more required.  Let me take a look at it today to see how 
much more effort it would take to get the baseline UGEN compiling (in 
usb_dev.c).

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

From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Sichen Zhao
Sent: Wednesday, April 19, 2017 7:06 AM
To: Christian Mauderer ; RTEMS 

Subject: Re: GSOC 2017 RTEMS-libbsd issue


Hi Christian Mauderer, Hi all,


I understand what you mean, i will update my RTEMS-libbsd to the newest branch.
I already pull over the host controller driver files（am335x_musb.c 
am335x_usbss.c umass.c）from freebsd and make them compilable in rtems-libbsd. 
The umass.c is driver for storage device.
And i already add the host controller and driver to 
nexus-devices.h(RTEMS_BSD_DEFINE_NEXUS_DEVICE(musbotg,0 , 
RTEMS_ARRAY_SIZE(musbotg_res), &musbotg_res[0]);).

Now uhub usbus and musbotg can mount on nexus bus.
the issue is: it can not find the new device(such as U disk)
So i compare with the FreeBSD boot log info, and the only difference is FreeBSD 
enable the USB_HAVE_UGEN, so i guess if it is necessary
to enable the macro USB_HAVE_UGEN.

Thank you for your suggestions.

Best regards
Sichen Zhao



From: Christian Mauderer 
mailto:christian.maude...@embedded-brains.de>>
Sent: Wednesday, April 19, 2017 2:02 PM
To: Sichen Zhao; RTEMS
Subject: Re: GSOC 2017 RTEMS-libbsd issue


Am 19.04.2017 um 07:45 schrieb Christian Mauderer:
> Am 18.04.2017 um 17:10 schrieb Sichen Zhao:
>>
>> Hi all,
>>
>> I am working on my goal of GSOC 2017 project: Beaglebone black bsp
>> improvement.
>>
>>
>> And i have some issue about the RTEMS-libbsd:
>>
>> if i switch on the macro USB_HAVE_UGEN in the
>> /rtemsbsd/include/rtems/bsd/local/opt_usb.h,
>>
>> There are lots of errors when compile code.
>>
>>
>>
>>
>> So the macro USB_HAVE_UGEN should keep unable? I see the FreeBSD on BBB
>> enable the USB_HAVE_UGEN.
>>
>>
>> Thanks
>>
>> Sichen Zhao
>>
>>
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
> Hello Sichen,
>
> I only read the introduction of the man page (see [1]) but as far as I
> can tell, ugen is a generic USB driver in FreeBSD. I think it would be
> useful if you want to get some generic device Information similar to the
> ones you can get with lsusb in linux. From the look of it, I would
> expect that you also would need it for a library like libusb (which is
> used for example in OpenOCD to get a direct access to the hardware
> without any special drivers).
>
> Normally you should not need it if there is a special driver for your
> USB device in the kernel. For example, if you want to attach a USB mass
> storage stick, you won't need it.
>
> Basically for porting the BBB USB support to libbsd, I would expect that
> you have to pull over the host controller driver files from freebsd and
> make them compilable in rtems-libbsd. Then you would have to add the
> host controller and device drivers to nexus-devices.h. After that, it's
> quite possible that you can already use some of the examples like
> testsuite/media01. If you need any help or details on that process, feel
> free to ask.
>
> Kind regards
>
> Christian Mauderer
>
>
> [1]
> https://www.freebsd.org/cgi/man.cgi?query=ugen&manpath=FreeBSD+11.0-RELEASE+and+Ports
>

By the way: I noted that the libbsd in your github repo is from December
2016. There have been quite some changes since then including a mayor
update to the FreeBSD head of 2016-08-23 and two smaller ones to more
recent FreeBSD head versions. Also the WLAN support has been added since
then. You might should consider an update if you still work with this
version.

--

embedded brains GmbH
Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: 
christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18

Re: GSOC 2017 RTEMS-libbsd issue

2017-04-19 Thread Sichen Zhao 
Hi Christian Mauderer, Hi all,


I understand what you mean, i will update my RTEMS-libbsd to the newest branch.
I already pull over the host controller driver files（am335x_musb.c 
am335x_usbss.c umass.c）from freebsd and make them compilable in rtems-libbsd. 
The umass.c is driver for storage device.
And i already add the host controller and driver to 
nexus-devices.h(RTEMS_BSD_DEFINE_NEXUS_DEVICE(musbotg,0 , 
RTEMS_ARRAY_SIZE(musbotg_res), &musbotg_res[0]);).

Now uhub usbus and musbotg can mount on nexus bus.
the issue is: it can not find the new device(such as U disk)
So i compare with the FreeBSD boot log info, and the only difference is FreeBSD 
enable the USB_HAVE_UGEN, so i guess if it is necessary
to enable the macro USB_HAVE_UGEN.

Thank you for your suggestions.

Best regards
Sichen Zhao



From: Christian Mauderer 
Sent: Wednesday, April 19, 2017 2:02 PM
To: Sichen Zhao; RTEMS
Subject: Re: GSOC 2017 RTEMS-libbsd issue


Am 19.04.2017 um 07:45 schrieb Christian Mauderer:
> Am 18.04.2017 um 17:10 schrieb Sichen Zhao:
>>
>> Hi all,
>>
>> I am working on my goal of GSOC 2017 project: Beaglebone black bsp
>> improvement.
>>
>>
>> And i have some issue about the RTEMS-libbsd:
>>
>> if i switch on the macro USB_HAVE_UGEN in the
>> /rtemsbsd/include/rtems/bsd/local/opt_usb.h,
>>
>> There are lots of errors when compile code.
>>
>>
>>
>>
>> So the macro USB_HAVE_UGEN should keep unable? I see the FreeBSD on BBB
>> enable the USB_HAVE_UGEN.
>>
>>
>> Thanks
>>
>> Sichen Zhao
>>
>>
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
> Hello Sichen,
>
> I only read the introduction of the man page (see [1]) but as far as I
> can tell, ugen is a generic USB driver in FreeBSD. I think it would be
> useful if you want to get some generic device Information similar to the
> ones you can get with lsusb in linux. From the look of it, I would
> expect that you also would need it for a library like libusb (which is
> used for example in OpenOCD to get a direct access to the hardware
> without any special drivers).
>
> Normally you should not need it if there is a special driver for your
> USB device in the kernel. For example, if you want to attach a USB mass
> storage stick, you won't need it.
>
> Basically for porting the BBB USB support to libbsd, I would expect that
> you have to pull over the host controller driver files from freebsd and
> make them compilable in rtems-libbsd. Then you would have to add the
> host controller and device drivers to nexus-devices.h. After that, it's
> quite possible that you can already use some of the examples like
> testsuite/media01. If you need any help or details on that process, feel
> free to ask.
>
> Kind regards
>
> Christian Mauderer
>
>
> [1]
> https://www.freebsd.org/cgi/man.cgi?query=ugen&manpath=FreeBSD+11.0-RELEASE+and+Ports
>

By the way: I noted that the libbsd in your github repo is from December
2016. There have been quite some changes since then including a mayor
update to the FreeBSD head of 2016-08-23 and two smaller ones to more
recent FreeBSD head versions. Also the WLAN support has been added since
then. You might should consider an update if you still work with this
version.

--

embedded brains GmbH
Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

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