[U-Boot] [PATCH] arm: mxs: Fix vectoring table crafting

Otavio Salvador otavio at ossystems.com.br
Fri Apr 26 05:20:10 CEST 2013


On Fri, Apr 26, 2013 at 12:10 AM, Marek Vasut <marex at 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: otavio at ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br


More information about the U-Boot mailing list