Re: psim: RTEMS_SHM_SEMAPHORE_KEY and RTEMS_SHM_KEY
On 05/04/16 08:55, Sebastian Huber wrote: Hello, the psim simulator script requires a RTEMS_SHM_SEMAPHORE_KEY and RTEMS_SHM_KEY. Does anyone know how to set up this? You can create the shared memory and semaphore via: ipcmk -M 131072 ipcmk -S 1 Use ipcs to get the keys, then do: export RTEMS_SHM_SEMAPHORE_KEY=0xe7ed7bf0 export RTEMS_SHM_KEY=0x9e15c750 With this I was able to run the MP tests on PSIM. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 04/15] score: Add node adjust to _RBTree_Find_inline()
On Tue, Apr 5, 2016 at 11:35 AM, Sebastian Huber wrote: > > - Gedare Bloom schrieb: >> I don't understand the name "adjust"? I think of adjusting as >> something that would cause a change or modify, which is not the case >> here. I don't have any great replacement, but I guess I might suggest >> "dereference"? > > You may adjust the pointer value, e.g. node + offset. Dereference is wrong, > since you are not supposed to do a *node. Maybe "fixup"? > As I understand it, this callout does not modify the tree or node, so I would avoid using any verb that implies a change happens: fixup implies some modification to me. Perhaps I misunderstood, but the comment says the callout should "get the return value" of a found node. get_value() would be OK except for slight overload with POSIX keys. read()? I'm not coming up with any great ideas. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 04/15] score: Add node adjust to _RBTree_Find_inline()
map might be fine. some other possibilities: index, offset, field. I just noticed though that this proposed callout seems somewhat awkward since it will return a void* pointing to something not a node, and the return likely goes to something expecting an RBTree_Node*? Why not leave it to the caller of Find() to do the end conversion to the data element embedded in the node that gets found? On Tue, Apr 5, 2016 at 12:42 PM, Sebastian Huber wrote: > Maybe "map"? > > - Gedare Bloom schrieb: >> On Tue, Apr 5, 2016 at 11:35 AM, Sebastian Huber >> wrote: >> > >> > - Gedare Bloom schrieb: >> >> I don't understand the name "adjust"? I think of adjusting as >> >> something that would cause a change or modify, which is not the case >> >> here. I don't have any great replacement, but I guess I might suggest >> >> "dereference"? >> > >> > You may adjust the pointer value, e.g. node + offset. Dereference is >> > wrong, since you are not supposed to do a *node. Maybe "fixup"? >> > >> As I understand it, this callout does not modify the tree or node, so >> I would avoid using any verb that implies a change happens: fixup >> implies some modification to me. Perhaps I misunderstood, but the >> comment says the callout should "get the return value" of a found >> node. get_value() would be OK except for slight overload with POSIX >> keys. read()? >> >> I'm not coming up with any great ideas. > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.huber at embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Bringing the Scheduling Simulator in synch with RTEMS master
Any ideas / updates / suggestions on this? Thanking You, Darshit Shah Sent from mobile device. Please excuse my brevity On 01-Apr-2016 4:13 pm, "Darshit Shah" wrote: > On 03/30, Joel Sherrill wrote: > >> On Wed, Mar 30, 2016 at 9:03 AM, Darshit Shah wrote: >> >> I've started trying to bring the scheduling simulator in synch with the >>> current RTEMS master. Joel has created Trac Ticket #2679 ( >>> https://devel.rtems.org/ticket/2679) for this task. >>> >>> While trying to get the simulator to compile, GCC spits out the following >>> error: >>> >>> In file included from >>> >>> /home/thedoctor/Programming/rtems/rtems/cpukit/score/include/rtems/score/threadq.h:25:0, >>> from >>> >>> /home/thedoctor/Programming/rtems/rtems/cpukit/score/include/rtems/score/thread.h:35, >>> from >>> >>> /home/thedoctor/Programming/rtems/rtems/cpukit/score/include/rtems/score/heap.h:22, >>> from >>> >>> /home/thedoctor/Programming/rtems/rtems/cpukit/rtems/include/rtems/rtems/types.h:26, >>> from >>> >>> /home/thedoctor/Programming/rtems/rtems/cpukit/rtems/include/rtems/rtems/config.h:24, >>> from >>> >>> /home/thedoctor/Programming/rtems/rtems/cpukit/sapi/include/rtems/config.h:57, >>> from >>> ../../../rtems-schedsim/schedsim/rtems/rtems_init.c:25: >>> >>> /home/thedoctor/Programming/rtems/rtems/cpukit/score/include/rtems/score/rbtree.h:21:22: >>> fatal error: sys/tree.h: No such file or directory >>> >>> Some scouting around reveals that the sys/tree.h header file is available >>> in Newlib. However, I am unable to find a way to point the compiler in >>> that >>> direction for the scheduling simulator. Can someone please point me to >>> the >>> right set of Automake directives I'd require for this? >>> >>> >>> There are two alternatives for missing libc files like this. >> >> 1) hope they really aren't needed and ifdef out the include. I suspect >> this >> won't work here. >> >> That could work for a few cases, but in this case I doubt that'll help. > > 2) put a copy in schedsim/rtems/sched_cpu/sys. Looks like I hit other >> issues like a missing >> cpuset.h method and had to add a stub sys/lock.h. >> >> Is this the only solution we have? Because, I see a few new issues where > newlib now has a newer version of the BSD time.h file and the schedsim > fails to build without it. Currently, the only way is to copy all those > header files into schedsim/rtems/sched_cpu/sys. Would it possible to extend > schedsim to directly use newlib just like the RTEMS build does? Then we > won't need to copy all these files around and keep duplicate copies. > > Add a section to the instructions in the ticket. I forgot about this case. >> >> Hopefully this isn't a bad thing to fix. Since you are layering BSD >> capabilities on top of >> glibc, it can be tricky to avoid naming conflicts. >> >> --joel >> >> >> >>> -- >>> Thanking You, >>> Darshit Shah >>> >>> >>> ___ >>> devel mailing list >>> devel@rtems.org >>> http://lists.rtems.org/mailman/listinfo/devel >>> >>> > -- > Thanking You, > Darshit Shah > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Bringing the Scheduling Simulator in synch with RTEMS master
Newlib has a Linux configuration and we don't assume a lot of the host. Using newlib as the native libc rather than glibc may solve these problems. The only gotcha I can see is that the Linux newlib target has a fair amount of code in the OS support directory for Linux. If they replace too much normal newlib, it may not work still. But that's a better long term solution. We depend more on the BSD-isms in newlib than we did years ago. At one point, there were no dependencies. On Apr 1, 2016 9:13 AM, "Darshit Shah" wrote: > On 03/30, Joel Sherrill wrote: > >> On Wed, Mar 30, 2016 at 9:03 AM, Darshit Shah wrote: >> >> I've started trying to bring the scheduling simulator in synch with the >>> current RTEMS master. Joel has created Trac Ticket #2679 ( >>> https://devel.rtems.org/ticket/2679) for this task. >>> >>> While trying to get the simulator to compile, GCC spits out the following >>> error: >>> >>> In file included from >>> >>> /home/thedoctor/Programming/rtems/rtems/cpukit/score/include/rtems/score/threadq.h:25:0, >>> from >>> >>> /home/thedoctor/Programming/rtems/rtems/cpukit/score/include/rtems/score/thread.h:35, >>> from >>> >>> /home/thedoctor/Programming/rtems/rtems/cpukit/score/include/rtems/score/heap.h:22, >>> from >>> >>> /home/thedoctor/Programming/rtems/rtems/cpukit/rtems/include/rtems/rtems/types.h:26, >>> from >>> >>> /home/thedoctor/Programming/rtems/rtems/cpukit/rtems/include/rtems/rtems/config.h:24, >>> from >>> >>> /home/thedoctor/Programming/rtems/rtems/cpukit/sapi/include/rtems/config.h:57, >>> from >>> ../../../rtems-schedsim/schedsim/rtems/rtems_init.c:25: >>> >>> /home/thedoctor/Programming/rtems/rtems/cpukit/score/include/rtems/score/rbtree.h:21:22: >>> fatal error: sys/tree.h: No such file or directory >>> >>> Some scouting around reveals that the sys/tree.h header file is available >>> in Newlib. However, I am unable to find a way to point the compiler in >>> that >>> direction for the scheduling simulator. Can someone please point me to >>> the >>> right set of Automake directives I'd require for this? >>> >>> >>> There are two alternatives for missing libc files like this. >> >> 1) hope they really aren't needed and ifdef out the include. I suspect >> this >> won't work here. >> >> That could work for a few cases, but in this case I doubt that'll help. > > 2) put a copy in schedsim/rtems/sched_cpu/sys. Looks like I hit other >> issues like a missing >> cpuset.h method and had to add a stub sys/lock.h. >> >> Is this the only solution we have? Because, I see a few new issues where > newlib now has a newer version of the BSD time.h file and the schedsim > fails to build without it. Currently, the only way is to copy all those > header files into schedsim/rtems/sched_cpu/sys. Would it possible to extend > schedsim to directly use newlib just like the RTEMS build does? Then we > won't need to copy all these files around and keep duplicate copies. > > Add a section to the instructions in the ticket. I forgot about this case. >> >> Hopefully this isn't a bad thing to fix. Since you are layering BSD >> capabilities on top of >> glibc, it can be tricky to avoid naming conflicts. >> >> --joel >> >> >> >>> -- >>> Thanking You, >>> Darshit Shah >>> >>> >>> ___ >>> devel mailing list >>> devel@rtems.org >>> http://lists.rtems.org/mailman/listinfo/devel >>> >>> > -- > Thanking You, > Darshit Shah > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Error while building arm/realview_pbx_a9_qemu BSP
Should work now using the latest RTEMS and libbsd master branch. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Error while building arm/realview_pbx_a9_qemu BSP
I am building this using RTEMS 4.12 and latest master branch pulled from github. I tried the same thing with RTEMS 4.11 also. I got the similar error. Looks like some files are not getting included/ missing. On Wed, Apr 6, 2016 at 6:26 PM, Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Should work now using the latest RTEMS and libbsd master branch. > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Error while building arm/realview_pbx_a9_qemu BSP
On 06/04/16 15:39, Deval Shah wrote: I am building this using RTEMS 4.12 and latest master branch pulled from github. I don't know how reliably and fast the github updates are. I tried the same thing with RTEMS 4.11 also. I got the similar error. Looks like some files are not getting included/ missing. For RTEMS 4.11 use the branches for RTEMS and libbsd. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Error while building arm/realview_pbx_a9_qemu BSP
On Wed, Apr 6, 2016 at 7:13 PM, Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > > > On 06/04/16 15:39, Deval Shah wrote: > >> I am building this using RTEMS 4.12 and latest master branch pulled from >> github. >> > > I don't know how reliably and fast the github updates are. > Any suggestions about that then ? > >> >> I tried the same thing with RTEMS 4.11 also. I got the similar error. >> Looks like some files are not getting included/ missing. >> > > For RTEMS 4.11 use the branches for RTEMS and libbsd. Okay. I will try that. > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Error while building arm/realview_pbx_a9_qemu BSP
On Wed, Apr 6, 2016 at 10:10 AM, Deval Shah wrote: > > > On Wed, Apr 6, 2016 at 7:13 PM, Sebastian Huber > wrote: >> >> >> >> On 06/04/16 15:39, Deval Shah wrote: >>> >>> I am building this using RTEMS 4.12 and latest master branch pulled from >>> github. >> >> >> I don't know how reliably and fast the github updates are. >> Any suggestions about that then ? Use git.rtems.org ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Bringing the Scheduling Simulator in synch with RTEMS master
On 06/04/16 14:49, Joel Sherrill wrote: Newlib has a Linux configuration and we don't assume a lot of the host. Using newlib as the native libc rather than glibc may solve these problems. The only gotcha I can see is that the Linux newlib target has a fair amount of code in the OS support directory for Linux. If they replace too much normal newlib, it may not work still. This will not work since the Linux port of Newlib provides its own for example. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Move POSIX network headers like etc. to Newlib?
Hello, what about moving the POSIX network headers arpa/inet.h netdb.h net/if.h netinet/in.h netinet/tcp.h syslog.h sys/socket.h sys/uio.h sys/un.h to Newlib? This has the following benefits. 1. It ensures compatibility between the standard and libbsd network stack at user API level. 2. These files may be used by lwIP to provide the standard API. 3. It allows 3rd party code depending only on the POSIX network headers to build without RTEMS, e.g. GCC Ada and Go languages, libressl library etc. Allows build of libraries per multilib. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
