* Re: powerpc/85xx: p2020rdb - move the NAND address. [not found] <E9CCADB024EDCD44A9C1083605680C42B9053302@ES05CO.wgti.net> @ 2012-03-29 7:26 ` Sebastian Andrzej Siewior 2012-03-29 13:10 ` Kumar Gala 0 siblings, 1 reply; 8+ messages in thread From: Sebastian Andrzej Siewior @ 2012-03-29 7:26 UTC (permalink / raw) To: Kumar Gala, linuxppc-dev; +Cc: Bryan Hundven 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: powerpc/85xx: p2020rdb - move the NAND address. 2012-03-29 7:26 ` powerpc/85xx: p2020rdb - move the NAND address Sebastian Andrzej Siewior @ 2012-03-29 13:10 ` Kumar Gala 2012-03-29 18:28 ` Bryan Hundven 2012-03-30 14:04 ` Sebastian Andrzej Siewior 0 siblings, 2 replies; 8+ messages in thread From: Kumar Gala @ 2012-03-29 13:10 UTC (permalink / raw) To: Sebastian Andrzej Siewior; +Cc: Bryan Hundven, linuxppc-dev 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: powerpc/85xx: p2020rdb - move the NAND address. 2012-03-29 13:10 ` Kumar Gala @ 2012-03-29 18:28 ` Bryan Hundven 2012-03-29 23:17 ` Bryan Hundven 2012-03-30 14:04 ` Sebastian Andrzej Siewior 1 sibling, 1 reply; 8+ messages in thread From: Bryan Hundven @ 2012-03-29 18:28 UTC (permalink / raw) To: Kumar Gala, Sebastian Andrzej Siewior; +Cc: linuxppc-dev@lists.ozlabs.org [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: powerpc/85xx: p2020rdb - move the NAND address. 2012-03-29 18:28 ` Bryan Hundven @ 2012-03-29 23:17 ` Bryan Hundven 0 siblings, 0 replies; 8+ messages in thread From: Bryan Hundven @ 2012-03-29 23:17 UTC (permalink / raw) To: Kumar Gala, Sebastian Andrzej Siewior; +Cc: linuxppc-dev@lists.ozlabs.org [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: powerpc/85xx: p2020rdb - move the NAND address. 2012-03-29 13:10 ` Kumar Gala 2012-03-29 18:28 ` Bryan Hundven @ 2012-03-30 14:04 ` Sebastian Andrzej Siewior 2012-03-31 14:48 ` Kumar Gala 1 sibling, 1 reply; 8+ messages in thread From: Sebastian Andrzej Siewior @ 2012-03-30 14:04 UTC (permalink / raw) To: Kumar Gala; +Cc: Bryan Hundven, linuxppc-dev 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: powerpc/85xx: p2020rdb - move the NAND address. 2012-03-30 14:04 ` Sebastian Andrzej Siewior @ 2012-03-31 14:48 ` Kumar Gala 2012-05-09 19:53 ` Sebastian Andrzej Siewior 0 siblings, 1 reply; 8+ messages in thread From: Kumar Gala @ 2012-03-31 14:48 UTC (permalink / raw) To: Sebastian Andrzej Siewior; +Cc: Bryan Hundven, linuxppc-dev 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: powerpc/85xx: p2020rdb - move the NAND address. 2012-03-31 14:48 ` Kumar Gala @ 2012-05-09 19:53 ` Sebastian Andrzej Siewior 2012-06-29 20:01 ` Kumar Gala 0 siblings, 1 reply; 8+ messages in thread From: Sebastian Andrzej Siewior @ 2012-05-09 19:53 UTC (permalink / raw) To: Kumar Gala; +Cc: Bryan Hundven, linuxppc-dev * 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 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: powerpc/85xx: p2020rdb - move the NAND address. 2012-05-09 19:53 ` Sebastian Andrzej Siewior @ 2012-06-29 20:01 ` Kumar Gala 0 siblings, 0 replies; 8+ messages in thread From: Kumar Gala @ 2012-06-29 20:01 UTC (permalink / raw) To: Sebastian Andrzej Siewior; +Cc: Bryan Hundven, linuxppc-dev 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-06-29 20:01 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <E9CCADB024EDCD44A9C1083605680C42B9053302@ES05CO.wgti.net>
2012-03-29 7:26 ` powerpc/85xx: p2020rdb - move the NAND address Sebastian Andrzej Siewior
2012-03-29 13:10 ` Kumar Gala
2012-03-29 18:28 ` Bryan Hundven
2012-03-29 23:17 ` Bryan Hundven
2012-03-30 14:04 ` Sebastian Andrzej Siewior
2012-03-31 14:48 ` Kumar Gala
2012-05-09 19:53 ` Sebastian Andrzej Siewior
2012-06-29 20:01 ` Kumar Gala
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).