From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Riesch Date: Wed, 18 Jun 2014 14:55:47 +0200 Subject: [U-Boot] enbw_cmc, da850evm_direct_nor, and calimain vectors table misaligned (was: [PATCH] arm: fix a build error with CONFIG_USE_IRQ) In-Reply-To: References: <20140609163656.95BE.AA925319@jp.panasonic.com> <20140609182926.95C2.AA925319@jp.panasonic.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 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 > 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 + /* ************************************************************************* * @@ -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