Re: GSOC 2017 RTEMS-libbsd issue
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.
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
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
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
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
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 Huberwrote: > 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