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