[U-Boot] enbw_cmc, da850evm_direct_nor, and calimain vectors table misaligned (was: [PATCH] arm: fix a build error with CONFIG_USE_IRQ)

[Christian Riesch]

Hi Albert,

On Fri, Jul 4, 2014 at 10:35 PM, Albert ARIBAUD
<albert.u.boot at aribaud.net> wrote:
> Hi Christian,
>
> On Wed, 2 Jul 2014 15:45:17 +0200, Christian Riesch
> <christian.riesch at omicron.at> wrote:
>
>> Hello Albert,
>>
>> On Wed, Jun 18, 2014 at 2:55 PM, Christian Riesch
>> <christian.riesch at omicron.at> wrote:
>> > Am I missing something here? What would be the preferred solution to
>> > make the board working again?
>>
>> Any comments on this? What shall we do to get the boards working again?
>
> Sorry for the delay.
>
> My opinion is that for these boards, there should actually be *no*
> exception vectors at the start of the image, since it would never serve
> any purpose anyway unless as you suggest we copy the vectors table from
> the image to the actual vectors table location (or set the VBAR to the
> image vector table location for those targets which allow it).
>
> (and I don't think this is limited to the three boards discussed here.
> IOW, the current exception/interrupt system in ARM U-Boot is FUBAR.)
>
> As far as fixing the boards, Masahiro had posted a series where one
> patch fixed the issue. I NAKed the submission for several reasons; I
> had expected a followup (v3) which I failed to ping for.
>
> MAsahiro: do you have a v3 ready?

I assume you are talking about [1]. Adding this #include alone does
not solve the issue for the calimain board.

With adding the include, we would end up with

#include <config.h>

#ifdef CONFIG_SYS_DV_NOR_BOOT_CFG
        .word   CONFIG_SYS_DV_NOR_BOOT_CFG
#endif
_start:

        ldr     pc, _reset
...

in arch/arm/lib/vectors.S. As a result, __image_copy_start points to
0x60000000 (CONFIG_SYS_TEXT_BASE) and _start points is 0x60000004. The
relocation code in arch/arm/lib/relocate.S calculates its relocation
offset based on __image_copy_start. However, arch/arm/lib/board.c
calculates the offset as

gd->reloc_off = addr - (ulong)&_start;

As the two are different, we have different offsets for the relocation
code in relocate.S (based on __image_copy_start) and the calculation
of the lr register in arch/arm/lib/crt0.S (gd->reloc_off). After
relocation, the CPU jumps to the wrong address.

So we can either unify the offset calculation (which of the two is the
correct one?) or put the _start label where it was in earlier versions
of u-boot:

#include <config.h>

_start:
#ifdef CONFIG_SYS_DV_NOR_BOOT_CFG
        .word   CONFIG_SYS_DV_NOR_BOOT_CFG
#endif

        ldr     pc, _reset
...

What do you think?
Thanks, Christian

[1] http://lists.denx.de/pipermail/u-boot/2014-June/181334.html