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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
