[PATCH] PPC440EPx SDRAM width

[PATCH] PPC440EPx SDRAM width

[Steven A. Falco]

There is an error in the way ibm4xx_denali_fixup_memsize calculates
memory size.  When testing the DDR_REDUC bit, the polarity is
backwards.  A "1" implies 32-bit wide memory while a "0" implies
64-bit wide memory.

For a 32-bit wide system, this bug causes twice the memory to be
reported, leading to boot failure.

Signed-off-by: Steven A. Falco <sfalco@harris.com>
---

Here is a partial log showing what happens in the
ibm4xx_denali_fixup_memsize routine.  This board has
128 Mbytes of RAM in a 32-bit wide configuration, but
the REDUC bug causes the path width to report as "8",
and the memory size to be doubled to 255 MB.  Once I
applied my patch, the memory correctly reported as
127 MB.

max_cs=00000002 max_col=0000000c max_row=0000000e
cs 00000001
path width 00000008
row=0000000d col=0000000a bank=00000004
ibm4xx_denali_fixup_memsize 10000000
Memory <- <0x0 0x0 0xffff000> (255MB)

diff --git a/arch/powerpc/boot/4xx.c b/arch/powerpc/boot/4xx.c
index 5c87843..3595c0a 100644
--- a/arch/powerpc/boot/4xx.c
+++ b/arch/powerpc/boot/4xx.c
@@ -193,9 +193,9 @@ void ibm4xx_denali_fixup_memsize(void)
        val = SDRAM0_READ(DDR0_14);

        if (DDR_GET_VAL(val, DDR_REDUC, DDR_REDUC_SHIFT))
-               dpath = 8; /* 64 bits */
-       else
                dpath = 4; /* 32 bits */
+       else
+               dpath = 8; /* 64 bits */

        /* get address pins (rows) */
        val = SDRAM0_READ(DDR0_42);

Re: [PATCH] PPC440EPx SDRAM width

[Josh Boyer]

On Thu, Apr 23, 2009 at 09:36:12AM -0400, Steven A. Falco wrote:
>There is an error in the way ibm4xx_denali_fixup_memsize calculates
>memory size.  When testing the DDR_REDUC bit, the polarity is
>backwards.  A "1" implies 32-bit wide memory while a "0" implies
>64-bit wide memory.
>
>For a 32-bit wide system, this bug causes twice the memory to be
>reported, leading to boot failure.
>
>Signed-off-by: Steven A. Falco <sfalco@harris.com>

So we had a previous patch for this, and a very long discussion on what the
right solution was.  Either we never came to a resolution, or I have just
forgotten what it was.

Stefan, Valentine, do either of you remember?  IIRC, it wasn't something that
effected Sequoia or Rainier, but it could (and obviously does) effect custom
boards.  I don't remember what we agreed on for the proper fix.

josh

Re: [PATCH] PPC440EPx SDRAM width

[Stefan Roese]

On Thursday 23 April 2009, Josh Boyer wrote:
> On Thu, Apr 23, 2009 at 09:36:12AM -0400, Steven A. Falco wrote:
> >There is an error in the way ibm4xx_denali_fixup_memsize calculates
> >memory size.  When testing the DDR_REDUC bit, the polarity is
> >backwards.  A "1" implies 32-bit wide memory while a "0" implies
> >64-bit wide memory.
> >
> >For a 32-bit wide system, this bug causes twice the memory to be
> >reported, leading to boot failure.
> >
> >Signed-off-by: Steven A. Falco <sfalco@harris.com>
>
> So we had a previous patch for this, and a very long discussion on what the
> right solution was.  Either we never came to a resolution, or I have just
> forgotten what it was.
>
> Stefan, Valentine, do either of you remember?

Not really, sorry. Must be longer than 2 weeks ago, so it's already flushed 
from my cache. :)

> IIRC, it wasn't something 
> that effected Sequoia or Rainier, but it could (and obviously does) effect
> custom boards.  I don't remember what we agreed on for the proper fix.

It would effect all 32-bit wide 440EPx/GRx boards using the boot wrapper. I 
never used the wrapper on those platforms though. Sorry, I don't remember the 
outcome of the discussion either.

Thanks,
Stefan

