http://permalink.gmane.org/gmane.os.rtems.user hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.os.rtems.user/21132 <pre>Maybe I have a disconnect but the subject says 4.10.2 and the tools are 4.11. Did Manish switch to the git master? </pre> Joel Sherrill 2013-05-21T12:59:51 http://permalink.gmane.org/gmane.os.rtems.user/21131 <pre>Maybe some problem with your sparc-rtems4.11-binutils? What guide are you following for building your project? You might like to check out the RTEMS source builder [1] [2]. It has known-to-work scripts for building RTEMS tools and RTEMS itself for many different hosts. -Gedare [1] http://git.rtems.org/rtems-source-builder/ [2] http://www.rtems.org/ftp/pub/rtems/people/chrisj/source-builder/source-builder.html On Tue, May 21, 2013 at 12:05 AM, manish jain &lt;manish8886-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; wrote: _______________________________________________ rtems-users mailing list rtems-users-WKV1R6NGPIzYtjvyW6yDsg&lt; at &gt;public.gmane.org http://www.rtems.org/mailman/listinfo/rtems-users </pre> Gedare Bloom 2013-05-21T12:49:42 http://permalink.gmane.org/gmane.os.rtems.user/21130 <pre>Hi All, I was able to build RTEMS-4.10.2 successfully last time. But due to some reason when I tried to build again, I am getting following "Assembler Errors". I have checked "sparc-rtems4.11-gcc", it is still working fine with ordinary ".c"files. Any input what might be the reason for these errors? configure:3440: sparc-rtems4.11-gcc -mcpu=cypress -O2 -g conftest.c &gt;&amp;5 /tmp/ccHERiZW.s: Assembler messages: /tmp/ccHERiZW.s:8: Error: unrecognized symbol type "" /tmp/ccHERiZW.s:9: Error: unknown pseudo-op: `.proc' /tmp/ccHERiZW.s:16: Error: bad register name `%o7+8' /tmp/ccHERiZW.s:17: Error: bad register name `%o0' /tmp/ccHERiZW.s:25: Error: unknown pseudo-op: `.uaword' /tmp/ccHERiZW.s:26: Error: unknown pseudo-op: `.uahalf' /tmp/ccHERiZW.s:27: Error: unknown pseudo-op: `.uaword' /tmp/ccHERiZW.s:30: Error: unknown pseudo-op: `.uaword' /tmp/ccHERiZW.s:32: Error: unknown pseudo-op: `.uaword' /tmp/ccHERiZW.s:33: Error: unknown pseudo-op: `.uaword' /tmp/ccHERiZW.s:34: Error: unknown pseudo-op: `.uaword' /tmp/</pre> manish jain 2013-05-21T04:05:26 http://permalink.gmane.org/gmane.os.rtems.user/21129 <pre>Gaisler includes code in their RCC which is not in RTEMS. They periodically submit patches to catch the community version up on their drivers, etc. The last time they started merging, there were about 50 individual patches to review and merge. We put leon3 and sparc specific ones first in the list along with small patches which were easy to review. In particular, this code makes capabilities available to all targets and BSPs. It was put at the bottom of the review list because of this. We are waiting for Gaisler personnel to have time to revisit the review and merge process. It may show up in 4.11. </pre> Joel Sherrill 2013-05-20T23:53:03 http://permalink.gmane.org/gmane.os.rtems.user/21128 <pre>I am trying to port RTEMS on LEON3(GR-XCS Development Board). While referring to "Gaisler RTEMS Driver Documentation", I found that a driver manager is responsible for managing the drivers in RTEMS bsp for Leon3. But the RTEMS-4.10.2 source code which I cloned from the repository doesn't have any directory named "cpukit/libdrvmgr". Can someone please explain why it is so? Thanks Manish _______________________________________________ rtems-users mailing list rtems-users-WKV1R6NGPIzYtjvyW6yDsg&lt; at &gt;public.gmane.org http://www.rtems.org/mailman/listinfo/rtems-users </pre> manish jain 2013-05-20T22:10:22 http://permalink.gmane.org/gmane.os.rtems.user/21127 <pre>I have that set to 20. You can see that here in this reply. Robert W. Joel Sherrill wrote: _______________________________________________ rtems-users mailing list rtems-users-WKV1R6NGPIzYtjvyW6yDsg&lt; at &gt;public.gmane.org http://www.rtems.org/mailman/listinfo/rtems-users </pre> rwas 2013-05-18T21:36:23 http://permalink.gmane.org/gmane.os.rtems.user/21126 <pre>I don't think you configured any extra file descriptors. I am on my phone but it should be CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS or something very similar to that. --jo rwas &lt;rbtwas-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; wrote: Hello, I've been working the bsp for the mvme177. It's looking pretty good at this point. Currently, I'm trying to get rshell to work. After some debugging I find that the "spawned_shell()" function in "telnetd.c" is trying to open "/dev/pty0" and failing. I tried to do a simple "fopen("/dev/pty0", "r+")" within "main.c" and that fails as well. Here are my configs from "main.c": The "CONFIGURE_SHELL..." stuff is commented out here, but enabled in another file. /* configuration information */ #define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER // need this for "sleep()" #define CONFIGURE_APPLICATION_NEEDS_LIBBLOCK #define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER #define CONFIGURE_APPLICATION_NEEDS_NULL_DRIVER // experimental 20130518 #define CONFIGURE_LIBIO_MAXIMUM_FIL</pre> Joel Sherrill 2013-05-18T21:16:44 http://permalink.gmane.org/gmane.os.rtems.user/21125 <pre>Hello, I've been working the bsp for the mvme177. It's looking pretty good at this point. Currently, I'm trying to get rshell to work. After some debugging I find that the "spawned_shell()" function in "telnetd.c" is trying to open "/dev/pty0" and failing. I tried to do a simple "fopen("/dev/pty0", "r+")" within "main.c" and that fails as well. Here are my configs from "main.c": The "CONFIGURE_SHELL..." stuff is commented out here, but enabled in another file. /* configuration information */ #define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER // need this for "sleep()" #define CONFIGURE_APPLICATION_NEEDS_LIBBLOCK #define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER #define CONFIGURE_APPLICATION_NEEDS_NULL_DRIVER // experimental 20130518 #define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS 20 #define CONFIGURE_USE_IMFS_AS_BASE_FILESYSTEM #define CONFIGURE_NUMBER_OF_TERMIOS_PORTS 4 #define CONFIGURE_EXECUTIVE_RAM_SIZE (32 * 512*1024) #define CONFIGURE_MEMORY_OVERHEAD 256 </pre> rwas 2013-05-18T20:08:53 http://permalink.gmane.org/gmane.os.rtems.user/21124 <pre>We have received a similar notice for our mvme6100s. I don't know if it is the same issue but with the 6100 the problem is that the manufacturer can no longer get the RAM they used for the L3 cache. The new version will have a slower L3. - Till On 05/15/2013 03:18 PM, Peter Dufault wrote: _______________________________________________ rtems-users mailing list rtems-users-WKV1R6NGPIzYtjvyW6yDsg&lt; at &gt;public.gmane.org http://www.rtems.org/mailman/listinfo/rtems-users </pre> Till Straumann 2013-05-15T23:37:48 http://permalink.gmane.org/gmane.os.rtems.user/21123 <pre>git clone git://git.rtems.org/examples-v2.git On May 15, 2013 5:34 PM, "Matthew J Fletcher" &lt;amimjf-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; wrote: _______________________________________________ rtems-users mailing list rtems-users-WKV1R6NGPIzYtjvyW6yDsg&lt; at &gt;public.gmane.org http://www.rtems.org/mailman/listinfo/rtems-users </pre> Gedare Bloom 2013-05-15T22:34:25 http://permalink.gmane.org/gmane.os.rtems.user/21122 <pre>Replace RTEMS with examples-v2 in the clone command. Matthew J Fletcher &lt;amimjf-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; wrote: Hi, Where in the git tree are examples-v2 ? On 15 May 2013 12:44, Joel Sherrill &lt;Joel.Sherrill-lGxtRh3/QYtBDgjK7y7TUQ&lt; at &gt;public.gmane.org&lt;mailto:Joel.Sherrill-lGxtRh3/QYtBDgjK7y7TUQ&lt; at &gt;public.gmane.org&gt;&gt; wrote: Also simple examples for inclusion in examples-v2 are appreciated. Sometimes there is nothing like seeing some working code Sebastian Huber &lt;sebastian.huber-L1vi/lXTdtsBbLBgBO8hYIQuADTiUCJX&lt; at &gt;public.gmane.org&lt;mailto:sebastian.huber&lt; at &gt;embedded-brains.de&gt;&gt; wrote: Hello, On 05/15/2013 01:16 PM, Matthew J Fletcher wrote: you can use rtems_timer_reset() to restart the timer in the timer service routine. You can send a patch for the documentation if you want: http://git.rtems.org/rtems/tree/doc/user/timer.t -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16&lt;tel:%2B49%2089%20189%2047%2041-16&gt; Fax : +49</pre> Joel Sherrill 2013-05-15T22:30:38 http://permalink.gmane.org/gmane.os.rtems.user/21121 <pre>I think this was entirely a false alarm. Emerson replaced the MVME5500 with a new model number with a "-R" on the end ("respun") and end-of-lifed the earlier one. I think this is just confusion on the part of Arrow and the way they dealt with people in purchasing at my client, people who would have no way to realize the "-R" model number is probably compatible. Yes, we'll need to double-check things, but I expect the "respun" board will work just fine. Two years ago Emerson issued a press release saying the MVME5500 would be in production at least through 2016, I expect that is still their plan. On May 14, 2013, at 17:29 , Peter Dufault &lt;dufault-zvzGBF1tbGQ&lt; at &gt;public.gmane.org&gt; wrote: Peter ----------------- Peter Dufault HD Associates, Inc. Software and System Engineering _______________________________________________ rtems-users mailing list rtems-users-WKV1R6NGPIzYtjvyW6yDsg&lt; at &gt;public.gmane.org http://www.rtems.org/mailman/listinfo/rtems-users </pre> Peter Dufault 2013-05-15T22:18:14 http://permalink.gmane.org/gmane.os.rtems.user/21120 <pre>Hi, Where in the git tree are examples-v2 ? On 15 May 2013 12:44, Joel Sherrill &lt;Joel.Sherrill-lGxtRh3/QYtBDgjK7y7TUQ&lt; at &gt;public.gmane.org&gt; wrote: </pre> Matthew J Fletcher 2013-05-15T21:32:29 http://permalink.gmane.org/gmane.os.rtems.user/21119 <pre>I don't think this is much of a concern. To summarize the bug, when a nested lock is obtained and priority is inherited, the thread's current_priority is saved. When the nested lock is released, the current_priority is restored without checking what the highest priority is on the outer lock. So there may be a thread blocked on the outer lock with a higher priority than the thread that just released the inner lock. I think we need to fix this bug and enable strict order all the time. I want to know what are the options to fix it? Would it be possible to fix the bug by updating the stored value of the current_priority to the inherited value of the outer lock while the holder is executing (or blocked!) on the nested lock? If blocked on the nested lock, the holder of the nested lock may also need to be inherited from the priority of the outer lock even if the outer lock is not held due to the transitive priority of the holder of the outer lock. -Gedare _______________________________________________ rtems</pre> Gedare Bloom 2013-05-15T20:48:14 http://permalink.gmane.org/gmane.os.rtems.user/21118 <pre>Also simple examples for inclusion in examples-v2 are appreciated. Sometimes there is nothing like seeing some working code Sebastian Huber &lt;sebastian.huber-L1vi/lXTdtsBbLBgBO8hYIQuADTiUCJX&lt; at &gt;public.gmane.org&gt; wrote: Hello, On 05/15/2013 01:16 PM, Matthew J Fletcher wrote: you can use rtems_timer_reset() to restart the timer in the timer service routine. You can send a patch for the documentation if you want: http://git.rtems.org/rtems/tree/doc/user/timer.t -- 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-L1vi/lXTdtsBbLBgBO8hYIQuADTiUCJX&lt; at &gt;public.gmane.org PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. _______________________________________________ rtems-users mailing list rtems-users-WKV1R6NGPIzYtjvyW6yDsg&lt; at &gt;public.gmane.org http://www.rtems.org/mailman/listinfo/rtems-users __________________________________</pre> Joel Sherrill 2013-05-15T11:44:57 http://permalink.gmane.org/gmane.os.rtems.user/21117 <pre>Hello, On 05/15/2013 01:16 PM, Matthew J Fletcher wrote: you can use rtems_timer_reset() to restart the timer in the timer service routine. You can send a patch for the documentation if you want: http://git.rtems.org/rtems/tree/doc/user/timer.t </pre> Sebastian Huber 2013-05-15T11:25:51 http://permalink.gmane.org/gmane.os.rtems.user/21116 <pre>Hi, It looks like rtems_timer_fire_after() is a one time only timer, you need to call rtems_timer_fire_after() to generate another. The documentation does not seem to indicate that, is it possible a small update could be made for clarity. I wrongly presumed it was a repeating timer that would go until you cancelled the timer. </pre> Matthew J Fletcher 2013-05-15T11:16:10 http://permalink.gmane.org/gmane.os.rtems.user/21115 <pre>The likely cause is that the default compiler settings are not for the greatest precision and favor speed. There should be lots of threads on the GCC mailing lists about this. SAeeD &lt;salpha.2004-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; wrote: Hello, I've executed paranoia test on 3 personal computers and on all of them, I get the following result at the end: "The number of FAILUREs encountered = 4. The number of SERIOUS DEFECTs discovered = 5. The number of DEFECTs discovered = 3. The number of FLAWs discovered = 2. The arithmetic diagnosed has unacceptable Serious Defects. Potentially fatal FAILURE may have spoiled this program's subsequent diagnoses." This is while the test runs perfectly on LPC3250 and here is the result: "No failures, defects nor flaws have been discovered. Rounding appears to conform to the proposed IEEE standard P754. The arithmetic diagnosed appears to be Excellent!" I wonder is there any consideration I'm missing for x86 platform!? As far as I k</pre> Joel Sherrill 2013-05-15T11:09:57 http://permalink.gmane.org/gmane.os.rtems.user/21114 <pre>Hello, I've executed paranoia test on 3 personal computers and on all of them, I get the following result at the end: "The number of FAILUREs encountered = 4. The number of SERIOUS DEFECTs discovered = 5. The number of DEFECTs discovered = 3. The number of FLAWs discovered = 2. The arithmetic diagnosed has unacceptable Serious Defects. Potentially fatal FAILURE may have spoiled this program's subsequent diagnoses." This is while the test runs perfectly on LPC3250 and here is the result: "No failures, defects nor flaws have been discovered. Rounding appears to conform to the proposed IEEE standard P754. The arithmetic diagnosed appears to be Excellent!" I wonder is there any consideration I'm missing for x86 platform!? As far as I know, stack overflow, and floating point exception handlers not being installed are possible reasons of failure. Am I doing something wrong? Thanks SAeeD _______________________________________________ rtems-users mailing list rtems-users-WKV1R6N</pre> SAeeD 2013-05-15T09:15:42 http://permalink.gmane.org/gmane.os.rtems.user/21113 <pre> I have. An mvme167 and an mvme162, in an active military project. And I can assure you, they have no desire to replace it. I don't think there is anything about those particular cards that makes then attractive to the military, other than many of these programs are shoestring in nature. Most of their hardware are leftovers from other projects.They get there contracts based on being ready to perform work. Within this niche, there is little room, in terms of money, or time to rebuild an already working system with new hardware. I've been trying to find an mvme162 on ebay for a while. They show up but for some bizarre reason, they are 4 or more times the cost of an mvme177. An mvme167 is cheaper than an mvme162 but still about twice as expensive as an mvme177. Again, I believe this has to do with legacy code, and existing development systems. Robert W. _______________________________________________ rtems-users mailing list rtems-users-WKV1R6NGPIzYtjvyW6yDsg&lt; at &gt;public.gmane.org http://www.rtems.or</pre> rwas 2013-05-15T01:57:47 http://permalink.gmane.org/gmane.os.rtems.user/21112 <pre> I suspect there is no relationship to military use. I have not seen a MVME167 in a system since the '90s. Most processing boards I came across where Radstone, DY4 or something similar (I cannot remember who made the UltraSparc boards in the NATO AWACS). Maybe there is a control market that is keeping the MVME167 going. Who knows. My exposure to this type of thing in the military world saw them manage procurement for the life of the project within the project. I have seen a chip mask be pulled from escrow and taken somewhere and remade to keep a board going. I suggest you contact the manufacture and openly discuss the issue and become registered for final buy type announcements. I suspect they maybe looking at a final chip run for something on the board because someone wants to close the line down so they will be after quantities. It might not be the processor and could be any chip on the board. Chris _______________________________________________ rtems-users mailing list rtems-users-WKV1R6NGP</pre> Chris Johns 2013-05-15T00:45:22 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.os.rtems.user