> 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.fu...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
