[..]
+
+/*
+ * If the application wants to provide an IDLE threads stack allocator, it
+ * must also provide a custom allocator/deallocator for user thread stacks.
+ */
+#elif (!defined(CONFIGURE_TASK_STACK_ALLOCATOR) \
+ && !defined(CONFIGURE_TASK_STACK_DEALLOCATOR)) \
+ && defined(CONFIGURE_T
For relative times, the clock identifier is not used to select the clock
and instead always the CLOCK_MONOTONIC is used. A side-effect is that
sleep() and nanosleep() use the wrong clock (CLOCK_MONOTONIC instead of
CLOCK_REALTIME).
I don't understand how the monotonic clock is not being used. I kn
hi Kinsey,
This change looks OK to me. Nice work.
Thanks
Chris
On 6/10/21 7:55 am, Kinsey Moore wrote:
> Conditionally compiled tests (consisting only of debugger01) were not
> compiling as expected when libdebugger was present. This appears to have
> occurred during the transition from header d
On 10/5/2021 02:48, Chris Johns wrote:
On 5/10/21 10:27 am, Kinsey Moore wrote:
Currently debugger01 is the only user of the test-if-library in libbsd and it
doesn't seem to work as expected. The configure step that detects libdebugger
occurs and succeeds as it should for the zynq a9 qemu BSP,
Conditionally compiled tests (consisting only of debugger01) were not
compiling as expected when libdebugger was present. This appears to have
occurred during the transition from header detection or due to an
intervening change in the waf internal libraries. The result of
check_cc() is the only loc
Updates #4520.
---
c-user/config/task-stack-alloc.rst | 39 +-
1 file changed, 38 insertions(+), 1 deletion(-)
diff --git a/c-user/config/task-stack-alloc.rst
b/c-user/config/task-stack-alloc.rst
index 297c624..054f301 100644
--- a/c-user/config/task-stack-all
From: Hesham ALMatary
---
.../microblaze_fpga/console/console-io.c | 74 +
.../microblaze/microblaze_fpga/include/bsp.h | 48 ++
.../microblaze/microblaze_fpga/include/tm27.h | 48 ++
.../microblaze/microblaze_fpga/start/start.S | 109 +
.../startup/_excepti
From: Joel Sherrill
---
.../gdbmbsim/startup/_hw_exception_handler.S | 38 +
cpukit/score/cpu/microblaze/cpu.c | 168 +++
cpukit/score/cpu/microblaze/rtems/asm.h | 125 ++
cpukit/score/cpu/microblaze/rtems/score/cpu.h | 1263 +
.../cpu/microblaze/rtems/scor
v2:
- Move files from bsps/microblaze/microblaze_fpga/startup to
bsps/microblaze/microblaze_fpga/start
- Use crtinit.S from libgloss rather than sim-crtinit.S
Hi,
This patch set adds support for the MicroBlaze architecture along with
a basic BSP based on Xilinx's KCU105 PetaLinux BSP conf
On Tue, Oct 5, 2021, 1:49 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 05/10/2021 20:34, Joel Sherrill wrote:
> > On Tue, Oct 5, 2021 at 1:26 PM Sebastian Huber
> > wrote:
> >> The schedule operation is only called by rtems_task_mode(). It is
> >> called if preempt mode
On 05/10/2021 20:34, Joel Sherrill wrote:
On Tue, Oct 5, 2021 at 1:26 PM Sebastian Huber
wrote:
The schedule operation is only called by rtems_task_mode(). It is
called if preempt mode of the executing thread changes from disabled to
enabled. Since the EDF SMP scheduler does not support the
Add a stack allocator hook specifically for allocation of IDLE thread stacks.
This allows the user to decide if IDLE thread stacks are statically allocated
or handled by the same custom allocator mechanism as other thread stacks.
Closes #4520.
---
cpukit/Makefile.am|
On Tue, Oct 5, 2021 at 1:26 PM Sebastian Huber
wrote:
>
> The schedule operation is only called by rtems_task_mode(). It is
> called if preempt mode of the executing thread changes from disabled to
> enabled. Since the EDF SMP scheduler does not support the disabled
> preemption mode, the schedu
The schedule operation is only called by rtems_task_mode(). It is
called if preempt mode of the executing thread changes from disabled to
enabled. Since the EDF SMP scheduler does not support the disabled
preemption mode, the schedule operation is never called.
---
cpukit/include/rtems/score/sch
Add specialized rotations RB_RED_ROTATE_LEFT() and RB_RED_ROTATE_RIGHT() which
may be used if we rotate a red child which has a black sibling. Such a red
node must have at least two child nodes so that the following red-black tree
invariant is fulfilled:
Every path from a given node to any of i
Change the prototypes to be in line with POSIX/glibc. This may fix
issues with new warnings produced by GCC 11.
Signed-off-by: Sebastian Huber
---
newlib/libc/include/sys/_default_fcntl.h | 2 +-
newlib/libc/include/sys/stat.h | 4 ++--
newlib/libc/include/sys/time.h | 6 +++
Add specialized rotations RB_PARENT_ROTATE_LEFT() and RB_PARENT_ROTATE_RIGHT()
which may be used if the parent node exists and the direction of the child is
known. The specialized rotations are derived from RB_ROTATE_LEFT() and
RB_ROTATE_RIGHT() where the RB_SWAP_CHILD() was replaced by a simple
a
In RB_GENERATE_REMOVE_COLOR() simplify a chain of conditions of the following
pattern
if (x) {
...
} else if (!x) {
...
}
to
if (x) {
...
} else {
...
}
---
newlib/libc/include/sys/tree.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/newlib/libc/include/sys/tree.h
Code coverage analysis of the red-black tree insert/extract operations defined
in showed that the macros contain dead code. This patch set
simplifies some expressions and add specialized rotations.
v2:
Add comments in patch 3 and 4.
Sebastian Huber (4):
sys/tree.h: Simplify loop condition
We have
#define RB_ISRED(elm, field) \
((elm) != NULL && RB_COLOR(elm, field) == RB_RED)
So, the RB_ISRED() contains an implicit check for NULL. In
RB_GENERATE_REMOVE_COLOR() the "elm" pointer cannot be NULL in the while
condition. Use RB_COLOR(elm) == RB_BLACK instead.
---
newlib/libc/i
CID 1503013: Unchecked return value from library in ZlibFilter().
Closes #4431
---
trace/record/record-filter-zlib.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/trace/record/record-filter-zlib.cc
b/trace/record/record-filter-zlib.cc
index 62f1171..b97335b 100644
--- a/tr
Code coverage analysis of the red-black tree insert/extract operations defined
in showed that the macros contain dead code. This patch set
simplifies some expressions and add specialized rotations.
Sebastian Huber (4):
sys/tree.h: Simplify loop condition
sys/tree.h: Simplify chain of conditi
Add specialized rotations RB_PARENT_ROTATE_LEFT() and RB_PARENT_ROTATE_RIGHT()
which may be used if the parent node exists and the direction of the child is
known. The specialized rotations are derived from RB_ROTATE_LEFT() and
RB_ROTATE_RIGHT() where the RB_SWAP_CHILD() was replaced by a simple
a
Add specialized rotations RB_RED_ROTATE_LEFT() and RB_RED_ROTATE_RIGHT() which
may be used if we rotate a red child which has a black sibling. Such a red
node must have at least two child nodes so that the following red-black tree
invariant is fulfilled:
Every path from a given node to any of i
In RB_GENERATE_REMOVE_COLOR() simplify a chain of conditions of the following
pattern
if (x) {
...
} else if (!x) {
...
}
to
if (x) {
...
} else {
...
}
---
newlib/libc/include/sys/tree.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/newlib/libc/include/sys/tree.h
We have
#define RB_ISRED(elm, field) \
((elm) != NULL && RB_COLOR(elm, field) == RB_RED)
So, the RB_ISRED() contains an implicit check for NULL. In
RB_GENERATE_REMOVE_COLOR() the "elm" pointer cannot be NULL in the while
condition. Use RB_COLOR(elm) == RB_BLACK instead.
---
newlib/libc/i
On 5/10/21 10:27 am, Kinsey Moore wrote:
> Currently debugger01 is the only user of the test-if-library in libbsd and it
> doesn't seem to work as expected. The configure step that detects libdebugger
> occurs and succeeds as it should for the zynq a9 qemu BSP, but debugger01.exe
> never gets compi
27 matches
Mail list logo
