RTEMS examples build failed
Hi,
While trying to build the examples with a fresh pull from upstream,
I got the following build error from gccdeps:
```
Build failed
Traceback (most recent call last):
File
"/home/lunatic/development/rtems-examples/.waf-2.0.19-1f3c580272b15a03d2566843c5fe872a/waflib/Task.py",
line 190, in process
self.post_run()
File "/home/lunatic/development/rtems-examples/rtems_waf/gccdeps.py",
line 144, in post_run
raise ValueError('could not find %r for %r' % (x, self))
ValueError: could not find ['filesystem', 'fat_ramdisk', 'fs-root-tar.h']
for
{task 140158121470544: c init.c -> init.c.5.o}
```
Looks like this error is coming from the commit where I updated the
rtems_waf.
Any Idea on how to solve this?
Thanks,
Vijay
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS examples build failed
On Sun, Apr 19, 2020 at 3:52 AM Vijay Kumar Banerjee wrote:
>
> Hi,
>
> While trying to build the examples with a fresh pull from upstream,
> I got the following build error from gccdeps:
>
> ```
> Build failed
> Traceback (most recent call last):
> File
> "/home/lunatic/development/rtems-examples/.waf-2.0.19-1f3c580272b15a03d2566843c5fe872a/waflib/Task.py",
> line 190, in process
> self.post_run()
> File "/home/lunatic/development/rtems-examples/rtems_waf/gccdeps.py", line
> 144, in post_run
> raise ValueError('could not find %r for %r' % (x, self))
> ValueError: could not find ['filesystem', 'fat_ramdisk', 'fs-root-tar.h'] for
It's doing an error check to find the build dependency fs-root-tar.h,
which gets generated in the build directory by bin2c. This has always
been tricky to handle in waf. I don't grok the way Chris reworked the
rootfs support in the example so I don't immediately see the root
(hah) problem or how to try to fix it.
> {task 140158121470544: c init.c -> init.c.5.o}
> ```
> Looks like this error is coming from the commit where I updated the rtems_waf.
> Any Idea on how to solve this?
>
> Thanks,
> Vijay
> ___
> 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: RTEMS examples build failed
On 19/04/2020 15:38, Gedare Bloom wrote:
On Sun, Apr 19, 2020 at 3:52 AM Vijay Kumar Banerjee wrote:
Hi,
While trying to build the examples with a fresh pull from upstream,
I got the following build error from gccdeps:
```
Build failed
Traceback (most recent call last):
File
"/home/lunatic/development/rtems-examples/.waf-2.0.19-1f3c580272b15a03d2566843c5fe872a/waflib/Task.py",
line 190, in process
self.post_run()
File "/home/lunatic/development/rtems-examples/rtems_waf/gccdeps.py", line
144, in post_run
raise ValueError('could not find %r for %r' % (x, self))
ValueError: could not find ['filesystem', 'fat_ramdisk', 'fs-root-tar.h'] for
It's doing an error check to find the build dependency fs-root-tar.h,
which gets generated in the build directory by bin2c. This has always
been tricky to handle in waf. I don't grok the way Chris reworked the
rootfs support in the example so I don't immediately see the root
(hah) problem or how to try to fix it.
I struggled with this stuff also in the new build system. waf is pretty
nice, once you figured out how something works, but at least for me it
was always very hard to figure out solutions. I can write Makefiles a
hundred times faster. Maybe this helps:
https://git.rtems.org/sebh/rtems.git/tree/wscript?h=build#n410
https://git.rtems.org/sebh/rtems.git/tree/spec/build/testsuites/libtests/RTEMS-BUILD-TEST-LIB-TAR01.yml?h=build
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Small doubt in a build time warning of sp test of leon3
Hey everyone, In the Covid Code-in update by Dr. Joel, he mentioned that the RTEMS could use some help to remove warnings from the code. In the link( https://ftp.rtems.org/pub/rtems/people/joel/warnings/warnings-5-20200408/warnings-all-5-20200408.txt) of warnings for RTEMS 5, one of the warning is: log/sparc-leon3.log:../../../../../../rtems/c/src/../../testsuites/sptests/sp37/init.c:172:21: warning: unused variable 'name' [-Wunused-variable] log/sparc-leon3.log:../../../../../../rtems/c/src/../../testsuites/sptests/sp37/init.c:172:21: warning: 'name' defined but not used [-Wunused-const-variable=] On opening init.c from ~/quick-start/src/rtems/testsuites/sptests/sp37/. Lines 172 to 175 are: static const char name[] = "test"; ISR_Level normal_interrupt_level = _ISR_Get_level(); ISR_lock_Control initialized = ISR_LOCK_INITIALIZER( name ); ISR_lock_Control zero_initialized; We can see that the name variable is being used in line 174(and later on 3 more times, outside any conditional blocks). Why would Dr. Joel get such a warning then? Thanks, Richi. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Doorstop Issues
Hello, I am about to add the next couple of hundred specification items for the RTEMS pre-qualification activity. Before I do this, I would like to present some issues that popped up during my daily work with Doorstop. Doorstop is a requirements management tool which was selected for the pre-qualification activity: https://docs.rtems.org/branches/master/eng/req-eng.html#selected-tool-doorstop I am quite happy that Jan Sommer suggested to use this tool. I has some pretty nice features. In particular, I think the file based organization in YAML format forming a directed acyclic graph is really the right thing for this project. However, it turned out that it lacks the required flexibility. 1. Its use case is requirements management. So it has some standard attributes useful in this domain, like derived, header, level, normative, ref, reviewed, and text. However, I want to use it more generally for specification items and these attributes make not always sense. Having them in every item is just overhead and may cause confusion. 2. The links cannot have custom attributes, e.g. role, enabled-by. 3. Inside a document (directory) items are supposed to have a common type. I would like to store at a hierarchy level also distinct specializations. 4. The verification if the items is quite limited. We need verification with type-based rules. 5. The UIDs in combination with the document hierarchy lead to duplication, e.g. a/b/c/a-b-c-d.yml. You have the path (a/b/c) also in the file name (a-b-c). You cannot have relative UIDs in links (e.g. ../parent-req) . The specification items may contain multiple requirements, e.g. min/max attributes. There is no way to identify them. I will probably stop using Doorstop and use a custom tooling. With Python, this is quite easy. I already have the infrastructure for this in: https://git.rtems.org/sebh/rtems-qual.git/ I will try this out with the new build system. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Small doubt in a build time warning of sp test of leon3
On Sun, Apr 19, 2020, 9:59 AM Richi Dubey wrote: > Hey everyone, > > In the Covid Code-in update by Dr. Joel, he mentioned that the RTEMS could > use some help to remove warnings from the code. In the link( > https://ftp.rtems.org/pub/rtems/people/joel/warnings/warnings-5-20200408/warnings-all-5-20200408.txt) > of warnings for RTEMS 5, one of the warning is: > > log/sparc-leon3.log:../../../../../../rtems/c/src/../../testsuites/sptests/sp37/init.c:172:21: > warning: unused variable 'name' [-Wunused-variable] > log/sparc-leon3.log:../../../../../../rtems/c/src/../../testsuites/sptests/sp37/init.c:172:21: > warning: 'name' defined but not used [-Wunused-const-variable=] > > > On opening init.c from ~/quick-start/src/rtems/testsuites/sptests/sp37/. > Lines 172 to 175 are: > > static const char name[] = "test"; > ISR_Level normal_interrupt_level = _ISR_Get_level(); > ISR_lock_Control initialized = ISR_LOCK_INITIALIZER( name ); > ISR_lock_Control zero_initialized; > > We can see that the name variable is being used in line 174(and later on 3 > more times, outside any conditional blocks). Why would Dr. Joel get such a > warning then? > Does ISR_LOCK_INITIALIZER actually use the name? It possibly only uses it when RTEMS_DEBUG is enabled. Check that. > > Thanks, > Richi. > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH v3] updates #3889, Added test for timer_create() using CLOCK_MONOTONIC
>I will create a timer using timer_create() function, and passing CLOCK_MONOTONIC in clock_id argument. >The test will fail as there is no support for CLOCK_MONOTONIC in cpukit/posix/src/psxtimercreate.c. >The added code compiles successfully without any errors. Signed-off-by: Eshan dhawan --- testsuites/psxtests/psxtimer02/psxtimer.c | 8 ++-- testsuites/psxtests/psxtimer02/psxtimer02.scn | 3 ++- 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/testsuites/psxtests/psxtimer02/psxtimer.c b/testsuites/psxtests/psxtimer02/psxtimer.c index 9f79d33c42..e071f98857 100644 --- a/testsuites/psxtests/psxtimer02/psxtimer.c +++ b/testsuites/psxtests/psxtimer02/psxtimer.c @@ -62,9 +62,9 @@ void *POSIX_Init ( status = timer_create( CLOCK_REALTIME, &event, NULL ); fatal_posix_service_status_errno( status, EINVAL, "bad timer id" ); - puts( "timer_create - OK" ); + puts( "timer_create (CLOCK_REALTIME) - OK" ); status = timer_create( CLOCK_REALTIME, NULL, &timer ); - posix_service_failed( status, "timer_create OK" ); + posix_service_failed( status, "timer_create (CLOCK_REALTIME)" ); puts( "timer_create - too many - EAGAIN" ); status = timer_create( CLOCK_REALTIME, NULL, &timer1 ); @@ -127,6 +127,10 @@ void *POSIX_Init ( status = timer_delete( timer ); fatal_posix_service_status_errno( status, EINVAL, "bad id" ); + puts( "timer_create (CLOCK_MONOTONIC) - OK" ); + status = timer_create( CLOCK_MONOTONIC, NULL, &timer ); + posix_service_failed( status, "timer_create (CLOCK_MONOTONIC)" ); + TEST_END(); rtems_test_exit (0); } diff --git a/testsuites/psxtests/psxtimer02/psxtimer02.scn b/testsuites/psxtests/psxtimer02/psxtimer02.scn index e78425a32e..7429bcf291 100644 --- a/testsuites/psxtests/psxtimer02/psxtimer02.scn +++ b/testsuites/psxtests/psxtimer02/psxtimer02.scn @@ -1,7 +1,7 @@ *** POSIX Timers Test 02 *** timer_create - bad clock id - EINVAL timer_create - bad timer id pointer - EINVAL -timer_create - OK +timer_create (CLOCK_REALTIME) - OK timer_create - too many - EAGAIN timer_delete - bad id - EINVAL timer_getoverrun - bad id - EINVAL @@ -13,4 +13,5 @@ timer_settime - bad itimer value - negative nanosecond - EINVAL timer_settime - bad clock value - EINVAL timer_delete - OK timer_delete - bad id - EINVAL +timer_create (CLOCK_MONOTONIC) - OK *** END OF POSIX Timers Test 02 *** -- 2.17.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
doubts in new RTEMS Test framework
Hello everyone, I tried to implement the new RTEMS Test framework told in this mail https://lists.rtems.org/pipermail/devel/2020-April/059203.html to pthread_getcpuclockid test suite as Dr Joel suggested https://lists.rtems.org/pipermail/devel/2020-April/059466.html But the terminal flashes the error when I replace POSIX_init with T_TEST_CASE() psxgetcpuclockid01/psxgetcpuclockid01-init.o:(.sdata2._POSIX_Threads_User_thread_table+0x0): undefined reference to `POSIX_Init' and when I remove #define CONFIGURE_POSIX_INIT_THREAD_TABLE Then it shows the error #error "You must define one of CONFIGURE_IDLE_TASK_INITIALIZES_APPLICATION, CONFIGURE_RTEMS_INIT_TASKS_TABLE, and CONFIGURE_POSIX_INIT_THREAD_TABLE" which option would be selected in the case and what other changes would be required Thanks :) -Eshan ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: doubts in new RTEMS Test framework
My advice in these situations is to look for an existing that that uses the framework and see what it looks like in the source files and Makefile.am. On Sun, Apr 19, 2020, 3:17 PM Eshan Dhawan wrote: > Hello everyone, > I tried to implement the new RTEMS Test framework > told in this mail > https://lists.rtems.org/pipermail/devel/2020-April/059203.html > to pthread_getcpuclockid test suite as Dr Joel suggested > https://lists.rtems.org/pipermail/devel/2020-April/059466.html > But the terminal flashes the error when I replace POSIX_init with > T_TEST_CASE() > psxgetcpuclockid01/psxgetcpuclockid01-init.o:(.sdata2._POSIX_Threads_User_thread_table+0x0): > undefined reference to `POSIX_Init' > and when I remove > #define CONFIGURE_POSIX_INIT_THREAD_TABLE > Then it shows the error > #error "You must define one of > CONFIGURE_IDLE_TASK_INITIALIZES_APPLICATION, > CONFIGURE_RTEMS_INIT_TASKS_TABLE, and CONFIGURE_POSIX_INIT_THREAD_TABLE" > > which option would be selected in the case and what other changes would be > required > > Thanks :) > -Eshan > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Add BSP for STM32H7
On 19/03/2020 09:32, Sebastian Huber wrote: Hello, I started to work on a BSP for the STM32H7: https://devel.rtems.org/ticket/3910 I will use the new build system for this BSP. The BSP is now available in the new build system branch: https://git.rtems.org/sebh/rtems.git/log/?h=build ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Add BSP for STM32H7
On 20/4/20 2:43 pm, Sebastian Huber wrote: On 19/03/2020 09:32, Sebastian Huber wrote: Hello, I started to work on a BSP for the STM32H7: https://devel.rtems.org/ticket/3910 I will use the new build system for this BSP. The BSP is now available in the new build system branch: https://git.rtems.org/sebh/rtems.git/log/?h=build How do you plan to have the build system (+ BSP + ??) code reviewed once we have branched for RTEMS 5? The more you add the more there is and I will be focused on the RTEMS 5 branch until the release. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Add BSP for STM32H7
On 20/04/2020 07:02, Chris Johns wrote: On 20/4/20 2:43 pm, Sebastian Huber wrote: On 19/03/2020 09:32, Sebastian Huber wrote: Hello, I started to work on a BSP for the STM32H7: https://devel.rtems.org/ticket/3910 I will use the new build system for this BSP. The BSP is now available in the new build system branch: https://git.rtems.org/sebh/rtems.git/log/?h=build How do you plan to have the build system (+ BSP + ??) code reviewed once we have branched for RTEMS 5? Yes. The more you add the more there is and I will be focused on the RTEMS 5 branch until the release. This is fine, I don't want to distract you from the RTEMS 5 release work. I added it just in case someone is interested in this BSP. The STM32H7 is a nice chip for RTEMS. Also I am about to rename the specification files with a script: https://lists.rtems.org/pipermail/devel/2020-April/059472.html ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Doorstop Issues
On 20/4/20 1:14 am, Sebastian Huber wrote: Hello, I am about to add the next couple of hundred specification items for the RTEMS pre-qualification activity. Before I do this, I would like to present some issues that popped up during my daily work with Doorstop. Doorstop is a requirements management tool which was selected for the pre-qualification activity: https://docs.rtems.org/branches/master/eng/req-eng.html#selected-tool-doorstop I am quite happy that Jan Sommer suggested to use this tool. I has some pretty nice features. In particular, I think the file based organization in YAML format forming a directed acyclic graph is really the right thing for this project. However, it turned out that it lacks the required flexibility. 1. Its use case is requirements management. So it has some standard attributes useful in this domain, like derived, header, level, normative, ref, reviewed, and text. However, I want to use it more generally for specification items and these attributes make not always sense. Having them in every item is just overhead and may cause confusion. 2. The links cannot have custom attributes, e.g. role, enabled-by. 3. Inside a document (directory) items are supposed to have a common type. I would like to store at a hierarchy level also distinct specializations. 4. The verification if the items is quite limited. We need verification with type-based rules. 5. The UIDs in combination with the document hierarchy lead to duplication, e.g. a/b/c/a-b-c-d.yml. You have the path (a/b/c) also in the file name (a-b-c). You cannot have relative UIDs in links (e.g. ../parent-req) . The specification items may contain multiple requirements, e.g. min/max attributes. There is no way to identify them. I will probably stop using Doorstop and use a custom tooling. Have you discussed these issues with the Doorstop project? With Python, this is quite easy. I already have the infrastructure for this in: https://git.rtems.org/sebh/rtems-qual.git/ Why not place the tool in the rtems-tools repo? This repo exists for this purpose. I will try this out with the new build system. I suppose this is something else in the queue to review Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Doorstop Issues
On 20/04/2020 07:12, Chris Johns wrote: On 20/4/20 1:14 am, Sebastian Huber wrote: Hello, I am about to add the next couple of hundred specification items for the RTEMS pre-qualification activity. Before I do this, I would like to present some issues that popped up during my daily work with Doorstop. Doorstop is a requirements management tool which was selected for the pre-qualification activity: https://docs.rtems.org/branches/master/eng/req-eng.html#selected-tool-doorstop I am quite happy that Jan Sommer suggested to use this tool. I has some pretty nice features. In particular, I think the file based organization in YAML format forming a directed acyclic graph is really the right thing for this project. However, it turned out that it lacks the required flexibility. 1. Its use case is requirements management. So it has some standard attributes useful in this domain, like derived, header, level, normative, ref, reviewed, and text. However, I want to use it more generally for specification items and these attributes make not always sense. Having them in every item is just overhead and may cause confusion. 2. The links cannot have custom attributes, e.g. role, enabled-by. 3. Inside a document (directory) items are supposed to have a common type. I would like to store at a hierarchy level also distinct specializations. 4. The verification if the items is quite limited. We need verification with type-based rules. 5. The UIDs in combination with the document hierarchy lead to duplication, e.g. a/b/c/a-b-c-d.yml. You have the path (a/b/c) also in the file name (a-b-c). You cannot have relative UIDs in links (e.g. ../parent-req) . The specification items may contain multiple requirements, e.g. min/max attributes. There is no way to identify them. I will probably stop using Doorstop and use a custom tooling. Have you discussed these issues with the Doorstop project? Not yet, but it would be quite a big change in Doorstop to fix these issues. With Python, this is quite easy. I already have the infrastructure for this in: https://git.rtems.org/sebh/rtems-qual.git/ Why not place the tool in the rtems-tools repo? This repo exists for this purpose. Now I am a bit confused. You wanted to have all the pre-qualification stuff separated. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
