OMAP2430 SDP boot broken after Linus' rmk merge

OMAP2430 SDP boot broken after Linus' rmk merge

[Paul Walmsley]

Hi,

After Linus's commit fb2af0020a51709ad87ea8055c325d3fbde04158 ("Merge 
branch 'for-linus' of git://git.linaro.org/people/rmk/linux-arm"), the 
OMAP2430 SDP here stopped booting.

Here's the bootlog at the commit before the merge, commit 790eac5640:

http://www.pwsan.com/omap/testlogs/bisect_2430sdp_hang_v3.11-rc/20130722015454/

and here's a log at commit fb2af0020a5:

http://www.pwsan.com/omap/testlogs/bisect_2430sdp_hang_v3.11-rc/20130722005921/

Any ideas as to what might have caused this?


- Paul

OMAP2430 SDP boot broken after Linus' rmk merge

[Russell King - ARM Linux]

On Mon, Jul 22, 2013 at 06:07:47PM +0000, Paul Walmsley wrote:
> After Linus's commit fb2af0020a51709ad87ea8055c325d3fbde04158 ("Merge 
> branch 'for-linus' of git://git.linaro.org/people/rmk/linux-arm"), the 
> OMAP2430 SDP here stopped booting.
> 
> Here's the bootlog at the commit before the merge, commit 790eac5640:
> 
> http://www.pwsan.com/omap/testlogs/bisect_2430sdp_hang_v3.11-rc/20130722015454/
> 
> and here's a log at commit fb2af0020a5:
> 
> http://www.pwsan.com/omap/testlogs/bisect_2430sdp_hang_v3.11-rc/20130722005921/
> 
> Any ideas as to what might have caused this?

Bear in mind that I'm almost at the point of not boot-testing anything
I sent to Linus because of the uselessness of the SDP4430 board now
that it's DT only - the only platform which boot-tests anything I send
is the 3430LDP board now.  If people care about that, maybe they can
assist with sorting out the issues I've raised on these lists about
the SDP4430 - and why the SDP4430 build remains disabled in my build
and boot system.

Looking at the boot log, it just stops after uboot hands over control.
With the lack of output from the decompressor, it's not possible to
tell whether it's a decompressor problem or a kernel problem.

I think you need to turn on the LL_DEBUG option, select the appropriate
output option, and also get the decompressor to use the kernel's debug
io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS).

OMAP2430 SDP boot broken after Linus' rmk merge

[Paul Walmsley]

On Mon, 22 Jul 2013, Russell King - ARM Linux wrote:

> Bear in mind that I'm almost at the point of not boot-testing anything
> I sent to Linus because of the uselessness of the SDP4430 board now
> that it's DT only - the only platform which boot-tests anything I send
> is the 3430LDP board now.  If people care about that, maybe they can
> assist with sorting out the issues I've raised on these lists about
> the SDP4430 - and why the SDP4430 build remains disabled in my build
> and boot system.

I understand completely...

> Looking at the boot log, it just stops after uboot hands over control.
> With the lack of output from the decompressor, it's not possible to
> tell whether it's a decompressor problem or a kernel problem.
> 
> I think you need to turn on the LL_DEBUG option, select the appropriate
> output option, and also get the decompressor to use the kernel's debug
> io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS).

OK, will dig deeper here at the next opportunity.


- Paul

OMAP2430 SDP boot broken after Linus' rmk merge

[Rajendra Nayak]

On Tuesday 23 July 2013 01:37 AM, Paul Walmsley wrote:
> On Mon, 22 Jul 2013, Russell King - ARM Linux wrote:
> 
>> Bear in mind that I'm almost at the point of not boot-testing anything
>> I sent to Linus because of the uselessness of the SDP4430 board now
>> that it's DT only - the only platform which boot-tests anything I send
>> is the 3430LDP board now.  If people care about that, maybe they can
>> assist with sorting out the issues I've raised on these lists about
>> the SDP4430 - and why the SDP4430 build remains disabled in my build
>> and boot system.
> 
> I understand completely...
> 
>> Looking at the boot log, it just stops after uboot hands over control.
>> With the lack of output from the decompressor, it's not possible to
>> tell whether it's a decompressor problem or a kernel problem.
>>
>> I think you need to turn on the LL_DEBUG option, select the appropriate
>> output option, and also get the decompressor to use the kernel's debug
>> io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS).
> 
> OK, will dig deeper here at the next opportunity.

Paul, I can take a look at the 4430sdp issue. Are you also seeing this also on
2430sdp as the subject says, or was that a typo?

> 
> 
> - Paul
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

OMAP2430 SDP boot broken after Linus' rmk merge

[Paul Walmsley]

Hi Rajendra,

On Tue, 23 Jul 2013, Rajendra Nayak wrote:

> On Tuesday 23 July 2013 01:37 AM, Paul Walmsley wrote:
> > On Mon, 22 Jul 2013, Russell King - ARM Linux wrote:
> > 
> >> Bear in mind that I'm almost at the point of not boot-testing anything
> >> I sent to Linus because of the uselessness of the SDP4430 board now
> >> that it's DT only - the only platform which boot-tests anything I send
> >> is the 3430LDP board now.  If people care about that, maybe they can
> >> assist with sorting out the issues I've raised on these lists about
> >> the SDP4430 - and why the SDP4430 build remains disabled in my build
> >> and boot system.
> > 
> > I understand completely...
> > 
> >> Looking at the boot log, it just stops after uboot hands over control.
> >> With the lack of output from the decompressor, it's not possible to
> >> tell whether it's a decompressor problem or a kernel problem.
> >>
> >> I think you need to turn on the LL_DEBUG option, select the appropriate
> >> output option, and also get the decompressor to use the kernel's debug
> >> io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS).
> > 
> > OK, will dig deeper here at the next opportunity.
> 
> Paul, I can take a look at the 4430sdp issue. Are you also seeing this also on
> 2430sdp as the subject says, or was that a typo?

Thanks for the offer.  The issue that I'm seeing is on the 2430SDP in my 
testbed.

I don't have a 4430SDP, so you might consider touching base with rmk for 
that one.


- Paul

OMAP2430 SDP boot broken after Linus' rmk merge

[Rajendra Nayak]

On Tuesday 23 July 2013 12:37 PM, Paul Walmsley wrote:
> Hi Rajendra,
> 
> On Tue, 23 Jul 2013, Rajendra Nayak wrote:
> 
>> On Tuesday 23 July 2013 01:37 AM, Paul Walmsley wrote:
>>> On Mon, 22 Jul 2013, Russell King - ARM Linux wrote:
>>>
>>>> Bear in mind that I'm almost at the point of not boot-testing anything
>>>> I sent to Linus because of the uselessness of the SDP4430 board now
>>>> that it's DT only - the only platform which boot-tests anything I send
>>>> is the 3430LDP board now.  If people care about that, maybe they can
>>>> assist with sorting out the issues I've raised on these lists about
>>>> the SDP4430 - and why the SDP4430 build remains disabled in my build
>>>> and boot system.
>>>
>>> I understand completely...
>>>
>>>> Looking at the boot log, it just stops after uboot hands over control.
>>>> With the lack of output from the decompressor, it's not possible to
>>>> tell whether it's a decompressor problem or a kernel problem.
>>>>
>>>> I think you need to turn on the LL_DEBUG option, select the appropriate
>>>> output option, and also get the decompressor to use the kernel's debug
>>>> io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS).
>>>
>>> OK, will dig deeper here at the next opportunity.
>>
>> Paul, I can take a look at the 4430sdp issue. Are you also seeing this also on
>> 2430sdp as the subject says, or was that a typo?
> 
> Thanks for the offer.  The issue that I'm seeing is on the 2430SDP in my 
> testbed.
> 
> I don't have a 4430SDP, so you might consider touching base with rmk for 
> that one.

So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see
the below errors. (I am using the mainline bootloaders which do not lock any
additional DPLLs like USB)

[    0.000000] clock: dpll_usb_ck failed transition to 'locked'
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] clock: trace_clk_div_ck: could not find divisor for target rate 0 for parent pmd_trace_clk_mux_ck
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] clock: dpll_per_m7x2_ck: could not find divisor for target rate 0 for parent dpll_per_x2_ck
[    0.000000] clock: dpll_per_m6x2_ck: could not find divisor for target rate 0 for parent dpll_per_x2_ck
[    0.000000] clock: dpll_per_m5x2_ck: could not find divisor for target rate 0 for parent dpll_per_x2_ck
[    0.000000] clock: dpll_per_m4x2_ck: could not find divisor for target rate 0 for parent dpll_per_x2_ck

> 
> 
> - Paul
> 

OMAP2430 SDP boot broken after Linus' rmk merge

[Will Deacon]

On Tue, Jul 23, 2013 at 10:05:17AM +0100, Rajendra Nayak wrote:
> On Tuesday 23 July 2013 12:37 PM, Paul Walmsley wrote:
> > Hi Rajendra,
> > 
> > On Tue, 23 Jul 2013, Rajendra Nayak wrote:
> > 
> >> On Tuesday 23 July 2013 01:37 AM, Paul Walmsley wrote:
> >>> On Mon, 22 Jul 2013, Russell King - ARM Linux wrote:
> >>>
> >>>> Bear in mind that I'm almost at the point of not boot-testing anything
> >>>> I sent to Linus because of the uselessness of the SDP4430 board now
> >>>> that it's DT only - the only platform which boot-tests anything I send
> >>>> is the 3430LDP board now.  If people care about that, maybe they can
> >>>> assist with sorting out the issues I've raised on these lists about
> >>>> the SDP4430 - and why the SDP4430 build remains disabled in my build
> >>>> and boot system.
> >>>
> >>> I understand completely...
> >>>
> >>>> Looking at the boot log, it just stops after uboot hands over control.
> >>>> With the lack of output from the decompressor, it's not possible to
> >>>> tell whether it's a decompressor problem or a kernel problem.
> >>>>
> >>>> I think you need to turn on the LL_DEBUG option, select the appropriate
> >>>> output option, and also get the decompressor to use the kernel's debug
> >>>> io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS).
> >>>
> >>> OK, will dig deeper here at the next opportunity.
> >>
> >> Paul, I can take a look at the 4430sdp issue. Are you also seeing this also on
> >> 2430sdp as the subject says, or was that a typo?
> > 
> > Thanks for the offer.  The issue that I'm seeing is on the 2430SDP in my 
> > testbed.
> > 
> > I don't have a 4430SDP, so you might consider touching base with rmk for 
> > that one.
> 
> So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see
> the below errors. (I am using the mainline bootloaders which do not lock any
> additional DPLLs like USB)

Any update on this? If it's an issue introduced by architectural changes,
I'd really like to bisect it down but I don't have a board.

Will

OMAP2430 SDP boot broken after Linus' rmk merge

[Santosh Shilimkar]

On Wednesday 24 July 2013 09:56 AM, Will Deacon wrote:
> On Tue, Jul 23, 2013 at 10:05:17AM +0100, Rajendra Nayak wrote:
>> On Tuesday 23 July 2013 12:37 PM, Paul Walmsley wrote:
>>> Hi Rajendra,
>>>
>>> On Tue, 23 Jul 2013, Rajendra Nayak wrote:
>>>
>>>> On Tuesday 23 July 2013 01:37 AM, Paul Walmsley wrote:
>>>>> On Mon, 22 Jul 2013, Russell King - ARM Linux wrote:
>>>>>
>>>>>> Bear in mind that I'm almost at the point of not boot-testing anything
>>>>>> I sent to Linus because of the uselessness of the SDP4430 board now
>>>>>> that it's DT only - the only platform which boot-tests anything I send
>>>>>> is the 3430LDP board now.  If people care about that, maybe they can
>>>>>> assist with sorting out the issues I've raised on these lists about
>>>>>> the SDP4430 - and why the SDP4430 build remains disabled in my build
>>>>>> and boot system.
>>>>>
>>>>> I understand completely...
>>>>>
>>>>>> Looking at the boot log, it just stops after uboot hands over control.
>>>>>> With the lack of output from the decompressor, it's not possible to
>>>>>> tell whether it's a decompressor problem or a kernel problem.
>>>>>>
>>>>>> I think you need to turn on the LL_DEBUG option, select the appropriate
>>>>>> output option, and also get the decompressor to use the kernel's debug
>>>>>> io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS).
>>>>>
>>>>> OK, will dig deeper here at the next opportunity.
>>>>
>>>> Paul, I can take a look at the 4430sdp issue. Are you also seeing this also on
>>>> 2430sdp as the subject says, or was that a typo?
>>>
>>> Thanks for the offer.  The issue that I'm seeing is on the 2430SDP in my 
>>> testbed.
>>>
>>> I don't have a 4430SDP, so you might consider touching base with rmk for 
>>> that one.
>>
>> So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see
>> the below errors. (I am using the mainline bootloaders which do not lock any
>> additional DPLLs like USB)
> 
> Any update on this? If it's an issue introduced by architectural changes,
> I'd really like to bisect it down but I don't have a board.
> 
>From the other thread, RMK did manage to get the board booting finally
(uImage related issues, low level debug problem) but with DT only supported
build, the audio and DSS was not at same state as before(non-DT build).
And then Tony pointed the issues to Peter and Tomy to address it further.

Russell,
Is above right or I am missing something ?

Regards,
Santosh

OMAP2430 SDP boot broken after Linus' rmk merge

[Will Deacon]

On Wed, Jul 24, 2013 at 03:17:01PM +0100, Santosh Shilimkar wrote:
> On Wednesday 24 July 2013 09:56 AM, Will Deacon wrote:
> > On Tue, Jul 23, 2013 at 10:05:17AM +0100, Rajendra Nayak wrote:
> >> On Tuesday 23 July 2013 12:37 PM, Paul Walmsley wrote:
> >>> Hi Rajendra,
> >>>
> >>> On Tue, 23 Jul 2013, Rajendra Nayak wrote:
> >>>
> >>>> On Tuesday 23 July 2013 01:37 AM, Paul Walmsley wrote:
> >>>>> On Mon, 22 Jul 2013, Russell King - ARM Linux wrote:
> >>>>>
> >>>>>> Bear in mind that I'm almost at the point of not boot-testing anything
> >>>>>> I sent to Linus because of the uselessness of the SDP4430 board now
> >>>>>> that it's DT only - the only platform which boot-tests anything I send
> >>>>>> is the 3430LDP board now.  If people care about that, maybe they can
> >>>>>> assist with sorting out the issues I've raised on these lists about
> >>>>>> the SDP4430 - and why the SDP4430 build remains disabled in my build
> >>>>>> and boot system.
> >>>>>
> >>>>> I understand completely...
> >>>>>
> >>>>>> Looking at the boot log, it just stops after uboot hands over control.
> >>>>>> With the lack of output from the decompressor, it's not possible to
> >>>>>> tell whether it's a decompressor problem or a kernel problem.
> >>>>>>
> >>>>>> I think you need to turn on the LL_DEBUG option, select the appropriate
> >>>>>> output option, and also get the decompressor to use the kernel's debug
> >>>>>> io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS).
> >>>>>
> >>>>> OK, will dig deeper here at the next opportunity.
> >>>>
> >>>> Paul, I can take a look at the 4430sdp issue. Are you also seeing this also on
> >>>> 2430sdp as the subject says, or was that a typo?
> >>>
> >>> Thanks for the offer.  The issue that I'm seeing is on the 2430SDP in my 
> >>> testbed.
> >>>
> >>> I don't have a 4430SDP, so you might consider touching base with rmk for 
> >>> that one.
> >>
> >> So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see
> >> the below errors. (I am using the mainline bootloaders which do not lock any
> >> additional DPLLs like USB)
> > 
> > Any update on this? If it's an issue introduced by architectural changes,
> > I'd really like to bisect it down but I don't have a board.
> > 
> From the other thread, RMK did manage to get the board booting finally
> (uImage related issues, low level debug problem) but with DT only supported
> build, the audio and DSS was not at same state as before(non-DT build).
> And then Tony pointed the issues to Peter and Tomy to address it further.
> 
> Russell,
> Is above right or I am missing something ?

I thought that was the 4430 from before the merge window. Ths issue here is
the 2430 running mainline, as reported by Paul

Will

OMAP2430 SDP boot broken after Linus' rmk merge

[Santosh Shilimkar]

On Wednesday 24 July 2013 10:20 AM, Will Deacon wrote:
> On Wed, Jul 24, 2013 at 03:17:01PM +0100, Santosh Shilimkar wrote:
>> On Wednesday 24 July 2013 09:56 AM, Will Deacon wrote:
>>> On Tue, Jul 23, 2013 at 10:05:17AM +0100, Rajendra Nayak wrote:
>>>> On Tuesday 23 July 2013 12:37 PM, Paul Walmsley wrote:
>>>>> Hi Rajendra,
>>>>>
>>>>> On Tue, 23 Jul 2013, Rajendra Nayak wrote:
>>>>>
>>>>>> On Tuesday 23 July 2013 01:37 AM, Paul Walmsley wrote:
>>>>>>> On Mon, 22 Jul 2013, Russell King - ARM Linux wrote:
>>>>>>>
>>>>>>>> Bear in mind that I'm almost at the point of not boot-testing anything
>>>>>>>> I sent to Linus because of the uselessness of the SDP4430 board now
>>>>>>>> that it's DT only - the only platform which boot-tests anything I send
>>>>>>>> is the 3430LDP board now.  If people care about that, maybe they can
>>>>>>>> assist with sorting out the issues I've raised on these lists about
>>>>>>>> the SDP4430 - and why the SDP4430 build remains disabled in my build
>>>>>>>> and boot system.
>>>>>>>
>>>>>>> I understand completely...
>>>>>>>
>>>>>>>> Looking at the boot log, it just stops after uboot hands over control.
>>>>>>>> With the lack of output from the decompressor, it's not possible to
>>>>>>>> tell whether it's a decompressor problem or a kernel problem.
>>>>>>>>
>>>>>>>> I think you need to turn on the LL_DEBUG option, select the appropriate
>>>>>>>> output option, and also get the decompressor to use the kernel's debug
>>>>>>>> io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS).
>>>>>>>
>>>>>>> OK, will dig deeper here at the next opportunity.
>>>>>>
>>>>>> Paul, I can take a look at the 4430sdp issue. Are you also seeing this also on
>>>>>> 2430sdp as the subject says, or was that a typo?
>>>>>
>>>>> Thanks for the offer.  The issue that I'm seeing is on the 2430SDP in my 
>>>>> testbed.
>>>>>
>>>>> I don't have a 4430SDP, so you might consider touching base with rmk for 
>>>>> that one.
>>>>
>>>> So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see
>>>> the below errors. (I am using the mainline bootloaders which do not lock any
>>>> additional DPLLs like USB)
>>>
>>> Any update on this? If it's an issue introduced by architectural changes,
>>> I'd really like to bisect it down but I don't have a board.
>>>
>> From the other thread, RMK did manage to get the board booting finally
>> (uImage related issues, low level debug problem) but with DT only supported
>> build, the audio and DSS was not at same state as before(non-DT build).
>> And then Tony pointed the issues to Peter and Tomy to address it further.
>>
>> Russell,
>> Is above right or I am missing something ?
> 
> I thought that was the 4430 from before the merge window. Ths issue here is
> the 2430 running mainline, as reported by Paul
> 
Actually thread got hijacked a bit when Rajendra replied the OMAP4430
results. I then replied on top of that. Sorry about that

Regards,
Santosh

OMAP2430 SDP boot broken after Linus' rmk merge

[Paul Walmsley]

Tonight I put on a Jon Hopkins album, in recollection of my UK ARM Linux 
colleagues perhaps, and started testing, and eventually wound up with this 
one:

commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc
Author: Will Deacon <will.deacon@arm.com>
Date:   Wed Jun 12 12:25:56 2013 +0100

    ARM: 7757/1: mm: don't flush icache in switch_mm with hardware broadcasting
    
    When scheduling an mm on a CPU where it hasn't previously been used, we
    flush the icache on that CPU so that any code loaded previously on
    a different core can be safely executed.
    
    For cores with hardware broadcasting of cache maintenance operations,
    this is clearly unnecessary, since the inner-shareable invalidation in
    __sync_icache_dcache will affect all CPUs.
    
    This patch conditionalises the icache flush in switch_mm based on
    cache_ops_need_broadcast().
    
    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    Reported-by: Albin Tonnerre <albin.tonnerre@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

...

v3.11-rc2 boots with it reverted.  What also works is v3.11-rc2 with the 
below patch applied.

Would be pleased to boot-test anything you'd care to send my way, as long 
as you can tolerate response latency jitter.


- Paul

diff --git a/arch/arm/include/asm/mmu_context.h b/arch/arm/include/asm/mmu_context.h
index b5792b7..8dfb295 100644
--- a/arch/arm/include/asm/mmu_context.h
+++ b/arch/arm/include/asm/mmu_context.h
@@ -112,7 +112,7 @@ switch_mm(struct mm_struct *prev, struct mm_struct *next,
 	 * so check for possible thread migration and invalidate the I-cache
 	 * if we're new to this CPU.
 	 */
-	if (cache_ops_need_broadcast() &&
+	if (1 &&
 	    !cpumask_empty(mm_cpumask(next)) &&
 	    !cpumask_test_cpu(cpu, mm_cpumask(next)))
 		__flush_icache_all();

OMAP2430 SDP boot broken after Linus' rmk merge

[Will Deacon]

On Sat, Jul 27, 2013 at 05:10:56AM +0100, Paul Walmsley wrote:
> 
> Tonight I put on a Jon Hopkins album, in recollection of my UK ARM Linux 
> colleagues perhaps, and started testing, and eventually wound up with this 
> one:
> 
> commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc
> Author: Will Deacon <will.deacon@arm.com>

Oh, great...

> Date:   Wed Jun 12 12:25:56 2013 +0100
> 
>     ARM: 7757/1: mm: don't flush icache in switch_mm with hardware broadcasting
>     
>     When scheduling an mm on a CPU where it hasn't previously been used, we
>     flush the icache on that CPU so that any code loaded previously on
>     a different core can be safely executed.
>     
>     For cores with hardware broadcasting of cache maintenance operations,
>     this is clearly unnecessary, since the inner-shareable invalidation in
>     __sync_icache_dcache will affect all CPUs.
>     
>     This patch conditionalises the icache flush in switch_mm based on
>     cache_ops_need_broadcast().
>     
>     Acked-by: Catalin Marinas <catalin.marinas@arm.com>
>     Reported-by: Albin Tonnerre <albin.tonnerre@arm.com>
>     Signed-off-by: Will Deacon <will.deacon@arm.com>
>     Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> 
> ...
> 
> v3.11-rc2 boots with it reverted.  What also works is v3.11-rc2 with the 
> below patch applied.

That's very odd -- I *suspect* your bootloader is up to no good (iirc, we've
had issues with the bootloader on this machine in the past, since it enters
the kernel in ABT mode or something).

> Would be pleased to boot-test anything you'd care to send my way, as long 
> as you can tolerate response latency jitter.

Can you try this quick hack please? It clobbers the I-cache as soon as we
enter the kernel, so it should tell us whether my theory is correct.

Cheers,

Will

--->8

diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 9cf6063..d74c64c 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -83,6 +83,9 @@ ENTRY(stext)
  THUMB(        .thumb                  )       @ switch to Thumb now.
  THUMB(1:                      )
 
+       mov     r9, #0
+       mcr     p15, 0, r9, c7, c5, 0
+
 #ifdef CONFIG_ARM_VIRT_EXT
        bl      __hyp_stub_install
 #endif

OMAP2430 SDP boot broken after Linus' rmk merge

[Paul Walmsley]

Hi Will,

On Sat, 27 Jul 2013, Will Deacon wrote:

> That's very odd -- I *suspect* your bootloader is up to no good (iirc, we've
> had issues with the bootloader on this machine in the past, since it enters
> the kernel in ABT mode or something).

Maybe you're thinking of the (2420-based) Nokia N800?  The 2430SDP here 
uses u-boot:

http://www.pwsan.com/omap/testlogs/test_v3.10-rc7/20130630191558/boot/2430sdp/

> Can you try this quick hack please? It clobbers the I-cache as soon as we
> enter the kernel, so it should tell us whether my theory is correct.

Tried it and still hangs.  Spent some time debugging - turns out it's due 
to the extended CP15 register read in cache_ops_need_broadcast().. the 
extended regs aren't present on ARM1136 r0* and trigger an undefined 
instruction abort :-(  Sorry about that, should have taken the time to 
send along an earlyprintk trace.  Patches in a few moments -


- Paul

[PATCH] ARM: v6: avoid remaining accesses to missing CP15 registers on ARM1136 r0

[Paul Walmsley]

Ensure that the remaining callers of read_cpuid_ext can't attempt an
extended CP15 register read on ARMv6.  The only one that appears dodgy
is tlb_ops_need_broadcast().

While here, convert feat_v6_fixup() to use cpu_is_arm1136_r0() to save
a few lines of code.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
---

Intended for v3.12.  Depends on the patch "ARM: v6: avoid read_cpuid_ext() 
on ARM1136r0 in cache_ops_need_broadcast()".

Tested (along with the parent patch) here:

http://www.pwsan.com/omap/testlogs/bisect_2430sdp_hang_v3.11-rc/20130727224434/README.txt

against stock v3.11-rc2, so several boards aren't booting due to unrelated 
issues.

 arch/arm/include/asm/smp_plat.h | 3 +++
 arch/arm/kernel/setup.c         | 7 +------
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/arch/arm/include/asm/smp_plat.h b/arch/arm/include/asm/smp_plat.h
index 76214cb..ad07564 100644
--- a/arch/arm/include/asm/smp_plat.h
+++ b/arch/arm/include/asm/smp_plat.h
@@ -30,6 +30,9 @@ static inline bool is_smp(void)
 #else
 static inline int tlb_ops_need_broadcast(void)
 {
+	if (cpu_is_arm1136_r0())
+		return 0;
+
 	if (!is_smp())
 		return 0;
 
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 63af9a7..a601843 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -389,16 +389,11 @@ static void __init cpuid_init_hwcaps(void)
 
 static void __init feat_v6_fixup(void)
 {
-	int id = read_cpuid_id();
-
-	if ((id & 0xff0f0000) != 0x41070000)
-		return;
-
 	/*
 	 * HWCAP_TLS is available only on 1136 r1p0 and later,
 	 * see also kuser_get_tls_init.
 	 */
-	if ((((id >> 4) & 0xfff) == 0xb36) && (((id >> 20) & 3) == 0))
+	if (cpu_is_arm1136_r0())
 		elf_hwcap &= ~HWCAP_TLS;
 }
 
-- 
1.8.3.2

[PATCH] ARM: v6: avoid remaining accesses to missing CP15 registers on ARM1136 r0

[Paul Walmsley]

On Sun, 28 Jul 2013, Paul Walmsley wrote:

> Ensure that the remaining callers of read_cpuid_ext can't attempt an
> extended CP15 register read on ARMv6.

This description is somewhat inaccurate - it should read something like 
"can't attempt an extended CP15 register read on ARMv6 cores that don't 
support it".  Will resend.


- Paul

[PATCH v2] ARM: v6: avoid remaining accesses to missing CP15 registers on ARM1136 r0

[Paul Walmsley]

Ensure that the remaining callers of read_cpuid_ext can't attempt an 
extended CP15 register read on ARMv6 cores that don't support it.  The 
only one that appears dodgy is tlb_ops_need_broadcast().

While here, convert feat_v6_fixup() to use cpu_is_arm1136_r0() to save
a few lines of code.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/include/asm/smp_plat.h | 3 +++
 arch/arm/kernel/setup.c         | 7 +------
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/arch/arm/include/asm/smp_plat.h b/arch/arm/include/asm/smp_plat.h
index 76214cb..ad07564 100644
--- a/arch/arm/include/asm/smp_plat.h
+++ b/arch/arm/include/asm/smp_plat.h
@@ -30,6 +30,9 @@ static inline bool is_smp(void)
 #else
 static inline int tlb_ops_need_broadcast(void)
 {
+	if (cpu_is_arm1136_r0())
+		return 0;
+
 	if (!is_smp())
 		return 0;
 
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 63af9a7..a601843 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -389,16 +389,11 @@ static void __init cpuid_init_hwcaps(void)
 
 static void __init feat_v6_fixup(void)
 {
-	int id = read_cpuid_id();
-
-	if ((id & 0xff0f0000) != 0x41070000)
-		return;
-
 	/*
 	 * HWCAP_TLS is available only on 1136 r1p0 and later,
 	 * see also kuser_get_tls_init.
 	 */
-	if ((((id >> 4) & 0xfff) == 0xb36) && (((id >> 20) & 3) == 0))
+	if (cpu_is_arm1136_r0())
 		elf_hwcap &= ~HWCAP_TLS;
 }
 
-- 
1.8.3.2

[PATCH v2] ARM: v6: avoid remaining accesses to missing CP15 registers on ARM1136 r0

[Paul Walmsley]

On Sun, 28 Jul 2013, Paul Walmsley wrote:

> Ensure that the remaining callers of read_cpuid_ext can't attempt an 
> extended CP15 register read on ARMv6 cores that don't support it.  The 
> only one that appears dodgy is tlb_ops_need_broadcast().
> 
> While here, convert feat_v6_fixup() to use cpu_is_arm1136_r0() to save
> a few lines of code.
> 
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Russell King <rmk+kernel@arm.linux.org.uk>

For the archives - this one can be ignored; the cpu_is_arm1136_r0() isn't 
needed due to the SMP-on-UP code.


- Paul

[PATCH] ARM: v6: avoid read_cpuid_ext() on ARM1136r0 in cache_ops_need_broadcast()

[Paul Walmsley]

Commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc ("ARM: 7757/1: mm:
don't flush icache in switch_mm with hardware broadcasting") breaks
the boot on OMAP2430SDP with omap2plus_defconfig.  Tracked to an
undefined instruction abort from the CP15 read in
cache_ops_need_broadcast().  It turns out that early ARM1136 variants
don't support several CP15 registers that later ARM cores do.
ARM1136JF-S TRM section 3.2.1 "Register allocation" has the details.

So, prevent cache_ops_need_broadcast() from attempting the CP15 read
if the running CPU doesn't provide the register.
cache_ops_need_broadcast() is a hot path function, so focus on
minimizing the execution time impact.  A subsequent patch will take
care of the remaining cases in the current kernel.

Thanks to Will Deacon for helping track this down.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Will Deacon <will.deacon@arm.com>
---

Intended for v3.11-rc.

Tested (along with the followup patch) here:

http://www.pwsan.com/omap/testlogs/bisect_2430sdp_hang_v3.11-rc/20130727224434/README.txt

against stock v3.11-rc2, so several boards aren't booting due to unrelated 
issues.

 arch/arm/include/asm/cputype.h  | 37 ++++++++++++++++++++++++++++++++++++-
 arch/arm/include/asm/smp_plat.h |  4 +++-
 2 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
index 8c25dc4..91ccd77 100644
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h
@@ -76,6 +76,8 @@
 #define ARM_CPU_XSCALE_ARCH_V2		0x4000
 #define ARM_CPU_XSCALE_ARCH_V3		0x6000
 
+#define ARM_CPU_ARM1136R0		0x4107b360
+
 extern unsigned int processor_id;
 
 #ifdef CONFIG_CPU_CP15
@@ -89,10 +91,43 @@ extern unsigned int processor_id;
 		__val;							\
 	})
 
+
+/* Workaround for missing CP15 registers on ARM1136 r0 */
+# if defined(CONFIG_CPU_V6)
+/**
+ * cpu_is_arm1136_r0 - is the kernel running on an ARM1136 r0 core?
+ *
+ * Returns true if the kernel is running on an ARM1136 r0 core, or
+ * false otherwise.  Callers use this to avoid undefined instruction
+ * aborts from CP15 accesses to registers not present on the r0
+ * variant, or to detect whether certain CPU features are available.
+ * ARM1136JF-S TRM section 3.2.1 "Register allocation"
+ */
+static inline bool __attribute_const__ cpu_is_arm1136_r0(void)
+{
+	return ((read_cpuid(CPUID_ID) & 0xfffffff0) == ARM_CPU_ARM1136R0);
+}
+
+/*
+ * The mrc in the read_cpuid_ext macro must not be reordered on ARMv6,
+ * else the compiler may move it before any ARM1136r0 test.
+ */
+# define CPUID_EXT_REORDER	volatile
+# else
+static inline bool __attribute_const__ cpu_is_arm1136_r0(void) { return false; }
+# define CPUID_EXT_REORDER
+# endif
+
+/*
+ * Early ARM1136 variants don't support many CP15 registers provided
+ * on later cores.  Users of read_cpuid_ext must ensure that it won't
+ * be used unless it's known that the running core provides the CP15
+ * register ext_reg.  See cpu_is_arm1136_r0() above.
+ */
 #define read_cpuid_ext(ext_reg)						\
 	({								\
 		unsigned int __val;					\
-		asm("mrc	p15, 0, %0, c0, " ext_reg		\
+		asm CPUID_EXT_REORDER("mrc p15, 0, %0, c0, " ext_reg	\
 		    : "=r" (__val)					\
 		    :							\
 		    : "cc");						\
diff --git a/arch/arm/include/asm/smp_plat.h b/arch/arm/include/asm/smp_plat.h
index 6462a72..76214cb 100644
--- a/arch/arm/include/asm/smp_plat.h
+++ b/arch/arm/include/asm/smp_plat.h
@@ -25,7 +25,6 @@ static inline bool is_smp(void)
 #endif
 }
 
-/* all SMP configurations have the extended CPUID registers */
 #ifndef CONFIG_MMU
 #define tlb_ops_need_broadcast()	0
 #else
@@ -43,6 +42,9 @@ static inline int tlb_ops_need_broadcast(void)
 #else
 static inline int cache_ops_need_broadcast(void)
 {
+	if (cpu_is_arm1136_r0())
+		return 0;
+
 	if (!is_smp())
 		return 0;
 
-- 
1.8.3.2

[PATCH] ARM: v6: avoid read_cpuid_ext() on ARM1136r0 in cache_ops_need_broadcast()

[Will Deacon]

Hi Paul,

Cheers for sticking with this!

On Sun, Jul 28, 2013 at 06:43:24AM +0100, Paul Walmsley wrote:
> 
> Commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc ("ARM: 7757/1: mm:
> don't flush icache in switch_mm with hardware broadcasting") breaks
> the boot on OMAP2430SDP with omap2plus_defconfig.  Tracked to an
> undefined instruction abort from the CP15 read in
> cache_ops_need_broadcast().  It turns out that early ARM1136 variants
> don't support several CP15 registers that later ARM cores do.
> ARM1136JF-S TRM section 3.2.1 "Register allocation" has the details.

Intriguing... I wouldn't expect a cp15 read to be emitted for 1136, since
the SMP_ON_UP magic should have caused is_smp() to return false.

> diff --git a/arch/arm/include/asm/smp_plat.h b/arch/arm/include/asm/smp_plat.h
> index 6462a72..76214cb 100644
> --- a/arch/arm/include/asm/smp_plat.h
> +++ b/arch/arm/include/asm/smp_plat.h
> @@ -25,7 +25,6 @@ static inline bool is_smp(void)
>  #endif
>  }
>  
> -/* all SMP configurations have the extended CPUID registers */
>  #ifndef CONFIG_MMU
>  #define tlb_ops_need_broadcast()	0
>  #else
> @@ -43,6 +42,9 @@ static inline int tlb_ops_need_broadcast(void)
>  #else
>  static inline int cache_ops_need_broadcast(void)
>  {
> +	if (cpu_is_arm1136_r0())
> +		return 0;
> +
>  	if (!is_smp())
>  		return 0;

So we should have returned 0 here without exploding (this just reads a
.globl initialised in head.S). Are we somehow misidentifying your 1136
as an SMP core?

Will

[PATCH] ARM: v6: avoid read_cpuid_ext() on ARM1136r0 in cache_ops_need_broadcast()

[Russell King - ARM Linux]

On Sun, Jul 28, 2013 at 12:10:38PM +0100, Will Deacon wrote:
> Hi Paul,
> 
> Cheers for sticking with this!
> 
> On Sun, Jul 28, 2013 at 06:43:24AM +0100, Paul Walmsley wrote:
> > 
> > Commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc ("ARM: 7757/1: mm:
> > don't flush icache in switch_mm with hardware broadcasting") breaks
> > the boot on OMAP2430SDP with omap2plus_defconfig.  Tracked to an
> > undefined instruction abort from the CP15 read in
> > cache_ops_need_broadcast().  It turns out that early ARM1136 variants
> > don't support several CP15 registers that later ARM cores do.
> > ARM1136JF-S TRM section 3.2.1 "Register allocation" has the details.
> 
> Intriguing... I wouldn't expect a cp15 read to be emitted for 1136, since
> the SMP_ON_UP magic should have caused is_smp() to return false.

The compiler seems to be doing something quite odd with schedule():

00000540 <__schedule>:
 558:   ee103ff1        mrc     15, 0, r3, cr0, cr1, {7}
 560:   e1a03623        lsr     r3, r3, #12
 564:   e203300f        and     r3, r3, #15
 570:   e50b3080        str     r3, [fp, #-128] ; 0x80
...
 6e8:   e59f3428        ldr     r3, [pc, #1064] ; b18 <__schedule+0x5d8>
 6f0:   e5933000        ldr     r3, [r3]
 6f4:   e3530000        cmp     r3, #0
 6f8:   1a000027        bne     79c <__schedule+0x25c>
 6fc:   e2851f65        add     r1, r5, #404    ; 0x194
 700:   ebfffffe        bl      0 <_test_and_set_bit>
                        700: R_ARM_CALL _test_and_set_bit
...
 79c:   e51b1080        ldr     r1, [fp, #-128] ; 0x80
 7a0:   e3510000        cmp     r1, #0
 7a4:   1affffd4        bne     6fc <__schedule+0x1bc>
                        b18: R_ARM_ABS32        smp_on_up

Yes - that's right, it's reading from the mcr at the very start of
__schedule and storing it on the stack for just one test later on.  The
act of storing it on the stack and reading it back of is likely a lot
more expensive than reading it from CP15 in the first place!

We don't want to make the asm() itself volatile, because that means the
asm() statement can't be optimised away.

Adding a memory clobber to that asm seems to place it more appropriately,
but again, that's not particularly desirable.

Another solution would be to make both tlb_ops_need_broadcast and
cache_ops_need_broadcast both be a flag test, but that introduces a
memory load in all those paths no matter if we're running on SMP_ON_UP
or not.

[PATCH] ARM: v6: avoid read_cpuid_ext() on ARM1136r0 in cache_ops_need_broadcast()

[Paul Walmsley]

On Sun, 28 Jul 2013, Russell King - ARM Linux wrote:

> We don't want to make the asm() itself volatile, because that means the 
> asm() statement can't be optimised away.
> 
> Adding a memory clobber to that asm seems to place it more appropriately,
> but again, that's not particularly desirable.
> 
> Another solution would be to make both tlb_ops_need_broadcast and
> cache_ops_need_broadcast both be a flag test, but that introduces a
> memory load in all those paths no matter if we're running on SMP_ON_UP
> or not.

I considered adding a HWCAP_* bit under the theory that elf_hwcap may 
already be cache-resident.  But thought that the loss of the flag space 
and possible memory access vs. the additional mrc wasn't worth it.

Anyway, if either of you have a preference between these three, I'd be 
happy to update the patch.  Or feel free to take it over from here if 
either of you prefer.


- Paul

[PATCH] ARM: v6: avoid read_cpuid_ext() on ARM1136r0 in cache_ops_need_broadcast()

[Paul Walmsley]

Hi Will

On Sun, 28 Jul 2013, Will Deacon wrote:

> On Sun, Jul 28, 2013 at 06:43:24AM +0100, Paul Walmsley wrote:
> > 
> > Commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc ("ARM: 7757/1: mm:
> > don't flush icache in switch_mm with hardware broadcasting") breaks
> > the boot on OMAP2430SDP with omap2plus_defconfig.  Tracked to an
> > undefined instruction abort from the CP15 read in
> > cache_ops_need_broadcast().  It turns out that early ARM1136 variants
> > don't support several CP15 registers that later ARM cores do.
> > ARM1136JF-S TRM section 3.2.1 "Register allocation" has the details.
> 
> Intriguing... I wouldn't expect a cp15 read to be emitted for 1136, since
> the SMP_ON_UP magic should have caused is_smp() to return false.
> 

...

> So we should have returned 0 here without exploding (this just reads a
> .globl initialised in head.S). Are we somehow misidentifying your 1136
> as an SMP core?

You're right - the is_arm1136_r0() logic is completely unnecessary - it's 
just the 'asm volatile' that makes the difference.

- Paul

[PATCH] ARM: v6: prevent gcc from reordering extended CP15 reads above is_smp() test

[Paul Walmsley]

Commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc ("ARM: 7757/1: mm:
don't flush icache in switch_mm with hardware broadcasting") breaks
the boot on OMAP2430SDP with omap2plus_defconfig.  Tracked to an
undefined instruction abort from the CP15 read in
cache_ops_need_broadcast().  It turns out that gcc reorders the
extended CP15 read above the is_smp() test.  This breaks ARM1136 r0
cores, since they don't support several CP15 registers that later ARM
cores do.  ARM1136JF-S TRM section 3.2.1 "Register allocation" has the
details.

So, when the kernel is built for ARMv6 cores, mark the extended CP15
read as clobbering memory, which seems to prevent the compiler from
reordering it before the is_smp() test.  Russell states that the code
generated from this approach is preferable to marking the inline asm
as volatile.

This patch was developed in collaboration with Will Deacon and Russell
King.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
---

Thought I'd respin this to have a discussion strawman.  It boots cleanly 
on 2430SDP.

[ Updated "ARM: v6: avoid read_cpuid_ext() on ARM1136r0 in 
cache_ops_need_broadcast()" to drop the unnecessary ARM1136 r0 test, to 
switch to a memory clobber per rmk's suggestion, and to update the commit 
message. ]

Intended for v3.11-rc.


 arch/arm/include/asm/cputype.h | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
index 8c25dc4..f428eb0 100644
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h
@@ -89,13 +89,25 @@ extern unsigned int processor_id;
 		__val;							\
 	})
 
+
+# if defined(CONFIG_CPU_V6)
+/*
+ * The mrc in the read_cpuid_ext macro must not be reordered on ARMv6,
+ * else the compiler may move it before an is_smp() test, causing
+ * undefined instruction aborts on ARM1136 r0.
+ */
+# define CPUID_EXT_REORDER	"cc", "memory"
+# else
+# define CPUID_EXT_REORDER	"cc"
+# endif
+
 #define read_cpuid_ext(ext_reg)						\
 	({								\
 		unsigned int __val;					\
 		asm("mrc	p15, 0, %0, c0, " ext_reg		\
 		    : "=r" (__val)					\
 		    :							\
-		    : "cc");						\
+		    : CPUID_EXT_REORDER);				\
 		__val;							\
 	})
 
-- 
1.8.3.2

[PATCH] ARM: v6: prevent gcc from reordering extended CP15 reads above is_smp() test

[Tony Lindgren]

Hi,

* Paul Walmsley <paul@pwsan.com> [130728 13:23]:
> 
> Commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc ("ARM: 7757/1: mm:
> don't flush icache in switch_mm with hardware broadcasting") breaks
> the boot on OMAP2430SDP with omap2plus_defconfig.  Tracked to an
> undefined instruction abort from the CP15 read in
> cache_ops_need_broadcast().  It turns out that gcc reorders the
> extended CP15 read above the is_smp() test.  This breaks ARM1136 r0
> cores, since they don't support several CP15 registers that later ARM
> cores do.  ARM1136JF-S TRM section 3.2.1 "Register allocation" has the
> details.
> 
> So, when the kernel is built for ARMv6 cores, mark the extended CP15
> read as clobbering memory, which seems to prevent the compiler from
> reordering it before the is_smp() test.  Russell states that the code
> generated from this approach is preferable to marking the inline asm
> as volatile.
> 
> This patch was developed in collaboration with Will Deacon and Russell
> King.
> 
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Russell King <rmk+kernel@arm.linux.org.uk>

Sorry to be late to this party, I was offline last week. This
patch fixes the issue for me:

Acked-by: Tony Lindgren <tony@atomide.com>

[PATCH] ARM: v6: prevent gcc from reordering extended CP15 reads above is_smp() test

[Will Deacon]

Hi Paul,

On Sun, Jul 28, 2013 at 09:16:29PM +0100, Paul Walmsley wrote:
> 
> Commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc ("ARM: 7757/1: mm:
> don't flush icache in switch_mm with hardware broadcasting") breaks
> the boot on OMAP2430SDP with omap2plus_defconfig.  Tracked to an
> undefined instruction abort from the CP15 read in
> cache_ops_need_broadcast().  It turns out that gcc reorders the
> extended CP15 read above the is_smp() test.  This breaks ARM1136 r0
> cores, since they don't support several CP15 registers that later ARM
> cores do.  ARM1136JF-S TRM section 3.2.1 "Register allocation" has the
> details.

Cheers for tracking this down. Interestingly, I can't reproduce this with
anything other than GCC 4.5.* tools -- 4.6+ do what we want. Still, it looks
like a valid (if not misguided) thing to do.

> diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
> index 8c25dc4..f428eb0 100644
> --- a/arch/arm/include/asm/cputype.h
> +++ b/arch/arm/include/asm/cputype.h
> @@ -89,13 +89,25 @@ extern unsigned int processor_id;
>  		__val;							\
>  	})
>  
> +
> +# if defined(CONFIG_CPU_V6)
> +/*
> + * The mrc in the read_cpuid_ext macro must not be reordered on ARMv6,
> + * else the compiler may move it before an is_smp() test, causing
> + * undefined instruction aborts on ARM1136 r0.
> + */
> +# define CPUID_EXT_REORDER	"cc", "memory"
> +# else
> +# define CPUID_EXT_REORDER	"cc"
> +# endif
> +
>  #define read_cpuid_ext(ext_reg)						\
>  	({								\
>  		unsigned int __val;					\
>  		asm("mrc	p15, 0, %0, c0, " ext_reg		\
>  		    : "=r" (__val)					\
>  		    :							\
> -		    : "cc");						\
> +		    : CPUID_EXT_REORDER);				\
>  		__val;							\
>  	})

I wouldn't worry about checking for CPU_V6. Besides, we probably need this
to be re-evaluated across barrier() when we get CPU migration on a
big-little platform anyway (we should probably also drop the
__attribute_const__ for that).

So you can just replace the "cc" (now that Nico kindly explained why those
aren't needed the other day) with "memory".

An alternative is to add barrier() between is_smp() and the read_cpuid_ext()
in all callers, adding a fake read from the stack to the latter (like I did
for the per-cpu accessor). However, this relies on fixing all callers for
very little gain, so I don't think it's worth the hassle.

I can cook a patch if you're tied up with other things -- just let me know.

Cheers,

Will

[PATCH] ARM: v6: prevent gcc from reordering extended CP15 reads above is_smp() test

[Paul Walmsley]

Hi Will

On Mon, 29 Jul 2013, Will Deacon wrote:

> I wouldn't worry about checking for CPU_V6. Besides, we probably need this
> to be re-evaluated across barrier() when we get CPU migration on a
> big-little platform anyway (we should probably also drop the
> __attribute_const__ for that).
> 
> So you can just replace the "cc" (now that Nico kindly explained why those
> aren't needed the other day) with "memory".
> 
> An alternative is to add barrier() between is_smp() and the read_cpuid_ext()
> in all callers, adding a fake read from the stack to the latter (like I did
> for the per-cpu accessor). However, this relies on fixing all callers for
> very little gain, so I don't think it's worth the hassle.
> 
> I can cook a patch if you're tied up with other things -- just let me know.

Makes sense to me.  Have respun the patch and will post it shortly.  
Thanks for the extra compiler research; it's been incorporated into the 
patch description and comments.


- Paul

[PATCH v2] ARM: v6: prevent gcc 4.5 from reordering extended CP15 reads above is_smp() test

[Paul Walmsley]

Commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc ("ARM: 7757/1: mm:
don't flush icache in switch_mm with hardware broadcasting") breaks
the boot on OMAP2430SDP with omap2plus_defconfig.  Tracked to an
undefined instruction abort from the CP15 read in
cache_ops_need_broadcast().  It turns out that gcc 4.5 reorders the
extended CP15 read above the is_smp() test.  This breaks ARM1136 r0
cores, since they don't support several CP15 registers that later ARM
cores do.  ARM1136JF-S TRM section 3.2.1 "Register allocation" has the
details.

So mark the extended CP15 read as clobbering memory, which prevents
the compiler from reordering it before the is_smp() test.  Russell
states that the code generated from this approach is preferable to
marking the inline asm as volatile.  Remove the existing condition
code clobber as it's obsolete, per Nico's post:

    http://www.spinics.net/lists/arm-kernel/msg261208.html

This patch is a collaboration with Will Deacon and Russell King.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Tony Lindgren <tony@atomide.com>
---

Intended for v3.11-rc.

Basic test logs available here:

http://www.pwsan.com/omap/testlogs/bisect_2430sdp_hang_v3.11-rc/20130730045715/

N.B., several boards have problems on v3.11-rc that are unrelated to this 
patch.

 arch/arm/include/asm/cputype.h | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
index 8c25dc4..9672e97 100644
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h
@@ -89,13 +89,18 @@ extern unsigned int processor_id;
 		__val;							\
 	})
 
+/*
+ * The memory clobber prevents gcc 4.5 from reordering the mrc before
+ * any is_smp() tests, which can cause undefined instruction aborts on
+ * ARM1136 r0 due to the missing extended CP15 registers.
+ */
 #define read_cpuid_ext(ext_reg)						\
 	({								\
 		unsigned int __val;					\
 		asm("mrc	p15, 0, %0, c0, " ext_reg		\
 		    : "=r" (__val)					\
 		    :							\
-		    : "cc");						\
+		    : "memory");					\
 		__val;							\
 	})
 
-- 
1.8.3.2

[PATCH v2] ARM: v6: prevent gcc 4.5 from reordering extended CP15 reads above is_smp() test

[Will Deacon]

On Tue, Jul 30, 2013 at 12:32:06PM +0100, Paul Walmsley wrote:
> 
> Commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc ("ARM: 7757/1: mm:
> don't flush icache in switch_mm with hardware broadcasting") breaks
> the boot on OMAP2430SDP with omap2plus_defconfig.  Tracked to an
> undefined instruction abort from the CP15 read in
> cache_ops_need_broadcast().  It turns out that gcc 4.5 reorders the
> extended CP15 read above the is_smp() test.  This breaks ARM1136 r0
> cores, since they don't support several CP15 registers that later ARM
> cores do.  ARM1136JF-S TRM section 3.2.1 "Register allocation" has the
> details.
> 
> So mark the extended CP15 read as clobbering memory, which prevents
> the compiler from reordering it before the is_smp() test.  Russell
> states that the code generated from this approach is preferable to
> marking the inline asm as volatile.  Remove the existing condition
> code clobber as it's obsolete, per Nico's post:
> 
>     http://www.spinics.net/lists/arm-kernel/msg261208.html
> 
> This patch is a collaboration with Will Deacon and Russell King.
> 
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Russell King <rmk+kernel@arm.linux.org.uk>
> Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
> Cc: Tony Lindgren <tony@atomide.com>
> ---

Acked-by: Will Deacon <will.deacon@arm.com>

Will

OMAP2430 SDP boot broken after Linus' rmk merge

[Russell King - ARM Linux]

On Wed, Jul 24, 2013 at 10:17:01AM -0400, Santosh Shilimkar wrote:
> On Wednesday 24 July 2013 09:56 AM, Will Deacon wrote:
> > On Tue, Jul 23, 2013 at 10:05:17AM +0100, Rajendra Nayak wrote:
> >> On Tuesday 23 July 2013 12:37 PM, Paul Walmsley wrote:
> >>> Hi Rajendra,
> >>>
> >>> On Tue, 23 Jul 2013, Rajendra Nayak wrote:
> >>>
> >>>> On Tuesday 23 July 2013 01:37 AM, Paul Walmsley wrote:
> >>>>> On Mon, 22 Jul 2013, Russell King - ARM Linux wrote:
> >>>>>
> >>>>>> Bear in mind that I'm almost at the point of not boot-testing anything
> >>>>>> I sent to Linus because of the uselessness of the SDP4430 board now
> >>>>>> that it's DT only - the only platform which boot-tests anything I send
> >>>>>> is the 3430LDP board now.  If people care about that, maybe they can
> >>>>>> assist with sorting out the issues I've raised on these lists about
> >>>>>> the SDP4430 - and why the SDP4430 build remains disabled in my build
> >>>>>> and boot system.
> >>>>>
> >>>>> I understand completely...
> >>>>>
> >>>>>> Looking at the boot log, it just stops after uboot hands over control.
> >>>>>> With the lack of output from the decompressor, it's not possible to
> >>>>>> tell whether it's a decompressor problem or a kernel problem.
> >>>>>>
> >>>>>> I think you need to turn on the LL_DEBUG option, select the appropriate
> >>>>>> output option, and also get the decompressor to use the kernel's debug
> >>>>>> io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS).
> >>>>>
> >>>>> OK, will dig deeper here at the next opportunity.
> >>>>
> >>>> Paul, I can take a look at the 4430sdp issue. Are you also seeing this also on
> >>>> 2430sdp as the subject says, or was that a typo?
> >>>
> >>> Thanks for the offer.  The issue that I'm seeing is on the 2430SDP in my 
> >>> testbed.
> >>>
> >>> I don't have a 4430SDP, so you might consider touching base with rmk for 
> >>> that one.
> >>
> >> So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see
> >> the below errors. (I am using the mainline bootloaders which do not lock any
> >> additional DPLLs like USB)
> > 
> > Any update on this? If it's an issue introduced by architectural changes,
> > I'd really like to bisect it down but I don't have a board.
> > 
> >From the other thread, RMK did manage to get the board booting finally
> (uImage related issues, low level debug problem) but with DT only supported
> build, the audio and DSS was not at same state as before(non-DT build).
> And then Tony pointed the issues to Peter and Tomy to address it further.
> 
> Russell,
> Is above right or I am missing something ?

Will is referring to the 2430 issues I think; the original topic of this
thread.

I've not enabled the 4430 again in the build system because I see no point
to it - it can't find its rootfs because the device numbering for the MMC/SD
cards has reversed itself.  Not only does that need the kernel command line
changed, but it also needs fixing in the fstab on the SD card rootfs, and
quite frankly I really can't be bothered at the moment with this kind of
pointless boot breaking churn.

I also continue to be disappointed by the lack of things working on the
4430 - it's been a number of years now and _still_ the on-board LCDs do
not work.  People have tried to blame that on hardware faults and the
like, but they're just being idiotic when they say stuff like that.  It
can't be hardware faults when the kernel supplied with the board is able
to make them work to the extent that userspace can play back video on all
three output devices simultaneously, without hiccup or any imperfection.
I don't know whether it's just that the backlight support isn't working
or what - because any information on the 4430 seems to be a tightly
controlled secret that only a few select people are permitted to know
about.  As far as I'm concerned, much of the hardware is a black box to
me.

And yes, my 4430 has the projector module on it.  Never ever seen that
work, and no idea how to make it work because there's no information
available on the hardware.

It's a bit like the useless 3430LDP - though there's information available
there's no way to work out which of the many different designs of 3430LDP
the one I have ties up with, and I'm pretty sure that all the published
revisions of the circuits for the 3430LDP do not match the version I have
here - which means when things go wrong, there's no way for me to look
at stuff.

And no, I don't want another Beagle board or Panda board or whatever, I
have those (I think I have one of each), and they've never been powered up
because they have no ethernet on them, and I have no USB to ethernet still,
partly because I don't really do USB here *at* *all*, so I don't know what
works well and what doesn't with Linux.  Even if I did provide them with a
USB ethernet, I doubt they'd be able to boot a kernel via the network.

My experience of USB is hellishly poor - I have an icybox eSATA enclosure
which also provides USB.  The USB interface on that regularly drops out
with errors, timeouts, and even isn't recognised on many occasions.  I
see slow serial comms with USB serial devices on platforms like the
4430SDP and Dove Cubox - the speed is very much like a 4800baud modem, even
though the serial runs at 115200 baud.  No, don't even _think_ about blaming
the host, because this happens whether it be a Thinkpad, or the USB hosts
in a Thecus N2100.

I can believe why this all happens, when you see USB interrupts taking
upwards of 3ms to complete:

Longest time: 3247506ns
Longest irq: 24
Longest handler: usb_hcd_irq+0x0/0x68

is it hardly surprising that USB is soo crap?  And the above 3ms is just
for handling a USB keyboard - what takes 3ms over servicing a USB keyboard?
I mean, what crap USB really is when it behaves like that... and is it
no wonder I hate the bloody thing.

Anyway, this is getting off topic. :)

OMAP4430 SDP boot issues.. (Was Re: OMAP2430 SDP boot broken after Linus' rmk merge)

[Santosh Shilimkar]

On Wednesday 24 July 2013 10:52 AM, Russell King - ARM Linux wrote:
> On Wed, Jul 24, 2013 at 10:17:01AM -0400, Santosh Shilimkar wrote:
>> On Wednesday 24 July 2013 09:56 AM, Will Deacon wrote:
>>> On Tue, Jul 23, 2013 at 10:05:17AM +0100, Rajendra Nayak wrote:
>>>> On Tuesday 23 July 2013 12:37 PM, Paul Walmsley wrote:

[..]

>>>>> I don't have a 4430SDP, so you might consider touching base with rmk for 
>>>>> that one.
>>>>
>>>> So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see
>>>> the below errors. (I am using the mainline bootloaders which do not lock any
>>>> additional DPLLs like USB)
>>>
>>> Any update on this? If it's an issue introduced by architectural changes,
>>> I'd really like to bisect it down but I don't have a board.
>>>
>> >From the other thread, RMK did manage to get the board booting finally
>> (uImage related issues, low level debug problem) but with DT only supported
>> build, the audio and DSS was not at same state as before(non-DT build).
>> And then Tony pointed the issues to Peter and Tomy to address it further.
>>
>> Russell,
>> Is above right or I am missing something ?
> 
> Will is referring to the 2430 issues I think; the original topic of this
> thread.
>
We crossed the emails. Am just renaming the thread since below summary is
still important for OMAP4430SDP.
 
> I've not enabled the 4430 again in the build system because I see no point
> to it - it can't find its rootfs because the device numbering for the MMC/SD
> cards has reversed itself.  Not only does that need the kernel command line
> changed, but it also needs fixing in the fstab on the SD card rootfs, and
> quite frankly I really can't be bothered at the moment with this kind of
> pointless boot breaking churn.
>
The MMC slot change has also troubled us in past in downstream kernel. Am
looping Balaji to see if he can fix it to restore the original ordering.
 
> I also continue to be disappointed by the lack of things working on the
> 4430 - it's been a number of years now and _still_ the on-board LCDs do
> not work.  People have tried to blame that on hardware faults and the
> like, but they're just being idiotic when they say stuff like that.  It
> can't be hardware faults when the kernel supplied with the board is able
> to make them work to the extent that userspace can play back video on all
> three output devices simultaneously, without hiccup or any imperfection.
> I don't know whether it's just that the backlight support isn't working
> or what - because any information on the 4430 seems to be a tightly
> controlled secret that only a few select people are permitted to know
> about.  As far as I'm concerned, much of the hardware is a black box to
> me.
> 
On the display related issues, Tomi and Archit have been sorting out
issue but am not sure about the current state. If the pre-built binaries
video playback works means your hardware seems to be fine.

> And yes, my 4430 has the projector module on it.  Never ever seen that
> work, and no idea how to make it work because there's no information
> available on the hardware.
> 
I think you mean the Pico DLP module. There was a downstream driver but
am not sure about the state. Archit, Tomi should be able to comment.

> It's a bit like the useless 3430LDP - though there's information available
> there's no way to work out which of the many different designs of 3430LDP
> the one I have ties up with, and I'm pretty sure that all the published
> revisions of the circuits for the 3430LDP do not match the version I have
> here - which means when things go wrong, there's no way for me to look
> at stuff.
> 
> And no, I don't want another Beagle board or Panda board or whatever, I
> have those (I think I have one of each), and they've never been powered up
> because they have no ethernet on them, and I have no USB to ethernet still,
> partly because I don't really do USB here *at* *all*, so I don't know what
> works well and what doesn't with Linux.  Even if I did provide them with a
> USB ethernet, I doubt they'd be able to boot a kernel via the network.
>
We discussed the LDP issue in past. That board is almost dead since almost
no one from TI is using/having it anymore.
 
> My experience of USB is hellishly poor - I have an icybox eSATA enclosure
> which also provides USB.  The USB interface on that regularly drops out
> with errors, timeouts, and even isn't recognised on many occasions.  I
> see slow serial comms with USB serial devices on platforms like the
> 4430SDP and Dove Cubox - the speed is very much like a 4800baud modem, even
> though the serial runs at 115200 baud.  No, don't even _think_ about blaming
> the host, because this happens whether it be a Thinkpad, or the USB hosts
> in a Thecus N2100.
> 
> I can believe why this all happens, when you see USB interrupts taking
> upwards of 3ms to complete:
> 
> Longest time: 3247506ns
> Longest irq: 24
> Longest handler: usb_hcd_irq+0x0/0x68
> 
> is it hardly surprising that USB is soo crap?  And the above 3ms is just
> for handling a USB keyboard - what takes 3ms over servicing a USB keyboard?
> I mean, what crap USB really is when it behaves like that... and is it
> no wonder I hate the bloody thing.
> 
Felipe might be able to comment better on the above USB topic.

Regards,
Santosh

OMAP4430 SDP boot issues.. (Was Re: OMAP2430 SDP boot broken after Linus' rmk merge)

[Russell King - ARM Linux]

On Wed, Jul 24, 2013 at 11:40:33AM -0400, Santosh Shilimkar wrote:
> On Wednesday 24 July 2013 10:52 AM, Russell King - ARM Linux wrote:
> > I also continue to be disappointed by the lack of things working on the
> > 4430 - it's been a number of years now and _still_ the on-board LCDs do
> > not work.  People have tried to blame that on hardware faults and the
> > like, but they're just being idiotic when they say stuff like that.  It
> > can't be hardware faults when the kernel supplied with the board is able
> > to make them work to the extent that userspace can play back video on all
> > three output devices simultaneously, without hiccup or any imperfection.
> > I don't know whether it's just that the backlight support isn't working
> > or what - because any information on the 4430 seems to be a tightly
> > controlled secret that only a few select people are permitted to know
> > about.  As far as I'm concerned, much of the hardware is a black box to
> > me.
> > 
> On the display related issues, Tomi and Archit have been sorting out
> issue but am not sure about the current state. If the pre-built binaries
> video playback works means your hardware seems to be fine.

Just let me be absolutely crystal clear about this: the on-board LCDs
have _never_ worked with a mainline kernel, but they did work with the
kernel which originally came with the board with the original 4430 SoC.
I can right now put the original 4430 SoC back on the board and boot
using the kernel which is still on the SD card and they will work.

Even with the original 4430 SoC and mainline kernels, they have never
worked.

I tried it back and forth several times, but even with this, the
explanation was always "your hardware must be faulty".  And then the wrong
voltage levels was found which was preventing the LCD modules from even
being recognised... but still, no sign of life on the LCD panels.

It may be that there's some error in the kernel configuration I'm building.
I don't know, because I have _no_ idea what hardware is involved in
bringing the LCDs online.  Like I said above, the 4430SDP board is just
a black box.  I am totally reliant on others telling me what the right
config options are supposed to be and fixing problems when things don't
work.

With the lack of information on this board, all I can do when things don't
work is whinge and moan at people.  I am powerless to debug the problems
myself, even if they're a simple misconfiguration.

Is there information available on the 4430SDP?  Is there any reason I
can't have access to it?

OMAP4430 SDP boot issues.. (Was Re: OMAP2430 SDP boot broken after Linus' rmk merge)

[Santosh Shilimkar]

On Wednesday 24 July 2013 01:23 PM, Russell King - ARM Linux wrote:
> On Wed, Jul 24, 2013 at 11:40:33AM -0400, Santosh Shilimkar wrote:
>> On Wednesday 24 July 2013 10:52 AM, Russell King - ARM Linux wrote:
>>> I also continue to be disappointed by the lack of things working on the
>>> 4430 - it's been a number of years now and _still_ the on-board LCDs do
>>> not work.  People have tried to blame that on hardware faults and the
>>> like, but they're just being idiotic when they say stuff like that.  It
>>> can't be hardware faults when the kernel supplied with the board is able
>>> to make them work to the extent that userspace can play back video on all
>>> three output devices simultaneously, without hiccup or any imperfection.
>>> I don't know whether it's just that the backlight support isn't working
>>> or what - because any information on the 4430 seems to be a tightly
>>> controlled secret that only a few select people are permitted to know
>>> about.  As far as I'm concerned, much of the hardware is a black box to
>>> me.
>>>
>> On the display related issues, Tomi and Archit have been sorting out
>> issue but am not sure about the current state. If the pre-built binaries
>> video playback works means your hardware seems to be fine.
> 
> Just let me be absolutely crystal clear about this: the on-board LCDs
> have _never_ worked with a mainline kernel, but they did work with the
> kernel which originally came with the board with the original 4430 SoC.
> I can right now put the original 4430 SoC back on the board and boot
> using the kernel which is still on the SD card and they will work.
> 
> Even with the original 4430 SoC and mainline kernels, they have never
> worked.
> 
> I tried it back and forth several times, but even with this, the
> explanation was always "your hardware must be faulty".  And then the wrong
> voltage levels was found which was preventing the LCD modules from even
> being recognised... but still, no sign of life on the LCD panels.
> 
> It may be that there's some error in the kernel configuration I'm building.
> I don't know, because I have _no_ idea what hardware is involved in
> bringing the LCDs online.  Like I said above, the 4430SDP board is just
> a black box.  I am totally reliant on others telling me what the right
> config options are supposed to be and fixing problems when things don't
> work.
> 
> With the lack of information on this board, all I can do when things don't
> work is whinge and moan at people.  I am powerless to debug the problems
> myself, even if they're a simple misconfiguration.
> 
> Is there information available on the 4430SDP?  Is there any reason I
> can't have access to it?
> 
I haven't come across the information which is available on the web.
Let me check if there are schematics which i can send across to
you.

Regards,
Santosh

OMAP2430 SDP boot broken after Linus' rmk merge

[Tomi Valkeinen]

On 24/07/13 17:52, Russell King - ARM Linux wrote:

> I also continue to be disappointed by the lack of things working on the
> 4430 - it's been a number of years now and _still_ the on-board LCDs do
> not work.  People have tried to blame that on hardware faults and the
> like, but they're just being idiotic when they say stuff like that.  It
> can't be hardware faults when the kernel supplied with the board is able
> to make them work to the extent that userspace can play back video on all
> three output devices simultaneously, without hiccup or any imperfection.
> I don't know whether it's just that the backlight support isn't working
> or what - because any information on the 4430 seems to be a tightly
> controlled secret that only a few select people are permitted to know
> about.  As far as I'm concerned, much of the hardware is a black box to
> me.

The 4430SDP's backlight hasn't been working in the mainline due to
missing support from the TWL driver. But we finally did get that in for
3.10 (or maybe 3.9), and booting 3.10 non-DT kernel brings up the
backlights. However, the BL doesn't work yet with DT boot, so again with
3.11, with no board files, the BL is out... Sigh.

The panel driver itself have been working as long as it has been in the
mainline kernel (for me). I think there was a mixup at some point with
pinmuxing due to TRM having wrong information, but for some reason my
board works fine with both right and wrong muxing. If I recall right,
your board did not. But that's also solved some kernel versions ago.

But even with the above fixed, you could observe that your panel doesn't
work. The reason is that the panels in the 4430SDP board were chosen a
bit oddly: they are so called manual update panels, meant to be
explicitly updated by the software only when required. The phones that
have such panels (which, I guess, is what 4430SDP is designed to
resemble) have software doing that, but obviously the standard linux
software does not.

There's a hack to enable a non-optimal automatic update for testing
purposes:

echo 1 > /sys/class/graphics/fb0/update_mode

This makes omapfb update the display 20 times per second. Or via a
module parameter: omapfb.auto_update=y

We could implement a better auto-update system for manual-update panels,
but I have opted not to:

- It's not easy to implement efficiently and reliably (in fact, we did
have auto-update support at some point in the kernel, but it was removed
as it was rather troublesome to keep working).

- Manual-update panels are meant to be updated manually, only when
needed. That's the whole point of the manual-update feature. Doing
auto-update with a manual-update panel is inefficient. So such a feature
would only be useful for testing purposes.

- Manual-update panels are quite rare, and the trend to use them seems
to be coming even rarer.

> And yes, my 4430 has the projector module on it.  Never ever seen that
> work, and no idea how to make it work because there's no information
> available on the hardware.

I don't have that one. PicoDLP shares resources (DSS pins, at least, if
I recall right, and some power line) with the second LCD, and we don't
have support to manage sharing those resources. So the PicoDLP is left
disabled in the board file.

I don't have any clear idea how to implement management of those
resources, and no one has ever asked about PicoDLP from me, so it's
never been a very high priority.

So 4430SDP is a bit difficult on the display side: non-standard panels
and a pico projector that is mutually exclusive with the LCD2.

> And no, I don't want another Beagle board or Panda board or whatever, I
> have those (I think I have one of each), and they've never been powered up
> because they have no ethernet on them, and I have no USB to ethernet still,
> partly because I don't really do USB here *at* *all*, so I don't know what
> works well and what doesn't with Linux.  Even if I did provide them with a
> USB ethernet, I doubt they'd be able to boot a kernel via the network.

Beagle xM and Panda have ethernet. I boot Panda via the network (load
kernel and use nfsroot). But they don't have panels, so you need an
external display for those.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130725/b7d54168/attachment.sig>

OMAP2430 SDP boot broken after Linus' rmk merge

[Tomi Valkeinen]

On 25/07/13 09:40, Tomi Valkeinen wrote:
> On 24/07/13 17:52, Russell King - ARM Linux wrote:
> 
>> I also continue to be disappointed by the lack of things working on the
>> 4430 - it's been a number of years now and _still_ the on-board LCDs do
>> not work.  People have tried to blame that on hardware faults and the
>> like, but they're just being idiotic when they say stuff like that.  It
>> can't be hardware faults when the kernel supplied with the board is able
>> to make them work to the extent that userspace can play back video on all
>> three output devices simultaneously, without hiccup or any imperfection.
>> I don't know whether it's just that the backlight support isn't working
>> or what - because any information on the 4430 seems to be a tightly
>> controlled secret that only a few select people are permitted to know
>> about.  As far as I'm concerned, much of the hardware is a black box to
>> me.
> 
> The 4430SDP's backlight hasn't been working in the mainline due to
> missing support from the TWL driver. But we finally did get that in for
> 3.10 (or maybe 3.9), and booting 3.10 non-DT kernel brings up the
> backlights. However, the BL doesn't work yet with DT boot, so again with
> 3.11, with no board files, the BL is out... Sigh.

Ah, sorry, I take that back. Backlight seems to be working fine with 3.11.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130725/de5e0ef5/attachment.sig>

OMAP2430 SDP boot broken after Linus' rmk merge

[Russell King - ARM Linux]

Having worked out how to get around the MMC ordering issue without having
to go and re-tweak it should it change again in the future, I've added
the SDP back into the build.

On Thu, Jul 25, 2013 at 09:50:13AM +0300, Tomi Valkeinen wrote:
> On 25/07/13 09:40, Tomi Valkeinen wrote:
> > On 24/07/13 17:52, Russell King - ARM Linux wrote:
> > 
> >> I also continue to be disappointed by the lack of things working on the
> >> 4430 - it's been a number of years now and _still_ the on-board LCDs do
> >> not work.  People have tried to blame that on hardware faults and the
> >> like, but they're just being idiotic when they say stuff like that.  It
> >> can't be hardware faults when the kernel supplied with the board is able
> >> to make them work to the extent that userspace can play back video on all
> >> three output devices simultaneously, without hiccup or any imperfection.
> >> I don't know whether it's just that the backlight support isn't working
> >> or what - because any information on the 4430 seems to be a tightly
> >> controlled secret that only a few select people are permitted to know
> >> about.  As far as I'm concerned, much of the hardware is a black box to
> >> me.
> > 
> > The 4430SDP's backlight hasn't been working in the mainline due to
> > missing support from the TWL driver. But we finally did get that in for
> > 3.10 (or maybe 3.9), and booting 3.10 non-DT kernel brings up the
> > backlights. However, the BL doesn't work yet with DT boot, so again with
> > 3.11, with no board files, the BL is out... Sigh.
> 
> Ah, sorry, I take that back. Backlight seems to be working fine with 3.11.

... if you know how to configure stuff so it works.  It seems that the
reason it hasn't been working, and the displays have been remaining
blank is because I had no idea that CONFIG_PWM and CONFIG_PWM_TWL were
required.  I've now added those to the config seed, so hopefully they
should start working now.  Only taken... what... two years to find that
out!

OMAP2430 SDP boot broken after Linus' rmk merge

[Paul Walmsley]

Hi Rajendra,

On Tue, 23 Jul 2013, Rajendra Nayak wrote:

> So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see
> the below errors. (I am using the mainline bootloaders which do not lock any
> additional DPLLs like USB)

Could you please send patches to fix these problems, or ensure that 
someone else from TI fixes them?  Let's see if we can deal with the 
remaining bootloader dependencies here.

thanks


- Paul

> 
> [    0.000000] clock: dpll_usb_ck failed transition to 'locked'
> [    0.000000] Division by zero in kernel.
> [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
> [    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
> [    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
> [    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
> [    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
> [    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
> [    0.000000] Division by zero in kernel.
> [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
> [    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
> [    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
> [    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
> [    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
> [    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
> [    0.000000] Division by zero in kernel.
> [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
> [    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
> [    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
> [    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
> [    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
> [    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
> [    0.000000] Division by zero in kernel.
> [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
> [    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
> [    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
> [    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
> [    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
> [    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
> [    0.000000] Division by zero in kernel.
> [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
> [    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
> [    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
> [    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
> [    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
> [    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
> [    0.000000] Division by zero in kernel.
> [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
> [    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
> [    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
> [    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
> [    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
> [    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
> [    0.000000] clock: trace_clk_div_ck: could not find divisor for target rate 0 for parent pmd_trace_clk_mux_ck
> [    0.000000] Division by zero in kernel.
> [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
> [    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
> [    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
> [    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
> [    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
> [    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
> [    0.000000] Division by zero in kernel.
> [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
> [    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
> [    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
> [    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
> [    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
> [    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
> [    0.000000] clock: dpll_per_m7x2_ck: could not find divisor for target rate 0 for parent dpll_per_x2_ck
> [    0.000000] clock: dpll_per_m6x2_ck: could not find divisor for target rate 0 for parent dpll_per_x2_ck
> [    0.000000] clock: dpll_per_m5x2_ck: could not find divisor for target rate 0 for parent dpll_per_x2_ck
> [    0.000000] clock: dpll_per_m4x2_ck: could not find divisor for target rate 0 for parent dpll_per_x2_ck
> 
> > 
> > 
> > - Paul
> > 
> 


- Paul

OMAP2430 SDP boot broken after Linus' rmk merge

[Rajendra Nayak]

On Wednesday 07 August 2013 11:39 PM, Paul Walmsley wrote:
> Hi Rajendra,
> 
> On Tue, 23 Jul 2013, Rajendra Nayak wrote:
> 
>> So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see
>> the below errors. (I am using the mainline bootloaders which do not lock any
>> additional DPLLs like USB)
> 
> Could you please send patches to fix these problems, or ensure that 
> someone else from TI fixes them?  Let's see if we can deal with the 
> remaining bootloader dependencies here.

Sure Paul, I'll take a look at this.

> 
> thanks
> 
> 
> - Paul
> 
>>
>> [    0.000000] clock: dpll_usb_ck failed transition to 'locked'
>> [    0.000000] Division by zero in kernel.
>> [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
>> [    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
>> [    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
>> [    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
>> [    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
>> [    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
>> [    0.000000] Division by zero in kernel.
>> [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
>> [    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
>> [    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
>> [    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
>> [    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
>> [    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
>> [    0.000000] Division by zero in kernel.
>> [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
>> [    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
>> [    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
>> [    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
>> [    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
>> [    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
>> [    0.000000] Division by zero in kernel.
>> [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
>> [    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
>> [    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
>> [    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
>> [    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
>> [    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
>> [    0.000000] Division by zero in kernel.
>> [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
>> [    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
>> [    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
>> [    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
>> [    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
>> [    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
>> [    0.000000] Division by zero in kernel.
>> [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
>> [    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
>> [    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
>> [    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
>> [    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
>> [    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
>> [    0.000000] clock: trace_clk_div_ck: could not find divisor for target rate 0 for parent pmd_trace_clk_mux_ck
>> [    0.000000] Division by zero in kernel.
>> [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
>> [    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
>> [    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
>> [    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
>> [    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
>> [    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
>> [    0.000000] Division by zero in kernel.
>> [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
>> [    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
>> [    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
>> [    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
>> [    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
>> [    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
>> [    0.000000] clock: dpll_per_m7x2_ck: could not find divisor for target rate 0 for parent dpll_per_x2_ck
>> [    0.000000] clock: dpll_per_m6x2_ck: could not find divisor for target rate 0 for parent dpll_per_x2_ck
>> [    0.000000] clock: dpll_per_m5x2_ck: could not find divisor for target rate 0 for parent dpll_per_x2_ck
>> [    0.000000] clock: dpll_per_m4x2_ck: could not find divisor for target rate 0 for parent dpll_per_x2_ck
>>
>>>
>>>
>>> - Paul
>>>
>>
> 
> 
> - Paul
> 

OMAP2430 SDP boot broken after Linus' rmk merge

[Rajendra Nayak]

On Thursday 08 August 2013 11:07 AM, Rajendra Nayak wrote:
> On Wednesday 07 August 2013 11:39 PM, Paul Walmsley wrote:
>> Hi Rajendra,
>>
>> On Tue, 23 Jul 2013, Rajendra Nayak wrote:
>>
>>> So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see
>>> the below errors. (I am using the mainline bootloaders which do not lock any
>>> additional DPLLs like USB)
>>
>> Could you please send patches to fix these problems, or ensure that 
>> someone else from TI fixes them?  Let's see if we can deal with the 
>> remaining bootloader dependencies here.
> 
> Sure Paul, I'll take a look at this.

+Mike,

Paul, I just posted a fix for this [1] though I am not sure if doing the
PLL locks in a certain sequence is the right thing to do, or perhaps there
is a need to relook at the need for a clk_set_rate() on all downstream clocks
as part of CCF.

regards,
Rajendra

[1] http://www.mail-archive.com/linux-omap at vger.kernel.org/msg93627.html

> 
>>
>> thanks
>>
>>
>> - Paul
>>
>>>
>>> [    0.000000] clock: dpll_usb_ck failed transition to 'locked'
>>> [    0.000000] Division by zero in kernel.
>>> [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
>>> [    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
>>> [    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
>>> [    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
>>> [    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
>>> [    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
>>> [    0.000000] Division by zero in kernel.
>>> [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
>>> [    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
>>> [    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
>>> [    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
>>> [    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
>>> [    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
>>> [    0.000000] Division by zero in kernel.
>>> [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
>>> [    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
>>> [    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
>>> [    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
>>> [    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
>>> [    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
>>> [    0.000000] Division by zero in kernel.
>>> [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
>>> [    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
>>> [    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
>>> [    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
>>> [    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
>>> [    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
>>> [    0.000000] Division by zero in kernel.
>>> [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
>>> [    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
>>> [    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
>>> [    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
>>> [    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
>>> [    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
>>> [    0.000000] Division by zero in kernel.
>>> [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
>>> [    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
>>> [    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
>>> [    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
>>> [    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
>>> [    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
>>> [    0.000000] clock: trace_clk_div_ck: could not find divisor for target rate 0 for parent pmd_trace_clk_mux_ck
>>> [    0.000000] Division by zero in kernel.
>>> [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
>>> [    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
>>> [    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
>>> [    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
>>> [    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
>>> [    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
>>> [    0.000000] Division by zero in kernel.
>>> [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
>>> [    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
>>> [    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
>>> [    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
>>> [    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
>>> [    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
>>> [    0.000000] clock: dpll_per_m7x2_ck: could not find divisor for target rate 0 for parent dpll_per_x2_ck
>>> [    0.000000] clock: dpll_per_m6x2_ck: could not find divisor for target rate 0 for parent dpll_per_x2_ck
>>> [    0.000000] clock: dpll_per_m5x2_ck: could not find divisor for target rate 0 for parent dpll_per_x2_ck
>>> [    0.000000] clock: dpll_per_m4x2_ck: could not find divisor for target rate 0 for parent dpll_per_x2_ck
>>>
>>>>
>>>>
>>>> - Paul
>>>>
>>>
>>
>>
>> - Paul
>>
> 

OMAP2430 SDP boot broken after Linus' rmk merge

[Jonathan Austin]

Hi Paul,

On 22/07/13 19:07, Paul Walmsley wrote:
>
> Hi,
>
> After Linus's commit fb2af0020a51709ad87ea8055c325d3fbde04158 ("Merge
> branch 'for-linus' of git://git.linaro.org/people/rmk/linux-arm"), the
> OMAP2430 SDP here stopped booting.
>
> Here's the bootlog at the commit before the merge, commit 790eac5640:
>
> http://www.pwsan.com/omap/testlogs/bisect_2430sdp_hang_v3.11-rc/20130722015454/
>
> and here's a log at commit fb2af0020a5:
>
> http://www.pwsan.com/omap/testlogs/bisect_2430sdp_hang_v3.11-rc/20130722005921/
>
> Any ideas as to what might have caused this?
>

I've just had a quick go at booting 3.11-rc2 on an integrator-cp (1136) 
in the hope that we might be able to reproduce this on those boards, but 
I'm afraid the integrator works...

I took your config, modified it as little as possible to switch to 
Integrator and turn on earlyprintk, and then tried to boot. That *did* 
require switching away from ARCH_MULTIPLATFORM, so it isn't as similar 
as I'd like, though...

So I think we can at least say that this is not 1136 specific... Sorry 
not to be more helpful...

Jonny

OMAP2430 SDP boot broken after Linus' rmk merge

[Paul Walmsley]

On Tue, 23 Jul 2013, Jonathan Austin wrote:

> I've just had a quick go at booting 3.11-rc2 on an integrator-cp (1136) in the
> hope that we might be able to reproduce this on those boards, but I'm afraid
> the integrator works...
> 
> I took your config, modified it as little as possible to switch to Integrator
> and turn on earlyprintk, and then tried to boot. That *did* require switching
> away from ARCH_MULTIPLATFORM, so it isn't as similar as I'd like, though...
> 
> So I think we can at least say that this is not 1136 specific... Sorry not to
> be more helpful...

Just saw this message - thanks for the test.  What 1136 variant does the 
Integrator-CP have in it?  Would assume an r1 or later?


- Paul