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 e
Stefan,
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 a
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
Stefan,
Yes, I am working with a 460SX and a board based off of AMCC Eiger
(unsupported as of 2010).
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:
mtd
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-
>
Sefan,
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 */
statu
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_S
Thanks for the suggestion Stefan, the addresses are definitely different:
v2013.01.01: I2C_BASE_ADDR = ef600400
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?
Thanks,
Greg
--
View this message
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
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 d
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-
txcotrader gmail.com> writes:
Dear txcotrader
>
> By board is based off of the ppc460sx.
> I only have one I2C bus.
>
> 2007 version has clock signal at 0x50 (DIMM0 I2C)
> 2013 version has no clock signal at 0x50
>
> My boardconfig.h file has the same values configured.
If you haven't tried
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
By board is based off of the ppc460sx.
I only have one I2C bus.
2007 version has clock signal at 0x50 (DIMM0 I2C)
2013 version has no clock signal at 0x50
My boardconfig.h file has the same values configured.
--
View this message in context:
http://u-boot.10912.n7.nabble.com/PPC4XX-Custom-
Hi,
On Wed, 3 Apr 2013 10:29:00 -0700 (PDT)
txcotrader 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
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?
--
View this message in context:
http://u-boot.10912.n7.nabble.com/PPC4XX-Custom-Board-Failing-to-read-I2C-tp151298p151
On 03.04.2013 18:15, txcotrader wrote:
> Thanks Stefan, great suggestion, I failed to copy those configurations into
> my original message.
>
> /*---
> * DDR SDRAM
> *--
Thanks Stefan, great suggestion, I failed to copy those configurations into
my original message.
/*---
* DDR SDRAM
*--*/
#if !defined(CONFIG_NAND_U_BOOT)
#
On 02.04.2013 23:48, txcotrader wrote:
> Hello,
>
> I'm looking for some direction. I'm trying to update my version of u-boot
> for a custom board based off of the PPC460SX. I'm struggling to understand
> why I cannot get past reading the I2C on the DIMM. I'm receiving this error:
>
> CPU: AMCC
Hello,
I'm looking for some direction. I'm trying to update my version of u-boot
for a custom board based off of the PPC460SX. I'm struggling to understand
why I cannot get past reading the I2C on the DIMM. I'm receiving this error:
CPU: AMCC PowerPC 460SX Rev. A at 231.291 MHz (PLB=33 OPB=16 E
20 matches
Mail list logo
