Re: [beagleboard] Re: BBB + PREEMPT_RT

2014-02-23 Thread 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

On Sun, Feb 23, 2014 at 10:06 PM, John Syn  wrote:

>
> From: "robert.berger" 
> Reply-To: 
> Date: Sunday, February 23, 2014 at 3:26 AM
> To: 
> Cc: 
> 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
>
> --
> 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.
>
>  --
> 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+unsubscr...@googlegroups.com.
> 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[beagleboard] Re: BBB + PREEMPT_RT

2014-02-23 Thread 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


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

Re: [beagleboard] BeagleBone Black: is it a Real-Time Board?

2013-12-13 Thread Daniel Nilsson 
Hi,

Linux is per default not a real-time OS, but you can turn it into a "firm" 
real-time OS using for example the PREEMPT-RT patch. However, you will 
still not the kind of absolute guaranteed latencies you would be able to 
get from a dedicated real-time OS.

If you need a real-time OS I think at least QNX should be supported on the 
BBB;

http://community.qnx.com/sf/wiki/do/viewPage/projects.bsp/wiki/TiAm335Beaglebone

Gerald, I assume you are answering from the perspective of the capabilities 
of the Sitara ARM SoC and there I agree that it is capable of industrial 
control systems. However, Alessandro asks if the BBB can be used for 
critical applications in industrial environments. I wouldn't call the HW 
design of the BBB "rugged" like what you would expect to see in those 
environments. After all, it is a $45 computer... Using the BBB to prototype 
those applications is likely OK, but I would recommend a rugged HW design 
to put such a system into operation in critical industrial environments.

/Daniel

On Friday, December 13, 2013 2:45:11 PM UTC+1, Gerald wrote:
>
> Yes. Assuming the SW you run is real-time in nature.
>
> Gerald
>
>
> On Fri, Dec 13, 2013 at 6:50 AM, > wrote:
>
>> Hi all,
>>
>> is it possible to use the BeagleBone Black as a Real-Time board, that 
>> allows it to be used for critical applications, like in industrial 
>> environment?
>>
>> Thank you very much!
>>
>> Alessandro
>>
>> -- 
>> 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.
>>
>
>

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

[beagleboard] Re: Has anybody tested the new Graphics SDK which should enable SGX on kernel 3.12?

2013-12-10 Thread Daniel Nilsson 
Hi,

I haven't tried the links you posted below, but I played around tonight 
with the latest bits in the arago project and now I have accelerated 3D 
graphics support on a beaglebone black. Using the beaglebone black BSP 
support in meta-ti, I get a 3.12.4 Linux kernel and then I built 
the arago-base-tisdk-image as root filesystem. Result is a beaglebone black 
which displays accelerated 3D graphics on the display connected over HDMI, 
so the SGX drivers are now available för the 3.12 kernel (in arago) but 
still not packaged nicely for the BBB I guess.

Regards
Daniel


On Monday, December 9, 2013 10:38:10 AM UTC+1, Giuseppe Iellamo wrote:
>
> As the title states... has anybody tried? 
>
>
> http://processors.wiki.ti.com/index.php/RN_5_00_00_01_alpha
>
>
> http://e2e.ti.com/support/arm/sitara_arm/f/791/p/298596/1072533.aspx#1072533
>

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

Re: [beagleboard] Re: Audio Cape with Beaglebone Black

2013-12-02 Thread Daniel Nilsson 
On Mon, Dec 2, 2013 at 12:45 AM, Robert Nelson wrote:

> On Sun, Dec 1, 2013 at 5:43 PM, Yasir K  wrote:
> > Thanks Robert for helping out, the patch provided by cody fails, i
> wonder if
> > anyone else has got it working and specifically under what conditions?
>
> This is normal kernel patch backporting.. First compare
> sound/soc/davinci/davinci-evm.c & sound/soc/davinci/davinci-evm.c.rej
> and fix it up..
>

Robert,

It seems like you have already added the patch from Cody to your tree
(patches/hdmi/0028-Make-the-McASP-code-generic-again-remove-all-hardcod.patch)
that I believe Yasir is trying to apply. This seems to have been the only
change from 3.8.13-bone29 to 3.8.13-bone30. So people that would like to
try the audio patch from Cody should only have to compile your v3.8 branch
and nothing else, correct?

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

Re: [beagleboard] Re: Audio Cape with Beaglebone Black

2013-12-02 Thread Daniel Nilsson 
On Mon, Dec 2, 2013 at 12:43 AM, Yasir K  wrote:

> Thanks Robert for helping out, the patch provided by cody fails, i wonder
> if anyone else has got it working and specifically under what conditions?
>


Yes, I have used it and it works under the conditions that Cody stated it
should be used under (the 3.8 kernel). Seems like you are trying to apply
it on the 3.12 kernel, which would require some work on your side.

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

[beagleboard] Re: Undefined reference to `clock_gettime'

2013-10-04 Thread Daniel Nilsson 
Hi,

You need to link you application with -lrt.

/Daniel


On Friday, October 4, 2013 3:30:06 PM UTC+2, tvv...@gmail.com wrote:
>
> Hello!
> I've setup cross compile environment using Eclipse according to the guide 
> here
> . 
> In this code:
>
> #include "Timer.h"
> #include 
>
>
> unsigned long millis(void)
> {
> struct timespec ts;
> clock_gettime(CLOCK_MONOTONIC,  &ts );
> return ( ts.tv_sec * 1000 + ts.tv_nsec / 100L );
> }
>
> #ifndef TIMER_H_
> #define TIMER_H_
>
> #define CLOCK_MONOTONIC 1
>
> unsigned long millis ();
>
> #endif /* TIMER_H_ */
>
>
>
> I have error:
>
> undefined reference to `clock_gettime'
>
> Another libraries work fine (for example stdio.h, iostream ...), but 
> time.h is not.
>
> Help, please. 
> Thanks
>

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