Fix SoC-specific exception handling
cover Fix SoC-specific exception handling
Short version:
* this patch fixes exception handling on i.MX27 which was broken, probably from day one.
* i.MX27-based board Maintainers please test this
patch: make sure your board boots with it and make sure e.g. a write to address 0 causes U-Boot to signal a data abort.
* i.MX custodian please review this patch and let me know if this should also be done for other i.MX SoCs as well.
Long version:
This patch was created after apf27 maintainer found out that the board did not boot any more. The root cause was that commit 3ff46cc4 would try and write into the exception vectors table, which i.MX27 has in ROM. This caused a data abort, and as the U-Boot vectors were not in place yet, this abort went to the ROM code which silently hung.
Investigation led to a patch sent in 2009 to the list (but never applied) with a description of the i.MX27 exception handling:
http://lists.denx.de/pipermail/u-boot/2009-October/062811.html
By his own author's admission, this patch was not fit for inclusion in U-Boot, but it gave the technical information needed to produce this present patch set.
The first patch is only cosmetic, fixing whitespace quirks which affect legibility or cause a warning in patman.
The second patch moves vectors relocation out of the relocate_code routine and into its own relocate_vectors routine. This routine is made weak so that it can be replaced by a SoC-specific, strong one. Such a strong replacement is provided for i.MX27.
Albert ARIBAUD (2):
cosmetic: arm: fix whitespace in arch/arm/lib/relocate.S
imx: fix exception vectors relocation in imx27
arch/arm/cpu/arm926ejs/mx27/Makefile | 4 ++ arch/arm/cpu/arm926ejs/mx27/relocate.S | 49 +++++++++++++++++++++++ arch/arm/lib/crt0.S | 5 +++ arch/arm/lib/relocate.S | 73 ++++++++++++++++++++-------------- 4 files changed, 101 insertions(+), 30 deletions(-) create mode 100644 arch/arm/cpu/arm926ejs/mx27/relocate.S
Signature · 1 line
2.1.0
PATCH 1/2 cosmetic: arm: fix whitespace in arch/arm/lib/relocate.S
---
arch/arm/lib/relocate.S | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
arch/arm/lib/relocate.S +4 -4
@@ -74,8 +74,8 @@ fixnext: ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */ mrc p15, 0, r2, c1, c0, 0 /* V bit (bit[13]) in CP15 c1 */ ands r2, r2, #(1 << 13) - ldreq r1, =0x00000000 /* If V=0 */ - ldrne r1, =0xFFFF0000 /* If V=1 */ + ldreq r1, =0x00000000 /* If V=0 */ + ldrne r1, =0xFFFF0000 /* If V=1 */ ldmia r0!, {r2-r8,r10} stmia r1!, {r2-r8,r10} ldmia r0!, {r2-r8,r10}
@@ -96,9 +96,9 @@ relocate_done: /* ARMv4- don't know bx lr but the assembler fails to see that */ #ifdef __ARM_ARCH_4__ - mov pc, lr + mov pc, lr #else - bx lr + bx lr #endif ENDPROC(relocate_code)
Signature · 1 line
2.1.0
PATCH 2/2 imx: fix exception vectors relocation in i.MX27
In reply to Albert ARIBAUDCommit 3ff46cc4 fixed exception vectors setting in the general ARM case, by either copying the exception and indirect vector tables to normal (0x00000000) or high (0xFFFF0000) vectors address, or setting VBAR to U-Boot's base if applicable.
i.MX27 SoC is ARM926E-JS, thus has only normal and high options, but does not provide RAM at 0xFFFF0000 and has only ROM at 0x00000000; it is therefore not possible to move or change its exception vectors.
Besides, i.MX27 ROM code does provide an indirect vectors table but at a non-standard address and with the reset and reserved vectors missing.
Turn the current vector relocation code into a weak routine called after relocate_code from crt0, and add strong version for i.MX27.
---
arch/arm/cpu/arm926ejs/mx27/Makefile | 4 ++ arch/arm/cpu/arm926ejs/mx27/relocate.S | 49 ++++++++++++++++++++++++ arch/arm/lib/crt0.S | 5 +++ arch/arm/lib/relocate.S | 69 ++++++++++++++++++++-------------- 4 files changed, 99 insertions(+), 28 deletions(-) create mode 100644 arch/arm/cpu/arm926ejs/mx27/relocate.S
arch/arm/cpu/arm926ejs/mx27/Makefile +4 -0
@@ -5,3 +5,7 @@ # SPDX-License-Identifier: GPL-2.0+ obj-y = generic.o reset.o timer.o + +ifndef CONFIG_SPL_BUILD +obj-y += relocate.o +endif
arch/arm/cpu/arm926ejs/mx27/relocate.S new file +49 -0
49 lines not on this page · raw message
arch/arm/lib/crt0.S +5 -0
@@ -104,6 +104,11 @@ clr_gd: ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */ b relocate_code here: +/* + * now relocate vectors + */ + + bl relocate_vectors /* Set up final (full) environment */
arch/arm/lib/relocate.S +41 -28
81 lines not on this page · raw message
Signature · 1 line
2.1.0
PATCH 2/2 imx: fix exception vectors relocation in i.MX27
Quoted 189 lines · Albert ARIBAUD
Commit
3ff46cc4fixed exception vectors setting in the general ARM case, by either copying the exception and indirect vector tables to normal (0x00000000) or high (0xFFFF0000) vectors address, or setting VBAR to U-Boot's base if applicable.i.MX27 SoC is ARM926E-JS, thus has only normal and high options, but does not provide RAM at
0xFFFF0000and has only ROM at0x00000000; it is therefore not possible to move or change its exception vectors.Besides, i.MX27 ROM code does provide an indirect vectors table but at a non-standard address and with the reset and reserved vectors missing.
Turn the current vector relocation code into a weak routine called after
relocate_codefrom crt0, and add strong version for i.MX27.Signed-off-by Albert ARIBAUD<[email protected]>---
arch/arm/cpu/arm926ejs/mx27/Makefile | 4 ++ arch/arm/cpu/arm926ejs/mx27/relocate.S | 49 ++++++++++++++++++++++++ arch/arm/lib/crt0.S | 5 +++ arch/arm/lib/relocate.S | 69 ++++++++++++++++++++-------------- 4 files changed, 99 insertions(+), 28 deletions(-)create mode 100644
arch/arm/cpu/arm926ejs/mx27/relocate.Sarch/arm/cpu/arm926ejs/mx27/Makefile +4
-0@@ -5,3 +5,7 @@ # SPDX-License-Identifier: GPL-2.0+ obj-y = generic.o reset.o timer.o + +ifndef CONFIG_SPL_BUILD +obj-y += relocate.o +endifarch/arm/cpu/arm926ejs/mx27/relocate.S new file +49
-0@@ -0,0 +1,49 @@ +/* + * relocate - i.MX27-specific vector relocation + * + * Copyright (c) 2013 Albert ARIBAUD<[email protected]> + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +#include<asm-offsets.h> +#include<config.h> +#include<linux/linkage.h> + +/* + * The i.MX27 SoC is very specific with respect to exceptions: it + * does not provide RAM at the high vectors address (0xFFFF0000), + * thus only the low address (0x00000000) is useable; but that is + * in ROM. Therefore, vectors cannot be changed at all. + * + * However, these ROM-based vectors actually just perform indirect + * calls through pointers located in RAM at SoC-specific addresses, + * as follows: + * + * Offset Exception Use by ROM code + * 0x00000000 reset indirect branch to [0x00000014] + * 0x00000004 undefined instruction indirect branch to [0xfffffef0] + * 0x00000008 software interrupt indirect branch to [0xfffffef4] + * 0x0000000c prefetch abort indirect branch to [0xfffffef8] + * 0x00000010 data abort indirect branch to [0xfffffefc] + * 0x00000014 (reserved in ARMv5) vector to ROM reset: 0xc0000000 + * 0x00000018 IRQ indirect branch to [0xffffff00] + * 0x0000001c FIQ indirect branch to [0xffffff04] + * + * In order to initialize exceptions on i.MX27, we must copy U-Boot's + * indirect (not exception!) vector table into 0xfffffef0..0xffffff04 + * taking care not to copy vectors 0x00 (reset) and 0x14 (reserved). + */ + + .section .text.relocate_vectors,"ax",%progbits + +ENTRY(relocate_vectors) + + ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */ + ldr r1, =0xFFFFFEF0 + ldmia r0!, {r2-r8,r10} /* load all eight vectors */ + stmia r1!, {r3-r6,r8,r10} /* only write supported vectors */ + + bx lr + +ENDPROC(relocate_vectors)arch/arm/lib/crt0.S +5
-0@@ -104,6 +104,11 @@ clr_gd: ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */ b relocate_code here: +/* + * now relocate vectors + */ + + bl relocate_vectors /* Set up final (full) environment */arch/arm/lib/relocate.S +41
-21@@ -11,6 +11,47 @@ #include<linux/linkage.h> /* + * Default/weak exception vectors relocation routine + * + * This routine covers the standard ARM cases: normal (0x00000000), + * high (0xffff0000) and VBAR. SoCs which do not comply with any of + * the standard cases must provide their own, strong, version. + */ + + .section .text.relocate_vectors,"ax",%progbits + .weak relocate_vectors + +ENTRY(relocate_vectors) + +#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 + /* + * Copy the relocated exception vectors to the + * correct address + * CP15 c1 V bit gives us the location of the vectors: + * 0x00000000 or 0xFFFF0000. + */ + ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */ + mrc p15, 0, r2, c1, c0, 0 /* V bit (bit[13]) in CP15 c1 */ + ands r2, r2, #(1<< 13) + ldreq r1, =0x00000000 /* If V=0 */ + ldrne r1, =0xFFFF0000 /* If V=1 */ + ldmia r0!, {r2-r8,r10} + stmia r1!, {r2-r8,r10} + ldmia r0!, {r2-r8,r10} + stmia r1!, {r2-r8,r10} +#endif + bx lr + +ENDPROC(relocate_vectors) + +/* * void relocate_code(addr_moni) * * This function relocates the monitor code.@@ -54,34 +95,6 @@ fixnext: cmp r2, r3 blo fixloop - /* - * Relocate the exception vectors - */ -#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 - /* - * Copy the relocated exception vectors to the - * correct address - * CP15 c1 V bit gives us the location of the vectors: - * 0x00000000 or 0xFFFF0000. - */ - ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */ - mrc p15, 0, r2, c1, c0, 0 /* V bit (bit[13]) in CP15 c1 */ - ands r2, r2, #(1<< 13) - ldreq r1, =0x00000000 /* If V=0 */
arch/arm/lib/relocate.S fixnext: · line 100
Quoted 10 lines
arch/arm/lib/relocate.S +0
-7- ldrne r1, =0xFFFF0000 /* If V=1 */ - ldmia r0!, {r2-r8,r10} - stmia r1!, {r2-r8,r10} - ldmia r0!, {r2-r8,r10} - stmia r1!, {r2-r8,r10} -#endif - relocate_done: #ifdef __XSCALE__
Hi Albert,
I've tested this patch, and it fix my boot issue on armadeus apf27. (without this patch, u-boot freeze on relocation on apf27). But after a "mw.l 0 0" I don't have the log "data abort", neither the board reboot.
Regards,
Philippe
PATCH 2/2 imx: fix exception vectors relocation in i.MX27
Hello trem,
Quoted 199 lines · trem
Quoted 198 lines · Albert ARIBAUD
Commit
3ff46cc4fixed exception vectors setting in the general ARM case, by either copying the exception and indirect vector tables to normal (0x00000000) or high (0xFFFF0000) vectors address, or setting VBAR to U-Boot's base if applicable.i.MX27 SoC is ARM926E-JS, thus has only normal and high options, but does not provide RAM at
0xFFFF0000and has only ROM at0x00000000; it is therefore not possible to move or change its exception vectors.Besides, i.MX27 ROM code does provide an indirect vectors table but at a non-standard address and with the reset and reserved vectors missing.
Turn the current vector relocation code into a weak routine called after
relocate_codefrom crt0, and add strong version for i.MX27.Signed-off-by Albert ARIBAUD<[email protected]>---
arch/arm/cpu/arm926ejs/mx27/Makefile | 4 ++ arch/arm/cpu/arm926ejs/mx27/relocate.S | 49 ++++++++++++++++++++++++ arch/arm/lib/crt0.S | 5 +++ arch/arm/lib/relocate.S | 69 ++++++++++++++++++++-------------- 4 files changed, 99 insertions(+), 28 deletions(-)create mode 100644
arch/arm/cpu/arm926ejs/mx27/relocate.Sarch/arm/cpu/arm926ejs/mx27/Makefile +4
-0@@ -5,3 +5,7 @@ # SPDX-License-Identifier: GPL-2.0+ obj-y = generic.o reset.o timer.o + +ifndef CONFIG_SPL_BUILD +obj-y += relocate.o +endifarch/arm/cpu/arm926ejs/mx27/relocate.S new file +49
-0@@ -0,0 +1,49 @@ +/* + * relocate - i.MX27-specific vector relocation + * + * Copyright (c) 2013 Albert ARIBAUD<[email protected]> + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +#include<asm-offsets.h> +#include<config.h> +#include<linux/linkage.h> + +/* + * The i.MX27 SoC is very specific with respect to exceptions: it + * does not provide RAM at the high vectors address (0xFFFF0000), + * thus only the low address (0x00000000) is useable; but that is + * in ROM. Therefore, vectors cannot be changed at all. + * + * However, these ROM-based vectors actually just perform indirect + * calls through pointers located in RAM at SoC-specific addresses, + * as follows: + * + * Offset Exception Use by ROM code + * 0x00000000 reset indirect branch to [0x00000014] + * 0x00000004 undefined instruction indirect branch to [0xfffffef0] + * 0x00000008 software interrupt indirect branch to [0xfffffef4] + * 0x0000000c prefetch abort indirect branch to [0xfffffef8] + * 0x00000010 data abort indirect branch to [0xfffffefc] + * 0x00000014 (reserved in ARMv5) vector to ROM reset: 0xc0000000 + * 0x00000018 IRQ indirect branch to [0xffffff00] + * 0x0000001c FIQ indirect branch to [0xffffff04] + * + * In order to initialize exceptions on i.MX27, we must copy U-Boot's + * indirect (not exception!) vector table into 0xfffffef0..0xffffff04 + * taking care not to copy vectors 0x00 (reset) and 0x14 (reserved). + */ + + .section .text.relocate_vectors,"ax",%progbits + +ENTRY(relocate_vectors) + + ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */ + ldr r1, =0xFFFFFEF0 + ldmia r0!, {r2-r8,r10} /* load all eight vectors */ + stmia r1!, {r3-r6,r8,r10} /* only write supported vectors */ + + bx lr + +ENDPROC(relocate_vectors)arch/arm/lib/crt0.S +5
-0@@ -104,6 +104,11 @@ clr_gd: ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */ b relocate_code here: +/* + * now relocate vectors + */ + + bl relocate_vectors /* Set up final (full) environment */arch/arm/lib/relocate.S +41
-28@@ -11,6 +11,47 @@ #include<linux/linkage.h> /* + * Default/weak exception vectors relocation routine + * + * This routine covers the standard ARM cases: normal (0x00000000), + * high (0xffff0000) and VBAR. SoCs which do not comply with any of + * the standard cases must provide their own, strong, version. + */ + + .section .text.relocate_vectors,"ax",%progbits + .weak relocate_vectors + +ENTRY(relocate_vectors) + +#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 + /* + * Copy the relocated exception vectors to the + * correct address + * CP15 c1 V bit gives us the location of the vectors: + * 0x00000000 or 0xFFFF0000. + */ + ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */ + mrc p15, 0, r2, c1, c0, 0 /* V bit (bit[13]) in CP15 c1 */ + ands r2, r2, #(1<< 13) + ldreq r1, =0x00000000 /* If V=0 */ + ldrne r1, =0xFFFF0000 /* If V=1 */ + ldmia r0!, {r2-r8,r10} + stmia r1!, {r2-r8,r10} + ldmia r0!, {r2-r8,r10} + stmia r1!, {r2-r8,r10} +#endif + bx lr + +ENDPROC(relocate_vectors) + +/* * void relocate_code(addr_moni) * * This function relocates the monitor code.@@ -54,34 +95,6 @@ fixnext: cmp r2, r3 blo fixloop - /* - * Relocate the exception vectors - */ -#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 - /* - * Copy the relocated exception vectors to the - * correct address - * CP15 c1 V bit gives us the location of the vectors: - * 0x00000000 or 0xFFFF0000. - */ - ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */ - mrc p15, 0, r2, c1, c0, 0 /* V bit (bit[13]) in CP15 c1 */ - ands r2, r2, #(1<< 13) - ldreq r1, =0x00000000 /* If V=0 */ - ldrne r1, =0xFFFF0000 /* If V=1 */ - ldmia r0!, {r2-r8,r10} - stmia r1!, {r2-r8,r10} - ldmia r0!, {r2-r8,r10} - stmia r1!, {r2-r8,r10} -#endif - relocate_done:
Quoted 8 lines
arch/arm/lib/relocate.S fixnext: · line 100
Quoted 1 line
arch/arm/lib/relocate.S +0
-0#ifdef __XSCALE__Hi Albert,
I've tested this patch, and it fix my boot issue on armadeus apf27. (without this patch, u-boot freeze on relocation on apf27). But after a "mw.l 0 0" I don't have the log "data abort", neither the board reboot.
My bad -- I thought I had properly rewritten the i.MX27 vector relocation code, but had made a blatant mistake -- copying into the i.MX27 indirect table from the U-Boot *exception*, not *indirect*, table.
Patch series v2 coming up.
Quoted 6 lines
Regards,
Philippe
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Amicalement,
Signature · 1 line
Albert.
v2 cover Fix SoC-specific exception handling
In reply to Albert ARIBAUDShort version:
* this patch fixes exception handling on i.MX27 which was broken, probably from day one.
* i.MX27-based board Maintainers please test this
patch: make sure your board boots with it and make sure e.g. a write to address 0 causes U-Boot to signal a data abort.
* i.MX custodian please review this patch and let me know if this should also be done for other i.MX SoCs as well.
Long version:
This patch was created after apf27 maintainer found out that the board did not boot any more. The root cause was that commit 3ff46cc4 would try and write into the exception vectors table, which i.MX27 has in ROM. This caused a data abort, and as the U-Boot vectors were not in place yet, this abort went to the ROM code which silently hung.
Investigation led to a patch sent in 2009 to the list (but never applied) with a description of the i.MX27 exception handling:
http://lists.denx.de/pipermail/u-boot/2009-October/062811.html
By his own author's admission, this patch was not fit for inclusion in U-Boot, but it gave the technical information needed to produce this present patch set.
The first patch is only cosmetic, fixing whitespace quirks which affect legibility or cause a warning in patman.
The second patch moves vectors relocation out of the relocate_code routine and into its own relocate_vectors routine. This routine is made weak so that it can be replaced by a SoC-specific, strong one. Such a strong replacement is provided for i.MX27.
Changes in v2:
- Fixed wrong i.MX27 vector relocation code
Albert ARIBAUD (2):
cosmetic: arm: fix whitespace in arch/arm/lib/relocate.S
imx: fix exception vectors relocation in imx27
arch/arm/cpu/arm926ejs/mx27/Makefile | 4 ++ arch/arm/cpu/arm926ejs/mx27/relocate.S | 51 ++++++++++++++++++++++++ arch/arm/lib/crt0.S | 5 +++ arch/arm/lib/relocate.S | 73 ++++++++++++++++++++-------------- 4 files changed, 103 insertions(+), 30 deletions(-) create mode 100644 arch/arm/cpu/arm926ejs/mx27/relocate.S
Signature · 1 line
2.1.0
PATCH v2 1/2 cosmetic: arm: fix whitespace in arch/arm/lib/relocate.S
---
Changes in v2: None
arch/arm/lib/relocate.S | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
arch/arm/lib/relocate.S +4 -4
@@ -74,8 +74,8 @@ fixnext: ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */ mrc p15, 0, r2, c1, c0, 0 /* V bit (bit[13]) in CP15 c1 */ ands r2, r2, #(1 << 13) - ldreq r1, =0x00000000 /* If V=0 */ - ldrne r1, =0xFFFF0000 /* If V=1 */ + ldreq r1, =0x00000000 /* If V=0 */ + ldrne r1, =0xFFFF0000 /* If V=1 */ ldmia r0!, {r2-r8,r10} stmia r1!, {r2-r8,r10} ldmia r0!, {r2-r8,r10}
@@ -96,9 +96,9 @@ relocate_done: /* ARMv4- don't know bx lr but the assembler fails to see that */ #ifdef __ARM_ARCH_4__ - mov pc, lr + mov pc, lr #else - bx lr + bx lr #endif ENDPROC(relocate_code)
Signature · 1 line
2.1.0
PATCH v2 2/2 imx: fix exception vectors relocation in imx27
In reply to Albert ARIBAUDCommit 3ff46cc4 fixed exception vectors setting in the general ARM case, by either copying the exception and indirect vector tables to normal (0x00000000) or high (0xFFFF0000) vectors address, or setting VBAR to U-Boot's base if applicable.
i.MX27 SoC is ARM926E-JS, thus has only normal and high options, but does not provide RAM at 0xFFFF0000 and has only ROM at 0x00000000; it is therefore not possible to move or change its exception vectors.
Besides, i.MX27 ROM code does provide an indirect vectors table but at a non-standard address and with the reset and reserved vectors missing.
Turn the current vector relocation code into a weak routine called after relocate_code from crt0, and add strong version for i.MX27.
---
Changes in v2:
- Fixed wrong i.MX27 vector relocation code
arch/arm/cpu/arm926ejs/mx27/Makefile | 4 ++ arch/arm/cpu/arm926ejs/mx27/relocate.S | 51 +++++++++++++++++++++++++ arch/arm/lib/crt0.S | 5 +++ arch/arm/lib/relocate.S | 69 ++++++++++++++++++++-------------- 4 files changed, 101 insertions(+), 28 deletions(-) create mode 100644 arch/arm/cpu/arm926ejs/mx27/relocate.S
arch/arm/cpu/arm926ejs/mx27/Makefile +4 -0
@@ -5,3 +5,7 @@ # SPDX-License-Identifier: GPL-2.0+ obj-y = generic.o reset.o timer.o + +ifndef CONFIG_SPL_BUILD +obj-y += relocate.o +endif
arch/arm/cpu/arm926ejs/mx27/relocate.S new file +51 -0
51 lines not on this page · raw message
arch/arm/lib/crt0.S +5 -0
@@ -104,6 +104,11 @@ clr_gd: ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */ b relocate_code here: +/* + * now relocate vectors + */ + + bl relocate_vectors /* Set up final (full) environment */
arch/arm/lib/relocate.S +41 -28
81 lines not on this page · raw message
Signature · 1 line
2.1.0
v3 cover Fix SoC-specific exception handling
In reply to Albert ARIBAUDShort version:
* this patch fixes exception handling on i.MX27 which was broken, probably from day one.
* this patch was tested on apf27. Due to lack of debugging hardware, only the data abort, prefetch abort and undefined instruction cases have been tested; software interrupt, IRQ and FIQ were not tested.
* This patch was NOT tested on imx27lite, which is the only other i.MX27-based board AFAICT. The maintainer of imx27lite is Cc:ed on this series.
* i.MX custodian (Cc:) please review this patch and let me know if this should also be done for other i.MX SoCs as well.
Long version:
This patch was created after apf27 maintainer found out that the board did not boot any more. The root cause was that commit 3ff46cc4 would try and write into the exception vectors table, which i.MX27 has in ROM. This caused a data abort, and as the U-Boot vectors were not in place yet, this abort went to the ROM code which silently hung.
Investigation led to a patch sent in 2009 to the list (but never applied) with a description of the i.MX27 exception handling:
http://lists.denx.de/pipermail/u-boot/2009-October/062811.html
By his own author's admission, this patch was not fit for inclusion in U-Boot, but it gave the technical information needed to produce this present patch set.
The first patch is only cosmetic, fixing whitespace quirks which affect legibility or cause a warning in patman.
The second patch moves vectors relocation out of the relocate_code routine and into its own relocate_vectors routine. This routine is made weak so that it can be replaced by a SoC-specific, strong one. Such a strong replacement is provided for i.MX27.
Changes in v3:
- Fixed AGAIN wrong i.MX27 vector relocation code
Changes in v2:
- Fixed wrong i.MX27 vector relocation code
Albert ARIBAUD (2):
cosmetic: arm: fix whitespace in arch/arm/lib/relocate.S
imx: fix exception vectors relocation in imx27
arch/arm/cpu/arm926ejs/mx27/Makefile | 4 ++ arch/arm/cpu/arm926ejs/mx27/relocate.S | 51 ++++++++++++++++++++++++ arch/arm/lib/crt0.S | 5 +++ arch/arm/lib/relocate.S | 73 ++++++++++++++++++++-------------- 4 files changed, 103 insertions(+), 30 deletions(-) create mode 100644 arch/arm/cpu/arm926ejs/mx27/relocate.S
Signature · 1 line
2.1.0
PATCH v3 1/2 cosmetic: arm: fix whitespace in arch/arm/lib/relocate.S
---
Changes in v3: None
Changes in v2: None
arch/arm/lib/relocate.S | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
arch/arm/lib/relocate.S +4 -4
@@ -74,8 +74,8 @@ fixnext: ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */ mrc p15, 0, r2, c1, c0, 0 /* V bit (bit[13]) in CP15 c1 */ ands r2, r2, #(1 << 13) - ldreq r1, =0x00000000 /* If V=0 */ - ldrne r1, =0xFFFF0000 /* If V=1 */ + ldreq r1, =0x00000000 /* If V=0 */ + ldrne r1, =0xFFFF0000 /* If V=1 */ ldmia r0!, {r2-r8,r10} stmia r1!, {r2-r8,r10} ldmia r0!, {r2-r8,r10}
@@ -96,9 +96,9 @@ relocate_done: /* ARMv4- don't know bx lr but the assembler fails to see that */ #ifdef __ARM_ARCH_4__ - mov pc, lr + mov pc, lr #else - bx lr + bx lr #endif ENDPROC(relocate_code)
Signature · 1 line
2.1.0
PATCH v3 1/2 cosmetic: arm: fix whitespace in arch/arm/lib/relocate.S
Quoted 38 lines · Albert ARIBAUD
Signed-off-by Albert ARIBAUD <[email protected]>---
Changes in v3: None
Changes in v2: Nonearch/arm/lib/relocate.S | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)arch/arm/lib/relocate.S +4
-4@@ -74,8 +74,8 @@ fixnext: ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */ mrc p15, 0, r2, c1, c0, 0 /* V bit (bit[13]) in CP15 c1 */ ands r2, r2, #(1 << 13) - ldreq r1, =0x00000000 /* If V=0 */ - ldrne r1, =0xFFFF0000 /* If V=1 */ + ldreq r1, =0x00000000 /* If V=0 */ + ldrne r1, =0xFFFF0000 /* If V=1 */ ldmia r0!, {r2-r8,r10} stmia r1!, {r2-r8,r10} ldmia r0!, {r2-r8,r10}@@ -96,9 +96,9 @@ relocate_done: /* ARMv4- don't know bx lr but the assembler fails to see that */ #ifdef __ARM_ARCH_4__ - mov pc, lr + mov pc, lr #else - bx lr + bx lr #endif ENDPROC(relocate_code)Signature · 1 line
2.1.0
Applied to u-boot-arm/master.
Amicalement,
Signature · 1 line
Albert.
PATCH v3 1/2 cosmetic: arm: fix whitespace in arch/arm/lib/relocate.S
Correction: this was actually already applied by Stefano in u-boot-imx, I'd just missed that he'd applied the whole series.
So: *not* applied to u-boot-arm/master, which remains unchanged.
Amicalement,
Signature · 1 line
Albert.
PATCH v3 2/2 imx: fix exception vectors relocation in imx27
In reply to Albert ARIBAUDCommit 3ff46cc4 fixed exception vectors setting in the general ARM case, by either copying the exception and indirect vector tables to normal (0x00000000) or high (0xFFFF0000) vectors address, or setting VBAR to U-Boot's base if applicable.
i.MX27 SoC is ARM926E-JS, thus has only normal and high options, but does not provide RAM at 0xFFFF0000 and has only ROM at 0x00000000; it is therefore not possible to move or change its exception vectors.
Besides, i.MX27 ROM code does provide an indirect vectors table but at a non-standard address and with the reset and reserved vectors missing.
Turn the current vector relocation code into a weak routine called after relocate_code from crt0, and add strong version for i.MX27.
Series-Cc: Heiko Schocher <[email protected]>
---
Changes in v3:
- Fixed AGAIN wrong i.MX27 vector relocation code
Changes in v2:
- Fixed wrong i.MX27 vector relocation code
arch/arm/cpu/arm926ejs/mx27/Makefile | 4 ++ arch/arm/cpu/arm926ejs/mx27/relocate.S | 51 +++++++++++++++++++++++++ arch/arm/lib/crt0.S | 5 +++ arch/arm/lib/relocate.S | 69 ++++++++++++++++++++-------------- 4 files changed, 101 insertions(+), 28 deletions(-) create mode 100644 arch/arm/cpu/arm926ejs/mx27/relocate.S
arch/arm/cpu/arm926ejs/mx27/Makefile +4 -0
@@ -5,3 +5,7 @@ # SPDX-License-Identifier: GPL-2.0+ obj-y = generic.o reset.o timer.o + +ifndef CONFIG_SPL_BUILD +obj-y += relocate.o +endif
arch/arm/cpu/arm926ejs/mx27/relocate.S new file +51 -0
51 lines not on this page · raw message
arch/arm/lib/crt0.S +5 -0
@@ -104,6 +104,11 @@ clr_gd: ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */ b relocate_code here: +/* + * now relocate vectors + */ + + bl relocate_vectors /* Set up final (full) environment */
arch/arm/lib/relocate.S +41 -28
81 lines not on this page · raw message
Signature · 1 line
2.1.0
PATCH v3 2/2 imx: fix exception vectors relocation in imx27
Hi Albert,
firstly I can tell you that patch fixes the issue. I tested on magnesium board. Board boots flawless with your patch.
Quoted 200 lines · Albert ARIBAUD
Commit
3ff46cc4fixed exception vectors setting in the general ARM case, by either copying the exception and indirect vector tables to normal (0x00000000) or high (0xFFFF0000) vectors address, or setting VBAR to U-Boot's base if applicable.i.MX27 SoC is ARM926E-JS, thus has only normal and high options, but does not provide RAM at
0xFFFF0000and has only ROM at0x00000000; it is therefore not possible to move or change its exception vectors.Besides, i.MX27 ROM code does provide an indirect vectors table but at a non-standard address and with the reset and reserved vectors missing.
Turn the current vector relocation code into a weak routine called after
relocate_codefrom crt0, and add strong version for i.MX27.Series-Cc: Heiko Schocher <[email protected]>
Signed-off-by Albert ARIBAUD <[email protected]>---
Changes in v3:
- Fixed AGAIN wrong i.MX27 vector relocation codeChanges in v2:
- Fixed wrong i.MX27 vector relocation codearch/arm/cpu/arm926ejs/mx27/Makefile | 4 ++ arch/arm/cpu/arm926ejs/mx27/relocate.S | 51 +++++++++++++++++++++++++ arch/arm/lib/crt0.S | 5 +++ arch/arm/lib/relocate.S | 69 ++++++++++++++++++++-------------- 4 files changed, 101 insertions(+), 28 deletions(-) create mode 100644 arch/arm/cpu/arm926ejs/mx27/relocate.Sarch/arm/cpu/arm926ejs/mx27/Makefile +4
-0@@ -5,3 +5,7 @@ # SPDX-License-Identifier: GPL-2.0+ obj-y = generic.o reset.o timer.o + +ifndef CONFIG_SPL_BUILD +obj-y += relocate.o +endifarch/arm/cpu/arm926ejs/mx27/relocate.S new file +51
-0@@ -0,0 +1,51 @@ +/* + * relocate - i.MX27-specific vector relocation + * + * Copyright (c) 2013 Albert ARIBAUD <[email protected]> + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +#include <asm-offsets.h> +#include <config.h> +#include <linux/linkage.h> + +/* + * The i.MX27 SoC is very specific with respect to exceptions: it + * does not provide RAM at the high vectors address (0xFFFF0000), + * thus only the low address (0x00000000) is useable; but that is + * in ROM. Therefore, vectors cannot be changed at all. + * + * However, these ROM-based vectors actually just perform indirect + * calls through pointers located in RAM at SoC-specific addresses, + * as follows: + * + * Offset Exception Use by ROM code + * 0x00000000 reset indirect branch to [0x00000014] + * 0x00000004 undefined instruction indirect branch to [0xfffffef0] + * 0x00000008 software interrupt indirect branch to [0xfffffef4] + * 0x0000000c prefetch abort indirect branch to [0xfffffef8] + * 0x00000010 data abort indirect branch to [0xfffffefc] + * 0x00000014 (reserved in ARMv5) vector to ROM reset: 0xc0000000 + * 0x00000018 IRQ indirect branch to [0xffffff00] + * 0x0000001c FIQ indirect branch to [0xffffff04] + * + * In order to initialize exceptions on i.MX27, we must copy U-Boot's + * indirect (not exception!) vector table into 0xfffffef0..0xffffff04 + * taking care not to copy vectors number 5 (reserved exception). + */ + + .section .text.relocate_vectors,"ax",%progbits + +ENTRY(relocate_vectors) + + ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */ + ldr r1, =32 /* size of vector table */ + add r0, r0, r1 /* skip to indirect table */ + ldr r1, =0xFFFFFEF0 /* i.MX27 indirect table */ + ldmia r0!, {r2-r8} /* load indirect vectors 1..7 */ + stmia r1!, {r2-r5, r7,r8} /* write all but vector 5 */ + + bx lr + +ENDPROC(relocate_vectors)arch/arm/lib/crt0.S +5
-0@@ -104,6 +104,11 @@ clr_gd: ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */ b relocate_code here: +/* + * now relocate vectors + */ + + bl relocate_vectors /* Set up final (full) environment */arch/arm/lib/relocate.S +41
-21@@ -11,6 +11,47 @@ #include <linux/linkage.h> /* + * Default/weak exception vectors relocation routine + * + * This routine covers the standard ARM cases: normal (0x00000000), + * high (0xffff0000) and VBAR. SoCs which do not comply with any of + * the standard cases must provide their own, strong, version. + */ + + .section .text.relocate_vectors,"ax",%progbits + .weak relocate_vectors + +ENTRY(relocate_vectors) + +#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 + /* + * Copy the relocated exception vectors to the + * correct address + * CP15 c1 V bit gives us the location of the vectors: + * 0x00000000 or 0xFFFF0000. + */ + ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */ + mrc p15, 0, r2, c1, c0, 0 /* V bit (bit[13]) in CP15 c1 */ + ands r2, r2, #(1 << 13) + ldreq r1, =0x00000000 /* If V=0 */ + ldrne r1, =0xFFFF0000 /* If V=1 */ + ldmia r0!, {r2-r8,r10} + stmia r1!, {r2-r8,r10} + ldmia r0!, {r2-r8,r10} + stmia r1!, {r2-r8,r10} +#endif + bx lr + +ENDPROC(relocate_vectors) + +/* * void relocate_code(addr_moni) * * This function relocates the monitor code.@@ -54,34 +95,6 @@ fixnext: cmp r2, r3 blo fixloop - /* - * Relocate the exception vectors - */ -#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 - /* - * Copy the relocated exception vectors to the - * correct address - * CP15 c1 V bit gives us the location of the vectors: - * 0x00000000 or 0xFFFF0000. - */ - ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */ - mrc p15, 0, r2, c1, c0, 0 /* V bit (bit[13]) in CP15 c1 */ - ands r2, r2, #(1 << 13) - ldreq r1, =0x00000000 /* If V=0 */
arch/arm/lib/relocate.S fixnext: · line 100
Quoted 10 lines
arch/arm/lib/relocate.S +0
-7- ldrne r1, =0xFFFF0000 /* If V=1 */ - ldmia r0!, {r2-r8,r10} - stmia r1!, {r2-r8,r10} - ldmia r0!, {r2-r8,r10} - stmia r1!, {r2-r8,r10} -#endif - relocate_done: #ifdef __XSCALE__
Nice work !
I don't currently know if the same issue happens on other i.MXes. Dropped the new ones, the other test cases are MX25 and MX31/35 (but last two are arm1136 (arm6) - is the issue also for this cpu type ?). It is surely worth to run current u-boot on these boards.
Best regards,
Stefano
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================
PATCH v3 2/2 imx: fix exception vectors relocation in imx27
Hello Stefano,
Quoted 4 lines
I don't currently know if the same issue happens on other i.MXes. Dropped the new ones, the other test cases are MX25 and MX31/35 (but last two are arm1136 (arm6) - is the issue also for this cpu type ?). It is surely worth to run current u-boot on these boards.
I don't have i.MX based boards myself to test.
ARM1136 does not have VBAR -- if it had, we could just set the VBAR to the base of the monitor and the issue would be solved.
I'll have a look at the i.MX25, i.MX31 and i.MX35 reference manuals, but at most that will only tell me if they have the same problem as i.MX27 has about ROM/RAM and low/high vectors; it probably won't tell me how their ROM code handles exceptions.
Quoted 2 lines
Best regards,
Stefano
Amicalement,
Signature · 1 line
Albert.
PATCH v3 2/2 imx: fix exception vectors relocation in imx27
Quoted 4 lines
I'll have a look at the i.MX25, i.MX31 and i.MX35 reference manuals, but at most that will only tell me if they have the same problem as i.MX27 has about ROM/RAM and low/high vectors; it probably won't tell me how their ROM code handles exceptions.
According to the i.MX25, i.MX31 and i.MX35 RM, all three SoCs have ROM at address 0x00000000 and no RAM at address 0xffff0000, so they most certainly have the same kind of issue as i.MX27, but there is no indication that the indirect vectors table is always the same, and it is quite probable that it is located at a different place for each SoC.
So in order to solve the issue, we would need a dump (or better yet a disassembly) of ROM addresses 0x00000000 to 0x0000001F for each of the three SoCs.
Quoted 2 lines
Quoted 2 lines
Best regards,
Stefano
Amicalement,
Signature · 1 line
Albert.
PATCH v3 2/2 imx: fix exception vectors relocation in imx27
Hi Albert,
Quoted 11 lines · Albert ARIBAUD
Quoted 4 lines
I'll have a look at the i.MX25, i.MX31 and i.MX35 reference manuals, but at most that will only tell me if they have the same problem as i.MX27 has about ROM/RAM and low/high vectors; it probably won't tell me how their ROM code handles exceptions.
According to the i.MX25, i.MX31 and i.MX35 RM, all three SoCs have ROM at address
0x00000000and no RAM at address0xffff0000, so they most certainly have the same kind of issue as i.MX27, but there is no indication that the indirect vectors table is always the same, and it is quite probable that it is located at a different place for each SoC.
Quoted 4 lines
So in order to solve the issue, we would need a dump (or better yet a disassembly) of ROM addresses
0x00000000to0x0000001Ffor each of the three SoCs.
ok - I have a MX35 based board, and I can do some tests, maybe in the week-end.
Best regards,
Stefano
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================
PATCH v3 2/2 imx: fix exception vectors relocation in imx27
Quoted 14 lines · Stefano Babic
Hi Albert,
Quoted 11 lines · Albert ARIBAUD
Quoted 4 lines
I'll have a look at the i.MX25, i.MX31 and i.MX35 reference manuals, but at most that will only tell me if they have the same problem as i.MX27 has about ROM/RAM and low/high vectors; it probably won't tell me how their ROM code handles exceptions.
According to the i.MX25, i.MX31 and i.MX35 RM, all three SoCs have ROM at address
0x00000000and no RAM at address0xffff0000, so they most certainly have the same kind of issue as i.MX27, but there is no indication that the indirect vectors table is always the same, and it is quite probable that it is located at a different place for each SoC.
Quoted 7 lines
Quoted 4 lines
So in order to solve the issue, we would need a dump (or better yet a disassembly) of ROM addresses
0x00000000to0x0000001Ffor each of the three SoCs.ok - I have a MX35 based board, and I can do some tests, maybe in the week-end.
I don't have access to a mx31 board, but I am adding Magnus in case he could help testing.
I remember that mx31 spl nand boot issue was fixed in the 2014.10 version.
Thanks
PATCH v3 2/2 imx: fix exception vectors relocation in imx27
In reply to Stefano BabicHello Stefano,
Quoted 14 lines · Stefano Babic
Hi Albert,
Quoted 11 lines · Albert ARIBAUD
Quoted 4 lines
I'll have a look at the i.MX25, i.MX31 and i.MX35 reference manuals, but at most that will only tell me if they have the same problem as i.MX27 has about ROM/RAM and low/high vectors; it probably won't tell me how their ROM code handles exceptions.
According to the i.MX25, i.MX31 and i.MX35 RM, all three SoCs have ROM at address
0x00000000and no RAM at address0xffff0000, so they most certainly have the same kind of issue as i.MX27, but there is no indication that the indirect vectors table is always the same, and it is quite probable that it is located at a different place for each SoC.
Quoted 7 lines
Quoted 4 lines
So in order to solve the issue, we would need a dump (or better yet a disassembly) of ROM addresses
0x00000000to0x0000001Ffor each of the three SoCs.ok - I have a MX35 based board, and I can do some tests, maybe in the week-end.
(thanks for applying my patch) Did you do the tests on i.MX35? Should there be a followup patch to fix i.MX35 as i.MX27 i now fixed?
Quoted 2 lines
Best regards,
Stefano
Amicalement,
Signature · 1 line
Albert.
PATCH v3 2/2 imx: fix exception vectors relocation in imx27
Hi Albert,
Quoted 5 lines · Albert ARIBAUD
Quoted 2 lines
ok - I have a MX35 based board, and I can do some tests, maybe in the week-end.
(thanks for applying my patch) Did you do the tests on i.MX35? Should there be a followup patch to fix i.MX35 as i.MX27 i now fixed?
I confess I have not yet done the test, but it is on my TODO list ;-)
Stefano
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================
PATCH v3 2/2 imx: fix exception vectors relocation in imx27
In reply to Albert ARIBAUDQuoted 15 lines · Albert ARIBAUD
Commit
3ff46cc4fixed exception vectors setting in the general ARM case, by either copying the exception and indirect vector tables to normal (0x00000000) or high (0xFFFF0000) vectors address, or setting VBAR to U-Boot's base if applicable.i.MX27 SoC is ARM926E-JS, thus has only normal and high options, but does not provide RAM at
0xFFFF0000and has only ROM at0x00000000; it is therefore not possible to move or change its exception vectors.Besides, i.MX27 ROM code does provide an indirect vectors table but at a non-standard address and with the reset and reserved vectors missing.
Quoted 5 lines
Turn the current vector relocation code into a weak routine called after
relocate_codefrom crt0, and add strong version for i.MX27.Series-Cc: Heiko Schocher<[email protected]>
Quoted 188 lines
Signed-off-by Albert ARIBAUD<[email protected]>---
Changes in v3:
- Fixed AGAIN wrong i.MX27 vector relocation codeChanges in v2:
- Fixed wrong i.MX27 vector relocation codearch/arm/cpu/arm926ejs/mx27/Makefile | 4 ++ arch/arm/cpu/arm926ejs/mx27/relocate.S | 51 +++++++++++++++++++++++++ arch/arm/lib/crt0.S | 5 +++ arch/arm/lib/relocate.S | 69 ++++++++++++++++++++-------------- 4 files changed, 101 insertions(+), 28 deletions(-)create mode 100644
arch/arm/cpu/arm926ejs/mx27/relocate.Sarch/arm/cpu/arm926ejs/mx27/Makefile +4
-0@@ -5,3 +5,7 @@ # SPDX-License-Identifier: GPL-2.0+ obj-y = generic.o reset.o timer.o + +ifndef CONFIG_SPL_BUILD +obj-y += relocate.o +endifarch/arm/cpu/arm926ejs/mx27/relocate.S new file +51
-0@@ -0,0 +1,51 @@ +/* + * relocate - i.MX27-specific vector relocation + * + * Copyright (c) 2013 Albert ARIBAUD<[email protected]> + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +#include<asm-offsets.h> +#include<config.h> +#include<linux/linkage.h> + +/* + * The i.MX27 SoC is very specific with respect to exceptions: it + * does not provide RAM at the high vectors address (0xFFFF0000), + * thus only the low address (0x00000000) is useable; but that is + * in ROM. Therefore, vectors cannot be changed at all. + * + * However, these ROM-based vectors actually just perform indirect + * calls through pointers located in RAM at SoC-specific addresses, + * as follows: + * + * Offset Exception Use by ROM code + * 0x00000000 reset indirect branch to [0x00000014] + * 0x00000004 undefined instruction indirect branch to [0xfffffef0] + * 0x00000008 software interrupt indirect branch to [0xfffffef4] + * 0x0000000c prefetch abort indirect branch to [0xfffffef8] + * 0x00000010 data abort indirect branch to [0xfffffefc] + * 0x00000014 (reserved in ARMv5) vector to ROM reset: 0xc0000000 + * 0x00000018 IRQ indirect branch to [0xffffff00] + * 0x0000001c FIQ indirect branch to [0xffffff04] + * + * In order to initialize exceptions on i.MX27, we must copy U-Boot's + * indirect (not exception!) vector table into 0xfffffef0..0xffffff04 + * taking care not to copy vectors number 5 (reserved exception). + */ + + .section .text.relocate_vectors,"ax",%progbits + +ENTRY(relocate_vectors) + + ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */ + ldr r1, =32 /* size of vector table */ + add r0, r0, r1 /* skip to indirect table */ + ldr r1, =0xFFFFFEF0 /* i.MX27 indirect table */ + ldmia r0!, {r2-r8} /* load indirect vectors 1..7 */ + stmia r1!, {r2-r5, r7,r8} /* write all but vector 5 */ + + bx lr + +ENDPROC(relocate_vectors)arch/arm/lib/crt0.S +5
-0@@ -104,6 +104,11 @@ clr_gd: ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */ b relocate_code here: +/* + * now relocate vectors + */ + + bl relocate_vectors /* Set up final (full) environment */arch/arm/lib/relocate.S +41
-28@@ -11,6 +11,47 @@ #include<linux/linkage.h> /* + * Default/weak exception vectors relocation routine + * + * This routine covers the standard ARM cases: normal (0x00000000), + * high (0xffff0000) and VBAR. SoCs which do not comply with any of + * the standard cases must provide their own, strong, version. + */ + + .section .text.relocate_vectors,"ax",%progbits + .weak relocate_vectors + +ENTRY(relocate_vectors) + +#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 + /* + * Copy the relocated exception vectors to the + * correct address + * CP15 c1 V bit gives us the location of the vectors: + * 0x00000000 or 0xFFFF0000. + */ + ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */ + mrc p15, 0, r2, c1, c0, 0 /* V bit (bit[13]) in CP15 c1 */ + ands r2, r2, #(1<< 13) + ldreq r1, =0x00000000 /* If V=0 */ + ldrne r1, =0xFFFF0000 /* If V=1 */ + ldmia r0!, {r2-r8,r10} + stmia r1!, {r2-r8,r10} + ldmia r0!, {r2-r8,r10} + stmia r1!, {r2-r8,r10} +#endif + bx lr + +ENDPROC(relocate_vectors) + +/* * void relocate_code(addr_moni) * * This function relocates the monitor code.@@ -54,34 +95,6 @@ fixnext: cmp r2, r3 blo fixloop - /* - * Relocate the exception vectors - */ -#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 - /* - * Copy the relocated exception vectors to the - * correct address - * CP15 c1 V bit gives us the location of the vectors: - * 0x00000000 or 0xFFFF0000. - */ - ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */ - mrc p15, 0, r2, c1, c0, 0 /* V bit (bit[13]) in CP15 c1 */ - ands r2, r2, #(1<< 13) - ldreq r1, =0x00000000 /* If V=0 */ - ldrne r1, =0xFFFF0000 /* If V=1 */ - ldmia r0!, {r2-r8,r10} - stmia r1!, {r2-r8,r10} - ldmia r0!, {r2-r8,r10} - stmia r1!, {r2-r8,r10} -#endif - relocate_done: #ifdef __XSCALE__
PATCH v3 2/2 imx: fix exception vectors relocation in imx27
In reply to Albert ARIBAUDQuoted 15 lines · Albert ARIBAUD
Commit
3ff46cc4fixed exception vectors setting in the general ARM case, by either copying the exception and indirect vector tables to normal (0x00000000) or high (0xFFFF0000) vectors address, or setting VBAR to U-Boot's base if applicable.i.MX27 SoC is ARM926E-JS, thus has only normal and high options, but does not provide RAM at
0xFFFF0000and has only ROM at0x00000000; it is therefore not possible to move or change its exception vectors.Besides, i.MX27 ROM code does provide an indirect vectors table but at a non-standard address and with the reset and reserved vectors missing.
Quoted 5 lines
Turn the current vector relocation code into a weak routine called after
relocate_codefrom crt0, and add strong version for i.MX27.Series-Cc: Heiko Schocher<[email protected]>
Quoted 189 lines
Signed-off-by Albert ARIBAUD<[email protected]>---
Changes in v3:
- Fixed AGAIN wrong i.MX27 vector relocation codeChanges in v2:
- Fixed wrong i.MX27 vector relocation codearch/arm/cpu/arm926ejs/mx27/Makefile | 4 ++ arch/arm/cpu/arm926ejs/mx27/relocate.S | 51 +++++++++++++++++++++++++ arch/arm/lib/crt0.S | 5 +++ arch/arm/lib/relocate.S | 69 ++++++++++++++++++++-------------- 4 files changed, 101 insertions(+), 28 deletions(-)create mode 100644
arch/arm/cpu/arm926ejs/mx27/relocate.Sarch/arm/cpu/arm926ejs/mx27/Makefile +4
-0@@ -5,3 +5,7 @@ # SPDX-License-Identifier: GPL-2.0+ obj-y = generic.o reset.o timer.o + +ifndef CONFIG_SPL_BUILD +obj-y += relocate.o +endifarch/arm/cpu/arm926ejs/mx27/relocate.S new file +51
-0@@ -0,0 +1,51 @@ +/* + * relocate - i.MX27-specific vector relocation + * + * Copyright (c) 2013 Albert ARIBAUD<[email protected]> + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +#include<asm-offsets.h> +#include<config.h> +#include<linux/linkage.h> + +/* + * The i.MX27 SoC is very specific with respect to exceptions: it + * does not provide RAM at the high vectors address (0xFFFF0000), + * thus only the low address (0x00000000) is useable; but that is + * in ROM. Therefore, vectors cannot be changed at all. + * + * However, these ROM-based vectors actually just perform indirect + * calls through pointers located in RAM at SoC-specific addresses, + * as follows: + * + * Offset Exception Use by ROM code + * 0x00000000 reset indirect branch to [0x00000014] + * 0x00000004 undefined instruction indirect branch to [0xfffffef0] + * 0x00000008 software interrupt indirect branch to [0xfffffef4] + * 0x0000000c prefetch abort indirect branch to [0xfffffef8] + * 0x00000010 data abort indirect branch to [0xfffffefc] + * 0x00000014 (reserved in ARMv5) vector to ROM reset: 0xc0000000 + * 0x00000018 IRQ indirect branch to [0xffffff00] + * 0x0000001c FIQ indirect branch to [0xffffff04] + * + * In order to initialize exceptions on i.MX27, we must copy U-Boot's + * indirect (not exception!) vector table into 0xfffffef0..0xffffff04 + * taking care not to copy vectors number 5 (reserved exception). + */ + + .section .text.relocate_vectors,"ax",%progbits + +ENTRY(relocate_vectors) + + ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */ + ldr r1, =32 /* size of vector table */ + add r0, r0, r1 /* skip to indirect table */ + ldr r1, =0xFFFFFEF0 /* i.MX27 indirect table */ + ldmia r0!, {r2-r8} /* load indirect vectors 1..7 */ + stmia r1!, {r2-r5, r7,r8} /* write all but vector 5 */ + + bx lr + +ENDPROC(relocate_vectors)arch/arm/lib/crt0.S +5
-0@@ -104,6 +104,11 @@ clr_gd: ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */ b relocate_code here: +/* + * now relocate vectors + */ + + bl relocate_vectors /* Set up final (full) environment */arch/arm/lib/relocate.S +41
-28@@ -11,6 +11,47 @@ #include<linux/linkage.h> /* + * Default/weak exception vectors relocation routine + * + * This routine covers the standard ARM cases: normal (0x00000000), + * high (0xffff0000) and VBAR. SoCs which do not comply with any of + * the standard cases must provide their own, strong, version. + */ + + .section .text.relocate_vectors,"ax",%progbits + .weak relocate_vectors + +ENTRY(relocate_vectors) + +#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 + /* + * Copy the relocated exception vectors to the + * correct address + * CP15 c1 V bit gives us the location of the vectors: + * 0x00000000 or 0xFFFF0000. + */ + ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */ + mrc p15, 0, r2, c1, c0, 0 /* V bit (bit[13]) in CP15 c1 */ + ands r2, r2, #(1<< 13) + ldreq r1, =0x00000000 /* If V=0 */ + ldrne r1, =0xFFFF0000 /* If V=1 */ + ldmia r0!, {r2-r8,r10} + stmia r1!, {r2-r8,r10} + ldmia r0!, {r2-r8,r10} + stmia r1!, {r2-r8,r10} +#endif + bx lr + +ENDPROC(relocate_vectors) + +/* * void relocate_code(addr_moni) * * This function relocates the monitor code.@@ -54,34 +95,6 @@ fixnext: cmp r2, r3 blo fixloop - /* - * Relocate the exception vectors - */ -#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 - /* - * Copy the relocated exception vectors to the - * correct address - * CP15 c1 V bit gives us the location of the vectors: - * 0x00000000 or 0xFFFF0000. - */ - ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */ - mrc p15, 0, r2, c1, c0, 0 /* V bit (bit[13]) in CP15 c1 */ - ands r2, r2, #(1<< 13) - ldreq r1, =0x00000000 /* If V=0 */ - ldrne r1, =0xFFFF0000 /* If V=1 */ - ldmia r0!, {r2-r8,r10} - stmia r1!, {r2-r8,r10} - ldmia r0!, {r2-r8,r10} - stmia r1!, {r2-r8,r10} -#endif - relocate_done: #ifdef __XSCALE__
PATCH v3 2/2 imx: fix exception vectors relocation in imx27
In reply to Albert ARIBAUDHi Albert,
Quoted 15 lines · Albert ARIBAUD
Commit
3ff46cc4fixed exception vectors setting in the general ARM case, by either copying the exception and indirect vector tables to normal (0x00000000) or high (0xFFFF0000) vectors address, or setting VBAR to U-Boot's base if applicable.i.MX27 SoC is ARM926E-JS, thus has only normal and high options, but does not provide RAM at
0xFFFF0000and has only ROM at0x00000000; it is therefore not possible to move or change its exception vectors.Besides, i.MX27 ROM code does provide an indirect vectors table but at a non-standard address and with the reset and reserved vectors missing.
Quoted 8 lines
Turn the current vector relocation code into a weak routine called after
relocate_codefrom crt0, and add strong version for i.MX27.Series-Cc: Heiko Schocher <[email protected]>
Signed-off-by Albert ARIBAUD <[email protected]>---
Applied to u-boot-imx, thanks !
Best regards,
Stefano Babic
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================
v3 cover Fix SoC-specific exception handling
In reply to Albert ARIBAUDQuoted 3 lines · Albert ARIBAUD
* This patch was NOT tested on imx27lite, which is the only other i.MX27-based board AFAICT. The maintainer of imx27lite is Cc:ed on this series.
... or should have, if it had not been for my flaky patman-fu. Wolfgang, CC:ing you as said maintainer. CC:ing Heiko as the magnesium maintainer, too, although I guess testing on one of the two variants will be enough to validate the patch.
Amicalement,
Signature · 1 line
Albert.