* [U-Boot] [PATCH] mx28: fix SPL code to make USB booting work
@ 2012-02-03 12:54 Matthias Fuchs
2012-02-03 13:22 ` Marek Vasut
0 siblings, 1 reply; 5+ messages in thread
From: Matthias Fuchs @ 2012-02-03 12:54 UTC (permalink / raw)
To: u-boot
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
+
+#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
+
pop {r0-r12,r14}
bx lr
--
1.6.1
^ permalink raw reply related [flat|nested] 5+ messages in thread
* [U-Boot] [PATCH] mx28: fix SPL code to make USB booting work
2012-02-03 12:54 [U-Boot] [PATCH] mx28: fix SPL code to make USB booting work Matthias Fuchs
@ 2012-02-03 13:22 ` Marek Vasut
2012-02-03 14:23 ` Matthias Fuchs
0 siblings, 1 reply; 5+ messages in thread
From: Marek Vasut @ 2012-02-03 13:22 UTC (permalink / raw)
To: u-boot
> 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?
> +
> +#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
^ permalink raw reply [flat|nested] 5+ messages in thread
* [U-Boot] [PATCH] mx28: fix SPL code to make USB booting work
2012-02-03 13:22 ` Marek Vasut
@ 2012-02-03 14:23 ` Matthias Fuchs
2012-02-03 14:31 ` Marek Vasut
0 siblings, 1 reply; 5+ messages in thread
From: Matthias Fuchs @ 2012-02-03 14:23 UTC (permalink / raw)
To: u-boot
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.
>
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* [U-Boot] [PATCH] mx28: fix SPL code to make USB booting work
2012-02-03 14:23 ` Matthias Fuchs
@ 2012-02-03 14:31 ` Marek Vasut
2012-02-04 14:16 ` Marek Vasut
0 siblings, 1 reply; 5+ messages in thread
From: Marek Vasut @ 2012-02-03 14:31 UTC (permalink / raw)
To: u-boot
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* [U-Boot] [PATCH] mx28: fix SPL code to make USB booting work
2012-02-03 14:31 ` Marek Vasut
@ 2012-02-04 14:16 ` Marek Vasut
0 siblings, 0 replies; 5+ messages in thread
From: Marek Vasut @ 2012-02-04 14:16 UTC (permalink / raw)
To: u-boot
> > 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.
Actually ... maybe we can store CPSR to some other register (say ... r10?) and
restore it before passing control back to bootrom. That might be the safest way
and I think that'd be even better solution.
M
>
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-02-04 14:16 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-02-03 12:54 [U-Boot] [PATCH] mx28: fix SPL code to make USB booting work Matthias Fuchs
2012-02-03 13:22 ` Marek Vasut
2012-02-03 14:23 ` Matthias Fuchs
2012-02-03 14:31 ` Marek Vasut
2012-02-04 14:16 ` Marek Vasut
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox