[U-Boot] ARM: interrupt_init before relocation, write fails

[Rob Herring <robherring2@gmail.com>]

On 11/05/2013 01:17 PM, Albert ARIBAUD wrote:
> Hi Rob,
> 
> On Tue, 5 Nov 2013 10:22:24 -0600, Rob Herring <robherring2@gmail.com>
> wrote:
> 
>> On Thu, Oct 24, 2013 at 4:37 PM, Andrew Ruder <andy@aeruder.net> 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,
>