From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Fri, 3 Feb 2012 14:22:43 +0100 Subject: [U-Boot] [PATCH] mx28: fix SPL code to make USB booting work In-Reply-To: <4F2BD8F4.2020105@esd.eu> References: <4F2BD8F4.2020105@esd.eu> Message-ID: <201202031422.43409.marek.vasut@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de > 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 > --- > 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? > + > +#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). 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?) and enable high- vectors just before passing control back to bootrom only then? Though now that I think of it, high-vectors should probably be unconditionally re-enabled upon entering bootrom. Can you investigate? > + > pop {r0-r12,r14} > bx lr