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 From pierre.ficheux at smile.fr Thu Apr 22 15:17:39 2021 From: pierre.ficheux at smile.fr (Pierre FICHEUX) Date: Thu, 22 Apr 2021 17:17:39 +0200 Subject: RTEMS on RISC-V Message-ID: Hi all, I've read several messages about running RTEMS on HiFive Unleashed board (with rv64imac/imafdc BSP ?). The board is currently discontinued so what is the best choice to test RTEMS on RISC-V (except QEMU) ? Thx by advance Regards -- Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.ficheux at smile.fr http://www.smile.fr https://smile.eu/fr/offres/embarque-iot I would love to change the world, but they won't give me the source code -------------- next part -------------- An HTML attachment was scrubbed... URL: From joel at rtems.org Thu Apr 22 15:43:26 2021 From: joel at rtems.org (Joel Sherrill) Date: Thu, 22 Apr 2021 10:43:26 -0500 Subject: RTEMS on RISC-V In-Reply-To: References: Message-ID: On Thu, Apr 22, 2021, 10:17 AM Pierre FICHEUX wrote: > Hi all, > > I've read several messages about running RTEMS on HiFive Unleashed board > (with rv64imac/imafdc BSP ?). The board is currently discontinued so what > is the best choice to test RTEMS on RISC-V (except QEMU) ? > I'm going to answer from the perspective of what I'd like to see supported. First Gaisler has the NOEL-V now and should have bit images for it for some popular fpga boards. You'd have to check on the technical details but this should work. There is a new HiFive board called Unmatched which would be nice to support. And there is a RISC-V Beagle now that also looks promising. I have no idea how much either of them would take to support. --joel > Thx by advance > > Regards > > -- > > Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.ficheux at smile.fr > http://www.smile.fr > https://smile.eu/fr/offres/embarque-iot > I would love to change the world, but they won't give me the source code > > _______________________________________________ > users mailing list > users at rtems.org > http://lists.rtems.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierre.ficheux at smile.fr Thu Apr 22 15:53:48 2021 From: pierre.ficheux at smile.fr (Pierre FICHEUX) Date: Thu, 22 Apr 2021 17:53:48 +0200 Subject: RTEMS on RISC-V In-Reply-To: References: Message-ID: Hi Joel, Thanks for your answer, so there is currently no RISC-V board supported by RTEMS (except HiFive Unleashed ) ? Le jeu. 22 avr. 2021 ? 17:43, Joel Sherrill a ?crit : > > > On Thu, Apr 22, 2021, 10:17 AM Pierre FICHEUX > wrote: > >> Hi all, >> >> I've read several messages about running RTEMS on HiFive Unleashed board >> (with rv64imac/imafdc BSP ?). The board is currently discontinued so what >> is the best choice to test RTEMS on RISC-V (except QEMU) ? >> > > I'm going to answer from the perspective of what I'd like to see supported. > > First Gaisler has the NOEL-V now and should have bit images for it for > some popular fpga boards. You'd have to check on the technical details but > this should work. > > There is a new HiFive board called Unmatched which would be nice to > support. And there is a RISC-V Beagle now that also looks promising. I have > no idea how much either of them would take to support. > > --joel > > > >> Thx by advance >> >> Regards >> >> -- >> >> Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.ficheux at smile.fr >> http://www.smile.fr >> https://smile.eu/fr/offres/embarque-iot >> I would love to change the world, but they won't give me the source code >> >> _______________________________________________ >> users mailing list >> users at rtems.org >> http://lists.rtems.org/mailman/listinfo/users > > -- Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.ficheux at smile.fr http://www.smile.fr https://smile.eu/fr/offres/embarque-iot I would love to change the world, but they won't give me the source code -------------- next part -------------- An HTML attachment was scrubbed... URL: From joel at rtems.org Thu Apr 22 16:00:02 2021 From: joel at rtems.org (Joel Sherrill) Date: Thu, 22 Apr 2021 11:00:02 -0500 Subject: RTEMS on RISC-V In-Reply-To: References: Message-ID: On Thu, Apr 22, 2021, 10:54 AM Pierre FICHEUX wrote: > Hi Joel, > > Thanks for your answer, so there is currently no RISC-V board supported by > RTEMS (except HiFive Unleashed ) ? > The NOEL-V is the only one I know. Not sure of the state of things for the Unleashed. > > Le jeu. 22 avr. 2021 ? 17:43, Joel Sherrill a ?crit : > >> >> >> On Thu, Apr 22, 2021, 10:17 AM Pierre FICHEUX >> wrote: >> >>> Hi all, >>> >>> I've read several messages about running RTEMS on HiFive Unleashed >>> board (with rv64imac/imafdc BSP ?). The board is currently discontinued so >>> what is the best choice to test RTEMS on RISC-V (except QEMU) ? >>> >> >> I'm going to answer from the perspective of what I'd like to see >> supported. >> >> First Gaisler has the NOEL-V now and should have bit images for it for >> some popular fpga boards. You'd have to check on the technical details but >> this should work. >> >> There is a new HiFive board called Unmatched which would be nice to >> support. And there is a RISC-V Beagle now that also looks promising. I have >> no idea how much either of them would take to support. >> >> --joel >> >> >> >>> Thx by advance >>> >>> Regards >>> >>> -- >>> >>> Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.ficheux at smile.fr >>> http://www.smile.fr >>> https://smile.eu/fr/offres/embarque-iot >>> I would love to change the world, but they won't give me the source code >>> >>> _______________________________________________ >>> users mailing list >>> users at rtems.org >>> http://lists.rtems.org/mailman/listinfo/users >> >> > > -- > > Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.ficheux at smile.fr > http://www.smile.fr > https://smile.eu/fr/offres/embarque-iot > I would love to change the world, but they won't give me the source code > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From heshamelmatary at gmail.com Thu Apr 22 16:44:05 2021 From: heshamelmatary at gmail.com (Hesham Almatary) Date: Thu, 22 Apr 2021 18:44:05 +0200 Subject: RTEMS on RISC-V In-Reply-To: References: Message-ID: There is also a BSP contributed by SiFive [1] to run on Freedom E310 Arty A7 FPGA. I am expecting a BeagleV board [2] as well and I'll work on porting RTEMS to it soon. [1] https://devel.rtems.org/ticket/3785 [2] https://beagleboard.org/beaglev On Thu, 22 Apr 2021 at 18:00, Joel Sherrill wrote: > > > > On Thu, Apr 22, 2021, 10:54 AM Pierre FICHEUX wrote: >> >> Hi Joel, >> >> Thanks for your answer, so there is currently no RISC-V board supported by RTEMS (except HiFive Unleashed ) ? > > > The NOEL-V is the only one I know. > > Not sure of the state of things for the Unleashed. >> >> >> Le jeu. 22 avr. 2021 ? 17:43, Joel Sherrill a ?crit : >>> >>> >>> >>> On Thu, Apr 22, 2021, 10:17 AM Pierre FICHEUX wrote: >>>> >>>> Hi all, >>>> >>>> I've read several messages about running RTEMS on HiFive Unleashed board (with rv64imac/imafdc BSP ?). The board is currently discontinued so what is the best choice to test RTEMS on RISC-V (except QEMU) ? >>> >>> >>> I'm going to answer from the perspective of what I'd like to see supported. >>> >>> First Gaisler has the NOEL-V now and should have bit images for it for some popular fpga boards. You'd have to check on the technical details but this should work. >>> >>> There is a new HiFive board called Unmatched which would be nice to support. And there is a RISC-V Beagle now that also looks promising. I have no idea how much either of them would take to support. >>> >>> --joel >>> >>> >>>> >>>> Thx by advance >>>> >>>> Regards >>>> >>>> -- >>>> >>>> Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.ficheux at smile.fr >>>> http://www.smile.fr >>>> https://smile.eu/fr/offres/embarque-iot >>>> I would love to change the world, but they won't give me the source code >>>> >>>> _______________________________________________ >>>> users mailing list >>>> users at rtems.org >>>> http://lists.rtems.org/mailman/listinfo/users >> >> >> >> -- >> >> Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.ficheux at smile.fr >> http://www.smile.fr >> https://smile.eu/fr/offres/embarque-iot >> I would love to change the world, but they won't give me the source code > > _______________________________________________ > users mailing list > users at rtems.org > http://lists.rtems.org/mailman/listinfo/users -- Hesham From someshdeshmukh07 at gmail.com Fri Apr 23 04:08:38 2021 From: someshdeshmukh07 at gmail.com (somesh deshmukh) Date: Fri, 23 Apr 2021 09:38:38 +0530 Subject: users Digest, Vol 175, Issue 9 In-Reply-To: References: Message-ID: Hi, I have successfully tested the RTEMS sample applications on PolarFire SoC ICICLE Kit. A little background about Polarfire SoC ICICLE Kit. The PolarFire SoC Icicle kit is a low-cost development platform that enables the evaluation of the five-core Linux capable RISC-V microprocessor subsystem. It includes - SiFive E51 Monitor core (1 x RV64IMAC) - SiFive U54 Application cores (4 x RV64GC) More info is available at the link below: https://www.microsemi.com/existing-parts/parts/152514 Regards, Somesh On Thu, Apr 22, 2021 at 9:30 PM wrote: > Send users mailing list submissions to > users at rtems.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.rtems.org/mailman/listinfo/users > or, via email, send a message with subject or body 'help' to > users-request at rtems.org > > You can reach the person managing the list at > users-owner at rtems.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of users digest..." > > > Today's Topics: > > 1. RTEMS on RISC-V (Pierre FICHEUX) > 2. Re: RTEMS on RISC-V (Joel Sherrill) > 3. Re: RTEMS on RISC-V (Pierre FICHEUX) > 4. Re: RTEMS on RISC-V (Joel Sherrill) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 22 Apr 2021 17:17:39 +0200 > From: Pierre FICHEUX > To: users at rtems.org > Subject: RTEMS on RISC-V > Message-ID: > < > CAFc1U0vv74ykw13LwqUzChb0sNefvLdje9b_VsUcgBxfxmP5Mg at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi all, > > I've read several messages about running RTEMS on HiFive Unleashed board > (with rv64imac/imafdc BSP ?). The board is currently discontinued so what > is the best choice to test RTEMS on RISC-V (except QEMU) ? > > Thx by advance > > Regards > > -- > > Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.ficheux at smile.fr > http://www.smile.fr > https://smile.eu/fr/offres/embarque-iot > I would love to change the world, but they won't give me the source code > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.rtems.org/pipermail/users/attachments/20210422/1d1912bf/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Thu, 22 Apr 2021 10:43:26 -0500 > From: Joel Sherrill > To: Pierre FICHEUX > Cc: "rtems-users at rtems.org" > Subject: Re: RTEMS on RISC-V > Message-ID: > R3LMow at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Thu, Apr 22, 2021, 10:17 AM Pierre FICHEUX > wrote: > > > Hi all, > > > > I've read several messages about running RTEMS on HiFive Unleashed board > > (with rv64imac/imafdc BSP ?). The board is currently discontinued so what > > is the best choice to test RTEMS on RISC-V (except QEMU) ? > > > > I'm going to answer from the perspective of what I'd like to see supported. > > First Gaisler has the NOEL-V now and should have bit images for it for some > popular fpga boards. You'd have to check on the technical details but this > should work. > > There is a new HiFive board called Unmatched which would be nice to > support. And there is a RISC-V Beagle now that also looks promising. I have > no idea how much either of them would take to support. > > --joel > > > > > Thx by advance > > > > Regards > > > > -- > > > > Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.ficheux at smile.fr > > http://www.smile.fr > > https://smile.eu/fr/offres/embarque-iot > > I would love to change the world, but they won't give me the source code > > > > _______________________________________________ > > users mailing list > > users at rtems.org > > http://lists.rtems.org/mailman/listinfo/users > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.rtems.org/pipermail/users/attachments/20210422/e51a4fad/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Thu, 22 Apr 2021 17:53:48 +0200 > From: Pierre FICHEUX > To: joel at rtems.org > Cc: "rtems-users at rtems.org" > Subject: Re: RTEMS on RISC-V > Message-ID: > < > CAFc1U0sd5s0R8BmfXvcim+DhWG8K2m6gaSXaj464LN7X933DaA at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Joel, > > Thanks for your answer, so there is currently no RISC-V board supported by > RTEMS (except HiFive Unleashed ) ? > > Le jeu. 22 avr. 2021 ? 17:43, Joel Sherrill a ?crit : > > > > > > > On Thu, Apr 22, 2021, 10:17 AM Pierre FICHEUX > > wrote: > > > >> Hi all, > >> > >> I've read several messages about running RTEMS on HiFive Unleashed > board > >> (with rv64imac/imafdc BSP ?). The board is currently discontinued so > what > >> is the best choice to test RTEMS on RISC-V (except QEMU) ? > >> > > > > I'm going to answer from the perspective of what I'd like to see > supported. > > > > First Gaisler has the NOEL-V now and should have bit images for it for > > some popular fpga boards. You'd have to check on the technical details > but > > this should work. > > > > There is a new HiFive board called Unmatched which would be nice to > > support. And there is a RISC-V Beagle now that also looks promising. I > have > > no idea how much either of them would take to support. > > > > --joel > > > > > > > >> Thx by advance > >> > >> Regards > >> > >> -- > >> > >> Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.ficheux at smile.fr > >> http://www.smile.fr > >> https://smile.eu/fr/offres/embarque-iot > >> I would love to change the world, but they won't give me the source code > >> > >> _______________________________________________ > >> users mailing list > >> users at rtems.org > >> http://lists.rtems.org/mailman/listinfo/users > > > > > > -- > > Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.ficheux at smile.fr > http://www.smile.fr > https://smile.eu/fr/offres/embarque-iot > I would love to change the world, but they won't give me the source code > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.rtems.org/pipermail/users/attachments/20210422/ce36c687/attachment-0001.html > > > > ------------------------------ > > Message: 4 > Date: Thu, 22 Apr 2021 11:00:02 -0500 > From: Joel Sherrill > To: Pierre FICHEUX > Cc: "rtems-users at rtems.org" > Subject: Re: RTEMS on RISC-V > Message-ID: > y_2Q at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Thu, Apr 22, 2021, 10:54 AM Pierre FICHEUX > wrote: > > > Hi Joel, > > > > Thanks for your answer, so there is currently no RISC-V board supported > by > > RTEMS (except HiFive Unleashed ) ? > > > > The NOEL-V is the only one I know. > > Not sure of the state of things for the Unleashed. > > > > > Le jeu. 22 avr. 2021 ? 17:43, Joel Sherrill a ?crit : > > > >> > >> > >> On Thu, Apr 22, 2021, 10:17 AM Pierre FICHEUX > >> wrote: > >> > >>> Hi all, > >>> > >>> I've read several messages about running RTEMS on HiFive Unleashed > >>> board (with rv64imac/imafdc BSP ?). The board is currently > discontinued so > >>> what is the best choice to test RTEMS on RISC-V (except QEMU) ? > >>> > >> > >> I'm going to answer from the perspective of what I'd like to see > >> supported. > >> > >> First Gaisler has the NOEL-V now and should have bit images for it for > >> some popular fpga boards. You'd have to check on the technical details > but > >> this should work. > >> > >> There is a new HiFive board called Unmatched which would be nice to > >> support. And there is a RISC-V Beagle now that also looks promising. I > have > >> no idea how much either of them would take to support. > >> > >> --joel > >> > >> > >> > >>> Thx by advance > >>> > >>> Regards > >>> > >>> -- > >>> > >>> Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.ficheux at smile.fr > >>> http://www.smile.fr > >>> https://smile.eu/fr/offres/embarque-iot > >>> I would love to change the world, but they won't give me the source > code > >>> > >>> _______________________________________________ > >>> users mailing list > >>> users at rtems.org > >>> http://lists.rtems.org/mailman/listinfo/users > >> > >> > > > > -- > > > > Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.ficheux at smile.fr > > http://www.smile.fr > > https://smile.eu/fr/offres/embarque-iot > > I would love to change the world, but they won't give me the source code > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.rtems.org/pipermail/users/attachments/20210422/0c2c84db/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > users mailing list > users at rtems.org > http://lists.rtems.org/mailman/listinfo/users > > ------------------------------ > > End of users Digest, Vol 175, Issue 9 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierre.ficheux at smile.fr Fri Apr 23 08:16:55 2021 From: pierre.ficheux at smile.fr (Pierre FICHEUX) Date: Fri, 23 Apr 2021 10:16:55 +0200 Subject: RTEMS on RISC-V In-Reply-To: References:

