Re: undefined symbol in tests

2021-02-09 Thread Antoine Hoarau via Xenomai 
Still having this "undefined reference" issue on 3.1. Is there any news on
that ?

Le mer. 19 févr. 2020 à 13:13, Jan Kiszka  a écrit :

> On 19.02.20 13:11, Antoine Hoarau wrote:
> > Dohell does no seem to be included either. Is that normal ?
> >
>
> It is, see /usr/lib/xenomai/testsuite/dohell.
>
> Jan
>
> > Le mer. 19 févr. 2020 à 12:35, Jan Kiszka  > > a écrit :
> >
> > On 19.02.20 09:54, Jan Kiszka via Xenomai wrote:
> >  > On 18.02.20 18:45, Antoine Hoarau via Xenomai wrote:
> >  >> Le mar. 18 févr. 2020 à 12:12, Gylstorff Quirin <
> >  >> quirin.gylsto...@siemens.com
> > > a écrit :
> >  >>
> >  >>> Hi Antoine,
> >  >>>
> >  >>> On 2/18/20 12:04 AM, Antoine Hoarau via Xenomai wrote:
> >   # ldd /usr/lib/xenomai/testsuite/libalchemy-test.so
> >     linux-vdso.so.1 (0x7fff1f944000)
> >     libcobalt.so.2 => /usr/lib/libcobalt.so.2
> >   (0x7f2a40bc9000)
> >     libalchemy.so.0 => /usr/lib/libalchemy.so.0
> >   (0x7f2a409b1000)
> >     libcopperplate.so.0 => /usr/lib/libcopperplate.so.0
> >   (0x7f2a407a3000)
> >     libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
> >  >>> (0x7f2a403b2000)
> >     librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1
> >  >>> (0x7f2a401aa000)
> >     libpthread.so.0 =>
> /lib/x86_64-linux-gnu/libpthread.so.0
> >   (0x7f2a3ff8b000)
> >     /lib64/ld-linux-x86-64.so.2 (0x7f2a40ff4000)
> >  
> >  
> >   For info I added --enable-dlopen-libs
> >   As in
> > https://xenomai.org/pipermail/xenomai/2020-January/042306.html
> >  
> >   Le lun. 17 févr. 2020 à 17:51, Jan Kiszka
> > mailto:jan.kis...@siemens.com>> a
> >  >>> écrit :
> >  
> >  > On 14.02.20 15:15, Antoine Hoarau wrote:
> >  >> I just built the debians:
> >  >> debchange -v 3.1 Release 3.1
> >  >> debuild -uc -us
> >  >>
> >  >>>
> >  >>> What is the Debian version and CPU architecture of your build
> > system?A
> >  >>
> >  >>
> >  >> A very standard Ubuntu 18.04 x64.
> >  >> Debuild version 2.17.12ubuntu1.1
> >  >>
> >  >
> >  > Ah! That is surely untested as no one here is using Ubuntu
> anymore.
> >  > Will check if it's a generic or a Ubuntu-exposed issue.
> >  >
> >
> > I'm starting to understand the issue. It's likely related to
> > optimizations of library dependency done differently by the Ubuntu
> > toolchain than that of Debian 10. I think we can avoid that by adding
> > all actual deps to our libs. Playing with it...
> >
> > Jan
> >
> > --
> > Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> > Corporate Competence Center Embedded Linux
> >
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>

Re: reminder: Xenomai community call on today, Feb 10th, UTC 7:00

2021-02-09 Thread Fino Meng via Xenomai 
the meeting started.

On Wed, Feb 10, 2021 at 01:33:37AM +, Meng, Fino via Xenomai wrote:
> Sorry for the late reminder, As planned, we have the Xenomai community call
> Topics may include but not limited to upstream/downstream project plan, 
> status update, and technical discussion.
> It's an open online meeting that anyone can join and ask questions,
> 
> Time:
> Feb 10th (Wednesday), UTC 7:00
> 15:00 for China
> 8:00 for France, Germany, Italy
> 23:00 (Feb 9th ) for Santa Clara
> 
> Pls download Webex meeting software or use the webpage version:
> https://intel.webex.com/intel/j.php?MTID=m230b1d97ab4f2a4f9dbc3b262885bab6
> 
> Meeting number (access code): 130 514 7605
> Meeting password: JQpEc7UY@38  
>  
> Tap to join from a mobile device (attendees only)  
> +1-210-795-1110,,1305147605## US Toll  
> +1-866-662-9987,,1305147605## US Toll Free  
> 
> Join by phone  
> +1-210-795-1110 US Toll  
> +1-866-662-9987 US Toll Free  
> Global call-in numbers  |  Toll-free calling restrictions   
>   
> Join from a video system or application
> Dial 1305147...@intel.webex.com  
> You can also dial 173.243.2.68 and enter your meeting number.   
> 
> BR / Fino (孟祥夫)
> Intel – IOTG Developer Enabling
> 
>

