For uniprocessor we have a complete ready JPF model for solving nested
mutex problem.
JPF-Code: https://github.com/saurabhgadia4/lock-model/tree/rtemsjpf-0.1
Avoid unwanted irrelevant commit messages!! The code is still in raw stage
but solves all the potential cases of nested mutex problem.
For
Hi,
Is there any explicit locking to avoid data races condition on members of
Thread_Control_struct in rtems? As for mutex we have ticket_lock over its
wait_queue in SMP architecture which can serve as explicit locking in
mutex. For thread I feel data race condition may happen while setting
*thread
Premysel.. can you update the patch to account for this?
It is OK to commit after that.
--joel
On 7/15/2015 3:01 PM, Martin Galvan wrote:
Oh, and one more thing: before commiting, please fix a typo
('prescaller' should be 'prescaler') and the const issue Daniel
pointed out :)
_
On 7/15/2015 2:51 PM, Martin Galvan wrote:
On Wed, Jul 15, 2015 at 3:33 PM, Pavel Pisa wrote:
Hello Martin,
Try to help us when we try to do TMS570 RTEMS work based
on my belief that it worth to be done for RTEMS but
without any actual or directly foreseen project/funding
backup. Try the c
Yes, those and add a comment regarding the reason for the change in
the source in case someone wanders across it randomly.
On Wed, Jul 15, 2015 at 4:01 PM, Martin Galvan
wrote:
> Oh, and one more thing: before commiting, please fix a typo
> ('prescaller' should be 'prescaler') and the const issue
Oh, and one more thing: before commiting, please fix a typo
('prescaller' should be 'prescaler') and the const issue Daniel
pointed out :)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
On Wed, Jul 15, 2015 at 3:33 PM, Pavel Pisa wrote:
> Hello Martin,
> Try to help us when we try to do TMS570 RTEMS work based
> on my belief that it worth to be done for RTEMS but
> without any actual or directly foreseen project/funding
> backup. Try the code it would ease and shorten this
> dis
Hello Joel,
On Wednesday 15 of July 2015 20:05:12 Joel Sherrill wrote:
> On 7/15/2015 12:30 PM, Martin Galvan wrote:
> > On Wed, Jul 15, 2015 at 12:22 PM, Pavel Pisa
wrote:
> >> Patch provides way to the previous working state at least.
> >> I would suggest to apply this patch because current ma
Hello Martin,
On Wednesday 15 of July 2015 19:30:55 Martin Galvan wrote:
> On Wed, Jul 15, 2015 at 12:22 PM, Pavel Pisa wrote:
> > Patch provides way to the previous working state at least.
> > I would suggest to apply this patch because current mainline is broken
> > in actual state - time read
On 7/15/2015 12:30 PM, Martin Galvan wrote:
On Wed, Jul 15, 2015 at 12:22 PM, Pavel Pisa wrote:
Patch provides way to the previous working state at least.
I would suggest to apply this patch because current mainline is broken
in actual state - time read goes totally unrelated to the delay fun
On Wed, Jul 15, 2015 at 12:22 PM, Pavel Pisa wrote:
> Patch provides way to the previous working state at least.
> I would suggest to apply this patch because current mainline is broken
> in actual state - time read goes totally unrelated to the delay functions.
Could you elaborate a bit more on
Hello Martin and others,
new proposal for TMS570 headers update can be found
in branch "tms570-bsp-new-headers" of Premysl Houdek's
RTEMS development repository
https://github.com/AoLaD/rtems
https://github.com/AoLaD/rtems/tree/tms570-bsp-new-headers/c/src/lib/libbsp/arm/tms570/include
The
On 7/15/2015 10:39 AM, Gedare Bloom wrote:
the comments on the CPP lines.
OK.. but is this a valid technical solution ignoring the
style nits? :)
On Wed, Jul 15, 2015 at 11:31 AM, Joel Sherrill
wrote:
OK but what about the patch itself technically?
It was only subtracting a blank line so
the comments on the CPP lines.
On Wed, Jul 15, 2015 at 11:31 AM, Joel Sherrill
wrote:
> OK but what about the patch itself technically?
>
> It was only subtracting a blank line so once I fix that,
> what else?
>
>
> On 7/15/2015 2:59 AM, Sebastian Huber wrote:
>>
>> I tried to clarify the rules f
OK but what about the patch itself technically?
It was only subtracting a blank line so once I fix that,
what else?
On 7/15/2015 2:59 AM, Sebastian Huber wrote:
I tried to clarify the rules for FreeBSD code changes:
https://git.rtems.org/rtems-libbsd/commit/?id=a57dfa0dedc1f25c4dfd6e0c786a1dbf
Hello Martin,
On Wednesday 15 of July 2015 16:58:02 Martin Galvan wrote:
> On Wed, Jul 15, 2015 at 11:41 AM, Pavel Pisa wrote:
> > the code has been tested for internal RAM now.
> > We have more cleanups in the mind but headers are critical
> > for now. Premek is working on that, time for feedbac
On Wed, Jul 15, 2015 at 11:41 AM, Pavel Pisa wrote:
> the code has been tested for internal RAM now.
> We have more cleanups in the mind but headers are critical
> for now. Premek is working on that, time for feedback
> form previous e-mail passed without input so he plans
> to send prepared chang
Hello Martin and others,
On Wednesday 15 of July 2015 15:37:28 Martin Galvan wrote:
> Hello Premysl! Thanks for this patch.
>
> Could you tell us why is this patch needed, and where does the new
> formula come from? From what I saw, HALCoGen generates a macro called
> RTI_FREQ which has the value
On Wed, Jul 15, 2015 at 8:46 AM, Premysl Houdek wrote:
> Signed-off-by: Premysl Houdek
> ---
> c/src/lib/libbsp/arm/tms570/clock/clock.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/c/src/lib/libbsp/arm/tms570/clock/clock.c
> b/c/src/lib/libbsp/arm/tms570/cl
Hello Premysl! Thanks for this patch.
Could you tell us why is this patch needed, and where does the new
formula come from? From what I saw, HALCoGen generates a macro called
RTI_FREQ which has the value from the previous version of the formula
(i.e. if BSP_PLL_OUT_CLOCK == 180 MHz, RTI_FREQ == 90
in case anyone else hit this..
-- Forwarded message --
From: Michael Meissner
Date: Tue, Jul 14, 2015 at 8:09 PM
Subject: [PR 66854 powerpc regression] Fix RTEMS powerpc build issue
To: gcc-patc...@gcc.gnu.org, dje@gmail.com
My IEEE 128-bit floating point infrastructure pat
Signed-off-by: Premysl Houdek
---
c/src/lib/libbsp/arm/tms570/clock/clock.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/c/src/lib/libbsp/arm/tms570/clock/clock.c
b/c/src/lib/libbsp/arm/tms570/clock/clock.c
index 98ee5d9..0770570 100644
--- a/c/src/lib/libbsp/arm/
> On Jul 15, 2015, at 05:17 , Pavel Pisa wrote:
>
>
> void *calloc(size_t nmemb, size_t size) \
>__attribute__ ((optimize("no-builtin")));
Oh-oh, now this mailing list is recursing! Check Joel’s earlier post.
Peter
-
Peter Dufault
HD Associates, Inc. Software and Sy
Hello Chris and others,
On Wednesday 15 of July 2015 09:48:34 Chris Johns wrote:
> On 15/07/2015 4:50 pm, Sebastian Huber wrote:
> > I didn't file a PR, only asked on the mailing list. My impression is
> > that this is not a bug, but a feature that must be disabled by C library
> > developers.
>
>
I tried to clarify the rules for FreeBSD code changes:
https://git.rtems.org/rtems-libbsd/commit/?id=a57dfa0dedc1f25c4dfd6e0c786a1dbf72f44a03
On 15/07/15 00:42, Joel Sherrill wrote:
---
freebsd/sys/contrib/altq/altq/altq_subr.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
On 15/07/2015 4:50 pm, Sebastian Huber wrote:
>
> I didn't file a PR, only asked on the mailing list. My impression is
> that this is not a bug, but a feature that must be disabled by C library
> developers.
A compiler that optimises to a infinite recursive loop for code that is
ok and not pushin
26 matches
Mail list logo
