[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,
I had one more look at this, please see my comments below.

On Wed, Jun 11, 2014 at 9:14 AM, Albert ARIBAUD
<albert.u.boot at aribaud.net> wrote:
> Hi Masahiro,
>
> (to: the board maintainers for enbw_cmc, da850evm_direct_nor, and
> calimain)
>
> On Mon, 09 Jun 2014 18:29:26 +0900, Masahiro Yamada
> <yamada.m at jp.panasonic.com> wrote:
>
>> Hi Albert,
>
>> You changed the behaviour of three boards,
>> "enbw_cmc", "da850evm_direct_nor", "calimain"!
>> Probably they are broken.
>>
>> These boards expects "0x00000011" (=CONFIG_SYS_DV_NOR_BOOT_CFG)
>> at the beginning of the image.
>> But since commit 41623c91, that is missing.
>>
>> If you still don't understand,  you should checkout   41623c91^ and
>> 41623c91 and compare u-boot.dis.
>
> Your description of the effects of my change is correct. However, this
> raises another question which I would like to see discussed before
> doing anything about these boards.
>
> Taking the last commit where the prefix word was actually emitted (that
> is, 41623c91^, which is actually 60a4f39f, "arm: remove unused _end_vect
> and _vectors_end symbols"), and reading arch/arm/cpu/arm926ejs/start.S,
> I see that the start of the image looks like this:
>
> offset   Content
> +0x0000  prefix word CONFIG_SYS_DV_NOR_BOOT_CFG
> +0x0004  reset vector
> +0x0008  undefined instruction vector
> +0x000c  software interrupt vector
> +0x0010  prefetch abort vector
> +0x0014  data abort vector
> +0x0018  unused
> +0x001c  irq vector
> +0x0020  fiq vector
> +0x0024  (end of vectors table)
>
> And that is /wrong/: the vectors table is misaligned by 4 bytes.

Let's have a look at the calimain board. The vector exception table of
this CPU (ARM926EJS) can be located either at 0x00000000 or at
0xffff0000 (depending on CONFIG_SYS_EXCEPTION_VECTORS_HIGH). This SoC
(Texas Instruments AM1808) has no physical memory at 0x00000000,
therefore CONFIG_SYS_EXCEPTION_VECTOR must be defined. The exception
vector table is located in the internal RAM of the device, that is
located at 0xffff0000.

However, CONFIG_SYS_TEXT_BASE is 0x60000000, that is the begin of NOR
flash memory on this device. Later, u-boot relocates itself to some
place DDR2 memory. So in the begin u-boot's vector table is located at
0x60000004. Later, it is relocated to somewhere in the DDR2 memory.
There is no code that actually touches the exception vector table at
0xffff0000. Exceptions are not used at all and therefore the location
of this table in memory is totally irrelevant.

What we actually need would be some code that copies the vector table
to the right location (0xffff0000). But this code could copy the table
from anywhere, so I don't understand why the
CONFIG_SYS_DV_NOR_BOOT_CFG word would disturb the alignment of the
table.

If we accept that we do not use any exceptions we could either restore
the old behavior:

--- a/arch/arm/lib/vectors.S
+++ b/arch/arm/lib/vectors.S
@@ -13,6 +13,8 @@
  * SPDX-License-Identifier:    GPL-2.0+
  */

+#include <config.h>
+
 /*
  *************************************************************************
  *
@@ -49,7 +51,6 @@ _start:
        .word   CONFIG_SYS_DV_NOR_BOOT_CFG
 #endif

-_start:
        ldr     pc, _reset


>
> Obviously, the boards have been working fine for a long time, because
> no exception vector was used apparently (or because when exceptions did
> happen, the error was debugged without the need to analyze the
> exception).
>
> I suspect we could just remove the '.word CONFIG_SYS_DV_NOR_BOOT_CFG'
> line from the vectors.S file and prepend the word to the image /after/
> linking.

Or we could remove .word CONFIG_SYS_DV_NOR_BOOT_CFG as you suggested
and later add the word after linking. But for this case we should be
able to set CONFIG_SYS_TEXT_BASE to 0x60000004. But due to the .align
5 statements below in arch/arm/lib/vectors.S this leads to a padding
at the start of u-boot.bin, since the entire .vectors section will be
aligned to 32 bytes:

 hexdump -C u-boot.bin
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 18 f0 9f e5  |................|
00000020  18 f0 9f e5 18 f0 9f e5  18 f0 9f e5 18 f0 9f e5  |................|

Now the ldr pc, _reset is at the wrong location, u-boot does not boot.

Am I missing something here? What would be the preferred solution to
make the board working again?

Best regards,
Christian