On Thu, Nov 10, 2011 at 11:12:41AM -0600, Timur Tabi wrote:
> 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.
>
I don't use NAND, nor any multi-stage boot (as far as I know).
I boot off of SDCARD (P2020COME_SDCARD_config). To write the U-Boot
image to the microSD card, I use a tool provided with the BSP called
"boot_format-1.0.0". Maybe you are familiar with it?
> > 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.
>
I relocate the CCSR because my device tree requires it. I wanted to use
the Linux arch/powerpc/boot/dts/p2020si.dtsi as a base, and override the
few things that are specific to this board. It requires the CCSR be
relocated to 0xffe00000.
I'll look at Kumar's DTS changes. I saw them on the Linux PPC ML.
> > 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.
>
I understand that. I only use one U-Boot. To the best of my knowledge,
boot on this platform works like this:
- power on
- the P2020 looks for the magic "BOOT" written by the boot_format tool
on the SD card
- the P2020 executes the instructions written by boot_format to setup
RAM correctly, load the U-Boot from the SD card to RAM, and then jumps
to it
- U-Boot runs, including relocating CCSR
Only one U-Boot is ever executed.
> > 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).
>
Of course. I have to get U-Boot working before I can boot any OS. This
was a way to test that the new code causes U-Boot to fail, nothing more.
It proved that there is something wrong with relocation on my board.
> > 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.
>
I understand that. Has the current top of tree been tested on P2020DS?
I'm looking for some assurance that the code I'm trying to use actually
works on a !CONFIG_FSL_CORENET platform which relocates the CCSR. One
in-tree example is the P2020DS.
> > 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
>
Can you tell me the subject lines of these patches? Even though I don't
use a multi-stage U-Boot, I'll check them out.
Thanks for the reply,
Ira
_______________________________________________
U-Boot mailing list
[email protected]
http://lists.denx.de/mailman/listinfo/u-boot
