Re: powerpc/85xx: p2020rdb - move the NAND address.
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 > 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 > --- > arch/powerpc/boot/dts/p2020rdb.dts |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) applied - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/85xx: p2020rdb - move the NAND address.
* 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
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
---
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 0xef00 0x0100
- 0x1 0x0 0x0 0xff80 0x0004
+ 0x1 0x0 0x0 0xffa0 0x0004
0x2 0x0 0x0 0xffb0 0x0002>;
nor@0,0 {
--
1.7.10
>>>> Since both system have the same SoC and the NAND_SPL is always linked
>>>> against 0xfff0 I don't see anything wrong to relocate the NAND CS
>>>> later to 0xff80 (or to 0xffa0) 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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/85xx: p2020rdb - move the NAND address.
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_BASE0xffa0 >>> #ifdef CONFIG_PHYS_64BIT >>> #define CONFIG_SYS_NAND_BASE_PHYS 0xfffa0ull >>> #else >>> #define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE >>> #endif >>> #else >>> #define CONFIG_SYS_NAND_BASE0xfff0 >>> #ifdef CONFIG_PHYS_64BIT >>> #define CONFIG_SYS_NAND_BASE_PHYS 0x0ull >>> #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_BASE0xff80 >>> #ifdef CONFIG_PHYS_64BIT >>> #define CONFIG_SYS_NAND_BASE_PHYS 0xfff80ull >>> #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 0xfff0 I don't see anything wrong to relocate the NAND CS >>> later to 0xff80 (or to 0xffa0) 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/85xx: p2020rdb - move the NAND address.
On 03/29/2012 03:10 PM, Kumar Gala wrote: - include/configs/P1_P2_RDB.h #ifndef CONFIG_NAND_SPL #define CONFIG_SYS_NAND_BASE0xffa0 #ifdef CONFIG_PHYS_64BIT #define CONFIG_SYS_NAND_BASE_PHYS 0xfffa0ull #else #define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE #endif #else #define CONFIG_SYS_NAND_BASE0xfff0 #ifdef CONFIG_PHYS_64BIT #define CONFIG_SYS_NAND_BASE_PHYS 0x0ull #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_BASE0xff80 #ifdef CONFIG_PHYS_64BIT #define CONFIG_SYS_NAND_BASE_PHYS 0xfff80ull #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 0xfff0 I don't see anything wrong to relocate the NAND CS later to 0xff80 (or to 0xffa0) 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: powerpc/85xx: p2020rdb - move the NAND address.
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 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 0xffa0. According to current u-boot source the NAND >> > controller is always at 0xff80 and it is either at CS0 or CS1 >> > depending on NAND or NAND+NOR mode. In 36bit mode it is shifted to >> > 0xfff80 but it has always an eight there and never an A. >> > >> > Signed-off-by: Sebastian Andrzej Siewior >> > Signed-off-by: Kumar Gala >> >> 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 0xff80 in u-boot. > > > >> But while I was checking changes in arch/powerpc/, I found this change >> and wanted to understand why 0xffa0 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_BASE0xffa0 > #ifdef CONFIG_PHYS_64BIT > #define CONFIG_SYS_NAND_BASE_PHYS 0xfffa0ull > #else > #define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE > #endif > #else > #define CONFIG_SYS_NAND_BASE0xfff0 > #ifdef CONFIG_PHYS_64BIT > #define CONFIG_SYS_NAND_BASE_PHYS 0x0ull > #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_BASE0xff80 > #ifdef CONFIG_PHYS_64BIT > #define CONFIG_SYS_NAND_BASE_PHYS 0xfff80ull > #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 0xfff0 I don't see anything wrong to relocate the NAND CS > later to 0xff80 (or to 0xffa0) and having it consistent among > both configs. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
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 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 0xffa0. According to current u-boot source the NAND >> > controller is always at 0xff80 and it is either at CS0 or CS1 >> > depending on NAND or NAND+NOR mode. In 36bit mode it is shifted to >> > 0xfff80 but it has always an eight there and never an A. >> > >> > Signed-off-by: Sebastian Andrzej Siewior >> > Signed-off-by: Kumar Gala >> >> 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 0xff80 in u-boot. > > > >> But while I was checking changes in arch/powerpc/, I found this change >> and wanted to understand why 0xffa0 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_BASE0xffa0 > #ifdef CONFIG_PHYS_64BIT > #define CONFIG_SYS_NAND_BASE_PHYS 0xfffa0ull > #else > #define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE > #endif > #else > #define CONFIG_SYS_NAND_BASE0xfff0 > #ifdef CONFIG_PHYS_64BIT > #define CONFIG_SYS_NAND_BASE_PHYS 0x0ull > #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_BASE0xff80 > #ifdef CONFIG_PHYS_64BIT > #define CONFIG_SYS_NAND_BASE_PHYS 0xfff80ull > #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 0xfff0 I don't see anything wrong to relocate the NAND CS > later to 0xff80 (or to 0xffa0) and having it consistent among > both configs. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/85xx: p2020rdb - move the NAND address.
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 0xffa0. According to current u-boot source the NAND >> > controller is always at 0xff80 and it is either at CS0 or CS1 >> > depending on NAND or NAND+NOR mode. In 36bit mode it is shifted to >> > 0xfff80 but it has always an eight there and never an A. >> > >> > Signed-off-by: Sebastian Andrzej Siewior >> > Signed-off-by: Kumar Gala >> >> 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 0xff80 in u-boot. > > > >> But while I was checking changes in arch/powerpc/, I found this change >> and wanted to understand why 0xffa0 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_BASE0xffa0 > #ifdef CONFIG_PHYS_64BIT > #define CONFIG_SYS_NAND_BASE_PHYS 0xfffa0ull > #else > #define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE > #endif > #else > #define CONFIG_SYS_NAND_BASE0xfff0 > #ifdef CONFIG_PHYS_64BIT > #define CONFIG_SYS_NAND_BASE_PHYS 0x0ull > #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_BASE0xff80 > #ifdef CONFIG_PHYS_64BIT > #define CONFIG_SYS_NAND_BASE_PHYS 0xfff80ull > #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 0xfff0 I don't see anything wrong to relocate the NAND CS > later to 0xff80 (or to 0xffa0) and having it consistent among > both configs. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/85xx: p2020rdb - move the NAND address.
On 03/28/2012 10:30 PM, Bryan Hundven wrote: > It is not at 0xffa0. According to current u-boot source the NAND > controller is always at 0xff80 and it is either at CS0 or CS1 > depending on NAND or NAND+NOR mode. In 36bit mode it is shifted to > 0xfff80 but it has always an eight there and never an A. > > Signed-off-by: Sebastian Andrzej Siewior > Signed-off-by: Kumar Gala 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 0xff80 in u-boot. But while I was checking changes in arch/powerpc/, I found this change and wanted to understand why 0xffa0 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_BASE0xffa0 #ifdef CONFIG_PHYS_64BIT #define CONFIG_SYS_NAND_BASE_PHYS 0xfffa0ull #else #define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE #endif #else #define CONFIG_SYS_NAND_BASE0xfff0 #ifdef CONFIG_PHYS_64BIT #define CONFIG_SYS_NAND_BASE_PHYS 0x0ull #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_BASE0xff80 #ifdef CONFIG_PHYS_64BIT #define CONFIG_SYS_NAND_BASE_PHYS 0xfff80ull #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 0xfff0 I don't see anything wrong to relocate the NAND CS later to 0xff80 (or to 0xffa0) and having it consistent among both configs. -Bryan Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
