I2C real time clock (RTC) again.

A couple of us had been working on this problem and the thread had quite a bit of dialog including some good hints from Hippp. I would like to pick this issue up again and it would be nice to have that information. Did anyone happen to print/save the old thread? If so would you mind re-entering it here? Thanks, Alex

This is a record! I seem to be keeping this thread going all by myself :). Anyway, yesterday I spent some time looking through the old cached records of this issue. All of the comments were available except the last two or so. Looking at the first line or so of each (which is cached), it looks like Hippo had added a patch. I can't tell if the patch worked or exactly what got patched. Both of which would be useful

pieces of information. Please, if anyone has any additional information before I go back to work on this it would help. Obviously, I don't want to spend time on it if Hippo has already provided a solution. Thanks, Alex

Why don't you give us a quote from what you found ?

-Michael

Michael, here is everything I could mine from the old thread. There's not much I can do about the length; it is what it is.

Hi all,

I am having trouble getting uClinux to recognize the DS1338 RTC on my hardware.

The device is functioning and I can read and set the time with the i2c utils and it is keeping time, so I think the hardware I/F is ok.

I have the following options checked in the kernel config:

--- Real Time Clock

[*] Set system time from RTC at startup and resume

[rtc0] RTC used to set the system time

[*] /sys/class/rtc/rtcN (sysfs)

[*] /proc/driver/rtc (procfs for rtc0)

[*] /dev/rtcN (character devices)

<*> Dallas/Maxim DS1307/37/38/39/40, ST M41T00

When the system boots I get the following error message:

.

Linux version 2.6.27-rc4 ...

.

.

/home/chris/nios2-linux/linux-2.6/drivers/rtc/hctosys.c: unable to open rtc device (rtc0)

.

.

/> ls -al /dev/rtc*

crw-r----- 1 0 0 10, 135 Nov 29 16:00 /dev/rtc

/>

Thanks and

Good Huntin&#39;

cb

hi cb,

I&#39;ve been following this thread as I am having trouble with the RTC also. I have managed to reproduce all of your data using a different RTC chip and with the same result I&#39;m sorry to say. At the moment this issue has become a priority so I will be continuing to look at it. Please post anything you find and I will do the same.. Alex

Hi cb and halfdome,

Please check if you added i2c board info in arch/nios2/kernel/config.c, like that of arch/blackfin/mach-bf527/boards/ezkit.c.

i2c_register_board_info() and I2C_BOARD_INFO("ds1307", 0x68)

Cheer,

Hippo

halfdome, Michael,

Sorry for the delay but I haven&#39;t been able to post (or reply or contact the admins) for the last two weeks. Somehow I lost this ability after the crash, but didn&#39;t know it. I have resolved the problem.

Short answer to your question, no.

I have been busy with some other problems (features) for the last few months and did not want to update our kernel until now.

I am updating our kernel to the latest revision, porting old projects and setting up for a new project. Everything has gone well following the wiki and the NEEK can now boot the latest &#39;default&#39; configuration of the &#39;test-nios2&#39; branch successfully.

I got a message from Hippo at the end of April indicating that he had successfully gotten a DS1338 to work on a NEEK and that he had applied some patches to the &#39;unstable&#39; branch. (Thanks Hippo).

I have added a breadboard to the NEEK containing a DS1338 RTC and a 24LC256 eeprom similar to the I2C example on the "Video" wiki page.

I will try to get the kernel to recognize the RTC while I am reconfiguring the kernel for our projects.

I will be out of the office till next week and will continue then. I will post what I find. If you discover anything please pass it on.

Good Huntin&#39;

cb

p.s. Be aware that the power on this header is 3.3V but the I2C levels come from a 2.5V bank of the FPGA. I added a shotky diode inline with the power to drop the supply voltage some.

halfdome, michael, hippo

YEA IT WORKS! - THANKS HIPPO.

I can confirm that the DS1338 RTC clock added to the NEEK platform works.

I downloaded the latest kernel code (less than 2 weeks ago) and followed Hippo&#39;s instructions on the GPIO wiki page.

I made a clean kernel from the PTF that Hippo put on the wiki page, enabled the RTC per the page and it works!

I am porting our old kernel code that uses the open-cores I2C controller to our hardware boards, so in a few weeks I&#39;ll should have some feedback from that configuration.

Thanks again for your hard work Hippo.

Good Huntin&#39;

cb

That is good news. I am still having problems though. I am trying to use a PCF8563 RTC and an opencores I2C insterface instead of the 1307 and the GPIO i2C. This is still proving problematic. I looked at the latest distribution and the 1307 driver has changed significantly. I don&#39;t know if these changes are related to Hippo&#39;s patch or not. I will need to look at the actual changes in detail to see what is going on. Maybe

that will be a hint for the 8563. I am also going to try and wire in a 1307 on our opencores bus. It looks like the config.c was modified by Hippo to support either configuration. If I can get the 1307 to work, I should be able to get the 8563 to work. Thanks for the update... Alex

Yee-Haw! I got it going. I looked at the i2c_board_info settings for one of the ARM chips (they are using a PCF8563 RTC). The setting is I2C_BOARD_INFO("pcf8563", 0x51) so I changed the flag data

from 68 to 51 and, as if by majic, it all works! Thanks Hippo, CB, Michael and all that worked on this. BTW I am using the OpenCores I2C interface instead of the I2C on GPIO. So that is tested now

too. Alex

Congrats !

<div class='quotetop'>QUOTE (halfdome @ Aug 11 2009, 01:06 AM) <{post_snapback}> (index.php?act=findpost&pid=23470)</div>

--- Quote Start ---

I am using the OpenCores I2C interface instead of the I2C on GPIO. So that is tested now

too.[/b]

--- Quote End ---

Great News !

-Michael