[Xenomai] VxWorks API on Xenomai 3.0

[Xenomai] VxWorks API on Xenomai 3.0

[Nicolas SCHURANDO]

Hello everyone,

In an attempt to migrate from Xenomai 2.6.4 on a Raspberry Pi 1 to Xenomai
3.0.1 on a Raspberry Pi 2, I get an error when trying to spawn a VxWorks
task in a fairly simple test program. Here is the output :

   0"000.064| WARNING: [main] Xenomai compiled with full debug enabled,
>                               very high latencies expected
> [--enable-debug=full]
>  [i] [main] Hello, launching root task ...
>  200"747.521| BUG in wind_task_normalize_priority():


The corresponding code is :

int main(int argc, char *argv[]) {


> /* Hello world */
> printf(" [i] [%s] Hello, launching root task ...\r\n", __FUNCTION__);


> /* Spawn root task */
> taskSpawn("root_task", 100, 0, 16 * 1024, (FUNCPTR) &root_task, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0);


> [...]


> }


I've tracked down the problem to threadobj_high_prio being equal to 0,
hence the following function expecting priorities from -1 to 0. I however
have no idea where threadobj_high_prio gets its value from.

__weak int wind_task_normalize_priority(int wind_prio)
> {
> /*
> * SCHED_FIFO priorities are always 1-based regardless of the
> * underlying real-time core. We remap the lowest VxWorks
> * priority to the lowest available level in the SCHED_FIFO
> * policy.
> */
> if (wind_prio > threadobj_high_prio - 1)
> panic("current implementation restricts VxWorks "
>      "priority levels to range [%d..0]",
>      threadobj_high_prio - 1);



/* Map a VxWorks priority level to a SCHED_FIFO one. */
> return threadobj_high_prio - wind_prio - 1;
> }


Here is if needed the output produced by --dump-config :

based on Xenomai/cobalt v3.0 -- #5f6b32f (2015-10-31 20:57:40 +0100)
> CONFIG_MMU=1
> CONFIG_SMP=1
> CONFIG_XENO_BUILD_ARGS=" '--with-core=cobalt' '--enable-debug=full'
> '--enable-smp' '--disable-doc-install'
> '--host=arm-bcm2708hardfp-linux-gnueabi' 'CFLAGS=-mcpu=cortex-a7
> -mfpu=neon-vfpv4 -mfloat-abi=hard' 'LDFLAGS=-mcpu=cortex-a7
> -mfpu=neon-vfpv4 -mfloat-abi=hard'
> 'host_alias=arm-bcm2708hardfp-linux-gnueabi'"
> CONFIG_XENO_BUILD_STRING="i686-pc-linux-gnu"
> CONFIG_XENO_COBALT=1
> CONFIG_XENO_COMPILER="gcc version 4.7.1 20120402 (prerelease)
> (crosstool-NG 1.15.2) "
> CONFIG_XENO_DEBUG=1
> CONFIG_XENO_DEBUG_FULL=1
> CONFIG_XENO_DEFAULT_PERIOD=1000000
> CONFIG_XENO_FORTIFY=1
> CONFIG_XENO_HOST_STRING="arm-bcm2708hardfp-linux-gnueabi"
> CONFIG_XENO_LORES_CLOCK_DISABLED=1
> CONFIG_XENO_PREFIX="/usr/xenomai"
> CONFIG_XENO_RAW_CLOCK_ENABLED=1
> CONFIG_XENO_REVISION_LEVEL=0
> CONFIG_XENO_SANITY=1
> CONFIG_XENO_TLSF=1
> CONFIG_XENO_TLS_MODEL="initial-exec"
> CONFIG_XENO_UAPI_LEVEL=14
> CONFIG_XENO_VERSION_MAJOR=3
> CONFIG_XENO_VERSION_MINOR=0
> CONFIG_XENO_VERSION_NAME="Exact Zero"
> CONFIG_XENO_VERSION_STRING="3.0"
> CONFIG_XENO_X86_VSYSCALL=1
> ---
> CONFIG_XENO_ASYNC_CANCEL is OFF
> CONFIG_XENO_COPPERPLATE_CLOCK_RESTRICTED is OFF
> CONFIG_XENO_LIBS_DLOPEN is OFF
> CONFIG_XENO_MERCURY is OFF
> CONFIG_XENO_PSHARED is OFF
> CONFIG_XENO_REGISTRY is OFF
> CONFIG_XENO_REGISTRY_ROOT is OFF
> CONFIG_XENO_VALGRIND_API is OFF
> CONFIG_XENO_WORKAROUND_CONDVAR_PI is OFF
> ---
> PTHREAD_STACK_DEFAULT=65536


Any help would be appreciated,

Thanks,

Nicolas

Re: [Xenomai] VxWorks API on Xenomai 3.0

[Philippe Gerum]

On 01/14/2016 10:22 AM, Nicolas SCHURANDO wrote:
> Hello everyone,
> 
> In an attempt to migrate from Xenomai 2.6.4 on a Raspberry Pi 1 to Xenomai
> 3.0.1 on a Raspberry Pi 2, I get an error when trying to spawn a VxWorks
> task in a fairly simple test program. Here is the output :
> 
>    0"000.064| WARNING: [main] Xenomai compiled with full debug enabled,
>>                               very high latencies expected
>> [--enable-debug=full]
>>  [i] [main] Hello, launching root task ...
>>  200"747.521| BUG in wind_task_normalize_priority():
> 
> 
> The corresponding code is :
> 
> int main(int argc, char *argv[]) {
> 
> 
>> /* Hello world */
>> printf(" [i] [%s] Hello, launching root task ...\r\n", __FUNCTION__);
> 
> 
>> /* Spawn root task */
>> taskSpawn("root_task", 100, 0, 16 * 1024, (FUNCPTR) &root_task, 0, 0, 0,
>> 0, 0, 0, 0, 0, 0, 0);
> 
> 
>> [...]
> 
> 
>> }
> 
> 
> I've tracked down the problem to threadobj_high_prio being equal to 0,
> hence the following function expecting priorities from -1 to 0. I however
> have no idea where threadobj_high_prio gets its value from.
> 

Your application is not initializing properly, the Xenomai libs are not
bootstrapped. There are detailed explanations about the init flow here:
http://xenomai.org/2015/05/application-setup-and-init/

-- 
Philippe.

Re: [Xenomai] VxWorks API on Xenomai 3.0

[Nicolas SCHURANDO]

Hi Philippe,

Thank your for your answer. I have read the manual page entitled
"Application setup and init", and in particular the part about manual vs
automatic bootstrap, and I have tried to follow the instructions to the
letter.

Cross GCC Compiler command is :

> arm-linux-gnueabihf-gcc -D_GNU_SOURCE -D_REENTRANT -D__COBALT__
> -ID:\Gcc\Raspberry-4.9.2-Rpi2Test\arm-linux-gnueabihf\sysroot\usr\xenomai\include\cobalt
> -ID:\Gcc\Raspberry-4.9.2-Rpi2Test\arm-linux-gnueabihf\sysroot\usr\xenomai\include
> -ID:\Gcc\Raspberry-4.9.2-Rpi2Test\arm-linux-gnueabihf\sysroot\usr\xenomai\include\vxworks
> -O0 -g3 -Wall -c -fmessage-length=0 -mcpu=cortex-a7 -mfpu=neon-vfpv4
> -mfloat-abi=hard -MMD -MP -MF"main.d" -MT"main.d" -o "main.o" "../main.c"


Cross GCC Linker command is :

> arm-linux-gnueabihf-gcc -L../libs
> D:\Gcc\Raspberry-4.9.2-Rpi2Test\arm-linux-gnueabihf\sysroot\usr\xenomai\lib\xenomai\bootstrap.o
> -Wl,--wrap=main
> -Wl,--dynamic-list=D:\Gcc\Raspberry-4.9.2-Rpi2Test\arm-linux-gnueabihf\sysroot\usr\xenomai\lib\dynlist.ld
> -o "rpi-test-bug-watchdog"  ./main.o   -lvxworks -lcopperplate -lcobalt
> -lpthread -lrt


And if I try to add an explicit call to xenomai_init at the very beginning
of my main, here is what happens :

>    0"001.000| WARNING: [main] duplicate call to xenomai_init() ignored
>    0"001.618| WARNING: [main] (xeno-config --no-auto-init disables
> implicit call)


What could I be missing ?

Cheers,

Nicolas

2016-01-14 18:24 GMT+01:00 Philippe Gerum <rpm@xenomai.org>:

> On 01/14/2016 10:22 AM, Nicolas SCHURANDO wrote:
> > Hello everyone,
> >
> > In an attempt to migrate from Xenomai 2.6.4 on a Raspberry Pi 1 to
> Xenomai
> > 3.0.1 on a Raspberry Pi 2, I get an error when trying to spawn a VxWorks
> > task in a fairly simple test program. Here is the output :
> >
> >    0"000.064| WARNING: [main] Xenomai compiled with full debug enabled,
> >>                               very high latencies expected
> >> [--enable-debug=full]
> >>  [i] [main] Hello, launching root task ...
> >>  200"747.521| BUG in wind_task_normalize_priority():
> >
> >
> > The corresponding code is :
> >
> > int main(int argc, char *argv[]) {
> >
> >
> >> /* Hello world */
> >> printf(" [i] [%s] Hello, launching root task ...\r\n", __FUNCTION__);
> >
> >
> >> /* Spawn root task */
> >> taskSpawn("root_task", 100, 0, 16 * 1024, (FUNCPTR) &root_task, 0, 0, 0,
> >> 0, 0, 0, 0, 0, 0, 0);
> >
> >
> >> [...]
> >
> >
> >> }
> >
> >
> > I've tracked down the problem to threadobj_high_prio being equal to 0,
> > hence the following function expecting priorities from -1 to 0. I however
> > have no idea where threadobj_high_prio gets its value from.
> >
>
> Your application is not initializing properly, the Xenomai libs are not
> bootstrapped. There are detailed explanations about the init flow here:
> http://xenomai.org/2015/05/application-setup-and-init/
>
> --
> Philippe.
>

Re: [Xenomai] VxWorks API on Xenomai 3.0

[Philippe Gerum]

On 01/15/2016 10:57 AM, Nicolas SCHURANDO wrote:
> Hi Philippe,
> 
> Thank your for your answer. I have read the manual page entitled
> "Application setup and init", and in particular the part about manual vs
> automatic bootstrap, and I have tried to follow the instructions to the
> letter.
> 
> Cross GCC Compiler command is :
> 
>     arm-linux-gnueabihf-gcc -D_GNU_SOURCE -D_REENTRANT -D__COBALT__
>     -ID:\Gcc\Raspberry-4.9.2-Rpi2Test\arm-linux-gnueabihf\sysroot\usr\xenomai\include\cobalt
>     -ID:\Gcc\Raspberry-4.9.2-Rpi2Test\arm-linux-gnueabihf\sysroot\usr\xenomai\include
>     -ID:\Gcc\Raspberry-4.9.2-Rpi2Test\arm-linux-gnueabihf\sysroot\usr\xenomai\include\vxworks
>     -O0 -g3 -Wall -c -fmessage-length=0 -mcpu=cortex-a7 -mfpu=neon-vfpv4
>     -mfloat-abi=hard -MMD -MP -MF"main.d" -MT"main.d" -o "main.o"
>     "../main.c"
> 
> 
> Cross GCC Linker command is :
> 
>     arm-linux-gnueabihf-gcc -L../libs
>     D:\Gcc\Raspberry-4.9.2-Rpi2Test\arm-linux-gnueabihf\sysroot\usr\xenomai\lib\xenomai\bootstrap.o
>     -Wl,--wrap=main
>     -Wl,--dynamic-list=D:\Gcc\Raspberry-4.9.2-Rpi2Test\arm-linux-gnueabihf\sysroot\usr\xenomai\lib\dynlist.ld
>     -o "rpi-test-bug-watchdog"  ./main.o   -lvxworks -lcopperplate
>     -lcobalt -lpthread -lrt
> 
> 
> And if I try to add an explicit call to xenomai_init at the very
> beginning of my main, here is what happens :
> 
>        0"001.000| WARNING: [main] duplicate call to xenomai_init() ignored
>        0"001.618| WARNING: [main] (xeno-config --no-auto-init disables
>     implicit call)
> 
> 
> What could I be missing ?

I don't understand your question. What is wrong with this output?

-- 
Philippe.

Re: [Xenomai] VxWorks API on Xenomai 3.0

[Nicolas SCHURANDO]

Hi Philippe,

In your previous message you suggested that something might be wrong with
the way the application is initialized. And my message was an attempt at
further describing what I had already done.

Oh, I see. I suppose the tense of my message was misleading. I meant that I
had already read the documentation prior to reaching out to you, and the
compiler and linker commands above are the one I had already used.

Are you confirming that the init seems to happen fine ? And if so, what
could explain the error I get when trying to spawn the VxWorks task ?

Regards

2016-01-18 12:55 GMT+01:00 Philippe Gerum <rpm@xenomai.org>:

> On 01/15/2016 10:57 AM, Nicolas SCHURANDO wrote:
> > Hi Philippe,
> >
> > Thank your for your answer. I have read the manual page entitled
> > "Application setup and init", and in particular the part about manual vs
> > automatic bootstrap, and I have tried to follow the instructions to the
> > letter.
> >
> > Cross GCC Compiler command is :
> >
> >     arm-linux-gnueabihf-gcc -D_GNU_SOURCE -D_REENTRANT -D__COBALT__
> >
>  -ID:\Gcc\Raspberry-4.9.2-Rpi2Test\arm-linux-gnueabihf\sysroot\usr\xenomai\include\cobalt
> >
>  -ID:\Gcc\Raspberry-4.9.2-Rpi2Test\arm-linux-gnueabihf\sysroot\usr\xenomai\include
> >
>  -ID:\Gcc\Raspberry-4.9.2-Rpi2Test\arm-linux-gnueabihf\sysroot\usr\xenomai\include\vxworks
> >     -O0 -g3 -Wall -c -fmessage-length=0 -mcpu=cortex-a7 -mfpu=neon-vfpv4
> >     -mfloat-abi=hard -MMD -MP -MF"main.d" -MT"main.d" -o "main.o"
> >     "../main.c"
> >
> >
> > Cross GCC Linker command is :
> >
> >     arm-linux-gnueabihf-gcc -L../libs
> >
>  D:\Gcc\Raspberry-4.9.2-Rpi2Test\arm-linux-gnueabihf\sysroot\usr\xenomai\lib\xenomai\bootstrap.o
> >     -Wl,--wrap=main
> >
>  -Wl,--dynamic-list=D:\Gcc\Raspberry-4.9.2-Rpi2Test\arm-linux-gnueabihf\sysroot\usr\xenomai\lib\dynlist.ld
> >     -o "rpi-test-bug-watchdog"  ./main.o   -lvxworks -lcopperplate
> >     -lcobalt -lpthread -lrt
> >
> >
> > And if I try to add an explicit call to xenomai_init at the very
> > beginning of my main, here is what happens :
> >
> >        0"001.000| WARNING: [main] duplicate call to xenomai_init()
> ignored
> >        0"001.618| WARNING: [main] (xeno-config --no-auto-init disables
> >     implicit call)
> >
> >
> > What could I be missing ?
>
> I don't understand your question. What is wrong with this output?
>
> --
> Philippe.
>

Re: [Xenomai] VxWorks API on Xenomai 3.0

[Philippe Gerum]

On 01/18/2016 01:34 PM, Nicolas SCHURANDO wrote:
> Hi Philippe,
> 
> In your previous message you suggested that something might be wrong
> with the way the application is initialized. And my message was an
> attempt at further describing what I had already done.
> 
> Oh, I see. I suppose the tense of my message was misleading. I meant
> that I had already read the documentation prior to reaching out to you,
> and the compiler and linker commands above are the one I had already used.
> 
> Are you confirming that the init seems to happen fine ? And if so, what
> could explain the error I get when trying to spawn the VxWorks task ?
> 

