Enter in the main Creating first task : Hello World! task with max priority now tv_sec = 4766459, tv_nsec = 567993600 timeout tv_sec = 4766459, tv_nsec = 567993603 The task is coming to enter in a timed wait The task is coming out from the timed wait First Task created Creating second task : Hello World! Task with lowest priority Second task created

Out of the main If I now swap the arguments in the set-function , i.e. instead of rtems_timespec_set(&timeout, 3, 0); rtems_timespec_set(&timeout, 0, 3); it looks as it should : Hello World! task with max priority now tv_sec = 10766729, tv_nsec = 567993600 timeout tv_sec = 10766732, tv_nsec = 567993600 The task is coming to enter in a timed wait The task is coming out from the timed wait First Task created Creating second task : Hello World! Task with lowest priority Second task created

Out of the main But still no timed wait recognizable :-( Heinz -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2542 bytes Desc: not available URL: From joel at rtems.org Fri Apr 9 18:19:39 2021 From: joel at rtems.org (Joel Sherrill) Date: Fri, 9 Apr 2021 13:19:39 -0500 Subject: SIS in "real time" In-Reply-To: References:

Message-ID: Hi I made some changes to test3.c so it can be compiled for RTEMS or any "normal" POSIX host like Linux. I avoided the rtems timespec addition method. I think this does what you expect on Linux but didn't try it on RTEMS. FWIW this is a good minimal example of how a program can support being built for Linux and RTEMS. For bigger examples, I prefer the RTEMS configuration and Init thread to be in a separate file. I think the psx reporting examples do that. --joel On Fri, Apr 9, 2021 at 12:45 PM Heinz Junkes wrote: > Jiri, Joel, thanks for your answers. > > @Joel: I was wondering that rtems-examples in psx_example_3 does not wait > 3 seconds. > > I made a curious observation: > > in the original code: > > clock_gettime( CLOCK_REALTIME, &timeout ); > timeout.tv_sec += 3; > timeout.tv_nsec = 0; > printf("The task is coming to enter in a timed wait\n"); > pthread_cond_timedwait(&cond, &mutex, &timeout); > > > I then inserted some printfs and found that the "3" is added to the nsec?s. > > Then I added the rtems-timespec-helpers routines, but get the same > behavior: > > > void * print_hello(void * arg) > { > struct timespec now, timeout; > rtems_timespec_set(&timeout, 3, 0); > > printf(": Hello World! task with max priority \n"); > clock_gettime( CLOCK_REALTIME, &now ); > printf("now tv_sec = %d, tv_nsec = %d\n", now.tv_sec, now.tv_nsec); > rtems_timespec_add_to(&timeout, &now); > printf("timeout tv_sec = %d, tv_nsec = %d\n", timeout.tv_sec, > timeout.tv_nsec); > printf("The task is coming to enter in a timed wait\n"); > pthread_cond_timedwait(&cond, &mutex, &timeout); > printf("The task is coming out from the timed wait \n"); > return NULL; > } > > program output: > >

Enter in the main > Creating first task > : Hello World! task with max priority > now tv_sec = 4766459, tv_nsec = 567993600 > timeout tv_sec = 4766459, tv_nsec = 567993603 > The task is coming to enter in a timed wait > The task is coming out from the timed wait > First Task created > Creating second task > : Hello World! Task with lowest priority Second task created >

Out of the main > > If I now swap the arguments in the set-function , i.e. instead of > rtems_timespec_set(&timeout, 3, 0); > > rtems_timespec_set(&timeout, 0, 3); > > it looks as it should > > : Hello World! task with max priority > now tv_sec = 10766729, tv_nsec = 567993600 > timeout tv_sec = 10766732, tv_nsec = 567993600 > The task is coming to enter in a timed wait > The task is coming out from the timed wait > First Task created > Creating second task > : Hello World! Task with lowest priority Second task created >

Out of the main > > But still no timed wait recognizable :-( > > Heinz > > > > _______________________________________________ > users mailing list > users at rtems.org > http://lists.rtems.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test3.c Type: application/octet-stream Size: 2581 bytes Desc: not available URL: From joel at rtems.org Fri Apr 9 19:45:36 2021 From: joel at rtems.org (Joel Sherrill) Date: Fri, 9 Apr 2021 14:45:36 -0500 Subject: Can not build rtems-examples for sparc/erc32 In-Reply-To: References: <493268701604ba3536d41d1ad79d797a@fhi-berlin.mpg.de> <3faa9b49-0722-5714-0368-cc5d41436c64@embedded-brains.de> Message-ID: On Fri, Apr 9, 2021 at 12:27 PM Heinz Junkes wrote: > Danke, > that worked. > On RTEMS? :) I saw it on Linux. > Heinz > > > On 9. Apr 2021, at 14:35, Sebastian Huber < > sebastian.huber at embedded-brains.de> wrote: > > > > On 09/04/2021 09:20, junkes wrote: > > > >> can not build examples (https://github.com/RTEMS/rtems-examples.git) > for sparc/erc32. > >> Seems to related to missing run time linker lib. > > I updated the RSB. I hope it is fixed now. > > > > -- > > embedded brains GmbH > > Herr Sebastian HUBER > > Dornierstr. 4 > > 82178 Puchheim > > Germany > > email: sebastian.huber at embedded-brains.de > > phone: +49-89-18 94 741 - 16 > > fax: +49-89-18 94 741 - 08 > > > > Registergericht: Amtsgericht M?nchen > > Registernummer: HRB 157899 > > Vertretungsberechtigte Gesch?ftsf?hrer: Peter Rasmussen, Thomas D?rfler > > Unsere Datenschutzerkl?rung finden Sie hier: > > https://embedded-brains.de/datenschutzerklaerung/ > > > > _______________________________________________ > users mailing list > users at rtems.org > http://lists.rtems.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From junkes at fhi-berlin.mpg.de Sat Apr 10 04:11:44 2021 From: junkes at fhi-berlin.mpg.de (Heinz Junkes) Date: Sat, 10 Apr 2021 06:11:44 +0200 Subject: SIS in "real time" In-Reply-To: References:

Message-ID: Hello Joel, thanks for the program, but it doesn't change the (mis-) behavior under RTEMS? I add a 3 seconds delay (sleep 3). clock_gettime( CLOCK_REALTIME, &now ); printf("\nnow tv_sec = %d, tv_nsec = %d\n", now.tv_sec, now.tv_nsec); printf(" sleep 3 sec \n"); sleep(3); clock_gettime( CLOCK_REALTIME, &now ); printf("\nnow tv_sec = %d, tv_nsec = %d\n", now.tv_sec, now.tv_nsec); The issue is related to the clock_gettime() it "sorts" the values incorrectly: now tv_sec = 6683109, tv_nsec = 567993600 sleep 3 sec now tv_sec = 10978989, tv_nsec = 567993603 on Unix: now tv_sec = 1618027860, tv_nsec = 240887959 sleep 3 sec now tv_sec = 1618027863, tv_nsec = 241181294 Heinz > On 9. Apr 2021, at 20:19, Joel Sherrill wrote: > > Hi > > I made some changes to test3.c so it can be compiled for RTEMS or > any "normal" POSIX host like Linux. I avoided the rtems timespec > addition method. > > I think this does what you expect on Linux but didn't try it on RTEMS. > > FWIW this is a good minimal example of how a program can support > being built for Linux and RTEMS. For bigger examples, I prefer the RTEMS > configuration and Init thread to be in a separate file. I think the psx reporting > examples do that. > > --joel > > On Fri, Apr 9, 2021 at 12:45 PM Heinz Junkes wrote: > Jiri, Joel, thanks for your answers. > > @Joel: I was wondering that rtems-examples in psx_example_3 does not wait 3 seconds. > > I made a curious observation: > > in the original code: > > clock_gettime( CLOCK_REALTIME, &timeout ); > timeout.tv_sec += 3; > timeout.tv_nsec = 0; > printf("The task is coming to enter in a timed wait\n"); > pthread_cond_timedwait(&cond, &mutex, &timeout); > > > I then inserted some printfs and found that the "3" is added to the nsec?s. > > Then I added the rtems-timespec-helpers routines, but get the same behavior: > > > void * print_hello(void * arg) > { > struct timespec now, timeout; > rtems_timespec_set(&timeout, 3, 0); > > printf(": Hello World! task with max priority \n"); > clock_gettime( CLOCK_REALTIME, &now ); > printf("now tv_sec = %d, tv_nsec = %d\n", now.tv_sec, now.tv_nsec); > rtems_timespec_add_to(&timeout, &now); > printf("timeout tv_sec = %d, tv_nsec = %d\n", timeout.tv_sec, timeout.tv_nsec); > printf("The task is coming to enter in a timed wait\n"); > pthread_cond_timedwait(&cond, &mutex, &timeout); > printf("The task is coming out from the timed wait \n"); > return NULL; > } > > program output: > >

Out of the main > > But still no timed wait recognizable :-( > > Heinz > > > > _______________________________________________ > users mailing list > users at rtems.org > http://lists.rtems.org/mailman/listinfo/users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2542 bytes Desc: not available URL: From junkes at fhi-berlin.mpg.de Sat Apr 10 10:16:04 2021 From: junkes at fhi-berlin.mpg.de (Heinz Junkes) Date: Sat, 10 Apr 2021 12:16:04 +0200 Subject: rtems-examples posix_api does not work with simulators/emulators like qemu and sis Message-ID: In rtems-examples/posix_api the examples psx_example_[123] do not work as they should (especially timing). E.g. in psx_example_1 the sleep(1) is ignored by sparc-rtems6-sis -rt ? . With qemu-system-arm -M xilinx-zynq-a9 the "sleep" at least works. With both simulators/emulators psx_example_2 gets stuck ( probably in pthread_join (child, NULL) ). BTW: in this example pthread_cond_timedwait() return ?1? !. In the documentation one can find Should return ?0? if ok, EINVAL or ETIMDOUT on failure. psx_example_3 works, but timing is totally ignored. Heinz -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2542 bytes Desc: not available URL: From gedare at rtems.org Mon Apr 12 18:38:25 2021 From: gedare at rtems.org (Gedare Bloom) Date: Mon, 12 Apr 2021 12:38:25 -0600 Subject: SIS in "real time" In-Reply-To: References:

Message-ID: On Fri, Apr 9, 2021 at 11:45 AM Heinz Junkes wrote: > > Jiri, Joel, thanks for your answers. > > @Joel: I was wondering that rtems-examples in psx_example_3 does not wait 3 seconds. > > I made a curious observation: > > in the original code: > > clock_gettime( CLOCK_REALTIME, &timeout ); > timeout.tv_sec += 3; > timeout.tv_nsec = 0; > printf("The task is coming to enter in a timed wait\n"); > pthread_cond_timedwait(&cond, &mutex, &timeout); > > > I then inserted some printfs and found that the "3" is added to the nsec?s. > > Then I added the rtems-timespec-helpers routines, but get the same behavior: > > > void * print_hello(void * arg) > { > struct timespec now, timeout; > rtems_timespec_set(&timeout, 3, 0); > > printf(": Hello World! task with max priority \n"); > clock_gettime( CLOCK_REALTIME, &now ); > printf("now tv_sec = %d, tv_nsec = %d\n", now.tv_sec, now.tv_nsec); > rtems_timespec_add_to(&timeout, &now); > printf("timeout tv_sec = %d, tv_nsec = %d\n", timeout.tv_sec, timeout.tv_nsec); Please try with the appropriate type sizes and report back what you find. tv_sec is of type time_t tv_nsec is of type long %d will only take 32b of those values, so you get some kind of garbage (that can depend on endianness) > printf("The task is coming to enter in a timed wait\n"); > pthread_cond_timedwait(&cond, &mutex, &timeout); > printf("The task is coming out from the timed wait \n"); > return NULL; > } > > program output: > >

Out of the main > > But still no timed wait recognizable :-( > > Heinz > > > > _______________________________________________ > users mailing list > users at rtems.org > http://lists.rtems.org/mailman/listinfo/users From junkes at fhi-berlin.mpg.de Tue Apr 13 13:02:13 2021 From: junkes at fhi-berlin.mpg.de (Heinz Junkes) Date: Tue, 13 Apr 2021 15:02:13 +0200 Subject: SIS in "real time" In-Reply-To: References:

Message-ID: Unfortunately I still do not understand it. Under Unix it runs perfectly and also the values are displayed correctly. In the debugger, the contents of the structure timespec are displayed correctly. Another point that probably makes the program hang: the function pthread_cond_timedwait(&cond, &mutex, &timeout) returns "1" and does not wait for the timeout. This return value should not exist at all? Under Unix, as expected, "110" is returned. ETIMOUT. Heinz > On 12. Apr 2021, at 20:38, Gedare Bloom wrote: > > On Fri, Apr 9, 2021 at 11:45 AM Heinz Junkes wrote: >> >> Jiri, Joel, thanks for your answers. >> >> @Joel: I was wondering that rtems-examples in psx_example_3 does not wait 3 seconds. >> >> I made a curious observation: >> >> in the original code: >> >> clock_gettime( CLOCK_REALTIME, &timeout ); >> timeout.tv_sec += 3; >> timeout.tv_nsec = 0; >> printf("The task is coming to enter in a timed wait\n"); >> pthread_cond_timedwait(&cond, &mutex, &timeout); >> >> >> I then inserted some printfs and found that the "3" is added to the nsec?s. >> >> Then I added the rtems-timespec-helpers routines, but get the same behavior: >> >> >> void * print_hello(void * arg) >> { >> struct timespec now, timeout; >> rtems_timespec_set(&timeout, 3, 0); >> >> printf(": Hello World! task with max priority \n"); >> clock_gettime( CLOCK_REALTIME, &now ); >> printf("now tv_sec = %d, tv_nsec = %d\n", now.tv_sec, now.tv_nsec); >> rtems_timespec_add_to(&timeout, &now); >> printf("timeout tv_sec = %d, tv_nsec = %d\n", timeout.tv_sec, timeout.tv_nsec); > > Please try with the appropriate type sizes and report back what you find. > > tv_sec is of type time_t > tv_nsec is of type long > > %d will only take 32b of those values, so you get some kind of garbage > (that can depend on endianness) > >> printf("The task is coming to enter in a timed wait\n"); >> pthread_cond_timedwait(&cond, &mutex, &timeout); >> printf("The task is coming out from the timed wait \n"); >> return NULL; >> } >> >> program output: >> >>

Enter in the main >> Creating first task >> : Hello World! task with max priority >> now tv_sec = 4766459, tv_nsec = 567993600 >> timeout tv_sec = 4766459, tv_nsec = 567993603 >> The task is coming to enter in a timed wait >> The task is coming out from the timed wait >> First Task created >> Creating second task >> : Hello World! Task with lowest priority Second task created >>

Out of the main >> >> If I now swap the arguments in the set-function , i.e. instead of >> rtems_timespec_set(&timeout, 3, 0); >> >> rtems_timespec_set(&timeout, 0, 3); >> >> it looks as it should >> >> : Hello World! task with max priority >> now tv_sec = 10766729, tv_nsec = 567993600 >> timeout tv_sec = 10766732, tv_nsec = 567993600 >> The task is coming to enter in a timed wait >> The task is coming out from the timed wait >> First Task created >> Creating second task >> : Hello World! Task with lowest priority Second task created >>

Out of the main >> >> But still no timed wait recognizable :-( >> >> Heinz >> >> >> >> _______________________________________________ >> users mailing list >> users at rtems.org >> http://lists.rtems.org/mailman/listinfo/users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2542 bytes Desc: not available URL: From joel at rtems.org Tue Apr 13 13:09:19 2021 From: joel at rtems.org (Joel Sherrill) Date: Tue, 13 Apr 2021 08:09:19 -0500 Subject: SIS in "real time" In-Reply-To: References:

Message-ID: On Tue, Apr 13, 2021 at 8:02 AM Heinz Junkes wrote: > Unfortunately I still do not understand it. Under Unix it runs perfectly > and also the > values are displayed correctly. > > In the debugger, the contents of the structure timespec are displayed > correctly. > > Another point that probably makes the program hang: > > the function pthread_cond_timedwait(&cond, &mutex, &timeout) returns "1" > and does not wait for the timeout. > This return value should not exist at all? > > Under Unix, as expected, "110" is returned. ETIMOUT. > What's your current version of the source? --joel > > Heinz > > > > On 12. Apr 2021, at 20:38, Gedare Bloom wrote: > > > > On Fri, Apr 9, 2021 at 11:45 AM Heinz Junkes > wrote: > >> > >> Jiri, Joel, thanks for your answers. > >> > >> @Joel: I was wondering that rtems-examples in psx_example_3 does not > wait 3 seconds. > >> > >> I made a curious observation: > >> > >> in the original code: > >> > >> clock_gettime( CLOCK_REALTIME, &timeout ); > >> timeout.tv_sec += 3; > >> timeout.tv_nsec = 0; > >> printf("The task is coming to enter in a timed wait\n"); > >> pthread_cond_timedwait(&cond, &mutex, &timeout); > >> > >> > >> I then inserted some printfs and found that the "3" is added to the > nsec?s. > >> > >> Then I added the rtems-timespec-helpers routines, but get the same > behavior: > >> > >> > >> void * print_hello(void * arg) > >> { > >> struct timespec now, timeout; > >> rtems_timespec_set(&timeout, 3, 0); > >> > >> printf(": Hello World! task with max priority \n"); > >> clock_gettime( CLOCK_REALTIME, &now ); > >> printf("now tv_sec = %d, tv_nsec = %d\n", now.tv_sec, now.tv_nsec); > >> rtems_timespec_add_to(&timeout, &now); > >> printf("timeout tv_sec = %d, tv_nsec = %d\n", timeout.tv_sec, > timeout.tv_nsec); > > > > Please try with the appropriate type sizes and report back what you find. > > > > tv_sec is of type time_t > > tv_nsec is of type long > > > > %d will only take 32b of those values, so you get some kind of garbage > > (that can depend on endianness) > > > >> printf("The task is coming to enter in a timed wait\n"); > >> pthread_cond_timedwait(&cond, &mutex, &timeout); > >> printf("The task is coming out from the timed wait \n"); > >> return NULL; > >> } > >> > >> program output: > >> > >>

Enter in the main > >> Creating first task > >> : Hello World! task with max priority > >> now tv_sec = 4766459, tv_nsec = 567993600 > >> timeout tv_sec = 4766459, tv_nsec = 567993603 > >> The task is coming to enter in a timed wait > >> The task is coming out from the timed wait > >> First Task created > >> Creating second task > >> : Hello World! Task with lowest priority Second task created > >>

Out of the main > >> > >> If I now swap the arguments in the set-function , i.e. instead of > >> rtems_timespec_set(&timeout, 3, 0); > >> > >> rtems_timespec_set(&timeout, 0, 3); > >> > >> it looks as it should > >> > >> : Hello World! task with max priority > >> now tv_sec = 10766729, tv_nsec = 567993600 > >> timeout tv_sec = 10766732, tv_nsec = 567993600 > >> The task is coming to enter in a timed wait > >> The task is coming out from the timed wait > >> First Task created > >> Creating second task > >> : Hello World! Task with lowest priority Second task created > >>

Message-ID: <59BB30FA-CE8E-41CE-B2C3-0E738E7F9EE6@fhi-berlin.mpg.de> rtems-examples, master commit d5ba50c15c6bd188d4bb5921ae520e1066597ab1 (HEAD -> master, origin/master, origin/HEAD) Author: Vijay Kumar Banerjee Date: Fri Mar 26 14:44:30 2021 -0600 lvgl/wscript: Add libpath to search for required libraries Heinz > On 13. Apr 2021, at 15:09, Joel Sherrill wrote: > > > > On Tue, Apr 13, 2021 at 8:02 AM Heinz Junkes wrote: > Unfortunately I still do not understand it. Under Unix it runs perfectly and also the > values are displayed correctly. > > In the debugger, the contents of the structure timespec are displayed correctly. > > Another point that probably makes the program hang: > > the function pthread_cond_timedwait(&cond, &mutex, &timeout) returns "1" and does not wait for the timeout. > This return value should not exist at all? > > Under Unix, as expected, "110" is returned. ETIMOUT. > > What's your current version of the source? > > --joel > > Heinz > > > > On 12. Apr 2021, at 20:38, Gedare Bloom wrote: > > > > On Fri, Apr 9, 2021 at 11:45 AM Heinz Junkes wrote: > >> > >> Jiri, Joel, thanks for your answers. > >> > >> @Joel: I was wondering that rtems-examples in psx_example_3 does not wait 3 seconds. > >> > >> I made a curious observation: > >> > >> in the original code: > >> > >> clock_gettime( CLOCK_REALTIME, &timeout ); > >> timeout.tv_sec += 3; > >> timeout.tv_nsec = 0; > >> printf("The task is coming to enter in a timed wait\n"); > >> pthread_cond_timedwait(&cond, &mutex, &timeout); > >> > >> > >> I then inserted some printfs and found that the "3" is added to the nsec?s. > >> > >> Then I added the rtems-timespec-helpers routines, but get the same behavior: > >> > >> > >> void * print_hello(void * arg) > >> { > >> struct timespec now, timeout; > >> rtems_timespec_set(&timeout, 3, 0); > >> > >> printf(": Hello World! task with max priority \n"); > >> clock_gettime( CLOCK_REALTIME, &now ); > >> printf("now tv_sec = %d, tv_nsec = %d\n", now.tv_sec, now.tv_nsec); > >> rtems_timespec_add_to(&timeout, &now); > >> printf("timeout tv_sec = %d, tv_nsec = %d\n", timeout.tv_sec, timeout.tv_nsec); > > > > Please try with the appropriate type sizes and report back what you find. > > > > tv_sec is of type time_t > > tv_nsec is of type long > > > > %d will only take 32b of those values, so you get some kind of garbage > > (that can depend on endianness) > > > >> printf("The task is coming to enter in a timed wait\n"); > >> pthread_cond_timedwait(&cond, &mutex, &timeout); > >> printf("The task is coming out from the timed wait \n"); > >> return NULL; > >> } > >> > >> program output: > >> > >>

Out of the main > >> > >> But still no timed wait recognizable :-( > >> > >> Heinz > >> > >> > >> > >> _______________________________________________ > >> users mailing list > >> users at rtems.org > >> http://lists.rtems.org/mailman/listinfo/users > > _______________________________________________ > users mailing list > users at rtems.org > http://lists.rtems.org/mailman/listinfo/users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2542 bytes Desc: not available URL: From dauto98 at gmail.com Tue Apr 13 14:56:42 2021 From: dauto98 at gmail.com (=?UTF-8?B?xJDhu6ljIEFuaA==?=) Date: Tue, 13 Apr 2021 21:56:42 +0700 Subject: Write the BSP for ARM Versatile Express device Message-ID: Dear all, I want to develop a BSP for ARM Versatile Express platform. My final purpose is to run Gem5 simulation using RTEMS as the kernel. Now Gem5 only model Versatile Express device, and I can see RTEMS does not have a BSP for it yet. More specifically, the machine type modelled in Gem5 is: - Arm Motherboard Express uATX (V2M-P1) - The memory map is based on Versatile Express RS1, with RS2 extension - Arm CoreTile Express A15x2 (V2P-CA15) as daughterboard. It contains Cortex-A15 CPU. In the past, the Realview-pbx-a9 BSP used to run successfully in Gem5, when they still supported realview machine type. It is not the case now. So I guess I can reuse the CPU related code in realview-pbx-a9 and just write new code for the BSP ? I am new to RTEMS so I need some help. Which direction should I head for? Best regards, Duc Anh -------------- next part -------------- An HTML attachment was scrubbed... URL: From gedare at rtems.org Tue Apr 13 16:23:01 2021 From: gedare at rtems.org (Gedare Bloom) Date: Tue, 13 Apr 2021 10:23:01 -0600 Subject: SIS in "real time" In-Reply-To: References:

Message-ID: Hi Heinz, On Tue, Apr 13, 2021 at 7:02 AM Heinz Junkes wrote: > > Unfortunately I still do not understand it. Under Unix it runs perfectly and also the > values are displayed correctly. > #include [...] printf("now tv_sec = %" PRIuLEAST64 ", tv_nsec = %d\n", now.tv_sec, now.tv_nsec); [...] printf("timeout tv_sec = %" PRIuLEAST64 ", tv_nsec = %d\n", timeout.tv_sec, timeout.tv_nsec); What you observe is an artifact of 32-/64-bit integer conversions in a 32-bit big-endian architecture, I suspect. > In the debugger, the contents of the structure timespec are displayed correctly. > > Another point that probably makes the program hang: > > the function pthread_cond_timedwait(&cond, &mutex, &timeout) returns "1" and does not wait for the timeout. > This return value should not exist at all? > > Under Unix, as expected, "110" is returned. ETIMOUT. > > Heinz > > > > On 12. Apr 2021, at 20:38, Gedare Bloom wrote: > > > > On Fri, Apr 9, 2021 at 11:45 AM Heinz Junkes wrote: > >> > >> Jiri, Joel, thanks for your answers. > >> > >> @Joel: I was wondering that rtems-examples in psx_example_3 does not wait 3 seconds. > >> > >> I made a curious observation: > >> > >> in the original code: > >> > >> clock_gettime( CLOCK_REALTIME, &timeout ); > >> timeout.tv_sec += 3; > >> timeout.tv_nsec = 0; > >> printf("The task is coming to enter in a timed wait\n"); > >> pthread_cond_timedwait(&cond, &mutex, &timeout); > >> > >> > >> I then inserted some printfs and found that the "3" is added to the nsec?s. > >> > >> Then I added the rtems-timespec-helpers routines, but get the same behavior: > >> > >> > >> void * print_hello(void * arg) > >> { > >> struct timespec now, timeout; > >> rtems_timespec_set(&timeout, 3, 0); > >> > >> printf(": Hello World! task with max priority \n"); > >> clock_gettime( CLOCK_REALTIME, &now ); > >> printf("now tv_sec = %d, tv_nsec = %d\n", now.tv_sec, now.tv_nsec); > >> rtems_timespec_add_to(&timeout, &now); > >> printf("timeout tv_sec = %d, tv_nsec = %d\n", timeout.tv_sec, timeout.tv_nsec); > > > > Please try with the appropriate type sizes and report back what you find. > > > > tv_sec is of type time_t > > tv_nsec is of type long > > > > %d will only take 32b of those values, so you get some kind of garbage > > (that can depend on endianness) > > > >> printf("The task is coming to enter in a timed wait\n"); > >> pthread_cond_timedwait(&cond, &mutex, &timeout); > >> printf("The task is coming out from the timed wait \n"); > >> return NULL; > >> } > >> > >> program output: > >> > >>

Out of the main > >> > >> But still no timed wait recognizable :-( > >> > >> Heinz > >> > >> > >> > >> _______________________________________________ > >> users mailing list > >> users at rtems.org > >> http://lists.rtems.org/mailman/listinfo/users > From junkes at fhi-berlin.mpg.de Tue Apr 13 18:33:15 2021 From: junkes at fhi-berlin.mpg.de (Heinz Junkes) Date: Tue, 13 Apr 2021 20:33:15 +0200 Subject: SIS in "real time" In-Reply-To: References:

Message-ID: Identical behavior with xilinx-zynq-a9 (little - endian?). What frustrates me much more is the missing wait and the return value of pthread_cond_timedwait(&cond, &mutex, &timeout) and that also the join in main will never be reached. qemu-system-arm -M xilinx-zynq-a9 -m 256M -no-reboot -serial null -serial mon:stdio -nographic -rtc base=localtime,clock=host -kernel build/arm-rtems6-xilinx_zynq_a9_qemu/posix_api/psx_example_2/psx_example_2.exe

: Wait for child thread... timeval : seconds : 8068 micro seconds : 567993600 timespec seconds : 8068000 nano seconds : 567993610 : Hello World coming to wait! Error on pthread_cond_timedwait: Success With the format instructions you suggested, the output at least is ok: time tv_sec = 567993600, tv_usec = 4470 timeout tv_sec = 567993610, tv_nsec = 4470000 Danke, Heinz > On 13. Apr 2021, at 18:23, Gedare Bloom wrote: > > Hi Heinz, > > On Tue, Apr 13, 2021 at 7:02 AM Heinz Junkes wrote: >> >> Unfortunately I still do not understand it. Under Unix it runs perfectly and also the >> values are displayed correctly. >> > > #include > > [...] > printf("now tv_sec = %" PRIuLEAST64 ", tv_nsec = %d\n", now.tv_sec, > now.tv_nsec); > [...] > printf("timeout tv_sec = %" PRIuLEAST64 ", tv_nsec = %d\n", > timeout.tv_sec, timeout.tv_nsec); > > What you observe is an artifact of 32-/64-bit integer conversions in a > 32-bit big-endian architecture, I suspect. > >> In the debugger, the contents of the structure timespec are displayed correctly. >> >> Another point that probably makes the program hang: >> >> the function pthread_cond_timedwait(&cond, &mutex, &timeout) returns "1" and does not wait for the timeout. >> This return value should not exist at all? >> >> Under Unix, as expected, "110" is returned. ETIMOUT. >> >> Heinz >> >> >>> On 12. Apr 2021, at 20:38, Gedare Bloom wrote: >>> >>> On Fri, Apr 9, 2021 at 11:45 AM Heinz Junkes wrote: >>>> >>>> Jiri, Joel, thanks for your answers. >>>> >>>> @Joel: I was wondering that rtems-examples in psx_example_3 does not wait 3 seconds. >>>> >>>> I made a curious observation: >>>> >>>> in the original code: >>>> >>>> clock_gettime( CLOCK_REALTIME, &timeout ); >>>> timeout.tv_sec += 3; >>>> timeout.tv_nsec = 0; >>>> printf("The task is coming to enter in a timed wait\n"); >>>> pthread_cond_timedwait(&cond, &mutex, &timeout); >>>> >>>> >>>> I then inserted some printfs and found that the "3" is added to the nsec?s. >>>> >>>> Then I added the rtems-timespec-helpers routines, but get the same behavior: >>>> >>>> >>>> void * print_hello(void * arg) >>>> { >>>> struct timespec now, timeout; >>>> rtems_timespec_set(&timeout, 3, 0); >>>> >>>> printf(": Hello World! task with max priority \n"); >>>> clock_gettime( CLOCK_REALTIME, &now ); >>>> printf("now tv_sec = %d, tv_nsec = %d\n", now.tv_sec, now.tv_nsec); >>>> rtems_timespec_add_to(&timeout, &now); >>>> printf("timeout tv_sec = %d, tv_nsec = %d\n", timeout.tv_sec, timeout.tv_nsec); >>> >>> Please try with the appropriate type sizes and report back what you find. >>> >>> tv_sec is of type time_t >>> tv_nsec is of type long >>> >>> %d will only take 32b of those values, so you get some kind of garbage >>> (that can depend on endianness) >>> >>>> printf("The task is coming to enter in a timed wait\n"); >>>> pthread_cond_timedwait(&cond, &mutex, &timeout); >>>> printf("The task is coming out from the timed wait \n"); >>>> return NULL; >>>> } >>>> >>>> program output: >>>> >>>>

Enter in the main >>>> Creating first task >>>> : Hello World! task with max priority >>>> now tv_sec = 4766459, tv_nsec = 567993600 >>>> timeout tv_sec = 4766459, tv_nsec = 567993603 >>>> The task is coming to enter in a timed wait >>>> The task is coming out from the timed wait >>>> First Task created >>>> Creating second task >>>> : Hello World! Task with lowest priority Second task created >>>>

Out of the main >>>> >>>> If I now swap the arguments in the set-function , i.e. instead of >>>> rtems_timespec_set(&timeout, 3, 0); >>>> >>>> rtems_timespec_set(&timeout, 0, 3); >>>> >>>> it looks as it should >>>> >>>> : Hello World! task with max priority >>>> now tv_sec = 10766729, tv_nsec = 567993600 >>>> timeout tv_sec = 10766732, tv_nsec = 567993600 >>>> The task is coming to enter in a timed wait >>>> The task is coming out from the timed wait >>>> First Task created >>>> Creating second task >>>> : Hello World! Task with lowest priority Second task created >>>>

Out of the main >>>> >>>> But still no timed wait recognizable :-( >>>> >>>> Heinz >>>> >>>> >>>> >>>> _______________________________________________ >>>> users mailing list >>>> users at rtems.org >>>> http://lists.rtems.org/mailman/listinfo/users >> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2542 bytes Desc: not available URL: From gedare at rtems.org Wed Apr 14 05:52:56 2021 From: gedare at rtems.org (Gedare Bloom) Date: Tue, 13 Apr 2021 23:52:56 -0600 Subject: Write the BSP for ARM Versatile Express device In-Reply-To: References: Message-ID: Hi Duc, On Tue, Apr 13, 2021 at 8:57 AM ??c Anh wrote: > > Dear all, > > I want to develop a BSP for ARM Versatile Express platform. My final purpose is to run Gem5 simulation using RTEMS as the kernel. Now Gem5 only model Versatile Express device, and I can see RTEMS does not have a BSP for it yet. > > More specifically, the machine type modelled in Gem5 is: > - Arm Motherboard Express uATX (V2M-P1) > - The memory map is based on Versatile Express RS1, with RS2 extension > - Arm CoreTile Express A15x2 (V2P-CA15) as daughterboard. It contains Cortex-A15 CPU. > > In the past, the Realview-pbx-a9 BSP used to run successfully in Gem5, when they still supported realview machine type. It is not the case now. So I guess I can reuse the CPU related code in realview-pbx-a9 and just write new code for the BSP ? > Well, the realview pbx a9 is a cortex-a9 device and not an a15. Plus, I guess the vexpress will have some differences in how it deals with interrupts and maybe messaging given its tiled architecture? I don't know too much about it. But, your best bet is probably to try to start with the FVP bsp, which was only added about 5 months ago and supports just a Cortex-R52 right now, but probably adding the vexpress RS1 memory map with the V2P-CA15 is the right way for you to go. > I am new to RTEMS so I need some help. Which direction should I head for? > Join the devel at rtems.org mailing list for technical email discussions regarding hacking within RTEMS proper. (The "users" mailing list is a bit more for people trying to develop/maintain their application software using RTEMS mostly *fingers crossed* out of the box.) I would strongly recommend that you get started by following through our tutorials to get a feel for the tools and development environment: https://docs.rtems.org/branches/master/user/start/index.html Read carefully and don't skip steps, or you probably miss something important that you won't figure out until a couple hours later and have to redo everything. Since you plan new development, you should use the `master` branch of RTEMS with the `master` branch of the rtems-source-builder to build your cross-compiler toolchain. This is referred to as version '6' although it is not yet a released version. Right now we have a lot of new faces on devel@ because of the Google Summer of Code, so you'll find a lot of other people with questions and answers about how to get started etc. I would recommend you also do our GSoC Getting Started part of the tutorial so that you can get some comfort with the developer workflow and how to make changes in RTEMS and see them in the recompiled version. Finally, for new BSP development, I guess you can start by having a look at https://docs.rtems.org/branches/master/bsp-howto/index.html This is an aging document, but still a good resource to understand the basic ideas about BSP implementation. -Gedare > Best regards, > Duc Anh > _______________________________________________ > users mailing list > users at rtems.org > http://lists.rtems.org/mailman/listinfo/users