[U-Boot-Users] I2C related questions with regards to booting 8xx on 2.6.10-rc3

[Povolotsky, Alexander]

> Hello,
>  
> I have MPC880 microprocessor based board with single 24C02 I2C EEPROM,
> connected to the I2C bus.
 In 2.6.10-rc3 the 8xx configuration is only buildable for the following
settings : 

CONFIG_EXPERIMENTAL=y
# CONFIG_CLEAN_COMPILE is not set
CONFIG_BROKEN=y
CONFIG_BROKEN_ON_SMP=y
>  
However until some time ago, even bulding of 8xx with I2C configured was
broken.

> Per suggestion from Tom Rini,  I copied i2c-algo-8xx.h from Linux 2.4.26
>  into 2.6.10-rc3 code source and made couple small changes
> to allow building of the 8xx code with I2C configured, please see: 
> http://archives.andrew.net.au/lm-sensors/msg28725.html
>  
> Currently booting of the board hangs in the I2C driver after invocation of
> interruptible_sleep_on( )
>  function call  in cpm_iic_tryaddress( ) function (in i2c-algo-8xx.c
> file).
> 
> Is it appropriate to use the interruptible_sleep_on( ) function at the
> kernel booting stage ?
>  (I personally do not think so - since such usage prevents further kernel
> booting - as observed).
> What should be done in this code to avoid slleping ?
> 
> I presume that the usage of the interruptible_sleep_on( ) function would
> be appropriate if the 
> I2C would be configured as a module (after the kernel booting is
> completed) ?
> Follow up question:  is it really expected to do I2C initialization ONLY
> as a module after the kernel booting ?
> (is it documented anyplace ?) 
  
I understood (am I correct ?) that there is an alternative "soft" I2C
approach, used in U-boot ?
If so, do you think - is it possible to port and try this "soft" I2C method
at kernel booting ?


> The (end of the ) log buffer  (please note that I have console_init() call
> commented out and rely on log buffer examination
during the bootloader stage upon kernel's soft reboot)  shows following:
> ....
.....
<6>HDLC support module revision 1.17.
<6>elevator: using anticipatory as default io scheduler.
<5>physmap flash device:400000 at 4000000.
<4>__ioremap(): phys addr 04000000 is RAM lr c01d93f0.
<4>__ioremap(): virt_to_phys(high_memory) addr 02000000.
<4>__ioremap(): passed first cond.
<4>__ioremap(): passed second cond.
<4>__ioremap(): passed label.
<5>init_physmap after simple_map_init.
<5>init_physmap type=cfi_probe.
<6>phys_mapped_flash: Found 1 x16 devys_mapped_flash:
Found 1 x16 devices at 0x0 in 16-bit bank.
<4> Amd/Fujitsu Extended Query Tableat 0x0040.
<5>number of CFI chips: 1.
<5>cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness..
<5>init_physmap after for loop.
<5>RedBoot partition parsing not available.
<5>init_physmap after parse_mtd_partitions.
<6>mtd: Giving out device 0 to phys_mapped_flash.
<5>init_physmap after add_mtd_device.
<7>CLASS: registering class device: ID = 'mice'.       <<==== can not get
rid of this from configuration (Of course I do not have mice !) 
<6>mice: PS/2 mouse device common for all mice      
> <6>i2c /dev entries driver.
> <7>device class 'i2c-dev': registering.
> <7>bus i2c:add driver dev_driver.
> <7>i2c-core: driver dev_driver registered
> <6>i2c-rpx: i2c MPC8xx driver.
> <7>DEV: registering device: ID ='i2c-0'.
> <7>CLASS: registering class device: ID= 'i2c-0'.
> <7>i2c_adapter i2c-0:Registered as minor 0.
> <7>CLASS:registering class device: ID = 'i2c-0'
> <7>i2c_adapter i2c-0: registered as adapter #0.
> <4>cpm_iic_init() - iip=fa203c80.
> <4>cpm_iic_init[132] Install ISR for IRQ 16.
> <6>CPM interrupt c0105d90 replacing c01f7a8c.
> <3>request_irq() returned -22  for CPM vector 32.
> <6> i2c-algo-8xx.o: scanning bus m8xx........
> <4>cpm_iic_tryaddress(cpm=c019b9f8,addr=0).
> <4>iip fa203c80, dp_addr 0x800.
> <4>iic_tbase 2048, r_tbase 2048
> <4>about to sleep
> .ABOVE LINE IS THE LAST ENTRY IN THE LOG BUFFER - THE BOOT HANGS
> THEREAFTER ... 
> 
> Here is the fragment of the cpm_iic_tryaddress( ) function in
> i2c-algo-8xx.c,
> where the problem takes place.
This function is getting called from a "for loop"
with the increment of the addresses range, 
starting from the address "0" to address "128", but it is getting into sleep
on a first entry into the cpm_iic_tryaddress( ) function with address 0 as
an argument.
I tried to exclude address 0 from the loop and start with address 1 - but
then it would hang
at waiting response from address 1.
>  :
> .... 
> //      save_flags(flags); cli();
>         i2c->i2c_i2cer = 0xff;
>         i2c->i2c_i2cmr = 0x13;  /* Enable some interupts */
>         i2c->i2c_i2mod = 1;     /* Enable */
>         i2c->i2c_i2com = 0x81;  /* Start master */
> //      restore_flags(flags);
> 
>         if (cpm_debug > 1) printk("about to sleep\n");
> 
>         /* wait for IIC transfer */
> interruptible_sleep_on(&iic_wait);
> if (signal_pending(current))
>         return -EIO;
> 
> if (cpm_debug > 1) printk("back from sleep\n");
> 
> if (tbdf->cbd_sc & BD_SC_NAK) {
>         if (cpm_debug > 1) printk("IIC try; no ack\n");
>         return 0;
> }
> 
> if (tbdf->cbd_sc & BD_SC_READY) {
>         printk("IIC try; complete but tbuf ready\n");
> }
> 
> return 1;
> 
> ........
Below I am attaching the log buffer showing successful I2C initialization on
Linux 2.4.26:
.....
Starting kswapd
devfs: v1.12c (20020818) Richard Gooch (rgooch at atnf.csiro.au)
devfs: boot_options: 0x1
JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
i2c-core.o: i2c core module version 2.6.1 (20010830)
i2c-dev.o: i2c /dev entries driver module version 2.6.1 (20010830)
i2c-algo-8xx.o: i2c mpc8xx algorithm module
i2c-rpx.o: i2c RPX Lite module
 i2c-algo-8xx.o: scanning bus rpx...
(56)
i2c-proc.o version 2.6.1 (20010830) 
CPM UART driver version 0.04
ttyS0 at 0x0280 is on SMC1 using BRG1
ttyS1 at 0x0380 is on SMC2 using BRG2
pty: 256 Unix98 ptys configured
Entropia driver v0.1
Entropia @06300000 remaped to c3072000
...
>  
As one could see, the same (in principle, except for my potential goofs in
porting  ;-) ) code works 
in 2.4.26 without hanging and finds the 24C02 I2C EEPROM device at address
56 !

> Thanks,
> Best Regards,
> Alex 
> 
>