Philippe Gerum wrote on 29/04/2022 17:29:>
Giulio Moro via Xenomai writes:
Hi everyone,
From /proc/xenomai/sched/stat I infer there must be an internal struct
somewhere keeping track of how much CPU time is actually used by each
thread. Is there any way to access this kind of statistics f
Hi everyone,
From /proc/xenomai/sched/stat I infer there must be an internal struct
somewhere keeping track of how much CPU time is actually used by each thread.
Is there any way to access this kind of statistics from a running Xenomai user
space program without leaving primary mode and without
What you are missing is also :opt-xenomai-next.yml because 5.4 requires
Yes! This worked:
kas-container build
kas.yml:board-beagle-bone-black.yml:opt-xenomai-next.yml:opt-linux-latest-5.4.yml
Then I checked out c6fafd0b83752c529483f7ba3a4277d02ce6aace (wip/dovetail) and
attempted:
kas-c
From: Giulio Moro
Signed-off-by: Giulio Moro
---
recipes-kernel/linux/linux-xenomai_latest.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/recipes-kernel/linux/linux-xenomai_latest.bb
b/recipes-kernel/linux/linux-xenomai_latest.bb
index bbec6b0..e6834fd 100644
--- a/rec
Hi there,
I tried building this with:
kas-container build
kas.yml:board-beagle-bone-black.yml:opt-linux-latest-5.4.yml
(not sure if that's the right syntax to get 5.4 ... I had to second guess it)
but it errors. I think the relevant error is:
AR kernel/printk/built-in.a
CC kern
The easiest way is to boot without sd card, login, and then
sudo su
dd if=/dev/zero of=/dev/mmcblk1 bs=1024k count=100
This should make the eMMC unbootable and so boot from SD. Otherwise you can
give power while holding down the USER button every time.
From: Xeno
I should have mentioned that you can also build an Isar image for the BBB with
Xenomai from here https://gitlab.denx.de/Xenomai/xenomai-images
Giulio Moro wrote:
You can download a working Debian image with Xenomai that runs on BB here
https://github.com/BelaPlatform/bela-image-builder/release
You can download a working Debian image with Xenomai that runs on BB here
https://github.com/BelaPlatform/bela-image-builder/releases
This contains Linux 4.14.108-ti-xenomai-r135 with Xenomai 3.0.10
The kernel is built from this branch
https://github.com/RobertCNelson/ti-linux-kernel-dev/tree/t
Hi Fred,
See here for an example of a rtdm driver that receives interrupts from the PRU:
https://github.com/BelaPlatform/rtdm_pruss_irq/blob/master/rtdm_pruss_irq.c
with ioctl you can set up the interrupts and route them through the interrupt
channels and export them to the ARM interrupt contr
A previous conversation on the topic can be found here
https://xenomai.org/pipermail/xenomai/2017-October/037758.html
Jan Leupold via Xenomai wrote:
> I just realised that not locking the mutex for pthread_cond_signal() is not
> a good practice
I don't necessarily agree with this. There are case
danwe wrote:
> I'm sorry I forgot to say that I was using Xenomai 2 with RTnet on top. I
> think RTnet is the problem isn't it? What exactly does RTnet to stop using
> mini usb port?
>
> Kind regards
>
> Daniel
You surely cannot use RTnet on that port, if that is what you are asking,
because
It definitely is possible. Our image allows that
https://github.com/BelaPlatform/bela-image-builder/releases .
When you log in via serial, what is the result of `lsusb` ? Can you see the two
USB interfaces?
If not, are they enabled in the device tree? Are the USB drivers compiled in
your kernel
we use this one for 4.14
https://github.com/RobertCNelson/ti-linux-kernel-dev/tree/ti-linux-xenomai-4.14.y
(and the 4.4 branch there for 4.4). These are scripts to "rebuild a kernel":
it checks out the appropriate vendor (TI) branch, and merges the corresponding
ipipe patches in.
Known issues
Hi there,
apologies if this has been discussed before.
In an older thread on this mailing list there was a link to
http://git.xenomai.org/ipipe-arm.git/commit/?id=63b8ee7f25b73547ac8eff7a6be5b587422015ca
, but the correct url is now
https://gitlab.denx.de/Xenomai/ipipe-arm/commit/63b8ee7f25b735
Hi there,
booting a 4.14.94-ti kernel with Cobalt 3.0.8 from the "stable/v3.0.x" branch,
on an am3358 (PocketBeagle) I get a warning during boot "irqchip tps65217 is
not pipeline-safe!". The tps65217 is the power-management IC for the board.
What does this message mean exactly? Is it something t
Hi there,
I have my kernel (4.4.113-ti-xenomai-r149 on BeagleBone BlacK) compiled with
CONFIG_XENO_OPT_WATCHDOG=y
CONFIG_XENO_OPT_WATCHDOG_TIMEOUT=4
I would like to experience the breeze of running without watchdog, to see what
the bare-metal performance of the board are, removing the overhead o
>Date: Fri, 18 Jan 2019 11:48:12 +0800 (CST)
>From: 张建昆
>The system freeze when interrupt is triggered. I clone ipipe-arm master,
> and use xenomai 3.0.8 following xenomai startup tutorial.
>The hardware cpu is am3358. System works fine after start up, but the system
>immediately locks up wh
o: Giulio Moro; Xenomai@xenomai.org
Subject: Re: "cheap", RT-safe way of detecting if a thread is Xenomai or Linux
On 13.01.19 10:33, Giulio Moro via Xenomai wrote:
> Hi all,
> is there a "cheap", RT-safe call that can be made in order to find out if the
> current thread is
Hi all,
is there a "cheap", RT-safe call that can be made in order to find out if the
current thread is a Xenomai thread or a Linux thread? Also, to detect whether
the Xenomai thread is in primary or secondary mode?
It seems that cobalt_thread_mode() gives some (all?) of these details. Is it
RT
Also, it may be worth pointing out in the docs that SCHED_SPORADIC, SCHED_TP,
SCHED_QUOTA need kernel support ( the docs already mention something about
kernel support for SCHED_WEAK).
Giulio
From: Xenomai on behalf of Giulio Moro via
Xenomai
Sent
The docs for sched_setscheduler_ex() [1] and pthread_setscheparam_ex()[2]
claim that among the valid values for policy there is "SCHED_NORMAL"
however, SCHED_NORMAL is not provided by any of the Xenomai headers, so you get
a compile-time error.
[1]
https://xenomai.org/documentation/xenomai-3
>From 398a77d3d172c10cda9826a7cc2a15266ff4c6a9 Mon Sep 17 00:00:00 2001
From: Giulio Moro
Date: Sat, 10 Nov 2018 20:23:10 +
Subject: [PATCH] Rename __clz to xenomai_count_leading_zeros.
This is to avoid namespace conflicts (e.g.: with Clang's arm_acle.h)
Signed-off-by: Giulio Moro
---
incl
>From de7bf8033570f15b68b00b6386097ceb8a402d6b Mon Sep 17 00:00:00 2001
From: Giulio Moro
Date: Tue, 20 Nov 2018 22:32:00 +
Subject: [PATCH] Rename __clz to xenomai_count_leading_zeros to avoid
namespace conflicts (e.g.: with Clang's arm_acle.h)
Signed-off-by: Giulio Moro
---
include/boile
> Why not solving the namespace clash the simplest way by renaming the
> offending stuff in boilerplate/compiler.h? __clz and friends are
> definitely not part of the public interface, so you only have to care
> about in-tree users. __clz could be renamed as count_leading_zeroes()
> without affecti
right, digging deeper into the issue, ARM says that if the __ARM_ACLE macro is
defined by the compiler, then it's safer to include `arm_acle.h`, which will
define __clz() as a function, so a better approach could be perhaps:
#ifdef __ARM_ACLE
#include
#else
#define __clz(__v)\
//
I have clang 3.9.1 (on Debian Stretch) on armv7.
the below minimal program clz-test.c:
```
#include
#include
int main()
{
return __clz(0);
}
```
will fail to build when compiled with
`clang -I/usr/xenomai/include/cobalt -I/usr/xenomai/include clz-test.c` , as
follows:
```
In file inclu
26 matches
Mail list logo
