Re: 4430SDP boot failure

[Tony Lindgren <tony@atomide.com>]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110106 12:32]:
> On Thu, Jan 06, 2011 at 10:20:23AM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [110106 10:00]:
> > > can't be in the BSS section?
> > 
> > BSS works too, got a patch for that?
> 
> Yes.
> 
> sed -i '/\.pushsection \.data/,/\.popsection/ {
> 	s/\.data/.bss/;
> 	s/.word\t0/.space\t4/;
> }' arch/arm/mach-omap2/include/mach/debug-macro.S

That does not work as BSS gets cleared in head-common.S.. See my other patch.
 
> > Can you please check if you have some older bootloader that passes
> > some wrong machine ID? 
> 
> If previous kernels didn't explicitly force the SDP4430 platform ID
> number (which they didn't for OMAP back to 2007), then it must be
> correct as previous kernels booted fine when only configured for
> the SDP4430.
> 
> It must also be correct as the decompressor can select the correct port
> for outputting the "Decompressing kernel..." message.
> 
> So by implication I think we can say that the ID number is correct.

OK thanks.
 
> I've just tried forcing it to use OMAP4 UART3, which seems to be what
> the decompressor is using for its output:
> 
> 0000090c <puts>:
>      90c:       e3a03802        mov     r3, #131072     ; 0x20000
>      910:       e38314fa        orr     r1, r3, #-100663296     ; 0xfa000000
>      914:       e3833312        orr     r3, r3, #1207959552     ; 0x48000000
>      918:       e4d02001        ldrb    r2, [r0], #1
>      91c:       e3320000        teq     r2, #0  ; 0x0
>      920:       01a0f00e        moveq   pc, lr
>      924:       e5c32000        strb    r2, [r3]
>      928:       e3a01802        mov     r1, #131072     ; 0x20000
>      92c:       e2511001        subs    r1, r1, #1      ; 0x1
>      930:       1afffffd        bne     92c <puts+0x20>
>      934:       e332000a        teq     r2, #10 ; 0xa
>      938:       03a0200d        moveq   r2, #13 ; 0xd
>      93c:       0afffff8        beq     924 <puts+0x18>
>      940:       e3300000        teq     r0, #0  ; 0x0
>      944:       1afffff3        bne     918 <puts+0xc>
>      948:       e1a0f00e        mov     pc, lr
> 
> 0x48020000 is the only UART address contained within the disassembly for
> the decompressor to use, so that must be the correct address.
> 
> However, even with that, it causes the 'X-Loader hangs' before producing
> any output.  No idea what to try next - and it's soo much hastle to keep
> moving SD cards around - which the laptop sometimes doesn't recognise -
> just to try new kernels that I'm wasting quite a bit of effort on each
> iteration it's untrue.
> 
> As I said previously, I think someone else can look into this - someone
> who understands the hardware quirks of OMAP, who has a decent test setup,
> and has the tools necessary to do hardware debug on OMAP.

I think I got it fixed, see the other patch I just posted.
 
> (If it could do dhcp/tftp - and be configured to do that from powerup
> without interruption, then I might feel differently as that would
> significantly reduce the hastle factor and amount of time involved with
> testing each iteration.)

Yes these new boards badly need the Ethernet working in u-boot..

Anyways, I can debug the DEBUG_LL booting issue further if the patch
I posted does not help.

Regards,

Tony