On 2021/4/23 下午7:10, Bezdeka, Florian wrote:
On Wed, 2021-04-21 at 16:33 +0800, Song Chen wrote:
From: chensong
Add a syscall specific for clock_gettime with 64bit
time_t.
Signed-off-by: chensong
---
v5:
1, new helper __cobalt_clock_gettime64
---
include/cobalt/kernel/time.h| 11
add test case for clock_nanosleep64 in testsuite
Signed-off-by: chensong
---
testsuite/smokey/y2038/syscall-tests.c | 65 ++
1 file changed, 65 insertions(+)
diff --git a/testsuite/smokey/y2038/syscall-tests.c
b/testsuite/smokey/y2038/syscall-tests.c
index
If sizeof time_t bigger than 4, which means glibc supports
64bit timespec, go to clock_nanosleep64.
otherwise, go to original clock_nanosleep.
Signed-off-by: chensong
---
lib/cobalt/clock.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/lib/cobalt/clock.c b/lib/cobalt/clock.c
index
Add a syscall specific for clock_nanosleep with 64bit
time_t.
Signed-off-by: chensong
---
include/cobalt/uapi/syscall.h | 1 +
kernel/cobalt/posix/clock.c | 23 +++
kernel/cobalt/posix/clock.h | 5 +
kernel/cobalt/posix/syscall32.c | 23
This patch serial is aimed to introduce a new syscall clock_nanosleep64
which is specific for 64-bit time_t.
chensong (3):
y2038: cobalt/posix/clock: Adding clock_nanosleep64
y2038: lib/cobalt/clock: dispatch clock_nanosleep
y2038: testsuite/smokey/y2038: testcase for nanosleep64
new test case for clock_settime64 and clock_gettime64 and reorganize
run_2038.
If you want to trigger and verify y2038 problem, please be careful and
make sure it has no impact to your test device.
Signed-off-by: chensong
---
v3:
1, rename structs, variables
2, reorganize registration in
On 2021年03月31日 03:54, Florian Bezdeka wrote:
Hi Song!
On 30.03.21 12:23, chensong wrote:
new test case for clock_settime64 and clock_gettime64 and reorganize
run_2038.
If you want to trigger and verify y2038 problem, please be careful and
make sure it has no impact to your test device.
new test case for clock_settime64 and clock_gettime64 and reorganize
run_2038.
If you want to trigger and verify y2038 problem, please be careful and
make sure it has no impact to your test device.
Signed-off-by: chensong
---
v3:
1, rename structs, variables
2, reorganize registration in
On 2021年03月26日 17:53, Florian Bezdeka wrote:
On 26.03.21 02:20, chensong wrote:
On 2021年03月24日 20:28, Florian Bezdeka wrote:
On 18.03.21 08:36, chensong wrote:
new test case for clock_settime64 and clock_gettime64 and reorganize
run_2038.
If you want to trigger and verify y2038 problem,
On 2021年03月24日 20:28, Florian Bezdeka wrote:
On 18.03.21 08:36, chensong wrote:
new test case for clock_settime64 and clock_gettime64 and reorganize
run_2038.
If you want to trigger and verify y2038 problem, please be careful and
make sure it has no impact to your test device.
i did, firefly, kernel is 4.4, xenomai 3.1, ipipe 4.9, backported manually.
Song
On 2021年03月26日 00:00, Zhao, Lixiang via Xenomai wrote:
Hi,
I would like to patch a board with a Rockchip RK3399 SoC with Xenomai v3.1, I'm
unsure if this SoC is supported, could you help me find it out ?
Best
On 2021年03月24日 17:33, florian.bezd...@siemens.com wrote:
Hi Song!
That looks good so far.
That's great, if this patch serial looks good to you, i can follow it up
for the rest syscalls.
I'm on "vacation" for the next two weeks, so no
timing guarantees, but I will give it a try and
new test case for clock_settime64 and clock_gettime64 and reorganize
run_2038.
If you want to trigger and verify y2038 problem, please be careful and
make sure it has no impact to your test device.
Signed-off-by: chensong
---
testsuite/smokey/y2038/syscall-tests.c | 115
If sizeof time_t bigger than 4, which means glibc supports
64bit timespec, go to clock_settime64.
otherwise, go to original clock_settime.
Signed-off-by: chensong
---
lib/cobalt/clock.c | 4
1 file changed, 4 insertions(+)
diff --git a/lib/cobalt/clock.c b/lib/cobalt/clock.c
index
If sizeof time_t bigger than 4, which means glibc supports
64bit timespec, go to clock_gettime64.
otherwise, go to original clock_settime.
Signed-off-by: chensong
---
lib/cobalt/clock.c | 8
1 file changed, 8 insertions(+)
diff --git a/lib/cobalt/clock.c b/lib/cobalt/clock.c
index
Adding a new syscall clock_settime64 specific for timespec64,
It can solve y2038 in below scenarios:
1, 64bit kernel, 64bit process, no break. y2038 safe
2, 32bit kernel, 32bit process, 32bit time_t, go to clock_settime,
no break, y2038 not safe.
3, 32bit kernel, 32bit process, 64bit time_t, go
Add a syscall specific for clock_gettime with 64bit
time_t.
Signed-off-by: chensong
---
include/cobalt/kernel/time.h| 11 +++
include/cobalt/uapi/syscall.h | 1 +
kernel/cobalt/posix/clock.c | 16 +++-
kernel/cobalt/posix/clock.h | 3 +++
This patch serial is aimed to introduce a new syscall clock_settime64
and clock_gettime64 which are specific for 64-bit time_t.
There is no impact to current implementation of clock_settime, nothing
broken.
---
v2:
1, merge clock_settime64 and compat clock_settime64
2, remove checking
On 2021年03月12日 18:19, florian.bezd...@siemens.com wrote:
On Fri, 2021-03-12 at 12:01 +0800, chensong wrote:
This patch serial is aimed to introduce a new syscall clock_settime64
and clock_gettime64 which are specific for 64-bit time_t.
There is no impact to current implementation of
new test case for clock_settime64 and clock_gettime64 and reorganize
run_2038.
If you want to trigger and verify y2038 problem, please be careful and
make sure it has no impact to your test device.
Signed-off-by: chensong
---
testsuite/smokey/y2038/syscall-tests.c | 114
If sizeof time_t bigger than 4, which means glibc supports
64bit timespec, go to clock_gettime64.
otherwise, go to original clock_settime.
Signed-off-by: chensong
---
lib/cobalt/clock.c | 8
1 file changed, 8 insertions(+)
diff --git a/lib/cobalt/clock.c b/lib/cobalt/clock.c
index
If sizeof time_t bigger than 4, which means glibc supports
64bit timespec, go to clock_settime64.
otherwise, go to original clock_settime.
Signed-off-by: chensong
---
V2: remove checking __xn_feat_time64
---
lib/cobalt/clock.c | 4
1 file changed, 4 insertions(+)
diff --git
Add a syscall specific for clock_gettime with 64bit
time_t.
Signed-off-by: chensong
---
include/cobalt/kernel/time.h| 3 +++
include/cobalt/uapi/syscall.h | 1 +
kernel/cobalt/posix/clock.c | 16 +++-
kernel/cobalt/posix/clock.h | 3 +++
This patch serial is aimed to introduce a new syscall clock_settime64
and clock_gettime64 which are specific for 64-bit time_t.
There is no impact to current implementation of clock_settime, nothing
broken.
---
v2:
1, merge clock_settime64 and compat clock_settime64
2, remove checking
Adding a new syscall clock_settime64 specific for timespec64,
It can solve y2038 in below scenarios:
1, 64bit kernel, 64bit process, no break. y2038 safe
2, 32bit kernel, 32bit process, 32bit time_t, go to clock_settime,
no break, y2038 not safe.
3, 32bit kernel, 32bit process, 64bit time_t, go
On 2021年03月11日 17:29, chensong via Xenomai wrote:
On 2021年03月11日 17:03, florian.bezd...@siemens.com wrote:
On Thu, 2021-03-11 at 10:46 +0800, chensong wrote:
Adding a new syscall clock_settime64 specific for timespec64,
It can solve y2038 in below scenarios:
1, 64bit kernel, y2038 safe
2
On 2021年03月11日 17:03, florian.bezd...@siemens.com wrote:
On Thu, 2021-03-11 at 10:46 +0800, chensong wrote:
Adding a new syscall clock_settime64 specific for timespec64,
It can solve y2038 in below scenarios:
1, 64bit kernel, y2038 safe
2, 32bit kernel, 32bit time_t, go to clock_settime, no
On 2021年03月11日 16:27, florian.bezd...@siemens.com wrote:
Hi!
On Thu, 2021-03-11 at 10:45 +0800, chensong wrote:
This patch serial is aimed to introduce a new syscall clock_settime64,
which is specific for 64-bit time_t.
There is no impact to current implemetation of clock_settime, nothing
If sizeof time_t bigger than 4, which means glibc supports
64bit timespec, and __xn_feat_time64 is available in kernel,
go to clock_settime64.
otherwise, go to original clock_settime.
Signed-off-by: chensong
---
lib/cobalt/clock.c | 6 ++
1 file changed, 6 insertions(+)
diff --git
Adding a new syscall clock_settime64 specific for timespec64,
It can solve y2038 in below scenarios:
1, 64bit kernel, y2038 safe
2, 32bit kernel, 32bit time_t, go to clock_settime, no break,
y2038 not safe.
3, 32bit kernel, 64bit time_t, go to clock_settime64 by the help
of libcobalt, no
old_timespec32 and __kernel_timespec were introduced to linux kernel specific
for y2038 problem, xenomai needs them as well, but it will break the build if
kernel version is old.
To be back compatibale with old version kernel. we introduce them in wrappers.h.
Signed-off-by: chensong
---
Add a new compat syscall clock_settime64 specific for
timespec64, It can solve y2038 in below scenarios:
1, 64bit kernel, 32bit process, 32bit time_t, go to clock_settime,
no break, y2038 not safe.
3, 64bit kernel, 32bit process, 64bit time_t, go to clock_settime64
by the help of libcobalt, no
This patch serial is aimed to introduce a new syscall clock_settime64,
which is specific for 64-bit time_t.
There is no impact to current implemetation of clock_settime, nothing
broken.
chensong (4):
include: wrappers: introduce old_timespec32 and __kernel_timespec
[y2038]cobalt: posix:
On 2021年03月10日 21:09, Florian Bezdeka via Xenomai wrote:
In case libcobalt is build with -D_TIME_BITS=64
sc_cobalt_sem_timedwait64 will be used instead of
sc_cobalt_sem_timedwait.
Signed-off-by: Florian Bezdeka
---
lib/cobalt/semaphore.c | 5 +
1 file changed, 5 insertions(+)
diff
On 2021年03月10日 15:51, florian.bezdeka--- via Xenomai wrote:
On Tue, 2021-03-09 at 07:53 +, florian.bezdeka--- via Xenomai
wrote:
On Mon, 2021-03-08 at 19:28 +0100, Jan Kiszka wrote:
On 08.03.21 18:02, Florian Bezdeka wrote:
Implementation is heavily inspired by the sem_timedwait
On 2021年03月05日 14:36, florian.bezd...@siemens.com wrote:
On Fri, 2021-03-05 at 13:49 +0800, chensong wrote:
On 2021年03月04日 19:36, Florian Bezdeka via Xenomai wrote:
Implementation is heavily inspired by the sem_timedwait syscall,
but expecting time64 based timespec / timeout.
We need two
On 2021年03月04日 19:36, Florian Bezdeka via Xenomai wrote:
Implementation is heavily inspired by the sem_timedwait syscall,
but expecting time64 based timespec / timeout.
We need two new syscall handlers:
- The native one (COBALT_SYSCALL()) to get 32 bit kernels time64
aware. This
On 2021年03月04日 17:00, florian.bezd...@siemens.com wrote:
On Thu, 2021-03-04 at 13:58 +0800, chensong wrote:
On 2021年03月02日 21:43, florian.bezdeka--- via Xenomai wrote:
On Tue, 2021-03-02 at 21:10 +0800, chensong wrote:
Florian $ Philippe,
As the discussion in the mails 2021-02-21, we are
On 2021年03月02日 21:44, Philippe Gerum via Xenomai wrote:
chensong writes:
Since timespec and timeval will be removed because of
y2038 problem, we need to introduce new time representations at
the kernel-user boundary and we also need to keep aligned with
upstream at the same time.
On 2021年03月02日 21:43, florian.bezdeka--- via Xenomai wrote:
On Tue, 2021-03-02 at 21:10 +0800, chensong wrote:
Florian $ Philippe,
As the discussion in the mails 2021-02-21, we are going to replace
__user_old_timespec with __kernel_old_timespec to keep aligned with
upstream.
Please note
Florian $ Philippe,
As the discussion in the mails 2021-02-21, we are going to replace
__user_old_timespec with __kernel_old_timespec to keep aligned with
upstream.
This patch introduced their definitions, if you both agree, i will start
replacing __user_old_timespec and __user_old_timeval
Since timespec and timeval will be removed because of
y2038 problem, we need to introduce new time representations at
the kernel-user boundary and we also need to keep aligned with
upstream at the same time.
Therefore, we introduce:
1)__kernel_old_timeval
2)__kernel_old_timespec
from upstream,
On 2021年02月21日 23:27, Philippe Gerum wrote:
chensong via Xenomai writes:
+/*
+ * Our representation of time at the kernel<->user interface boundary
+ * at the moment, until we have fully transitioned to a y2038-safe
+ * implementation in libcobalt.
+ */
+struct __user_old_ti
On 2021年02月20日 23:18, Philippe Gerum via Xenomai wrote:
From: Philippe Gerum
As internal interfaces are gradually being made y2038-safe, the
timespec64 type should be used internally by the kernel to represent
time values. Apply the same reasoning to Cobalt.
We still use a legacy
On 2021年02月20日 20:45, Philippe Gerum via Xenomai wrote:
From: Philippe Gerum
In order to intimately connect Cobalt to the kernel, Dovetail allows
us to extend the latter with data and procedures we need:
- we can embed our own context information into a set of critical
kernel data
why do we need a new interface instead of adding a new parameter(cpu) in
old interface, in this case rtdm_task_init.
For backward compatibility?
On 2021年02月20日 13:53, hongzha1 via Xenomai wrote:
Initialise and start a real-time task on specified cpu
Signed-off-by: hongzha1
diff --git
On 2021年01月12日 09:35, Chen, Hongzhan wrote:
>
>
>-Original Message-
>From: chensong
>Sent: Tuesday, January 12, 2021 9:21 AM
>To: Chen, Hongzhan ; Xenomai@xenomai.org
>Subject: Re: [PATCH 09/10] dovetail/clock: implement
pipeline_timer_name to get name of real device
>
On 2021年01月11日 14:43, hongzha1 via Xenomai wrote:
Signed-off-by: hongzha1
---
include/cobalt/kernel/dovetail/pipeline/clock.h | 5 ++---
kernel/cobalt/dovetail/tick.c | 8
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git
It's working, many thanks.
BR
chensong
On 2020年12月29日 11:06, Chen, Hongzhan wrote:
Hi chensong
Let us switch to and focus on CXP. Actually
https://github.com/hongzhanchen/xenomai.git is
not based on
https://lab.xenomai.org/xenomai-rpm.git/log/?h=for-upstream/dovetail which
is base of CXP
Great, many thanks, i will give it a try.
BR
chensong
On 2020年12月29日 11:06, Chen, Hongzhan wrote:
Hi chensong
Let us switch to and focus on CXP. Actually
https://github.com/hongzhanchen/xenomai.git is
not based on
https://lab.xenomai.org/xenomai-rpm.git/log/?h=for-upstream/dovetail which
Dear Philippe & Hongzhan,
I was trying to build xenomai3.2 and boot it in my desktop, here is what
i did:
1, git clone -b dovetail/master git://git.evlproject.org/linux.evl.git
2, git clone -b hongzhan/dovetail
https://github.com/hongzhanchen/xenomai.git
3,
Mr. Denk,
Thanks a lot for the explanation, now it's clear to me.
My concern was, it's a competition outside, RTOS emulators might be
additional value xenomai brings to customers besides low and
deterministic latency.
If we think nobody benefits, we should move on and focus on what is
clear to me, many thanks.
BR
chensong
On 2020年12月07日 18:12, Philippe Gerum wrote:
Hi,
chensong via Xenomai writes:
hi Philippe,
As far as i know, some vxworks customers like xenomai because they can
move their RT processes from vxworks to linux without rewriting their
code by the help
On 2020年12月07日 14:59, Greg Gallagher wrote:
On Sun, Dec 6, 2020 at 9:15 PM chensong via Xenomai mailto:xenomai@xenomai.org>> wrote:
hi Philippe,
As far as i know, some vxworks customers like xenomai because they can
move their RT processes from vxworks to linux w
hi Philippe,
As far as i know, some vxworks customers like xenomai because they can
move their RT processes from vxworks to linux without rewriting their
code by the help of vxworks skin.
If we "Excluding the legacy RTOS emulators such as VxWorks", we will
lose them. It could depend on the
On 2020年11月23日 23:14, florian.bezd...@siemens.com wrote:
Hi Song,
On Mon, 2020-11-23 at 20:44 +0800, chensong wrote:
@@ -243,14 +241,18 @@ int __cobalt_clock_adjtime(clockid_t clock_id, struct
timex *tx)
}
COBALT_SYSCALL(clock_settime, current,
- (clockid_t
On 2020年11月23日 20:19, florian.bezd...@siemens.com wrote:
On Mon, 2020-11-23 at 19:03 +0800, chensong wrote:
On 2020年11月19日 20:11, florian.bezd...@siemens.com wrote:
On Thu, 2020-11-19 at 16:36 +0800, chensong wrote:
old_timespec32 was introduced in vanilla kernel at version 4.19
for
On 2020年11月19日 20:11, florian.bezd...@siemens.com wrote:
On Thu, 2020-11-19 at 16:36 +0800, chensong wrote:
old_timespec32 was introduced in vanilla kernel at version 4.19
for y2038, it replaces timespec in syscalls to keep compatibility
for 32bit timespec.
In this patch, i follow it's
On 2020年11月11日 17:43, Jan Kiszka wrote:
On 11.11.20 10:23, chensong wrote:
On 2020年11月11日 15:29, Jan Kiszka wrote:
On 11.11.20 04:55, chensong wrote:
On 2020年11月10日 18:24, Jan Kiszka wrote:
On 03.11.20 04:05, chensong wrote:
Regarding sizeof time_t, dispatch 32bit timespec to
On 2020年11月11日 15:34, Jan Kiszka wrote:
On 11.11.20 06:50, chensong wrote:
On 2020年11月10日 18:17, Jan Kiszka wrote:
On 03.11.20 04:05, chensong wrote:
1, introduce old_timespec32 for 32bit process with 32bit timespec
2, implement clock_settime64 for 32bit process with 64bit timespec
On 2020年11月11日 15:23, Jan Kiszka wrote:
On 11.11.20 04:21, chensong wrote:
On 2020年11月10日 18:14, Jan Kiszka wrote:
On 03.11.20 04:04, chensong wrote:
Replace timespec with old_timespec32 as the parameter passed from
processes with 32bit timespec in clock_settime.
Also, replace timespec
On 2020年11月11日 15:29, Jan Kiszka wrote:
On 11.11.20 04:55, chensong wrote:
On 2020年11月10日 18:24, Jan Kiszka wrote:
On 03.11.20 04:05, chensong wrote:
Regarding sizeof time_t, dispatch 32bit timespec to clock_settime
and 64bit timespec to clock_settime64.
Signed-off-by: chensong
---
On 2020年11月10日 18:17, Jan Kiszka wrote:
On 03.11.20 04:05, chensong wrote:
1, introduce old_timespec32 for 32bit process with 32bit timespec
2, implement clock_settime64 for 32bit process with 64bit timespec
Signed-off-by: chensong
---
include/cobalt/kernel/compat.h | 6 ++
On 2020年11月10日 18:24, Jan Kiszka wrote:
On 03.11.20 04:05, chensong wrote:
Regarding sizeof time_t, dispatch 32bit timespec to clock_settime
and 64bit timespec to clock_settime64.
Signed-off-by: chensong
---
lib/cobalt/clock.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
On 2020年11月10日 18:14, Jan Kiszka wrote:
On 03.11.20 04:04, chensong wrote:
Replace timespec with old_timespec32 as the parameter passed from
processes with 32bit timespec in clock_settime.
Also, replace timespec with timespec64 inside clock_settime.
Signed-off-by: chensong
---
Regarding sizeof time_t, dispatch 32bit timespec to clock_settime
and 64bit timespec to clock_settime64.
Signed-off-by: chensong
---
lib/cobalt/clock.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/lib/cobalt/clock.c b/lib/cobalt/clock.c
index 11fd1aa..44b2f3f 100644
1, introduce old_timespec32 for 32bit process with 32bit timespec
2, implement clock_settime64 for 32bit process with 64bit timespec
Signed-off-by: chensong
---
include/cobalt/kernel/compat.h | 6 ++
kernel/cobalt/posix/compat.c| 20
Implement a new syscall, clock_settime64 specific for
processes with 64bit timespec.
Signed-off-by: chensong
---
include/cobalt/uapi/syscall.h| 1 +
kernel/cobalt/include/asm-generic/xenomai/wrappers.h | 8
kernel/cobalt/posix/clock.c
old_timespec32 was introduced in vanilla kernel at version 4.19
for y2038 problem, therefore, xenomai should introduce it in wrappers
as well to get compatible with old kernel versions.
Signed-off-by: chensong
---
kernel/cobalt/include/asm-generic/xenomai/wrappers.h | 9 +
1 file
Replace timespec with old_timespec32 as the parameter passed from
processes with 32bit timespec in clock_settime.
Also, replace timespec with timespec64 inside clock_settime.
Signed-off-by: chensong
---
include/cobalt/kernel/clock.h | 6 +++---
kernel/cobalt/posix/clock.c| 14
This patch serial is aimed to remove 32bit timespec for clock_settime.
In the interface level, 32bit timespec is replaced by old_timespec32
followed the solution of vanilla kernel 5.4.
In addition, a new interface clock_settime64 is implemented specific
for 64bit timespec.
In the libcobalt,
On 2020年10月30日 17:09, Jan Kiszka wrote:
On 30.10.20 09:50, chensong wrote:
On 2020年10月28日 00:33, Jan Kiszka wrote:
On 29.09.20 09:19, chensong wrote:
Upstream has used timespec64 to replace timespec inside kernel and
used __kernel_timespec to replace timespect in syscalls, therefore
we
On 2020年10月28日 00:33, Jan Kiszka wrote:
On 29.09.20 09:19, chensong wrote:
Upstream has used timespec64 to replace timespec inside kernel and
used __kernel_timespec to replace timespect in syscalls, therefore
we must keep aligned with upstream.
clock_settime is a point to get started at, it
On 2020年10月26日 21:45, Greg Gallagher via Xenomai wrote:
On Mon, Oct 26, 2020 at 4:25 AM Fino Meng via Xenomai
wrote:
On Mon, Oct 26, 2020 at 08:54:54AM +0100, Jan Kiszka via Xenomai wrote:
Hi all,
a brief update on the porting status to 5.4:
- new noarch ipipe/master is ready:
On 2020年10月26日 19:04, Jan Kiszka via Xenomai wrote:
From: Fino Meng
compat_timex related definitions moved from compat code into normal timekeeping
code.
see 4d5f007e in upstream Linux kernel.
Signed-off-by: Fino Meng
Signed-off-by: Mingliang Hu
[Jan: account for older kernel versions]
Hi Jan;
i talked to arnd Bergmann about how to build a 32bit 2038-safe process,
he told me that neither gcc nor glibc can fully support 64bit timespec
yet, he suggested me to use musl(https://wiki.musl-libc.org/), and he
also suggested me to use kernel5.4.
I followed his suggestion, built a
On 2020年10月01日 03:19, Jan Kiszka wrote:
On 29.09.20 08:27, chensong wrote:
On 2020年09月29日 00:52, Jan Kiszka wrote:
On 23.09.20 03:40, song wrote:
On 2020/9/22 下午11:16, Jan Kiszka wrote:
On 21.09.20 14:32, chensong wrote:
Upstream has used timespec64 to replace timespec inside kernel
Upstream has used timespec64 to replace timespec inside kernel and
used __kernel_timespec to replace timespect in syscalls, therefore
we must keep aligned with upstream.
clock_settime is a point to get started at, it involves 2 parts:
1, syscall in ./include/trace/events/cobalt-posix.h for 64bits
On 2020年09月29日 00:52, Jan Kiszka wrote:
On 23.09.20 03:40, song wrote:
On 2020/9/22 下午11:16, Jan Kiszka wrote:
On 21.09.20 14:32, chensong wrote:
Upstream has used timespec64 to replace timespec inside kernel and
used __kernel_timespec to replace timespect in syscalls, therefore
we must
Upstream has used timespec64 to replace timespec inside kernel and
used __kernel_timespec to replace timespect in syscalls, therefore
we must keep aligned with upstream.
clock_settime is a point to get started at, it involves 2 parts:
1, syscall in ./include/trace/events/cobalt-posix.h for 64bits
hi Henning,
I collected some discussions about y2038 from upstream and made a
rough list for xenomai:
1, 64bit-xenomai y2038-safe
2, 32bit-xenomai y2038-safe
3, 64bit-ipipe y2038-safe (arm64, x86_64)
4, 32bit-ipipe y2038-safe (arm, x86)
5, syscall (posix and all other skins)
6, libc
7, 32 bit
On 2020年08月13日 18:27, Jan Kiszka wrote:
On 13.08.20 12:06, chensong wrote:
On 2020年08月13日 16:54, Jan Kiszka wrote:
On 13.08.20 03:57, chensong wrote:
I read the code in cyclictest, looks like
printf("index: %d, inner_diff: %llu, outer_diff: %llu\n", index,
(unsigned
On 2020年08月13日 16:54, Jan Kiszka wrote:
On 13.08.20 03:57, chensong wrote:
I read the code in cyclictest, looks like
printf("index: %d, inner_diff: %llu, outer_diff: %llu\n", index,
(unsigned long long)inner_diff,
(unsigned long long)outer_diff);
I read the code in cyclictest, looks like
printf("index: %d, inner_diff: %llu, outer_diff: %llu\n", index,
(unsigned long long)inner_diff,
(unsigned long long)outer_diff);
can fix the error reported in
This a tool to benchmark the latency of GPIO driver,
it's able to run 2 kinds of benchmark test:
1, loopback mode
1) apply 2 gpio pins by calling service in gpio RTDM driver
like gpio-bcm2835 and gpio-core.c, one is as output,
the other is as interrupt
2) call write_rt to send a pulse from
From: chensong
It's a tool to benchmark the latency of GPIO driver
it's able to run 2 kinds of benchmark test:
1, loopback mode
1) apply 2 gpio pins by calling service in gpio RTDM driver
like gpio-bcm2835 and gpio-core.c, one is as output,
the other is as interrupt
2) call write_rt to
On 2020年07月07日 08:42, chensong via Xenomai wrote:
On 2020年07月07日 00:05, Greg Gallagher wrote:
On Mon, Jul 6, 2020 at 5:29 AM chensong wrote:
On 2020年07月06日 13:59, Greg Gallagher wrote:
Hi
On Sun, Jul 5, 2020 at 9:36 PM chensong via Xenomai
wrote:
On 2020年07月03日 17:21, Jan
On 2020年07月07日 00:05, Greg Gallagher wrote:
On Mon, Jul 6, 2020 at 5:29 AM chensong wrote:
On 2020年07月06日 13:59, Greg Gallagher wrote:
Hi
On Sun, Jul 5, 2020 at 9:36 PM chensong via Xenomai wrote:
On 2020年07月03日 17:21, Jan Kiszka wrote:
On 03.07.20 08:37, chensong via Xenomai
On 2020年07月06日 13:59, Greg Gallagher wrote:
Hi
On Sun, Jul 5, 2020 at 9:36 PM chensong via Xenomai wrote:
On 2020年07月03日 17:21, Jan Kiszka wrote:
On 03.07.20 08:37, chensong via Xenomai wrote:
In general, we use cyclictest and latency to evaluate the determinism
of our real
time
On 2020年07月06日 09:35, chensong via Xenomai wrote:
On 2020年07月03日 17:21, Jan Kiszka wrote:
On 03.07.20 08:37, chensong via Xenomai wrote:
In general, we use cyclictest and latency to evaluate the determinism
of our real
time system. As we know, cyclictest and latency use hrtimer to set up
On 2020年07月03日 17:21, Jan Kiszka wrote:
On 03.07.20 08:37, chensong via Xenomai wrote:
In general, we use cyclictest and latency to evaluate the determinism
of our real
time system. As we know, cyclictest and latency use hrtimer to set up
a timer and
calculate jitter by comparing expected
On 2020年07月03日 17:21, Jan Kiszka wrote:
On 03.07.20 08:37, chensong via Xenomai wrote:
In general, we use cyclictest and latency to evaluate the determinism
of our real
time system. As we know, cyclictest and latency use hrtimer to set up
a timer and
calculate jitter by comparing expected
From: chensong
1, request 2 gpio ports, one is output, the other is interrupt
connect them with a cable, once there is a signal in output,
an interrupt will be raised
2, an interrupt handler
3, write_rt, read_rt for app to get timestamp
4, record timestamp in write_rt and interrupt handler
From: chensong
It's a tool to benchmark the latency of GPIO driver
It consists of 2 parts:
1,driver:
1) request 2 gpio ports, one is output, the other is interrupt
connect them with a cable, once there is a signal in output,
an interrupt will be raised
2) an interrupt handler
3) write_rt,
In general, we use cyclictest and latency to evaluate the determinism of our
real
time system. As we know, cyclictest and latency use hrtimer to set up a timer
and
calculate jitter by comparing expected wakeup time and real wakeup time.
Besides that, we can also use GPIO to evaluate more
In general, i used ftrace to figure out latency sources, below is what i
did, you can give it a try
trace-cmd start -e irq -e sched -e timer -p function -l '*spin*';
cyclictest -p 90 -m -c 0 -n -i 100 -h 100 -q -l 100 -a -b 80 --tracemark
trace-cmd extract
trace-cmd report -l >
I think it's fixed
Brcm_MSI hasn't complied with IPIPE IRQ handling yet,as a result, it
still goes to the stack like:
brcm_pcie_msi_isr --
generic_handle_irq --
handle_simple_irq --
handle_irq_event --
__handle_irq_event_percpu.
Regarding the warning, !irq_disabled is
On 2020年06月02日 17:08, Jan Kiszka wrote:
On 02.06.20 10:51, chensong wrote:
On 2020年06月02日 15:49, Jan Kiszka wrote:
On 01.06.20 15:51, Greg Gallagher via Xenomai wrote:
I'm not sure if the rpi4 is in mainline yet but you may have more
success trying this with the mainline kernel
The
On 2020年06月02日 15:49, Jan Kiszka wrote:
On 01.06.20 15:51, Greg Gallagher via Xenomai wrote:
I'm not sure if the rpi4 is in mainline yet but you may have more
success trying this with the mainline kernel
The RPi4 is still far aways from mainline, unfortunately. The usual
downstream mess.
On 2020年06月01日 21:51, Greg Gallagher wrote:
Hi,
On Mon, Jun 1, 2020 at 4:41 AM chensong via Xenomai wrote:
hi guys,
I have a raspberry pi 4b and i have had xenoami running on it. Here is
what i did:
I don't think anyone has tried this yet, so you are one of the first :)
lucky me.
1
1 - 100 of 108 matches
Mail list logo
