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

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

[Felix Radensky]

Hi Ira,

On 11/10/2011 10:00 PM, Felix Radensky 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".
>
> 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.
>
> 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").
>
> 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
>
> As an alternative, reverting the commit causes my board to work again.
> The CCSRBAR is relocated correctly.
>
> 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"?
>
> Thanks,
> Ira
>

I have P2020DS and can test it. Which configuration exactly, P2020DS or
P2020DS_SDCARD ?

Felix.

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

[Ira W. Snyder]

On Thu, Nov 10, 2011 at 10:07:41PM +0200, Felix Radensky wrote:
> Hi Ira,
> 
> On 11/10/2011 10:00 PM, Felix Radensky 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".
> >
> > 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.
> >
> > 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").
> >
> > 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
> >
> > As an alternative, reverting the commit causes my board to work again.
> > The CCSRBAR is relocated correctly.
> >
> > 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"?
> >
> > Thanks,
> > Ira
> >
> 
> I have P2020DS and can test it. Which configuration exactly, P2020DS or
> P2020DS_SDCARD ?
> 

The issue I've had with CCSR relocation has been fixed by Timur's
patchset titled "powerpc/85xx: fix definition of MAS register macros".
So you don't really need to test this.

If you'd like to test it anyway, use P2020DS_SDCARD, where you use the
boot_format tool + configuration file to write the U-Boot image to the
SD card. It should be booting with the help of the Freescale On-Chip
ROM.

Thanks,
Ira

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

[Ira W. Snyder]

On Thu, Nov 10, 2011 at 01:49:20PM -0600, Timur Tabi wrote:
> Ira W. Snyder wrote:
> 
> > I boot using the on-chip ROM, loading U-Boot from SD card to DDR.
> 
> The on-chip creates a 4GB TLB, which breaks the CCSR code.  My five-patch patchset fixes this.
> 

Yep, that worked. I applied the patchset starting with "powerpc/85xx:
fix definition of MAS register macros", and it now works, with
relocation.

I'll post a v3 of my board port shortly. The v2 removed relocation,
which didn't work against the top of tree code.

Thanks everyone!

Ira

> -- 
> Timur Tabi
> Linux kernel developer at Freescale
> 
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

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

[Timur Tabi]

Ira W. Snyder wrote:

> I boot using the on-chip ROM, loading U-Boot from SD card to DDR.

The on-chip creates a 4GB TLB, which breaks the CCSR code.  My five-patch patchset fixes this.

-- 
Timur Tabi
Linux kernel developer at Freescale

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

[Ira W. Snyder]

On Thu, Nov 10, 2011 at 07:24:00PM +0000, McClintock Matthew-B29882 wrote:
> On Thu, Nov 10, 2011 at 11:47 AM, Timur Tabi <timur@freescale.com> wrote:
> >> 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.
> 
> Timur,
> 
> Did you test your CCSRBAR changes with a board that uses the on chip
> rom as well as L2SRAM to boot? Does the COME board load from SDCARD to
> DDR or to L2SRAM? I suspect it's L2SRAM since this board has 512kB
> which is large enough for a stock u-boot image.
> 

I boot using the on-chip ROM, loading U-Boot from SD card to DDR. The
configuration file I was provided for boot_format-1.0.0 uses DDR, so it
is what I have continued to use. I remember seeing a comment somewhere
saying that the L2 doesn't work on P2020 due to some hardware problem,
though I cannot find that comment at the moment.

My configuration for boot_format is attached. The configuration is
described in the P2020RM (section 4.5) and Freescale Document Number
AN3659, titled "Booting from On-Chip ROM (eSHDC or eSPI)" section 2.5.1.

My configuration is attached. I'm happy to test using the L2SRAM
instead, if I can figure out what to change in the attached
configuration file.

Thanks,
Ira
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config_sram_blackadder2020.dat
Type: chemical/x-mopac-input
Size: 1697 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111110/17258d5f/attachment.mopcrt 

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

[Timur Tabi]

McClintock Matthew-B29882 wrote:
> Did you test your CCSRBAR changes with a board that uses the on chip
> rom as well as L2SRAM to boot?

No, just the on-chip ROM.  Kumar later noticed that NAND booting was broken, so I fixed that too.  That's why I'm saying the latest set of patches should fix it for everyone.  

I didn't consider the combination of multi-stage with SRAM, but since normal U-Boot runs from SRAM first, I expect that to work as well.

> Does the COME board load from SDCARD to
> DDR or to L2SRAM? I suspect it's L2SRAM since this board has 512kB
> which is large enough for a stock u-boot image.

Ira says that early boot loader sets of DDR, so I presume it's running from that, not SRAM.

-- 
Timur Tabi
Linux kernel developer at Freescale

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

[McClintock Matthew-B29882]

On Thu, Nov 10, 2011 at 11:47 AM, Timur Tabi <timur@freescale.com> wrote:
>> 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.

Timur,

Did you test your CCSRBAR changes with a board that uses the on chip
rom as well as L2SRAM to boot? Does the COME board load from SDCARD to
DDR or to L2SRAM? I suspect it's L2SRAM since this board has 512kB
which is large enough for a stock u-boot image.

-M

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

[Timur Tabi]

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] Is CCSRBAR relocation broken on P2020?

[Ira W. Snyder]

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] Is CCSRBAR relocation broken on P2020?

[Timur Tabi]

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

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

[Ira W. Snyder]

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

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.

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

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

As an alternative, reverting the commit causes my board to work again.
The CCSRBAR is relocated correctly.

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

Thanks,
Ira