[Buildroot] Real time Linux implementation

[Buildroot] Real time Linux implementation

[Morten Jensen]

Hello,
We are using Buildroot on an ARM based development platform from IC-BOARD:
http://www.ic-board.de/product_info.php?info=p163_STK-ADB3000---ICnova-SAM9G45-XC3S700AN-OEM.html

Does anybody have any experience with implementing Real Time OS
functionality in the Linux Buildroot system or can you guide us to someone
that may be able to help or consult in this effort ?

Sincerely

Morten Jensen
NVS Technologies
3603 Haven Ave #A
Menlo Park, CA 94025
Tlf 650 363 8776 x 212
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20111201/c15642c1/attachment.html>

[Buildroot] Real time Linux implementation

[Thomas Petazzoni]

Le Thu, 1 Dec 2011 11:27:37 -0800,
Morten Jensen <mjensen@nvs-technologies.com> a ?crit :

> Hello,
> We are using Buildroot on an ARM based development platform from IC-BOARD:
> http://www.ic-board.de/product_info.php?info=p163_STK-ADB3000---ICnova-SAM9G45-XC3S700AN-OEM.html
> 
> Does anybody have any experience with implementing Real Time OS
> functionality in the Linux Buildroot system or can you guide us to someone
> that may be able to help or consult in this effort ?

Yes. First thing to find out is what you need in terms of real-time :

 *) A vanilla Linux kernel with preemption enabled and proper process
    priorities ;

 *) A Linux kernel patched with PREEMPT_RT

 *) The more radical approach provided by Xenomai

All three are possible with Buildroot, it's rather what kind of
real-time guarantees and latencies you need and how much effort you're
ready to spend on achieving those guarantees.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Real time Linux implementation

[Stephan Hoffmann]

Am 01.12.2011 22:18, schrieb Thomas Petazzoni:
> Le Thu, 1 Dec 2011 11:27:37 -0800,
> Morten Jensen <mjensen@nvs-technologies.com> a ?crit :
>
>> Hello,
>> We are using Buildroot on an ARM based development platform from IC-BOARD:
>> http://www.ic-board.de/product_info.php?info=p163_STK-ADB3000---ICnova-SAM9G45-XC3S700AN-OEM.html
>>
>> Does anybody have any experience with implementing Real Time OS
>> functionality in the Linux Buildroot system or can you guide us to someone
>> that may be able to help or consult in this effort ?
> Yes. First thing to find out is what you need in terms of real-time :
>
>  *) A vanilla Linux kernel with preemption enabled and proper process
>     priorities ;
>
>  *) A Linux kernel patched with PREEMPT_RT
I have good experiences with this patch, but did not try it with a ARM.
It's not that much effort and integrates well with buildroot. Look here:
https://rt.wiki.kernel.org/ and here:
https://www.osadl.org/Latest-Stable-Realtime.latest-stable-realtime-linux.0.html
for further information.

@Peter and Thomas,

what do you think about adding the PREEMPT_RT patch as a config option
to buildroot?

Kind regards

Stephan


-- 
reLinux     -    Stephan Hoffmann
Am Schmidtgrund 124    50765 K?ln
Tel. +49.221.95595-19    Fax: -64
www.reLinux.de     sho at reLinux.de

[Buildroot] Real time Linux implementation

[Thomas Petazzoni]

Le Fri, 02 Dec 2011 19:33:47 +0100,
Stephan Hoffmann <sho@relinux.de> a ?crit :

> what do you think about adding the PREEMPT_RT patch as a config option
> to buildroot?

That would definitely be nice. The only problem is that PREEMPT_RT is
far from being available for every upstream kernel version, so it's a
bit hard to integrate from that perspective, but this isn't much
different from Xenomai and RTAI having similar kernel version
constraints. So, yes, having some PREEMPT_RT integration would be nice,
at least to show that it is possible.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Real time Linux implementation

[Michael S. Zick]

