[PATCH] RFS: Fix resource leak
Close #2433.
---
cpukit/libfs/src/rfs/rtems-rfs-rtems.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/cpukit/libfs/src/rfs/rtems-rfs-rtems.c
b/cpukit/libfs/src/rfs/rtems-rfs-rtems.c
index 999dfb3..a0ade04 100644
--- a/cpukit/libfs/src/rfs/rtems-rfs-rtems.c
+++ b/cpukit/libfs/src/rfs/rtems-rfs-rtems.c
@@ -831,6 +831,8 @@ rtems_rfs_rtems_initialise
(rtems_filesystem_mount_table_entry_t* mt_entry,
rc = rtems_rfs_fs_open (mt_entry->dev, rtems, flags, max_held_buffers, &fs);
if (rc)
{
+rtems_rfs_mutex_unlock (&rtems->access);
+rtems_rfs_mutex_destroy (&rtems->access);
free (rtems);
return rtems_rfs_rtems_error ("initialise: open", errno);
}
--
1.8.4.5
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Random lwIP Crashes in _POSIX_Mutex_Lock_support()
Thanks for the reply.
On 10/21/2015 01:50 AM, Sebastian Huber wrote:
On 20/10/15 16:02, Isaac Gutekunst wrote:
Hi Devel,
I'm pretty sure this is a devel question, not users.
I'm working with a colleague at Vecna to port lwIP to the STM32F7 BSP we've
developed.
We have a basic HTTP server that prints out the current list of tasks. We
refresh the page at
a very high rate, and after about 1-30 minutes, get a crash.
Every time the exception is thrown after _CORE_mutex_Check_dispatch_for_seize(
wait ) on
line 254 of coremuteximpl.h. Every time this is inside a pthread_mutex_lock()
call.
Here is the full backtrace:
stm32f_fatal_error_handler() at hal-fatal-error-handler.c:126 0x800af92
_User_extensions_Fatal_visitor() at userextiterate.c:123 0x803212c
_User_extensions_Iterate() at userextiterate.c:166 0x80321c0
_User_extensions_Fatal() at userextimpl.h:254 0x802a85e
_Terminate() at interr.c:44 0x802a888
_CORE_mutex_Seize_body() at coremuteximpl.h:255 0x8068df0
_POSIX_Mutex_Lock_support() at mutexlocksupp.c:57 0x806907e
pthread_mutex_lock() at mutexlock.c:40 0x8068bee
sys_arch_sem_wait() at sys_arch.c:485 0x808da8a
sys_arch_mbox_fetch() at sys_arch.c:357 0x808d804
sys_timeouts_mbox_fetch() at timers.c:532 0x80883ce
tcpip_thread() at tcpip.c:95 0x808c170
_Thread_Handler() at threadhandler.c:102 0x806bbe8
_User_extensions_Thread_exitted() at userextimpl.h:244 0x806bb60
bsp_section_work_begin() at 0xc016a12c
However, the lwip code calling pthread_mutex_lock varies, but is consistently
from lwIP.
Does this ring any bells?
Normally you get this if you obtain a locked mutex in interrupt context, but
your stack trace
says you are not.
That was my first suspicion as well.
As far as I can tell this would only occur if the caller of pthread_mutex_lock was in a
"bad"
state. I don't believe it is in an interrupt context, and don't know what other
bad states
could exist.
We have
#define _CORE_mutex_Check_dispatch_for_seize(_wait) \
(!_Thread_Dispatch_is_enabled() \
&& (_wait) \
&& (_System_state_Get() >= SYSTEM_STATE_UP))
What is the thread dispatch disable level and the system state at this point?
In case the thread dispatch disable level is not zero, then something is
probably broken in the
operating system code which is difficult to find. Could be a general memory
corruption problem
too. Which RTEMS version do you use?
The thread dispatch disable level is usually -1 or -2.
(0xFFFE or 0xFFD).
We first suspected that _Thread_Dispatch_decrement_disable_level (in threaddispatch.h) was
being called two many times (somehow). However, it always crashes without the check being fired.
For the record, I inserted this snippet of code:
if (disable_level < 0) {
_Terminate(
INTERNAL_ERROR_CORE,
true,
INTERNAL_ERROR_MUTEX_OBTAIN_FROM_BAD_STATE
);
// In case the _Terminate call doesn't work
__asm__ volatile ("BKPT #01");
}
This pointed us towards a general memory corruption issue, so we are a bit stuck. Another
avenue we are exploring is sticking tests for a negative disable_level all over the code hoping
to get closer to the corruption.
We are running a fork based on 314ff3c43ff1c00232e201df68e39cc0e5600d95. Our changes since then
include the addition of our STM32F BSPs, but no changes to the kernel except a new CAN driver.
Real trace functionality would be really nice, but we lack the hardware (both trace probes, and
exposed trace lines).
This is probably a stretch, but does anyone have experience getting the ETM or ITM sending data
to the ETB and getting the data over JTAG? (with RTEMS and GCC)
Isaac
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Random lwIP Crashes in _POSIX_Mutex_Lock_support()
On 21/10/15 14:13, Isaac Gutekunst wrote: Thanks for the reply. On 10/21/2015 01:50 AM, Sebastian Huber wrote: On 20/10/15 16:02, Isaac Gutekunst wrote: [...] As far as I can tell this would only occur if the caller of pthread_mutex_lock was in a "bad" state. I don't believe it is in an interrupt context, and don't know what other bad states could exist. We have #define _CORE_mutex_Check_dispatch_for_seize(_wait) \ (!_Thread_Dispatch_is_enabled() \ && (_wait) \ && (_System_state_Get() >= SYSTEM_STATE_UP)) What is the thread dispatch disable level and the system state at this point? In case the thread dispatch disable level is not zero, then something is probably broken in the operating system code which is difficult to find. Could be a general memory corruption problem too. Which RTEMS version do you use? The thread dispatch disable level is usually -1 or -2. (0xFFFE or 0xFFD). A negative value is very bad, but easy to detect via manual instrumentation (only an hand full of spots touch this variable) or hardware breakpoints/watchpoints. Looks the rest of _Per_CPU_Information all right? On Cortex-M interrupt disable around operating system calls leads to unpredictable system behaviour. -- 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
Re: Random lwIP Crashes in _POSIX_Mutex_Lock_support()
On 10/21/2015 08:24 AM, Sebastian Huber wrote:
On 21/10/15 14:13, Isaac Gutekunst wrote:
Thanks for the reply.
On 10/21/2015 01:50 AM, Sebastian Huber wrote:
On 20/10/15 16:02, Isaac Gutekunst wrote:
[...]
As far as I can tell this would only occur if the caller of pthread_mutex_lock was in a
"bad"
state. I don't believe it is in an interrupt context, and don't know what other
bad states
could exist.
We have
#define _CORE_mutex_Check_dispatch_for_seize(_wait) \
(!_Thread_Dispatch_is_enabled() \
&& (_wait) \
&& (_System_state_Get() >= SYSTEM_STATE_UP))
What is the thread dispatch disable level and the system state at this point?
In case the thread dispatch disable level is not zero, then something is
probably broken in the
operating system code which is difficult to find. Could be a general memory
corruption problem
too. Which RTEMS version do you use?
The thread dispatch disable level is usually -1 or -2.
(0xFFFE or 0xFFD).
A negative value is very bad, but easy to detect via manual instrumentation
(only an hand full
of spots touch this variable) or hardware breakpoints/watchpoints. Looks the
rest of
_Per_CPU_Information all right?
It looks like it's only the thread_dispatch_disable_level that's broken.
We'll go and grep for all places for all the places it's touched, and look for
something.
The problem with watchpoints is they fire exceptionally often, and putting in a conditional
watchpoint slows the code to a crawl, but that may be worth it.
Here are some printouts of the relevant structs right after a crash:
$4 = {
cpu_per_cpu = {},
isr_nest_level = 0,
thread_dispatch_disable_level = 4294967295,
executing = 0xc01585c8,
heir = 0xc0154038,
dispatch_necessary = true,
time_of_last_context_switch = {
sec = 2992,
frac = 10737447432380511034
},
Stats = {}
}
This might be excessive information, but the executing struct looks good too:
p *(cpu_self->executing)
$6 = ((null) ?) {
Object = {
Node = {
next = 0xc0153558,
previous = 0xc0004568
},
id = 184614914,
name = {
name_p = 0x0,
name_u32 = 0
}
},
current_state = 0,
current_priority = 240,
real_priority = 240,
priority_generation = 0,
priority_restore_hint = false,
resource_count = 0,
Wait = {
Node = {
Chain = {
next = 0xc015b764,
previous = 0xc015b760
},
RBTree = {
Node = {
rbe_left = 0xc015b764,
rbe_right = 0xc015b760,
rbe_parent = 0xc0158644,
rbe_color = 134262661
}
}
},
id = 1124139010,
count = 3222636040,
return_argument = 0x8032101 <_User_extensions_Fatal_visitor>,
return_argument_second = {
mutable_object = 0xc0158644,
immutable_object = 0xc0158644
},
option = 1461858615,
return_code = 0,
timeout_code = 116,
queue = 0x0,
flags = 1028,
operations = 0x80966d0 <_Thread_queue_Operations_default>,
spare_heads = 0xc015b760
},
Timer = {
Node = {
next = 0xc015304c,
previous = 0xc014f9ec
},
state = WATCHDOG_INACTIVE,
initial = 78,
delta_interval = 64,
start_time = 2991580,
stop_time = 2991580,
routine = 0x8031cdd <_Thread_Timeout>,
id = 0,
user_data = 0xc01585c8
},
is_preemptible = true,
is_fp = true,
Scheduler = {
node = 0xc0158784
},
cpu_time_budget = 18,
budget_algorithm = THREAD_CPU_BUDGET_ALGORITHM_NONE,
budget_callout = 0x0,
cpu_time_used = {
sec = 22,
frac = 11951614103676580982
},
Start = {
entry_point = 0x808c149 ,
prototype = THREAD_START_POINTER,
pointer_argument = 0x0,
numeric_argument = 0,
is_preemptible = true,
budget_algorithm = THREAD_CPU_BUDGET_ALGORITHM_NONE,
budget_callout = 0x0,
isr_level = 0,
initial_priority = 240,
core_allocated_stack = true,
Initial_stack = {
size = 4096,
area = 0xc01690f0
},
stack = 0xc01690f0,
tls_area = 0x0
},
Post_switch_actions = {
Chain = {
Head = {
Node = {
next = 0xc01586b0,
previous = 0x0
},
fill = 0xc01586ac
},
Tail = {
fill = 0xc01586b0,
Node = {
next = 0x0,
previous = 0xc01586ac
}
}
}
},
Registers = {
register_r4 = 3222651512,
register_r5 = 0,
register_r6 = 0,
register_r7 = 3222708080,
register_r8 = 0,
register_r9 = 0,
register_r10 = 0,
register_r11 = 0,
register_lr = 0x802f269 <_Thread_Do_dispatch+124>,
register_sp = 0xc0169f70,
isr_nest_level = 1,
register_d8 = 0,
register_d9 = 0,
register_d10 = 0,
register_d11 = 0,
register_d12 = 0,
register_d13 = 0,
register_d14 = 0,
register_d15 = 0
},
libc_reent = 0xc0158890,
API_Extensions = {0xc0158794, 0xc01587c0},
task_variables = 0x0,
Key_Chain = {
Head = {
Node = {
next =
Re: Random lwIP Crashes in _POSIX_Mutex_Lock_support()
On 21/10/15 14:56, Isaac Gutekunst wrote:
On 10/21/2015 08:24 AM, Sebastian Huber wrote:
On 21/10/15 14:13, Isaac Gutekunst wrote:
Thanks for the reply.
On 10/21/2015 01:50 AM, Sebastian Huber wrote:
On 20/10/15 16:02, Isaac Gutekunst wrote:
[...]
As far as I can tell this would only occur if the caller of
pthread_mutex_lock was in a "bad"
state. I don't believe it is in an interrupt context, and don't
know what other bad states
could exist.
We have
#define _CORE_mutex_Check_dispatch_for_seize(_wait) \
(!_Thread_Dispatch_is_enabled() \
&& (_wait) \
&& (_System_state_Get() >= SYSTEM_STATE_UP))
What is the thread dispatch disable level and the system state at
this point?
In case the thread dispatch disable level is not zero, then
something is probably broken in the
operating system code which is difficult to find. Could be a
general memory corruption problem
too. Which RTEMS version do you use?
The thread dispatch disable level is usually -1 or -2.
(0xFFFE or 0xFFD).
A negative value is very bad, but easy to detect via manual
instrumentation (only an hand full
of spots touch this variable) or hardware breakpoints/watchpoints.
Looks the rest of
_Per_CPU_Information all right?
It looks like it's only the thread_dispatch_disable_level that's broken.
We'll go and grep for all places for all the places it's touched, and
look for something.
The problem with watchpoints is they fire exceptionally often, and
putting in a conditional watchpoint slows the code to a crawl, but
that may be worth it.
Here are some printouts of the relevant structs right after a crash:
$4 = {
cpu_per_cpu = {},
isr_nest_level = 0,
thread_dispatch_disable_level = 4294967295,
executing = 0xc01585c8,
heir = 0xc0154038,
dispatch_necessary = true,
time_of_last_context_switch = {
sec = 2992,
frac = 10737447432380511034
},
Stats = {}
}
No, this doesn't look good. According to the stack trace you are in
thread context. However, we have executing != heir and
dispatch_necessary == true. This is a broken state itself. I guess,
something is wrong with the interrupt level so that a context switch is
blocked. On ARMv7-M this is done via the system call exception.
--
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
Re: Random lwIP Crashes in _POSIX_Mutex_Lock_support()
On 10/21/2015 09:00 AM, Sebastian Huber wrote:
On 21/10/15 14:56, Isaac Gutekunst wrote:
On 10/21/2015 08:24 AM, Sebastian Huber wrote:
On 21/10/15 14:13, Isaac Gutekunst wrote:
Thanks for the reply.
On 10/21/2015 01:50 AM, Sebastian Huber wrote:
On 20/10/15 16:02, Isaac Gutekunst wrote:
[...]
As far as I can tell this would only occur if the caller of pthread_mutex_lock
was in a
"bad"
state. I don't believe it is in an interrupt context, and don't know what other
bad states
could exist.
We have
#define _CORE_mutex_Check_dispatch_for_seize(_wait) \
(!_Thread_Dispatch_is_enabled() \
&& (_wait) \
&& (_System_state_Get() >= SYSTEM_STATE_UP))
What is the thread dispatch disable level and the system state at this point?
In case the thread dispatch disable level is not zero, then something is
probably broken
in the
operating system code which is difficult to find. Could be a general memory
corruption
problem
too. Which RTEMS version do you use?
The thread dispatch disable level is usually -1 or -2.
(0xFFFE or 0xFFD).
A negative value is very bad, but easy to detect via manual instrumentation
(only an hand full
of spots touch this variable) or hardware breakpoints/watchpoints. Looks the
rest of
_Per_CPU_Information all right?
It looks like it's only the thread_dispatch_disable_level that's broken.
We'll go and grep for all places for all the places it's touched, and look for
something.
The problem with watchpoints is they fire exceptionally often, and putting in a
conditional
watchpoint slows the code to a crawl, but that may be worth it.
Here are some printouts of the relevant structs right after a crash:
$4 = {
cpu_per_cpu = {},
isr_nest_level = 0,
thread_dispatch_disable_level = 4294967295,
executing = 0xc01585c8,
heir = 0xc0154038,
dispatch_necessary = true,
time_of_last_context_switch = {
sec = 2992,
frac = 10737447432380511034
},
Stats = {}
}
No, this doesn't look good. According to the stack trace you are in thread
context. However, we
have executing != heir and dispatch_necessary == true. This is a broken state
itself. I guess,
something is wrong with the interrupt level so that a context switch is
blocked. On ARMv7-M
this is done via the system call exception.
This is a bit beyond my RTEMS knowledge. What would you advise looking into?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Random lwIP Crashes in _POSIX_Mutex_Lock_support()
On 21/10/15 15:08, Isaac Gutekunst wrote:
On 10/21/2015 09:00 AM, Sebastian Huber wrote:
On 21/10/15 14:56, Isaac Gutekunst wrote:
On 10/21/2015 08:24 AM, Sebastian Huber wrote:
On 21/10/15 14:13, Isaac Gutekunst wrote:
Thanks for the reply.
On 10/21/2015 01:50 AM, Sebastian Huber wrote:
On 20/10/15 16:02, Isaac Gutekunst wrote:
[...]
As far as I can tell this would only occur if the caller of
pthread_mutex_lock was in a
"bad"
state. I don't believe it is in an interrupt context, and don't
know what other bad states
could exist.
We have
#define _CORE_mutex_Check_dispatch_for_seize(_wait) \
(!_Thread_Dispatch_is_enabled() \
&& (_wait) \
&& (_System_state_Get() >= SYSTEM_STATE_UP))
What is the thread dispatch disable level and the system state at
this point?
In case the thread dispatch disable level is not zero, then
something is probably broken
in the
operating system code which is difficult to find. Could be a
general memory corruption
problem
too. Which RTEMS version do you use?
The thread dispatch disable level is usually -1 or -2.
(0xFFFE or 0xFFD).
A negative value is very bad, but easy to detect via manual
instrumentation (only an hand full
of spots touch this variable) or hardware breakpoints/watchpoints.
Looks the rest of
_Per_CPU_Information all right?
It looks like it's only the thread_dispatch_disable_level that's
broken.
We'll go and grep for all places for all the places it's touched,
and look for something.
The problem with watchpoints is they fire exceptionally often, and
putting in a conditional
watchpoint slows the code to a crawl, but that may be worth it.
Here are some printouts of the relevant structs right after a crash:
$4 = {
cpu_per_cpu = {},
isr_nest_level = 0,
thread_dispatch_disable_level = 4294967295,
executing = 0xc01585c8,
heir = 0xc0154038,
dispatch_necessary = true,
time_of_last_context_switch = {
sec = 2992,
frac = 10737447432380511034
},
Stats = {}
}
No, this doesn't look good. According to the stack trace you are in
thread context. However, we
have executing != heir and dispatch_necessary == true. This is a
broken state itself. I guess,
something is wrong with the interrupt level so that a context switch
is blocked. On ARMv7-M
this is done via the system call exception.
This is a bit beyond my RTEMS knowledge. What would you advise looking
into?
I would try to instrument the code to figure out where the thread
dispatch disable level goes negative.
--
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
Re: Random lwIP Crashes in _POSIX_Mutex_Lock_support()
On 21/10/15 15:35, Sebastian Huber wrote:
On 21/10/15 15:08, Isaac Gutekunst wrote:
On 10/21/2015 09:00 AM, Sebastian Huber wrote:
On 21/10/15 14:56, Isaac Gutekunst wrote:
On 10/21/2015 08:24 AM, Sebastian Huber wrote:
On 21/10/15 14:13, Isaac Gutekunst wrote:
Thanks for the reply.
On 10/21/2015 01:50 AM, Sebastian Huber wrote:
On 20/10/15 16:02, Isaac Gutekunst wrote:
[...]
As far as I can tell this would only occur if the caller of
pthread_mutex_lock was in a
"bad"
state. I don't believe it is in an interrupt context, and don't
know what other bad states
could exist.
We have
#define _CORE_mutex_Check_dispatch_for_seize(_wait) \
(!_Thread_Dispatch_is_enabled() \
&& (_wait) \
&& (_System_state_Get() >= SYSTEM_STATE_UP))
What is the thread dispatch disable level and the system state
at this point?
In case the thread dispatch disable level is not zero, then
something is probably broken
in the
operating system code which is difficult to find. Could be a
general memory corruption
problem
too. Which RTEMS version do you use?
The thread dispatch disable level is usually -1 or -2.
(0xFFFE or 0xFFD).
A negative value is very bad, but easy to detect via manual
instrumentation (only an hand full
of spots touch this variable) or hardware breakpoints/watchpoints.
Looks the rest of
_Per_CPU_Information all right?
It looks like it's only the thread_dispatch_disable_level that's
broken.
We'll go and grep for all places for all the places it's touched,
and look for something.
The problem with watchpoints is they fire exceptionally often, and
putting in a conditional
watchpoint slows the code to a crawl, but that may be worth it.
Here are some printouts of the relevant structs right after a crash:
$4 = {
cpu_per_cpu = {},
isr_nest_level = 0,
thread_dispatch_disable_level = 4294967295,
executing = 0xc01585c8,
heir = 0xc0154038,
dispatch_necessary = true,
time_of_last_context_switch = {
sec = 2992,
frac = 10737447432380511034
},
Stats = {}
}
No, this doesn't look good. According to the stack trace you are in
thread context. However, we
have executing != heir and dispatch_necessary == true. This is a
broken state itself. I guess,
something is wrong with the interrupt level so that a context switch
is blocked. On ARMv7-M
this is done via the system call exception.
This is a bit beyond my RTEMS knowledge. What would you advise
looking into?
I would try to instrument the code to figure out where the thread
dispatch disable level goes negative.
I would also read the file doc/cpu_supplement/arm.t and look for ARMv7-M.
--
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
Re: Random lwIP Crashes in _POSIX_Mutex_Lock_support()
On 10/21/2015 8:35 AM, Sebastian Huber wrote:
On 21/10/15 15:08, Isaac Gutekunst wrote:
On 10/21/2015 09:00 AM, Sebastian Huber wrote:
On 21/10/15 14:56, Isaac Gutekunst wrote:
On 10/21/2015 08:24 AM, Sebastian Huber wrote:
On 21/10/15 14:13, Isaac Gutekunst wrote:
Thanks for the reply.
On 10/21/2015 01:50 AM, Sebastian Huber wrote:
On 20/10/15 16:02, Isaac Gutekunst wrote:
[...]
As far as I can tell this would only occur if the caller of
pthread_mutex_lock was in a
"bad"
state. I don't believe it is in an interrupt context, and don't
know what other bad states
could exist.
We have
#define _CORE_mutex_Check_dispatch_for_seize(_wait) \
(!_Thread_Dispatch_is_enabled() \
&& (_wait) \
&& (_System_state_Get() >= SYSTEM_STATE_UP))
What is the thread dispatch disable level and the system state at
this point?
In case the thread dispatch disable level is not zero, then
something is probably broken
in the
operating system code which is difficult to find. Could be a
general memory corruption
problem
too. Which RTEMS version do you use?
The thread dispatch disable level is usually -1 or -2.
(0xFFFE or 0xFFD).
A negative value is very bad, but easy to detect via manual
instrumentation (only an hand full
of spots touch this variable) or hardware breakpoints/watchpoints.
Looks the rest of
_Per_CPU_Information all right?
It looks like it's only the thread_dispatch_disable_level that's
broken.
We'll go and grep for all places for all the places it's touched,
and look for something.
The problem with watchpoints is they fire exceptionally often, and
putting in a conditional
watchpoint slows the code to a crawl, but that may be worth it.
Here are some printouts of the relevant structs right after a crash:
$4 = {
cpu_per_cpu = {},
isr_nest_level = 0,
thread_dispatch_disable_level = 4294967295,
executing = 0xc01585c8,
heir = 0xc0154038,
dispatch_necessary = true,
time_of_last_context_switch = {
sec = 2992,
frac = 10737447432380511034
},
Stats = {}
}
No, this doesn't look good. According to the stack trace you are in
thread context. However, we
have executing != heir and dispatch_necessary == true. This is a
broken state itself. I guess,
something is wrong with the interrupt level so that a context switch
is blocked. On ARMv7-M
this is done via the system call exception.
This is a bit beyond my RTEMS knowledge. What would you advise looking
into?
I would try to instrument the code to figure out where the thread
dispatch disable level goes negative.
The test suite macros check that thread_dispatch_disable_level
is always 0 when a call returns (in a uniprocessor configuration).
If all the tests are passing on this BSP, then my assumption would
be a mismatch someone in architecture specific code related to
the interrupt path. This is not guaranteed but likely.
The settings above look like something decided to trigger a
context switch and left a dispatch disable critical but was
never in a dispatch disable critical section. So when it
left/decremented it, there was no corresponding enter/increment.
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Random lwIP Crashes in _POSIX_Mutex_Lock_support()
On 10/21/2015 09:58 AM, Joel Sherrill wrote:
On 10/21/2015 8:35 AM, Sebastian Huber wrote:
On 21/10/15 15:08, Isaac Gutekunst wrote:
On 10/21/2015 09:00 AM, Sebastian Huber wrote:
On 21/10/15 14:56, Isaac Gutekunst wrote:
On 10/21/2015 08:24 AM, Sebastian Huber wrote:
On 21/10/15 14:13, Isaac Gutekunst wrote:
Thanks for the reply.
On 10/21/2015 01:50 AM, Sebastian Huber wrote:
On 20/10/15 16:02, Isaac Gutekunst wrote:
[...]
As far as I can tell this would only occur if the caller of
pthread_mutex_lock was in a
"bad"
state. I don't believe it is in an interrupt context, and don't
know what other bad states
could exist.
We have
#define _CORE_mutex_Check_dispatch_for_seize(_wait) \
(!_Thread_Dispatch_is_enabled() \
&& (_wait) \
&& (_System_state_Get() >= SYSTEM_STATE_UP))
What is the thread dispatch disable level and the system state at
this point?
In case the thread dispatch disable level is not zero, then
something is probably broken
in the
operating system code which is difficult to find. Could be a
general memory corruption
problem
too. Which RTEMS version do you use?
The thread dispatch disable level is usually -1 or -2.
(0xFFFE or 0xFFD).
A negative value is very bad, but easy to detect via manual
instrumentation (only an hand full
of spots touch this variable) or hardware breakpoints/watchpoints.
Looks the rest of
_Per_CPU_Information all right?
It looks like it's only the thread_dispatch_disable_level that's
broken.
We'll go and grep for all places for all the places it's touched,
and look for something.
The problem with watchpoints is they fire exceptionally often, and
putting in a conditional
watchpoint slows the code to a crawl, but that may be worth it.
Here are some printouts of the relevant structs right after a crash:
$4 = {
cpu_per_cpu = {},
isr_nest_level = 0,
thread_dispatch_disable_level = 4294967295,
executing = 0xc01585c8,
heir = 0xc0154038,
dispatch_necessary = true,
time_of_last_context_switch = {
sec = 2992,
frac = 10737447432380511034
},
Stats = {}
}
No, this doesn't look good. According to the stack trace you are in
thread context. However, we
have executing != heir and dispatch_necessary == true. This is a
broken state itself. I guess,
something is wrong with the interrupt level so that a context switch
is blocked. On ARMv7-M
this is done via the system call exception.
This is a bit beyond my RTEMS knowledge. What would you advise looking
into?
I would try to instrument the code to figure out where the thread
dispatch disable level goes negative.
We have done some testing and found an interrupt that decrements the value below zero. However,
this may not be the problem, as a previous call may have incorrectly decremented it to zero.
We'll keep looking.
The test suite macros check that thread_dispatch_disable_level
is always 0 when a call returns (in a uniprocessor configuration).
If all the tests are passing on this BSP, then my assumption would
be a mismatch someone in architecture specific code related to
the interrupt path. This is not guaranteed but likely.
Unfortunately we have not been able to run the tests for this BSP. This seems like good
motivation to make them run.
Does it seem likely that there would be problems between different ARMV7M BSPs? Where one
Cortex-M4 BSP works while a different one doesn't on this level? My understanding is they share
the same NVIC and should behave the same.
The settings above look like something decided to trigger a
context switch and left a dispatch disable critical but was
never in a dispatch disable critical section. So when it
left/decremented it, there was no corresponding enter/increment.
Is this something a new BPS that doesn't change anything besides the bare minimum would likely
break? I'm wondering if we should compare to a different Cortex M BSP.
Maybe there is a difference between the M4 and M7 that is sufficient to
introduce problems.
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] bsp/qoriq: Use U-Boot provided FDT
On Wed, Oct 21, 2015 at 2:07 AM, Sebastian Huber wrote: > On 21/10/15 06:15, Chris Johns wrote: >> >> On 20/10/2015 9:10 pm, Sebastian Huber wrote: >>> >>> On 20/10/15 00:46, Chris Johns wrote: [...] >> >> It is easy to add things like the FDT support to the shared BSP tree and >> if you look over that code we have all sorts of specific localised >> things that effect various subsets of BSPs as well as important generic >> things almost all BSPs use. The BSP shared directory is becoming more >> complex. Changes in that directory tree now effect a wider and wider >> range of BSPs and often when things go in it is specific and not a >> general API with some level of formal agreement. Add to this testing on >> all effected BSPs is often difficult. As I said these things are easy to >> add but difficult to remove or change because users end up depending on >> them as they are. >> >> This issue is coming to a head with the build system change. >> >> If we change or do not provide something in the build system change that >> is BSP specific and not an API is it our fault for forcing application >> changes or is it the BSP developer's for not providing a formal >> interface? What is ok to vary for a BSP and what is not ok? >> >> As I said easy to add and hard to maintain through changes. We are doing >> our best not to change things but it is not easy. > > > Instead of less code in the shared area we need more. There is still a lot > of copy and paste in the BSPs. During the interrupt support code cleanup > several years ago I removed hundreds of lines of duplicated code. > I believe Chris' point is that we need more guidance in what should go there, and we should aim for more uniformity in the BSP layer to make the guidance simple and maintainable. The problem we face is the lack of good abstraction within and across BSPs. This is a separate issue from the FDT patch itself. >> I do not remember any discussion about how BSPs and FDT will be supported. >>> >>> U-Boot supports FDT for several years now. So, all U-Boot based BSPs may >>> use this option. >>> >> FDT is not constrained to u-boot. There are other possible uses in RTEMS. > > > Yes, and for all of the uses a libfdt is probably required. > > [...] Can you please describe this use of FDT in RTEMS and how this can used by more than the immediate use you have for your BSP? >>> >>> The use of FDT for BSPs is to get U-Boot provided parameters. >>> >> Where is this interaction documented and how would a user find this >> information? > > > It is documented in the source code and in the README of the BSP. > > The BSP area of RTEMS is virtually undocumented and even worse the existing > documentation is partly outdated and misleading. > We should try to plan how to correct this problem especially for code in the shared part. Doxygen on the source is a good start. README files can be hard to find and easy to ignore. Gedare ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Suggestions for BSPs to Obsolete
On 10/21/2015 12:41 AM, Thomas Dörfler wrote: I have discussed dropping BSPs from support and from a technical point I fully agree that this must be done. We should have some sort of active BSPs which are regularily tested. On the other hand, RTEMS can only live and grow, if it is attrative enough for new users. Therefore we should not simply drop old BSP and remove them from mentioning. Instead we should keep a list stating "mr332 supported up to version 4.9". This indicates, that the basic code is still available for taming the processor, but the structure and API may need tinkering before working again with 4.12. The Wiki pages for BSPs have included this information when we have done this in the past. One of the things I stated was that nothing would be removed before instructions for removing a BSP and architecture were in the Wiki. This is specifically to provide a checklist, encourage removing the BSP as a single commit, remember to touch documentation, wiki, supported CPU lists, update a BSP Wiki page, etc. This is not so important for the really old BSPs (68k-based, various other stuff), but also for those, which just pop into RTEMS but then are not properly maintained (like possibly some STM/ARM stuff). IMO this sweep is more for the long dead and to reduce the number of configurations to convert to waf and to feed into Buildbot. Beyond that we need tiers. This morning on the way in, I thought it would be good to get a notice out to the EPICS community to get a list of boards they actually have an interest in. We normally don't hear directly from them. Chris and I discussed the mvme136[1] being removed but the mvme147, 162, and 167 have NICs, more RAM, and could still be used in the labs. I know I spoke with someone recently who had 167's as backups. [1] The mvme136 was the original RTEMS BSP. It was already in use when I started in 1989. Of the three architectures and BSPs done during that phase of RTEMS' life. The three were m68k/mvme136, i386/force386, and i960/cyclone. wkr, Thomas. Am 21.10.2015 um 01:24 schrieb Chris Johns: On 21/10/2015 12:56 am, Joel Sherrill wrote: On 10/20/2015 6:15 AM, Sebastian Huber wrote: Maybe we should build a list of BSP directories and find maintainers for each directory in some time frame. Then remove all BSPs without a maintainer. That is one approach. Another is defining tiers for the BSP and being more aggressive about dropping them. I think Chris has discussed his ideas on tiers before. I think both will be needed. We are moving to Phabricator and having areas developers can approve will be important. I am concerned if we do not things will sit and not be pushed through. I also think we will need tiers so we can manage the results from buildbot. There are active and current BSPs we have no way of testing because we do not have the hardware. If a user has a board and sets up a slave to allow testing for that BSP it will reach a higher tier and we have better testing. Chris ___ 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: Random lwIP Crashes in _POSIX_Mutex_Lock_support()
Forwarded Message
Subject:Re: Random lwIP Crashes in _POSIX_Mutex_Lock_support()
Date: Wed, 21 Oct 2015 09:48:42 -0400
From: Jay Doyle
To: Sebastian Huber
On 10/21/2015 09:35 AM, Sebastian Huber wrote:
On 21/10/15 15:08, Isaac Gutekunst wrote:
On 10/21/2015 09:00 AM, Sebastian Huber wrote:
On 21/10/15 14:56, Isaac Gutekunst wrote:
On 10/21/2015 08:24 AM, Sebastian Huber wrote:
On 21/10/15 14:13, Isaac Gutekunst wrote:
Thanks for the reply.
On 10/21/2015 01:50 AM, Sebastian Huber wrote:
On 20/10/15 16:02, Isaac Gutekunst wrote:
[...]
As far as I can tell this would only occur if the caller of
pthread_mutex_lock was in a
"bad"
state. I don't believe it is in an interrupt context, and don't
know what other bad states
could exist.
We have
#define _CORE_mutex_Check_dispatch_for_seize(_wait) \
(!_Thread_Dispatch_is_enabled() \
&& (_wait) \
&& (_System_state_Get() >= SYSTEM_STATE_UP))
What is the thread dispatch disable level and the system state
at this point?
In case the thread dispatch disable level is not zero, then
something is probably broken
in the
operating system code which is difficult to find. Could be a
general memory corruption
problem
too. Which RTEMS version do you use?
The thread dispatch disable level is usually -1 or -2.
(0xFFFE or 0xFFD).
A negative value is very bad, but easy to detect via manual
instrumentation (only an hand full
of spots touch this variable) or hardware breakpoints/watchpoints.
Looks the rest of
_Per_CPU_Information all right?
It looks like it's only the thread_dispatch_disable_level that's
broken.
We'll go and grep for all places for all the places it's touched,
and look for something.
The problem with watchpoints is they fire exceptionally often, and
putting in a conditional
watchpoint slows the code to a crawl, but that may be worth it.
Here are some printouts of the relevant structs right after a crash:
$4 = {
cpu_per_cpu = {},
isr_nest_level = 0,
thread_dispatch_disable_level = 4294967295,
executing = 0xc01585c8,
heir = 0xc0154038,
dispatch_necessary = true,
time_of_last_context_switch = {
sec = 2992,
frac = 10737447432380511034
},
Stats = {}
}
No, this doesn't look good. According to the stack trace you are in
thread context. However, we
have executing != heir and dispatch_necessary == true. This is a
broken state itself. I guess,
something is wrong with the interrupt level so that a context switch
is blocked. On ARMv7-M
this is done via the system call exception.
This is a bit beyond my RTEMS knowledge. What would you advise
looking into?
I would try to instrument the code to figure out where the thread
dispatch disable level goes negative.
We just did. I added a check in _ARMV7M_Interrupt_service_leave to see
if the _Thread_Dispatch_disable_level is positive before the
decrementing it and this eventually fails.
I'm not sure if this tells us much because I think the call itself
correct. In this particular case it is processing an I2C interrupt. I
will try to see if we can capture information about the sequence of
changes to the _Thread_Dispatch_disable_level just before the point in
which we know something is clearly wrong (i.e., decreasing it below zero.)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] RFS: Fix resource leak
Did you also commit this to 4.11 branch?
Does it apply to the 4.10 branch?
On 10/21/2015 2:56 AM, Sebastian Huber wrote:
Close #2433.
---
cpukit/libfs/src/rfs/rtems-rfs-rtems.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/cpukit/libfs/src/rfs/rtems-rfs-rtems.c
b/cpukit/libfs/src/rfs/rtems-rfs-rtems.c
index 999dfb3..a0ade04 100644
--- a/cpukit/libfs/src/rfs/rtems-rfs-rtems.c
+++ b/cpukit/libfs/src/rfs/rtems-rfs-rtems.c
@@ -831,6 +831,8 @@ rtems_rfs_rtems_initialise
(rtems_filesystem_mount_table_entry_t* mt_entry,
rc = rtems_rfs_fs_open (mt_entry->dev, rtems, flags, max_held_buffers, &fs);
if (rc)
{
+rtems_rfs_mutex_unlock (&rtems->access);
+rtems_rfs_mutex_destroy (&rtems->access);
free (rtems);
return rtems_rfs_rtems_error ("initialise: open", errno);
}
--
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: Random lwIP Crashes in _POSIX_Mutex_Lock_support()
On 10/21/2015 9:09 AM, Isaac Gutekunst wrote:
On 10/21/2015 09:58 AM, Joel Sherrill wrote:
On 10/21/2015 8:35 AM, Sebastian Huber wrote:
On 21/10/15 15:08, Isaac Gutekunst wrote:
On 10/21/2015 09:00 AM, Sebastian Huber wrote:
On 21/10/15 14:56, Isaac Gutekunst wrote:
On 10/21/2015 08:24 AM, Sebastian Huber wrote:
On 21/10/15 14:13, Isaac Gutekunst wrote:
Thanks for the reply.
On 10/21/2015 01:50 AM, Sebastian Huber wrote:
On 20/10/15 16:02, Isaac Gutekunst wrote:
[...]
As far as I can tell this would only occur if the caller of
pthread_mutex_lock was in a
"bad"
state. I don't believe it is in an interrupt context, and don't
know what other bad states
could exist.
We have
#define _CORE_mutex_Check_dispatch_for_seize(_wait) \
(!_Thread_Dispatch_is_enabled() \
&& (_wait) \
&& (_System_state_Get() >= SYSTEM_STATE_UP))
What is the thread dispatch disable level and the system state at
this point?
In case the thread dispatch disable level is not zero, then
something is probably broken
in the
operating system code which is difficult to find. Could be a
general memory corruption
problem
too. Which RTEMS version do you use?
The thread dispatch disable level is usually -1 or -2.
(0xFFFE or 0xFFD).
A negative value is very bad, but easy to detect via manual
instrumentation (only an hand full
of spots touch this variable) or hardware breakpoints/watchpoints.
Looks the rest of
_Per_CPU_Information all right?
It looks like it's only the thread_dispatch_disable_level that's
broken.
We'll go and grep for all places for all the places it's touched,
and look for something.
The problem with watchpoints is they fire exceptionally often, and
putting in a conditional
watchpoint slows the code to a crawl, but that may be worth it.
Here are some printouts of the relevant structs right after a crash:
$4 = {
cpu_per_cpu = {},
isr_nest_level = 0,
thread_dispatch_disable_level = 4294967295,
executing = 0xc01585c8,
heir = 0xc0154038,
dispatch_necessary = true,
time_of_last_context_switch = {
sec = 2992,
frac = 10737447432380511034
},
Stats = {}
}
No, this doesn't look good. According to the stack trace you are in
thread context. However, we
have executing != heir and dispatch_necessary == true. This is a
broken state itself. I guess,
something is wrong with the interrupt level so that a context switch
is blocked. On ARMv7-M
this is done via the system call exception.
This is a bit beyond my RTEMS knowledge. What would you advise looking
into?
I would try to instrument the code to figure out where the thread
dispatch disable level goes negative.
We have done some testing and found an interrupt that decrements the value
below zero. However,
this may not be the problem, as a previous call may have incorrectly
decremented it to zero.
We'll keep looking.
The test suite macros check that thread_dispatch_disable_level
is always 0 when a call returns (in a uniprocessor configuration).
If all the tests are passing on this BSP, then my assumption would
be a mismatch someone in architecture specific code related to
the interrupt path. This is not guaranteed but likely.
Unfortunately we have not been able to run the tests for this BSP. This seems
like good
motivation to make them run.
Does it seem likely that there would be problems between different ARMV7M BSPs?
Where one
Cortex-M4 BSP works while a different one doesn't on this level? My
understanding is they share
the same NVIC and should behave the same.
In general terms, the more specific you get with a CPU model, the
fewer and fewer users there are on a specific line of code. It is
possible that this code just hasn't been beaten up that much.
The settings above look like something decided to trigger a
context switch and left a dispatch disable critical but was
never in a dispatch disable critical section. So when it
left/decremented it, there was no corresponding enter/increment.
Is this something a new BPS that doesn't change anything besides the bare
minimum would likely
break? I'm wondering if we should compare to a different Cortex M BSP.
Everything can be wrong at some point. :(
I suspect a path through the interrupt code that somehow either didn't
increment it (unlikely) or double-decremented it (likely).
A desk check that this value is only incremented once and decremented
once per path might turn it up.
Maybe there is a difference between the M4 and M7 that is sufficient to
introduce problems.
That is possible. Without looking at the code, be suspicious of
code that is unique to your architectural revision or in conditionals.
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Fixes GPIO APIs Naming Convention and Comments
On Thu, Oct 15, 2015 at 12:02 AM, Gedare Bloom wrote: > A ticket would be preferred. I didn't notice the attachment. Can you > please (1) make a ticket, (2) close it in the commit message, and (3) > re-send your patch. > > Ben, if you get around to it, please commit the revised patch when it > comes through. I'll be away for a few days and unable to commit. Tested on mainline and merged. Ticket: https://devel.rtems.org/ticket/2435 > > On Wed, Oct 14, 2015 at 5:06 PM, sudarshan.rajagopalan > wrote: >> On 2015-10-14 16:28, Gedare Bloom wrote: >>> >>> OK to commit, but the patch did not apply cleanly for me, something >>> wrong with the mail message. >> >> >> >> Hi Gedare, >> >> The mail message was not sent using git send-email (this is not working for >> us currently), so I copied the contents of the patch to this mail message. >> Could you try using the patch attached in my first mail? >> >> Also, does this require a ticket? >> >> Thanks and Regards, >> Sudarshan >> >> >>> >>> On Tue, Oct 13, 2015 at 3:11 AM, Ben Gras wrote: All, This change renames these gpio-specific functions: rtems_bsp_enable_interrupt rtems_bsp_disable_interrupt rtems_bsp_select_specific_io to rtems_gpio_bsp_enable_interrupt rtems_gpio_bsp_disable_interrupt rtems_gpio_bsp_select_specific_io +1, Definitely an improvement. On Mon, Oct 12, 2015 at 7:37 PM, sudarshan.rajagopalan wrote: > > > Just found few function names to be inconsistent towards the naming > convention, and also few API documentation in the RTEMS GPIO files. > Please > commit this if required. > > Thanks and Regards, > Sudarshan Rajagopalan > > From e17ce266ba4cfaec0159c5477697847629946ced Mon Sep 17 00:00:00 2001 > From: Sudarshan Rajagopalan > Date: Mon, 12 Oct 2015 12:47:35 -0400 > Subject: [PATCH] Fixes GPIO APIs Naming Convention and Comments > > --- > c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c | 8 > c/src/lib/libbsp/arm/raspberrypi/gpio/rpi-gpio.c | 4 ++-- > c/src/lib/libbsp/shared/gpio.c | 6 +++--- > c/src/lib/libbsp/shared/include/gpio.h | 20 > > 4 files changed, 21 insertions(+), 17 deletions(-) > > diff --git a/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c > b/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c > index 8cf690f..9737dec 100644 > --- a/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c > +++ b/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c > @@ -299,7 +299,7 @@ uint32_t > rtems_gpio_bsp_interrupt_line(rtems_vector_number vector) >return event_status; > } > > -rtems_status_code rtems_bsp_enable_interrupt( > +rtems_status_code rtems_gpio_bsp_enable_interrupt( >uint32_t bank, >uint32_t pin, >rtems_gpio_interrupt interrupt > @@ -354,7 +354,7 @@ rtems_status_code rtems_bsp_enable_interrupt( >return RTEMS_SUCCESSFUL; > } > > -rtems_status_code rtems_bsp_disable_interrupt( > +rtems_status_code rtems_gpio_bsp_disable_interrupt( >uint32_t bank, >uint32_t pin, >rtems_gpio_interrupt interrupt > @@ -528,7 +528,7 @@ uint32_t > rtems_gpio_bsp_interrupt_line(rtems_vector_number vector) >return -1; > } > > -rtems_status_code rtems_bsp_enable_interrupt( > +rtems_status_code rtems_gpio_bsp_enable_interrupt( >uint32_t bank, >uint32_t pin, >rtems_gpio_interrupt interrupt > @@ -536,7 +536,7 @@ rtems_status_code rtems_bsp_enable_interrupt( >return RTEMS_NOT_DEFINED; > } > > -rtems_status_code rtems_bsp_disable_interrupt( > +rtems_status_code rtems_gpio_bsp_disable_interrupt( >uint32_t bank, >uint32_t pin, >rtems_gpio_interrupt interrupt > diff --git a/c/src/lib/libbsp/arm/raspberrypi/gpio/rpi-gpio.c > b/c/src/lib/libbsp/arm/raspberrypi/gpio/rpi-gpio.c > index a782d11..4fb2c93 100644 > --- a/c/src/lib/libbsp/arm/raspberrypi/gpio/rpi-gpio.c > +++ b/c/src/lib/libbsp/arm/raspberrypi/gpio/rpi-gpio.c > @@ -183,7 +183,7 @@ uint32_t > rtems_gpio_bsp_interrupt_line(rtems_vector_number vector) >return event_status; > } > > -rtems_status_code rtems_bsp_enable_interrupt( > +rtems_status_code rtems_gpio_bsp_enable_interrupt( >uint32_t bank, >uint32_t pin, >rtems_gpio_interrupt interrupt > @@ -227,7 +227,7 @@ rtems_status_code rtems_bsp_enable_interrupt( >return RTEMS_SUCCESSFUL; > } > > -rtems_status_code rtems_bsp_disable_interrupt( > +rtems_status_code rtems_gpio_bsp_disable_interrupt( >uint32_t bank, >uint32_t pin, >rtems_gpio_interrupt interrupt > diff --git a/c/src/lib/libbsp/shared/gpio.c > b/c/src/lib/libbsp/shared/gpio.c > index 80e2727..b806556
Re: [PATCH] Add STM32 HAL Files for F4 and F7
Isaac, Is all the code attached licensed under a 2/3-bsd? Gedare On Wed, Oct 14, 2015 at 4:54 PM, Joel Sherrill wrote: > > > On 10/14/2015 3:35 PM, Gedare Bloom wrote: >> >> I don't have a problem on the surface of it, but can we get a clear >> statement of the licensing for the included code? >> > > The patch is huge but includes the license in pdf and rtf format. > Based on the one source file I looked at, the license is BSD > w/advertising. I am not sure if this is the same with all files. > > This is a cut and paste from a file added: > > + * © COPYRIGHT(c) 2015 STMicroelectronics > + * > + * Redistribution and use in source and binary forms, with or without > modification, > + * are permitted provided that the following conditions are met: > + * 1. Redistributions of source code must retain the above copyright > notice, > + * this list of conditions and the following disclaimer. > + * 2. Redistributions in binary form must reproduce the above copyright > notice, > + * this list of conditions and the following disclaimer in the > documentation > + * and/or other materials provided with the distribution. > + * 3. Neither the name of STMicroelectronics nor the names of its > contributors > + * may be used to endorse or promote products derived from this > software > + * without specific prior written permission. > + * > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS > IS" > + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, > THE > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE ARE > + * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE > LIABLE > + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR > CONSEQUENTIAL > + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS > OR > + * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) > HOWEVER > + * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT > LIABILITY, > + * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF > THE USE > + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > + * > > > >> >> >> On Mon, Sep 28, 2015 at 4:25 PM, Isaac Gutekunst >> wrote: >>> >>> Hi Devel, >>> >>> As mentioned earlier, Vecna has developed two BSP families using the HAL >>> code provide by ST as a foundation. The code isn't perfect, but it let us >>> get up to speed very fast, and provides a consistent abstraction across a >>> number of processors. >>> >>> I formatted a giant patch with all the relevant files needed for the new >>> BSP >>> that will be arriving later. The plan is to get this code approved and >>> merged, and then add the BSP piece by piece to reduce the amount of code >>> coming in at once. >>> >>> >>> This includes some HAL files that we aren't using in the BSP just yet. >>> Let >>> me know if we should remove them. It's a rather absurd amount of code :) >>> >>> >>> As before, I can't get git-send-email to work. In addition, the patches >>> are >>> giant, so I've inserted links to files in Google Drive. >>> >>> https://drive.google.com/open?id=0BxaqNLUoI5onZ3lUUDNrYXlyX1U >>> https://drive.google.com/open?id=0BxaqNLUoI5onM3JsenRJRkotWm8 >>> >>> >>> >>> -- >>> Isaac Gutekunst >>> Embedded Systems Software Engineer >>> isaac.guteku...@vecna.com >>> www.vecna.com >>> >>> Cambridge Research Laboratory >>> Vecna Technologies, Inc. >>> 36 Cambridge Park Drive >>> Cambridge, MA 02140 >>> Office: (617) 864-0636 x3069 >>> Fax: (617) 864-0638 >>> http://vecna.com >>> >>> Better Technology, Better World (TM) >>> >>> ___ >>> 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 >> > > -- > 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] Add STM32 HAL Files for F4 and F7
I haven't actually looked at every file individually, but AFIK yes. Isaac On 10/21/2015 11:55 AM, Gedare Bloom wrote: Isaac, Is all the code attached licensed under a 2/3-bsd? Gedare On Wed, Oct 14, 2015 at 4:54 PM, Joel Sherrill wrote: On 10/14/2015 3:35 PM, Gedare Bloom wrote: I don't have a problem on the surface of it, but can we get a clear statement of the licensing for the included code? The patch is huge but includes the license in pdf and rtf format. Based on the one source file I looked at, the license is BSD w/advertising. I am not sure if this is the same with all files. This is a cut and paste from a file added: + * © COPYRIGHT(c) 2015 STMicroelectronics + * + * Redistribution and use in source and binary forms, with or without modification, + * are permitted provided that the following conditions are met: + * 1. Redistributions of source code must retain the above copyright notice, + * this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright notice, + * this list of conditions and the following disclaimer in the documentation + * and/or other materials provided with the distribution. + * 3. Neither the name of STMicroelectronics nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE + * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR + * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER + * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, + * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * On Mon, Sep 28, 2015 at 4:25 PM, Isaac Gutekunst wrote: Hi Devel, As mentioned earlier, Vecna has developed two BSP families using the HAL code provide by ST as a foundation. The code isn't perfect, but it let us get up to speed very fast, and provides a consistent abstraction across a number of processors. I formatted a giant patch with all the relevant files needed for the new BSP that will be arriving later. The plan is to get this code approved and merged, and then add the BSP piece by piece to reduce the amount of code coming in at once. This includes some HAL files that we aren't using in the BSP just yet. Let me know if we should remove them. It's a rather absurd amount of code :) As before, I can't get git-send-email to work. In addition, the patches are giant, so I've inserted links to files in Google Drive. https://drive.google.com/open?id=0BxaqNLUoI5onZ3lUUDNrYXlyX1U https://drive.google.com/open?id=0BxaqNLUoI5onM3JsenRJRkotWm8 -- Isaac Gutekunst Embedded Systems Software Engineer isaac.guteku...@vecna.com www.vecna.com Cambridge Research Laboratory Vecna Technologies, Inc. 36 Cambridge Park Drive Cambridge, MA 02140 Office: (617) 864-0636 x3069 Fax: (617) 864-0638 http://vecna.com Better Technology, Better World (TM) ___ 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 -- 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
Selecting Tests to run/Missing tests
Hi All, I'm trying to run the RTEMS tests for our new BSP. I've managed to get close, but am missing something. In general, I'm trying to figure out how the build system decides what tests to build. Below is a bunch of information about what I've tried. It might be irrelevant, so if there is something obvious, just don't bother reading and let me know :) Details --- I run configure with --enable tests, and have disabled a bunch of tests that don't compile. See the list further down. The file does have effect. ../rtems/configure --enable-rtemsbsp="stm32f7x" --enable-maintainer-mode --enable-tests --target=arm-rtems4.11 --prefix=/other/rtems/lib-rtems --disable-networking --enable-rtems-debug In the install path, I have a bunch of tests exes. They are specifically located in /other/rtems/lib-rtems/arm-rtems4.11/stm32f7x/lib/rtems-4.12/tests/ psxtmbarrier01.doc psxtmmutex01.exe psxtmsem03.doc psxtmbarrier01.exe psxtmmutex02.doc psxtmsem03.exe psxtmbarrier02.doc psxtmmutex02.exe psxtmsem04.doc psxtmbarrier02.exe psxtmmutex03.doc psxtmsem04.exe psxtmbarrier03.doc psxtmmutex03.exe psxtmsem05.doc psxtmbarrier03.exe psxtmmutex04.doc psxtmsem05.exe psxtmbarrier04.doc psxtmmutex04.exe psxtmsleep01.doc psxtmbarrier04.exe psxtmmutex05.doc psxtmsleep01.exe psxtmcond01.doc psxtmmutex05.exe psxtmsleep02.doc psxtmcond01.exe psxtmmutex06.doc psxtmsleep02.exe psxtmcond02.doc psxtmmutex06.exe psxtmthread01.doc psxtmcond02.exe psxtmmutex07.doc psxtmthread01.exe psxtmcond03.doc psxtmmutex07.exe psxtmthread02.doc psxtmcond03.exe psxtmnanosleep01.doc psxtmthread02.exe psxtmcond04.doc psxtmnanosleep01.exe psxtmthread03.doc psxtmcond04.exe psxtmnanosleep02.doc psxtmthread03.exe psxtmcond05.doc psxtmnanosleep02.exe psxtmthread04.doc psxtmcond05.exe psxtmrwlock01.doc psxtmthread04.exe psxtmcond06.doc psxtmrwlock01.exe psxtmthread05.doc psxtmcond06.exe psxtmrwlock02.doc psxtmthread05.exe psxtmcond07.doc psxtmrwlock02.exe psxtmthread06.doc psxtmcond07.exe psxtmrwlock03.doc psxtmthread06.exe psxtmcond08.doc psxtmrwlock03.exe rhdeadlockbrk.adoc psxtmcond08.exe psxtmrwlock04.doc rhdeadlockbrk.exe psxtmcond09.doc psxtmrwlock04.exe rhilatency.adoc psxtmcond09.exe psxtmrwlock05.doc rhilatency.exe psxtmcond10.doc psxtmrwlock05.exe rhmlatency.adoc psxtmcond10.exe psxtmrwlock06.doc rhmlatency.exe psxtmkey01.doc psxtmrwlock06.exe rhsemshuffle.adoc psxtmkey01.exe psxtmrwlock07.doc rhsemshuffle.exe psxtmkey02.doc psxtmrwlock07.exe rhtaskpreempt.adoc psxtmkey02.exe psxtmsem01.docrhtaskpreempt.exe psxtmmq01.doc psxtmsem01.exerhtaskswitch.adoc psxtmmq01.exe psxtmsem02.docrhtaskswitch.exe psxtmmutex01.docpsxtmsem02.exe This is missing a bunch of tests. This is the contents of libbsp/arm/stm32f7x/make/custom/stm32f7x-testsuite.tcfg fsdosfsname01 jffs2_fserror jffs2_fslink jffs2_fspatheval jffs2_fspermission jffs2_fsrdwr jffs2_fsscandir01 jffs2_fssymlink jffs2_fstime devfs01 devfs02 devfs03 devfs04 termios02 termios03 termios04 stringto01 math mathf tar03 mathl complex sptimecounter01 spfatal26 spinternalerror01 fsnofs01 -- Isaac Gutekunst Embedded Systems Software Engineer isaac.guteku...@vecna.com www.vecna.com ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Selecting Tests to run/Missing tests
On 10/21/2015 12:30 PM, Isaac Gutekunst wrote: Hi All, I'm trying to run the RTEMS tests for our new BSP. I've managed to get close, but am missing something. In general, I'm trying to figure out how the build system decides what tests to build. Below is a bunch of information about what I've tried. It might be irrelevant, so if there is something obvious, just don't bother reading and let me know :) There is not as much magic as you might suspect. :) Comments scattered below. Details --- I run configure with --enable tests, and have disabled a bunch of tests that don't compile. See the list further down. The file does have effect. ../rtems/configure --enable-rtemsbsp="stm32f7x" --enable-maintainer-mode --enable-tests --target=arm-rtems4.11 --prefix=/other/rtems/lib-rtems --disable-networking --enable-rtems-debug (1) You can configure for no tests, samples only, or all tests. The set of tests built varies based on if things like networking, posix, and SMP are enabled. In the install path, I have a bunch of tests exes. They are specifically located in /other/rtems/lib-rtems/arm-rtems4.11/stm32f7x/lib/rtems-4.12/tests/ psxtmbarrier01.doc psxtmmutex01.exe psxtmsem03.doc psxtmbarrier01.exe psxtmmutex02.doc psxtmsem03.exe psxtmbarrier02.doc psxtmmutex02.exe psxtmsem04.doc psxtmbarrier02.exe psxtmmutex03.doc psxtmsem04.exe psxtmbarrier03.doc psxtmmutex03.exe psxtmsem05.doc psxtmbarrier03.exe psxtmmutex04.doc psxtmsem05.exe psxtmbarrier04.doc psxtmmutex04.exe psxtmsleep01.doc psxtmbarrier04.exe psxtmmutex05.doc psxtmsleep01.exe psxtmcond01.doc psxtmmutex05.exe psxtmsleep02.doc psxtmcond01.exe psxtmmutex06.doc psxtmsleep02.exe psxtmcond02.doc psxtmmutex06.exe psxtmthread01.doc psxtmcond02.exe psxtmmutex07.doc psxtmthread01.exe psxtmcond03.doc psxtmmutex07.exe psxtmthread02.doc psxtmcond03.exe psxtmnanosleep01.doc psxtmthread02.exe psxtmcond04.doc psxtmnanosleep01.exe psxtmthread03.doc psxtmcond04.exe psxtmnanosleep02.doc psxtmthread03.exe psxtmcond05.doc psxtmnanosleep02.exe psxtmthread04.doc psxtmcond05.exe psxtmrwlock01.doc psxtmthread04.exe psxtmcond06.doc psxtmrwlock01.exe psxtmthread05.doc psxtmcond06.exe psxtmrwlock02.doc psxtmthread05.exe psxtmcond07.doc psxtmrwlock02.exe psxtmthread06.doc psxtmcond07.exe psxtmrwlock03.doc psxtmthread06.exe psxtmcond08.doc psxtmrwlock03.exe rhdeadlockbrk.adoc psxtmcond08.exe psxtmrwlock04.doc rhdeadlockbrk.exe psxtmcond09.doc psxtmrwlock04.exe rhilatency.adoc psxtmcond09.exe psxtmrwlock05.doc rhilatency.exe psxtmcond10.doc psxtmrwlock05.exe rhmlatency.adoc psxtmcond10.exe psxtmrwlock06.doc rhmlatency.exe psxtmkey01.doc psxtmrwlock06.exe rhsemshuffle.adoc psxtmkey01.exe psxtmrwlock07.doc rhsemshuffle.exe psxtmkey02.doc psxtmrwlock07.exe rhtaskpreempt.adoc psxtmkey02.exe psxtmsem01.docrhtaskpreempt.exe psxtmmq01.doc psxtmsem01.exerhtaskswitch.adoc psxtmmq01.exe psxtmsem02.docrhtaskswitch.exe psxtmmutex01.docpsxtmsem02.exe This is missing a bunch of tests. I don't see any sp* or tm* tests. Are they in the tree itself? I always run using a find command and not from an install point. It is possible that only some tests install themselves but I don't know what the rationale for primarily POSIX tests doing that would be. This is the contents of libbsp/arm/stm32f7x/make/custom/stm32f7x-testsuite.tcfg This file specifies the files which are known not to link. Usually this is because the test takes too much code or data space for the target board. fsdosfsname01 jffs2_fserror jffs2_fslink jffs2_fspatheval jffs2_fspermission jffs2_fsrdwr jffs2_fsscandir01 jffs2_fssymlink jffs2_fstime devfs01 devfs02 devfs03 devfs04 termios02 termios03 termios04 stringto01 math mathf tar03 mathl complex sptimecounter01 spfatal26 spinternalerror01 fsnofs01 -- 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
4.11 Branch BSP C++ Build Issues
Hi lm32, moxie, and nios2 all have generic issues with C++ applications which indicate C++ is not really supported by gcc for these targets. Would it be OK to disable C++ for those targets? --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
or1k Build Issues
Hi I think the or1k tools are out of sync with RTEMS now. or1k-rtems4.11-gcc -B../../../../../generic_or1k/lib/ -specs bsp_specs -qrtems -O2 -O0 -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs-O2 -o hello.exe init.o /data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/or1k-rtems4.11/4.8.3/../../../../or1k-rtems4.11/lib/libc.a(lib_a-puts.o): In function `_puts_r': /data/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/or1k-rtems4.11-gcc-4.8.3-newlib-f296bb3569839b0217ec1a775165d239877e3548-x86_64-linux-gnu-1/build/or1k-rtems4.11/newlib/libc/stdio/../../../../../gcc-4.8.3/newlib/libc/stdio/puts.c:102: undefined reference to `_Mutex_recursive_Release' . Any suggestions? --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Selecting Tests to run/Missing tests
Thanks Joel, that pushed me in the right direction. All the missing tests where living in the build tree, not the install tree. I've now gotten to the point where none of the tests run, but that's another problem for another email. On 10/21/2015 01:57 PM, Joel Sherrill wrote: On 10/21/2015 12:30 PM, Isaac Gutekunst wrote: Hi All, I'm trying to run the RTEMS tests for our new BSP. I've managed to get close, but am missing something. In general, I'm trying to figure out how the build system decides what tests to build. Below is a bunch of information about what I've tried. It might be irrelevant, so if there is something obvious, just don't bother reading and let me know :) There is not as much magic as you might suspect. :) Comments scattered below. Details --- I run configure with --enable tests, and have disabled a bunch of tests that don't compile. See the list further down. The file does have effect. ../rtems/configure --enable-rtemsbsp="stm32f7x" --enable-maintainer-mode --enable-tests --target=arm-rtems4.11 --prefix=/other/rtems/lib-rtems --disable-networking --enable-rtems-debug (1) You can configure for no tests, samples only, or all tests. The set of tests built varies based on if things like networking, posix, and SMP are enabled. In the install path, I have a bunch of tests exes. They are specifically located in /other/rtems/lib-rtems/arm-rtems4.11/stm32f7x/lib/rtems-4.12/tests/ psxtmbarrier01.doc psxtmmutex01.exe psxtmsem03.doc psxtmbarrier01.exe psxtmmutex02.doc psxtmsem03.exe psxtmbarrier02.doc psxtmmutex02.exe psxtmsem04.doc psxtmbarrier02.exe psxtmmutex03.doc psxtmsem04.exe psxtmbarrier03.doc psxtmmutex03.exe psxtmsem05.doc psxtmbarrier03.exe psxtmmutex04.doc psxtmsem05.exe psxtmbarrier04.doc psxtmmutex04.exe psxtmsleep01.doc psxtmbarrier04.exe psxtmmutex05.doc psxtmsleep01.exe psxtmcond01.doc psxtmmutex05.exe psxtmsleep02.doc psxtmcond01.exe psxtmmutex06.doc psxtmsleep02.exe psxtmcond02.doc psxtmmutex06.exe psxtmthread01.doc psxtmcond02.exe psxtmmutex07.doc psxtmthread01.exe psxtmcond03.doc psxtmmutex07.exe psxtmthread02.doc psxtmcond03.exe psxtmnanosleep01.doc psxtmthread02.exe psxtmcond04.doc psxtmnanosleep01.exe psxtmthread03.doc psxtmcond04.exe psxtmnanosleep02.doc psxtmthread03.exe psxtmcond05.doc psxtmnanosleep02.exe psxtmthread04.doc psxtmcond05.exe psxtmrwlock01.doc psxtmthread04.exe psxtmcond06.doc psxtmrwlock01.exe psxtmthread05.doc psxtmcond06.exe psxtmrwlock02.doc psxtmthread05.exe psxtmcond07.doc psxtmrwlock02.exe psxtmthread06.doc psxtmcond07.exe psxtmrwlock03.doc psxtmthread06.exe psxtmcond08.doc psxtmrwlock03.exe rhdeadlockbrk.adoc psxtmcond08.exe psxtmrwlock04.doc rhdeadlockbrk.exe psxtmcond09.doc psxtmrwlock04.exe rhilatency.adoc psxtmcond09.exe psxtmrwlock05.doc rhilatency.exe psxtmcond10.doc psxtmrwlock05.exe rhmlatency.adoc psxtmcond10.exe psxtmrwlock06.doc rhmlatency.exe psxtmkey01.docpsxtmrwlock06.exe rhsemshuffle.adoc psxtmkey01.exepsxtmrwlock07.doc rhsemshuffle.exe psxtmkey02.docpsxtmrwlock07.exe rhtaskpreempt.adoc psxtmkey02.exepsxtmsem01.doc rhtaskpreempt.exe psxtmmq01.docpsxtmsem01.exe rhtaskswitch.adoc psxtmmq01.exepsxtmsem02.doc rhtaskswitch.exe psxtmmutex01.docpsxtmsem02.exe This is missing a bunch of tests. I don't see any sp* or tm* tests. Are they in the tree itself? I always run using a find command and not from an install point. It is possible that only some tests install themselves but I don't know what the rationale for primarily POSIX tests doing that would be. This is the contents of libbsp/arm/stm32f7x/make/custom/stm32f7x-testsuite.tcfg This file specifies the files which are known not to link. Usually this is because the test takes too much code or data space for the target board. All of these tests seem to be failing to do something related to devfs and multiple definitions of some symbols. I'll post a followup later once I get at least some tests to run. fsdosfsname01 jffs2_fserror jffs2_fslink jffs2_fspatheval jffs2_fspermission jffs2_fsrdwr jffs2_fsscandir01 jffs2_fssymlink jffs2_fstime devfs01 devfs02 devfs03 devfs04 termios02 termios03 termios04 stringto01 math mathf tar03 mathl complex sptimecounter01 spfatal26 spinternalerror01 fsnofs01 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Per-BSP confdefs (or resource allocation)
Hi Devel, I looked for a while, but couldn't find a way to specify what resources (semaphores, tasks, etc) a BSP requires for an empty project (empty Init function). I took a look at this page: https://docs.rtems.org/doc-current/share/rtems/html/bsp_howto/Initialization-Code-The-RTEMS-Configuration-Table.html but couldn't glean the correct method. What is the preferred way to do so? Our BSP uses a number of resources for hardware drivers, including UART, CAN, SPI, I2C and Ethernet. -- Isaac Gutekunst Embedded Systems Software Engineer isaac.guteku...@vecna.com www.vecna.com ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Selecting Tests to run/Missing tests
Please file a ticket on the off set of tests installing. It definitely is clearly something that needs a decision so we can make them consistent. I am guessing that we not install any except maybe the samples. On 10/21/2015 2:48 PM, Isaac Gutekunst wrote: Thanks Joel, that pushed me in the right direction. All the missing tests where living in the build tree, not the install tree. I've now gotten to the point where none of the tests run, but that's another problem for another email. On 10/21/2015 01:57 PM, Joel Sherrill wrote: On 10/21/2015 12:30 PM, Isaac Gutekunst wrote: Hi All, I'm trying to run the RTEMS tests for our new BSP. I've managed to get close, but am missing something. In general, I'm trying to figure out how the build system decides what tests to build. Below is a bunch of information about what I've tried. It might be irrelevant, so if there is something obvious, just don't bother reading and let me know :) There is not as much magic as you might suspect. :) Comments scattered below. Details --- I run configure with --enable tests, and have disabled a bunch of tests that don't compile. See the list further down. The file does have effect. ../rtems/configure --enable-rtemsbsp="stm32f7x" --enable-maintainer-mode --enable-tests --target=arm-rtems4.11 --prefix=/other/rtems/lib-rtems --disable-networking --enable-rtems-debug (1) You can configure for no tests, samples only, or all tests. The set of tests built varies based on if things like networking, posix, and SMP are enabled. In the install path, I have a bunch of tests exes. They are specifically located in /other/rtems/lib-rtems/arm-rtems4.11/stm32f7x/lib/rtems-4.12/tests/ psxtmbarrier01.doc psxtmmutex01.exe psxtmsem03.doc psxtmbarrier01.exe psxtmmutex02.doc psxtmsem03.exe psxtmbarrier02.doc psxtmmutex02.exe psxtmsem04.doc psxtmbarrier02.exe psxtmmutex03.doc psxtmsem04.exe psxtmbarrier03.doc psxtmmutex03.exe psxtmsem05.doc psxtmbarrier03.exe psxtmmutex04.doc psxtmsem05.exe psxtmbarrier04.doc psxtmmutex04.exe psxtmsleep01.doc psxtmbarrier04.exe psxtmmutex05.doc psxtmsleep01.exe psxtmcond01.doc psxtmmutex05.exe psxtmsleep02.doc psxtmcond01.exe psxtmmutex06.doc psxtmsleep02.exe psxtmcond02.doc psxtmmutex06.exe psxtmthread01.doc psxtmcond02.exe psxtmmutex07.doc psxtmthread01.exe psxtmcond03.doc psxtmmutex07.exe psxtmthread02.doc psxtmcond03.exe psxtmnanosleep01.doc psxtmthread02.exe psxtmcond04.doc psxtmnanosleep01.exe psxtmthread03.doc psxtmcond04.exe psxtmnanosleep02.doc psxtmthread03.exe psxtmcond05.doc psxtmnanosleep02.exe psxtmthread04.doc psxtmcond05.exe psxtmrwlock01.doc psxtmthread04.exe psxtmcond06.doc psxtmrwlock01.exe psxtmthread05.doc psxtmcond06.exe psxtmrwlock02.doc psxtmthread05.exe psxtmcond07.doc psxtmrwlock02.exe psxtmthread06.doc psxtmcond07.exe psxtmrwlock03.doc psxtmthread06.exe psxtmcond08.doc psxtmrwlock03.exe rhdeadlockbrk.adoc psxtmcond08.exe psxtmrwlock04.doc rhdeadlockbrk.exe psxtmcond09.doc psxtmrwlock04.exe rhilatency.adoc psxtmcond09.exe psxtmrwlock05.doc rhilatency.exe psxtmcond10.doc psxtmrwlock05.exe rhmlatency.adoc psxtmcond10.exe psxtmrwlock06.doc rhmlatency.exe psxtmkey01.docpsxtmrwlock06.exe rhsemshuffle.adoc psxtmkey01.exepsxtmrwlock07.doc rhsemshuffle.exe psxtmkey02.docpsxtmrwlock07.exe rhtaskpreempt.adoc psxtmkey02.exepsxtmsem01.doc rhtaskpreempt.exe psxtmmq01.docpsxtmsem01.exe rhtaskswitch.adoc psxtmmq01.exepsxtmsem02.doc rhtaskswitch.exe psxtmmutex01.docpsxtmsem02.exe This is missing a bunch of tests. I don't see any sp* or tm* tests. Are they in the tree itself? I always run using a find command and not from an install point. It is possible that only some tests install themselves but I don't know what the rationale for primarily POSIX tests doing that would be. This is the contents of libbsp/arm/stm32f7x/make/custom/stm32f7x-testsuite.tcfg This file specifies the files which are known not to link. Usually this is because the test takes too much code or data space for the target board. All of these tests seem to be failing to do something related to devfs and multiple definitions of some symbols. I'll post a followup later once I get at least some tests to run. fsdosfsname01 jffs2_fserror jffs2_fslink jffs2_fspatheval jffs2_fspermission jffs2_fsrdwr jffs2_fsscandir01 jffs2_fssymlink jffs2_fstime devfs01 devfs02 devfs03 devfs04 termios02 termios03 termios04 stringto01 math mathf tar03 mathl complex sptimecounter01 spfatal26 spinternalerror01 fsnofs01 -- 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
Re: Per-BSP confdefs (or resource allocation)
On 10/21/2015 2:53 PM, Isaac Gutekunst wrote: Hi Devel, I looked for a while, but couldn't find a way to specify what resources (semaphores, tasks, etc) a BSP requires for an empty project (empty Init function). I took a look at this page: https://docs.rtems.org/doc-current/share/rtems/html/bsp_howto/Initialization-Code-The-RTEMS-Configuration-Table.html but couldn't glean the correct method. What is the preferred way to do so? Our BSP uses a number of resources for hardware drivers, including UART, CAN, SPI, I2C and Ethernet. Starting out, the easiest thing to do is turn on unified workspace and unlimited resources. #define CONFIGURE_UNLIMITED_OBJECTS #define CONFIGURE_UNIFIED_WORK_AREAS This sets things up as a single pool of memory for malloc and RTEMS and does not place a limit on how many objects you can create. You keep going until you run out of work space. After that, you will need to figure out how many objects each driver really uses and consider that the base set which an application configuration must account for. There isn't really any system for this built in. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Per-BSP confdefs (or resource allocation)
Let me clarify. I don't think I explained my predicament very well. None of the tests will run because the base application for our BSP requires resources that aren't available. On the application side we're fine. We have a couple of applications running correctly, by specifying configuration in the main C file using the standard method (#defining options and including condefs.h). Isaac On 10/21/2015 04:00 PM, Joel Sherrill wrote: On 10/21/2015 2:53 PM, Isaac Gutekunst wrote: Hi Devel, I looked for a while, but couldn't find a way to specify what resources (semaphores, tasks, etc) a BSP requires for an empty project (empty Init function). I took a look at this page: https://docs.rtems.org/doc-current/share/rtems/html/bsp_howto/Initialization-Code-The-RTEMS-Configuration-Table.html but couldn't glean the correct method. What is the preferred way to do so? Our BSP uses a number of resources for hardware drivers, including UART, CAN, SPI, I2C and Ethernet. Starting out, the easiest thing to do is turn on unified workspace and unlimited resources. #define CONFIGURE_UNLIMITED_OBJECTS #define CONFIGURE_UNIFIED_WORK_AREAS This sets things up as a single pool of memory for malloc and RTEMS and does not place a limit on how many objects you can create. You keep going until you run out of work space. After that, you will need to figure out how many objects each driver really uses and consider that the base set which an application configuration must account for. There isn't really any system for this built in. Is there any hackish way to setup the tests to allocate more resources? --joel Isaac ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: 4.11 Branch BSP C++ Build Issues
On Wed, Oct 21, 2015 at 3:41 PM, Joel Sherrill wrote: > Hi > > lm32, moxie, and nios2 all have generic issues with C++ applications > which indicate C++ is not really supported by gcc for these targets. Could you please provide more information/details about the error and messages? What does "C++ is not really supported" mean? C++ is front-end plus the STL, and since the front-end is target agnostic, I'm assuming there is some issue with the STL. > > Would it be OK to disable C++ for those targets? > > --joel > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel -- Daniel F. Gutson Chief Engineering Officer, SPD San Lorenzo 47, 3rd Floor, Office 5 Córdoba, Argentina Phone: +54 351 4217888 / +54 351 4218211 Skype:dgutson LinkedIn: http://ar.linkedin.com/in/danielgutson ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: 4.11 Branch BSP C++ Build Issues
On 10/21/2015 3:52 PM, Daniel Gutson wrote:
On Wed, Oct 21, 2015 at 3:41 PM, Joel Sherrill
wrote:
Hi
lm32, moxie, and nios2 all have generic issues with C++ applications
which indicate C++ is not really supported by gcc for these targets.
Could you please provide more information/details about the error and messages?
What does "C++ is not really supported" mean? C++ is front-end plus
the STL, and since
the front-end is target agnostic, I'm assuming there is some issue with the STL.
Ok.. if you see how to fix these, I am happy to push more testing. :)
==
lm32 all bsps fail similar to this
==
lm32-rtems4.11-g++ -B../../../../../lm32_evr_gdbsim/lib/ -specs bsp_specs
-qrtems -O0 -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration
-Wstrict-prototypes -Wnested-externs -o cxx_iostream.exe init.o
`.gcc_except_table._ZN9__gnu_cxx7__mutexD2Ev' referenced in section
`.rodata.cst4' of
/data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/lm32-rtems4.11/4.9.3/libstdc++.a(eh_terminate.o):
defined in discarded section
`.gcc_except_table._ZN9__gnu_cxx7__mutexD2Ev[_ZN9__gnu_cxx7__mutexD5Ev]' of
/data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/lm32-rtems4.11/4.9.3/libstdc++.a(eh_terminate.o)
`.gcc_except_table._ZN9__gnu_cxx7__mutexD2Ev' referenced in section
`.rodata.cst4' of
/data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/lm32-rtems4.11/4.9.3/libstdc++.a(new_handler.o):
defined in discarded section
`.gcc_except_table._ZN9__gnu_cxx7__mutexD2Ev[_ZN9__gnu_cxx7__mutexD5Ev]' of
/data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/lm32-rtems4.11/4.9.3/libstdc++.a(new_handler.o)
collect2: error: ld returned 1 exit status
Both linkcmds appear to have the right magic:
.gcc_except_table : {
*(.gcc_except_table)
*(.gcc_except_table.*)
} > sdram
==
Moxie
==
moxie-rtems4.11-g++ -B../../../../../moxiesim/lib/ -specs bsp_specs -qrtems -Os
-g -ffunction-sections -fdata-sections -Wall -Wmissing-prototypes
-Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs
-Wl,--gc-sections -o cxx_iostream.exe init.o
init.o: In function `__static_initialization_and_destruction_0':
/data/home/joel/rtems-4.11-work/tools/lib/gcc/moxie-rtems4.11/4.9.3/include/c++/iostream:74:
undefined reference to `__dso_handle'
/data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/moxie-rtems4.11/4.9.3/libstdc++.a(locale_init.o):
In function `get_locale_mutex':
/data/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/moxie-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-linux-gnu-1/build/moxie-rtems4.11/libstdc++-v3/src/c++98/../../../../../gcc-4.9.3/libstdc++-v3/src/c++98/locale_init.cc:36:
undefined reference to `__dso_handle'
/data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/moxie-rtems4.11/4.9.3/libstdc++.a(eh_alloc.o):
In function `__static_initialization_and_destruction_0':
/data/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/moxie-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-linux-gnu-1/build/moxie-rtems4.11/libstdc++-v3/libsupc++/../../../../gcc-4.9.3/libstdc++-v3/libsupc++/eh_alloc.cc:96:
undefined reference to `__dso_handle'
/data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/moxie-rtems4.11/4.9.3/libstdc++.a(eh_globals.o):
In function `__static_initialization_and_destruction_0':
==
NIOS2
==
Missing needed atomic operations.
nios2-rtems4.11-g++ -B../../../../../nios2_iss/lib/ -specs bsp_specs -qrtems
-mno-hw-mul -mno-hw-div -O0 -g -Wall -Wmissing-prototypes
-Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs
-mno-hw-mul -mno-hw-div -o cxx_iostream.exe init.o
/data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/nios2-rtems4.11/4.9.3/libstdc++.a(ios_init.o):
In function `__exchange_and_add_dispatch':
/data/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/nios2-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-linux-gnu-1/build/nios2-
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
or1k C++ was Re: 4.11 Branch BSP C++ Build Issues
Sorry.. forgot the or1k: or1k has its own special gcc and (maybe) newlib version. They are likely out of sync enough to miss the new locking support. or1k-rtems4.11-gcc -B../../../../../generic_or1k/lib/ -specs bsp_specs -qrtems -DHAVE_CONFIG_H -I. -I../../../../../../../rtems/c/src/../../testsuites/samples/hello -I.. -O2 -O0 -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT init.o -MD -MP -MF .deps/init.Tpo -c -o init.o ../../../../../../../rtems/c/src/../../testsuites/samples/hello/init.c mv -f .deps/init.Tpo .deps/init.Po or1k-rtems4.11-gcc -B../../../../../generic_or1k/lib/ -specs bsp_specs -qrtems -O2 -O0 -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs-O2 -o hello.exe init.o /data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/or1k-rtems4.11/4.8.3/../../../../or1k-rtems4.11/lib/libc.a(lib_a-puts.o): In function `_puts_r': /data/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/or1k-rtems4.11-gcc-4.8.3-newlib-f296bb3569839b0217ec1a775165d239877e3548-x86_64-linux-gnu-1/build/or1k-rtems4.11/newlib/libc/stdio/../../../../../gcc-4.8.3/newlib/libc/stdio/puts.c:102: undefined reference to `_Mutex_recursive_Release' /data/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/or1k-rtems4.11-gcc-4.8.3-newlib-f296bb3569839b0217ec1a775165d239877e3548-x86_64-linux-gnu-1/build/or1k-rtems4.11/newlib/libc/stdio/../../../../../gcc-4.8.3/newlib/libc/stdio/puts.c:99: undefined reference to `_Mutex_recursive_Acquire' / On 10/21/2015 3:52 PM, Daniel Gutson wrote: On Wed, Oct 21, 2015 at 3:41 PM, Joel Sherrill wrote: Hi lm32, moxie, and nios2 all have generic issues with C++ applications which indicate C++ is not really supported by gcc for these targets. Could you please provide more information/details about the error and messages? What does "C++ is not really supported" mean? C++ is front-end plus the STL, and since the front-end is target agnostic, I'm assuming there is some issue with the STL. Would it be OK to disable C++ for those targets? --joel ___ 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: 4.11 Branch BSP C++ Build Issues
On Wed, Oct 21, 2015 at 6:02 PM, Joel Sherrill
wrote:
>
>
> On 10/21/2015 3:52 PM, Daniel Gutson wrote:
>>
>> On Wed, Oct 21, 2015 at 3:41 PM, Joel Sherrill
>> wrote:
>>>
>>> Hi
>>>
>>> lm32, moxie, and nios2 all have generic issues with C++ applications
>>> which indicate C++ is not really supported by gcc for these targets.
>>
>>
>> Could you please provide more information/details about the error and
>> messages?
>> What does "C++ is not really supported" mean? C++ is front-end plus
>> the STL, and since
>> the front-end is target agnostic, I'm assuming there is some issue with
>> the STL.
>
>
> Ok.. if you see how to fix these, I am happy to push more testing. :)
>
> ==
> lm32 all bsps fail similar to this
> ==
> lm32-rtems4.11-g++ -B../../../../../lm32_evr_gdbsim/lib/ -specs bsp_specs
> -qrtems -O0 -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration
> -Wstrict-prototypes -Wnested-externs -o cxx_iostream.exe init.o
> `.gcc_except_table._ZN9__gnu_cxx7__mutexD2Ev' referenced in section
> `.rodata.cst4' of
> /data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/lm32-rtems4.11/4.9.3/libstdc++.a(eh_terminate.o):
> defined in discarded section
> `.gcc_except_table._ZN9__gnu_cxx7__mutexD2Ev[_ZN9__gnu_cxx7__mutexD5Ev]' of
> /data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/lm32-rtems4.11/4.9.3/libstdc++.a(eh_terminate.o)
> `.gcc_except_table._ZN9__gnu_cxx7__mutexD2Ev' referenced in section
> `.rodata.cst4' of
> /data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/lm32-rtems4.11/4.9.3/libstdc++.a(new_handler.o):
> defined in discarded section
> `.gcc_except_table._ZN9__gnu_cxx7__mutexD2Ev[_ZN9__gnu_cxx7__mutexD5Ev]' of
> /data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/lm32-rtems4.11/4.9.3/libstdc++.a(new_handler.o)
> collect2: error: ld returned 1 exit status
>
> Both linkcmds appear to have the right magic:
>
> .gcc_except_table : {
> *(.gcc_except_table)
> *(.gcc_except_table.*)
> } > sdram
> ==
> Moxie
> ==
>
> moxie-rtems4.11-g++ -B../../../../../moxiesim/lib/ -specs bsp_specs -qrtems
> -Os -g -ffunction-sections -fdata-sections -Wall -Wmissing-prototypes
> -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs
> -Wl,--gc-sections -o cxx_iostream.exe init.o
> init.o: In function `__static_initialization_and_destruction_0':
> /data/home/joel/rtems-4.11-work/tools/lib/gcc/moxie-rtems4.11/4.9.3/include/c++/iostream:74:
> undefined reference to `__dso_handle'
> /data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/moxie-rtems4.11/4.9.3/libstdc++.a(locale_init.o):
> In function `get_locale_mutex':
> /data/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/moxie-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-linux-gnu-1/build/moxie-rtems4.11/libstdc++-v3/src/c++98/../../../../../gcc-4.9.3/libstdc++-v3/src/c++98/locale_init.cc:36:
> undefined reference to `__dso_handle'
> /data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/moxie-rtems4.11/4.9.3/libstdc++.a(eh_alloc.o):
> In function `__static_initialization_and_destruction_0':
> /data/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/moxie-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-linux-gnu-1/build/moxie-rtems4.11/libstdc++-v3/libsupc++/../../../../gcc-4.9.3/libstdc++-v3/libsupc++/eh_alloc.cc:96:
> undefined reference to `__dso_handle'
> /data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/moxie-rtems4.11/4.9.3/libstdc++.a(eh_globals.o):
> In function `__static_initialization_and_destruction_0':
>
Those two (lm32 and Moxie) have problems with exception handling and
the linker scripts.
NIOS2 seems that it wants to use atomics but are not implemented,
instead of using the pthreads layer. (Sebastian?)
We can fix all of them but unfortunately have no time :(
What about at least disabling EH? I suggest build a multilib without
exceptions handling support (-fno-exceptions which will apply to the
STL).
> ==
> NIOS2
> ==
>
> Missing needed atomic operations.
>
> nios2-rtems4.11-g++ -B../../../../../nios2_iss/lib/ -specs bsp_specs -qrtems
> -mno-hw-mul -mno-hw-div -O0 -g -Wall -Wmissing-prototypes
> -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs
> -mno-hw-mul -mno-hw-div -o cxx_iostream.exe init.o
> /data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/nios2-rtems4.11/4.9.3/libstdc++.a(ios_init.o):
> In function `__exchange_and_add_dispatch':
> /data/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/nios2-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-linux-gnu-1/build/nios2-
>
>
>
--
Daniel F. Gutson
Chief Engineering Officer, SPD
San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina
Phone: +54 351 4217888 / +54 351 4218211
Skype:d
Re: or1k Build Issues
Hi, That's mainly because the RSB is fetching an upstream gcc-4.8.3 version and it applies my old patch there. I suggested to temporarily use the current or1k up-to-date repos from github (like Epiphany tools), which incorporate our RTEMS stuff, and are synced with gcc-5x version. FWIW Christian told me two weeks ago that they managed to contact the last code contributor to finish the FSF paper work, and hopefully the or1k-gcc will be upstream soon. On Wed, Oct 21, 2015 at 7:42 PM, Joel Sherrill wrote: > Hi > > I think the or1k tools are out of sync with RTEMS now. > > or1k-rtems4.11-gcc -B../../../../../generic_or1k/lib/ -specs bsp_specs > -qrtems -O2 -O0 -g -Wall -Wmissing-prototypes > -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs-O2 > -o hello.exe init.o > /data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/or1k-rtems4.11/4.8.3/../../../../or1k-rtems4.11/lib/libc.a(lib_a-puts.o): > In function `_puts_r': > /data/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/or1k-rtems4.11-gcc-4.8.3-newlib-f296bb3569839b0217ec1a775165d239877e3548-x86_64-linux-gnu-1/build/or1k-rtems4.11/newlib/libc/stdio/../../../../../gcc-4.8.3/newlib/libc/stdio/puts.c:102: > undefined reference to `_Mutex_recursive_Release' > . > > Any suggestions? > > --joel -- Hesham ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] bsp/qoriq: Use U-Boot provided FDT
On 22/10/2015 1:09 am, Gedare Bloom wrote: > On Wed, Oct 21, 2015 at 2:07 AM, Sebastian Huber > wrote: >> On 21/10/15 06:15, Chris Johns wrote: >>> >>> On 20/10/2015 9:10 pm, Sebastian Huber wrote: On 20/10/15 00:46, Chris Johns wrote: > [...] >>> >>> It is easy to add things like the FDT support to the shared BSP tree and >>> if you look over that code we have all sorts of specific localised >>> things that effect various subsets of BSPs as well as important generic >>> things almost all BSPs use. The BSP shared directory is becoming more >>> complex. Changes in that directory tree now effect a wider and wider >>> range of BSPs and often when things go in it is specific and not a >>> general API with some level of formal agreement. Add to this testing on >>> all effected BSPs is often difficult. As I said these things are easy to >>> add but difficult to remove or change because users end up depending on >>> them as they are. >>> >>> This issue is coming to a head with the build system change. >>> >>> If we change or do not provide something in the build system change that >>> is BSP specific and not an API is it our fault for forcing application >>> changes or is it the BSP developer's for not providing a formal >>> interface? What is ok to vary for a BSP and what is not ok? >>> >>> As I said easy to add and hard to maintain through changes. We are doing >>> our best not to change things but it is not easy. >> >> >> Instead of less code in the shared area we need more. There is still a lot >> of copy and paste in the BSPs. During the interrupt support code cleanup >> several years ago I removed hundreds of lines of duplicated code. >> > I believe Chris' point is that we need more guidance in what should go > there, and we should aim for more uniformity in the BSP layer to make > the guidance simple and maintainable. The problem we face is the lack > of good abstraction within and across BSPs. This is a separate issue > from the FDT patch itself. Yes this is correct. Gedare, thanks for nicely expressing this. > >>> > I do not remember any discussion about how BSPs and FDT will be > supported. U-Boot supports FDT for several years now. So, all U-Boot based BSPs may use this option. >>> FDT is not constrained to u-boot. There are other possible uses in RTEMS. >> >> >> Yes, and for all of the uses a libfdt is probably required. >> >> [...] > > Can you please describe this use of FDT in RTEMS and how this can used > by more than the immediate use you have for your BSP? The use of FDT for BSPs is to get U-Boot provided parameters. >>> Where is this interaction documented and how would a user find this >>> information? >> >> >> It is documented in the source code and in the README of the BSP. >> >> The BSP area of RTEMS is virtually undocumented and even worse the existing >> documentation is partly outdated and misleading. >> > We should try to plan how to correct this problem especially for code > in the shared part. Doxygen on the source is a good start. README > files can be hard to find and easy to ignore. > I am also foreshadowing changes in the build system will result in changes in BSPS and I suspect changes in some user applications. We need to be mindful of this and work together to minimise the impact for users while allowing RTEMS to develop better and more robust BSP interfaces. There will need to be give on both sides. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: 4.11 Branch BSP C++ Build Issues
On 21/10/15 23:02, Joel Sherrill wrote: == NIOS2 == Missing needed atomic operations. nios2-rtems4.11-g++ -B../../../../../nios2_iss/lib/ -specs bsp_specs -qrtems -mno-hw-mul -mno-hw-div -O0 -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs-mno-hw-mul -mno-hw-div -o cxx_iostream.exe init.o /data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/nios2-rtems4.11/4.9.3/libstdc++.a(ios_init.o): In function `__exchange_and_add_dispatch': /data/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/nios2-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-linux-gnu-1/build/nios2- This is not a general C++ issue. It is a libstdc++ issue. I would not disable C++ in this case. Looks again like a problem with the missing libatomic support for RTEMS. -- 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
Re: Per-BSP confdefs (or resource allocation)
On 21/10/15 21:53, Isaac Gutekunst wrote: Hi Devel, I looked for a while, but couldn't find a way to specify what resources (semaphores, tasks, etc) a BSP requires for an empty project (empty Init function). There is no useful support for this and this is a constant source of problems. One way out of this situation would be to use self-contained objects for the drivers. I took a look at this page: https://docs.rtems.org/doc-current/share/rtems/html/bsp_howto/Initialization-Code-The-RTEMS-Configuration-Table.html but couldn't glean the correct method. What is the preferred way to do so? Our BSP uses a number of resources for hardware drivers, including UART, CAN, SPI, I2C and Ethernet. In case an empty project includes all these drivers, then something is wrong with this BSP. -- 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
Re: Per-BSP confdefs (or resource allocation)
On 22/10/2015 4:33 pm, Sebastian Huber wrote: > > > On 21/10/15 21:53, Isaac Gutekunst wrote: >> Hi Devel, >> >> I looked for a while, but couldn't find a way to specify what >> resources (semaphores, tasks, etc) a BSP requires for an empty project >> (empty Init function). > > There is no useful support for this and this is a constant source of > problems. > > One way out of this situation would be to use self-contained objects for > the drivers. > What does this mean? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Random lwIP Crashes in _POSIX_Mutex_Lock_support()
On 21/10/15 15:48, Jay Doyle wrote:
On 10/21/2015 09:35 AM, Sebastian Huber wrote:
On 21/10/15 15:08, Isaac Gutekunst wrote:
On 10/21/2015 09:00 AM, Sebastian Huber wrote:
On 21/10/15 14:56, Isaac Gutekunst wrote:
On 10/21/2015 08:24 AM, Sebastian Huber wrote:
On 21/10/15 14:13, Isaac Gutekunst wrote:
Thanks for the reply.
On 10/21/2015 01:50 AM, Sebastian Huber wrote:
On 20/10/15 16:02, Isaac Gutekunst wrote:
[...]
As far as I can tell this would only occur if the caller of
pthread_mutex_lock was in a
"bad"
state. I don't believe it is in an interrupt context, and
don't know what other bad states
could exist.
We have
#define _CORE_mutex_Check_dispatch_for_seize(_wait) \
(!_Thread_Dispatch_is_enabled() \
&& (_wait) \
&& (_System_state_Get() >= SYSTEM_STATE_UP))
What is the thread dispatch disable level and the system state
at this point?
In case the thread dispatch disable level is not zero, then
something is probably broken
in the
operating system code which is difficult to find. Could be a
general memory corruption
problem
too. Which RTEMS version do you use?
The thread dispatch disable level is usually -1 or -2.
(0xFFFE or 0xFFD).
A negative value is very bad, but easy to detect via manual
instrumentation (only an hand full
of spots touch this variable) or hardware
breakpoints/watchpoints. Looks the rest of
_Per_CPU_Information all right?
It looks like it's only the thread_dispatch_disable_level that's
broken.
We'll go and grep for all places for all the places it's touched,
and look for something.
The problem with watchpoints is they fire exceptionally often, and
putting in a conditional
watchpoint slows the code to a crawl, but that may be worth it.
Here are some printouts of the relevant structs right after a crash:
$4 = {
cpu_per_cpu = {},
isr_nest_level = 0,
thread_dispatch_disable_level = 4294967295,
executing = 0xc01585c8,
heir = 0xc0154038,
dispatch_necessary = true,
time_of_last_context_switch = {
sec = 2992,
frac = 10737447432380511034
},
Stats = {}
}
No, this doesn't look good. According to the stack trace you are in
thread context. However, we
have executing != heir and dispatch_necessary == true. This is a
broken state itself. I guess,
something is wrong with the interrupt level so that a context
switch is blocked. On ARMv7-M
this is done via the system call exception.
This is a bit beyond my RTEMS knowledge. What would you advise
looking into?
I would try to instrument the code to figure out where the thread
dispatch disable level goes negative.
We just did. I added a check in _ARMV7M_Interrupt_service_leave to
see if the _Thread_Dispatch_disable_level is positive before the
decrementing it and this eventually fails.
I'm not sure if this tells us much because I think the call itself
correct. In this particular case it is processing an I2C interrupt.
I will try to see if we can capture information about the sequence of
changes to the _Thread_Dispatch_disable_level just before the point in
which we know something is clearly wrong (i.e., decreasing it below
zero.)
Since the isr_nest_level is 0, I don't think its a problem with the
spots that use _ARMV7M_Interrupt_service_leave(). Did you check the
interrupt priorities? See also
https://lists.rtems.org/pipermail/users/2015-June/029155.html
--
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
Re: Per-BSP confdefs (or resource allocation)
On 22/10/15 07:37, Chris Johns wrote: On 22/10/2015 4:33 pm, Sebastian Huber wrote: > > >On 21/10/15 21:53, Isaac Gutekunst wrote: >>Hi Devel, >> >>I looked for a while, but couldn't find a way to specify what >>resources (semaphores, tasks, etc) a BSP requires for an empty project >>(empty Init function). > >There is no useful support for this and this is a constant source of >problems. > >One way out of this situation would be to use self-contained objects for >the drivers. > What does this mean? If you use C11, C++11, libgomp or libbsd synchronization objects, then the storage space for them is provided by the user and not the workspace. -- 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
Re: [PATCH] RFS: Fix resource leak
On 21/10/15 16:23, Joel Sherrill wrote: Did you also commit this to 4.11 branch? I didn't commit anything so far. Does it apply to the 4.10 branch? Yes, see corresponding ticket. -- 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
Re: Per-BSP confdefs (or resource allocation)
On 22/10/2015 4:41 pm, Sebastian Huber wrote: > > If you use C11, C++11, libgomp or libbsd synchronization objects, then > the storage space for them is provided by the user and not the workspace. > Typically drivers in BSPs have used documented APIs. Is this approach and support documented and available for users? Is it available in 4.11? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] RFS: Fix resource leak
On 22/10/2015 4:45 pm, Sebastian Huber wrote: > > > On 21/10/15 16:23, Joel Sherrill wrote: >> Did you also commit this to 4.11 branch? > > I didn't commit anything so far. > >> >> Does it apply to the 4.10 branch? > > Yes, see corresponding ticket. > Ok for 4.10 and 4.11. Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Per-BSP confdefs (or resource allocation)
On 22/10/15 07:45, Chris Johns wrote: On 22/10/2015 4:41 pm, Sebastian Huber wrote: > >If you use C11, C++11, libgomp or libbsd synchronization objects, then >the storage space for them is provided by the user and not the workspace. > Typically drivers in BSPs have used documented APIs. Is this approach and support documented and available for users? Is it available in 4.11? With "would be" I meant that it is technically possible. There is some work necessary to actually use it. My approach would be to move the FreeBSD synchronization objects from libbsd to RTEMS, since they offer the best designed APIs. -- 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
