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.
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.