Message-ID: One RTEMS user talked to me about SiFive FE310 boards. https://www.elektor.com/sparkfun-red-v-redboard-sifive-risc-v-fe310-soc https://www.berrybase.de/fr/dev.-boards/sparkfun-thing/sparkfun-red-v-thing-plus-sifive-risc-v-fe310-soc I will try it, very cheap. regards Le jeu. 22 avr. 2021 ? 18:44, Hesham Almatary a ?crit : > There is also a BSP contributed by SiFive [1] to run on Freedom E310 > Arty A7 FPGA. > > I am expecting a BeagleV board [2] as well and I'll work on porting > RTEMS to it soon. > > > [1] https://devel.rtems.org/ticket/3785 > [2] https://beagleboard.org/beaglev > > On Thu, 22 Apr 2021 at 18:00, Joel Sherrill wrote: > > > > > > > > On Thu, Apr 22, 2021, 10:54 AM Pierre FICHEUX > wrote: > >> > >> Hi Joel, > >> > >> Thanks for your answer, so there is currently no RISC-V board supported > by RTEMS (except HiFive Unleashed ) ? > > > > > > The NOEL-V is the only one I know. > > > > Not sure of the state of things for the Unleashed. > >> > >> > >> Le jeu. 22 avr. 2021 ? 17:43, Joel Sherrill a ?crit : > >>> > >>> > >>> > >>> On Thu, Apr 22, 2021, 10:17 AM Pierre FICHEUX > wrote: > >>>> > >>>> Hi all, > >>>> > >>>> I've read several messages about running RTEMS on HiFive Unleashed > board (with rv64imac/imafdc BSP ?). The board is currently discontinued so > what is the best choice to test RTEMS on RISC-V (except QEMU) ? > >>> > >>> > >>> I'm going to answer from the perspective of what I'd like to see > supported. > >>> > >>> First Gaisler has the NOEL-V now and should have bit images for it for > some popular fpga boards. You'd have to check on the technical details but > this should work. > >>> > >>> There is a new HiFive board called Unmatched which would be nice to > support. And there is a RISC-V Beagle now that also looks promising. I have > no idea how much either of them would take to support. > >>> > >>> --joel > >>> > >>> > >>>> > >>>> Thx by advance > >>>> > >>>> Regards > >>>> > >>>> -- > >>>> > >>>> Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.ficheux at smile.fr > >>>> http://www.smile.fr > >>>> https://smile.eu/fr/offres/embarque-iot > >>>> I would love to change the world, but they won't give me the source > code > >>>> > >>>> _______________________________________________ > >>>> users mailing list > >>>> users at rtems.org > >>>> http://lists.rtems.org/mailman/listinfo/users > >> > >> > >> > >> -- > >> > >> Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.ficheux at smile.fr > >> http://www.smile.fr > >> https://smile.eu/fr/offres/embarque-iot > >> I would love to change the world, but they won't give me the source code > > > > _______________________________________________ > > users mailing list > > users at rtems.org > > http://lists.rtems.org/mailman/listinfo/users > > -- > Hesham > -- Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.ficheux at smile.fr http://www.smile.fr https://smile.eu/fr/offres/embarque-iot I would love to change the world, but they won't give me the source code -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andre.Nahrwold at dlr.de Fri Apr 23 13:29:40 2021 From: Andre.Nahrwold at dlr.de (Andre.Nahrwold at dlr.de) Date: Fri, 23 Apr 2021 13:29:40 +0000 Subject: Spidev different ioctl structure Message-ID: Hello, I discovered that the Spidev include (linux/spi/spidev.h) contains different implementations of the ioctl structure when comparing rtems and linux. I used the mode value of the structure and wanted to compile the application for rtems and linux, that is where I got some errors. A few further value names differ also: cs, word_delay_usecs, pad. Does anybody now why there is this difference? Or is it not necessary to use the mode value for the ioctl commands? On rtems it looks like this: struct spi_ioc_transfer { void *rx_buf; const void *tx_buf; size_t len; uint32_t speed_hz; uint16_t delay_usecs; uint8_t bits_per_word; uint8_t cs_change; uint8_t rx_nbits; uint8_t tx_nbits; uint32_t mode; uint8_t cs; }; On linux it looks like this: struct spi_ioc_transfer { __u64 tx_buf; __u64 rx_buf; __u32 len; __u32 speed_hz; __u16 delay_usecs; __u8 bits_per_word; __u8 cs_change; __u8 tx_nbits; __u8 rx_nbits; __u8 word_delay_usecs; __u8 pad; }; Best regards Andre Nahrwold -------------------------- Deutsches Zentrum f?r Luft- und Raumfahrt e. V. (DLR) German Aerospace Center Institute for Software Technolog | SRV-OSS BS | Lilienthalpl. 7 | 38108 Braunschweig | Geb. 112C Raum 001 M.Sc. Andre Nahrwold | Telephone +49 531 295-3834 | andre.nahrwold at dlr.de DLR.de From wangqiang3 at sugon.com Sat Apr 24 09:25:50 2021 From: wangqiang3 at sugon.com (wangqiang3 at sugon.com) Date: Sat, 24 Apr 2021 17:25:50 +0800 Subject: Question on rtems epoch time Message-ID: Hi: I have a question is that why rtems's epoch base year is 1988(#define TOD_BASE_YEAR 1988)? I change TOD_BASE_YEAR to 1970 and TOD_SECONDS_1970_THROUGH_1988 to 0,such as: It work well. So I wonder is that a good method? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 35006 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 11470 bytes Desc: not available URL: From joel at rtems.org Sat Apr 24 17:35:52 2021 From: joel at rtems.org (Joel Sherrill) Date: Sat, 24 Apr 2021 12:35:52 -0500 Subject: Question on rtems epoch time In-Reply-To: References: Message-ID: On Sat, Apr 24, 2021, 4:26 AM wrote: > Hi: > > I have a question is that why rtems's epoch base year is 1988(#define > TOD_BASE_YEAR 1988)? > I change TOD_BASE_YEAR to 1970 and TOD_SECONDS_1970_THROUGH_1988 to 0,such > as: > > > It work well. So I wonder is that a good method? RTEMS development started in 1988 and it was for the Classic API only. Using 1988 as the base year gave us a leap year as epoch and dividing by four worked for a long time to determine leap years. Over the years, the score has moved to POSIX time and the 1988 restriction could be enforced not at the score level but at the classic level. > > > > > Thanks! _______________________________________________ > 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: noname Type: image/gif Size: 35006 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: noname Type: image/gif Size: 11470 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: noname Type: image/gif Size: 35006 bytes Desc: not available URL: From pierre.ficheux at smile.fr Sun Apr 25 14:31:37 2021 From: pierre.ficheux at smile.fr (Pierre FICHEUX) Date: Sun, 25 Apr 2021 16:31:37 +0200 Subject: Announce: RTEMS 5.1 Release In-Reply-To: References:

Message-ID: Hi, Back to RTEMS for a (future) project, I try to use some RTEMS BSPs, including Raspberry Pi (1 B+). It worked fine some years ago with 4.11 (Thx to Alan !), then version 5 was OK too (tested in 2018) but when I try with an official 5.1 (tar.xz) I have no display on Pi 1 B+ console. Host PC is Ubuntu 18.04 LTS, I use branch 5.1 for rtems-source-builder. Is Raspberry Pi 1 B+ BSP OK for RTEMS 5.1 ? Thx by advance Regards Le ven. 28 ao?t 2020 ? 23:13, Alan Cudmore a ?crit : > Hello Chris, > Thanks to you and the RTEMS developers for creating this release! > I am testing your release packages. So far I have tried the following: > 1. Built tools for SPARC, ARM, and i386 on an Ubuntu 18.04 LTS host. > 2. Built the BSP for Beaglebone Black and the corresponding LibBSD > 3. Built the SPARC LEON3 BSP > 4. I have tested a few of my applications, and am working on getting > the latest core Flight System (cFS) bundle working on RTEMS 5.1 for > both the LEON 3/QEMU and Beaglebone Black. Ethernet is working for the > beagle. > > I have not tested the Raspberry Pi models yet, but I expect to do that > soon! > > I'm also working on updating my docker images for 5.1. I have a tagged > branch, but still need to test those images: > https://github.com/alanc98/rtems-release-docker > Documentation is about half complete for that project. > > Thanks again, > Alan > > On Tue, Aug 25, 2020 at 9:53 PM Chris Johns wrote: > > > > The RTEMS 5.1 Release is available. The release can be found at: > > > > https://ftp.rtems.org/pub/rtems/releases/5/5.1 > > > > Please follow the release instructions provided by the link. > > > > The RTEMS 5 release is a significant milestone for the RTEMS project > with many > > years of effort from many people as we continue to improve RTEMS's > features, > > capabilities and performance while maintaining our stability. > > > > We love to hear about your projects and what you use RTEMS on so please > let us > > know. You can post on user at rtems.org or you can send Joel or me a > private email. > > > > If you find a problem please raise a ticket and select the 5.2 > milestone. The > > simplest way to create a ticket is to head to the developer Wiki at: > > > > https://devel.rtems.org/ > > > > Then click on the "Next (milestone)" link for the RTEMS 5 Release. You > will need > > an account. > > > > Thanks to everyone who has contributed to the release over the past few > years. > > This is a community project and without the support of the community we > would > > not be able to make these quality releases. > > > > Thanks > > Chris > > > > ps: Happy birthday Dad! > > _______________________________________________ > > 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 > -- Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.ficheux at smile.fr http://www.smile.fr https://smile.eu/fr/offres/embarque-iot I would love to change the world, but they won't give me the source code -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierre.ficheux at smile.fr Mon Apr 26 06:47:50 2021 From: pierre.ficheux at smile.fr (Pierre FICHEUX) Date: Mon, 26 Apr 2021 08:47:50 +0200 Subject: RTEMS Discord Server Available In-Reply-To: References: Message-ID: Hi Joel, Looks like the link is outdated, is there a way to join the RTEMS community on Discord? Thx Le mar. 23 mars 2021 ? 21:49, Joel Sherrill a ?crit : > Hi > > RTEMS now has a Discord server (https://discord.gg/6SrpDfBF). > > Feel free to drop by and chat. > > --joel > _______________________________________________ > users mailing list > users at rtems.org > http://lists.rtems.org/mailman/listinfo/users -- Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.ficheux at smile.fr http://www.smile.fr https://smile.eu/fr/offres/embarque-iot I would love to change the world, but they won't give me the source code -------------- next part -------------- An HTML attachment was scrubbed... URL: From eshandhawan51 at gmail.com Mon Apr 26 06:56:52 2021 From: eshandhawan51 at gmail.com (Eshan Dhawan) Date: Mon, 26 Apr 2021 12:26:52 +0530 Subject: RTEMS Discord Server Available In-Reply-To: References: Message-ID: Hi Maybe this should help Link : https://discord.gg/vgXyBEc8 Thanks - Eshan > On 26-Apr-2021, at 12:18 PM, Pierre FICHEUX wrote: > > ? > Hi Joel, > > Looks like the link is outdated, is there a way to join the RTEMS community on Discord? > > Thx > > >> Le mar. 23 mars 2021 ? 21:49, Joel Sherrill a ?crit : >> Hi >> >> RTEMS now has a Discord server (https://discord.gg/6SrpDfBF). >> >> Feel free to drop by and chat. >> >> --joel >> _______________________________________________ >> users mailing list >> users at rtems.org >> http://lists.rtems.org/mailman/listinfo/users > > > -- > Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.ficheux at smile.fr > http://www.smile.fr > https://smile.eu/fr/offres/embarque-iot > I would love to change the world, but they won't give me the source code > _______________________________________________ > users mailing list > users at rtems.org > http://lists.rtems.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierre.ficheux at smile.fr Mon Apr 26 07:02:55 2021 From: pierre.ficheux at smile.fr (Pierre FICHEUX) Date: Mon, 26 Apr 2021 09:02:55 +0200 Subject: RTEMS Discord Server Available In-Reply-To: References:

Message-ID: Thx a lot, it works. Le lun. 26 avr. 2021 ? 08:56, Eshan Dhawan a ?crit : > Hi > Maybe this should help > Link : https://discord.gg/vgXyBEc8 > > Thanks > - Eshan > > On 26-Apr-2021, at 12:18 PM, Pierre FICHEUX > wrote: > > ? > Hi Joel, > > Looks like the link is outdated, is there a way to join the RTEMS > community on Discord? > > Thx > > > Le mar. 23 mars 2021 ? 21:49, Joel Sherrill a ?crit : > >> Hi >> >> RTEMS now has a Discord server (https://discord.gg/6SrpDfBF). >> >> Feel free to drop by and chat. >> >> --joel >> _______________________________________________ >> users mailing list >> users at rtems.org >> http://lists.rtems.org/mailman/listinfo/users > > > > -- > > Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.ficheux at smile.fr > http://www.smile.fr > https://smile.eu/fr/offres/embarque-iot > I would love to change the world, but they won't give me the source code > > _______________________________________________ > users mailing list > users at rtems.org > http://lists.rtems.org/mailman/listinfo/users > > -- Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.ficheux at smile.fr http://www.smile.fr https://smile.eu/fr/offres/embarque-iot I would love to change the world, but they won't give me the source code -------------- next part -------------- An HTML attachment was scrubbed... URL: From Goetz.Pfeiffer at helmholtz-berlin.de Mon Apr 26 08:21:19 2021 From: Goetz.Pfeiffer at helmholtz-berlin.de (Goetz Pfeiffer) Date: Mon, 26 Apr 2021 10:21:19 +0200 Subject: rsb (RTEMS source Builder) support for local mirrors ? Message-ID: Hello, I have used rsb to build my local cross compiler toolchain for RTEMS. This is a great tool, but it downloads all sources from some internet servers. The problem is that servers may be down at the time I need them or that the locations of some files have changed and rsb doesn't know about this. Would it be possible to change rsb in a way that it has an option to download all needed files from a local mirror ? In my case I would need this feature not just for version 5 of RTEMS but also for version 4.9 and 4.10. Greetings ? Goetz Pfeiffer (control system engineer, Helmholtz-Zentrum Berlin) -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From pierre.ficheux at smile.fr Mon Apr 26 11:49:26 2021 From: pierre.ficheux at smile.fr (Pierre FICHEUX) Date: Mon, 26 Apr 2021 13:49:26 +0200 Subject: rtems-bootstrap failed on master Message-ID: Hi, When using rtems-bootstrap on master branch of rtems, I got "automake: error: cannot open < libnetworking/headers.am: No such file or directory" autoreconf: automake failed with exit status: 1 13/119: autoreconf: testsuites/samples/configure.ac 14/119: autoreconf: testsuites/smptests/configure.ac 15/119: autoreconf: testsuites/rhealstone/configure.ac 16/119: autoreconf: c/configure.ac error: error: autoreconf: autoreconf -i --no-recursive Bootstrap FAILED I use automake/autoconf from RTEMS (not from Ubuntu). Any idea? thx -- Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.ficheux at smile.fr http://www.smile.fr https://smile.eu/fr/offres/embarque-iot I would love to change the world, but they won't give me the source code -------------- next part -------------- An HTML attachment was scrubbed... URL: From richidubey at gmail.com Mon Apr 26 11:51:55 2021 From: richidubey at gmail.com (Richi Dubey) Date: Mon, 26 Apr 2021 17:21:55 +0530 Subject: rtems-bootstrap failed on master In-Reply-To: References: Message-ID: https://lists.rtems.org/pipermail/devel/2021-April/066817.html :p On Mon, Apr 26, 2021 at 5:19 PM Pierre FICHEUX wrote: > Hi, > > When using rtems-bootstrap on master branch of rtems, I got "automake: > error: cannot open < libnetworking/headers.am: No such file or directory" > autoreconf: automake failed with exit status: 1 > 13/119: autoreconf: testsuites/samples/configure.ac > 14/119: autoreconf: testsuites/smptests/configure.ac > 15/119: autoreconf: testsuites/rhealstone/configure.ac > 16/119: autoreconf: c/configure.ac > error: error: autoreconf: autoreconf -i --no-recursive > Bootstrap FAILED > > I use automake/autoconf from RTEMS (not from Ubuntu). Any idea? > > thx > -- > > Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.ficheux at smile.fr > http://www.smile.fr > https://smile.eu/fr/offres/embarque-iot > I would love to change the world, but they won't give me the source code > > _______________________________________________ > users mailing list > users at rtems.org > http://lists.rtems.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From joel at rtems.org Mon Apr 26 12:35:12 2021 From: joel at rtems.org (Joel Sherrill) Date: Mon, 26 Apr 2021 07:35:12 -0500 Subject: RTEMS Discord Server Available In-Reply-To: References:

Message-ID: I generated a permanent link and made it available via the left hand side of rtems.org's top page. I'm still learning Discord. Thanks. --joel On Mon, Apr 26, 2021 at 2:03 AM Pierre FICHEUX wrote: > Thx a lot, it works. > > Le lun. 26 avr. 2021 ? 08:56, Eshan Dhawan a > ?crit : > >> Hi >> Maybe this should help >> Link : https://discord.gg/vgXyBEc8 >> >> Thanks >> - Eshan >> >> On 26-Apr-2021, at 12:18 PM, Pierre FICHEUX >> wrote: >> >> ? >> Hi Joel, >> >> Looks like the link is outdated, is there a way to join the RTEMS >> community on Discord? >> >> Thx >> >> >> Le mar. 23 mars 2021 ? 21:49, Joel Sherrill a ?crit : >> >>> Hi >>> >>> RTEMS now has a Discord server (https://discord.gg/6SrpDfBF). >>> >>> Feel free to drop by and chat. >>> >>> --joel >>> _______________________________________________ >>> users mailing list >>> users at rtems.org >>> http://lists.rtems.org/mailman/listinfo/users >> >> >> >> -- >> >> Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.ficheux at smile.fr >> http://www.smile.fr >> https://smile.eu/fr/offres/embarque-iot >> I would love to change the world, but they won't give me the source code >> >> _______________________________________________ >> users mailing list >> users at rtems.org >> http://lists.rtems.org/mailman/listinfo/users >> >> > > -- > > Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.ficheux at smile.fr > http://www.smile.fr > https://smile.eu/fr/offres/embarque-iot > I would love to change the world, but they won't give me the source code > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierre.ficheux at smile.fr Mon Apr 26 12:55:00 2021 From: pierre.ficheux at smile.fr (Pierre FICHEUX) Date: Mon, 26 Apr 2021 14:55:00 +0200 Subject: rtems-bootstrap failed on master In-Reply-To: References: Message-ID: Thx a lot, it works fine. regards Le lun. 26 avr. 2021 ? 13:52, Richi Dubey a ?crit : > https://lists.rtems.org/pipermail/devel/2021-April/066817.html :p > > On Mon, Apr 26, 2021 at 5:19 PM Pierre FICHEUX > wrote: > >> Hi, >> >> When using rtems-bootstrap on master branch of rtems, I got "automake: >> error: cannot open < libnetworking/headers.am: No such file or directory" >> autoreconf: automake failed with exit status: 1 >> 13/119: autoreconf: testsuites/samples/configure.ac >> 14/119: autoreconf: testsuites/smptests/configure.ac >> 15/119: autoreconf: testsuites/rhealstone/configure.ac >> 16/119: autoreconf: c/configure.ac >> error: error: autoreconf: autoreconf -i --no-recursive >> Bootstrap FAILED >> >> I use automake/autoconf from RTEMS (not from Ubuntu). Any idea? >> >> thx >> -- >> >> Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.ficheux at smile.fr >> http://www.smile.fr >> https://smile.eu/fr/offres/embarque-iot >> I would love to change the world, but they won't give me the source code >> >> _______________________________________________ >> users mailing list >> users at rtems.org >> http://lists.rtems.org/mailman/listinfo/users > > -- Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.ficheux at smile.fr http://www.smile.fr https://smile.eu/fr/offres/embarque-iot I would love to change the world, but they won't give me the source code -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierre.ficheux at smile.fr Mon Apr 26 12:55:45 2021 From: pierre.ficheux at smile.fr (Pierre FICHEUX) Date: Mon, 26 Apr 2021 14:55:45 +0200 Subject: RTEMS Discord Server Available In-Reply-To: References:

Message-ID: Same for me, looks like IRC for young people :-) Le lun. 26 avr. 2021 ? 14:35, Joel Sherrill a ?crit : > I generated a permanent link and made it available via the left hand side > of rtems.org's top page. > > I'm still learning Discord. > > Thanks. > > --joel > > On Mon, Apr 26, 2021 at 2:03 AM Pierre FICHEUX > wrote: > >> Thx a lot, it works. >> >> Le lun. 26 avr. 2021 ? 08:56, Eshan Dhawan a >> ?crit : >> >>> Hi >>> Maybe this should help >>> Link : https://discord.gg/vgXyBEc8 >>> >>> Thanks >>> - Eshan >>> >>> On 26-Apr-2021, at 12:18 PM, Pierre FICHEUX >>> wrote: >>> >>> ? >>> Hi Joel, >>> >>> Looks like the link is outdated, is there a way to join the RTEMS >>> community on Discord? >>> >>> Thx >>> >>> >>> Le mar. 23 mars 2021 ? 21:49, Joel Sherrill a ?crit : >>> >>>> Hi >>>> >>>> RTEMS now has a Discord server (https://discord.gg/6SrpDfBF). >>>> >>>> Feel free to drop by and chat. >>>> >>>> --joel >>>> _______________________________________________ >>>> users mailing list >>>> users at rtems.org >>>> http://lists.rtems.org/mailman/listinfo/users >>> >>> >>> >>> -- >>> >>> Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.ficheux at smile.fr >>> http://www.smile.fr >>> https://smile.eu/fr/offres/embarque-iot >>> I would love to change the world, but they won't give me the source code >>> >>> _______________________________________________ >>> users mailing list >>> users at rtems.org >>> http://lists.rtems.org/mailman/listinfo/users >>> >>> >> >> -- >> >> Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.ficheux at smile.fr >> http://www.smile.fr >> https://smile.eu/fr/offres/embarque-iot >> I would love to change the world, but they won't give me the source code >> >> -- Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.ficheux at smile.fr http://www.smile.fr https://smile.eu/fr/offres/embarque-iot I would love to change the world, but they won't give me the source code -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdavidsaver at gmail.com Mon Apr 26 18:07:57 2021 From: mdavidsaver at gmail.com (Michael Davidsaver) Date: Mon, 26 Apr 2021 11:07:57 -0700 Subject: rsb (RTEMS source Builder) support for local mirrors ? In-Reply-To: References: Message-ID: On 4/26/21 1:21 AM, Goetz Pfeiffer wrote: > Hello, > > I have used rsb to build my local cross compiler toolchain for RTEMS. > > This is a great tool, but it downloads all sources from some internet servers. The problem is > that servers may be down at the time I need them or that the locations of some files have changed > and rsb doesn't know about this. > > Would it be possible to change rsb in a way that it has an option to download all needed files from a > local mirror ? I've had some success with running the RSB recipes twice. First with '--source-only-download', and then again with '--no-download'. The second time uses previously downloaded files, and can be run on a offline host. > In my case I would need this feature not just for version 5 of RTEMS but also for version > 4.9 and 4.10. > > Greetings > > ? Goetz Pfeiffer (control system engineer, Helmholtz-Zentrum Berlin) > > > > _______________________________________________ > users mailing list > users at rtems.org > http://lists.rtems.org/mailman/listinfo/users > From groups at chichak.ca Mon Apr 26 21:59:56 2021 From: groups at chichak.ca (groups at chichak.ca) Date: Mon, 26 Apr 2021 15:59:56 -0600 Subject: Segmentation fault 11 issue with gdb Message-ID: <5FC426F8-EEF7-41FB-98ED-5355E310180C@chichak.ca> In my ongoing quest to bring up libbsd, I ran into an issue with gdb as built for RTEMS5. gdb 9.1 immediately gives a segmentation fault 11 as it has a fight with python3 version 3.9.2. I managed to find a good explanation of the problem at https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=c47bae859a5af0d95224d90000df0e529f7c5aa0 So I managed to trick the RTEMS5 installer into building with gdb 9.2 and it had exactly the same problem. The problem report, above, was generated a couple of days after 9.2 was released, so the problem should have existed there too. I then persuaded the installer to grab 10.1 and the issue was gone. Yay. 10.1 also worked adequately with eclipse and OpenODC (yuck). I just noticed that gdb 10.2 was released today. I have not tried it yet. That is all, Andrei (from The Great White North) From chrisj at rtems.org Tue Apr 27 03:14:40 2021 From: chrisj at rtems.org (Chris Johns) Date: Tue, 27 Apr 2021 13:14:40 +1000 Subject: rsb (RTEMS source Builder) support for local mirrors ? In-Reply-To: References:

Message-ID: <432ec6dd-02b6-4954-f12e-89bb854a1066@rtems.org> On 27/4/21 4:07 am, Michael Davidsaver wrote: > On 4/26/21 1:21 AM, Goetz Pfeiffer wrote: >> Hello, >> >> I have used rsb to build my local cross compiler toolchain for RTEMS. >> >> This is a great tool, but it downloads all sources from some internet servers. The problem is >> that servers may be down at the time I need them or that the locations of some files have changed >> and rsb doesn't know about this. >> >> Would it be possible to change rsb in a way that it has an option to download all needed files from a >> local mirror ? > > I've had some success with running the RSB recipes twice. First with '--source-only-download', > and then again with '--no-download'. The second time uses previously downloaded files, > and can be run on a offline host. Does the `--url` option work? It should point you to a local server. A better or more complete way to handle tools is to "deploy" them. Deployed tools lets you add a version label into the tools that can be seen with the standard version option the tools come with. There is a real benefit to having a special label in the version for deployed tool sets especially binary packages. Unfortunately I have not had the time to document how to do this so here is a brief untested procedure. It is pretty much what the release procedure does: 1. Clone or download the RSB source. 2. Add or edit a VERSION file in the top level of the RSB source. The 5.1 release tarball of the RSB has a version file. 3. Run the `sb-get-sources` command to fetch all the source and patches. 4. Package the RSB, source and patches. Notes: a) The format for the VERSION file is documented here: https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/version.py#n31 b) The release process creates the VERSION file here: https://git.rtems.org/rtems-release/tree/rtems-release-rsb-version c) The get sources command is better than the download options because it downloads all patches for all archs and all hosts. This is a requirement for releasing. d) Released sources contain a released RTEMS kernel and RTEMS Tools and this requires special management of the checksum the RSB uses when building from a source package. The hashes for these packages are placed in the VERSION file. The 5.1 release shows how this is done. e) A simple and clean way to deploy ... clone the release scripts and run them :) Joel has patches for Linux he is yet to post so pester him if you would like to follow this path. The release scripts handle the release path for downloading and special release labels. The release procedure is open and available for just this purpose. >> In my case I would need this feature not just for version 5 of RTEMS but also for version >> 4.9 and 4.10. RTEMS 4.9, 4.10, and 4.11 would need some work to bring it inline with 5 to support deployment. That work would need to be funded so if this is something you need please contact me off list. Chris From Jan.Sommer at dlr.de Thu Apr 29 11:43:51 2021 From: Jan.Sommer at dlr.de (Jan.Sommer at dlr.de) Date: Thu, 29 Apr 2021 11:43:51 +0000 Subject: libbsd: React to link status change events Message-ID: <5e1a480f310640ecbb03353187a6fea5@dlr.de> Hello, is there an easy way to register a callback function or block until a link status change of an Ethernet device occurs in the libbsd stack? Searching for it, I found some references for EV_NETDEV in kqueue, but this seems to be a legacy function which has been removed years ago. In the console of the Zedboard, for example, I see those events as info statements, but haven't found an API to hook into that: info: lo0: link state changed to UP info: cgem0: link state changed to DOWN info: cgem0: link state changed to UP Best regards, Jan Deutsches Zentrum f?r Luft- und Raumfahrt e. V. (DLR) German Aerospace Center Institute for Software Technology | Software for Space Systems and Interactive Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany From sebastian.huber at embedded-brains.de Thu Apr 29 11:45:44 2021 From: sebastian.huber at embedded-brains.de (Sebastian Huber) Date: Thu, 29 Apr 2021 13:45:44 +0200 Subject: libbsd: React to link status change events In-Reply-To: <5e1a480f310640ecbb03353187a6fea5@dlr.de> References: <5e1a480f310640ecbb03353187a6fea5@dlr.de> Message-ID: On 29/04/2021 13:43, Jan.Sommer at dlr.de wrote: > is there an easy way to register a callback function or block until a link status change of an Ethernet device occurs in the libbsd stack? > Searching for it, I found some references for EV_NETDEV in kqueue, but this seems to be a legacy function which has been removed years ago. > > In the console of the Zedboard, for example, I see those events as info statements, but haven't found an API to hook into that: > > info: lo0: link state changed to UP > info: cgem0: link state changed to DOWN > info: cgem0: link state changed to UP You can look at the dhcpcd code to figure out how this works. I think a routing socket can be used to get these events. -- 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/ From Jan.Sommer at dlr.de Thu Apr 29 11:47:58 2021 From: Jan.Sommer at dlr.de (Jan.Sommer at dlr.de) Date: Thu, 29 Apr 2021 11:47:58 +0000 Subject: libbsd: React to link status change events In-Reply-To: References: <5e1a480f310640ecbb03353187a6fea5@dlr.de> Message-ID: Thanks. I will have a look. > -----Original Message----- > From: Sebastian Huber > Sent: Thursday, April 29, 2021 1:46 PM > To: Sommer, Jan ; users at rtems.org > Subject: Re: libbsd: React to link status change events > > On 29/04/2021 13:43, Jan.Sommer at dlr.de wrote: > > > is there an easy way to register a callback function or block until a link status > change of an Ethernet device occurs in the libbsd stack? > > Searching for it, I found some references for EV_NETDEV in kqueue, but > this seems to be a legacy function which has been removed years ago. > > > > In the console of the Zedboard, for example, I see those events as info > statements, but haven't found an API to hook into that: > > > > info: lo0: link state changed to UP > > info: cgem0: link state changed to DOWN > > info: cgem0: link state changed to UP > You can look at the dhcpcd code to figure out how this works. I think a > routing socket can be used to get these events. > > -- > 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/ From sebastian.huber at embedded-brains.de Thu Apr 29 11:48:04 2021 From: sebastian.huber at embedded-brains.de (Sebastian Huber) Date: Thu, 29 Apr 2021 13:48:04 +0200 Subject: Announce: RTEMS 5.1 Release In-Reply-To: References:

