[U-Boot] Is CCSRBAR relocation broken on P2020?

[Timur Tabi <timur@freescale.com>]

Ira W. Snyder wrote:
> 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 see NAND here:

+P2020COME_NAND               powerpc     mpc85xx     p2020come           freescale      -           P2020COME:NAND

> 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?

I think that qualifies as multi-stage booting.  The SD card is not mapped at address fff00000 at POR time, which is needed to boot a single-stage U-Boot.  Therefore, you must have a multi-stage U-Boot.

I'm not familiar with boot_format-1.0.0, but my guess is that it creates the pre-boot loader.

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

CCSR relocation is required for a 36-bit build, but if you don't need to support that, then I recommend you avoid relocation.  

If your device tree isn't set in stone, now would be a great time to change it.

> I'll look at Kumar's DTS changes. I saw them on the Linux PPC ML.

Kumar just posted a bunch more a few minutes ago.

>>> 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

You need to figure out what this boot utility does.  It might create a 4GB TLB, or it might relocate CCSR.  I have a fix for the 4GB TLB problem that was posted recently.  If that boot relocates CCSR, then the boot_format tool needs to be fixed.

> - 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

Well, THAT is a multi-stage boot.  A single-stage boot is when the first instruction that the core executes on POR is in your u-boot.bin, and that u-boot.bin is the only version of U-Boot that is loaded.  This is true only when booting from NOR flash.

> Only one U-Boot is ever executed.

But it isn't the first code to be executed.  That's what I'm talking about.

> I understand that. Has the current top of tree been tested on P2020DS?

Well, I didn't test EVERY board, and I did find some problems with some boards that I fixed recently.  If you add all the patches that Kumar and I posted, everything should work (assuming boot_format doesn't relocate CCSR).

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

I tested my code on the P1022DS, which is similar.

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

powerpc/85xx: Fix NAND SPL support
powerpc/85xx: Fix MPC8572DS NAND build

Then there's a five-patch set from my posted on 10/31 that Kumar recently applied to his repository.

-- 
Timur Tabi
Linux kernel developer at Freescale