On Fri December 2 2011, Thomas Petazzoni wrote:
> Le Fri, 02 Dec 2011 19:33:47 +0100,
> Stephan Hoffmann <sho@relinux.de> a ?crit :
> 
> > what do you think about adding the PREEMPT_RT patch as a config option
> > to buildroot?
> 
> That would definitely be nice. The only problem is that PREEMPT_RT is
> far from being available for every upstream kernel version, so it's a
> bit hard to integrate from that perspective, but this isn't much
> different from Xenomai and RTAI having similar kernel version
> constraints. So, yes, having some PREEMPT_RT integration would be nice,
> at least to show that it is possible.
> 

And the pending EtherCAT patch which has both kernel version constraints
and supports only a few specific Ethernet adapters.

Having the new "kernel extensions" build support is a nice feature.

And BR does target building embedded systems where "strange and unusual"
kernel extensions are sometimes a way-of-life, but...

Will the project need a general policy of just how "strange and unusual"
will be considered for inclusion in the build system?

My reason for posing this question early in the life-time of the
"kernel extensions" feature is the on-going maintenace chore of 
these specializations.

Often, it will take the actual downloading and examination of each
source package by someone who is also familiar with that BR patch
to do a "version bump" of that kernel extension package.

Maybe a policy of whoever proposes the extension also accept the
responsibility of maintaining its "version bumps"?
And then if a kernel extension gets too old or becomes unusable,
let the normal deprecated/remove maintenace routine get rid of it.

I can't see that expecting the usual maintainers of the BR system
to take on these extra chores of maintaining the "specials" is 
reasonable.

Perhaps this question is too early, but worth bookmarking until
we see just how many one-user, one-time, things get proposed.

Mike
> Regards,
> 
> Thomas

[Buildroot] Real time Linux implementation

[Thomas Petazzoni]

Hello,

Le Sat, 3 Dec 2011 04:53:41 -0600,
"Michael S. Zick" <minimod@morethan.org> a ?crit :

> And the pending EtherCAT patch which has both kernel version constraints
> and supports only a few specific Ethernet adapters.
> 
> Having the new "kernel extensions" build support is a nice feature.
> 
> And BR does target building embedded systems where "strange and unusual"
> kernel extensions are sometimes a way-of-life, but...

Correct.

> Will the project need a general policy of just how "strange and unusual"
> will be considered for inclusion in the build system?
> 
> My reason for posing this question early in the life-time of the
> "kernel extensions" feature is the on-going maintenace chore of 
> these specializations.

For all these kernel extensions, Buildroot does not even try to make
sure that the kernel selected by the user is compatible with the kernel
extension that was enabled. We leave that work to the user, simply
because it is impossible to keep track of which kernel extension
supports which kernel version on which architecture.

I think that Buildroot is merely a tool to automate the build process
of an embedded Linux system. It doesn't, and it will never, replace the
engineer that makes decision on using Xenomai version X, knowing that
it supports the kernel version Y that he is using on his embedded
device. Buildroot only helps here by making the build process
automated, *once* the engineer has made the right choices in terms of
versions (kernel version and kernel extension version).

For extensions like Xenomai and RTAI, I think having Buildroot
integration make sense because those extensions have userspace parts
that need to be compiled and integrated to the root filesystem.

For something like PREEMPT_RT, which is "only" a kernel patch, the need
for integration in Buildroot is a bit less important, in my opinion.
You can just manage your kernel tree outside of Buildroot (choosing the
right kernel version, applying the right PREEMPT_RT patch set), and
then tell Buildroot to use that particular kernel source tree.

Another illustration of this is that Buildroot does not try to enforce
that Netfilter is enabled in the kernel when the iptables userspace
package is enabled, does not try to ensure that Wireless support is
enabled in the kernel when the wireless userspace tools package is
enabled, etc. And I really think it's good not to go down this road,
because it would create an unmaintainable mess.

> Perhaps this question is too early, but worth bookmarking until
> we see just how many one-user, one-time, things get proposed.

I think there's a question of orthogonality here. If the new package or
extension is completely orthogonal to what exists and its integration
does not require major infrastructure changes, then we can very much
integrate everything that gets proposed, and if it turns out a year or
two later that it is unmaintained, we can simply get rid of it.
However, if the integration of the package or extension requires deep
changes of Buildroot internals, then of course more thought is needed
to ensure that it is really worth it.

Regarding igh-ethercat, I think the solution is not too bad. The
packaging itself does not depend on a specific kernel version (i.e
Buildroot does not try to make sure that you have selected a kernel
version for which igh-ethercat has driver patches), it's up to the user
to ensure this.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Real time Linux implementation

[Michael S. Zick]

On Sat December 3 2011, Thomas Petazzoni wrote:
> > Will the project need a general policy of just how "strange and unusual"
> > will be considered for inclusion in the build system?
> > 
> > My reason for posing this question early in the life-time of the
> > "kernel extensions" feature is the on-going maintenace chore of 
> > these specializations.
> 
> For all these kernel extensions, Buildroot does not even try to make
> sure that the kernel selected by the user is compatible with the kernel
> extension that was enabled. We leave that work to the user, simply
> because it is impossible to keep track of which kernel extension
> supports which kernel version on which architecture.
> 
> I think that Buildroot is merely a tool to automate the build process
> of an embedded Linux system. It doesn't, and it will never, replace the
> engineer that makes decision on using Xenomai version X, knowing that
> it supports the kernel version Y that he is using on his embedded
> device. Buildroot only helps here by making the build process
> automated, *once* the engineer has made the right choices in terms of
> versions (kernel version and kernel extension version).
> 

Sounds like a policy statement to me.
Buildroot != Automated engineering

Maybe even distill that down to a (polite) "user is on their own here"
comment at the head of the kernel extensions menu branch.
;-)

Since BR does provide a great degree of build automation, a new user
might just assume that it is also fully checking package compatability.
(It doesn't and I agree that it shouldn't - different job.)

Mike

[Buildroot] Real time Linux implementation

[Julien Boibessot]

On 03/12/2011 12:08, Thomas Petazzoni wrote:
> For extensions like Xenomai and RTAI, I think having Buildroot
> integration make sense because those extensions have userspace parts
> that need to be compiled and integrated to the root filesystem.
>
> For something like PREEMPT_RT, which is "only" a kernel patch, the need
> for integration in Buildroot is a bit less important, in my opinion.
> You can just manage your kernel tree outside of Buildroot (choosing the
> right kernel version, applying the right PREEMPT_RT patch set), and
> then tell Buildroot to use that particular kernel source tree.

Thomas is right. To use PREEMPT_RT with Buildroot a:
    BR2_LINUX_KERNEL_CUSTOM_VERSION=y
    BR2_LINUX_KERNEL_VERSION="3.0.12"
   
BR2_LINUX_KERNEL_PATCH="http://www.kernel.org/pub/linux/kernel/projects/rt/3.0/patch-3.0.12-rt29.patch.bz2"
is enough.
Ok, this implies that the user knows what he wants to do, but this is
generally the case when using PREEMPT-RT as this patch is only available
for a restricted number of Linux kernel versions.

Regards,
Julien

[Buildroot] Real time Linux implementation

[Thomas Petazzoni]

Le Wed, 07 Dec 2011 09:34:49 +0100,
Julien Boibessot <julien.boibessot@free.fr> a ?crit :

> Thomas is right. To use PREEMPT_RT with Buildroot a:
>     BR2_LINUX_KERNEL_CUSTOM_VERSION=y
>     BR2_LINUX_KERNEL_VERSION="3.0.12"
>    
> BR2_LINUX_KERNEL_PATCH="http://www.kernel.org/pub/linux/kernel/projects/rt/3.0/patch-3.0.12-rt29.patch.bz2"
> is enough.
> Ok, this implies that the user knows what he wants to do, but this is
> generally the case when using PREEMPT-RT as this patch is only
> available for a restricted number of Linux kernel versions.

Agreed.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com