Message-ID: Hello Pierre, On 25/04/2021 16:31, Pierre FICHEUX wrote: > Is Raspberry Pi 1 B+ BSP OK for RTEMS 5.1 ? maybe this BSP is affected by this bug: https://devel.rtems.org/ticket/4394 -- 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/ From jens.gollasch at lss-lighting.de Thu Apr 29 16:29:55 2021 From: jens.gollasch at lss-lighting.de (Jens Gollasch) Date: Thu, 29 Apr 2021 18:29:55 +0200 Subject: libbsd: React to link status change events In-Reply-To: <5e1a480f310640ecbb03353187a6fea5@dlr.de> References: <5e1a480f310640ecbb03353187a6fea5@dlr.de> Message-ID: > is there an easy way to register a callback function or block until a link status change of an Ethernet device occurs in the libbsd stack? > Searching for it, I found some references for EV_NETDEV in kqueue, but this seems to be a legacy function which has been removed years ago. > > I solved this with setting an hook function for the dhcpcd and react to the "reason" string in the environment. Link is "CARRIER" and NOCARRIER". Look at dhcpcd01 test. -- Mit freundlichen Gr??en Jens Gollasch Licht-, Steuer- und Schaltanlagenbau GmbH NL Dresden From Dave.DeGroote at astrobotic.com Fri Apr 30 19:07:17 2021 From: Dave.DeGroote at astrobotic.com (Dave DeGroote) Date: Fri, 30 Apr 2021 19:07:17 +0000 Subject: Can printf() be made SMP safe? In-Reply-To: References: Message-ID: Hello, I'm trying to get RTEMS running using SMP on a Leon3/gr712rc (2 cores). I have it partially running, but it crashes intermittently on printf's. Can anyone tell me if there's a way to make printf() SMP safe? printf appears to use termios which uses rtems_mutex_init() and rtems_binary_semaphore_init() which I don't think are SMP safe (but I'm also new to this so I'm not sure). Thanks! [Astrobotic Logo] Dave DeGroote Flight Software Engineer Astrobotic 1016 N. Lincoln Avenue | Pittsburgh, PA 15233 office: 412.682.3282 Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joel at rtems.org Fri Apr 30 20:21:41 2021 From: joel at rtems.org (Joel Sherrill) Date: Fri, 30 Apr 2021 15:21:41 -0500 Subject: Can printf() be made SMP safe? In-Reply-To: References: Message-ID: On Fri, Apr 30, 2021 at 2:07 PM Dave DeGroote wrote: > Hello, > > I'm trying to get RTEMS running using SMP on a Leon3/gr712rc (2 cores). I > have it partially running, but it crashes intermittently on printf's. Can > anyone tell me if there's a way to make printf() SMP safe? printf appears > to use termios which uses rtems_mutex_init() and > rtems_binary_semaphore_init() which I don't think are SMP safe (but I'm > also new to this so I'm not sure). > Those are SMP safe. I suspect you are using the Classic API (e.g. rtems_task_) and by default they do not have floating point enabled. You probably just need to enable the floating point attribute on the task create calls (or for the init task). https://docs.rtems.org/branches/master/c-user/task/directives.html#rtems-task-create See configuring a system chapter for the init task setting. If you provide the exception, we would know for sure. --joel > > Thanks! > > [image: Astrobotic Logo] *Dave DeGroote* > > Flight Software Engineer > > *Astrobotic* > > 1016 N. Lincoln Avenue | Pittsburgh, PA 15233 > > office: 412.682.3282 > > > > > > *Disclaimer* > > The information contained in this communication from the sender is > confidential. It is intended solely for use by the recipient and others > authorized to receive it. If you are not the recipient, you are hereby > notified that any disclosure, copying, distribution or taking action in > relation of the contents of this information is strictly prohibited and may > be unlawful. > _______________________________________________ > users mailing list > users at rtems.org > http://lists.rtems.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dave.DeGroote at astrobotic.com Fri Apr 30 22:42:13 2021 From: Dave.DeGroote at astrobotic.com (Dave DeGroote) Date: Fri, 30 Apr 2021 22:42:13 +0000 Subject: Can printf() be made SMP safe? In-Reply-To: References: , Message-ID: Thanks Joel! I said it was crashing, it's actually currently hanging, but it changes. The common thread is it always seems to be in semaphore access functions w/at least one task in printf(). I don't think it's floating point, it looks like RTEMS_FLOATING_POINT is passed to rtems_task_create(), but I'll have to do some testing to be sure. The current backtrace I get when I ^c after it hangs is below. Dave CPU 0: Interrupted! 0x6005bad4: 80a08003 cmp %g2, %g3 <_Mutex_Acquire+52> CPU 1: Interrupted! 0x6005ff98: 80a04002 cmp %g1, %g2 <_SMP_lock_Acquire+40> grmon3> bt cpu0 %pc %sp #0 0x6005bad4 0x6047af58 <_Mutex_Acquire+0x34> #1 0x60047558 0x6047b068 #2 0x600495a4 0x6047b0e8 #3 0x600d558c 0x6047b148 <__sflush_r+0x1bc> #4 0x600d56f0 0x6047b1a8 <_fflush_r+0x9c> #5 0x600f086c 0x6047b208 <__sbprintf+0xb4> #6 0x600db280 0x6047b6e8 #7 0x60030f30 0x6047b750 #8 0x60030fd0 0x6047b7f0 #9 0x6003111c 0x6047b850 #10 0x600314b4 0x6047b8b0 #11 0x60023d28 0x6047b928 #12 0x60056d28 0x6047b990 <_Thread_Entry_adaptor_numeric+0x8> #13 0x60055878 0x6047b9f0 <_Thread_Handler+0xf4> #14 0x60055784 0x6047ba58 <_Thread_Handler+0> grmon3> bt cpu1 %pc %sp #0 0x6005ff98 0x60466ba8 <_SMP_lock_Acquire+0x28> #1 0x60058164 0x60466ba8 <_Thread_queue_Surrender+0x54> #2 0x6005bd4c 0x60466c10 <_Mutex_Release+0x7c> #3 0x600475fc 0x60466d20 #4 0x600495a4 0x60466da0 #5 0x600d558c 0x60466e00 <__sflush_r+0x1bc> #6 0x600d56f0 0x60466e60 <_fflush_r+0x9c> #7 0x600f086c 0x60466ec0 <__sbprintf+0xb4> #8 0x600db280 0x604673a0 #9 0x60029074 0x60467408 #10 0x60029324 0x604674c0 #11 0x60029764 0x60467528 #12 0x600287bc 0x604675a0 #13 0x60023d28 0x60467608 #14 0x60056d28 0x60467670 <_Thread_Entry_adaptor_numeric+0x8> #15 0x60055878 0x604676d0 <_Thread_Handler+0xf4> #16 0x60055784 0x60467738 <_Thread_Handler+0> ________________________________ From: Joel Sherrill Sent: Friday, April 30, 2021 4:21 PM To: Dave DeGroote Cc: users at rtems.org Subject: Re: Can printf() be made SMP safe? CAUTION: This email originated from outside of the organization. On Fri, Apr 30, 2021 at 2:07 PM Dave DeGroote > wrote: Hello, I'm trying to get RTEMS running using SMP on a Leon3/gr712rc (2 cores). I have it partially running, but it crashes intermittently on printf's. Can anyone tell me if there's a way to make printf() SMP safe? printf appears to use termios which uses rtems_mutex_init() and rtems_binary_semaphore_init() which I don't think are SMP safe (but I'm also new to this so I'm not sure). Those are SMP safe. I suspect you are using the Classic API (e.g. rtems_task_) and by default they do not have floating point enabled. You probably just need to enable the floating point attribute on the task create calls (or for the init task). https://docs.rtems.org/branches/master/c-user/task/directives.html#rtems-task-create See configuring a system chapter for the init task setting. If you provide the exception, we would know for sure. --joel Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website. -------------- next part -------------- An HTML attachment was scrubbed... URL: