Re: [xenomai-images][PATCH 1/2] linux-xenomai: Fix arm/arm64 latest branches, add 5.4 option

[Greg Gallagher via Xenomai]

On Mon, Feb 8, 2021 at 3:49 PM Jan Kiszka via Xenomai 
wrote:

> From: Jan Kiszka 
>
> ipipe/master was no longer tracking the latest arm/arm64 I-pipe
> versions.
>
> While at it, add the new 5.4 branches.
>
> Signed-off-by: Jan Kiszka 
> ---
>  recipes-kernel/linux/linux-xenomai_latest.bb | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/recipes-kernel/linux/linux-xenomai_latest.bb
> b/recipes-kernel/linux/linux-xenomai_latest.bb
> index f7d9e1b..9dd4c93 100644
> --- a/recipes-kernel/linux/linux-xenomai_latest.bb
> +++ b/recipes-kernel/linux/linux-xenomai_latest.bb
> @@ -26,10 +26,10 @@ GIT_REPO_amd64 = "${@'ipipe.git' if is_xeno_3_0(d)
> else 'ipipe-x86.git'}"
>  GIT_BRANCH_amd64 = "${@'ipipe-4.4.y-cip' if is_xeno_3_0(d) else
> 'ipipe-x86-5.4.y' if is_5_4_branch(d) else 'ipipe-x86-4.19.y-cip'}"
>
>  GIT_REPO_armhf = "${@'ipipe.git' if is_xeno_3_0(d) else 'ipipe-arm.git'}"
> -GIT_BRANCH_armhf = "${@'ipipe-4.4.y-cip' if is_xeno_3_0(d) else
> 'ipipe/master'}"
> +GIT_BRANCH_armhf = "${@'ipipe-4.4.y-cip' if is_xeno_3_0(d) else
> 'ipipe/5.4.y' if is_5_4_branch(d) else 'ipipe/4.19-y-cip'}"
>
>  GIT_REPO_arm64 = "ipipe-arm64.git"
> -GIT_BRANCH_arm64 = "ipipe/master"
> +GIT_BRANCH_arm64 = "${@'ipipe/5.4.y' if is_5_4_branch(d) else
> 'ipipe/4.19.y-cip'}"
>
>  SRC_URI += "git://
> github.com/xenomai-ci/${GIT_REPO};protocol=https;branch=${GIT_BRANCH}
> 
> "
>  SRCREV = "${AUTOREV}"
> --
> 2.26.2
>

Thanks for updating this

-Greg

>
>

[xenomai-images][PATCH 1/2] linux-xenomai: Fix arm/arm64 latest branches, add 5.4 option

[Jan Kiszka via Xenomai]

From: Jan Kiszka 

ipipe/master was no longer tracking the latest arm/arm64 I-pipe
versions.

While at it, add the new 5.4 branches.

Signed-off-by: Jan Kiszka 
---
 recipes-kernel/linux/linux-xenomai_latest.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-kernel/linux/linux-xenomai_latest.bb 
b/recipes-kernel/linux/linux-xenomai_latest.bb
index f7d9e1b..9dd4c93 100644
--- a/recipes-kernel/linux/linux-xenomai_latest.bb
+++ b/recipes-kernel/linux/linux-xenomai_latest.bb
@@ -26,10 +26,10 @@ GIT_REPO_amd64 = "${@'ipipe.git' if is_xeno_3_0(d) else 
'ipipe-x86.git'}"
 GIT_BRANCH_amd64 = "${@'ipipe-4.4.y-cip' if is_xeno_3_0(d) else 
'ipipe-x86-5.4.y' if is_5_4_branch(d) else 'ipipe-x86-4.19.y-cip'}"
 
 GIT_REPO_armhf = "${@'ipipe.git' if is_xeno_3_0(d) else 'ipipe-arm.git'}"
-GIT_BRANCH_armhf = "${@'ipipe-4.4.y-cip' if is_xeno_3_0(d) else 
'ipipe/master'}"
+GIT_BRANCH_armhf = "${@'ipipe-4.4.y-cip' if is_xeno_3_0(d) else 'ipipe/5.4.y' 
if is_5_4_branch(d) else 'ipipe/4.19-y-cip'}"
 
 GIT_REPO_arm64 = "ipipe-arm64.git"
