[U-Boot-Users] Board init

[U-Boot-Users] Board init

[Robert Schwebel]

Hi, 

The PXA250 often has the problem that when it is powercycled during i2c
activity there are "hanging" transfers on the bus. We now have connected
one GPIO line to the i2c bus so that we are able to toggle the line
several times to let all bus participants think that current transfers
are finished. 

Now I would like to add this method to u-boot; unfortunately, the
environment is read from the serial eeprom _before_
board/xxx/board.c:board_init() or misc_init_r are run. So where is the
best place to add the code? It could be put into
cpu/xscale/i2c.c:i2c_reset(), but as it definitely is board dependend I
would not think it is a good idea. 

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] Board init

[Wolfgang Denk]

In message <20030304132446.GE3593@pengutronix.de> you wrote:
> 
> The PXA250 often has the problem that when it is powercycled during i2c
> activity there are "hanging" transfers on the bus. We now have connected

Are you refering to the I2C Edge Conditions propblem? (You _did_ read
the doc/I2C_Edge_Conditions files, didn't you?)

> one GPIO line to the i2c bus so that we are able to toggle the line
> several times to let all bus participants think that current transfers
> are finished. 
> 
> Now I would like to add this method to u-boot; unfortunately, the
> environment is read from the serial eeprom _before_
> board/xxx/board.c:board_init() or misc_init_r are run. So where is the
> best place to add the code? It could be put into
> cpu/xscale/i2c.c:i2c_reset(), but as it definitely is board dependend I
> would not think it is a good idea. 

Seems you are (at least) the second person who  got  bitten  by  this
probem,  so  we  should probably add a generic solution that will fix
this problem in all cases.

Can you come up with a generic solution?


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
The use of COBOL cripples the mind; its teaching  should,  therefore,
be regarded as a criminal offense.                   - E. W. Dijkstra

[U-Boot-Users] Board init

[Robert Schwebel]

On Tue, Mar 04, 2003 at 04:27:24PM +0100, Wolfgang Denk wrote:
> Are you refering to the I2C Edge Conditions propblem? (You _did_ read
> the doc/I2C_Edge_Conditions files, didn't you?)

Nope, but that seems to be what we also see :-) 

> Seems you are (at least) the second person who  got  bitten  by  this
> probem,  so  we  should probably add a generic solution that will fix
> this problem in all cases.
> 
> Can you come up with a generic solution?

I'll try something.

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] Board init

[Adam Bezanson]

This is an interesting topic, because I am actually
seeing I2C bus hangs on our own custom hardware
once and a great while. This hardware is PowerPC
based but doesn't use u-boot. I kind of narrowed
it down to the processor getting reset during
an I2C transaction. Since the slave device (EEPROM with a temp
sensor in it) doesn't have a reset, the bus gets stuck
low and when a master tries to start a new transaction
it can't because the bus appears busy.

Which line did you attach a GPIO pin to? The clock or the data?
It seems that this would be a good generic solution to this
particular part of the problem to simply clock the slaves back to
a known state. I'm not sure if I've seen corruption as mentioned in the
I2C_Edge_Conditions doc.

I was thinking, in my design, since I have independent control of the
reset to the processor subsystem in hardware, To make the code set a bit
which gates the reset to the processor subsystem while doing I2C accesses.
When the access(es) finish the bit would be cleared and then the reset would
be
allowed to take effect. This of course is very hardware specific, but just a
thought
I had.

Adam



-----Original Message-----
From: u-boot-users-admin@lists.sourceforge.net
[mailto:u-boot-users-admin at lists.sourceforge.net]On Behalf Of Robert
Schwebel
Sent: Tuesday, March 04, 2003 10:58 AM
To: U-Boot Mailing List
Subject: Re: [U-Boot-Users] Board init


