BBB + PREEMPT_RT

[quik...@gmail.com]

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?

[Bas Laarhoven]

On 21-2-2014 9:20, 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.

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...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[David Goodenough]

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

[Giuseppe Iellamo]

Or just try Xenomai...

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

[David Goodenough]

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:

[rchrd...@gmail.com]

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 ...

[robert.berger]

Hi,

On Saturday, February 22, 2014 2:17:24 PM UTC+2, rchrd...@gmail.com 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

[Daniel Nilsson]

Hi,

On Saturday, February 22, 2014 1:17:24 PM UTC+1, rchrd...@gmail.com 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

[John Syn]

From: "robert.berger" <robert.ka...@gmail.com>
Reply-To: <beagl...@googlegroups.com>
Date: Sunday, February 23, 2014 at 3:26 AM
To: <beagl...@googlegroups.com>
Cc: <rchrd...@gmail.com>
Subject: [beagleboard] Re: BBB + PREEMPT_RT

Hi,

On Saturday, February 22, 2014 2:17:24 PM UTC+2, rchrd...@gmail.com 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

[Daniel Nilsson]

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

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...@googlegroups.com.

[John Syn]

From: Daniel Nilsson <dan...@dnil.se>
Reply-To: <beagl...@googlegroups.com>
Date: Sunday, February 23, 2014 at 1:19 PM
To: <beagl...@googlegroups.com>
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.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

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

[quik...@gmail.com]

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.

[quik...@gmail.com]

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.

[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.

--
Charles Steinkuehler
cha...@steinkuehler.net

[David Goodenough]

On Monday 24 February 2014 08:43:27 quik...@gmail.com 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:

[dlewin555]

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.

[quik...@gmail.com]

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.

[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.

>> cha...@steinkuehler.net <javascript:>
>>
>


--
Charles Steinkuehler
cha...@steinkuehler.net

[quik...@gmail.com]

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:

root@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:

root@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.

[quik...@gmail.com]

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.

[Robert Nelson]

On Wed, Feb 26, 2014 at 7:59 AM, <quik...@gmail.com> 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/

[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.

--
Charles Steinkuehler
cha...@steinkuehler.net

[quik...@gmail.com]

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?

[quik...@gmail.com]

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.

[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...@gmail.com 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.
>>

[rchrd...@gmail.com]

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.

[quik...@gmail.com]

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.

[Yang]

Hi ,all. I had been reading this thread of PREEMPT_RT for a few days.
(I miss the starting mails since I can't get to the web page of google groups)

For my situation, I just need my userspace program run once every 1ms sys tick.
The result will be writed to a fifo in FPGA to achive realtime IO control.

Can this be achive by eanbling PREEMPT ? any other works need?

　　

======== 2014-02-28 16:53:26 您在来信中写道： ========

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:

--
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...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

在此邮件中未发现病毒。
检查工具：AVG - www.avg.com
版本：2014.0.4259 / 病毒数据库：3705/7143 - 发布日期：03/02/14

= = = = = = = = = = = = = = = = = = = = = =
　　　　　　　　致
礼！

　　　　　　　　　　　　　　Yang
　　　　　　　　　　　　　　wing...@163.com
　　　　　　　　　　　　　　　2014-03-04

[quik...@gmail.com]

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:

[quik...@gmail.com]

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.

[fj.r...@openmailbox.org]

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.bz2 into 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.
 

[quik...@gmail.com]

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.

[dickelbeck]

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

[mhfar...@gmail.com]

Hi thats great!

Is that possible to have your compiled kernel for BBB? I would avoid the compiling process.
Thanks a lot,

Morteza

[quik...@gmail.com]

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.

[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...@gmail.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...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

在此邮件中未发现病毒。 检查工具：AVG - www.avg.com

版本：2013.0.3462 / 病毒数据库：3722/7208 - 发布日期：03/17/14

= = = = = = = = = = = = = = = = = = = = = =

　　　　　　　　致
礼！

 

　　　　　　　　　　　　　　winglion

　　　　　　　　　　　　　　wing...@163.com

　　　　　　　　　　　　　　　2014-03-19

 

[quik...@gmail.com]

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:



[Yang]

quikcjack！

 

　　  Oh, thanks! I will try to get it later. I had allways use email to read this board,

since I am form mainland China and can't access this board form web page. :-( 

Any way, thansk for your work and help.

 

======== 2014-04-04 23:08:32 您在来信中写道： ========

　　　　　　　　　　　　　　Yang

　　　　　　　　　　　　　　wing...@163.com

　　　　　　　　　　　　　　　2014-07-01