The only reason would be that copperplate_init() did not run, which
means that your application init sequence does not work as expected.

You may want to pick the latest changes from stable-3.0.x, and start
your application with the --trace option. This will trace the init
sequence from xenomai_init() onward. For a VxWorks application based on
the copperplate layer running over Cobalt, you should see something
along these lines:

# /your/application --trace
--  xenomai_init() running
--  cobalt->init()
--  connected to Cobalt
--  memory locked
--  memory heaps mapped
--  boilerplate->init()
--  copperplate->init()
--  alchemy->init()
--  initialization complete

If you don't see such output, then something is wrong.

-- 
Philippe.

Re: [Xenomai] VxWorks API on Xenomai 3.0

[Nicolas SCHURANDO]

Hi Philippe,

I switched to branch stable-3.0.x, retrieved your commit b411e4c
"lib/cobalt: add init trace points", and rebuilt everything.

Below is what I have with the new --trace option.

With static linking :

> --  xenomai_init() running
> --  cobalt->init()
> --  connected to Cobalt
> --  memory locked
> --  memory heaps mapped
> --  boilerplate->init()
>    0"000.070| WARNING: [main] Xenomai compiled with full debug enabled,
>                               very high latencies expected
> [--enable-debug=full]
> --  initialization complete
>  [i] [main] Hello, launching root task ...
>    0"001.747| BUG in wind_task_normalize_priority():


I also decided to try with dynamic linking as well, to see if it was
producing anything different :

> --  xenomai_init() running
> --  cobalt->init()
> --  connected to Cobalt
> --  memory locked
> --  memory heaps mapped
> --  boilerplate->init()
> --  copperplate->init()
> --  vxworks->init()
>    0"016.431| WARNING: [rpi-test-bug-wa] low resolution clock disabled
> [--enable-lores-clock]
>    0"019.474| WARNING: [rpi-test-bug-wa] vxworks_init: failed to
> initialize VxWorks clock (res=1000000 ns)
>    0"022.093| WARNING: [main] setup call vxworks failed
>    0"024.535| BUG in xenomai_init(): [main] initialization failed, EINVAL


Regards

2016-01-18 16:19 GMT+01:00 Philippe Gerum <rpm@xenomai.org>:

> On 01/18/2016 01:34 PM, Nicolas SCHURANDO wrote:
> > Hi Philippe,
> >
> > In your previous message you suggested that something might be wrong
> > with the way the application is initialized. And my message was an
> > attempt at further describing what I had already done.
> >
> > Oh, I see. I suppose the tense of my message was misleading. I meant
> > that I had already read the documentation prior to reaching out to you,
> > and the compiler and linker commands above are the one I had already
> used.
> >
> > Are you confirming that the init seems to happen fine ? And if so, what
> > could explain the error I get when trying to spawn the VxWorks task ?
> >
>
> The only reason would be that copperplate_init() did not run, which
> means that your application init sequence does not work as expected.
>
> You may want to pick the latest changes from stable-3.0.x, and start
> your application with the --trace option. This will trace the init
> sequence from xenomai_init() onward. For a VxWorks application based on
> the copperplate layer running over Cobalt, you should see something
> along these lines:
>
> # /your/application --trace
> --  xenomai_init() running
> --  cobalt->init()
> --  connected to Cobalt
> --  memory locked
> --  memory heaps mapped
> --  boilerplate->init()
> --  copperplate->init()
> --  alchemy->init()
> --  initialization complete
>
> If you don't see such output, then something is wrong.
>
> --
> Philippe.
>

Re: [Xenomai] VxWorks API on Xenomai 3.0

[Philippe Gerum]

On 01/18/2016 07:15 PM, Nicolas SCHURANDO wrote:
> Hi Philippe,
> 
> I switched to branch stable-3.0.x, retrieved your commit b411e4c
> "lib/cobalt: add init trace points", and rebuilt everything.
> 
> Below is what I have with the new --trace option.
> 
> With static linking : 
> 
>     --  xenomai_init() running
>     --  cobalt->init()
>     --  connected to Cobalt
>     --  memory locked
>     --  memory heaps mapped
>     --  boilerplate->init()
>        0"000.070| WARNING: [main] Xenomai compiled with full debug enabled,
>                                   very high latencies expected
>     [--enable-debug=full]
>     --  initialization complete
>      [i] [main] Hello, launching root task ...
>        0"001.747| BUG in wind_task_normalize_priority(): 

The init call for the VxWorks API is missing, which explains the issue.

> 
> 
> I also decided to try with dynamic linking as well, to see if it was
> producing anything different :
> 
>     --  xenomai_init() running
>     --  cobalt->init()
>     --  connected to Cobalt
>     --  memory locked
>     --  memory heaps mapped
>     --  boilerplate->init()
>     --  copperplate->init()
>     --  vxworks->init()

The issue is most likely with static linking. It seems that the linker
is eliminating the interface setup descriptor in lib/vxworks/init.c from
the final executable; unfortunately this is a library constructor,
connecting the API to the system. We already stumbled upon this issue,
but no fix could be found at this point, with toolchains ignoring
explicit requests to keep such symbols into the name list.

Some (likely terminally ugly) work around may exist, but support for
static linking is very low priority here, so I would advise to stay with
dynamic linking for now.

>        0"016.431| WARNING: [rpi-test-bug-wa] low resolution clock
>     disabled [--enable-lores-clock]

--enable-lores-clock when configuring is required by tick-based APIs.

-- 
Philippe.

Re: [Xenomai] VxWorks API on Xenomai 3.0

[Nicolas SCHURANDO]

Hi Philippe,

Thank you very much for you help !

Configuring xenomai with --enable-lores-clock and using dynamic linking
instead of the static one did the trick.

I haven't finished testing everything but, so far so good.

Regards,

Nicolas

On Jan 19, 2016 09:22, "Philippe Gerum" <rpm@xenomai.org> wrote:

> On 01/18/2016 07:15 PM, Nicolas SCHURANDO wrote:
> > Hi Philippe,
> >
> > I switched to branch stable-3.0.x, retrieved your commit b411e4c
> > "lib/cobalt: add init trace points", and rebuilt everything.
> >
> > Below is what I have with the new --trace option.
> >
> > With static linking :
> >
> >     --  xenomai_init() running
> >     --  cobalt->init()
> >     --  connected to Cobalt
> >     --  memory locked
> >     --  memory heaps mapped
> >     --  boilerplate->init()
> >        0"000.070| WARNING: [main] Xenomai compiled with full debug
> enabled,
> >                                   very high latencies expected
> >     [--enable-debug=full]
> >     --  initialization complete
> >      [i] [main] Hello, launching root task ...
> >        0"001.747| BUG in wind_task_normalize_priority():
>
> The init call for the VxWorks API is missing, which explains the issue.
>
> >
> >
> > I also decided to try with dynamic linking as well, to see if it was
> > producing anything different :
> >
> >     --  xenomai_init() running
> >     --  cobalt->init()
> >     --  connected to Cobalt
> >     --  memory locked
> >     --  memory heaps mapped
> >     --  boilerplate->init()
> >     --  copperplate->init()
> >     --  vxworks->init()
>
> The issue is most likely with static linking. It seems that the linker
> is eliminating the interface setup descriptor in lib/vxworks/init.c from
> the final executable; unfortunately this is a library constructor,
> connecting the API to the system. We already stumbled upon this issue,
> but no fix could be found at this point, with toolchains ignoring
> explicit requests to keep such symbols into the name list.
>
> Some (likely terminally ugly) work around may exist, but support for
> static linking is very low priority here, so I would advise to stay with
> dynamic linking for now.
>
> >        0"016.431| WARNING: [rpi-test-bug-wa] low resolution clock
> >     disabled [--enable-lores-clock]
>
> --enable-lores-clock when configuring is required by tick-based APIs.
>
> --
> Philippe.
>