devel Digest, Vol 75, Issue 41

yao0718 29171383 at qq.com
Fri Feb 23 18:18:35 UTC 2018


micropython or lua,you can find micropyhon port for rtems on ESA,if you choice lua,you can find elua on github

------------------ Original ------------------
From: "Salil Sirotia" <salil.sirotia at gmail.com>;
Date: Sat, Feb 24, 2018 01:19 AM
To: "devel" <devel at rtems.org>;
Subject: Re: devel Digest, Vol 75, Issue 41



Hi all

I am more intrested in high level programming projects.Currently I am doing a project on wireless sensor networks in python.
So please suggest me some Open project matching with my skills

Thanks & regards,
Salil Sirotia,

Mtech,CSE-IS(Final Year),


IIT(ISM),Dhanbad





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


More information about the devel mailing list