On Fri, Apr 26, 2013 at 12:10 AM, Marek Vasut <ma...@denx.de> wrote: > Dear Otavio Salvador, > > [...] > >> > +/* >> > + * 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. >> > + */ >> >> 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.
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: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot