[U-Boot-Users] i2c compiling and/or linking problem
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
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
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
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
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
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
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
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.
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
participants (4)
-
gleb＠nbase.co.il -
Jerry Van Baren -
Peter Asemann -
Wolfgang Denk