Regarding modified hello world example
Hello Devs, Kindly advise me whether I need to send a patch with a modified hello world example as given in https://devel.rtems.org/wiki/GSoC/GettingStarted#ProveYouCanWorkOnRTEMS. Furthermore, I wanted to ask, is there a new set of documentation that I should be aware of, other than that hosted at https://devel.rtems.org/ ? I aim to participate in GSoC '17 under RTEMS. How should I proceed now, that I have set up RTEMS ? Also, when I modified testsuites/samples/hello/init.c, the following m4 files also got modified: c/src/lib/libbsp/bfin/acinclude.m4 c/src/lib/libbsp/powerpc/acinclude.m4 in the following way, diff --git a/c/src/lib/libbsp/bfin/acinclude.m4 b/c/src/lib/libbsp/bfin/acinclud index ab6082e..828fd89 100644 --- a/c/src/lib/libbsp/bfin/acinclude.m4 +++ b/c/src/lib/libbsp/bfin/acinclude.m4 @@ -2,12 +2,12 @@ AC_DEFUN([RTEMS_CHECK_BSPDIR], [ case "$1" in - TLL6527M ) -AC_CONFIG_SUBDIRS([TLL6527M]);; bf537Stamp ) AC_CONFIG_SUBDIRS([bf537Stamp]);; eZKit533 ) AC_CONFIG_SUBDIRS([eZKit533]);; + TLL6527M ) +AC_CONFIG_SUBDIRS([TLL6527M]);; *) AC_MSG_ERROR([Invalid BSP]);; esac diff --git a/c/src/lib/libbsp/powerpc/acinclude.m4 b/c/src/lib/libbsp/powerpc/ac index 4c83475..edc67b5 100644 --- a/c/src/lib/libbsp/powerpc/acinclude.m4 +++ b/c/src/lib/libbsp/powerpc/acinclude.m4 @@ -32,12 +32,12 @@ AC_DEFUN([RTEMS_CHECK_BSPDIR], AC_CONFIG_SUBDIRS([t32mppc]);; tqm8xx ) AC_CONFIG_SUBDIRS([tqm8xx]);; - virtex ) -AC_CONFIG_SUBDIRS([virtex]);; virtex4 ) AC_CONFIG_SUBDIRS([virtex4]);; virtex5 ) AC_CONFIG_SUBDIRS([virtex5]);; + virtex ) +AC_CONFIG_SUBDIRS([virtex]);; *) AC_MSG_ERROR([Invalid BSP]);; esac Should I be worried about these? Why did the order of the subdir change here? ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/7] Adding pipe support
Hello Kevin, looks good so far (except one white space change, which I will fix for you, white space changes may lead to merge conflicts during a FreeBSD update). However, the "LIBBSD SELECT AND POLL AND KQUEUE AND PIPE 1 TEST" fails: qemu-system-arm -no-reboot -serial null -serial mon:stdio -net none -nographic -M xilinx-zynq-a9 -m 256M -kernel build/arm-rtems4.12-xilinx_zynq_a9_qemu/selectpollkqueue01.exe Warning: nic cadence_gem.0 has no peer Warning: nic cadence_gem.1 has no peer *** LIBBSD SELECT AND POLL AND KQUEUE AND PIPE 1 TEST *** nexus0: test select timeout test select connect worker: create new connect socket worker: connect test select read worker: write test select write worker: read test select close worker: close test poll timeout test poll connect worker: create new connect socket worker: connect test poll read worker: write test poll write worker: read test poll close worker: close test kqueue timer test kqueue timer test kqueue connect worker: create new connect socket worker: connect test kqueue read worker: write test kqueue write worker: read test kqueue close worker: shutdown test kqueue user test pipe timeout assertion "rv == 0" failed: file "../../testsuite/selectpollkqueue01/test_main.c", line 1057, function: test_pipe_timeout -- 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/7] Adding pipe support
Let me take a look when running it with QEMU. I ran it against my custom LPC3250 BSP on real hardware. Perhaps there is something else that needs to be done to support pipe than just the patches I submitted. 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: Thursday, December 15, 2016 3:52 AM To: Kirspel, Kevin ; devel@rtems.org Subject: Re: [PATCH 1/7] Adding pipe support Hello Kevin, looks good so far (except one white space change, which I will fix for you, white space changes may lead to merge conflicts during a FreeBSD update). However, the "LIBBSD SELECT AND POLL AND KQUEUE AND PIPE 1 TEST" fails: qemu-system-arm -no-reboot -serial null -serial mon:stdio -net none -nographic -M xilinx-zynq-a9 -m 256M -kernel build/arm-rtems4.12-xilinx_zynq_a9_qemu/selectpollkqueue01.exe Warning: nic cadence_gem.0 has no peer Warning: nic cadence_gem.1 has no peer *** LIBBSD SELECT AND POLL AND KQUEUE AND PIPE 1 TEST *** nexus0: test select timeout test select connect worker: create new connect socket worker: connect test select read worker: write test select write worker: read test select close worker: close test poll timeout test poll connect worker: create new connect socket worker: connect test poll read worker: write test poll write worker: read test poll close worker: close test kqueue timer test kqueue timer test kqueue connect worker: create new connect socket worker: connect test kqueue read worker: write test kqueue write worker: read test kqueue close worker: shutdown test kqueue user test pipe timeout assertion "rv == 0" failed: file "../../testsuite/selectpollkqueue01/test_main.c", line 1057, function: test_pipe_timeout -- 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 1/1] getting started for gsoc
From: sgmonusg
---
testsuites/samples/hello/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/testsuites/samples/hello/init.c b/testsuites/samples/hello/init.c
index a2d6c30..2aca030 100644
--- a/testsuites/samples/hello/init.c
+++ b/testsuites/samples/hello/init.c
@@ -31,7 +31,7 @@ rtems_task Init(
{
rtems_print_printer_printf(&rtems_test_printer);
rtems_test_begin();
- printf( "Hello World\n" );
+ printf( "Hello sagar\n" );
rtems_test_end();
exit( 0 );
}
--
1.9.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Regarding modified hello world example
Congratulations on getting it working. Please post your diff to hello world and a screenshot. What host OS are you using? What type of project are you interested in doing? Depending on the project, you may have to move to another BSP which has a simulator with same networking or graphics support. Or you may need to be on actual hardware. We can guide you through BSP selection after we know what you want to do. Disclaimer: No organizations have applied to GSOC and there is no guarantee we will be accepted. :) --joel On Dec 15, 2016 12:24 AM, "Tanu Hari Dixit" wrote: > Hello Devs, > > Kindly advise me whether I need to send a patch with a modified hello > world example as given in > https://devel.rtems.org/wiki/GSoC/GettingStarted#ProveYouCanWorkOnRTEMS. > Furthermore, I wanted to ask, is there a new set of documentation that > I should be aware of, other than that hosted at > https://devel.rtems.org/ ? > I aim to participate in GSoC '17 under RTEMS. How should I proceed > now, that I have set up RTEMS ? > Also, when I modified testsuites/samples/hello/init.c, the following > m4 files also got modified: > > c/src/lib/libbsp/bfin/acinclude.m4 > c/src/lib/libbsp/powerpc/acinclude.m4 > > in the following way, > > diff --git a/c/src/lib/libbsp/bfin/acinclude.m4 b/c/src/lib/libbsp/bfin/ > acinclud > index ab6082e..828fd89 100644 > --- a/c/src/lib/libbsp/bfin/acinclude.m4 > +++ b/c/src/lib/libbsp/bfin/acinclude.m4 > @@ -2,12 +2,12 @@ > AC_DEFUN([RTEMS_CHECK_BSPDIR], > [ >case "$1" in > - TLL6527M ) > -AC_CONFIG_SUBDIRS([TLL6527M]);; >bf537Stamp ) > AC_CONFIG_SUBDIRS([bf537Stamp]);; >eZKit533 ) > AC_CONFIG_SUBDIRS([eZKit533]);; > + TLL6527M ) > +AC_CONFIG_SUBDIRS([TLL6527M]);; >*) > AC_MSG_ERROR([Invalid BSP]);; >esac > diff --git a/c/src/lib/libbsp/powerpc/acinclude.m4 > b/c/src/lib/libbsp/powerpc/ac > index 4c83475..edc67b5 100644 > --- a/c/src/lib/libbsp/powerpc/acinclude.m4 > +++ b/c/src/lib/libbsp/powerpc/acinclude.m4 > @@ -32,12 +32,12 @@ AC_DEFUN([RTEMS_CHECK_BSPDIR], > AC_CONFIG_SUBDIRS([t32mppc]);; >tqm8xx ) > AC_CONFIG_SUBDIRS([tqm8xx]);; > - virtex ) > -AC_CONFIG_SUBDIRS([virtex]);; >virtex4 ) > AC_CONFIG_SUBDIRS([virtex4]);; >virtex5 ) > AC_CONFIG_SUBDIRS([virtex5]);; > + virtex ) > +AC_CONFIG_SUBDIRS([virtex]);; >*) > AC_MSG_ERROR([Invalid BSP]);; >esac > > Should I be worried about these? Why did the order of the subdir change > here? > ___ > 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
POSIX compliance development
Hello, For Slingshot, an RTEMS-targeted fault-injection tool for the POSIX API, I need to remove the tests that correspond to unimplemented/unimplementable POSIX functions/constants/etc. I can either 1. write a script that searches for "Unimplemented" and "Unimplementable" in the doc's source, and removes the corresponding function's test cases every time after generating test cases or, 2. manually delete all unimplemented/unimplementable from the Slingshot core so that they aren't generated at all. Now the question is: Apart from unimplementable functions, is there any direction to implement unimplemented parts beyond the current situation? Cause in that case, I think writing a script is a better option. Best Regards, Saeed ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RTEMS Presentation in a Couple of Hours
Hi I will be giving a RTEMS state of the world presentation this morning at the Flight Software Workshop. The talks are great a d are being streamed live on YouTube. Go to flightsoftware.org for the agenda and link. If the presentation leads to questions, feel free to ask them. Thanks. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Update Atsam BSP Support
On 15/12/2016 17:21, Sebastian Huber wrote: It would be quite nice if we can write BSP README files in reStructuredText placed in the Git repository that show up on the wiki. I support using the ReST format. I am not convinced the Wiki is the best place to land this documentation. These READMEs are really good documentation and we need better BSP documentation. Having it included in the release documentation would be nice. We already have BSP documentation on the wiki. We have also BSP documentation in the README files. What we really need is to document things only once for a specific domain and present it to the user where it expects the information. I agree. Using README files in ReST format gives us the opportunity to present the same information * in the source tree as a simple text file, * in the wiki via plug-in, and * in a user manual via sphinx. I do not think the wiki is needed if a manual contains the needed content and too many places confuses the work flow for users. I also feel generated doco on a wiki is confusing because users of a wiki expect to be able to change the content on the wiki and there is no back flow to the README source. The rtems-doco.git repo is user focused and not design or implementation documentation. I see the wiki holding specific use cases for someone doing a specific thing as a how to. Joel and stated to me he would like to see more of the wiki content have related to Quick Start etc moved into the User Manual to strength it and make it easier for users and I agree. For example who is going to search the wiki and remove all SIS BSP related issues how it has been removed from the master branch? The SIS BSP is still in 4.10 and 4.11 so does removing those references mean users of those versions have lost a documentation resource? Why not add this documentation to the rtems-docs.git repo? Why not move the documentation back into the rtems.git repo? The docs are a boarder set of topics than just the kernel and it complicates constant integration. I think is it very nice if you have the BSP sources and a basic documentation in the same directory. How often do these files change? I suspect infrequently because they impact on the user if changes are made. The type of information I see being in the documentation is user focused so it is about configuration and management of the BSP and this is a contract between the user and BSP that should not change without careful consideration. Having the BSP doco in the rtems-docs.git repo means we can make and publish the doc formats we support, ie HTML and PDF, because that repo has all the support needed to build the documentation. It is also supported as part of the release procedure. If the desire is to keep this documentation close to the source, which is attractive, and using rtems-docs.git is a good idea then we need to figure out how to handle this. I still think that it was not good to move the documentation sources into a separate repository. I do not agree. Documentation is more than just the RTEMS kernel. We need to cover Eclipse, debugging, tools not in the kernel source tree, eco-systems, libbsd, applications, building system issues for applications and pushing these down into the RTEMS kernel source is confusing for those topics creating unrelated commit churn which then effects constant integration. We have a lot of copy and paste in the documentation and duplicated information in the header files and the documentation files. I would hope the amount of user focused documentation in the headers is small. We need formal documentation for all the APIs we support and I would like to see us adding examples to each function to show it's usage. One option to simplify this would be a XML file I tolerant XML, I do not love it. Personally I find INI files a simpler input format to handle when a user needs to maintain it and INI files are OK in some cases and not great in others. :) which defines and documents the RTEMS interfaces (data types, functions, defines, macros, etc.) and then use a generator to produce header (maybe even with Doxygen comments) files, documentation files and also test cases. I would prefer the user documentation be user focused and we aim at just the supported API functions. These are the functions that do not and cannot change across releases unless there is a documented, considered and traceable reason. I am fine with internal, implementation and test case documentation being on a wiki, deoxygen or what ever works best and being generated. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: C11 Re: [PATCH 3/6] termios: Use C11 mutex for input/output
On 15/12/2016 18:02, Sebastian Huber wrote: On 14/12/16 22:15, Chris Johns wrote: On 15/12/2016 00:39, Sebastian Huber wrote: Use C11 mutexes instead of Classic semaphores as a performance optimization and to simplify the application configuration. The use of C11 mutexes has not been agreed too and we need to discuss this in more detail before we allow use within RTEMS. I would like to see positive agreement from all core maintainers before this and similar patches can be merged. A patch is a good thing to start such a discussion. Great. RTEMS has required the use of the Classic API because: 1. Available on all architectures, BSPs and tool sets. 2. Always present in a build. 3. Was considered faster than POSIX. 3. is not the case. From an API point of view the POSIX operations could be faster than the Classic API since the parameter evaluation is simpler. Yes, things have moved on and those crusty old developers like me have a soft spot for the classic API and I suspect these days it is little distorted view. :) The Classic API provides a base level of required functionality because it is always available in supported tool sets and leads to the smallest footprint because we do not need to link in more than one API. Compared to self-contained objects (like the C11 mutexes for example) the overhead of the Classic objects is huge in terms of run-time, memory footprint, code size (object administration) and complexity (object administration, use of a heap, unlimited objects, configuration). I agree. The self contained is very attractive and a really big feature. I understand things change and move on so it is great to see this change being proposed and our existing base line being challenged. I see from your performance figures C11 mutexes are better and the resources are allocated as needed and used which is a better model than the Classic API's configuration table. This is nice. Do all architectures and BSPs have working C11 support? Yes, all architectures and BSPs support the C11 mutexes, condition variables, thread-specific storage (mapped to POSIX keys), once support (mapped to POSIX once) in all configurations. The C11 threads are mapped to POSIX threads (for simplicity, not a hard requirement). Thank you and well done for all your efforts in this area. This is a really excellent place to be. Is there tests in the RTEMS testsuite for C11 threading services? https://git.rtems.org/rtems/tree/testsuites/sptests/spstdthreads01/init.c Nice. What target resources are used to support this API, ie code and RAM usage? On a 32-bit target: (gdb) p sizeof(Semaphore_Control) $1 = 72 (gdb) p sizeof(mtx_t) $2 = 20 With Thumb-2 instruction set: size ./arm-rtems4.12/c/atsamv/cpukit/score/src/libscore_a-mutex.o ./arm-rtems4.12/c/atsamv/cpukit/score/src/libscore_a-condition.o ./arm-rtems4.12/c/atsamv/cpukit/libstdthreads/libstdthreads_a-*.o textdata bss dec hex filename 704 0 0 704 2c0 ./arm-rtems4.12/c/atsamv/cpukit/score/src/libscore_a-mutex.o 536 0 0 536 218 ./arm-rtems4.12/c/atsamv/cpukit/score/src/libscore_a-condition.o 4 0 0 4 4 ./arm-rtems4.12/c/atsamv/cpukit/libstdthreads/libstdthreads_a-call_once.o 100 0 0 100 64 ./arm-rtems4.12/c/atsamv/cpukit/libstdthreads/libstdthreads_a-cnd.o 104 0 0 104 68 ./arm-rtems4.12/c/atsamv/cpukit/libstdthreads/libstdthreads_a-mtx.o 156 0 0 156 9c ./arm-rtems4.12/c/atsamv/cpukit/libstdthreads/libstdthreads_a-thrd.o 40 0 0 40 28 ./arm-rtems4.12/c/atsamv/cpukit/libstdthreads/libstdthreads_a-tss.o size ./arm-rtems4.12/c/atsamv/cpukit/rtems/src/librtems_a-sem* textdata bss dec hex filename 496 0 0 496 1f0 ./arm-rtems4.12/c/atsamv/cpukit/rtems/src/librtems_a-semcreate.o 152 0 0 152 98 ./arm-rtems4.12/c/atsamv/cpukit/rtems/src/librtems_a-semdelete.o 68 0 0 68 44 ./arm-rtems4.12/c/atsamv/cpukit/rtems/src/librtems_a-semflush.o 28 0 0 28 1c ./arm-rtems4.12/c/atsamv/cpukit/rtems/src/librtems_a-semident.o 48 0 0 48 30 ./arm-rtems4.12/c/atsamv/cpukit/rtems/src/librtems_a-sem.o 428 0 0 428 1ac ./arm-rtems4.12/c/atsamv/cpukit/rtems/src/librtems_a-semobtain.o 464 0 0 464 1d0 ./arm-rtems4.12/c/atsamv/cpukit/rtems/src/librtems_a-semrelease.o 312 0 0 312 138 ./arm-rtems4.12/c/atsamv/cpukit/rtems/src/librtems_a-semsetpriority.o Nice. The libscore_a-mutex.o contains more than one function. For example we have (Cortex-M7 target): 7000c5f0 <_Mutex_recursive_Acquire>: 7000c5f0: 2380movsr3, #128; 0x80 7000c5f2: f3ef 8111 mrs r1, BASEPRI 7000c5f6: f383 8812
Re: [PATCH] dev: Add NXP SC16IS752 serial device driver
On 15/12/2016 17:27, Sebastian Huber wrote: On 14/12/16 22:59, Chris Johns wrote: On 15/12/2016 01:23, Sebastian Huber wrote: From: Alexander Krutwig Update #2841. --- cpukit/dev/Makefile.am| 7 + cpukit/dev/include/dev/serial/nxp-sc16is752.h | 165 + cpukit/dev/preinstall.am | 9 + cpukit/dev/serial/nxp-sc16is752-regs.h| 108 +++ cpukit/dev/serial/nxp-sc16is752-spi.c | 126 + cpukit/dev/serial/nxp-sc16is752.c | 257 ++ 6 files changed, 672 insertions(+) create mode 100644 cpukit/dev/include/dev/serial/nxp-sc16is752.h create mode 100644 cpukit/dev/serial/nxp-sc16is752-regs.h create mode 100644 cpukit/dev/serial/nxp-sc16is752-spi.c create mode 100644 cpukit/dev/serial/nxp-sc16is752.c I see this change adds serial drivers to the cpukit/dev tree. Yes, and it was in total more than one man month of work to make this possible. Its not a small thing. OK. Is this where all new serial drivers are to be located? I am happy to see this happen but we need suitable documentation about this and any rules etc developers need to know including "add all new serial drivers here". The preferred place for drivers should be the cpukit. I agree. We need however a suitable abstraction of the low-level hardware access. We don't have this at the moment except for I2C and SPI. OK. Do we have documentation about the cpukit/dev tree? Documentation of the new SPI and I2C frameworks is on my todo list. I will add some notes to the console driver chapter. Thanks. What happens to the existing drivers we have in libchip and other locations? Is the aim to have all driver move to cpukit/dev? Yes, this should be the aim, however, I don't see that anyone has time to do this. OK. I already spend more than one man week in vain to do this and eventually gave up. What was the issue? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
