arm: mxs: Fix vectoring table crafting

PATCH New Marek Vasut 4 participants 7 messages Apr 26, 2013 – Jun 3, 2013

Subsystems (2)

Arm (32-bit) Arm i.MX and Layerscape

lore

Share & tools

lore

Marek Vasut

author

2013-04-26 02:37 UTC #0 lore raw

PATCH 1/1 arm: mxs: Fix vectoring table crafting

The vectoring table has to be placed at 0x0, but U-Boot on MX23/MX28 starts from RAM, so the vectoring table at 0x0 is not present. Craft code that will be placed at 0x0 and will redirect interrupt vectoring to proper location of the U-Boot in RAM.

Signed-off-by Marek Vasut <[email protected]>

CC Stefano Babic <[email protected]>

CC Fabio Estevam <[email protected]>

---
 arch/arm/cpu/arm926ejs/mxs/mxs.c |   25 ++++++++++++++++++++++---
 1 file changed, 22 insertions(+), 3 deletions(-)

arch/arm/cpu/arm926ejs/mxs/mxs.c +22 -3

index e2b4196..600e2a8 100644
@@ -139,13 +139,32 @@ int mxs_reset_block(struct mxs_register_32 *reg)
 	return 0;
 }
 
+/*
+ * This function will craft a jumptable at 0x0 which will redirect interrupt
+ * vectoring to proper location of U-Boot in RAM.
+ *
+ * The structure of the jumptable will be as follows:
+ *  ldr pc, [pc, #0x18] ..... for each vector, thus repeated 8 times
+ *  <destination address> ... for each previous ldr, thus also repeated 8 times
+ *
+ * The "ldr pc, [pc, #0x18]" instruction above loads address from memory at
+ * offset 0x18 from current value of PC register. Note that PC is already
+ * incremented by 4 when computing the offset, so the effective offset is
+ * actually 0x20, this the associated <destination address>. Loading the PC
+ * register with an address performs a jump to that address.
+ */
 void mx28_fixup_vt(uint32_t start_addr)
 {
-	uint32_t *vt = (uint32_t *)0x20;
+	/* ldr pc, [pc, #0x18] */
+	const uint32_t ldr_pc = 0xe59ff018;
+	/* Jumptable location is 0x0 */
+	uint32_t *vt = (uint32_t *)0x0;
 	int i;
 
-	for (i = 0; i < 8; i++)
-		vt[i] = start_addr + (4 * i);
+	for (i = 0; i < 8; i++) {
+		vt[i] = ldr_pc;
+		vt[i + 8] = start_addr + (4 * i);
+	}
 }
 
 #ifdef	CONFIG_ARCH_MISC_INIT

Signature · 1 line

1.7.10.4

Otavio Salvador

2013-04-26 03:05 UTC #1 lore raw

PATCH 1/1 arm: mxs: Fix vectoring table crafting

Quoted 8 lines · Marek Vasut

The vectoring table has to be placed at 0x0, but U-Boot on MX23/MX28 starts from RAM, so the vectoring table at 0x0 is not present. Craft code that will be placed at 0x0 and will redirect interrupt vectoring to proper location of the U-Boot in RAM.
Signed-off-by Marek Vasut <[email protected]>
CC Stefano Babic <[email protected]>
CC Fabio Estevam <[email protected]>

Please always Cc me in 'mxs' patches.

Quoted 6 lines

+/*
+ * This function will craft a jumptable at 0x0 which will redirect interrupt
+ * vectoring to proper location of U-Boot in RAM.
+ *
+ * The structure of the jumptable will be as follows:
+ * ldr pc, [pc, #0x18] ..... for each vector, thus repeated 8 times

Quoted 8 lines

+ * <destination address> ... for each previous ldr, thus also repeated 8 times
+ *
+ * The "ldr pc, [pc, #0x18]" instruction above loads address from memory at
+ * offset 0x18 from current value of PC register. Note that PC is already
+ * incremented by 4 when computing the offset, so the effective offset is
+ * actually 0x20, this the associated <destination address>. Loading the PC
+ * register with an address performs a jump to that address.
+ */

I understood what you're doing but not the motivation for it. What problem you're fixing or feature this will allow?

--
Otavio Salvador O.S. Systems
E-mail: otavio at ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br

Marek Vasut

author

2013-04-26 03:10 UTC #2 lore raw

PATCH 1/1 arm: mxs: Fix vectoring table crafting

Dear Otavio Salvador,

[...]

Quoted 16 lines

Quoted 7 lines
+/*
+ * This function will craft a jumptable at 0x0 which will redirect interrupt + * vectoring to proper location of U-Boot in RAM.
+ *
+ * The structure of the jumptable will be as follows:
+ * ldr pc, [pc, #0x18] ..... for each vector, thus repeated 8 times
+ * <destination address> ... for each previous ldr, thus also repeated
Quoted 8 lines
8 times + *
+ * The "ldr pc, [pc, #0x18]" instruction above loads address from memory at + * offset 0x18 from current value of PC register. Note that PC is already + * incremented by 4 when computing the offset, so the effective offset is + * actually 0x20, this the associated <destination address>. Loading the PC + * register with an address performs a jump to that address.
+ */

Quoted 2 lines

I understood what you're doing but not the motivation for it. What problem you're fixing or feature this will allow?

