[U-Boot] [PATCH v2] mx25: Fix boot hang by avoiding vector relocation

From: Fabio Estevam fabio.estevam@freescale.com
Since commit 3ff46cc42b9d73d0 ("arm: relocate the exception vectors") mx25pdk hangs like this:
CPU: Freescale i.MX25 rev1.2 at 399 MHz Reset cause: WDOG Board: MX25PDK I2C: ready DRAM: 64 MiB (hangs)
Add a specific relocate_vectors macro that skips the vector relocation, as the i.MX25 SoC does not provide RAM at the high vectors address (0xFFFF0000), and (0x00000000) maps to ROM.
This allows mx25 to boot again.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com --- Changes since v1: - Skip the vector relocation on mx25
arch/arm/cpu/arm926ejs/mx25/Makefile | 4 ++++ arch/arm/cpu/arm926ejs/mx25/relocate.S | 23 +++++++++++++++++++++++ 2 files changed, 27 insertions(+) create mode 100644 arch/arm/cpu/arm926ejs/mx25/relocate.S
diff --git a/arch/arm/cpu/arm926ejs/mx25/Makefile b/arch/arm/cpu/arm926ejs/mx25/Makefile index 134c69d..ebc0407 100644 --- a/arch/arm/cpu/arm926ejs/mx25/Makefile +++ b/arch/arm/cpu/arm926ejs/mx25/Makefile @@ -5,3 +5,7 @@ # SPDX-License-Identifier: GPL-2.0+
obj-y = generic.o timer.o reset.o + +ifndef CONFIG_SPL_BUILD +obj-y += relocate.o +endif diff --git a/arch/arm/cpu/arm926ejs/mx25/relocate.S b/arch/arm/cpu/arm926ejs/mx25/relocate.S new file mode 100644 index 0000000..8ebb81f --- /dev/null +++ b/arch/arm/cpu/arm926ejs/mx25/relocate.S @@ -0,0 +1,23 @@ +/* + * relocate - i.MX25-specific vector relocation + * + * Copyright (c) 2013 Albert ARIBAUD albert.u.boot@aribaud.net + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +#include <linux/linkage.h> + +/* + * The i.MX25 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, so let's avoid relocating the vectors. + */ + .section .text.relocate_vectors,"ax",%progbits + +ENTRY(relocate_vectors) + + bx lr + +ENDPROC(relocate_vectors)

On Tue, Jan 06, 2015 at 01:06:48PM -0200, Fabio Estevam wrote:
From: Fabio Estevam fabio.estevam@freescale.com
Since commit 3ff46cc42b9d73d0 ("arm: relocate the exception vectors") mx25pdk hangs like this:
CPU: Freescale i.MX25 rev1.2 at 399 MHz Reset cause: WDOG Board: MX25PDK I2C: ready DRAM: 64 MiB (hangs)
Add a specific relocate_vectors macro that skips the vector relocation, as the i.MX25 SoC does not provide RAM at the high vectors address (0xFFFF0000), and (0x00000000) maps to ROM.
This allows mx25 to boot again.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com
I'd like to pull this in for the release. I'd also really like someone else to ack or otherwise comment on this (and why this is more right than not just relocating the vectors as v1 did, I see both boot to a U-Boot prompt but shouldn't we do a bit more testing to confirm that we don't need to relocate these exception vectors or have we now introduced some subtle breakage (or perhaps not so subtle once you hit it) in these cases? Thanks!

On Tue, Jan 06, 2015 at 01:06:48PM -0200, Fabio Estevam wrote:
From: Fabio Estevam fabio.estevam@freescale.com
Since commit 3ff46cc42b9d73d0 ("arm: relocate the exception vectors") mx25pdk hangs like this:
CPU: Freescale i.MX25 rev1.2 at 399 MHz Reset cause: WDOG Board: MX25PDK I2C: ready DRAM: 64 MiB (hangs)
Add a specific relocate_vectors macro that skips the vector relocation, as the i.MX25 SoC does not provide RAM at the high vectors address (0xFFFF0000), and (0x00000000) maps to ROM.
This allows mx25 to boot again.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com
On 8 Jan 2015, trini@ti.com wrote:
I'd like to pull this in for the release. I'd also really like someone else to ack or otherwise comment on this (and why this is more right than not just relocating the vectors as v1 did, I see both boot to a U-Boot prompt but shouldn't we do a bit more testing to confirm that we don't need to relocate these exception vectors or have we now introduced some subtle breakage (or perhaps not so subtle once you hit it) in these cases? Thanks!
Acked-By: Bill Pringlemeir bpringlemeir@nbsps.com
The addresses in v1 of the patch are for the imx27. The will do nothing for the imx25. On the imx25, the address 0x0 is ROM and will BUS error on a write (default without any patch). The address 0xffff0000 is mapped to a WEIM peripheral (external Addr+Data w chip select) and writes there will not BUS error (so v1 patch works). However, it is misleading as the real 'hook' vectors are located in IRAM (0x78xxxxxx); it is very similar in concept to imx27. It is better just to provide a stub that does nothing than misleading people to think they are hooked.
The HAB code on the iMX25 ROM has some vectors installed so that any errors will reset or go to serial boot mode. This is what this platform has done all along. The most correct way would be to hook the vectors, but the hook addresses are only in an NDA doc and would require some testing, etc. because even that document is not 100% clear.
Fwiw, Bill Pringlemeir.

On Thu, Jan 08, 2015 at 10:10:45AM -0500, Bill Pringlemeir wrote:
On Tue, Jan 06, 2015 at 01:06:48PM -0200, Fabio Estevam wrote:
From: Fabio Estevam fabio.estevam@freescale.com
Since commit 3ff46cc42b9d73d0 ("arm: relocate the exception vectors") mx25pdk hangs like this:
CPU: Freescale i.MX25 rev1.2 at 399 MHz Reset cause: WDOG Board: MX25PDK I2C: ready DRAM: 64 MiB (hangs)
Add a specific relocate_vectors macro that skips the vector relocation, as the i.MX25 SoC does not provide RAM at the high vectors address (0xFFFF0000), and (0x00000000) maps to ROM.
This allows mx25 to boot again.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com
On 8 Jan 2015, trini@ti.com wrote:
I'd like to pull this in for the release. I'd also really like someone else to ack or otherwise comment on this (and why this is more right than not just relocating the vectors as v1 did, I see both boot to a U-Boot prompt but shouldn't we do a bit more testing to confirm that we don't need to relocate these exception vectors or have we now introduced some subtle breakage (or perhaps not so subtle once you hit it) in these cases? Thanks!
Acked-By: Bill Pringlemeir bpringlemeir@nbsps.com
Applied to u-boot/master and thanks for the details!
participants (3)
-
Bill Pringlemeir
-
Fabio Estevam
-
Tom Rini