Skip to contentSkip to conversation

PPC440EPx SDRAM width

PATCH In review Steven A. Falco 4 participants 14 messages Apr 23, 2009 – Apr 24, 2009 PowerPC

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 PPC440EPx SDRAM width

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.

---

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)

arch/powerpc/boot/4xx.c +2 -2
index 5c87843..3595c0a 100644
@@ -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);
#1 lore raw
Quoted 9 lines · 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.

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

#2 lore raw
Quoted 9 lines · Josh Boyer
Quoted 8 lines · 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.

Quoted 7 lines
Quoted 1 line

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. :)

Quoted 3 lines

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

#3 lore raw
Quoted 10 lines · Stefan Roese
Quoted 9 lines · Josh Boyer
Quoted 8 lines · 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.

Quoted 7 lines
Quoted 6 lines
Quoted 1 line

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.

Quoted 13 lines

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

Quoted 2 lines

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
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-dev

#4 lore raw
Quoted 24 lines · Valentine Barshak
Quoted 10 lines · Stefan Roese
Quoted 9 lines · Josh Boyer
Quoted 8 lines · 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.

Quoted 7 lines
Quoted 6 lines
Quoted 1 line

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.

Quoted 4 lines

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

#5 lore raw
Quoted 17 lines · Josh Boyer
Quoted 16 lines · Valentine Barshak
Quoted 15 lines · Stefan Roese
Quoted 14 lines · Josh Boyer
Quoted 9 lines · 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.

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.

Quoted 8 lines
Quoted 5 lines
Quoted 1 line
Quoted 1 line

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

Quoted 2 lines

josh

#6 lore raw
Quoted 21 lines · Valentine Barshak
Quoted 19 lines · Josh Boyer
Quoted 18 lines · Valentine Barshak
Quoted 17 lines · Stefan Roese
Quoted 16 lines · Josh Boyer
Quoted 9 lines · 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.

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.

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line

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. :-)

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines

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.

Quoted 10 lines
Quoted 8 lines
Quoted 4 lines

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

Quoted 12 lines

Thanks,
Val

Quoted 2 lines

josh

_______________________________________________
Linuxppc-dev mailing list
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-dev

#7 lore raw

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

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.

---
 arch/powerpc/boot/4xx.c |   52 +++++++++++++++++++++++++++++++++++++----------
 1 files changed, 41 insertions(+), 11 deletions(-)
arch/powerpc/boot/4xx.c +41 -11
index 5c87843..6196067 100644
@@ -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)
author Acked-by on v1 1/1
#8 lore raw

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

Quoted 77 lines · 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.

---
 arch/powerpc/boot/4xx.c |   52 +++++++++++++++++++++++++++++++++++++----------
 1 files changed, 41 insertions(+), 11 deletions(-)
arch/powerpc/boot/4xx.c +35 -11
index 5c87843..6196067 100644
@@ -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");

arch/powerpc/boot/4xx.c void ibm4xx_denali_fixup_memsize(void) · line 219

Quoted 10 lines
arch/powerpc/boot/4xx.c +6 -0
+
+	/* 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,

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

#9 lore raw

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

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.

Quoted 20 lines · Steven A. Falco

Thanks for doing this so quickly!

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

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

#10 lore raw

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

Quoted 6 lines · 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.

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

#11 lore raw

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

Quoted 8 lines · Josh Boyer
Quoted 6 lines · 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.

Quoted 5 lines

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

#12 lore raw

PATCH 1/1 PowerPC 44x: ibm4xx_denali_fixup_memsize fix

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.

---
 arch/powerpc/boot/4xx.c |   56 ++++++++++++++++++++++++++++++++++++-----------
 1 files changed, 43 insertions(+), 13 deletions(-)
arch/powerpc/boot/4xx.c +43 -13
index 5c87843..325b310 100644
@@ -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);
Acked-by on v1 1/1
#13 lore raw

Re: [PATCH] PowerPC 44x: ibm4xx_denali_fixup_memsize fix

Quoted 10 lines · 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.

Quoted 2 lines

Thanks.

Best regards,
Stefan