Re: GSOC 2017 RTEMS-libbsd issue

2017-04-18 Thread 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=FreeBSD+11.0-RELEASE+and+Ports
-- 

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] cpukit: Return RTEMS_INVALID_MODE if the rtems_task_create mode is invalid.

2017-04-18 Thread Chris Johns 
The mode's RTEMS_NO_PREEMPT and RTEMS_INTERRUPT_LEVEL(n) are not valid
with SMP. This change reports the error as RTEMS_INVALID_MODE rather
than RTEMS_UNSATISFIED.

Closes #3000.
---
 cpukit/rtems/include/rtems/rtems/status.h |  8 ++--
 cpukit/rtems/src/status.c |  3 ++-
 cpukit/rtems/src/statustext.c |  3 ++-
 cpukit/rtems/src/taskcreate.c | 20 ++--
 cpukit/score/src/threadinitialize.c   |  9 ++---
 5 files changed, 30 insertions(+), 13 deletions(-)

diff --git a/cpukit/rtems/include/rtems/rtems/status.h 
b/cpukit/rtems/include/rtems/rtems/status.h
index c54404ba14..cc22d8e574 100644
--- a/cpukit/rtems/include/rtems/rtems/status.h
+++ b/cpukit/rtems/include/rtems/rtems/status.h
@@ -177,7 +177,11 @@ typedef enum {
*
*  @note This status will @b NOT be returned to the user.
*/
-  RTEMS_PROXY_BLOCKING   = 28
+  RTEMS_PROXY_BLOCKING   = 28,
+  /**
+   *  This is the status to indicate the mode is invalid.
+   */
+  RTEMS_INVALID_MODE = 29
 } rtems_status_code;
 
 /**
@@ -188,7 +192,7 @@ typedef enum {
 /**
  *  This is the highest valid value for a Classic API status code.
  */
-#define RTEMS_STATUS_CODES_LAST  RTEMS_PROXY_BLOCKING
+#define RTEMS_STATUS_CODES_LAST  RTEMS_INVALID_MODE
 
 /**
  *  @brief Checks if the status code is equal to RTEMS_SUCCESSFUL.
diff --git a/cpukit/rtems/src/status.c b/cpukit/rtems/src/status.c
index 810c0e18de..c0015a9345 100644
--- a/cpukit/rtems/src/status.c
+++ b/cpukit/rtems/src/status.c
@@ -58,7 +58,8 @@ static const int status_code_to_errno 
[RTEMS_STATUS_CODES_LAST + 1] = {
   [RTEMS_INTERNAL_ERROR]   = EIO,
   [RTEMS_NO_MEMORY]= ENOMEM,
   [RTEMS_IO_ERROR] = EIO,
-  [RTEMS_PROXY_BLOCKING]   = EIO
+  [RTEMS_PROXY_BLOCKING]   = EIO,
+  [RTEMS_INVALID_MODE] = EINVAL
 };
 
 int rtems_status_code_to_errno(rtems_status_code sc)
diff --git a/cpukit/rtems/src/statustext.c b/cpukit/rtems/src/statustext.c
index f701ebd356..2f5ea59854 100644
--- a/cpukit/rtems/src/statustext.c
+++ b/cpukit/rtems/src/statustext.c
@@ -53,7 +53,8 @@ static const char *const status_code_text[] = {
   "RTEMS_INTERNAL_ERROR",
   "RTEMS_NO_MEMORY",
   "RTEMS_IO_ERROR",
-  "RTEMS_PROXY_BLOCKING"
+  "RTEMS_PROXY_BLOCKING",
+  "RTEMS_INVALID_MODE"
 };
 
 const char *rtems_status_text( rtems_status_code code )
diff --git a/cpukit/rtems/src/taskcreate.c b/cpukit/rtems/src/taskcreate.c
index 26953828e9..d63e1c11e2 100644
--- a/cpukit/rtems/src/taskcreate.c
+++ b/cpukit/rtems/src/taskcreate.c
@@ -49,6 +49,8 @@ rtems_status_code rtems_task_create(
   Priority_Control priority;
   RTEMS_API_Control   *api;
   ASR_Information *asr;
+  bool is_preemptible;
+  uint32_t isr_level;
 
 
   if ( !id )
@@ -138,6 +140,20 @@ rtems_status_code rtems_task_create(
 #endif
 
   /*
+   * Setting the mode to non-preemptible and/or the ISR level is not allowed
+   * with SMP. It provides no protection to any data because the setting is
+   * specific to only one core.
+   */
+  is_preemptible = _Modes_Is_preempt(initial_modes) ? true : false;
+  isr_level = _Modes_Get_interrupt_level(initial_modes);
+#if defined( RTEMS_SMP )
+  if ( rtems_configuration_is_smp_enabled() ) {
+if ( !is_preemptible || isr_level != 0 )
+  return RTEMS_INVALID_MODE;
+  }
+#endif
+
+  /*
*  Initialize the core thread for this task.
*/
 
