From: Peter Tyser <ptyser@xes-inc.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] 85xx: Fix mapping of 0xfffffxxx when CONFIG_MP
Date: Tue, 07 Jul 2009 17:13:05 -0500 [thread overview]
Message-ID: <1247004785.11207.157.camel@localhost.localdomain> (raw)
In-Reply-To: <FF932971-B121-4758-91FB-BE29AE039162@kernel.crashing.org>
On Tue, 2009-07-07 at 16:59 -0500, Kumar Gala wrote:
> On Jul 7, 2009, at 1:43 PM, Peter Tyser wrote:
>
> > Previously, boot page translation was enabled while U-Boot executed.
> > This resulted in the address range 0xfffff000 - 0xffffffff being
> > translated to SDRAM which made the 0xfffffxxx address space unusable
> > for
> > other peripherals.
> >
> > This change disables boot page translation after the secondary CPU
> > cores
> > have been initialized which allows the 0xfffffxxx address space to be
> > properly accessed.
> >
> > Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> > ---
> > This was tested on the XPedite5370 which has flash mapped in the
> > 0xfffffxxx adddress space. I verified the flash was accessible
> > as expected and Linux properly brought up 2 cores.
> >
> > I wasn't sure how the MPC8572 handled caching with respect to the boot
> > page translation. I didn't add any cache flushes/invalidates, but
> > they
> > may be necessary if the 0xfffffxxx range is not mapped as uncachable.
> > Anyone at Freescale have any comments on this?
> >
> > Best,
> > Peter
>
> I'm concerned about this because we specifically avoid the 0xfffff000
> - 0xffffffff range since if we reset a core we want it to go through
> boot page translation. Can you explain what you are putting at that
> address?
Most of our boards (MPC8548, MPC8640, MPC8572-based) have two 128MB
flashes - 1 from 0xf0000000-0xf7f00000 and the other from 0xf8000000 -
0xffffffff. We've used this convention for a while, before we started
using MPC8572s.
U-Boot is always stored at in the flash at 0xfff80000 on the
MPC85xx-based boards we support. Thus I couldn't reprogram U-Boot when
CONFIG_MP was defined since the top 4K of flash was really accessing
SDRAM because of the boot page translation.
With this patch boot page translation is still used to bring up the
secondary cores on power on. This change just makes it so that boot
page translation is disabled after the other cores are brought up.
Best,
Peter
next prev parent reply other threads:[~2009-07-07 22:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-07 18:43 [U-Boot] [PATCH] 85xx: Fix mapping of 0xfffffxxx when CONFIG_MP Peter Tyser
2009-07-07 21:59 ` Kumar Gala
2009-07-07 22:13 ` Peter Tyser [this message]
2009-07-07 22:24 ` Kumar Gala
2009-07-07 22:38 ` Peter Tyser
2009-07-08 15:52 ` Kumar Gala
2009-07-08 16:25 ` Peter Tyser
2009-07-22 15:47 ` Peter Tyser
2009-07-23 15:07 ` Kumar Gala
2009-07-23 17:58 ` Peter Tyser
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=1247004785.11207.157.camel@localhost.localdomain \
--to=ptyser@xes-inc.com \
--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