* [Xenomai] OMAP L138
@ 2014-04-02 2:59 Peter Howard
2014-04-02 7:24 ` Gilles Chanteperdrix
0 siblings, 1 reply; 57+ messages in thread
From: Peter Howard @ 2014-04-02 2:59 UTC (permalink / raw)
To: xenomai
Hi,
I'm interested in running xenomai on a TI-OMAP L138 board. I found the
following thread in the archives:
http://www.xenomai.org/pipermail/xenomai/2010-January/018898.html
where someone was working on porting ipipe and xenomai to that board.
However, the thread ended with problems still unresolved, and the patch
in the thread (just the changes for ipipe) isn't in the ipipe
repository.
Does anyone know if this work was completed or just faded into the
ether?
Thanks in advance.
--
Peter Howard <pjh@northern-ridge.com.au>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-02 2:59 [Xenomai] OMAP L138 Peter Howard
@ 2014-04-02 7:24 ` Gilles Chanteperdrix
2014-04-02 22:37 ` Peter Howard
2014-04-07 5:34 ` Peter Howard
0 siblings, 2 replies; 57+ messages in thread
From: Gilles Chanteperdrix @ 2014-04-02 7:24 UTC (permalink / raw)
To: Peter Howard; +Cc: xenomai
On 04/02/2014 04:59 AM, Peter Howard wrote:
> Hi,
>
> I'm interested in running xenomai on a TI-OMAP L138 board. I found the
> following thread in the archives:
>
> http://www.xenomai.org/pipermail/xenomai/2010-January/018898.html
>
> where someone was working on porting ipipe and xenomai to that board.
> However, the thread ended with problems still unresolved, and the patch
> in the thread (just the changes for ipipe) isn't in the ipipe
> repository.
>
> Does anyone know if this work was completed or just faded into the
> ether?
We never merged a patch for this processor. And a lot of things changed
since that time. If you are interested in porting the I-pipe patch to
this processor, see:
http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
--
Gilles.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-02 7:24 ` Gilles Chanteperdrix
@ 2014-04-02 22:37 ` Peter Howard
2014-04-02 23:31 ` Gilles Chanteperdrix
2014-04-07 5:34 ` Peter Howard
1 sibling, 1 reply; 57+ messages in thread
From: Peter Howard @ 2014-04-02 22:37 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On Wed, 2014-04-02 at 09:24 +0200, Gilles Chanteperdrix wrote:
> On 04/02/2014 04:59 AM, Peter Howard wrote:
> > Hi,
> >
> > I'm interested in running xenomai on a TI-OMAP L138 board. I found the
> > following thread in the archives:
> >
> > http://www.xenomai.org/pipermail/xenomai/2010-January/018898.html
> >
> > where someone was working on porting ipipe and xenomai to that board.
> > However, the thread ended with problems still unresolved, and the patch
> > in the thread (just the changes for ipipe) isn't in the ipipe
> > repository.
> >
> > Does anyone know if this work was completed or just faded into the
> > ether?
>
> We never merged a patch for this processor. And a lot of things changed
> since that time. If you are interested in porting the I-pipe patch to
> this processor, see:
>
> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
>
Thanks for that. A further question - the latest "official" kernel for
that board is 3.3. Looking through the ipip git repo I can trace back
against mainline to 3.8, but no further. Did work in the git repo
(re-)start then? Or am I missing things?
Thanks,
--
Peter Howard <pjh@northern-ridge.com.au>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-02 22:37 ` Peter Howard
@ 2014-04-02 23:31 ` Gilles Chanteperdrix
2014-04-03 1:28 ` Peter Howard
0 siblings, 1 reply; 57+ messages in thread
From: Gilles Chanteperdrix @ 2014-04-02 23:31 UTC (permalink / raw)
To: Peter Howard; +Cc: xenomai
On 04/03/2014 12:37 AM, Peter Howard wrote:
> On Wed, 2014-04-02 at 09:24 +0200, Gilles Chanteperdrix wrote:
>> On 04/02/2014 04:59 AM, Peter Howard wrote:
>>> Hi,
>>>
>>> I'm interested in running xenomai on a TI-OMAP L138 board. I found the
>>> following thread in the archives:
>>>
>>> http://www.xenomai.org/pipermail/xenomai/2010-January/018898.html
>>>
>>> where someone was working on porting ipipe and xenomai to that board.
>>> However, the thread ended with problems still unresolved, and the patch
>>> in the thread (just the changes for ipipe) isn't in the ipipe
>>> repository.
>>>
>>> Does anyone know if this work was completed or just faded into the
>>> ether?
>>
>> We never merged a patch for this processor. And a lot of things changed
>> since that time. If you are interested in porting the I-pipe patch to
>> this processor, see:
>>
>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
>>
>
> Thanks for that. A further question - the latest "official" kernel for
> that board is 3.3. Looking through the ipip git repo I can trace back
> against mainline to 3.8, but no further. Did work in the git repo
> (re-)start then? Or am I missing things?
I do not know which git you are talking about, but the "official" git,
that is:
http://git.xenomai.org/ipipe.git/refs/heads
goes back to 2.6.19.
--
Gilles.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-02 23:31 ` Gilles Chanteperdrix
@ 2014-04-03 1:28 ` Peter Howard
0 siblings, 0 replies; 57+ messages in thread
From: Peter Howard @ 2014-04-03 1:28 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On Thu, 2014-04-03 at 01:31 +0200, Gilles Chanteperdrix wrote:
> On 04/03/2014 12:37 AM, Peter Howard wrote:
> > On Wed, 2014-04-02 at 09:24 +0200, Gilles Chanteperdrix wrote:
> >> On 04/02/2014 04:59 AM, Peter Howard wrote:
> >>> Hi,
> >>>
> >>> I'm interested in running xenomai on a TI-OMAP L138 board. I found the
> >>> following thread in the archives:
> >>>
> >>> http://www.xenomai.org/pipermail/xenomai/2010-January/018898.html
> >>>
> >>> where someone was working on porting ipipe and xenomai to that board.
> >>> However, the thread ended with problems still unresolved, and the patch
> >>> in the thread (just the changes for ipipe) isn't in the ipipe
> >>> repository.
> >>>
> >>> Does anyone know if this work was completed or just faded into the
> >>> ether?
> >>
> >> We never merged a patch for this processor. And a lot of things changed
> >> since that time. If you are interested in porting the I-pipe patch to
> >> this processor, see:
> >>
> >> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
> >>
> >
> > Thanks for that. A further question - the latest "official" kernel for
> > that board is 3.3. Looking through the ipip git repo I can trace back
> > against mainline to 3.8, but no further. Did work in the git repo
> > (re-)start then? Or am I missing things?
>
> I do not know which git you are talking about, but the "official" git,
> that is:
>
> http://git.xenomai.org/ipipe.git/refs/heads
>
> goes back to 2.6.19.
>
>
Brain fade on my part (briefly forgetting everything I know about git
branches). Sorry for that - all good now.
--
Peter Howard <pjh@northern-ridge.com.au>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-02 7:24 ` Gilles Chanteperdrix
2014-04-02 22:37 ` Peter Howard
@ 2014-04-07 5:34 ` Peter Howard
2014-04-07 9:53 ` Gilles Chanteperdrix
2014-04-08 9:18 ` Gilles Chanteperdrix
1 sibling, 2 replies; 57+ messages in thread
From: Peter Howard @ 2014-04-07 5:34 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On Wed, 2014-04-02 at 09:24 +0200, Gilles Chanteperdrix wrote:
> On 04/02/2014 04:59 AM, Peter Howard wrote:
> > Hi,
> >
> > I'm interested in running xenomai on a TI-OMAP L138 board. I found the
> > following thread in the archives:
> >
> > http://www.xenomai.org/pipermail/xenomai/2010-January/018898.html
> >
> > where someone was working on porting ipipe and xenomai to that board.
> > However, the thread ended with problems still unresolved, and the patch
> > in the thread (just the changes for ipipe) isn't in the ipipe
> > repository.
> >
> > Does anyone know if this work was completed or just faded into the
> > ether?
>
> We never merged a patch for this processor. And a lot of things changed
> since that time. If you are interested in porting the I-pipe patch to
> this processor, see:
>
> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
>
Contrary to what I said last week, I'm working on a patch off the head
of the ipipe repo. I have built a kernel with an ipipe port and with
xenomai patched in. However the latency results are bad right now:
root@arago:~# xeno latency -T 25
== Sampling period: 1000 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| 3.541| 8.833| 60.749| 0| 0| 3.541| 60.749
RTD| 3.499| 13.583| 93.916| 0| 0| 3.499| 93.916
RTD| 3.666| 88.999| 109.708| 0| 0| 3.499| 109.708
RTD| 3.541| 14.958| 95.374| 0| 0| 3.499| 109.708
RTD| 3.541| 9.333| 77.583| 0| 0| 3.499| 109.708
RTD| 4.041| 88.416| 109.791| 0| 0| 3.499| 109.791
RTD| 3.499| 8.958| 72.791| 0| 0| 3.499| 109.791
RTD| 3.499| 26.041| 106.874| 0| 0| 3.499| 109.791
RTD| 3.874| 82.708| 107.916| 0| 0| 3.499| 109.791
RTD| 3.499| 9.083| 73.708| 0| 0| 3.499| 109.791
RTD| 3.333| 8.874| 62.458| 0| 0| 3.333| 109.791
RTD| 3.333| 8.749| 62.208| 0| 0| 3.333| 109.791
RTD| 3.416| 12.708| 99.416| 0| 0| 3.333| 109.791
RTD| 3.499| 14.249| 106.749| 0| 0| 3.333| 109.791
RTD| 3.541| 9.083| 76.499| 0| 0| 3.333| 109.791
RTD| 3.249| 8.791| 63.499| 0| 0| 3.249| 109.791
RTD| 3.416| 8.999| 62.499| 0| 0| 3.249| 109.791
RTD| 3.541| 26.166| 101.208| 0| 0| 3.249| 109.791
RTD| 3.583| 13.624| 92.458| 0| 0| 3.249| 109.791
RTD| 3.541| 8.916| 73.708| 0| 0| 3.249| 109.791
RTD| 3.541| 8.999| 64.291| 0| 0| 3.249| 109.791
RTT| 00:00:22 (periodic user-mode task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| 3.499| 8.874| 61.374| 0| 0| 3.249| 109.791
RTD| 3.499| 13.833| 100.749| 0| 0| 3.249| 109.791
RTD| 3.541| 13.083| 99.249| 0| 0| 3.249| 109.791
---|-----------|-----------|-----------|--------|------|------------------------
RTS| 3.249| 21.458| 109.791| 0| 0| 00:00:25/00:00:25
root@arago:~#
I have confirmed that CONFIG_CPU_FREQ, CONFIG_CPU_IDLE,
CONFIG_CC_STACKPROTECTOR, and CONFIG_KGDB are turned off. There are no
obvious errors in the system log:
root@arago:~# dmesg | grep Xenomai
I-pipe: head domain Xenomai registered.
Xenomai: hal/arm started.
Xenomai: scheduling class idle registered.
Xenomai: scheduling class rt registered.
Xenomai: real-time nucleus v2.6.3 (Lies and Truths) loaded.
Xenomai: debug mode enabled.
Xenomai: starting native API services.
Xenomai: starting POSIX services.
Xenomai: starting RTDM services.
root@arago:~#
The one change I had to make in the xenomai patch was:
diff --git a/include/asm-arm/hal.h b/include/asm-arm/hal.h
index d7768e8..4ac0a8f 100644
--- a/include/asm-arm/hal.h
+++ b/include/asm-arm/hal.h
@@ -95,6 +95,9 @@
#elif defined(CONFIG_PLAT_SPEAR)
#define RTHAL_TIMER_DEVICE "tmr0"
#define RTHAL_CLOCK_DEVICE "tmr1"
+#elif defined(CONFIG_ARCH_DAVINCI)
+#define RTHAL_TIMER_DEVICE "gp timer"
+#define RTHAL_CLOCK_DEVICE "gp timer"
#else
#error "Unsupported ARM machine"
#endif /* CONFIG_ARCH_SA1100 */
Was that correct? Any other suggestions?
--
Peter Howard <pjh@northern-ridge.com.au>
^ permalink raw reply related [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-07 5:34 ` Peter Howard
@ 2014-04-07 9:53 ` Gilles Chanteperdrix
2014-04-08 2:37 ` Peter Howard
2014-04-08 9:18 ` Gilles Chanteperdrix
1 sibling, 1 reply; 57+ messages in thread
From: Gilles Chanteperdrix @ 2014-04-07 9:53 UTC (permalink / raw)
To: Peter Howard; +Cc: xenomai
On 04/07/2014 07:34 AM, Peter Howard wrote:
>
> On Wed, 2014-04-02 at 09:24 +0200, Gilles Chanteperdrix wrote:
>> On 04/02/2014 04:59 AM, Peter Howard wrote:
>>> Hi,
>>>
>>> I'm interested in running xenomai on a TI-OMAP L138 board. I found the
>>> following thread in the archives:
>>>
>>> http://www.xenomai.org/pipermail/xenomai/2010-January/018898.html
>>>
>>> where someone was working on porting ipipe and xenomai to that board.
>>> However, the thread ended with problems still unresolved, and the patch
>>> in the thread (just the changes for ipipe) isn't in the ipipe
>>> repository.
>>>
>>> Does anyone know if this work was completed or just faded into the
>>> ether?
>>
>> We never merged a patch for this processor. And a lot of things changed
>> since that time. If you are interested in porting the I-pipe patch to
>> this processor, see:
>>
>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
>>
>
> Contrary to what I said last week, I'm working on a patch off the head
> of the ipipe repo. I have built a kernel with an ipipe port and with
> xenomai patched in. However the latency results are bad right now:
Well, in that case enable the I-pipe tracer, and run latency with the -f
option to know why.
--
Gilles.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-07 9:53 ` Gilles Chanteperdrix
@ 2014-04-08 2:37 ` Peter Howard
2014-04-08 8:12 ` Gilles Chanteperdrix
0 siblings, 1 reply; 57+ messages in thread
From: Peter Howard @ 2014-04-08 2:37 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On Mon, 2014-04-07 at 11:53 +0200, Gilles Chanteperdrix wrote:
> On 04/07/2014 07:34 AM, Peter Howard wrote:
> >
> > On Wed, 2014-04-02 at 09:24 +0200, Gilles Chanteperdrix wrote:
> >> On 04/02/2014 04:59 AM, Peter Howard wrote:
> >>> Hi,
> >>>
> >>> I'm interested in running xenomai on a TI-OMAP L138 board. I found the
> >>> following thread in the archives:
> >>>
> >>> http://www.xenomai.org/pipermail/xenomai/2010-January/018898.html
> >>>
> >>> where someone was working on porting ipipe and xenomai to that board.
> >>> However, the thread ended with problems still unresolved, and the patch
> >>> in the thread (just the changes for ipipe) isn't in the ipipe
> >>> repository.
> >>>
> >>> Does anyone know if this work was completed or just faded into the
> >>> ether?
> >>
> >> We never merged a patch for this processor. And a lot of things changed
> >> since that time. If you are interested in porting the I-pipe patch to
> >> this processor, see:
> >>
> >> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
> >>
> >
> > Contrary to what I said last week, I'm working on a patch off the head
> > of the ipipe repo. I have built a kernel with an ipipe port and with
> > xenomai patched in. However the latency results are bad right now:
>
> Well, in that case enable the I-pipe tracer, and run latency with the -f
> option to know why.
>
I turned the tracing on and . . . start getting kernel panics from a
NULL pointer dereference. If I have tracing on from boot it dies
shortly after getting to the login prompt. If I disable it at boot, I
start getting ext-3 errors as soon as I enable it (losing the ability to
read the filesystem at all), then get the panic a few seconds later. I
get an I-pipe tracer log along with the panic, but aren't really sure
how to interpret it in this context. In all cases the failure appears
to be in the context of __ipipe_trace():
Unable to handle kernel NULL pointer dereference at virtual address 00000004
pgd = c73e8000, hw pgd = c73e8000
[00000004] *pgd=c72a3831, *pte=00000000, *ppte=00000000
Internal error: Oops: 817 [#1] PREEMPT ARM
Modules linked in:
CPU: 0 PID: 2307 Comm: run-parts Not tainted 3.10.0-ipipe-00165-g9a2c8c8-dirty 5
task: c70ef800 ti: c737a000 task.ti: c737a000
PC is at get_page_from_freelist+0x164/0x750
LR is at __ipipe_trace+0xa8/0x5b8
I'm going to keep digging to see if I can work out what the actual
failure is, but any suggestions would be appreciated. (I can provide
full dump and following trace log if it would be useful)
>
--
Peter Howard <pjh@northern-ridge.com.au>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-08 2:37 ` Peter Howard
@ 2014-04-08 8:12 ` Gilles Chanteperdrix
2014-04-08 23:44 ` Peter Howard
0 siblings, 1 reply; 57+ messages in thread
From: Gilles Chanteperdrix @ 2014-04-08 8:12 UTC (permalink / raw)
To: Peter Howard; +Cc: xenomai
On 04/08/2014 04:37 AM, Peter Howard wrote:
> On Mon, 2014-04-07 at 11:53 +0200, Gilles Chanteperdrix wrote:
>> On 04/07/2014 07:34 AM, Peter Howard wrote:
>>>
>>> On Wed, 2014-04-02 at 09:24 +0200, Gilles Chanteperdrix wrote:
>>>> On 04/02/2014 04:59 AM, Peter Howard wrote:
>>>>> Hi,
>>>>>
>>>>> I'm interested in running xenomai on a TI-OMAP L138 board. I found the
>>>>> following thread in the archives:
>>>>>
>>>>> http://www.xenomai.org/pipermail/xenomai/2010-January/018898.html
>>>>>
>>>>> where someone was working on porting ipipe and xenomai to that board.
>>>>> However, the thread ended with problems still unresolved, and the patch
>>>>> in the thread (just the changes for ipipe) isn't in the ipipe
>>>>> repository.
>>>>>
>>>>> Does anyone know if this work was completed or just faded into the
>>>>> ether?
>>>>
>>>> We never merged a patch for this processor. And a lot of things changed
>>>> since that time. If you are interested in porting the I-pipe patch to
>>>> this processor, see:
>>>>
>>>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
>>>>
>>>
>>> Contrary to what I said last week, I'm working on a patch off the head
>>> of the ipipe repo. I have built a kernel with an ipipe port and with
>>> xenomai patched in. However the latency results are bad right now:
>>
>> Well, in that case enable the I-pipe tracer, and run latency with the -f
>> option to know why.
>>
>
> I turned the tracing on and . . . start getting kernel panics from a
> NULL pointer dereference. If I have tracing on from boot it dies
> shortly after getting to the login prompt. If I disable it at boot, I
> start getting ext-3 errors as soon as I enable it (losing the ability to
> read the filesystem at all), then get the panic a few seconds later. I
> get an I-pipe tracer log along with the panic, but aren't really sure
> how to interpret it in this context. In all cases the failure appears
> to be in the context of __ipipe_trace():
Do you have CONFIG_IPIPE_TRACE_VMALLOC turned on? If not, you should. If
the backtraces are not meaningful, you can try disabling stack unwinding.
>
>
> Unable to handle kernel NULL pointer dereference at virtual address 00000004
> pgd = c73e8000, hw pgd = c73e8000
> [00000004] *pgd=c72a3831, *pte=00000000, *ppte=00000000
> Internal error: Oops: 817 [#1] PREEMPT ARM
> Modules linked in:
> CPU: 0 PID: 2307 Comm: run-parts Not tainted 3.10.0-ipipe-00165-g9a2c8c8-dirty 5
> task: c70ef800 ti: c737a000 task.ti: c737a000
> PC is at get_page_from_freelist+0x164/0x750
> LR is at __ipipe_trace+0xa8/0x5b8
>
>
> I'm going to keep digging to see if I can work out what the actual
> failure is, but any suggestions would be appreciated. (I can provide
> full dump and following trace log if it would be useful)
Disable stack unwinding, and show us the backtrace you get, and the full
trace if you get it.
--
Gilles.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-07 5:34 ` Peter Howard
2014-04-07 9:53 ` Gilles Chanteperdrix
@ 2014-04-08 9:18 ` Gilles Chanteperdrix
2014-04-08 23:30 ` Peter Howard
1 sibling, 1 reply; 57+ messages in thread
From: Gilles Chanteperdrix @ 2014-04-08 9:18 UTC (permalink / raw)
To: Peter Howard; +Cc: xenomai
On 04/07/2014 07:34 AM, Peter Howard wrote:
>
> On Wed, 2014-04-02 at 09:24 +0200, Gilles Chanteperdrix wrote:
>> On 04/02/2014 04:59 AM, Peter Howard wrote:
>>> Hi,
>>>
>>> I'm interested in running xenomai on a TI-OMAP L138 board. I found the
>>> following thread in the archives:
>>>
>>> http://www.xenomai.org/pipermail/xenomai/2010-January/018898.html
>>>
>>> where someone was working on porting ipipe and xenomai to that board.
>>> However, the thread ended with problems still unresolved, and the patch
>>> in the thread (just the changes for ipipe) isn't in the ipipe
>>> repository.
>>>
>>> Does anyone know if this work was completed or just faded into the
>>> ether?
>>
>> We never merged a patch for this processor. And a lot of things changed
>> since that time. If you are interested in porting the I-pipe patch to
>> this processor, see:
>>
>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
>>
>
> Contrary to what I said last week, I'm working on a patch off the head
> of the ipipe repo. I have built a kernel with an ipipe port and with
> xenomai patched in. However the latency results are bad right now:
>
> root@arago:~# xeno latency -T 25
> == Sampling period: 1000 us
> == Test mode: periodic user-mode task
> == All results in microseconds
> warming up...
> RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)
> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
> RTD| 3.541| 8.833| 60.749| 0| 0| 3.541| 60.749
> RTD| 3.499| 13.583| 93.916| 0| 0| 3.499| 93.916
> RTD| 3.666| 88.999| 109.708| 0| 0| 3.499| 109.708
> RTD| 3.541| 14.958| 95.374| 0| 0| 3.499| 109.708
> RTD| 3.541| 9.333| 77.583| 0| 0| 3.499| 109.708
> RTD| 4.041| 88.416| 109.791| 0| 0| 3.499| 109.791
> RTD| 3.499| 8.958| 72.791| 0| 0| 3.499| 109.791
> RTD| 3.499| 26.041| 106.874| 0| 0| 3.499| 109.791
> RTD| 3.874| 82.708| 107.916| 0| 0| 3.499| 109.791
> RTD| 3.499| 9.083| 73.708| 0| 0| 3.499| 109.791
> RTD| 3.333| 8.874| 62.458| 0| 0| 3.333| 109.791
> RTD| 3.333| 8.749| 62.208| 0| 0| 3.333| 109.791
> RTD| 3.416| 12.708| 99.416| 0| 0| 3.333| 109.791
> RTD| 3.499| 14.249| 106.749| 0| 0| 3.333| 109.791
> RTD| 3.541| 9.083| 76.499| 0| 0| 3.333| 109.791
> RTD| 3.249| 8.791| 63.499| 0| 0| 3.249| 109.791
> RTD| 3.416| 8.999| 62.499| 0| 0| 3.249| 109.791
> RTD| 3.541| 26.166| 101.208| 0| 0| 3.249| 109.791
> RTD| 3.583| 13.624| 92.458| 0| 0| 3.249| 109.791
> RTD| 3.541| 8.916| 73.708| 0| 0| 3.249| 109.791
> RTD| 3.541| 8.999| 64.291| 0| 0| 3.249| 109.791
> RTT| 00:00:22 (periodic user-mode task, 1000 us period, priority 99)
> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
> RTD| 3.499| 8.874| 61.374| 0| 0| 3.249| 109.791
> RTD| 3.499| 13.833| 100.749| 0| 0| 3.249| 109.791
> RTD| 3.541| 13.083| 99.249| 0| 0| 3.249| 109.791
> ---|-----------|-----------|-----------|--------|------|------------------------
> RTS| 3.249| 21.458| 109.791| 0| 0| 00:00:25/00:00:25
> root@arago:~#
Note that if the OMAPL138 is an armv4 or armv5, you may want to enable
the FCSE in order to reduce context switch time (and latencies).
--
Gilles.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-08 9:18 ` Gilles Chanteperdrix
@ 2014-04-08 23:30 ` Peter Howard
2014-04-09 0:18 ` Gilles Chanteperdrix
2014-04-09 0:20 ` Gilles Chanteperdrix
0 siblings, 2 replies; 57+ messages in thread
From: Peter Howard @ 2014-04-08 23:30 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On Tue, 2014-04-08 at 11:18 +0200, Gilles Chanteperdrix wrote:
> On 04/07/2014 07:34 AM, Peter Howard wrote:
> >
> > On Wed, 2014-04-02 at 09:24 +0200, Gilles Chanteperdrix wrote:
> >> On 04/02/2014 04:59 AM, Peter Howard wrote:
> >>> Hi,
> >>>
> >>> I'm interested in running xenomai on a TI-OMAP L138 board. I found the
> >>> following thread in the archives:
> >>>
> >>> http://www.xenomai.org/pipermail/xenomai/2010-January/018898.html
> >>>
> >>> where someone was working on porting ipipe and xenomai to that board.
> >>> However, the thread ended with problems still unresolved, and the patch
> >>> in the thread (just the changes for ipipe) isn't in the ipipe
> >>> repository.
> >>>
> >>> Does anyone know if this work was completed or just faded into the
> >>> ether?
> >>
> >> We never merged a patch for this processor. And a lot of things changed
> >> since that time. If you are interested in porting the I-pipe patch to
> >> this processor, see:
> >>
> >> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
> >>
> >
> > Contrary to what I said last week, I'm working on a patch off the head
> > of the ipipe repo. I have built a kernel with an ipipe port and with
> > xenomai patched in. However the latency results are bad right now:
> >
> > root@arago:~# xeno latency -T 25
> > == Sampling period: 1000 us
> > == Test mode: periodic user-mode task
> > == All results in microseconds
> > warming up...
> > RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)
> > RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
> > RTD| 3.541| 8.833| 60.749| 0| 0| 3.541| 60.749
> > RTD| 3.499| 13.583| 93.916| 0| 0| 3.499| 93.916
> > RTD| 3.666| 88.999| 109.708| 0| 0| 3.499| 109.708
> > RTD| 3.541| 14.958| 95.374| 0| 0| 3.499| 109.708
> > RTD| 3.541| 9.333| 77.583| 0| 0| 3.499| 109.708
> > RTD| 4.041| 88.416| 109.791| 0| 0| 3.499| 109.791
> > RTD| 3.499| 8.958| 72.791| 0| 0| 3.499| 109.791
> > RTD| 3.499| 26.041| 106.874| 0| 0| 3.499| 109.791
> > RTD| 3.874| 82.708| 107.916| 0| 0| 3.499| 109.791
> > RTD| 3.499| 9.083| 73.708| 0| 0| 3.499| 109.791
> > RTD| 3.333| 8.874| 62.458| 0| 0| 3.333| 109.791
> > RTD| 3.333| 8.749| 62.208| 0| 0| 3.333| 109.791
> > RTD| 3.416| 12.708| 99.416| 0| 0| 3.333| 109.791
> > RTD| 3.499| 14.249| 106.749| 0| 0| 3.333| 109.791
> > RTD| 3.541| 9.083| 76.499| 0| 0| 3.333| 109.791
> > RTD| 3.249| 8.791| 63.499| 0| 0| 3.249| 109.791
> > RTD| 3.416| 8.999| 62.499| 0| 0| 3.249| 109.791
> > RTD| 3.541| 26.166| 101.208| 0| 0| 3.249| 109.791
> > RTD| 3.583| 13.624| 92.458| 0| 0| 3.249| 109.791
> > RTD| 3.541| 8.916| 73.708| 0| 0| 3.249| 109.791
> > RTD| 3.541| 8.999| 64.291| 0| 0| 3.249| 109.791
> > RTT| 00:00:22 (periodic user-mode task, 1000 us period, priority 99)
> > RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
> > RTD| 3.499| 8.874| 61.374| 0| 0| 3.249| 109.791
> > RTD| 3.499| 13.833| 100.749| 0| 0| 3.249| 109.791
> > RTD| 3.541| 13.083| 99.249| 0| 0| 3.249| 109.791
> > ---|-----------|-----------|-----------|--------|------|------------------------
> > RTS| 3.249| 21.458| 109.791| 0| 0| 00:00:25/00:00:25
> > root@arago:~#
>
> Note that if the OMAPL138 is an armv4 or armv5, you may want to enable
> the FCSE in order to reduce context switch time (and latencies).
>
>
I enabled FCSE, and the max latency is more consistent (though the min
and average latency has climbed). How do the below figures look?
root@arago:~# xeno latency -T 25
== Sampling period: 1000 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| 8.499| 32.874| 105.791| 0| 0| 8.499| 105.791
RTD| 8.041| 18.458| 80.416| 0| 0| 8.041| 105.791
RTD| 8.416| 14.124| 62.374| 0| 0| 8.041| 105.791
RTD| 8.791| 14.666| 66.541| 0| 0| 8.041| 105.791
RTD| 8.249| 14.749| 69.916| 0| 0| 8.041| 105.791
RTD| 8.749| 17.833| 87.208| 0| 0| 8.041| 105.791
RTD| 8.499| 18.291| 77.583| 0| 0| 8.041| 105.791
RTD| 8.291| 14.166| 65.541| 0| 0| 8.041| 105.791
RTD| 8.458| 14.624| 64.874| 0| 0| 8.041| 105.791
RTD| 8.249| 14.208| 66.624| 0| 0| 8.041| 105.791
RTD| 8.708| 17.208| 86.041| 0| 0| 8.041| 105.791
RTD| 8.708| 18.374| 76.291| 0| 0| 8.041| 105.791
RTD| 8.499| 14.958| 71.458| 0| 0| 8.041| 105.791
RTD| 16.041| 24.291| 85.541| 0| 0| 8.041| 105.791
RTD| 8.083| 14.083| 64.749| 0| 0| 8.041| 105.791
RTD| 8.833| 17.416| 87.666| 0| 0| 8.041| 105.791
RTD| 8.749| 24.416| 81.208| 0| 0| 8.041| 105.791
RTD| 8.458| 14.083| 67.374| 0| 0| 8.041| 105.791
RTD| 8.041| 14.624| 64.958| 0| 0| 8.041| 105.791
RTD| 8.666| 23.499| 84.333| 0| 0| 8.041| 105.791
RTD| 7.749| 17.083| 80.249| 0| 0| 7.749| 105.791
RTT| 00:00:22 (periodic user-mode task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| 7.916| 18.208| 81.541| 0| 0| 7.749| 105.791
RTD| 8.541| 27.541| 102.958| 0| 0| 7.749| 105.791
RTD| 8.249| 14.083| 64.416| 0| 0| 7.749| 105.791
---|-----------|-----------|-----------|--------|------|------------------------
RTS| 7.749| 18.041| 105.791| 0| 0| 00:00:25/00:00:25
root@arago:~#
--
Peter Howard <pjh@northern-ridge.com.au>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-08 8:12 ` Gilles Chanteperdrix
@ 2014-04-08 23:44 ` Peter Howard
0 siblings, 0 replies; 57+ messages in thread
From: Peter Howard @ 2014-04-08 23:44 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On Tue, 2014-04-08 at 10:12 +0200, Gilles Chanteperdrix wrote:
> On 04/08/2014 04:37 AM, Peter Howard wrote:
> > On Mon, 2014-04-07 at 11:53 +0200, Gilles Chanteperdrix wrote:
> >> On 04/07/2014 07:34 AM, Peter Howard wrote:
> >>>
> >>> On Wed, 2014-04-02 at 09:24 +0200, Gilles Chanteperdrix wrote:
> >>>> On 04/02/2014 04:59 AM, Peter Howard wrote:
> >>>>> Hi,
> >>>>>
> >>>>> I'm interested in running xenomai on a TI-OMAP L138 board. I found the
> >>>>> following thread in the archives:
> >>>>>
> >>>>> http://www.xenomai.org/pipermail/xenomai/2010-January/018898.html
> >>>>>
> >>>>> where someone was working on porting ipipe and xenomai to that board.
> >>>>> However, the thread ended with problems still unresolved, and the patch
> >>>>> in the thread (just the changes for ipipe) isn't in the ipipe
> >>>>> repository.
> >>>>>
> >>>>> Does anyone know if this work was completed or just faded into the
> >>>>> ether?
> >>>>
> >>>> We never merged a patch for this processor. And a lot of things changed
> >>>> since that time. If you are interested in porting the I-pipe patch to
> >>>> this processor, see:
> >>>>
> >>>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
> >>>>
> >>>
> >>> Contrary to what I said last week, I'm working on a patch off the head
> >>> of the ipipe repo. I have built a kernel with an ipipe port and with
> >>> xenomai patched in. However the latency results are bad right now:
> >>
> >> Well, in that case enable the I-pipe tracer, and run latency with the -f
> >> option to know why.
> >>
> >
> > I turned the tracing on and . . . start getting kernel panics from a
> > NULL pointer dereference. If I have tracing on from boot it dies
> > shortly after getting to the login prompt. If I disable it at boot, I
> > start getting ext-3 errors as soon as I enable it (losing the ability to
> > read the filesystem at all), then get the panic a few seconds later. I
> > get an I-pipe tracer log along with the panic, but aren't really sure
> > how to interpret it in this context. In all cases the failure appears
> > to be in the context of __ipipe_trace():
>
> Do you have CONFIG_IPIPE_TRACE_VMALLOC turned on? If not, you should. If
> the backtraces are not meaningful, you can try disabling stack unwinding.
>
I had already turned on CONFIG_IPIPE_TRACE_VMALLOC delayed the panic,
but didn't remove it. Turning off stack unwinding stops the panic, but
now the console hangs shortly after the boot sequence gets to the login
prompt. I'll have to look at this further (including cutting back the
contents of the rootfs).
> >
> >
> > Unable to handle kernel NULL pointer dereference at virtual address 00000004
> > pgd = c73e8000, hw pgd = c73e8000
> > [00000004] *pgd=c72a3831, *pte=00000000, *ppte=00000000
> > Internal error: Oops: 817 [#1] PREEMPT ARM
> > Modules linked in:
> > CPU: 0 PID: 2307 Comm: run-parts Not tainted 3.10.0-ipipe-00165-g9a2c8c8-dirty 5
> > task: c70ef800 ti: c737a000 task.ti: c737a000
> > PC is at get_page_from_freelist+0x164/0x750
> > LR is at __ipipe_trace+0xa8/0x5b8
> >
> >
> > I'm going to keep digging to see if I can work out what the actual
> > failure is, but any suggestions would be appreciated. (I can provide
> > full dump and following trace log if it would be useful)
>
> Disable stack unwinding, and show us the backtrace you get, and the full
> trace if you get it.
>
--
Peter Howard <pjh@northern-ridge.com.au>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-08 23:30 ` Peter Howard
@ 2014-04-09 0:18 ` Gilles Chanteperdrix
2014-04-09 0:20 ` Gilles Chanteperdrix
1 sibling, 0 replies; 57+ messages in thread
From: Gilles Chanteperdrix @ 2014-04-09 0:18 UTC (permalink / raw)
To: Peter Howard; +Cc: xenomai
On 04/09/2014 01:30 AM, Peter Howard wrote:
> On Tue, 2014-04-08 at 11:18 +0200, Gilles Chanteperdrix wrote:
>> On 04/07/2014 07:34 AM, Peter Howard wrote:
>>>
>>> On Wed, 2014-04-02 at 09:24 +0200, Gilles Chanteperdrix wrote:
>>>> On 04/02/2014 04:59 AM, Peter Howard wrote:
>>>>> Hi,
>>>>>
>>>>> I'm interested in running xenomai on a TI-OMAP L138 board. I found the
>>>>> following thread in the archives:
>>>>>
>>>>> http://www.xenomai.org/pipermail/xenomai/2010-January/018898.html
>>>>>
>>>>> where someone was working on porting ipipe and xenomai to that board.
>>>>> However, the thread ended with problems still unresolved, and the patch
>>>>> in the thread (just the changes for ipipe) isn't in the ipipe
>>>>> repository.
>>>>>
>>>>> Does anyone know if this work was completed or just faded into the
>>>>> ether?
>>>>
>>>> We never merged a patch for this processor. And a lot of things changed
>>>> since that time. If you are interested in porting the I-pipe patch to
>>>> this processor, see:
>>>>
>>>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
>>>>
>>>
>>> Contrary to what I said last week, I'm working on a patch off the head
>>> of the ipipe repo. I have built a kernel with an ipipe port and with
>>> xenomai patched in. However the latency results are bad right now:
>>>
>>> root@arago:~# xeno latency -T 25
>>> == Sampling period: 1000 us
>>> == Test mode: periodic user-mode task
>>> == All results in microseconds
>>> warming up...
>>> RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)
>>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
>>> RTD| 3.541| 8.833| 60.749| 0| 0| 3.541| 60.749
>>> RTD| 3.499| 13.583| 93.916| 0| 0| 3.499| 93.916
>>> RTD| 3.666| 88.999| 109.708| 0| 0| 3.499| 109.708
>>> RTD| 3.541| 14.958| 95.374| 0| 0| 3.499| 109.708
>>> RTD| 3.541| 9.333| 77.583| 0| 0| 3.499| 109.708
>>> RTD| 4.041| 88.416| 109.791| 0| 0| 3.499| 109.791
>>> RTD| 3.499| 8.958| 72.791| 0| 0| 3.499| 109.791
>>> RTD| 3.499| 26.041| 106.874| 0| 0| 3.499| 109.791
>>> RTD| 3.874| 82.708| 107.916| 0| 0| 3.499| 109.791
>>> RTD| 3.499| 9.083| 73.708| 0| 0| 3.499| 109.791
>>> RTD| 3.333| 8.874| 62.458| 0| 0| 3.333| 109.791
>>> RTD| 3.333| 8.749| 62.208| 0| 0| 3.333| 109.791
>>> RTD| 3.416| 12.708| 99.416| 0| 0| 3.333| 109.791
>>> RTD| 3.499| 14.249| 106.749| 0| 0| 3.333| 109.791
>>> RTD| 3.541| 9.083| 76.499| 0| 0| 3.333| 109.791
>>> RTD| 3.249| 8.791| 63.499| 0| 0| 3.249| 109.791
>>> RTD| 3.416| 8.999| 62.499| 0| 0| 3.249| 109.791
>>> RTD| 3.541| 26.166| 101.208| 0| 0| 3.249| 109.791
>>> RTD| 3.583| 13.624| 92.458| 0| 0| 3.249| 109.791
>>> RTD| 3.541| 8.916| 73.708| 0| 0| 3.249| 109.791
>>> RTD| 3.541| 8.999| 64.291| 0| 0| 3.249| 109.791
>>> RTT| 00:00:22 (periodic user-mode task, 1000 us period, priority 99)
>>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
>>> RTD| 3.499| 8.874| 61.374| 0| 0| 3.249| 109.791
>>> RTD| 3.499| 13.833| 100.749| 0| 0| 3.249| 109.791
>>> RTD| 3.541| 13.083| 99.249| 0| 0| 3.249| 109.791
>>> ---|-----------|-----------|-----------|--------|------|------------------------
>>> RTS| 3.249| 21.458| 109.791| 0| 0| 00:00:25/00:00:25
>>> root@arago:~#
>>
>> Note that if the OMAPL138 is an armv4 or armv5, you may want to enable
>> the FCSE in order to reduce context switch time (and latencies).
>>
>>
>
> I enabled FCSE, and the max latency is more consistent (though the min
> and average latency has climbed). How do the below figures look?
Without any load? It is meaningless.
--
Gilles.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-08 23:30 ` Peter Howard
2014-04-09 0:18 ` Gilles Chanteperdrix
@ 2014-04-09 0:20 ` Gilles Chanteperdrix
2014-04-09 0:34 ` Peter Howard
1 sibling, 1 reply; 57+ messages in thread
From: Gilles Chanteperdrix @ 2014-04-09 0:20 UTC (permalink / raw)
To: Peter Howard; +Cc: xenomai
On 04/09/2014 01:30 AM, Peter Howard wrote:
> On Tue, 2014-04-08 at 11:18 +0200, Gilles Chanteperdrix wrote:
>> On 04/07/2014 07:34 AM, Peter Howard wrote:
>>>
>>> On Wed, 2014-04-02 at 09:24 +0200, Gilles Chanteperdrix wrote:
>>>> On 04/02/2014 04:59 AM, Peter Howard wrote:
>>>>> Hi,
>>>>>
>>>>> I'm interested in running xenomai on a TI-OMAP L138 board. I found the
>>>>> following thread in the archives:
>>>>>
>>>>> http://www.xenomai.org/pipermail/xenomai/2010-January/018898.html
>>>>>
>>>>> where someone was working on porting ipipe and xenomai to that board.
>>>>> However, the thread ended with problems still unresolved, and the patch
>>>>> in the thread (just the changes for ipipe) isn't in the ipipe
>>>>> repository.
>>>>>
>>>>> Does anyone know if this work was completed or just faded into the
>>>>> ether?
>>>>
>>>> We never merged a patch for this processor. And a lot of things changed
>>>> since that time. If you are interested in porting the I-pipe patch to
>>>> this processor, see:
>>>>
>>>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
>>>>
>>>
>>> Contrary to what I said last week, I'm working on a patch off the head
>>> of the ipipe repo. I have built a kernel with an ipipe port and with
>>> xenomai patched in. However the latency results are bad right now:
>>>
>>> root@arago:~# xeno latency -T 25
>>> == Sampling period: 1000 us
>>> == Test mode: periodic user-mode task
>>> == All results in microseconds
>>> warming up...
>>> RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)
>>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
>>> RTD| 3.541| 8.833| 60.749| 0| 0| 3.541| 60.749
>>> RTD| 3.499| 13.583| 93.916| 0| 0| 3.499| 93.916
>>> RTD| 3.666| 88.999| 109.708| 0| 0| 3.499| 109.708
>>> RTD| 3.541| 14.958| 95.374| 0| 0| 3.499| 109.708
>>> RTD| 3.541| 9.333| 77.583| 0| 0| 3.499| 109.708
>>> RTD| 4.041| 88.416| 109.791| 0| 0| 3.499| 109.791
>>> RTD| 3.499| 8.958| 72.791| 0| 0| 3.499| 109.791
>>> RTD| 3.499| 26.041| 106.874| 0| 0| 3.499| 109.791
>>> RTD| 3.874| 82.708| 107.916| 0| 0| 3.499| 109.791
>>> RTD| 3.499| 9.083| 73.708| 0| 0| 3.499| 109.791
>>> RTD| 3.333| 8.874| 62.458| 0| 0| 3.333| 109.791
>>> RTD| 3.333| 8.749| 62.208| 0| 0| 3.333| 109.791
>>> RTD| 3.416| 12.708| 99.416| 0| 0| 3.333| 109.791
>>> RTD| 3.499| 14.249| 106.749| 0| 0| 3.333| 109.791
>>> RTD| 3.541| 9.083| 76.499| 0| 0| 3.333| 109.791
>>> RTD| 3.249| 8.791| 63.499| 0| 0| 3.249| 109.791
>>> RTD| 3.416| 8.999| 62.499| 0| 0| 3.249| 109.791
>>> RTD| 3.541| 26.166| 101.208| 0| 0| 3.249| 109.791
>>> RTD| 3.583| 13.624| 92.458| 0| 0| 3.249| 109.791
>>> RTD| 3.541| 8.916| 73.708| 0| 0| 3.249| 109.791
>>> RTD| 3.541| 8.999| 64.291| 0| 0| 3.249| 109.791
>>> RTT| 00:00:22 (periodic user-mode task, 1000 us period, priority 99)
>>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
>>> RTD| 3.499| 8.874| 61.374| 0| 0| 3.249| 109.791
>>> RTD| 3.499| 13.833| 100.749| 0| 0| 3.249| 109.791
>>> RTD| 3.541| 13.083| 99.249| 0| 0| 3.249| 109.791
>>> ---|-----------|-----------|-----------|--------|------|------------------------
>>> RTS| 3.249| 21.458| 109.791| 0| 0| 00:00:25/00:00:25
>>> root@arago:~#
>>
>> Note that if the OMAPL138 is an armv4 or armv5, you may want to enable
>> the FCSE in order to reduce context switch time (and latencies).
>>
>>
>
> I enabled FCSE, and the max latency is more consistent (though the min
> and average latency has climbed). How do the below figures look?
Otherwise, it is hard to say whether there is an issue or not. It is not
uncommon for armv4 or armv5 to have high latencies like this.
On what core is this processor based, running at what frequency?
--
Gilles.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-09 0:20 ` Gilles Chanteperdrix
@ 2014-04-09 0:34 ` Peter Howard
2014-04-09 4:27 ` Peter Howard
0 siblings, 1 reply; 57+ messages in thread
From: Peter Howard @ 2014-04-09 0:34 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On Wed, 2014-04-09 at 02:20 +0200, Gilles Chanteperdrix wrote:
> On 04/09/2014 01:30 AM, Peter Howard wrote:
> > On Tue, 2014-04-08 at 11:18 +0200, Gilles Chanteperdrix wrote:
> >> On 04/07/2014 07:34 AM, Peter Howard wrote:
> >>>
> >>> On Wed, 2014-04-02 at 09:24 +0200, Gilles Chanteperdrix wrote:
> >>>> On 04/02/2014 04:59 AM, Peter Howard wrote:
> >>>>> Hi,
> >>>>>
> >>>>> I'm interested in running xenomai on a TI-OMAP L138 board. I found the
> >>>>> following thread in the archives:
> >>>>>
> >>>>> http://www.xenomai.org/pipermail/xenomai/2010-January/018898.html
> >>>>>
> >>>>> where someone was working on porting ipipe and xenomai to that board.
> >>>>> However, the thread ended with problems still unresolved, and the patch
> >>>>> in the thread (just the changes for ipipe) isn't in the ipipe
> >>>>> repository.
> >>>>>
> >>>>> Does anyone know if this work was completed or just faded into the
> >>>>> ether?
> >>>>
> >>>> We never merged a patch for this processor. And a lot of things changed
> >>>> since that time. If you are interested in porting the I-pipe patch to
> >>>> this processor, see:
> >>>>
> >>>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
> >>>>
> >>>
> >>> Contrary to what I said last week, I'm working on a patch off the head
> >>> of the ipipe repo. I have built a kernel with an ipipe port and with
> >>> xenomai patched in. However the latency results are bad right now:
> >>>
> >>> root@arago:~# xeno latency -T 25
> >>> == Sampling period: 1000 us
> >>> == Test mode: periodic user-mode task
> >>> == All results in microseconds
> >>> warming up...
> >>> RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)
> >>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
> >>> RTD| 3.541| 8.833| 60.749| 0| 0| 3.541| 60.749
> >>> RTD| 3.499| 13.583| 93.916| 0| 0| 3.499| 93.916
> >>> RTD| 3.666| 88.999| 109.708| 0| 0| 3.499| 109.708
> >>> RTD| 3.541| 14.958| 95.374| 0| 0| 3.499| 109.708
> >>> RTD| 3.541| 9.333| 77.583| 0| 0| 3.499| 109.708
> >>> RTD| 4.041| 88.416| 109.791| 0| 0| 3.499| 109.791
> >>> RTD| 3.499| 8.958| 72.791| 0| 0| 3.499| 109.791
> >>> RTD| 3.499| 26.041| 106.874| 0| 0| 3.499| 109.791
> >>> RTD| 3.874| 82.708| 107.916| 0| 0| 3.499| 109.791
> >>> RTD| 3.499| 9.083| 73.708| 0| 0| 3.499| 109.791
> >>> RTD| 3.333| 8.874| 62.458| 0| 0| 3.333| 109.791
> >>> RTD| 3.333| 8.749| 62.208| 0| 0| 3.333| 109.791
> >>> RTD| 3.416| 12.708| 99.416| 0| 0| 3.333| 109.791
> >>> RTD| 3.499| 14.249| 106.749| 0| 0| 3.333| 109.791
> >>> RTD| 3.541| 9.083| 76.499| 0| 0| 3.333| 109.791
> >>> RTD| 3.249| 8.791| 63.499| 0| 0| 3.249| 109.791
> >>> RTD| 3.416| 8.999| 62.499| 0| 0| 3.249| 109.791
> >>> RTD| 3.541| 26.166| 101.208| 0| 0| 3.249| 109.791
> >>> RTD| 3.583| 13.624| 92.458| 0| 0| 3.249| 109.791
> >>> RTD| 3.541| 8.916| 73.708| 0| 0| 3.249| 109.791
> >>> RTD| 3.541| 8.999| 64.291| 0| 0| 3.249| 109.791
> >>> RTT| 00:00:22 (periodic user-mode task, 1000 us period, priority 99)
> >>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
> >>> RTD| 3.499| 8.874| 61.374| 0| 0| 3.249| 109.791
> >>> RTD| 3.499| 13.833| 100.749| 0| 0| 3.249| 109.791
> >>> RTD| 3.541| 13.083| 99.249| 0| 0| 3.249| 109.791
> >>> ---|-----------|-----------|-----------|--------|------|------------------------
> >>> RTS| 3.249| 21.458| 109.791| 0| 0| 00:00:25/00:00:25
> >>> root@arago:~#
> >>
> >> Note that if the OMAPL138 is an armv4 or armv5, you may want to enable
> >> the FCSE in order to reduce context switch time (and latencies).
> >>
> >>
> >
> > I enabled FCSE, and the max latency is more consistent (though the min
> > and average latency has climbed). How do the below figures look?
>
> Otherwise, it is hard to say whether there is an issue or not. It is not
> uncommon for armv4 or armv5 to have high latencies like this.
> On what core is this processor based, running at what frequency?
>
>
It's an AMR926EJ-S r5. Datasheet claims 375MHz, U-boot claims 300MHz.
Load test to follow.
--
Peter Howard <pjh@northern-ridge.com.au>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-09 0:34 ` Peter Howard
@ 2014-04-09 4:27 ` Peter Howard
2014-04-09 11:54 ` Gilles Chanteperdrix
0 siblings, 1 reply; 57+ messages in thread
From: Peter Howard @ 2014-04-09 4:27 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On Wed, 2014-04-09 at 10:34 +1000, Peter Howard wrote:
> On Wed, 2014-04-09 at 02:20 +0200, Gilles Chanteperdrix wrote:
> > On 04/09/2014 01:30 AM, Peter Howard wrote:
> > > On Tue, 2014-04-08 at 11:18 +0200, Gilles Chanteperdrix wrote:
> > >> On 04/07/2014 07:34 AM, Peter Howard wrote:
> > >>>
> > >>> On Wed, 2014-04-02 at 09:24 +0200, Gilles Chanteperdrix wrote:
> > >>>> On 04/02/2014 04:59 AM, Peter Howard wrote:
> > >>>>> Hi,
> > >>>>>
> > >>>>> I'm interested in running xenomai on a TI-OMAP L138 board. I found the
> > >>>>> following thread in the archives:
> > >>>>>
> > >>>>> http://www.xenomai.org/pipermail/xenomai/2010-January/018898.html
> > >>>>>
> > >>>>> where someone was working on porting ipipe and xenomai to that board.
> > >>>>> However, the thread ended with problems still unresolved, and the patch
> > >>>>> in the thread (just the changes for ipipe) isn't in the ipipe
> > >>>>> repository.
> > >>>>>
> > >>>>> Does anyone know if this work was completed or just faded into the
> > >>>>> ether?
> > >>>>
> > >>>> We never merged a patch for this processor. And a lot of things changed
> > >>>> since that time. If you are interested in porting the I-pipe patch to
> > >>>> this processor, see:
> > >>>>
> > >>>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
> > >>>>
> > >>>
> > >>> Contrary to what I said last week, I'm working on a patch off the head
> > >>> of the ipipe repo. I have built a kernel with an ipipe port and with
> > >>> xenomai patched in. However the latency results are bad right now:
> > >>>
> > >>> root@arago:~# xeno latency -T 25
> > >>> == Sampling period: 1000 us
> > >>> == Test mode: periodic user-mode task
> > >>> == All results in microseconds
> > >>> warming up...
> > >>> RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)
> > >>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
> > >>> RTD| 3.541| 8.833| 60.749| 0| 0| 3.541| 60.749
> > >>> RTD| 3.499| 13.583| 93.916| 0| 0| 3.499| 93.916
> > >>> RTD| 3.666| 88.999| 109.708| 0| 0| 3.499| 109.708
> > >>> RTD| 3.541| 14.958| 95.374| 0| 0| 3.499| 109.708
> > >>> RTD| 3.541| 9.333| 77.583| 0| 0| 3.499| 109.708
> > >>> RTD| 4.041| 88.416| 109.791| 0| 0| 3.499| 109.791
> > >>> RTD| 3.499| 8.958| 72.791| 0| 0| 3.499| 109.791
> > >>> RTD| 3.499| 26.041| 106.874| 0| 0| 3.499| 109.791
> > >>> RTD| 3.874| 82.708| 107.916| 0| 0| 3.499| 109.791
> > >>> RTD| 3.499| 9.083| 73.708| 0| 0| 3.499| 109.791
> > >>> RTD| 3.333| 8.874| 62.458| 0| 0| 3.333| 109.791
> > >>> RTD| 3.333| 8.749| 62.208| 0| 0| 3.333| 109.791
> > >>> RTD| 3.416| 12.708| 99.416| 0| 0| 3.333| 109.791
> > >>> RTD| 3.499| 14.249| 106.749| 0| 0| 3.333| 109.791
> > >>> RTD| 3.541| 9.083| 76.499| 0| 0| 3.333| 109.791
> > >>> RTD| 3.249| 8.791| 63.499| 0| 0| 3.249| 109.791
> > >>> RTD| 3.416| 8.999| 62.499| 0| 0| 3.249| 109.791
> > >>> RTD| 3.541| 26.166| 101.208| 0| 0| 3.249| 109.791
> > >>> RTD| 3.583| 13.624| 92.458| 0| 0| 3.249| 109.791
> > >>> RTD| 3.541| 8.916| 73.708| 0| 0| 3.249| 109.791
> > >>> RTD| 3.541| 8.999| 64.291| 0| 0| 3.249| 109.791
> > >>> RTT| 00:00:22 (periodic user-mode task, 1000 us period, priority 99)
> > >>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
> > >>> RTD| 3.499| 8.874| 61.374| 0| 0| 3.249| 109.791
> > >>> RTD| 3.499| 13.833| 100.749| 0| 0| 3.249| 109.791
> > >>> RTD| 3.541| 13.083| 99.249| 0| 0| 3.249| 109.791
> > >>> ---|-----------|-----------|-----------|--------|------|------------------------
> > >>> RTS| 3.249| 21.458| 109.791| 0| 0| 00:00:25/00:00:25
> > >>> root@arago:~#
> > >>
> > >> Note that if the OMAPL138 is an armv4 or armv5, you may want to enable
> > >> the FCSE in order to reduce context switch time (and latencies).
> > >>
> > >>
> > >
> > > I enabled FCSE, and the max latency is more consistent (though the min
> > > and average latency has climbed). How do the below figures look?
> >
> > Otherwise, it is hard to say whether there is an issue or not. It is not
> > uncommon for armv4 or armv5 to have high latencies like this.
> > On what core is this processor based, running at what frequency?
> >
> >
> It's an AMR926EJ-S r5. Datasheet claims 375MHz, U-boot claims 300MHz.
>
> Load test to follow.
>
OK, this run was done with LTP running on the board (runltplite.sh),
with cpu utilization between 90% and 100%
root@arago:~# xeno latency -T 25
== Sampling period: 1000 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| 29.999| 45.083| 80.833| 0| 0| 29.999| 80.833
RTD| 35.416| 49.083| 94.666| 0| 0| 29.999| 94.666
RTD| 19.749| 45.374| 83.874| 0| 0| 19.749| 94.666
RTD| 28.291| 47.999| 96.458| 0| 0| 19.749| 96.458
RTD| 16.999| 54.458| 107.041| 0| 0| 16.999| 107.041
RTD| 15.458| 60.083| 100.374| 0| 0| 15.458| 107.041
RTD| 39.041| 74.333| 97.041| 0| 0| 15.458| 107.041
RTD| 39.416| 73.874| 97.624| 0| 0| 15.458| 107.041
RTD| 39.624| 74.249| 104.749| 0| 0| 15.458| 107.041
RTD| 39.666| 74.458| 103.333| 0| 0| 15.458| 107.041
RTD| 42.499| 74.583| 105.874| 0| 0| 15.458| 107.041
RTD| 38.333| 74.583| 96.416| 0| 0| 15.458| 107.041
RTD| 39.833| 74.083| 99.916| 0| 0| 15.458| 107.041
RTD| 37.749| 75.166| 105.708| 0| 0| 15.458| 107.041
RTD| 40.833| 74.749| 97.791| 0| 0| 15.458| 107.041
RTD| 34.833| 74.083| 98.624| 0| 0| 15.458| 107.041
RTD| 42.249| 74.249| 96.708| 0| 0| 15.458| 107.041
RTD| 41.916| 74.499| 103.208| 0| 0| 15.458| 107.041
RTD| 34.166| 74.374| 102.833| 0| 0| 15.458| 107.041
RTD| 44.583| 74.791| 101.291| 0| 0| 15.458| 107.041
RTD| 38.041| 74.458| 103.083| 0| 0| 15.458| 107.041
RTT| 00:00:22 (periodic user-mode task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| 43.249| 74.416| 97.124| 0| 0| 15.458| 107.041
RTD| 40.749| 74.166| 104.874| 0| 0| 15.458| 107.041
RTD| 40.791| 74.791| 97.833| 0| 0| 15.458| 107.041
---|-----------|-----------|-----------|--------|------|-------------------------
RTS| 15.458| 68.416| 107.041| 0| 0| 00:00:25/00:00:25
root@arago:~#
--
Peter Howard <pjh@northern-ridge.com.au>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-09 4:27 ` Peter Howard
@ 2014-04-09 11:54 ` Gilles Chanteperdrix
2014-04-10 7:01 ` Peter Howard
0 siblings, 1 reply; 57+ messages in thread
From: Gilles Chanteperdrix @ 2014-04-09 11:54 UTC (permalink / raw)
To: Peter Howard; +Cc: xenomai
On 04/09/2014 06:27 AM, Peter Howard wrote:
> On Wed, 2014-04-09 at 10:34 +1000, Peter Howard wrote:
>> On Wed, 2014-04-09 at 02:20 +0200, Gilles Chanteperdrix wrote:
>>> On 04/09/2014 01:30 AM, Peter Howard wrote:
>>>> On Tue, 2014-04-08 at 11:18 +0200, Gilles Chanteperdrix wrote:
>>>>> On 04/07/2014 07:34 AM, Peter Howard wrote:
>>>>>>
>>>>>> On Wed, 2014-04-02 at 09:24 +0200, Gilles Chanteperdrix wrote:
>>>>>>> On 04/02/2014 04:59 AM, Peter Howard wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I'm interested in running xenomai on a TI-OMAP L138 board. I found the
>>>>>>>> following thread in the archives:
>>>>>>>>
>>>>>>>> http://www.xenomai.org/pipermail/xenomai/2010-January/018898.html
>>>>>>>>
>>>>>>>> where someone was working on porting ipipe and xenomai to that board.
>>>>>>>> However, the thread ended with problems still unresolved, and the patch
>>>>>>>> in the thread (just the changes for ipipe) isn't in the ipipe
>>>>>>>> repository.
>>>>>>>>
>>>>>>>> Does anyone know if this work was completed or just faded into the
>>>>>>>> ether?
>>>>>>>
>>>>>>> We never merged a patch for this processor. And a lot of things changed
>>>>>>> since that time. If you are interested in porting the I-pipe patch to
>>>>>>> this processor, see:
>>>>>>>
>>>>>>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
>>>>>>>
>>>>>>
>>>>>> Contrary to what I said last week, I'm working on a patch off the head
>>>>>> of the ipipe repo. I have built a kernel with an ipipe port and with
>>>>>> xenomai patched in. However the latency results are bad right now:
>>>>>>
>>>>>> root@arago:~# xeno latency -T 25
>>>>>> == Sampling period: 1000 us
>>>>>> == Test mode: periodic user-mode task
>>>>>> == All results in microseconds
>>>>>> warming up...
>>>>>> RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)
>>>>>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
>>>>>> RTD| 3.541| 8.833| 60.749| 0| 0| 3.541| 60.749
>>>>>> RTD| 3.499| 13.583| 93.916| 0| 0| 3.499| 93.916
>>>>>> RTD| 3.666| 88.999| 109.708| 0| 0| 3.499| 109.708
>>>>>> RTD| 3.541| 14.958| 95.374| 0| 0| 3.499| 109.708
>>>>>> RTD| 3.541| 9.333| 77.583| 0| 0| 3.499| 109.708
>>>>>> RTD| 4.041| 88.416| 109.791| 0| 0| 3.499| 109.791
>>>>>> RTD| 3.499| 8.958| 72.791| 0| 0| 3.499| 109.791
>>>>>> RTD| 3.499| 26.041| 106.874| 0| 0| 3.499| 109.791
>>>>>> RTD| 3.874| 82.708| 107.916| 0| 0| 3.499| 109.791
>>>>>> RTD| 3.499| 9.083| 73.708| 0| 0| 3.499| 109.791
>>>>>> RTD| 3.333| 8.874| 62.458| 0| 0| 3.333| 109.791
>>>>>> RTD| 3.333| 8.749| 62.208| 0| 0| 3.333| 109.791
>>>>>> RTD| 3.416| 12.708| 99.416| 0| 0| 3.333| 109.791
>>>>>> RTD| 3.499| 14.249| 106.749| 0| 0| 3.333| 109.791
>>>>>> RTD| 3.541| 9.083| 76.499| 0| 0| 3.333| 109.791
>>>>>> RTD| 3.249| 8.791| 63.499| 0| 0| 3.249| 109.791
>>>>>> RTD| 3.416| 8.999| 62.499| 0| 0| 3.249| 109.791
>>>>>> RTD| 3.541| 26.166| 101.208| 0| 0| 3.249| 109.791
>>>>>> RTD| 3.583| 13.624| 92.458| 0| 0| 3.249| 109.791
>>>>>> RTD| 3.541| 8.916| 73.708| 0| 0| 3.249| 109.791
>>>>>> RTD| 3.541| 8.999| 64.291| 0| 0| 3.249| 109.791
>>>>>> RTT| 00:00:22 (periodic user-mode task, 1000 us period, priority 99)
>>>>>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
>>>>>> RTD| 3.499| 8.874| 61.374| 0| 0| 3.249| 109.791
>>>>>> RTD| 3.499| 13.833| 100.749| 0| 0| 3.249| 109.791
>>>>>> RTD| 3.541| 13.083| 99.249| 0| 0| 3.249| 109.791
>>>>>> ---|-----------|-----------|-----------|--------|------|------------------------
>>>>>> RTS| 3.249| 21.458| 109.791| 0| 0| 00:00:25/00:00:25
>>>>>> root@arago:~#
>>>>>
>>>>> Note that if the OMAPL138 is an armv4 or armv5, you may want to enable
>>>>> the FCSE in order to reduce context switch time (and latencies).
>>>>>
>>>>>
>>>>
>>>> I enabled FCSE, and the max latency is more consistent (though the min
>>>> and average latency has climbed). How do the below figures look?
>>>
>>> Otherwise, it is hard to say whether there is an issue or not. It is not
>>> uncommon for armv4 or armv5 to have high latencies like this.
>>> On what core is this processor based, running at what frequency?
>>>
>>>
>> It's an AMR926EJ-S r5. Datasheet claims 375MHz, U-boot claims 300MHz.
>>
>> Load test to follow.
>>
>
> OK, this run was done with LTP running on the board (runltplite.sh),
> with cpu utilization between 90% and 100%
You have to run the latency test while ltp is running, and run this for
a few hours (ltp runs a few hours anyway).
We provide the xeno-test script to do this (and dohell to generate
load).
See:
http://www.xenomai.org/documentation/xenomai-2.6/html/xeno-test/index.html
http://www.xenomai.org/documentation/xenomai-2.6/html/dohell/index.html
--
Gilles.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-09 11:54 ` Gilles Chanteperdrix
@ 2014-04-10 7:01 ` Peter Howard
2014-04-10 12:06 ` Gilles Chanteperdrix
0 siblings, 1 reply; 57+ messages in thread
From: Peter Howard @ 2014-04-10 7:01 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On Wed, 2014-04-09 at 13:54 +0200, Gilles Chanteperdrix wrote:
> On 04/09/2014 06:27 AM, Peter Howard wrote:
> > On Wed, 2014-04-09 at 10:34 +1000, Peter Howard wrote:
> >> On Wed, 2014-04-09 at 02:20 +0200, Gilles Chanteperdrix wrote:
> >>> On 04/09/2014 01:30 AM, Peter Howard wrote:
> >>>> On Tue, 2014-04-08 at 11:18 +0200, Gilles Chanteperdrix wrote:
> >>>>> On 04/07/2014 07:34 AM, Peter Howard wrote:
> >>>>>>
> >>>>>> On Wed, 2014-04-02 at 09:24 +0200, Gilles Chanteperdrix wrote:
> >>>>>>> On 04/02/2014 04:59 AM, Peter Howard wrote:
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> I'm interested in running xenomai on a TI-OMAP L138 board. I found the
> >>>>>>>> following thread in the archives:
> >>>>>>>>
> >>>>>>>> http://www.xenomai.org/pipermail/xenomai/2010-January/018898.html
> >>>>>>>>
> >>>>>>>> where someone was working on porting ipipe and xenomai to that board.
> >>>>>>>> However, the thread ended with problems still unresolved, and the patch
> >>>>>>>> in the thread (just the changes for ipipe) isn't in the ipipe
> >>>>>>>> repository.
> >>>>>>>>
> >>>>>>>> Does anyone know if this work was completed or just faded into the
> >>>>>>>> ether?
> >>>>>>>
> >>>>>>> We never merged a patch for this processor. And a lot of things changed
> >>>>>>> since that time. If you are interested in porting the I-pipe patch to
> >>>>>>> this processor, see:
> >>>>>>>
> >>>>>>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
> >>>>>>>
> >>>>>>
> >>>>>> Contrary to what I said last week, I'm working on a patch off the head
> >>>>>> of the ipipe repo. I have built a kernel with an ipipe port and with
> >>>>>> xenomai patched in. However the latency results are bad right now:
> >>>>>>
> >>>>>> root@arago:~# xeno latency -T 25
> >>>>>> == Sampling period: 1000 us
> >>>>>> == Test mode: periodic user-mode task
> >>>>>> == All results in microseconds
> >>>>>> warming up...
> >>>>>> RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)
> >>>>>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
> >>>>>> RTD| 3.541| 8.833| 60.749| 0| 0| 3.541| 60.749
> >>>>>> RTD| 3.499| 13.583| 93.916| 0| 0| 3.499| 93.916
> >>>>>> RTD| 3.666| 88.999| 109.708| 0| 0| 3.499| 109.708
> >>>>>> RTD| 3.541| 14.958| 95.374| 0| 0| 3.499| 109.708
> >>>>>> RTD| 3.541| 9.333| 77.583| 0| 0| 3.499| 109.708
> >>>>>> RTD| 4.041| 88.416| 109.791| 0| 0| 3.499| 109.791
> >>>>>> RTD| 3.499| 8.958| 72.791| 0| 0| 3.499| 109.791
> >>>>>> RTD| 3.499| 26.041| 106.874| 0| 0| 3.499| 109.791
> >>>>>> RTD| 3.874| 82.708| 107.916| 0| 0| 3.499| 109.791
> >>>>>> RTD| 3.499| 9.083| 73.708| 0| 0| 3.499| 109.791
> >>>>>> RTD| 3.333| 8.874| 62.458| 0| 0| 3.333| 109.791
> >>>>>> RTD| 3.333| 8.749| 62.208| 0| 0| 3.333| 109.791
> >>>>>> RTD| 3.416| 12.708| 99.416| 0| 0| 3.333| 109.791
> >>>>>> RTD| 3.499| 14.249| 106.749| 0| 0| 3.333| 109.791
> >>>>>> RTD| 3.541| 9.083| 76.499| 0| 0| 3.333| 109.791
> >>>>>> RTD| 3.249| 8.791| 63.499| 0| 0| 3.249| 109.791
> >>>>>> RTD| 3.416| 8.999| 62.499| 0| 0| 3.249| 109.791
> >>>>>> RTD| 3.541| 26.166| 101.208| 0| 0| 3.249| 109.791
> >>>>>> RTD| 3.583| 13.624| 92.458| 0| 0| 3.249| 109.791
> >>>>>> RTD| 3.541| 8.916| 73.708| 0| 0| 3.249| 109.791
> >>>>>> RTD| 3.541| 8.999| 64.291| 0| 0| 3.249| 109.791
> >>>>>> RTT| 00:00:22 (periodic user-mode task, 1000 us period, priority 99)
> >>>>>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
> >>>>>> RTD| 3.499| 8.874| 61.374| 0| 0| 3.249| 109.791
> >>>>>> RTD| 3.499| 13.833| 100.749| 0| 0| 3.249| 109.791
> >>>>>> RTD| 3.541| 13.083| 99.249| 0| 0| 3.249| 109.791
> >>>>>> ---|-----------|-----------|-----------|--------|------|------------------------
> >>>>>> RTS| 3.249| 21.458| 109.791| 0| 0| 00:00:25/00:00:25
> >>>>>> root@arago:~#
> >>>>>
> >>>>> Note that if the OMAPL138 is an armv4 or armv5, you may want to enable
> >>>>> the FCSE in order to reduce context switch time (and latencies).
> >>>>>
> >>>>>
> >>>>
> >>>> I enabled FCSE, and the max latency is more consistent (though the min
> >>>> and average latency has climbed). How do the below figures look?
> >>>
> >>> Otherwise, it is hard to say whether there is an issue or not. It is not
> >>> uncommon for armv4 or armv5 to have high latencies like this.
> >>> On what core is this processor based, running at what frequency?
> >>>
> >>>
> >> It's an AMR926EJ-S r5. Datasheet claims 375MHz, U-boot claims 300MHz.
> >>
> >> Load test to follow.
> >>
> >
> > OK, this run was done with LTP running on the board (runltplite.sh),
> > with cpu utilization between 90% and 100%
>
> You have to run the latency test while ltp is running, and run this for
> a few hours (ltp runs a few hours anyway).
>
> We provide the xeno-test script to do this (and dohell to generate
> load).
>
> See:
> http://www.xenomai.org/documentation/xenomai-2.6/html/xeno-test/index.html
> http://www.xenomai.org/documentation/xenomai-2.6/html/dohell/index.html
>
That's proving to be a bit challenging. Giving dohell ltp is causing
more kernel panics - usually a SIGSEGV to init. Now I'm aware from your
previous thread on the OMAP-L138 that ltp doesn't run cleanly on low-end
arm chips as-is, but I'm guessing kernel panics wasn't the failure mode
you were seeing. (running ltp by itself also gives a different kernel
panic after about 15-20 minutes) So I need to look into that more.
I also need to try the ltp build on the stock Ti-supplied system to make
sure there's not a pre-existing problem lurking in there; I should do
that tomorrow.
FWIW just running xeno-test with no arguments finishes cleanly after
running for 10 minutes or so.
Is it worth putting up the diff to the ipipe tree at this stage for
people to look over?
--
Peter Howard <pjh@northern-ridge.com.au>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-10 7:01 ` Peter Howard
@ 2014-04-10 12:06 ` Gilles Chanteperdrix
2014-04-10 19:57 ` Peter Howard
0 siblings, 1 reply; 57+ messages in thread
From: Gilles Chanteperdrix @ 2014-04-10 12:06 UTC (permalink / raw)
To: Peter Howard; +Cc: xenomai
On 04/10/2014 09:01 AM, Peter Howard wrote:
> On Wed, 2014-04-09 at 13:54 +0200, Gilles Chanteperdrix wrote:
>> On 04/09/2014 06:27 AM, Peter Howard wrote:
>>> On Wed, 2014-04-09 at 10:34 +1000, Peter Howard wrote:
>>>> On Wed, 2014-04-09 at 02:20 +0200, Gilles Chanteperdrix wrote:
>>>>> On 04/09/2014 01:30 AM, Peter Howard wrote:
>>>>>> On Tue, 2014-04-08 at 11:18 +0200, Gilles Chanteperdrix wrote:
>>>>>>> On 04/07/2014 07:34 AM, Peter Howard wrote:
>>>>>>>>
>>>>>>>> On Wed, 2014-04-02 at 09:24 +0200, Gilles Chanteperdrix wrote:
>>>>>>>>> On 04/02/2014 04:59 AM, Peter Howard wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I'm interested in running xenomai on a TI-OMAP L138 board. I found the
>>>>>>>>>> following thread in the archives:
>>>>>>>>>>
>>>>>>>>>> http://www.xenomai.org/pipermail/xenomai/2010-January/018898.html
>>>>>>>>>>
>>>>>>>>>> where someone was working on porting ipipe and xenomai to that board.
>>>>>>>>>> However, the thread ended with problems still unresolved, and the patch
>>>>>>>>>> in the thread (just the changes for ipipe) isn't in the ipipe
>>>>>>>>>> repository.
>>>>>>>>>>
>>>>>>>>>> Does anyone know if this work was completed or just faded into the
>>>>>>>>>> ether?
>>>>>>>>>
>>>>>>>>> We never merged a patch for this processor. And a lot of things changed
>>>>>>>>> since that time. If you are interested in porting the I-pipe patch to
>>>>>>>>> this processor, see:
>>>>>>>>>
>>>>>>>>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
>>>>>>>>>
>>>>>>>>
>>>>>>>> Contrary to what I said last week, I'm working on a patch off the head
>>>>>>>> of the ipipe repo. I have built a kernel with an ipipe port and with
>>>>>>>> xenomai patched in. However the latency results are bad right now:
>>>>>>>>
>>>>>>>> root@arago:~# xeno latency -T 25
>>>>>>>> == Sampling period: 1000 us
>>>>>>>> == Test mode: periodic user-mode task
>>>>>>>> == All results in microseconds
>>>>>>>> warming up...
>>>>>>>> RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)
>>>>>>>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
>>>>>>>> RTD| 3.541| 8.833| 60.749| 0| 0| 3.541| 60.749
>>>>>>>> RTD| 3.499| 13.583| 93.916| 0| 0| 3.499| 93.916
>>>>>>>> RTD| 3.666| 88.999| 109.708| 0| 0| 3.499| 109.708
>>>>>>>> RTD| 3.541| 14.958| 95.374| 0| 0| 3.499| 109.708
>>>>>>>> RTD| 3.541| 9.333| 77.583| 0| 0| 3.499| 109.708
>>>>>>>> RTD| 4.041| 88.416| 109.791| 0| 0| 3.499| 109.791
>>>>>>>> RTD| 3.499| 8.958| 72.791| 0| 0| 3.499| 109.791
>>>>>>>> RTD| 3.499| 26.041| 106.874| 0| 0| 3.499| 109.791
>>>>>>>> RTD| 3.874| 82.708| 107.916| 0| 0| 3.499| 109.791
>>>>>>>> RTD| 3.499| 9.083| 73.708| 0| 0| 3.499| 109.791
>>>>>>>> RTD| 3.333| 8.874| 62.458| 0| 0| 3.333| 109.791
>>>>>>>> RTD| 3.333| 8.749| 62.208| 0| 0| 3.333| 109.791
>>>>>>>> RTD| 3.416| 12.708| 99.416| 0| 0| 3.333| 109.791
>>>>>>>> RTD| 3.499| 14.249| 106.749| 0| 0| 3.333| 109.791
>>>>>>>> RTD| 3.541| 9.083| 76.499| 0| 0| 3.333| 109.791
>>>>>>>> RTD| 3.249| 8.791| 63.499| 0| 0| 3.249| 109.791
>>>>>>>> RTD| 3.416| 8.999| 62.499| 0| 0| 3.249| 109.791
>>>>>>>> RTD| 3.541| 26.166| 101.208| 0| 0| 3.249| 109.791
>>>>>>>> RTD| 3.583| 13.624| 92.458| 0| 0| 3.249| 109.791
>>>>>>>> RTD| 3.541| 8.916| 73.708| 0| 0| 3.249| 109.791
>>>>>>>> RTD| 3.541| 8.999| 64.291| 0| 0| 3.249| 109.791
>>>>>>>> RTT| 00:00:22 (periodic user-mode task, 1000 us period, priority 99)
>>>>>>>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
>>>>>>>> RTD| 3.499| 8.874| 61.374| 0| 0| 3.249| 109.791
>>>>>>>> RTD| 3.499| 13.833| 100.749| 0| 0| 3.249| 109.791
>>>>>>>> RTD| 3.541| 13.083| 99.249| 0| 0| 3.249| 109.791
>>>>>>>> ---|-----------|-----------|-----------|--------|------|------------------------
>>>>>>>> RTS| 3.249| 21.458| 109.791| 0| 0| 00:00:25/00:00:25
>>>>>>>> root@arago:~#
>>>>>>>
>>>>>>> Note that if the OMAPL138 is an armv4 or armv5, you may want to enable
>>>>>>> the FCSE in order to reduce context switch time (and latencies).
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> I enabled FCSE, and the max latency is more consistent (though the min
>>>>>> and average latency has climbed). How do the below figures look?
>>>>>
>>>>> Otherwise, it is hard to say whether there is an issue or not. It is not
>>>>> uncommon for armv4 or armv5 to have high latencies like this.
>>>>> On what core is this processor based, running at what frequency?
>>>>>
>>>>>
>>>> It's an AMR926EJ-S r5. Datasheet claims 375MHz, U-boot claims 300MHz.
>>>>
>>>> Load test to follow.
>>>>
>>>
>>> OK, this run was done with LTP running on the board (runltplite.sh),
>>> with cpu utilization between 90% and 100%
>>
>> You have to run the latency test while ltp is running, and run this for
>> a few hours (ltp runs a few hours anyway).
>>
>> We provide the xeno-test script to do this (and dohell to generate
>> load).
>>
>> See:
>> http://www.xenomai.org/documentation/xenomai-2.6/html/xeno-test/index.html
>> http://www.xenomai.org/documentation/xenomai-2.6/html/dohell/index.html
>>
>
> That's proving to be a bit challenging. Giving dohell ltp is causing
> more kernel panics - usually a SIGSEGV to init. Now I'm aware from your
> previous thread on the OMAP-L138 that ltp doesn't run cleanly on low-end
> arm chips as-is, but I'm guessing kernel panics wasn't the failure mode
> you were seeing. (running ltp by itself also gives a different kernel
> panic after about 15-20 minutes) So I need to look into that more.
>
> I also need to try the ltp build on the stock Ti-supplied system to make
> sure there's not a pre-existing problem lurking in there; I should do
> that tomorrow.
The thing is, if you enabled FCSE in guaranteed mode, it does not really
make sense to run LTP: most tests will fail because of the processes
number limit. In that case you should use the -b option, and pass the
path to hackbench only.
>
> FWIW just running xeno-test with no arguments finishes cleanly after
> running for 10 minutes or so.
>
> Is it worth putting up the diff to the ipipe tree at this stage for
> people to look over?
If you have random segfault, then something is still wrong. Have you
tried enabling I-pipe debugging options?
The non-working I-pipe tracer with stack unwinding is not normal either,
what version of the kernel are you using?
--
Gilles.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-10 12:06 ` Gilles Chanteperdrix
@ 2014-04-10 19:57 ` Peter Howard
2014-04-10 21:56 ` Gilles Chanteperdrix
0 siblings, 1 reply; 57+ messages in thread
From: Peter Howard @ 2014-04-10 19:57 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On Thu, 2014-04-10 at 14:06 +0200, Gilles Chanteperdrix wrote:
> On 04/10/2014 09:01 AM, Peter Howard wrote:
> > On Wed, 2014-04-09 at 13:54 +0200, Gilles Chanteperdrix wrote:
> >> On 04/09/2014 06:27 AM, Peter Howard wrote:
> >>> On Wed, 2014-04-09 at 10:34 +1000, Peter Howard wrote:
> >>>> On Wed, 2014-04-09 at 02:20 +0200, Gilles Chanteperdrix wrote:
> >>>>> On 04/09/2014 01:30 AM, Peter Howard wrote:
> >>>>>> On Tue, 2014-04-08 at 11:18 +0200, Gilles Chanteperdrix wrote:
> >>>>>>> On 04/07/2014 07:34 AM, Peter Howard wrote:
> >>>>>>>>
> >>>>>>>> On Wed, 2014-04-02 at 09:24 +0200, Gilles Chanteperdrix wrote:
> >>>>>>>>> On 04/02/2014 04:59 AM, Peter Howard wrote:
> >>>>>>>>>> Hi,
> >>>>>>>>>>
> >>>>>>>>>> I'm interested in running xenomai on a TI-OMAP L138 board. I found the
> >>>>>>>>>> following thread in the archives:
> >>>>>>>>>>
> >>>>>>>>>> http://www.xenomai.org/pipermail/xenomai/2010-January/018898.html
> >>>>>>>>>>
> >>>>>>>>>> where someone was working on porting ipipe and xenomai to that board.
> >>>>>>>>>> However, the thread ended with problems still unresolved, and the patch
> >>>>>>>>>> in the thread (just the changes for ipipe) isn't in the ipipe
> >>>>>>>>>> repository.
> >>>>>>>>>>
> >>>>>>>>>> Does anyone know if this work was completed or just faded into the
> >>>>>>>>>> ether?
> >>>>>>>>>
> >>>>>>>>> We never merged a patch for this processor. And a lot of things changed
> >>>>>>>>> since that time. If you are interested in porting the I-pipe patch to
> >>>>>>>>> this processor, see:
> >>>>>>>>>
> >>>>>>>>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Contrary to what I said last week, I'm working on a patch off the head
> >>>>>>>> of the ipipe repo. I have built a kernel with an ipipe port and with
> >>>>>>>> xenomai patched in. However the latency results are bad right now:
> >>>>>>>>
> >>>>>>>> root@arago:~# xeno latency -T 25
> >>>>>>>> == Sampling period: 1000 us
> >>>>>>>> == Test mode: periodic user-mode task
> >>>>>>>> == All results in microseconds
> >>>>>>>> warming up...
> >>>>>>>> RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)
> >>>>>>>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
> >>>>>>>> RTD| 3.541| 8.833| 60.749| 0| 0| 3.541| 60.749
> >>>>>>>> RTD| 3.499| 13.583| 93.916| 0| 0| 3.499| 93.916
> >>>>>>>> RTD| 3.666| 88.999| 109.708| 0| 0| 3.499| 109.708
> >>>>>>>> RTD| 3.541| 14.958| 95.374| 0| 0| 3.499| 109.708
> >>>>>>>> RTD| 3.541| 9.333| 77.583| 0| 0| 3.499| 109.708
> >>>>>>>> RTD| 4.041| 88.416| 109.791| 0| 0| 3.499| 109.791
> >>>>>>>> RTD| 3.499| 8.958| 72.791| 0| 0| 3.499| 109.791
> >>>>>>>> RTD| 3.499| 26.041| 106.874| 0| 0| 3.499| 109.791
> >>>>>>>> RTD| 3.874| 82.708| 107.916| 0| 0| 3.499| 109.791
> >>>>>>>> RTD| 3.499| 9.083| 73.708| 0| 0| 3.499| 109.791
> >>>>>>>> RTD| 3.333| 8.874| 62.458| 0| 0| 3.333| 109.791
> >>>>>>>> RTD| 3.333| 8.749| 62.208| 0| 0| 3.333| 109.791
> >>>>>>>> RTD| 3.416| 12.708| 99.416| 0| 0| 3.333| 109.791
> >>>>>>>> RTD| 3.499| 14.249| 106.749| 0| 0| 3.333| 109.791
> >>>>>>>> RTD| 3.541| 9.083| 76.499| 0| 0| 3.333| 109.791
> >>>>>>>> RTD| 3.249| 8.791| 63.499| 0| 0| 3.249| 109.791
> >>>>>>>> RTD| 3.416| 8.999| 62.499| 0| 0| 3.249| 109.791
> >>>>>>>> RTD| 3.541| 26.166| 101.208| 0| 0| 3.249| 109.791
> >>>>>>>> RTD| 3.583| 13.624| 92.458| 0| 0| 3.249| 109.791
> >>>>>>>> RTD| 3.541| 8.916| 73.708| 0| 0| 3.249| 109.791
> >>>>>>>> RTD| 3.541| 8.999| 64.291| 0| 0| 3.249| 109.791
> >>>>>>>> RTT| 00:00:22 (periodic user-mode task, 1000 us period, priority 99)
> >>>>>>>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
> >>>>>>>> RTD| 3.499| 8.874| 61.374| 0| 0| 3.249| 109.791
> >>>>>>>> RTD| 3.499| 13.833| 100.749| 0| 0| 3.249| 109.791
> >>>>>>>> RTD| 3.541| 13.083| 99.249| 0| 0| 3.249| 109.791
> >>>>>>>> ---|-----------|-----------|-----------|--------|------|------------------------
> >>>>>>>> RTS| 3.249| 21.458| 109.791| 0| 0| 00:00:25/00:00:25
> >>>>>>>> root@arago:~#
> >>>>>>>
> >>>>>>> Note that if the OMAPL138 is an armv4 or armv5, you may want to enable
> >>>>>>> the FCSE in order to reduce context switch time (and latencies).
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> I enabled FCSE, and the max latency is more consistent (though the min
> >>>>>> and average latency has climbed). How do the below figures look?
> >>>>>
> >>>>> Otherwise, it is hard to say whether there is an issue or not. It is not
> >>>>> uncommon for armv4 or armv5 to have high latencies like this.
> >>>>> On what core is this processor based, running at what frequency?
> >>>>>
> >>>>>
> >>>> It's an AMR926EJ-S r5. Datasheet claims 375MHz, U-boot claims 300MHz.
> >>>>
> >>>> Load test to follow.
> >>>>
> >>>
> >>> OK, this run was done with LTP running on the board (runltplite.sh),
> >>> with cpu utilization between 90% and 100%
> >>
> >> You have to run the latency test while ltp is running, and run this for
> >> a few hours (ltp runs a few hours anyway).
> >>
> >> We provide the xeno-test script to do this (and dohell to generate
> >> load).
> >>
> >> See:
> >> http://www.xenomai.org/documentation/xenomai-2.6/html/xeno-test/index.html
> >> http://www.xenomai.org/documentation/xenomai-2.6/html/dohell/index.html
> >>
> >
> > That's proving to be a bit challenging. Giving dohell ltp is causing
> > more kernel panics - usually a SIGSEGV to init. Now I'm aware from your
> > previous thread on the OMAP-L138 that ltp doesn't run cleanly on low-end
> > arm chips as-is, but I'm guessing kernel panics wasn't the failure mode
> > you were seeing. (running ltp by itself also gives a different kernel
> > panic after about 15-20 minutes) So I need to look into that more.
> >
> > I also need to try the ltp build on the stock Ti-supplied system to make
> > sure there's not a pre-existing problem lurking in there; I should do
> > that tomorrow.
>
> The thing is, if you enabled FCSE in guaranteed mode, it does not really
> make sense to run LTP: most tests will fail because of the processes
> number limit. In that case you should use the -b option, and pass the
> path to hackbench only.
>
> >
> > FWIW just running xeno-test with no arguments finishes cleanly after
> > running for 10 minutes or so.
> >
> > Is it worth putting up the diff to the ipipe tree at this stage for
> > people to look over?
>
> If you have random segfault, then something is still wrong. Have you
> tried enabling I-pipe debugging options?
>
> The non-working I-pipe tracer with stack unwinding is not normal either,
> what version of the kernel are you using?
>
>
The kernel source I'm modifying is the master branch of the ipipe git
repo.
--
Peter Howard <pjh@northern-ridge.com.au>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-10 19:57 ` Peter Howard
@ 2014-04-10 21:56 ` Gilles Chanteperdrix
2014-04-10 22:17 ` Peter Howard
0 siblings, 1 reply; 57+ messages in thread
From: Gilles Chanteperdrix @ 2014-04-10 21:56 UTC (permalink / raw)
To: Peter Howard; +Cc: xenomai
On 04/10/2014 09:57 PM, Peter Howard wrote:
> On Thu, 2014-04-10 at 14:06 +0200, Gilles Chanteperdrix wrote:
>> On 04/10/2014 09:01 AM, Peter Howard wrote:
>>> On Wed, 2014-04-09 at 13:54 +0200, Gilles Chanteperdrix wrote:
>>>> On 04/09/2014 06:27 AM, Peter Howard wrote:
>>>>> On Wed, 2014-04-09 at 10:34 +1000, Peter Howard wrote:
>>>>>> On Wed, 2014-04-09 at 02:20 +0200, Gilles Chanteperdrix wrote:
>>>>>>> On 04/09/2014 01:30 AM, Peter Howard wrote:
>>>>>>>> On Tue, 2014-04-08 at 11:18 +0200, Gilles Chanteperdrix wrote:
>>>>>>>>> On 04/07/2014 07:34 AM, Peter Howard wrote:
>>>>>>>>>>
>>>>>>>>>> On Wed, 2014-04-02 at 09:24 +0200, Gilles Chanteperdrix wrote:
>>>>>>>>>>> On 04/02/2014 04:59 AM, Peter Howard wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I'm interested in running xenomai on a TI-OMAP L138 board. I found the
>>>>>>>>>>>> following thread in the archives:
>>>>>>>>>>>>
>>>>>>>>>>>> http://www.xenomai.org/pipermail/xenomai/2010-January/018898.html
>>>>>>>>>>>>
>>>>>>>>>>>> where someone was working on porting ipipe and xenomai to that board.
>>>>>>>>>>>> However, the thread ended with problems still unresolved, and the patch
>>>>>>>>>>>> in the thread (just the changes for ipipe) isn't in the ipipe
>>>>>>>>>>>> repository.
>>>>>>>>>>>>
>>>>>>>>>>>> Does anyone know if this work was completed or just faded into the
>>>>>>>>>>>> ether?
>>>>>>>>>>>
>>>>>>>>>>> We never merged a patch for this processor. And a lot of things changed
>>>>>>>>>>> since that time. If you are interested in porting the I-pipe patch to
>>>>>>>>>>> this processor, see:
>>>>>>>>>>>
>>>>>>>>>>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Contrary to what I said last week, I'm working on a patch off the head
>>>>>>>>>> of the ipipe repo. I have built a kernel with an ipipe port and with
>>>>>>>>>> xenomai patched in. However the latency results are bad right now:
>>>>>>>>>>
>>>>>>>>>> root@arago:~# xeno latency -T 25
>>>>>>>>>> == Sampling period: 1000 us
>>>>>>>>>> == Test mode: periodic user-mode task
>>>>>>>>>> == All results in microseconds
>>>>>>>>>> warming up...
>>>>>>>>>> RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)
>>>>>>>>>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
>>>>>>>>>> RTD| 3.541| 8.833| 60.749| 0| 0| 3.541| 60.749
>>>>>>>>>> RTD| 3.499| 13.583| 93.916| 0| 0| 3.499| 93.916
>>>>>>>>>> RTD| 3.666| 88.999| 109.708| 0| 0| 3.499| 109.708
>>>>>>>>>> RTD| 3.541| 14.958| 95.374| 0| 0| 3.499| 109.708
>>>>>>>>>> RTD| 3.541| 9.333| 77.583| 0| 0| 3.499| 109.708
>>>>>>>>>> RTD| 4.041| 88.416| 109.791| 0| 0| 3.499| 109.791
>>>>>>>>>> RTD| 3.499| 8.958| 72.791| 0| 0| 3.499| 109.791
>>>>>>>>>> RTD| 3.499| 26.041| 106.874| 0| 0| 3.499| 109.791
>>>>>>>>>> RTD| 3.874| 82.708| 107.916| 0| 0| 3.499| 109.791
>>>>>>>>>> RTD| 3.499| 9.083| 73.708| 0| 0| 3.499| 109.791
>>>>>>>>>> RTD| 3.333| 8.874| 62.458| 0| 0| 3.333| 109.791
>>>>>>>>>> RTD| 3.333| 8.749| 62.208| 0| 0| 3.333| 109.791
>>>>>>>>>> RTD| 3.416| 12.708| 99.416| 0| 0| 3.333| 109.791
>>>>>>>>>> RTD| 3.499| 14.249| 106.749| 0| 0| 3.333| 109.791
>>>>>>>>>> RTD| 3.541| 9.083| 76.499| 0| 0| 3.333| 109.791
>>>>>>>>>> RTD| 3.249| 8.791| 63.499| 0| 0| 3.249| 109.791
>>>>>>>>>> RTD| 3.416| 8.999| 62.499| 0| 0| 3.249| 109.791
>>>>>>>>>> RTD| 3.541| 26.166| 101.208| 0| 0| 3.249| 109.791
>>>>>>>>>> RTD| 3.583| 13.624| 92.458| 0| 0| 3.249| 109.791
>>>>>>>>>> RTD| 3.541| 8.916| 73.708| 0| 0| 3.249| 109.791
>>>>>>>>>> RTD| 3.541| 8.999| 64.291| 0| 0| 3.249| 109.791
>>>>>>>>>> RTT| 00:00:22 (periodic user-mode task, 1000 us period, priority 99)
>>>>>>>>>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
>>>>>>>>>> RTD| 3.499| 8.874| 61.374| 0| 0| 3.249| 109.791
>>>>>>>>>> RTD| 3.499| 13.833| 100.749| 0| 0| 3.249| 109.791
>>>>>>>>>> RTD| 3.541| 13.083| 99.249| 0| 0| 3.249| 109.791
>>>>>>>>>> ---|-----------|-----------|-----------|--------|------|------------------------
>>>>>>>>>> RTS| 3.249| 21.458| 109.791| 0| 0| 00:00:25/00:00:25
>>>>>>>>>> root@arago:~#
>>>>>>>>>
>>>>>>>>> Note that if the OMAPL138 is an armv4 or armv5, you may want to enable
>>>>>>>>> the FCSE in order to reduce context switch time (and latencies).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> I enabled FCSE, and the max latency is more consistent (though the min
>>>>>>>> and average latency has climbed). How do the below figures look?
>>>>>>>
>>>>>>> Otherwise, it is hard to say whether there is an issue or not. It is not
>>>>>>> uncommon for armv4 or armv5 to have high latencies like this.
>>>>>>> On what core is this processor based, running at what frequency?
>>>>>>>
>>>>>>>
>>>>>> It's an AMR926EJ-S r5. Datasheet claims 375MHz, U-boot claims 300MHz.
>>>>>>
>>>>>> Load test to follow.
>>>>>>
>>>>>
>>>>> OK, this run was done with LTP running on the board (runltplite.sh),
>>>>> with cpu utilization between 90% and 100%
>>>>
>>>> You have to run the latency test while ltp is running, and run this for
>>>> a few hours (ltp runs a few hours anyway).
>>>>
>>>> We provide the xeno-test script to do this (and dohell to generate
>>>> load).
>>>>
>>>> See:
>>>> http://www.xenomai.org/documentation/xenomai-2.6/html/xeno-test/index.html
>>>> http://www.xenomai.org/documentation/xenomai-2.6/html/dohell/index.html
>>>>
>>>
>>> That's proving to be a bit challenging. Giving dohell ltp is causing
>>> more kernel panics - usually a SIGSEGV to init. Now I'm aware from your
>>> previous thread on the OMAP-L138 that ltp doesn't run cleanly on low-end
>>> arm chips as-is, but I'm guessing kernel panics wasn't the failure mode
>>> you were seeing. (running ltp by itself also gives a different kernel
>>> panic after about 15-20 minutes) So I need to look into that more.
>>>
>>> I also need to try the ltp build on the stock Ti-supplied system to make
>>> sure there's not a pre-existing problem lurking in there; I should do
>>> that tomorrow.
>>
>> The thing is, if you enabled FCSE in guaranteed mode, it does not really
>> make sense to run LTP: most tests will fail because of the processes
>> number limit. In that case you should use the -b option, and pass the
>> path to hackbench only.
>>
>>>
>>> FWIW just running xeno-test with no arguments finishes cleanly after
>>> running for 10 minutes or so.
>>>
>>> Is it worth putting up the diff to the ipipe tree at this stage for
>>> people to look over?
>>
>> If you have random segfault, then something is still wrong. Have you
>> tried enabling I-pipe debugging options?
>>
>> The non-working I-pipe tracer with stack unwinding is not normal either,
>> what version of the kernel are you using?
>>
>>
> The kernel source I'm modifying is the master branch of the ipipe git
> repo.
Despite the fact that this branch does not correspond to any released
I-pipe patch, I can confirm that the I-pipe tracer works with stack
unwinding on at91rm9200, ,an armv4, and at91sam9263, an armv5. So, you
must miss something in your patch. Again, I would advise you to use:
http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
As a check list.
Also, if you can give us more details about the crash you get (kernel
configuration, console messages), we could help you find what is wrong.
And again, please enable all the I-pipe debugging option, in case it
would catch an issue.
--
Gilles.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-10 21:56 ` Gilles Chanteperdrix
@ 2014-04-10 22:17 ` Peter Howard
2014-04-10 22:23 ` Gilles Chanteperdrix
0 siblings, 1 reply; 57+ messages in thread
From: Peter Howard @ 2014-04-10 22:17 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On Thu, 2014-04-10 at 23:56 +0200, Gilles Chanteperdrix wrote:
> On 04/10/2014 09:57 PM, Peter Howard wrote:
> > On Thu, 2014-04-10 at 14:06 +0200, Gilles Chanteperdrix wrote:
> >> On 04/10/2014 09:01 AM, Peter Howard wrote:
> >>> On Wed, 2014-04-09 at 13:54 +0200, Gilles Chanteperdrix wrote:
> >>>> On 04/09/2014 06:27 AM, Peter Howard wrote:
> >>>>> On Wed, 2014-04-09 at 10:34 +1000, Peter Howard wrote:
> >>>>>> On Wed, 2014-04-09 at 02:20 +0200, Gilles Chanteperdrix wrote:
> >>>>>>> On 04/09/2014 01:30 AM, Peter Howard wrote:
> >>>>>>>> On Tue, 2014-04-08 at 11:18 +0200, Gilles Chanteperdrix wrote:
> >>>>>>>>> On 04/07/2014 07:34 AM, Peter Howard wrote:
> >>>>>>>>>>
> >>>>>>>>>> On Wed, 2014-04-02 at 09:24 +0200, Gilles Chanteperdrix wrote:
> >>>>>>>>>>> On 04/02/2014 04:59 AM, Peter Howard wrote:
> >>>>>>>>>>>> Hi,
> >>>>>>>>>>>>
> >>>>>>>>>>>> I'm interested in running xenomai on a TI-OMAP L138 board. I found the
> >>>>>>>>>>>> following thread in the archives:
> >>>>>>>>>>>>
> >>>>>>>>>>>> http://www.xenomai.org/pipermail/xenomai/2010-January/018898.html
> >>>>>>>>>>>>
> >>>>>>>>>>>> where someone was working on porting ipipe and xenomai to that board.
> >>>>>>>>>>>> However, the thread ended with problems still unresolved, and the patch
> >>>>>>>>>>>> in the thread (just the changes for ipipe) isn't in the ipipe
> >>>>>>>>>>>> repository.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Does anyone know if this work was completed or just faded into the
> >>>>>>>>>>>> ether?
> >>>>>>>>>>>
> >>>>>>>>>>> We never merged a patch for this processor. And a lot of things changed
> >>>>>>>>>>> since that time. If you are interested in porting the I-pipe patch to
> >>>>>>>>>>> this processor, see:
> >>>>>>>>>>>
> >>>>>>>>>>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Contrary to what I said last week, I'm working on a patch off the head
> >>>>>>>>>> of the ipipe repo. I have built a kernel with an ipipe port and with
> >>>>>>>>>> xenomai patched in. However the latency results are bad right now:
> >>>>>>>>>>
> >>>>>>>>>> root@arago:~# xeno latency -T 25
> >>>>>>>>>> == Sampling period: 1000 us
> >>>>>>>>>> == Test mode: periodic user-mode task
> >>>>>>>>>> == All results in microseconds
> >>>>>>>>>> warming up...
> >>>>>>>>>> RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)
> >>>>>>>>>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
> >>>>>>>>>> RTD| 3.541| 8.833| 60.749| 0| 0| 3.541| 60.749
> >>>>>>>>>> RTD| 3.499| 13.583| 93.916| 0| 0| 3.499| 93.916
> >>>>>>>>>> RTD| 3.666| 88.999| 109.708| 0| 0| 3.499| 109.708
> >>>>>>>>>> RTD| 3.541| 14.958| 95.374| 0| 0| 3.499| 109.708
> >>>>>>>>>> RTD| 3.541| 9.333| 77.583| 0| 0| 3.499| 109.708
> >>>>>>>>>> RTD| 4.041| 88.416| 109.791| 0| 0| 3.499| 109.791
> >>>>>>>>>> RTD| 3.499| 8.958| 72.791| 0| 0| 3.499| 109.791
> >>>>>>>>>> RTD| 3.499| 26.041| 106.874| 0| 0| 3.499| 109.791
> >>>>>>>>>> RTD| 3.874| 82.708| 107.916| 0| 0| 3.499| 109.791
> >>>>>>>>>> RTD| 3.499| 9.083| 73.708| 0| 0| 3.499| 109.791
> >>>>>>>>>> RTD| 3.333| 8.874| 62.458| 0| 0| 3.333| 109.791
> >>>>>>>>>> RTD| 3.333| 8.749| 62.208| 0| 0| 3.333| 109.791
> >>>>>>>>>> RTD| 3.416| 12.708| 99.416| 0| 0| 3.333| 109.791
> >>>>>>>>>> RTD| 3.499| 14.249| 106.749| 0| 0| 3.333| 109.791
> >>>>>>>>>> RTD| 3.541| 9.083| 76.499| 0| 0| 3.333| 109.791
> >>>>>>>>>> RTD| 3.249| 8.791| 63.499| 0| 0| 3.249| 109.791
> >>>>>>>>>> RTD| 3.416| 8.999| 62.499| 0| 0| 3.249| 109.791
> >>>>>>>>>> RTD| 3.541| 26.166| 101.208| 0| 0| 3.249| 109.791
> >>>>>>>>>> RTD| 3.583| 13.624| 92.458| 0| 0| 3.249| 109.791
> >>>>>>>>>> RTD| 3.541| 8.916| 73.708| 0| 0| 3.249| 109.791
> >>>>>>>>>> RTD| 3.541| 8.999| 64.291| 0| 0| 3.249| 109.791
> >>>>>>>>>> RTT| 00:00:22 (periodic user-mode task, 1000 us period, priority 99)
> >>>>>>>>>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
> >>>>>>>>>> RTD| 3.499| 8.874| 61.374| 0| 0| 3.249| 109.791
> >>>>>>>>>> RTD| 3.499| 13.833| 100.749| 0| 0| 3.249| 109.791
> >>>>>>>>>> RTD| 3.541| 13.083| 99.249| 0| 0| 3.249| 109.791
> >>>>>>>>>> ---|-----------|-----------|-----------|--------|------|------------------------
> >>>>>>>>>> RTS| 3.249| 21.458| 109.791| 0| 0| 00:00:25/00:00:25
> >>>>>>>>>> root@arago:~#
> >>>>>>>>>
> >>>>>>>>> Note that if the OMAPL138 is an armv4 or armv5, you may want to enable
> >>>>>>>>> the FCSE in order to reduce context switch time (and latencies).
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> I enabled FCSE, and the max latency is more consistent (though the min
> >>>>>>>> and average latency has climbed). How do the below figures look?
> >>>>>>>
> >>>>>>> Otherwise, it is hard to say whether there is an issue or not. It is not
> >>>>>>> uncommon for armv4 or armv5 to have high latencies like this.
> >>>>>>> On what core is this processor based, running at what frequency?
> >>>>>>>
> >>>>>>>
> >>>>>> It's an AMR926EJ-S r5. Datasheet claims 375MHz, U-boot claims 300MHz.
> >>>>>>
> >>>>>> Load test to follow.
> >>>>>>
> >>>>>
> >>>>> OK, this run was done with LTP running on the board (runltplite.sh),
> >>>>> with cpu utilization between 90% and 100%
> >>>>
> >>>> You have to run the latency test while ltp is running, and run this for
> >>>> a few hours (ltp runs a few hours anyway).
> >>>>
> >>>> We provide the xeno-test script to do this (and dohell to generate
> >>>> load).
> >>>>
> >>>> See:
> >>>> http://www.xenomai.org/documentation/xenomai-2.6/html/xeno-test/index.html
> >>>> http://www.xenomai.org/documentation/xenomai-2.6/html/dohell/index.html
> >>>>
> >>>
> >>> That's proving to be a bit challenging. Giving dohell ltp is causing
> >>> more kernel panics - usually a SIGSEGV to init. Now I'm aware from your
> >>> previous thread on the OMAP-L138 that ltp doesn't run cleanly on low-end
> >>> arm chips as-is, but I'm guessing kernel panics wasn't the failure mode
> >>> you were seeing. (running ltp by itself also gives a different kernel
> >>> panic after about 15-20 minutes) So I need to look into that more.
> >>>
> >>> I also need to try the ltp build on the stock Ti-supplied system to make
> >>> sure there's not a pre-existing problem lurking in there; I should do
> >>> that tomorrow.
> >>
> >> The thing is, if you enabled FCSE in guaranteed mode, it does not really
> >> make sense to run LTP: most tests will fail because of the processes
> >> number limit. In that case you should use the -b option, and pass the
> >> path to hackbench only.
> >>
> >>>
> >>> FWIW just running xeno-test with no arguments finishes cleanly after
> >>> running for 10 minutes or so.
> >>>
> >>> Is it worth putting up the diff to the ipipe tree at this stage for
> >>> people to look over?
> >>
> >> If you have random segfault, then something is still wrong. Have you
> >> tried enabling I-pipe debugging options?
> >>
> >> The non-working I-pipe tracer with stack unwinding is not normal either,
> >> what version of the kernel are you using?
> >>
> >>
> > The kernel source I'm modifying is the master branch of the ipipe git
> > repo.
>
> Despite the fact that this branch does not correspond to any released
> I-pipe patch, I can confirm that the I-pipe tracer works with stack
> unwinding on at91rm9200, ,an armv4, and at91sam9263, an armv5. So, you
> must miss something in your patch. Again, I would advise you to use:
>
> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
>
> As a check list.
>
I did indeed use that page as a basis for the porting, and worked
through the "Troubleshooting" section at the bottom. Going through each
section:
* Hardware Timer - this is a slight concern as there is no acking
(hardware or software) of the irq at this level, so struct
ipipe_timer has .ack as NULL. Otherwise, set up as per example.
* High Resolution timer - it's free running, and straightforward
as per the example. It's edge triggered; changing to level
triggering results in no interrupts.
* Interrupt controller - no multi irqs. Mask/Unmask have the
ipipe_{un}lock_irq() added. Separate hold/release and
enable/disable calls without the lock (the latter added after
warnings with ipipe debugging turned on).
* GPIO - ipipe_handle_demuxed_irq() added in.
* I-pipe spinlocks - no conversions needed.
* Interrupt Controller Muting - skipped as recommended.
* Fast context switch extension - enabled (now - initial
crashes/panics were without it enabled).
* Troubleshooting - worked through as best I can with latency
tracing causing kernel panics.
> Also, if you can give us more details about the crash you get (kernel
> configuration, console messages), we could help you find what is wrong.
> And again, please enable all the I-pipe debugging option, in case it
> would catch an issue.
>
>
I can provide the defconfig either as an attachment or inline in the
mail - preference?
As to the crashes - I'll run through a full set today (tracing off,
tracing on, various tracing levels) and try to give as much info as
possible.
--
Peter Howard <pjh@northern-ridge.com.au>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-10 22:17 ` Peter Howard
@ 2014-04-10 22:23 ` Gilles Chanteperdrix
2014-04-10 22:27 ` Peter Howard
` (2 more replies)
0 siblings, 3 replies; 57+ messages in thread
From: Gilles Chanteperdrix @ 2014-04-10 22:23 UTC (permalink / raw)
To: Peter Howard; +Cc: xenomai
On 04/11/2014 12:17 AM, Peter Howard wrote:
> On Thu, 2014-04-10 at 23:56 +0200, Gilles Chanteperdrix wrote:
>> On 04/10/2014 09:57 PM, Peter Howard wrote:
>>> On Thu, 2014-04-10 at 14:06 +0200, Gilles Chanteperdrix wrote:
>>>> On 04/10/2014 09:01 AM, Peter Howard wrote:
>>>>> On Wed, 2014-04-09 at 13:54 +0200, Gilles Chanteperdrix wrote:
>>>>>> On 04/09/2014 06:27 AM, Peter Howard wrote:
>>>>>>> On Wed, 2014-04-09 at 10:34 +1000, Peter Howard wrote:
>>>>>>>> On Wed, 2014-04-09 at 02:20 +0200, Gilles Chanteperdrix wrote:
>>>>>>>>> On 04/09/2014 01:30 AM, Peter Howard wrote:
>>>>>>>>>> On Tue, 2014-04-08 at 11:18 +0200, Gilles Chanteperdrix wrote:
>>>>>>>>>>> On 04/07/2014 07:34 AM, Peter Howard wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, 2014-04-02 at 09:24 +0200, Gilles Chanteperdrix wrote:
>>>>>>>>>>>>> On 04/02/2014 04:59 AM, Peter Howard wrote:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm interested in running xenomai on a TI-OMAP L138 board. I found the
>>>>>>>>>>>>>> following thread in the archives:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://www.xenomai.org/pipermail/xenomai/2010-January/018898.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> where someone was working on porting ipipe and xenomai to that board.
>>>>>>>>>>>>>> However, the thread ended with problems still unresolved, and the patch
>>>>>>>>>>>>>> in the thread (just the changes for ipipe) isn't in the ipipe
>>>>>>>>>>>>>> repository.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Does anyone know if this work was completed or just faded into the
>>>>>>>>>>>>>> ether?
>>>>>>>>>>>>>
>>>>>>>>>>>>> We never merged a patch for this processor. And a lot of things changed
>>>>>>>>>>>>> since that time. If you are interested in porting the I-pipe patch to
>>>>>>>>>>>>> this processor, see:
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Contrary to what I said last week, I'm working on a patch off the head
>>>>>>>>>>>> of the ipipe repo. I have built a kernel with an ipipe port and with
>>>>>>>>>>>> xenomai patched in. However the latency results are bad right now:
>>>>>>>>>>>>
>>>>>>>>>>>> root@arago:~# xeno latency -T 25
>>>>>>>>>>>> == Sampling period: 1000 us
>>>>>>>>>>>> == Test mode: periodic user-mode task
>>>>>>>>>>>> == All results in microseconds
>>>>>>>>>>>> warming up...
>>>>>>>>>>>> RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)
>>>>>>>>>>>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
>>>>>>>>>>>> RTD| 3.541| 8.833| 60.749| 0| 0| 3.541| 60.749
>>>>>>>>>>>> RTD| 3.499| 13.583| 93.916| 0| 0| 3.499| 93.916
>>>>>>>>>>>> RTD| 3.666| 88.999| 109.708| 0| 0| 3.499| 109.708
>>>>>>>>>>>> RTD| 3.541| 14.958| 95.374| 0| 0| 3.499| 109.708
>>>>>>>>>>>> RTD| 3.541| 9.333| 77.583| 0| 0| 3.499| 109.708
>>>>>>>>>>>> RTD| 4.041| 88.416| 109.791| 0| 0| 3.499| 109.791
>>>>>>>>>>>> RTD| 3.499| 8.958| 72.791| 0| 0| 3.499| 109.791
>>>>>>>>>>>> RTD| 3.499| 26.041| 106.874| 0| 0| 3.499| 109.791
>>>>>>>>>>>> RTD| 3.874| 82.708| 107.916| 0| 0| 3.499| 109.791
>>>>>>>>>>>> RTD| 3.499| 9.083| 73.708| 0| 0| 3.499| 109.791
>>>>>>>>>>>> RTD| 3.333| 8.874| 62.458| 0| 0| 3.333| 109.791
>>>>>>>>>>>> RTD| 3.333| 8.749| 62.208| 0| 0| 3.333| 109.791
>>>>>>>>>>>> RTD| 3.416| 12.708| 99.416| 0| 0| 3.333| 109.791
>>>>>>>>>>>> RTD| 3.499| 14.249| 106.749| 0| 0| 3.333| 109.791
>>>>>>>>>>>> RTD| 3.541| 9.083| 76.499| 0| 0| 3.333| 109.791
>>>>>>>>>>>> RTD| 3.249| 8.791| 63.499| 0| 0| 3.249| 109.791
>>>>>>>>>>>> RTD| 3.416| 8.999| 62.499| 0| 0| 3.249| 109.791
>>>>>>>>>>>> RTD| 3.541| 26.166| 101.208| 0| 0| 3.249| 109.791
>>>>>>>>>>>> RTD| 3.583| 13.624| 92.458| 0| 0| 3.249| 109.791
>>>>>>>>>>>> RTD| 3.541| 8.916| 73.708| 0| 0| 3.249| 109.791
>>>>>>>>>>>> RTD| 3.541| 8.999| 64.291| 0| 0| 3.249| 109.791
>>>>>>>>>>>> RTT| 00:00:22 (periodic user-mode task, 1000 us period, priority 99)
>>>>>>>>>>>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
>>>>>>>>>>>> RTD| 3.499| 8.874| 61.374| 0| 0| 3.249| 109.791
>>>>>>>>>>>> RTD| 3.499| 13.833| 100.749| 0| 0| 3.249| 109.791
>>>>>>>>>>>> RTD| 3.541| 13.083| 99.249| 0| 0| 3.249| 109.791
>>>>>>>>>>>> ---|-----------|-----------|-----------|--------|------|------------------------
>>>>>>>>>>>> RTS| 3.249| 21.458| 109.791| 0| 0| 00:00:25/00:00:25
>>>>>>>>>>>> root@arago:~#
>>>>>>>>>>>
>>>>>>>>>>> Note that if the OMAPL138 is an armv4 or armv5, you may want to enable
>>>>>>>>>>> the FCSE in order to reduce context switch time (and latencies).
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I enabled FCSE, and the max latency is more consistent (though the min
>>>>>>>>>> and average latency has climbed). How do the below figures look?
>>>>>>>>>
>>>>>>>>> Otherwise, it is hard to say whether there is an issue or not. It is not
>>>>>>>>> uncommon for armv4 or armv5 to have high latencies like this.
>>>>>>>>> On what core is this processor based, running at what frequency?
>>>>>>>>>
>>>>>>>>>
>>>>>>>> It's an AMR926EJ-S r5. Datasheet claims 375MHz, U-boot claims 300MHz.
>>>>>>>>
>>>>>>>> Load test to follow.
>>>>>>>>
>>>>>>>
>>>>>>> OK, this run was done with LTP running on the board (runltplite.sh),
>>>>>>> with cpu utilization between 90% and 100%
>>>>>>
>>>>>> You have to run the latency test while ltp is running, and run this for
>>>>>> a few hours (ltp runs a few hours anyway).
>>>>>>
>>>>>> We provide the xeno-test script to do this (and dohell to generate
>>>>>> load).
>>>>>>
>>>>>> See:
>>>>>> http://www.xenomai.org/documentation/xenomai-2.6/html/xeno-test/index.html
>>>>>> http://www.xenomai.org/documentation/xenomai-2.6/html/dohell/index.html
>>>>>>
>>>>>
>>>>> That's proving to be a bit challenging. Giving dohell ltp is causing
>>>>> more kernel panics - usually a SIGSEGV to init. Now I'm aware from your
>>>>> previous thread on the OMAP-L138 that ltp doesn't run cleanly on low-end
>>>>> arm chips as-is, but I'm guessing kernel panics wasn't the failure mode
>>>>> you were seeing. (running ltp by itself also gives a different kernel
>>>>> panic after about 15-20 minutes) So I need to look into that more.
>>>>>
>>>>> I also need to try the ltp build on the stock Ti-supplied system to make
>>>>> sure there's not a pre-existing problem lurking in there; I should do
>>>>> that tomorrow.
>>>>
>>>> The thing is, if you enabled FCSE in guaranteed mode, it does not really
>>>> make sense to run LTP: most tests will fail because of the processes
>>>> number limit. In that case you should use the -b option, and pass the
>>>> path to hackbench only.
>>>>
>>>>>
>>>>> FWIW just running xeno-test with no arguments finishes cleanly after
>>>>> running for 10 minutes or so.
>>>>>
>>>>> Is it worth putting up the diff to the ipipe tree at this stage for
>>>>> people to look over?
>>>>
>>>> If you have random segfault, then something is still wrong. Have you
>>>> tried enabling I-pipe debugging options?
>>>>
>>>> The non-working I-pipe tracer with stack unwinding is not normal either,
>>>> what version of the kernel are you using?
>>>>
>>>>
>>> The kernel source I'm modifying is the master branch of the ipipe git
>>> repo.
>>
>> Despite the fact that this branch does not correspond to any released
>> I-pipe patch, I can confirm that the I-pipe tracer works with stack
>> unwinding on at91rm9200, ,an armv4, and at91sam9263, an armv5. So, you
>> must miss something in your patch. Again, I would advise you to use:
>>
>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
>>
>> As a check list.
>>
>
> I did indeed use that page as a basis for the porting, and worked
> through the "Troubleshooting" section at the bottom. Going through each
> section:
> * Hardware Timer - this is a slight concern as there is no acking
> (hardware or software) of the irq at this level, so struct
> ipipe_timer has .ack as NULL. Otherwise, set up as per example.
> * High Resolution timer - it's free running, and straightforward
> as per the example. It's edge triggered; changing to level
> triggering results in no interrupts.
> * Interrupt controller - no multi irqs. Mask/Unmask have the
> ipipe_{un}lock_irq() added. Separate hold/release and
> enable/disable calls without the lock (the latter added after
> warnings with ipipe debugging turned on).
> * GPIO - ipipe_handle_demuxed_irq() added in.
> * I-pipe spinlocks - no conversions needed.
> * Interrupt Controller Muting - skipped as recommended.
> * Fast context switch extension - enabled (now - initial
> crashes/panics were without it enabled).
> * Troubleshooting - worked through as best I can with latency
> tracing causing kernel panics.
One missing point: the idle routine. As a quick check, could you boot
with the nohlt parameter and see if it changes anything?
>
>
>> Also, if you can give us more details about the crash you get (kernel
>> configuration, console messages), we could help you find what is wrong.
>> And again, please enable all the I-pipe debugging option, in case it
>> would catch an issue.
>>
>>
> I can provide the defconfig either as an attachment or inline in the
> mail - preference?
> As to the crashes - I'll run through a full set today (tracing off,
> tracing on, various tracing levels) and try to give as much info as
> possible.
>
Attachment is better. Also please post the changes you made for omapL138
--
Gilles.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-10 22:23 ` Gilles Chanteperdrix
@ 2014-04-10 22:27 ` Peter Howard
2014-04-10 22:34 ` Peter Howard
2014-04-10 23:01 ` Peter Howard
2 siblings, 0 replies; 57+ messages in thread
From: Peter Howard @ 2014-04-10 22:27 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On Fri, 2014-04-11 at 00:23 +0200, Gilles Chanteperdrix wrote:
> On 04/11/2014 12:17 AM, Peter Howard wrote:
> > On Thu, 2014-04-10 at 23:56 +0200, Gilles Chanteperdrix wrote:
> >> On 04/10/2014 09:57 PM, Peter Howard wrote:
> >>> On Thu, 2014-04-10 at 14:06 +0200, Gilles Chanteperdrix wrote:
> >>>> On 04/10/2014 09:01 AM, Peter Howard wrote:
> >>>>> On Wed, 2014-04-09 at 13:54 +0200, Gilles Chanteperdrix wrote:
> >>>>>> On 04/09/2014 06:27 AM, Peter Howard wrote:
> >>>>>>> On Wed, 2014-04-09 at 10:34 +1000, Peter Howard wrote:
> >>>>>>>> On Wed, 2014-04-09 at 02:20 +0200, Gilles Chanteperdrix wrote:
> >>>>>>>>> On 04/09/2014 01:30 AM, Peter Howard wrote:
> >>>>>>>>>> On Tue, 2014-04-08 at 11:18 +0200, Gilles Chanteperdrix wrote:
> >>>>>>>>>>> On 04/07/2014 07:34 AM, Peter Howard wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Wed, 2014-04-02 at 09:24 +0200, Gilles Chanteperdrix wrote:
> >>>>>>>>>>>>> On 04/02/2014 04:59 AM, Peter Howard wrote:
> >>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I'm interested in running xenomai on a TI-OMAP L138 board. I found the
> >>>>>>>>>>>>>> following thread in the archives:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> http://www.xenomai.org/pipermail/xenomai/2010-January/018898.html
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> where someone was working on porting ipipe and xenomai to that board.
> >>>>>>>>>>>>>> However, the thread ended with problems still unresolved, and the patch
> >>>>>>>>>>>>>> in the thread (just the changes for ipipe) isn't in the ipipe
> >>>>>>>>>>>>>> repository.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Does anyone know if this work was completed or just faded into the
> >>>>>>>>>>>>>> ether?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> We never merged a patch for this processor. And a lot of things changed
> >>>>>>>>>>>>> since that time. If you are interested in porting the I-pipe patch to
> >>>>>>>>>>>>> this processor, see:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Contrary to what I said last week, I'm working on a patch off the head
> >>>>>>>>>>>> of the ipipe repo. I have built a kernel with an ipipe port and with
> >>>>>>>>>>>> xenomai patched in. However the latency results are bad right now:
> >>>>>>>>>>>>
> >>>>>>>>>>>> root@arago:~# xeno latency -T 25
> >>>>>>>>>>>> == Sampling period: 1000 us
> >>>>>>>>>>>> == Test mode: periodic user-mode task
> >>>>>>>>>>>> == All results in microseconds
> >>>>>>>>>>>> warming up...
> >>>>>>>>>>>> RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)
> >>>>>>>>>>>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
> >>>>>>>>>>>> RTD| 3.541| 8.833| 60.749| 0| 0| 3.541| 60.749
> >>>>>>>>>>>> RTD| 3.499| 13.583| 93.916| 0| 0| 3.499| 93.916
> >>>>>>>>>>>> RTD| 3.666| 88.999| 109.708| 0| 0| 3.499| 109.708
> >>>>>>>>>>>> RTD| 3.541| 14.958| 95.374| 0| 0| 3.499| 109.708
> >>>>>>>>>>>> RTD| 3.541| 9.333| 77.583| 0| 0| 3.499| 109.708
> >>>>>>>>>>>> RTD| 4.041| 88.416| 109.791| 0| 0| 3.499| 109.791
> >>>>>>>>>>>> RTD| 3.499| 8.958| 72.791| 0| 0| 3.499| 109.791
> >>>>>>>>>>>> RTD| 3.499| 26.041| 106.874| 0| 0| 3.499| 109.791
> >>>>>>>>>>>> RTD| 3.874| 82.708| 107.916| 0| 0| 3.499| 109.791
> >>>>>>>>>>>> RTD| 3.499| 9.083| 73.708| 0| 0| 3.499| 109.791
> >>>>>>>>>>>> RTD| 3.333| 8.874| 62.458| 0| 0| 3.333| 109.791
> >>>>>>>>>>>> RTD| 3.333| 8.749| 62.208| 0| 0| 3.333| 109.791
> >>>>>>>>>>>> RTD| 3.416| 12.708| 99.416| 0| 0| 3.333| 109.791
> >>>>>>>>>>>> RTD| 3.499| 14.249| 106.749| 0| 0| 3.333| 109.791
> >>>>>>>>>>>> RTD| 3.541| 9.083| 76.499| 0| 0| 3.333| 109.791
> >>>>>>>>>>>> RTD| 3.249| 8.791| 63.499| 0| 0| 3.249| 109.791
> >>>>>>>>>>>> RTD| 3.416| 8.999| 62.499| 0| 0| 3.249| 109.791
> >>>>>>>>>>>> RTD| 3.541| 26.166| 101.208| 0| 0| 3.249| 109.791
> >>>>>>>>>>>> RTD| 3.583| 13.624| 92.458| 0| 0| 3.249| 109.791
> >>>>>>>>>>>> RTD| 3.541| 8.916| 73.708| 0| 0| 3.249| 109.791
> >>>>>>>>>>>> RTD| 3.541| 8.999| 64.291| 0| 0| 3.249| 109.791
> >>>>>>>>>>>> RTT| 00:00:22 (periodic user-mode task, 1000 us period, priority 99)
> >>>>>>>>>>>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
> >>>>>>>>>>>> RTD| 3.499| 8.874| 61.374| 0| 0| 3.249| 109.791
> >>>>>>>>>>>> RTD| 3.499| 13.833| 100.749| 0| 0| 3.249| 109.791
> >>>>>>>>>>>> RTD| 3.541| 13.083| 99.249| 0| 0| 3.249| 109.791
> >>>>>>>>>>>> ---|-----------|-----------|-----------|--------|------|------------------------
> >>>>>>>>>>>> RTS| 3.249| 21.458| 109.791| 0| 0| 00:00:25/00:00:25
> >>>>>>>>>>>> root@arago:~#
> >>>>>>>>>>>
> >>>>>>>>>>> Note that if the OMAPL138 is an armv4 or armv5, you may want to enable
> >>>>>>>>>>> the FCSE in order to reduce context switch time (and latencies).
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> I enabled FCSE, and the max latency is more consistent (though the min
> >>>>>>>>>> and average latency has climbed). How do the below figures look?
> >>>>>>>>>
> >>>>>>>>> Otherwise, it is hard to say whether there is an issue or not. It is not
> >>>>>>>>> uncommon for armv4 or armv5 to have high latencies like this.
> >>>>>>>>> On what core is this processor based, running at what frequency?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> It's an AMR926EJ-S r5. Datasheet claims 375MHz, U-boot claims 300MHz.
> >>>>>>>>
> >>>>>>>> Load test to follow.
> >>>>>>>>
> >>>>>>>
> >>>>>>> OK, this run was done with LTP running on the board (runltplite.sh),
> >>>>>>> with cpu utilization between 90% and 100%
> >>>>>>
> >>>>>> You have to run the latency test while ltp is running, and run this for
> >>>>>> a few hours (ltp runs a few hours anyway).
> >>>>>>
> >>>>>> We provide the xeno-test script to do this (and dohell to generate
> >>>>>> load).
> >>>>>>
> >>>>>> See:
> >>>>>> http://www.xenomai.org/documentation/xenomai-2.6/html/xeno-test/index.html
> >>>>>> http://www.xenomai.org/documentation/xenomai-2.6/html/dohell/index.html
> >>>>>>
> >>>>>
> >>>>> That's proving to be a bit challenging. Giving dohell ltp is causing
> >>>>> more kernel panics - usually a SIGSEGV to init. Now I'm aware from your
> >>>>> previous thread on the OMAP-L138 that ltp doesn't run cleanly on low-end
> >>>>> arm chips as-is, but I'm guessing kernel panics wasn't the failure mode
> >>>>> you were seeing. (running ltp by itself also gives a different kernel
> >>>>> panic after about 15-20 minutes) So I need to look into that more.
> >>>>>
> >>>>> I also need to try the ltp build on the stock Ti-supplied system to make
> >>>>> sure there's not a pre-existing problem lurking in there; I should do
> >>>>> that tomorrow.
> >>>>
> >>>> The thing is, if you enabled FCSE in guaranteed mode, it does not really
> >>>> make sense to run LTP: most tests will fail because of the processes
> >>>> number limit. In that case you should use the -b option, and pass the
> >>>> path to hackbench only.
> >>>>
> >>>>>
> >>>>> FWIW just running xeno-test with no arguments finishes cleanly after
> >>>>> running for 10 minutes or so.
> >>>>>
> >>>>> Is it worth putting up the diff to the ipipe tree at this stage for
> >>>>> people to look over?
> >>>>
> >>>> If you have random segfault, then something is still wrong. Have you
> >>>> tried enabling I-pipe debugging options?
> >>>>
> >>>> The non-working I-pipe tracer with stack unwinding is not normal either,
> >>>> what version of the kernel are you using?
> >>>>
> >>>>
> >>> The kernel source I'm modifying is the master branch of the ipipe git
> >>> repo.
> >>
> >> Despite the fact that this branch does not correspond to any released
> >> I-pipe patch, I can confirm that the I-pipe tracer works with stack
> >> unwinding on at91rm9200, ,an armv4, and at91sam9263, an armv5. So, you
> >> must miss something in your patch. Again, I would advise you to use:
> >>
> >> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
> >>
> >> As a check list.
> >>
> >
> > I did indeed use that page as a basis for the porting, and worked
> > through the "Troubleshooting" section at the bottom. Going through each
> > section:
> > * Hardware Timer - this is a slight concern as there is no acking
> > (hardware or software) of the irq at this level, so struct
> > ipipe_timer has .ack as NULL. Otherwise, set up as per example.
> > * High Resolution timer - it's free running, and straightforward
> > as per the example. It's edge triggered; changing to level
> > triggering results in no interrupts.
> > * Interrupt controller - no multi irqs. Mask/Unmask have the
> > ipipe_{un}lock_irq() added. Separate hold/release and
> > enable/disable calls without the lock (the latter added after
> > warnings with ipipe debugging turned on).
> > * GPIO - ipipe_handle_demuxed_irq() added in.
> > * I-pipe spinlocks - no conversions needed.
> > * Interrupt Controller Muting - skipped as recommended.
> > * Fast context switch extension - enabled (now - initial
> > crashes/panics were without it enabled).
> > * Troubleshooting - worked through as best I can with latency
> > tracing causing kernel panics.
>
> One missing point: the idle routine. As a quick check, could you boot
> with the nohlt parameter and see if it changes anything?
>
> >
> >
> >> Also, if you can give us more details about the crash you get (kernel
> >> configuration, console messages), we could help you find what is wrong.
> >> And again, please enable all the I-pipe debugging option, in case it
> >> would catch an issue.
> >>
> >>
> > I can provide the defconfig either as an attachment or inline in the
> > mail - preference?
> > As to the crashes - I'll run through a full set today (tracing off,
> > tracing on, various tracing levels) and try to give as much info as
> > possible.
> >
>
> Attachment is better. Also please post the changes you made for omapL138
>
Defconfig attached. Patch to follow.
--
Peter Howard <pjh@northern-ridge.com.au>
-------------- next part --------------
#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 3.10.0 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_IPIPE_WANT_ACTIVE_MM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ARCH_HAS_CPUFREQ=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ZONE_DMA=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_VECTORS_BASE=0xffff0000
CONFIG_ARM_PATCH_PHYS_VIRT=y
CONFIG_NEED_MACH_GPIO_H=y
CONFIG_GENERIC_BUG=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION="-ipipe"
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_FHANDLE is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y
#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
#
# RCU Subsystem
#
CONFIG_TREE_PREEMPT_RCU=y
# CONFIG_TINY_PREEMPT_RCU is not set
CONFIG_PREEMPT_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_FANOUT=32
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_BOOST is not set
# CONFIG_RCU_NOCB_CPU is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
# CONFIG_CGROUP_FREEZER is not set
# CONFIG_CGROUP_DEVICE is not set
# CONFIG_CPUSETS is not set
# CONFIG_CGROUP_CPUACCT is not set
# CONFIG_RESOURCE_COUNTERS is not set
# CONFIG_CGROUP_SCHED is not set
# CONFIG_BLK_CGROUP is not set
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_NAMESPACES is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_HOTPLUG=y
CONFIG_EXPERT=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y
#
# Kernel Performance Events And Counters
#
# CONFIG_PERF_EVENTS is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
CONFIG_COMPAT_BRK=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
# CONFIG_PROFILING is not set
CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
# CONFIG_JUMP_LABEL is not set
# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_DMA_CONTIGUOUS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_GENERIC_IDLE_POLL_SETUP=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_HAVE_CONTEXT_TRACKING=y
CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
CONFIG_HAVE_MOD_ARCH_SPECIFIC=y
CONFIG_MODULES_USE_ELF_REL=y
CONFIG_CLONE_BACKWARDS=y
CONFIG_OLD_SIGSUSPEND3=y
CONFIG_OLD_SIGACTION=y
#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
# CONFIG_MODULE_SIG is not set
CONFIG_BLOCK=y
CONFIG_LBDAF=y
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_BSGLIB is not set
# CONFIG_BLK_DEV_INTEGRITY is not set
#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"
CONFIG_UNINLINE_SPIN_UNLOCK=y
#
# Real-time sub-system
#
CONFIG_XENOMAI=y
CONFIG_XENO_GENERIC_STACKPOOL=y
CONFIG_XENO_FASTSYNCH_DEP=y
CONFIG_XENO_FASTSYNCH=y
CONFIG_XENO_OPT_NUCLEUS=y
CONFIG_XENO_OPT_PERVASIVE=y
# CONFIG_XENO_OPT_PRIOCPL is not set
CONFIG_XENO_OPT_PIPELINE_HEAD=y
# CONFIG_XENO_OPT_SCHED_CLASSES is not set
CONFIG_XENO_OPT_PIPE=y
CONFIG_XENO_OPT_MAP=y
CONFIG_XENO_OPT_VFILE=y
CONFIG_XENO_OPT_PIPE_NRDEV=32
CONFIG_XENO_OPT_REGISTRY_NRSLOTS=512
CONFIG_XENO_OPT_SYS_HEAPSZ=256
CONFIG_XENO_OPT_SYS_STACKPOOLSZ=128
CONFIG_XENO_OPT_SEM_HEAPSZ=12
CONFIG_XENO_OPT_GLOBAL_SEM_HEAPSZ=12
CONFIG_XENO_OPT_STATS=y
CONFIG_XENO_OPT_DEBUG=y
# CONFIG_XENO_OPT_DEBUG_NUCLEUS is not set
# CONFIG_XENO_OPT_DEBUG_XNLOCK is not set
# CONFIG_XENO_OPT_DEBUG_QUEUES is not set
# CONFIG_XENO_OPT_DEBUG_REGISTRY is not set
# CONFIG_XENO_OPT_DEBUG_TIMERS is not set
CONFIG_XENO_OPT_DEBUG_SYNCH_RELAX=y
CONFIG_XENO_OPT_WATCHDOG=y
CONFIG_XENO_OPT_WATCHDOG_TIMEOUT=4
# CONFIG_XENO_OPT_SHIRQ is not set
CONFIG_XENO_OPT_SELECT=y
CONFIG_XENO_OPT_HOSTRT=y
#
# Timing
#
# CONFIG_XENO_OPT_TIMING_PERIODIC is not set
CONFIG_XENO_OPT_TIMING_VIRTICK=1000
CONFIG_XENO_OPT_TIMING_SCHEDLAT=0
#
# Scalability
#
# CONFIG_XENO_OPT_SCALABLE_SCHED is not set
CONFIG_XENO_OPT_TIMER_LIST=y
# CONFIG_XENO_OPT_TIMER_HEAP is not set
# CONFIG_XENO_OPT_TIMER_WHEEL is not set
#
# Machine
#
CONFIG_IPIPE_WANT_PREEMPTIBLE_SWITCH=y
CONFIG_XENO_HW_FPU=y
CONFIG_XENO_HW_UNLOCKED_SWITCH=y
#
# Interfaces
#
CONFIG_XENO_SKIN_NATIVE=y
CONFIG_XENO_OPT_NATIVE_PERIOD=0
CONFIG_XENO_OPT_NATIVE_PIPE=y
CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=1024
CONFIG_XENO_OPT_NATIVE_SEM=y
CONFIG_XENO_OPT_NATIVE_EVENT=y
CONFIG_XENO_OPT_NATIVE_MUTEX=y
CONFIG_XENO_OPT_NATIVE_COND=y
CONFIG_XENO_OPT_NATIVE_QUEUE=y
CONFIG_XENO_OPT_NATIVE_BUFFER=y
CONFIG_XENO_OPT_NATIVE_HEAP=y
CONFIG_XENO_OPT_NATIVE_ALARM=y
CONFIG_XENO_OPT_NATIVE_MPS=y
# CONFIG_XENO_OPT_NATIVE_INTR is not set
CONFIG_XENO_OPT_DEBUG_NATIVE=y
CONFIG_XENO_SKIN_POSIX=y
CONFIG_XENO_OPT_POSIX_PERIOD=0
CONFIG_XENO_OPT_POSIX_REGISTRY_NRSLOTS=64
CONFIG_XENO_OPT_POSIX_REGISTRY_NRDESCS=128
CONFIG_XENO_OPT_POSIX_NRTIMERS=128
# CONFIG_XENO_OPT_POSIX_SHM is not set
# CONFIG_XENO_OPT_POSIX_INTR is not set
CONFIG_XENO_OPT_POSIX_SELECT=y
CONFIG_XENO_OPT_DEBUG_POSIX=y
# CONFIG_XENO_SKIN_PSOS is not set
# CONFIG_XENO_SKIN_UITRON is not set
# CONFIG_XENO_SKIN_VRTX is not set
# CONFIG_XENO_SKIN_VXWORKS is not set
# CONFIG_XENO_OPT_NOWARN_DEPRECATED is not set
CONFIG_XENO_SKIN_RTDM=y
CONFIG_XENO_OPT_RTDM_PERIOD=0
CONFIG_XENO_OPT_RTDM_FILDES=128
CONFIG_XENO_OPT_RTDM_SELECT=y
# CONFIG_XENO_OPT_DEBUG_RTDM is not set
CONFIG_XENO_OPT_DEBUG_RTDM_APPL=y
#
# Drivers
#
#
# Serial drivers
#
# CONFIG_XENO_DRIVERS_16550A is not set
#
# Testing drivers
#
CONFIG_XENO_DRIVERS_TIMERBENCH=y
# CONFIG_XENO_DRIVERS_KLATENCY is not set
# CONFIG_XENO_DRIVERS_IRQBENCH is not set
CONFIG_XENO_DRIVERS_SWITCHTEST=y
# CONFIG_XENO_DRIVERS_RTDMTEST is not set
#
# CAN drivers
#
# CONFIG_XENO_DRIVERS_CAN is not set
#
# ANALOGY drivers
#
# CONFIG_XENO_DRIVERS_ANALOGY is not set
#
# Real-time IPC drivers
#
CONFIG_XENO_DRIVERS_RTIPC=y
CONFIG_XENO_DRIVERS_RTIPC_XDDP=y
CONFIG_XENO_DRIVERS_RTIPC_IDDP=y
CONFIG_XENO_OPT_IDDP_NRPORT=32
CONFIG_XENO_DRIVERS_RTIPC_BUFP=y
CONFIG_XENO_OPT_BUFP_NRPORT=32
CONFIG_FREEZER=y
#
# System Type
#
CONFIG_MMU=y
# CONFIG_ARCH_MULTIPLATFORM is not set
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_GEMINI is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_DOVE is not set
# CONFIG_ARCH_KIRKWOOD is not set
# CONFIG_ARCH_MV78XX0 is not set
# CONFIG_ARCH_ORION5X is not set
# CONFIG_ARCH_MMP is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_W90X900 is not set
# CONFIG_ARCH_LPC32XX is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_MSM is not set
# CONFIG_ARCH_SHMOBILE is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C24XX is not set
# CONFIG_ARCH_S3C64XX is not set
# CONFIG_ARCH_S5P64X0 is not set
# CONFIG_ARCH_S5PC100 is not set
# CONFIG_ARCH_S5PV210 is not set
# CONFIG_ARCH_EXYNOS is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_U300 is not set
CONFIG_ARCH_DAVINCI=y
# CONFIG_ARCH_OMAP1 is not set
CONFIG_CP_INTC=y
#
# TI DaVinci Implementations
#
#
# DaVinci Core Type
#
# CONFIG_ARCH_DAVINCI_DM644x is not set
# CONFIG_ARCH_DAVINCI_DM355 is not set
# CONFIG_ARCH_DAVINCI_DM646x is not set
CONFIG_ARCH_DAVINCI_DA830=y
CONFIG_ARCH_DAVINCI_DA850=y
CONFIG_ARCH_DAVINCI_DA8XX=y
# CONFIG_ARCH_DAVINCI_DM365 is not set
# CONFIG_ARCH_DAVINCI_TNETV107X is not set
#
# DaVinci Board Type
#
CONFIG_MACH_DA8XX_DT=y
CONFIG_MACH_DAVINCI_DA830_EVM=y
CONFIG_DA830_UI_LCD=y
# CONFIG_DA830_UI_NAND is not set
CONFIG_MACH_DAVINCI_DA850_EVM=y
CONFIG_DA850_UI_NONE=y
# CONFIG_DA850_UI_RMII is not set
# CONFIG_DA850_UI_SD_VIDEO_PORT is not set
# CONFIG_DA850_WL12XX is not set
CONFIG_GPIO_PCA953X=y
CONFIG_KEYBOARD_GPIO_POLLED=y
CONFIG_MACH_MITYOMAPL138=y
CONFIG_MACH_OMAPL138_HAWKBOARD=y
CONFIG_DAVINCI_MUX=y
# CONFIG_DAVINCI_MUX_DEBUG is not set
# CONFIG_DAVINCI_MUX_WARNINGS is not set
CONFIG_DAVINCI_RESET_CLOCKS=y
# CONFIG_PLAT_SPEAR is not set
CONFIG_IPIPE_ARM_KUSER_TSC=y
#
# Processor Type
#
CONFIG_CPU_ARM926T=y
CONFIG_CPU_32v5=y
CONFIG_CPU_ABRT_EV5TJ=y
CONFIG_CPU_PABRT_LEGACY=y
CONFIG_CPU_CACHE_VIVT=y
CONFIG_CPU_COPY_V4WB=y
CONFIG_CPU_TLB_V4WBI=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y
CONFIG_CPU_USE_DOMAINS=y
#
# Processor Features
#
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
CONFIG_ARM_THUMB=y
# CONFIG_CPU_ICACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
CONFIG_CPU_DCACHE_WRITETHROUGH=y
# CONFIG_CPU_CACHE_ROUND_ROBIN is not set
# CONFIG_CACHE_L2X0 is not set
CONFIG_ARM_L1_CACHE_SHIFT=5
CONFIG_ARM_FCSE=y
# CONFIG_ARM_FCSE_GUARANTEED is not set
CONFIG_ARM_FCSE_BEST_EFFORT=y
# CONFIG_ARM_FCSE_PREEMPT_FLUSH is not set
CONFIG_ARM_FCSE_MESSAGES=y
# CONFIG_ARM_FCSE_DEBUG is not set
CONFIG_ARM_NR_BANKS=8
#
# Bus support
#
# CONFIG_PCI_SYSCALL is not set
# CONFIG_PCCARD is not set
#
# Kernel Features
#
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_ARCH_NR_GPIO=0
CONFIG_IPIPE=y
CONFIG_IPIPE_LEGACY=y
CONFIG_IPIPE_CORE=y
CONFIG_IPIPE_CORE_APIREV=2
CONFIG_IPIPE_WANT_APIREV_2=y
CONFIG_IPIPE_TARGET_APIREV=2
CONFIG_IPIPE_HAVE_HOSTRT=y
CONFIG_IPIPE_DELAYED_ATOMICSW=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_COUNT=y
CONFIG_HZ=100
CONFIG_SCHED_HRTICK=y
CONFIG_AEABI=y
# CONFIG_OABI_COMPAT is not set
CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y
# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
CONFIG_HAVE_ARCH_PFN_VALID=y
# CONFIG_HIGHMEM is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_HAVE_MEMBLOCK=y
# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=999999
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_NEED_PER_CPU_KM=y
# CONFIG_CLEANCACHE is not set
CONFIG_FORCE_MAX_ZONEORDER=11
CONFIG_ALIGNMENT_TRAP=y
# CONFIG_UACCESS_WITH_MEMCPY is not set
# CONFIG_SECCOMP is not set
# CONFIG_CC_STACKPROTECTOR is not set
#
# Boot options
#
CONFIG_USE_OF=y
CONFIG_ATAGS=y
# CONFIG_DEPRECATED_PARAM_STRUCT is not set
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
# CONFIG_ARM_APPENDED_DTB is not set
CONFIG_CMDLINE=""
# CONFIG_XIP_KERNEL is not set
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
# CONFIG_AUTO_ZRELADDR is not set
#
# CPU Power Management
#
#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
# CONFIG_CPU_IDLE is not set
# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set
#
# Floating point emulation
#
#
# At least one emulation must be selected
#
# CONFIG_VFP is not set
#
# Userspace binary formats
#
CONFIG_BINFMT_ELF=y
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_BINFMT_SCRIPT=y
CONFIG_HAVE_AOUT=y
# CONFIG_BINFMT_AOUT is not set
# CONFIG_BINFMT_MISC is not set
CONFIG_COREDUMP=y
#
# Power management options
#
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_PM_SLEEP=y
# CONFIG_PM_AUTOSLEEP is not set
# CONFIG_PM_WAKELOCKS is not set
CONFIG_PM_RUNTIME=y
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
# CONFIG_APM_EMULATION is not set
CONFIG_PM_CLK=y
CONFIG_CPU_PM=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARM_CPU_SUSPEND=y
CONFIG_NET=y
#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_DIAG is not set
CONFIG_UNIX=y
# CONFIG_UNIX_DIAG is not set
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_XFRM_STATISTICS is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
# CONFIG_IP_PNP_BOOTP is not set
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE_DEMUX is not set
CONFIG_NET_IP_TUNNEL=m
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_NET_IPVTI is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
CONFIG_INET_TUNNEL=m
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
# CONFIG_INET_LRO is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_INET_UDP_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
CONFIG_IPV6=m
# CONFIG_IPV6_PRIVACY is not set
# CONFIG_IPV6_ROUTER_PREF is not set
# CONFIG_IPV6_OPTIMISTIC_DAD is not set
# CONFIG_INET6_AH is not set
# CONFIG_INET6_ESP is not set
# CONFIG_INET6_IPCOMP is not set
# CONFIG_IPV6_MIP6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
CONFIG_INET6_XFRM_MODE_TRANSPORT=m
CONFIG_INET6_XFRM_MODE_TUNNEL=m
CONFIG_INET6_XFRM_MODE_BEET=m
# CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
CONFIG_IPV6_SIT=m
# CONFIG_IPV6_SIT_6RD is not set
CONFIG_IPV6_NDISC_NODETYPE=y
# CONFIG_IPV6_TUNNEL is not set
# CONFIG_IPV6_GRE is not set
# CONFIG_IPV6_MULTIPLE_TABLES is not set
# CONFIG_IPV6_MROUTE is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_NETFILTER_ADVANCED=y
#
# Core Netfilter Configuration
#
# CONFIG_NETFILTER_NETLINK_ACCT is not set
# CONFIG_NETFILTER_NETLINK_QUEUE is not set
# CONFIG_NETFILTER_NETLINK_LOG is not set
# CONFIG_NF_CONNTRACK is not set
# CONFIG_NETFILTER_XTABLES is not set
# CONFIG_IP_VS is not set
#
# IP: Netfilter Configuration
#
# CONFIG_NF_DEFRAG_IPV4 is not set
# CONFIG_IP_NF_IPTABLES is not set
# CONFIG_IP_NF_ARPTABLES is not set
#
# IPv6: Netfilter Configuration
#
# CONFIG_NF_DEFRAG_IPV6 is not set
# CONFIG_IP6_NF_IPTABLES is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_L2TP is not set
# CONFIG_BRIDGE is not set
CONFIG_HAVE_NET_DSA=y
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
# CONFIG_DCB is not set
# CONFIG_BATMAN_ADV is not set
# CONFIG_OPENVSWITCH is not set
# CONFIG_VSOCKETS is not set
# CONFIG_NETLINK_MMAP is not set
# CONFIG_NETLINK_DIAG is not set
# CONFIG_NETPRIO_CGROUP is not set
CONFIG_BQL=y
# CONFIG_BPF_JIT is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
CONFIG_WIRELESS=y
# CONFIG_CFG80211 is not set
# CONFIG_LIB80211 is not set
#
# CFG80211 needs to be enabled for MAC80211
#
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_RFKILL_REGULATOR is not set
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set
# CONFIG_NFC is not set
CONFIG_HAVE_BPF_JIT=y
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_FW_LOADER is not set
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_GENERIC_CPU_DEVICES is not set
CONFIG_REGMAP=y
CONFIG_REGMAP_I2C=m
# CONFIG_DMA_SHARED_BUFFER is not set
# CONFIG_CMA is not set
#
# Bus devices
#
# CONFIG_CONNECTOR is not set
# CONFIG_MTD is not set
CONFIG_DTC=y
CONFIG_OF=y
#
# Device Tree and Open Firmware support
#
# CONFIG_PROC_DEVICETREE is not set
# CONFIG_OF_SELFTEST is not set
CONFIG_OF_FLATTREE=y
CONFIG_OF_EARLY_FLATTREE=y
CONFIG_OF_ADDRESS=y
CONFIG_OF_IRQ=y
CONFIG_OF_DEVICE=y
CONFIG_OF_I2C=y
CONFIG_OF_NET=y
CONFIG_OF_MDIO=y
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_DRBD is not set
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=1
CONFIG_BLK_DEV_RAM_SIZE=32768
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_MG_DISK is not set
# CONFIG_BLK_DEV_RBD is not set
#
# Misc devices
#
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_AD525X_DPOT is not set
# CONFIG_ATMEL_PWM is not set
# CONFIG_DUMMY_IRQ is not set
# CONFIG_ICS932S401 is not set
# CONFIG_ATMEL_SSC is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_APDS9802ALS is not set
# CONFIG_ISL29003 is not set
# CONFIG_ISL29020 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_SENSORS_BH1780 is not set
# CONFIG_SENSORS_BH1770 is not set
# CONFIG_SENSORS_APDS990X is not set
# CONFIG_HMC6352 is not set
# CONFIG_DS1682 is not set
# CONFIG_BMP085_I2C is not set
# CONFIG_USB_SWITCH_FSA9480 is not set
# CONFIG_SRAM is not set
# CONFIG_C2PORT is not set
#
# EEPROM support
#
CONFIG_EEPROM_AT24=y
# CONFIG_EEPROM_LEGACY is not set
# CONFIG_EEPROM_MAX6875 is not set
# CONFIG_EEPROM_93CX6 is not set
#
# Texas Instruments shared transport line discipline
#
# CONFIG_TI_ST is not set
# CONFIG_SENSORS_LIS3_I2C is not set
#
# Altera FPGA firmware download module
#
# CONFIG_ALTERA_STAPL is not set
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set
#
# SCSI device support
#
CONFIG_SCSI_MOD=m
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=m
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
CONFIG_SCSI_PROC_FS=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
# CONFIG_CHR_DEV_SCH is not set
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set
#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
# CONFIG_ISCSI_BOOT_SYSFS is not set
# CONFIG_SCSI_UFSHCD is not set
# CONFIG_LIBFC is not set
# CONFIG_LIBFCOE is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
# CONFIG_ATA is not set
# CONFIG_MD is not set
# CONFIG_TARGET_CORE is not set
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
# CONFIG_BONDING is not set
# CONFIG_DUMMY is not set
# CONFIG_EQUALIZER is not set
CONFIG_MII=y
# CONFIG_NET_TEAM is not set
# CONFIG_MACVLAN is not set
# CONFIG_VXLAN is not set
CONFIG_NETCONSOLE=y
CONFIG_NETPOLL=y
CONFIG_NETPOLL_TRAP=y
CONFIG_NET_POLL_CONTROLLER=y
CONFIG_TUN=m
# CONFIG_VETH is not set
#
# CAIF transport drivers
#
#
# Distributed Switch Architecture drivers
#
# CONFIG_NET_DSA_MV88E6XXX is not set
# CONFIG_NET_DSA_MV88E6060 is not set
# CONFIG_NET_DSA_MV88E6XXX_NEED_PPU is not set
# CONFIG_NET_DSA_MV88E6131 is not set
# CONFIG_NET_DSA_MV88E6123_61_65 is not set
CONFIG_ETHERNET=y
CONFIG_NET_CADENCE=y
# CONFIG_ARM_AT91_ETHER is not set
# CONFIG_MACB is not set
CONFIG_NET_VENDOR_BROADCOM=y
# CONFIG_B44 is not set
# CONFIG_NET_CALXEDA_XGMAC is not set
CONFIG_NET_VENDOR_CIRRUS=y
# CONFIG_CS89x0 is not set
# CONFIG_DM9000 is not set
# CONFIG_DNET is not set
CONFIG_NET_VENDOR_FARADAY=y
# CONFIG_FTMAC100 is not set
# CONFIG_FTGMAC100 is not set
CONFIG_NET_VENDOR_INTEL=y
CONFIG_NET_VENDOR_I825XX=y
CONFIG_NET_VENDOR_MARVELL=y
# CONFIG_MVMDIO is not set
CONFIG_NET_VENDOR_MICREL=y
# CONFIG_KS8842 is not set
# CONFIG_KS8851_MLL is not set
CONFIG_NET_VENDOR_NATSEMI=y
CONFIG_NET_VENDOR_8390=y
# CONFIG_AX88796 is not set
# CONFIG_ETHOC is not set
CONFIG_NET_VENDOR_SEEQ=y
CONFIG_NET_VENDOR_SMSC=y
# CONFIG_SMC91X is not set
# CONFIG_SMC911X is not set
# CONFIG_SMSC911X is not set
CONFIG_NET_VENDOR_STMICRO=y
# CONFIG_STMMAC_ETH is not set
CONFIG_NET_VENDOR_TI=y
CONFIG_TI_DAVINCI_EMAC=y
CONFIG_TI_DAVINCI_MDIO=y
CONFIG_TI_DAVINCI_CPDMA=y
# CONFIG_TI_CPSW is not set
CONFIG_NET_VENDOR_WIZNET=y
# CONFIG_WIZNET_W5100 is not set
# CONFIG_WIZNET_W5300 is not set
CONFIG_PHYLIB=y
#
# MII PHY device drivers
#
# CONFIG_AT803X_PHY is not set
# CONFIG_AMD_PHY is not set
# CONFIG_MARVELL_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_QSEMI_PHY is not set
CONFIG_LXT_PHY=y
# CONFIG_CICADA_PHY is not set
# CONFIG_VITESSE_PHY is not set
# CONFIG_SMSC_PHY is not set
# CONFIG_BROADCOM_PHY is not set
# CONFIG_BCM87XX_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_REALTEK_PHY is not set
# CONFIG_NATIONAL_PHY is not set
# CONFIG_STE10XP is not set
CONFIG_LSI_ET1011C_PHY=y
# CONFIG_MICREL_PHY is not set
# CONFIG_FIXED_PHY is not set
# CONFIG_MDIO_BITBANG is not set
# CONFIG_MDIO_BUS_MUX_GPIO is not set
# CONFIG_MDIO_BUS_MUX_MMIOREG is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
CONFIG_WLAN=y
# CONFIG_HOSTAP is not set
# CONFIG_WL_TI is not set
#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
# CONFIG_WAN is not set
# CONFIG_ISDN is not set
#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
CONFIG_INPUT_POLLDEV=y
# CONFIG_INPUT_SPARSEKMAP is not set
# CONFIG_INPUT_MATRIXKMAP is not set
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=m
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=m
CONFIG_INPUT_EVBUG=m
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ADP5588 is not set
# CONFIG_KEYBOARD_ADP5589 is not set
CONFIG_KEYBOARD_ATKBD=m
# CONFIG_KEYBOARD_QT1070 is not set
# CONFIG_KEYBOARD_QT2160 is not set
# CONFIG_KEYBOARD_LKKBD is not set
CONFIG_KEYBOARD_GPIO=y
# CONFIG_KEYBOARD_TCA6416 is not set
# CONFIG_KEYBOARD_TCA8418 is not set
# CONFIG_KEYBOARD_MATRIX is not set
# CONFIG_KEYBOARD_LM8333 is not set
# CONFIG_KEYBOARD_MAX7359 is not set
# CONFIG_KEYBOARD_MCS is not set
# CONFIG_KEYBOARD_MPR121 is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_OPENCORES is not set
# CONFIG_KEYBOARD_SAMSUNG is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_KEYBOARD_SUNKBD is not set
CONFIG_KEYBOARD_XTKBD=m
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
CONFIG_INPUT_TOUCHSCREEN=y
# CONFIG_TOUCHSCREEN_AD7879 is not set
# CONFIG_TOUCHSCREEN_ATMEL_MXT is not set
# CONFIG_TOUCHSCREEN_AUO_PIXCIR is not set
# CONFIG_TOUCHSCREEN_BU21013 is not set
# CONFIG_TOUCHSCREEN_CY8CTMG110 is not set
# CONFIG_TOUCHSCREEN_CYTTSP_CORE is not set
# CONFIG_TOUCHSCREEN_DYNAPRO is not set
# CONFIG_TOUCHSCREEN_HAMPSHIRE is not set
# CONFIG_TOUCHSCREEN_EETI is not set
# CONFIG_TOUCHSCREEN_EGALAX is not set
# CONFIG_TOUCHSCREEN_FUJITSU is not set
# CONFIG_TOUCHSCREEN_ILI210X is not set
# CONFIG_TOUCHSCREEN_GUNZE is not set
# CONFIG_TOUCHSCREEN_ELO is not set
# CONFIG_TOUCHSCREEN_WACOM_W8001 is not set
# CONFIG_TOUCHSCREEN_WACOM_I2C is not set
# CONFIG_TOUCHSCREEN_MAX11801 is not set
# CONFIG_TOUCHSCREEN_MCS5000 is not set
# CONFIG_TOUCHSCREEN_MMS114 is not set
# CONFIG_TOUCHSCREEN_MTOUCH is not set
# CONFIG_TOUCHSCREEN_INEXIO is not set
# CONFIG_TOUCHSCREEN_MK712 is not set
# CONFIG_TOUCHSCREEN_PENMOUNT is not set
# CONFIG_TOUCHSCREEN_EDT_FT5X06 is not set
# CONFIG_TOUCHSCREEN_TOUCHRIGHT is not set
# CONFIG_TOUCHSCREEN_TOUCHWIN is not set
# CONFIG_TOUCHSCREEN_PIXCIR is not set
# CONFIG_TOUCHSCREEN_TOUCHIT213 is not set
# CONFIG_TOUCHSCREEN_TSC_SERIO is not set
# CONFIG_TOUCHSCREEN_TSC2007 is not set
# CONFIG_TOUCHSCREEN_W90X900 is not set
# CONFIG_TOUCHSCREEN_ST1232 is not set
# CONFIG_TOUCHSCREEN_TPS6507X is not set
# CONFIG_INPUT_MISC is not set
#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_SERPORT=y
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_SERIO_ALTERA_PS2 is not set
# CONFIG_SERIO_PS2MULT is not set
# CONFIG_SERIO_ARC_PS2 is not set
# CONFIG_SERIO_APBPS2 is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#
CONFIG_TTY=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
# CONFIG_VT_CONSOLE is not set
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_N_GSM is not set
# CONFIG_TRACE_SINK is not set
CONFIG_DEVKMEM=y
#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_DEPRECATED_OPTIONS=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_DMA=y
CONFIG_SERIAL_8250_NR_UARTS=3
CONFIG_SERIAL_8250_RUNTIME_UARTS=3
# CONFIG_SERIAL_8250_EXTENDED is not set
# CONFIG_SERIAL_8250_DW is not set
# CONFIG_SERIAL_8250_EM is not set
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_OF_PLATFORM=y
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_XILINX_PS_UART is not set
# CONFIG_SERIAL_ARC is not set
# CONFIG_TTY_PRINTK is not set
# CONFIG_HVC_DCC is not set
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=m
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
# CONFIG_HW_RANDOM_ATMEL is not set
# CONFIG_HW_RANDOM_EXYNOS is not set
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
CONFIG_I2C_CHARDEV=y
# CONFIG_I2C_MUX is not set
CONFIG_I2C_HELPER_AUTO=y
#
# I2C Hardware Bus support
#
#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_CBUS_GPIO is not set
CONFIG_I2C_DAVINCI=y
# CONFIG_I2C_DESIGNWARE_PLATFORM is not set
# CONFIG_I2C_GPIO is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_PXA_PCI is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_XILINX is not set
#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set
#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_SPI is not set
#
# Qualcomm MSM SSBI bus support
#
# CONFIG_SSBI is not set
# CONFIG_HSI is not set
#
# PPS support
#
# CONFIG_PPS is not set
#
# PPS generators support
#
#
# PTP clock support
#
# CONFIG_PTP_1588_CLOCK is not set
#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
# CONFIG_PTP_1588_CLOCK_PCH is not set
CONFIG_PINCTRL=y
#
# Pin controllers
#
CONFIG_PINMUX=y
CONFIG_PINCONF=y
CONFIG_GENERIC_PINCONF=y
# CONFIG_DEBUG_PINCTRL is not set
CONFIG_PINCTRL_SINGLE=y
# CONFIG_PINCTRL_EXYNOS is not set
# CONFIG_PINCTRL_EXYNOS5440 is not set
CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y
CONFIG_ARCH_REQUIRE_GPIOLIB=y
CONFIG_GPIO_DEVRES=y
CONFIG_GPIOLIB=y
CONFIG_OF_GPIO=y
# CONFIG_DEBUG_GPIO is not set
# CONFIG_GPIO_SYSFS is not set
#
# Memory mapped GPIO drivers:
#
# CONFIG_GPIO_GENERIC_PLATFORM is not set
# CONFIG_GPIO_EM is not set
# CONFIG_GPIO_RCAR is not set
# CONFIG_GPIO_TS5500 is not set
# CONFIG_GPIO_GRGPIO is not set
#
# I2C GPIO expanders:
#
# CONFIG_GPIO_MAX7300 is not set
# CONFIG_GPIO_MAX732X is not set
# CONFIG_GPIO_PCA953X_IRQ is not set
CONFIG_GPIO_PCF857X=y
# CONFIG_GPIO_SX150X is not set
# CONFIG_GPIO_ADP5588 is not set
# CONFIG_GPIO_ADNP is not set
#
# PCI GPIO expanders:
#
#
# SPI GPIO expanders:
#
# CONFIG_GPIO_MCP23S08 is not set
#
# AC97 GPIO expanders:
#
#
# MODULbus GPIO expanders:
#
#
# USB GPIO expanders:
#
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
# CONFIG_POWER_AVS is not set
# CONFIG_HWMON is not set
# CONFIG_THERMAL is not set
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_CORE is not set
# CONFIG_WATCHDOG_NOWAYOUT is not set
#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
# CONFIG_DW_WATCHDOG is not set
# CONFIG_DAVINCI_WATCHDOG is not set
# CONFIG_MAX63XX_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y
#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y
#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set
#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_AS3711 is not set
# CONFIG_PMIC_ADP5520 is not set
# CONFIG_MFD_AAT2870_CORE is not set
# CONFIG_MFD_CROS_EC is not set
# CONFIG_MFD_ASIC3 is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_MFD_DA9052_I2C is not set
# CONFIG_MFD_DA9055 is not set
# CONFIG_MFD_MC13XXX_I2C is not set
# CONFIG_HTC_EGPIO is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_HTC_I2CPLD is not set
# CONFIG_MFD_88PM800 is not set
# CONFIG_MFD_88PM805 is not set
# CONFIG_MFD_88PM860X is not set
# CONFIG_MFD_MAX77686 is not set
# CONFIG_MFD_MAX77693 is not set
# CONFIG_MFD_MAX8907 is not set
# CONFIG_MFD_MAX8925 is not set
# CONFIG_MFD_MAX8997 is not set
# CONFIG_MFD_MAX8998 is not set
# CONFIG_MFD_RETU is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_MFD_RC5T583 is not set
# CONFIG_MFD_SEC_CORE is not set
# CONFIG_MFD_SI476X_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_MFD_SMSC is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_MFD_STMPE is not set
# CONFIG_MFD_SYSCON is not set
# CONFIG_MFD_TI_AM335X_TSCADC is not set
# CONFIG_MFD_LP8788 is not set
# CONFIG_MFD_PALMAS is not set
# CONFIG_TPS6105X is not set
# CONFIG_TPS65010 is not set
# CONFIG_TPS6507X is not set
# CONFIG_MFD_TPS65090 is not set
# CONFIG_MFD_TPS65217 is not set
# CONFIG_MFD_TPS6586X is not set
# CONFIG_MFD_TPS65910 is not set
# CONFIG_MFD_TPS65912 is not set
# CONFIG_MFD_TPS65912_I2C is not set
# CONFIG_MFD_TPS80031 is not set
# CONFIG_TWL4030_CORE is not set
# CONFIG_TWL6040_CORE is not set
# CONFIG_MFD_WL1273_CORE is not set
# CONFIG_MFD_LM3533 is not set
# CONFIG_MFD_TC3589X is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_T7L66XB is not set
# CONFIG_MFD_TC6387XB is not set
# CONFIG_MFD_TC6393XB is not set
# CONFIG_MFD_ARIZONA_I2C is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM831X_I2C is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_WM8994 is not set
CONFIG_REGULATOR=y
# CONFIG_REGULATOR_DEBUG is not set
CONFIG_REGULATOR_DUMMY=y
# CONFIG_REGULATOR_FIXED_VOLTAGE is not set
# CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set
# CONFIG_REGULATOR_USERSPACE_CONSUMER is not set
# CONFIG_REGULATOR_GPIO is not set
# CONFIG_REGULATOR_AD5398 is not set
# CONFIG_REGULATOR_FAN53555 is not set
# CONFIG_REGULATOR_ISL6271A is not set
# CONFIG_REGULATOR_MAX1586 is not set
# CONFIG_REGULATOR_MAX8649 is not set
# CONFIG_REGULATOR_MAX8660 is not set
# CONFIG_REGULATOR_MAX8952 is not set
# CONFIG_REGULATOR_MAX8973 is not set
# CONFIG_REGULATOR_LP3971 is not set
# CONFIG_REGULATOR_LP3972 is not set
# CONFIG_REGULATOR_LP872X is not set
# CONFIG_REGULATOR_LP8755 is not set
# CONFIG_REGULATOR_TPS51632 is not set
# CONFIG_REGULATOR_TPS62360 is not set
# CONFIG_REGULATOR_TPS65023 is not set
CONFIG_REGULATOR_TPS6507X=y
# CONFIG_MEDIA_SUPPORT is not set
#
# Graphics support
#
# CONFIG_DRM is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
# CONFIG_FB_DDC is not set
# CONFIG_FB_BOOT_VESA_SUPPORT is not set
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
CONFIG_FB_CFB_REV_PIXELS_IN_BYTE=y
# CONFIG_FB_SYS_FILLRECT is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_FOREIGN_ENDIAN is not set
# CONFIG_FB_SYS_FOPS is not set
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
# CONFIG_FB_MODE_HELPERS is not set
# CONFIG_FB_TILEBLITTING is not set
#
# Frame buffer hardware drivers
#
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_GOLDFISH is not set
CONFIG_FB_DA8XX=y
# CONFIG_FB_VIRTUAL is not set
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_BROADSHEET is not set
# CONFIG_FB_AUO_K190X is not set
# CONFIG_FB_SIMPLE is not set
# CONFIG_EXYNOS_VIDEO is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
#
# Console display driver support
#
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
CONFIG_LOGO_LINUX_VGA16=y
CONFIG_LOGO_LINUX_CLUT224=y
# CONFIG_FB_SSD1307 is not set
CONFIG_SOUND=m
# CONFIG_SOUND_OSS_CORE is not set
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_COMPRESS_OFFLOAD=m
CONFIG_SND_JACK=y
# CONFIG_SND_SEQUENCER is not set
# CONFIG_SND_MIXER_OSS is not set
# CONFIG_SND_PCM_OSS is not set
# CONFIG_SND_HRTIMER is not set
# CONFIG_SND_DYNAMIC_MINORS is not set
CONFIG_SND_SUPPORT_OLD_API=y
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
# CONFIG_SND_RAWMIDI_SEQ is not set
# CONFIG_SND_OPL3_LIB_SEQ is not set
# CONFIG_SND_OPL4_LIB_SEQ is not set
# CONFIG_SND_SBAWE_SEQ is not set
# CONFIG_SND_EMU10K1_SEQ is not set
CONFIG_SND_DRIVERS=y
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_ALOOP is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set
CONFIG_SND_ARM=y
CONFIG_SND_SOC=m
# CONFIG_SND_ATMEL_SOC is not set
CONFIG_SND_DAVINCI_SOC=m
# CONFIG_SND_DA830_SOC_EVM is not set
# CONFIG_SND_DA850_SOC_EVM is not set
# CONFIG_SND_DESIGNWARE_I2S is not set
CONFIG_SND_SOC_I2C_AND_SPI=m
# CONFIG_SND_SOC_ALL_CODECS is not set
# CONFIG_SND_SIMPLE_CARD is not set
# CONFIG_SOUND_PRIME is not set
#
# HID support
#
CONFIG_HID=y
# CONFIG_HIDRAW is not set
# CONFIG_UHID is not set
CONFIG_HID_GENERIC=y
#
# Special HID drivers
#
# CONFIG_HID_A4TECH is not set
# CONFIG_HID_ACRUX is not set
# CONFIG_HID_APPLE is not set
# CONFIG_HID_AUREAL is not set
# CONFIG_HID_BELKIN is not set
# CONFIG_HID_CHERRY is not set
# CONFIG_HID_CHICONY is not set
# CONFIG_HID_PRODIKEYS is not set
# CONFIG_HID_CYPRESS is not set
# CONFIG_HID_DRAGONRISE is not set
# CONFIG_HID_EMS_FF is not set
# CONFIG_HID_ELECOM is not set
# CONFIG_HID_EZKEY is not set
# CONFIG_HID_KEYTOUCH is not set
# CONFIG_HID_KYE is not set
# CONFIG_HID_UCLOGIC is not set
# CONFIG_HID_WALTOP is not set
# CONFIG_HID_GYRATION is not set
# CONFIG_HID_ICADE is not set
# CONFIG_HID_TWINHAN is not set
# CONFIG_HID_KENSINGTON is not set
# CONFIG_HID_LCPOWER is not set
# CONFIG_HID_LOGITECH is not set
# CONFIG_HID_MAGICMOUSE is not set
# CONFIG_HID_MICROSOFT is not set
# CONFIG_HID_MONTEREY is not set
# CONFIG_HID_MULTITOUCH is not set
# CONFIG_HID_ORTEK is not set
# CONFIG_HID_PANTHERLORD is not set
# CONFIG_HID_PETALYNX is not set
# CONFIG_HID_PICOLCD is not set
# CONFIG_HID_PRIMAX is not set
# CONFIG_HID_PS3REMOTE is not set
# CONFIG_HID_SAITEK is not set
# CONFIG_HID_SAMSUNG is not set
# CONFIG_HID_SPEEDLINK is not set
# CONFIG_HID_STEELSERIES is not set
# CONFIG_HID_SUNPLUS is not set
# CONFIG_HID_GREENASIA is not set
# CONFIG_HID_SMARTJOYPLUS is not set
# CONFIG_HID_TIVO is not set
# CONFIG_HID_TOPSEED is not set
# CONFIG_HID_THRUSTMASTER is not set
# CONFIG_HID_ZEROPLUS is not set
# CONFIG_HID_ZYDACRON is not set
# CONFIG_HID_SENSOR_HUB is not set
#
# I2C HID support
#
# CONFIG_I2C_HID is not set
CONFIG_USB_ARCH_HAS_OHCI=y
# CONFIG_USB_ARCH_HAS_EHCI is not set
# CONFIG_USB_ARCH_HAS_XHCI is not set
# CONFIG_USB_SUPPORT is not set
CONFIG_MMC=y
# CONFIG_MMC_DEBUG is not set
# CONFIG_MMC_UNSAFE_RESUME is not set
# CONFIG_MMC_CLKGATE is not set
#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_MINORS=8
CONFIG_MMC_BLOCK_BOUNCE=y
# CONFIG_SDIO_UART is not set
# CONFIG_MMC_TEST is not set
#
# MMC/SD/SDIO Host Controller Drivers
#
# CONFIG_MMC_SDHCI is not set
# CONFIG_MMC_SDHCI_PXAV3 is not set
# CONFIG_MMC_SDHCI_PXAV2 is not set
CONFIG_MMC_DAVINCI=y
# CONFIG_MMC_DW is not set
# CONFIG_MEMSTICK is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=y
# CONFIG_RTC_CLASS is not set
CONFIG_DMADEVICES=y
# CONFIG_DMADEVICES_DEBUG is not set
#
# DMA Devices
#
# CONFIG_DW_DMAC is not set
# CONFIG_TIMB_DMA is not set
CONFIG_TI_EDMA=y
CONFIG_DMA_ENGINE=y
CONFIG_DMA_VIRTUAL_CHANNELS=y
CONFIG_DMA_OF=y
#
# DMA Clients
#
# CONFIG_NET_DMA is not set
# CONFIG_ASYNC_TX_DMA is not set
# CONFIG_DMATEST is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
# CONFIG_VIRT_DRIVERS is not set
#
# Virtio drivers
#
# CONFIG_VIRTIO_MMIO is not set
#
# Microsoft Hyper-V guest support
#
# CONFIG_STAGING is not set
CONFIG_CLKDEV_LOOKUP=y
#
# Hardware Spinlock drivers
#
# CONFIG_MAILBOX is not set
CONFIG_IOMMU_SUPPORT=y
CONFIG_OF_IOMMU=y
#
# Remoteproc drivers
#
# CONFIG_STE_MODEM_RPROC is not set
# CONFIG_DA8XX_REMOTEPROC is not set
#
# Rpmsg drivers
#
# CONFIG_PM_DEVFREQ is not set
# CONFIG_EXTCON is not set
# CONFIG_MEMORY is not set
# CONFIG_IIO is not set
# CONFIG_PWM is not set
CONFIG_IRQCHIP=y
# CONFIG_IPACK_BUS is not set
# CONFIG_RESET_CONTROLLER is not set
#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
# CONFIG_EXT3_FS_SECURITY is not set
# CONFIG_EXT4_FS is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_XFS_FS=m
# CONFIG_XFS_QUOTA is not set
# CONFIG_XFS_POSIX_ACL is not set
# CONFIG_XFS_RT is not set
# CONFIG_XFS_WARN is not set
# CONFIG_XFS_DEBUG is not set
# CONFIG_GFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
# CONFIG_FS_POSIX_ACL is not set
CONFIG_EXPORTFS=m
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
# CONFIG_QUOTA is not set
# CONFIG_QUOTACTL is not set
CONFIG_AUTOFS4_FS=m
# CONFIG_FUSE_FS is not set
#
# Caches
#
# CONFIG_FSCACHE is not set
#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_CONFIGFS_FS is not set
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_LOGFS is not set
CONFIG_CRAMFS=y
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
CONFIG_MINIX_FS=m
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX6FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_PSTORE is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_F2FS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V2=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_SWAP is not set
CONFIG_ROOT_NFS=y
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V3_ACL is not set
# CONFIG_NFSD_V4 is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_SUNRPC_DEBUG is not set
# CONFIG_CEPH_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=m
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_MAC_ROMAN is not set
# CONFIG_NLS_MAC_CELTIC is not set
# CONFIG_NLS_MAC_CENTEURO is not set
# CONFIG_NLS_MAC_CROATIAN is not set
# CONFIG_NLS_MAC_CYRILLIC is not set
# CONFIG_NLS_MAC_GAELIC is not set
# CONFIG_NLS_MAC_GREEK is not set
# CONFIG_NLS_MAC_ICELAND is not set
# CONFIG_NLS_MAC_INUIT is not set
# CONFIG_NLS_MAC_ROMANIAN is not set
# CONFIG_NLS_MAC_TURKISH is not set
CONFIG_NLS_UTF8=m
#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_READABLE_ASM is not set
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
# CONFIG_IPIPE_DEBUG is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
# CONFIG_LOCKUP_DETECTOR is not set
# CONFIG_PANIC_ON_OOPS is not set
CONFIG_PANIC_ON_OOPS_VALUE=0
# CONFIG_DETECT_HUNG_TASK is not set
CONFIG_SCHED_DEBUG=y
# CONFIG_SCHEDSTATS is not set
CONFIG_TIMER_STATS=y
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
CONFIG_HAVE_DEBUG_KMEMLEAK=y
# CONFIG_DEBUG_KMEMLEAK is not set
CONFIG_DEBUG_PREEMPT=y
CONFIG_DEBUG_RT_MUTEXES=y
CONFIG_DEBUG_PI_LIST=y
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
CONFIG_DEBUG_MUTEXES=y
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_ATOMIC_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_WRITECOUNT is not set
# CONFIG_DEBUG_MEMORY_INIT is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
# CONFIG_BOOT_PRINTK_DELAY is not set
#
# RCU Debugging
#
# CONFIG_PROVE_RCU_DELAY is not set
# CONFIG_SPARSE_RCU_POINTER is not set
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_RCU_CPU_STALL_TIMEOUT=21
CONFIG_RCU_CPU_STALL_VERBOSE=y
# CONFIG_RCU_CPU_STALL_INFO is not set
# CONFIG_RCU_TRACE is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_LKDTM is not set
# CONFIG_NOTIFIER_ERROR_INJECTION is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_LATENCYTOP is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
# CONFIG_FUNCTION_TRACER is not set
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_PREEMPT_TRACER is not set
# CONFIG_SCHED_TRACER is not set
# CONFIG_ENABLE_DEFAULT_TRACERS is not set
# CONFIG_FTRACE_SYSCALLS is not set
# CONFIG_TRACER_SNAPSHOT is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
# CONFIG_STACK_TRACER is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_PROBE_EVENTS is not set
# CONFIG_RBTREE_TEST is not set
# CONFIG_INTERVAL_TREE_TEST is not set
# CONFIG_DYNAMIC_DEBUG is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_ATOMIC64_SELFTEST is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
# CONFIG_TEST_STRING_HELPERS is not set
# CONFIG_TEST_KSTRTOX is not set
# CONFIG_STRICT_DEVMEM is not set
CONFIG_ARM_UNWIND=y
CONFIG_DEBUG_USER=y
# CONFIG_DEBUG_LL is not set
CONFIG_DEBUG_LL_INCLUDE="mach/debug-macro.S"
CONFIG_UNCOMPRESS_INCLUDE="mach/uncompress.h"
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_CRYPTO=y
#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_HASH=m
CONFIG_CRYPTO_HASH2=m
# CONFIG_CRYPTO_MANAGER is not set
# CONFIG_CRYPTO_MANAGER2 is not set
# CONFIG_CRYPTO_USER is not set
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_AUTHENC is not set
# CONFIG_CRYPTO_TEST is not set
#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set
#
# Block modes
#
# CONFIG_CRYPTO_CBC is not set
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
# CONFIG_CRYPTO_ECB is not set
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set
#
# Hash modes
#
# CONFIG_CRYPTO_CMAC is not set
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set
#
# Digest
#
CONFIG_CRYPTO_CRC32C=m
# CONFIG_CRYPTO_CRC32 is not set
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_MD4 is not set
# CONFIG_CRYPTO_MD5 is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA1_ARM is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set
#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_ARM is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set
#
# Compression
#
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_ZLIB is not set
# CONFIG_CRYPTO_LZO is not set
#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
# CONFIG_CRYPTO_USER_API_HASH is not set
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
# CONFIG_CRYPTO_HW is not set
# CONFIG_BINARY_PRINTF is not set
#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IO=y
CONFIG_CRC_CCITT=m
# CONFIG_CRC16 is not set
CONFIG_CRC_T10DIF=m
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=m
# CONFIG_CRC8 is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
# CONFIG_XZ_DEC is not set
# CONFIG_XZ_DEC_BCJ is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_GENERIC_ALLOCATOR=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_DQL=y
CONFIG_NLATTR=y
CONFIG_GENERIC_ATOMIC64=y
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
# CONFIG_AVERAGE is not set
# CONFIG_CORDIC is not set
# CONFIG_DDR is not set
# CONFIG_VIRTUALIZATION is not set
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-10 22:23 ` Gilles Chanteperdrix
2014-04-10 22:27 ` Peter Howard
@ 2014-04-10 22:34 ` Peter Howard
2014-04-10 22:48 ` Gilles Chanteperdrix
2014-04-10 23:01 ` Peter Howard
2 siblings, 1 reply; 57+ messages in thread
From: Peter Howard @ 2014-04-10 22:34 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On Fri, 2014-04-11 at 00:23 +0200, Gilles Chanteperdrix wrote:
(Stripping back conversation on this one - apologies if that's bad
etiquette for this list)
> Attachment is better. Also please post the changes you made for omapL138
>
diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index a075b3e..3d8bc59 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -41,6 +41,8 @@ config ARCH_DAVINCI_DA850
select ARCH_DAVINCI_DA8XX
select ARCH_HAS_CPUFREQ
select CP_INTC
+ select IPIPE_ARM_KUSER_TSC if IPIPE
+ select ARM_FCSE if IPIPE
config ARCH_DAVINCI_DA8XX
bool
diff --git a/arch/arm/mach-davinci/cp_intc.c b/arch/arm/mach-davinci/cp_intc.c
index 006dae8..61fa26f 100644
--- a/arch/arm/mach-davinci/cp_intc.c
+++ b/arch/arm/mach-davinci/cp_intc.c
@@ -17,6 +17,7 @@
#include <linux/of.h>
#include <linux/of_address.h>
#include <linux/of_irq.h>
+#include <linux/ipipe.h>
#include <mach/common.h>
#include <mach/cp_intc.h>
@@ -39,6 +40,7 @@ static void cp_intc_ack_irq(struct irq_data *d)
/* Disable interrupt */
static void cp_intc_mask_irq(struct irq_data *d)
{
+ ipipe_lock_irq(d->irq);
/* XXX don't know why we need to disable nIRQ here... */
cp_intc_write(1, CP_INTC_HOST_ENABLE_IDX_CLR);
cp_intc_write(d->hwirq, CP_INTC_SYS_ENABLE_IDX_CLR);
@@ -49,8 +51,25 @@ static void cp_intc_mask_irq(struct irq_data *d)
static void cp_intc_unmask_irq(struct irq_data *d)
{
cp_intc_write(d->hwirq, CP_INTC_SYS_ENABLE_IDX_SET);
+ ipipe_unlock_irq(d->irq);
}
+#ifdef CONFIG_IPIPE
+/* Hold and release without irq locking */
+static void cp_intc_hold_irq(struct irq_data *d)
+{
+ /* XXX don't know why we need to disable nIRQ here... */
+ cp_intc_write(1, CP_INTC_HOST_ENABLE_IDX_CLR);
+ cp_intc_write(d->hwirq, CP_INTC_SYS_ENABLE_IDX_CLR);
+ cp_intc_write(1, CP_INTC_HOST_ENABLE_IDX_SET);
+}
+
+static void cp_intc_release_irq(struct irq_data *d)
+{
+ cp_intc_write(d->hwirq, CP_INTC_SYS_ENABLE_IDX_SET);
+}
+#endif /* CONFIG_IPIPE */
+
static int cp_intc_set_irq_type(struct irq_data *d, unsigned int flow_type)
{
unsigned reg = BIT_WORD(d->hwirq);
@@ -100,6 +119,12 @@ static struct irq_chip cp_intc_irq_chip = {
.irq_ack = cp_intc_ack_irq,
.irq_mask = cp_intc_mask_irq,
.irq_unmask = cp_intc_unmask_irq,
+#ifdef CONFIG_IPIPE
+ .irq_disable = cp_intc_hold_irq,
+ .irq_enable = cp_intc_release_irq,
+ .irq_hold = cp_intc_hold_irq,
+ .irq_release = cp_intc_release_irq,
+#endif /* CONFIG_IPIPE */
.irq_set_type = cp_intc_set_irq_type,
.irq_set_wake = cp_intc_set_wake,
};
diff --git a/arch/arm/mach-davinci/time.c b/arch/arm/mach-davinci/time.c
index bad361e..2b39ba5 100644
--- a/arch/arm/mach-davinci/time.c
+++ b/arch/arm/mach-davinci/time.c
@@ -18,6 +18,10 @@
#include <linux/clk.h>
#include <linux/err.h>
#include <linux/platform_device.h>
+#ifdef CONFIG_IPIPE
+#include <linux/ipipe.h>
+#include <linux/ipipe_tickdev.h>
+#endif /* CONFIG_IPIPE */
#include <asm/sched_clock.h>
#include <asm/mach/irq.h>
@@ -94,9 +98,15 @@ struct timer_s {
unsigned long opts;
unsigned long flags;
void __iomem *base;
+#ifdef CONFIG_IPIPE
+ void *pbase;
+#endif /*CONFIG_IPIPE */
unsigned long tim_off;
unsigned long prd_off;
unsigned long enamode_shift;
+#ifdef CONFIG_IPIPE
+ int irq;
+#endif /* CONFIG_IPIPE */
struct irqaction irqaction;
};
static struct timer_s timers[];
@@ -166,6 +176,9 @@ static irqreturn_t timer_interrupt(int irq, void *dev_id)
{
struct clock_event_device *evt = &clockevent_davinci;
+#ifdef CONFIG_IPIPE
+ __ipipe_tsc_update();
+#endif /* CONFIG_IPIPE */
evt->event_handler(evt);
return IRQ_HANDLED;
}
@@ -241,6 +254,9 @@ static void __init timer_init(void)
t->base = base[timer];
if (!t->base)
continue;
+#ifdef CONFIG_IPIPE
+ t->pbase = (void *)dtip[timer].base;
+#endif /* CONFIG_IPIPE */
if (IS_TIMER_BOT(t->id)) {
t->enamode_shift = 6;
@@ -262,6 +278,9 @@ static void __init timer_init(void)
irq = USING_COMPARE(t) ? dtip[i].cmp_irq : irq;
setup_irq(irq, &t->irqaction);
}
+#ifdef CONFIG_IPIPE
+ t->irq = irq;
+#endif /* CONFIG_IPIPE */
}
}
@@ -329,11 +348,27 @@ static void davinci_set_mode(enum clock_event_mode mode,
}
}
+#ifdef CONFIG_IPIPE
+static struct ipipe_timer davinci_itimer;
+
+static struct __ipipe_tscinfo tsc_info = {
+ .type = IPIPE_TSC_TYPE_FREERUNNING,
+ .u = {
+ {
+ .mask = 0xffffffff,
+ },
+ },
+};
+#endif /* CONFIG_IPIPE */
+
static struct clock_event_device clockevent_davinci = {
.features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
.shift = 32,
.set_next_event = davinci_set_next_event,
.set_mode = davinci_set_mode,
+#ifdef CONFIG_IPIPE
+ .ipipe_timer = &davinci_itimer,
+#endif /* CONFIG_IPIPE */
};
@@ -404,6 +439,17 @@ void __init davinci_timer_init(void)
clockevent_davinci.min_delta_ns = 50000; /* 50 usec */
clockevent_davinci.cpumask = cpumask_of(0);
+#ifdef CONFIG_IPIPE
+ tsc_info.freq = davinci_clock_tick_rate;
+ tsc_info.counter_vaddr = (void *)(timers[TID_CLOCKSOURCE].base +
+ timers[TID_CLOCKSOURCE].tim_off);
+ tsc_info.u.counter_paddr = timers[TID_CLOCKSOURCE].pbase +
+ timers[TID_CLOCKSOURCE].tim_off;
+ __ipipe_tsc_register(&tsc_info);
+
+ davinci_itimer.irq = timers[TID_CLOCKEVENT].irq;
+ davinci_itimer.min_delay_ticks = 3;
+#endif /* CONFIG_IPIPE */
clockevents_register_device(&clockevent_davinci);
for (i=0; i< ARRAY_SIZE(timers); i++)
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 17df6db..0426ab2 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -15,6 +15,7 @@
#include <linux/clk.h>
#include <linux/err.h>
#include <linux/io.h>
+#include <linux/ipipe.h>
#include <asm/mach/irq.h>
@@ -282,7 +283,11 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc)
while (status) {
res = ffs(status);
n += res;
+#ifdef CONFIG_IPIPE
+ ipipe_handle_demuxed_irq(n - 1);
+#else
generic_handle_irq(n - 1);
+#endif /* CONFIG_IPIPE */
status >>= res;
}
}
--
Peter Howard <pjh@northern-ridge.com.au>
^ permalink raw reply related [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-10 22:34 ` Peter Howard
@ 2014-04-10 22:48 ` Gilles Chanteperdrix
2014-04-10 22:52 ` Peter Howard
0 siblings, 1 reply; 57+ messages in thread
From: Gilles Chanteperdrix @ 2014-04-10 22:48 UTC (permalink / raw)
To: Peter Howard; +Cc: xenomai
On 04/11/2014 12:34 AM, Peter Howard wrote:
> On Fri, 2014-04-11 at 00:23 +0200, Gilles Chanteperdrix wrote:
> (Stripping back conversation on this one - apologies if that's bad
> etiquette for this list)
>
>> Attachment is better. Also please post the changes you made for omapL138
>>
>
> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
> index a075b3e..3d8bc59 100644
> --- a/arch/arm/mach-davinci/Kconfig
> +++ b/arch/arm/mach-davinci/Kconfig
> @@ -41,6 +41,8 @@ config ARCH_DAVINCI_DA850
> select ARCH_DAVINCI_DA8XX
> select ARCH_HAS_CPUFREQ
> select CP_INTC
> + select IPIPE_ARM_KUSER_TSC if IPIPE
> + select ARM_FCSE if IPIPE
You may want to leave the choice of enabling or disabling FCSE to the user.
>
> config ARCH_DAVINCI_DA8XX
> bool
> diff --git a/arch/arm/mach-davinci/cp_intc.c b/arch/arm/mach-davinci/cp_intc.c
> index 006dae8..61fa26f 100644
> --- a/arch/arm/mach-davinci/cp_intc.c
> +++ b/arch/arm/mach-davinci/cp_intc.c
> @@ -17,6 +17,7 @@
> #include <linux/of.h>
> #include <linux/of_address.h>
> #include <linux/of_irq.h>
> +#include <linux/ipipe.h>
>
> #include <mach/common.h>
> #include <mach/cp_intc.h>
> @@ -39,6 +40,7 @@ static void cp_intc_ack_irq(struct irq_data *d)
> /* Disable interrupt */
> static void cp_intc_mask_irq(struct irq_data *d)
> {
> + ipipe_lock_irq(d->irq);
> /* XXX don't know why we need to disable nIRQ here... */
> cp_intc_write(1, CP_INTC_HOST_ENABLE_IDX_CLR);
> cp_intc_write(d->hwirq, CP_INTC_SYS_ENABLE_IDX_CLR);
> @@ -49,8 +51,25 @@ static void cp_intc_mask_irq(struct irq_data *d)
> static void cp_intc_unmask_irq(struct irq_data *d)
> {
> cp_intc_write(d->hwirq, CP_INTC_SYS_ENABLE_IDX_SET);
> + ipipe_unlock_irq(d->irq);
> }
>
> +#ifdef CONFIG_IPIPE
> +/* Hold and release without irq locking */
> +static void cp_intc_hold_irq(struct irq_data *d)
> +{
> + /* XXX don't know why we need to disable nIRQ here... */
> + cp_intc_write(1, CP_INTC_HOST_ENABLE_IDX_CLR);
> + cp_intc_write(d->hwirq, CP_INTC_SYS_ENABLE_IDX_CLR);
> + cp_intc_write(1, CP_INTC_HOST_ENABLE_IDX_SET);
> +}
> +
> +static void cp_intc_release_irq(struct irq_data *d)
> +{
> + cp_intc_write(d->hwirq, CP_INTC_SYS_ENABLE_IDX_SET);
> +}
> +#endif /* CONFIG_IPIPE */
> +
> static int cp_intc_set_irq_type(struct irq_data *d, unsigned int flow_type)
> {
> unsigned reg = BIT_WORD(d->hwirq);
> @@ -100,6 +119,12 @@ static struct irq_chip cp_intc_irq_chip = {
> .irq_ack = cp_intc_ack_irq,
> .irq_mask = cp_intc_mask_irq,
> .irq_unmask = cp_intc_unmask_irq,
> +#ifdef CONFIG_IPIPE
> + .irq_disable = cp_intc_hold_irq,
> + .irq_enable = cp_intc_release_irq,
> + .irq_hold = cp_intc_hold_irq,
> + .irq_release = cp_intc_release_irq,
> +#endif /* CONFIG_IPIPE */
> .irq_set_type = cp_intc_set_irq_type,
> .irq_set_wake = cp_intc_set_wake,
> };
The hold/release stuff should be only be needed for fasteoi irq, not for
edge irqs.
Other than that, the patch looks pretty straightforward.
--
Gilles.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-10 22:48 ` Gilles Chanteperdrix
@ 2014-04-10 22:52 ` Peter Howard
2014-04-10 22:55 ` Gilles Chanteperdrix
2014-04-15 6:03 ` Peter Howard
0 siblings, 2 replies; 57+ messages in thread
From: Peter Howard @ 2014-04-10 22:52 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On Fri, 2014-04-11 at 00:48 +0200, Gilles Chanteperdrix wrote:
> On 04/11/2014 12:34 AM, Peter Howard wrote:
> > On Fri, 2014-04-11 at 00:23 +0200, Gilles Chanteperdrix wrote:
> > (Stripping back conversation on this one - apologies if that's bad
> > etiquette for this list)
> >
> >> Attachment is better. Also please post the changes you made for omapL138
> >>
> >
> > diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
> > index a075b3e..3d8bc59 100644
> > --- a/arch/arm/mach-davinci/Kconfig
> > +++ b/arch/arm/mach-davinci/Kconfig
> > @@ -41,6 +41,8 @@ config ARCH_DAVINCI_DA850
> > select ARCH_DAVINCI_DA8XX
> > select ARCH_HAS_CPUFREQ
> > select CP_INTC
> > + select IPIPE_ARM_KUSER_TSC if IPIPE
> > + select ARM_FCSE if IPIPE
>
> You may want to leave the choice of enabling or disabling FCSE to the user.
>
Understood; at the moment the variance on max latency is really bad if
you don't enable FCSE. When I sort out the crashing issues I'll re-test
with it off.
> >
> > config ARCH_DAVINCI_DA8XX
> > bool
> > diff --git a/arch/arm/mach-davinci/cp_intc.c b/arch/arm/mach-davinci/cp_intc.c
> > index 006dae8..61fa26f 100644
> > --- a/arch/arm/mach-davinci/cp_intc.c
> > +++ b/arch/arm/mach-davinci/cp_intc.c
> > @@ -17,6 +17,7 @@
> > #include <linux/of.h>
> > #include <linux/of_address.h>
> > #include <linux/of_irq.h>
> > +#include <linux/ipipe.h>
> >
> > #include <mach/common.h>
> > #include <mach/cp_intc.h>
> > @@ -39,6 +40,7 @@ static void cp_intc_ack_irq(struct irq_data *d)
> > /* Disable interrupt */
> > static void cp_intc_mask_irq(struct irq_data *d)
> > {
> > + ipipe_lock_irq(d->irq);
> > /* XXX don't know why we need to disable nIRQ here... */
> > cp_intc_write(1, CP_INTC_HOST_ENABLE_IDX_CLR);
> > cp_intc_write(d->hwirq, CP_INTC_SYS_ENABLE_IDX_CLR);
> > @@ -49,8 +51,25 @@ static void cp_intc_mask_irq(struct irq_data *d)
> > static void cp_intc_unmask_irq(struct irq_data *d)
> > {
> > cp_intc_write(d->hwirq, CP_INTC_SYS_ENABLE_IDX_SET);
> > + ipipe_unlock_irq(d->irq);
> > }
> >
> > +#ifdef CONFIG_IPIPE
> > +/* Hold and release without irq locking */
> > +static void cp_intc_hold_irq(struct irq_data *d)
> > +{
> > + /* XXX don't know why we need to disable nIRQ here... */
> > + cp_intc_write(1, CP_INTC_HOST_ENABLE_IDX_CLR);
> > + cp_intc_write(d->hwirq, CP_INTC_SYS_ENABLE_IDX_CLR);
> > + cp_intc_write(1, CP_INTC_HOST_ENABLE_IDX_SET);
> > +}
> > +
> > +static void cp_intc_release_irq(struct irq_data *d)
> > +{
> > + cp_intc_write(d->hwirq, CP_INTC_SYS_ENABLE_IDX_SET);
> > +}
> > +#endif /* CONFIG_IPIPE */
> > +
> > static int cp_intc_set_irq_type(struct irq_data *d, unsigned int flow_type)
> > {
> > unsigned reg = BIT_WORD(d->hwirq);
> > @@ -100,6 +119,12 @@ static struct irq_chip cp_intc_irq_chip = {
> > .irq_ack = cp_intc_ack_irq,
> > .irq_mask = cp_intc_mask_irq,
> > .irq_unmask = cp_intc_unmask_irq,
> > +#ifdef CONFIG_IPIPE
> > + .irq_disable = cp_intc_hold_irq,
> > + .irq_enable = cp_intc_release_irq,
> > + .irq_hold = cp_intc_hold_irq,
> > + .irq_release = cp_intc_release_irq,
> > +#endif /* CONFIG_IPIPE */
> > .irq_set_type = cp_intc_set_irq_type,
> > .irq_set_wake = cp_intc_set_wake,
> > };
>
> The hold/release stuff should be only be needed for fasteoi irq, not for
> edge irqs.
>
Are those changes a problem, or just irrelevant with edge triggering?
> Other than that, the patch looks pretty straightforward.
>
>
--
Peter Howard <pjh@northern-ridge.com.au>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-10 22:52 ` Peter Howard
@ 2014-04-10 22:55 ` Gilles Chanteperdrix
2014-04-15 6:03 ` Peter Howard
1 sibling, 0 replies; 57+ messages in thread
From: Gilles Chanteperdrix @ 2014-04-10 22:55 UTC (permalink / raw)
To: Peter Howard; +Cc: xenomai
On 04/11/2014 12:52 AM, Peter Howard wrote:
> On Fri, 2014-04-11 at 00:48 +0200, Gilles Chanteperdrix wrote:
>> On 04/11/2014 12:34 AM, Peter Howard wrote:
>>> On Fri, 2014-04-11 at 00:23 +0200, Gilles Chanteperdrix wrote:
>>> (Stripping back conversation on this one - apologies if that's bad
>>> etiquette for this list)
>>>
>>>> Attachment is better. Also please post the changes you made for omapL138
>>>>
>>>
>>> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
>>> index a075b3e..3d8bc59 100644
>>> --- a/arch/arm/mach-davinci/Kconfig
>>> +++ b/arch/arm/mach-davinci/Kconfig
>>> @@ -41,6 +41,8 @@ config ARCH_DAVINCI_DA850
>>> select ARCH_DAVINCI_DA8XX
>>> select ARCH_HAS_CPUFREQ
>>> select CP_INTC
>>> + select IPIPE_ARM_KUSER_TSC if IPIPE
>>> + select ARM_FCSE if IPIPE
>>
>> You may want to leave the choice of enabling or disabling FCSE to the user.
>>
>
> Understood; at the moment the variance on max latency is really bad if
> you don't enable FCSE. When I sort out the crashing issues I'll re-test
> with it off.
>
>>>
>>> config ARCH_DAVINCI_DA8XX
>>> bool
>>> diff --git a/arch/arm/mach-davinci/cp_intc.c b/arch/arm/mach-davinci/cp_intc.c
>>> index 006dae8..61fa26f 100644
>>> --- a/arch/arm/mach-davinci/cp_intc.c
>>> +++ b/arch/arm/mach-davinci/cp_intc.c
>>> @@ -17,6 +17,7 @@
>>> #include <linux/of.h>
>>> #include <linux/of_address.h>
>>> #include <linux/of_irq.h>
>>> +#include <linux/ipipe.h>
>>>
>>> #include <mach/common.h>
>>> #include <mach/cp_intc.h>
>>> @@ -39,6 +40,7 @@ static void cp_intc_ack_irq(struct irq_data *d)
>>> /* Disable interrupt */
>>> static void cp_intc_mask_irq(struct irq_data *d)
>>> {
>>> + ipipe_lock_irq(d->irq);
>>> /* XXX don't know why we need to disable nIRQ here... */
>>> cp_intc_write(1, CP_INTC_HOST_ENABLE_IDX_CLR);
>>> cp_intc_write(d->hwirq, CP_INTC_SYS_ENABLE_IDX_CLR);
>>> @@ -49,8 +51,25 @@ static void cp_intc_mask_irq(struct irq_data *d)
>>> static void cp_intc_unmask_irq(struct irq_data *d)
>>> {
>>> cp_intc_write(d->hwirq, CP_INTC_SYS_ENABLE_IDX_SET);
>>> + ipipe_unlock_irq(d->irq);
>>> }
>>>
>>> +#ifdef CONFIG_IPIPE
>>> +/* Hold and release without irq locking */
>>> +static void cp_intc_hold_irq(struct irq_data *d)
>>> +{
>>> + /* XXX don't know why we need to disable nIRQ here... */
>>> + cp_intc_write(1, CP_INTC_HOST_ENABLE_IDX_CLR);
>>> + cp_intc_write(d->hwirq, CP_INTC_SYS_ENABLE_IDX_CLR);
>>> + cp_intc_write(1, CP_INTC_HOST_ENABLE_IDX_SET);
>>> +}
>>> +
>>> +static void cp_intc_release_irq(struct irq_data *d)
>>> +{
>>> + cp_intc_write(d->hwirq, CP_INTC_SYS_ENABLE_IDX_SET);
>>> +}
>>> +#endif /* CONFIG_IPIPE */
>>> +
>>> static int cp_intc_set_irq_type(struct irq_data *d, unsigned int flow_type)
>>> {
>>> unsigned reg = BIT_WORD(d->hwirq);
>>> @@ -100,6 +119,12 @@ static struct irq_chip cp_intc_irq_chip = {
>>> .irq_ack = cp_intc_ack_irq,
>>> .irq_mask = cp_intc_mask_irq,
>>> .irq_unmask = cp_intc_unmask_irq,
>>> +#ifdef CONFIG_IPIPE
>>> + .irq_disable = cp_intc_hold_irq,
>>> + .irq_enable = cp_intc_release_irq,
>>> + .irq_hold = cp_intc_hold_irq,
>>> + .irq_release = cp_intc_release_irq,
>>> +#endif /* CONFIG_IPIPE */
>>> .irq_set_type = cp_intc_set_irq_type,
>>> .irq_set_wake = cp_intc_set_wake,
>>> };
>>
>> The hold/release stuff should be only be needed for fasteoi irq, not for
>> edge irqs.
>>
>
> Are those changes a problem, or just irrelevant with edge triggering?
They should not be a problem, as for an edge irq, only ack is called,
not mask and unmask.
--
Gilles.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-10 22:23 ` Gilles Chanteperdrix
2014-04-10 22:27 ` Peter Howard
2014-04-10 22:34 ` Peter Howard
@ 2014-04-10 23:01 ` Peter Howard
2014-04-11 15:46 ` Lennart Sorensen
2 siblings, 1 reply; 57+ messages in thread
From: Peter Howard @ 2014-04-10 23:01 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On Fri, 2014-04-11 at 00:23 +0200, Gilles Chanteperdrix wrote:
> On 04/11/2014 12:17 AM, Peter Howard wrote:
> > On Thu, 2014-04-10 at 23:56 +0200, Gilles Chanteperdrix wrote:
> >> On 04/10/2014 09:57 PM, Peter Howard wrote:
> >>> On Thu, 2014-04-10 at 14:06 +0200, Gilles Chanteperdrix wrote:
> >>>> On 04/10/2014 09:01 AM, Peter Howard wrote:
> >>>>> On Wed, 2014-04-09 at 13:54 +0200, Gilles Chanteperdrix wrote:
> >>>>>> On 04/09/2014 06:27 AM, Peter Howard wrote:
> >>>>>>> On Wed, 2014-04-09 at 10:34 +1000, Peter Howard wrote:
> >>>>>>>> On Wed, 2014-04-09 at 02:20 +0200, Gilles Chanteperdrix wrote:
> >>>>>>>>> On 04/09/2014 01:30 AM, Peter Howard wrote:
> >>>>>>>>>> On Tue, 2014-04-08 at 11:18 +0200, Gilles Chanteperdrix wrote:
> >>>>>>>>>>> On 04/07/2014 07:34 AM, Peter Howard wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Wed, 2014-04-02 at 09:24 +0200, Gilles Chanteperdrix wrote:
> >>>>>>>>>>>>> On 04/02/2014 04:59 AM, Peter Howard wrote:
> >>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I'm interested in running xenomai on a TI-OMAP L138 board. I found the
> >>>>>>>>>>>>>> following thread in the archives:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> http://www.xenomai.org/pipermail/xenomai/2010-January/018898.html
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> where someone was working on porting ipipe and xenomai to that board.
> >>>>>>>>>>>>>> However, the thread ended with problems still unresolved, and the patch
> >>>>>>>>>>>>>> in the thread (just the changes for ipipe) isn't in the ipipe
> >>>>>>>>>>>>>> repository.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Does anyone know if this work was completed or just faded into the
> >>>>>>>>>>>>>> ether?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> We never merged a patch for this processor. And a lot of things changed
> >>>>>>>>>>>>> since that time. If you are interested in porting the I-pipe patch to
> >>>>>>>>>>>>> this processor, see:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Contrary to what I said last week, I'm working on a patch off the head
> >>>>>>>>>>>> of the ipipe repo. I have built a kernel with an ipipe port and with
> >>>>>>>>>>>> xenomai patched in. However the latency results are bad right now:
> >>>>>>>>>>>>
> >>>>>>>>>>>> root@arago:~# xeno latency -T 25
> >>>>>>>>>>>> == Sampling period: 1000 us
> >>>>>>>>>>>> == Test mode: periodic user-mode task
> >>>>>>>>>>>> == All results in microseconds
> >>>>>>>>>>>> warming up...
> >>>>>>>>>>>> RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)
> >>>>>>>>>>>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
> >>>>>>>>>>>> RTD| 3.541| 8.833| 60.749| 0| 0| 3.541| 60.749
> >>>>>>>>>>>> RTD| 3.499| 13.583| 93.916| 0| 0| 3.499| 93.916
> >>>>>>>>>>>> RTD| 3.666| 88.999| 109.708| 0| 0| 3.499| 109.708
> >>>>>>>>>>>> RTD| 3.541| 14.958| 95.374| 0| 0| 3.499| 109.708
> >>>>>>>>>>>> RTD| 3.541| 9.333| 77.583| 0| 0| 3.499| 109.708
> >>>>>>>>>>>> RTD| 4.041| 88.416| 109.791| 0| 0| 3.499| 109.791
> >>>>>>>>>>>> RTD| 3.499| 8.958| 72.791| 0| 0| 3.499| 109.791
> >>>>>>>>>>>> RTD| 3.499| 26.041| 106.874| 0| 0| 3.499| 109.791
> >>>>>>>>>>>> RTD| 3.874| 82.708| 107.916| 0| 0| 3.499| 109.791
> >>>>>>>>>>>> RTD| 3.499| 9.083| 73.708| 0| 0| 3.499| 109.791
> >>>>>>>>>>>> RTD| 3.333| 8.874| 62.458| 0| 0| 3.333| 109.791
> >>>>>>>>>>>> RTD| 3.333| 8.749| 62.208| 0| 0| 3.333| 109.791
> >>>>>>>>>>>> RTD| 3.416| 12.708| 99.416| 0| 0| 3.333| 109.791
> >>>>>>>>>>>> RTD| 3.499| 14.249| 106.749| 0| 0| 3.333| 109.791
> >>>>>>>>>>>> RTD| 3.541| 9.083| 76.499| 0| 0| 3.333| 109.791
> >>>>>>>>>>>> RTD| 3.249| 8.791| 63.499| 0| 0| 3.249| 109.791
> >>>>>>>>>>>> RTD| 3.416| 8.999| 62.499| 0| 0| 3.249| 109.791
> >>>>>>>>>>>> RTD| 3.541| 26.166| 101.208| 0| 0| 3.249| 109.791
> >>>>>>>>>>>> RTD| 3.583| 13.624| 92.458| 0| 0| 3.249| 109.791
> >>>>>>>>>>>> RTD| 3.541| 8.916| 73.708| 0| 0| 3.249| 109.791
> >>>>>>>>>>>> RTD| 3.541| 8.999| 64.291| 0| 0| 3.249| 109.791
> >>>>>>>>>>>> RTT| 00:00:22 (periodic user-mode task, 1000 us period, priority 99)
> >>>>>>>>>>>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
> >>>>>>>>>>>> RTD| 3.499| 8.874| 61.374| 0| 0| 3.249| 109.791
> >>>>>>>>>>>> RTD| 3.499| 13.833| 100.749| 0| 0| 3.249| 109.791
> >>>>>>>>>>>> RTD| 3.541| 13.083| 99.249| 0| 0| 3.249| 109.791
> >>>>>>>>>>>> ---|-----------|-----------|-----------|--------|------|------------------------
> >>>>>>>>>>>> RTS| 3.249| 21.458| 109.791| 0| 0| 00:00:25/00:00:25
> >>>>>>>>>>>> root@arago:~#
> >>>>>>>>>>>
> >>>>>>>>>>> Note that if the OMAPL138 is an armv4 or armv5, you may want to enable
> >>>>>>>>>>> the FCSE in order to reduce context switch time (and latencies).
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> I enabled FCSE, and the max latency is more consistent (though the min
> >>>>>>>>>> and average latency has climbed). How do the below figures look?
> >>>>>>>>>
> >>>>>>>>> Otherwise, it is hard to say whether there is an issue or not. It is not
> >>>>>>>>> uncommon for armv4 or armv5 to have high latencies like this.
> >>>>>>>>> On what core is this processor based, running at what frequency?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> It's an AMR926EJ-S r5. Datasheet claims 375MHz, U-boot claims 300MHz.
> >>>>>>>>
> >>>>>>>> Load test to follow.
> >>>>>>>>
> >>>>>>>
> >>>>>>> OK, this run was done with LTP running on the board (runltplite.sh),
> >>>>>>> with cpu utilization between 90% and 100%
> >>>>>>
> >>>>>> You have to run the latency test while ltp is running, and run this for
> >>>>>> a few hours (ltp runs a few hours anyway).
> >>>>>>
> >>>>>> We provide the xeno-test script to do this (and dohell to generate
> >>>>>> load).
> >>>>>>
> >>>>>> See:
> >>>>>> http://www.xenomai.org/documentation/xenomai-2.6/html/xeno-test/index.html
> >>>>>> http://www.xenomai.org/documentation/xenomai-2.6/html/dohell/index.html
> >>>>>>
> >>>>>
> >>>>> That's proving to be a bit challenging. Giving dohell ltp is causing
> >>>>> more kernel panics - usually a SIGSEGV to init. Now I'm aware from your
> >>>>> previous thread on the OMAP-L138 that ltp doesn't run cleanly on low-end
> >>>>> arm chips as-is, but I'm guessing kernel panics wasn't the failure mode
> >>>>> you were seeing. (running ltp by itself also gives a different kernel
> >>>>> panic after about 15-20 minutes) So I need to look into that more.
> >>>>>
> >>>>> I also need to try the ltp build on the stock Ti-supplied system to make
> >>>>> sure there's not a pre-existing problem lurking in there; I should do
> >>>>> that tomorrow.
> >>>>
> >>>> The thing is, if you enabled FCSE in guaranteed mode, it does not really
> >>>> make sense to run LTP: most tests will fail because of the processes
> >>>> number limit. In that case you should use the -b option, and pass the
> >>>> path to hackbench only.
> >>>>
> >>>>>
> >>>>> FWIW just running xeno-test with no arguments finishes cleanly after
> >>>>> running for 10 minutes or so.
> >>>>>
> >>>>> Is it worth putting up the diff to the ipipe tree at this stage for
> >>>>> people to look over?
> >>>>
> >>>> If you have random segfault, then something is still wrong. Have you
> >>>> tried enabling I-pipe debugging options?
> >>>>
> >>>> The non-working I-pipe tracer with stack unwinding is not normal either,
> >>>> what version of the kernel are you using?
> >>>>
> >>>>
> >>> The kernel source I'm modifying is the master branch of the ipipe git
> >>> repo.
> >>
> >> Despite the fact that this branch does not correspond to any released
> >> I-pipe patch, I can confirm that the I-pipe tracer works with stack
> >> unwinding on at91rm9200, ,an armv4, and at91sam9263, an armv5. So, you
> >> must miss something in your patch. Again, I would advise you to use:
> >>
> >> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
> >>
> >> As a check list.
> >>
> >
> > I did indeed use that page as a basis for the porting, and worked
> > through the "Troubleshooting" section at the bottom. Going through each
> > section:
> > * Hardware Timer - this is a slight concern as there is no acking
> > (hardware or software) of the irq at this level, so struct
> > ipipe_timer has .ack as NULL. Otherwise, set up as per example.
> > * High Resolution timer - it's free running, and straightforward
> > as per the example. It's edge triggered; changing to level
> > triggering results in no interrupts.
> > * Interrupt controller - no multi irqs. Mask/Unmask have the
> > ipipe_{un}lock_irq() added. Separate hold/release and
> > enable/disable calls without the lock (the latter added after
> > warnings with ipipe debugging turned on).
> > * GPIO - ipipe_handle_demuxed_irq() added in.
> > * I-pipe spinlocks - no conversions needed.
> > * Interrupt Controller Muting - skipped as recommended.
> > * Fast context switch extension - enabled (now - initial
> > crashes/panics were without it enabled).
> > * Troubleshooting - worked through as best I can with latency
> > tracing causing kernel panics.
>
> One missing point: the idle routine. As a quick check, could you boot
> with the nohlt parameter and see if it changes anything?
>
At least in the "xeno-test + ltp" it doesn't. Test still runs for
~10minutes then the machine dies with init geting a SIGSEGV.
> >
> >
> >> Also, if you can give us more details about the crash you get (kernel
> >> configuration, console messages), we could help you find what is wrong.
> >> And again, please enable all the I-pipe debugging option, in case it
> >> would catch an issue.
> >>
> >>
> > I can provide the defconfig either as an attachment or inline in the
> > mail - preference?
> > As to the crashes - I'll run through a full set today (tracing off,
> > tracing on, various tracing levels) and try to give as much info as
> > possible.
> >
>
> Attachment is better. Also please post the changes you made for omapL138
>
--
Peter Howard <pjh@northern-ridge.com.au>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-10 23:01 ` Peter Howard
@ 2014-04-11 15:46 ` Lennart Sorensen
2014-04-14 0:28 ` Peter Howard
0 siblings, 1 reply; 57+ messages in thread
From: Lennart Sorensen @ 2014-04-11 15:46 UTC (permalink / raw)
To: Peter Howard, ^[; +Cc: xenomai
On Fri, Apr 11, 2014 at 09:01:52AM +1000, Peter Howard wrote:
> On Fri, 2014-04-11 at 00:23 +0200, Gilles Chanteperdrix wrote:
> > On 04/11/2014 12:17 AM, Peter Howard wrote:
> > > On Thu, 2014-04-10 at 23:56 +0200, Gilles Chanteperdrix wrote:
> > >> On 04/10/2014 09:57 PM, Peter Howard wrote:
> > >>> On Thu, 2014-04-10 at 14:06 +0200, Gilles Chanteperdrix wrote:
> > >>>> On 04/10/2014 09:01 AM, Peter Howard wrote:
> > >>>>> On Wed, 2014-04-09 at 13:54 +0200, Gilles Chanteperdrix wrote:
> > >>>>>> On 04/09/2014 06:27 AM, Peter Howard wrote:
> > >>>>>>> On Wed, 2014-04-09 at 10:34 +1000, Peter Howard wrote:
> > >>>>>>>> On Wed, 2014-04-09 at 02:20 +0200, Gilles Chanteperdrix wrote:
> > >>>>>>>>> On 04/09/2014 01:30 AM, Peter Howard wrote:
> > >>>>>>>>>> On Tue, 2014-04-08 at 11:18 +0200, Gilles Chanteperdrix wrote:
> > >>>>>>>>>>> On 04/07/2014 07:34 AM, Peter Howard wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On Wed, 2014-04-02 at 09:24 +0200, Gilles Chanteperdrix wrote:
> > >>>>>>>>>>>>> On 04/02/2014 04:59 AM, Peter Howard wrote:
> > >>>>>>>>>>>>>> Hi,
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> I'm interested in running xenomai on a TI-OMAP L138 board. I found the
> > >>>>>>>>>>>>>> following thread in the archives:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> http://www.xenomai.org/pipermail/xenomai/2010-January/018898.html
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> where someone was working on porting ipipe and xenomai to that board.
> > >>>>>>>>>>>>>> However, the thread ended with problems still unresolved, and the patch
> > >>>>>>>>>>>>>> in the thread (just the changes for ipipe) isn't in the ipipe
> > >>>>>>>>>>>>>> repository.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Does anyone know if this work was completed or just faded into the
> > >>>>>>>>>>>>>> ether?
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> We never merged a patch for this processor. And a lot of things changed
> > >>>>>>>>>>>>> since that time. If you are interested in porting the I-pipe patch to
> > >>>>>>>>>>>>> this processor, see:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Contrary to what I said last week, I'm working on a patch off the head
> > >>>>>>>>>>>> of the ipipe repo. I have built a kernel with an ipipe port and with
> > >>>>>>>>>>>> xenomai patched in. However the latency results are bad right now:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> root@arago:~# xeno latency -T 25
> > >>>>>>>>>>>> == Sampling period: 1000 us
> > >>>>>>>>>>>> == Test mode: periodic user-mode task
> > >>>>>>>>>>>> == All results in microseconds
> > >>>>>>>>>>>> warming up...
> > >>>>>>>>>>>> RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)
> > >>>>>>>>>>>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
> > >>>>>>>>>>>> RTD| 3.541| 8.833| 60.749| 0| 0| 3.541| 60.749
> > >>>>>>>>>>>> RTD| 3.499| 13.583| 93.916| 0| 0| 3.499| 93.916
> > >>>>>>>>>>>> RTD| 3.666| 88.999| 109.708| 0| 0| 3.499| 109.708
> > >>>>>>>>>>>> RTD| 3.541| 14.958| 95.374| 0| 0| 3.499| 109.708
> > >>>>>>>>>>>> RTD| 3.541| 9.333| 77.583| 0| 0| 3.499| 109.708
> > >>>>>>>>>>>> RTD| 4.041| 88.416| 109.791| 0| 0| 3.499| 109.791
> > >>>>>>>>>>>> RTD| 3.499| 8.958| 72.791| 0| 0| 3.499| 109.791
> > >>>>>>>>>>>> RTD| 3.499| 26.041| 106.874| 0| 0| 3.499| 109.791
> > >>>>>>>>>>>> RTD| 3.874| 82.708| 107.916| 0| 0| 3.499| 109.791
> > >>>>>>>>>>>> RTD| 3.499| 9.083| 73.708| 0| 0| 3.499| 109.791
> > >>>>>>>>>>>> RTD| 3.333| 8.874| 62.458| 0| 0| 3.333| 109.791
> > >>>>>>>>>>>> RTD| 3.333| 8.749| 62.208| 0| 0| 3.333| 109.791
> > >>>>>>>>>>>> RTD| 3.416| 12.708| 99.416| 0| 0| 3.333| 109.791
> > >>>>>>>>>>>> RTD| 3.499| 14.249| 106.749| 0| 0| 3.333| 109.791
> > >>>>>>>>>>>> RTD| 3.541| 9.083| 76.499| 0| 0| 3.333| 109.791
> > >>>>>>>>>>>> RTD| 3.249| 8.791| 63.499| 0| 0| 3.249| 109.791
> > >>>>>>>>>>>> RTD| 3.416| 8.999| 62.499| 0| 0| 3.249| 109.791
> > >>>>>>>>>>>> RTD| 3.541| 26.166| 101.208| 0| 0| 3.249| 109.791
> > >>>>>>>>>>>> RTD| 3.583| 13.624| 92.458| 0| 0| 3.249| 109.791
> > >>>>>>>>>>>> RTD| 3.541| 8.916| 73.708| 0| 0| 3.249| 109.791
> > >>>>>>>>>>>> RTD| 3.541| 8.999| 64.291| 0| 0| 3.249| 109.791
> > >>>>>>>>>>>> RTT| 00:00:22 (periodic user-mode task, 1000 us period, priority 99)
> > >>>>>>>>>>>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
> > >>>>>>>>>>>> RTD| 3.499| 8.874| 61.374| 0| 0| 3.249| 109.791
> > >>>>>>>>>>>> RTD| 3.499| 13.833| 100.749| 0| 0| 3.249| 109.791
> > >>>>>>>>>>>> RTD| 3.541| 13.083| 99.249| 0| 0| 3.249| 109.791
> > >>>>>>>>>>>> ---|-----------|-----------|-----------|--------|------|------------------------
> > >>>>>>>>>>>> RTS| 3.249| 21.458| 109.791| 0| 0| 00:00:25/00:00:25
> > >>>>>>>>>>>> root@arago:~#
> > >>>>>>>>>>>
> > >>>>>>>>>>> Note that if the OMAPL138 is an armv4 or armv5, you may want to enable
> > >>>>>>>>>>> the FCSE in order to reduce context switch time (and latencies).
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> I enabled FCSE, and the max latency is more consistent (though the min
> > >>>>>>>>>> and average latency has climbed). How do the below figures look?
> > >>>>>>>>>
> > >>>>>>>>> Otherwise, it is hard to say whether there is an issue or not. It is not
> > >>>>>>>>> uncommon for armv4 or armv5 to have high latencies like this.
> > >>>>>>>>> On what core is this processor based, running at what frequency?
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>> It's an AMR926EJ-S r5. Datasheet claims 375MHz, U-boot claims 300MHz.
> > >>>>>>>>
> > >>>>>>>> Load test to follow.
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>> OK, this run was done with LTP running on the board (runltplite.sh),
> > >>>>>>> with cpu utilization between 90% and 100%
> > >>>>>>
> > >>>>>> You have to run the latency test while ltp is running, and run this for
> > >>>>>> a few hours (ltp runs a few hours anyway).
> > >>>>>>
> > >>>>>> We provide the xeno-test script to do this (and dohell to generate
> > >>>>>> load).
> > >>>>>>
> > >>>>>> See:
> > >>>>>> http://www.xenomai.org/documentation/xenomai-2.6/html/xeno-test/index.html
> > >>>>>> http://www.xenomai.org/documentation/xenomai-2.6/html/dohell/index.html
> > >>>>>>
> > >>>>>
> > >>>>> That's proving to be a bit challenging. Giving dohell ltp is causing
> > >>>>> more kernel panics - usually a SIGSEGV to init. Now I'm aware from your
> > >>>>> previous thread on the OMAP-L138 that ltp doesn't run cleanly on low-end
> > >>>>> arm chips as-is, but I'm guessing kernel panics wasn't the failure mode
> > >>>>> you were seeing. (running ltp by itself also gives a different kernel
> > >>>>> panic after about 15-20 minutes) So I need to look into that more.
> > >>>>>
> > >>>>> I also need to try the ltp build on the stock Ti-supplied system to make
> > >>>>> sure there's not a pre-existing problem lurking in there; I should do
> > >>>>> that tomorrow.
> > >>>>
> > >>>> The thing is, if you enabled FCSE in guaranteed mode, it does not really
> > >>>> make sense to run LTP: most tests will fail because of the processes
> > >>>> number limit. In that case you should use the -b option, and pass the
> > >>>> path to hackbench only.
> > >>>>
> > >>>>>
> > >>>>> FWIW just running xeno-test with no arguments finishes cleanly after
> > >>>>> running for 10 minutes or so.
> > >>>>>
> > >>>>> Is it worth putting up the diff to the ipipe tree at this stage for
> > >>>>> people to look over?
> > >>>>
> > >>>> If you have random segfault, then something is still wrong. Have you
> > >>>> tried enabling I-pipe debugging options?
> > >>>>
> > >>>> The non-working I-pipe tracer with stack unwinding is not normal either,
> > >>>> what version of the kernel are you using?
> > >>>>
> > >>>>
> > >>> The kernel source I'm modifying is the master branch of the ipipe git
> > >>> repo.
> > >>
> > >> Despite the fact that this branch does not correspond to any released
> > >> I-pipe patch, I can confirm that the I-pipe tracer works with stack
> > >> unwinding on at91rm9200, ,an armv4, and at91sam9263, an armv5. So, you
> > >> must miss something in your patch. Again, I would advise you to use:
> > >>
> > >> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
> > >>
> > >> As a check list.
> > >>
> > >
> > > I did indeed use that page as a basis for the porting, and worked
> > > through the "Troubleshooting" section at the bottom. Going through each
> > > section:
> > > * Hardware Timer - this is a slight concern as there is no acking
> > > (hardware or software) of the irq at this level, so struct
> > > ipipe_timer has .ack as NULL. Otherwise, set up as per example.
> > > * High Resolution timer - it's free running, and straightforward
> > > as per the example. It's edge triggered; changing to level
> > > triggering results in no interrupts.
> > > * Interrupt controller - no multi irqs. Mask/Unmask have the
> > > ipipe_{un}lock_irq() added. Separate hold/release and
> > > enable/disable calls without the lock (the latter added after
> > > warnings with ipipe debugging turned on).
> > > * GPIO - ipipe_handle_demuxed_irq() added in.
> > > * I-pipe spinlocks - no conversions needed.
> > > * Interrupt Controller Muting - skipped as recommended.
> > > * Fast context switch extension - enabled (now - initial
> > > crashes/panics were without it enabled).
> > > * Troubleshooting - worked through as best I can with latency
> > > tracing causing kernel panics.
> >
> > One missing point: the idle routine. As a quick check, could you boot
> > with the nohlt parameter and see if it changes anything?
> >
>
> At least in the "xeno-test + ltp" it doesn't. Test still runs for
> ~10minutes then the machine dies with init geting a SIGSEGV.
Which kernel are you using?
I was having segfaults in processes doing sigchld handling, and init does
that a lot for any processes that get abandoned. Going from 3.8 to 3.12
kernel solved it for me, and unfortunately I have not tracked down the
patch that fixed the kernel, although I have one commit I would test at
some point when I have time. The commit is this one:
t c2cc499c5bcf9040a738f49e8051b42078205748
Author: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
Date: Fri May 24 15:55:18 2013 -0700
mm compaction: fix of improper cache flush in migration code
Page 'new' during MIGRATION can't be flushed with flush_cache_page().
Using flush_cache_page(vma, addr, pfn) is justified only if the page is
already placed in process page table, and that is done right after
flush_cache_page(). But without it the arch function has no knowledge
of process PTE and does nothing.
Besides that, flush_cache_page() flushes an application cache page, but
the kernel has a different page virtual address and dirtied it.
Replace it with flush_dcache_page(new) which is the proper usage.
The old page is flushed in try_to_unmap_one() before migration.
This bug takes place in Sead3 board with M14Kc MIPS CPU without cache
aliasing (but Harvard arch - separate I and D cache) in tight memory
environment (128MB) each 1-3days on SOAK test. It fails in cc1 during
kernel build (SIGILL, SIGBUS, SIGSEG) if CONFIG_COMPACTION is switched
ON.
Signed-off-by: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
Cc: Leonid Yegoshin <yegoshin@mips.com>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: Michal Hocko <mhocko@suse.cz>
Acked-by: Mel Gorman <mgorman@suse.de>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: David Miller <davem@davemloft.net>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Yes it mentions MIPS as a case known to fail, but it is in the general
mm code and should apply potentially to any system. If you use 3.10 or
higher, you should already have that commit, 3.9 and earlier do not.
--
Len Sorensen
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-11 15:46 ` Lennart Sorensen
@ 2014-04-14 0:28 ` Peter Howard
2014-04-14 1:10 ` Lennart Sorensen
0 siblings, 1 reply; 57+ messages in thread
From: Peter Howard @ 2014-04-14 0:28 UTC (permalink / raw)
To: Lennart Sorensen; +Cc: xenomai
On Fri, 2014-04-11 at 11:46 -0400, Lennart Sorensen wrote:
> On Fri, Apr 11, 2014 at 09:01:52AM +1000, Peter Howard wrote:
> > On Fri, 2014-04-11 at 00:23 +0200, Gilles Chanteperdrix wrote:
> > > On 04/11/2014 12:17 AM, Peter Howard wrote:
> > > > On Thu, 2014-04-10 at 23:56 +0200, Gilles Chanteperdrix wrote:
> > > >> On 04/10/2014 09:57 PM, Peter Howard wrote:
> > > >>> On Thu, 2014-04-10 at 14:06 +0200, Gilles Chanteperdrix wrote:
> > > >>>> On 04/10/2014 09:01 AM, Peter Howard wrote:
> > > >>>>> On Wed, 2014-04-09 at 13:54 +0200, Gilles Chanteperdrix wrote:
> > > >>>>>> On 04/09/2014 06:27 AM, Peter Howard wrote:
> > > >>>>>>> On Wed, 2014-04-09 at 10:34 +1000, Peter Howard wrote:
> > > >>>>>>>> On Wed, 2014-04-09 at 02:20 +0200, Gilles Chanteperdrix wrote:
> > > >>>>>>>>> On 04/09/2014 01:30 AM, Peter Howard wrote:
> > > >>>>>>>>>> On Tue, 2014-04-08 at 11:18 +0200, Gilles Chanteperdrix wrote:
> > > >>>>>>>>>>> On 04/07/2014 07:34 AM, Peter Howard wrote:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> On Wed, 2014-04-02 at 09:24 +0200, Gilles Chanteperdrix wrote:
> > > >>>>>>>>>>>>> On 04/02/2014 04:59 AM, Peter Howard wrote:
> > > >>>>>>>>>>>>>> Hi,
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> I'm interested in running xenomai on a TI-OMAP L138 board. I found the
> > > >>>>>>>>>>>>>> following thread in the archives:
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> http://www.xenomai.org/pipermail/xenomai/2010-January/018898.html
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> where someone was working on porting ipipe and xenomai to that board.
> > > >>>>>>>>>>>>>> However, the thread ended with problems still unresolved, and the patch
> > > >>>>>>>>>>>>>> in the thread (just the changes for ipipe) isn't in the ipipe
> > > >>>>>>>>>>>>>> repository.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Does anyone know if this work was completed or just faded into the
> > > >>>>>>>>>>>>>> ether?
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> We never merged a patch for this processor. And a lot of things changed
> > > >>>>>>>>>>>>> since that time. If you are interested in porting the I-pipe patch to
> > > >>>>>>>>>>>>> this processor, see:
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Contrary to what I said last week, I'm working on a patch off the head
> > > >>>>>>>>>>>> of the ipipe repo. I have built a kernel with an ipipe port and with
> > > >>>>>>>>>>>> xenomai patched in. However the latency results are bad right now:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> root@arago:~# xeno latency -T 25
> > > >>>>>>>>>>>> == Sampling period: 1000 us
> > > >>>>>>>>>>>> == Test mode: periodic user-mode task
> > > >>>>>>>>>>>> == All results in microseconds
> > > >>>>>>>>>>>> warming up...
> > > >>>>>>>>>>>> RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)
> > > >>>>>>>>>>>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
> > > >>>>>>>>>>>> RTD| 3.541| 8.833| 60.749| 0| 0| 3.541| 60.749
> > > >>>>>>>>>>>> RTD| 3.499| 13.583| 93.916| 0| 0| 3.499| 93.916
> > > >>>>>>>>>>>> RTD| 3.666| 88.999| 109.708| 0| 0| 3.499| 109.708
> > > >>>>>>>>>>>> RTD| 3.541| 14.958| 95.374| 0| 0| 3.499| 109.708
> > > >>>>>>>>>>>> RTD| 3.541| 9.333| 77.583| 0| 0| 3.499| 109.708
> > > >>>>>>>>>>>> RTD| 4.041| 88.416| 109.791| 0| 0| 3.499| 109.791
> > > >>>>>>>>>>>> RTD| 3.499| 8.958| 72.791| 0| 0| 3.499| 109.791
> > > >>>>>>>>>>>> RTD| 3.499| 26.041| 106.874| 0| 0| 3.499| 109.791
> > > >>>>>>>>>>>> RTD| 3.874| 82.708| 107.916| 0| 0| 3.499| 109.791
> > > >>>>>>>>>>>> RTD| 3.499| 9.083| 73.708| 0| 0| 3.499| 109.791
> > > >>>>>>>>>>>> RTD| 3.333| 8.874| 62.458| 0| 0| 3.333| 109.791
> > > >>>>>>>>>>>> RTD| 3.333| 8.749| 62.208| 0| 0| 3.333| 109.791
> > > >>>>>>>>>>>> RTD| 3.416| 12.708| 99.416| 0| 0| 3.333| 109.791
> > > >>>>>>>>>>>> RTD| 3.499| 14.249| 106.749| 0| 0| 3.333| 109.791
> > > >>>>>>>>>>>> RTD| 3.541| 9.083| 76.499| 0| 0| 3.333| 109.791
> > > >>>>>>>>>>>> RTD| 3.249| 8.791| 63.499| 0| 0| 3.249| 109.791
> > > >>>>>>>>>>>> RTD| 3.416| 8.999| 62.499| 0| 0| 3.249| 109.791
> > > >>>>>>>>>>>> RTD| 3.541| 26.166| 101.208| 0| 0| 3.249| 109.791
> > > >>>>>>>>>>>> RTD| 3.583| 13.624| 92.458| 0| 0| 3.249| 109.791
> > > >>>>>>>>>>>> RTD| 3.541| 8.916| 73.708| 0| 0| 3.249| 109.791
> > > >>>>>>>>>>>> RTD| 3.541| 8.999| 64.291| 0| 0| 3.249| 109.791
> > > >>>>>>>>>>>> RTT| 00:00:22 (periodic user-mode task, 1000 us period, priority 99)
> > > >>>>>>>>>>>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
> > > >>>>>>>>>>>> RTD| 3.499| 8.874| 61.374| 0| 0| 3.249| 109.791
> > > >>>>>>>>>>>> RTD| 3.499| 13.833| 100.749| 0| 0| 3.249| 109.791
> > > >>>>>>>>>>>> RTD| 3.541| 13.083| 99.249| 0| 0| 3.249| 109.791
> > > >>>>>>>>>>>> ---|-----------|-----------|-----------|--------|------|------------------------
> > > >>>>>>>>>>>> RTS| 3.249| 21.458| 109.791| 0| 0| 00:00:25/00:00:25
> > > >>>>>>>>>>>> root@arago:~#
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Note that if the OMAPL138 is an armv4 or armv5, you may want to enable
> > > >>>>>>>>>>> the FCSE in order to reduce context switch time (and latencies).
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> I enabled FCSE, and the max latency is more consistent (though the min
> > > >>>>>>>>>> and average latency has climbed). How do the below figures look?
> > > >>>>>>>>>
> > > >>>>>>>>> Otherwise, it is hard to say whether there is an issue or not. It is not
> > > >>>>>>>>> uncommon for armv4 or armv5 to have high latencies like this.
> > > >>>>>>>>> On what core is this processor based, running at what frequency?
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>> It's an AMR926EJ-S r5. Datasheet claims 375MHz, U-boot claims 300MHz.
> > > >>>>>>>>
> > > >>>>>>>> Load test to follow.
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>> OK, this run was done with LTP running on the board (runltplite.sh),
> > > >>>>>>> with cpu utilization between 90% and 100%
> > > >>>>>>
> > > >>>>>> You have to run the latency test while ltp is running, and run this for
> > > >>>>>> a few hours (ltp runs a few hours anyway).
> > > >>>>>>
> > > >>>>>> We provide the xeno-test script to do this (and dohell to generate
> > > >>>>>> load).
> > > >>>>>>
> > > >>>>>> See:
> > > >>>>>> http://www.xenomai.org/documentation/xenomai-2.6/html/xeno-test/index.html
> > > >>>>>> http://www.xenomai.org/documentation/xenomai-2.6/html/dohell/index.html
> > > >>>>>>
> > > >>>>>
> > > >>>>> That's proving to be a bit challenging. Giving dohell ltp is causing
> > > >>>>> more kernel panics - usually a SIGSEGV to init. Now I'm aware from your
> > > >>>>> previous thread on the OMAP-L138 that ltp doesn't run cleanly on low-end
> > > >>>>> arm chips as-is, but I'm guessing kernel panics wasn't the failure mode
> > > >>>>> you were seeing. (running ltp by itself also gives a different kernel
> > > >>>>> panic after about 15-20 minutes) So I need to look into that more.
> > > >>>>>
> > > >>>>> I also need to try the ltp build on the stock Ti-supplied system to make
> > > >>>>> sure there's not a pre-existing problem lurking in there; I should do
> > > >>>>> that tomorrow.
> > > >>>>
> > > >>>> The thing is, if you enabled FCSE in guaranteed mode, it does not really
> > > >>>> make sense to run LTP: most tests will fail because of the processes
> > > >>>> number limit. In that case you should use the -b option, and pass the
> > > >>>> path to hackbench only.
> > > >>>>
> > > >>>>>
> > > >>>>> FWIW just running xeno-test with no arguments finishes cleanly after
> > > >>>>> running for 10 minutes or so.
> > > >>>>>
> > > >>>>> Is it worth putting up the diff to the ipipe tree at this stage for
> > > >>>>> people to look over?
> > > >>>>
> > > >>>> If you have random segfault, then something is still wrong. Have you
> > > >>>> tried enabling I-pipe debugging options?
> > > >>>>
> > > >>>> The non-working I-pipe tracer with stack unwinding is not normal either,
> > > >>>> what version of the kernel are you using?
> > > >>>>
> > > >>>>
> > > >>> The kernel source I'm modifying is the master branch of the ipipe git
> > > >>> repo.
> > > >>
> > > >> Despite the fact that this branch does not correspond to any released
> > > >> I-pipe patch, I can confirm that the I-pipe tracer works with stack
> > > >> unwinding on at91rm9200, ,an armv4, and at91sam9263, an armv5. So, you
> > > >> must miss something in your patch. Again, I would advise you to use:
> > > >>
> > > >> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
> > > >>
> > > >> As a check list.
> > > >>
> > > >
> > > > I did indeed use that page as a basis for the porting, and worked
> > > > through the "Troubleshooting" section at the bottom. Going through each
> > > > section:
> > > > * Hardware Timer - this is a slight concern as there is no acking
> > > > (hardware or software) of the irq at this level, so struct
> > > > ipipe_timer has .ack as NULL. Otherwise, set up as per example.
> > > > * High Resolution timer - it's free running, and straightforward
> > > > as per the example. It's edge triggered; changing to level
> > > > triggering results in no interrupts.
> > > > * Interrupt controller - no multi irqs. Mask/Unmask have the
> > > > ipipe_{un}lock_irq() added. Separate hold/release and
> > > > enable/disable calls without the lock (the latter added after
> > > > warnings with ipipe debugging turned on).
> > > > * GPIO - ipipe_handle_demuxed_irq() added in.
> > > > * I-pipe spinlocks - no conversions needed.
> > > > * Interrupt Controller Muting - skipped as recommended.
> > > > * Fast context switch extension - enabled (now - initial
> > > > crashes/panics were without it enabled).
> > > > * Troubleshooting - worked through as best I can with latency
> > > > tracing causing kernel panics.
> > >
> > > One missing point: the idle routine. As a quick check, could you boot
> > > with the nohlt parameter and see if it changes anything?
> > >
> >
> > At least in the "xeno-test + ltp" it doesn't. Test still runs for
> > ~10minutes then the machine dies with init geting a SIGSEGV.
>
> Which kernel are you using?
>
> I was having segfaults in processes doing sigchld handling, and init does
> that a lot for any processes that get abandoned. Going from 3.8 to 3.12
> kernel solved it for me, and unfortunately I have not tracked down the
> patch that fixed the kernel, although I have one commit I would test at
> some point when I have time. The commit is this one:
>
> t c2cc499c5bcf9040a738f49e8051b42078205748
> Author: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
> Date: Fri May 24 15:55:18 2013 -0700
>
> mm compaction: fix of improper cache flush in migration code
>
> Page 'new' during MIGRATION can't be flushed with flush_cache_page().
> Using flush_cache_page(vma, addr, pfn) is justified only if the page is
> already placed in process page table, and that is done right after
> flush_cache_page(). But without it the arch function has no knowledge
> of process PTE and does nothing.
>
> Besides that, flush_cache_page() flushes an application cache page, but
> the kernel has a different page virtual address and dirtied it.
>
> Replace it with flush_dcache_page(new) which is the proper usage.
>
> The old page is flushed in try_to_unmap_one() before migration.
>
> This bug takes place in Sead3 board with M14Kc MIPS CPU without cache
> aliasing (but Harvard arch - separate I and D cache) in tight memory
> environment (128MB) each 1-3days on SOAK test. It fails in cc1 during
> kernel build (SIGILL, SIGBUS, SIGSEG) if CONFIG_COMPACTION is switched
> ON.
>
> Signed-off-by: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
> Cc: Leonid Yegoshin <yegoshin@mips.com>
> Acked-by: Rik van Riel <riel@redhat.com>
> Cc: Michal Hocko <mhocko@suse.cz>
> Acked-by: Mel Gorman <mgorman@suse.de>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: Russell King <rmk@arm.linux.org.uk>
> Cc: David Miller <davem@davemloft.net>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>
> Yes it mentions MIPS as a case known to fail, but it is in the general
> mm code and should apply potentially to any system. If you use 3.10 or
> higher, you should already have that commit, 3.9 and earlier do not.
>
The ipipe repo is at 3.10, and I've just confirmed I have that patch.
Sadly that's not the problem.
Thanks for the suggestion though.
--
Peter Howard <pjh@northern-ridge.com.au>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-14 0:28 ` Peter Howard
@ 2014-04-14 1:10 ` Lennart Sorensen
2014-04-14 5:02 ` Peter Howard
2014-04-15 1:58 ` Peter Howard
0 siblings, 2 replies; 57+ messages in thread
From: Lennart Sorensen @ 2014-04-14 1:10 UTC (permalink / raw)
To: Peter Howard; +Cc: xenomai
On Mon, Apr 14, 2014 at 10:28:01AM +1000, Peter Howard wrote:
> The ipipe repo is at 3.10, and I've just confirmed I have that patch.
> Sadly that's not the problem.
>
> Thanks for the suggestion though.
Well I hadn't tried it yet myself. All I know so far is 3.12 works
great for me, and 3.8 segfaulted randomly during sigchld handling.
If you could get a debug build of init and turn on core dumps, that
might give you something to analyze with gdb to see if you might be
hitting the same situation.
Xenomai also seems to be running great on arm on 3.12 for me using the
ipipe for 3.12 git branch, and the latest xenomai-2.6 git tree.
Maybe that would be worth giving a try.
--
Len Sorensen
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-14 1:10 ` Lennart Sorensen
@ 2014-04-14 5:02 ` Peter Howard
2014-04-14 5:48 ` Peter Howard
2014-04-14 13:21 ` Lennart Sorensen
2014-04-15 1:58 ` Peter Howard
1 sibling, 2 replies; 57+ messages in thread
From: Peter Howard @ 2014-04-14 5:02 UTC (permalink / raw)
To: Lennart Sorensen; +Cc: xenomai
On Sun, 2014-04-13 at 21:10 -0400, Lennart Sorensen wrote:
> On Mon, Apr 14, 2014 at 10:28:01AM +1000, Peter Howard wrote:
> > The ipipe repo is at 3.10, and I've just confirmed I have that patch.
> > Sadly that's not the problem.
> >
> > Thanks for the suggestion though.
>
> Well I hadn't tried it yet myself. All I know so far is 3.12 works
> great for me, and 3.8 segfaulted randomly during sigchld handling.
>
> If you could get a debug build of init and turn on core dumps, that
> might give you something to analyze with gdb to see if you might be
> hitting the same situation.
>
> Xenomai also seems to be running great on arm on 3.12 for me using the
> ipipe for 3.12 git branch, and the latest xenomai-2.6 git tree.
The 3.11 git branch displays the same behavior as master, and on the
3.12 and 3.14 branches (and, presumably the 3.13 branch too) the kernel
no longer detects the SD card (driver _is_ enabled). Not sure where the
bug appears, but it's one bug too many for the moment.
--
Peter Howard <pjh@northern-ridge.com.au>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-14 5:02 ` Peter Howard
@ 2014-04-14 5:48 ` Peter Howard
2014-04-14 13:21 ` Lennart Sorensen
1 sibling, 0 replies; 57+ messages in thread
From: Peter Howard @ 2014-04-14 5:48 UTC (permalink / raw)
To: Lennart Sorensen; +Cc: xenomai
On Mon, 2014-04-14 at 15:02 +1000, Peter Howard wrote:
>
> The 3.11 git branch displays the same behavior as master, and on the
> 3.12 and 3.14 branches (and, presumably the 3.13 branch too) the kernel
> no longer detects the SD card (driver _is_ enabled). Not sure where the
> bug appears, but it's one bug too many for the moment.
>
I take it back; after my frustration levels returned to "acceptable",
git bisect found the offending commit in ~30 minute :-) Once I've
resolved it fully I'll report properly on 3.12 and later.
--
Peter Howard <pjh@northern-ridge.com.au>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-14 5:02 ` Peter Howard
2014-04-14 5:48 ` Peter Howard
@ 2014-04-14 13:21 ` Lennart Sorensen
1 sibling, 0 replies; 57+ messages in thread
From: Lennart Sorensen @ 2014-04-14 13:21 UTC (permalink / raw)
To: Peter Howard; +Cc: xenomai
On Mon, Apr 14, 2014 at 03:02:31PM +1000, Peter Howard wrote:
> The 3.11 git branch displays the same behavior as master, and on the
> 3.12 and 3.14 branches (and, presumably the 3.13 branch too) the kernel
> no longer detects the SD card (driver _is_ enabled). Not sure where the
> bug appears, but it's one bug too many for the moment.
That would be very inconvinient.
--
Len Sorensen
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-14 1:10 ` Lennart Sorensen
2014-04-14 5:02 ` Peter Howard
@ 2014-04-15 1:58 ` Peter Howard
1 sibling, 0 replies; 57+ messages in thread
From: Peter Howard @ 2014-04-15 1:58 UTC (permalink / raw)
To: Lennart Sorensen; +Cc: xenomai
On Sun, 2014-04-13 at 21:10 -0400, Lennart Sorensen wrote:
> On Mon, Apr 14, 2014 at 10:28:01AM +1000, Peter Howard wrote:
> > The ipipe repo is at 3.10, and I've just confirmed I have that patch.
> > Sadly that's not the problem.
> >
> > Thanks for the suggestion though.
>
> Well I hadn't tried it yet myself. All I know so far is 3.12 works
> great for me, and 3.8 segfaulted randomly during sigchld handling.
>
> If you could get a debug build of init and turn on core dumps, that
> might give you something to analyze with gdb to see if you might be
> hitting the same situation.
>
> Xenomai also seems to be running great on arm on 3.12 for me using the
> ipipe for 3.12 git branch, and the latest xenomai-2.6 git tree.
>
> Maybe that would be worth giving a try.
>
OK, so I managed to get the SD card being detected on 3.12 (getting that
properly fixed is a thread on a different mailing list). And I've
gotten a 3.12 kernel with my ipipe changes for the DA850 and Xenomai 2.6
running.
Sadly I'm left with the same set of panics that I had before; usually
ending with init getting a SIGSEGV.
--
Peter Howard <pjh@northern-ridge.com.au>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-10 22:52 ` Peter Howard
2014-04-10 22:55 ` Gilles Chanteperdrix
@ 2014-04-15 6:03 ` Peter Howard
2014-04-15 11:37 ` Gilles Chanteperdrix
1 sibling, 1 reply; 57+ messages in thread
From: Peter Howard @ 2014-04-15 6:03 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On Fri, 2014-04-11 at 08:52 +1000, Peter Howard wrote:
> On Fri, 2014-04-11 at 00:48 +0200, Gilles Chanteperdrix wrote:
> > On 04/11/2014 12:34 AM, Peter Howard wrote:
> > > On Fri, 2014-04-11 at 00:23 +0200, Gilles Chanteperdrix wrote:
> > > (Stripping back conversation on this one - apologies if that's bad
> > > etiquette for this list)
> > >
> > >> Attachment is better. Also please post the changes you made for omapL138
> > >>
> > >
> > > diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
> > > index a075b3e..3d8bc59 100644
> > > --- a/arch/arm/mach-davinci/Kconfig
> > > +++ b/arch/arm/mach-davinci/Kconfig
> > > @@ -41,6 +41,8 @@ config ARCH_DAVINCI_DA850
> > > select ARCH_DAVINCI_DA8XX
> > > select ARCH_HAS_CPUFREQ
> > > select CP_INTC
> > > + select IPIPE_ARM_KUSER_TSC if IPIPE
> > > + select ARM_FCSE if IPIPE
> >
> > You may want to leave the choice of enabling or disabling FCSE to the user.
> >
>
> Understood; at the moment the variance on max latency is really bad if
> you don't enable FCSE. When I sort out the crashing issues I'll re-test
> with it off.
Well, FCSE turned out to be my problem.
More specifically, FCSE and ARM_FCSE_BEST_EFFORT. Either a) disabling
ARM_FCSE altogether, or b) selecting ARM_FCSE with ARM_FCSE_GUARENTEED
gets rid of the crashes/panics with ipipe latency tracing enabled.
So now things seem reasonably stable, I'll go through the full set of
tests. Though I still can't do 'xeno-test -l "dohell -l /opt/ltp"' as
ltp takes out the system without any ipipe/xenomai bits.
--
Peter Howard <pjh@northern-ridge.com.au>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-15 6:03 ` Peter Howard
@ 2014-04-15 11:37 ` Gilles Chanteperdrix
2014-04-15 21:59 ` Peter Howard
0 siblings, 1 reply; 57+ messages in thread
From: Gilles Chanteperdrix @ 2014-04-15 11:37 UTC (permalink / raw)
To: Peter Howard; +Cc: xenomai
On 04/15/2014 08:03 AM, Peter Howard wrote:
> On Fri, 2014-04-11 at 08:52 +1000, Peter Howard wrote:
>> On Fri, 2014-04-11 at 00:48 +0200, Gilles Chanteperdrix wrote:
>>> On 04/11/2014 12:34 AM, Peter Howard wrote:
>>>> On Fri, 2014-04-11 at 00:23 +0200, Gilles Chanteperdrix wrote:
>>>> (Stripping back conversation on this one - apologies if that's bad
>>>> etiquette for this list)
>>>>
>>>>> Attachment is better. Also please post the changes you made for omapL138
>>>>>
>>>>
>>>> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
>>>> index a075b3e..3d8bc59 100644
>>>> --- a/arch/arm/mach-davinci/Kconfig
>>>> +++ b/arch/arm/mach-davinci/Kconfig
>>>> @@ -41,6 +41,8 @@ config ARCH_DAVINCI_DA850
>>>> select ARCH_DAVINCI_DA8XX
>>>> select ARCH_HAS_CPUFREQ
>>>> select CP_INTC
>>>> + select IPIPE_ARM_KUSER_TSC if IPIPE
>>>> + select ARM_FCSE if IPIPE
>>>
>>> You may want to leave the choice of enabling or disabling FCSE to the user.
>>>
>>
>> Understood; at the moment the variance on max latency is really bad if
>> you don't enable FCSE. When I sort out the crashing issues I'll re-test
>> with it off.
>
> Well, FCSE turned out to be my problem.
>
> More specifically, FCSE and ARM_FCSE_BEST_EFFORT. Either a) disabling
> ARM_FCSE altogether, or b) selecting ARM_FCSE with ARM_FCSE_GUARENTEED
> gets rid of the crashes/panics with ipipe latency tracing enabled.
>
> So now things seem reasonably stable, I'll go through the full set of
> tests. Though I still can't do 'xeno-test -l "dohell -l /opt/ltp"' as
> ltp takes out the system without any ipipe/xenomai bits.
>
Ok, FCSE best effort is currently being validated on 3.14, so it may
well be broken. After all, the raw/* branches are work in progress.
--
Gilles.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-15 11:37 ` Gilles Chanteperdrix
@ 2014-04-15 21:59 ` Peter Howard
2014-04-15 22:25 ` Gilles Chanteperdrix
2014-04-22 23:02 ` Gilles Chanteperdrix
0 siblings, 2 replies; 57+ messages in thread
From: Peter Howard @ 2014-04-15 21:59 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On Tue, 2014-04-15 at 13:37 +0200, Gilles Chanteperdrix wrote:
> On 04/15/2014 08:03 AM, Peter Howard wrote:
> > On Fri, 2014-04-11 at 08:52 +1000, Peter Howard wrote:
> >> On Fri, 2014-04-11 at 00:48 +0200, Gilles Chanteperdrix wrote:
> >>> On 04/11/2014 12:34 AM, Peter Howard wrote:
> >>>> On Fri, 2014-04-11 at 00:23 +0200, Gilles Chanteperdrix wrote:
> >>>> (Stripping back conversation on this one - apologies if that's bad
> >>>> etiquette for this list)
> >>>>
> >>>>> Attachment is better. Also please post the changes you made for omapL138
> >>>>>
> >>>>
> >>>> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
> >>>> index a075b3e..3d8bc59 100644
> >>>> --- a/arch/arm/mach-davinci/Kconfig
> >>>> +++ b/arch/arm/mach-davinci/Kconfig
> >>>> @@ -41,6 +41,8 @@ config ARCH_DAVINCI_DA850
> >>>> select ARCH_DAVINCI_DA8XX
> >>>> select ARCH_HAS_CPUFREQ
> >>>> select CP_INTC
> >>>> + select IPIPE_ARM_KUSER_TSC if IPIPE
> >>>> + select ARM_FCSE if IPIPE
> >>>
> >>> You may want to leave the choice of enabling or disabling FCSE to the user.
> >>>
> >>
> >> Understood; at the moment the variance on max latency is really bad if
> >> you don't enable FCSE. When I sort out the crashing issues I'll re-test
> >> with it off.
> >
> > Well, FCSE turned out to be my problem.
> >
> > More specifically, FCSE and ARM_FCSE_BEST_EFFORT. Either a) disabling
> > ARM_FCSE altogether, or b) selecting ARM_FCSE with ARM_FCSE_GUARENTEED
> > gets rid of the crashes/panics with ipipe latency tracing enabled.
> >
> > So now things seem reasonably stable, I'll go through the full set of
> > tests. Though I still can't do 'xeno-test -l "dohell -l /opt/ltp"' as
> > ltp takes out the system without any ipipe/xenomai bits.
> >
> Ok, FCSE best effort is currently being validated on 3.14, so it may
> well be broken. After all, the raw/* branches are work in progress.
>
Note: selecting ARM_FCSE_BEST_EFFORT produces the same result on the
master branch too . . .
--
Peter Howard <pjh@northern-ridge.com.au>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-15 21:59 ` Peter Howard
@ 2014-04-15 22:25 ` Gilles Chanteperdrix
2014-04-16 0:58 ` Peter Howard
2014-04-22 23:02 ` Gilles Chanteperdrix
1 sibling, 1 reply; 57+ messages in thread
From: Gilles Chanteperdrix @ 2014-04-15 22:25 UTC (permalink / raw)
To: Peter Howard; +Cc: xenomai
On 04/15/2014 11:59 PM, Peter Howard wrote:
> On Tue, 2014-04-15 at 13:37 +0200, Gilles Chanteperdrix wrote:
>> On 04/15/2014 08:03 AM, Peter Howard wrote:
>>> On Fri, 2014-04-11 at 08:52 +1000, Peter Howard wrote:
>>>> On Fri, 2014-04-11 at 00:48 +0200, Gilles Chanteperdrix wrote:
>>>>> On 04/11/2014 12:34 AM, Peter Howard wrote:
>>>>>> On Fri, 2014-04-11 at 00:23 +0200, Gilles Chanteperdrix wrote:
>>>>>> (Stripping back conversation on this one - apologies if that's bad
>>>>>> etiquette for this list)
>>>>>>
>>>>>>> Attachment is better. Also please post the changes you made for omapL138
>>>>>>>
>>>>>>
>>>>>> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
>>>>>> index a075b3e..3d8bc59 100644
>>>>>> --- a/arch/arm/mach-davinci/Kconfig
>>>>>> +++ b/arch/arm/mach-davinci/Kconfig
>>>>>> @@ -41,6 +41,8 @@ config ARCH_DAVINCI_DA850
>>>>>> select ARCH_DAVINCI_DA8XX
>>>>>> select ARCH_HAS_CPUFREQ
>>>>>> select CP_INTC
>>>>>> + select IPIPE_ARM_KUSER_TSC if IPIPE
>>>>>> + select ARM_FCSE if IPIPE
>>>>>
>>>>> You may want to leave the choice of enabling or disabling FCSE to the user.
>>>>>
>>>>
>>>> Understood; at the moment the variance on max latency is really bad if
>>>> you don't enable FCSE. When I sort out the crashing issues I'll re-test
>>>> with it off.
>>>
>>> Well, FCSE turned out to be my problem.
>>>
>>> More specifically, FCSE and ARM_FCSE_BEST_EFFORT. Either a) disabling
>>> ARM_FCSE altogether, or b) selecting ARM_FCSE with ARM_FCSE_GUARENTEED
>>> gets rid of the crashes/panics with ipipe latency tracing enabled.
>>>
>>> So now things seem reasonably stable, I'll go through the full set of
>>> tests. Though I still can't do 'xeno-test -l "dohell -l /opt/ltp"' as
>>> ltp takes out the system without any ipipe/xenomai bits.
>>>
>> Ok, FCSE best effort is currently being validated on 3.14, so it may
>> well be broken. After all, the raw/* branches are work in progress.
>>
>
> Note: selecting ARM_FCSE_BEST_EFFORT produces the same result on the
> master branch too . . .
>
Could you turn CONFIG_ARM_FCSE_MESSAGES on and show us the messages you
get (with the 3.14 kernel, not the master branch)?
--
Gilles.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-15 22:25 ` Gilles Chanteperdrix
@ 2014-04-16 0:58 ` Peter Howard
2014-04-16 7:34 ` Gilles Chanteperdrix
0 siblings, 1 reply; 57+ messages in thread
From: Peter Howard @ 2014-04-16 0:58 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On Wed, 2014-04-16 at 00:25 +0200, Gilles Chanteperdrix wrote:
> On 04/15/2014 11:59 PM, Peter Howard wrote:
> > On Tue, 2014-04-15 at 13:37 +0200, Gilles Chanteperdrix wrote:
> >> On 04/15/2014 08:03 AM, Peter Howard wrote:
> >>> On Fri, 2014-04-11 at 08:52 +1000, Peter Howard wrote:
> >>>> On Fri, 2014-04-11 at 00:48 +0200, Gilles Chanteperdrix wrote:
> >>>>> On 04/11/2014 12:34 AM, Peter Howard wrote:
> >>>>>> On Fri, 2014-04-11 at 00:23 +0200, Gilles Chanteperdrix wrote:
> >>>>>> (Stripping back conversation on this one - apologies if that's bad
> >>>>>> etiquette for this list)
> >>>>>>
> >>>>>>> Attachment is better. Also please post the changes you made for omapL138
> >>>>>>>
> >>>>>>
> >>>>>> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
> >>>>>> index a075b3e..3d8bc59 100644
> >>>>>> --- a/arch/arm/mach-davinci/Kconfig
> >>>>>> +++ b/arch/arm/mach-davinci/Kconfig
> >>>>>> @@ -41,6 +41,8 @@ config ARCH_DAVINCI_DA850
> >>>>>> select ARCH_DAVINCI_DA8XX
> >>>>>> select ARCH_HAS_CPUFREQ
> >>>>>> select CP_INTC
> >>>>>> + select IPIPE_ARM_KUSER_TSC if IPIPE
> >>>>>> + select ARM_FCSE if IPIPE
> >>>>>
> >>>>> You may want to leave the choice of enabling or disabling FCSE to the user.
> >>>>>
> >>>>
> >>>> Understood; at the moment the variance on max latency is really bad if
> >>>> you don't enable FCSE. When I sort out the crashing issues I'll re-test
> >>>> with it off.
> >>>
> >>> Well, FCSE turned out to be my problem.
> >>>
> >>> More specifically, FCSE and ARM_FCSE_BEST_EFFORT. Either a) disabling
> >>> ARM_FCSE altogether, or b) selecting ARM_FCSE with ARM_FCSE_GUARENTEED
> >>> gets rid of the crashes/panics with ipipe latency tracing enabled.
> >>>
> >>> So now things seem reasonably stable, I'll go through the full set of
> >>> tests. Though I still can't do 'xeno-test -l "dohell -l /opt/ltp"' as
> >>> ltp takes out the system without any ipipe/xenomai bits.
> >>>
> >> Ok, FCSE best effort is currently being validated on 3.14, so it may
> >> well be broken. After all, the raw/* branches are work in progress.
> >>
> >
> > Note: selecting ARM_FCSE_BEST_EFFORT produces the same result on the
> > master branch too . . .
> >
>
> Could you turn CONFIG_ARM_FCSE_MESSAGES on and show us the messages you
> get (with the 3.14 kernel, not the master branch)?
>
OK - sadly there's not much, but here's what I get from the "dies at, or
immediately after, login" rootfs. That also has all ipipe debugging,
and stack unwinding, enabled.
Arago Project http://arago-project.org arago ttyS2
Arago 2011.06 arago ttyS2
arago login: Unable to handle kernel paging request at virtual address e5902f10
fcse pid: 0, 0x00000000, hw pid: 0x00000000
pgd = c6934000, hw pgd = c6934000
[e5902f10] *pgd=00000000
Internal error: Oops: 80000005 [#1] PREEMPT ARM
Modules linked in:
CPU: 0 PID: 2456 Comm: matrix_guiE Not tainted 3.12.0-ipipe-12092-g1f7fa99-dirt7
task: c7221b00 ti: c7192000 task.ti: c7192000
PC is at 0xe5902f10
Unable to handle kernel paging request at virtual address ebff3ace
fcse pid: 93, 0xba000000, hw pid: 0xba000000
pgd = c6908000, hw pgd = c6908000
[ebff3ace] *pgd=00000000
Internal error: Oops: 80000005 [#2] PREEMPT ARM
Modules linked in:
CPU: 0 PID: 2429 Comm: klogd Not tainted 3.12.0-ipipe-12092-g1f7fa99-dirty #47
task: c7226900 ti: c7180000 task.ti: c7180000
PC is at 0xebff3ace
Unable to handle kernel paging request at virtual address 8148c464
fcse pid: 0, 0x00000000, hw pid: 0x00000000
pgd = c6934000, hw pgd = c6934000
[8148c464] *pgd=00000000
That goes on for a while longer, but it's just variations on the same
error.
(Without FCSE debugging enabled, you just get garbage and lockup)
If I can get anything useful out of my other rootfs setup I'll post
that.
--
Peter Howard <pjh@northern-ridge.com.au>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-16 0:58 ` Peter Howard
@ 2014-04-16 7:34 ` Gilles Chanteperdrix
2014-04-17 0:30 ` Peter Howard
0 siblings, 1 reply; 57+ messages in thread
From: Gilles Chanteperdrix @ 2014-04-16 7:34 UTC (permalink / raw)
To: Peter Howard; +Cc: xenomai
On 04/16/2014 02:58 AM, Peter Howard wrote:
> On Wed, 2014-04-16 at 00:25 +0200, Gilles Chanteperdrix wrote:
>> On 04/15/2014 11:59 PM, Peter Howard wrote:
>>> On Tue, 2014-04-15 at 13:37 +0200, Gilles Chanteperdrix wrote:
>>>> On 04/15/2014 08:03 AM, Peter Howard wrote:
>>>>> On Fri, 2014-04-11 at 08:52 +1000, Peter Howard wrote:
>>>>>> On Fri, 2014-04-11 at 00:48 +0200, Gilles Chanteperdrix wrote:
>>>>>>> On 04/11/2014 12:34 AM, Peter Howard wrote:
>>>>>>>> On Fri, 2014-04-11 at 00:23 +0200, Gilles Chanteperdrix wrote:
>>>>>>>> (Stripping back conversation on this one - apologies if that's bad
>>>>>>>> etiquette for this list)
>>>>>>>>
>>>>>>>>> Attachment is better. Also please post the changes you made for omapL138
>>>>>>>>>
>>>>>>>>
>>>>>>>> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
>>>>>>>> index a075b3e..3d8bc59 100644
>>>>>>>> --- a/arch/arm/mach-davinci/Kconfig
>>>>>>>> +++ b/arch/arm/mach-davinci/Kconfig
>>>>>>>> @@ -41,6 +41,8 @@ config ARCH_DAVINCI_DA850
>>>>>>>> select ARCH_DAVINCI_DA8XX
>>>>>>>> select ARCH_HAS_CPUFREQ
>>>>>>>> select CP_INTC
>>>>>>>> + select IPIPE_ARM_KUSER_TSC if IPIPE
>>>>>>>> + select ARM_FCSE if IPIPE
>>>>>>>
>>>>>>> You may want to leave the choice of enabling or disabling FCSE to the user.
>>>>>>>
>>>>>>
>>>>>> Understood; at the moment the variance on max latency is really bad if
>>>>>> you don't enable FCSE. When I sort out the crashing issues I'll re-test
>>>>>> with it off.
>>>>>
>>>>> Well, FCSE turned out to be my problem.
>>>>>
>>>>> More specifically, FCSE and ARM_FCSE_BEST_EFFORT. Either a) disabling
>>>>> ARM_FCSE altogether, or b) selecting ARM_FCSE with ARM_FCSE_GUARENTEED
>>>>> gets rid of the crashes/panics with ipipe latency tracing enabled.
>>>>>
>>>>> So now things seem reasonably stable, I'll go through the full set of
>>>>> tests. Though I still can't do 'xeno-test -l "dohell -l /opt/ltp"' as
>>>>> ltp takes out the system without any ipipe/xenomai bits.
>>>>>
>>>> Ok, FCSE best effort is currently being validated on 3.14, so it may
>>>> well be broken. After all, the raw/* branches are work in progress.
>>>>
>>>
>>> Note: selecting ARM_FCSE_BEST_EFFORT produces the same result on the
>>> master branch too . . .
>>>
>>
>> Could you turn CONFIG_ARM_FCSE_MESSAGES on and show us the messages you
>> get (with the 3.14 kernel, not the master branch)?
>>
>
> OK - sadly there's not much, but here's what I get from the "dies at, or
> immediately after, login" rootfs. That also has all ipipe debugging,
> and stack unwinding, enabled.
You should enable CONFIG_DEBUG_USER and boot with the user_debug=29
kernel parameter. Disabling stack unwinding enable frame pointers which
usually lead to better stack traces.
>
> Arago Project http://arago-project.org arago ttyS2
>
> Arago 2011.06 arago ttyS2
>
> arago login: Unable to handle kernel paging request at virtual address e5902f10
> fcse pid: 0, 0x00000000, hw pid: 0x00000000
> pgd = c6934000, hw pgd = c6934000
> [e5902f10] *pgd=00000000
> Internal error: Oops: 80000005 [#1] PREEMPT ARM
> Modules linked in:
> CPU: 0 PID: 2456 Comm: matrix_guiE Not tainted 3.12.0-ipipe-12092-g1f7fa99-dirt7
Please do not base your work on the 3.12 kernel: the previous released
I-pipe was 3.10 and the next will be 3.14.
--
Gilles.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-16 7:34 ` Gilles Chanteperdrix
@ 2014-04-17 0:30 ` Peter Howard
2014-04-17 11:37 ` Gilles Chanteperdrix
0 siblings, 1 reply; 57+ messages in thread
From: Peter Howard @ 2014-04-17 0:30 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On Wed, 2014-04-16 at 09:34 +0200, Gilles Chanteperdrix wrote:
> On 04/16/2014 02:58 AM, Peter Howard wrote:
> > On Wed, 2014-04-16 at 00:25 +0200, Gilles Chanteperdrix wrote:
> >> On 04/15/2014 11:59 PM, Peter Howard wrote:
> >>> On Tue, 2014-04-15 at 13:37 +0200, Gilles Chanteperdrix wrote:
> >>>> On 04/15/2014 08:03 AM, Peter Howard wrote:
> >>>>> On Fri, 2014-04-11 at 08:52 +1000, Peter Howard wrote:
> >>>>>> On Fri, 2014-04-11 at 00:48 +0200, Gilles Chanteperdrix wrote:
> >>>>>>> On 04/11/2014 12:34 AM, Peter Howard wrote:
> >>>>>>>> On Fri, 2014-04-11 at 00:23 +0200, Gilles Chanteperdrix wrote:
> >>>>>>>> (Stripping back conversation on this one - apologies if that's bad
> >>>>>>>> etiquette for this list)
> >>>>>>>>
> >>>>>>>>> Attachment is better. Also please post the changes you made for omapL138
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
> >>>>>>>> index a075b3e..3d8bc59 100644
> >>>>>>>> --- a/arch/arm/mach-davinci/Kconfig
> >>>>>>>> +++ b/arch/arm/mach-davinci/Kconfig
> >>>>>>>> @@ -41,6 +41,8 @@ config ARCH_DAVINCI_DA850
> >>>>>>>> select ARCH_DAVINCI_DA8XX
> >>>>>>>> select ARCH_HAS_CPUFREQ
> >>>>>>>> select CP_INTC
> >>>>>>>> + select IPIPE_ARM_KUSER_TSC if IPIPE
> >>>>>>>> + select ARM_FCSE if IPIPE
> >>>>>>>
> >>>>>>> You may want to leave the choice of enabling or disabling FCSE to the user.
> >>>>>>>
> >>>>>>
> >>>>>> Understood; at the moment the variance on max latency is really bad if
> >>>>>> you don't enable FCSE. When I sort out the crashing issues I'll re-test
> >>>>>> with it off.
> >>>>>
> >>>>> Well, FCSE turned out to be my problem.
> >>>>>
> >>>>> More specifically, FCSE and ARM_FCSE_BEST_EFFORT. Either a) disabling
> >>>>> ARM_FCSE altogether, or b) selecting ARM_FCSE with ARM_FCSE_GUARENTEED
> >>>>> gets rid of the crashes/panics with ipipe latency tracing enabled.
> >>>>>
> >>>>> So now things seem reasonably stable, I'll go through the full set of
> >>>>> tests. Though I still can't do 'xeno-test -l "dohell -l /opt/ltp"' as
> >>>>> ltp takes out the system without any ipipe/xenomai bits.
> >>>>>
> >>>> Ok, FCSE best effort is currently being validated on 3.14, so it may
> >>>> well be broken. After all, the raw/* branches are work in progress.
> >>>>
> >>>
> >>> Note: selecting ARM_FCSE_BEST_EFFORT produces the same result on the
> >>> master branch too . . .
> >>>
> >>
> >> Could you turn CONFIG_ARM_FCSE_MESSAGES on and show us the messages you
> >> get (with the 3.14 kernel, not the master branch)?
> >>
> >
> > OK - sadly there's not much, but here's what I get from the "dies at, or
> > immediately after, login" rootfs. That also has all ipipe debugging,
> > and stack unwinding, enabled.
>
> You should enable CONFIG_DEBUG_USER and boot with the user_debug=29
> kernel parameter. Disabling stack unwinding enable frame pointers which
> usually lead to better stack traces.
>
> >
> > Arago Project http://arago-project.org arago ttyS2
> >
> > Arago 2011.06 arago ttyS2
> >
> > arago login: Unable to handle kernel paging request at virtual address e5902f10
> > fcse pid: 0, 0x00000000, hw pid: 0x00000000
> > pgd = c6934000, hw pgd = c6934000
> > [e5902f10] *pgd=00000000
> > Internal error: Oops: 80000005 [#1] PREEMPT ARM
> > Modules linked in:
> > CPU: 0 PID: 2456 Comm: matrix_guiE Not tainted 3.12.0-ipipe-12092-g1f7fa99-dirt7
>
> Please do not base your work on the 3.12 kernel: the previous released
> I-pipe was 3.10 and the next will be 3.14.
OK, I now get a decent (long) stack trace on failure:
Arago Project http://arago-project.org arago ttyS2
Arago 2011.06 arago ttyS2
arago login: Unable to handle kernel paging request at virtual address e154000c
fcse pid: 0, 0x00000000, hw pid: 0x00000000
pgd = c71d0000, hw pgd = c71d0000
[e154000c] *pgd=00000000
Unable to handle kernel paging request at virtual address e154000c
fcse pid: 0, 0x00000000, hw pid: 0x00000000
pgd = c71d0000, hw pgd = c71d0000
[e154000c] *pgd=00000000
------------[ cut here ]------------
WARNING: CPU: 0 PID: 0 at kernel/ipipe/core.c:605 __ipipe_lock_irq+0x160/0x184()
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 3.14.0-ipipe-38808-gd8d4639-dirty #56
Backtrace:
[<c000d228>] (dump_backtrace) from [<c000d7d0>] (show_stack+0x20/0x24)
r6:c04cc8d0 r5:0000025d r4:00000000 r3:00000000
[<c000d7b0>] (show_stack) from [<c03fa760>] (dump_stack+0x20/0x28)
[<c03fa740>] (dump_stack) from [<c001f634>] (warn_slowpath_common+0x78/0x98)
[<c001f5bc>] (warn_slowpath_common) from [<c001f680>] (warn_slowpath_null+0x2c/0x34)
r8:00000001 r7:c05b6b80 r6:c0580a98 r5:c059bee6 r4:00000010
[<c001f654>] (warn_slowpath_null) from [<c008ab40>] (__ipipe_lock_irq+0x160/0x184)
[<c008a9e0>] (__ipipe_lock_irq) from [<c001b0b0>] (cp_intc_mask_irq+0x68/0x7c)
r8:00000001 r7:c05b6b80 r6:c0580a98 r5:00000010 r4:c0575e50 r3:c05b6ba0
[<c001b048>] (cp_intc_mask_irq) from [<c0065b98>] (handle_edge_irq+0x124/0x170)
r4:c0575e50 r3:c001b048
[<c0065a74>] (handle_edge_irq) from [<c0061560>] (generic_handle_irq+0x28/0x3c)
r4:c058afdc r3:c0065a74
[<c0061538>] (generic_handle_irq) from [<c000a514>] (handle_IRQ+0x40/0x94)
[<c000a4d4>] (handle_IRQ) from [<c000f644>] (__ipipe_do_IRQ+0x1c/0x24)
r6:00000000 r5:00000011 r4:00000010 r3:c000f628
[<c000f628>] (__ipipe_do_IRQ) from [<c008bcb8>] (__ipipe_do_sync_stage+0x218/0x2f4)
[<c008baa0>] (__ipipe_do_sync_stage) from [<c008c580>] (ipipe_unstall_root+0x80/0x88)
r10:00000805 r9:c0569108 r8:c055f110 r7:60000013 r6:c055e000 r5:00000000
r4:c055f110
[<c008c500>] (ipipe_unstall_root) from [<c0011f30>] (do_page_fault+0x298/0x344)
[<c0011c98>] (do_page_fault) from [<c0012130>] (do_translation_fault+0xd8/0x144)
r10:c025fad4 r9:00000004 r8:c055f110 r7:00000005 r6:00000805 r5:c055f110
r4:60000013
[<c0012058>] (do_translation_fault) from [<c0008794>] (do_DataAbort+0x50/0x160)
r7:00000005 r6:c056a154 r5:00000805 r4:60000013
[<c0008744>] (do_DataAbort) from [<c000e530>] (__dabt_svc+0x50/0x80)
Exception stack(0xc055f110 to 0xc055f158)
f100: 60000013 00000000 c055f300 00000000
f120: 00000003 01000000 60000013 c059dc5c 00000801 00000004 c025fad4 c055f174
f140: 00000002 c055f158 c0014b20 c0014688 40000013 ffffffff
r10:c025fad4 r8:00000801 r7:c055f144 r6:ffffffff r5:40000013 r4:c0014688
[<c0014638>] (do_alignment_ldrstr) from [<c0014b20>] (do_alignment+0x1a0/0x928)
r6:60000013 r5:00000000 r4:c055f300 r3:c0014638
[<c0014980>] (do_alignment) from [<c0008794>] (do_DataAbort+0x50/0x160)
r10:80000005 r9:c0569fd8 r8:c055f300 r7:00000001 r6:c056a154 r5:00000801
r4:60000013
[<c0008744>] (do_DataAbort) from [<c000e530>] (__dabt_svc+0x50/0x80)
Exception stack(0xc055f300 to 0xc055f348)
f300: c055f364 ffffffe4 ffffffe4 00000000 00000000 e154000c c055f364 60000013
f320: c73dd860 c0569fd8 80000005 c055f394 0000001c c055f34c c0400da4 c025fad8
f340: 00000013 ffffffff
r10:80000005 r8:c73dd860 r7:c055f334 r6:ffffffff r5:00000013 r4:c025fad4
[<c000dbc8>] (is_valid_bugaddr) from [<c024f310>] (report_bug+0x18/0xf8)
r6:e154000c r5:c055f510 r4:c059db64
[<c024f2f8>] (report_bug) from [<c000d984>] (die+0x1b0/0x298)
r8:c73dd860 r7:60000013 r6:c04c2ac8 r5:c055f510 r4:c059db64 r3:80000013
[<c000d7d4>] (die) from [<c0011c78>] (__do_kernel_fault+0x74/0x94)
r10:00000001 r9:00000000 r8:c73dd860 r7:80000005 r6:00000000 r5:e154000c
r4:c055f510
[<c0011c04>] (__do_kernel_fault) from [<c001202c>] (do_bad_area+0x50/0x7c)
r8:c055f510 r7:00000000 r6:80000005 r5:c055f510 r4:e154000c r3:c055f510
[<c0011fdc>] (do_bad_area) from [<c001211c>] (do_translation_fault+0xc4/0x144)
[<c0012058>] (do_translation_fault) from [<c00088ec>] (do_PrefetchAbort+0x48/0x148)
r7:c056a154 r6:00000050 r5:e154000c r4:00000005
[<c00088a4>] (do_PrefetchAbort) from [<c000e750>] (__pabt_svc+0x50/0xa0)
Exception stack(0xc055f510 to 0xc055f558)
f500: c0574cc0 c7837a00 00000001 e154000e
f520: c7837a00 00000001 c0574cc0 60000013 00000000 00000000 00000001 c055f574
f540: 00000418 c055f558 c004d518 e154000c 80000013 ffffffff
r10:00000001 r8:00000000 r7:c055f544 r6:ffffffff r5:80000013 r4:e154000c
[<c004d4dc>] (enqueue_task) from [<c004d638>] (activate_task+0x38/0x3c)
r6:00000001 r5:00000080 r4:c7837a00 r3:00000001
[<c004d600>] (activate_task) from [<c004de78>] (try_to_wake_up+0xf0/0x1cc)
[<c004dd88>] (try_to_wake_up) from [<c004df70>] (default_wake_function+0x1c/0x20)
r8:00000000 r7:c7097ea8 r6:00000000 r5:c0054fbc r4:c717de24 r3:00000000
[<c004df54>] (default_wake_function) from [<c0054fd8>] (autoremove_wake_function+0x1c/0x44)
[<c0054fbc>] (autoremove_wake_function) from [<c005581c>] (__wake_up_common+0x6c/0xa8)
r4:c7097e9c r3:00000000
[<c00557b0>] (__wake_up_common) from [<c0055b50>] (__wake_up+0x70/0xe0)
r10:60000013 r9:c057e754 r8:00000001 r7:00000001 r6:c7097ea8 r5:00000000
r4:00000001
[<c0055ae0>] (__wake_up) from [<c02fa6f4>] (mmc_wait_data_done+0x34/0x38)
r10:c055e000 r8:00000000 r7:00000000 r6:00000004 r5:00000000 r4:c7097ec0
[<c02fa6c0>] (mmc_wait_data_done) from [<c02f962c>] (mmc_request_done+0x44/0x68)
[<c02f95e8>] (mmc_request_done) from [<c030de40>] (mmc_davinci_irq+0x224/0x410)
[<c030dc1c>] (mmc_davinci_irq) from [<c030e1a0>] (mmc_davinci_start_command+0x174/0x220)
r8:00000000 r7:00000094 r6:c7170dcc r5:0000001c r4:c7097ec0
[<c030e02c>] (mmc_davinci_start_command) from [<c030df58>] (mmc_davinci_irq+0x33c/0x410)
r7:00000001 r6:00001001 r5:c7170e00 r4:c7097ec0
[<c030dc1c>] (mmc_davinci_irq) from [<c0061d4c>] (handle_irq_event_percpu+0x7c/0x3dc)
r8:00000000 r7:00000010 r6:c0580a98 r5:c7161200 r4:c7161200
[<c0061cd0>] (handle_irq_event_percpu) from [<c006210c>] (handle_irq_event+0x60/0x94)
r10:00000002 r9:c05b6ba0 r8:00000001 r7:c05b6b80 r6:c0580a98 r5:c7161200
r4:c0575e50
[<c00620ac>] (handle_irq_event) from [<c0065b08>] (handle_edge_irq+0x94/0x170)
r5:00000010 r4:c0575e50
[<c0065a74>] (handle_edge_irq) from [<c0061560>] (generic_handle_irq+0x28/0x3c)
r4:c058afdc r3:c0065a74
[<c0061538>] (generic_handle_irq) from [<c000a514>] (handle_IRQ+0x40/0x94)
[<c000a4d4>] (handle_IRQ) from [<c000f644>] (__ipipe_do_IRQ+0x1c/0x24)
r6:00000000 r5:00000011 r4:00000010 r3:c000f628
[<c000f628>] (__ipipe_do_IRQ) from [<c008bcb8>] (__ipipe_do_sync_stage+0x218/0x2f4)
[<c008baa0>] (__ipipe_do_sync_stage) from [<c008c580>] (ipipe_unstall_root+0x80/0x88)
r10:00000805 r9:c0569108 r8:c055f908 r7:60000013 r6:c055e000 r5:00000000
r4:c055f908
[<c008c500>] (ipipe_unstall_root) from [<c0011f30>] (do_page_fault+0x298/0x344)
[<c0011c98>] (do_page_fault) from [<c0012130>] (do_translation_fault+0xd8/0x144)
r10:c025fad4 r9:00000004 r8:c055f908 r7:00000005 r6:00000805 r5:c055f908
r4:60000013
[<c0012058>] (do_translation_fault) from [<c0008794>] (do_DataAbort+0x50/0x160)
r7:00000005 r6:c056a154 r5:00000805 r4:60000013
[<c0008744>] (do_DataAbort) from [<c000e530>] (__dabt_svc+0x50/0x80)
Exception stack(0xc055f908 to 0xc055f950)
f900: 60000013 00000000 c055faf8 00000000 00000003 01000000
f920: 60000013 c059dc5c 00000801 00000004 c025fad4 c055f96c 00000001 c055f950
f940: c0014b20 c0014688 40000013 ffffffff
r10:c025fad4 r8:00000801 r7:c055f93c r6:ffffffff r5:40000013 r4:c0014688
[<c0014638>] (do_alignment_ldrstr) from [<c0014b20>] (do_alignment+0x1a0/0x928)
r6:60000013 r5:00000000 r4:c055faf8 r3:c0014638
[<c0014980>] (do_alignment) from [<c0008794>] (do_DataAbort+0x50/0x160)
r10:80000005 r9:c0569fd8 r8:c055faf8 r7:00000001 r6:c056a154 r5:00000801
r4:60000013
[<c0008744>] (do_DataAbort) from [<c000e530>] (__dabt_svc+0x50/0x80)
Exception stack(0xc055faf8 to 0xc055fb40)
fae0: c055fb5c ffffffe4
fb00: ffffffe4 00000000 00000000 e154000c c055fb5c 60000013 c73dd860 c0569fd8
fb20: 80000005 c055fb8c 0000001c c055fb44 c0400da4 c025fad8 00000013 ffffffff
r10:80000005 r8:c73dd860 r7:c055fb2c r6:ffffffff r5:00000013 r4:c025fad4
[<c000dbc8>] (is_valid_bugaddr) from [<c024f310>] (report_bug+0x18/0xf8)
r6:e154000c r5:c055fd08 r4:c059db64
[<c024f2f8>] (report_bug) from [<c000d984>] (die+0x1b0/0x298)
r8:c73dd860 r7:60000013 r6:c04c2ac8 r5:c055fd08 r4:c059db64 r3:80000013
[<c000d7d4>] (die) from [<c0011c78>] (__do_kernel_fault+0x74/0x94)
r10:00000002 r9:0000000c r8:c73dd860 r7:80000005 r6:00000000 r5:e154000c
r4:c055fd08
[<c0011c04>] (__do_kernel_fault) from [<c001202c>] (do_bad_area+0x50/0x7c)
r8:c055fd08 r7:00000000 r6:80000005 r5:c055fd08 r4:e154000c r3:c055fd08
[<c0011fdc>] (do_bad_area) from [<c001211c>] (do_translation_fault+0xc4/0x144)
[<c0012058>] (do_translation_fault) from [<c00088ec>] (do_PrefetchAbort+0x48/0x148)
r7:c056a154 r6:00000050 r5:e154000c r4:00000005
[<c00088a4>] (do_PrefetchAbort) from [<c000e750>] (__pabt_svc+0x50/0xa0)
Exception stack(0xc055fd08 to 0xc055fd50)
fd00: c0574cc0 c7834740 00000001 e154000e c7834740 00000001
fd20: c0574cc0 60000013 00000000 0000000c 00000002 c055fd6c 00000418 c055fd50
fd40: c004d518 e154000c 80000013 ffffffff
r10:00000002 r8:00000000 r7:c055fd3c r6:ffffffff r5:80000013 r4:e154000c
[<c004d4dc>] (enqueue_task) from [<c004d638>] (activate_task+0x38/0x3c)
r6:00000001 r5:00000080 r4:c7834740 r3:00000001
[<c004d600>] (activate_task) from [<c004de78>] (try_to_wake_up+0xf0/0x1cc)
[<c004dd88>] (try_to_wake_up) from [<c004dfa8>] (wake_up_process+0x34/0x50)
r8:00000003 r7:00000000 r6:c055e000 r5:00000002 r4:c7834740 r3:00000001
[<c004df74>] (wake_up_process) from [<c002417c>] (wakeup_softirqd+0x34/0x3c)
r4:60000013 r3:00000001
[<c0024148>] (wakeup_softirqd) from [<c0024460>] (__do_softirq+0x204/0x364)
[<c002425c>] (__do_softirq) from [<c0024944>] (irq_exit+0xc0/0x110)
r10:00000002 r9:c05b6ba0 r8:00000001 r7:c05b6b80 r6:00000000 r5:00000022
r4:c055e000
[<c0024884>] (irq_exit) from [<c000a518>] (handle_IRQ+0x44/0x94)
r4:c058afdc r3:c0065a74
[<c000a4d4>] (handle_IRQ) from [<c000f644>] (__ipipe_do_IRQ+0x1c/0x24)
r6:00000000 r5:00000023 r4:00000022 r3:c000f628
[<c000f628>] (__ipipe_do_IRQ) from [<c008bcb8>] (__ipipe_do_sync_stage+0x218/0x2f4)
[<c008baa0>] (__ipipe_do_sync_stage) from [<c008be54>] (__ipipe_do_sync_pipeline+0xc0/0x10c)
r10:00002340 r9:0000119c r8:c05b6b80 r7:c057e754 r6:c05b6ba0 r5:c05b6ba0
r4:c057e754
[<c008bd94>] (__ipipe_do_sync_pipeline) from [<c008c0cc>] (__ipipe_dispatch_irq+0x22c/0x2e0)
r10:c057e754 r9:c059c464 r8:c057e750 r7:00000000 r6:00000023 r5:c057e754
r4:00000022 r3:c05b6ba0
[<c008bea0>] (__ipipe_dispatch_irq) from [<c00086dc>] (__ipipe_grab_irq+0x48/0xb0)
r10:c059c464 r8:00000000 r7:c055ff5c r6:c057e754 r5:c055ff28 r4:00000022
[<c0008694>] (__ipipe_grab_irq) from [<c000e5b0>] (__irq_svc+0x50/0x9c)
Exception stack(0xc055ff28 to 0xc055ff70)
ff20: 00000000 00000000 62240000 00000000 c055e000 c057e754
ff40: 60000013 c0566094 00000000 c059c464 c059c464 c055ff9c c0580b10 c055ff70
ff60: c008e214 c00613f0 60000013 ffffffff
r6:febfd000 r5:60000013 r4:c00613f0 r3:c008e214
[<c00612c8>] (cpu_startup_entry) from [<c03f8f94>] (rest_init+0x80/0x98)
r10:c7ffc980 r9:41069265 r8:c0566000 r7:c0554510 r6:c059d9c0 r5:ffffffff
r4:00000002 r3:00000001
[<c03f8f14>] (rest_init) from [<c0528ae8>] (start_kernel+0x364/0x3c8)
r4:c0566c68 r3:60000053
[<c0528784>] (start_kernel) from [<c0008040>] (0xc0008040)
---[ end trace 9b973359c02939c1 ]---
--
Peter Howard <pjh@northern-ridge.com.au>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-17 0:30 ` Peter Howard
@ 2014-04-17 11:37 ` Gilles Chanteperdrix
0 siblings, 0 replies; 57+ messages in thread
From: Gilles Chanteperdrix @ 2014-04-17 11:37 UTC (permalink / raw)
To: Peter Howard; +Cc: xenomai
On 04/17/2014 02:30 AM, Peter Howard wrote:
> On Wed, 2014-04-16 at 09:34 +0200, Gilles Chanteperdrix wrote:
>> On 04/16/2014 02:58 AM, Peter Howard wrote:
>>> On Wed, 2014-04-16 at 00:25 +0200, Gilles Chanteperdrix wrote:
>>>> On 04/15/2014 11:59 PM, Peter Howard wrote:
>>>>> On Tue, 2014-04-15 at 13:37 +0200, Gilles Chanteperdrix wrote:
>>>>>> On 04/15/2014 08:03 AM, Peter Howard wrote:
>>>>>>> On Fri, 2014-04-11 at 08:52 +1000, Peter Howard wrote:
>>>>>>>> On Fri, 2014-04-11 at 00:48 +0200, Gilles Chanteperdrix wrote:
>>>>>>>>> On 04/11/2014 12:34 AM, Peter Howard wrote:
>>>>>>>>>> On Fri, 2014-04-11 at 00:23 +0200, Gilles Chanteperdrix wrote:
>>>>>>>>>> (Stripping back conversation on this one - apologies if that's bad
>>>>>>>>>> etiquette for this list)
>>>>>>>>>>
>>>>>>>>>>> Attachment is better. Also please post the changes you made for omapL138
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
>>>>>>>>>> index a075b3e..3d8bc59 100644
>>>>>>>>>> --- a/arch/arm/mach-davinci/Kconfig
>>>>>>>>>> +++ b/arch/arm/mach-davinci/Kconfig
>>>>>>>>>> @@ -41,6 +41,8 @@ config ARCH_DAVINCI_DA850
>>>>>>>>>> select ARCH_DAVINCI_DA8XX
>>>>>>>>>> select ARCH_HAS_CPUFREQ
>>>>>>>>>> select CP_INTC
>>>>>>>>>> + select IPIPE_ARM_KUSER_TSC if IPIPE
>>>>>>>>>> + select ARM_FCSE if IPIPE
>>>>>>>>>
>>>>>>>>> You may want to leave the choice of enabling or disabling FCSE to the user.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Understood; at the moment the variance on max latency is really bad if
>>>>>>>> you don't enable FCSE. When I sort out the crashing issues I'll re-test
>>>>>>>> with it off.
>>>>>>>
>>>>>>> Well, FCSE turned out to be my problem.
>>>>>>>
>>>>>>> More specifically, FCSE and ARM_FCSE_BEST_EFFORT. Either a) disabling
>>>>>>> ARM_FCSE altogether, or b) selecting ARM_FCSE with ARM_FCSE_GUARENTEED
>>>>>>> gets rid of the crashes/panics with ipipe latency tracing enabled.
>>>>>>>
>>>>>>> So now things seem reasonably stable, I'll go through the full set of
>>>>>>> tests. Though I still can't do 'xeno-test -l "dohell -l /opt/ltp"' as
>>>>>>> ltp takes out the system without any ipipe/xenomai bits.
>>>>>>>
>>>>>> Ok, FCSE best effort is currently being validated on 3.14, so it may
>>>>>> well be broken. After all, the raw/* branches are work in progress.
>>>>>>
>>>>>
>>>>> Note: selecting ARM_FCSE_BEST_EFFORT produces the same result on the
>>>>> master branch too . . .
>>>>>
>>>>
>>>> Could you turn CONFIG_ARM_FCSE_MESSAGES on and show us the messages you
>>>> get (with the 3.14 kernel, not the master branch)?
>>>>
>>>
>>> OK - sadly there's not much, but here's what I get from the "dies at, or
>>> immediately after, login" rootfs. That also has all ipipe debugging,
>>> and stack unwinding, enabled.
>>
>> You should enable CONFIG_DEBUG_USER and boot with the user_debug=29
>> kernel parameter. Disabling stack unwinding enable frame pointers which
>> usually lead to better stack traces.
>>
>>>
>>> Arago Project http://arago-project.org arago ttyS2
>>>
>>> Arago 2011.06 arago ttyS2
>>>
>>> arago login: Unable to handle kernel paging request at virtual address e5902f10
>>> fcse pid: 0, 0x00000000, hw pid: 0x00000000
>>> pgd = c6934000, hw pgd = c6934000
>>> [e5902f10] *pgd=00000000
>>> Internal error: Oops: 80000005 [#1] PREEMPT ARM
>>> Modules linked in:
>>> CPU: 0 PID: 2456 Comm: matrix_guiE Not tainted 3.12.0-ipipe-12092-g1f7fa99-dirt7
>>
>> Please do not base your work on the 3.12 kernel: the previous released
>> I-pipe was 3.10 and the next will be 3.14.
>
> OK, I now get a decent (long) stack trace on failure:
>
> Arago Project http://arago-project.org arago ttyS2
>
> Arago 2011.06 arago ttyS2
>
> arago login: Unable to handle kernel paging request at virtual address e154000c
> fcse pid: 0, 0x00000000, hw pid: 0x00000000
> pgd = c71d0000, hw pgd = c71d0000
> [e154000c] *pgd=00000000
> Unable to handle kernel paging request at virtual address e154000c
> fcse pid: 0, 0x00000000, hw pid: 0x00000000
> pgd = c71d0000, hw pgd = c71d0000
> [e154000c] *pgd=00000000
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 0 at kernel/ipipe/core.c:605 __ipipe_lock_irq+0x160/0x184()
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper Not tainted 3.14.0-ipipe-38808-gd8d4639-dirty #56
> Backtrace:
> [<c000d228>] (dump_backtrace) from [<c000d7d0>] (show_stack+0x20/0x24)
> r6:c04cc8d0 r5:0000025d r4:00000000 r3:00000000
> [<c000d7b0>] (show_stack) from [<c03fa760>] (dump_stack+0x20/0x28)
> [<c03fa740>] (dump_stack) from [<c001f634>] (warn_slowpath_common+0x78/0x98)
> [<c001f5bc>] (warn_slowpath_common) from [<c001f680>] (warn_slowpath_null+0x2c/0x34)
> r8:00000001 r7:c05b6b80 r6:c0580a98 r5:c059bee6 r4:00000010
> [<c001f654>] (warn_slowpath_null) from [<c008ab40>] (__ipipe_lock_irq+0x160/0x184)
> [<c008a9e0>] (__ipipe_lock_irq) from [<c001b0b0>] (cp_intc_mask_irq+0x68/0x7c)
> r8:00000001 r7:c05b6b80 r6:c0580a98 r5:00000010 r4:c0575e50 r3:c05b6ba0
> [<c001b048>] (cp_intc_mask_irq) from [<c0065b98>] (handle_edge_irq+0x124/0x170)
> r4:c0575e50 r3:c001b048
> [<c0065a74>] (handle_edge_irq) from [<c0061560>] (generic_handle_irq+0x28/0x3c)
> r4:c058afdc r3:c0065a74
As I said, and as explained in the howto, you do not need to call
ipipe_lock_irq in the "mask" callback for an edge irq, you only need to
do that for fasteoi irqs.
The rest seems to be a mix between several issues. Could you enable FCSE
messages?
--
Gilles.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-15 21:59 ` Peter Howard
2014-04-15 22:25 ` Gilles Chanteperdrix
@ 2014-04-22 23:02 ` Gilles Chanteperdrix
2014-04-23 1:45 ` Peter Howard
1 sibling, 1 reply; 57+ messages in thread
From: Gilles Chanteperdrix @ 2014-04-22 23:02 UTC (permalink / raw)
To: Peter Howard; +Cc: xenomai
On 04/15/2014 11:59 PM, Peter Howard wrote:
> On Tue, 2014-04-15 at 13:37 +0200, Gilles Chanteperdrix wrote:
>> On 04/15/2014 08:03 AM, Peter Howard wrote:
>>> On Fri, 2014-04-11 at 08:52 +1000, Peter Howard wrote:
>>>> On Fri, 2014-04-11 at 00:48 +0200, Gilles Chanteperdrix wrote:
>>>>> On 04/11/2014 12:34 AM, Peter Howard wrote:
>>>>>> On Fri, 2014-04-11 at 00:23 +0200, Gilles Chanteperdrix wrote:
>>>>>> (Stripping back conversation on this one - apologies if that's bad
>>>>>> etiquette for this list)
>>>>>>
>>>>>>> Attachment is better. Also please post the changes you made for omapL138
>>>>>>>
>>>>>>
>>>>>> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
>>>>>> index a075b3e..3d8bc59 100644
>>>>>> --- a/arch/arm/mach-davinci/Kconfig
>>>>>> +++ b/arch/arm/mach-davinci/Kconfig
>>>>>> @@ -41,6 +41,8 @@ config ARCH_DAVINCI_DA850
>>>>>> select ARCH_DAVINCI_DA8XX
>>>>>> select ARCH_HAS_CPUFREQ
>>>>>> select CP_INTC
>>>>>> + select IPIPE_ARM_KUSER_TSC if IPIPE
>>>>>> + select ARM_FCSE if IPIPE
>>>>>
>>>>> You may want to leave the choice of enabling or disabling FCSE to the user.
>>>>>
>>>>
>>>> Understood; at the moment the variance on max latency is really bad if
>>>> you don't enable FCSE. When I sort out the crashing issues I'll re-test
>>>> with it off.
>>>
>>> Well, FCSE turned out to be my problem.
>>>
>>> More specifically, FCSE and ARM_FCSE_BEST_EFFORT. Either a) disabling
>>> ARM_FCSE altogether, or b) selecting ARM_FCSE with ARM_FCSE_GUARENTEED
>>> gets rid of the crashes/panics with ipipe latency tracing enabled.
>>>
>>> So now things seem reasonably stable, I'll go through the full set of
>>> tests. Though I still can't do 'xeno-test -l "dohell -l /opt/ltp"' as
>>> ltp takes out the system without any ipipe/xenomai bits.
>>>
>> Ok, FCSE best effort is currently being validated on 3.14, so it may
>> well be broken. After all, the raw/* branches are work in progress.
>>
>
> Note: selecting ARM_FCSE_BEST_EFFORT produces the same result on the
> master branch too . . .
>
Hi Peter,
I am unable to reproduce these issues with 3.14, FCSE seems to be doing
just fine, I can boot and run the LTP testsuite and get almost the same
results as a non patched kernel. I have tried with and without
preemptible cache flushes, and with and without Xenomai. My rootfs is
based on busybox and minimal, maybe that is the reason why it works
fine, could you put a tarball with your rootfs somewhere?
Regards.
--
Gilles.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-22 23:02 ` Gilles Chanteperdrix
@ 2014-04-23 1:45 ` Peter Howard
2014-04-23 2:15 ` Peter Howard
` (2 more replies)
0 siblings, 3 replies; 57+ messages in thread
From: Peter Howard @ 2014-04-23 1:45 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On Wed, 2014-04-23 at 01:02 +0200, Gilles Chanteperdrix wrote:
> On 04/15/2014 11:59 PM, Peter Howard wrote:
> > On Tue, 2014-04-15 at 13:37 +0200, Gilles Chanteperdrix wrote:
> >> On 04/15/2014 08:03 AM, Peter Howard wrote:
> >>> On Fri, 2014-04-11 at 08:52 +1000, Peter Howard wrote:
> >>>> On Fri, 2014-04-11 at 00:48 +0200, Gilles Chanteperdrix wrote:
> >>>>> On 04/11/2014 12:34 AM, Peter Howard wrote:
> >>>>>> On Fri, 2014-04-11 at 00:23 +0200, Gilles Chanteperdrix wrote:
> >>>>>> (Stripping back conversation on this one - apologies if that's bad
> >>>>>> etiquette for this list)
> >>>>>>
> >>>>>>> Attachment is better. Also please post the changes you made for omapL138
> >>>>>>>
> >>>>>>
> >>>>>> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
> >>>>>> index a075b3e..3d8bc59 100644
> >>>>>> --- a/arch/arm/mach-davinci/Kconfig
> >>>>>> +++ b/arch/arm/mach-davinci/Kconfig
> >>>>>> @@ -41,6 +41,8 @@ config ARCH_DAVINCI_DA850
> >>>>>> select ARCH_DAVINCI_DA8XX
> >>>>>> select ARCH_HAS_CPUFREQ
> >>>>>> select CP_INTC
> >>>>>> + select IPIPE_ARM_KUSER_TSC if IPIPE
> >>>>>> + select ARM_FCSE if IPIPE
> >>>>>
> >>>>> You may want to leave the choice of enabling or disabling FCSE to the user.
> >>>>>
> >>>>
> >>>> Understood; at the moment the variance on max latency is really bad if
> >>>> you don't enable FCSE. When I sort out the crashing issues I'll re-test
> >>>> with it off.
> >>>
> >>> Well, FCSE turned out to be my problem.
> >>>
> >>> More specifically, FCSE and ARM_FCSE_BEST_EFFORT. Either a) disabling
> >>> ARM_FCSE altogether, or b) selecting ARM_FCSE with ARM_FCSE_GUARENTEED
> >>> gets rid of the crashes/panics with ipipe latency tracing enabled.
> >>>
> >>> So now things seem reasonably stable, I'll go through the full set of
> >>> tests. Though I still can't do 'xeno-test -l "dohell -l /opt/ltp"' as
> >>> ltp takes out the system without any ipipe/xenomai bits.
> >>>
> >> Ok, FCSE best effort is currently being validated on 3.14, so it may
> >> well be broken. After all, the raw/* branches are work in progress.
> >>
> >
> > Note: selecting ARM_FCSE_BEST_EFFORT produces the same result on the
> > master branch too . . .
> >
> Hi Peter,
>
> I am unable to reproduce these issues with 3.14, FCSE seems to be doing
> just fine, I can boot and run the LTP testsuite and get almost the same
> results as a non patched kernel. I have tried with and without
> preemptible cache flushes, and with and without Xenomai. My rootfs is
> based on busybox and minimal, maybe that is the reason why it works
> fine, could you put a tarball with your rootfs somewhere?
A bit of testing shows (at least) one case is directly related to the
rootfs. This is the Texas Instruments rootfs that is supplied for the
DA850 board. During normal startup, it wants to start the GUI for the
LCD which would go past the 32MB process limit with FCSE enabled. With
FCSE_GUARENTEED selected this is noted but doesn't cause a crash. With
FCSE_BEST_EFFORT selected this is noted and then the system crashes
within a few seconds. I'm not sure if this counts as a bug in
BEST_EFFORT or whether all bets are off if you try to start a process
that's too large.
At this point I'm not sure if anything else is specific to that rootfs
but I'll still make it available to you to have a look.
--
Peter Howard <pjh@northern-ridge.com.au>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-23 1:45 ` Peter Howard
@ 2014-04-23 2:15 ` Peter Howard
2014-04-23 12:13 ` Gilles Chanteperdrix
2014-04-24 21:30 ` Gilles Chanteperdrix
2 siblings, 0 replies; 57+ messages in thread
From: Peter Howard @ 2014-04-23 2:15 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On Wed, 2014-04-23 at 11:45 +1000, Peter Howard wrote:
> On Wed, 2014-04-23 at 01:02 +0200, Gilles Chanteperdrix wrote:
> > On 04/15/2014 11:59 PM, Peter Howard wrote:
> > > On Tue, 2014-04-15 at 13:37 +0200, Gilles Chanteperdrix wrote:
> > >> On 04/15/2014 08:03 AM, Peter Howard wrote:
> > >>> On Fri, 2014-04-11 at 08:52 +1000, Peter Howard wrote:
> > >>>> On Fri, 2014-04-11 at 00:48 +0200, Gilles Chanteperdrix wrote:
> > >>>>> On 04/11/2014 12:34 AM, Peter Howard wrote:
> > >>>>>> On Fri, 2014-04-11 at 00:23 +0200, Gilles Chanteperdrix wrote:
> > >>>>>> (Stripping back conversation on this one - apologies if that's bad
> > >>>>>> etiquette for this list)
> > >>>>>>
> > >>>>>>> Attachment is better. Also please post the changes you made for omapL138
> > >>>>>>>
> > >>>>>>
> > >>>>>> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
> > >>>>>> index a075b3e..3d8bc59 100644
> > >>>>>> --- a/arch/arm/mach-davinci/Kconfig
> > >>>>>> +++ b/arch/arm/mach-davinci/Kconfig
> > >>>>>> @@ -41,6 +41,8 @@ config ARCH_DAVINCI_DA850
> > >>>>>> select ARCH_DAVINCI_DA8XX
> > >>>>>> select ARCH_HAS_CPUFREQ
> > >>>>>> select CP_INTC
> > >>>>>> + select IPIPE_ARM_KUSER_TSC if IPIPE
> > >>>>>> + select ARM_FCSE if IPIPE
> > >>>>>
> > >>>>> You may want to leave the choice of enabling or disabling FCSE to the user.
> > >>>>>
> > >>>>
> > >>>> Understood; at the moment the variance on max latency is really bad if
> > >>>> you don't enable FCSE. When I sort out the crashing issues I'll re-test
> > >>>> with it off.
> > >>>
> > >>> Well, FCSE turned out to be my problem.
> > >>>
> > >>> More specifically, FCSE and ARM_FCSE_BEST_EFFORT. Either a) disabling
> > >>> ARM_FCSE altogether, or b) selecting ARM_FCSE with ARM_FCSE_GUARENTEED
> > >>> gets rid of the crashes/panics with ipipe latency tracing enabled.
> > >>>
> > >>> So now things seem reasonably stable, I'll go through the full set of
> > >>> tests. Though I still can't do 'xeno-test -l "dohell -l /opt/ltp"' as
> > >>> ltp takes out the system without any ipipe/xenomai bits.
> > >>>
> > >> Ok, FCSE best effort is currently being validated on 3.14, so it may
> > >> well be broken. After all, the raw/* branches are work in progress.
> > >>
> > >
> > > Note: selecting ARM_FCSE_BEST_EFFORT produces the same result on the
> > > master branch too . . .
> > >
> > Hi Peter,
> >
> > I am unable to reproduce these issues with 3.14, FCSE seems to be doing
> > just fine, I can boot and run the LTP testsuite and get almost the same
> > results as a non patched kernel. I have tried with and without
> > preemptible cache flushes, and with and without Xenomai. My rootfs is
> > based on busybox and minimal, maybe that is the reason why it works
> > fine, could you put a tarball with your rootfs somewhere?
>
> A bit of testing shows (at least) one case is directly related to the
> rootfs. This is the Texas Instruments rootfs that is supplied for the
> DA850 board. During normal startup, it wants to start the GUI for the
> LCD which would go past the 32MB process limit with FCSE enabled. With
> FCSE_GUARENTEED selected this is noted but doesn't cause a crash. With
> FCSE_BEST_EFFORT selected this is noted and then the system crashes
> within a few seconds. I'm not sure if this counts as a bug in
> BEST_EFFORT or whether all bets are off if you try to start a process
> that's too large.
>
> At this point I'm not sure if anything else is specific to that rootfs
> but I'll still make it available to you to have a look.
>
With the ipipe_lock_irq() and ipipe_unlock_irq() calls removed from the
mask/unmask calls, the only problem left that isn't caused by the above
>32MB process is an alignment fault during xeno-test. Only happens with
the xenomai programs built from the 2.6 tree and only on the full Ti
rootfs (the same build works fine on a buildroot-based rootfs, as do the
xenomai programs built via buildroot). So I'm guessing that problem is
mismatched libraries and nothing to do with xenomai itself. (I've
included the error just for reference at the end of the email).
So given that:
1. Do you still want the rootfs to look at?
2. What would you like me to run/test before I put up a formal
patch for merging?
Thanks for the help so far.
Alignment trap: switchtest (1592) PC=0x01b7ff18 Instr=0xe590c000 Address=0x00001
switchtest: unhandled page fault (11) at 0x00000001, code 0x001
fcse pid: 79, 0x9e000000, hw pid: 0x9e000000
pgd = c68cc000, hw pgd = c68cc000
[00000001] *pgd=c73fe831, *pte=00000000, *ppte=00000000
CPU: 0 PID: 1592 Comm: switchtest Not tainted 3.14.0-ipipe-38808-gd8d4639-dirty6
task: c6847a00 ti: c6904000 task.ti: c6904000
PC is at 0x1b7ff18
LR is at 0x1b7ff0c
pc : [<01b7ff18>] lr : [<01b7ff0c>] psr: 20000010
sp : 018e6334 ip : 01b90280 fp : 00000258
r10: 00000158 r9 : 01b1b000 r8 : 018e6350
r7 : 00000000 r6 : 00000008 r5 : 00000000 r4 : 01b90290
r3 : 00000050 r2 : 01b94050 r1 : 00000001 r0 : 00000001
Flags: nzCv IRQs on FIQs on Mode USER_32 ISA ARM Segment user
Control: 0005317f Table: c68cc000 DAC: 00000015
CPU: 0 PID: 1592 Comm: switchtest Not tainted 3.14.0-ipipe-38808-gd8d4639-dirty6
Backtrace:
[<c000d228>] (dump_backtrace) from [<c000d7d0>] (show_stack+0x20/0x24)
r6:00000001 r5:0000000b r4:c6905fb0 r3:00000000
[<c000d7b0>] (show_stack) from [<c03f849c>] (dump_stack+0x20/0x2c)
[<c03f847c>] (dump_stack) from [<c000ac48>] (show_regs+0x2c/0x34)
[<c000ac1c>] (show_regs) from [<c0011bf8>] (__do_user_fault+0xf0/0xfc)
r4:c6847a00 r3:60000013
[<c0011b08>] (__do_user_fault) from [<c0012050>] (do_bad_area+0x74/0x7c)
r8:00000001 r7:c059bc3c r6:00000001 r5:00000000 r4:c6905fb0
[<c0011fdc>] (do_bad_area) from [<c0014998>] (do_alignment+0x37c/0x928)
[<c001461c>] (do_alignment) from [<c0008794>] (do_DataAbort+0x50/0x160)
r10:00000158 r9:01b1b000 r8:c6905fb0 r7:00000001 r6:c0568154 r5:00000001
r4:00000001
[<c0008744>] (do_DataAbort) from [<c000e7fc>] (__dabt_usr+0x5c/0x60)
Exception stack(0xc6905fb0 to 0xc6905ff8)
5fa0: 00000001 00000001 01b94050 00000050
5fc0: 01b90290 00000000 00000008 00000000 018e6350 01b1b000 00000158 00000258
5fe0: 01b90280 018e6334 01b7ff0c 01b7ff18 20000010 ffffffff
r10:00000158 r8:018e6350 r7:00000000 r6:ffffffff r5:20000010 r4:01b7ff18
mappings:
0x00008000-0x0000e000 r-xp 0x00000000 /usr/xenomai/bin/switchtest
0x00016000-0x00017000 rwxp 0x00006000 /usr/xenomai/bin/switchtest
0x00017000-0x0005f000 rwxp 0x00017000 [heap]
0x0189d000-0x018a8000 r-xp 0x00000000 /lib/libgcc_s.so.1
0x018a8000-0x018af000 ---p 0x0000b000 /lib/libgcc_s.so.1
0x018af000-0x018b0000 rwxp 0x0000a000 /lib/libgcc_s.so.1
0x018b0000-0x018b1000 ---p 0x018b0000
0x018b1000-0x018b8000 rwxp 0x018b1000
0x018b8000-0x018b9000 ---p 0x018b8000
0x018b9000-0x018c0000 rwxp 0x018b9000
0x018c0000-0x018c1000 ---p 0x018c0000
0x018c1000-0x018c8000 rwxp 0x018c1000
0x018c8000-0x018c9000 ---p 0x018c8000
0x018c9000-0x018d0000 rwxp 0x018c9000
0x018d0000-0x018d1000 ---p 0x018d0000
0x018d1000-0x018d8000 rwxp 0x018d1000
0x018d8000-0x018d9000 ---p 0x018d8000
0x018d9000-0x018e0000 rwxp 0x018d9000
0x018e0000-0x018e1000 ---p 0x018e0000
0x018e1000-0x018e8000 rwxp 0x018e1000 <- SP
0x018e8000-0x018e9000 ---p 0x018e8000
0x018e9000-0x019e8000 rwxp 0x018e9000
0x019e8000-0x019eb000 rwxs 0xc8986000 /dev/rtheap
0x019eb000-0x019ee000 rwxs 0xc8b1e000 /dev/rtheap
0x019ee000-0x019ef000 ---p 0x019ee000
0x019ef000-0x019f6000 rwxp 0x019ef000
0x019f6000-0x01b11000 r-xp 0x00000000 /lib/libc-2.9.so
0x01b11000-0x01b19000 ---p 0x0011b000 /lib/libc-2.9.so
0x01b19000-0x01b1a000 r-xp 0x0011b000 /lib/libc-2.9.so
0x01b1a000-0x01b1c000 rwxp 0x0011c000 /lib/libc-2.9.so
0x01b1c000-0x01b1f000 rwxp 0x01b1c000
0x01b1f000-0x01b25000 r-xp 0x00000000 /lib/librt-2.9.so
0x01b25000-0x01b2c000 ---p 0x00006000 /lib/librt-2.9.so
0x01b2c000-0x01b2d000 r-xp 0x00005000 /lib/librt-2.9.so
0x01b2d000-0x01b2e000 rwxp 0x00006000 /lib/librt-2.9.so
0x01b2e000-0x01b42000 r-xp 0x00000000 /lib/libpthread-2.9.so
0x01b42000-0x01b49000 ---p 0x00014000 /lib/libpthread-2.9.so
0x01b49000-0x01b4a000 r-xp 0x00013000 /lib/libpthread-2.9.so
0x01b4a000-0x01b4b000 rwxp 0x00014000 /lib/libpthread-2.9.so
0x01b4b000-0x01b4d000 rwxp 0x01b4b000
0x01b4d000-0x01b54000 r-xp 0x00000000 /usr/xenomai/lib/libxenomai.so.0.0.0
0x01b54000-0x01b5b000 ---p 0x00007000 /usr/xenomai/lib/libxenomai.so.0.0.0
0x01b5b000-0x01b5c000 rwxp 0x00006000 /usr/xenomai/lib/libxenomai.so.0.0.0
0x01b5c000-0x01b67000 r-xp 0x00000000 /usr/xenomai/lib/libpthread_rt.so.1.0.0
0x01b67000-0x01b6e000 ---p 0x0000b000 /usr/xenomai/lib/libpthread_rt.so.1.0.0
0x01b6e000-0x01b6f000 rwxp 0x0000a000 /usr/xenomai/lib/libpthread_rt.so.1.0.0
0x01b6f000-0x01b8c000 r-xp 0x00000000 /lib/ld-2.9.so <- PC
0x01b8c000-0x01b8d000 rwxp 0x01b8c000
0x01b8d000-0x01b8e000 r-xs 0x01c20000 /dev/mem
0x01b8e000-0x01b8f000 r-xs 0xc898a000 /dev/rtheap
0x01b8f000-0x01b92000 rwxp 0x01b8f000
0x01b92000-0x01b93000 r-xp 0x01b92000 [sigpage]
0x01b93000-0x01b95000 rwxp 0x0001c000 /lib/ld-2.9.so
0x01d56000-0x01d78000 rw-p 0x01fde000 [stack]
Xenomai: RTDM: closing file descriptor 0.
Segmentation fault
--
Peter Howard <pjh@northern-ridge.com.au>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-23 1:45 ` Peter Howard
2014-04-23 2:15 ` Peter Howard
@ 2014-04-23 12:13 ` Gilles Chanteperdrix
2014-04-24 21:30 ` Gilles Chanteperdrix
2 siblings, 0 replies; 57+ messages in thread
From: Gilles Chanteperdrix @ 2014-04-23 12:13 UTC (permalink / raw)
To: Peter Howard; +Cc: xenomai
On 04/23/2014 03:45 AM, Peter Howard wrote:
> On Wed, 2014-04-23 at 01:02 +0200, Gilles Chanteperdrix wrote:
>> On 04/15/2014 11:59 PM, Peter Howard wrote:
>>> On Tue, 2014-04-15 at 13:37 +0200, Gilles Chanteperdrix wrote:
>>>> On 04/15/2014 08:03 AM, Peter Howard wrote:
>>>>> On Fri, 2014-04-11 at 08:52 +1000, Peter Howard wrote:
>>>>>> On Fri, 2014-04-11 at 00:48 +0200, Gilles Chanteperdrix wrote:
>>>>>>> On 04/11/2014 12:34 AM, Peter Howard wrote:
>>>>>>>> On Fri, 2014-04-11 at 00:23 +0200, Gilles Chanteperdrix wrote:
>>>>>>>> (Stripping back conversation on this one - apologies if that's bad
>>>>>>>> etiquette for this list)
>>>>>>>>
>>>>>>>>> Attachment is better. Also please post the changes you made for omapL138
>>>>>>>>>
>>>>>>>>
>>>>>>>> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
>>>>>>>> index a075b3e..3d8bc59 100644
>>>>>>>> --- a/arch/arm/mach-davinci/Kconfig
>>>>>>>> +++ b/arch/arm/mach-davinci/Kconfig
>>>>>>>> @@ -41,6 +41,8 @@ config ARCH_DAVINCI_DA850
>>>>>>>> select ARCH_DAVINCI_DA8XX
>>>>>>>> select ARCH_HAS_CPUFREQ
>>>>>>>> select CP_INTC
>>>>>>>> + select IPIPE_ARM_KUSER_TSC if IPIPE
>>>>>>>> + select ARM_FCSE if IPIPE
>>>>>>>
>>>>>>> You may want to leave the choice of enabling or disabling FCSE to the user.
>>>>>>>
>>>>>>
>>>>>> Understood; at the moment the variance on max latency is really bad if
>>>>>> you don't enable FCSE. When I sort out the crashing issues I'll re-test
>>>>>> with it off.
>>>>>
>>>>> Well, FCSE turned out to be my problem.
>>>>>
>>>>> More specifically, FCSE and ARM_FCSE_BEST_EFFORT. Either a) disabling
>>>>> ARM_FCSE altogether, or b) selecting ARM_FCSE with ARM_FCSE_GUARENTEED
>>>>> gets rid of the crashes/panics with ipipe latency tracing enabled.
>>>>>
>>>>> So now things seem reasonably stable, I'll go through the full set of
>>>>> tests. Though I still can't do 'xeno-test -l "dohell -l /opt/ltp"' as
>>>>> ltp takes out the system without any ipipe/xenomai bits.
>>>>>
>>>> Ok, FCSE best effort is currently being validated on 3.14, so it may
>>>> well be broken. After all, the raw/* branches are work in progress.
>>>>
>>>
>>> Note: selecting ARM_FCSE_BEST_EFFORT produces the same result on the
>>> master branch too . . .
>>>
>> Hi Peter,
>>
>> I am unable to reproduce these issues with 3.14, FCSE seems to be doing
>> just fine, I can boot and run the LTP testsuite and get almost the same
>> results as a non patched kernel. I have tried with and without
>> preemptible cache flushes, and with and without Xenomai. My rootfs is
>> based on busybox and minimal, maybe that is the reason why it works
>> fine, could you put a tarball with your rootfs somewhere?
>
> A bit of testing shows (at least) one case is directly related to the
> rootfs. This is the Texas Instruments rootfs that is supplied for the
> DA850 board. During normal startup, it wants to start the GUI for the
> LCD which would go past the 32MB process limit with FCSE enabled. With
> FCSE_GUARENTEED selected this is noted but doesn't cause a crash. With
> FCSE_BEST_EFFORT selected this is noted and then the system crashes
> within a few seconds.
With FCSE_GUARANTEED the system refuses processes to go above the 32MB
limit, so, the program probably does not even start. With
FCSE_BEST_EFFORT, processes should be allowed to go above 32MB.
I'm not sure if this counts as a bug in
> BEST_EFFORT or whether all bets are off if you try to start a process
> that's too large.
It is supposed to work.
>
> At this point I'm not sure if anything else is specific to that rootfs
> but I'll still make it available to you to have a look.
>
>
Yes, please make it available if that is possible.
Regards.
--
Gilles.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-23 1:45 ` Peter Howard
2014-04-23 2:15 ` Peter Howard
2014-04-23 12:13 ` Gilles Chanteperdrix
@ 2014-04-24 21:30 ` Gilles Chanteperdrix
2014-04-27 22:14 ` Peter Howard
` (2 more replies)
2 siblings, 3 replies; 57+ messages in thread
From: Gilles Chanteperdrix @ 2014-04-24 21:30 UTC (permalink / raw)
To: Peter Howard; +Cc: xenomai
On 04/23/2014 03:45 AM, Peter Howard wrote:
> On Wed, 2014-04-23 at 01:02 +0200, Gilles Chanteperdrix wrote:
>> On 04/15/2014 11:59 PM, Peter Howard wrote:
>>> On Tue, 2014-04-15 at 13:37 +0200, Gilles Chanteperdrix wrote:
>>>> On 04/15/2014 08:03 AM, Peter Howard wrote:
>>>>> On Fri, 2014-04-11 at 08:52 +1000, Peter Howard wrote:
>>>>>> On Fri, 2014-04-11 at 00:48 +0200, Gilles Chanteperdrix wrote:
>>>>>>> On 04/11/2014 12:34 AM, Peter Howard wrote:
>>>>>>>> On Fri, 2014-04-11 at 00:23 +0200, Gilles Chanteperdrix wrote:
>>>>>>>> (Stripping back conversation on this one - apologies if that's bad
>>>>>>>> etiquette for this list)
>>>>>>>>
>>>>>>>>> Attachment is better. Also please post the changes you made for omapL138
>>>>>>>>>
>>>>>>>>
>>>>>>>> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
>>>>>>>> index a075b3e..3d8bc59 100644
>>>>>>>> --- a/arch/arm/mach-davinci/Kconfig
>>>>>>>> +++ b/arch/arm/mach-davinci/Kconfig
>>>>>>>> @@ -41,6 +41,8 @@ config ARCH_DAVINCI_DA850
>>>>>>>> select ARCH_DAVINCI_DA8XX
>>>>>>>> select ARCH_HAS_CPUFREQ
>>>>>>>> select CP_INTC
>>>>>>>> + select IPIPE_ARM_KUSER_TSC if IPIPE
>>>>>>>> + select ARM_FCSE if IPIPE
>>>>>>>
>>>>>>> You may want to leave the choice of enabling or disabling FCSE to the user.
>>>>>>>
>>>>>>
>>>>>> Understood; at the moment the variance on max latency is really bad if
>>>>>> you don't enable FCSE. When I sort out the crashing issues I'll re-test
>>>>>> with it off.
>>>>>
>>>>> Well, FCSE turned out to be my problem.
>>>>>
>>>>> More specifically, FCSE and ARM_FCSE_BEST_EFFORT. Either a) disabling
>>>>> ARM_FCSE altogether, or b) selecting ARM_FCSE with ARM_FCSE_GUARENTEED
>>>>> gets rid of the crashes/panics with ipipe latency tracing enabled.
>>>>>
>>>>> So now things seem reasonably stable, I'll go through the full set of
>>>>> tests. Though I still can't do 'xeno-test -l "dohell -l /opt/ltp"' as
>>>>> ltp takes out the system without any ipipe/xenomai bits.
>>>>>
>>>> Ok, FCSE best effort is currently being validated on 3.14, so it may
>>>> well be broken. After all, the raw/* branches are work in progress.
>>>>
>>>
>>> Note: selecting ARM_FCSE_BEST_EFFORT produces the same result on the
>>> master branch too . . .
>>>
>> Hi Peter,
>>
>> I am unable to reproduce these issues with 3.14, FCSE seems to be doing
>> just fine, I can boot and run the LTP testsuite and get almost the same
>> results as a non patched kernel. I have tried with and without
>> preemptible cache flushes, and with and without Xenomai. My rootfs is
>> based on busybox and minimal, maybe that is the reason why it works
>> fine, could you put a tarball with your rootfs somewhere?
>
> A bit of testing shows (at least) one case is directly related to the
> rootfs. This is the Texas Instruments rootfs that is supplied for the
> DA850 board. During normal startup, it wants to start the GUI for the
> LCD which would go past the 32MB process limit with FCSE enabled. With
> FCSE_GUARENTEED selected this is noted but doesn't cause a crash. With
> FCSE_BEST_EFFORT selected this is noted and then the system crashes
> within a few seconds. I'm not sure if this counts as a bug in
> BEST_EFFORT or whether all bets are off if you try to start a process
> that's too large.
>
> At this point I'm not sure if anything else is specific to that rootfs
> but I'll still make it available to you to have a look.
No luck with your rootfs: matrix_GUI craches indeed, but it also crashes
without CONFIG_FCSE, so it would seem the crash is unrelated to the
FCSE. Obviously it does not crash with FCSE_GUARANTEED, because it is
stopped as soon as it wants to go over 32 MB. And that crash does not
cause the cascade of crashes you mentioned, ending with init crashing.
The processor on which I am running the tests does not have a
framebuffer maybe that is the reason I get a crash, and do not go as far
as in your case.
Could you post the kernel configuration you use?
--
Gilles.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-24 21:30 ` Gilles Chanteperdrix
@ 2014-04-27 22:14 ` Peter Howard
2014-04-28 1:19 ` Peter Howard
2014-04-29 1:46 ` Peter Howard
2 siblings, 0 replies; 57+ messages in thread
From: Peter Howard @ 2014-04-27 22:14 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On Thu, 2014-04-24 at 23:30 +0200, Gilles Chanteperdrix wrote:
> On 04/23/2014 03:45 AM, Peter Howard wrote:
> > On Wed, 2014-04-23 at 01:02 +0200, Gilles Chanteperdrix wrote:
> >> On 04/15/2014 11:59 PM, Peter Howard wrote:
> >>> On Tue, 2014-04-15 at 13:37 +0200, Gilles Chanteperdrix wrote:
> >>>> On 04/15/2014 08:03 AM, Peter Howard wrote:
> >>>>> On Fri, 2014-04-11 at 08:52 +1000, Peter Howard wrote:
> >>>>>> On Fri, 2014-04-11 at 00:48 +0200, Gilles Chanteperdrix wrote:
> >>>>>>> On 04/11/2014 12:34 AM, Peter Howard wrote:
> >>>>>>>> On Fri, 2014-04-11 at 00:23 +0200, Gilles Chanteperdrix wrote:
> >>>>>>>> (Stripping back conversation on this one - apologies if that's bad
> >>>>>>>> etiquette for this list)
> >>>>>>>>
> >>>>>>>>> Attachment is better. Also please post the changes you made for omapL138
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
> >>>>>>>> index a075b3e..3d8bc59 100644
> >>>>>>>> --- a/arch/arm/mach-davinci/Kconfig
> >>>>>>>> +++ b/arch/arm/mach-davinci/Kconfig
> >>>>>>>> @@ -41,6 +41,8 @@ config ARCH_DAVINCI_DA850
> >>>>>>>> select ARCH_DAVINCI_DA8XX
> >>>>>>>> select ARCH_HAS_CPUFREQ
> >>>>>>>> select CP_INTC
> >>>>>>>> + select IPIPE_ARM_KUSER_TSC if IPIPE
> >>>>>>>> + select ARM_FCSE if IPIPE
> >>>>>>>
> >>>>>>> You may want to leave the choice of enabling or disabling FCSE to the user.
> >>>>>>>
> >>>>>>
> >>>>>> Understood; at the moment the variance on max latency is really bad if
> >>>>>> you don't enable FCSE. When I sort out the crashing issues I'll re-test
> >>>>>> with it off.
> >>>>>
> >>>>> Well, FCSE turned out to be my problem.
> >>>>>
> >>>>> More specifically, FCSE and ARM_FCSE_BEST_EFFORT. Either a) disabling
> >>>>> ARM_FCSE altogether, or b) selecting ARM_FCSE with ARM_FCSE_GUARENTEED
> >>>>> gets rid of the crashes/panics with ipipe latency tracing enabled.
> >>>>>
> >>>>> So now things seem reasonably stable, I'll go through the full set of
> >>>>> tests. Though I still can't do 'xeno-test -l "dohell -l /opt/ltp"' as
> >>>>> ltp takes out the system without any ipipe/xenomai bits.
> >>>>>
> >>>> Ok, FCSE best effort is currently being validated on 3.14, so it may
> >>>> well be broken. After all, the raw/* branches are work in progress.
> >>>>
> >>>
> >>> Note: selecting ARM_FCSE_BEST_EFFORT produces the same result on the
> >>> master branch too . . .
> >>>
> >> Hi Peter,
> >>
> >> I am unable to reproduce these issues with 3.14, FCSE seems to be doing
> >> just fine, I can boot and run the LTP testsuite and get almost the same
> >> results as a non patched kernel. I have tried with and without
> >> preemptible cache flushes, and with and without Xenomai. My rootfs is
> >> based on busybox and minimal, maybe that is the reason why it works
> >> fine, could you put a tarball with your rootfs somewhere?
> >
> > A bit of testing shows (at least) one case is directly related to the
> > rootfs. This is the Texas Instruments rootfs that is supplied for the
> > DA850 board. During normal startup, it wants to start the GUI for the
> > LCD which would go past the 32MB process limit with FCSE enabled. With
> > FCSE_GUARENTEED selected this is noted but doesn't cause a crash. With
> > FCSE_BEST_EFFORT selected this is noted and then the system crashes
> > within a few seconds. I'm not sure if this counts as a bug in
> > BEST_EFFORT or whether all bets are off if you try to start a process
> > that's too large.
> >
> > At this point I'm not sure if anything else is specific to that rootfs
> > but I'll still make it available to you to have a look.
>
> No luck with your rootfs: matrix_GUI craches indeed, but it also crashes
> without CONFIG_FCSE, so it would seem the crash is unrelated to the
> FCSE. Obviously it does not crash with FCSE_GUARANTEED, because it is
> stopped as soon as it wants to go over 32 MB. And that crash does not
> cause the cascade of crashes you mentioned, ending with init crashing.
> The processor on which I am running the tests does not have a
> framebuffer maybe that is the reason I get a crash, and do not go as far
> as in your case.
>
> Could you post the kernel configuration you use?
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config
Type: application/x-config
Size: 55010 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20140428/50ad2e29/attachment.bin>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-24 21:30 ` Gilles Chanteperdrix
2014-04-27 22:14 ` Peter Howard
@ 2014-04-28 1:19 ` Peter Howard
2014-04-29 1:46 ` Peter Howard
2 siblings, 0 replies; 57+ messages in thread
From: Peter Howard @ 2014-04-28 1:19 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
Re-sending as the original seems to have vanished into the ether.
On Thu, 2014-04-24 at 23:30 +0200, Gilles Chanteperdrix wrote:
> On 04/23/2014 03:45 AM, Peter Howard wrote:
> > On Wed, 2014-04-23 at 01:02 +0200, Gilles Chanteperdrix wrote:
> >> On 04/15/2014 11:59 PM, Peter Howard wrote:
> >>> On Tue, 2014-04-15 at 13:37 +0200, Gilles Chanteperdrix wrote:
> >>>> On 04/15/2014 08:03 AM, Peter Howard wrote:
> >>>>> On Fri, 2014-04-11 at 08:52 +1000, Peter Howard wrote:
> >>>>>> On Fri, 2014-04-11 at 00:48 +0200, Gilles Chanteperdrix wrote:
> >>>>>>> On 04/11/2014 12:34 AM, Peter Howard wrote:
> >>>>>>>> On Fri, 2014-04-11 at 00:23 +0200, Gilles Chanteperdrix wrote:
> >>>>>>>> (Stripping back conversation on this one - apologies if that's bad
> >>>>>>>> etiquette for this list)
> >>>>>>>>
> >>>>>>>>> Attachment is better. Also please post the changes you made for omapL138
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
> >>>>>>>> index a075b3e..3d8bc59 100644
> >>>>>>>> --- a/arch/arm/mach-davinci/Kconfig
> >>>>>>>> +++ b/arch/arm/mach-davinci/Kconfig
> >>>>>>>> @@ -41,6 +41,8 @@ config ARCH_DAVINCI_DA850
> >>>>>>>> select ARCH_DAVINCI_DA8XX
> >>>>>>>> select ARCH_HAS_CPUFREQ
> >>>>>>>> select CP_INTC
> >>>>>>>> + select IPIPE_ARM_KUSER_TSC if IPIPE
> >>>>>>>> + select ARM_FCSE if IPIPE
> >>>>>>>
> >>>>>>> You may want to leave the choice of enabling or disabling FCSE to the user.
> >>>>>>>
> >>>>>>
> >>>>>> Understood; at the moment the variance on max latency is really bad if
> >>>>>> you don't enable FCSE. When I sort out the crashing issues I'll re-test
> >>>>>> with it off.
> >>>>>
> >>>>> Well, FCSE turned out to be my problem.
> >>>>>
> >>>>> More specifically, FCSE and ARM_FCSE_BEST_EFFORT. Either a) disabling
> >>>>> ARM_FCSE altogether, or b) selecting ARM_FCSE with ARM_FCSE_GUARENTEED
> >>>>> gets rid of the crashes/panics with ipipe latency tracing enabled.
> >>>>>
> >>>>> So now things seem reasonably stable, I'll go through the full set of
> >>>>> tests. Though I still can't do 'xeno-test -l "dohell -l /opt/ltp"' as
> >>>>> ltp takes out the system without any ipipe/xenomai bits.
> >>>>>
> >>>> Ok, FCSE best effort is currently being validated on 3.14, so it may
> >>>> well be broken. After all, the raw/* branches are work in progress.
> >>>>
> >>>
> >>> Note: selecting ARM_FCSE_BEST_EFFORT produces the same result on the
> >>> master branch too . . .
> >>>
> >> Hi Peter,
> >>
> >> I am unable to reproduce these issues with 3.14, FCSE seems to be doing
> >> just fine, I can boot and run the LTP testsuite and get almost the same
> >> results as a non patched kernel. I have tried with and without
> >> preemptible cache flushes, and with and without Xenomai. My rootfs is
> >> based on busybox and minimal, maybe that is the reason why it works
> >> fine, could you put a tarball with your rootfs somewhere?
> >
> > A bit of testing shows (at least) one case is directly related to the
> > rootfs. This is the Texas Instruments rootfs that is supplied for the
> > DA850 board. During normal startup, it wants to start the GUI for the
> > LCD which would go past the 32MB process limit with FCSE enabled. With
> > FCSE_GUARENTEED selected this is noted but doesn't cause a crash. With
> > FCSE_BEST_EFFORT selected this is noted and then the system crashes
> > within a few seconds. I'm not sure if this counts as a bug in
> > BEST_EFFORT or whether all bets are off if you try to start a process
> > that's too large.
> >
> > At this point I'm not sure if anything else is specific to that rootfs
> > but I'll still make it available to you to have a look.
>
> No luck with your rootfs: matrix_GUI craches indeed, but it also crashes
> without CONFIG_FCSE, so it would seem the crash is unrelated to the
> FCSE. Obviously it does not crash with FCSE_GUARANTEED, because it is
> stopped as soon as it wants to go over 32 MB. And that crash does not
> cause the cascade of crashes you mentioned, ending with init crashing.
> The processor on which I am running the tests does not have a
> framebuffer maybe that is the reason I get a crash, and do not go as far
> as in your case.
>
> Could you post the kernel configuration you use?
>
Attached.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config
Type: application/x-config
Size: 55010 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20140428/c017ab77/attachment.bin>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-24 21:30 ` Gilles Chanteperdrix
2014-04-27 22:14 ` Peter Howard
2014-04-28 1:19 ` Peter Howard
@ 2014-04-29 1:46 ` Peter Howard
2014-05-04 19:25 ` Gilles Chanteperdrix
2 siblings, 1 reply; 57+ messages in thread
From: Peter Howard @ 2014-04-29 1:46 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On Thu, 2014-04-24 at 23:30 +0200, Gilles Chanteperdrix wrote:
> On 04/23/2014 03:45 AM, Peter Howard wrote:
> > On Wed, 2014-04-23 at 01:02 +0200, Gilles Chanteperdrix wrote:
> >> On 04/15/2014 11:59 PM, Peter Howard wrote:
> >>> On Tue, 2014-04-15 at 13:37 +0200, Gilles Chanteperdrix wrote:
> >>>> On 04/15/2014 08:03 AM, Peter Howard wrote:
> >>>>> On Fri, 2014-04-11 at 08:52 +1000, Peter Howard wrote:
> >>>>>> On Fri, 2014-04-11 at 00:48 +0200, Gilles Chanteperdrix wrote:
> >>>>>>> On 04/11/2014 12:34 AM, Peter Howard wrote:
> >>>>>>>> On Fri, 2014-04-11 at 00:23 +0200, Gilles Chanteperdrix wrote:
> >>>>>>>> (Stripping back conversation on this one - apologies if that's bad
> >>>>>>>> etiquette for this list)
> >>>>>>>>
> >>>>>>>>> Attachment is better. Also please post the changes you made for omapL138
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
> >>>>>>>> index a075b3e..3d8bc59 100644
> >>>>>>>> --- a/arch/arm/mach-davinci/Kconfig
> >>>>>>>> +++ b/arch/arm/mach-davinci/Kconfig
> >>>>>>>> @@ -41,6 +41,8 @@ config ARCH_DAVINCI_DA850
> >>>>>>>> select ARCH_DAVINCI_DA8XX
> >>>>>>>> select ARCH_HAS_CPUFREQ
> >>>>>>>> select CP_INTC
> >>>>>>>> + select IPIPE_ARM_KUSER_TSC if IPIPE
> >>>>>>>> + select ARM_FCSE if IPIPE
> >>>>>>>
> >>>>>>> You may want to leave the choice of enabling or disabling FCSE to the user.
> >>>>>>>
> >>>>>>
> >>>>>> Understood; at the moment the variance on max latency is really bad if
> >>>>>> you don't enable FCSE. When I sort out the crashing issues I'll re-test
> >>>>>> with it off.
> >>>>>
> >>>>> Well, FCSE turned out to be my problem.
> >>>>>
> >>>>> More specifically, FCSE and ARM_FCSE_BEST_EFFORT. Either a) disabling
> >>>>> ARM_FCSE altogether, or b) selecting ARM_FCSE with ARM_FCSE_GUARENTEED
> >>>>> gets rid of the crashes/panics with ipipe latency tracing enabled.
> >>>>>
> >>>>> So now things seem reasonably stable, I'll go through the full set of
> >>>>> tests. Though I still can't do 'xeno-test -l "dohell -l /opt/ltp"' as
> >>>>> ltp takes out the system without any ipipe/xenomai bits.
> >>>>>
> >>>> Ok, FCSE best effort is currently being validated on 3.14, so it may
> >>>> well be broken. After all, the raw/* branches are work in progress.
> >>>>
> >>>
> >>> Note: selecting ARM_FCSE_BEST_EFFORT produces the same result on the
> >>> master branch too . . .
> >>>
> >> Hi Peter,
> >>
> >> I am unable to reproduce these issues with 3.14, FCSE seems to be doing
> >> just fine, I can boot and run the LTP testsuite and get almost the same
> >> results as a non patched kernel. I have tried with and without
> >> preemptible cache flushes, and with and without Xenomai. My rootfs is
> >> based on busybox and minimal, maybe that is the reason why it works
> >> fine, could you put a tarball with your rootfs somewhere?
> >
> > A bit of testing shows (at least) one case is directly related to the
> > rootfs. This is the Texas Instruments rootfs that is supplied for the
> > DA850 board. During normal startup, it wants to start the GUI for the
> > LCD which would go past the 32MB process limit with FCSE enabled. With
> > FCSE_GUARENTEED selected this is noted but doesn't cause a crash. With
> > FCSE_BEST_EFFORT selected this is noted and then the system crashes
> > within a few seconds. I'm not sure if this counts as a bug in
> > BEST_EFFORT or whether all bets are off if you try to start a process
> > that's too large.
> >
> > At this point I'm not sure if anything else is specific to that rootfs
> > but I'll still make it available to you to have a look.
>
> No luck with your rootfs: matrix_GUI craches indeed, but it also crashes
> without CONFIG_FCSE, so it would seem the crash is unrelated to the
> FCSE. Obviously it does not crash with FCSE_GUARANTEED, because it is
> stopped as soon as it wants to go over 32 MB. And that crash does not
> cause the cascade of crashes you mentioned, ending with init crashing.
> The processor on which I am running the tests does not have a
> framebuffer maybe that is the reason I get a crash, and do not go as far
> as in your case.
>
> Could you post the kernel configuration you use?
>
Take 3. Ignore the previous two. They will probably trigger it, but
this one I actually tested to confirm it does cause the crash.
-------------- next part --------------
#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 3.14.0 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_IPIPE_WANT_ACTIVE_MM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ARCH_HAS_CPUFREQ=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ZONE_DMA=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_VECTORS_BASE=0xffff0000
CONFIG_ARM_PATCH_PHYS_VIRT=y
CONFIG_GENERIC_BUG=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION="-ipipe"
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_FHANDLE is not set
# CONFIG_AUDIT is not set
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
#
# RCU Subsystem
#
CONFIG_TREE_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_FANOUT=32
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_BOOST is not set
# CONFIG_RCU_NOCB_CPU is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_GENERIC_SCHED_CLOCK=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
# CONFIG_CGROUP_FREEZER is not set
# CONFIG_CGROUP_DEVICE is not set
# CONFIG_CPUSETS is not set
# CONFIG_CGROUP_CPUACCT is not set
# CONFIG_RESOURCE_COUNTERS is not set
# CONFIG_CGROUP_SCHED is not set
# CONFIG_BLK_CGROUP is not set
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_NAMESPACES is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_EXPERT=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y
#
# Kernel Performance Events And Counters
#
# CONFIG_PERF_EVENTS is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
CONFIG_COMPAT_BRK=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
# CONFIG_PROFILING is not set
CONFIG_TRACEPOINTS=y
CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
# CONFIG_JUMP_LABEL is not set
# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set
CONFIG_ARCH_USE_BUILTIN_BSWAP=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_DMA_CONTIGUOUS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_GENERIC_IDLE_POLL_SETUP=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_PERF_REGS=y
CONFIG_HAVE_PERF_USER_STACK_DUMP=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_HAVE_CC_STACKPROTECTOR=y
# CONFIG_CC_STACKPROTECTOR is not set
CONFIG_CC_STACKPROTECTOR_NONE=y
# CONFIG_CC_STACKPROTECTOR_REGULAR is not set
# CONFIG_CC_STACKPROTECTOR_STRONG is not set
CONFIG_HAVE_CONTEXT_TRACKING=y
CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y
CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
CONFIG_MODULES_USE_ELF_REL=y
CONFIG_CLONE_BACKWARDS=y
CONFIG_OLD_SIGSUSPEND3=y
CONFIG_OLD_SIGACTION=y
#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
# CONFIG_MODULE_SIG is not set
CONFIG_BLOCK=y
CONFIG_LBDAF=y
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_BSGLIB is not set
# CONFIG_BLK_DEV_INTEGRITY is not set
# CONFIG_BLK_CMDLINE_PARSER is not set
#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_AIX_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set
# CONFIG_CMDLINE_PARTITION is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"
CONFIG_UNINLINE_SPIN_UNLOCK=y
#
# Real-time sub-system
#
CONFIG_XENOMAI=y
CONFIG_XENO_GENERIC_STACKPOOL=y
CONFIG_XENO_FASTSYNCH_DEP=y
CONFIG_XENO_FASTSYNCH=y
CONFIG_XENO_OPT_NUCLEUS=y
CONFIG_XENO_OPT_PERVASIVE=y
# CONFIG_XENO_OPT_PRIOCPL is not set
CONFIG_XENO_OPT_PIPELINE_HEAD=y
# CONFIG_XENO_OPT_SCHED_CLASSES is not set
CONFIG_XENO_OPT_PIPE=y
CONFIG_XENO_OPT_MAP=y
CONFIG_XENO_OPT_VFILE=y
CONFIG_XENO_OPT_PIPE_NRDEV=32
CONFIG_XENO_OPT_REGISTRY_NRSLOTS=512
CONFIG_XENO_OPT_SYS_HEAPSZ=256
CONFIG_XENO_OPT_SYS_STACKPOOLSZ=128
CONFIG_XENO_OPT_SEM_HEAPSZ=12
CONFIG_XENO_OPT_GLOBAL_SEM_HEAPSZ=12
CONFIG_XENO_OPT_STATS=y
CONFIG_XENO_OPT_DEBUG=y
# CONFIG_XENO_OPT_DEBUG_NUCLEUS is not set
# CONFIG_XENO_OPT_DEBUG_XNLOCK is not set
# CONFIG_XENO_OPT_DEBUG_QUEUES is not set
# CONFIG_XENO_OPT_DEBUG_REGISTRY is not set
# CONFIG_XENO_OPT_DEBUG_TIMERS is not set
CONFIG_XENO_OPT_DEBUG_SYNCH_RELAX=y
CONFIG_XENO_OPT_WATCHDOG=y
CONFIG_XENO_OPT_WATCHDOG_TIMEOUT=4
# CONFIG_XENO_OPT_SHIRQ is not set
CONFIG_XENO_OPT_SELECT=y
CONFIG_XENO_OPT_HOSTRT=y
#
# Timing
#
# CONFIG_XENO_OPT_TIMING_PERIODIC is not set
CONFIG_XENO_OPT_TIMING_VIRTICK=1000
CONFIG_XENO_OPT_TIMING_SCHEDLAT=0
#
# Scalability
#
# CONFIG_XENO_OPT_SCALABLE_SCHED is not set
CONFIG_XENO_OPT_TIMER_LIST=y
# CONFIG_XENO_OPT_TIMER_HEAP is not set
# CONFIG_XENO_OPT_TIMER_WHEEL is not set
#
# Machine
#
CONFIG_IPIPE_WANT_PREEMPTIBLE_SWITCH=y
CONFIG_XENO_HW_FPU=y
CONFIG_XENO_HW_UNLOCKED_SWITCH=y
#
# Interfaces
#
CONFIG_XENO_SKIN_NATIVE=y
CONFIG_XENO_OPT_NATIVE_PERIOD=0
CONFIG_XENO_OPT_NATIVE_PIPE=y
CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=1024
CONFIG_XENO_OPT_NATIVE_SEM=y
CONFIG_XENO_OPT_NATIVE_EVENT=y
CONFIG_XENO_OPT_NATIVE_MUTEX=y
CONFIG_XENO_OPT_NATIVE_COND=y
CONFIG_XENO_OPT_NATIVE_QUEUE=y
CONFIG_XENO_OPT_NATIVE_BUFFER=y
CONFIG_XENO_OPT_NATIVE_HEAP=y
CONFIG_XENO_OPT_NATIVE_ALARM=y
CONFIG_XENO_OPT_NATIVE_MPS=y
# CONFIG_XENO_OPT_NATIVE_INTR is not set
CONFIG_XENO_OPT_DEBUG_NATIVE=y
CONFIG_XENO_SKIN_POSIX=y
CONFIG_XENO_OPT_POSIX_PERIOD=0
CONFIG_XENO_OPT_POSIX_REGISTRY_NRSLOTS=64
CONFIG_XENO_OPT_POSIX_REGISTRY_NRDESCS=128
CONFIG_XENO_OPT_POSIX_NRTIMERS=128
# CONFIG_XENO_OPT_POSIX_SHM is not set
# CONFIG_XENO_OPT_POSIX_INTR is not set
CONFIG_XENO_OPT_POSIX_SELECT=y
CONFIG_XENO_OPT_DEBUG_POSIX=y
# CONFIG_XENO_SKIN_PSOS is not set
# CONFIG_XENO_SKIN_UITRON is not set
# CONFIG_XENO_SKIN_VRTX is not set
# CONFIG_XENO_SKIN_VXWORKS is not set
# CONFIG_XENO_OPT_NOWARN_DEPRECATED is not set
CONFIG_XENO_SKIN_RTDM=y
CONFIG_XENO_OPT_RTDM_PERIOD=0
CONFIG_XENO_OPT_RTDM_FILDES=128
CONFIG_XENO_OPT_RTDM_SELECT=y
# CONFIG_XENO_OPT_DEBUG_RTDM is not set
CONFIG_XENO_OPT_DEBUG_RTDM_APPL=y
#
# Drivers
#
#
# Serial drivers
#
# CONFIG_XENO_DRIVERS_16550A is not set
#
# Testing drivers
#
CONFIG_XENO_DRIVERS_TIMERBENCH=y
# CONFIG_XENO_DRIVERS_KLATENCY is not set
# CONFIG_XENO_DRIVERS_IRQBENCH is not set
CONFIG_XENO_DRIVERS_SWITCHTEST=y
# CONFIG_XENO_DRIVERS_RTDMTEST is not set
#
# CAN drivers
#
# CONFIG_XENO_DRIVERS_CAN is not set
#
# ANALOGY drivers
#
# CONFIG_XENO_DRIVERS_ANALOGY is not set
#
# Real-time IPC drivers
#
CONFIG_XENO_DRIVERS_RTIPC=y
CONFIG_XENO_DRIVERS_RTIPC_XDDP=y
CONFIG_XENO_DRIVERS_RTIPC_IDDP=y
CONFIG_XENO_OPT_IDDP_NRPORT=32
CONFIG_XENO_DRIVERS_RTIPC_BUFP=y
CONFIG_XENO_OPT_BUFP_NRPORT=32
CONFIG_FREEZER=y
#
# System Type
#
CONFIG_MMU=y
# CONFIG_ARCH_MULTIPLATFORM is not set
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_GEMINI is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_DOVE is not set
# CONFIG_ARCH_KIRKWOOD is not set
# CONFIG_ARCH_MV78XX0 is not set
# CONFIG_ARCH_ORION5X is not set
# CONFIG_ARCH_MMP is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_W90X900 is not set
# CONFIG_ARCH_LPC32XX is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_MSM_NODT is not set
# CONFIG_ARCH_SHMOBILE_LEGACY is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C24XX is not set
# CONFIG_ARCH_S3C64XX is not set
# CONFIG_ARCH_S5P64X0 is not set
# CONFIG_ARCH_S5PC100 is not set
# CONFIG_ARCH_S5PV210 is not set
# CONFIG_ARCH_EXYNOS is not set
CONFIG_ARCH_DAVINCI=y
# CONFIG_ARCH_OMAP1 is not set
CONFIG_CP_INTC=y
#
# TI DaVinci Implementations
#
#
# DaVinci Core Type
#
# CONFIG_ARCH_DAVINCI_DM644x is not set
# CONFIG_ARCH_DAVINCI_DM355 is not set
# CONFIG_ARCH_DAVINCI_DM646x is not set
CONFIG_ARCH_DAVINCI_DA830=y
CONFIG_ARCH_DAVINCI_DA850=y
CONFIG_ARCH_DAVINCI_DA8XX=y
# CONFIG_ARCH_DAVINCI_DM365 is not set
# CONFIG_ARCH_DAVINCI_TNETV107X is not set
#
# DaVinci Board Type
#
CONFIG_MACH_DA8XX_DT=y
CONFIG_MACH_DAVINCI_DA830_EVM=y
CONFIG_DA830_UI_LCD=y
# CONFIG_DA830_UI_NAND is not set
CONFIG_MACH_DAVINCI_DA850_EVM=y
CONFIG_DA850_UI_NONE=y
# CONFIG_DA850_UI_RMII is not set
# CONFIG_DA850_UI_SD_VIDEO_PORT is not set
# CONFIG_DA850_WL12XX is not set
CONFIG_GPIO_PCA953X=y
CONFIG_KEYBOARD_GPIO_POLLED=y
CONFIG_MACH_MITYOMAPL138=y
CONFIG_MACH_OMAPL138_HAWKBOARD=y
CONFIG_DAVINCI_MUX=y
# CONFIG_DAVINCI_MUX_DEBUG is not set
# CONFIG_DAVINCI_MUX_WARNINGS is not set
CONFIG_DAVINCI_RESET_CLOCKS=y
# CONFIG_PLAT_SPEAR is not set
CONFIG_IPIPE_ARM_KUSER_TSC=y
#
# Processor Type
#
CONFIG_CPU_ARM926T=y
CONFIG_CPU_32v5=y
CONFIG_CPU_ABRT_EV5TJ=y
CONFIG_CPU_PABRT_LEGACY=y
CONFIG_CPU_CACHE_VIVT=y
CONFIG_CPU_COPY_V4WB=y
CONFIG_CPU_TLB_V4WBI=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y
CONFIG_CPU_USE_DOMAINS=y
#
# Processor Features
#
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
CONFIG_ARM_THUMB=y
# CONFIG_CPU_ICACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
CONFIG_CPU_DCACHE_WRITETHROUGH=y
# CONFIG_CPU_CACHE_ROUND_ROBIN is not set
CONFIG_NEED_KUSER_HELPERS=y
CONFIG_KUSER_HELPERS=y
# CONFIG_CACHE_L2X0 is not set
CONFIG_ARM_L1_CACHE_SHIFT=5
CONFIG_ARM_FCSE=y
# CONFIG_ARM_FCSE_GUARANTEED is not set
CONFIG_ARM_FCSE_BEST_EFFORT=y
# CONFIG_ARM_FCSE_PREEMPT_FLUSH is not set
CONFIG_ARM_FCSE_MESSAGES=y
# CONFIG_ARM_FCSE_DEBUG is not set
CONFIG_ARM_NR_BANKS=8
CONFIG_TI_PRIV_EDMA=y
#
# Bus support
#
# CONFIG_PCI_SYSCALL is not set
# CONFIG_PCCARD is not set
#
# Kernel Features
#
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_ARCH_NR_GPIO=0
CONFIG_IPIPE=y
CONFIG_IPIPE_LEGACY=y
CONFIG_IPIPE_CORE=y
CONFIG_IPIPE_CORE_APIREV=2
CONFIG_IPIPE_WANT_APIREV_2=y
CONFIG_IPIPE_TARGET_APIREV=2
CONFIG_IPIPE_HAVE_HOSTRT=y
CONFIG_IPIPE_DELAYED_ATOMICSW=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_COUNT=y
CONFIG_HZ_FIXED=0
CONFIG_HZ_100=y
# CONFIG_HZ_200 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
# CONFIG_HZ_500 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=100
CONFIG_SCHED_HRTICK=y
CONFIG_AEABI=y
# CONFIG_OABI_COMPAT is not set
CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y
# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
CONFIG_HAVE_ARCH_PFN_VALID=y
# CONFIG_HIGHMEM is not set
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_NO_BOOTMEM=y
# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=999999
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_NEED_PER_CPU_KM=y
# CONFIG_CLEANCACHE is not set
# CONFIG_CMA is not set
# CONFIG_ZBUD is not set
# CONFIG_ZSMALLOC is not set
CONFIG_FORCE_MAX_ZONEORDER=11
CONFIG_ALIGNMENT_TRAP=y
# CONFIG_UACCESS_WITH_MEMCPY is not set
# CONFIG_SECCOMP is not set
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y
#
# Boot options
#
CONFIG_USE_OF=y
CONFIG_ATAGS=y
# CONFIG_DEPRECATED_PARAM_STRUCT is not set
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
# CONFIG_ARM_APPENDED_DTB is not set
CONFIG_CMDLINE=""
# CONFIG_XIP_KERNEL is not set
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
# CONFIG_AUTO_ZRELADDR is not set
#
# CPU Power Management
#
#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
#
# CPU Idle
#
# CONFIG_CPU_IDLE is not set
# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set
#
# Floating point emulation
#
#
# At least one emulation must be selected
#
# CONFIG_VFP is not set
#
# Userspace binary formats
#
CONFIG_BINFMT_ELF=y
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_BINFMT_SCRIPT=y
# CONFIG_HAVE_AOUT is not set
# CONFIG_BINFMT_MISC is not set
CONFIG_COREDUMP=y
#
# Power management options
#
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_PM_SLEEP=y
# CONFIG_PM_AUTOSLEEP is not set
# CONFIG_PM_WAKELOCKS is not set
CONFIG_PM_RUNTIME=y
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
# CONFIG_APM_EMULATION is not set
CONFIG_PM_CLK=y
# CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set
CONFIG_CPU_PM=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARM_CPU_SUSPEND=y
CONFIG_NET=y
#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_DIAG is not set
CONFIG_UNIX=y
# CONFIG_UNIX_DIAG is not set
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_XFRM_STATISTICS is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
# CONFIG_IP_PNP_BOOTP is not set
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE_DEMUX is not set
CONFIG_NET_IP_TUNNEL=m
# CONFIG_SYN_COOKIES is not set
# CONFIG_NET_IPVTI is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
CONFIG_INET_TUNNEL=m
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
# CONFIG_INET_LRO is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_INET_UDP_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
CONFIG_IPV6=m
# CONFIG_IPV6_ROUTER_PREF is not set
# CONFIG_IPV6_OPTIMISTIC_DAD is not set
# CONFIG_INET6_AH is not set
# CONFIG_INET6_ESP is not set
# CONFIG_INET6_IPCOMP is not set
# CONFIG_IPV6_MIP6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
CONFIG_INET6_XFRM_MODE_TRANSPORT=m
CONFIG_INET6_XFRM_MODE_TUNNEL=m
CONFIG_INET6_XFRM_MODE_BEET=m
# CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
# CONFIG_IPV6_VTI is not set
CONFIG_IPV6_SIT=m
# CONFIG_IPV6_SIT_6RD is not set
CONFIG_IPV6_NDISC_NODETYPE=y
# CONFIG_IPV6_TUNNEL is not set
# CONFIG_IPV6_GRE is not set
# CONFIG_IPV6_MULTIPLE_TABLES is not set
# CONFIG_IPV6_MROUTE is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_NETFILTER_ADVANCED=y
#
# Core Netfilter Configuration
#
# CONFIG_NETFILTER_NETLINK_ACCT is not set
# CONFIG_NETFILTER_NETLINK_QUEUE is not set
# CONFIG_NETFILTER_NETLINK_LOG is not set
# CONFIG_NF_CONNTRACK is not set
# CONFIG_NF_TABLES is not set
# CONFIG_NETFILTER_XTABLES is not set
# CONFIG_IP_SET is not set
# CONFIG_IP_VS is not set
#
# IP: Netfilter Configuration
#
# CONFIG_NF_DEFRAG_IPV4 is not set
# CONFIG_IP_NF_IPTABLES is not set
# CONFIG_IP_NF_ARPTABLES is not set
#
# IPv6: Netfilter Configuration
#
# CONFIG_NF_DEFRAG_IPV6 is not set
# CONFIG_IP6_NF_IPTABLES is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_L2TP is not set
# CONFIG_BRIDGE is not set
CONFIG_HAVE_NET_DSA=y
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
# CONFIG_DCB is not set
# CONFIG_BATMAN_ADV is not set
# CONFIG_OPENVSWITCH is not set
# CONFIG_VSOCKETS is not set
# CONFIG_NETLINK_MMAP is not set
# CONFIG_NETLINK_DIAG is not set
# CONFIG_NET_MPLS_GSO is not set
# CONFIG_HSR is not set
# CONFIG_CGROUP_NET_PRIO is not set
# CONFIG_CGROUP_NET_CLASSID is not set
CONFIG_NET_RX_BUSY_POLL=y
CONFIG_BQL=y
# CONFIG_BPF_JIT is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NET_DROP_MONITOR is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
CONFIG_WIRELESS=y
# CONFIG_CFG80211 is not set
# CONFIG_LIB80211 is not set
#
# CFG80211 needs to be enabled for MAC80211
#
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_RFKILL_REGULATOR is not set
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set
# CONFIG_NFC is not set
CONFIG_HAVE_BPF_JIT=y
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_FW_LOADER is not set
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_GENERIC_CPU_DEVICES is not set
CONFIG_REGMAP=y
CONFIG_REGMAP_I2C=m
# CONFIG_DMA_SHARED_BUFFER is not set
#
# Bus devices
#
# CONFIG_ARM_CCI is not set
# CONFIG_CONNECTOR is not set
# CONFIG_MTD is not set
CONFIG_DTC=y
CONFIG_OF=y
#
# Device Tree and Open Firmware support
#
# CONFIG_PROC_DEVICETREE is not set
# CONFIG_OF_SELFTEST is not set
CONFIG_OF_FLATTREE=y
CONFIG_OF_EARLY_FLATTREE=y
CONFIG_OF_ADDRESS=y
CONFIG_OF_IRQ=y
CONFIG_OF_NET=y
CONFIG_OF_MDIO=y
# CONFIG_PARPORT is not set
CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_NULL_BLK is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_DRBD is not set
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=1
CONFIG_BLK_DEV_RAM_SIZE=32768
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_MG_DISK is not set
# CONFIG_BLK_DEV_RBD is not set
#
# Misc devices
#
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_AD525X_DPOT is not set
# CONFIG_ATMEL_PWM is not set
# CONFIG_DUMMY_IRQ is not set
# CONFIG_ICS932S401 is not set
# CONFIG_ATMEL_SSC is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_APDS9802ALS is not set
# CONFIG_ISL29003 is not set
# CONFIG_ISL29020 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_SENSORS_BH1780 is not set
# CONFIG_SENSORS_BH1770 is not set
# CONFIG_SENSORS_APDS990X is not set
# CONFIG_HMC6352 is not set
# CONFIG_DS1682 is not set
# CONFIG_BMP085_I2C is not set
# CONFIG_USB_SWITCH_FSA9480 is not set
# CONFIG_SRAM is not set
# CONFIG_C2PORT is not set
#
# EEPROM support
#
CONFIG_EEPROM_AT24=y
# CONFIG_EEPROM_LEGACY is not set
# CONFIG_EEPROM_MAX6875 is not set
# CONFIG_EEPROM_93CX6 is not set
#
# Texas Instruments shared transport line discipline
#
# CONFIG_TI_ST is not set
# CONFIG_SENSORS_LIS3_I2C is not set
#
# Altera FPGA firmware download module
#
# CONFIG_ALTERA_STAPL is not set
#
# Intel MIC Host Driver
#
#
# Intel MIC Card Driver
#
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set
#
# SCSI device support
#
CONFIG_SCSI_MOD=m
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=m
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
CONFIG_SCSI_PROC_FS=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
# CONFIG_CHR_DEV_SCH is not set
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set
#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
# CONFIG_ISCSI_BOOT_SYSFS is not set
# CONFIG_SCSI_UFSHCD is not set
# CONFIG_LIBFC is not set
# CONFIG_LIBFCOE is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
# CONFIG_ATA is not set
# CONFIG_MD is not set
# CONFIG_TARGET_CORE is not set
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
# CONFIG_BONDING is not set
# CONFIG_DUMMY is not set
# CONFIG_EQUALIZER is not set
# CONFIG_NET_TEAM is not set
# CONFIG_MACVLAN is not set
# CONFIG_VXLAN is not set
CONFIG_NETCONSOLE=y
CONFIG_NETPOLL=y
CONFIG_NETPOLL_TRAP=y
CONFIG_NET_POLL_CONTROLLER=y
CONFIG_TUN=m
# CONFIG_VETH is not set
# CONFIG_NLMON is not set
#
# CAIF transport drivers
#
#
# Distributed Switch Architecture drivers
#
# CONFIG_NET_DSA_MV88E6XXX is not set
# CONFIG_NET_DSA_MV88E6060 is not set
# CONFIG_NET_DSA_MV88E6XXX_NEED_PPU is not set
# CONFIG_NET_DSA_MV88E6131 is not set
# CONFIG_NET_DSA_MV88E6123_61_65 is not set
CONFIG_ETHERNET=y
CONFIG_NET_VENDOR_ARC=y
# CONFIG_ARC_EMAC is not set
CONFIG_NET_CADENCE=y
# CONFIG_ARM_AT91_ETHER is not set
# CONFIG_MACB is not set
CONFIG_NET_VENDOR_BROADCOM=y
# CONFIG_B44 is not set
# CONFIG_NET_CALXEDA_XGMAC is not set
CONFIG_NET_VENDOR_CIRRUS=y
# CONFIG_CS89x0 is not set
# CONFIG_DM9000 is not set
# CONFIG_DNET is not set
CONFIG_NET_VENDOR_FARADAY=y
# CONFIG_FTMAC100 is not set
# CONFIG_FTGMAC100 is not set
CONFIG_NET_VENDOR_INTEL=y
CONFIG_NET_VENDOR_I825XX=y
CONFIG_NET_VENDOR_MARVELL=y
# CONFIG_MVMDIO is not set
CONFIG_NET_VENDOR_MICREL=y
# CONFIG_KS8842 is not set
# CONFIG_KS8851_MLL is not set
CONFIG_NET_VENDOR_NATSEMI=y
CONFIG_NET_VENDOR_8390=y
# CONFIG_AX88796 is not set
# CONFIG_ETHOC is not set
# CONFIG_SH_ETH is not set
CONFIG_NET_VENDOR_SEEQ=y
CONFIG_NET_VENDOR_SMSC=y
# CONFIG_SMC91X is not set
# CONFIG_SMC911X is not set
# CONFIG_SMSC911X is not set
CONFIG_NET_VENDOR_STMICRO=y
# CONFIG_STMMAC_ETH is not set
CONFIG_NET_VENDOR_TI=y
CONFIG_TI_DAVINCI_EMAC=y
CONFIG_TI_DAVINCI_MDIO=y
CONFIG_TI_DAVINCI_CPDMA=y
# CONFIG_TI_CPSW is not set
CONFIG_NET_VENDOR_VIA=y
# CONFIG_VIA_VELOCITY is not set
CONFIG_NET_VENDOR_WIZNET=y
# CONFIG_WIZNET_W5100 is not set
# CONFIG_WIZNET_W5300 is not set
CONFIG_PHYLIB=y
#
# MII PHY device drivers
#
# CONFIG_AT803X_PHY is not set
# CONFIG_AMD_PHY is not set
# CONFIG_MARVELL_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_QSEMI_PHY is not set
CONFIG_LXT_PHY=y
# CONFIG_CICADA_PHY is not set
# CONFIG_VITESSE_PHY is not set
# CONFIG_SMSC_PHY is not set
# CONFIG_BROADCOM_PHY is not set
# CONFIG_BCM87XX_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_REALTEK_PHY is not set
# CONFIG_NATIONAL_PHY is not set
# CONFIG_STE10XP is not set
CONFIG_LSI_ET1011C_PHY=y
# CONFIG_MICREL_PHY is not set
# CONFIG_FIXED_PHY is not set
# CONFIG_MDIO_BITBANG is not set
# CONFIG_MDIO_BUS_MUX_GPIO is not set
# CONFIG_MDIO_BUS_MUX_MMIOREG is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
CONFIG_WLAN=y
# CONFIG_HOSTAP is not set
# CONFIG_WL_TI is not set
#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
# CONFIG_WAN is not set
# CONFIG_ISDN is not set
#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
CONFIG_INPUT_POLLDEV=y
# CONFIG_INPUT_SPARSEKMAP is not set
# CONFIG_INPUT_MATRIXKMAP is not set
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=m
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=m
CONFIG_INPUT_EVBUG=m
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ADP5588 is not set
# CONFIG_KEYBOARD_ADP5589 is not set
CONFIG_KEYBOARD_ATKBD=m
# CONFIG_KEYBOARD_QT1070 is not set
# CONFIG_KEYBOARD_QT2160 is not set
# CONFIG_KEYBOARD_LKKBD is not set
CONFIG_KEYBOARD_GPIO=y
# CONFIG_KEYBOARD_TCA6416 is not set
# CONFIG_KEYBOARD_TCA8418 is not set
# CONFIG_KEYBOARD_MATRIX is not set
# CONFIG_KEYBOARD_LM8333 is not set
# CONFIG_KEYBOARD_MAX7359 is not set
# CONFIG_KEYBOARD_MCS is not set
# CONFIG_KEYBOARD_MPR121 is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_OPENCORES is not set
# CONFIG_KEYBOARD_SAMSUNG is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_KEYBOARD_SUNKBD is not set
CONFIG_KEYBOARD_XTKBD=m
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
CONFIG_INPUT_TOUCHSCREEN=y
# CONFIG_TOUCHSCREEN_AD7879 is not set
# CONFIG_TOUCHSCREEN_ATMEL_MXT is not set
# CONFIG_TOUCHSCREEN_AUO_PIXCIR is not set
# CONFIG_TOUCHSCREEN_BU21013 is not set
# CONFIG_TOUCHSCREEN_CY8CTMG110 is not set
# CONFIG_TOUCHSCREEN_CYTTSP_CORE is not set
# CONFIG_TOUCHSCREEN_CYTTSP4_CORE is not set
# CONFIG_TOUCHSCREEN_DYNAPRO is not set
# CONFIG_TOUCHSCREEN_HAMPSHIRE is not set
# CONFIG_TOUCHSCREEN_EETI is not set
# CONFIG_TOUCHSCREEN_EGALAX is not set
# CONFIG_TOUCHSCREEN_FUJITSU is not set
# CONFIG_TOUCHSCREEN_ILI210X is not set
# CONFIG_TOUCHSCREEN_GUNZE is not set
# CONFIG_TOUCHSCREEN_ELO is not set
# CONFIG_TOUCHSCREEN_WACOM_W8001 is not set
# CONFIG_TOUCHSCREEN_WACOM_I2C is not set
# CONFIG_TOUCHSCREEN_MAX11801 is not set
# CONFIG_TOUCHSCREEN_MCS5000 is not set
# CONFIG_TOUCHSCREEN_MMS114 is not set
# CONFIG_TOUCHSCREEN_MTOUCH is not set
# CONFIG_TOUCHSCREEN_INEXIO is not set
# CONFIG_TOUCHSCREEN_MK712 is not set
# CONFIG_TOUCHSCREEN_PENMOUNT is not set
# CONFIG_TOUCHSCREEN_EDT_FT5X06 is not set
# CONFIG_TOUCHSCREEN_TOUCHRIGHT is not set
# CONFIG_TOUCHSCREEN_TOUCHWIN is not set
# CONFIG_TOUCHSCREEN_PIXCIR is not set
# CONFIG_TOUCHSCREEN_TOUCHIT213 is not set
# CONFIG_TOUCHSCREEN_TSC_SERIO is not set
# CONFIG_TOUCHSCREEN_TSC2007 is not set
# CONFIG_TOUCHSCREEN_W90X900 is not set
# CONFIG_TOUCHSCREEN_ST1232 is not set
# CONFIG_TOUCHSCREEN_TPS6507X is not set
# CONFIG_TOUCHSCREEN_ZFORCE is not set
# CONFIG_INPUT_MISC is not set
#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_SERPORT=y
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_SERIO_ALTERA_PS2 is not set
# CONFIG_SERIO_PS2MULT is not set
# CONFIG_SERIO_ARC_PS2 is not set
# CONFIG_SERIO_APBPS2 is not set
# CONFIG_SERIO_OLPC_APSP is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#
CONFIG_TTY=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
# CONFIG_VT_CONSOLE is not set
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_N_GSM is not set
# CONFIG_TRACE_SINK is not set
CONFIG_DEVKMEM=y
#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_DEPRECATED_OPTIONS=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_DMA=y
CONFIG_SERIAL_8250_NR_UARTS=3
CONFIG_SERIAL_8250_RUNTIME_UARTS=3
# CONFIG_SERIAL_8250_EXTENDED is not set
# CONFIG_SERIAL_8250_DW is not set
# CONFIG_SERIAL_8250_EM is not set
#
# Non-8250 serial port support
#
# CONFIG_SERIAL_SH_SCI is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_OF_PLATFORM=y
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_XILINX_PS_UART is not set
# CONFIG_SERIAL_ARC is not set
# CONFIG_SERIAL_FSL_LPUART is not set
# CONFIG_SERIAL_ST_ASC is not set
# CONFIG_TTY_PRINTK is not set
# CONFIG_HVC_DCC is not set
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=m
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
# CONFIG_HW_RANDOM_ATMEL is not set
# CONFIG_HW_RANDOM_EXYNOS is not set
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
CONFIG_I2C_CHARDEV=y
# CONFIG_I2C_MUX is not set
CONFIG_I2C_HELPER_AUTO=y
#
# I2C Hardware Bus support
#
#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_CBUS_GPIO is not set
CONFIG_I2C_DAVINCI=y
# CONFIG_I2C_DESIGNWARE_PLATFORM is not set
# CONFIG_I2C_GPIO is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_PXA_PCI is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_XILINX is not set
#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set
#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_SPI is not set
# CONFIG_HSI is not set
#
# PPS support
#
# CONFIG_PPS is not set
#
# PPS generators support
#
#
# PTP clock support
#
# CONFIG_PTP_1588_CLOCK is not set
#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
CONFIG_PINCTRL=y
#
# Pin controllers
#
CONFIG_PINMUX=y
CONFIG_PINCONF=y
CONFIG_GENERIC_PINCONF=y
# CONFIG_DEBUG_PINCTRL is not set
# CONFIG_PINCTRL_CAPRI is not set
# CONFIG_PINCTRL_MSM8X74 is not set
CONFIG_PINCTRL_SINGLE=y
CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y
CONFIG_ARCH_REQUIRE_GPIOLIB=y
CONFIG_GPIOLIB=y
CONFIG_GPIO_DEVRES=y
CONFIG_OF_GPIO=y
# CONFIG_DEBUG_GPIO is not set
# CONFIG_GPIO_SYSFS is not set
#
# Memory mapped GPIO drivers:
#
CONFIG_GPIO_DAVINCI=y
# CONFIG_GPIO_GENERIC_PLATFORM is not set
# CONFIG_GPIO_EM is not set
# CONFIG_GPIO_RCAR is not set
# CONFIG_GPIO_SCH311X is not set
# CONFIG_GPIO_TS5500 is not set
# CONFIG_GPIO_GRGPIO is not set
#
# I2C GPIO expanders:
#
# CONFIG_GPIO_MAX7300 is not set
# CONFIG_GPIO_MAX732X is not set
# CONFIG_GPIO_PCA953X_IRQ is not set
CONFIG_GPIO_PCF857X=y
# CONFIG_GPIO_SX150X is not set
# CONFIG_GPIO_ADP5588 is not set
# CONFIG_GPIO_ADNP is not set
#
# PCI GPIO expanders:
#
#
# SPI GPIO expanders:
#
# CONFIG_GPIO_MCP23S08 is not set
#
# AC97 GPIO expanders:
#
#
# LPC GPIO expanders:
#
#
# MODULbus GPIO expanders:
#
# CONFIG_GPIO_BCM_KONA is not set
#
# USB GPIO expanders:
#
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
# CONFIG_POWER_AVS is not set
# CONFIG_HWMON is not set
# CONFIG_THERMAL is not set
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_CORE is not set
# CONFIG_WATCHDOG_NOWAYOUT is not set
#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
# CONFIG_GPIO_WATCHDOG is not set
# CONFIG_DW_WATCHDOG is not set
# CONFIG_DAVINCI_WATCHDOG is not set
# CONFIG_MAX63XX_WATCHDOG is not set
# CONFIG_MEN_A21_WDT is not set
CONFIG_SSB_POSSIBLE=y
#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y
#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set
#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_AS3711 is not set
# CONFIG_MFD_AS3722 is not set
# CONFIG_PMIC_ADP5520 is not set
# CONFIG_MFD_AAT2870_CORE is not set
# CONFIG_MFD_CROS_EC is not set
# CONFIG_MFD_ASIC3 is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_MFD_DA9052_I2C is not set
# CONFIG_MFD_DA9055 is not set
# CONFIG_MFD_DA9063 is not set
# CONFIG_MFD_MC13XXX_I2C is not set
# CONFIG_HTC_EGPIO is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_HTC_I2CPLD is not set
# CONFIG_MFD_KEMPLD is not set
# CONFIG_MFD_88PM800 is not set
# CONFIG_MFD_88PM805 is not set
# CONFIG_MFD_88PM860X is not set
# CONFIG_MFD_MAX14577 is not set
# CONFIG_MFD_MAX77686 is not set
# CONFIG_MFD_MAX77693 is not set
# CONFIG_MFD_MAX8907 is not set
# CONFIG_MFD_MAX8925 is not set
# CONFIG_MFD_MAX8997 is not set
# CONFIG_MFD_MAX8998 is not set
# CONFIG_MFD_RETU is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_MFD_RC5T583 is not set
# CONFIG_MFD_SEC_CORE is not set
# CONFIG_MFD_SI476X_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_MFD_SMSC is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_MFD_STMPE is not set
# CONFIG_MFD_SYSCON is not set
# CONFIG_MFD_TI_AM335X_TSCADC is not set
# CONFIG_MFD_LP3943 is not set
# CONFIG_MFD_LP8788 is not set
# CONFIG_MFD_PALMAS is not set
# CONFIG_TPS6105X is not set
# CONFIG_TPS65010 is not set
# CONFIG_TPS6507X is not set
# CONFIG_MFD_TPS65090 is not set
# CONFIG_MFD_TPS65217 is not set
# CONFIG_MFD_TPS6586X is not set
# CONFIG_MFD_TPS65910 is not set
# CONFIG_MFD_TPS65912 is not set
# CONFIG_MFD_TPS65912_I2C is not set
# CONFIG_MFD_TPS80031 is not set
# CONFIG_TWL4030_CORE is not set
# CONFIG_TWL6040_CORE is not set
# CONFIG_MFD_WL1273_CORE is not set
# CONFIG_MFD_LM3533 is not set
# CONFIG_MFD_TC3589X is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_T7L66XB is not set
# CONFIG_MFD_TC6387XB is not set
# CONFIG_MFD_TC6393XB is not set
# CONFIG_MFD_ARIZONA_I2C is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM831X_I2C is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_WM8994 is not set
# CONFIG_VEXPRESS_CONFIG is not set
CONFIG_REGULATOR=y
# CONFIG_REGULATOR_DEBUG is not set
# CONFIG_REGULATOR_FIXED_VOLTAGE is not set
# CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set
# CONFIG_REGULATOR_USERSPACE_CONSUMER is not set
# CONFIG_REGULATOR_ACT8865 is not set
# CONFIG_REGULATOR_AD5398 is not set
# CONFIG_REGULATOR_DA9210 is not set
# CONFIG_REGULATOR_FAN53555 is not set
# CONFIG_REGULATOR_GPIO is not set
# CONFIG_REGULATOR_ISL6271A is not set
# CONFIG_REGULATOR_LP3971 is not set
# CONFIG_REGULATOR_LP3972 is not set
# CONFIG_REGULATOR_LP872X is not set
# CONFIG_REGULATOR_LP8755 is not set
# CONFIG_REGULATOR_MAX1586 is not set
# CONFIG_REGULATOR_MAX8649 is not set
# CONFIG_REGULATOR_MAX8660 is not set
# CONFIG_REGULATOR_MAX8952 is not set
# CONFIG_REGULATOR_MAX8973 is not set
# CONFIG_REGULATOR_PFUZE100 is not set
# CONFIG_REGULATOR_TPS51632 is not set
# CONFIG_REGULATOR_TPS62360 is not set
# CONFIG_REGULATOR_TPS65023 is not set
CONFIG_REGULATOR_TPS6507X=y
# CONFIG_MEDIA_SUPPORT is not set
#
# Graphics support
#
# CONFIG_DRM is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
CONFIG_VIDEOMODE_HELPERS=y
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
# CONFIG_FB_DDC is not set
# CONFIG_FB_BOOT_VESA_SUPPORT is not set
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
CONFIG_FB_CFB_REV_PIXELS_IN_BYTE=y
# CONFIG_FB_SYS_FILLRECT is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_FOREIGN_ENDIAN is not set
# CONFIG_FB_SYS_FOPS is not set
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
# CONFIG_FB_TILEBLITTING is not set
#
# Frame buffer hardware drivers
#
# CONFIG_FB_OPENCORES is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_GOLDFISH is not set
CONFIG_FB_DA8XX=y
# CONFIG_FB_VIRTUAL is not set
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_BROADSHEET is not set
# CONFIG_FB_AUO_K190X is not set
# CONFIG_FB_SIMPLE is not set
# CONFIG_EXYNOS_VIDEO is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
#
# Console display driver support
#
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
CONFIG_LOGO_LINUX_VGA16=y
CONFIG_LOGO_LINUX_CLUT224=y
# CONFIG_FB_SSD1307 is not set
CONFIG_SOUND=m
# CONFIG_SOUND_OSS_CORE is not set
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_COMPRESS_OFFLOAD=m
CONFIG_SND_JACK=y
# CONFIG_SND_SEQUENCER is not set
# CONFIG_SND_MIXER_OSS is not set
# CONFIG_SND_PCM_OSS is not set
# CONFIG_SND_HRTIMER is not set
# CONFIG_SND_DYNAMIC_MINORS is not set
CONFIG_SND_SUPPORT_OLD_API=y
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
# CONFIG_SND_RAWMIDI_SEQ is not set
# CONFIG_SND_OPL3_LIB_SEQ is not set
# CONFIG_SND_OPL4_LIB_SEQ is not set
# CONFIG_SND_SBAWE_SEQ is not set
# CONFIG_SND_EMU10K1_SEQ is not set
CONFIG_SND_DRIVERS=y
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_ALOOP is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set
CONFIG_SND_ARM=y
CONFIG_SND_SOC=m
# CONFIG_SND_ATMEL_SOC is not set
CONFIG_SND_DAVINCI_SOC=m
# CONFIG_SND_DA830_SOC_EVM is not set
# CONFIG_SND_DA850_SOC_EVM is not set
# CONFIG_SND_DESIGNWARE_I2S is not set
CONFIG_SND_SOC_I2C_AND_SPI=m
# CONFIG_SND_SIMPLE_CARD is not set
# CONFIG_SOUND_PRIME is not set
#
# HID support
#
CONFIG_HID=y
# CONFIG_HIDRAW is not set
# CONFIG_UHID is not set
CONFIG_HID_GENERIC=y
#
# Special HID drivers
#
# CONFIG_HID_A4TECH is not set
# CONFIG_HID_ACRUX is not set
# CONFIG_HID_APPLE is not set
# CONFIG_HID_AUREAL is not set
# CONFIG_HID_BELKIN is not set
# CONFIG_HID_CHERRY is not set
# CONFIG_HID_CHICONY is not set
# CONFIG_HID_PRODIKEYS is not set
# CONFIG_HID_CYPRESS is not set
# CONFIG_HID_DRAGONRISE is not set
# CONFIG_HID_EMS_FF is not set
# CONFIG_HID_ELECOM is not set
# CONFIG_HID_EZKEY is not set
# CONFIG_HID_KEYTOUCH is not set
# CONFIG_HID_KYE is not set
# CONFIG_HID_UCLOGIC is not set
# CONFIG_HID_WALTOP is not set
# CONFIG_HID_GYRATION is not set
# CONFIG_HID_ICADE is not set
# CONFIG_HID_TWINHAN is not set
# CONFIG_HID_KENSINGTON is not set
# CONFIG_HID_LCPOWER is not set
# CONFIG_HID_LENOVO_TPKBD is not set
# CONFIG_HID_LOGITECH is not set
# CONFIG_HID_MAGICMOUSE is not set
# CONFIG_HID_MICROSOFT is not set
# CONFIG_HID_MONTEREY is not set
# CONFIG_HID_MULTITOUCH is not set
# CONFIG_HID_ORTEK is not set
# CONFIG_HID_PANTHERLORD is not set
# CONFIG_HID_PETALYNX is not set
# CONFIG_HID_PICOLCD is not set
# CONFIG_HID_PRIMAX is not set
# CONFIG_HID_SAITEK is not set
# CONFIG_HID_SAMSUNG is not set
# CONFIG_HID_SPEEDLINK is not set
# CONFIG_HID_STEELSERIES is not set
# CONFIG_HID_SUNPLUS is not set
# CONFIG_HID_GREENASIA is not set
# CONFIG_HID_SMARTJOYPLUS is not set
# CONFIG_HID_TIVO is not set
# CONFIG_HID_TOPSEED is not set
# CONFIG_HID_THRUSTMASTER is not set
# CONFIG_HID_XINMO is not set
# CONFIG_HID_ZEROPLUS is not set
# CONFIG_HID_ZYDACRON is not set
# CONFIG_HID_SENSOR_HUB is not set
#
# I2C HID support
#
# CONFIG_I2C_HID is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
# CONFIG_USB_SUPPORT is not set
CONFIG_MMC=y
# CONFIG_MMC_DEBUG is not set
# CONFIG_MMC_UNSAFE_RESUME is not set
# CONFIG_MMC_CLKGATE is not set
#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_MINORS=8
CONFIG_MMC_BLOCK_BOUNCE=y
# CONFIG_SDIO_UART is not set
# CONFIG_MMC_TEST is not set
#
# MMC/SD/SDIO Host Controller Drivers
#
# CONFIG_MMC_SDHCI is not set
# CONFIG_MMC_SDHCI_PXAV3 is not set
# CONFIG_MMC_SDHCI_PXAV2 is not set
CONFIG_MMC_DAVINCI=y
# CONFIG_MMC_DW is not set
# CONFIG_MEMSTICK is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=y
# CONFIG_RTC_CLASS is not set
CONFIG_DMADEVICES=y
# CONFIG_DMADEVICES_DEBUG is not set
#
# DMA Devices
#
# CONFIG_DW_DMAC_CORE is not set
# CONFIG_DW_DMAC is not set
# CONFIG_TIMB_DMA is not set
CONFIG_TI_EDMA=y
CONFIG_DMA_ENGINE=y
CONFIG_DMA_VIRTUAL_CHANNELS=y
CONFIG_DMA_OF=y
#
# DMA Clients
#
# CONFIG_ASYNC_TX_DMA is not set
# CONFIG_DMATEST is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
# CONFIG_VIRT_DRIVERS is not set
#
# Virtio drivers
#
# CONFIG_VIRTIO_MMIO is not set
#
# Microsoft Hyper-V guest support
#
# CONFIG_STAGING is not set
CONFIG_CLKDEV_LOOKUP=y
#
# Hardware Spinlock drivers
#
# CONFIG_MAILBOX is not set
CONFIG_IOMMU_SUPPORT=y
CONFIG_OF_IOMMU=y
#
# Remoteproc drivers
#
# CONFIG_STE_MODEM_RPROC is not set
# CONFIG_DA8XX_REMOTEPROC is not set
#
# Rpmsg drivers
#
# CONFIG_PM_DEVFREQ is not set
# CONFIG_EXTCON is not set
# CONFIG_MEMORY is not set
# CONFIG_IIO is not set
# CONFIG_PWM is not set
CONFIG_IRQCHIP=y
# CONFIG_IPACK_BUS is not set
# CONFIG_RESET_CONTROLLER is not set
# CONFIG_FMC is not set
#
# PHY Subsystem
#
# CONFIG_GENERIC_PHY is not set
# CONFIG_PHY_EXYNOS_MIPI_VIDEO is not set
# CONFIG_PHY_EXYNOS_DP_VIDEO is not set
# CONFIG_POWERCAP is not set
#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
# CONFIG_EXT3_FS_SECURITY is not set
# CONFIG_EXT4_FS is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_XFS_FS=m
# CONFIG_XFS_QUOTA is not set
# CONFIG_XFS_POSIX_ACL is not set
# CONFIG_XFS_RT is not set
# CONFIG_XFS_WARN is not set
# CONFIG_XFS_DEBUG is not set
# CONFIG_GFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
# CONFIG_FS_POSIX_ACL is not set
CONFIG_EXPORTFS=m
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
# CONFIG_QUOTA is not set
# CONFIG_QUOTACTL is not set
CONFIG_AUTOFS4_FS=m
# CONFIG_FUSE_FS is not set
#
# Caches
#
# CONFIG_FSCACHE is not set
#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_CONFIGFS_FS is not set
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_LOGFS is not set
CONFIG_CRAMFS=y
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
CONFIG_MINIX_FS=m
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX6FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_PSTORE is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_F2FS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V2=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_SWAP is not set
CONFIG_ROOT_NFS=y
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V3_ACL is not set
# CONFIG_NFSD_V4 is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_SUNRPC_DEBUG is not set
# CONFIG_CEPH_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=m
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_MAC_ROMAN is not set
# CONFIG_NLS_MAC_CELTIC is not set
# CONFIG_NLS_MAC_CENTEURO is not set
# CONFIG_NLS_MAC_CROATIAN is not set
# CONFIG_NLS_MAC_CYRILLIC is not set
# CONFIG_NLS_MAC_GAELIC is not set
# CONFIG_NLS_MAC_GREEK is not set
# CONFIG_NLS_MAC_ICELAND is not set
# CONFIG_NLS_MAC_INUIT is not set
# CONFIG_NLS_MAC_ROMANIAN is not set
# CONFIG_NLS_MAC_TURKISH is not set
CONFIG_NLS_UTF8=m
#
# Kernel hacking
#
#
# printk and dmesg options
#
# CONFIG_PRINTK_TIME is not set
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_DYNAMIC_DEBUG is not set
#
# Compile-time checks and compiler options
#
# CONFIG_DEBUG_INFO is not set
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_READABLE_ASM is not set
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_FRAME_POINTER=y
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_MAGIC_SYSRQ is not set
CONFIG_IPIPE_DEBUG=y
CONFIG_IPIPE_DEBUG_CONTEXT=y
CONFIG_IPIPE_DEBUG_INTERNAL=y
CONFIG_IPIPE_TRACE=y
CONFIG_IPIPE_TRACE_ENABLE=y
CONFIG_IPIPE_TRACE_MCOUNT=y
CONFIG_IPIPE_TRACE_IRQSOFF=y
CONFIG_IPIPE_TRACE_SHIFT=14
CONFIG_IPIPE_TRACE_VMALLOC=y
CONFIG_IPIPE_TRACE_PANIC=y
CONFIG_DEBUG_KERNEL=y
#
# Memory Debugging
#
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
CONFIG_HAVE_DEBUG_KMEMLEAK=y
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_MEMORY_INIT is not set
# CONFIG_DEBUG_SHIRQ is not set
#
# Debug Lockups and Hangs
#
# CONFIG_LOCKUP_DETECTOR is not set
# CONFIG_DETECT_HUNG_TASK is not set
# CONFIG_PANIC_ON_OOPS is not set
CONFIG_PANIC_ON_OOPS_VALUE=0
CONFIG_PANIC_TIMEOUT=0
CONFIG_SCHED_DEBUG=y
# CONFIG_SCHEDSTATS is not set
CONFIG_TIMER_STATS=y
CONFIG_DEBUG_PREEMPT=y
#
# Lock Debugging (spinlocks, mutexes, etc...)
#
CONFIG_DEBUG_RT_MUTEXES=y
CONFIG_DEBUG_PI_LIST=y
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
CONFIG_DEBUG_MUTEXES=y
# CONFIG_DEBUG_WW_MUTEX_SLOWPATH is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_ATOMIC_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_WRITECOUNT is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
#
# RCU Debugging
#
# CONFIG_PROVE_RCU_DELAY is not set
# CONFIG_SPARSE_RCU_POINTER is not set
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_RCU_CPU_STALL_TIMEOUT=21
CONFIG_RCU_CPU_STALL_VERBOSE=y
# CONFIG_RCU_CPU_STALL_INFO is not set
# CONFIG_RCU_TRACE is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_NOTIFIER_ERROR_INJECTION is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_LATENCYTOP is not set
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACE_CLOCK=y
CONFIG_RING_BUFFER=y
CONFIG_EVENT_TRACING=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_TRACING=y
CONFIG_GENERIC_TRACER=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y
CONFIG_FUNCTION_GRAPH_TRACER=y
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_PREEMPT_TRACER is not set
# CONFIG_SCHED_TRACER is not set
# CONFIG_FTRACE_SYSCALLS is not set
# CONFIG_TRACER_SNAPSHOT is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
# CONFIG_STACK_TRACER is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_PROBE_EVENTS is not set
# CONFIG_FUNCTION_PROFILER is not set
# CONFIG_FTRACE_STARTUP_TEST is not set
# CONFIG_RING_BUFFER_BENCHMARK is not set
# CONFIG_RING_BUFFER_STARTUP_TEST is not set
#
# Runtime Testing
#
# CONFIG_LKDTM is not set
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_RBTREE_TEST is not set
# CONFIG_INTERVAL_TREE_TEST is not set
# CONFIG_PERCPU_TEST is not set
# CONFIG_ATOMIC64_SELFTEST is not set
# CONFIG_TEST_STRING_HELPERS is not set
# CONFIG_TEST_KSTRTOX is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_TEST_MODULE is not set
# CONFIG_TEST_USER_COPY is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
# CONFIG_ARM_PTDUMP is not set
# CONFIG_STRICT_DEVMEM is not set
# CONFIG_ARM_UNWIND is not set
CONFIG_OLD_MCOUNT=y
CONFIG_DEBUG_USER=y
# CONFIG_DEBUG_LL is not set
CONFIG_DEBUG_LL_INCLUDE="mach/debug-macro.S"
# CONFIG_DEBUG_UART_PL01X is not set
# CONFIG_DEBUG_UART_8250 is not set
CONFIG_UNCOMPRESS_INCLUDE="mach/uncompress.h"
# CONFIG_DEBUG_SET_MODULE_RONX is not set
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_CRYPTO=y
#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_HASH=m
CONFIG_CRYPTO_HASH2=m
# CONFIG_CRYPTO_MANAGER is not set
# CONFIG_CRYPTO_MANAGER2 is not set
# CONFIG_CRYPTO_USER is not set
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_AUTHENC is not set
# CONFIG_CRYPTO_TEST is not set
#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set
#
# Block modes
#
# CONFIG_CRYPTO_CBC is not set
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
# CONFIG_CRYPTO_ECB is not set
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set
#
# Hash modes
#
# CONFIG_CRYPTO_CMAC is not set
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set
#
# Digest
#
CONFIG_CRYPTO_CRC32C=m
# CONFIG_CRYPTO_CRC32 is not set
CONFIG_CRYPTO_CRCT10DIF=m
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_MD4 is not set
# CONFIG_CRYPTO_MD5 is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA1_ARM is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set
#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_ARM is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set
#
# Compression
#
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_ZLIB is not set
# CONFIG_CRYPTO_LZO is not set
# CONFIG_CRYPTO_LZ4 is not set
# CONFIG_CRYPTO_LZ4HC is not set
#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
# CONFIG_CRYPTO_USER_API_HASH is not set
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
# CONFIG_CRYPTO_HW is not set
CONFIG_BINARY_PRINTF=y
#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_NET_UTILS=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IO=y
CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y
CONFIG_CRC_CCITT=m
# CONFIG_CRC16 is not set
CONFIG_CRC_T10DIF=m
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=m
# CONFIG_CRC8 is not set
# CONFIG_RANDOM32_SELFTEST is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
# CONFIG_XZ_DEC is not set
# CONFIG_XZ_DEC_BCJ is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_GENERIC_ALLOCATOR=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_DQL=y
CONFIG_NLATTR=y
CONFIG_GENERIC_ATOMIC64=y
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
# CONFIG_AVERAGE is not set
# CONFIG_CORDIC is not set
# CONFIG_DDR is not set
CONFIG_FONT_SUPPORT=y
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
# CONFIG_VIRTUALIZATION is not set
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-04-29 1:46 ` Peter Howard
@ 2014-05-04 19:25 ` Gilles Chanteperdrix
2014-05-05 23:00 ` Peter Howard
0 siblings, 1 reply; 57+ messages in thread
From: Gilles Chanteperdrix @ 2014-05-04 19:25 UTC (permalink / raw)
To: Peter Howard; +Cc: xenomai
On 04/29/2014 03:46 AM, Peter Howard wrote:
> On Thu, 2014-04-24 at 23:30 +0200, Gilles Chanteperdrix wrote:
>> On 04/23/2014 03:45 AM, Peter Howard wrote:
>>> On Wed, 2014-04-23 at 01:02 +0200, Gilles Chanteperdrix wrote:
>>>> On 04/15/2014 11:59 PM, Peter Howard wrote:
>>>>> On Tue, 2014-04-15 at 13:37 +0200, Gilles Chanteperdrix wrote:
>>>>>> On 04/15/2014 08:03 AM, Peter Howard wrote:
>>>>>>> On Fri, 2014-04-11 at 08:52 +1000, Peter Howard wrote:
>>>>>>>> On Fri, 2014-04-11 at 00:48 +0200, Gilles Chanteperdrix wrote:
>>>>>>>>> On 04/11/2014 12:34 AM, Peter Howard wrote:
>>>>>>>>>> On Fri, 2014-04-11 at 00:23 +0200, Gilles Chanteperdrix wrote:
>>>>>>>>>> (Stripping back conversation on this one - apologies if that's bad
>>>>>>>>>> etiquette for this list)
>>>>>>>>>>
>>>>>>>>>>> Attachment is better. Also please post the changes you made for omapL138
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
>>>>>>>>>> index a075b3e..3d8bc59 100644
>>>>>>>>>> --- a/arch/arm/mach-davinci/Kconfig
>>>>>>>>>> +++ b/arch/arm/mach-davinci/Kconfig
>>>>>>>>>> @@ -41,6 +41,8 @@ config ARCH_DAVINCI_DA850
>>>>>>>>>> select ARCH_DAVINCI_DA8XX
>>>>>>>>>> select ARCH_HAS_CPUFREQ
>>>>>>>>>> select CP_INTC
>>>>>>>>>> + select IPIPE_ARM_KUSER_TSC if IPIPE
>>>>>>>>>> + select ARM_FCSE if IPIPE
>>>>>>>>>
>>>>>>>>> You may want to leave the choice of enabling or disabling FCSE to the user.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Understood; at the moment the variance on max latency is really bad if
>>>>>>>> you don't enable FCSE. When I sort out the crashing issues I'll re-test
>>>>>>>> with it off.
>>>>>>>
>>>>>>> Well, FCSE turned out to be my problem.
>>>>>>>
>>>>>>> More specifically, FCSE and ARM_FCSE_BEST_EFFORT. Either a) disabling
>>>>>>> ARM_FCSE altogether, or b) selecting ARM_FCSE with ARM_FCSE_GUARENTEED
>>>>>>> gets rid of the crashes/panics with ipipe latency tracing enabled.
>>>>>>>
>>>>>>> So now things seem reasonably stable, I'll go through the full set of
>>>>>>> tests. Though I still can't do 'xeno-test -l "dohell -l /opt/ltp"' as
>>>>>>> ltp takes out the system without any ipipe/xenomai bits.
>>>>>>>
>>>>>> Ok, FCSE best effort is currently being validated on 3.14, so it may
>>>>>> well be broken. After all, the raw/* branches are work in progress.
>>>>>>
>>>>>
>>>>> Note: selecting ARM_FCSE_BEST_EFFORT produces the same result on the
>>>>> master branch too . . .
>>>>>
>>>> Hi Peter,
>>>>
>>>> I am unable to reproduce these issues with 3.14, FCSE seems to be doing
>>>> just fine, I can boot and run the LTP testsuite and get almost the same
>>>> results as a non patched kernel. I have tried with and without
>>>> preemptible cache flushes, and with and without Xenomai. My rootfs is
>>>> based on busybox and minimal, maybe that is the reason why it works
>>>> fine, could you put a tarball with your rootfs somewhere?
>>>
>>> A bit of testing shows (at least) one case is directly related to the
>>> rootfs. This is the Texas Instruments rootfs that is supplied for the
>>> DA850 board. During normal startup, it wants to start the GUI for the
>>> LCD which would go past the 32MB process limit with FCSE enabled. With
>>> FCSE_GUARENTEED selected this is noted but doesn't cause a crash. With
>>> FCSE_BEST_EFFORT selected this is noted and then the system crashes
>>> within a few seconds. I'm not sure if this counts as a bug in
>>> BEST_EFFORT or whether all bets are off if you try to start a process
>>> that's too large.
>>>
>>> At this point I'm not sure if anything else is specific to that rootfs
>>> but I'll still make it available to you to have a look.
>>
>> No luck with your rootfs: matrix_GUI craches indeed, but it also crashes
>> without CONFIG_FCSE, so it would seem the crash is unrelated to the
>> FCSE. Obviously it does not crash with FCSE_GUARANTEED, because it is
>> stopped as soon as it wants to go over 32 MB. And that crash does not
>> cause the cascade of crashes you mentioned, ending with init crashing.
>> The processor on which I am running the tests does not have a
>> framebuffer maybe that is the reason I get a crash, and do not go as far
>> as in your case.
>>
>> Could you post the kernel configuration you use?
>>
>
> Take 3. Ignore the previous two. They will probably trigger it, but
> this one I actually tested to confirm it does cause the crash.
This configuration with only omapl138 replaced with at91sam9263 seems to
run correctly, except for the segfault in the matrix_guiE application,
which I also have on an unpatched kernel. Note that this configuration
sets the cache to writethrough mode which, at least on at91sam9263
results in a much slower kernel than writeback mode.
So, I would say any remaining issue is specific to omapl138.
--
Gilles.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-05-04 19:25 ` Gilles Chanteperdrix
@ 2014-05-05 23:00 ` Peter Howard
2014-05-06 11:35 ` Gilles Chanteperdrix
0 siblings, 1 reply; 57+ messages in thread
From: Peter Howard @ 2014-05-05 23:00 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On Sun, 2014-05-04 at 21:25 +0200, Gilles Chanteperdrix wrote:
> On 04/29/2014 03:46 AM, Peter Howard wrote:
> > On Thu, 2014-04-24 at 23:30 +0200, Gilles Chanteperdrix wrote:
> >> On 04/23/2014 03:45 AM, Peter Howard wrote:
> >>> On Wed, 2014-04-23 at 01:02 +0200, Gilles Chanteperdrix wrote:
> >>>> On 04/15/2014 11:59 PM, Peter Howard wrote:
> >>>>> On Tue, 2014-04-15 at 13:37 +0200, Gilles Chanteperdrix wrote:
> >>>>>> On 04/15/2014 08:03 AM, Peter Howard wrote:
> >>>>>>> On Fri, 2014-04-11 at 08:52 +1000, Peter Howard wrote:
> >>>>>>>> On Fri, 2014-04-11 at 00:48 +0200, Gilles Chanteperdrix wrote:
> >>>>>>>>> On 04/11/2014 12:34 AM, Peter Howard wrote:
> >>>>>>>>>> On Fri, 2014-04-11 at 00:23 +0200, Gilles Chanteperdrix wrote:
> >>>>>>>>>> (Stripping back conversation on this one - apologies if that's bad
> >>>>>>>>>> etiquette for this list)
> >>>>>>>>>>
> >>>>>>>>>>> Attachment is better. Also please post the changes you made for omapL138
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
> >>>>>>>>>> index a075b3e..3d8bc59 100644
> >>>>>>>>>> --- a/arch/arm/mach-davinci/Kconfig
> >>>>>>>>>> +++ b/arch/arm/mach-davinci/Kconfig
> >>>>>>>>>> @@ -41,6 +41,8 @@ config ARCH_DAVINCI_DA850
> >>>>>>>>>> select ARCH_DAVINCI_DA8XX
> >>>>>>>>>> select ARCH_HAS_CPUFREQ
> >>>>>>>>>> select CP_INTC
> >>>>>>>>>> + select IPIPE_ARM_KUSER_TSC if IPIPE
> >>>>>>>>>> + select ARM_FCSE if IPIPE
> >>>>>>>>>
> >>>>>>>>> You may want to leave the choice of enabling or disabling FCSE to the user.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Understood; at the moment the variance on max latency is really bad if
> >>>>>>>> you don't enable FCSE. When I sort out the crashing issues I'll re-test
> >>>>>>>> with it off.
> >>>>>>>
> >>>>>>> Well, FCSE turned out to be my problem.
> >>>>>>>
> >>>>>>> More specifically, FCSE and ARM_FCSE_BEST_EFFORT. Either a) disabling
> >>>>>>> ARM_FCSE altogether, or b) selecting ARM_FCSE with ARM_FCSE_GUARENTEED
> >>>>>>> gets rid of the crashes/panics with ipipe latency tracing enabled.
> >>>>>>>
> >>>>>>> So now things seem reasonably stable, I'll go through the full set of
> >>>>>>> tests. Though I still can't do 'xeno-test -l "dohell -l /opt/ltp"' as
> >>>>>>> ltp takes out the system without any ipipe/xenomai bits.
> >>>>>>>
> >>>>>> Ok, FCSE best effort is currently being validated on 3.14, so it may
> >>>>>> well be broken. After all, the raw/* branches are work in progress.
> >>>>>>
> >>>>>
> >>>>> Note: selecting ARM_FCSE_BEST_EFFORT produces the same result on the
> >>>>> master branch too . . .
> >>>>>
> >>>> Hi Peter,
> >>>>
> >>>> I am unable to reproduce these issues with 3.14, FCSE seems to be doing
> >>>> just fine, I can boot and run the LTP testsuite and get almost the same
> >>>> results as a non patched kernel. I have tried with and without
> >>>> preemptible cache flushes, and with and without Xenomai. My rootfs is
> >>>> based on busybox and minimal, maybe that is the reason why it works
> >>>> fine, could you put a tarball with your rootfs somewhere?
> >>>
> >>> A bit of testing shows (at least) one case is directly related to the
> >>> rootfs. This is the Texas Instruments rootfs that is supplied for the
> >>> DA850 board. During normal startup, it wants to start the GUI for the
> >>> LCD which would go past the 32MB process limit with FCSE enabled. With
> >>> FCSE_GUARENTEED selected this is noted but doesn't cause a crash. With
> >>> FCSE_BEST_EFFORT selected this is noted and then the system crashes
> >>> within a few seconds. I'm not sure if this counts as a bug in
> >>> BEST_EFFORT or whether all bets are off if you try to start a process
> >>> that's too large.
> >>>
> >>> At this point I'm not sure if anything else is specific to that rootfs
> >>> but I'll still make it available to you to have a look.
> >>
> >> No luck with your rootfs: matrix_GUI craches indeed, but it also crashes
> >> without CONFIG_FCSE, so it would seem the crash is unrelated to the
> >> FCSE. Obviously it does not crash with FCSE_GUARANTEED, because it is
> >> stopped as soon as it wants to go over 32 MB. And that crash does not
> >> cause the cascade of crashes you mentioned, ending with init crashing.
> >> The processor on which I am running the tests does not have a
> >> framebuffer maybe that is the reason I get a crash, and do not go as far
> >> as in your case.
> >>
> >> Could you post the kernel configuration you use?
> >>
> >
> > Take 3. Ignore the previous two. They will probably trigger it, but
> > this one I actually tested to confirm it does cause the crash.
>
> This configuration with only omapl138 replaced with at91sam9263 seems to
> run correctly, except for the segfault in the matrix_guiE application,
> which I also have on an unpatched kernel. Note that this configuration
> sets the cache to writethrough mode which, at least on at91sam9263
> results in a much slower kernel than writeback mode.
>
Yep. Writethrough is forced by that defconfig selecting the da830 as
well as the da850. Disabling the da830 and turning writethrough off
speeds things up slightly but doesn't have any other effect.
> So, I would say any remaining issue is specific to omapl138.
>
Seems a reasonable assumption.
Right now I'm largely stumped. I'm not always getting meaningful
backtraces on panic, but when I do they invariably pass through
__do_kernel_fault() - often more than once. It seems I can also trigger
the problem if I *disable* xenomai and ipipe, but leave FCSE best-effort
and lots of tracing enabled.
On best-effort that >32MB process won't be killed - correct? Is it
possible to hit problems with the 32MB boundary while in the kernel?
--
Peter Howard <pjh@northern-ridge.com.au>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-05-05 23:00 ` Peter Howard
@ 2014-05-06 11:35 ` Gilles Chanteperdrix
2014-05-06 22:44 ` Peter Howard
0 siblings, 1 reply; 57+ messages in thread
From: Gilles Chanteperdrix @ 2014-05-06 11:35 UTC (permalink / raw)
To: Peter Howard; +Cc: xenomai
On 05/06/2014 01:00 AM, Peter Howard wrote:
> On Sun, 2014-05-04 at 21:25 +0200, Gilles Chanteperdrix wrote:
>> On 04/29/2014 03:46 AM, Peter Howard wrote:
>>> On Thu, 2014-04-24 at 23:30 +0200, Gilles Chanteperdrix wrote:
>>>> On 04/23/2014 03:45 AM, Peter Howard wrote:
>>>>> On Wed, 2014-04-23 at 01:02 +0200, Gilles Chanteperdrix wrote:
>>>>>> On 04/15/2014 11:59 PM, Peter Howard wrote:
>>>>>>> On Tue, 2014-04-15 at 13:37 +0200, Gilles Chanteperdrix wrote:
>>>>>>>> On 04/15/2014 08:03 AM, Peter Howard wrote:
>>>>>>>>> On Fri, 2014-04-11 at 08:52 +1000, Peter Howard wrote:
>>>>>>>>>> On Fri, 2014-04-11 at 00:48 +0200, Gilles Chanteperdrix wrote:
>>>>>>>>>>> On 04/11/2014 12:34 AM, Peter Howard wrote:
>>>>>>>>>>>> On Fri, 2014-04-11 at 00:23 +0200, Gilles Chanteperdrix wrote:
>>>>>>>>>>>> (Stripping back conversation on this one - apologies if that's bad
>>>>>>>>>>>> etiquette for this list)
>>>>>>>>>>>>
>>>>>>>>>>>>> Attachment is better. Also please post the changes you made for omapL138
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
>>>>>>>>>>>> index a075b3e..3d8bc59 100644
>>>>>>>>>>>> --- a/arch/arm/mach-davinci/Kconfig
>>>>>>>>>>>> +++ b/arch/arm/mach-davinci/Kconfig
>>>>>>>>>>>> @@ -41,6 +41,8 @@ config ARCH_DAVINCI_DA850
>>>>>>>>>>>> select ARCH_DAVINCI_DA8XX
>>>>>>>>>>>> select ARCH_HAS_CPUFREQ
>>>>>>>>>>>> select CP_INTC
>>>>>>>>>>>> + select IPIPE_ARM_KUSER_TSC if IPIPE
>>>>>>>>>>>> + select ARM_FCSE if IPIPE
>>>>>>>>>>>
>>>>>>>>>>> You may want to leave the choice of enabling or disabling FCSE to the user.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Understood; at the moment the variance on max latency is really bad if
>>>>>>>>>> you don't enable FCSE. When I sort out the crashing issues I'll re-test
>>>>>>>>>> with it off.
>>>>>>>>>
>>>>>>>>> Well, FCSE turned out to be my problem.
>>>>>>>>>
>>>>>>>>> More specifically, FCSE and ARM_FCSE_BEST_EFFORT. Either a) disabling
>>>>>>>>> ARM_FCSE altogether, or b) selecting ARM_FCSE with ARM_FCSE_GUARENTEED
>>>>>>>>> gets rid of the crashes/panics with ipipe latency tracing enabled.
>>>>>>>>>
>>>>>>>>> So now things seem reasonably stable, I'll go through the full set of
>>>>>>>>> tests. Though I still can't do 'xeno-test -l "dohell -l /opt/ltp"' as
>>>>>>>>> ltp takes out the system without any ipipe/xenomai bits.
>>>>>>>>>
>>>>>>>> Ok, FCSE best effort is currently being validated on 3.14, so it may
>>>>>>>> well be broken. After all, the raw/* branches are work in progress.
>>>>>>>>
>>>>>>>
>>>>>>> Note: selecting ARM_FCSE_BEST_EFFORT produces the same result on the
>>>>>>> master branch too . . .
>>>>>>>
>>>>>> Hi Peter,
>>>>>>
>>>>>> I am unable to reproduce these issues with 3.14, FCSE seems to be doing
>>>>>> just fine, I can boot and run the LTP testsuite and get almost the same
>>>>>> results as a non patched kernel. I have tried with and without
>>>>>> preemptible cache flushes, and with and without Xenomai. My rootfs is
>>>>>> based on busybox and minimal, maybe that is the reason why it works
>>>>>> fine, could you put a tarball with your rootfs somewhere?
>>>>>
>>>>> A bit of testing shows (at least) one case is directly related to the
>>>>> rootfs. This is the Texas Instruments rootfs that is supplied for the
>>>>> DA850 board. During normal startup, it wants to start the GUI for the
>>>>> LCD which would go past the 32MB process limit with FCSE enabled. With
>>>>> FCSE_GUARENTEED selected this is noted but doesn't cause a crash. With
>>>>> FCSE_BEST_EFFORT selected this is noted and then the system crashes
>>>>> within a few seconds. I'm not sure if this counts as a bug in
>>>>> BEST_EFFORT or whether all bets are off if you try to start a process
>>>>> that's too large.
>>>>>
>>>>> At this point I'm not sure if anything else is specific to that rootfs
>>>>> but I'll still make it available to you to have a look.
>>>>
>>>> No luck with your rootfs: matrix_GUI craches indeed, but it also crashes
>>>> without CONFIG_FCSE, so it would seem the crash is unrelated to the
>>>> FCSE. Obviously it does not crash with FCSE_GUARANTEED, because it is
>>>> stopped as soon as it wants to go over 32 MB. And that crash does not
>>>> cause the cascade of crashes you mentioned, ending with init crashing.
>>>> The processor on which I am running the tests does not have a
>>>> framebuffer maybe that is the reason I get a crash, and do not go as far
>>>> as in your case.
>>>>
>>>> Could you post the kernel configuration you use?
>>>>
>>>
>>> Take 3. Ignore the previous two. They will probably trigger it, but
>>> this one I actually tested to confirm it does cause the crash.
>>
>> This configuration with only omapl138 replaced with at91sam9263 seems to
>> run correctly, except for the segfault in the matrix_guiE application,
>> which I also have on an unpatched kernel. Note that this configuration
>> sets the cache to writethrough mode which, at least on at91sam9263
>> results in a much slower kernel than writeback mode.
>>
>
> Yep. Writethrough is forced by that defconfig selecting the da830 as
> well as the da850. Disabling the da830 and turning writethrough off
> speeds things up slightly but doesn't have any other effect.
>
>> So, I would say any remaining issue is specific to omapl138.
>>
>
> Seems a reasonable assumption.
>
> Right now I'm largely stumped. I'm not always getting meaningful
> backtraces on panic, but when I do they invariably pass through
> __do_kernel_fault() - often more than once. It seems I can also trigger
> the problem if I *disable* xenomai and ipipe, but leave FCSE best-effort
> and lots of tracing enabled.
>
> On best-effort that >32MB process won't be killed - correct?
Yes, as soon as a process has a virtual address space larger than 32MB
it gets relocated to the null fcse pid.
> Is it
> possible to hit problems with the 32MB boundary while in the kernel?
The kernel mapping does not use fcse pids, so, there is no 32MB limit.
The kernel has 1GiB + 16MiB of memory.
One thing you can do to verify if the suppressed cache flushes is what
causes the issue is to get fcse_flush_needed_p to always return 1, in
arch/arm/mm/fcse.c
One last thing: could you try and revert commit
84f452b1e8fc73ac0e31254c66e3e2260ce5263d
--
Gilles.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-05-06 11:35 ` Gilles Chanteperdrix
@ 2014-05-06 22:44 ` Peter Howard
2014-05-07 0:26 ` Gilles Chanteperdrix
0 siblings, 1 reply; 57+ messages in thread
From: Peter Howard @ 2014-05-06 22:44 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On Tue, 2014-05-06 at 13:35 +0200, Gilles Chanteperdrix wrote:
> On 05/06/2014 01:00 AM, Peter Howard wrote:
> > On Sun, 2014-05-04 at 21:25 +0200, Gilles Chanteperdrix wrote:
> >> On 04/29/2014 03:46 AM, Peter Howard wrote:
> >>> On Thu, 2014-04-24 at 23:30 +0200, Gilles Chanteperdrix wrote:
> >>>> On 04/23/2014 03:45 AM, Peter Howard wrote:
> >>>>> On Wed, 2014-04-23 at 01:02 +0200, Gilles Chanteperdrix wrote:
> >>>>>> On 04/15/2014 11:59 PM, Peter Howard wrote:
> >>>>>>> On Tue, 2014-04-15 at 13:37 +0200, Gilles Chanteperdrix wrote:
> >>>>>>>> On 04/15/2014 08:03 AM, Peter Howard wrote:
> >>>>>>>>> On Fri, 2014-04-11 at 08:52 +1000, Peter Howard wrote:
> >>>>>>>>>> On Fri, 2014-04-11 at 00:48 +0200, Gilles Chanteperdrix wrote:
> >>>>>>>>>>> On 04/11/2014 12:34 AM, Peter Howard wrote:
> >>>>>>>>>>>> On Fri, 2014-04-11 at 00:23 +0200, Gilles Chanteperdrix wrote:
> >>>>>>>>>>>> (Stripping back conversation on this one - apologies if that's bad
> >>>>>>>>>>>> etiquette for this list)
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Attachment is better. Also please post the changes you made for omapL138
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
> >>>>>>>>>>>> index a075b3e..3d8bc59 100644
> >>>>>>>>>>>> --- a/arch/arm/mach-davinci/Kconfig
> >>>>>>>>>>>> +++ b/arch/arm/mach-davinci/Kconfig
> >>>>>>>>>>>> @@ -41,6 +41,8 @@ config ARCH_DAVINCI_DA850
> >>>>>>>>>>>> select ARCH_DAVINCI_DA8XX
> >>>>>>>>>>>> select ARCH_HAS_CPUFREQ
> >>>>>>>>>>>> select CP_INTC
> >>>>>>>>>>>> + select IPIPE_ARM_KUSER_TSC if IPIPE
> >>>>>>>>>>>> + select ARM_FCSE if IPIPE
> >>>>>>>>>>>
> >>>>>>>>>>> You may want to leave the choice of enabling or disabling FCSE to the user.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Understood; at the moment the variance on max latency is really bad if
> >>>>>>>>>> you don't enable FCSE. When I sort out the crashing issues I'll re-test
> >>>>>>>>>> with it off.
> >>>>>>>>>
> >>>>>>>>> Well, FCSE turned out to be my problem.
> >>>>>>>>>
> >>>>>>>>> More specifically, FCSE and ARM_FCSE_BEST_EFFORT. Either a) disabling
> >>>>>>>>> ARM_FCSE altogether, or b) selecting ARM_FCSE with ARM_FCSE_GUARENTEED
> >>>>>>>>> gets rid of the crashes/panics with ipipe latency tracing enabled.
> >>>>>>>>>
> >>>>>>>>> So now things seem reasonably stable, I'll go through the full set of
> >>>>>>>>> tests. Though I still can't do 'xeno-test -l "dohell -l /opt/ltp"' as
> >>>>>>>>> ltp takes out the system without any ipipe/xenomai bits.
> >>>>>>>>>
> >>>>>>>> Ok, FCSE best effort is currently being validated on 3.14, so it may
> >>>>>>>> well be broken. After all, the raw/* branches are work in progress.
> >>>>>>>>
> >>>>>>>
> >>>>>>> Note: selecting ARM_FCSE_BEST_EFFORT produces the same result on the
> >>>>>>> master branch too . . .
> >>>>>>>
> >>>>>> Hi Peter,
> >>>>>>
> >>>>>> I am unable to reproduce these issues with 3.14, FCSE seems to be doing
> >>>>>> just fine, I can boot and run the LTP testsuite and get almost the same
> >>>>>> results as a non patched kernel. I have tried with and without
> >>>>>> preemptible cache flushes, and with and without Xenomai. My rootfs is
> >>>>>> based on busybox and minimal, maybe that is the reason why it works
> >>>>>> fine, could you put a tarball with your rootfs somewhere?
> >>>>>
> >>>>> A bit of testing shows (at least) one case is directly related to the
> >>>>> rootfs. This is the Texas Instruments rootfs that is supplied for the
> >>>>> DA850 board. During normal startup, it wants to start the GUI for the
> >>>>> LCD which would go past the 32MB process limit with FCSE enabled. With
> >>>>> FCSE_GUARENTEED selected this is noted but doesn't cause a crash. With
> >>>>> FCSE_BEST_EFFORT selected this is noted and then the system crashes
> >>>>> within a few seconds. I'm not sure if this counts as a bug in
> >>>>> BEST_EFFORT or whether all bets are off if you try to start a process
> >>>>> that's too large.
> >>>>>
> >>>>> At this point I'm not sure if anything else is specific to that rootfs
> >>>>> but I'll still make it available to you to have a look.
> >>>>
> >>>> No luck with your rootfs: matrix_GUI craches indeed, but it also crashes
> >>>> without CONFIG_FCSE, so it would seem the crash is unrelated to the
> >>>> FCSE. Obviously it does not crash with FCSE_GUARANTEED, because it is
> >>>> stopped as soon as it wants to go over 32 MB. And that crash does not
> >>>> cause the cascade of crashes you mentioned, ending with init crashing.
> >>>> The processor on which I am running the tests does not have a
> >>>> framebuffer maybe that is the reason I get a crash, and do not go as far
> >>>> as in your case.
> >>>>
> >>>> Could you post the kernel configuration you use?
> >>>>
> >>>
> >>> Take 3. Ignore the previous two. They will probably trigger it, but
> >>> this one I actually tested to confirm it does cause the crash.
> >>
> >> This configuration with only omapl138 replaced with at91sam9263 seems to
> >> run correctly, except for the segfault in the matrix_guiE application,
> >> which I also have on an unpatched kernel. Note that this configuration
> >> sets the cache to writethrough mode which, at least on at91sam9263
> >> results in a much slower kernel than writeback mode.
> >>
> >
> > Yep. Writethrough is forced by that defconfig selecting the da830 as
> > well as the da850. Disabling the da830 and turning writethrough off
> > speeds things up slightly but doesn't have any other effect.
> >
> >> So, I would say any remaining issue is specific to omapl138.
> >>
> >
> > Seems a reasonable assumption.
> >
> > Right now I'm largely stumped. I'm not always getting meaningful
> > backtraces on panic, but when I do they invariably pass through
> > __do_kernel_fault() - often more than once. It seems I can also trigger
> > the problem if I *disable* xenomai and ipipe, but leave FCSE best-effort
> > and lots of tracing enabled.
> >
> > On best-effort that >32MB process won't be killed - correct?
>
> Yes, as soon as a process has a virtual address space larger than 32MB
> it gets relocated to the null fcse pid.
>
> > Is it
> > possible to hit problems with the 32MB boundary while in the kernel?
>
> The kernel mapping does not use fcse pids, so, there is no 32MB limit.
> The kernel has 1GiB + 16MiB of memory.
>
> One thing you can do to verify if the suppressed cache flushes is what
> causes the issue is to get fcse_flush_needed_p to always return 1, in
> arch/arm/mm/fcse.c
>
No change. For that matter, I forgot to mention I'd tried booting with
both I and D caches disabled and still got the same Oops.
> One last thing: could you try and revert commit
> 84f452b1e8fc73ac0e31254c66e3e2260ce5263d
>
Sadly, no change from that either.
--
Peter Howard <pjh@northern-ridge.com.au>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [Xenomai] OMAP L138
2014-05-06 22:44 ` Peter Howard
@ 2014-05-07 0:26 ` Gilles Chanteperdrix
0 siblings, 0 replies; 57+ messages in thread
From: Gilles Chanteperdrix @ 2014-05-07 0:26 UTC (permalink / raw)
To: Peter Howard; +Cc: xenomai
On 05/07/2014 12:44 AM, Peter Howard wrote:
> On Tue, 2014-05-06 at 13:35 +0200, Gilles Chanteperdrix wrote:
>> On 05/06/2014 01:00 AM, Peter Howard wrote:
>>> On Sun, 2014-05-04 at 21:25 +0200, Gilles Chanteperdrix wrote:
>>>> On 04/29/2014 03:46 AM, Peter Howard wrote:
>>>>> On Thu, 2014-04-24 at 23:30 +0200, Gilles Chanteperdrix wrote:
>>>>>> On 04/23/2014 03:45 AM, Peter Howard wrote:
>>>>>>> On Wed, 2014-04-23 at 01:02 +0200, Gilles Chanteperdrix wrote:
>>>>>>>> On 04/15/2014 11:59 PM, Peter Howard wrote:
>>>>>>>>> On Tue, 2014-04-15 at 13:37 +0200, Gilles Chanteperdrix wrote:
>>>>>>>>>> On 04/15/2014 08:03 AM, Peter Howard wrote:
>>>>>>>>>>> On Fri, 2014-04-11 at 08:52 +1000, Peter Howard wrote:
>>>>>>>>>>>> On Fri, 2014-04-11 at 00:48 +0200, Gilles Chanteperdrix wrote:
>>>>>>>>>>>>> On 04/11/2014 12:34 AM, Peter Howard wrote:
>>>>>>>>>>>>>> On Fri, 2014-04-11 at 00:23 +0200, Gilles Chanteperdrix wrote:
>>>>>>>>>>>>>> (Stripping back conversation on this one - apologies if that's bad
>>>>>>>>>>>>>> etiquette for this list)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Attachment is better. Also please post the changes you made for omapL138
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
>>>>>>>>>>>>>> index a075b3e..3d8bc59 100644
>>>>>>>>>>>>>> --- a/arch/arm/mach-davinci/Kconfig
>>>>>>>>>>>>>> +++ b/arch/arm/mach-davinci/Kconfig
>>>>>>>>>>>>>> @@ -41,6 +41,8 @@ config ARCH_DAVINCI_DA850
>>>>>>>>>>>>>> select ARCH_DAVINCI_DA8XX
>>>>>>>>>>>>>> select ARCH_HAS_CPUFREQ
>>>>>>>>>>>>>> select CP_INTC
>>>>>>>>>>>>>> + select IPIPE_ARM_KUSER_TSC if IPIPE
>>>>>>>>>>>>>> + select ARM_FCSE if IPIPE
>>>>>>>>>>>>>
>>>>>>>>>>>>> You may want to leave the choice of enabling or disabling FCSE to the user.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Understood; at the moment the variance on max latency is really bad if
>>>>>>>>>>>> you don't enable FCSE. When I sort out the crashing issues I'll re-test
>>>>>>>>>>>> with it off.
>>>>>>>>>>>
>>>>>>>>>>> Well, FCSE turned out to be my problem.
>>>>>>>>>>>
>>>>>>>>>>> More specifically, FCSE and ARM_FCSE_BEST_EFFORT. Either a) disabling
>>>>>>>>>>> ARM_FCSE altogether, or b) selecting ARM_FCSE with ARM_FCSE_GUARENTEED
>>>>>>>>>>> gets rid of the crashes/panics with ipipe latency tracing enabled.
>>>>>>>>>>>
>>>>>>>>>>> So now things seem reasonably stable, I'll go through the full set of
>>>>>>>>>>> tests. Though I still can't do 'xeno-test -l "dohell -l /opt/ltp"' as
>>>>>>>>>>> ltp takes out the system without any ipipe/xenomai bits.
>>>>>>>>>>>
>>>>>>>>>> Ok, FCSE best effort is currently being validated on 3.14, so it may
>>>>>>>>>> well be broken. After all, the raw/* branches are work in progress.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Note: selecting ARM_FCSE_BEST_EFFORT produces the same result on the
>>>>>>>>> master branch too . . .
>>>>>>>>>
>>>>>>>> Hi Peter,
>>>>>>>>
>>>>>>>> I am unable to reproduce these issues with 3.14, FCSE seems to be doing
>>>>>>>> just fine, I can boot and run the LTP testsuite and get almost the same
>>>>>>>> results as a non patched kernel. I have tried with and without
>>>>>>>> preemptible cache flushes, and with and without Xenomai. My rootfs is
>>>>>>>> based on busybox and minimal, maybe that is the reason why it works
>>>>>>>> fine, could you put a tarball with your rootfs somewhere?
>>>>>>>
>>>>>>> A bit of testing shows (at least) one case is directly related to the
>>>>>>> rootfs. This is the Texas Instruments rootfs that is supplied for the
>>>>>>> DA850 board. During normal startup, it wants to start the GUI for the
>>>>>>> LCD which would go past the 32MB process limit with FCSE enabled. With
>>>>>>> FCSE_GUARENTEED selected this is noted but doesn't cause a crash. With
>>>>>>> FCSE_BEST_EFFORT selected this is noted and then the system crashes
>>>>>>> within a few seconds. I'm not sure if this counts as a bug in
>>>>>>> BEST_EFFORT or whether all bets are off if you try to start a process
>>>>>>> that's too large.
>>>>>>>
>>>>>>> At this point I'm not sure if anything else is specific to that rootfs
>>>>>>> but I'll still make it available to you to have a look.
>>>>>>
>>>>>> No luck with your rootfs: matrix_GUI craches indeed, but it also crashes
>>>>>> without CONFIG_FCSE, so it would seem the crash is unrelated to the
>>>>>> FCSE. Obviously it does not crash with FCSE_GUARANTEED, because it is
>>>>>> stopped as soon as it wants to go over 32 MB. And that crash does not
>>>>>> cause the cascade of crashes you mentioned, ending with init crashing.
>>>>>> The processor on which I am running the tests does not have a
>>>>>> framebuffer maybe that is the reason I get a crash, and do not go as far
>>>>>> as in your case.
>>>>>>
>>>>>> Could you post the kernel configuration you use?
>>>>>>
>>>>>
>>>>> Take 3. Ignore the previous two. They will probably trigger it, but
>>>>> this one I actually tested to confirm it does cause the crash.
>>>>
>>>> This configuration with only omapl138 replaced with at91sam9263 seems to
>>>> run correctly, except for the segfault in the matrix_guiE application,
>>>> which I also have on an unpatched kernel. Note that this configuration
>>>> sets the cache to writethrough mode which, at least on at91sam9263
>>>> results in a much slower kernel than writeback mode.
>>>>
>>>
>>> Yep. Writethrough is forced by that defconfig selecting the da830 as
>>> well as the da850. Disabling the da830 and turning writethrough off
>>> speeds things up slightly but doesn't have any other effect.
>>>
>>>> So, I would say any remaining issue is specific to omapl138.
>>>>
>>>
>>> Seems a reasonable assumption.
>>>
>>> Right now I'm largely stumped. I'm not always getting meaningful
>>> backtraces on panic, but when I do they invariably pass through
>>> __do_kernel_fault() - often more than once. It seems I can also trigger
>>> the problem if I *disable* xenomai and ipipe, but leave FCSE best-effort
>>> and lots of tracing enabled.
Note that if you are still using the 3.12, it had a problem without
xenomai and ipipe which got fixed in 3.14:
http://git.xenomai.org/ipipe-gch.git/commit/?h=for-ipipe-3.14.0&id=55a7f285035a4d34b05a02d80af11bc38ea4deab
It would be interesting to test without CONFIG_IPIPE, and with this
patch applied.
>>>
>>> On best-effort that >32MB process won't be killed - correct?
>>
>> Yes, as soon as a process has a virtual address space larger than 32MB
>> it gets relocated to the null fcse pid.
>>
>>> Is it
>>> possible to hit problems with the 32MB boundary while in the kernel?
>>
>> The kernel mapping does not use fcse pids, so, there is no 32MB limit.
>> The kernel has 1GiB + 16MiB of memory.
>>
>> One thing you can do to verify if the suppressed cache flushes is what
>> causes the issue is to get fcse_flush_needed_p to always return 1, in
>> arch/arm/mm/fcse.c
>>
>
> No change. For that matter, I forgot to mention I'd tried booting with
> both I and D caches disabled and still got the same Oops.
>
>> One last thing: could you try and revert commit
>> 84f452b1e8fc73ac0e31254c66e3e2260ce5263d
>>
>
> Sadly, no change from that either.
>
Ok, some different part we can try and neutralize is the handling of
processes above 32MB. In arch/arm/include/asm/fcse.h, function
fcse_check_mmap_addr, simply return addr without conditions.
--
Gilles.
^ permalink raw reply [flat|nested] 57+ messages in thread
end of thread, other threads:[~2014-05-07 0:26 UTC | newest]
Thread overview: 57+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-04-02 2:59 [Xenomai] OMAP L138 Peter Howard
2014-04-02 7:24 ` Gilles Chanteperdrix
2014-04-02 22:37 ` Peter Howard
2014-04-02 23:31 ` Gilles Chanteperdrix
2014-04-03 1:28 ` Peter Howard
2014-04-07 5:34 ` Peter Howard
2014-04-07 9:53 ` Gilles Chanteperdrix
2014-04-08 2:37 ` Peter Howard
2014-04-08 8:12 ` Gilles Chanteperdrix
2014-04-08 23:44 ` Peter Howard
2014-04-08 9:18 ` Gilles Chanteperdrix
2014-04-08 23:30 ` Peter Howard
2014-04-09 0:18 ` Gilles Chanteperdrix
2014-04-09 0:20 ` Gilles Chanteperdrix
2014-04-09 0:34 ` Peter Howard
2014-04-09 4:27 ` Peter Howard
2014-04-09 11:54 ` Gilles Chanteperdrix
2014-04-10 7:01 ` Peter Howard
2014-04-10 12:06 ` Gilles Chanteperdrix
2014-04-10 19:57 ` Peter Howard
2014-04-10 21:56 ` Gilles Chanteperdrix
2014-04-10 22:17 ` Peter Howard
2014-04-10 22:23 ` Gilles Chanteperdrix
2014-04-10 22:27 ` Peter Howard
2014-04-10 22:34 ` Peter Howard
2014-04-10 22:48 ` Gilles Chanteperdrix
2014-04-10 22:52 ` Peter Howard
2014-04-10 22:55 ` Gilles Chanteperdrix
2014-04-15 6:03 ` Peter Howard
2014-04-15 11:37 ` Gilles Chanteperdrix
2014-04-15 21:59 ` Peter Howard
2014-04-15 22:25 ` Gilles Chanteperdrix
2014-04-16 0:58 ` Peter Howard
2014-04-16 7:34 ` Gilles Chanteperdrix
2014-04-17 0:30 ` Peter Howard
2014-04-17 11:37 ` Gilles Chanteperdrix
2014-04-22 23:02 ` Gilles Chanteperdrix
2014-04-23 1:45 ` Peter Howard
2014-04-23 2:15 ` Peter Howard
2014-04-23 12:13 ` Gilles Chanteperdrix
2014-04-24 21:30 ` Gilles Chanteperdrix
2014-04-27 22:14 ` Peter Howard
2014-04-28 1:19 ` Peter Howard
2014-04-29 1:46 ` Peter Howard
2014-05-04 19:25 ` Gilles Chanteperdrix
2014-05-05 23:00 ` Peter Howard
2014-05-06 11:35 ` Gilles Chanteperdrix
2014-05-06 22:44 ` Peter Howard
2014-05-07 0:26 ` Gilles Chanteperdrix
2014-04-10 23:01 ` Peter Howard
2014-04-11 15:46 ` Lennart Sorensen
2014-04-14 0:28 ` Peter Howard
2014-04-14 1:10 ` Lennart Sorensen
2014-04-14 5:02 ` Peter Howard
2014-04-14 5:48 ` Peter Howard
2014-04-14 13:21 ` Lennart Sorensen
2014-04-15 1:58 ` Peter Howard
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.