Re: [PATCH] PPC440EPx SDRAM width

[Valentine Barshak]

Stefan Roese wrote:
> On Thursday 23 April 2009, Josh Boyer wrote:
>> On Thu, Apr 23, 2009 at 09:36:12AM -0400, Steven A. Falco wrote:
>>> There is an error in the way ibm4xx_denali_fixup_memsize calculates
>>> memory size.  When testing the DDR_REDUC bit, the polarity is
>>> backwards.  A "1" implies 32-bit wide memory while a "0" implies
>>> 64-bit wide memory.
>>>
>>> For a 32-bit wide system, this bug causes twice the memory to be
>>> reported, leading to boot failure.
>>>
>>> Signed-off-by: Steven A. Falco <sfalco@harris.com>
>> So we had a previous patch for this, and a very long discussion on what the
>> right solution was.  Either we never came to a resolution, or I have just
>> forgotten what it was.
>>
>> Stefan, Valentine, do either of you remember?
> 

The patch will break sequia/rainier since u-boot doesn't set the number 
of chipselects correctly for them. IIRC, the last conversation didn't 
come to any conclusion. We sort of wanted to fix that regardless of 
whether we had corrected u-boot or not.

Could we use a "model" property to distinguish between the "real" 
sequoia/rainier and other custom boards?
If yes, we could add a workaround the ibm4xx_denali_fixup_memsize to 
hardcode the chipselect number to 1 for sequoia/rainier.

Thanks,
Val.

> Not really, sorry. Must be longer than 2 weeks ago, so it's already flushed 
> from my cache. :)
> 
>> IIRC, it wasn't something 
>> that effected Sequoia or Rainier, but it could (and obviously does) effect
>> custom boards.  I don't remember what we agreed on for the proper fix.
> 
> It would effect all 32-bit wide 440EPx/GRx boards using the boot wrapper. I 
> never used the wrapper on those platforms though. Sorry, I don't remember the 
> outcome of the discussion either.
> 
> Thanks,
> Stefan
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] PPC440EPx SDRAM width

[Josh Boyer]

On Thu, Apr 23, 2009 at 06:40:48PM +0400, Valentine Barshak wrote:
> Stefan Roese wrote:
>> On Thursday 23 April 2009, Josh Boyer wrote:
>>> On Thu, Apr 23, 2009 at 09:36:12AM -0400, Steven A. Falco wrote:
>>>> There is an error in the way ibm4xx_denali_fixup_memsize calculates
>>>> memory size.  When testing the DDR_REDUC bit, the polarity is
>>>> backwards.  A "1" implies 32-bit wide memory while a "0" implies
>>>> 64-bit wide memory.
>>>>
>>>> For a 32-bit wide system, this bug causes twice the memory to be
>>>> reported, leading to boot failure.
>>>>
>>>> Signed-off-by: Steven A. Falco <sfalco@harris.com>
>>> So we had a previous patch for this, and a very long discussion on what the
>>> right solution was.  Either we never came to a resolution, or I have just
>>> forgotten what it was.
>>>
>>> Stefan, Valentine, do either of you remember?
>>
>
> The patch will break sequia/rainier since u-boot doesn't set the number  
> of chipselects correctly for them. IIRC, the last conversation didn't  
> come to any conclusion. We sort of wanted to fix that regardless of  
> whether we had corrected u-boot or not.
>
> Could we use a "model" property to distinguish between the "real"  
> sequoia/rainier and other custom boards?
> If yes, we could add a workaround the ibm4xx_denali_fixup_memsize to  
> hardcode the chipselect number to 1 for sequoia/rainier.

We could do that perhaps, yes.  In cases where the board has a newer U-Boot
with the fix already, it shouldn't really cause any harm, correct?

josh

Re: [PATCH] PPC440EPx SDRAM width

[Valentine Barshak]

Josh Boyer wrote:
> On Thu, Apr 23, 2009 at 06:40:48PM +0400, Valentine Barshak wrote:
>> Stefan Roese wrote:
>>> On Thursday 23 April 2009, Josh Boyer wrote:
>>>> On Thu, Apr 23, 2009 at 09:36:12AM -0400, Steven A. Falco wrote:
>>>>> There is an error in the way ibm4xx_denali_fixup_memsize calculates
>>>>> memory size.  When testing the DDR_REDUC bit, the polarity is
>>>>> backwards.  A "1" implies 32-bit wide memory while a "0" implies
>>>>> 64-bit wide memory.
>>>>>
>>>>> For a 32-bit wide system, this bug causes twice the memory to be
>>>>> reported, leading to boot failure.
>>>>>
>>>>> Signed-off-by: Steven A. Falco <sfalco@harris.com>
>>>> So we had a previous patch for this, and a very long discussion on what the
>>>> right solution was.  Either we never came to a resolution, or I have just
>>>> forgotten what it was.
>>>>
>>>> Stefan, Valentine, do either of you remember?
>> The patch will break sequia/rainier since u-boot doesn't set the number  
>> of chipselects correctly for them. IIRC, the last conversation didn't  
>> come to any conclusion. We sort of wanted to fix that regardless of  
>> whether we had corrected u-boot or not.
>>
>> Could we use a "model" property to distinguish between the "real"  
>> sequoia/rainier and other custom boards?
>> If yes, we could add a workaround the ibm4xx_denali_fixup_memsize to  
>> hardcode the chipselect number to 1 for sequoia/rainier.
> 
> We could do that perhaps, yes.  In cases where the board has a newer U-Boot
> with the fix already, it shouldn't really cause any harm, correct?

Yes, that's correct.

Thanks,
Val

> 
> josh

Re: [PATCH] PPC440EPx SDRAM width

[Steven A. Falco]

Valentine Barshak wrote:
> 
> Josh Boyer wrote:
>> On Thu, Apr 23, 2009 at 06:40:48PM +0400, Valentine Barshak wrote:
>>> Stefan Roese wrote:
>>>> On Thursday 23 April 2009, Josh Boyer wrote:
>>>>> On Thu, Apr 23, 2009 at 09:36:12AM -0400, Steven A. Falco wrote:
>>>>>> There is an error in the way ibm4xx_denali_fixup_memsize calculates
>>>>>> memory size.  When testing the DDR_REDUC bit, the polarity is
>>>>>> backwards.  A "1" implies 32-bit wide memory while a "0" implies
>>>>>> 64-bit wide memory.
>>>>>>
>>>>>> For a 32-bit wide system, this bug causes twice the memory to be
>>>>>> reported, leading to boot failure.
>>>>>>
>>>>>> Signed-off-by: Steven A. Falco <sfalco@harris.com>
>>>>> So we had a previous patch for this, and a very long discussion on
>>>>> what the
>>>>> right solution was.  Either we never came to a resolution, or I
>>>>> have just
>>>>> forgotten what it was.
>>>>>
>>>>> Stefan, Valentine, do either of you remember?
>>> The patch will break sequia/rainier since u-boot doesn't set the
>>> number  of chipselects correctly for them. 

I had wondered about that.  I was surprised that sequoia uboot
enabled both cs bits - now I know why it worked.  Two wrongs
sometimes do make a right. :-)

>>> IIRC, the last
>>> conversation didn't  come to any conclusion. We sort of wanted to fix
>>> that regardless of  whether we had corrected u-boot or not.

That would have saved me a bit of grief.  It will probably
help someone else someday too.

>>> Could we use a "model" property to distinguish between the "real" 
>>> sequoia/rainier and other custom boards?
>>> If yes, we could add a workaround the ibm4xx_denali_fixup_memsize to 
>>> hardcode the chipselect number to 1 for sequoia/rainier.
>>
>> We could do that perhaps, yes.  In cases where the board has a newer
>> U-Boot
>> with the fix already, it shouldn't really cause any harm, correct?
> 
> Yes, that's correct.

Not sure if you want me to do something further in my patch.
Are you suggesting testing for model = "amcc,sequoia" and
forcing cs to 1, or is there more to it?

	Steve

> 
> Thanks,
> Val
> 
>>
>> josh
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> 

[PATCH] PowerPC: 440EPx/GRx Sequoia/Rainier U-Boot incorrect chipselect number workaround

[Valentine Barshak]

Some U-Boot versions incorrectly set the number of chipselects to two
for Sequoia/Rainier boards while they only have one chipselect hardwired.
This patch adds a workaround for this, hardcoding the number of chipselects
to one for sequioa/rainer board models and reading the actual value from
the memory controller register DDR0_10 otherwise.

Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
 arch/powerpc/boot/4xx.c |   52 +++++++++++++++++++++++++++++++++++++----------
 1 files changed, 41 insertions(+), 11 deletions(-)

diff --git a/arch/powerpc/boot/4xx.c b/arch/powerpc/boot/4xx.c
index 5c87843..6196067 100644
--- a/arch/powerpc/boot/4xx.c
+++ b/arch/powerpc/boot/4xx.c
@@ -158,21 +158,33 @@ void ibm440spe_fixup_memsize(void)
 
 #define DDR_GET_VAL(val, mask, shift)	(((val) >> (shift)) & (mask))
 
-void ibm4xx_denali_fixup_memsize(void)
+/*
+ * Some U-Boot versions set the number of chipselects to two
+ * for Sequoia/Rainier boards while they only have one chipselect
+ * hardwired. Hardcode the number of chipselects to one 
+ * for sequioa/rainer board models or read the actual value
+ * from the memory controller register DDR0_10 otherwise.
+ */
+static inline u32 ibm4xx_denali_get_cs(void)
 {
-	u32 val, max_cs, max_col, max_row;
-	u32 cs, col, row, bank, dpath;
-	unsigned long memsize;
+	void *devp;
+	char model[64];
+	u32 val, cs;
 
-	val = SDRAM0_READ(DDR0_02);
-	if (!DDR_GET_VAL(val, DDR_START, DDR_START_SHIFT))
-		fatal("DDR controller is not initialized\n");
+	devp = finddevice("/");
+	if (!devp)
+		goto read_cs;
 
-	/* get maximum cs col and row values */
-	max_cs  = DDR_GET_VAL(val, DDR_MAX_CS_REG, DDR_MAX_CS_REG_SHIFT);
-	max_col = DDR_GET_VAL(val, DDR_MAX_COL_REG, DDR_MAX_COL_REG_SHIFT);
-	max_row = DDR_GET_VAL(val, DDR_MAX_ROW_REG, DDR_MAX_ROW_REG_SHIFT);
+	if (getprop(devp, "model", model, sizeof(model)) <= 0)
+		goto read_cs;
 
+	model[sizeof(model)-1] = 0;
+
+	if (!strcmp(model, "amcc,sequoia") ||
+	    !strcmp(model, "amcc,rainier"))
+		return 1;
+
+read_cs:
 	/* get CS value */
 	val = SDRAM0_READ(DDR0_10);
 
@@ -183,7 +195,25 @@ void ibm4xx_denali_fixup_memsize(void)
 			cs++;
 		val = val >> 1;
 	}
