[U-Boot-Users] i2c compiling and/or linking problem

[U-Boot-Users] i2c compiling and/or linking problem

[Peter Asemann]

Well, I wanted to compile u-boot with i2c support.
So I just added an #include <i2c.h> in to my boards board.c, put #define 
CFG_HARD_I2C in the include-file and thought that'd be enough.

Well... apparently that's not enough as compiling (make distclean done 
before) stops in the linking process with a lot of complaints like this:

common/libcommon.a(cmd_i2c.o)(.text+0x128): In function `do_i2c_md':
/opt/asemann/u-boot/common/cmd_i2c.c:188: undefined reference to `i2c_read'

and the error

common/libcommon.a(exports.o)(.got2+0x24):/opt/asemann/u-boot/common/exports.c:14: 
undefined reference to `i2c_read'

So... any suggestions where to add some references so it find all the 
stuff? I tried to figure out what other boards that use i2c do, but 
couldn't find any hints that I missed some Makefile or config, got lost 
in the build-system.

Peter Asemann

[U-Boot-Users] i2c compiling and/or linking problem

[Wolfgang Denk]

In message <420B8EFE.7010301@web.de> you wrote:
> Well, I wanted to compile u-boot with i2c support.

For which board? Which architecture?

> So I just added an #include <i2c.h> in to my boards board.c, put #define 

Why would you need this?

> CFG_HARD_I2C in the include-file and thought that'd be enough.

Why do you want to use CFG_HARD_I2C? Soft-I2C is much easier.

> Well... apparently that's not enough as compiling (make distclean done 
> before) stops in the linking process with a lot of complaints like this:
...
> undefined reference to `i2c_read'

Maybe there is no hardware I2C implementation for your processor?

> So... any suggestions where to add some references so it find all the 
> stuff? I tried to figure out what other boards that use i2c do, but 
> couldn't find any hints that I missed some Makefile or config, got lost 
> in the build-system.

You only have to compare the board config files. No other changes are
needed. Again, I recommend to use soft-i2c  instead.  There  is  zero
advantages with hard-i2c, just a lot of trouble.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A penny saved is a penny to squander.
- Ambrose Bierce

[U-Boot-Users] i2c compiling and/or linking problem

[Peter Asemann]

>>So I just added an #include <i2c.h> in to my boards board.c, put #define 
> Why would you need this?

No idea, just because others do include it for some reason.

>>CFG_HARD_I2C in the include-file and thought that'd be enough.

> Why do you want to use CFG_HARD_I2C? Soft-I2C is much easier.

I thought that CFG_HARD_I2C would do everything on its own - and there's 
less to configure in the /include/configs/board.h file.
Why is the HARD I2c so much more difficult?

> Maybe there is no hardware I2C implementation for your processor?
I just assumed there was one for the MPC875, maybe that was premature.

> You only have to compare the board config files. No other changes are
> needed. Again, I recommend to use soft-i2c  instead.  There  is  zero
> advantages with hard-i2c, just a lot of trouble.

You're the expert, I'm convinced ;-)

Thanks a lot,

Peter Asemann

[U-Boot-Users] i2c compiling and/or linking problem

[Wolfgang Denk]

In message <420B9826.9080405@web.de> you wrote:
> > Why would you need this?
> 
> No idea, just because others do include it for some reason.

This is a bad strategy. NEVER do something  which  you  don't  under-
stand.  At  least  TRY  to understand things before blindly following
others.

> I thought that CFG_HARD_I2C would do everything on its own - and there's 

Remember, this is software. Never will "everything"  happen  "on  its
own". You will always have to program each and every action yourself.

> less to configure in the /include/configs/board.h file.
> Why is the HARD I2c so much more difficult?

Just look at the code.

> > Maybe there is no hardware I2C implementation for your processor?
> I just assumed there was one for the MPC875, maybe that was premature.

No, that's an 8xx, and should work. However, I still recommend to use
soft-i2c instead.

> > needed. Again, I recommend to use soft-i2c  instead.  There  is  zero
> > advantages with hard-i2c, just a lot of trouble.
> 
> You're the expert, I'm convinced ;-)

Again, this is not a good strategy. Of course I feel flattered if you
call me an expert, but I'd prefer if you make your decisions based on
understanding, not on hearsay.

Viele Gr??e,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If you're not part of the solution, then you're part of the  precipi-
tate.

[U-Boot-Users] i2c compiling and/or linking problem - solved (for the archive)

[Peter Asemann]

> This is a bad strategy. NEVER do something  which  you  don't  under-
> stand.  At  least  TRY  to understand things before blindly following
> others.

I should not start an argument here, but: Sometimes understanding 
follows seeing the solution.

>>I thought that CFG_HARD_I2C would do everything on its own - and there's 
> 
> Remember, this is software. Never will "everything"  happen  "on  its
> own". You will always have to program each and every action yourself.

But ... another assumption of mine ... normally hardware support makes 
things easier than if there is no hardware support, for noone implements 
hardware support for something that can be done in software quite 
simple... or not?

>>less to configure in the /include/configs/board.h file.
>>Why is the HARD I2c so much more difficult?
>  
> Just look at the code.

Okay, the HARD code is twice as long and looks more complicated, but 
this could - theoretically - also be the fault of the coder, not the 
hardware.

> No, that's an 8xx, and should work. However, I still recommend to use
> soft-i2c instead.

Got it compiling with HARD support. Misspelled CONFIG_HARD_I2C (wrote 
CFG_HARD_I2C) and didn't see it until grep'ing all other HARD-using 
board sources.

>>>needed. Again, I recommend to use soft-i2c  instead.  There  is  zero
>>>advantages with hard-i2c, just a lot of trouble.

I'll also prepare SOFT support - the prototype of the board still is 
being faciliated, so I can't test anything in real life anyway.

>>You're the expert, I'm convinced ;-)
>  
> Again, this is not a good strategy. Of course I feel flattered if you
> call me an expert, but I'd prefer if you make your decisions based on
> understanding, not on hearsay.

At least believing in and following experts is a good excuse in case you 
fail (Noone ever got fired for buying IBM - or trusting experts).
It also saves time - if it works - which it does most time.

Best regards,

Peter Asemann

[U-Boot-Users] i2c compiling and/or linking problem - solved (for the archive)

[Jerry Van Baren]

Peter Asemann wrote:

[snip]

> But ... another assumption of mine ... normally hardware support makes 
> things easier than if there is no hardware support, for noone implements 
> hardware support for something that can be done in software quite 
> simple... or not?

Not necessarily.  Hardware can do things in the background, but u-boot 
doesn't use "background" operation (by design and mostly by necessity). 
  Hardware requires setting up the operation, waiting for it to 
complete, and then getting the results.  Error detection and recovery 
(especially for I2C) is a real pain.

Trivia: I2C on the 82xx and, IIRC, 8xx family is actually done in 
software (microcode in the CPM) and is horribly inefficient in terms of 
CPM resources (not that that matters for u-boot).

>>> less to configure in the /include/configs/board.h file.
>>> Why is the HARD I2c so much more difficult?
>>
>>  
>> Just look at the code.
> 
> 
> Okay, the HARD code is twice as long and looks more complicated, but 
> this could - theoretically - also be the fault of the coder, not the 
> hardware.

We're all above average here ;-).  Seriously, there isn't much 
inefficient code in u-boot.  About the only thing I can think of is the 
8245 I2C code (which is hardware only)... that is an ugly glue-in of 
some example Mot code so we can Blame Someone Else[tm].

[snip]

> Best regards,
> 
> Peter Asemann

gvb

[U-Boot-Users] i2c compiling and/or linking problem - solved (for the archive)

[Wolfgang Denk]

In message <420CCAFE.3000004@smiths-aerospace.com> you wrote:
> 
> Trivia: I2C on the 82xx and, IIRC, 8xx family is actually done in 
> software (microcode in the CPM) and is horribly inefficient in terms of 
> CPM resources (not that that matters for u-boot).

Well, it DOES matter.

If you need to access data in U-Boot, you most probably will want  to
access  the  same data in Linux, too. If not now, then with your next
software update. We just had a case where a  customer  ran  into  I2C
problems  during  shutdown  of the system - he tried to save a lot of
data to an IDE device connected to the PCMCIA controller, and  to  an
EEPROM on the I2C bus. We got lots of lost IDE interrupts because the
PCMCIA  controller  died again and again when the CPM got overloaded,
and we got lots of I2C errors - it turned out that writing just a few
bytes to EEPROM ran into a timeout which was set to a  generous  full
second. Unfortunately, the CPM needed more than 3 seconds (!) in some
cases to complete the I2C request.

I really dislike I2C, especially when used to store data like  in  an
EEPROM.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Death. Destruction. Disease. Horror. That's what war  is  all  about.
That's what makes it a thing to be avoided.
	-- Kirk, "A Taste of Armageddon", stardate 3193.0

[U-Boot-Users] i2c compiling and/or linking problem - solved (for the archive)

[Gleb Natapov]

On Fri, Feb 11, 2005 at 10:10:54AM -0500, Jerry Van Baren wrote:
> >Okay, the HARD code is twice as long and looks more complicated, but 
> >this could - theoretically - also be the fault of the coder, not the 
> >hardware.
> 
> We're all above average here ;-).  Seriously, there isn't much 
> inefficient code in u-boot.  About the only thing I can think of is the 
> 8245 I2C code (which is hardware only)... that is an ugly glue-in of 
> some example Mot code so we can Blame Someone Else[tm].
> 
8245 no longer use Motorola code for i2c. So if you want to blame
someone, blame me :)

--
			Gleb.

[U-Boot-Users] i2c compiling and/or linking problem - solved (for the archive)

[Wolfgang Denk]

In message <420CC656.7000309@web.de> you wrote:
>
> But ... another assumption of mine ... normally hardware support makes 
> things easier than if there is no hardware support, for noone implements 
> hardware support for something that can be done in software quite 
> simple... or not?

Not in this case. The soft-i2c driver just toggles two port pins with
appropriate busy wait loops to get  the  bit  timings  right.  Really
simple.  For  the  CPM  driver you have to prepare buffers and buffer
descriptors, initialize the CPM's I2C controller, hand  it  over  the
buffer  descriptor(s),  start  the transfer, wait until it gets done,
check for error conditions, etc.

Hardware I2C is OK in Linux, because it is a slow  transfer  and  you
don't  want to keep the CPU in a busy wait loop just to clock out the
bits when you can start a transfer and then wait  for  an  interrupt.
Here  the overhead is payed for by the advantage of being able to run
other more useful things in parallel. U-Boot is  single-threaded,  so
the CPM i2c driver is just a waste of code and programming effort.

Well, to be honest, it may have advantages when reading lots of  data
at  "high"  speeds  (i. e. with a I2C clock >> 100 kHz). Then you may
actually be faster. But when time is critical than  this  is  only  a
workaround  for  the design error of putting time critical data in an
I2C device.


> Okay, the HARD code is twice as long and looks more complicated, but 
> this could - theoretically - also be the fault of the coder, not the 
> hardware.

It ain't so.

> At least believing in and following experts is a good excuse in case you 
> fail (Noone ever got fired for buying IBM - or trusting experts).
> It also saves time - if it works - which it does most time.

:-)

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Philosophy:  A route of many roads leading from nowhere to nothing.
- Ambrose Bierce