Hello Timur,
Timur Tabi wrote:
> Wolfgang Denk wrote:
>> As mentioned before, this is what we currently have as "device model"
>> in U-Boot - not only I2C: we have the same "current device" concept
>> with IDE, USB, ...
>
> The difference is that I2C operations are typically done internally by
> other code, whereas IDE, USB, etc are done by the user on the command
> line. It's not unusual for boot code to access multiple I2C devices on
> different buses, so we're switching I2C buses a lot. People generally
> don't try to access two networks or two USB devices back-to-back, but
> that's exactly what we do with I2C.
>
> The other problem is that I2C operations are necessary prior to
> relocation, but IDE, USB, etc generally are not. That's why we have this:
>
> static unsigned int i2c_bus_num __attribute__ ((section (".data"))) =
> CONFIG_SYS_SPD_BUS_NUM;
Yep, correct. For that case, I need the "trickery" with the "cur_i2c_adap"
pointer in gd_t in the "new" framework, as gd_t is writeable before
relocation ...
> We need to initialize i2c_bus_num to the I2C bus that SPD is on, because
> i2c_bus_num is not writable until after relocation, and DDR initialization
> requires I2C.
>
> A board that has SPD on two different I2C buses could not be supported by
> U-Boot today.
... and so with the "new" framework, it should be possible to switch to
other i2c busses (incl. i2c muxes on that), before relocation.
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