RE: several questions about porting latmus

2021-02-09 Thread 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?

>>>
>>>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.
>>
>> Thanks  for your suggestions. I have f

Re: several questions about porting latmus

2021-02-09 Thread 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.
>
> Thanks  for your suggestions. I have finished implementing generic helper in 
> gpio-core.c and
> also developed new gpio rtdm driver for my board

[I-PIPE] ipipe-core-4.19.165-cip41-arm64-09 released

2021-02-09 Thread xenomai--- via Xenomai 
Download URL: 
https://xenomai.org/downloads/ipipe/v4.x/arm64/ipipe-core-4.19.165-cip41-arm64-09.patch

Repository: https://git.xenomai.org/ipipe-arm64
Release tag: ipipe-core-4.19.165-cip41-arm64-09

reminder: Xenomai community call on today, Feb 10th, UTC 7:00

2021-02-09 Thread Meng, Fino via Xenomai 
Sorry for the late reminder, As planned, we have the Xenomai community call
Topics may include but not limited to upstream/downstream project plan, status 
update, and technical discussion.
It's an open online meeting that anyone can join and ask questions,

Time:
Feb 10th (Wednesday), UTC 7:00
15:00 for China
8:00 for France, Germany, Italy
23:00 (Feb 9th ) for Santa Clara

Pls download Webex meeting software or use the webpage version:
https://intel.webex.com/intel/j.php?MTID=m230b1d97ab4f2a4f9dbc3b262885bab6

Meeting number (access code): 130 514 7605
Meeting password: JQpEc7UY@38  
 
Tap to join from a mobile device (attendees only)  
+1-210-795-1110,,1305147605## US Toll  
+1-866-662-9987,,1305147605## US Toll Free  

Join by phone  
+1-210-795-1110 US Toll  
+1-866-662-9987 US Toll Free  
Global call-in numbers  |  Toll-free calling restrictions   
  
Join from a video system or application
Dial 1305147...@intel.webex.com  
You can also dial 173.243.2.68 and enter your meeting number.   

BR / Fino (孟祥夫)
Intel – IOTG Developer Enabling

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

2021-02-09 Thread Jan Kiszka via Xenomai 
On 09.02.21 18:59, Giulio Moro wrote:
>> 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-container build
> kas.yml:board-beagle-bone-black.yml:opt-xenomai-next.yml:opt-linux-latest-5.10.yml
> 
> 
> however this failed because `dovetail/master` was not available in
> GIT_REPO_armhf. I am submitting a patch separately to fix this.
> 

Should be fine now, we both fixed it.

> I also tried to build with gitlab-runner, but the line provided in the
> README didn't work:
> 
> gitlab-runner exec docker --docker-privileged \
>   --env "HTTP_PROXY=$HTTP_PROXY" --env "HTTPS_PROXY=$HTTPS_PROXY" \
>   --env "NO_PROXY=$NO_PROXY" build:qemu-armhf
> 
> fails with
> 
> FATAL: no job named "build:qemu-armhf"
> 
> Note that I don't have any of those variables set in my env and that I
> am not running behind a proxy, but the failure seems to be unrelated (I
> am no docker expert), so maybe the README needs update on this one, too?

Yeah, our README is totally outdated here. We changed the naming scheme
of jobs since then. Plus I'm not sure how to specify the variations
(kernel version, Xenomai versions) this way. Quirin?

Thanks for reporting in any case.

Jan

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

Re: [xenomai-images][PATCH] Fix linux repo for 5.10 ARM

2021-02-09 Thread Jan Kiszka via Xenomai 
On 09.02.21 18:49, Giulio Moro wrote:
> 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/recipes-kernel/linux/linux-xenomai_latest.bb
> +++ b/recipes-kernel/linux/linux-xenomai_latest.bb
> @@ -25,7 +25,7 @@ def is_kernel(d, ver):
>  GIT_REPO_amd64 = "${@'git://github.com/xenomai-ci/ipipe.git' if
> is_xeno_3_0(d) else 'git://git.evlproject.org/linux-evl.git' if
> is_kernel(d, '5.10') else 'git://github.com/xenomai-ci/ipipe-x86.git'}"
>  GIT_BRANCH_amd64 = "${@'ipipe-4.4.y-cip' if is_xeno_3_0(d) else
> 'dovetail/master' if is_kernel(d, '5.10') else 'ipipe-x86-5.4.y' if
> is_kernel(d, '5.4') else 'ipipe-x86-4.19.y-cip'}"
> 
> -GIT_REPO_armhf = "${@'git://github.com/xenomai-ci/ipipe.git' if
> is_xeno_3_0(d) else 'git://github.com/xenomai-ci/ipipe-arm.git'}"
> +GIT_REPO_armhf = "${@'git://github.com/xenomai-ci/ipipe.git' if
> is_xeno_3_0(d) else 'git://git.evlproject.org/linux-evl.git' if
> is_kernel(d, '5.10') else 'git://github.com/xenomai-ci/ipipe-arm.git'}"
>  GIT_BRANCH_armhf = "${@'ipipe-4.4.y-cip' if is_xeno_3_0(d) else
> 'dovetail/master' if is_kernel(d, '5.10') else 'ipipe/5.4.y' if
> is_kernel(d, '5.4') else 'ipipe/4.19-y-cip'}"
> 
>  GIT_REPO_arm64 = "git://github.com/xenomai-ci/ipipe-arm64.git"
> -- 
> 2.17.1

Thanks, noticed that as well and pushed a force-update to wip/dovetail
earlier.

Jan

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

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

2021-02-09 Thread Giulio Moro via Xenomai 

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-container build 
kas.yml:board-beagle-bone-black.yml:opt-xenomai-next.yml:opt-linux-latest-5.10.yml

however this failed because `dovetail/master` was not available in 
GIT_REPO_armhf. I am submitting a patch separately to fix this.

I also tried to build with gitlab-runner, but the line provided in the README 
didn't work:

gitlab-runner exec docker --docker-privileged \
  --env "HTTP_PROXY=$HTTP_PROXY" --env "HTTPS_PROXY=$HTTPS_PROXY" \
  --env "NO_PROXY=$NO_PROXY" build:qemu-armhf

fails with

FATAL: no job named "build:qemu-armhf"

Note that I don't have any of those variables set in my env and that I am not 
running behind a proxy, but the failure seems to be unrelated (I am no docker 
expert), so maybe the README needs update on this one, too?

Best,
Giulio



Jan Kiszka wrote on 09/02/2021 11:42:

On 09.02.21 12:35, Giulio Moro wrote:

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)


Yeah, all these knobs are not well documented, primarily as they are
currently being added more for testing than for users. Should be improved.



but it errors. I think the relevant error is:

   AR  kernel/printk/built-in.a
   CC  kernel/trace/ring_buffer.o
   DTC arch/arm/boot/dts/logicpd-som-lv-37xx-devkit.dtb
   CC  arch/arm/mach-omap2/prm2xxx_3xxx.o
   DTC arch/arm/boot/dts/omap3430-sdp.dtb
   DTC arch/arm/boot/dts/omap3-beagle.dtb
   CC  arch/arm/mach-omap2/prm3xxx.o
   CC  kernel/trace/trace.o
   CC  kernel/irq/generic-chip.o
   DTC arch/arm/boot/dts/omap3-beagle-xm.dtb
   AR  arch/arm/mach-imx/built-in.a
   DTC arch/arm/boot/dts/omap3-beagle-xm-ab.dtb
   CC  arch/arm/mach-omap2/cm3xxx.o
../kernel/xenomai/posix/clock.c:21:10: fatal error:
cobalt/kernel/vdso.h: No such file or directory
  #include 
   ^~
compilation terminated.
   CC  kernel/time/timekeeping.o
make[6]: *** [../scripts/Makefile.build:262:
kernel/xenomai/posix/clock.o] Error 1
make[5]: *** [../scripts/Makefile.build:496: kernel/xenomai/posix] Error 2
make[4]: *** [../scripts/Makefile.build:496: kernel/xenomai] Error 2
make[4]: *** Waiting for unfinished jobs

