Overo (I am using Air) has two i2c devices. First all of, add i2c driver in kernel.
Note:
Every time when I try to modify kernel, I need to re-source the kernel profile by using:
overo-oe$ source build/profile
overo-oe$ bitbake -c menuconfig virtual/kernel
----------------------------------------------------------------------------------------------------
PS: the virtual/kernel means the default build kernel in overo directory. or, I still can use:
overo-oe$ bitbake -c menuconfig overo-omap3
take a look at:
/build/czhang/overo-oe/org.openembedded.dev/conf/machine/overo.conf
-----------------------------------------------------------------------------------------------------
in 'device drivers' --- 'real time clock'
add 'y' in front of 'Dallas/Maxim DS1307/37/38/39/40, ST M41T00, EPSON RX-8025'
ps: y: build into kernel
m: add a module
save it.
$ cd /build/czhang/overo-oe/org.openembedded.dev/recipes/linux/linux-omap3-2.6.34/overo
$ cp deconfig deconfig.old
$ cp /build/czhang/overo-oe/tmp/work/overo-angstrom-linux-gnueabi/linux-omap3-2.6.34-r90/git/.config /build/czhang/overo-oe/org.openembedded.dev/recipes/linux/linux-omap3-2.6.34/overo/deconfig
take a look at the "deconfig"
#
# I2C Hardware Bus support
#
#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_DESIGNWARE is not set
# CONFIG_I2C_GPIO is not set
# CONFIG_I2C_OCORES is not set
CONFIG_I2C_OMAP=y
# I2C Hardware Bus support
#
#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_DESIGNWARE is not set
# CONFIG_I2C_GPIO is not set
# CONFIG_I2C_OCORES is not set
CONFIG_I2C_OMAP=y
#
# I2C RTC drivers
#
CONFIG_RTC_DRV_DS1307=y
# CONFIG_RTC_DRV_DS1374 is not set
# CONFIG_RTC_DRV_DS1672 is not set
# I2C RTC drivers
#
CONFIG_RTC_DRV_DS1307=y
# CONFIG_RTC_DRV_DS1374 is not set
# CONFIG_RTC_DRV_DS1672 is not set
rebuild kernel:
overo-oe$ bitbake -c clean virtual/kernel
overo-oe$ bitbake virtual/kernel
New kernel image is in /build/czhang/overo-oe/tmp/deploy/glibc/images/overo
copy new kernel (uImage) to SD card FAT partition.
start Gumstix, I can see i2c-1 and i2c-3 in /dev.
I2C-1 is the power chip. If you want to alter power settings use this.
I2C-3 is the external connection port. If you want to communicate to
external circuits use this.
I am using DS1338 rtc chip.
power supply votage Vcc is 1.8V
logic VH = Vcc x 0.7
logic VL = 0.3V
Therefore, I don't need a logic converter.
connect rtc to overo, try command:
$ i2cdetect -y -r 3
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50:50-- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
the address of ds1338 is 0x68, not 0x50.
Googled around, found the 0x50 is address of eeprom on the overo. That means the rtc chip has not been detected in the i2c bus.
Then, I thought I need to change to i2c bus speed to be 100khz. The overo i2c bus' default speed is 400khz. I am sure the ds1338 can run at hight speed mode. But I could not talk to rtc at the mement. So, give it a try.
------------------------------------------------------
Change i2c bus speed:
(followed steps from http://www.jumpnowtek.com/)
i2c bus speed can be changed by passing a kernel boot argument to the driver in the u-boot startup script.
To modify u-boot, start your system, stop the u-boot process by hitting a key, and make the following change to either nandargs or mmcargs depending how you boot. The nandargs/mmcargs variables are just gumstix conventions for initializing bootargs which is the value u-boot cares about.
Using mmc booting as the example, the old value should look SOMETHING like this:
Overo # printenv
...
mmcargs=setenv bootargs console=${console} ...
...
So a add new variable so you can easily change the speed again and then modify mmcargs and save your changes.
Overo # setenv i2cspeed 3,100
Overo # setenv mmcargs setenv bootargs console=\${console} i2c_bus=\${i2cspeed} ...
Overo # saveenv
After reboot gumstix, i got errors:
Root-NFS: No NFS server available, giving up.
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "(null)" or unknown-block(2,0)
Please append a correct "root=" boot option; here are the available partitions:
1f00 512 mtdblock0 (driver?)
1f01 1792 mtdblock1 (driver?)
1f02 256 mtdblock2 (driver?)
1f03 4096 mtdblock3 (driver?)
1f04 255488 mtdblock4 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)
Where did I do wrong?!!
Read the instruction again...
Pay attention to these RED words. I was using exact command (copy and paste), even includes the "..." .
How stupid I am : (
I can not remember my mmcargs argument. So, I went to internet, search a printevn to find a similar print out. here is what i found quit similar:
mmcargs=setenv bootargs console=${console} vram=${vram} omapfb.mode=dvi:${dvimode} omapfb.debug=y omapdss.def_disp=${defaultdisplay} root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
nandargs=setenv bootargs console=${console} vram=${vram} omapfb.mode=dvi:${dvimode} omapfb.debug=y omapdss.def_disp=${defaultdisplay} root=/dev/mtdblock4 rw rootfstype=jffs2
Re-do the 'setenv', reboot, all good. It can boot from mmc again. Thank goodness.
---------------------------------------------------------------------------------------
The speed has been changed. But the rtc still can not been found.
Do I need two pull up resisters for SDA and SCL? No, the overo already has them on board.
Do I need two pull up resisters for SDA and SCL? No, the overo already has them on board.
I had a close look the chip... It is ds133833!! this is running at 3.3v! Wrong chip!
*waiting for new chip*
Got a correct rtc ds1338c-18
0x68, yeah, found it.
Here are two command to read and write time from/to rtc:
root@ i2cget -y 3 0x68 0x01 // read from address 0x01 from rtc
root@ i2cset -y 3 0x68 0x02 0x11 // set rtc address 0x02 to be 0x11
after used i2cset command to set time and date correctly, then used command 'hwclock -w' to write clock to system from rtc.
Check system clock:
the data and time are different from what i just set in rtc.
then do:
Strange!!
the 'hwclock' is supposed to read hardware clock (rtc). Does that mean the overo has on board rtc?
Google around, yes, it has a 'twl4030' on board rtc.
when i do:
the rtc0 is on board twl4030.
on the internet, most people recommended to get the external rtc clock time from their program code. that's hard~~
Todo:
use on board rtc and get battery charged.
Got a correct rtc ds1338c-18
$ i2cdetect -y -r 3
root@overo:~# i2cdetect -y -r 3
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50:50-- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- --68-- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
0x68, yeah, found it.
Here are two command to read and write time from/to rtc:
root@ i2cget -y 3 0x68 0x01 // read from address 0x01 from rtc
root@ i2cset -y 3 0x68 0x02 0x11 // set rtc address 0x02 to be 0x11
after used i2cset command to set time and date correctly, then used command 'hwclock -w' to write clock to system from rtc.
Check system clock:
root@ date
the data and time are different from what i just set in rtc.
then do:
root@ hwclock
this clock time is as same as the system clcok, but different from rtc.Strange!!
the 'hwclock' is supposed to read hardware clock (rtc). Does that mean the overo has on board rtc?
Google around, yes, it has a 'twl4030' on board rtc.
when i do:
root@ ls /dev
i can see rtc and rtc0the rtc0 is on board twl4030.
on the internet, most people recommended to get the external rtc clock time from their program code. that's hard~~
Todo:
use on board rtc and get battery charged.
No comments:
Post a Comment