+	return cs;
+}
+
+void ibm4xx_denali_fixup_memsize(void)
+{
+	u32 val, max_cs, max_col, max_row;
+	u32 cs, col, row, bank, dpath;
+	unsigned long memsize;
+
+	val = SDRAM0_READ(DDR0_02);
+	if (!DDR_GET_VAL(val, DDR_START, DDR_START_SHIFT))
+		fatal("DDR controller is not initialized\n");
+
+	/* get maximum cs col and row values */
+	max_cs  = DDR_GET_VAL(val, DDR_MAX_CS_REG, DDR_MAX_CS_REG_SHIFT);
+	max_col = DDR_GET_VAL(val, DDR_MAX_COL_REG, DDR_MAX_COL_REG_SHIFT);
+	max_row = DDR_GET_VAL(val, DDR_MAX_ROW_REG, DDR_MAX_ROW_REG_SHIFT);
 
+	cs = ibm4xx_denali_get_cs();
 	if (!cs)
 		fatal("No memory installed\n");
 	if (cs > max_cs)

Re: [PATCH] PowerPC: 440EPx/GRx Sequoia/Rainier U-Boot incorrect chipselect number workaround

[Steven A. Falco]

Valentine Barshak wrote:
> Some U-Boot versions incorrectly set the number of chipselects to two
> for Sequoia/Rainier boards while they only have one chipselect hardwired.
> This patch adds a workaround for this, hardcoding the number of chipselects
> to one for sequioa/rainer board models and reading the actual value from
> the memory controller register DDR0_10 otherwise.
> 
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> ---
>  arch/powerpc/boot/4xx.c |   52 +++++++++++++++++++++++++++++++++++++----------
>  1 files changed, 41 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/powerpc/boot/4xx.c b/arch/powerpc/boot/4xx.c
> index 5c87843..6196067 100644
> --- a/arch/powerpc/boot/4xx.c
> +++ b/arch/powerpc/boot/4xx.c
> @@ -158,21 +158,33 @@ void ibm440spe_fixup_memsize(void)
>  
>  #define DDR_GET_VAL(val, mask, shift)	(((val) >> (shift)) & (mask))
>  
> -void ibm4xx_denali_fixup_memsize(void)
> +/*
> + * Some U-Boot versions set the number of chipselects to two
> + * for Sequoia/Rainier boards while they only have one chipselect
> + * hardwired. Hardcode the number of chipselects to one 
> + * for sequioa/rainer board models or read the actual value
> + * from the memory controller register DDR0_10 otherwise.
> + */
> +static inline u32 ibm4xx_denali_get_cs(void)
>  {
> -	u32 val, max_cs, max_col, max_row;
> -	u32 cs, col, row, bank, dpath;
> -	unsigned long memsize;
> +	void *devp;
> +	char model[64];
> +	u32 val, cs;
>  
> -	val = SDRAM0_READ(DDR0_02);
> -	if (!DDR_GET_VAL(val, DDR_START, DDR_START_SHIFT))
> -		fatal("DDR controller is not initialized\n");
> +	devp = finddevice("/");
> +	if (!devp)
> +		goto read_cs;
>  
> -	/* get maximum cs col and row values */
> -	max_cs  = DDR_GET_VAL(val, DDR_MAX_CS_REG, DDR_MAX_CS_REG_SHIFT);
> -	max_col = DDR_GET_VAL(val, DDR_MAX_COL_REG, DDR_MAX_COL_REG_SHIFT);
> -	max_row = DDR_GET_VAL(val, DDR_MAX_ROW_REG, DDR_MAX_ROW_REG_SHIFT);
> +	if (getprop(devp, "model", model, sizeof(model)) <= 0)
> +		goto read_cs;
>  
> +	model[sizeof(model)-1] = 0;
> +
> +	if (!strcmp(model, "amcc,sequoia") ||
> +	    !strcmp(model, "amcc,rainier"))
> +		return 1;
> +
> +read_cs:
>  	/* get CS value */
>  	val = SDRAM0_READ(DDR0_10);
>  
> @@ -183,7 +195,25 @@ void ibm4xx_denali_fixup_memsize(void)
>  			cs++;
>  		val = val >> 1;
>  	}
> +	return cs;
> +}
> +
> +void ibm4xx_denali_fixup_memsize(void)
> +{
> +	u32 val, max_cs, max_col, max_row;
> +	u32 cs, col, row, bank, dpath;
> +	unsigned long memsize;
> +
> +	val = SDRAM0_READ(DDR0_02);
> +	if (!DDR_GET_VAL(val, DDR_START, DDR_START_SHIFT))
> +		fatal("DDR controller is not initialized\n");
> +
> +	/* get maximum cs col and row values */
> +	max_cs  = DDR_GET_VAL(val, DDR_MAX_CS_REG, DDR_MAX_CS_REG_SHIFT);
> +	max_col = DDR_GET_VAL(val, DDR_MAX_COL_REG, DDR_MAX_COL_REG_SHIFT);
> +	max_row = DDR_GET_VAL(val, DDR_MAX_ROW_REG, DDR_MAX_ROW_REG_SHIFT);
>  
> +	cs = ibm4xx_denali_get_cs();
>  	if (!cs)
>  		fatal("No memory installed\n");
>  	if (cs > max_cs)
> 

Thanks for doing this so quickly!

I applied your patch plus my patch - my custom board reports
the correct memory size.  Therefore,

Acked-by: Steven A. Falco <sfalco@harris.com>

Clearly, both your and my patches must be applied together or
"bad things will happen".

BTW, I got a whitespace warning when applying your patch:

Applying: PowerPC: 440EPx/GRx Sequoia/Rainier U-Boot incorrect chipselect number workaround
/proj/hydra/sw/sfalco/linux-2.6-denx/.git/rebase-apply/patch:17: trailing whitespace.
 * hardwired. Hardcode the number of chipselects to one
warning: 1 line adds whitespace errors.

	Steve

Re: [PATCH] PowerPC: 440EPx/GRx Sequoia/Rainier U-Boot incorrect chipselect number workaround

[Valentine]

Thanks Steven,
Yes, both patches have to be applied.
Sorry, I missed a trailing space in the comment.
I'll resubmit another one in a bit.
Thanks,
Val.

Steven A. Falco wrote:
> 
> Thanks for doing this so quickly!
> 
> I applied your patch plus my patch - my custom board reports
> the correct memory size.  Therefore,
> 
> Acked-by: Steven A. Falco <sfalco@harris.com>
> 
> Clearly, both your and my patches must be applied together or
> "bad things will happen".
> 
> BTW, I got a whitespace warning when applying your patch:
> 
> Applying: PowerPC: 440EPx/GRx Sequoia/Rainier U-Boot incorrect chipselect number workaround
> /proj/hydra/sw/sfalco/linux-2.6-denx/.git/rebase-apply/patch:17: trailing whitespace.
>  * hardwired. Hardcode the number of chipselects to one
> warning: 1 line adds whitespace errors.
> 
> 	Steve
> 

Re: [PATCH] PowerPC: 440EPx/GRx Sequoia/Rainier U-Boot incorrect chipselect number workaround

[Josh Boyer]

On Fri, Apr 24, 2009 at 12:04:39AM +0400, Valentine wrote:
> Thanks Steven,
> Yes, both patches have to be applied.
> Sorry, I missed a trailing space in the comment.
> I'll resubmit another one in a bit.
> Thanks,
> Val.

Could you roll both patches into one, and include Steven's signed-off-by?  That
way I only have a single patch to apply.

josh

Re: [PATCH] PowerPC: 440EPx/GRx Sequoia/Rainier U-Boot incorrect chipselect number workaround

[Steven A. Falco]

Josh Boyer wrote:
> On Fri, Apr 24, 2009 at 12:04:39AM +0400, Valentine wrote:
>> Thanks Steven,
>> Yes, both patches have to be applied.
>> Sorry, I missed a trailing space in the comment.
>> I'll resubmit another one in a bit.
>> Thanks,
>> Val.
> 
> Could you roll both patches into one, and include Steven's signed-off-by?  That
> way I only have a single patch to apply.
> 
> josh
> 

That would certainly be safer.  Please let's combine them.

	Steve

[PATCH] PowerPC 44x: ibm4xx_denali_fixup_memsize fix

[Valentine Barshak]

Some U-Boot versions incorrectly set the number of chipselects to two
for Sequoia/Rainier boards while they only have one chipselect hardwired.
This patch adds a workaround for this, hardcoding the number of chipselects
to one for sequioa/rainer board models and reading the actual value from
the memory controller register DDR0_10 otherwise.
It also fixes another error in the way ibm4xx_denali_fixup_memsize
calculates memory size. When testing the DDR_REDUC bit, the polarity is
backwards.  A "1" implies 32-bit wide memory while a "0" implies 64-bit
wide memory.

Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
Signed-off-by: Steven A. Falco <sfalco@harris.com>
---
 arch/powerpc/boot/4xx.c |   56 ++++++++++++++++++++++++++++++++++++-----------
 1 files changed, 43 insertions(+), 13 deletions(-)

diff --git a/arch/powerpc/boot/4xx.c b/arch/powerpc/boot/4xx.c
index 5c87843..325b310 100644
--- a/arch/powerpc/boot/4xx.c
+++ b/arch/powerpc/boot/4xx.c
@@ -158,21 +158,33 @@ void ibm440spe_fixup_memsize(void)
 
 #define DDR_GET_VAL(val, mask, shift)	(((val) >> (shift)) & (mask))
 
-void ibm4xx_denali_fixup_memsize(void)
+/*
+ * Some U-Boot versions set the number of chipselects to two
+ * for Sequoia/Rainier boards while they only have one chipselect
+ * hardwired. Hardcode the number of chipselects to one
+ * for sequioa/rainer board models or read the actual value
+ * from the memory controller register DDR0_10 otherwise.
+ */
+static inline u32 ibm4xx_denali_get_cs(void)
 {
-	u32 val, max_cs, max_col, max_row;
-	u32 cs, col, row, bank, dpath;
-	unsigned long memsize;
+	void *devp;
+	char model[64];
+	u32 val, cs;
 
-	val = SDRAM0_READ(DDR0_02);
-	if (!DDR_GET_VAL(val, DDR_START, DDR_START_SHIFT))
-		fatal("DDR controller is not initialized\n");
+	devp = finddevice("/");
+	if (!devp)
+		goto read_cs;
 
-	/* get maximum cs col and row values */
-	max_cs  = DDR_GET_VAL(val, DDR_MAX_CS_REG, DDR_MAX_CS_REG_SHIFT);
-	max_col = DDR_GET_VAL(val, DDR_MAX_COL_REG, DDR_MAX_COL_REG_SHIFT);
-	max_row = DDR_GET_VAL(val, DDR_MAX_ROW_REG, DDR_MAX_ROW_REG_SHIFT);
+	if (getprop(devp, "model", model, sizeof(model)) <= 0)
+		goto read_cs;
 
+	model[sizeof(model)-1] = 0;
+
+	if (!strcmp(model, "amcc,sequoia") ||
+	    !strcmp(model, "amcc,rainier"))
+		return 1;
+
+read_cs:
 	/* get CS value */
 	val = SDRAM0_READ(DDR0_10);
 
@@ -183,7 +195,25 @@ void ibm4xx_denali_fixup_memsize(void)
 			cs++;
 		val = val >> 1;
 	}
+	return cs;
+}
+
+void ibm4xx_denali_fixup_memsize(void)
+{
+	u32 val, max_cs, max_col, max_row;
+	u32 cs, col, row, bank, dpath;
+	unsigned long memsize;
+
+	val = SDRAM0_READ(DDR0_02);
+	if (!DDR_GET_VAL(val, DDR_START, DDR_START_SHIFT))
+		fatal("DDR controller is not initialized\n");
 
+	/* get maximum cs col and row values */
+	max_cs  = DDR_GET_VAL(val, DDR_MAX_CS_REG, DDR_MAX_CS_REG_SHIFT);
+	max_col = DDR_GET_VAL(val, DDR_MAX_COL_REG, DDR_MAX_COL_REG_SHIFT);
+	max_row = DDR_GET_VAL(val, DDR_MAX_ROW_REG, DDR_MAX_ROW_REG_SHIFT);
+
+	cs = ibm4xx_denali_get_cs();
 	if (!cs)
 		fatal("No memory installed\n");
 	if (cs > max_cs)
@@ -193,9 +223,9 @@ void ibm4xx_denali_fixup_memsize(void)
 	val = SDRAM0_READ(DDR0_14);
 
 	if (DDR_GET_VAL(val, DDR_REDUC, DDR_REDUC_SHIFT))
-		dpath = 8; /* 64 bits */
-	else
 		dpath = 4; /* 32 bits */
+	else
+		dpath = 8; /* 64 bits */
 
 	/* get address pins (rows) */
  	val = SDRAM0_READ(DDR0_42);

Re: [PATCH] PowerPC 44x: ibm4xx_denali_fixup_memsize fix

[Stefan Roese]

On Thursday 23 April 2009, Valentine Barshak wrote:
> Some U-Boot versions incorrectly set the number of chipselects to two
> for Sequoia/Rainier boards while they only have one chipselect hardwired.
> This patch adds a workaround for this, hardcoding the number of chipselects
> to one for sequioa/rainer board models and reading the actual value from
> the memory controller register DDR0_10 otherwise.
> It also fixes another error in the way ibm4xx_denali_fixup_memsize
> calculates memory size. When testing the DDR_REDUC bit, the polarity is
> backwards.  A "1" implies 32-bit wide memory while a "0" implies 64-bit
> wide memory.
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> Signed-off-by: Steven A. Falco <sfalco@harris.com>

Acked-by: Stefan Roese <sr@denx.de>

Thanks.

Best regards,
Stefan