On 10/09/2017 02:22 AM, Christoph Müllner wrote:
Hi Xenomai/I-pipe devs,
we have I-pipe/Cobalt/Xenomai running here on a Rockchip RK3399, which is a six
core ARMv8/aarch64 SoC.
Our current kernel is based on vanilla Linux 4.12.10 and we've applied the
I-pipe patches for 4.11-arm64.
Of course t
On 10/12/2017 05:49 AM, Christoph Muellner wrote:
This patch enables interrupt pipelining for ARM/ARM64 SoC with a
GICv3 interrupt controller.
The patch was tested on a Rockchip RK3399 (ARM64 SoC) with
Linux 4.12.14, I-pipe 4.11-arm64 and Xenomai/Cobalt 3.1 (next).
xeno-test did not show any err
On 10/12/2017 11:16 AM, Christoph Müllner wrote:
That was my first attempt, but that ends up in a hang during bootup.
I suspect that the .irq_hold() callback must not call ipipe_lock_irq().
And since I added that call to gic_mask_irq(), I cannot call .irq_mask().
Note, that this code equals als
On 11/21/2017 09:11 AM, Philippe Gerum wrote:
So, let's talk about the elephant in the room: the current situation of
the Xenomai project is not viable in the long run. I can only encourage
people who feel concerned about it to discuss openly the practical steps
to best address this challenge.
This patch set updates Xenomai for compatibility with the 4.14 kernel.
Dmitriy Cherkasov (3):
cobalt/kernel: make signal code handling compatible with 4.14
cobalt/kernel: remove usage of GFP_TEMPORARY
cobalt/kernel: add missing header for 4.14 compatibility
kernel/cobalt/debug.c
Linux does away with GFP_TEMPORARY starting with 4.14 (see 0ee931c4e31a5).
Update cobalt to use GFP_KERNEL instead.
Signed-off-by: Dmitriy Cherkasov
---
kernel/cobalt/debug.c | 2 +-
kernel/cobalt/posix/process.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a
Add missing uaccess.h needed for copy_{to/from}_user_inatomic under Linux 4.14.
Signed-off-by: Dmitriy Cherkasov
---
kernel/cobalt/include/asm-generic/xenomai/syscall.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/cobalt/include/asm-generic/xenomai/syscall.h
b/kernel/cobalt
Linux does away with __SI_MASK in 4.14 (see cc731525f26af).
Update cobalt to reflect this change.
Signed-off-by: Dmitriy Cherkasov
---
kernel/cobalt/posix/signal.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/cobalt/posix/signal.c b/kernel/cobalt/posix/signal.c
On 01/09/2018 03:22 AM, Henning Schild wrote:
>
> Where: somewhere in Brussels (details will follow)
>and remotely, TelCo link will be published
> When: 02.02.18 13:00-18:00 (CET)
I will try to attend via teleconference.
___
Xenomai mailing li
On 02/08/2018 12:32 PM, Greg Gallagher wrote:
> geared towards Zynq but they can be generalized. Once I get these
> raspberry pi images to a point where I can share, I'd be happy to work
> with someone on gearing some of the getting started material towards
> raspberry pi.
Which pi boards are yo
On Wed, May 16, 2018, at 11:13 AM, Auel, Kendall wrote:
> I'm trying to build a xenomai-enabled kernel for an arm64 (quad A53
> cores). Something is not configured correctly, but I haven't been able
> to get past a stall during xenomai_init. Any ideas on what I'm doing
> wrong? Thanks.
>
> [
On 05/20/2018 08:07 AM, Philippe Gerum wrote:
> On 05/18/2018 06:24 PM, Singh, Raman wrote:
>> Environment: ARM Cortex-A53 quad-core processor (ARM 64-bit) on a
>> Zynq Ultrascale+ ZCU102 dev board, Xenomai 3 next branch from May
>> 14, 2018 (SHA1: 410a4cc1109ba4e0d05b7ece7b4a5210287e1183 ),
>> C
On 05/18/2018 12:00 AM, Jan Kiszka wrote:
> On 2018-05-17 04:13, Dmitriy Cherkasov wrote:
>> On Wed, May 16, 2018, at 11:13 AM, Auel, Kendall wrote:
>>> I'm trying to build a xenomai-enabled kernel for an arm64 (quad A53
>>> cores). Something is not configured co
On 06/25/2018 11:19 PM, Philippe Gerum wrote:
> On 06/26/2018 03:32 AM, gengdongjiu wrote:
>> Sorry for the noise, I see you just merge to "ipipe-arm"
>> project(https://gitlab.denx.de/Xenomai/ipipe-arm).
>> the ipipe-arm64" project also needs this patch, because arm arch timer
>> driver is used
Serialize accesses to the fpsimd so as to allow co-kernel activities
(e.g. tasks) running in the head domain to share the unit with the
host kernel.
---
arch/arm64/kernel/fpsimd.c | 138 -
1 file changed, 123 insertions(+), 15 deletions(-)
diff --git a/
cobalt/arm64: add basic FPU support (2015-09-24 12:04:42 -0700)
--------
Dmitriy Cherkasov (1):
cobalt/arm64: add basic FPU support
kernel/cobalt/arch/arm64/Kconfig | 2 +-
.../cobalt/arch/arm64/include/a
l. As far as I can tell,
the FPU in Linux is always on for arm64. This is in contrast to armv7,
where it was okay to return to the kernel with FPU traps enabled.
-Dmitriy
On 09/25/2015 08:02 AM, Gilles Chanteperdrix wrote:
On Thu, Sep 24, 2015 at 12:39:38PM -0700, Dmitriy Cherkasov wrote:
On Sat, Sep 26, 2015 at 4:24 AM, Gilles Chanteperdrix <
gilles.chanteperd...@xenomai.org> wrote:
>
> Ok, I feel I have not been completely clear. There are three
> questions:
>
> - whether every context switch should switch the fpu context: your
> answer is yes, my answer is no: simply remove the
On 09/29/2015 05:54 AM, Jorge Ramirez Ortiz wrote:
On 09/28/2015 08:12 PM, Gilles Chanteperdrix wrote:
On Mon, Sep 28, 2015 at 04:57:28PM -0700, Dmitriy Cherkasov wrote:
Ok, this page:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0024a/CJHECGIH.html
seems to indicate that
ef3ddd26d4ceb2ceec22e0df996e1215ea9935d5:
cobalt/arm64: add lazy FPU switching (2015-10-01 16:42:56 -0700)
Dmitriy Cherkasov (3):
cobalt/arm64: add basic FPU support
cobalt/arm64: fix fpu exception names
cobalt/arm64: add
37d9698b827c664027180a07f151346d0979e7d6:
cobalt/arm64: FPU code cleanup (2015-10-02 13:03:38 -0700)
Dmitriy Cherkasov (4):
cobalt/arm64: add basic FPU support
cobalt/arm64: fix fpu exception names
cobalt/arm64: add lazy
On arm64, running the included switchtest program hits the default
system heap limit of 256k.
The program creates 97 threads, each allocating space on the system heap
for struct cobalt_thread (3616 bytes on arm64). This adds up to a total
of 350725 bytes required.
This patch increases the de
Hello.
We are seeing a possible SMP bug on arm64. When running the attached test
program on the 410c board, the following message appears, usually followed
by a complete lockup:
Message from syslogd@linaro-developer at Jul 3 18:51:00 ...
kernel:[ 284.102490] NMI watchdog: BUG: soft lockup - CPU#
Hello,
I have noticed that when Xenomai is running on an arm64 platform that uses
the arm architected timer, a spurious timer tick can occur.
Here is a patch to observe it:
diff --git a/drivers/clocksource/arm_arch_timer.c
b/drivers/clocksource/arm_arch_timer.c
index 51230ee7..4a91ce6 10064
Hello folks,
What is the status of kernel entry/exit tracing on arm64? I found two posts
on the mailing list with patches to enable this, but the titles seem to
imply that the patchset as posted is incomplete (Patch 1/2, patch 1/3).
Can someone please clarify?
Relevant posts:
http://www.xeno
Do you see any problem in my configuration, or is it a bug? Please, do
not hesitate to ask me more information if needed. I am trying to
understand the problem, but with no success for now.
I can confirm that this is a bug. The fpsimd switch mechanism on the
Xenomai side does not work correct
Do you know if there is a workaround? Maybe a previous version of
ipipe/linux (where to find it ?)?
For now I think the most stable fpsimd support is in the 3.18 kernel, which
can be found in Jorge's hikey port here:
http://git.xenomai.org/ipipe-jro.git/
And here is the Xenomai side to go
My condolences to the community, as well as his friends and family. This is
very sad news indeed, and he will be missed. In my interactions with him,
he was patient, helpful, and clearly a very intelligent person.
Thank you Gilles, for all your help.
Dmitriy
__
On 09/06/2016 09:02 AM, BREGARDIS Cedric wrote:
Here are other options I could imagine:
1 - Contain the bug. Will I meet the floating point context saving
problem if the xenomai application do not switch to the Linux
Domain? Maybe the floating point problem only occur in certain
conditions that
The script name was being output as "$me" when run with --help.
---
scripts/ipipe/genpatches.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/ipipe/genpatches.sh b/scripts/ipipe/genpatches.sh
index 9392a41..07b6cf3 100755
--- a/scripts/ipipe/genpatches.sh
+++ b/sc
This adds the clocksource and GIC drivers to the arm64 patch.
---
scripts/ipipe/genpatches.sh | 3 +++
1 file changed, 3 insertions(+)
diff --git a/scripts/ipipe/genpatches.sh b/scripts/ipipe/genpatches.sh
index 07b6cf3..e2846a4 100755
--- a/scripts/ipipe/genpatches.sh
+++ b/scripts/ipipe/genpatc
On 02/07/2017 12:32 AM, Philippe Gerum wrote:
This patch would break the ARM32 side. This is an associative array
shared by all archs. The logic of genpatches.sh needs significant rework
for handling the case of driver code shared by multiple archs.
Ah yes, I see what you mean. I'll take anot
Previous versions of genpatches.sh only allow one architecture
per driver. Since some drivers are shared between arm and arm64,
this adds new functionality to the script, allowing multiple
architectures to be specified per driver as a space-separated list.
---
scripts/ipipe/genpatches.sh | 37
Previous versions of genpatches.sh only allow one architecture
per driver. Since some drivers are shared between arm and arm64,
this adds new functionality to the script, allowing multiple
architectures to be specified per driver as a space-separated list.
Signed-off-by: Dmitriy Cherkasov
This adds support for properly generating arm64 patches.
Signed-off-by: Dmitriy Cherkasov
---
scripts/ipipe/genpatches.sh | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/scripts/ipipe/genpatches.sh b/scripts/ipipe/genpatches.sh
index 4c21c9c..3714c1b 100755
--- a
Hi,
I've noticed that if I have XENO_OPT_DEBUG=y and XENO_OPT_DEBUG_LOCKING=n,
I get build errors with an undefined reference to `xnlock_stats'.
In the Kconfig, XENO_OPT_DEBUG_LOCKING is enabled by default for SMP and
XENO_OPT_DEBUG, but there is no hard dependency.
The use case here is if
Update: Only happens on incremental build. Running a "make clean" fixed it.
-Dmitriy
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai
37 matches
Mail list logo
