Hello.<br>Im doing a thesis about LEON3 as a multiprocessor and would really like to use RTEMS. <br>However RTEMS for LEON3 are still not modified for multiprocessor.<br>________________________________________________________<br>
/rtems-4.10/c/src/lib/libbsp/sparc/leon3/readme<br><div id=":12q" class="ii gt">"This BSP supports<b> <span style="background-color: rgb(255, 0, 0);">single</span></b> LEON3-processor system"<br>________________________________________________________<br>
Are this a correct interpretation of the readme file?<br><br>If so, how much work is it to change RTEMS so it will function with LEON3 in a multiprocessor system?<br>Have some one done this before and how is it done?<br>
A tip where to read I would be really grateful. <br><br>Best regards <br>Gustav <br></div><br><br><div class="gmail_quote">2009/5/6 <span dir="ltr"><<a href="mailto:rtems-users-request@rtems.org">rtems-users-request@rtems.org</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Send rtems-users mailing list submissions to<br>
<a href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://www.rtems.org/mailman/listinfo/rtems-users" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-users</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:rtems-users-request@rtems.org">rtems-users-request@rtems.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:rtems-users-owner@rtems.org">rtems-users-owner@rtems.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of rtems-users digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: rename issue (Chris Johns)<br>
2. Re: rename issue (Ralf Corsepius)<br>
3. Re: NFS against UDP (Till Straumann)<br>
4. Re: NFS against UDP (Leon Pollak)<br>
5. Code sharing in shared memory systems? (Axel von Engel)<br>
6. Re: Code sharing in shared memory systems? (Joel Sherrill)<br>
7. warning question (Joel Sherrill)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Wed, 06 May 2009 10:10:57 +1000<br>
From: Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>><br>
Subject: Re: rename issue<br>
To: Joel Sherrill <<a href="mailto:joel.sherrill@oarcorp.com">joel.sherrill@oarcorp.com</a>><br>
Cc: RTEMS Users <<a href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a>>, Ralf Corsepius<br>
<<a href="mailto:ralf.corsepius@rtems.org">ralf.corsepius@rtems.org</a>><br>
Message-ID: <<a href="mailto:4A00D591.8020708@rtems.org">4A00D591.8020708@rtems.org</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
Joel Sherrill wrote:<br>
> Ralf Corsepius wrote:<br>
>> Joel Sherrill wrote:<br>
>><br>
>>> Looks like we are heading for a new spin of the 4.10 tools<br>
>>> soon.<br>
>>><br>
>>><br>
>> Yep, .... I am going to address these issues sequentially.<br>
>><br>
>>> + drop - DMISSING_SYSCALL_NAMES from configure.host<br>
>>><br>
>>><br>
>> Having cross-checked your proposal, I leaned to agree with your proposal<br>
>> and am about to launch a toolchain spin.<br>
>><br>
>> Please test this toolchain! Though this patch is a one-liner, this step<br>
>> is quite intrusive, and is not unlikely to have (so far) unconsidered<br>
>> side-effects.<br>
>><br>
>><br>
> Yeah! This one worried me. It could easily turn up a LOT of<br>
> stuff.<br>
<br>
What should we be looking for ?<br>
<br>
>>> + inttypes.h warning<br>
>>><br>
>>><br>
>> WIP on my part, but no patch available so far.<br>
>><br>
> OK. Chris and I were on a warning hunt and these showed up<br>
> in cpukit. They will disappear again when you get the patch.<br>
><br>
<br>
Which warnings will this fix ?<br>
<br>
Regards<br>
Chris<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Wed, 06 May 2009 02:36:18 +0200<br>
From: Ralf Corsepius <<a href="mailto:ralf.corsepius@rtems.org">ralf.corsepius@rtems.org</a>><br>
Subject: Re: rename issue<br>
To: Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>><br>
Cc: RTEMS Users <<a href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a>><br>
Message-ID: <<a href="mailto:4A00DB82.6010301@rtems.org">4A00DB82.6010301@rtems.org</a>><br>
Content-Type: text/plain; charset=UTF-8; format=flowed<br>
<br>
Chris Johns wrote:<br>
> Joel Sherrill wrote:<br>
><br>
>> Ralf Corsepius wrote:<br>
>><br>
>>> Joel Sherrill wrote:<br>
>>><br>
>>><br>
>>>> Looks like we are heading for a new spin of the 4.10 tools<br>
>>>> soon.<br>
>>>><br>
>>>><br>
>>>><br>
>>> Yep, .... I am going to address these issues sequentially.<br>
>>><br>
>>><br>
>>>> + drop - DMISSING_SYSCALL_NAMES from configure.host<br>
>>>><br>
>>>><br>
>>>><br>
>>> Having cross-checked your proposal, I leaned to agree with your proposal<br>
>>> and am about to launch a toolchain spin.<br>
>>><br>
>>> Please test this toolchain! Though this patch is a one-liner, this step<br>
>>> is quite intrusive, and is not unlikely to have (so far) unconsidered<br>
>>> side-effects.<br>
>>><br>
>>><br>
>>><br>
>> Yeah! This one worried me. It could easily turn up a LOT of<br>
>> stuff.<br>
>><br>
><br>
> What should we be looking for ?<br>
><br>
Symbol clashes/conflicts related to "_"-prefixed function symbols and<br>
bogus/redundant <function>_r vs. <function> calls.<br>
<br>
><br>
>>>> + inttypes.h warning<br>
>>>><br>
>>>><br>
>>>><br>
>>> WIP on my part, but no patch available so far.<br>
>>><br>
>>><br>
>> OK. Chris and I were on a warning hunt and these showed up<br>
>> in cpukit. They will disappear again when you get the patch.<br>
>><br>
>><br>
><br>
> Which warnings will this fix ?<br>
><br>
<br>
Joel's test case had been this:<br>
<br>
../../../../../../rtems/c/src/../../cpukit/libmisc/shell/main_mwdump.c:65:<br>
>> warning: format '%08llX' expects type 'long long unsigned int', but<br>
>> argument<br>
>> 2 has type 'uintptr_t'<br>
<br>
<br>
It shows with newlib-1.17.0 based toolchains (rtems-4.10) and can be reproduced with this test case:<br>
<br>
<br>
#include <inttypes.h><br>
#include <stdio.h><br>
<br>
extern uintptr_t x;<br>
<br>
void doit( void ) {<br>
printf("0x%08" PRIXPTR " ",addr);<br>
}<br>
<br>
The origin of this warning is PRIXPTR being defined to "llX" on some<br>
targets, while uintptr_t is a (32bit) "long".<br>
<br>
The warning had been introduced by an upstream newlib patch, which was<br>
supposed to provide better c99/POSIX compliance. However, with this<br>
patch applied, gcc now complains about it.<br>
<br>
So, the question, I don't know the anser to, is: Whose fault is this<br>
warning? Is GCC not sufficently c99/POSIX compliant or is newlib bugged?<br>
<br>
newlib-1.16.0 (rtems-4.9 toolchains) don't have the patch in question<br>
applied, and are not subject to this issue.<br>
<br>
Ralf<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Wed, 06 May 2009 02:30:27 -0700<br>
From: Till Straumann <<a href="mailto:strauman@slac.stanford.edu">strauman@slac.stanford.edu</a>><br>
Subject: Re: NFS against UDP<br>
To: Leon Pollak <<a href="mailto:leonp@plris.com">leonp@plris.com</a>><br>
Cc: <a href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a><br>
Message-ID: <<a href="mailto:4A0158B3.9090103@slac.stanford.edu">4A0158B3.9090103@slac.stanford.edu</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
Leon Pollak wrote:<br>
> Hello, all.<br>
><br>
><br>
> I need a help from the list members, gurus in networking, as I am too<br>
> weak in this.<br>
><br>
><br>
> I have today an application under RTEMS speaking with another<br>
> application via UDP. Most of the time data exchange via our simple UDP<br>
> protocol is transferring big amounts of data, the rest are some commands.<br>
> The amounts of data are so big (for the system) that most of the time<br>
> CPU is processing the BSD stack operations.<br>
><br>
><br>
> The customer now insists on introducing the NFS. I object, explaining<br>
> my objection mostly by significant increasing of required CPU power<br>
> and traffic to perform the NFS protocol.<br>
><br>
><br>
> The question is - am I right? Do someone has a similar experience? How<br>
> can I estimate the load growth even VERY roughly?<br>
A few hints (NFS read operation only; write is very similar)<br>
<br>
- rtems NFS implementation is fully synchronous (no read-ahead,<br>
i.e., request block X, wait until block X received). Probably your<br>
raw UDP communication is similar but if it does implement<br>
read-ahead / caching then expect significant slowdown when<br>
using NFS.<br>
<br>
- For every block read, NFS requires XDR-decoding a protocol<br>
header. This overhead is relatively small, especially if a large<br>
block size is used (you want 8k / max. allowed by UDP). A large<br>
block size also speeds up synchronous operation.<br>
<br>
- The payload data is copied verbatim (w/o any byte-swapping<br>
to the user's buffer). If the 'xdr_mbuf' stream is used then<br>
the cost is similar to using normal UDP (copying from mbufs<br>
into user buffer) -- otherwise data are copied twice (from<br>
mbufs to NFS memory buffer, then again from there to user<br>
buffer.<br>
The behavior is compile-time configurable (nfsclient/src/rpcio.c)<br>
-- by default a second copy operation is avoided.<br>
<br>
-> If you use a large block size, read relatively large files<br>
(>> NFS protocol header) and your current implementation<br>
does not implement read-ahead/caching then I'd be surprised<br>
if NFS is a lot slower. Nevertheless, you want to run a few<br>
tests...<br>
<br>
HTH<br>
-- Till<br>
><br>
><br>
> Many thanks for any comment/help.<br>
><br>
><br>
> --<br>
> Leon<br>
><br>
><br>
> ------------------------------------------------------------------------<br>
><br>
> _______________________________________________<br>
> rtems-users mailing list<br>
> <a href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a><br>
> <a href="http://www.rtems.org/mailman/listinfo/rtems-users" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-users</a><br>
><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Wed, 6 May 2009 14:46:21 +0300<br>
From: Leon Pollak <<a href="mailto:leonp@plris.com">leonp@plris.com</a>><br>
Subject: Re: NFS against UDP<br>
To: "Undisclosed.Recipients": ;<br>
Cc: <a href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a><br>
Message-ID: <<a href="mailto:200905061446.22078.leonp@plris.com">200905061446.22078.leonp@plris.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
On Wednesday May 6 2009, Till Straumann wrote:<br>
> A few hints (NFS read operation only; write is very similar)<br>
><br>
> - rtems NFS implementation is fully synchronous (no read-ahead,<br>
> i.e., request block X, wait until block X received). Probably your<br>
> raw UDP communication is similar but if it does implement<br>
> read-ahead / caching then expect significant slowdown when<br>
> using NFS.<br>
Thanks for the tip, I shall take this into account.<br>
But most of the time we do writing, not reading...<br>
<br>
<br>
> - For every block read, NFS requires XDR-decoding a protocol<br>
> header. This overhead is relatively small, especially if a large<br>
> block size is used (you want 8k / max. allowed by UDP). A large<br>
> block size also speeds up synchronous operation.<br>
Yes, but as i was able to understand from the last e-mails on the list, the<br>
Jumbo packets are not supported "out-of-the-box" today. Or am I wrong?<br>
<br>
<br>
> - The payload data is copied verbatim (w/o any byte-swapping<br>
> to the user's buffer). If the 'xdr_mbuf' stream is used then<br>
> the cost is similar to using normal UDP (copying from mbufs<br>
> into user buffer) -- otherwise data are copied twice (from<br>
> mbufs to NFS memory buffer, then again from there to user<br>
> buffer.<br>
> The behavior is compile-time configurable (nfsclient/src/rpcio.c)<br>
> -- by default a second copy operation is avoided.<br>
Great. Where can I read about all this?<br>
<br>
<br>
> -> If you use a large block size, read relatively large files<br>
> (>> NFS protocol header) and your current implementation<br>
> does not implement read-ahead/caching then I'd be surprised<br>
> if NFS is a lot slower. Nevertheless, you want to run a few<br>
> tests...<br>
Can you say something about "writes"? I suppose the same, yes?<br>
<br>
The last question - I need to be the NFS server (not client). Can you<br>
recommend something for this?<br>
<br>
Till, thank you very much for your time.<br>
--<br>
Leon<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <a href="http://www.rtems.org/pipermail/rtems-users/attachments/20090506/d1b41fdf/attachment-0001.html" target="_blank">http://www.rtems.org/pipermail/rtems-users/attachments/20090506/d1b41fdf/attachment-0001.html</a><br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Wed, 6 May 2009 15:11:34 +0200<br>
From: Axel von Engel <<a href="mailto:a.vonengel@gmail.com">a.vonengel@gmail.com</a>><br>
Subject: Code sharing in shared memory systems?<br>
To: <a href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a><br>
Message-ID:<br>
<<a href="mailto:44e01eee0905060611t7d9a9110n6238ef12f9619776@mail.gmail.com">44e01eee0905060611t7d9a9110n6238ef12f9619776@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
Hello everyone!<br>
<br>
I am developing a simulated multiprocessor system using MIPS cores,<br>
starting from a single processor system with RTEMS set up. Since the<br>
goal "simply" is to have a multiprocessor system running RTEMS with<br>
multiprocessing support (i.e. almost no design constraints), I<br>
currently look for options to achieve this.<br>
<br>
Shared memory seems to be the simplest way to communicate. In my<br>
current, very basic system the address space is shared, too. This<br>
leads to my question: Is it possible to run multiple RTEMS instances<br>
with the code being shared?<br>
<br>
My first impression is that it would be possible if I could find means<br>
to use different configuration tables depending on the current node<br>
ID. Any ideas on how this could be done? What else has to be<br>
separated?<br>
<br>
Regards<br>
Axel von Engel<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Wed, 6 May 2009 08:50:21 -0500<br>
From: Joel Sherrill <joel.sherrill@OARcorp.com><br>
Subject: Re: Code sharing in shared memory systems?<br>
To: Axel von Engel <<a href="mailto:a.vonengel@gmail.com">a.vonengel@gmail.com</a>><br>
Cc: "<a href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a>" <<a href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a>><br>
Message-ID: <<a href="mailto:4A01959D.70606@oarcorp.com">4A01959D.70606@oarcorp.com</a>><br>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed<br>
<br>
Axel von Engel wrote:<br>
> Hello everyone!<br>
><br>
> I am developing a simulated multiprocessor system using MIPS cores,<br>
> starting from a single processor system with RTEMS set up. Since the<br>
> goal "simply" is to have a multiprocessor system running RTEMS with<br>
> multiprocessing support (i.e. almost no design constraints), I<br>
> currently look for options to achieve this.<br>
><br>
> Shared memory seems to be the simplest way to communicate. In my<br>
> current, very basic system the address space is shared, too. This<br>
> leads to my question: Is it possible to run multiple RTEMS instances<br>
> with the code being shared?<br>
><br>
> My first impression is that it would be possible if I could find means<br>
> to use different configuration tables depending on the current node<br>
> ID. Any ideas on how this could be done? What else has to be<br>
> separated?<br>
><br>
><br>
The current mptests build the same source twice but they<br>
only differ in the node number. That is used to determine<br>
which node does what. That helps with the "same code image"<br>
issue but doesn't solve the problem of ensuring that<br>
each node has different addresses for .data, .bss, C program<br>
heap and workspace.<br>
<br>
For running them on psim, each CPU is an independent instance<br>
of a PowerPC with its own memory space. A block of unix shared<br>
memory is mapped into each CPU's address space for shared<br>
communication.<br>
<br>
There are 4 core LEON3 systems and they do a slightly different<br>
setup if I remember right. Link each node's code/data to a different<br>
area of memory and reserve part of the memory for communication<br>
between nodes.<br>
> Regards<br>
> Axel von Engel<br>
> _______________________________________________<br>
> rtems-users mailing list<br>
> <a href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a><br>
> <a href="http://www.rtems.org/mailman/listinfo/rtems-users" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-users</a><br>
><br>
<br>
<br>
--<br>
Joel Sherrill, Ph.D. Director of Research & Development<br>
joel.sherrill@OARcorp.com On-Line Applications Research<br>
Ask me about RTEMS: a free RTOS Huntsville AL 35805<br>
Support Available (256) 722-9985<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Wed, 6 May 2009 10:49:28 -0500<br>
From: Joel Sherrill <joel.sherrill@OARcorp.com><br>
Subject: warning question<br>
To: "<a href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a>" <<a href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a>><br>
Message-ID: <<a href="mailto:4A01B188.2070807@oarcorp.com">4A01B188.2070807@oarcorp.com</a>><br>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed<br>
<br>
Hi,<br>
<br>
I am looking at warnings and wondered if someone<br>
could figured this one out.<br>
<br>
c/src/libchip/network/i82586.c:1722: warning: suggest parentheses around<br>
operand of '!' or change '|' to '||' or '!' to '~'<br>
<br>
The code is clearly questionable IMO. ;)<br>
<br>
*IE_CMD_CFG_PROMISC(buf) = !!promiscuous | manchester << 2;<br>
<br>
Hopefully someone can help out.<br>
<br>
--<br>
Joel Sherrill, Ph.D. Director of Research & Development<br>
joel.sherrill@OARcorp.com On-Line Applications Research<br>
Ask me about RTEMS: a free RTOS Huntsville AL 35805<br>
Support Available (256) 722-9985<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
rtems-users mailing list<br>
<a href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a><br>
<a href="http://www.rtems.org/mailman/listinfo/rtems-users" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-users</a><br>
<br>
<br>
End of rtems-users Digest, Vol 32, Issue 6<br>
******************************************<br>
</blockquote></div><br>