From: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Date: 2012-03-29 07:26:27
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 [off-list ref]
> Signed-off-by: Kumar Gala [off-list ref]
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.
From: Kumar Gala <hidden> Date: 2012-03-29 13:10:37
On Mar 29, 2012, at 2:26 AM, Sebastian Andrzej Siewior wrote:
On 03/28/2012 10:30 PM, Bryan Hundven wrote:
quoted
quoted
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 <redacted>
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>
quoted
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.
Kumar,
Sorry, i should have posted to the ml.
Thank you, I was looking in the wrong spot.
Cheers,
-Bryan
Kumar Gala [off-list ref] wrote:
On Mar 29, 2012, at 2:26 AM, Sebastian Andrzej Siewior wrote:
On 03/28/2012 10:30 PM, Bryan Hundven wrote:
quoted
quoted
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 <redacted>
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>
quoted
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.
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 [off-list ref] wrote:
On Mar 29, 2012, at 2:26 AM, Sebastian Andrzej Siewior wrote:
On 03/28/2012 10:30 PM, Bryan Hundven wrote:
quoted
quoted
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 <redacted>
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>
quoted
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.
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?
quoted
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 :)
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.
quoted
quoted
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 :)
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Date: 2012-05-09 19:53:13
* 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(-)
@@ -34,7 +34,7 @@/* NOR and NAND Flashes */ranges=<0x00x00x00xef0000000x01000000-0x10x00x00xff8000000x00040000+0x10x00x00xffa000000x000400000x20x00x00xffb000000x00020000>;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
From: Kumar Gala <hidden> Date: 2012-06-29 20:01:05
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.
quoted
Yes, please do.
Here it comes.
quoted
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(-)