-GIT_BRANCH_arm64 = "ipipe/master"
+GIT_BRANCH_arm64 = "${@'ipipe/5.4.y' if is_5_4_branch(d) else 
'ipipe/4.19.y-cip'}"
 
 SRC_URI += 
"git://github.com/xenomai-ci/${GIT_REPO};protocol=https;branch=${GIT_BRANCH}"
 SRCREV = "${AUTOREV}"
-- 
2.26.2

[xenomai-images][PATCH 2/2] ci: Add 5.4 kernels targets for arm and arm64

[Jan Kiszka via Xenomai]

From: Jan Kiszka 

Signed-off-by: Jan Kiszka 
---
 ci/kernel_5_4_xenomai_next.yml | 52 ++
 1 file changed, 52 insertions(+)

diff --git a/ci/kernel_5_4_xenomai_next.yml b/ci/kernel_5_4_xenomai_next.yml
index 4d366dc..1092aea 100644
--- a/ci/kernel_5_4_xenomai_next.yml
+++ b/ci/kernel_5_4_xenomai_next.yml
@@ -22,6 +22,58 @@ lava-test-5.4:qemu-amd64:
 DEPLOY_DIR_EXTENSION: "5.4"
 BUILD_IDENTIFIER: "5.4"
 
+build-5.4:board-qemu-armhf:
+  extends: .build:board-qemu-armhf
+  variables:
+LINUX_BUILD_OPTION: ":opt-linux-latest-5.4.yml"
+DEPLOY_DIR_EXTENSION: "5.4"
+
+lava-test-5.4:qemu-armhf:
+  needs: [ "build-5.4:board-qemu-armhf" ]
+  extends: .lava-test:qemu-armhf
+  variables:
+DEPLOY_DIR_EXTENSION: "5.4"
+BUILD_IDENTIFIER: "5.4"
+
+build-5.4:board-qemu-arm64:
+  extends: .build:board-qemu-arm64
+  variables:
+LINUX_BUILD_OPTION: ":opt-linux-latest-5.4.yml"
+DEPLOY_DIR_EXTENSION: "5.4"
+
+lava-test-5.4:qemu-arm64:
+  needs: [ "build-5.4:board-qemu-arm64" ]
+  extends: .lava-test:qemu-arm64
+  variables:
+DEPLOY_DIR_EXTENSION: "5.4"
+BUILD_IDENTIFIER: "5.4"
+
+build-5.4:board-hikey:
+  extends: .build:board-hikey
+  variables:
+LINUX_BUILD_OPTION: ":opt-linux-latest-5.4.yml"
+DEPLOY_DIR_EXTENSION: "5.4"
+
+lava-test-5.4:board-hikey:
+  needs: [ "build-5.4:board-hikey" ]
+  extends: .lava-test:board-hikey
+  variables:
+DEPLOY_DIR_EXTENSION: "5.4"
+BUILD_IDENTIFIER: "5.4"
+
+build-5.4:board-beagle-bone-black:
+  extends: .build:board-beagle-bone-black
+  variables:
+LINUX_BUILD_OPTION: ":opt-linux-latest-5.4.yml"
+DEPLOY_DIR_EXTENSION: "5.4"
+
+lava-test-5.4:board-beagle-bone-black:
+  needs: [ "build-5.4:board-beagle-bone-black" ]
+  extends: .lava-test:board-beagle-bone-black
+  variables:
+DEPLOY_DIR_EXTENSION: "5.4"
+BUILD_IDENTIFIER: "5.4"
+
 build-5.4:board-x86-64-efi:
   extends: .build:board-x86-64-efi
   variables:
-- 
2.26.2

Re: [PATCH 09/18] cobalt/thread: dovetail: define out-of-band state accessors

[Jan Kiszka via Xenomai]

