[Xenomai] Build Xenomai Lib native on the Beaglebone Black

[Xenomai] Build Xenomai Lib native on the Beaglebone Black

[Flavio Castro Alves Filho]

Hello,

Does anybody tried to build the Xenomai user space native on a BeagleBone Black?

I'm using Debian on my board, with the build-essential package installed.

Should we have the same result as cross-compiling?

Best regards,

Flavio

-- 
Flavio de Castro Alves Filho

flavio.alves@gmail.com
www.linuxembarcado.com
Twitter: http://twitter.com/#!/fraviofii
LinkedIn profile: www.linkedin.com/in/flaviocastroalves

Re: [Xenomai] Build Xenomai Lib native on the Beaglebone Black

[Gilles Chanteperdrix]

On 03/10/2014 04:00 AM, Flavio Castro Alves Filho wrote:
> Hello,
> 
> Does anybody tried to build the Xenomai user space native on a BeagleBone Black?
> 
> I'm using Debian on my board, with the build-essential package installed.

If you do not use xenomai 2.6 git, you will probably need this patch:
http://git.xenomai.org/xenomai-2.6.git/commit/?id=b10527ed14399a6485f69b935988d9d5211066d0

to allow compiling xenomai for the armhf flavor of debian.

> 
> Should we have the same result as cross-compiling?

With the same versions of the tools, you should have exactly the same result. 
Only, you will probably get it after some more time.

Regards.

-- 
                                                                Gilles.

Re: [Xenomai] Build Xenomai Lib native on the Beaglebone Black

[Flavio Castro Alves Filho]

Hello Gilles,

It worked :-)

Thank you.

Flavio


2014-03-10 3:49 GMT-03:00 Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org>:
> On 03/10/2014 04:00 AM, Flavio Castro Alves Filho wrote:
>> Hello,
>>
>> Does anybody tried to build the Xenomai user space native on a BeagleBone Black?
>>
>> I'm using Debian on my board, with the build-essential package installed.
>
> If you do not use xenomai 2.6 git, you will probably need this patch:
> http://git.xenomai.org/xenomai-2.6.git/commit/?id=b10527ed14399a6485f69b935988d9d5211066d0
>
> to allow compiling xenomai for the armhf flavor of debian.
>
>>
>> Should we have the same result as cross-compiling?
>
> With the same versions of the tools, you should have exactly the same result.
> Only, you will probably get it after some more time.
>
> Regards.
>
> --
>                                                                 Gilles.



-- 
Flavio de Castro Alves Filho

flavio.alves@gmail.com
www.linuxembarcado.com
Twitter: http://twitter.com/#!/fraviofii
LinkedIn profile: www.linkedin.com/in/flaviocastroalves

Re: [Xenomai] Build Xenomai Lib native on the Beaglebone Black

[Yogi A. Patel]

Flavio -

Would you mind sharing what latencies you are seeing on your Beaglebone black with xenomai?

--
Yogi A. Patel
(c): (828) 291-6715
(url): www.yapatel.org | @yapatel525

Re: [Xenomai] Build Xenomai Lib native on the Beaglebone Black

[Gilles Chanteperdrix]

On 03/12/2014 12:59 AM, Yogi A. Patel wrote:
> Flavio -
> 
> Would you mind sharing what latencies you are seeing on your Beaglebone black with xenomai?

Some results which might be interesting, the results for the IGEPv2
board, using an omap3630 processor, close to the beaglebone black
processor, are in the 40-45us range, if the kernel is compiled with the
right options, that is:
- kernel built using thumb2 and optimized for size
- preemption set to CONFIG_PREEMPT_NONE
- CONFIG_SMP disabled
- stack unwinding enabled
- xenomai unlocked switch disabled
- all xenomai/ipipe debugs off, except maybe "watchdog support" and
"detect mutexes held in relaxed sections", as they should not incur an
increase in latency.

Since the I-pipe core series (so since linux 3.2), I have started
recording the results I get on the test platforms I have, see, to show
the improvements over time (most improvements are due to configurations
changes):

http://xenomai.org/~gch/core-3.2-latencies/
http://xenomai.org/~gch/core-3.4-latencies/
http://xenomai.org/~gch/core-3.5-latencies/
http://xenomai.org/~gch/core-3.8-latencies/
http://xenomai.org/~gch/core-3.10-latencies/

Note that we recently discovered that disabling the L2 cache
"write-allocate" bit on imx6 and omap4, so probably on any multi-core
cortex a9, improved latencies considerably, and that moving the
spinlocks code out-of-line did too, see:
http://sisyphus.hd.free.fr/~gilles/panda-test/inline-spinlocks.png

The change of the L2 write-allocate bit will be in the next Xenomai 2.x
release, whereas the change of spinlock code will only appear in xenomai
3.0.

Anyway, I would like to also try disabling the L2 cache write-allocate
on omap3, but IGEPv2 is running in secure mode, so I can not change this
configuration, I would probably need an "smc" call, but I have not found
a documentation for these calls, so if anyone knows where to find this
info, I am interested.

Regards.


-- 
                                                                Gilles.

Re: [Xenomai] Build Xenomai Lib native on the Beaglebone Black

[Yogi A. Patel]

Hi Gilles -

Thanks for this information - this is great and provides a good comparison. I am getting about 40us on my beaglebone black running debian+xenomai 2.6.3. Disabling the L2 cache write-allocate bit to get 10us would be phenomenal. 

Question - what is the option to deselect in the “make menuconfig” to disable the L2 cache write-allocate bit?

I’ll post any results I have for comparison, if it helps.

--
Yogi A. Patel
(c): (828) 291-6715
(url): www.yapatel.org | @yapatel525

On Mar 12, 2014, at 8:29 AM, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:

> On 03/12/2014 12:59 AM, Yogi A. Patel wrote:
>> Flavio -
>> 
>> Would you mind sharing what latencies you are seeing on your Beaglebone black with xenomai?
> 
> Some results which might be interesting, the results for the IGEPv2
> board, using an omap3630 processor, close to the beaglebone black
> processor, are in the 40-45us range, if the kernel is compiled with the
> right options, that is:
> - kernel built using thumb2 and optimized for size
> - preemption set to CONFIG_PREEMPT_NONE
> - CONFIG_SMP disabled
> - stack unwinding enabled
> - xenomai unlocked switch disabled
> - all xenomai/ipipe debugs off, except maybe "watchdog support" and
> "detect mutexes held in relaxed sections", as they should not incur an
> increase in latency.
> 
> Since the I-pipe core series (so since linux 3.2), I have started
> recording the results I get on the test platforms I have, see, to show
> the improvements over time (most improvements are due to configurations
> changes):
> 
> http://xenomai.org/~gch/core-3.2-latencies/
> http://xenomai.org/~gch/core-3.4-latencies/
> http://xenomai.org/~gch/core-3.5-latencies/
> http://xenomai.org/~gch/core-3.8-latencies/
> http://xenomai.org/~gch/core-3.10-latencies/
> 
> Note that we recently discovered that disabling the L2 cache
> "write-allocate" bit on imx6 and omap4, so probably on any multi-core
> cortex a9, improved latencies considerably, and that moving the
> spinlocks code out-of-line did too, see:
> http://sisyphus.hd.free.fr/~gilles/panda-test/inline-spinlocks.png
> 
> The change of the L2 write-allocate bit will be in the next Xenomai 2.x
> release, whereas the change of spinlock code will only appear in xenomai
> 3.0.
> 
> Anyway, I would like to also try disabling the L2 cache write-allocate
> on omap3, but IGEPv2 is running in secure mode, so I can not change this
> configuration, I would probably need an "smc" call, but I have not found
> a documentation for these calls, so if anyone knows where to find this
> info, I am interested.
> 
> Regards.
> 
> 
> -- 
>                                                                Gilles.

Re: [Xenomai] Build Xenomai Lib native on the Beaglebone Black

[Gilles Chanteperdrix]

On 03/16/2014 10:37 PM, Yogi A. Patel wrote:
> Hi Gilles -
> 
> Thanks for this information - this is great and provides a good
> comparison. I am getting about 40us on my beaglebone black running
> debian+xenomai 2.6.3. Disabling the L2 cache write-allocate bit to
> get 10us would be phenomenal.
> 
> Question - what is the option to deselect in the “make menuconfig” to
> disable the L2 cache write-allocate bit?

Please read my answer again.

-- 
                                                                Gilles.