public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] ARM: interrupt_init before relocation, write fails
Date: Tue, 5 Nov 2013 20:17:42 +0100	[thread overview]
Message-ID: <20131105201742.07a7d418@lilith> (raw)
In-Reply-To: <CAL_JsqJ8twZRVwCC36C_qZ7NcTbujnzC+ARN7XhCGk0FS+KwAg@mail.gmail.com>

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?

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

  reply	other threads:[~2013-11-05 19:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-23 17:41 [U-Boot] ARM: interrupt_init before relocation, write fails Joe Kulikauskas
2013-10-24 21:37 ` Andrew Ruder
2013-11-05 16:22   ` Rob Herring
2013-11-05 19:17     ` Albert ARIBAUD [this message]
2013-11-05 19:46       ` Rob Herring
2013-11-06 16:18         ` Joe Kulikauskas
2013-11-07  9:15           ` Albert ARIBAUD

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131105201742.07a7d418@lilith \
    --to=albert.u.boot@aribaud.net \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox