#if defined(RTEMS_SMP)
RTEMS_INLINE_ROUTINE void _Thread_Lock_restore_default(
Thread_Control *the_thread
)
{
_Atomic_Fence( ATOMIC_ORDER_RELEASE );
_Thread_Lock_set_unprotected( the_thread, &the_thread->Lock.Default );
}
what does this atomic fence does when we set Lock.current=Default in
As per thread initialization in threadinitialize.c we should acquire
default lock i.e the_thread->Lock.Default. Am I right?
Thanks,
Saurabh Gadia
On Thu, Jul 23, 2015 at 6:58 PM, Saurabh Gadia wrote:
> basically every time we try to acquire mutex there should be lock
> acquisition related exec
basically every time we try to acquire mutex there should be lock
acquisition related executing thread.
Thanks,
Saurabh Gadia
On Thu, Jul 23, 2015 at 6:47 PM, Saurabh Gadia wrote:
> hi,
>
>
> Scenario:
> thread t1: current_priority = 5, mutex acquired = m1, m2
> thread t2: current_priority = 3
hi,
Scenario:
thread t1: current_priority = 5, mutex acquired = m1, m2
thread t2: current_priority = 3, mutex_acquired = None
flow: thread t1 tries to acquire mutex m3 and thread t2 tries to acquire
mutex m1 which is already acquired by thread t1 simultaneously on SMP.
Action:
thred t1 finds th
There is a bit of weirdness in the way that ST generates code from Cube. First,
they create a main.c file for you with a main() routine. Nice, but it conflicts
with the way that RTEMS uses Init() as a user entry point.
Next, they put all of the highest level code into a directory called Src.
Th
On Tue, Jun 23, 2015 at 4:27 PM, Rohini Kulkarni
wrote:
>
>
>
> On Tue, Jun 23, 2015 at 1:44 PM, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> Please avoid unnecessary white-space changes and white-space at the end
>> of line.
>>
>> Something went wrong with the whitespace.
On Jun 23, 2015, at 8:30 PM, Gene Smith wrote:
> On 06/23/2015 02:18 PM, Joel Sherrill wrote:
>>
>>
>> On 6/23/2015 1:09 PM, Gene Smith wrote:
>>>
>>> Here's the things I did to fix the Makefile. I think you added the
>>> quotes (item 1) and maybe item 2. I think the error you are seeing is
>
Since a fresh git pull of the RTEMS master this morning (CET), I’ve been having
trouble building various components. Building the xilinx-zynq-zedboard with
—enable-smp ends with failing to build sptls01 (which had no trouble
yesterday):
cpukit/score/cpu/arm/__tls_get_addr.c:28: undefined refe
On 7/23/2015 8:54 AM, Sebastian Huber wrote:
On 23/07/15 15:49, Joel Sherrill wrote:
Is this intended for master only or also for the 4.11 branch?
This is for the master only if you ask me.
OK. I hoped so. :)
I have deferred saying much about post 4.11 but I would like
to propose a few t
On 23/07/15 15:49, Joel Sherrill wrote:
Is this intended for master only or also for the 4.11 branch?
This is for the master only if you ask me.
--
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
Is this intended for master only or also for the 4.11 branch?
On 7/23/2015 7:54 AM, Sebastian Huber wrote:
https://lists.rtems.org/pipermail/devel/2015-July/011989.html
Its fully functional and well tested. It is based on the FreeBSD support:
https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/i
All,
I have a few basic questions that I was wondering if someone could give
me some pointers on.
My colleagues and I are working on a new RTEMS BSP to support various
Cortex-M series processors in the STM32F series. ST provides a nice
hardware abstraction layer that is common for all their
Hello Sebastian,
On Thursday 23 of July 2015 13:31:23 Sebastian Huber wrote:
> Hello Pavel,
>
> thanks for your comments.
>
> On 23/07/15 12:40, Pavel Pisa wrote:
> > Hello Sebastian,
...
> > I fully understand your motivation and for small footprint system
> > the direct pointers use is most effi
This enables external libraries to use thread locks since they are
independent of the actual RTEMS build configuration, e.g. profiling
enabled or disabled.
---
cpukit/score/include/rtems/score/thread.h | 20 ++-
cpukit/score/include/rtems/score/threadimpl.h | 80 -
Use a leading underscore in the structure name to allow forward
declarations in standard header files provided by Newlib and GCC.
---
cpukit/score/include/rtems/score/threadq.h | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/cpukit/score/include/rtems/score/threadq.h
b/
This mutex implementation uses a thread priority queue with a simple
priority inheritance mechanism (similar to the object based mutexes)
without support for timeouts. The storage space must be supplied by the
user (16 bytes on 32-bit targets).
---
cpukit/configure.ac|
---
cpukit/score/Makefile.am | 1 +
cpukit/score/src/sched.c | 70 ++
testsuites/sptests/spsyslock01/init.c | 17 +++
testsuites/sptests/spsyslock01/spsyslock01.doc | 5 ++
4 files changed, 93 insertions(+)
create
https://lists.rtems.org/pipermail/devel/2015-July/011989.html
Its fully functional and well tested. It is based on the FreeBSD support:
https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/include/machine/rtems-bsd-muteximpl.h
https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/rtems/rtems-bsd-muteximp
---
cpukit/libmisc/monitor/mon-prmisc.c| 1 +
cpukit/score/Makefile.am | 1 +
cpukit/score/include/rtems/score/statesimpl.h | 3 +
cpukit/score/src/futex.c | 174 +
testsuites/sptests/spsyslock01/init.c
---
cpukit/libmisc/monitor/mon-prmisc.c| 1 +
cpukit/score/Makefile.am | 1 +
cpukit/score/include/rtems/score/statesimpl.h | 3 +
cpukit/score/src/semaphore.c | 118 +
testsuites/sptests/spsyslock01/init.c
Add a leading underscore to the structure name to allow forward
declarations in standard header files provided by Newlib and GCC.
---
cpukit/score/include/rtems/score/percpu.h | 10 +-
cpukit/score/include/rtems/score/thread.h | 5 -
cpukit/score/include/rtems/score/threadq.h | 2 +
These SMP lock statistics are used for all lock objects that lack a
storage space for the statistics. Examples are lock objects used in
external libraries which are independent of the actual RTEMS build
configuration.
---
cpukit/score/include/rtems/score/thread.h | 12
cpukit/score/s
On 23/07/15 13:51, Joel Sherrill wrote:
On 7/23/2015 6:36 AM, Sebastian Huber wrote:
On 23/07/15 12:29, Chris Johns wrote:
I feel this needs to be a real API not a pseudo-internal API. Making
this an API means the project agrees to support the API, it has tests
and we have to make sure it i
On 7/23/2015 6:36 AM, Sebastian Huber wrote:
On 23/07/15 12:29, Chris Johns wrote:
I feel this needs to be a real API not a pseudo-internal API. Making
this an API means the project agrees to support the API, it has tests
and we have to make sure it is working for a release. Oh and it has
docu
Hello Pavel,
thanks for your comments.
On 23/07/15 12:40, Pavel Pisa wrote:
Hello Sebastian,
the first big thanks for RTEMS architectural updates.
On Thursday 23 of July 2015 11:16:03 Sebastian Huber wrote:
The Classic RTEMS and POSIX APIs have at least three weaknesses.
* Dynamic memory (t
On 23/07/15 12:29, Chris Johns wrote:
I feel this needs to be a real API not a pseudo-internal API. Making
this an API means the project agrees to support the API, it has tests
and we have to make sure it is working for a release. Oh and it has
documentation.
For an API I suggest to use C11/C++
Hello Sebastian,
the first big thanks for RTEMS architectural updates.
On Thursday 23 of July 2015 11:16:03 Sebastian Huber wrote:
> The Classic RTEMS and POSIX APIs have at least three weaknesses.
>
> * Dynamic memory (the workspace) is used to allocate object pools. This
>requires a complex
It lists an IP address in AU (144.132.189.169) as the one that
spamhaus doesn't like.
http://ipaddress.is/144.132.189.1#.VbDDtPlViko
I am on a corporate guest network in the UK but sent that via OAR.
So I think something at Telstra is at fault this time.
What do you think?
--joel
On 7/23/2015
Spam detection software, running on the system "corb.contemporary.net.au",
has identified this incoming email as possible spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
The administrator of that system for deta
Spam detection software, running on the system "corb.contemporary.net.au",
has identified this incoming email as possible spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
The administrator of that system for deta
On Jul 22, 2015, at 05:50 AM, Pavel Pisa wrote:
Hello Qiao Yang,
On Wednesday 22 of July 2015 11:19:35 QIAO YANG wrote:
Hi,
When I updated to the latest firmware start.elf , the graphic doesn’t show
anymore. I haven’t yet found out what has been changed in the latest
firmware. I’ve uploaded my
The Classic RTEMS and POSIX APIs have at least three weaknesses.
* Dynamic memory (the workspace) is used to allocate object pools. This
requires a complex configuration with heavy use of the C pre-processor.
* Objects are created via function calls which return an object identifier.
The obj
On 7/23/2015 4:02 AM, Nick Withers wrote:
On Thu, 2015-07-23 at 03:20 -0500, Joel Sherrill wrote:
On 7/23/2015 3:17 AM, Nick Withers wrote:
On Thu, 2015-07-23 at 02:50 -0500, Joel Sherrill wrote:
Hi
I was test building on FreeBSD and noticed a couple of issues.
+ none of the m68k BSPs lin
On Thu, 2015-07-23 at 03:20 -0500, Joel Sherrill wrote:
>
> On 7/23/2015 3:17 AM, Nick Withers wrote:
> > On Thu, 2015-07-23 at 02:50 -0500, Joel Sherrill wrote:
> >> Hi
> >>
> >> I was test building on FreeBSD and noticed a couple of issues.
> >>
> >> + none of the m68k BSPs link. Fixing this now
On Jul 21, 2015, at 09:51 PM, Pavel Pisa wrote:
Hello Qiao Yang
On Tuesday 21 of July 2015 14:21:07 QIAO YANG wrote:
Hi Pavel Pisa,
On Jul 19, 2015, at 10:35 PM, Pavel Pisa wrote:
Hello Chris and Qiao Yang,
On Monday 20 of July 2015 01:12:33 Chris Johns wrote:
On 20/07/2015 6:55 am, QIAO Y
On 7/23/2015 3:17 AM, Nick Withers wrote:
On Thu, 2015-07-23 at 02:50 -0500, Joel Sherrill wrote:
Hi
I was test building on FreeBSD and noticed a couple of issues.
+ none of the m68k BSPs link. Fixing this now.
+ mips tools do not build
Anyone else notice any other issues or have comments?
On Thu, 2015-07-23 at 02:50 -0500, Joel Sherrill wrote:
> Hi
>
> I was test building on FreeBSD and noticed a couple of issues.
>
> + none of the m68k BSPs link. Fixing this now.
>
> + mips tools do not build
>
> Anyone else notice any other issues or have comments?
The only thing I've got is:
Hi
I was test building on FreeBSD and noticed a couple of issues.
+ none of the m68k BSPs link. Fixing this now.
+ mips tools do not build
Anyone else notice any other issues or have comments?
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.com
This avoids the "0x0xabc" output and is more compact.
---
cpukit/libmisc/monitor/mon-prmisc.c | 4 ++--
cpukit/libmisc/monitor/monitor.h| 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/cpukit/libmisc/monitor/mon-prmisc.c
b/cpukit/libmisc/monitor/mon-prmisc.c
index 1b3a4d
---
cpukit/libmisc/monitor/mon-task.c | 36 +++-
cpukit/libmisc/monitor/monitor.h | 3 ++-
2 files changed, 21 insertions(+), 18 deletions(-)
diff --git a/cpukit/libmisc/monitor/mon-task.c
b/cpukit/libmisc/monitor/mon-task.c
index 851c593..57f506e 100644
--- a/c
---
cpukit/libmisc/monitor/mon-task.c | 8 ++--
cpukit/libmisc/monitor/monitor.h | 1 +
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/cpukit/libmisc/monitor/mon-task.c
b/cpukit/libmisc/monitor/mon-task.c
index 57f506e..0d65557 100644
--- a/cpukit/libmisc/monitor/mon-task.c
+
---
cpukit/libmisc/monitor/mon-prmisc.c | 16
cpukit/libmisc/monitor/mon-task.c | 23 +--
cpukit/libmisc/monitor/monitor.h| 3 ---
3 files changed, 1 insertion(+), 41 deletions(-)
diff --git a/cpukit/libmisc/monitor/mon-prmisc.c
b/cpukit/libmisc/monito
---
cpukit/libmisc/monitor/mon-prmisc.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/cpukit/libmisc/monitor/mon-prmisc.c
b/cpukit/libmisc/monitor/mon-prmisc.c
index f0d6b00..738014f 100644
--- a/cpukit/libmisc/monitor/mon-prmisc.c
+++ b/cpuk
43 matches
Mail list logo
