From: Timur Tabi <timur@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Is CCSRBAR relocation broken on P2020?
Date: Thu, 10 Nov 2011 11:12:41 -0600 [thread overview]
Message-ID: <4EBC0609.2030709@freescale.com> (raw)
In-Reply-To: <20111110165447.GA1801@ovro.caltech.edu>
Ira W. Snyder wrote:
> Hello Timur, Kumar, U-Boot List,
>
> I'm working on porting U-Boot to the Freescale P2020 COM-Express board.
> See the ML post from 2011-09-27 titled "[PATCH 0/2] mpc85xx: support for
> Freescale COM Express P2020".
I see that you are using a NAND boot, which is a multi-stage boot. There are some problems with that that have been fixed in recent patches posted by me and Kumar to the U-boot mailing list.
In particular, one patches puts U-boot into an infinite loop if CCSR is relocated in the wrong step.
> When it was posted, the port was working on the top of tree U-Boot. This
> included relocation of the CCSRBAR from the power on location of
> 0xff700000 to 0xffe00000.
Is there a reason why you want to relocate CCSR at all? Everything would be a lot easier if you just left it at the default location. I have a suspicion that many boards relocate CCSR just for the heck of it.
However, Kumar's recent rework of the device trees may force all P2020 boards to have the same CCSR, so you might be stuck.
> Today I updated U-Boot to top of tree to address the comments in the
> initial mailing list posting. Upon attempting to boot the board, I get
> no console output. I have traced this to commit 6ca88b0958
> ("powerpc/85xx: relocate CCSR before creating the initial RAM area").
This patch requires that only the last stage of U-Boot (i.e. the "real" U-Boot) relocate CCSR. All previous stages must not relocate CCSR. This is a change from the way we were doing things in the past.
> Indeed, making sure that the code does not run by adding the following
> to my board config file causes U-Boot to start correctly. Though the
> CCSRBAR is not relocated, as expected.
>
> #define CONFIG_SYS_CCSR_DO_NOT_RELOCATE
If you set this macro and your DTS puts CCSR at 0xffe00000, then you won't be able to boot Linux (or any OS that uses the device tree).
> As an alternative, reverting the commit causes my board to work again.
> The CCSRBAR is relocated correctly.
The new CCSR relocation method is needed to standardize the way we handle that task and to support future SOCs that require CCSR to be relocated earlier in the boot process. I admit that it can sneak up on people, like it did for you, but the new approach is necessary. In the end, it will make everything a lot easier.
> The P2020DS board is very similar to the board I am using. It performs
> the same relocation of the CCSRBAR that I want to use as well. Does
> anyone have a P2020DS that they can test with the current top of tree
> U-Boot? Does it boot? Can you send the output of "md ffe00000 1"?
Kumar recently posted a patch that fixes the relocation on multi-stage U-Boots (e.g. NAND booting, SPI booting, etc). I also posted a patchset last week that fixes a few problems with
--
Timur Tabi
Linux kernel developer at Freescale
next prev parent reply other threads:[~2011-11-10 17:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-10 16:54 [U-Boot] Is CCSRBAR relocation broken on P2020? Ira W. Snyder
2011-11-10 17:12 ` Timur Tabi [this message]
2011-11-10 17:33 ` Ira W. Snyder
2011-11-10 17:47 ` Timur Tabi
2011-11-10 19:24 ` McClintock Matthew-B29882
2011-11-10 19:28 ` Timur Tabi
2011-11-10 19:46 ` Ira W. Snyder
2011-11-10 19:49 ` Timur Tabi
2011-11-10 19:59 ` Ira W. Snyder
[not found] <4EBC2D50.5070200@embedded-sol.com>
2011-11-10 20:07 ` Felix Radensky
2011-11-10 20:48 ` Ira W. Snyder
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=4EBC0609.2030709@freescale.com \
--to=timur@freescale.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