In case the CPU core gets and interrupt (data abort, invalid instruction...), the CPU will jump to 0x0. It is imperative for handling code to be present at 0x0, but since U-Boot on MXS is started from RAM, only remnants of SPL are present at 0x0. Any core interrupt will then hit those remnants and cause undefined behavior. This patch puts redirection table there which in turn jumps to U-Boot vectoring entry points in RAM ... but this is all in the commit message already, so dunno if that helps you.

Best regards,
Marek Vasut

Otavio Salvador

2013-04-26 03:20 UTC #3 lore raw

PATCH 1/1 arm: mxs: Fix vectoring table crafting

Quoted 23 lines · Marek Vasut

Dear Otavio Salvador,
[...]
Quoted 16 lines
Quoted 7 lines
+/*
+ * This function will craft a jumptable at 0x0 which will redirect interrupt + * vectoring to proper location of U-Boot in RAM.
+ *
+ * The structure of the jumptable will be as follows:
+ * ldr pc, [pc, #0x18] ..... for each vector, thus repeated 8 times
+ * <destination address> ... for each previous ldr, thus also repeated
Quoted 8 lines
8 times + *
+ * The "ldr pc, [pc, #0x18]" instruction above loads address from memory at + * offset 0x18 from current value of PC register. Note that PC is already + * incremented by 4 when computing the offset, so the effective offset is + * actually 0x20, this the associated <destination address>. Loading the PC + * register with an address performs a jump to that address.
+ */
Quoted 2 lines
I understood what you're doing but not the motivation for it. What problem you're fixing or feature this will allow?

Quoted 7 lines

In case the CPU core gets and interrupt (data abort, invalid instruction...), the CPU will jump to 0x0. It is imperative for handling code to be present at 0x0, but since U-Boot on MXS is started from RAM, only remnants of SPL are present at 0x0. Any core interrupt will then hit those remnants and cause undefined behavior. This patch puts redirection table there which in turn jumps to U-Boot vectoring entry points in RAM ... but this is all in the commit message already, so dunno if that helps you.

Much clear now. Did you actually tested this in MX23 as well? How did you simulated the exception to test it?

--
Otavio Salvador O.S. Systems
E-mail: otavio at ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br

Marek Vasut

author

2013-04-26 12:08 UTC #4 lore raw

PATCH 1/1 arm: mxs: Fix vectoring table crafting

Dear Otavio Salvador,

Quoted 33 lines · Marek Vasut

Quoted 23 lines
Dear Otavio Salvador,
[...]
Quoted 16 lines
Quoted 7 lines
+/*
+ * This function will craft a jumptable at 0x0 which will redirect interrupt + * vectoring to proper location of U-Boot in RAM.
+ *
+ * The structure of the jumptable will be as follows:
+ * ldr pc, [pc, #0x18] ..... for each vector, thus repeated 8 times
+ * <destination address> ... for each previous ldr, thus also
Quoted 8 lines
repeated 8 times + *
+ * The "ldr pc, [pc, #0x18]" instruction above loads address from memory at + * offset 0x18 from current value of PC register. Note that PC is already + * incremented by 4 when computing the offset, so the effective offset is + * actually 0x20, this the associated <destination address>. Loading the PC + * register with an address performs a jump to that address.
+ */
Quoted 2 lines
I understood what you're doing but not the motivation for it. What problem you're fixing or feature this will allow?
Quoted 8 lines
In case the CPU core gets and interrupt (data abort, invalid instruction...), the CPU will jump to 0x0. It is imperative for handling code to be present at 0x0, but since U-Boot on MXS is started from RAM, only remnants of SPL are present at 0x0. Any core interrupt will then hit those remnants and cause undefined behavior. This patch puts redirection table there which in turn jumps to U-Boot vectoring entry points in RAM ... but this is all in the commit message already, so dunno if that helps you.

Quoted 1 line

Much clear now. Did you actually tested this in MX23 as well?

No, it is not needed, but you can test it if it'd make you feel better. The ARM core is the same in both, so is the memory map for DRAM and SRAM.

Quoted 2 lines

How did
you simulated the exception to test it?

Try "md.l 0x1" or "go 0x20", they'll cause either dabt or invalid instruction.

Best regards,
Marek Vasut

Fabio Estevam

reviewer

2013-04-26 20:32 UTC #5 lore raw

PATCH 1/1 arm: mxs: Fix vectoring table crafting

In reply to Marek Vasut

Quoted 8 lines · Marek Vasut

The vectoring table has to be placed at 0x0, but U-Boot on MX23/MX28 starts from RAM, so the vectoring table at 0x0 is not present. Craft code that will be placed at 0x0 and will redirect interrupt vectoring to proper location of the U-Boot in RAM.
Signed-off-by Marek Vasut <[email protected]>
CC Stefano Babic <[email protected]>
CC Fabio Estevam <[email protected]>

On a mx23evk:

Tested-by Fabio Estevam <[email protected]>

Stefano Babic

2013-06-03 10:50 UTC #6 lore raw

PATCH 1/1 arm: mxs: Fix vectoring table crafting

In reply to Marek Vasut

Quoted 9 lines · Marek Vasut

The vectoring table has to be placed at 0x0, but U-Boot on MX23/MX28 starts from RAM, so the vectoring table at 0x0 is not present. Craft code that will be placed at 0x0 and will redirect interrupt vectoring to proper location of the U-Boot in RAM.
Signed-off-by Marek Vasut <[email protected]>
CC Stefano Babic <[email protected]>
CC Fabio Estevam <[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
=====================================================================