On 03.04.2013 18:15, txcotrader wrote:

Thanks Stefan, great suggestion, I failed to copy those configurations into my original message.

/*-----------------------------------------------------------------------

• DDR SDRAM

*----------------------------------------------------------------------*/ #if !defined(CONFIG_NAND_U_BOOT) #define CONFIG_SPD_EEPROM 1 /* Use SPD EEPROM for setup */ #define CONFIG_DDR_ECC 1 /* with ECC support */

/* SPD i2c spd addresses */ #define SPD_EEPROM_ADDRESS {IIC0_DIMM0_ADDR} #define IIC0_DIMM0_ADDR 0x50 #define IIC0_DIMM1_ADDR 0x52

I am questioning my bus configurations... I haven't hooked up the scope yet, but I don't think data is hitting the bus. I don't see any areas to configure the I2C bus besides the board configuration file. Any suggestions?

Are you sure that 0x50 is correct? I suggest you try this instead:

#define SPD_EEPROM_ADDRESS { IIC0_DIMM0_ADDR, IIC0_DIMM1_ADDR }

Thanks, Stefan

Hi,

On Wed, 3 Apr 2013 10:29:00 -0700 (PDT) txcotrader txcotrader@gmail.com wrote:

After hooking the DIMM's I2C up to the o-scope, I don't see a clock signal. The board will boot with a u-boot version from 2007. Have you ever come across a missing I2C clock?

How many I2C busses are actually used on your board ? On which bus is the SPD EEPROM ? If it is on a I2C bus other than 0, then you have to use

#define CONFIG_SYS_SPD_BUS_NUM <your-spd-bus-num>

in the board config file.

HTH,

Anatolij

I feel like something "different" is happening when executing the io.h->out_8 function. Could somebody help me understand this op code

v2013.01.01 Code: extern inline void out_8(volatile unsigned char __iomem *addr, u8 val) { __asm__ __volatile__("sync;\n" "stb%U0%X0 %1,%0;\n" : "=m" (*addr) : "r" (val)); }

Old 1.7.02 Code: extern inline void out_8(volatile unsigned char __iomem *addr, int val) { __asm__ __volatile__("stb%U0%X0 %1,%0; eieio" : "=m" (*addr) : "r" (val)); }

So I understand the sync op code but what is going on here? Could someone with some expertise explain "stb%U0%X0 %1,%0" and "stb%U0%X0 %1,%0; eieio".

Thanks!

-- View this message in context: http://u-boot.10912.n7.nabble.com/PPC4XX-Custom-Board-Failing-to-read-I2C-tp... Sent from the U-Boot mailing list archive at Nabble.com.

Rommel,

That sounds like a great suggestion, could you elaborate on 'mw' or 'mm' a little bit more? I'm unfamiliar with both of those. Are they a #define config, Make config...?

Many thanks! --Greg

-- View this message in context: http://u-boot.10912.n7.nabble.com/PPC4XX-Custom-Board-Failing-to-read-I2C-tp... Sent from the U-Boot mailing list archive at Nabble.com.

On 05.04.2013 02:04, txcotrader wrote:

After looking deeper I've found a difference in register values when performing drivers/i2c/ppc4xx_i2c.c->i2c_transfer function.

v1.7.02 code yields:

/* Transfer is in progress * we have to wait for upto 5 bytes of data * 1 byte chip address+r/w bit then bc bytes * of data. * udelay(10) is 1 bit time at 100khz * Doubled for slop. 20 is too small. */ i = 2*5*8; do { /* Get status */ status = in_8((u8 *)IIC_STS); printf("gd_ do status->i = %d, status = %d\n", i, status); udelay(20); i--; } while ((status & IIC_STS_PT) && !(status & IIC_STS_ERR) && (i > 0));

gd_ do status->i = 80, status = 40

v2013.01.01 Yields: i = 2 * 5 * 8; do { /* Get status */ status = in_8(&i2c->sts); printf("gd_ do status->i = %d, status = %d\n", i, status); udelay(10); i--; } while ((status & IIC_STS_PT) && !(status & IIC_STS_ERR) && (i > 0));

gd_ do status->i = 80, status = 40

v1.7.02 - include/4xx_i2c.h:#define IIC_STS (I2C_REGISTERS_BASE_ADDRESS+IICSTS) v2013.01.01 - struct ppc4xx_i2c *i2c = (struct ppc4xx_i2c *)I2C_BASE_ADDR;

Newb question, but I should be able to add an offset to correct this issue right?

The resulting addresses should be the same. The old version uses the offset via a define and the new one the (recommended) struct access to the register. I suggest you print the resulting address to verify that it really is the same.

Thanks, Stefan

On 08.04.2013 14:26, txcotrader wrote:

Thanks for the suggestion Stefan, the addresses are definitely different:

v2013.01.01: I2C_BASE_ADDR = ef600400

Thats the base address of the struct. Please check the address of the STS register instead (&i2c->sts). It it still different from the IIC_STS define from the old version?

v1.7.02: IIC_STS = ef600408

Would you suggest not using the default drivers and configure GPIO or could this possibly be a bug in the new version?

If the addresses really are different, then its a bug. Most likely only for the 440SX (correct?). I suggest you dig into this a bit deeper to find the root cause for this address difference.

Hope this helps, Stefan

Greg,

On 08.04.2013 16:16, txcotrader wrote:

Thanks for the suggestion, I2C_BASE_ADDR is the same in both versions. After doing some more digging, I can see why v2013.01.01 is not passing i2c_transfer. The following routine yields different results in the 2 versions:

v2013.01.01- do { /* Get status */ status = in_8(&i2c->sts); printf("gd_ do status->i = %x, status = %d, IIC_STS = %x\n", i, status, &i2c->sts); udelay(10); i--; } while ((status & IIC_STS_PT) && !(status & IIC_STS_ERR) && (i > 0));

Result: gd_ do status->i = 80, status = 4, IIC_STS = ef600408

v1.7.02- do { /* Get status */ status = in_8((u8 *)IIC_STS); printf("gd_ do status->i = %d, status = %d, IIC_STS = %x\n", i, status, IIC_STS); udelay(10); i--; } while ((status & IIC_STS_PT) && !(status & IIC_STS_ERR) && (i > 0));

Result: gd_ do status->i = 80, status = 40, IIC_STS = ef600408

So in v2013.01.01 (status & IIC_STS_ERR) == 1, versus a (status & IIC_STS_ERR) == 0 in v1.7.02. Am I missing some sort of offset config someplace? Once again, any help is greatly appreciated.

So look into the manual to check what exactly these IIC_STS bits/differences mean. 0x4 versus 0x40. This might give you a hint. Perhaps some clocks missing? Not sure.

Which PPC4xx variant are you using again? 460SX?

Thanks, Stefan

Greg,

On 08.04.2013 21:54, txcotrader wrote:

Yes, I am working with a 460SX and a board based off of AMCC Eiger (unsupported as of 2010).

460SX is quite untested these days I'm afraid. I don't have such a board here as well.

IICx_STS Register settings: 04 = MDBF Full = Master data buffer contains data 40 = IRQA Active = An IIC interrrupt has been sent to the UIC

I'm clearing the IIC register early on in my code: mtdcr(UIC0SR, 0xffffffff); /* clear all */ mtdcr(UIC0ER, 0x00000000); /* disable all */ mtdcr(UIC0CR, 0x00000005); /* ATI & UIC1 crit are critical */ mtdcr(UIC0PR, 0xffffffff); /* per ref-board manual */ mtdcr(UIC0TR, 0x00000000); /* per ref-board manual */ mtdcr(UIC0VR, 0x00000000); /* int31 highest, base=0x000 */ mtdcr(UIC0SR, 0xffffffff); /* clear all */

mtdcr(UIC1SR, 0xffffffff);  /* clear all */
mtdcr(UIC1ER, 0x00000000);  /* disable all */
mtdcr(UIC1CR, 0x00000000);  /* all non-critical */
mtdcr(UIC1PR, 0xffffffff);  /* per ref-board manual */
mtdcr(UIC1TR, 0x00000000);  /* per ref-board manual */
mtdcr(UIC1VR, 0x00000000);  /* int31 highest, base=0x000 */
mtdcr(UIC1SR, 0xffffffff);  /* clear all */

Ughh! This is not IIC (I2C) but UIC released code. So its for the interrupt controller and not I2C controller. But nevertheless this should not matter.

I'm really not sure what to look for at this point, any additional tips you might have would be extremely helpful. I truly appreciate your help to this point.

As mentioned above I don't have such a board here, so I can't really test anything. Sorry.

Best regards, Stefan

Greg,

On 07/25/2013 12:58 AM, txcotrader wrote:

I know it's been awhile, but I do appreciate your previous help. I took some time off to complete other projects, now I'm back working on finishing this port. During the boot I'm seeing the value of &i2c->extsts is either 0x40 or 0x60 which equates to lost arbitration or lost arbitration and incomplete transfer. Have you seen this type of error based on a misconfiguration? Any help you're willing to provide is greatly appreciated.

Sorry, I have no idea why this could be the case. Do you have another 4xx based board (some AMCC/APM eval board) to compare the "extsts" register value? This might give you a clue.

Thanks, Stefan