On 20/9/17 3:48 pm, Sebastian Huber wrote:
> There are some checks that help to debug broken applications. For example the
> heap protection, the deadlock detection, the file descriptor reference
> counting
> and simple parameter validation.
Yes I agree some of these are useful and I am not agai
On 20/09/17 09:07, xuelin.t...@qkmtech.com wrote:
I am not sure this is a bug or I just use it in a wrong way. If anyone
has encountered the same situation like me, I will send a ticket.
Your use case looks all right, if this doesn't work, then its a bug from
my point of view.
--
Sebastian
For semaphore object pointer and object validation see
POSIX_SEMAPHORE_VALIDATE_OBJECT().
Destruction or close of a busy semaphore returns an error status. The
object is not flushed.
Update #3116.
---
cpukit/posix/Makefile.am | 3 +-
cpukit/posix/include/rtems/posix/se
Signed-off-by: Sebastian Huber
---
newlib/libc/sys/rtems/include/semaphore.h | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/newlib/libc/sys/rtems/include/semaphore.h
b/newlib/libc/sys/rtems/include/semaphore.h
index e3c61da04..44ecc58f4 100644
--- a/newlib/libc/sys/r
On 19/09/17 21:18, Joel Sherrill wrote:
Hi
I am starting to investigate the failures but 41 BSPs fail to
build with --enable-rtems-debug and --enable-tests=all.
Some fail because tests are too large to fit with debug enabled.
These fail with an error related to bsp_interrupt_assert:
log/powe
Hi Chris,
Lurking RPi Linux user here..
Are you talking about having the RPI control the reset line to one or more
targets?
Would a GPIO pin be sufficient for that, or would we need another output?
Also, what would the serial port on the Pi be used for? Would it connect to
a test target serial po
Thanks for fixing so many. Now it is down to these failures.
These are BSPs where enabling debug resulted in more tests not
fitting. Do we add all of these test build/link failures to the tcfg?
log/arm-lm3s3749.log
log/arm-lpc1768_mbed_ahb_ram_eth.log
log/arm-lpc2362.log
log/arm-lpc23xx_tli800.lo
On 21/09/2017 03:21, Alan Cudmore wrote:
> Lurking RPi Linux user here..
Nice and thanks for responding.
> Are you talking about having the RPI control the reset line to one or more
> targets?
Yes. I was thinking about insecure telnet access to pulse a GPIO pin.
> Would a GPIO pin be sufficien