[U-Boot] enbw_cmc, da850evm_direct_nor, and calimain vectors table misaligned

[Christian Riesch]

Hi all,

On Wed, Jun 11, 2014 at 9:47 AM, Heiko Schocher <hs at denx.de> wrote:
> Hello Albert,
>
> Am 11.06.2014 09:14, schrieb Albert ARIBAUD:
>>
>> 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.
>>
>> 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).

Probably a bit of both ;-)

I don't know much about exceptions, so maybe this is just stupid, but:
I had a look at some ARM documentation (and the datasheets of the
AM1808 that is used on the calimain board). According to these, the
exception vector table of this CPU is located at 0xffff0000. I had a
look at the memory there, and the content of this table seems to be
branches to the ROM bootloader located at 0xfffd0000. So my question
is: Are we actually setting up the ARM's exception table for this
device? And if yes, where is this done in the code?

>> 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.

Yes, I think this would be the right way to do it.

>> This, of course, requires confirmation from maintainers.
>>
>> Manfred, Christian, Sudhakar, Heiko: can any one of you let us know the
>> reason for this signature word exactly, and how exactly it is used by
>> the board? Ideally, can you also:
>
>
> See "AM18xx Bootloader Application Report":
> http://www.ti.com/lit/pdf/spraba5
>
> Section "3.1 NOR Boot" on page 3ff
>
> This word is used to setup some settings ...

Exactly. 0x60000000 is the start of the NOR flash. 0x00000011 as the
first word tells the ROM bootloader to use the "Direct NOR boot"
method, i.e. to branch to 0x60000004, which is the start of u-boot.
u-boot then relocates itself to RAM.

>
>> - test a current build (which does not have the signature word) and
>>    confirm it fails to load);

I tested a current build for calimain, and yes, it fails to load.

>>
>> - test the same build with the 4-byte signature manually prepended
>>    (this may possibly require padding the image);

No, this didn't work, I guess because the relocation offsets are wrong
now. I tried to set CONFIG_SYS_TEXT_BASE in include/configs/calimain.h
to 0x60000004, but this resulted in some strange padding (28 bytes set
to 0x00 prepend the u-boot image) which I currently don't understand.

Christian