On 07.02.21 17:04, Philippe Gerum wrote:
> From: Philippe Gerum 
> 
> Signed-off-by: Philippe Gerum 
> ---
>  .../cobalt/kernel/dovetail/pipeline/thread.h  | 27 +++
>  1 file changed, 27 insertions(+)
>  create mode 100644 include/cobalt/kernel/dovetail/pipeline/thread.h
> 
> diff --git a/include/cobalt/kernel/dovetail/pipeline/thread.h 
> b/include/cobalt/kernel/dovetail/pipeline/thread.h
> new file mode 100644
> index 0..1e6b0f091
> --- /dev/null
> +++ b/include/cobalt/kernel/dovetail/pipeline/thread.h
> @@ -0,0 +1,27 @@
> +/*
> + * SPDX-License-Identifier: GPL-2.0
> + *
> + * Copyright (C) 2019 Philippe Gerum  
> + */
> +
> +#ifndef _COBALT_KERNEL_DOVETAIL_THREAD_H
> +#define _COBALT_KERNEL_DOVETAIL_THREAD_H
> +
> +#include 
> +
> +struct xnthread;
> +
> +#define cobalt_threadinfo oob_thread_state
> +
> +static inline struct cobalt_threadinfo *pipeline_current(void)
> +{
> + return dovetail_current_state();
> +}
> +
> +static inline
> +struct xnthread *pipeline_thread_from_task(struct task_struct *p)
> +{
> + return dovetail_task_state(p)->thread;
> +}
> +
> +#endif /* !_COBALT_KERNEL_DOVETAIL_THREAD_H */
> 

Applied up to here to next.

Thanks,
Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [PATCH 10/18] cobalt/timer: ipipe: directly use the abstract interface for IPIs

[Jan Kiszka via Xenomai]

On 07.02.21 17:04, Philippe Gerum wrote:
> From: Philippe Gerum 
> 
> Signed-off-by: Philippe Gerum 
> ---
>  kernel/cobalt/ipipe/tick.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/cobalt/ipipe/tick.c b/kernel/cobalt/ipipe/tick.c
> index da1563a66..b711bedc0 100644
> --- a/kernel/cobalt/ipipe/tick.c
> +++ b/kernel/cobalt/ipipe/tick.c
> @@ -187,7 +187,7 @@ int pipeline_install_tick_proxy(void)
>   nkclock.wallclock_offset =
>   ktime_to_ns(ktime_get_real()) - 
> xnclock_read_monotonic();
>  
> - ret = xntimer_setup_ipi();
> + ret = pipeline_request_timer_ipi(xnintr_core_clock_handler);

Ah, here we change this to the suboptimal pattern: Just fold that
implementation in here.

We should try to reduce needless static inlines.

>   if (ret)
>   return ret;
>  
> @@ -244,7 +244,7 @@ fail:
>   ipipe_timer_stop(_cpu);
>   }
>  
> - xntimer_release_ipi();
> + pipeline_free_timer_ipi();
>  
>   return ret;
>  }
> @@ -270,7 +270,7 @@ void pipeline_uninstall_tick_proxy(void)
>   for_each_realtime_cpu(cpu)
>   ipipe_timer_stop(cpu);
>  
> - xntimer_release_ipi();
> + pipeline_free_timer_ipi();
>  
>  #ifdef CONFIG_XENO_OPT_STATS_IRQS
>   xnintr_destroy();
> 

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [PATCH 12/18] cobalt/tick: dovetail: add placeholders for tick management

[Jan Kiszka via Xenomai]

On 07.02.21 17:04, Philippe Gerum wrote:
> From: Philippe Gerum 
> 
> Signed-off-by: Philippe Gerum 
> ---
>  .../cobalt/kernel/dovetail/pipeline/tick.h| 12 +
>  kernel/cobalt/dovetail/Makefile   |  2 +-
>  kernel/cobalt/dovetail/tick.c | 45 +++
>  3 files changed, 58 insertions(+), 1 deletion(-)
>  create mode 100644 include/cobalt/kernel/dovetail/pipeline/tick.h
>  create mode 100644 kernel/cobalt/dovetail/tick.c
> 
> diff --git a/include/cobalt/kernel/dovetail/pipeline/tick.h 
> b/include/cobalt/kernel/dovetail/pipeline/tick.h
> new file mode 100644
> index 0..409581a3c
> --- /dev/null
> +++ b/include/cobalt/kernel/dovetail/pipeline/tick.h
> @@ -0,0 +1,12 @@
> +/*
> + * SPDX-License-Identifier: GPL-2.0
> + */
> +
> +#ifndef _COBALT_KERNEL_IPIPE_TICK_H
> +#define _COBALT_KERNEL_IPIPE_TICK_H
> +
> +int pipeline_install_tick_proxy(void);
> +
> +void pipeline_uninstall_tick_proxy(void);
> +
> +#endif /* !_COBALT_KERNEL_IPIPE_TICK_H */
> diff --git a/kernel/cobalt/dovetail/Makefile b/kernel/cobalt/dovetail/Makefile
> index 24320b3f2..84788f9ce 100644
> --- a/kernel/cobalt/dovetail/Makefile
> +++ b/kernel/cobalt/dovetail/Makefile
> @@ -2,4 +2,4 @@ ccflags-y += -I$(srctree)/kernel
>  
>  obj-y += pipeline.o
>  
> -pipeline-y :=init.o kevents.o sched.o
> +pipeline-y :=init.o kevents.o sched.o tick.o
> diff --git a/kernel/cobalt/dovetail/tick.c b/kernel/cobalt/dovetail/tick.c
> new file mode 100644
> index 0..02cd86690
> --- /dev/null
> +++ b/kernel/cobalt/dovetail/tick.c
> @@ -0,0 +1,45 @@
> +/*
> + * SPDX-License-Identifier: GPL-2.0
> + *
> + * Copyright (C) 2001,2002,2003,2007,2012 Philippe Gerum .
> + * Copyright (C) 2004 Gilles Chanteperdrix 
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +extern struct xnintr nktimer;
> +
> +int pipeline_install_tick_proxy(void)
> +{
> + int ret;
> +
> + ret = pipeline_request_timer_ipi(xnintr_core_clock_handler);

Why calling an abstraction here? We know that we are in dovetail land.

I know we do the same on ipipe already. But maybe fix that first and
avoid this over-abstraction here in the first place.

> + if (ret)
> + return ret;
> +
> + /* Install the proxy tick device */
> + TODO(); ret = 0;
> + if (ret)
> + goto fail_proxy;
> +
> + return 0;
> +
> +fail_proxy:
> + pipeline_free_timer_ipi();
> +
> + return ret;
> +}
> +
> +void pipeline_uninstall_tick_proxy(void)
> +{
> + /* Uninstall the proxy tick device. */
> + TODO();
> +
> + pipeline_free_timer_ipi();
> +
> +#ifdef CONFIG_XENO_OPT_STATS_IRQS
> + xnintr_destroy();
> +#endif /* CONFIG_XENO_OPT_STATS_IRQS */
> +}
> 

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: Announce RTnet on PREEMPT_RT Linux

[Jan Kiszka via Xenomai]

On 08.02.21 15:45, Laurentiu-Cristian Duca via Xenomai wrote:
> Dear friends,
> 
>   Please let me announce the port of the RTnet core on PREEMPT_RT Linux 5.9.
>   Features:
> - ported raspberry pi 4 (bcmgenet), orange pi one (stmmac),
> realtek (8139too), ticpsw (beaglebone black), microchip (enc28j60)
> - rtnet UDP socket, bind, recvmsg, sendto, recvfrom, sendmsg, select,
> poll system calls;
> - sockets with AF_INET (UDP) or AF_PACKET (raw) family;
> - rtnetproxy for ssh and scp (but uses RT driver bandwidth)
> 
>   The project is available on my github [1].
> I've made the code available although it needs some polishing.
> 
> Best regards,
> L-C. Duca
> 
> [1] https://github.com/laurentiuduca/rtnet-preempt_rt
> 

Thanks for sharing!

Very interesting to see this direction while people are (validly)
concerned about maintaining the driver forks that RTnet implies. Can you
share your motivation for and plans with this work?

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: several questions about porting latmus

[Philippe Gerum via Xenomai]

Chen, Hongzhan  writes:

> Chen, Hongzhan  writes:
>>
>>> -Original Message-
From: Philippe Gerum  
Sent: Monday, February 8, 2021 12:21 AM
To: Chen, Hongzhan 
Cc: xenomai@xenomai.org
Subject: Re: several questions about porting latmus


Chen, Hongzhan  writes:

>>-Original Message-
>>From: Philippe Gerum  
>>Sent: Monday, February 1, 2021 5:31 PM
>>To: Chen, Hongzhan 
>>Cc: xenomai@xenomai.org
>>Subject: Re: several questions about porting latmus
>>
>>
>>Hi Hongzhan,
>>
>>Chen, Hongzhan  writes:
>>
>>> Hi Philippe
>>>
>>> When I was trying to port latmus from evl to xenomai 3.2,  I met 
>>> several issues that block porting
>>> and need your suggestions.
>>>
>>> 1. When I tried to replace function evl_run_kthread_on_cpu of latmus.c 
>>> driver ,  I found that only rtdm_task_init  
>>> can meet our requirements mostly  but we still cannot pass cpu 
>>> affinity through it to pin task to required
>>> cpu. Do we need to implement new API so that we can  pass cpu 
>>> affinity to pin task to required cpu but
>>> finish all functions  of rtdm_task_init?
>>>
>>
>>We should probably introduce rtdm_task_init_on_cpu() in 3.2, since this
>>is a desirable feature which should be part of the CXP. Other ways to
>>pin the new kthread are fairly ugly ATM, ranging from pinning the parent
>>to the destination CPU before creating the child thread, or open coding
>>the spawning sequence based on the internal interface (xnthread_init,
>>xnthread_start). Please submit a patch for review of that change
>>specifically, prior to submitting any latmus-related bits.
>>
>
> OK.  I have finished latmus driver porting so far and built it 
> successfully with linux.
> In the following , I would  start to port latmus application. After 
> latmus application is done,
> I would validate all of them and then will try to submit patches to 
> review after validation 
> is successful. 
>

With respect to the timer responder test, the latmus application is
based on EVL's built-in timerfd [1] feature, which is very close to the
Cobalt/POSIX equivalent, so the port should be straightforward.

Things may be a little trickier with the GPIO responder test, as Cobalt
needs a specific RTDM driver to operate the GPIO lines (EVL reuses the
common GPIOLIB for this [2], so do not look for any specific driver
here). It depends on the GPIO controller you will test on. You will
certainly need to add support for it to kernel/drivers/gpio.

Which hardware do you plan to use?
>>>
>>> Currently , I am working on up xtream Lite board which is based on
>>> Intel Whiskey Lake.  Yes,  I need to add new GPIO controller rtdm driver
>>> under kernel/drivers/gpio for my board after further investigated, thanks 
>>> for your soft reminder. 
>>>
>>> I have almost finished latmus application porting and validated that latmus 
>>> driver is 
>>> working but I still have not got Freedom-K64F so far.  So the gpio test
>>> environment can not be setup in short time because of lack of hardware on 
>>> my side.
>>>
>>
>>There is also the option of making benchmarks/zephyr/latmon a Xenomai
>>application, which would act as the latency monitor running on a
>>separate Linux board. Xenomai would then help testing Xenomai which
>>might not be optimal at first glance, however this should be ok
>>nevertheless provided that such monitoring board runs a known to be
>>stable I-pipe configuration.
>>
>
> One more question,  I saw that rtdm gpio driver can call rtdm_gpiochip_scan_of
> to do init currently but actually rtdm_gpiochip_scan_of do call 
> of_find_compatible_node
> to find device node, It is workable for those devices registered through ACPI 
> table?
> If not , does that means we need to add new API to implement analogous 
> function for those
> gpio pinctrl devices registered by ACPI?
>

gpiochip_find() is available to non-OF systems as well; what gets
enumerated by the platform code ends up being registered in the gpiolib
device list.

The idea is to match by name the type of controller which is expected on
your platform with the gpio chips enumerated by gpiochip_find(). You may
want to add some generic helper to gpio-core.c doing that for non-OF
platforms, which you would call from additional controller-specific RTDM
modules (those which would define more GPIO device subclasses,
i.e. RTDM_SUBCLASS_xx).

-- 
Philippe.

[PATCH] ci: Improve PIPELINE_REV matching rule

[Jan Kiszka via Xenomai]

From: Jan Kiszka 

Allows filtering on 'dovetail/master' e.g.

Signed-off-by: Jan Kiszka 
---
 .gitlab-ci.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 83a8247c72..ad13942f89 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -35,7 +35,7 @@ variables:
 - update-alternatives --install /usr/bin/aarch64-linux-gnu-gcc 
aarch64-linux-gnu-gcc /usr/bin/aarch64-linux-gnu-gcc-8 800
 - update-alternatives --install /usr/bin/arm-linux-gnueabihf-gcc 
arm-linux-gnueabihf-gcc /usr/bin/arm-linux-gnueabihf-gcc-8 800
 - update-alternatives --install /usr/bin/powerpc-linux-gnu-gcc 
powerpc-linux-gnu-gcc /usr/bin/powerpc-linux-gnu-gcc-8 800
-- REV=$(git ls-remote --tags --head --refs ${PIPELINE_KERNEL} | sed -e 
"s|.*[[:space:]]refs/.*/||" | grep "${PIPELINE_REV}" | sort -r -n -t - -k 5 -k 
6 | head -1)
+- REV=$(git ls-remote --tags --head --refs ${PIPELINE_KERNEL} | sed -e 
"s/.*[[:space:]]refs\/\(tags\|heads\)\///" | grep "${PIPELINE_REV}" | sort -r 
-n -t - -k 5 -k 6 | head -1)
 - test -n "${REV}" || REV="${PIPELINE_REV}"
 - git clone --depth 1 --branch ${REV} ${PIPELINE_KERNEL} ${KDIR}
 - case "${ARCH}" in
-- 
2.26.2


-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Announce RTnet on PREEMPT_RT Linux

[Laurentiu-Cristian Duca via Xenomai]

Dear friends,

  Please let me announce the port of the RTnet core on PREEMPT_RT Linux 5.9.
  Features:
- ported raspberry pi 4 (bcmgenet), orange pi one (stmmac),
realtek (8139too), ticpsw (beaglebone black), microchip (enc28j60)
- rtnet UDP socket, bind, recvmsg, sendto, recvfrom, sendmsg, select,
poll system calls;
- sockets with AF_INET (UDP) or AF_PACKET (raw) family;
- rtnetproxy for ssh and scp (but uses RT driver bandwidth)

  The project is available on my github [1].
I've made the code available although it needs some polishing.

Best regards,
L-C. Duca

[1] https://github.com/laurentiuduca/rtnet-preempt_rt

RE: several questions about porting latmus

[Chen, Hongzhan via Xenomai]

Chen, Hongzhan  writes:
>
>> -Original Message-
>>>From: Philippe Gerum  
>>>Sent: Monday, February 8, 2021 12:21 AM
>>>To: Chen, Hongzhan 
>>>Cc: xenomai@xenomai.org
>>>Subject: Re: several questions about porting latmus
>>>
>>>
>>>Chen, Hongzhan  writes:
>>>
>-Original Message-
>From: Philippe Gerum  
>Sent: Monday, February 1, 2021 5:31 PM
>To: Chen, Hongzhan 
>Cc: xenomai@xenomai.org
>Subject: Re: several questions about porting latmus
>
>
>Hi Hongzhan,
>
>Chen, Hongzhan  writes:
>
>> Hi Philippe
>>
>> When I was trying to port latmus from evl to xenomai 3.2,  I met several 
>> issues that block porting
>> and need your suggestions.
>>
>> 1. When I tried to replace function evl_run_kthread_on_cpu of latmus.c 
>> driver ,  I found that only rtdm_task_init  
>> can meet our requirements mostly  but we still cannot pass cpu 
>> affinity through it to pin task to required
>> cpu. Do we need to implement new API so that we can  pass cpu 
>> affinity to pin task to required cpu but
>> finish all functions  of rtdm_task_init?
>>
>
>We should probably introduce rtdm_task_init_on_cpu() in 3.2, since this
>is a desirable feature which should be part of the CXP. Other ways to
>pin the new kthread are fairly ugly ATM, ranging from pinning the parent
>to the destination CPU before creating the child thread, or open coding
>the spawning sequence based on the internal interface (xnthread_init,
>xnthread_start). Please submit a patch for review of that change
>specifically, prior to submitting any latmus-related bits.
>

 OK.  I have finished latmus driver porting so far and built it 
 successfully with linux.
 In the following , I would  start to port latmus application. After latmus 
 application is done,
 I would validate all of them and then will try to submit patches to review 
 after validation 
 is successful. 

>>>
>>>With respect to the timer responder test, the latmus application is
>>>based on EVL's built-in timerfd [1] feature, which is very close to the
>>>Cobalt/POSIX equivalent, so the port should be straightforward.
>>>
>>>Things may be a little trickier with the GPIO responder test, as Cobalt
>>>needs a specific RTDM driver to operate the GPIO lines (EVL reuses the
>>>common GPIOLIB for this [2], so do not look for any specific driver
>>>here). It depends on the GPIO controller you will test on. You will
>>>certainly need to add support for it to kernel/drivers/gpio.
>>>
>>>Which hardware do you plan to use?
>>
>> Currently , I am working on up xtream Lite board which is based on
>> Intel Whiskey Lake.  Yes,  I need to add new GPIO controller rtdm driver
>> under kernel/drivers/gpio for my board after further investigated, thanks 
>> for your soft reminder. 
>>
>> I have almost finished latmus application porting and validated that latmus 
>> driver is 
>> working but I still have not got Freedom-K64F so far.  So the gpio test
>> environment can not be setup in short time because of lack of hardware on my 
>> side.
>>
>
>There is also the option of making benchmarks/zephyr/latmon a Xenomai
>application, which would act as the latency monitor running on a
>separate Linux board. Xenomai would then help testing Xenomai which
>might not be optimal at first glance, however this should be ok
>nevertheless provided that such monitoring board runs a known to be
>stable I-pipe configuration.
>

One more question,  I saw that rtdm gpio driver can call rtdm_gpiochip_scan_of
to do init currently but actually rtdm_gpiochip_scan_of do call 
of_find_compatible_node
to find device node, It is workable for those devices registered through ACPI 
table?
If not , does that means we need to add new API to implement analogous function 
for those
gpio pinctrl devices registered by ACPI?

>-- 
>Philippe.

Re: [I-PIPE] ipipe-core-5.4.72-arm64-0 released

[Jan Kiszka via Xenomai]

On 08.02.21 09:24, Jan Kiszka via Xenomai wrote:
> On 06.02.21 15:50, Greg Gallagher wrote:
>>
>>
>> On Sat, Feb 6, 2021 at 7:23 AM Jan Kiszka > > wrote:
>>
>> On 05.02.21 06:24, Greg Gallagher via Xenomai wrote:
>> > On Fri, Feb 5, 2021 at 12:24 AM xenomai--- via Xenomai
>> mailto:xenomai@xenomai.org>>
>> > wrote:
>> >
>> >> Download URL:
>> >>
>> 
>> https://xenomai.org/downloads/ipipe/v5.x/arm64/ipipe-core-5.4.72-arm64-0.patch
>> 
>> 
>> >>
>> >> Repository: https://git.xenomai.org/ipipe-arm64
>> 
>> >> Release tag: ipipe-core-5.4.72-arm64-0
>> >>
>> >>
>> > This is a beta release, any testing is welcome
>> >
>>
>> You asked for it: ;)
>>
>> https://gitlab.denx.de/Xenomai/xenomai-images/-/jobs/218159#L638
>> 
>>
>> Jan
>>
>> -- 
>> Siemens AG, T RDA IOT
>> Corporate Competence Center Embedded Linux
>>
>>
>> Ack, I’ll look into this today. How hard is it to get a ci or something
>> similar setup in a local machine? I think I may have asked this before
>> but i can’t remember what we decided.
>>
> 
> The easiest option are the qemu targets, generated and run via
> xenomai-images. Unfortunately, this issue does not seem to trigger in
> qemu, only on the BeagleBone. But if you have that board, also that
> target image can be reproduced, obviously. Follow the README in that case.
> 
> Or you just pick up the config from xenomai-images and do your own setup.
> 

Err, wrong context, this is arm64. Here it's the hikey, and only the
hikey board. For the arm issue, both qemu and bbb expose the problem.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [I-PIPE] ipipe-core-5.4.72-arm64-0 released

[Jan Kiszka via Xenomai]

On 06.02.21 15:50, Greg Gallagher wrote:
> 
> 
> On Sat, Feb 6, 2021 at 7:23 AM Jan Kiszka  > wrote:
> 
> On 05.02.21 06:24, Greg Gallagher via Xenomai wrote:
> > On Fri, Feb 5, 2021 at 12:24 AM xenomai--- via Xenomai
> mailto:xenomai@xenomai.org>>
> > wrote:
> >
> >> Download URL:
> >>
> 
> https://xenomai.org/downloads/ipipe/v5.x/arm64/ipipe-core-5.4.72-arm64-0.patch
> 
> 
> >>
> >> Repository: https://git.xenomai.org/ipipe-arm64
> 
> >> Release tag: ipipe-core-5.4.72-arm64-0
> >>
> >>
> > This is a beta release, any testing is welcome
> >
> 
> You asked for it: ;)
> 
> https://gitlab.denx.de/Xenomai/xenomai-images/-/jobs/218159#L638
> 
> 
> Jan
> 
> -- 
> Siemens AG, T RDA IOT
> Corporate Competence Center Embedded Linux
> 
> 
> Ack, I’ll look into this today. How hard is it to get a ci or something
> similar setup in a local machine? I think I may have asked this before
> but i can’t remember what we decided.
> 

The easiest option are the qemu targets, generated and run via
xenomai-images. Unfortunately, this issue does not seem to trigger in
qemu, only on the BeagleBone. But if you have that board, also that
target image can be reproduced, obviously. Follow the README in that case.

Or you just pick up the config from xenomai-images and do your own setup.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: several questions about porting latmus

[Philippe Gerum via Xenomai]

Chen, Hongzhan  writes:

> -Original Message-
>>From: Philippe Gerum  
>>Sent: Monday, February 8, 2021 12:21 AM
>>To: Chen, Hongzhan 
>>Cc: xenomai@xenomai.org
>>Subject: Re: several questions about porting latmus
>>
>>
>>Chen, Hongzhan  writes:
>>
-Original Message-
From: Philippe Gerum  
Sent: Monday, February 1, 2021 5:31 PM
To: Chen, Hongzhan 
Cc: xenomai@xenomai.org
Subject: Re: several questions about porting latmus


Hi Hongzhan,

Chen, Hongzhan  writes:

> Hi Philippe
>
> When I was trying to port latmus from evl to xenomai 3.2,  I met several 
> issues that block porting
> and need your suggestions.
>
> 1. When I tried to replace function evl_run_kthread_on_cpu of latmus.c 
> driver ,  I found that only rtdm_task_init  
> can meet our requirements mostly  but we still cannot pass cpu 
> affinity through it to pin task to required
> cpu. Do we need to implement new API so that we can  pass cpu 
> affinity to pin task to required cpu but
> finish all functions  of rtdm_task_init?
>

We should probably introduce rtdm_task_init_on_cpu() in 3.2, since this
is a desirable feature which should be part of the CXP. Other ways to
pin the new kthread are fairly ugly ATM, ranging from pinning the parent
to the destination CPU before creating the child thread, or open coding
the spawning sequence based on the internal interface (xnthread_init,
xnthread_start). Please submit a patch for review of that change
specifically, prior to submitting any latmus-related bits.

>>>
>>> OK.  I have finished latmus driver porting so far and built it successfully 
>>> with linux.
>>> In the following , I would  start to port latmus application. After latmus 
>>> application is done,
>>> I would validate all of them and then will try to submit patches to review 
>>> after validation 
>>> is successful. 
>>>
>>
>>With respect to the timer responder test, the latmus application is
>>based on EVL's built-in timerfd [1] feature, which is very close to the
>>Cobalt/POSIX equivalent, so the port should be straightforward.
>>
>>Things may be a little trickier with the GPIO responder test, as Cobalt
>>needs a specific RTDM driver to operate the GPIO lines (EVL reuses the
>>common GPIOLIB for this [2], so do not look for any specific driver
>>here). It depends on the GPIO controller you will test on. You will
>>certainly need to add support for it to kernel/drivers/gpio.
>>
>>Which hardware do you plan to use?
>
> Currently , I am working on up xtream Lite board which is based on
> Intel Whiskey Lake.  Yes,  I need to add new GPIO controller rtdm driver
> under kernel/drivers/gpio for my board after further investigated, thanks 
> for your soft reminder. 
>
> I have almost finished latmus application porting and validated that latmus 
> driver is 
> working but I still have not got Freedom-K64F so far.  So the gpio test
> environment can not be setup in short time because of lack of hardware on my 
> side.
>

There is also the option of making benchmarks/zephyr/latmon a Xenomai
application, which would act as the latency monitor running on a
separate Linux board. Xenomai would then help testing Xenomai which
might not be optimal at first glance, however this should be ok
nevertheless provided that such monitoring board runs a known to be
stable I-pipe configuration.

-- 
Philippe.