| Message ID | 1420556808-26425-1-git-send-email-festevam@gmail.com |
|---|---|
| State | Accepted |
| Delegated to: | Tom Rini |
| Headers | show |
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!
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)