Linux/OMAP-L138: Linux SDK 04.01.00.06 with PREEMPT_RT

Hi Diego,

Real Time linux kernel was never officially released on OMAP-L138, so we do not support it.
If you want real time features with OMAP-L138 device, you should use the TI RTOS SDK. Officially supported TISDKs are listed here:
www.ti.com/.../toolssoftware

Best Regards,
Yordan

Hi Yordan,

Thanks for your response.

Using the TI RTOS is not an option for us. We'll have to go with Linux. We are upgrading from the seven years old kernel 2.6.33 version with PREEMPT_RT.

I'm just wondering if someone from TI or from the community can give me some kind of guidance on how to add real-time capabilities for OMAP-L138 in this Linux kernel 4.9 version.

RT kernel has not been tested on OMAP-L138 devices yet. What I can suggest is refer to the am335x release:
www.ti.com/.../PROCESSOR-SDK-AM335X
And try to see what is needed to port the PREEMPT_RT into the OMAP-L138 release. The following wiki may be useful:
rt.wiki.kernel.org/.../CONFIG_PREEMPT_RT_Patch
rt.wiki.kernel.org/.../Main_Page
www.kernel.org/.../

Best Regards,
Yordan

Thanks,

But this didn't help to understand why an AM335X has a better determinism than OMAP-L138.

Could be really helpful if someone could point me to an article/page which explains what needs to be changed for a platform to take benefit from PREEMPT_RT patches.

Hi,

At the moment there is not one answer that would resolve the system latency difference between the two platforms. There is not a document that I am aware of (at least not yet) that summarizes the work necessary to lower the OMAP-L138 system latency.

Along the lines of what you mentioned earlier, the platforms that currently support RT-Linux went through considerable work on driver and system analysis looking for anything that added latency to the system.

Also as you point out there maybe some kernel configuration options. The two silicon IPs are different between the OMAP-L138 and the AM335x and config options on the OMAP_L138 may have not affect.

The graph above of the cyclictest results, were these on the 4.9 kernel? If so did you run cylictest on the 2.6.33 kernel? Is there a difference?

Regards,
Schuyler

Hello Schuyler,

Thanks for the information.

The graphs above were on the 4.9 kernel with PREEMPT_RT patches.

Find below the graph for OMAP-L138 on 2.6.33 kernel with PREEMPT_RT patches. As you can see the determinism and maximum latency are much better.

 

Now I'm running the cyclictest with more threads and next week I'll come up with the results. I cleaned up the kernel configuration by removing all DEBUG relate config and will collect the results and make a new comparison.

Hello Diego,

Thanks for posting that latency graph on the earlier kernel, that is a significant difference. I am interested to see the results with the increased threads test. Will this be on the 4.9 kernel or the 2.6?

Best Regards,
Schuyler

Schuyler,

I'll plot the graphs for both kernel versions.

Hello Schuyler,

Find the histogram graphs generated for OMAP-L138 kernel 2.6.33-rt and 4.9-rt. The latency data was stored in the RAM. I included the summary data as well.

Command used: cyclictest -D67h -m -p80 -i1000 -h100000 -q -t5 -n > /tmp/output

Tread ID - 2.6.33 - Latencies	Min	Avg	Max
0	47	76	181
1	49	83	196
2	50	85	213
3	46	104	263
4	49	88	276

Tread ID - 4.9 Latencies	Min	Avg	Max
0	102	156	484
1	46	85	309
2	100	136	404
3	57	83	498
4	89	123	289

Hi Diego,

Are you still looking at using the 4.9 kernel on the OMAP-L138? Have you looked for an RT mailing list? I am trying to see if there is a community mailing list somewhere where some guidance on how to proceed might be obtained.

Regards,
Schuyler

@Schuyler,

I haven't progressed too much. We had different results when running cyclictest without generating histogram data. In that case, the new kernel (4.9) is slightly better.

We are now analyzing other aspects of the upgrade like our own drivers to decide to upgrade or not and if we are going to upgrade I'll take a look at this in detail. Any new information I'll be posting into here.

Thanks for your kindly help.

And by the way, do you know if TI accepts patches from its costumers?

Hi Diego,

TI does accept patches from contributors outside of TI but there is a process. On the current supported processors patches can be submitted to a mailing list where driver maintainers will review patches and provide feedback or ACK them. However since TI is not supporting the processor used here so there may not be anybody to merge the patches into the source tree. I will check to see if what would happen to a patch submitted for the omapl138.

Best Regards,
Schuyler