Re: powerpc/85xx: p2020rdb - move the NAND address.

Re: powerpc/85xx: p2020rdb - move the NAND address.

[Sebastian Andrzej Siewior]

On 03/28/2012 10:30 PM, Bryan Hundven wrote:
>  > It is not at 0xffa00000. According to current u-boot source the NAND
>  > controller is always at 0xff800000 and it is either at CS0 or CS1
>  > depending on NAND or NAND+NOR mode. In 36bit mode it is shifted to
>  > 0xfff800000 but it has always an eight there and never an A.
>  >
>  > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>  > Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>
> I am having a hard time verifying this change. I don't think you are
> wrong, I'm just having a hard time following.
>
> I do not see where this has always been 0xff800000 in u-boot.

<cut>

> But while I was checking changes in arch/powerpc/, I found this change
> and wanted to understand why 0xffa00000 has worked for us for so long?

Kumar, I wasn't wrong entirely I just missed one detail. U-Boot
provides two different configs, not just one define like its for
SPL/SPI/...:

- include/configs/P1_P2_RDB.h

  #ifndef CONFIG_NAND_SPL
  #define CONFIG_SYS_NAND_BASE            0xffa00000
  #ifdef CONFIG_PHYS_64BIT
  #define CONFIG_SYS_NAND_BASE_PHYS       0xfffa00000ull
  #else
  #define CONFIG_SYS_NAND_BASE_PHYS       CONFIG_SYS_NAND_BASE
  #endif
  #else
  #define CONFIG_SYS_NAND_BASE            0xfff00000
  #ifdef CONFIG_PHYS_64BIT
  #define CONFIG_SYS_NAND_BASE_PHYS       0xffff00000ull
  #else
  #define CONFIG_SYS_NAND_BASE_PHYS       CONFIG_SYS_NAND_BASE
  #endif
  #endif

- include/configs/p1_p2_rdb_pc.h

  #ifdef CONFIG_NAND_FSL_ELBC
  #define CONFIG_SYS_NAND_BASE            0xff800000
  #ifdef CONFIG_PHYS_64BIT
  #define CONFIG_SYS_NAND_BASE_PHYS       0xfff800000ull
  #else
  #define CONFIG_SYS_NAND_BASE_PHYS       CONFIG_SYS_NAND_BASE
  #endif

and for kernel they use both the same device tree. So with the change,
the _pc variant finds its flash. Before that it worked for the non-pc
variant only if NAND_SPL wasn't used.
Any suggestion on fixing that? Providing a new dt for _pc would "fix"
it but the non pc variant won't find it in the case of NAND_SPL.

Since both system have the same SoC and the NAND_SPL is always linked
against 0xfff00000 I don't see anything wrong to relocate the NAND CS
later to 0xff800000 (or to 0xffa00000) and having it consistent among
both configs.

> -Bryan

Sebastian

Re: powerpc/85xx: p2020rdb - move the NAND address.

[Kumar Gala]

On Mar 29, 2012, at 2:26 AM, Sebastian Andrzej Siewior wrote:

> On 03/28/2012 10:30 PM, Bryan Hundven wrote:
>> > It is not at 0xffa00000. According to current u-boot source the NAND
>> > controller is always at 0xff800000 and it is either at CS0 or CS1
>> > depending on NAND or NAND+NOR mode. In 36bit mode it is shifted to
>> > 0xfff800000 but it has always an eight there and never an A.
>> >
>> > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>> > Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>> 
>> I am having a hard time verifying this change. I don't think you are
>> wrong, I'm just having a hard time following.
>> 
>> I do not see where this has always been 0xff800000 in u-boot.
> 
> <cut>
> 
>> But while I was checking changes in arch/powerpc/, I found this change
>> and wanted to understand why 0xffa00000 has worked for us for so long?
> 
> Kumar, I wasn't wrong entirely I just missed one detail. U-Boot
> provides two different configs, not just one define like its for
> SPL/SPI/...:
> 
> - include/configs/P1_P2_RDB.h
> 
> #ifndef CONFIG_NAND_SPL
> #define CONFIG_SYS_NAND_BASE            0xffa00000
> #ifdef CONFIG_PHYS_64BIT
> #define CONFIG_SYS_NAND_BASE_PHYS       0xfffa00000ull
> #else
> #define CONFIG_SYS_NAND_BASE_PHYS       CONFIG_SYS_NAND_BASE
> #endif
> #else
> #define CONFIG_SYS_NAND_BASE            0xfff00000
> #ifdef CONFIG_PHYS_64BIT
> #define CONFIG_SYS_NAND_BASE_PHYS       0xffff00000ull
> #else
> #define CONFIG_SYS_NAND_BASE_PHYS       CONFIG_SYS_NAND_BASE
> #endif
> #endif
> 
> - include/configs/p1_p2_rdb_pc.h
> 
> #ifdef CONFIG_NAND_FSL_ELBC
> #define CONFIG_SYS_NAND_BASE            0xff800000
> #ifdef CONFIG_PHYS_64BIT
> #define CONFIG_SYS_NAND_BASE_PHYS       0xfff800000ull
> #else
> #define CONFIG_SYS_NAND_BASE_PHYS       CONFIG_SYS_NAND_BASE
> #endif
> 
> and for kernel they use both the same device tree. So with the change,
> the _pc variant finds its flash. Before that it worked for the non-pc
> variant only if NAND_SPL wasn't used.
> Any suggestion on fixing that? Providing a new dt for _pc would "fix"
> it but the non pc variant won't find it in the case of NAND_SPL.

