From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Herring Date: Tue, 05 Nov 2013 13:46:51 -0600 Subject: [U-Boot] ARM: interrupt_init before relocation, write fails In-Reply-To: <20131105201742.07a7d418@lilith> References: <20131024213724.GA16569@gmail.com> <20131105201742.07a7d418@lilith> Message-ID: <52794B2B.6010705@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 11/05/2013 01:17 PM, Albert ARIBAUD wrote: > Hi Rob, > > On Tue, 5 Nov 2013 10:22:24 -0600, Rob Herring > wrote: > >> On Thu, Oct 24, 2013 at 4:37 PM, Andrew Ruder wrote: >>> On Wed, Oct 23, 2013 at 11:41:45AM -0600, Joe Kulikauskas wrote: > > (putting back more context) > >>>> v2013.10-rc1 (and after) has a patch ( >>>> http://lists.denx.de/pipermail/u-boot/2013-June/156298.html) >>>> which sets up the abort stack before relocation. However, what >>>> I am seeing: IRQ_STACK_START_IN >>>> is in flash at that time, so this write fails. > > Hmm... Which one exactly is "this write"? The instructions below are > reads, not writes. > >>>> interrupt_init: >>>> FF0A0FA8 e59f3010 LDR R3,ff0a0fc0 >>>> (ff0a0050=IRQ_STACK_START_IN) >>> >>>> Before this patch, abort stack setup was done after relocation, so >>>> target location is in RAM and writeable. >>> >>>> interrupt_init: >>>> 9FFB4020 e59f3010 LDR R3,9ffb4038 >>>> (9ffb3054=IRQ_STACK_START_IN) >>> >>>> If I revert that patch, I don't see that problem. > > That problem only happens when there actually is an abort before > relocation, right? Not as I understand it. The address here is the address of the variable holding the stack address. So we are trying to write the stack address to flash which I guess does more that just get ignored. Rob > >>> FWIW, I am working on a PXA270 target, and have had to revert this patch >>> as well. I hadn't gotten around to tracking down where and why I was >>> crashing though so hadn't emailed in a bug report yet. Now seeing as >>> there's someone else now seeing it too I thought I would chime in with >>> a "me too". >>> >>> Rob: CC'd you since you were the author and might have some insight. >>> Full email in entirety below. >> >> Other than doing stack setup in a completely different way by setting >> the mode in the CPSR and setting up SP_irq and SP_abt directly, I >> don't see an easy fix. So we should revert this change. It works for >> me because I run from RAM before relocation. >> >> Albert or Tom, can you please revert commit 0f5141e9c57e96de11642a. > > I'm ok with reverting in the ARM repo (I'll PR to mainline after I get > Atmel and IMX in), as soon as I get a clear understanding of the exact > issue. > >> Rob > > Amicalement, >