There is no need to pass in the order relation since the scheduled
threads reside on an already ordered chain. The caller will decide what
to do with the lowest scheduled thread.
---
.../score/include/rtems/score/schedulersmpimpl.h | 11 +++-
cpukit/score/src/scheduleredfsmp.c
In case the user provides a stack with address and size, then do not
alter the stack size.
Close #3211.
---
cpukit/posix/src/pthreadcreate.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/cpukit/posix/src/pthreadcreate.c b/cpukit/posix/src/pthreadcreate.c
inde
---
testsuites/sptests/spscheduler01/init.c| 120 +
testsuites/sptests/spscheduler01/spscheduler01.doc | 2 +
2 files changed, 99 insertions(+), 23 deletions(-)
diff --git a/testsuites/sptests/spscheduler01/init.c
b/testsuites/sptests/spscheduler01/init.c
index
---
cpukit/score/src/scheduleredfsmp.c | 9 -
cpukit/score/src/schedulersetaffinity.c | 7 +++
testsuites/sptests/spscheduler01/init.c | 13 -
3 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/cpukit/score/src/scheduleredfsmp.c
b/cpukit/score/src/sched
On 27/10/17 01:45, Hesham Almatary wrote:
+static void riscv_generic_clock_at_tick(void)
+{
+ REG(MTIME_MM) = 0;
+ REG(MTIMECMP_MM) = TTMR_NUM_OF_CLOCK_TICKS_INTERRUPT;
+
+ cpu_counter_ticks += TTMR_NUM_OF_CLOCK_TICKS_INTERRUPT * 1;
+}
+
Instead of setting the MM to 0, can't you incremen
On 27/10/17 01:45, Hesham Almatary wrote:
+#define REG(x) (*((volatile uint32_t *) (x)))
+#define BIT(n) (1 << (n))
+
+#define MTIME_MM0x0200bff8
+#define MTIMECMP_MM 0x02004000
This stuff should better not be in .
--
Sebastian Huber, embedded brains GmbH
Address : Do
Patch set v3 looks all right from my point of view.
--
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.
Die
symlink riscv_generic -> riscv64_generic
Update #3109
---
.../riscv_generic/make/custom/riscv64_generic.cfg | 7 ++
c/src/lib/libbsp/riscv64/Makefile.am | 14
c/src/lib/libbsp/riscv64/acinclude.m4 | 10 +++
c/src/lib/libbsp/riscv64/configure.ac | 19
Update #3109
---
c/src/lib/libbsp/riscv32/riscv_generic/include/bsp.h| 6 +++---
c/src/lib/libbsp/riscv32/riscv_generic/start/start.S| 10 --
c/src/lib/libbsp/riscv32/riscv_generic/startup/linkcmds | 10 ++
3 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/c
Update #3109
---
c/src/aclocal/rtems-cpu-subdirs.m4 | 1 +
cpukit/configure.ac| 1 +
cpukit/score/cpu/Makefile.am | 1 +
3 files changed, 3 insertions(+)
diff --git a/c/src/aclocal/rtems-cpu-subdirs.m4
b/c/src/aclocal/rtems-cpu-subdirs.m4
index b5b579e..863451e 100644
--- a
Hello,
what is now the consensus?
1. We keep the Linux submodule and the scripting support private to EB.
2. We rename the "linux" directory into "linux-dual-license" to
emphasize that this directory contains dual licensed code imported from
Linux.
3. All commits referencing "linux-dual-lic
Hello Chris,
thanks for your hints. This ser2net and the IO via telnet is really
nice. I am now able to run the tests on a board with U-Boot.
U-Boot has a "tftpdstport" option. Maybe this can be used to avoid
running the rtems-test as root.
There is a problem on some tests with mixed output
Hi
First I am thrilled at the reports going to build@
It occurred to me looking at the reports I was posting that they only
say x86_64-linux-gnu. That is not enough to distinguish distributions or
even tell the difference between something as old as CentOS 6 from a
bleeding edge Fedora or Ubuntu
This impacts rtems_task_mode() and rtems_task_create().
updates #3000.
---
c/src/ada/rtems.ads | 3 ++-
cpukit/rtems/include/rtems/rtems/status.h | 10 --
cpukit/rtems/src/statustext.c | 1 +
cpukit/rtems/src/taskcreate.c | 19 ++
On Fri, Oct 27, 2017 at 5:55 PM, Chris Johns wrote:
> On 27/10/2017 16:45, Sebastian Huber wrote:
>> Thanks, committed. Even the Ada support works:
>>
>> riscv64-rtems4.12-gnat --version
>> GNAT 7.2.0 20170814 (RTEMS 4.12, RSB
>> 5bd4aa6bb33872b0f0fb243e7fc2f0784e69ab81,
>> Newlib 2.5.0.20170922)
Update #3109
---
tester/rtems/rtems-bsps-riscv32.ini | 25
tester/rtems/rtems-bsps-riscv64.ini | 25
tester/rtems/testing/bsps/riscv64_generic.ini | 38 ++
tester/rtems/testing/bsps/riscv64_generic.mc | 53
tes
Update #3109
---
bare/config/devel/spike-1.1.0.cfg | 21
bare/config/devel/spike.bset| 7
source-builder/config/spike-1-1.cfg | 64 +
3 files changed, 92 insertions(+)
create mode 100644 bare/config/devel/spike-1.1.0.cfg
create mod
On 28/10/2017 06:18, Joel Sherrill wrote:
>
> First I am thrilled at the reports going to build@
>
I am as well. It is great to see valid test results being published.
To everyone, the results are easy to publish so please do so. If you are on a
host we do not have results for or you just want
18 matches
Mail list logo