-----Original Message----- >From: Philippe Gerum <[email protected]> >Sent: Monday, February 8, 2021 12:21 AM >To: Chen, Hongzhan <[email protected]> >Cc: [email protected] >Subject: Re: several questions about porting latmus > > >Chen, Hongzhan <[email protected]> writes: > >>>-----Original Message----- >>>From: Philippe Gerum <[email protected]> >>>Sent: Monday, February 1, 2021 5:31 PM >>>To: Chen, Hongzhan <[email protected]> >>>Cc: [email protected] >>>Subject: Re: several questions about porting latmus >>> >>> >>>Hi Hongzhan, >>> >>>Chen, Hongzhan <[email protected]> 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. > >[1] https://evlproject.org/core/user-api/timer/ >[2] http://evlproject.org/core/oob-drivers/gpio/ > >-- >Philippe.