Full log is available here
https://gist.github.com/giuliomoro/c1996a5b4c915ea385f2bde3900f8bb2
(pastebin rejects the log because of "potentially offensive or
questionable content").

Any advice will be greatly appreciated.



What you are missing is also :opt-xenomai-next.yml because 5.4 requires
some changes that are not in the last release (which is the default
otherwise). Then you will get [1] - where the resulting options are
unfortunately not printed.

Jan

[1] https://gitlab.denx.de/Xenomai/xenomai-images/-/jobs/220139

[xenomai-images][PATCH] Fix linux repo for 5.10 ARM

2021-02-09 Thread Giulio Moro via Xenomai 

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/recipes-kernel/linux/linux-xenomai_latest.bb
+++ b/recipes-kernel/linux/linux-xenomai_latest.bb
@@ -25,7 +25,7 @@ def is_kernel(d, ver):
 GIT_REPO_amd64 = "${@'git://github.com/xenomai-ci/ipipe.git' if is_xeno_3_0(d) else 
'git://git.evlproject.org/linux-evl.git' if is_kernel(d, '5.10') else 
'git://github.com/xenomai-ci/ipipe-x86.git'}"
 GIT_BRANCH_amd64 = "${@'ipipe-4.4.y-cip' if is_xeno_3_0(d) else 'dovetail/master' 
if is_kernel(d, '5.10') else 'ipipe-x86-5.4.y' if is_kernel(d, '5.4') else 
'ipipe-x86-4.19.y-cip'}"

-GIT_REPO_armhf = "${@'git://github.com/xenomai-ci/ipipe.git' if is_xeno_3_0(d) else 
'git://github.com/xenomai-ci/ipipe-arm.git'}"
+GIT_REPO_armhf = "${@'git://github.com/xenomai-ci/ipipe.git' if is_xeno_3_0(d) else 
'git://git.evlproject.org/linux-evl.git' if is_kernel(d, '5.10') else 
'git://github.com/xenomai-ci/ipipe-arm.git'}"
 GIT_BRANCH_armhf = "${@'ipipe-4.4.y-cip' if is_xeno_3_0(d) else 'dovetail/master' 
if is_kernel(d, '5.10') else 'ipipe/5.4.y' if is_kernel(d, '5.4') else 
'ipipe/4.19-y-cip'}"

 GIT_REPO_arm64 = "git://github.com/xenomai-ci/ipipe-arm64.git"
--
2.17.1

Re: Announce RTnet on PREEMPT_RT Linux

2021-02-09 Thread Laurentiu-Cristian Duca via Xenomai 
On 2/8/21, Jan Kiszka  wrote:
> 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
>

Hi,
  I consider RTnet an interesting project and I was curious about
RTnet architecture
and wondered if its core can be ported to PREEMPT_RT because some
people asked about this.

L.-C.

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

2021-02-09 Thread Jan Kiszka via Xenomai 
On 09.02.21 12:35, Giulio Moro wrote:
> 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)

Yeah, all these knobs are not well documented, primarily as they are
currently being added more for testing than for users. Should be improved.

