From mboxrd@z Thu Jan  1 00:00:00 1970
From: Helmut Raiger <helmut.raiger@hale.at>
Date: Tue, 08 Jul 2014 14:32:20 +0200
Subject: [U-Boot] SPL broken on i.mx31 platforms
In-Reply-To: <53BBA64A.70309@hale.at>
References: <53B2B8B8.7010406@hale.at>	<CAOMZO5A-BDSXjOZFjs=fouLqb7wLcGAEHWyrX8+_F08rZC5dFA@mail.gmail.com>	<E1X2400-00078B-Qy@janus>
	<53B3AF0E.1010105@hale.at>	<CA+sos7_csPisqFUCf14S6fZpZ_uM=CJ-rLy2tbEL-p_-HzzWdw@mail.gmail.com>	<53B5121B.809@hale.at>	<CA+sos7-Pn76+B=F9AmDux95z09R4VJCObMKtL+mzxFEEbBBuuw@mail.gmail.com>
	<53BBA64A.70309@hale.at>
Message-ID: <53BBE4D4.3060007@hale.at>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On 07/08/2014 10:05 AM, Helmut Raiger wrote:
>
> I meant, that the SPL is now doing the RAM init and copying of the SPL 
> code
> correctly. RAM is working, the SPL code is at 0x87dc0000 after that 
> (CRCed it via JTAG).
> I could not track it further (I have very limited development time 
> right now ... repeating myself).
>
> After all I need to debug further. If someone could test the current 
> state on the
> mx31pdk, this still would be great. Just to rule out any other board 
> specific issues.
>
> Helmut

Ok, I've got some new input and I have no clue what's going on.

1) I fixed the first branch to reset (uses b reset instead of ldr pc, 
_reset)
2) The startup does:

   b reset
...

reset:
     - set the cpu to SVC32 mode
     - bl  cpu_init_crit (cache and MMU stuff, calls low_level_init)
     - bl _main

low_level_init:
    unlike in mx31pdk this only does:

     ldr    r0, =ARM_PPMRR      /* start from AIPS 2GB region */
     mcr    p15, 0, r0, c15, c2, 4
     mov    pc, lr

_main:
     - set up stack pointer to internal SRAM
     - bl board_init_f

As I can't break right after reset with peedi, I do:

   - reset stop
   - set pc 0xb8000000
   - go -> system never returns

next:
    reset stop
    - set pc 0xb8000000
    - break add hard 0xb80000c8        // set hardware breakpoint to the 
'bl board_init_f' instruction
    - go
     ... it stops at the breakpoint
    - go
     ... I'm at the u-boot command prompt

If I set the breakpoint somewhere after the bl board_init_f it fails, if 
I break a few instructions
early and go from there it also fails. Tracking down the location 
in-between I end up at:

at the end of cpu_init_crit():

     mov    ip, lr        /* persevere link reg across call */
     bl    lowlevel_init    /* go setup pll,mux,memory */
->    mov    lr, ip        /* restore link */
     mov    pc, lr        /* back to my caller */

That is, if I set the breakpoint to mov lr, ip it works, if I set it one 
instruction later it ends working.

Could be struggling with the debugger here, as the SPL probably ran a 
few instruction before it
was stopped. Might this be a cache issue? But it is invalidated in 
cpu_init_crit() anyway ...

Feeling a little dumbstruck right now ...

Sorry for the mess, but it's hard to describe.

Any ideas?
Helmut


--
Scanned by MailScanner.