<div dir="ltr">Hi all<div><br></div><div>I am more intrested in high level programming projects.Currently I am doing a project on wireless sensor networks in python.<br>So please suggest me some Open project matching with my skills<br><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div style="font-size:12.8px"><div>Thanks & regards,<br>Salil Sirotia,<br></div><div><span style="font-size:12.8px">Mtech,CSE-IS(Final Year),</span><br></div></div><span style="font-size:12.8px">IIT(ISM),Dhanbad</span><br></div></div></div></div></div>
<br><div class="gmail_quote">On Fri, Feb 23, 2018 at 8:27 AM, <span dir="ltr"><<a href="mailto:devel-request@rtems.org" target="_blank">devel-request@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-size:12px;color:#777;font-family:'Lucida Grande',Helvetica,Arial,sans-serif;background-color:#fff;padding:4px">
<a href="https://www.boxbe.com/overview" style="text-decoration:none;color:#5e96ea" target="_blank"><img alt="Boxbe" src="http://www.boxbe.com/images/logo_dark_small.png" width="64px" style="margin-left:0px;border:none"></a>
<img src="http://www.boxbe.com/stfopen?tc_serial=36942243920&tc_rand=1497184358&utm_source=stf&utm_medium=email&utm_campaign=ANNO_CLEANUP_ADD&utm_content=001">
This message is eligible for Automatic Cleanup! (<a href="mailto:devel-request@rtems.org" target="_blank">devel-request@rtems.org</a>)
<a style="text-decoration:none;color:#5e96ea" href="https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3DrgGJJzJx4Ue6j1tOq2VfMbPkpEIhsVMN%252BcIkqFRPOSY%253D%26token%3D0Ms05lrhnX4ZVx2f3yzg5nd3QNBUKqRtQH6IDgYjO%252BFF731etfRAta05zTEJJgQqLOaCDSZ0zbdJR1jaE0E2hFi1NWVnSEQkaverFiCvT717VPdQn%252BDnuvitdr%252F26IWDcGKKKelZkkVu6fpwVk8A0A%253D%253D&tc_serial=36942243920&tc_rand=1497184358&utm_source=stf&utm_medium=email&utm_campaign=ANNO_CLEANUP_ADD&utm_content=001" title="Add a new automatic cleanup rule" target="_blank">Add cleanup rule</a>
| <a style="text-decoration:none;color:#5e96ea" href="http://blog.boxbe.com/general/boxbe-automatic-cleanup?tc_serial=36942243920&tc_rand=1497184358&utm_source=stf&utm_medium=email&utm_campaign=ANNO_CLEANUP_ADD&utm_content=001" title="Get info on automatic cleanup" target="_blank">More info</a>
<br>
</div>
<br>Send devel mailing list submissions to<br>
<a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/devel</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:devel-request@rtems.org">devel-request@rtems.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:devel-owner@rtems.org">devel-owner@rtems.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of devel digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: GSOC 2018 (Christian Mauderer)<br>
2. Re: [PATCH 0/3] v3 - Paravirtualization Patch Series<br>
(Joel Sherrill)<br>
3. Re: [PATCH v3 2/3] Add ARM Paravirtualization support<br>
(Chris Johns)<br>
4. [PATCH] sb: Covert any unicode keys to strings (Chris Johns)<br>
5. [PATCH] sb: Convert any unicode keys to strings (Chris Johns)<br>
6. Re: [PATCH v3 2/3] Add ARM Paravirtualization support<br>
(Sebastian Huber)<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Thu, 22 Feb 2018 15:48:52 +0100<br>
From: Christian Mauderer <<a href="mailto:christian.mauderer@embedded-brains.de">christian.mauderer@embedded-<wbr>brains.de</a>><br>
To: <a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
Subject: Re: GSOC 2018<br>
Message-ID: <<a href="mailto:8257435e-3cba-80df-1f42-817959fc49a6@embedded-brains.de">8257435e-3cba-80df-1f42-<wbr>817959fc49a6@embedded-brains.<wbr>de</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
Am 22.02.2018 um 03:35 schrieb Salil Sirotia:<br>
> Hi all,<br>
><br>
> My name is Salil Sirotia and I'd like to be a part of RTEMS project for GSoC<br>
> 2018.<br>
><br>
> As of now, I have gone through 'Getting Started documentation'<br>
> available on the?<a href="http://devel.rteme.org" rel="noreferrer" target="_blank">devel.rteme.org</a> <<a href="http://devel.rteme.org/" rel="noreferrer" target="_blank">http://devel.rteme.org/</a>>?and have<br>
> managed to set up a working environment<br>
> for SPARC/ERC32.The wiki prospective students need to provide a proof<br>
> of setting up environemt,? i've sent a snapshot with the modefied Hello<br>
> World Test program after I ran it with ' sparc-rtems5-gdb ' as<br>
> shown on the wiki page. Please Do let me know if I need to provide<br>
> anything else .<br>
><br>
> I have modified the hello world Sample application and Now I want to<br>
> learn more things like Open Projects in RTEMS? Organization.<br>
> Would you like to suggest me some Open Projects that match my skills?<br>
> Any suggestion would be greatly appreciated.<br>
><br>
> I would love to work on any open projects.<br>
> My skills sets are :-<br>
> C,C++<br>
> Begineer in Python,Java<br>
><br>
><br>
<br>
Hello Salil,<br>
<br>
first of all: Welcome to RTEMS.<br>
<br>
It really depends on what you would like to do. For some open projects,<br>
you can have a look at the OpenProjects page in the wiki:<br>
<br>
<a href="https://devel.rtems.org/wiki/Developer/OpenProjects" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/<wbr>Developer/OpenProjects</a><br>
<br>
If you see something that interests you, just start to discuss it on the<br>
mailing list. If you have some ideas of your own you can discuss them too.<br>
<br>
If you can't decide, it would be useful if you could tell us something<br>
more about your interests and experience. Are you interested more in<br>
high-level programming or something as close to hardware as possible?<br>
Did your already use some embedded boards like Beagle or Raspberry?<br>
<br>
Kind regards<br>
<br>
Christian Mauderer<br>
<br>
--<br>
------------------------------<wbr>--------------<br>
embedded brains GmbH<br>
Herr Christian Mauderer<br>
Dornierstr. 4<br>
D-82178 Puchheim<br>
Germany<br>
email: <a href="mailto:christian.mauderer@embedded-brains.de">christian.mauderer@embedded-<wbr>brains.de</a><br>
Phone: +49-89-18 94 741 - 18<br>
Fax: +49-89-18 94 741 - 08<br>
PGP: Public key available on request.<br>
<br>
Diese Nachricht ist keine gesch?ftliche Mitteilung im Sinne des EHUG.<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Thu, 22 Feb 2018 10:57:46 -0600<br>
From: Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a>><br>
To: Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-<wbr>brains.de</a>><br>
Cc: devel <<a href="mailto:devel@rtems.org">devel@rtems.org</a>><br>
Subject: Re: [PATCH 0/3] v3 - Paravirtualization Patch Series<br>
Message-ID:<br>
<CAF9ehCUuyEj+Tqct1w3x29+<wbr>2Zgd99Q=<a href="mailto:aXzYqj6i0_MVZ-6XQHQ@mail.gmail.com">aXzYqj6i0_MVZ-6XQHQ@<wbr>mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On Thu, Feb 22, 2018 at 5:42 AM, Sebastian Huber <<br>
<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-<wbr>brains.de</a>> wrote:<br>
<br>
> ----- Am 22. Feb 2018 um 6:06 schrieb Chris Johns <a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>:<br>
><br>
> > On 22/02/2018 13:37, Sebastian Huber wrote:<br>
> >>><br>
> >>> Architecture-specific names should use an ARCH_ or _Arch prefix and<br>
> not CPU_ARCH<br>
> >>> or _CPU_Arch.<br>
> >>><br>
> >>> This<br>
> >>><br>
> >>> CPU_DISABLE_INLINE_ISR_<wbr>DISABLE_ENABLE<br>
> >>><br>
> >>> is an architecture-specific implementation detail which doesn't<br>
> propagate to<br>
> >>> generic files, e.g. rtems/score/isrlevel.h, so it should not be<br>
> introduced from<br>
> >>> my point of view.<br>
><br>
> OK. I can add an architecture to the constant but my hope was that<br>
isrlevel.h would eventually be where the cut off to the paravirtualized<br>
ISR disable/enable methods would be made.<br>
<br>
<br>
> >>> I don't think it is worth to add a rtems/score/paravirt.h for each<br>
> architecture.<br>
> >>> The changes introduced by RTEMS_PARAVIRT are too small to justify<br>
> this. I am<br>
> >>> also not sure if you can encapsulate this in one header in all cases.<br>
> >><br>
> >> Please don't ignore this.<br>
> >><br>
> ><br>
> > I felt spreading the RTEMS_PARAVIRT across the code was hiding the<br>
> reason in<br>
> > some cases. When I reviewed the v2 patches I felt changes in a specific<br>
> area<br>
> > needed more information to aid long term maintenance. For example look<br>
> at the<br>
> > ARM thread id register. It is clear what is happening and if that change<br>
> flows<br>
> > out to other parts of the system it is clear what is happening if there<br>
> is a<br>
> > dependence on that register.<br>
><br>
> Yes, this is all right, but do we really need a special header file for<br>
> this? We can do this in one area of cpu.h or cpuimpl.h.<br>
><br>
<br>
It might be able to go near the top of cpu.h. But the inclusion of<br>
paravirt.h is already<br>
wrapped in a conditional so it isn't impacting normal compiles.<br>
<br>
Given that this file exists to specifically map an RTEMS configuration onto<br>
architectural tweaks and document them, I still think they should be in<br>
their<br>
own file. Putting it at the top of cpu.h is likely technically feasible but<br>
doesn't<br>
achieve the goal of having a clear place to document paravirtualization<br>
tweaks, etc.<br>
<br>
<br>
><br>
> One long term goal is to reduce the implementation details visible via<br>
> <rtems.h> and move more and more stuff into cpuimpl.h. This paravirt.h is a<br>
> step back under this point of view.<br>
><br>
<br>
It was actually hiding the reason for the conditional in all cases.<br>
<br>
Chris' suggestion was because none of this can be tested without special<br>
setups which are not generally available. Plus it is completely undocumented<br>
what the host restrictions and requirements were that led to the<br>
conditionals<br>
being put in place.<br>
<br>
This header file is primarily to document (and do a good job of it) the<br>
paravirtualization changes. Your thread id response is a perfect example.<br>
The need to compile with that option should have been documented. As<br>
the code is today, the definition of that register is only implied by<br>
a GCC architectural revision. The register is indeed present in our<br>
paravirtualized environment but we can't set it because it can't<br>
be set in user mode. You already solved this problem and could<br>
have even provided the helper routine for paravirtualized environments.<br>
<br>
Scattering around a bunch of undocumented tweaks without a<br>
way to document them is bad. Especially when only the person<br>
who did the paravirtualization adapter for a specific host knows the<br>
details.<br>
<br>
I agreed with Chris that in-code documentation was the answer<br>
and providing a nice container for it was the answer.<br>
<br>
Having paravirt.h could have the configure process give you an<br>
error if the architecture doesn't have it -- which implies it doesn't<br>
support it.<br>
<br>
--joel<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.rtems.org/pipermail/devel/attachments/20180222/343c4d48/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>pipermail/devel/attachments/<wbr>20180222/343c4d48/attachment-<wbr>0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Fri, 23 Feb 2018 12:32:00 +1100<br>
From: Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>><br>
To: Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-<wbr>brains.de</a>>, joel<br>
<<a href="mailto:joel@rtems.org">joel@rtems.org</a>><br>
Cc: devel <<a href="mailto:devel@rtems.org">devel@rtems.org</a>><br>
Subject: Re: [PATCH v3 2/3] Add ARM Paravirtualization support<br>
Message-ID: <<a href="mailto:4b0ada16-f114-1dab-1372-b5fb08e40421@rtems.org">4b0ada16-f114-1dab-1372-<wbr>b5fb08e40421@rtems.org</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
On 22/02/2018 22:39, Sebastian Huber wrote:<br>
> For the XtratuM support on ARMv7-R I simply built the tools via the RSB and added "-mtp=soft" to the C/C++ flags. I also used "-mtp=soft" for the BSP, this instructs GCC to use calls to __aeabi_read_tp().<br>
<br>
I had no idea this was the case.<br>
<br>
On ARM or to be more specific on ARM SMP builds the thread ID will have to be<br>
set to the thread TCB on ARM SMP machines by the context switcher. It is needed<br>
to support libdebugger on SMP for stepping to work.<br>
<br>
Chris<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Fri, 23 Feb 2018 12:59:51 +1100<br>
From: Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>><br>
To: <a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
Subject: [PATCH] sb: Covert any unicode keys to strings<br>
Message-ID: <<a href="mailto:20180223015951.68196-1-chrisj@rtems.org">20180223015951.68196-1-<wbr>chrisj@rtems.org</a>><br>
<br>
Closes #3312<br>
---<br>
source-builder/sb/macros.py | 6 +++---<br>
1 file changed, 3 insertions(+), 3 deletions(-)<br>
<br>
diff --git a/source-builder/sb/macros.py b/source-builder/sb/macros.py<br>
index 28a52b2..cf25783 100644<br>
--- a/source-builder/sb/macros.py<br>
+++ b/source-builder/sb/macros.py<br>
@@ -150,7 +150,7 @@ class macros:<br>
def __setitem__(self, key, value):<br>
key = self._unicode_to_str(key)<br>
if type(key) is not str:<br>
- raise TypeError('bad key type (want str): %s' % (type(key)))<br>
+ raise TypeError('bad key type (want str): %s (%s)' % (type(key), key))<br>
if type(value) is not tuple:<br>
value = self._unicode_to_str(value)<br>
if type(value) is str:<br>
@@ -396,6 +396,7 @@ class macros:<br>
(path.host(self.expand(name)))<wbr>)<br>
<br>
def get(self, key, globals = True, maps = None):<br>
+ key = self._unicode_to_str(key)<br>
if type(key) is not str:<br>
raise TypeError('bad key type: %s' % (type(key)))<br>
key = self.key_filter(key)<br>
@@ -435,11 +436,10 @@ class macros:<br>
return self.get_attribute(key) == 'override'<br>
<br>
def define(self, key, value = '1'):<br>
- if type(key) is not str:<br>
- raise TypeError('bad key type: %s' % (type(key)))<br>
self.__setitem__(key, ('none', 'none', value))<br>
<br>
def undefine(self, key):<br>
+ key = self._unicode_to_str(key)<br>
if type(key) is not str:<br>
raise TypeError('bad key type: %s' % (type(key)))<br>
key = self.key_filter(key)<br>
--<br>
2.14.1<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Fri, 23 Feb 2018 13:04:18 +1100<br>
From: Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>><br>
To: <a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
Subject: [PATCH] sb: Convert any unicode keys to strings<br>
Message-ID: <<a href="mailto:20180223020418.68287-1-chrisj@rtems.org">20180223020418.68287-1-<wbr>chrisj@rtems.org</a>><br>
<br>
Closes #3313<br>
---<br>
source-builder/sb/macros.py | 6 +++---<br>
1 file changed, 3 insertions(+), 3 deletions(-)<br>
<br>
diff --git a/source-builder/sb/macros.py b/source-builder/sb/macros.py<br>
index 28a52b2..cf25783 100644<br>
--- a/source-builder/sb/macros.py<br>
+++ b/source-builder/sb/macros.py<br>
@@ -150,7 +150,7 @@ class macros:<br>
def __setitem__(self, key, value):<br>
key = self._unicode_to_str(key)<br>
if type(key) is not str:<br>
- raise TypeError('bad key type (want str): %s' % (type(key)))<br>
+ raise TypeError('bad key type (want str): %s (%s)' % (type(key), key))<br>
if type(value) is not tuple:<br>
value = self._unicode_to_str(value)<br>
if type(value) is str:<br>
@@ -396,6 +396,7 @@ class macros:<br>
(path.host(self.expand(name)))<wbr>)<br>
<br>
def get(self, key, globals = True, maps = None):<br>
+ key = self._unicode_to_str(key)<br>
if type(key) is not str:<br>
raise TypeError('bad key type: %s' % (type(key)))<br>
key = self.key_filter(key)<br>
@@ -435,11 +436,10 @@ class macros:<br>
return self.get_attribute(key) == 'override'<br>
<br>
def define(self, key, value = '1'):<br>
- if type(key) is not str:<br>
- raise TypeError('bad key type: %s' % (type(key)))<br>
self.__setitem__(key, ('none', 'none', value))<br>
<br>
def undefine(self, key):<br>
+ key = self._unicode_to_str(key)<br>
if type(key) is not str:<br>
raise TypeError('bad key type: %s' % (type(key)))<br>
key = self.key_filter(key)<br>
--<br>
2.14.1<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Fri, 23 Feb 2018 03:58:47 +0100 (CET)<br>
From: Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-<wbr>brains.de</a>><br>
To: Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>><br>
Cc: devel <<a href="mailto:devel@rtems.org">devel@rtems.org</a>><br>
Subject: Re: [PATCH v3 2/3] Add ARM Paravirtualization support<br>
Message-ID:<br>
<<a href="mailto:411038642.36489.1519354727816.JavaMail.zimbra@embedded-brains.de">411038642.36489.<wbr>1519354727816.JavaMail.zimbra@<wbr>embedded-brains.de</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
----- Am 23. Feb 2018 um 2:32 schrieb Chris Johns <a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>:<br>
<br>
> On 22/02/2018 22:39, Sebastian Huber wrote:<br>
>> For the XtratuM support on ARMv7-R I simply built the tools via the RSB and<br>
>> added "-mtp=soft" to the C/C++ flags. I also used "-mtp=soft" for the BSP, this<br>
>> instructs GCC to use calls to __aeabi_read_tp().<br>
><br>
> I had no idea this was the case.<br>
<br>
This is a workaround for an XtratuM shortcoming. A proper hypervisor would support a hypercall to set the TPIDRURO.<br>
<br>
><br>
> On ARM or to be more specific on ARM SMP builds the thread ID will have to be<br>
> set to the thread TCB on ARM SMP machines by the context switcher. It is needed<br>
> to support libdebugger on SMP for stepping to work.<br>
<br>
This is fine.<br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
______________________________<wbr>_________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/devel</a><br>
<br>
------------------------------<br>
<br>
End of devel Digest, Vol 75, Issue 41<br>
******************************<wbr>*******<br>
<br></blockquote></div><br></div></div></div>