From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Thu, 7 Nov 2013 10:15:02 +0100 Subject: [U-Boot] ARM: interrupt_init before relocation, write fails In-Reply-To: References: <20131024213724.GA16569@gmail.com> <20131105201742.07a7d418@lilith> <52794B2B.6010705@gmail.com> Message-ID: <20131107101502.25db21ac@lilith> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Joe, On Wed, 6 Nov 2013 09:18:53 -0700, Joe Kulikauskas wrote: > Hi, > > Rob, yes that's correct. > > To Albert's question: the disassembled instruction I had showed > LDR R3,ff0a0fc0 is load of r3 with address of the variable holding > the stack address; "this write" is the str which I've now copied in below. > IRQ_STACK_START_IN = gd->irq_sp + 8; > ff0a0fb0: e5992044 ldr r2, [r9, #68] ; 0x44 > ff0a0fb4: e2822008 add r2, r2, #8 > ff0a0fb8: e5832000 str r2, [r3] > > For my target, IIRC the write to flash caused problem in the flash > controller hardware, breaking further instruction fetches. On other > platforms the write to flash may fail silently. But the issue is that > interrupt_init() moving into board_init_f (i.e. before relocation) > generally just doesn't work right. > > Joe Thanks Rob and Joe for the clarification. Indeed interrupt_init() cannot execute before relocation as it sets globals. Further, interrupt_init() uses globals to communicate with start.S. This should be changed. I understand that is because the interrupt handlers actually set the interrupt stack when they are invoked -- and that is unnecessary; stacks should be set up as soon as their addresses are known. I'll revert the patch as soon as I finish getting the current PRs in. I have a start.S rewrite effort underway whcuh I should post soon. I'll add to it a change to the way stacks are initialized. Amicalement, -- Albert.