On Tue, Mar 04, 2003 at 04:27:24PM +0100, Wolfgang Denk wrote:
> Are you refering to the I2C Edge Conditions propblem? (You _did_ read
> the doc/I2C_Edge_Conditions files, didn't you?)

Nope, but that seems to be what we also see :-)

> Seems you are (at least) the second person who  got  bitten  by  this
> probem,  so  we  should probably add a generic solution that will fix
> this problem in all cases.
>
> Can you come up with a generic solution?

I'll try something.

Robert
--
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] I2C Initialization

[Reinhard Meyer]

Its one of the trickiest things at all...

For I2C Reset it is adviseable to cause at least a sequence of eight STOP
one START and another STOP condition. Some Manufacturers (Microchip when I
remember correctly) require that because in violation of the I2C Spec they
do not recognize a STOP condition while expecting the Bits of a Byte.
Otherwise you might end up writing an arbitrary value the last addressed
location in your I2C memory if the previous transfer has been interrupted in
an unfortunate state... (see also I2C Edge Conditions, which addresses a
part of the Problem).

I know it doesn't help you, but we put our Vital Product Data section in a
part of the EEPROM that can be protected against writes by keeping the WP
pulled high (ATMEL 24LC64: 6kb always writeable, 2kb protected). The test
adapter will pull it low so it can be programmed during testing.

In order to do that you need TWO general purpose I/O Lines. Its simple with
the MPC8xx series, since the I2C Bus Pins can also be used as general
purpose I/O lines. Can't you somehow directly control your I2C lines through
the processor?

((Note to myself: check whether the SOFT_I2C driver in u-boot does that kind
of init, if NOT add it?))

A wild idea might be to conditionally power the I2C devices to cause them a
power-on-reset...

Reinhard

> This is an interesting topic, because I am actually
> seeing I2C bus hangs on our own custom hardware
> once and a great while. This hardware is PowerPC
> based but doesn't use u-boot. I kind of narrowed
> it down to the processor getting reset during
> an I2C transaction. Since the slave device (EEPROM with a temp
> sensor in it) doesn't have a reset, the bus gets stuck
> low and when a master tries to start a new transaction
> it can't because the bus appears busy.
>
> Which line did you attach a GPIO pin to? The clock or the data?
> It seems that this would be a good generic solution to this
> particular part of the problem to simply clock the slaves back to
> a known state. I'm not sure if I've seen corruption as mentioned in the
> I2C_Edge_Conditions doc.
>
> I was thinking, in my design, since I have independent control of the
> reset to the processor subsystem in hardware, To make the code set a bit
> which gates the reset to the processor subsystem while doing I2C accesses.
> When the access(es) finish the bit would be cleared and then the reset
would
> be
> allowed to take effect. This of course is very hardware specific, but just
a
> thought
> I had.

What _IF_ your systems hangs during that phase?

[U-Boot-Users] I2C Initialization

[Wolfgang Denk]

In message <05ff01c2e2da$20817c60$6d4ba8c0@alb.sub.de> you wrote:
> 
> In order to do that you need TWO general purpose I/O Lines. Its simple with
> the MPC8xx series, since the I2C Bus Pins can also be used as general
> purpose I/O lines. Can't you somehow directly control your I2C lines through
> the processor?

This is my hope...

> ((Note to myself: check whether the SOFT_I2C driver in u-boot does that kind
> of init, if NOT add it?))