> 
> but it errors. I think the relevant error is:
> 
>   AR  kernel/printk/built-in.a
>   CC  kernel/trace/ring_buffer.o
>   DTC arch/arm/boot/dts/logicpd-som-lv-37xx-devkit.dtb
>   CC  arch/arm/mach-omap2/prm2xxx_3xxx.o
>   DTC arch/arm/boot/dts/omap3430-sdp.dtb
>   DTC arch/arm/boot/dts/omap3-beagle.dtb
>   CC  arch/arm/mach-omap2/prm3xxx.o
>   CC  kernel/trace/trace.o
>   CC  kernel/irq/generic-chip.o
>   DTC arch/arm/boot/dts/omap3-beagle-xm.dtb
>   AR  arch/arm/mach-imx/built-in.a
>   DTC arch/arm/boot/dts/omap3-beagle-xm-ab.dtb
>   CC  arch/arm/mach-omap2/cm3xxx.o
> ../kernel/xenomai/posix/clock.c:21:10: fatal error:
> cobalt/kernel/vdso.h: No such file or directory
>  #include 
>   ^~
> compilation terminated.
>   CC  kernel/time/timekeeping.o
> make[6]: *** [../scripts/Makefile.build:262:
> kernel/xenomai/posix/clock.o] Error 1
> make[5]: *** [../scripts/Makefile.build:496: kernel/xenomai/posix] Error 2
> make[4]: *** [../scripts/Makefile.build:496: kernel/xenomai] Error 2
> make[4]: *** Waiting for unfinished jobs
> 
> Full log is available here
> https://gist.github.com/giuliomoro/c1996a5b4c915ea385f2bde3900f8bb2
> (pastebin rejects the log because of "potentially offensive or
> questionable content").
> 
> Any advice will be greatly appreciated.
> 

What you are missing is also :opt-xenomai-next.yml because 5.4 requires
some changes that are not in the last release (which is the default
otherwise). Then you will get [1] - where the resulting options are
unfortunately not printed.

Jan

[1] https://gitlab.denx.de/Xenomai/xenomai-images/-/jobs/220139

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

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

2021-02-09 Thread Giulio Moro via Xenomai 

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  kernel/trace/ring_buffer.o
  DTC arch/arm/boot/dts/logicpd-som-lv-37xx-devkit.dtb
  CC  arch/arm/mach-omap2/prm2xxx_3xxx.o
  DTC arch/arm/boot/dts/omap3430-sdp.dtb
  DTC arch/arm/boot/dts/omap3-beagle.dtb
  CC  arch/arm/mach-omap2/prm3xxx.o
  CC  kernel/trace/trace.o
  CC  kernel/irq/generic-chip.o
  DTC arch/arm/boot/dts/omap3-beagle-xm.dtb
  AR  arch/arm/mach-imx/built-in.a
  DTC arch/arm/boot/dts/omap3-beagle-xm-ab.dtb
  CC  arch/arm/mach-omap2/cm3xxx.o
../kernel/xenomai/posix/clock.c:21:10: fatal error: cobalt/kernel/vdso.h: No 
such file or directory
 #include 
  ^~
compilation terminated.
  CC  kernel/time/timekeeping.o
make[6]: *** [../scripts/Makefile.build:262: kernel/xenomai/posix/clock.o] 
Error 1
make[5]: *** [../scripts/Makefile.build:496: kernel/xenomai/posix] Error 2
make[4]: *** [../scripts/Makefile.build:496: kernel/xenomai] Error 2
make[4]: *** Waiting for unfinished jobs

Full log is available here 
https://gist.github.com/giuliomoro/c1996a5b4c915ea385f2bde3900f8bb2 (pastebin rejects the 
log because of "potentially offensive or questionable content").

Any advice will be greatly appreciated.

Thanks,
Giulio

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

2021-02-09 Thread Jan Kiszka via Xenomai 
On 09.02.21 10:04, Philippe Gerum wrote:
> 
> Jan Kiszka  writes:
> 
>> 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(&nkclock);
>>>  
>>> -   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.
>>
> 
> The idea is rather to drop the xnintr layer which has zero value in this
> case, because it does not abstract anything by itself, all is provided
> by the pipeline-specific section. This is why the pipeline call moved
> there, this is the one which brings value in, just like we directly call
> the pipeline interface elsewhere from the generic section, to flatten
> the call stack.
> 

I don't disagree with this step, just that is stopped in the middle.
Make it complete, if you like on top, by folding
pipeline_request_timer_ipi & Co. in.

Jan

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

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

2021-02-09 Thread Philippe Gerum via Xenomai 


Jan Kiszka  writes:

> 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.
>

Yes, we can remove that one. We need to keep the call hooking the
rescheduling IPI though, this one needs to be pulled in from the generic
scheduler core.

-- 
Philippe.

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

2021-02-09 Thread Philippe Gerum via Xenomai 


Philippe Gerum  writes:

> Jan Kiszka  writes:
>
>> 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(&nkclock);
>>>  
>>> -   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.
>>
>
> The idea is rather to drop the xnintr layer which has zero value in
> this

s,xnintr_,xntimer_,

-- 
Philippe.

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

2021-02-09 Thread Philippe Gerum via Xenomai 


Jan Kiszka  writes:

> 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(&nkclock);
>>  
>> -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.
>

The idea is rather to drop the xnintr layer which has zero value in this
case, because it does not abstract anything by itself, all is provided
by the pipeline-specific section. This is why the pipeline call moved
there, this is the one which brings value in, just like we directly call
the pipeline interface elsewhere from the generic section, to flatten
the call stack.

-- 
Philippe.

RE: several questions about porting latmus

2021-02-09 Thread 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?
>>
>
>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.

Thanks  for your suggestions. I have finished implementing generic helper in 
gpio-core.c and
also developed new gpio rtdm driver for my board. After build successfully and 
run xenomai 
on my board, bother latmus and gpio chip device file can be found under 
/dev/rtdm folder.
But when I