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, quikcj...@gmail.com 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...@gmail.com <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...@gmail.com 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...@steinkuehler.net <javascript:> >> > -- Charles Steinkuehler char...@steinkuehler.net -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