@@ -149,12 +165,12 @@ rtems_status_code rtems_task_create(
 stack_size,
 is_fp,
 priority,
-_Modes_Is_preempt(initial_modes)   ? true : false,
+is_preemptible,
 _Modes_Is_timeslice(initial_modes) ?
   THREAD_CPU_BUDGET_ALGORITHM_RESET_TIMESLICE :
   THREAD_CPU_BUDGET_ALGORITHM_NONE,
 NULL,/* no budget algorithm callout */
-_Modes_Get_interrupt_level(initial_modes),
+isr_level,
 (Objects_Name) name
   );
 
diff --git a/cpukit/score/src/threadinitialize.c 
b/cpukit/score/src/threadinitialize.c
index c34113db3d..2a76035e69 100644
--- a/cpukit/score/src/threadinitialize.c
+++ b/cpukit/score/src/threadinitialize.c
@@ -61,13 +61,8 @@ bool _Thread_Initialize(
 
 #if defined( RTEMS_SMP )
   if ( rtems_configuration_is_smp_enabled() ) {
-if ( !is_preemptible ) {
-  return false;
-}
-
-if ( isr_level != 0 ) {
-  return false;
-}
+_Assert( is_preemptible );
+_Assert( isr_level == 0 );
   }
 #endif
 
-- 
2.11.0

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

Re: Issue with 'rtems_shell_wait_for_input' function

2017-04-18 Thread Chris Johns 

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

[PATCH] bsp/xilinx-zynq: Correct the ZedBoard PERIPHCLK frequency

2017-04-18 Thread Patrick Gauvin 
With the default CPU clock ratio of 6:2:1 with a PS_CLK of 33.33 MHz, the
CPU/SCU clock is 667 MHz (See UG585 v1.11 section 25.3). In the Zynq7000
series, PERIPHCLK is equivalent to the CPU/SCU clock divided by 2.

This was discovered by noticing that the ticker sample program was running
two times slower than expected.
---
 c/src/lib/libbsp/arm/xilinx-zynq/configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/c/src/lib/libbsp/arm/xilinx-zynq/configure.ac 
b/c/src/lib/libbsp/arm/xilinx-zynq/configure.ac
index 99140c3..43dd43e 100644
--- a/c/src/lib/libbsp/arm/xilinx-zynq/configure.ac
+++ b/c/src/lib/libbsp/arm/xilinx-zynq/configure.ac
@@ -33,7 +33,7 @@ RTEMS_BSPOPTS_SET([BSP_INSTRUCTION_CACHE_ENABLED],[*],[1])
 RTEMS_BSPOPTS_HELP([BSP_INSTRUCTION_CACHE_ENABLED],[enable instruction cache])
 
 
RTEMS_BSPOPTS_SET([BSP_ARM_A9MPCORE_PERIPHCLK],[xilinx_zynq_zc702*],[3U])
-RTEMS_BSPOPTS_SET([BSP_ARM_A9MPCORE_PERIPHCLK],[xilinx_zynq_zedboard*],[7U])
+RTEMS_BSPOPTS_SET([BSP_ARM_A9MPCORE_PERIPHCLK],[xilinx_zynq_zedboard*],[3U])
 RTEMS_BSPOPTS_SET([BSP_ARM_A9MPCORE_PERIPHCLK],[*],[1U])
 RTEMS_BSPOPTS_HELP([BSP_ARM_A9MPCORE_PERIPHCLK],[ARM Cortex-A9 MPCore 
PERIPHCLK clock frequency in Hz])
 
-- 
2.7.4

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

GSOC 2017 RTEMS-libbsd issue

2017-04-18 Thread 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.


[cid:effcc62c-d373-428f-9066-723c5cb9703c]


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

Re: Issue with 'rtems_shell_wait_for_input' function

2017-04-18 Thread vivek kukreja 
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.

Regards,
Vivek

On Tue, Mar 7, 2017 at 8:21 PM, Sebastian Huber
 wrote:
> On 03/03/17 23:50, vivek kukreja wrote:
>>
>> Hello all,
>>
>> I made few changes to the fileio test to run NFS using libbsd. The test
>> compiles and when i run it on qemu NFS is initialised.
>>
>> The test starts with the 'rtems_shell_wait_for_input' function which
>> returns RTEMS_UNSATISFIED so the test quits as soon as it begins. I read
>> this means the terminal related attributes could not be set. When i bypass
>> this function to directly start the test it works fine. Im not sure this is
>> a bug or some problem with my configuration. Any help with this issue is
>> appreciated!
>
>
> The serial driver doesn't implement the set attributes device handler
> properly and returns an error.
>
> --
> 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