There are two (well 3 since rdb-pc has both 32b & 36b) in the tree now:

arch/powerpc/boot/dts/p2020rdb.dts
arch/powerpc/boot/dts/p2020rdb-pc_32b.dts
arch/powerpc/boot/dts/p2020rdb-pc_36b.dts

> 
> Since both system have the same SoC and the NAND_SPL is always linked
> against 0xfff00000 I don't see anything wrong to relocate the NAND CS
> later to 0xff800000 (or to 0xffa00000) and having it consistent among
> both configs.


- k

Re: powerpc/85xx: p2020rdb - move the NAND address.

[Bryan Hundven]

[-- Attachment #1: Type: text/plain, Size: 2838 bytes --]

Kumar,

Sorry, i should have posted to the ml.

Thank you, I was looking in the wrong spot.

Cheers,

-Bryan



Kumar Gala <galak@kernel.crashing.org> wrote:



On Mar 29, 2012, at 2:26 AM, Sebastian Andrzej Siewior wrote:

> On 03/28/2012 10:30 PM, Bryan Hundven wrote:
>> > It is not at 0xffa00000. According to current u-boot source the NAND
>> > controller is always at 0xff800000 and it is either at CS0 or CS1
>> > depending on NAND or NAND+NOR mode. In 36bit mode it is shifted to
>> > 0xfff800000 but it has always an eight there and never an A.
>> >
>> > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>> > Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>>
>> I am having a hard time verifying this change. I don't think you are
>> wrong, I'm just having a hard time following.
>>
>> I do not see where this has always been 0xff800000 in u-boot.
>
> <cut>
>
>> But while I was checking changes in arch/powerpc/, I found this change
>> and wanted to understand why 0xffa00000 has worked for us for so long?
>
> Kumar, I wasn't wrong entirely I just missed one detail. U-Boot
> provides two different configs, not just one define like its for
> SPL/SPI/...:
>
> - include/configs/P1_P2_RDB.h
>
> #ifndef CONFIG_NAND_SPL
> #define CONFIG_SYS_NAND_BASE            0xffa00000
> #ifdef CONFIG_PHYS_64BIT
> #define CONFIG_SYS_NAND_BASE_PHYS       0xfffa00000ull
> #else
> #define CONFIG_SYS_NAND_BASE_PHYS       CONFIG_SYS_NAND_BASE
> #endif
> #else
> #define CONFIG_SYS_NAND_BASE            0xfff00000
> #ifdef CONFIG_PHYS_64BIT
> #define CONFIG_SYS_NAND_BASE_PHYS       0xffff00000ull
> #else
> #define CONFIG_SYS_NAND_BASE_PHYS       CONFIG_SYS_NAND_BASE
> #endif
> #endif
>
> - include/configs/p1_p2_rdb_pc.h
>
> #ifdef CONFIG_NAND_FSL_ELBC
> #define CONFIG_SYS_NAND_BASE            0xff800000
> #ifdef CONFIG_PHYS_64BIT
> #define CONFIG_SYS_NAND_BASE_PHYS       0xfff800000ull
> #else
> #define CONFIG_SYS_NAND_BASE_PHYS       CONFIG_SYS_NAND_BASE
> #endif
>
> and for kernel they use both the same device tree. So with the change,
> the _pc variant finds its flash. Before that it worked for the non-pc
> variant only if NAND_SPL wasn't used.
> Any suggestion on fixing that? Providing a new dt for _pc would "fix"
> it but the non pc variant won't find it in the case of NAND_SPL.

There are two (well 3 since rdb-pc has both 32b & 36b) in the tree now:

arch/powerpc/boot/dts/p2020rdb.dts
arch/powerpc/boot/dts/p2020rdb-pc_32b.dts
arch/powerpc/boot/dts/p2020rdb-pc_36b.dts

>
> Since both system have the same SoC and the NAND_SPL is always linked
> against 0xfff00000 I don't see anything wrong to relocate the NAND CS
> later to 0xff800000 (or to 0xffa00000) and having it consistent among
> both configs.


- k

[-- Attachment #2: Type: text/html, Size: 4345 bytes --]

RE: powerpc/85xx: p2020rdb - move the NAND address.

[Bryan Hundven]

[-- Attachment #1: Type: text/plain, Size: 3355 bytes --]

One final question on this change is: If the nand base address was wrong in the kernel, but right in u-boot, how did this work before this change and what kinds of problems would I see with the old base address value in the kernel.

Thanks for your time in advance,

-Bryan
________________________________
From: Bryan Hundven
Sent: Thursday, March 29, 2012 11:28 AM
To: Kumar Gala; Sebastian Andrzej Siewior
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: powerpc/85xx: p2020rdb - move the NAND address.

Kumar,

Sorry, i should have posted to the ml.

Thank you, I was looking in the wrong spot.

Cheers,

-Bryan



Kumar Gala <galak@kernel.crashing.org> wrote:



On Mar 29, 2012, at 2:26 AM, Sebastian Andrzej Siewior wrote:

> On 03/28/2012 10:30 PM, Bryan Hundven wrote:
>> > It is not at 0xffa00000. According to current u-boot source the NAND
>> > controller is always at 0xff800000 and it is either at CS0 or CS1
>> > depending on NAND or NAND+NOR mode. In 36bit mode it is shifted to
>> > 0xfff800000 but it has always an eight there and never an A.
>> >
>> > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>> > Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>>
>> I am having a hard time verifying this change. I don't think you are
>> wrong, I'm just having a hard time following.
>>
>> I do not see where this has always been 0xff800000 in u-boot.
>
> <cut>
>
>> But while I was checking changes in arch/powerpc/, I found this change
>> and wanted to understand why 0xffa00000 has worked for us for so long?
>
> Kumar, I wasn't wrong entirely I just missed one detail. U-Boot
> provides two different configs, not just one define like its for
> SPL/SPI/...:
>
> - include/configs/P1_P2_RDB.h
>
> #ifndef CONFIG_NAND_SPL
> #define CONFIG_SYS_NAND_BASE            0xffa00000
> #ifdef CONFIG_PHYS_64BIT
> #define CONFIG_SYS_NAND_BASE_PHYS       0xfffa00000ull
> #else
> #define CONFIG_SYS_NAND_BASE_PHYS       CONFIG_SYS_NAND_BASE
> #endif
> #else
> #define CONFIG_SYS_NAND_BASE            0xfff00000
> #ifdef CONFIG_PHYS_64BIT
> #define CONFIG_SYS_NAND_BASE_PHYS       0xffff00000ull
> #else
> #define CONFIG_SYS_NAND_BASE_PHYS       CONFIG_SYS_NAND_BASE
> #endif
> #endif
>
> - include/configs/p1_p2_rdb_pc.h
>
> #ifdef CONFIG_NAND_FSL_ELBC
> #define CONFIG_SYS_NAND_BASE            0xff800000
> #ifdef CONFIG_PHYS_64BIT
> #define CONFIG_SYS_NAND_BASE_PHYS       0xfff800000ull
> #else
> #define CONFIG_SYS_NAND_BASE_PHYS       CONFIG_SYS_NAND_BASE
> #endif
>
> and for kernel they use both the same device tree. So with the change,
> the _pc variant finds its flash. Before that it worked for the non-pc
> variant only if NAND_SPL wasn't used.
> Any suggestion on fixing that? Providing a new dt for _pc would "fix"
> it but the non pc variant won't find it in the case of NAND_SPL.

There are two (well 3 since rdb-pc has both 32b & 36b) in the tree now:

arch/powerpc/boot/dts/p2020rdb.dts
arch/powerpc/boot/dts/p2020rdb-pc_32b.dts
arch/powerpc/boot/dts/p2020rdb-pc_36b.dts

>
> Since both system have the same SoC and the NAND_SPL is always linked
> against 0xfff00000 I don't see anything wrong to relocate the NAND CS
> later to 0xff800000 (or to 0xffa00000) and having it consistent among
> both configs.


- k

[-- Attachment #2: Type: text/html, Size: 5272 bytes --]

Re: powerpc/85xx: p2020rdb - move the NAND address.

[Sebastian Andrzej Siewior]

On 03/29/2012 03:10 PM, Kumar Gala wrote:

>> - include/configs/P1_P2_RDB.h
>>
>> #ifndef CONFIG_NAND_SPL
>> #define CONFIG_SYS_NAND_BASE            0xffa00000
>> #ifdef CONFIG_PHYS_64BIT
>> #define CONFIG_SYS_NAND_BASE_PHYS       0xfffa00000ull
>> #else
>> #define CONFIG_SYS_NAND_BASE_PHYS       CONFIG_SYS_NAND_BASE
>> #endif
>> #else
>> #define CONFIG_SYS_NAND_BASE            0xfff00000
>> #ifdef CONFIG_PHYS_64BIT
>> #define CONFIG_SYS_NAND_BASE_PHYS       0xffff00000ull
>> #else
>> #define CONFIG_SYS_NAND_BASE_PHYS       CONFIG_SYS_NAND_BASE
>> #endif
>> #endif
>>
>> - include/configs/p1_p2_rdb_pc.h
>>
>> #ifdef CONFIG_NAND_FSL_ELBC
>> #define CONFIG_SYS_NAND_BASE            0xff800000
>> #ifdef CONFIG_PHYS_64BIT
>> #define CONFIG_SYS_NAND_BASE_PHYS       0xfff800000ull
>> #else
>> #define CONFIG_SYS_NAND_BASE_PHYS       CONFIG_SYS_NAND_BASE
>> #endif
>>
>
> There are two (well 3 since rdb-pc has both 32b&  36b) in the tree now:
>
> arch/powerpc/boot/dts/p2020rdb.dts
> arch/powerpc/boot/dts/p2020rdb-pc_32b.dts
> arch/powerpc/boot/dts/p2020rdb-pc_36b.dts

Okay. So I assume that one has the proper NAND address and my patch
should be reverted then. Do want a patch from me for that?

>> Since both system have the same SoC and the NAND_SPL is always linked
>> against 0xfff00000 I don't see anything wrong to relocate the NAND CS
>> later to 0xff800000 (or to 0xffa00000) and having it consistent among
>> both configs.

what about this thing? Should leave it as it or move to the same
location? Since I have no HW *I* would prefer not to touch it :)

>
> - k

Sebastian

Re: powerpc/85xx: p2020rdb - move the NAND address.

[Kumar Gala]

On Mar 30, 2012, at 9:04 AM, Sebastian Andrzej Siewior wrote:

> On 03/29/2012 03:10 PM, Kumar Gala wrote:
> 
>>> - include/configs/P1_P2_RDB.h
>>> 
>>> #ifndef CONFIG_NAND_SPL
>>> #define CONFIG_SYS_NAND_BASE            0xffa00000
>>> #ifdef CONFIG_PHYS_64BIT
>>> #define CONFIG_SYS_NAND_BASE_PHYS       0xfffa00000ull
>>> #else
>>> #define CONFIG_SYS_NAND_BASE_PHYS       CONFIG_SYS_NAND_BASE
>>> #endif
>>> #else
>>> #define CONFIG_SYS_NAND_BASE            0xfff00000
>>> #ifdef CONFIG_PHYS_64BIT
>>> #define CONFIG_SYS_NAND_BASE_PHYS       0xffff00000ull
>>> #else
>>> #define CONFIG_SYS_NAND_BASE_PHYS       CONFIG_SYS_NAND_BASE
>>> #endif
>>> #endif
>>> 
>>> - include/configs/p1_p2_rdb_pc.h
>>> 
>>> #ifdef CONFIG_NAND_FSL_ELBC
>>> #define CONFIG_SYS_NAND_BASE            0xff800000
>>> #ifdef CONFIG_PHYS_64BIT
>>> #define CONFIG_SYS_NAND_BASE_PHYS       0xfff800000ull
>>> #else
>>> #define CONFIG_SYS_NAND_BASE_PHYS       CONFIG_SYS_NAND_BASE
>>> #endif
>>> 
>> 
>> There are two (well 3 since rdb-pc has both 32b&  36b) in the tree now:
>> 
>> arch/powerpc/boot/dts/p2020rdb.dts
>> arch/powerpc/boot/dts/p2020rdb-pc_32b.dts
>> arch/powerpc/boot/dts/p2020rdb-pc_36b.dts
> 
> Okay. So I assume that one has the proper NAND address and my patch
> should be reverted then. Do want a patch from me for that?

Yes, please do.

>>> Since both system have the same SoC and the NAND_SPL is always linked
>>> against 0xfff00000 I don't see anything wrong to relocate the NAND CS
>>> later to 0xff800000 (or to 0xffa00000) and having it consistent among
>>> both configs.
> 
> what about this thing? Should leave it as it or move to the same
> location? Since I have no HW *I* would prefer not to touch it :)

Hmm, that implies a u-boot change, right?

- k

Re: powerpc/85xx: p2020rdb - move the NAND address.

[Sebastian Andrzej Siewior]

* Kumar Gala | 2012-03-31 09:48:18 [-0500]:

Sorry for the delay Kumar, I though I allready done it.

>Yes, please do.
Here it comes.

>From 5b3e09992615e5670fa8e432e50424466fa9ca1a Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: Wed, 9 May 2012 21:48:42 +0200
Subject: [PATCH] Revert "powerpc/85xx: p2020rdb - move the NAND address."

This reverts commit 0c00f65653389a408dfbbee7578e671664eea26a.
The initial commit was my fault. There are two boards out there:
P2020RDB and P2020RDB-PC. I wasn't aware of that and assumed that I have
a RDB board in front of me while I the RDB-PC. This patch makes it work
for the RDB-PC variant and breaks it for the RDB. Now there is a device
tree file available for the RDB-PC which was not there earlier. So with
this revert, everything gets back to normal :)

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
 arch/powerpc/boot/dts/p2020rdb.dts |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/boot/dts/p2020rdb.dts b/arch/powerpc/boot/dts/p2020rdb.dts
index 153bc76..4d52bce 100644
--- a/arch/powerpc/boot/dts/p2020rdb.dts
+++ b/arch/powerpc/boot/dts/p2020rdb.dts
@@ -34,7 +34,7 @@
 
 		/* NOR and NAND Flashes */
 		ranges = <0x0 0x0 0x0 0xef000000 0x01000000
-			  0x1 0x0 0x0 0xff800000 0x00040000
+			  0x1 0x0 0x0 0xffa00000 0x00040000
 			  0x2 0x0 0x0 0xffb00000 0x00020000>;
 
 		nor@0,0 {
-- 
1.7.10

>>>> Since both system have the same SoC and the NAND_SPL is always linked
>>>> against 0xfff00000 I don't see anything wrong to relocate the NAND CS
>>>> later to 0xff800000 (or to 0xffa00000) and having it consistent among
>>>> both configs.
>> 
>> what about this thing? Should leave it as it or move to the same
>> location? Since I have no HW *I* would prefer not to touch it :)
>
>Hmm, that implies a u-boot change, right?

Yup.

>- k

Sebastian

Re: powerpc/85xx: p2020rdb - move the NAND address.

[Kumar Gala]

On May 9, 2012, at 2:53 PM, Sebastian Andrzej Siewior wrote:

> * Kumar Gala | 2012-03-31 09:48:18 [-0500]:
> 
> Sorry for the delay Kumar, I though I allready done it.
> 
>> Yes, please do.
> Here it comes.
> 
>> From 5b3e09992615e5670fa8e432e50424466fa9ca1a Mon Sep 17 00:00:00 2001
> From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Date: Wed, 9 May 2012 21:48:42 +0200
> Subject: [PATCH] Revert "powerpc/85xx: p2020rdb - move the NAND address."
> 
> This reverts commit 0c00f65653389a408dfbbee7578e671664eea26a.
> The initial commit was my fault. There are two boards out there:
> P2020RDB and P2020RDB-PC. I wasn't aware of that and assumed that I have
> a RDB board in front of me while I the RDB-PC. This patch makes it work
> for the RDB-PC variant and breaks it for the RDB. Now there is a device
> tree file available for the RDB-PC which was not there earlier. So with
> this revert, everything gets back to normal :)
> 
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
> arch/powerpc/boot/dts/p2020rdb.dts |    2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)

applied

- k