RTC problem

Hi,

I'm also having some troubles getting the RTC clock up and running.
I'm using PicoCOMA5 Rev1.22 in combination with the fsvybrid-V1.2 release.

With the CONFIG_PICOCOMA5_VYBRID_RTC=Y in the linux kernel menuconfig, I get following messages during the bootlog:
snvs_rtc snvs_rtc.0: rtc core: registered snvs_rtc as rtc0
snvs_rtc snvs_rtc.0: setting system clock to 1970-01-01 01:35:14 UTC (5714)
But when setting date / hwclock, it fails remembering the time.

With the CONFIG_PICOCOMA5_VYBRID_RTC=N in the linux kernel menuconfig, and support for I2C RTC Driver Philips PCF8563 on, I don't get much in the bootlog:
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)

Any advice? Should I use newer fsvybrid version, should I set some other RTC or I2C settings?

Best regards,
Johan Hellemans

You should definitely use a newer version. RTC support was enhanced in fsvybrid-V2.1.

Some background: The Vybrid CPU has an internal RTC. But in an early chip revision, this RTC had a bug and consumed too much power so that a regular button cell battery was empty within a week or so. Therefore we redesigned the PicoCOM to allow for an external RTC chip (PCA8565, handled by the PCF8563 driver). In a newer chip revision, the internal RTC was fixed, and the external RTC is not required anymore. So depending on the chip revision that is used on the PicoCOMA5 board in question, it either has or has not the external RTC chip. The software automatically decides which RTC to use by default. But of course only if you have at least fsvybrid-V2.1.

There is also another very important reason to switch to this newer version. NAND flash support has also improved considerably starting with fsvybrid-V2.0. We do not recommend using the older version in the field. The original Freescale NAND code used before V2.0 is not stable enough and you may experience read errors after a while.

Your F&S Support Team

Hi,
I am already using V2.1. Communication with RTC is not working - it seems to be problem of I2C itself. I added some debug messages and there is log:

Quote

[ 15.684330] <i2c_transfer> msg[0] Write, addr=0x51, len=1
[ 15.684381] <i2c_transfer> msg[1] Read, addr=0x51, len=13
[ 15.684495] <i2c_imx_xfer> START messages 2, irq 106
[ 15.684583] <i2c_imx_start> irq 106, i2c_imx: clk=0x804D3128, base=0xE7000
[ 15.684812] <i2c_imx_start> irq 106, I2C regirsters: IFDR 0x32 I2CR 0x00 I2SR 0x81 i2DR 0xA2
[ 15.684886] <i2c_imx_bus_busy> irq 106
[ 15.684929] <i2c_imx_xfer> i2c_imx_start result 0
[ 15.684977] <i2c_imx_xfer> before call of i2c_imx_read/write I2CR 0x78 I2SR 0xA1
[ 15.685146] <i2c_imx_xfer> i2c_imx_read/write finished: result -5. I2CR 0x78 I2SR 0xA1
[ 15.685201] <i2c_imx_bus_busy> DONE
[ 15.685247] <i2c_imx_stop> DONE
[ 15.685286] <i2c_imx_xfer> DONE: <i2c_imx_xfer> exit with: error: -5
[ 15.685384] <pcf8563_get_datetime> rtc i2c_trf result -5
[ 15.685437] rtc-pcf8563 3-0051: pcf8563_get_datetime: read error

Display More

i2c_imx_write returns -EIO

As explained in the message above, the external RTC is not necessary anymore and is also not equipped on newer PicoCOMA5 anymore. But as the driver is still active in the software, there are two RTC devices visible under /dev. Unfortunately we have very little influence on the numbering, the RTC devices are simply numbered in the sequence of intialization which in turn depends on such simple things as the names of the driver files or the sequence they are mentioned in the Makefiles. Therefore we can not guarantee that the internal RTC will always be under the same number. The best procedure is to write the time to all available RTC devices and ignore any errors.

Your F&S Support Team