Re: Doubt regarding Thread_Control_struct in rtems
On 16/07/15 01:49, Saurabh Gadia wrote: 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->current_priority. *As it is updated by thread while restoring its priority and while some other thread trying to promote for nested_mutex behavior. There is no data race condition, see _Thread_Change_priority() and Thread_Lock_control. There is a potential problem with a deadlock at spin lock level however, in case the application provokes a deadlock at object level. This needs some further investigation. -- 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-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] Fix buiding for the i386.
---
freebsd/sys/contrib/altq/altq/altq_subr.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/freebsd/sys/contrib/altq/altq/altq_subr.c
b/freebsd/sys/contrib/altq/altq/altq_subr.c
index 3ebd58d..cfa5c7e 100644
--- a/freebsd/sys/contrib/altq/altq/altq_subr.c
+++ b/freebsd/sys/contrib/altq/altq/altq_subr.c
@@ -292,7 +292,7 @@ altq_disable(ifq)
ASSERT(ifq->ifq_len == 0);
ifq->altq_flags &= ~(ALTQF_ENABLED|ALTQF_CLASSIFY);
splx(s);
-
+
IFQ_UNLOCK(ifq);
return 0;
}
@@ -379,7 +379,7 @@ tbr_set(ifq, profile)
struct tb_profile *profile;
{
struct tb_regulator *tbr, *otbr;
-
+
if (tbr_dequeue_ptr == NULL)
tbr_dequeue_ptr = tbr_dequeue;
@@ -930,6 +930,7 @@ init_machclk_setup(void)
#if defined(__NetBSD__) && defined(MULTIPROCESSOR)
machclk_usepcc = 0;
#endif
+#if !defined(__rtems__)
#if defined(__amd64__) || defined(__i386__)
/* check if TSC is available */
#ifdef __FreeBSD__
@@ -938,6 +939,7 @@ init_machclk_setup(void)
#else
if ((cpu_feature & CPUID_TSC) == 0)
#endif
+#endif /* __rtems__ */
machclk_usepcc = 0;
#endif
}
@@ -968,6 +970,7 @@ init_machclk(void)
* accessible, just use it.
*/
#if defined(__amd64__) || defined(__i386__)
+#ifndef __rtems__
#ifdef __FreeBSD__
machclk_freq = atomic_load_acq_64(&tsc_freq);
#elif defined(__NetBSD__)
@@ -975,6 +978,7 @@ init_machclk(void)
#elif defined(__OpenBSD__) && (defined(I586_CPU) || defined(I686_CPU))
machclk_freq = pentium_mhz * 100;
#endif
+#endif /* __rtems */
#endif
/*
--
2.2.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH v2] Fix buiding for the i386.
--- freebsd/sys/contrib/altq/altq/altq_subr.c | 4 1 file changed, 4 insertions(+) diff --git a/freebsd/sys/contrib/altq/altq/altq_subr.c b/freebsd/sys/contrib/altq/altq/altq_subr.c index 3ebd58d..fbbf589 100644 --- a/freebsd/sys/contrib/altq/altq/altq_subr.c +++ b/freebsd/sys/contrib/altq/altq/altq_subr.c @@ -930,6 +930,7 @@ init_machclk_setup(void) #if defined(__NetBSD__) && defined(MULTIPROCESSOR) machclk_usepcc = 0; #endif +#if !defined(__rtems__) #if defined(__amd64__) || defined(__i386__) /* check if TSC is available */ #ifdef __FreeBSD__ @@ -938,6 +939,7 @@ init_machclk_setup(void) #else if ((cpu_feature & CPUID_TSC) == 0) #endif +#endif /* __rtems__ */ machclk_usepcc = 0; #endif } @@ -968,6 +970,7 @@ init_machclk(void) * accessible, just use it. */ #if defined(__amd64__) || defined(__i386__) +#ifndef __rtems__ #ifdef __FreeBSD__ machclk_freq = atomic_load_acq_64(&tsc_freq); #elif defined(__NetBSD__) @@ -975,6 +978,7 @@ init_machclk(void) #elif defined(__OpenBSD__) && (defined(I586_CPU) || defined(I686_CPU)) machclk_freq = pentium_mhz * 100; #endif +#endif /* __rtems */ #endif /* -- 2.2.2 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/3] bsp/tms570: fix get time resolution after infrastructure change to timecounter.
From: Pavel Pisa
The update fixes breakage of TMS570 support after Alexander Krutwig
switch of RTEMS time read to timecounter mechanism
bsps: Convert clock drivers to use a timecounter
Mechanism to specify odd (non 1 Mhz) time base update frequencies
implemented after objections of Martin Galvan.
Code is adjusted to convert RTEMS configuration parameter
microseconds_per_tick to such odd base if
TMS570_PREFERRED_TC_FREQUENCY is specified appropriately.
Signed-off-by: Premysl Houdek
Signed-off-by: Pavel Pisa
---
c/src/lib/libbsp/arm/tms570/clock/clock.c | 41 ++-
1 file changed, 35 insertions(+), 6 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..03c156e 100644
--- a/c/src/lib/libbsp/arm/tms570/clock/clock.c
+++ b/c/src/lib/libbsp/arm/tms570/clock/clock.c
@@ -39,6 +39,17 @@ static uint32_t tms570_rti_get_timecount(struct timecounter
*tc)
return TMS570_RTI.RTIFRC0;
}
+#ifndef TMS570_PREFERRED_TC_FREQUENCY
+/*
+ * Define preferred main time base counter frequency
+ * The value of 1MHz is the best matching RTEMS
+ * timing system because then there is no need
+ * to scale RTEMS configuration microseconds_per_tick
+ * parameter
+ */
+#define TMS570_PREFERRED_TC_FREQUENCY 100
+#endif /* TMS570_PREFERRED_TC_FREQUENCY */
+
/**
* @brief Initialize the HW peripheral for clock driver
*
@@ -49,13 +60,31 @@ static uint32_t tms570_rti_get_timecount(struct timecounter
*tc)
static void tms570_clock_driver_support_initialize_hardware( void )
{
- uint32_t microsec_per_tick = rtems_configuration_get_microseconds_per_tick();
+ uint32_t microsec_per_tick;
+ uint32_t tc_frequency;
+ uint32_t tc_prescaler;
+ uint32_t tc_increments_per_tick;
+
+ microsec_per_tick = rtems_configuration_get_microseconds_per_tick();
+ tc_frequency = TMS570_PREFERRED_TC_FREQUENCY;
rtems_counter_initialize_converter(BSP_PLL_OUT_CLOCK);
+ tc_prescaler = (BSP_PLL_OUT_CLOCK + tc_frequency) / (tc_frequency * 2);
+
+ /* Recompute actual most close frequency which can be realized */
+ tc_frequency = (BSP_PLL_OUT_CLOCK + tc_prescaler) / (tc_prescaler * 2);
+
+ /*
+ * Recompute tick period to adjust for configurable or exact
+ * preferred time base 1 usec resolution.
+ */
+ tc_increments_per_tick = ((uint64_t)microsec_per_tick * tc_frequency +
+ 50) / 100;
+
/* Hardware specific initialize */
TMS570_RTI.RTIGCTRL = 0;
- TMS570_RTI.RTICPUC0 = BSP_PLL_OUT_CLOCK /100 / 2; /* prescaler */
+ TMS570_RTI.RTICPUC0 = tc_prescaler - 1;
TMS570_RTI.RTITBCTRL = 2;
TMS570_RTI.RTICAPCTRL = 0;
TMS570_RTI.RTICOMPCTRL = 0;
@@ -66,9 +95,9 @@ static void tms570_clock_driver_support_initialize_hardware(
void )
TMS570_RTI.RTICLEARINTENA = 0x00070f0f;
TMS570_RTI.RTIINTFLAG = 0x0007000f;
/* set timer */
- TMS570_RTI.RTICOMP0 = TMS570_RTI.RTIFRC0 + microsec_per_tick;
- TMS570_RTI.RTICOMP0CLR = TMS570_RTI.RTICOMP0 + microsec_per_tick / 2;
- TMS570_RTI.RTIUDCP0 = microsec_per_tick;
+ TMS570_RTI.RTICOMP0 = TMS570_RTI.RTIFRC0 + tc_increments_per_tick;
+ TMS570_RTI.RTICOMP0CLR = TMS570_RTI.RTICOMP0 + tc_increments_per_tick / 2;
+ TMS570_RTI.RTIUDCP0 = tc_increments_per_tick;
/* enable interupt */
TMS570_RTI.RTISETINTENA = 0x1;
/* enable timer */
@@ -76,7 +105,7 @@ static void tms570_clock_driver_support_initialize_hardware(
void )
/* set timecounter */
tms570_rti_tc.tc_get_timecount = tms570_rti_get_timecount;
tms570_rti_tc.tc_counter_mask = 0x;
- tms570_rti_tc.tc_frequency = BSP_PLL_OUT_CLOCK;
+ tms570_rti_tc.tc_frequency = tc_frequency;
tms570_rti_tc.tc_quality = RTEMS_TIMECOUNTER_QUALITY_CLOCK_DRIVER;
rtems_timecounter_install(&tms570_rti_tc);
}
--
1.9.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 3/3] bsp/tms570: source changes reflecting new headers.
Signed-off-by: Premysl Houdek
---
c/src/lib/libbsp/arm/tms570/clock/clock.c | 34 ++---
.../lib/libbsp/arm/tms570/console/printk-support.c | 8 +-
c/src/lib/libbsp/arm/tms570/console/tms570-sci.c | 55
.../lib/libbsp/arm/tms570/include/system-clocks.h | 2 +-
c/src/lib/libbsp/arm/tms570/include/tms570-pom.h | 42 +-
c/src/lib/libbsp/arm/tms570/include/tms570-rti.h | 51 +--
c/src/lib/libbsp/arm/tms570/include/tms570-sci.h | 33 +
c/src/lib/libbsp/arm/tms570/include/tms570-vim.h | 29 +---
c/src/lib/libbsp/arm/tms570/include/tms570.h | 151 +
c/src/lib/libbsp/arm/tms570/startup/bspreset.c | 11 +-
10 files changed, 186 insertions(+), 230 deletions(-)
diff --git a/c/src/lib/libbsp/arm/tms570/clock/clock.c
b/c/src/lib/libbsp/arm/tms570/clock/clock.c
index 03c156e..1d887af 100644
--- a/c/src/lib/libbsp/arm/tms570/clock/clock.c
+++ b/c/src/lib/libbsp/arm/tms570/clock/clock.c
@@ -36,7 +36,7 @@ static struct timecounter tms570_rti_tc;
static uint32_t tms570_rti_get_timecount(struct timecounter *tc)
{
- return TMS570_RTI.RTIFRC0;
+ return TMS570_RTI.CNT[0].FRCx;
}
#ifndef TMS570_PREFERRED_TC_FREQUENCY
@@ -83,25 +83,25 @@ static void
tms570_clock_driver_support_initialize_hardware( void )
50) / 100;
/* Hardware specific initialize */
- TMS570_RTI.RTIGCTRL = 0;
- TMS570_RTI.RTICPUC0 = tc_prescaler - 1;
- TMS570_RTI.RTITBCTRL = 2;
- TMS570_RTI.RTICAPCTRL = 0;
- TMS570_RTI.RTICOMPCTRL = 0;
+ TMS570_RTI.GCTRL = 0;
+ TMS570_RTI.CNT[0].CPUCx = tc_prescaler - 1;
+ TMS570_RTI.TBCTRL = 2;
+ TMS570_RTI.CAPCTRL = 0;
+ TMS570_RTI.COMPCTRL = 0;
/* set counter to zero */
- TMS570_RTI.RTIUC0 = 0;
- TMS570_RTI.RTIFRC0 = 0;
+ TMS570_RTI.CNT[0].UCx = 0;
+ TMS570_RTI.CNT[0].FRCx = 0;
/* clear interrupts*/
- TMS570_RTI.RTICLEARINTENA = 0x00070f0f;
- TMS570_RTI.RTIINTFLAG = 0x0007000f;
+ TMS570_RTI.CLEARINTENA = 0x00070f0f;
+ TMS570_RTI.INTFLAG = 0x0007000f;
/* set timer */
- TMS570_RTI.RTICOMP0 = TMS570_RTI.RTIFRC0 + tc_increments_per_tick;
- TMS570_RTI.RTICOMP0CLR = TMS570_RTI.RTICOMP0 + tc_increments_per_tick / 2;
- TMS570_RTI.RTIUDCP0 = tc_increments_per_tick;
+ TMS570_RTI.CMP[0].COMPx = TMS570_RTI.CNT[0].FRCx + tc_increments_per_tick;
+ TMS570_RTI.COMP0CLR = TMS570_RTI.CMP[0].COMPx + tc_increments_per_tick / 2;
+ TMS570_RTI.CMP[0].UDCPx = tc_increments_per_tick;
/* enable interupt */
- TMS570_RTI.RTISETINTENA = 0x1;
+ TMS570_RTI.SETINTENA = 0x1;
/* enable timer */
- TMS570_RTI.RTIGCTRL = 1;
+ TMS570_RTI.GCTRL = 1;
/* set timecounter */
tms570_rti_tc.tc_get_timecount = tms570_rti_get_timecount;
tms570_rti_tc.tc_counter_mask = 0x;
@@ -117,7 +117,7 @@ static void
tms570_clock_driver_support_initialize_hardware( void )
*/
static void tms570_clock_driver_support_at_tick( void )
{
- TMS570_RTI.RTIINTFLAG = 0x0001;
+ TMS570_RTI.INTFLAG = 0x0001;
}
/**
@@ -156,7 +156,7 @@ static void tms570_clock_driver_support_install_isr(
static void tms570_clock_driver_support_shutdown_hardware( void )
{
/* turn off the timer interrupts */
- TMS570_RTI.RTICLEARINTENA = 0x2;
+ TMS570_RTI.CLEARINTENA = 0x2;
}
#define Clock_driver_support_initialize_hardware \
diff --git a/c/src/lib/libbsp/arm/tms570/console/printk-support.c
b/c/src/lib/libbsp/arm/tms570/console/printk-support.c
index 241ca9b..ed33d98 100644
--- a/c/src/lib/libbsp/arm/tms570/console/printk-support.c
+++ b/c/src/lib/libbsp/arm/tms570/console/printk-support.c
@@ -41,10 +41,10 @@ static void tms570_putc(char ch)
rtems_interrupt_level level;
rtems_interrupt_disable(level);
- while ( ( driver_context_table[0].regs->SCIFLR & 0x100 ) == 0) {
+ while ( ( driver_context_table[0].regs->FLR & 0x100 ) == 0) {
rtems_interrupt_flash(level);
}
- driver_context_table[0].regs->SCITD = ch;
+ driver_context_table[0].regs->TD = ch;
rtems_interrupt_enable(level);
}
@@ -74,8 +74,8 @@ static void tms570_uart_output(char c)
*/
static int tms570_uart_input( void )
{
- if ( driver_context_table[0].regs->SCIFLR & (1<<9) ) {
- return driver_context_table[0].regs->SCIRD;
+ if ( driver_context_table[0].regs->FLR & (1<<9) ) {
+ return driver_context_table[0].regs->RD;
} else {
return -1;
}
diff --git a/c/src/lib/libbsp/arm/tms570/console/tms570-sci.c
b/c/src/lib/libbsp/arm/tms570/console/tms570-sci.c
index d78cf20..44b53f5 100644
--- a/c/src/lib/libbsp/arm/tms570/console/tms570-sci.c
+++ b/c/src/lib/libbsp/arm/tms570/console/tms570-sci.c
@@ -44,13 +44,16 @@ tms570_sci_context driver_context_table[] = {
{
.base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER("TMS570 SCI1"),
.device_name = "/dev/console",
-.regs = &TMS570_SCI,
+/* TMS570 UART peripheral use subset of LIN registers which are equivalent
+ * to SCI ones
+ */
+.regs = (volatile tms570_sci_t *) &TMS570_LIN,
.irq = TMS570_IRQ_SCI_LEVEL_0,
Re: [PATCH] bsp/tms570: fix get time resolution after infrastructure change to timecounter.
Please attach any patches to tickets for 4.11 as it is entering
release and maintain mode.
On Wed, Jul 15, 2015 at 4:46 PM, Joel Sherrill
wrote:
> 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 :)
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
> --
> Joel Sherrill, Ph.D. Director of Research & Development
> joel.sherr...@oarcorp.comOn-Line Applications Research
> Ask me about RTEMS: a free RTOS Huntsville AL 35805
> Support Available(256) 722-9985
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2] Fix buiding for the i386.
Thanks for following conventions. I guess this replaces the one Joel sent yesterday? On Thu, Jul 16, 2015 at 7:11 AM, Chris Johns wrote: > --- > freebsd/sys/contrib/altq/altq/altq_subr.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/freebsd/sys/contrib/altq/altq/altq_subr.c > b/freebsd/sys/contrib/altq/altq/altq_subr.c > index 3ebd58d..fbbf589 100644 > --- a/freebsd/sys/contrib/altq/altq/altq_subr.c > +++ b/freebsd/sys/contrib/altq/altq/altq_subr.c > @@ -930,6 +930,7 @@ init_machclk_setup(void) > #if defined(__NetBSD__) && defined(MULTIPROCESSOR) > machclk_usepcc = 0; > #endif > +#if !defined(__rtems__) > #if defined(__amd64__) || defined(__i386__) > /* check if TSC is available */ > #ifdef __FreeBSD__ > @@ -938,6 +939,7 @@ init_machclk_setup(void) > #else > if ((cpu_feature & CPUID_TSC) == 0) > #endif > +#endif /* __rtems__ */ > machclk_usepcc = 0; > #endif > } > @@ -968,6 +970,7 @@ init_machclk(void) > * accessible, just use it. > */ > #if defined(__amd64__) || defined(__i386__) > +#ifndef __rtems__ > #ifdef __FreeBSD__ > machclk_freq = atomic_load_acq_64(&tsc_freq); > #elif defined(__NetBSD__) > @@ -975,6 +978,7 @@ init_machclk(void) > #elif defined(__OpenBSD__) && (defined(I586_CPU) || defined(I686_CPU)) > machclk_freq = pentium_mhz * 100; > #endif > +#endif /* __rtems */ > #endif > > /* > -- > 2.2.2 > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] bsp/tms570: fix get time resolution after infrastructure change to timecounter.
By attach, I should mean, refer or close the ticket in the commit
message. Thanks for opening the ticket already!
Gedare
On Thu, Jul 16, 2015 at 9:11 AM, Gedare Bloom wrote:
> Please attach any patches to tickets for 4.11 as it is entering
> release and maintain mode.
>
> On Wed, Jul 15, 2015 at 4:46 PM, Joel Sherrill
> wrote:
>> 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 :)
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>>
>>
>> --
>> Joel Sherrill, Ph.D. Director of Research & Development
>> joel.sherr...@oarcorp.comOn-Line Applications Research
>> Ask me about RTEMS: a free RTOS Huntsville AL 35805
>> Support Available(256) 722-9985
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/2] pc386/.../bsp.h: Change include guard
This is needed to follow the convention expected in nexus-devices.h in the rtems-libbsd tree. --- c/src/lib/libbsp/i386/pc386/include/bsp.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/c/src/lib/libbsp/i386/pc386/include/bsp.h b/c/src/lib/libbsp/i386/pc386/include/bsp.h index f537eb6..5a82ac2 100644 --- a/c/src/lib/libbsp/i386/pc386/include/bsp.h +++ b/c/src/lib/libbsp/i386/pc386/include/bsp.h @@ -44,8 +44,8 @@ | ** +--*/ -#ifndef _BSP_H -#define _BSP_H +#ifndef LIBBSP_I386_PC386_BSP_H +#define LIBBSP_I386_PC386_BSP_H #ifndef ASM -- 1.7.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/2] pc386/.../bsp.h: Change include guard
Would you care to sweep the other bsp.h too? On Thu, Jul 16, 2015 at 10:47 AM, Joel Sherrill wrote: > This is needed to follow the convention expected in nexus-devices.h > in the rtems-libbsd tree. > --- > c/src/lib/libbsp/i386/pc386/include/bsp.h |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/c/src/lib/libbsp/i386/pc386/include/bsp.h > b/c/src/lib/libbsp/i386/pc386/include/bsp.h > index f537eb6..5a82ac2 100644 > --- a/c/src/lib/libbsp/i386/pc386/include/bsp.h > +++ b/c/src/lib/libbsp/i386/pc386/include/bsp.h > @@ -44,8 +44,8 @@ > | ** > +--*/ > > -#ifndef _BSP_H > -#define _BSP_H > +#ifndef LIBBSP_I386_PC386_BSP_H > +#define LIBBSP_I386_PC386_BSP_H > > #ifndef ASM > > -- > 1.7.1 > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/2] pc386/.../bsp.h: Change include guard
Sure. Should I do it before we branch? --joel On 7/16/2015 9:57 AM, Gedare Bloom wrote: Would you care to sweep the other bsp.h too? On Thu, Jul 16, 2015 at 10:47 AM, Joel Sherrill wrote: This is needed to follow the convention expected in nexus-devices.h in the rtems-libbsd tree. --- c/src/lib/libbsp/i386/pc386/include/bsp.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/c/src/lib/libbsp/i386/pc386/include/bsp.h b/c/src/lib/libbsp/i386/pc386/include/bsp.h index f537eb6..5a82ac2 100644 --- a/c/src/lib/libbsp/i386/pc386/include/bsp.h +++ b/c/src/lib/libbsp/i386/pc386/include/bsp.h @@ -44,8 +44,8 @@ | ** +--*/ -#ifndef _BSP_H -#define _BSP_H +#ifndef LIBBSP_I386_PC386_BSP_H +#define LIBBSP_I386_PC386_BSP_H #ifndef ASM -- 1.7.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/2] pc386/.../bsp.h: Change include guard
Up to you. If other BSPs might get libbsd support in 4.11 release, it makes sense to do it now. Either way, you should open a ticket and close it with the commit. On Thu, Jul 16, 2015 at 11:01 AM, Joel Sherrill wrote: > Sure. > > Should I do it before we branch? > > --joel > > On 7/16/2015 9:57 AM, Gedare Bloom wrote: >> >> Would you care to sweep the other bsp.h too? >> >> On Thu, Jul 16, 2015 at 10:47 AM, Joel Sherrill >> wrote: >>> >>> This is needed to follow the convention expected in nexus-devices.h >>> in the rtems-libbsd tree. >>> --- >>> c/src/lib/libbsp/i386/pc386/include/bsp.h |4 ++-- >>> 1 files changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/c/src/lib/libbsp/i386/pc386/include/bsp.h >>> b/c/src/lib/libbsp/i386/pc386/include/bsp.h >>> index f537eb6..5a82ac2 100644 >>> --- a/c/src/lib/libbsp/i386/pc386/include/bsp.h >>> +++ b/c/src/lib/libbsp/i386/pc386/include/bsp.h >>> @@ -44,8 +44,8 @@ >>> | >>> ** >>> >>> +--*/ >>> >>> -#ifndef _BSP_H >>> -#define _BSP_H >>> +#ifndef LIBBSP_I386_PC386_BSP_H >>> +#define LIBBSP_I386_PC386_BSP_H >>> >>> #ifndef ASM >>> >>> -- >>> 1.7.1 >>> >>> ___ >>> devel mailing list >>> devel@rtems.org >>> http://lists.rtems.org/mailman/listinfo/devel > > > -- > Joel Sherrill, Ph.D. Director of Research & Development > joel.sherr...@oarcorp.comOn-Line Applications Research > Ask me about RTEMS: a free RTOS Huntsville AL 35805 > Support Available(256) 722-9985 > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 2/2] remaining bsp.h: Fix by hand to LIBBSP_@CPU@_@BSP_FAMILY@_BSP_H
These files were left after running the script in the previous patch. --- c/src/lib/libbsp/arm/gba/include/bsp.h | 4 ++-- c/src/lib/libbsp/arm/nds/include/bsp.h | 4 ++-- c/src/lib/libbsp/m68k/av5282/include/bsp.h | 4 ++-- c/src/lib/libbsp/m68k/genmcf548x/include/bsp.h | 4 ++-- c/src/lib/libbsp/m68k/sim68000/include/bsp.h | 4 ++-- c/src/lib/libbsp/powerpc/gen5200/include/bsp.h | 4 ++-- c/src/lib/libbsp/powerpc/gen83xx/include/bsp.h | 4 ++-- 7 files changed, 14 insertions(+), 14 deletions(-) diff --git a/c/src/lib/libbsp/arm/gba/include/bsp.h b/c/src/lib/libbsp/arm/gba/include/bsp.h index f9cbbc4..fa7df74 100644 --- a/c/src/lib/libbsp/arm/gba/include/bsp.h +++ b/c/src/lib/libbsp/arm/gba/include/bsp.h @@ -17,8 +17,8 @@ * http://www.rtems.org/license/LICENSE. */ -#ifndef __BSP_H_ -#define __BSP_H_ +#ifndef LIBBSP_ARM_GBA_H +#define LIBBSP_ARM_GBA_H #include #include diff --git a/c/src/lib/libbsp/arm/nds/include/bsp.h b/c/src/lib/libbsp/arm/nds/include/bsp.h index 2f1d730..8b795e2 100644 --- a/c/src/lib/libbsp/arm/nds/include/bsp.h +++ b/c/src/lib/libbsp/arm/nds/include/bsp.h @@ -7,8 +7,8 @@ * http://www.rtems.org/license/LICENSE */ -#ifndef __BSP_H_ -#define __BSP_H_ +#ifndef LIBBSP_ARM_NDS_H +#define LIBBSP_ARM_NDS_H #include #include diff --git a/c/src/lib/libbsp/m68k/av5282/include/bsp.h b/c/src/lib/libbsp/m68k/av5282/include/bsp.h index 007fc40..d663df6 100644 --- a/c/src/lib/libbsp/m68k/av5282/include/bsp.h +++ b/c/src/lib/libbsp/m68k/av5282/include/bsp.h @@ -18,8 +18,8 @@ * @brief AV5282 support. */ -#ifndef __SBav5282_BSP_H -#define __SBav5282_BSP_H +#ifndef LIBBSP_M68K_AV5282_BSP_H +#define LIBBSP_M68K_AV5282_BSP_H #ifndef ASM diff --git a/c/src/lib/libbsp/m68k/genmcf548x/include/bsp.h b/c/src/lib/libbsp/m68k/genmcf548x/include/bsp.h index d818763..61b3ced 100644 --- a/c/src/lib/libbsp/m68k/genmcf548x/include/bsp.h +++ b/c/src/lib/libbsp/m68k/genmcf548x/include/bsp.h @@ -51,8 +51,8 @@ | | \*===*/ -#ifndef __GENMCF548X_BSP_H -#define __GENMCF548X_BSP_H +#ifndef LIBBSP_M68K_GENMCF548X_BSP_H +#define LIBBSP_M68K_GENMCF548X_BSP_H #include #include diff --git a/c/src/lib/libbsp/m68k/sim68000/include/bsp.h b/c/src/lib/libbsp/m68k/sim68000/include/bsp.h index fbfc37c..c0337d1 100644 --- a/c/src/lib/libbsp/m68k/sim68000/include/bsp.h +++ b/c/src/lib/libbsp/m68k/sim68000/include/bsp.h @@ -11,8 +11,8 @@ * http://www.rtems.org/license/LICENSE. */ -#ifndef __BSVC_SIM -#define __BSVC_SIM +#ifndef LIBBSP_M68K_SIM68000_BSP_H +#define LIBBSP_M68K_SIM68000_BSP_H #include #include diff --git a/c/src/lib/libbsp/powerpc/gen5200/include/bsp.h b/c/src/lib/libbsp/powerpc/gen5200/include/bsp.h index d27c9c1..66d8364 100644 --- a/c/src/lib/libbsp/powerpc/gen5200/include/bsp.h +++ b/c/src/lib/libbsp/powerpc/gen5200/include/bsp.h @@ -20,8 +20,8 @@ | this file contains board specific definitions | \*===*/ -#ifndef __GEN5200_BSP_h -#define __GEN5200_BSP_h +#ifndef LIBBSP_POWERPC_GEN5200_BSP_H +#define LIBBSP_POWERPC_GEN5200_BSP_H #include diff --git a/c/src/lib/libbsp/powerpc/gen83xx/include/bsp.h b/c/src/lib/libbsp/powerpc/gen83xx/include/bsp.h index b9033c1..1e1243b 100644 --- a/c/src/lib/libbsp/powerpc/gen83xx/include/bsp.h +++ b/c/src/lib/libbsp/powerpc/gen83xx/include/bsp.h @@ -18,8 +18,8 @@ \*===*/ -#ifndef __GEN83xx_BSP_h -#define __GEN83xx_BSP_h +#ifndef LIBBSP_POWERPC_GEN83XX_BSP_H +#define LIBBSP_POWERPC_GEN83XX_BSP_H #define BSP_FEATURE_IRQ_EXTENSION -- 1.8.3.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/2] Most bsp.h: Switch to LIBBSP_@CPU@_@BSP_FAMILY@_H for guard
This was done by the following script run from libbsp:
find * -name bsp.h | xargs -e grep -l "#ifndef.*_BSP_H" | while read b
do
echo $b
cpu=`echo $b | cut -d'/' -f1 | tr '[:lower:]' '[:upper:]' `
bsp=`echo $b | cut -d'/' -f2 | tr '[:lower:]' '[:upper:]' `
g="LIBBSP_${cpu}_${bsp}_BSP_H"
# echo $g
sed -e "s/ifndef _BSP_H/ifndef ${g}/" \
-e "s/define _BSP_H/define ${g}/" \
-i $b
done
---
c/src/lib/libbsp/arm/csb336/include/bsp.h | 4 ++--
c/src/lib/libbsp/arm/csb337/include/bsp.h | 4 ++--
c/src/lib/libbsp/arm/edb7312/include/bsp.h | 4 ++--
c/src/lib/libbsp/arm/gdbarmsim/include/bsp.h| 4 ++--
c/src/lib/libbsp/arm/gp32/include/bsp.h | 4 ++--
c/src/lib/libbsp/arm/gumstix/include/bsp.h | 4 ++--
c/src/lib/libbsp/arm/rtl22xx/include/bsp.h | 4 ++--
c/src/lib/libbsp/arm/smdk2410/include/bsp.h | 4 ++--
c/src/lib/libbsp/avr/avrtest/include/bsp.h | 4 ++--
c/src/lib/libbsp/bfin/TLL6527M/include/bsp.h| 4 ++--
c/src/lib/libbsp/bfin/bf537Stamp/include/bsp.h | 4 ++--
c/src/lib/libbsp/bfin/eZKit533/include/bsp.h| 4 ++--
c/src/lib/libbsp/h8300/h8sim/include/bsp.h | 4 ++--
c/src/lib/libbsp/i386/pc386/include/bsp.h | 4 ++--
c/src/lib/libbsp/lm32/lm32_evr/include/bsp.h| 4 ++--
c/src/lib/libbsp/lm32/milkymist/include/bsp.h | 4 ++--
c/src/lib/libbsp/m32c/m32cbsp/include/bsp.h | 4 ++--
c/src/lib/libbsp/m32r/m32rsim/include/bsp.h | 4 ++--
c/src/lib/libbsp/m68k/csb360/include/bsp.h | 4 ++--
c/src/lib/libbsp/m68k/gen68302/include/bsp.h| 4 ++--
c/src/lib/libbsp/m68k/gen68340/include/bsp.h| 4 ++--
c/src/lib/libbsp/m68k/gen68360/include/bsp.h| 4 ++--
c/src/lib/libbsp/m68k/idp/include/bsp.h | 4 ++--
c/src/lib/libbsp/m68k/mcf5206elite/include/bsp.h| 4 ++--
c/src/lib/libbsp/m68k/mcf52235/include/bsp.h| 4 ++--
c/src/lib/libbsp/m68k/mcf5225x/include/bsp.h| 4 ++--
c/src/lib/libbsp/m68k/mcf5235/include/bsp.h | 4 ++--
c/src/lib/libbsp/m68k/mcf5329/include/bsp.h | 4 ++--
c/src/lib/libbsp/m68k/mrm332/include/bsp.h | 4 ++--
c/src/lib/libbsp/m68k/mvme136/include/bsp.h | 4 ++--
c/src/lib/libbsp/m68k/mvme147/include/bsp.h | 4 ++--
c/src/lib/libbsp/m68k/mvme147s/include/bsp.h| 4 ++--
c/src/lib/libbsp/m68k/mvme162/include/bsp.h | 4 ++--
c/src/lib/libbsp/m68k/mvme167/include/bsp.h | 4 ++--
c/src/lib/libbsp/m68k/ods68302/include/bsp.h| 4 ++--
c/src/lib/libbsp/m68k/uC5282/include/bsp.h | 4 ++--
c/src/lib/libbsp/mips/csb350/include/bsp.h | 4 ++--
c/src/lib/libbsp/mips/genmongoosev/include/bsp.h| 4 ++--
c/src/lib/libbsp/mips/hurricane/include/bsp.h | 4 ++--
c/src/lib/libbsp/mips/jmr3904/include/bsp.h | 4 ++--
c/src/lib/libbsp/mips/malta/include/bsp.h | 4 ++--
c/src/lib/libbsp/mips/rbtx4925/include/bsp.h| 4 ++--
c/src/lib/libbsp/mips/rbtx4938/include/bsp.h| 4 ++--
c/src/lib/libbsp/moxie/moxiesim/include/bsp.h | 4 ++--
c/src/lib/libbsp/nios2/nios2_iss/include/bsp.h | 4 ++--
c/src/lib/libbsp/no_cpu/no_bsp/include/bsp.h| 4 ++--
c/src/lib/libbsp/powerpc/ep1a/include/bsp.h | 4 ++--
c/src/lib/libbsp/powerpc/haleakala/include/bsp.h| 4 ++--
c/src/lib/libbsp/powerpc/mbx8xx/include/bsp.h | 4 ++--
c/src/lib/libbsp/powerpc/motorola_powerpc/include/bsp.h | 4 ++--
c/src/lib/libbsp/powerpc/mpc8260ads/include/bsp.h | 4 ++--
c/src/lib/libbsp/powerpc/mvme3100/include/bsp.h | 4 ++--
c/src/lib/libbsp/powerpc/mvme5500/include/bsp.h | 4 ++--
c/src/lib/libbsp/powerpc/psim/include/bsp.h | 4 ++--
c/src/lib/libbsp/powerpc/qemuppc/include/bsp.h | 4 ++--
c/src/lib/libbsp/powerpc/score603e/include/bsp.h| 4 ++--
c/src/lib/libbsp/powerpc/ss555/include/bsp.h| 4 ++--
c/src/lib/libbsp/powerpc/tqm8xx/include/bsp.h | 4 ++--
c/src/lib/libbsp/powerpc/virtex/include/bsp.h | 4 ++--
c/src/lib/libbsp/powerpc/virtex4/include/bsp.h | 4 ++--
c/src/lib/libbsp/powerpc/virtex5/include/bsp.h | 4 ++--
c/src/lib/libbsp/sh/gensh1/include/bsp.h| 4 ++--
c/src/lib/libbsp/sh/gensh2/include/bsp.h| 4 ++--
c/src/lib/libbsp/sh/gensh4/include/bsp.h| 4 ++--
c/src/lib/libbsp/sh/shsim/include/bsp.h | 4 ++--
c/src/lib/libbsp/sparc/erc32/include/bsp.h | 4 ++--
c/src/lib/libbsp/sparc/leon2/include/bsp.h | 4 ++--
c/src/lib/libbsp/sparc/leon3/include/bsp.h | 4 ++--
c/src/lib/libbsp/sparc64/niagara/include/bsp.h | 4 ++--
c/src/lib/libbsp/sparc64/usiii/in
Near Last Call Before Branching 4.11
Hi I am in the middle of a build sweep now with the tms570 patches and my bsp.h changes. Once this finishes, I plan to push those changes and cut the branch. Speak now. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC 2015 RPi USB Support
Which qemu build are you using? And what qemu args for xilinx zynq? ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Near Last Call Before Branching 4.11
> On Jul 16, 2015, at 13:55 , Joel Sherrill wrote: > > I am in the middle of a build sweep now with the tms570 patches > and my bsp.h changes. Once this finishes, I plan to push those > changes and cut the branch. > > Speak now. I have a two concerns but they’ll have to be fixed after the branch. This is Phytec MPC5554. - My flash code had a dereference of the NULL pointer (expected) and it triggered the GCC -O2 optimization that replaced it with a TRAP instruction. When I disassembled the application binary there were 39 calls to a TRAP instruction total, many in RTEMS code. I recompiled with -fno-delete-null-pointer-checks (both RTEMS and my application) and there were 2. I haven’t had time to go back and analyze this. - I was having NFS crashes regularly. I removed a pthread_mutex_trylock() in an ISR (I assumed that was safe) while trying to make that ISR faster and the NFS issues disappeared. I haven’t had time to go back to that either. On a plus note the -ffunction-sections -fdata-sections size optimization has worked great and I didn’t need to make any changes other than rebuilding with that. I’m on a project that’s late and that’s why I haven’t kept up on this. Peter - Peter Dufault HD Associates, Inc. Software and System Engineering ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Near Last Call Before Branching 4.11
On 7/16/2015 1:59 PM, Peter Dufault wrote: On Jul 16, 2015, at 13:55 , Joel Sherrill wrote: I am in the middle of a build sweep now with the tms570 patches and my bsp.h changes. Once this finishes, I plan to push those changes and cut the branch. Speak now. I have a two concerns but they’ll have to be fixed after the branch. This is Phytec MPC5554. - My flash code had a dereference of the NULL pointer (expected) and it triggered the GCC -O2 optimization that replaced it with a TRAP instruction. When I disassembled the application binary there were 39 calls to a TRAP instruction total, many in RTEMS code. I recompiled with -fno-delete-null-pointer-checks (both RTEMS and my application) and there were 2. I haven’t had time to go back and analyze this. I wonder if this is something we should turn on by default. But more investigation would be required before we did that. - I was having NFS crashes regularly. I removed a pthread_mutex_trylock() in an ISR (I assumed that was safe) while trying to make that ISR faster and the NFS issues disappeared. I haven’t had time to go back to that either. There are checks against that. I don't remember the exact restrictions and it may be completely forbidden. But depending on the configuration of the mutex, it doesn't even make sense. Priority inheritance and ceiling imply an owner thread so lock operations need to be from threads for mutexes. You probably could have gotten by with a semaphore but wouldn't have had the nice properties of a mutex. On a plus note the -ffunction-sections -fdata-sections size optimization has worked great and I didn’t need to make any changes other than rebuilding with that. I am glad to hear this. It looked promising to turn on. Just required testing on a per BSP basis. I’m on a project that’s late and that’s why I haven’t kept up on this. Peter - Peter Dufault HD Associates, Inc. Software and System Engineering -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Near Last Call Before Branching 4.11
> On Jul 16, 2015, at 15:07 , Joel Sherrill wrote: > >> >> - I was having NFS crashes regularly. I removed a pthread_mutex_trylock() >> in an ISR (I assumed that was safe) while trying to make that ISR faster and >> the NFS issues disappeared. I haven’t had time to go back to that either. > > There are checks against that. I don't remember the exact restrictions and > it may be completely forbidden. But depending on the configuration of the > mutex, it doesn't even make sense. Priority inheritance and ceiling imply > an owner thread so lock operations need to be from threads for mutexes. > > You probably could have gotten by with a semaphore but wouldn't have had > the nice properties of a mutex. > > I was foolishly thinking any non-blocking routine usable in a signal handler should be usable in an ISR. The way I’m using it can and should be replaced by a compare-and-swap. I hope it was the cause of the NFS issues, when I have time I’m going to re-enable it and see if the problems come back. Peter - Peter Dufault HD Associates, Inc. Software and System Engineering ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Doubt regarding Thread_Control_struct in rtems
Yes I was looking for same present in Thread_Lock_control. I might some how missed it while going through Thread_Control_struct. Thanks. Then as lock is present then I suppose we might have certainly taken care of data race conditions. Thanks, Saurabh Gadia On Thu, Jul 16, 2015 at 12:19 AM, Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > > > On 16/07/15 01:49, Saurabh Gadia wrote: > >> 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->current_priority. *As it is updated by thread while restoring its >> priority and while some other thread trying to promote for nested_mutex >> behavior. >> > > There is no data race condition, see _Thread_Change_priority() and > Thread_Lock_control. There is a potential problem with a deadlock at spin > lock level however, in case the application provokes a deadlock at object > level. This needs some further investigation. > > -- > 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-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Global lock free Nested Mutex JPF model
Hi, I have just implemented global lock free nested mutex JPF model for SMP arch also. github JPF link: https://github.com/saurabhgadia4/lock-model/tree/rtemsjpf-0.6-global-free please review the model and give your feedback!! Thanks, Saurabh Gadia ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2] Fix buiding for the i386.
On 16/07/2015 11:13 pm, Gedare Bloom wrote: > Thanks for following conventions. I guess this replaces the one Joel > sent yesterday? Yes. I will push it. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Doubt regarding Thread_Control_struct in rtems
On 17/07/15 03:39, Cyrille Artho wrote: Note that the lock only protects against direct accesses to the thread priority. If other code relies on the fact that the change is still current further down, then we may have an "atomicity race" (as it's sometimes called) or causality problem (another name for this). We are currently trying out ways to avoid any such issues, without using too many locks. Please review the _Thread_Change_priority() function and Thread_Lock_control carefully. You may have a look at _Thread_queue_Enqueue_critical() and search for _Thread_Lock_set() for example. -- 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-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
