[U-Boot] [u-boot v2] and i2c

Hello Sascha,
I actually looked in the u-boot-v2.git in the i2c branch, because I wanted to look how things in v2 work, specially I2C Subsystem ... and I have a first question:
- In ppc area, we start running from flash and have to relocate code. Before setting up RAM, we maybe have to read SPD EEprom over I2C for this. How could this work in v2? I see in drivers/i2c/i2c-core.c in i2c_register_adapter () an INIT_LIST_HEAD(&adap->clients);
This could not work, when running from Flash, because we have no usable RAM ... So I looked how this device approach globally works, and found in lib/driver.c in register_device() also:
107 108 list_add_tail(&new_device->list, &device_list); 109 INIT_LIST_HEAD(&new_device->children); 110
so would this device_driver approach in v2 actually only work, if running from RAM? What if we need the devices earlier?
Maybe I overlooked something obvious?
bye Heiko

Hi Heiko,
On Tue, Apr 28, 2009 at 09:36:46AM +0200, Heiko Schocher wrote:
Hello Sascha,
I actually looked in the u-boot-v2.git in the i2c branch, because I wanted to look how things in v2 work, specially I2C Subsystem ... and I have a first question:
Note that the I2C branch is out of date and probably needs some updating. That does not affect your current problem though.
In ppc area, we start running from flash and have to relocate code. Before setting up RAM, we maybe have to read SPD EEprom over I2C for this. How could this work in v2? I see in drivers/i2c/i2c-core.c in i2c_register_adapter () an INIT_LIST_HEAD(&adap->clients);
This could not work, when running from Flash, because we have no usable RAM ... So I looked how this device approach globally works, and found in lib/driver.c in register_device() also:
107 108 list_add_tail(&new_device->list, &device_list); 109 INIT_LIST_HEAD(&new_device->children); 110
so would this device_driver approach in v2 actually only work, if running from RAM?
Yes
What if we need the devices earlier?
You would need portions of the driver which bypass the I2C framework. I did something similar for the console (see drivers/serial/serial_mpc5xxx.c). This is not particularly nice but I see no other way handling this. If done with care you can reuse most of the driver code. Once the framework is initialized the normal functions can be used.
Sascha

Hello Sascha,
Sascha Hauer wrote:
On Tue, Apr 28, 2009 at 09:36:46AM +0200, Heiko Schocher wrote:
Hello Sascha,
I actually looked in the u-boot-v2.git in the i2c branch, because I wanted to look how things in v2 work, specially I2C Subsystem ... and I have a first question:
Note that the I2C branch is out of date and probably needs some updating. That does not affect your current problem though.
Yep, I know.
In ppc area, we start running from flash and have to relocate code. Before setting up RAM, we maybe have to read SPD EEprom over I2C for this. How could this work in v2? I see in drivers/i2c/i2c-core.c in i2c_register_adapter () an INIT_LIST_HEAD(&adap->clients);
This could not work, when running from Flash, because we have no usable RAM ... So I looked how this device approach globally works, and found in lib/driver.c in register_device() also:
107 108 list_add_tail(&new_device->list, &device_list); 109 INIT_LIST_HEAD(&new_device->children); 110
so would this device_driver approach in v2 actually only work, if running from RAM?
Yes
Hmm... :-(
What if we need the devices earlier?
You would need portions of the driver which bypass the I2C framework. I did something similar for the console (see drivers/serial/serial_mpc5xxx.c). This is not particularly nice but I
:-(
Ok, thanks for the info.
bye Heiko
participants (2)
-
Heiko Schocher
-
Sascha Hauer