This is exactly what I was thinking of. At least on 8xx and  82xx  it
makes  little  sense  to  use the CPM based I2C anyway - the overhead
necessary to set up a transfer  outperforms  the  win  of  speed  for
almost  all  cases (except when loading the environment from big fast
devices like FRAM - but this again is only  noticable  when  you  are
optimizing  for  boot  time, and then you will put the environment if
flash which is MUCH faster).


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Do you suppose the reason the ends of the `Intel Inside'  logo  don't
match up is that it was drawn on a Pentium?

[U-Boot-Users] I2C Initialization

[Adam Bezanson]

I don't have the ability to control the I2C lines directly from the
processor. I'm using a 7410. I have a System controller chip which
has the I2C master controller in it. All it provides is a higher lever
indirect access register interface to control I2C transactions.

I have though about controlling the power supply to the I2C slaves
and have them controled by register bits in memory space. But this
would require alot of rework of the hardware at several places in my
particular system.

In terms of your question of the system hanging while masking reset to the
processor, I was thinking of adding a timer in hardware to unmask the reset
if it's set too long. Thanks for making sure I've thought of all the
obvious corner cases.

Regards,
Adam



-----Original Message-----
From: u-boot-users-admin@lists.sourceforge.net
[mailto:u-boot-users-admin at lists.sourceforge.net]On Behalf Of Reinhard
Meyer
Sent: Wednesday, March 05, 2003 12:43 AM
To: U-Boot Mailing List
Subject: [U-Boot-Users] I2C Initialization


Its one of the trickiest things at all...

For I2C Reset it is adviseable to cause at least a sequence of eight STOP
one START and another STOP condition. Some Manufacturers (Microchip when I
remember correctly) require that because in violation of the I2C Spec they
do not recognize a STOP condition while expecting the Bits of a Byte.
Otherwise you might end up writing an arbitrary value the last addressed
location in your I2C memory if the previous transfer has been interrupted in
an unfortunate state... (see also I2C Edge Conditions, which addresses a
part of the Problem).

I know it doesn't help you, but we put our Vital Product Data section in a
part of the EEPROM that can be protected against writes by keeping the WP
pulled high (ATMEL 24LC64: 6kb always writeable, 2kb protected). The test
adapter will pull it low so it can be programmed during testing.

In order to do that you need TWO general purpose I/O Lines. Its simple with
the MPC8xx series, since the I2C Bus Pins can also be used as general
purpose I/O lines. Can't you somehow directly control your I2C lines through
the processor?

((Note to myself: check whether the SOFT_I2C driver in u-boot does that kind
of init, if NOT add it?))

A wild idea might be to conditionally power the I2C devices to cause them a
power-on-reset...

Reinhard

> This is an interesting topic, because I am actually
> seeing I2C bus hangs on our own custom hardware
> once and a great while. This hardware is PowerPC
> based but doesn't use u-boot. I kind of narrowed
> it down to the processor getting reset during
> an I2C transaction. Since the slave device (EEPROM with a temp
> sensor in it) doesn't have a reset, the bus gets stuck
> low and when a master tries to start a new transaction
> it can't because the bus appears busy.
>
> Which line did you attach a GPIO pin to? The clock or the data?
> It seems that this would be a good generic solution to this
> particular part of the problem to simply clock the slaves back to
> a known state. I'm not sure if I've seen corruption as mentioned in the
> I2C_Edge_Conditions doc.
>
> I was thinking, in my design, since I have independent control of the
> reset to the processor subsystem in hardware, To make the code set a bit
> which gates the reset to the processor subsystem while doing I2C accesses.
> When the access(es) finish the bit would be cleared and then the reset
would
> be
> allowed to take effect. This of course is very hardware specific, but just
a
> thought
> I had.

What _IF_ your systems hangs during that phase?




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] I2C Initialization

[Robert Schwebel]

On Wed, Mar 05, 2003 at 08:05:45AM -0500, Adam Bezanson wrote:
> I don't have the ability to control the I2C lines directly from the
> processor. I'm using a 7410. I have a System controller chip which has
> the I2C master controller in it. All it provides is a higher lever
> indirect access register interface to control I2C transactions.
> 
> I have though about controlling the power supply to the I2C slaves and
> have them controled by register bits in memory space. But this would
> require alot of rework of the hardware at several places in my
> particular system.
> 
> In terms of your question of the system hanging while masking reset to
> the processor, I was thinking of adding a timer in hardware to unmask
> the reset if it's set too long. Thanks for making sure I've thought of
> all the obvious corner cases.

All these answers let me conclude that we need a board specific
board_i2c_reset() function. I'll prepare a patch. 

Robert 
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] I2C Initialization

[Robert Schwebel]

On Wed, Mar 05, 2003 at 03:44:41PM +0100, Robert Schwebel wrote:
> All these answers let me conclude that we need a board specific
> board_i2c_reset() function. I'll prepare a patch. 

I have a patch in my local working copy but it becomes more and more
difficult to sort it out as my tree begins to differ significantly from
the CVS. Wolfgang, can you estimate when you'll find some time to look
at my PXA patches? I don't want to push you, but if it'll be some time
I'll make another snapshot of my tree available on our homepage. 

What I've done is to add an CFG_I2C_COLDSTART option. When set
i2c_coldstart(), implemented in board/myboard/myboard.c, is called from
lib_xxx/board.c early in the boot sequence, especially before the
environment was read. 

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] I2C Initialization

[Wolfgang Denk]

In message <20030305173922.GQ16290@pengutronix.de> Robert Schwebel wrote:
> 
> What I've done is to add an CFG_I2C_COLDSTART option. When set
> i2c_coldstart(), implemented in board/myboard/myboard.c, is called from
> lib_xxx/board.c early in the boot sequence, especially before the
> environment was read. 

Please call it "i2c_init_board()" (similar to pci_init_board()"), and
call it from i2c_init().

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"He only drinks when he gets depressed." "Why does he get depressed?"
"Sometimes it's because he hasn't had a drink."
                                     - Terry Pratchett, _Men at Arms_

[U-Boot-Users] I2C Initialization

[Robert Schwebel]

On Wed, Mar 05, 2003 at 08:12:06PM +0100, Wolfgang Denk wrote:
> Please call it "i2c_init_board()" (similar to pci_init_board()"), and
> call it from i2c_init().

I've renamed it. It's not easily possible to put it in i2c_init() as
this is implemented in cpu/xxx/i2c.c. Calling the function is cpu
independend, so it should be done from a higher level. For ppc I've put
it into lib_ppc/board.c:init_func_i2c(), ARM doesn't currently have the
same design, so I've put it in a comparable place inside
lib_arm/board.c:start_armboot(). Is this ok for your?  

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] I2C Initialization

[Wolfgang Denk]

In message <20030306062129.GT16290@pengutronix.de> Robert Schwebel wrote:
> On Wed, Mar 05, 2003 at 08:12:06PM +0100, Wolfgang Denk wrote:
> > Please call it "i2c_init_board()" (similar to pci_init_board()"), and
> > call it from i2c_init().
> 
> I've renamed it. It's not easily possible to put it in i2c_init() as
> this is implemented in cpu/xxx/i2c.c. Calling the function is cpu
> independend, so it should be done from a higher level. For ppc I've put

I don't understand the problem. i2c_init() is the first I2C related function that will be called on any system.

It is implemented in common/soft_i2c.c for the itbanging version  and
in cpu/??/i2c.c and cpu/mpc824x/drivers/i2c/i2c1.c for the others.


What prevents you from adding it there?

I don't want to add even more code to the init functions part.  Let's
keep the stuff as local as possible.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
No question is too silly to ask. Of course, some  questions  are  too
silly to to answer...  - L. Wall & R. L. Schwartz, _Programming Perl_

[U-Boot-Users] I2C Initialization

[Robert Schwebel]

On Thu, Mar 06, 2003 at 09:01:48AM +0100, Wolfgang Denk wrote:
> I don't understand the problem. i2c_init() is the first I2C related
> function that will be called on any system.
> 
> It is implemented in common/soft_i2c.c for the itbanging version  and
> in cpu/??/i2c.c and cpu/mpc824x/drivers/i2c/i2c1.c for the others.
> 
> 
> What prevents you from adding it there?
> 
> I don't want to add even more code to the init functions part.  Let's
> keep the stuff as local as possible.

Do we agree that i2c_init_board() has to be called right before (or at
the beginning of) i2c_init()? So we have the choice to either add the
call to all 12 cpu implementations or only once in the place right
before i2c_init() is called. Why make it cpu dependend when it is not? 

Robert 
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] I2C Initialization

[Wolfgang Denk]

In message <20030306084006.GZ16290@pengutronix.de> you wrote:
> 
> Do we agree that i2c_init_board() has to be called right before (or at
> the beginning of) i2c_init()? So we have the choice to either add the

At the beginning of i2c_init().

> call to all 12 cpu implementations or only once in the place right
> before i2c_init() is called. Why make it cpu dependend when it is not? 

I don't think this means it's CPU dependend.


Assume we need 5 more init routines for the I2C code. It makes  sense
to  put  all  this in the i2c_init() code. It makes no sense to me to
put all this in the board.c file - we have only one  I2C  sub-system,
so there should be only one init function call for it.



Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
The use of anthropomorphic terminology when  dealing  with  computing
systems is a symptom of professional immaturity.   -- Edsger Dijkstra

[U-Boot-Users] I2C Initialization

[Robert Schwebel]

On Thu, Mar 06, 2003 at 10:24:41AM +0100, Wolfgang Denk wrote:
> At the beginning of i2c_init().

Ok, fixed in local tree. I cannot test it for ppc architectures, I don't
have the crosschains to even find out if it compiles. 

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] I2C Initialization

[Joakim Tjernlund]

> For I2C Reset it is adviseable to cause at least a sequence of eight STOP
> one START and another STOP condition. Some Manufacturers (Microchip when I
> remember correctly) require that because in violation of the I2C Spec they
> do not recognize a STOP condition while expecting the Bits of a Byte.
> Otherwise you might end up writing an arbitrary value the last addressed
> location in your I2C memory if the previous transfer has been interrupted in
> an unfortunate state... (see also I2C Edge Conditions, which addresses a
> part of the Problem).

Hi 

I have a DS1337 RTC which hangs if you press the reset button while doing
hwclock. To "unhang" the DS1337 I have to remove the battery :-(.
I figured the above I2C reset trick would help, but so far nothing helps.

I copied parts of mpc8xx/soft_i2c.c in my ppcboot(1.0.5) and hacked
a I2C Reset function that is called from misc_init_r().

Someone else that has this problem or can see what I am doing wrong? 

This is my i2c reset hack:

#define PB_SCL		0x00000020	/* PB 26 */
#define PB_SDA		0x00000010	/* PB 27 */

#define	SET_PB_BIT(bit)	do {						\
			immr->im_cpm.cp_pbdir |=  bit;	/* output */	\
			immr->im_cpm.cp_pbdat |=  bit;	/* set  1 */	\
			udelay (5);					\
		} while (0)

#define RESET_PB_BIT(bit) do {						\
			immr->im_cpm.cp_pbdir |=  bit;	/* output */	\
			immr->im_cpm.cp_pbdat &= ~bit;	/* set  0 */	\
			udelay (5);					\
		} while (0)
/*-----------------------------------------------------------------------
 * START: High -> Low on SDA while SCL is High
 */
static void send_start (void)
{
	volatile immap_t *immr = (immap_t *)CFG_IMMR;

	SET_PB_BIT   (PB_SCL);
	udelay (10);
	RESET_PB_BIT (PB_SDA);
	udelay (20);
}

/*-----------------------------------------------------------------------
 * STOP: Low -> High on SDA while SCL is High
 */
static void send_stop (void)
{
	volatile immap_t *immr = (immap_t *)CFG_IMMR;

	RESET_PB_BIT (PB_SDA);
	udelay (10);
	SET_PB_BIT   (PB_SCL);
	udelay (10);
	SET_PB_BIT   (PB_SDA);
	udelay (20);
}

void my_i2c_reset(void)
{
	volatile immap_t *immr = (immap_t *)CFG_IMMR;

	immr->im_cpm.cp_pbpar &= ~(PB_SCL | PB_SDA);	/* GPIO */
	immr->im_cpm.cp_pbodr |=  (PB_SCL | PB_SDA);	/* Open Drain Output */

	send_stop();
	send_stop();
	send_stop();
	send_stop();
	send_stop();
	send_stop();
	send_stop();
	send_stop();

	send_start();

	send_stop();
}
 

[U-Boot-Users] I2C Initialization

[Robert Schwebel]

On Wed, Mar 12, 2003 at 09:31:46AM +0100, Joakim Tjernlund wrote:
> I copied parts of mpc8xx/soft_i2c.c in my ppcboot(1.0.5) and hacked
> a I2C Reset function that is called from misc_init_r().

You should use the i2c_init_board() infrastructure I've recently added. 

On PXA you get problems when you just toggle between the states - the
internal i2c controller thinks there is traffic. So for the innokom
board we switch betwenn "low" and "high impedance". I have no idea if
that helps in your case... 

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] I2C Initialization

[Joakim Tjernlund]

> On Wed, Mar 12, 2003 at 09:31:46AM +0100, Joakim Tjernlund wrote:
> > I copied parts of mpc8xx/soft_i2c.c in my ppcboot(1.0.5) and hacked
> > a I2C Reset function that is called from misc_init_r().
> 
> You should use the i2c_init_board() infrastructure I've recently added. 
> 
> On PXA you get problems when you just toggle between the states - the
> internal i2c controller thinks there is traffic. So for the innokom
> board we switch betwenn "low" and "high impedance". I have no idea if
> that helps in your case... 
> 
> Robert

I found the cause. The DS1337 is in Data Read(Slave Transmitter Mode) and
is in the middle of a byte transfer. SDA is activly driven low by the DS1337
and therefore it won't listen to START/STOP conditions. One must generate
clocks until it releases SDA. I am not sure how to do this in
a safe way.

 Any ideas?

 Jocke

[U-Boot-Users] I2C Initialization, important Update!!

[Joakim Tjernlund]

> > For I2C Reset it is adviseable to cause at least a sequence of eight STOP
> > one START and another STOP condition. Some Manufacturers (Microchip when I
> > remember correctly) require that because in violation of the I2C Spec they
> > do not recognize a STOP condition while expecting the Bits of a Byte.

So does the DS1337 also, but I don't think this is a bug. When you are
reading FROM a I2C device, it owns the SDA signal and all you can do is
set the master SDA to high and generate clocks util the slave wants ACK/NACK.
When the slave sees the masters high SDA during the ACK/NACK cycle it will
look for a START or STOP condition. If the slave sees a STOP, it will go
into "passive"(release the bus) mode and listen for a new transmision.  

> > Otherwise you might end up writing an arbitrary value the last addressed
> > location in your I2C memory if the previous transfer has been interrupted in
> > an unfortunate state... (see also I2C Edge Conditions, which addresses a
> > part of the Problem).
> 
> Hi 
> 
> I have a DS1337 RTC which hangs if you press the reset button while doing
> hwclock. To "unhang" the DS1337 I have to remove the battery :-(.
> I figured the above I2C reset trick would help, but so far nothing helps.

[SNIP]

I managed to fix my problem, by coping the latest soft I2C code u-boot,
but I had to do some some changes to make it work reliably. I think this
is something all 8xx(possibly 82xx too) suffer from.

On my boards(862, B0 rev.) I2C_ACTIVE will pull SDA low initially whatever
I do(verified with a scope)!! 
This messes up the DS1337 so it wont recover(sometimes), no matter how
many times I run the loop. By modifying the code to avoid activate, see #if 1
below, SDA is kept high until I do stop(as it should). 

I think the I2C_ACTIVE behaviour is a CPU bug, possibly in other 8xx PUs as well.
Can anybody confirm this?

This is what I run now:

void myi2c_reset(void)
{
	volatile immap_t *immr = (immap_t *)CFG_IMMR;
	int j;

	immr->im_cpm.cp_pbpar &= ~(PB_SCL | PB_SDA);	/* GPIO */
	immr->im_cpm.cp_pbodr |=  PB_SDA;	/* Open Drain Output */

	if(getenv("noi2cres")){
	  printf("No I2C reset!\n");
	  return;
	}
if 1
	I2C_SCL(1);
	I2C_SDA(1);
	I2C_INIT;
	I2C_TRISTATE;
#else
	I2C_SCL(1);
	I2C_SDA(1);
	I2C_INIT;
	I2C_ACTIVE; /* Buggy, will pull SDA low! */
#endif
	for(j = 0; j < 9; j++) {
		I2C_SCL(0);
		I2C_DELAY;
		I2C_DELAY;
		I2C_SCL(1);
		I2C_DELAY;
		I2C_DELAY;
	}
	send_stop();
}

[U-Boot-Users] I2C Initialization, important Update!!

[Wolfgang Denk]

In message <IGEFJKJNHJDCBKALBJLLAECLFLAA.joakim.tjernlund@lumentis.se> you wrote:
> 
...
> Can anybody confirm this?
> 
> This is what I run now:
> 
> void myi2c_reset(void)
> {
...

Can you please provide a  patch  that  can  be  applied  to  existing
sources? This would make testing much easier.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"Most people would like to be delivered  from  temptation  but  would
like it to keep in touch."                             - Robert Orben

[U-Boot-Users] I2C Initialization, important Update!!

[Joakim Tjernlund]

> Can you please provide a  patch  that  can  be  applied  to  existing
> sources? This would make testing much easier.

Compiles, but not tested in u-boot as I am still in ppcboot.

 Jocke
Index: common/soft_i2c.c
===================================================================
RCS file: /cvsroot/u-boot/u-boot/common/soft_i2c.c,v
retrieving revision 1.2
diff -u -u -r1.2 soft_i2c.c
--- common/soft_i2c.c	17 Dec 2002 01:51:08 -0000	1.2
+++ common/soft_i2c.c	14 Mar 2003 14:28:10 -0000
@@ -83,8 +83,12 @@
 #endif
 	int j;
 
-	I2C_ACTIVE;
+	I2C_SCL(1);
 	I2C_SDA(1);
+#ifdef	I2C_INIT
+	I2C_INIT;
+#endif
+	I2C_TRISTATE;
 	for(j = 0; j < 9; j++) {
 		I2C_SCL(0);
 		I2C_DELAY;
@@ -266,9 +270,6 @@
 	volatile immap_t *immr = (immap_t *)CFG_IMMR;
 #endif
 
-#ifdef	I2C_INIT
-	I2C_INIT;
-#endif
 	/*
          * WARNING: Do NOT save speed in a static variable: if the
          * I2C routines are called before RAM is initialized (to read

[U-Boot-Users] Board init

[Wolfgang Denk]

In message <NNEHJEGKOBOALJLKPJLDKEEKCDAA.bezanson@attbi.com> you wrote:
>
> Which line did you attach a GPIO pin to? The clock or the data?
> It seems that this would be a good generic solution to this

I don't think that  this  is  a  good  solution,  as  it  requires  a
modification  of the hardware and wasting a GPIO pin which should not
be necessary.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
If the hours are long enough and the pay  is  short  enough,  someone
will say it's women's work.

[U-Boot-Users] Board init

[Robert Schwebel]

On Wed, Mar 05, 2003 at 09:10:49AM +0100, Wolfgang Denk wrote:
> I don't think that  this  is  a  good  solution,  as  it  requires  a
> modification  of the hardware and wasting a GPIO pin which should not
> be necessary.
 
I don't see another possibility - on the PXA250 you cannot use the i2c
lines as generic I/O pins. 

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4