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

[Peter Asemann <peter.asemann@web.de>]

> 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