Discussion:
BBB + PREEMPT_RT
(too old to reply)
q***@public.gmane.org
2014-02-21 08:20:39 UTC
Permalink
I am trying to figure out how to create a kernel for the BBB that supports
PREEMPT_RT. It's kind of strange that the BBB's default kernel does not
even have PREEMPT activated. Such a board doesn't fit to many embedded
applications where we need at least some kind of determinism. It is even
worse, that nobody seems to care about this problem. Contrary to that, the
Raspberry PI's standard kernel has PREEMPT activacted from the very
beginning.

I have tested Robert Nelsons kernel 3.8.13-r9
(https://github.com/beagleboard/kernel/tree/3.8-rt). It does not have
PREEMPT_RT activated by default. When doing so, it does not boot. But
activating PREEMPT does work. However, development of this branch has
stopped several months ago. The official source for RT Linux (3.8.13) has
evolved since then. Meanwhile there's an rt17 patch set
(https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did anybody
give this a try? Does it work with the BBB?


--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Bas Laarhoven
2014-02-21 09:54:20 UTC
Permalink
On 21-2-2014 9:20, quikcjack-***@public.gmane.org wrote:
> I am trying to figure out how to create a kernel for the BBB that
> supports PREEMPT_RT. It's kind of strange that the BBB's default
> kernel does not even have PREEMPT activated. Such a board doesn't fit
> to many embedded applications where we need at least some kind of
> determinism. It is even worse, that nobody seems to care about this
> problem. Contrary to that, the Raspberry PI's standard kernel has
> PREEMPT activacted from the very beginning.

A long, long time ago (with the original BeagleBone) I tried this, but
ran into problems with the NIC driver. There's probably a reason it's
not enabled by default! Feel free to try though, maybe some problems
have been fixed since then.

-- Bas

>
> I have tested Robert Nelsons kernel 3.8.13-r9
> (https://github.com/beagleboard/kernel/tree/3.8-rt). It does not have
> PREEMPT_RT activated by default. When doing so, it does not boot. But
> activating PREEMPT does work. However, development of this branch has
> stopped several months ago. The official source for RT Linux (3.8.13)
> has evolved since then. Meanwhile there's an rt17 patch set
> (https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did
> anybody give this a try? Does it work with the BBB?
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
> For more options, visit https://groups.google.com/groups/opt_out.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
David Goodenough
2014-02-21 10:03:24 UTC
Permalink
On Friday 21 February 2014 00:20:39 quikcjack-***@public.gmane.org wrote:
> I am trying to figure out how to create a kernel for the BBB that supports
> PREEMPT_RT. It's kind of strange that the BBB's default kernel does not
> even have PREEMPT activated. Such a board doesn't fit to many embedded
> applications where we need at least some kind of determinism. It is even
> worse, that nobody seems to care about this problem. Contrary to that, the
> Raspberry PI's standard kernel has PREEMPT activacted from the very
> beginning.
>
> I have tested Robert Nelsons kernel 3.8.13-r9
> (https://github.com/beagleboard/kernel/tree/3.8-rt). It does not have
> PREEMPT_RT activated by default. When doing so, it does not boot. But
> activating PREEMPT does work. However, development of this branch has
> stopped several months ago. The official source for RT Linux (3.8.13) has
> evolved since then. Meanwhile there's an rt17 patch set
> (https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did anybody
> give this a try? Does it work with the BBB?
Surely the point of the Beaglebone, or rather its processor, is that you
do not need to put the time critical bits on the main processor, you put
them in the PRUSS processors.

David

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Giuseppe Iellamo
2014-02-21 11:27:01 UTC
Permalink
Or just try Xenomai...

https://github.com/cdsteinkuehler/linux-dev/tree/3.8.13-bone39-xenomai


Il giorno venerdì 21 febbraio 2014 11:03:24 UTC+1, David Goodenough ha
scritto:
>
> On Friday 21 February 2014 00:20:39 quik...-***@public.gmane.org <javascript:>wrote:
> > I am trying to figure out how to create a kernel for the BBB that
> supports
> > PREEMPT_RT. It's kind of strange that the BBB's default kernel does not
> > even have PREEMPT activated. Such a board doesn't fit to many embedded
> > applications where we need at least some kind of determinism. It is even
> > worse, that nobody seems to care about this problem. Contrary to that,
> the
> > Raspberry PI's standard kernel has PREEMPT activacted from the very
> > beginning.
> >
> > I have tested Robert Nelsons kernel 3.8.13-r9
> > (https://github.com/beagleboard/kernel/tree/3.8-rt). It does not have
> > PREEMPT_RT activated by default. When doing so, it does not boot. But
> > activating PREEMPT does work. However, development of this branch has
> > stopped several months ago. The official source for RT Linux (3.8.13)
> has
> > evolved since then. Meanwhile there's an rt17 patch set
> > (https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did anybody
> > give this a try? Does it work with the BBB?
> Surely the point of the Beaglebone, or rather its processor, is that you
> do not need to put the time critical bits on the main processor, you put
> them in the PRUSS processors.
>
> David
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
David Goodenough
2014-02-21 14:23:33 UTC
Permalink
On Friday 21 February 2014 03:27:01 Giuseppe Iellamo wrote:
> Or just try Xenomai...
>
> https://github.com/cdsteinkuehler/linux-dev/tree/3.8.13-bone39-xenomai
>
While this may be answer to the original poster's question, it is of no
relevance to my point which is that the Sitara processor encourages a
different way of solving the real time problem by having PRUSS processors
in the SoC to do the real time bits independently of the main processor

David
>
> Il giorno venerdì 21 febbraio 2014 11:03:24 UTC+1, David Goodenough ha
>
> scritto:
> > On Friday 21 February 2014 00:20:39 quik...-***@public.gmane.org <javascript:>wrote:
> > > I am trying to figure out how to create a kernel for the BBB that
> >
> > supports
> >
> > > PREEMPT_RT. It's kind of strange that the BBB's default kernel does not
> > > even have PREEMPT activated. Such a board doesn't fit to many embedded
> > > applications where we need at least some kind of determinism. It is even
> > > worse, that nobody seems to care about this problem. Contrary to that,
> >
> > the
> >
> > > Raspberry PI's standard kernel has PREEMPT activacted from the very
> > > beginning.
> > >
> > > I have tested Robert Nelsons kernel 3.8.13-r9
> > > (https://github.com/beagleboard/kernel/tree/3.8-rt). It does not have
> > > PREEMPT_RT activated by default. When doing so, it does not boot. But
> > > activating PREEMPT does work. However, development of this branch has
> > > stopped several months ago. The official source for RT Linux (3.8.13)
> >
> > has
> >
> > > evolved since then. Meanwhile there's an rt17 patch set
> > > (https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did anybody
> > > give this a try? Does it work with the BBB?
> >
> > Surely the point of the Beaglebone, or rather its processor, is that you
> > do not need to put the time critical bits on the main processor, you put
> > them in the PRUSS processors.
> >
> > David

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
q***@public.gmane.org
2014-02-24 16:47:11 UTC
Permalink
Only PREEMPT_RT allows access to the full Linux functionality. Xenomai uses
a dual kernel concept which is very limited. All custom device drivers need
be design to fit into the Xenomai concept which makes things even worse.
The performance gain of Xenomai compared to that of PREEMPt_RT is
negligible in most cases.


Am Freitag, 21. Februar 2014 12:27:01 UTC+1 schrieb Giuseppe Iellamo:
>
> Or just try Xenomai...
>
> https://github.com/cdsteinkuehler/linux-dev/tree/3.8.13-bone39-xenomai
>
>
> Il giorno venerdì 21 febbraio 2014 11:03:24 UTC+1, David Goodenough ha
> scritto:
>>
>> On Friday 21 February 2014 00:20:39 quik...-***@public.gmane.org wrote:
>> > I am trying to figure out how to create a kernel for the BBB that
>> supports
>> > PREEMPT_RT. It's kind of strange that the BBB's default kernel does not
>> > even have PREEMPT activated. Such a board doesn't fit to many embedded
>> > applications where we need at least some kind of determinism. It is
>> even
>> > worse, that nobody seems to care about this problem. Contrary to that,
>> the
>> > Raspberry PI's standard kernel has PREEMPT activacted from the very
>> > beginning.
>> >
>> > I have tested Robert Nelsons kernel 3.8.13-r9
>> > (https://github.com/beagleboard/kernel/tree/3.8-rt). It does not have
>> > PREEMPT_RT activated by default. When doing so, it does not boot. But
>> > activating PREEMPT does work. However, development of this branch has
>> > stopped several months ago. The official source for RT Linux (3.8.13)
>> has
>> > evolved since then. Meanwhile there's an rt17 patch set
>> > (https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did
>> anybody
>> > give this a try? Does it work with the BBB?
>> Surely the point of the Beaglebone, or rather its processor, is that you
>> do not need to put the time critical bits on the main processor, you put
>> them in the PRUSS processors.
>>
>> David
>>
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Charles Steinkuehler
2014-02-24 17:30:51 UTC
Permalink
Be careful of applying x86 experience to the ARM. PREEMPT_RT requires
well written driver code that is "high-performance SMP friendly" in
order to run well. PREEMPT_RT on the x86 works so well because a *LOT*
of smart people have been working very hard to get maximum performance
out of the multi-core CPUs that ship in virtually every new system these
days.

ARM systems, on the other hand, are riddled with vendor supplied device
drivers that hopefully work well and if you're lucky weren't written by
the summer intern. The ARM situation _is_ getting better, but IMHO
PREEMPT_RT on the ARM is still hit-and-miss. It will work quite well in
some situations, and have horrible performance on similar but
not-quite-identical setups.

That said, while Xenomai offers better bounded performance figures,
PREEMPT_RT is perfectly fine for a large class of problems and as you
mentioned you get access to the full suite of Linux services.

Unless I missed it, you never said exactly _what_ you are trying to do,
you simply started off by complaining that the kernel wasn't configured
by default the way that you wanted it. So go compile a kernel, and if
you're asking for advice, please provide specifics on exactly what you
are trying to do and any limitations on your solution space.

Also, make sure you test any PREEMPT_ based kernel to determine your
worst-case performance. When I was looking into this some time ago, the
PREEMPT_RT patches wouldn't even apply to the BeagleBone kernel, and
using the built-in CONFIG_PREEMPT setting I was seeing latencies in the
hundreds of mS (yes that is tenths of seconds!). I believe things have
gotten much better, but you'll need to test to know if your setup will
provide the performance you require.

On 2/24/2014 10:47 AM, quikcjack-***@public.gmane.org wrote:
> Only PREEMPT_RT allows access to the full Linux functionality. Xenomai uses
> a dual kernel concept which is very limited. All custom device drivers need
> be design to fit into the Xenomai concept which makes things even worse.
> The performance gain of Xenomai compared to that of PREEMPt_RT is
> negligible in most cases.
>
>
> Am Freitag, 21. Februar 2014 12:27:01 UTC+1 schrieb Giuseppe Iellamo:
>>
>> Or just try Xenomai...
>>
>> https://github.com/cdsteinkuehler/linux-dev/tree/3.8.13-bone39-xenomai
>>
>>
>> Il giorno venerdì 21 febbraio 2014 11:03:24 UTC+1, David Goodenough ha
>> scritto:
>>>
>>> On Friday 21 February 2014 00:20:39 quik...-***@public.gmane.org wrote:
>>>> I am trying to figure out how to create a kernel for the BBB that
>>> supports
>>>> PREEMPT_RT. It's kind of strange that the BBB's default kernel does not
>>>> even have PREEMPT activated. Such a board doesn't fit to many embedded
>>>> applications where we need at least some kind of determinism. It is
>>> even
>>>> worse, that nobody seems to care about this problem. Contrary to that,
>>> the
>>>> Raspberry PI's standard kernel has PREEMPT activacted from the very
>>>> beginning.
>>>>
>>>> I have tested Robert Nelsons kernel 3.8.13-r9
>>>> (https://github.com/beagleboard/kernel/tree/3.8-rt). It does not have
>>>> PREEMPT_RT activated by default. When doing so, it does not boot. But
>>>> activating PREEMPT does work. However, development of this branch has
>>>> stopped several months ago. The official source for RT Linux (3.8.13)
>>> has
>>>> evolved since then. Meanwhile there's an rt17 patch set
>>>> (https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did
>>> anybody
>>>> give this a try? Does it work with the BBB?
>>> Surely the point of the Beaglebone, or rather its processor, is that you
>>> do not need to put the time critical bits on the main processor, you put
>>> them in the PRUSS processors.
>>>
>>> David
>>>
>>
>


--
Charles Steinkuehler
charles-***@public.gmane.org

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
q***@public.gmane.org
2014-02-26 09:11:22 UTC
Permalink
Hi Charles,

the PREEMPT_RT patches can now be applied to the BBB kernel. As John3909
suggested there is a ready to use patch script available from OSADL.
Compiling a BBB kernel 3.12.10-rt15 is quick and easy. But unfortunately,
it requires the use of kernel 3.12.x which causes problems with the GPMC as
documented at
https://groups.google.com/forum/#!searchin/beagleboard/gpmc/beagleboard/KOHLJI1NUTA/8wrsV_ZodDUJ.

In the default BBB kernel there is no "built-in" PREEMPT option. Without
that Linux cannot be used for any time critical application and latencies a
very bad. Contrary to that the Raspberry PI's default kernel had PREEMPT
activated from the very beginning and does provide some form of determinism
out of the box.

What we need is a default kernel that has at least support for the simple
PREEMPT option. Yes, there are custom drivers and they need to fit into the
concept. But that is working perfectly for the Raspberry PI which
definitely uses custom firmware and drivers. The BBB seems to be far behind
that.



Am Montag, 24. Februar 2014 18:30:51 UTC+1 schrieb Charles Steinkuehler:
>
> Be careful of applying x86 experience to the ARM. PREEMPT_RT requires
> well written driver code that is "high-performance SMP friendly" in
> order to run well. PREEMPT_RT on the x86 works so well because a *LOT*
> of smart people have been working very hard to get maximum performance
> out of the multi-core CPUs that ship in virtually every new system these
> days.
>
> ARM systems, on the other hand, are riddled with vendor supplied device
> drivers that hopefully work well and if you're lucky weren't written by
> the summer intern. The ARM situation _is_ getting better, but IMHO
> PREEMPT_RT on the ARM is still hit-and-miss. It will work quite well in
> some situations, and have horrible performance on similar but
> not-quite-identical setups.
>
> That said, while Xenomai offers better bounded performance figures,
> PREEMPT_RT is perfectly fine for a large class of problems and as you
> mentioned you get access to the full suite of Linux services.
>
> Unless I missed it, you never said exactly _what_ you are trying to do,
> you simply started off by complaining that the kernel wasn't configured
> by default the way that you wanted it. So go compile a kernel, and if
> you're asking for advice, please provide specifics on exactly what you
> are trying to do and any limitations on your solution space.
>
> Also, make sure you test any PREEMPT_ based kernel to determine your
> worst-case performance. When I was looking into this some time ago, the
> PREEMPT_RT patches wouldn't even apply to the BeagleBone kernel, and
> using the built-in CONFIG_PREEMPT setting I was seeing latencies in the
> hundreds of mS (yes that is tenths of seconds!). I believe things have
> gotten much better, but you'll need to test to know if your setup will
> provide the performance you require.
>
> On 2/24/2014 10:47 AM, quik...-***@public.gmane.org <javascript:> wrote:
> > Only PREEMPT_RT allows access to the full Linux functionality. Xenomai
> uses
> > a dual kernel concept which is very limited. All custom device drivers
> need
> > be design to fit into the Xenomai concept which makes things even worse.
> > The performance gain of Xenomai compared to that of PREEMPt_RT is
> > negligible in most cases.
> >
> >
> > Am Freitag, 21. Februar 2014 12:27:01 UTC+1 schrieb Giuseppe Iellamo:
> >>
> >> Or just try Xenomai...
> >>
> >> https://github.com/cdsteinkuehler/linux-dev/tree/3.8.13-bone39-xenomai
> >>
> >>
> >> Il giorno venerdì 21 febbraio 2014 11:03:24 UTC+1, David Goodenough ha
> >> scritto:
> >>>
> >>> On Friday 21 February 2014 00:20:39 quik...-***@public.gmane.org wrote:
> >>>> I am trying to figure out how to create a kernel for the BBB that
> >>> supports
> >>>> PREEMPT_RT. It's kind of strange that the BBB's default kernel does
> not
> >>>> even have PREEMPT activated. Such a board doesn't fit to many
> embedded
> >>>> applications where we need at least some kind of determinism. It is
> >>> even
> >>>> worse, that nobody seems to care about this problem. Contrary to
> that,
> >>> the
> >>>> Raspberry PI's standard kernel has PREEMPT activacted from the very
> >>>> beginning.
> >>>>
> >>>> I have tested Robert Nelsons kernel 3.8.13-r9
> >>>> (https://github.com/beagleboard/kernel/tree/3.8-rt). It does not
> have
> >>>> PREEMPT_RT activated by default. When doing so, it does not boot. But
> >>>> activating PREEMPT does work. However, development of this branch has
> >>>> stopped several months ago. The official source for RT Linux (3.8.13)
> >>> has
> >>>> evolved since then. Meanwhile there's an rt17 patch set
> >>>> (https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did
> >>> anybody
> >>>> give this a try? Does it work with the BBB?
> >>> Surely the point of the Beaglebone, or rather its processor, is that
> you
> >>> do not need to put the time critical bits on the main processor, you
> put
> >>> them in the PRUSS processors.
> >>>
> >>> David
> >>>
> >>
> >
>
>
> --
> Charles Steinkuehler
> cha...-***@public.gmane.org <javascript:>
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Charles Steinkuehler
2014-02-26 12:21:58 UTC
Permalink
There's PREEMPT_RT, and there's PREEMPT. *ALL* Linux kernels have
PREEMPT available now. It sounds like you're just complaining that the
kernel was built with a different option than you want. Simply rebuild
the kernel and set CONFIG_PREEMPT instead of CONFIG_PREEMPT_VOLUNTARY:

https://github.com/RobertCNelson/linux-dev/blob/am33x-v3.8/patches/defconfig#L467

Or if you're requesting a change to the default kernel configuration,
you're going about it in kind of a round-about way.

On 2/26/2014 3:11 AM, quikcjack-***@public.gmane.org wrote:
> Hi Charles,
>
> the PREEMPT_RT patches can now be applied to the BBB kernel. As John3909
> suggested there is a ready to use patch script available from OSADL.
> Compiling a BBB kernel 3.12.10-rt15 is quick and easy. But unfortunately,
> it requires the use of kernel 3.12.x which causes problems with the GPMC as
> documented at
> https://groups.google.com/forum/#!searchin/beagleboard/gpmc/beagleboard/KOHLJI1NUTA/8wrsV_ZodDUJ.
>
> In the default BBB kernel there is no "built-in" PREEMPT option. Without
> that Linux cannot be used for any time critical application and latencies a
> very bad. Contrary to that the Raspberry PI's default kernel had PREEMPT
> activated from the very beginning and does provide some form of determinism
> out of the box.
>
> What we need is a default kernel that has at least support for the simple
> PREEMPT option. Yes, there are custom drivers and they need to fit into the
> concept. But that is working perfectly for the Raspberry PI which
> definitely uses custom firmware and drivers. The BBB seems to be far behind
> that.
>
>
>
> Am Montag, 24. Februar 2014 18:30:51 UTC+1 schrieb Charles Steinkuehler:
>>
>> Be careful of applying x86 experience to the ARM. PREEMPT_RT requires
>> well written driver code that is "high-performance SMP friendly" in
>> order to run well. PREEMPT_RT on the x86 works so well because a *LOT*
>> of smart people have been working very hard to get maximum performance
>> out of the multi-core CPUs that ship in virtually every new system these
>> days.
>>
>> ARM systems, on the other hand, are riddled with vendor supplied device
>> drivers that hopefully work well and if you're lucky weren't written by
>> the summer intern. The ARM situation _is_ getting better, but IMHO
>> PREEMPT_RT on the ARM is still hit-and-miss. It will work quite well in
>> some situations, and have horrible performance on similar but
>> not-quite-identical setups.
>>
>> That said, while Xenomai offers better bounded performance figures,
>> PREEMPT_RT is perfectly fine for a large class of problems and as you
>> mentioned you get access to the full suite of Linux services.
>>
>> Unless I missed it, you never said exactly _what_ you are trying to do,
>> you simply started off by complaining that the kernel wasn't configured
>> by default the way that you wanted it. So go compile a kernel, and if
>> you're asking for advice, please provide specifics on exactly what you
>> are trying to do and any limitations on your solution space.
>>
>> Also, make sure you test any PREEMPT_ based kernel to determine your
>> worst-case performance. When I was looking into this some time ago, the
>> PREEMPT_RT patches wouldn't even apply to the BeagleBone kernel, and
>> using the built-in CONFIG_PREEMPT setting I was seeing latencies in the
>> hundreds of mS (yes that is tenths of seconds!). I believe things have
>> gotten much better, but you'll need to test to know if your setup will
>> provide the performance you require.
>>
>> On 2/24/2014 10:47 AM, quik...-***@public.gmane.org <javascript:> wrote:
>>> Only PREEMPT_RT allows access to the full Linux functionality. Xenomai
>> uses
>>> a dual kernel concept which is very limited. All custom device drivers
>> need
>>> be design to fit into the Xenomai concept which makes things even worse.
>>> The performance gain of Xenomai compared to that of PREEMPt_RT is
>>> negligible in most cases.
>>>
>>>
>>> Am Freitag, 21. Februar 2014 12:27:01 UTC+1 schrieb Giuseppe Iellamo:
>>>>
>>>> Or just try Xenomai...
>>>>
>>>> https://github.com/cdsteinkuehler/linux-dev/tree/3.8.13-bone39-xenomai
>>>>
>>>>
>>>> Il giorno venerdì 21 febbraio 2014 11:03:24 UTC+1, David Goodenough ha
>>>> scritto:
>>>>>
>>>>> On Friday 21 February 2014 00:20:39 quik...-***@public.gmane.org wrote:
>>>>>> I am trying to figure out how to create a kernel for the BBB that
>>>>> supports
>>>>>> PREEMPT_RT. It's kind of strange that the BBB's default kernel does
>> not
>>>>>> even have PREEMPT activated. Such a board doesn't fit to many
>> embedded
>>>>>> applications where we need at least some kind of determinism. It is
>>>>> even
>>>>>> worse, that nobody seems to care about this problem. Contrary to
>> that,
>>>>> the
>>>>>> Raspberry PI's standard kernel has PREEMPT activacted from the very
>>>>>> beginning.
>>>>>>
>>>>>> I have tested Robert Nelsons kernel 3.8.13-r9
>>>>>> (https://github.com/beagleboard/kernel/tree/3.8-rt). It does not
>> have
>>>>>> PREEMPT_RT activated by default. When doing so, it does not boot. But
>>>>>> activating PREEMPT does work. However, development of this branch has
>>>>>> stopped several months ago. The official source for RT Linux (3.8.13)
>>>>> has
>>>>>> evolved since then. Meanwhile there's an rt17 patch set
>>>>>> (https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did
>>>>> anybody
>>>>>> give this a try? Does it work with the BBB?
>>>>> Surely the point of the Beaglebone, or rather its processor, is that
>> you
>>>>> do not need to put the time critical bits on the main processor, you
>> put
>>>>> them in the PRUSS processors.
>>>>>
>>>>> David
>>>>>
>>>>
>>>
>>
>>
>> --
>> Charles Steinkuehler
>> cha...-***@public.gmane.org <javascript:>
>>
>


--
Charles Steinkuehler
charles-***@public.gmane.org

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
q***@public.gmane.org
2014-02-26 13:59:45 UTC
Permalink
Of course every user can create his own kernel coniguration or even modify
the Linux kernel in any way he wants. But if there is any problem he's
beeing left alone. I think it would be much better to have a default kernel
configuration which at least provides simple PREEMPT support. That might
help people to fight against most simple latency problems.


Am Mittwoch, 26. Februar 2014 13:21:58 UTC+1 schrieb Charles Steinkuehler:
>
> There's PREEMPT_RT, and there's PREEMPT. *ALL* Linux kernels have
> PREEMPT available now. It sounds like you're just complaining that the
> kernel was built with a different option than you want. Simply rebuild
> the kernel and set CONFIG_PREEMPT instead of CONFIG_PREEMPT_VOLUNTARY:
>
>
> https://github.com/RobertCNelson/linux-dev/blob/am33x-v3.8/patches/defconfig#L467
>
> Or if you're requesting a change to the default kernel configuration,
> you're going about it in kind of a round-about way.
>
> On 2/26/2014 3:11 AM, quik...-***@public.gmane.org <javascript:> wrote:
> > Hi Charles,
> >
> > the PREEMPT_RT patches can now be applied to the BBB kernel. As John3909
> > suggested there is a ready to use patch script available from OSADL.
> > Compiling a BBB kernel 3.12.10-rt15 is quick and easy. But
> unfortunately,
> > it requires the use of kernel 3.12.x which causes problems with the GPMC
> as
> > documented at
> >
> https://groups.google.com/forum/#!searchin/beagleboard/gpmc/beagleboard/KOHLJI1NUTA/8wrsV_ZodDUJ.
>
> >
> > In the default BBB kernel there is no "built-in" PREEMPT option. Without
> > that Linux cannot be used for any time critical application and
> latencies a
> > very bad. Contrary to that the Raspberry PI's default kernel had PREEMPT
> > activated from the very beginning and does provide some form of
> determinism
> > out of the box.
> >
> > What we need is a default kernel that has at least support for the
> simple
> > PREEMPT option. Yes, there are custom drivers and they need to fit into
> the
> > concept. But that is working perfectly for the Raspberry PI which
> > definitely uses custom firmware and drivers. The BBB seems to be far
> behind
> > that.
> >
> >
> >
> > Am Montag, 24. Februar 2014 18:30:51 UTC+1 schrieb Charles Steinkuehler:
> >>
> >> Be careful of applying x86 experience to the ARM. PREEMPT_RT requires
> >> well written driver code that is "high-performance SMP friendly" in
> >> order to run well. PREEMPT_RT on the x86 works so well because a *LOT*
> >> of smart people have been working very hard to get maximum performance
> >> out of the multi-core CPUs that ship in virtually every new system
> these
> >> days.
> >>
> >> ARM systems, on the other hand, are riddled with vendor supplied device
> >> drivers that hopefully work well and if you're lucky weren't written by
> >> the summer intern. The ARM situation _is_ getting better, but IMHO
> >> PREEMPT_RT on the ARM is still hit-and-miss. It will work quite well
> in
> >> some situations, and have horrible performance on similar but
> >> not-quite-identical setups.
> >>
> >> That said, while Xenomai offers better bounded performance figures,
> >> PREEMPT_RT is perfectly fine for a large class of problems and as you
> >> mentioned you get access to the full suite of Linux services.
> >>
> >> Unless I missed it, you never said exactly _what_ you are trying to do,
> >> you simply started off by complaining that the kernel wasn't configured
> >> by default the way that you wanted it. So go compile a kernel, and if
> >> you're asking for advice, please provide specifics on exactly what you
> >> are trying to do and any limitations on your solution space.
> >>
> >> Also, make sure you test any PREEMPT_ based kernel to determine your
> >> worst-case performance. When I was looking into this some time ago,
> the
> >> PREEMPT_RT patches wouldn't even apply to the BeagleBone kernel, and
> >> using the built-in CONFIG_PREEMPT setting I was seeing latencies in the
> >> hundreds of mS (yes that is tenths of seconds!). I believe things have
> >> gotten much better, but you'll need to test to know if your setup will
> >> provide the performance you require.
> >>
> >> On 2/24/2014 10:47 AM, quik...-***@public.gmane.org <javascript:> wrote:
> >>> Only PREEMPT_RT allows access to the full Linux functionality. Xenomai
> >> uses
> >>> a dual kernel concept which is very limited. All custom device drivers
> >> need
> >>> be design to fit into the Xenomai concept which makes things even
> worse.
> >>> The performance gain of Xenomai compared to that of PREEMPt_RT is
> >>> negligible in most cases.
> >>>
> >>>
> >>> Am Freitag, 21. Februar 2014 12:27:01 UTC+1 schrieb Giuseppe Iellamo:
> >>>>
> >>>> Or just try Xenomai...
> >>>>
> >>>>
> https://github.com/cdsteinkuehler/linux-dev/tree/3.8.13-bone39-xenomai
> >>>>
> >>>>
> >>>> Il giorno venerdì 21 febbraio 2014 11:03:24 UTC+1, David Goodenough
> ha
> >>>> scritto:
> >>>>>
> >>>>> On Friday 21 February 2014 00:20:39 quik...-***@public.gmane.org wrote:
> >>>>>> I am trying to figure out how to create a kernel for the BBB that
> >>>>> supports
> >>>>>> PREEMPT_RT. It's kind of strange that the BBB's default kernel does
> >> not
> >>>>>> even have PREEMPT activated. Such a board doesn't fit to many
> >> embedded
> >>>>>> applications where we need at least some kind of determinism. It is
> >>>>> even
> >>>>>> worse, that nobody seems to care about this problem. Contrary to
> >> that,
> >>>>> the
> >>>>>> Raspberry PI's standard kernel has PREEMPT activacted from the very
> >>>>>> beginning.
> >>>>>>
> >>>>>> I have tested Robert Nelsons kernel 3.8.13-r9
> >>>>>> (https://github.com/beagleboard/kernel/tree/3.8-rt). It does not
> >> have
> >>>>>> PREEMPT_RT activated by default. When doing so, it does not boot.
> But
> >>>>>> activating PREEMPT does work. However, development of this branch
> has
> >>>>>> stopped several months ago. The official source for RT Linux
> (3.8.13)
> >>>>> has
> >>>>>> evolved since then. Meanwhile there's an rt17 patch set
> >>>>>> (https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did
> >>>>> anybody
> >>>>>> give this a try? Does it work with the BBB?
> >>>>> Surely the point of the Beaglebone, or rather its processor, is that
> >> you
> >>>>> do not need to put the time critical bits on the main processor, you
> >> put
> >>>>> them in the PRUSS processors.
> >>>>>
> >>>>> David
> >>>>>
> >>>>
> >>>
> >>
> >>
> >> --
> >> Charles Steinkuehler
> >> cha...-***@public.gmane.org <javascript:>
> >>
> >
>
>
> --
> Charles Steinkuehler
> cha...-***@public.gmane.org <javascript:>
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Robert Nelson
2014-02-26 14:23:01 UTC
Permalink
On Wed, Feb 26, 2014 at 7:59 AM, <quikcjack-***@public.gmane.org> wrote:
> Of course every user can create his own kernel coniguration or even modify
> the Linux kernel in any way he wants. But if there is any problem he's
> beeing left alone. I think it would be much better to have a default kernel
> configuration which at least provides simple PREEMPT support. That might
> help people to fight against most simple latency problems.


Notice how the github account says "RobertCNelson"? Your welcome to
fork that project and push kernel/image with your modifications. I'm
not psychically forcing my config choices down people's throat.
Everything is setup to easily allow you to rebuild/modify/etc
everything. Maybe I just give too many options. So I have my reasons
for leaving PREEMPT disabled by default and on an old tested v3.8
kernel, the last thing i'm going to do is radically change the config.
To much of a risk on a kernel in maintenance only mode at this point.

Regards,

--
Robert Nelson
http://www.rcn-ee.com/

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
q***@public.gmane.org
2014-02-26 15:51:38 UTC
Permalink
I fully understand why it is a bad idea to change the defaul kernel
configuration for kernel 3.8. But I think it might be possible to consider
such a change for kernel 3.12 or a future kernel version. I'm sure there
are lots of people out there who would like that.


Am Mittwoch, 26. Februar 2014 15:23:01 UTC+1 schrieb RobertCNelson:
>
> On Wed, Feb 26, 2014 at 7:59 AM, <quik...-***@public.gmane.org <javascript:>>
> wrote:
> > Of course every user can create his own kernel coniguration or even
> modify
> > the Linux kernel in any way he wants. But if there is any problem he's
> > beeing left alone. I think it would be much better to have a default
> kernel
> > configuration which at least provides simple PREEMPT support. That might
> > help people to fight against most simple latency problems.
>
>
> Notice how the github account says "RobertCNelson"? Your welcome to
> fork that project and push kernel/image with your modifications. I'm
> not psychically forcing my config choices down people's throat.
> Everything is setup to easily allow you to rebuild/modify/etc
> everything. Maybe I just give too many options. So I have my reasons
> for leaving PREEMPT disabled by default and on an old tested v3.8
> kernel, the last thing i'm going to do is radically change the config.
> To much of a risk on a kernel in maintenance only mode at this point.
>
> Regards,
>
> --
> Robert Nelson
> http://www.rcn-ee.com/
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
q***@public.gmane.org
2014-03-05 10:14:43 UTC
Permalink
There are two repos on github which are related to the BBB kernel. It seems
that you are active in both of theses repositories.I have always used
https://github.com/beagleboard/kernel. But there's another repo at
https://github.com/RobertCNelson/linux-dev. What exactly is the difference
between these repos?

The default kernel configuration for kernel 3.8 from
https://github.com/beagleboard/kernel is at
https://github.com/beagleboard/kernel/blob/3.8/configs/beaglebone. In order
to allow people to build a PREEMPT capable version we could simply provide
a second kernel configuration. The name could be beaglebone_preempt. This
way you wouldn't have to change the default configuration. On the other
hand this would allow people to quickly evaluate the PREEMPT version and
have at least some basic determinism.

I have attached my modified kernel configuration. I am currently doing
further tests.


Am Mittwoch, 26. Februar 2014 15:23:01 UTC+1 schrieb RobertCNelson:
>
> On Wed, Feb 26, 2014 at 7:59 AM, <quik...-***@public.gmane.org <javascript:>>
> wrote:
> > Of course every user can create his own kernel coniguration or even
> modify
> > the Linux kernel in any way he wants. But if there is any problem he's
> > beeing left alone. I think it would be much better to have a default
> kernel
> > configuration which at least provides simple PREEMPT support. That might
> > help people to fight against most simple latency problems.
>
>
> Notice how the github account says "RobertCNelson"? Your welcome to
> fork that project and push kernel/image with your modifications. I'm
> not psychically forcing my config choices down people's throat.
> Everything is setup to easily allow you to rebuild/modify/etc
> everything. Maybe I just give too many options. So I have my reasons
> for leaving PREEMPT disabled by default and on an old tested v3.8
> kernel, the last thing i'm going to do is radically change the config.
> To much of a risk on a kernel in maintenance only mode at this point.
>
> Regards,
>
> --
> Robert Nelson
> http://www.rcn-ee.com/
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
q***@public.gmane.org
2014-03-05 14:16:46 UTC
Permalink
I did a test using the latest kernel from
https://github.com/beagleboard/kernel/blob/3.8/configs/beaglebone and the
kernel configuration I posted this morning. To load the cpu I used stress
--cpu 1 & cyclictest -l10000000 -m -n -t1 -p99 -i400 -h400 -q. I have
attached the output of cyclictest and an image with the latency histogram.

The maximum latency is now at 262 µs. However, only about 0.2% of the
samples are at t>=36 µs. It is clear that a kernel with the simple PREEMPT
option is not as good as one with the PREEMPT_RT option. But it is
definitely much better than a default kernel without any preemption enabled.


Am Mittwoch, 5. MÀrz 2014 11:14:43 UTC+1 schrieb quik...-***@public.gmane.org:
>
> There are two repos on github which are related to the BBB kernel. It
> seems that you are active in both of theses repositories.I have always used
> https://github.com/beagleboard/kernel. But there's another repo at
> https://github.com/RobertCNelson/linux-dev. What exactly is the
> difference between these repos?
>
> The default kernel configuration for kernel 3.8 from
> https://github.com/beagleboard/kernel is at
> https://github.com/beagleboard/kernel/blob/3.8/configs/beaglebone. In
> order to allow people to build a PREEMPT capable version we could simply
> provide a second kernel configuration. The name could be
> beaglebone_preempt. This way you wouldn't have to change the default
> configuration. On the other hand this would allow people to quickly
> evaluate the PREEMPT version and have at least some basic determinism.
>
> I have attached my modified kernel configuration. I am currently doing
> further tests.
>
>
> Am Mittwoch, 26. Februar 2014 15:23:01 UTC+1 schrieb RobertCNelson:
>>
>> On Wed, Feb 26, 2014 at 7:59 AM, <quik...-***@public.gmane.org> wrote:
>> > Of course every user can create his own kernel coniguration or even
>> modify
>> > the Linux kernel in any way he wants. But if there is any problem he's
>> > beeing left alone. I think it would be much better to have a default
>> kernel
>> > configuration which at least provides simple PREEMPT support. That
>> might
>> > help people to fight against most simple latency problems.
>>
>>
>> Notice how the github account says "RobertCNelson"? Your welcome to
>> fork that project and push kernel/image with your modifications. I'm
>> not psychically forcing my config choices down people's throat.
>> Everything is setup to easily allow you to rebuild/modify/etc
>> everything. Maybe I just give too many options. So I have my reasons
>> for leaving PREEMPT disabled by default and on an old tested v3.8
>> kernel, the last thing i'm going to do is radically change the config.
>> To much of a risk on a kernel in maintenance only mode at this point.
>>
>> Regards,
>>
>> --
>> Robert Nelson
>> http://www.rcn-ee.com/
>>
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
q***@public.gmane.org
2014-02-24 16:43:27 UTC
Permalink
No, the PRUSS unit is not a solution because support for it is even worse.
It's not a solution to program in assembler. If we had PREEMPT_RT we could
use the full Linux functionality. That's the way to go.


Am Freitag, 21. Februar 2014 11:03:24 UTC+1 schrieb David Goodenough:
>
> On Friday 21 February 2014 00:20:39 quik...-***@public.gmane.org <javascript:>wrote:
> > I am trying to figure out how to create a kernel for the BBB that
> supports
> > PREEMPT_RT. It's kind of strange that the BBB's default kernel does not
> > even have PREEMPT activated. Such a board doesn't fit to many embedded
> > applications where we need at least some kind of determinism. It is even
> > worse, that nobody seems to care about this problem. Contrary to that,
> the
> > Raspberry PI's standard kernel has PREEMPT activacted from the very
> > beginning.
> >
> > I have tested Robert Nelsons kernel 3.8.13-r9
> > (https://github.com/beagleboard/kernel/tree/3.8-rt). It does not have
> > PREEMPT_RT activated by default. When doing so, it does not boot. But
> > activating PREEMPT does work. However, development of this branch has
> > stopped several months ago. The official source for RT Linux (3.8.13)
> has
> > evolved since then. Meanwhile there's an rt17 patch set
> > (https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did anybody
> > give this a try? Does it work with the BBB?
> Surely the point of the Beaglebone, or rather its processor, is that you
> do not need to put the time critical bits on the main processor, you put
> them in the PRUSS processors.
>
> David
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
David Goodenough
2014-02-24 18:41:35 UTC
Permalink
On Monday 24 February 2014 08:43:27 quikcjack-***@public.gmane.org wrote:
> No, the PRUSS unit is not a solution because support for it is even worse.
> It's not a solution to program in assembler. If we had PREEMPT_RT we could
> use the full Linux functionality. That's the way to go.
There is a C compiler which is in beta, and can be requested. There have
been references to it on this list.

David
>
> Am Freitag, 21. Februar 2014 11:03:24 UTC+1 schrieb David Goodenough:
> > On Friday 21 February 2014 00:20:39 quik...-***@public.gmane.org <javascript:>wrote:
> > > I am trying to figure out how to create a kernel for the BBB that
> >
> > supports
> >
> > > PREEMPT_RT. It's kind of strange that the BBB's default kernel does not
> > > even have PREEMPT activated. Such a board doesn't fit to many embedded
> > > applications where we need at least some kind of determinism. It is even
> > > worse, that nobody seems to care about this problem. Contrary to that,
> >
> > the
> >
> > > Raspberry PI's standard kernel has PREEMPT activacted from the very
> > > beginning.
> > >
> > > I have tested Robert Nelsons kernel 3.8.13-r9
> > > (https://github.com/beagleboard/kernel/tree/3.8-rt). It does not have
> > > PREEMPT_RT activated by default. When doing so, it does not boot. But
> > > activating PREEMPT does work. However, development of this branch has
> > > stopped several months ago. The official source for RT Linux (3.8.13)
> >
> > has
> >
> > > evolved since then. Meanwhile there's an rt17 patch set
> > > (https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did anybody
> > > give this a try? Does it work with the BBB?
> >
> > Surely the point of the Beaglebone, or rather its processor, is that you
> > do not need to put the time critical bits on the main processor, you put
> > them in the PRUSS processors.
> >
> > David

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
r***@public.gmane.org
2014-02-22 12:17:24 UTC
Permalink
Just a few thoughts ...

It is not possible to have a fully deterministic real-time operating system
on a processor that uses instruction/data caches. ie you have to turn off
the cacheing to achieve determinism and eliminate performance jitter (which
then degrades the average performance).

>From what I understand PREEMPT_RT does not really improve the real-time
performance of linux if you stick to user level applications. You have to
start doing things at kernel level, which can get difficult and break many
of the existing device drivers. Anyway, who said all embedded applications
require a deterministic real-time performance? Soft real-time performance
is generally good enough for a lot of applications.

For real-time, the PRU co-processors are the way to go.

There are a number of papers around on the web comparing the performance of
normal linux, PREEMPT_RT and Xemonai in real-world situations (use google
to find them). They make for interesting reading and caused me to re-access
my approach to embedded linux systems.

Regards ...

On Friday, February 21, 2014 7:20:39 PM UTC+11, quik...-***@public.gmane.org wrote:
>
> I am trying to figure out how to create a kernel for the BBB that supports
> PREEMPT_RT. It's kind of strange that the BBB's default kernel does not
> even have PREEMPT activated. Such a board doesn't fit to many embedded
> applications where we need at least some kind of determinism. It is even
> worse, that nobody seems to care about this problem. Contrary to that, the
> Raspberry PI's standard kernel has PREEMPT activacted from the very
> beginning.
>
> I have tested Robert Nelsons kernel 3.8.13-r9 (
> https://github.com/beagleboard/kernel/tree/3.8-rt). It does not have
> PREEMPT_RT activated by default. When doing so, it does not boot. But
> activating PREEMPT does work. However, development of this branch has
> stopped several months ago. The official source for RT Linux (3.8.13) has
> evolved since then. Meanwhile there's an rt17 patch set (
> https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did anybody
> give this a try? Does it work with the BBB?
>
>
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
robert.berger
2014-02-23 11:26:23 UTC
Permalink
Hi,

On Saturday, February 22, 2014 2:17:24 PM UTC+2, rchrd...-***@public.gmane.org wrote:
>
> Just a few thoughts ...
>
> It is not possible to have a fully deterministic real-time operating
> system on a processor that uses instruction/data caches. ie you have to
> turn off the cacheing to achieve determinism and eliminate performance
> jitter (which then degrades the average performance).
>

Yep, but, that's the easy part. How about pipelines and instructions
reordering done by the compiler and the processor? How about interrupts?
How about multi-cores? How about the drift of the crystal you use as the
clock source of your CPU? You might be shocked now, but as you can see
it's impossible to have a hard real-time system with state of the art
(multi-core) processors. Is it? I think that you need to come up with a
realistic test suite to see if preempt-rt (with or without CPU isolation)
is good enough, or if you need Xenomai (still you will see issues if
Xenomai and Linux use the same caches), or some dedicated hardware like
PRU. There is also some interesting work by Jan Kiszka - not yet on ARM.[1]

Regards,

Robert

[1] http://lwn.net/Articles/574273/

Shameless self promotion:

[2] http://www.reliableembeddedsystems.com/pdfs/2010_03_04_rt_linux.pdf
[3]
http://www.embedded.com/design/operating-systems/4204740/Getting-real--time--about-embedded-GNU-Linux

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
John Syn
2014-02-23 21:06:05 UTC
Permalink
From: "robert.berger" <robert.karl.berger-***@public.gmane.org>
Reply-To: <beagleboard-/***@public.gmane.org>
Date: Sunday, February 23, 2014 at 3:26 AM
To: <beagleboard-/***@public.gmane.org>
Cc: <rchrdlyon1-***@public.gmane.org>
Subject: [beagleboard] Re: BBB + PREEMPT_RT

> Hi,
>
> On Saturday, February 22, 2014 2:17:24 PM UTC+2, rchrd...-***@public.gmane.org wrote:
>> Just a few thoughts ...
>>
>> It is not possible to have a fully deterministic real-time operating system
>> on a processor that uses instruction/data caches. ie you have to turn off the
>> cacheing to achieve determinism and eliminate performance jitter (which then
>> degrades the average performance).
>
> Yep, but, that's the easy part. How about pipelines and instructions
> reordering done by the compiler and the processor? How about interrupts? How
> about multi-cores? How about the drift of the crystal you use as the clock
> source of your CPU? You might be shocked now, but as you can see it's
> impossible to have a hard real-time system with state of the art (multi-core)
> processors. Is it? I think that you need to come up with a realistic test
> suite to see if preempt-rt (with or without CPU isolation) is good enough, or
> if you need Xenomai (still you will see issues if Xenomai and Linux use the
> same caches), or some dedicated hardware like PRU. There is also some
> interesting work by Jan Kiszka - not yet on ARM.[1]
I think there is some confusion about what real-time really means. It
doesn¹t mean fast or even consistent, it just means that it will respond to
some event in a required time. If your requirement is that something respond
in 1 second, then Linux kernel is good for real-time. If you want a response
of less than 1ms, then the Linux interrupt latency may not meet this
requirement. Remember, latency tests are conducted when the processor is
under load. Xenomai running on the BBB can achieve 50uS interrupt latency
whereas preempt-rt is more like 200uS.

Regards,
John
>
>
> Regards,
>
> Robert
>
> [1] http://lwn.net/Articles/574273/
>
> Shameless self promotion:
>
> [2] http://www.reliableembeddedsystems.com/pdfs/2010_03_04_rt_linux.pdf
> [3]
> http://www.embedded.com/design/operating-systems/4204740/Getting-real--time--a
> bout-embedded-GNU-Linux
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
> For more options, visit https://groups.google.com/groups/opt_out.


--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Daniel Nilsson
2014-02-23 21:19:04 UTC
Permalink
Hi,

For those interested in what the BBB can do in terms of interrupt latencies
with PREEMPT-RT applied, OSADL actually has one in their Q&A racks;

https://www.osadl.org/Profile-of-system-in-rack-7-slot-8.qa-profile-r7s8.0.html

Most recent latency plot (under load) is here:

https://www.osadl.org/Latency-plot-of-system-in-rack-7-slot.qa-latencyplot-r7s8.0.html

Regards
Daniel

On Sun, Feb 23, 2014 at 10:06 PM, John Syn <john3909-***@public.gmane.org> wrote:

>
> From: "robert.berger" <robert.karl.berger-***@public.gmane.org>
> Reply-To: <beagleboard-/***@public.gmane.org>
> Date: Sunday, February 23, 2014 at 3:26 AM
> To: <beagleboard-/***@public.gmane.org>
> Cc: <rchrdlyon1-***@public.gmane.org>
> Subject: [beagleboard] Re: BBB + PREEMPT_RT
>
> Hi,
>
> On Saturday, February 22, 2014 2:17:24 PM UTC+2, rchrd...-***@public.gmane.org wrote:
>>
>> Just a few thoughts ...
>>
>> It is not possible to have a fully deterministic real-time operating
>> system on a processor that uses instruction/data caches. ie you have to
>> turn off the cacheing to achieve determinism and eliminate performance
>> jitter (which then degrades the average performance).
>>
>
> Yep, but, that's the easy part. How about pipelines and instructions
> reordering done by the compiler and the processor? How about interrupts?
> How about multi-cores? How about the drift of the crystal you use as the
> clock source of your CPU? You might be shocked now, but as you can see
> it's impossible to have a hard real-time system with state of the art
> (multi-core) processors. Is it? I think that you need to come up with a
> realistic test suite to see if preempt-rt (with or without CPU isolation)
> is good enough, or if you need Xenomai (still you will see issues if
> Xenomai and Linux use the same caches), or some dedicated hardware like
> PRU. There is also some interesting work by Jan Kiszka - not yet on ARM.[1]
>
> I think there is some confusion about what real-time really means. It
> doesn't mean fast or even consistent, it just means that it will respond to
> some event in a required time. If your requirement is that something
> respond in 1 second, then Linux kernel is good for real-time. If you want a
> response of less than 1ms, then the Linux interrupt latency may not meet
> this requirement. Remember, latency tests are conducted when the processor
> is under load. Xenomai running on the BBB can achieve 50uS interrupt
> latency whereas preempt-rt is more like 200uS.
>
> Regards,
> John
>
>
>
> Regards,
>
> Robert
>
> [1] http://lwn.net/Articles/574273/
>
> Shameless self promotion:
>
> [2] http://www.reliableembeddedsystems.com/pdfs/2010_03_04_rt_linux.pdf
> [3]
> http://www.embedded.com/design/operating-systems/4204740/Getting-real--time--about-embedded-GNU-Linux
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
> For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/gJ_iFT2IwEQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
> For more options, visit https://groups.google.com/groups/opt_out.
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
John Syn
2014-02-23 21:43:47 UTC
Permalink
From: Daniel Nilsson <daniel-***@public.gmane.org>
Reply-To: <beagleboard-/***@public.gmane.org>
Date: Sunday, February 23, 2014 at 1:19 PM
To: <beagleboard-/***@public.gmane.org>
Subject: Re: [beagleboard] Re: BBB + PREEMPT_RT

> Hi,
>
> For those interested in what the BBB can do in terms of interrupt latencies
> with PREEMPT-RT applied, OSADL actually has one in their Q&A racks;
>
>
https://www.osadl.org/Profile-of-system-in-rack-7-slot-8.qa-profile-r7s8.0.htm>
l
>
> Most recent latency plot (under load) is here:
>
> https://www.osadl.org/Latency-plot-of-system-in-rack-7-slot.qa-latencyplot-r7s
> 8.0.html
Very interesting. Looks like preempt-rt is getting better all the time. At
110uS, it is only double that of Xenomai and for most applications that
won¹t matter.

Regards,
John
>
>
> Regards
> Daniel
>
> On Sun, Feb 23, 2014 at 10:06 PM, John Syn <john3909-***@public.gmane.org> wrote:
>>
>> From: "robert.berger" <robert.karl.berger-***@public.gmane.org>
>> Reply-To: <beagleboard-/***@public.gmane.org>
>> Date: Sunday, February 23, 2014 at 3:26 AM
>> To: <beagleboard-/***@public.gmane.org>
>> Cc: <rchrdlyon1-***@public.gmane.org>
>> Subject: [beagleboard] Re: BBB + PREEMPT_RT
>>
>>> Hi,
>>>
>>> On Saturday, February 22, 2014 2:17:24 PM UTC+2, rchrd...-***@public.gmane.org wrote:
>>>> Just a few thoughts ...
>>>>
>>>> It is not possible to have a fully deterministic real-time operating system
>>>> on a processor that uses instruction/data caches. ie you have to turn off
>>>> the cacheing to achieve determinism and eliminate performance jitter (which
>>>> then degrades the average performance).
>>>
>>> Yep, but, that's the easy part. How about pipelines and instructions
>>> reordering done by the compiler and the processor? How about interrupts?
>>> How about multi-cores? How about the drift of the crystal you use as the
>>> clock source of your CPU? You might be shocked now, but as you can see it's
>>> impossible to have a hard real-time system with state of the art
>>> (multi-core) processors. Is it? I think that you need to come up with a
>>> realistic test suite to see if preempt-rt (with or without CPU isolation) is
>>> good enough, or if you need Xenomai (still you will see issues if Xenomai
>>> and Linux use the same caches), or some dedicated hardware like PRU. There
>>> is also some interesting work by Jan Kiszka - not yet on ARM.[1]
>> I think there is some confusion about what real-time really means. It doesn¹t
>> mean fast or even consistent, it just means that it will respond to some
>> event in a required time. If your requirement is that something respond in 1
>> second, then Linux kernel is good for real-time. If you want a response of
>> less than 1ms, then the Linux interrupt latency may not meet this
>> requirement. Remember, latency tests are conducted when the processor is
>> under load. Xenomai running on the BBB can achieve 50uS interrupt latency
>> whereas preempt-rt is more like 200uS.
>>
>> Regards,
>> John
>>>
>>>
>>> Regards,
>>>
>>> Robert
>>>
>>> [1] http://lwn.net/Articles/574273/
>>>
>>> Shameless self promotion:
>>>
>>> [2] http://www.reliableembeddedsystems.com/pdfs/2010_03_04_rt_linux.pdf
>>> [3]
>>> http://www.embedded.com/design/operating-systems/4204740/Getting-real--time-
>>> -about-embedded-GNU-Linux
>>>
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google Groups
>>> "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to a topic in the Google
>> Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/beagleboard/gJ_iFT2IwEQ/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> beagleboard+unsubscribe-/***@public.gmane.org
>> <mailto:beagleboard%2Bunsubscribe-/***@public.gmane.org> .
>> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
> For more options, visit https://groups.google.com/groups/opt_out.


--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
dlewin555
2014-02-25 12:52:01 UTC
Permalink
While I agree with your definition I'd like to know where you have got this
results as mine in worst case conditions have been somewhat different, and
worst includes "load+running in SD card " the latency test average have
been more around 40 µS:

http://flic.kr/ps/2LwUC9

Therefore, I'm confident in the new latency measurements that I'm going to
do with the Charles' Xenomaibone39 from the emmC, as it will < those in SD.


Le dimanche 23 février 2014 22:06:05 UTC+1, john3909 a écrit :
>
>
> From: "robert.berger" <robert.ka...-***@public.gmane.org <javascript:>>
> Reply-To: <beagl...-/***@public.gmane.org <javascript:>>
> Date: Sunday, February 23, 2014 at 3:26 AM
> To: <beagl...-/***@public.gmane.org <javascript:>>
> Cc: <rchrd...-***@public.gmane.org <javascript:>>
> Subject: [beagleboard] Re: BBB + PREEMPT_RT
>
> Hi,
>
> On Saturday, February 22, 2014 2:17:24 PM UTC+2, rchrd...-***@public.gmane.org wrote:
>>
>> Just a few thoughts ...
>>
>> It is not possible to have a fully deterministic real-time operating
>> system on a processor that uses instruction/data caches. ie you have to
>> turn off the cacheing to achieve determinism and eliminate performance
>> jitter (which then degrades the average performance).
>>
>
> Yep, but, that's the easy part. How about pipelines and instructions
> reordering done by the compiler and the processor? How about interrupts?
> How about multi-cores? How about the drift of the crystal you use as the
> clock source of your CPU? You might be shocked now, but as you can see
> it's impossible to have a hard real-time system with state of the art
> (multi-core) processors. Is it? I think that you need to come up with a
> realistic test suite to see if preempt-rt (with or without CPU isolation)
> is good enough, or if you need Xenomai (still you will see issues if
> Xenomai and Linux use the same caches), or some dedicated hardware like
> PRU. There is also some interesting work by Jan Kiszka - not yet on ARM.[1]
>
> I think there is some confusion about what real-time really means. It
> doesn’t mean fast or even consistent, it just means that it will respond to
> some event in a required time. If your requirement is that something
> respond in 1 second, then Linux kernel is good for real-time. If you want a
> response of less than 1ms, then the Linux interrupt latency may not meet
> this requirement. Remember, latency tests are conducted when the processor
> is under load. Xenomai running on the BBB can achieve 50uS interrupt
> latency whereas preempt-rt is more like 200uS.
>
> Regards,
> John
>
>
>
> Regards,
>
> Robert
>
> [1] http://lwn.net/Articles/574273/
>
> Shameless self promotion:
>
> [2] http://www.reliableembeddedsystems.com/pdfs/2010_03_04_rt_linux.pdf
> [3]
> http://www.embedded.com/design/operating-systems/4204740/Getting-real--time--about-embedded-GNU-Linux
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard...-/***@public.gmane.org <javascript:>.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Daniel Nilsson
2014-02-23 15:49:32 UTC
Permalink
Hi,

On Saturday, February 22, 2014 1:17:24 PM UTC+1, rchrd...-***@public.gmane.org wrote:
>
> It is not possible to have a fully deterministic real-time operating
> system on a processor that uses instruction/data caches. ie you have to
> turn off the cacheing to achieve determinism and eliminate performance
> jitter (which then degrades the average performance).
>

That is correct (in theory), but you need to figure out what kind of
real-time requirements you have on your system first to understand if that
is important or not. You typically divide real-time operating systems in
these 3 categories;


- *Hard:* Missing a deadline is a total system failure.
- *Firm:* Infrequent deadline misses are tolerable, but may degrade the
systems quality of service. The usefulness of a result is zero after its
deadline.
- *Soft:* The usefulness of a result degrades after its deadline,
thereby degrading the system's quality of service


Above defintions from http://en.wikipedia.org/wiki/Real-time_computing

If you have "Hard" real-time requirements you typically do not try to run
that application in Linux user-space, not even with PREEMPT-RT. That is the
task for dedicated real-time solutions such as the PRU co-processor or
dedicated real-time OSes.

Firm real-time can be solved using Linux PREEMPT-RT though, and also soft
of course. I did a quick benchmark on the BBone some time ago on the
3.4.39-rt54 kernel and found bounded latencies in the 60us range. So if you
have firm real-time requirements and can accept latencies in that range
PREEMPT-RT can be a solution.


> From what I understand PREEMPT_RT does not really improve the real-time
> performance of linux if you stick to user level applications. You have to
> start doing things at kernel level, which can get difficult and break many
> of the existing device drivers. Anyway, who said all embedded applications
> require a deterministic real-time performance? Soft real-time performance
> is generally good enough for a lot of applications.
>

The point of PREEMPT-RT is to provide bounded latencies for user-space
applications (SCHED_FIFO tasks), without PREEMPT-RT can can't count on
bounded latencies in Linux (even for SCHED_FIFO tasks).


>
> For real-time, the PRU co-processors are the way to go.
>

Agreed, but that is for hard real-time. And programming the PRU is not at
all as convenient as programming user-space applications in Linux on the
posix interface. Posix on top of Linux with PREEMPT-RT provides you with a
preemptive programming model (if needed) and bounded latencies, though you
need to be careful with which system calls you are using.

Regards
Daniel


--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
q***@public.gmane.org
2014-02-26 13:53:05 UTC
Permalink
I have recently tested kernel 3.8.13-rt9 (
https://github.com/beagleboard/kernel/tree/3.8-rt) using
git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git. I am
using Ubuntu 12.04.4. The load was created using stress –cpu 1 which
generates a cpu load of about 100%. I then used cyclictest:


***@ubuntu-armhf:/home/ubuntu/rt-tests# ./cyclictest -l1000000 -m -n -t1
-p99 -i400 -q

# /dev/cpu_dma_latency set to 0us

T: 0 ( 770) P:99 I:400 C:1000000 Min: 14 Act: 19 Avg: 18 Max: 132


uname -a reports:

***@ubuntu-armhf:/home/ubuntu/rt-tests# uname -a

Linux ubuntu-armhf 3.8.13-rt9-00899-g160e771 #1 SMP PREEMPT Wed Jun 19
10:49:36 CEST 2013 armv7l armv7l armv7l GNU/Linux


I am absolutely surprised that the result is looking that good.



Am Freitag, 21. Februar 2014 09:20:39 UTC+1 schrieb quik...-***@public.gmane.org:
>
> I am trying to figure out how to create a kernel for the BBB that supports
> PREEMPT_RT. It's kind of strange that the BBB's default kernel does not
> even have PREEMPT activated. Such a board doesn't fit to many embedded
> applications where we need at least some kind of determinism. It is even
> worse, that nobody seems to care about this problem. Contrary to that, the
> Raspberry PI's standard kernel has PREEMPT activacted from the very
> beginning.
>
> I have tested Robert Nelsons kernel 3.8.13-r9 (
> https://github.com/beagleboard/kernel/tree/3.8-rt). It does not have
> PREEMPT_RT activated by default. When doing so, it does not boot. But
> activating PREEMPT does work. However, development of this branch has
> stopped several months ago. The official source for RT Linux (3.8.13) has
> evolved since then. Meanwhile there's an rt17 patch set (
> https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did anybody
> give this a try? Does it work with the BBB?
>
>
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Charles Steinkuehler
2014-02-26 14:58:55 UTC
Permalink
Those are pretty good numbers. Did you have heavy network and disk
(uSD/eMMC) load going as well? IIRC, the uSD/eMMC driver was
responsible for the worst of the latency spikes I saw, but that's been
some time ago and based on the OMAP kernel list traffic, it appears
there have been lots of improvements to that code.

On 2/26/2014 7:53 AM, quikcjack-***@public.gmane.org wrote:
>
>
> I have recently tested kernel 3.8.13-rt9 (
> https://github.com/beagleboard/kernel/tree/3.8-rt) using
> git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git. I am
> using Ubuntu 12.04.4. The load was created using stress –cpu 1 which
> generates a cpu load of about 100%. I then used cyclictest:
>
>
> ***@ubuntu-armhf:/home/ubuntu/rt-tests# ./cyclictest -l1000000 -m -n -t1
> -p99 -i400 -q
>
> # /dev/cpu_dma_latency set to 0us
>
> T: 0 ( 770) P:99 I:400 C:1000000 Min: 14 Act: 19 Avg: 18 Max: 132
>
>
> uname -a reports:
>
> ***@ubuntu-armhf:/home/ubuntu/rt-tests# uname -a
>
> Linux ubuntu-armhf 3.8.13-rt9-00899-g160e771 #1 SMP PREEMPT Wed Jun 19
> 10:49:36 CEST 2013 armv7l armv7l armv7l GNU/Linux
>
>
> I am absolutely surprised that the result is looking that good.
>
>
>
> Am Freitag, 21. Februar 2014 09:20:39 UTC+1 schrieb quik...-***@public.gmane.org:
>>
>> I am trying to figure out how to create a kernel for the BBB that supports
>> PREEMPT_RT. It's kind of strange that the BBB's default kernel does not
>> even have PREEMPT activated. Such a board doesn't fit to many embedded
>> applications where we need at least some kind of determinism. It is even
>> worse, that nobody seems to care about this problem. Contrary to that, the
>> Raspberry PI's standard kernel has PREEMPT activacted from the very
>> beginning.
>>
>> I have tested Robert Nelsons kernel 3.8.13-r9 (
>> https://github.com/beagleboard/kernel/tree/3.8-rt). It does not have
>> PREEMPT_RT activated by default. When doing so, it does not boot. But
>> activating PREEMPT does work. However, development of this branch has
>> stopped several months ago. The official source for RT Linux (3.8.13) has
>> evolved since then. Meanwhile there's an rt17 patch set (
>> https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did anybody
>> give this a try? Does it work with the BBB?
>>
>>
>>
>


--
Charles Steinkuehler
charles-***@public.gmane.org

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
q***@public.gmane.org
2014-02-26 15:48:10 UTC
Permalink
The stress tool generates cpu load only. But it is a good idea to consider
other load scenarios, too. The current test was done using ssh so there was
at least some network activity. Do you know of a good test tool which
allows to generate disk and network load?


Am Mittwoch, 26. Februar 2014 15:58:55 UTC+1 schrieb Charles Steinkuehler:
>
> Those are pretty good numbers. Did you have heavy network and disk
> (uSD/eMMC) load going as well? IIRC, the uSD/eMMC driver was
> responsible for the worst of the latency spikes I saw, but that's been
> some time ago and based on the OMAP kernel list traffic, it appears
> there have been lots of improvements to that code.
>
> On 2/26/2014 7:53 AM, quik...-***@public.gmane.org <javascript:> wrote:
> >
> >
> > I have recently tested kernel 3.8.13-rt9 (
> > https://github.com/beagleboard/kernel/tree/3.8-rt) using
> > git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git. I
> am
> > using Ubuntu 12.04.4. The load was created using stress –cpu 1 which
> > generates a cpu load of about 100%. I then used cyclictest:
> >
> >
> > ***@ubuntu-armhf:/home/ubuntu/rt-tests# ./cyclictest -l1000000 -m -n
> -t1
> > -p99 -i400 -q
> >
> > # /dev/cpu_dma_latency set to 0us
> >
> > T: 0 ( 770) P:99 I:400 C:1000000 Min: 14 Act: 19 Avg: 18 Max: 132
> >
> >
> > uname -a reports:
> >
> > ***@ubuntu-armhf:/home/ubuntu/rt-tests# uname -a
> >
> > Linux ubuntu-armhf 3.8.13-rt9-00899-g160e771 #1 SMP PREEMPT Wed Jun 19
> > 10:49:36 CEST 2013 armv7l armv7l armv7l GNU/Linux
> >
> >
> > I am absolutely surprised that the result is looking that good.
> >
> >
> >
> > Am Freitag, 21. Februar 2014 09:20:39 UTC+1 schrieb quik...-***@public.gmane.org:
> >>
> >> I am trying to figure out how to create a kernel for the BBB that
> supports
> >> PREEMPT_RT. It's kind of strange that the BBB's default kernel does not
> >> even have PREEMPT activated. Such a board doesn't fit to many embedded
> >> applications where we need at least some kind of determinism. It is
> even
> >> worse, that nobody seems to care about this problem. Contrary to that,
> the
> >> Raspberry PI's standard kernel has PREEMPT activacted from the very
> >> beginning.
> >>
> >> I have tested Robert Nelsons kernel 3.8.13-r9 (
> >> https://github.com/beagleboard/kernel/tree/3.8-rt). It does not have
> >> PREEMPT_RT activated by default. When doing so, it does not boot. But
> >> activating PREEMPT does work. However, development of this branch has
> >> stopped several months ago. The official source for RT Linux (3.8.13)
> has
> >> evolved since then. Meanwhile there's an rt17 patch set (
> >> https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did anybody
> >> give this a try? Does it work with the BBB?
> >>
> >>
> >>
> >
>
>
> --
> Charles Steinkuehler
> cha...-***@public.gmane.org <javascript:>
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Charles Steinkuehler
2014-02-26 15:58:31 UTC
Permalink
Xenomai includes a "dohell" script that can generate disk and network
load. You can always just "dd" to a file for a while.

If you're running a Debian/Ubuntu based system, I've found that running
"aptitude upgrade" if you have a few dated packages can be a major
stress to the system. That gets you both network and disk load, and not
so long ago had a decent chance of wedging the eMMC kernel driver (even
without the Xenomai patches that 'tickled' the eMMC driver bug and made
it more likely to happen).

Opening GUI programs and moving windows around is another good stress.

On 2/26/2014 9:48 AM, quikcjack-***@public.gmane.org wrote:
> The stress tool generates cpu load only. But it is a good idea to consider
> other load scenarios, too. The current test was done using ssh so there was
> at least some network activity. Do you know of a good test tool which
> allows to generate disk and network load?
>
>
> Am Mittwoch, 26. Februar 2014 15:58:55 UTC+1 schrieb Charles Steinkuehler:
>>
>> Those are pretty good numbers. Did you have heavy network and disk
>> (uSD/eMMC) load going as well? IIRC, the uSD/eMMC driver was
>> responsible for the worst of the latency spikes I saw, but that's been
>> some time ago and based on the OMAP kernel list traffic, it appears
>> there have been lots of improvements to that code.
>>
>> On 2/26/2014 7:53 AM, quik...-***@public.gmane.org <javascript:> wrote:
>>>
>>>
>>> I have recently tested kernel 3.8.13-rt9 (
>>> https://github.com/beagleboard/kernel/tree/3.8-rt) using
>>> git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git. I
>> am
>>> using Ubuntu 12.04.4. The load was created using stress –cpu 1 which
>>> generates a cpu load of about 100%. I then used cyclictest:
>>>
>>>
>>> ***@ubuntu-armhf:/home/ubuntu/rt-tests# ./cyclictest -l1000000 -m -n
>> -t1
>>> -p99 -i400 -q
>>>
>>> # /dev/cpu_dma_latency set to 0us
>>>
>>> T: 0 ( 770) P:99 I:400 C:1000000 Min: 14 Act: 19 Avg: 18 Max: 132
>>>
>>>
>>> uname -a reports:
>>>
>>> ***@ubuntu-armhf:/home/ubuntu/rt-tests# uname -a
>>>
>>> Linux ubuntu-armhf 3.8.13-rt9-00899-g160e771 #1 SMP PREEMPT Wed Jun 19
>>> 10:49:36 CEST 2013 armv7l armv7l armv7l GNU/Linux
>>>
>>>
>>> I am absolutely surprised that the result is looking that good.
>>>
>>>
>>>
>>> Am Freitag, 21. Februar 2014 09:20:39 UTC+1 schrieb quik...-***@public.gmane.org:
>>>>
>>>> I am trying to figure out how to create a kernel for the BBB that
>> supports
>>>> PREEMPT_RT. It's kind of strange that the BBB's default kernel does not
>>>> even have PREEMPT activated. Such a board doesn't fit to many embedded
>>>> applications where we need at least some kind of determinism. It is
>> even
>>>> worse, that nobody seems to care about this problem. Contrary to that,
>> the
>>>> Raspberry PI's standard kernel has PREEMPT activacted from the very
>>>> beginning.
>>>>
>>>> I have tested Robert Nelsons kernel 3.8.13-r9 (
>>>> https://github.com/beagleboard/kernel/tree/3.8-rt). It does not have
>>>> PREEMPT_RT activated by default. When doing so, it does not boot. But
>>>> activating PREEMPT does work. However, development of this branch has
>>>> stopped several months ago. The official source for RT Linux (3.8.13)
>> has
>>>> evolved since then. Meanwhile there's an rt17 patch set (
>>>> https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did anybody
>>>> give this a try? Does it work with the BBB?
>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Charles Steinkuehler
>> cha...-***@public.gmane.org <javascript:>
>>
>


--
Charles Steinkuehler
charles-***@public.gmane.org

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
q***@public.gmane.org
2014-02-28 08:53:14 UTC
Permalink
Thanks for you tips. I am using a minimal Ubuntu system without a full
desktop that is based on
http://www.armhf.com/index.php/boards/beaglebone-black/#precise. I used
apt-get to update the system. The integrated eMMC and HDMI are deactivated.

To create a network stress I used Ubuntu's iperf in server mode from
another ssh shell while running stress and cyclictest at the same time. The
transfer rate to another Ubuntu box reached 94.7 MBit/s and > 100MB were
copied. The latency numbers did not change.


Am Mittwoch, 26. Februar 2014 16:58:31 UTC+1 schrieb Charles Steinkuehler:
>
> Xenomai includes a "dohell" script that can generate disk and network
> load. You can always just "dd" to a file for a while.
>
> If you're running a Debian/Ubuntu based system, I've found that running
> "aptitude upgrade" if you have a few dated packages can be a major
> stress to the system. That gets you both network and disk load, and not
> so long ago had a decent chance of wedging the eMMC kernel driver (even
> without the Xenomai patches that 'tickled' the eMMC driver bug and made
> it more likely to happen).
>
> Opening GUI programs and moving windows around is another good stress.
>
> On 2/26/2014 9:48 AM, quik...-***@public.gmane.org <javascript:> wrote:
> > The stress tool generates cpu load only. But it is a good idea to
> consider
> > other load scenarios, too. The current test was done using ssh so there
> was
> > at least some network activity. Do you know of a good test tool which
> > allows to generate disk and network load?
> >
> >
> > Am Mittwoch, 26. Februar 2014 15:58:55 UTC+1 schrieb Charles
> Steinkuehler:
> >>
> >> Those are pretty good numbers. Did you have heavy network and disk
> >> (uSD/eMMC) load going as well? IIRC, the uSD/eMMC driver was
> >> responsible for the worst of the latency spikes I saw, but that's been
> >> some time ago and based on the OMAP kernel list traffic, it appears
> >> there have been lots of improvements to that code.
> >>
> >> On 2/26/2014 7:53 AM, quik...-***@public.gmane.org <javascript:> wrote:
> >>>
> >>>
> >>> I have recently tested kernel 3.8.13-rt9 (
> >>> https://github.com/beagleboard/kernel/tree/3.8-rt) using
> >>> git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git.
> I
> >> am
> >>> using Ubuntu 12.04.4. The load was created using stress –cpu 1 which
> >>> generates a cpu load of about 100%. I then used cyclictest:
> >>>
> >>>
> >>> ***@ubuntu-armhf:/home/ubuntu/rt-tests# ./cyclictest -l1000000 -m -n
> >> -t1
> >>> -p99 -i400 -q
> >>>
> >>> # /dev/cpu_dma_latency set to 0us
> >>>
> >>> T: 0 ( 770) P:99 I:400 C:1000000 Min: 14 Act: 19 Avg: 18 Max: 132
> >>>
> >>>
> >>> uname -a reports:
> >>>
> >>> ***@ubuntu-armhf:/home/ubuntu/rt-tests# uname -a
> >>>
> >>> Linux ubuntu-armhf 3.8.13-rt9-00899-g160e771 #1 SMP PREEMPT Wed Jun 19
> >>> 10:49:36 CEST 2013 armv7l armv7l armv7l GNU/Linux
> >>>
> >>>
> >>> I am absolutely surprised that the result is looking that good.
> >>>
> >>>
> >>>
> >>> Am Freitag, 21. Februar 2014 09:20:39 UTC+1 schrieb quik...-***@public.gmane.org:
>
> >>>>
> >>>> I am trying to figure out how to create a kernel for the BBB that
> >> supports
> >>>> PREEMPT_RT. It's kind of strange that the BBB's default kernel does
> not
> >>>> even have PREEMPT activated. Such a board doesn't fit to many
> embedded
> >>>> applications where we need at least some kind of determinism. It is
> >> even
> >>>> worse, that nobody seems to care about this problem. Contrary to
> that,
> >> the
> >>>> Raspberry PI's standard kernel has PREEMPT activacted from the very
> >>>> beginning.
> >>>>
> >>>> I have tested Robert Nelsons kernel 3.8.13-r9 (
> >>>> https://github.com/beagleboard/kernel/tree/3.8-rt). It does not have
> >>>> PREEMPT_RT activated by default. When doing so, it does not boot. But
> >>>> activating PREEMPT does work. However, development of this branch has
> >>>> stopped several months ago. The official source for RT Linux (3.8.13)
> >> has
> >>>> evolved since then. Meanwhile there's an rt17 patch set (
> >>>> https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did
> anybody
> >>>> give this a try? Does it work with the BBB?
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >> --
> >> Charles Steinkuehler
> >> cha...-***@public.gmane.org <javascript:>
> >>
> >
>
>
> --
> Charles Steinkuehler
> cha...-***@public.gmane.org <javascript:>
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Yang
2014-03-04 02:11:04 UTC
Permalink
This post might be inappropriate. Click to display it.
r***@public.gmane.org
2014-02-28 03:40:13 UTC
Permalink
Interesting result. Would be nice to see a histogram. I will try and
duplicate this measurement. Also doing the some measure with the standard
kernel would be informative.

That upper tail of 132 is a big problem for me.

On Thursday, February 27, 2014 12:53:05 AM UTC+11, quik...-***@public.gmane.org wrote:
>
> I have recently tested kernel 3.8.13-rt9 (
> https://github.com/beagleboard/kernel/tree/3.8-rt) using git://
> git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git. I am
> using Ubuntu 12.04.4. The load was created using stress –cpu 1 which
> generates a cpu load of about 100%. I then used cyclictest:
>
>
> ***@ubuntu-armhf:/home/ubuntu/rt-tests# ./cyclictest -l1000000 -m -n
> -t1 -p99 -i400 -q
>
> # /dev/cpu_dma_latency set to 0us
>
> T: 0 ( 770) P:99 I:400 C:1000000 Min: 14 Act: 19 Avg: 18 Max: 132
>
>
> uname -a reports:
>
> ***@ubuntu-armhf:/home/ubuntu/rt-tests# uname -a
>
> Linux ubuntu-armhf 3.8.13-rt9-00899-g160e771 #1 SMP PREEMPT Wed Jun 19
> 10:49:36 CEST 2013 armv7l armv7l armv7l GNU/Linux
>
>
> I am absolutely surprised that the result is looking that good.
>
>
>
> Am Freitag, 21. Februar 2014 09:20:39 UTC+1 schrieb quik...-***@public.gmane.org:
>>
>> I am trying to figure out how to create a kernel for the BBB that
>> supports PREEMPT_RT. It's kind of strange that the BBB's default kernel
>> does not even have PREEMPT activated. Such a board doesn't fit to many
>> embedded applications where we need at least some kind of determinism. It
>> is even worse, that nobody seems to care about this problem. Contrary to
>> that, the Raspberry PI's standard kernel has PREEMPT activacted from the
>> very beginning.
>>
>> I have tested Robert Nelsons kernel 3.8.13-r9 (
>> https://github.com/beagleboard/kernel/tree/3.8-rt). It does not have
>> PREEMPT_RT activated by default. When doing so, it does not boot. But
>> activating PREEMPT does work. However, development of this branch has
>> stopped several months ago. The official source for RT Linux (3.8.13) has
>> evolved since then. Meanwhile there's an rt17 patch set (
>> https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did anybody
>> give this a try? Does it work with the BBB?
>>
>>
>>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
q***@public.gmane.org
2014-04-04 15:06:50 UTC
Permalink
Sorry for my late answer. I have posted my kernel configuration on March 5.
Please take a close look at my postings. You mave have to log in to google
to see the attachments.



Am Mittwoch, 19. MÀrz 2014 16:06:07 UTC+1 schrieb winglion:
>
> 
> hi,quikcjack. I had been fallowing the topic for some dates.
>
> I plan to build a CNC controler with BBBlack.
> I want to get your kernel config to make a
> PREEMPT/PREEMPT_RT capable kernel too.
>
> whould you please seem me your kernel confiuration too? Thanks.
>
>
> ======== 2014-03-19 16:47:58  ========
>
>
> It's really nice to see that there is some interest in having a
> PREEMPT/PREEMPT_RT capable kernel for the BBB.
>
> Well, it's relatively easy to compile a kernel. If you want to develop
> applications for the BBB you need a compiler/toolchain. So I guess you
> might have that already. The instructions to compile a kernel are explained
> at https://github.com/beagleboard/kernel/tree/3.8.
>
> I could send you my modified kernel configuration. You simply have the
> replace the original kernel configuration to create the PREEMPT capable
> kernel.
>
>
> Am Freitag, 14. MÀrz 2014 13:03:51 UTC+1 schrieb mhfar...-***@public.gmane.org:
>>
>> Hi thats great!
>>
>> Is that possible to have your compiled kernel for BBB? I would avoid the
>> compiling process.
>> Thanks a lot,
>>
>> Morteza
>>
>> Am Mittwoch, 26. Februar 2014 14:53:05 UTC+1 schrieb quik...-***@public.gmane.org:
>>>
>>> I have recently tested kernel 3.8.13-rt9 (
>>> https://github.com/beagleboard/kernel/tree/3.8-rt) using git://
>>> git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git. I am
>>> using Ubuntu 12.04.4. The load was created using stress –cpu 1 which
>>> generates a cpu load of about 100%. I then used cyclictest:
>>>
>>>
>>> ***@ubuntu-armhf:/home/ubuntu/rt-tests# ./cyclictest -l1000000 -m -n
>>> -t1 -p99 -i400 -q
>>>
>>> # /dev/cpu_dma_latency set to 0us
>>>
>>> T: 0 ( 770) P:99 I:400 C:1000000 Min: 14 Act: 19 Avg: 18 Max: 132
>>>
>>>
>>> uname -a reports:
>>>
>>> ***@ubuntu-armhf:/home/ubuntu/rt-tests# uname -a
>>>
>>> Linux ubuntu-armhf 3.8.13-rt9-00899-g160e771 #1 SMP PREEMPT Wed Jun 19
>>> 10:49:36 CEST 2013 armv7l armv7l armv7l GNU/Linux
>>>
>>>
>>> I am absolutely surprised that the result is looking that good.
>>>
>>>
>>>
>>> Am Freitag, 21. Februar 2014 09:20:39 UTC+1 schrieb quik...-***@public.gmane.org:
>>>>
>>>> I am trying to figure out how to create a kernel for the BBB that
>>>> supports PREEMPT_RT. It's kind of strange that the BBB's default kernel
>>>> does not even have PREEMPT activated. Such a board doesn't fit to many
>>>> embedded applications where we need at least some kind of determinism. It
>>>> is even worse, that nobody seems to care about this problem. Contrary to
>>>> that, the Raspberry PI's standard kernel has PREEMPT activacted from the
>>>> very beginning.
>>>>
>>>> I have tested Robert Nelsons kernel 3.8.13-r9 (
>>>> https://github.com/beagleboard/kernel/tree/3.8-rt). It does not have
>>>> PREEMPT_RT activated by default. When doing so, it does not boot. But
>>>> activating PREEMPT does work. However, development of this branch has
>>>> stopped several months ago. The official source for RT Linux (3.8.13) has
>>>> evolved since then. Meanwhile there's an rt17 patch set (
>>>> https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did anybody
>>>> give this a try? Does it work with the BBB?
>>>>
>>>>
>>>> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard...-/***@public.gmane.org <javascript:>.
> For more options, visit https://groups.google.com/d/optout.
>
> 圚歀邮件䞭未发现病毒。
> 检查工具AVG - www.avg.com
> 版本2013.0.3462 / 病毒数据库3722/7208 - 发垃日期03/17/14
>
> = = = = = = = = = = = = = = = = = = = = = =
>
> 臎
> 瀌
>
> winglion
> wing...-9Onoh4P/***@public.gmane.org <javascript:>
> 2014-03-19
>
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
f***@public.gmane.org
2014-03-08 21:15:04 UTC
Permalink
I have lately also unsuccessfully tried to install RT_PREEMPT on BBB.

What I have done until now (and failed) is:

A.
1. Get the sources from here:
https://github.com/beagleboard/kernel/tree/3.8-rt
2. Before make command, enable Full Preemption under kernel features
options.
3. Compile. When testing on BBB, the kernel doesn't boot.

B.
1. Get the sources from here:
https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.8
2. ./build_kernel.sh
3. Download the rt patch from here:
https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/patch-3.8.13.14-rt27.patch.bz2into KERNEL folder
4. patch p1 < patch-3.8.13.14-rt27.patch
5. From here, it turned a little bit weird since approximately 21 HUNKS
failed. Reading this post:
https://groups.google.com/forum/#!topic/beagleboard/aAufDe13SeQ then I
re-edited the .patch file taking away the modifications in cpsw.h and
cpsw.c (lines 5825 to 7346 from .patch file).
6. Then repeated steps 1 through 4 again, but using the edited patch.
7. Use menuconfig to activate Full-Preemption.
8. ./tools/rebuild.sh
9. ./tools/install_kernel.sh (with the modifications in the system.sh
file)
10. Plug the SD card in the BBB. and it never booted.

I have seen the osadl 3.8.12 kernel, but I'm more interested in using the
3.8.13 kernel.

If anyone could give away any ideas, I would be really grateful.

Thank you for your time.

>
>
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
q***@public.gmane.org
2014-03-11 11:06:44 UTC
Permalink
I have never heard of a PREEMPT_RT capable kernel for the BBB besides that
from OSADL. I have recently had a conversation with Robert C. Nelson. He
told me, that kernel 3.8 has problems and did never support PREEMPT_RT. The
3.8-rt branch is no longer in development. Officially, the BBB does not
even support simple PREEMPT.

So I guess your only chance is the OSADL kernel. The current version is
3.12.13-rt21. It seems to work. But there are issues with GPMC. I have
created a new thread on this topic here:
https://groups.google.com/forum/#!category-topic/beagleboard/beaglebone-black/uac_Zh41LYo.


Am Samstag, 8. MÀrz 2014 22:15:04 UTC+1 schrieb fj.r...-***@public.gmane.orgg:
>
> I have lately also unsuccessfully tried to install RT_PREEMPT on BBB.
>
> What I have done until now (and failed) is:
>
> A.
> 1. Get the sources from here:
> https://github.com/beagleboard/kernel/tree/3.8-rt
> 2. Before make command, enable Full Preemption under kernel features
> options.
> 3. Compile. When testing on BBB, the kernel doesn't boot.
>
> B.
> 1. Get the sources from here:
> https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.8
> 2. ./build_kernel.sh
> 3. Download the rt patch from here:
> https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/patch-3.8.13.14-rt27.patch.bz2into KERNEL folder
> 4. patch p1 < patch-3.8.13.14-rt27.patch
> 5. From here, it turned a little bit weird since approximately 21
> HUNKS failed. Reading this post:
> https://groups.google.com/forum/#!topic/beagleboard/aAufDe13SeQ then I
> re-edited the .patch file taking away the modifications in cpsw.h and
> cpsw.c (lines 5825 to 7346 from .patch file).
> 6. Then repeated steps 1 through 4 again, but using the edited patch.
> 7. Use menuconfig to activate Full-Preemption.
> 8. ./tools/rebuild.sh
> 9. ./tools/install_kernel.sh (with the modifications in the system.sh
> file)
> 10. Plug the SD card in the BBB. and it never booted.
>
> I have seen the osadl 3.8.12 kernel, but I'm more interested in using the
> 3.8.13 kernel.
>
> If anyone could give away any ideas, I would be really grateful.
>
> Thank you for your time.
>
>>
>>
>>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
dickelbeck
2014-03-11 17:01:22 UTC
Permalink
I tried PREEMPT yesterday on 3.12.9 and the ethernet seemed to work. The
only thing I had a problem with was USB host.
It failed the probe().

So I reverted. Years ago I filed a bug report with TI regarding the
ethernet driver not working with PREEMPT in kernel 3.2.
Some progress has been made, ethernet seemed to work now on 3.12.9.

Dick


--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
Loading...