This happens because the Linux omap_i2c driver omap_i2c_idle() routine thinks we have a register we don't have:
if (dev->rev >= OMAP_I2C_REV_ON_4430)
omap_i2c_write_reg(dev, OMAP_I2C_IRQENABLE_CLR, 1);
else
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
...because we're claiming a REVISION of 0x40 which Linux thinks means 4430. This in turn happens because qemu's beagle model initialises the omap3 code to be "omap3630", which is wrong according to the Beagle XM docs which say it has an omap3530. The qemu omap code doesn't model an omap3530.
I don't know if qemu is right about the I2C revision being 0x40 on the 3630 because for some reason TI think that the revision number is "TI internal data" despite it being freely available in the register if you have the hardware...
This happens because the Linux omap_i2c driver omap_i2c_idle() routine thinks we have a register we don't have: REV_ON_ 4430) i2c_write_ reg(dev, OMAP_I2C_ IRQENABLE_ CLR, 1); i2c_write_ reg(dev, OMAP_I2C_IE_REG, 0);
if (dev->rev >= OMAP_I2C_
omap_
else
omap_
...because we're claiming a REVISION of 0x40 which Linux thinks means 4430. This in turn happens because qemu's beagle model initialises the omap3 code to be "omap3630", which is wrong according to the Beagle XM docs which say it has an omap3530. The qemu omap code doesn't model an omap3530.
I don't know if qemu is right about the I2C revision being 0x40 on the 3630 because for some reason TI think that the revision number is "TI internal data" despite it being freely available in the register if you have the hardware...