* [U-Boot] [PATCH] arm: fix exception vectors @ 2014-12-29 15:10 Luca Ellero 2015-01-17 6:40 ` Albert ARIBAUD 0 siblings, 1 reply; 7+ messages in thread From: Luca Ellero @ 2014-12-29 15:10 UTC (permalink / raw) To: u-boot After relocation, exception vectors still point to the old code (not relocated). This patch fixes them. Signed-off-by: Luca Ellero <luca.ellero@brickedbrain.com> --- arch/arm/lib/relocate.S | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S index 92f5314..4186344 100644 --- a/arch/arm/lib/relocate.S +++ b/arch/arm/lib/relocate.S @@ -76,6 +76,21 @@ copy_loop: blo copy_loop /* + * fix exception vectors + */ + ldr r2, =_undefined_instruction + ldr r3, =_fiq + add r2, r2, r4 + add r3, r3, r4 +fix_exceptions: + ldr r0, [r2] + add r0, r0, r4 + str r0, [r2] + cmp r2,r3 + add r2, #4 + blo fix_exceptions + + /* * fix .rel.dyn relocations */ ldr r2, =__rel_dyn_start /* r2 <- SRC &__rel_dyn_start */ -- 1.7.10.4 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* [U-Boot] [PATCH] arm: fix exception vectors 2014-12-29 15:10 [U-Boot] [PATCH] arm: fix exception vectors Luca Ellero @ 2015-01-17 6:40 ` Albert ARIBAUD 2015-01-19 10:11 ` Luca Ellero 0 siblings, 1 reply; 7+ messages in thread From: Albert ARIBAUD @ 2015-01-17 6:40 UTC (permalink / raw) To: u-boot Hello Luca, On Mon, 29 Dec 2014 16:10:53 +0100, Luca Ellero <luca.ellero@brickedbrain.com> wrote: > After relocation, exception vectors still point to the old code (not relocated). > This patch fixes them. > > Signed-off-by: Luca Ellero <luca.ellero@brickedbrain.com> > --- > arch/arm/lib/relocate.S | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > > diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S > index 92f5314..4186344 100644 > --- a/arch/arm/lib/relocate.S > +++ b/arch/arm/lib/relocate.S > @@ -76,6 +76,21 @@ copy_loop: > blo copy_loop > > /* > + * fix exception vectors > + */ > + ldr r2, =_undefined_instruction > + ldr r3, =_fiq > + add r2, r2, r4 > + add r3, r3, r4 > +fix_exceptions: > + ldr r0, [r2] > + add r0, r0, r4 > + str r0, [r2] > + cmp r2,r3 > + add r2, #4 > + blo fix_exceptions > + > + /* > * fix .rel.dyn relocations > */ > ldr r2, =__rel_dyn_start /* r2 <- SRC &__rel_dyn_start */ > -- > 1.7.10.4 > There is already a mechanism to relocate vectors (do a git grep for 'relocate_vectors' which takes into account various ISA and SoC cases. Can you describe the use case which you are encountering? Amicalement, -- Albert. ^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] [PATCH] arm: fix exception vectors 2015-01-17 6:40 ` Albert ARIBAUD @ 2015-01-19 10:11 ` Luca Ellero 2015-01-19 10:28 ` Albert ARIBAUD 0 siblings, 1 reply; 7+ messages in thread From: Luca Ellero @ 2015-01-19 10:11 UTC (permalink / raw) To: u-boot Hi Albert, On 17/01/2015 07:40, Albert ARIBAUD wrote: > Hello Luca, > > On Mon, 29 Dec 2014 16:10:53 +0100, Luca Ellero > <luca.ellero@brickedbrain.com> wrote: >> After relocation, exception vectors still point to the old code (not relocated). >> This patch fixes them. >> >> Signed-off-by: Luca Ellero <luca.ellero@brickedbrain.com> >> --- >> arch/arm/lib/relocate.S | 15 +++++++++++++++ >> 1 file changed, 15 insertions(+) >> >> diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S >> index 92f5314..4186344 100644 >> --- a/arch/arm/lib/relocate.S >> +++ b/arch/arm/lib/relocate.S >> @@ -76,6 +76,21 @@ copy_loop: >> blo copy_loop >> >> /* >> + * fix exception vectors >> + */ >> + ldr r2, =_undefined_instruction >> + ldr r3, =_fiq >> + add r2, r2, r4 >> + add r3, r3, r4 >> +fix_exceptions: >> + ldr r0, [r2] >> + add r0, r0, r4 >> + str r0, [r2] >> + cmp r2,r3 >> + add r2, #4 >> + blo fix_exceptions >> + >> + /* >> * fix .rel.dyn relocations >> */ >> ldr r2, =__rel_dyn_start /* r2 <- SRC &__rel_dyn_start */ >> -- >> 1.7.10.4 >> > > There is already a mechanism to relocate vectors (do a git grep for > 'relocate_vectors' which takes into account various ISA and SoC cases. > > Can you describe the use case which you are encountering? As far as I can see the mechanism to relocate vectors is implemented only on iMX25/27 and involves high vectors address (0xFFFFxxxx). The problem is that, after relocation, U-Boot doesn't fix the vector table addresses, they still point to the old addresses (before relocation). This is wrong and this patch fixes them to point to the new addresses. I had to use this patch trying to implement IRQ support for a Freescale iMX6 board. iMX6 does not provide RAM at the high vectors address and trying to access them leads to errors, so I couldn't use them. Regards -- Luca Ellero E-mail: luca.ellero at brickedbrain.com Internet: www.brickedbrain.com ^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] [PATCH] arm: fix exception vectors 2015-01-19 10:11 ` Luca Ellero @ 2015-01-19 10:28 ` Albert ARIBAUD 2015-01-19 15:28 ` Luca Ellero 2015-01-19 15:40 ` Bill Pringlemeir 0 siblings, 2 replies; 7+ messages in thread From: Albert ARIBAUD @ 2015-01-19 10:28 UTC (permalink / raw) To: u-boot Hello Luca, On Mon, 19 Jan 2015 11:11:34 +0100, Luca Ellero <luca.ellero@brickedbrain.com> wrote: > Hi Albert, > > On 17/01/2015 07:40, Albert ARIBAUD wrote: > > Hello Luca, > > > > On Mon, 29 Dec 2014 16:10:53 +0100, Luca Ellero > > <luca.ellero@brickedbrain.com> wrote: > >> After relocation, exception vectors still point to the old code (not relocated). > >> This patch fixes them. > >> > >> Signed-off-by: Luca Ellero <luca.ellero@brickedbrain.com> > >> --- > >> arch/arm/lib/relocate.S | 15 +++++++++++++++ > >> 1 file changed, 15 insertions(+) > >> > >> diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S > >> index 92f5314..4186344 100644 > >> --- a/arch/arm/lib/relocate.S > >> +++ b/arch/arm/lib/relocate.S > >> @@ -76,6 +76,21 @@ copy_loop: > >> blo copy_loop > >> > >> /* > >> + * fix exception vectors > >> + */ > >> + ldr r2, =_undefined_instruction > >> + ldr r3, =_fiq > >> + add r2, r2, r4 > >> + add r3, r3, r4 > >> +fix_exceptions: > >> + ldr r0, [r2] > >> + add r0, r0, r4 > >> + str r0, [r2] > >> + cmp r2,r3 > >> + add r2, #4 > >> + blo fix_exceptions > >> + > >> + /* > >> * fix .rel.dyn relocations > >> */ > >> ldr r2, =__rel_dyn_start /* r2 <- SRC &__rel_dyn_start */ > >> -- > >> 1.7.10.4 > >> > > > > There is already a mechanism to relocate vectors (do a git grep for > > 'relocate_vectors' which takes into account various ISA and SoC cases. > > > > Can you describe the use case which you are encountering? > > As far as I can see the mechanism to relocate vectors is implemented > only on iMX25/27 and involves high vectors address (0xFFFFxxxx). You are correct that the mechanism is /used/ only by mx25 and mx27. However, it has been introduced to support /all/ SoCs (or even boards), not only mx25, mx27, and /all/ exception vector handling scenarios, not only high vectors addresses. Actually, the standard high and low address is handled by default, and mx25 and mx27 are cases where this default is overriden /because/ high or low vector addresses are *unapplicable* for them due to their memory mapping. > The problem is that, after relocation, U-Boot doesn't fix the vector > table addresses, they still point to the old addresses (before relocation). > This is wrong and this patch fixes them to point to the new addresses. You are right about the problem, and this problem is exactly what the relocate_vectors mechanism is here to fix -- exactly the same problem mx25 and mx27 had before we fixed it (quite recently actually, as it was done mid-November, between 2015.01-rc1 and 2015.01-rc1 rc2). > I had to use this patch trying to implement IRQ support for a Freescale > iMX6 board. iMX6 does not provide RAM at the high vectors address and > trying to access them leads to errors, so I couldn't use them. This is *exactly* the case where you should define your own version of relocate_vectors (probably at SoC level). > Regards > > -- > Luca Ellero Amicalement, -- Albert. ^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] [PATCH] arm: fix exception vectors 2015-01-19 10:28 ` Albert ARIBAUD @ 2015-01-19 15:28 ` Luca Ellero 2015-01-19 15:40 ` Bill Pringlemeir 1 sibling, 0 replies; 7+ messages in thread From: Luca Ellero @ 2015-01-19 15:28 UTC (permalink / raw) To: u-boot Hi Albert, On 19/01/2015 11:28, Albert ARIBAUD wrote: > Hello Luca, > > On Mon, 19 Jan 2015 11:11:34 +0100, Luca Ellero > <luca.ellero@brickedbrain.com> wrote: >> Hi Albert, >> >> On 17/01/2015 07:40, Albert ARIBAUD wrote: >>> Hello Luca, >>> >>> On Mon, 29 Dec 2014 16:10:53 +0100, Luca Ellero >>> <luca.ellero@brickedbrain.com> wrote: >>>> After relocation, exception vectors still point to the old code (not relocated). >>>> This patch fixes them. >>>> >>>> Signed-off-by: Luca Ellero <luca.ellero@brickedbrain.com> >>>> --- >>>> arch/arm/lib/relocate.S | 15 +++++++++++++++ >>>> 1 file changed, 15 insertions(+) >>>> >>>> diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S >>>> index 92f5314..4186344 100644 >>>> --- a/arch/arm/lib/relocate.S >>>> +++ b/arch/arm/lib/relocate.S >>>> @@ -76,6 +76,21 @@ copy_loop: >>>> blo copy_loop >>>> >>>> /* >>>> + * fix exception vectors >>>> + */ >>>> + ldr r2, =_undefined_instruction >>>> + ldr r3, =_fiq >>>> + add r2, r2, r4 >>>> + add r3, r3, r4 >>>> +fix_exceptions: >>>> + ldr r0, [r2] >>>> + add r0, r0, r4 >>>> + str r0, [r2] >>>> + cmp r2,r3 >>>> + add r2, #4 >>>> + blo fix_exceptions >>>> + >>>> + /* >>>> * fix .rel.dyn relocations >>>> */ >>>> ldr r2, =__rel_dyn_start /* r2 <- SRC &__rel_dyn_start */ >>>> -- >>>> 1.7.10.4 >>>> >>> >>> There is already a mechanism to relocate vectors (do a git grep for >>> 'relocate_vectors' which takes into account various ISA and SoC cases. >>> >>> Can you describe the use case which you are encountering? >> >> As far as I can see the mechanism to relocate vectors is implemented >> only on iMX25/27 and involves high vectors address (0xFFFFxxxx). > > You are correct that the mechanism is /used/ only by mx25 and mx27. > > However, it has been introduced to support /all/ SoCs (or even boards), > not only mx25, mx27, and /all/ exception vector handling scenarios, not > only high vectors addresses. > > Actually, the standard high and low address is handled by default, > and mx25 and mx27 are cases where this default is overriden /because/ > high or low vector addresses are *unapplicable* for them due to their > memory mapping. > >> The problem is that, after relocation, U-Boot doesn't fix the vector >> table addresses, they still point to the old addresses (before relocation). >> This is wrong and this patch fixes them to point to the new addresses. > > You are right about the problem, and this problem is exactly what the > relocate_vectors mechanism is here to fix -- exactly the same problem > mx25 and mx27 had before we fixed it (quite recently actually, as it > was done mid-November, between 2015.01-rc1 and 2015.01-rc1 rc2). > >> I had to use this patch trying to implement IRQ support for a Freescale >> iMX6 board. iMX6 does not provide RAM at the high vectors address and >> trying to access them leads to errors, so I couldn't use them. > > This is *exactly* the case where you should define your own version of > relocate_vectors (probably at SoC level). > Ok, I will try to implement it as you suggested. Thank you regards Luca -- Luca Ellero E-mail: luca.ellero at brickedbrain.com Internet: www.brickedbrain.com ^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] [PATCH] arm: fix exception vectors 2015-01-19 10:28 ` Albert ARIBAUD 2015-01-19 15:28 ` Luca Ellero @ 2015-01-19 15:40 ` Bill Pringlemeir 2015-01-20 6:55 ` Albert ARIBAUD 1 sibling, 1 reply; 7+ messages in thread From: Bill Pringlemeir @ 2015-01-19 15:40 UTC (permalink / raw) To: u-boot > On Mon, 19 Jan 2015 11:11:34 +0100, Luca Ellero >> As far as I can see the mechanism to relocate vectors is implemented >> only on iMX25/27 and involves high vectors address (0xFFFFxxxx). On 19 Jan 2015, albert.u.boot at aribaud.net wrote: > You are correct that the mechanism is /used/ only by mx25 and mx27. > However, it has been introduced to support /all/ SoCs (or even > boards), not only mx25, mx27, and /all/ exception vector handling > scenarios, not only high vectors addresses. > Actually, the standard high and low address is handled by default, > and mx25 and mx27 are cases where this default is overriden /because/ > high or low vector addresses are *unapplicable* for them due to their > memory mapping. > On Mon, 19 Jan 2015 11:11:34 +0100, Luca Ellero >> The problem is that, after relocation, U-Boot doesn't fix the vector >> table addresses, they still point to the old addresses (before >> relocation). This is wrong and this patch fixes them to point to the >> new addresses. On 19 Jan 2015, albert.u.boot at aribaud.net wrote: > You are right about the problem, and this problem is exactly what the > relocate_vectors mechanism is here to fix -- exactly the same problem > mx25 and mx27 had before we fixed it (quite recently actually, as it > was done mid-November, between 2015.01-rc1 and 2015.01-rc1 rc2). > On Mon, 19 Jan 2015 11:11:34 +0100, Luca Ellero >> I had to use this patch trying to implement IRQ support for a >> Freescale iMX6 board. iMX6 does not provide RAM at the high vectors >> address and trying to access them leads to errors, so I couldn't use >> them. On 19 Jan 2015, albert.u.boot at aribaud.net wrote: > This is *exactly* the case where you should define your own version of > relocate_vectors (probably at SoC level). A key difference is the ARM CPU architecture version. The ARMv7/Cortex on the imx6 will support vector table 'remaps'. Currently I see, #ifdef CONFIG_HAS_VBAR /* * If the ARM processor has the security extensions, * use VBAR to relocate the exception vectors. */ ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */ mcr p15, 0, r0, c12, c0, 0 /* Set VBAR */ #else This should be available for the CPUs, but I don't see this symbol besides a 'Kconfig'. There are three versions on the Cortex, but the VBAR (whether secure or not) is the the correct one. At least in theory, this code if activated should work for the iMx6 and an override of the 'weak' relocate vectors is not needed. I think trying to use the 'VBAR' is the correct way to go? Fwiw, Bill Pringlemeir. ^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] [PATCH] arm: fix exception vectors 2015-01-19 15:40 ` Bill Pringlemeir @ 2015-01-20 6:55 ` Albert ARIBAUD 0 siblings, 0 replies; 7+ messages in thread From: Albert ARIBAUD @ 2015-01-20 6:55 UTC (permalink / raw) To: u-boot Hello Bill, On Mon, 19 Jan 2015 10:40:07 -0500, Bill Pringlemeir <bpringlemeir@nbsps.com> wrote: > > > On Mon, 19 Jan 2015 11:11:34 +0100, Luca Ellero > > >> As far as I can see the mechanism to relocate vectors is implemented > >> only on iMX25/27 and involves high vectors address (0xFFFFxxxx). > > On 19 Jan 2015, albert.u.boot at aribaud.net wrote: > > > You are correct that the mechanism is /used/ only by mx25 and mx27. > > > However, it has been introduced to support /all/ SoCs (or even > > boards), not only mx25, mx27, and /all/ exception vector handling > > scenarios, not only high vectors addresses. > > > Actually, the standard high and low address is handled by default, > > and mx25 and mx27 are cases where this default is overriden /because/ > > high or low vector addresses are *unapplicable* for them due to their > > memory mapping. > > > On Mon, 19 Jan 2015 11:11:34 +0100, Luca Ellero > > >> The problem is that, after relocation, U-Boot doesn't fix the vector > >> table addresses, they still point to the old addresses (before > >> relocation). This is wrong and this patch fixes them to point to the > >> new addresses. > > On 19 Jan 2015, albert.u.boot at aribaud.net wrote: > > > You are right about the problem, and this problem is exactly what the > > relocate_vectors mechanism is here to fix -- exactly the same problem > > mx25 and mx27 had before we fixed it (quite recently actually, as it > > was done mid-November, between 2015.01-rc1 and 2015.01-rc1 rc2). > > > On Mon, 19 Jan 2015 11:11:34 +0100, Luca Ellero > > >> I had to use this patch trying to implement IRQ support for a > >> Freescale iMX6 board. iMX6 does not provide RAM at the high vectors > >> address and trying to access them leads to errors, so I couldn't use > >> them. > > On 19 Jan 2015, albert.u.boot at aribaud.net wrote: > > > This is *exactly* the case where you should define your own version of > > relocate_vectors (probably at SoC level). > > A key difference is the ARM CPU architecture version. The ARMv7/Cortex > on the imx6 will support vector table 'remaps'. Currently I see, > > #ifdef CONFIG_HAS_VBAR > /* > * If the ARM processor has the security extensions, > * use VBAR to relocate the exception vectors. > */ > ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */ > mcr p15, 0, r0, c12, c0, 0 /* Set VBAR */ > #else > > This should be available for the CPUs, but I don't see this symbol > besides a 'Kconfig'. There are three versions on the Cortex, but the > VBAR (whether secure or not) is the the correct one. > > At least in theory, this code if activated should work for the iMx6 and > an override of the 'weak' relocate vectors is not needed. I think > trying to use the 'VBAR' is the correct way to go? Possibly, though one should take into account the fact that the SoC design around the armv7 core (and the associated ROM code) might or might not allow changing the VBAR. Best is to look up the i.MX6 technical specs, especially the chapter on exceptions. If no specific indication is given that changing VBAR is forbidden, then yes, one should rely on CONFIG_HAS_VBAR (which should be set for all ARMv7-based targets). > Fwiw, > Bill Pringlemeir. Amicalement, -- Albert. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-01-20 6:55 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-12-29 15:10 [U-Boot] [PATCH] arm: fix exception vectors Luca Ellero 2015-01-17 6:40 ` Albert ARIBAUD 2015-01-19 10:11 ` Luca Ellero 2015-01-19 10:28 ` Albert ARIBAUD 2015-01-19 15:28 ` Luca Ellero 2015-01-19 15:40 ` Bill Pringlemeir 2015-01-20 6:55 ` Albert ARIBAUD
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox