Subject: OMAP2430 SDP boot broken after Linus' rmk merge

From: [email-masked] (Santosh Shilimkar)
Date: Wed, 24 Jul 2013 10:17:01 -0400

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