[U-Boot] [PATCH] mx28: fix SPL code to make USB booting work

[Marek Vasut <marek.vasut@gmail.com>]

> On 03.02.2012 14:22, Marek Vasut wrote:
> >> This patch fixes booting i.MX28 CPUs via USB download.
> >> In this mode the CPU's bootrom implements a USB HID device that
> >> accepts a bootstream.
> >> 
> >> When downloading the bootstream via USB, first the SPL code is
> >> received and executed. Then the u-boot image is received and
> >> called.
> >> 
> >> The USB bootmode is interrupt driven.
> >> 
> >> This patch fixes two things:
> >> 
> >> 1) The ARM's fast interrupt mode is disabled when the SPL code
> >> has been run. This is the default state when called by the bootrom.
> >> 
> >> 2) The exception vector location is set back to bootrom space to
> >> make the USB interrupts work again. The SPL code needs to change this
> >> option for the ram size probing.
> >> 
> >> Signed-off-by: Matthias Fuchs <matthias.fuchs@esd.eu>
> >> ---
> >> 
> >>  arch/arm/cpu/arm926ejs/mx28/start.S |   17 +++++++++++++++++
> >>  1 files changed, 17 insertions(+), 0 deletions(-)
> >> 
> >> diff --git a/arch/arm/cpu/arm926ejs/mx28/start.S
> >> b/arch/arm/cpu/arm926ejs/mx28/start.S index 2cd4d73..4116bb1 100644
> >> --- a/arch/arm/cpu/arm926ejs/mx28/start.S
> >> +++ b/arch/arm/cpu/arm926ejs/mx28/start.S
> >> 
> >> @@ -185,6 +185,23 @@ _reset:
> >>  	bl	board_init_ll
> >> 
> >> +	/*
> >> +	 * turn of fast interrupt mode (required by bootrom for USB boot)
> >> +	 */
> >> +	mrs	r0,cpsr
> >> +	bic	r0,r0,#0x80
> >> +	msr	cpsr,r0
> > 
> > Add this section just past _reset into:
> > 
> > 170         /*
> > 171          * set the cpu to SVC32 mode
> > 172          */
> > 173         mrs     r0,cpsr
> > 174         bic     r0,r0,#0x1f
> > 175         orr     r0,r0,#0xd3
> > 176         msr     cpsr,r0
> > 
> > And only if you really need this. Why do you need to disable FIQ?
> 
> First: my commit message was not very clear in ths concern.
> When the SPL is called from the bootrom FIQ is turned off. When the SPL
> has run and control is passed back to the bootrom (!), the bootrom
> crashes, stalls or stops when FIQ is on. So we need to turn FIQ
> off when the SPL has done it's job. So that's why I added the code after
> board_init_ll(). I also noticed that the SPL runs fine when FIQ is never
> turned on. So I could think of never turning it on at all in SPL:
> 170         /*
> 171          * set the cpu to SVC32 mode
> 172          */
> 173         mrs     r0,cpsr
> 174         bic     r0,r0,#0x1f
> - 175         orr     r0,r0,#0xd3
> + 175         orr     r0,r0,#0x53
> 176         msr     cpsr,r0
> 
> This will result in CPSR = 0x53 which is the register content when
> the SPL is called (setup by bootrom). So we could completely get rid of
> this sequence.
> 
> And yes, for USB boot the FIQ must be turned off when SPL has done it's
> work. Other boot modes do not care as far as I noticed.
> 
> >> +
> >> +#ifndef CONFIG_SKIP_LOWLEVEL_INIT
> >> +	/*
> >> +	 * set exception vector location back to bootrom space.
> >> +	 * (required by bootrom for USB boot)
> >> +	 */
> >> +	mrc	p15, 0, r0, c1, c0, 0
> >> +	orr	r0, r0, #0x00002000	/* set bit 13 'V' */
> >> +	mcr	p15, 0, r0, c1, c0, 0
> >> +#endif
> > 
> > High-vectors break the current implementation. That IS WRONG. The RAM
> > memory detection routine will not work if you enable high vectors since
> > it depends on adjusting the jumptable at 0x0 (aka. low vectors).
> 
> Right. That's why the SPL code clears the 'V' bit and we got 'low
> vectors'. But when the SPL code has done it's work we need to return to
> 'high vectors' (... in bootrom space) to keep USB from bootrom alive.
> That's what my patch does. SPL run with low vectors and before it
> returns to bootrom it switches back to high vectors.
> 
> > Why do you need to enable high vectors? Can't you detect that USB boot is
> > happening (can mx28 report boot reason like mxc chips do?)
> 
> Yes, by checking some GPIOs (I send an RFC/PATCH some days ago). But
> there's no need to only do this when using USB boot.
> 
> > and enable high-
> > vectors just before passing control back to bootrom only then?
> 
> That's what I do! Please take a look at my patch.

I just noticed where you put it. OK. Why that CONFIG_SKIP_LOWLEVEL_INIT there 
anyway?

And about FIQ, do it like you outlined it, disable it altogether and be done 
with it.

M
> 
> > Though now that I think of it, high-vectors should probably be
> > unconditionally re-enabled upon entering bootrom. Can you investigate?
> 
> That's what my patch does!
> 
> 
> Matthias