[PATCH] powerpc 4xx: DDR0_14[REDUC] decoded incorrectly

[PATCH] powerpc 4xx: DDR0_14[REDUC] decoded incorrectly

[Mikhail Zolotaryov]

[-- Attachment #1: Type: text/plain, Size: 434 bytes --]

Hi,

according to the PPC440EPx Embedded Processor User Manual (rev 1.14) 
DDR0_14[REDUC] bit has the following meaning:

REDUC - Enable the half data path feature of the controller
0 = Standard operation using full 64/72-bit memory bus
1 = Memory data path width is 32/40 bits

However, "1" is decoded as 64 bit (8 byte), "0" - as 32 bit (4 byte) bus 
by the kernel code. My understanding is this is not correct - patch 
attached.



[-- Attachment #2: patch-ibm4xx_denali_fixup_memsize.patch --]
[-- Type: text/plain, Size: 412 bytes --]

--- linux.orig/arch/powerpc/boot/4xx.c	2009-03-09 17:55:01.000000000 +0200
+++ linux/arch/powerpc/boot/4xx.c	2009-03-09 17:58:07.000000000 +0200
@@ -193,9 +193,9 @@
 	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 4xx: DDR0_14[REDUC] decoded incorrectly

[Josh Boyer]

On Mon, Mar 09, 2009 at 06:21:36PM +0200, Mikhail Zolotaryov wrote:
> Hi,
>
> according to the PPC440EPx Embedded Processor User Manual (rev 1.14)  
> DDR0_14[REDUC] bit has the following meaning:
>
> REDUC - Enable the half data path feature of the controller
> 0 = Standard operation using full 64/72-bit memory bus
> 1 = Memory data path width is 32/40 bits
>
> However, "1" is decoded as 64 bit (8 byte), "0" - as 32 bit (4 byte) bus  
> by the kernel code. My understanding is this is not correct - patch  
> attached.

You are missing the Signed-off-by tag that is needed.

Aside from that, I'm curious if you found this just through inspection, or
if you actually had a problem because of it.  Your fix seems correct, yet
I've had no problems with my boards at all.

josh

Re: [PATCH] powerpc 4xx: DDR0_14[REDUC] decoded incorrectly

[Mikhail Zolotaryov]

>> However, "1" is decoded as 64 bit (8 byte), "0" - as 32 bit (4 byte) bus  
>> by the kernel code. My understanding is this is not correct - patch  
>> attached.
>
> You are missing the Signed-off-by tag that is needed.
>
I'm sorry.

Signed-off-by: Mikhail Zolotaryov <lebon@lebon.org.ua>

> Aside from that, I'm curious if you found this just through inspection, or
> if you actually had a problem because of it.  Your fix seems correct, yet
> I've had no problems with my boards at all.
>

I'm actually working on custom PowerPC 440EPX board development here and 
have found the problem: without applying changes described, Linux 
detects memory size incorrectly and is unable to start. The rest of 
memory size computation process seems to be correct.

I have checked Sequoia evaluation board with U-Boot 2009.1 and confirm 
that original kernel code reported memory size correctly. So, for my 
understanding, if computation algorithm was wrong but result was correct 
- the problem is source data i.e. initial DDR configuration parameters 
loaded by U-Boot (please don't give a damn that memory size is always 
reported correctly by U-Boot - it's hard-coded constant there). I have 
checked Sequoia board schematics (DES0211_11_SCH_11.pdf, page 5, unit 
U1D) and noted that BankSel#1 is not connected, while bootloader memory 
configuration is (board/amcc/sequoia/sdram.c):
        mtsdram(DDR0_10, 0x00000300);
i.e. both Chip Selects used.

If I change this line to:
        mtsdram(DDR0_10, 0x00000100);
memory is accessible, patched kernel detects memory size correctly and 
kernel seems to be working well.

Please check my considerations, possibly it may be necessary to request 
additional information from board manufacturer.