Real time clock with Oleg's firmware

[simplyred]

@andi

hi Andi,

i use your rtc3 with OLEG 1.9.2.7-7g and it works fine. Thank you very much.

But after the upgrade to OLEG 1.9.2.7-8 it didn't work. I don't remember the error message because i switched back to -7g again.

Could you please check this ?

greets
simplyred

[andi]

But after the upgrade to OLEG 1.9.2.7-8 it didn't work. I don't remember the error message because i switched back to -7g again.

Could you please check this ?

That seems to be difficult without an error message. If you followed this thread from where I jumped in, you might have noticed that I don't run Oleg's firmware on my box, so I can't verify this here. And from Oleg's announcement, I don't see which of his changes might be the cause for the problem.

Sorry for not being of much help here at the moment.

[simplyred]

I switched to OLEG 1.9.2.7-8 again and tried to set the time with putty.
here is the result:

[admin@WL-HDD harddisk]$ /tmp/harddisk/hwclock.sh --hctosys
date: invalid date `-91-91-91-911809.-91'


In the syslog i also found the following errors:

Jan 1 01:28:50 kernel: SCL pin should be low
Jan 1 01:28:50 kernel: SCL pin should be low
Jan 1 01:28:50 kernel: SCL pin should be low
Jan 1 01:28:50 kernel: SCL pin should be low
Jan 1 01:28:50 kernel: SCL pin should be low
Jan 1 01:28:50 kernel: SCL pin should be low
Jan 1 01:28:50 kernel: SCL pin should be low
Jan 1 01:28:50 kernel: SCL pin should be low
Jan 1 01:28:50 kernel: SCL pin should be low
Jan 1 01:28:50 kernel: ***RTC BATTERY FAILURE***

Any idea ? Is there a problem with the new image ?

[andi]

I switched to OLEG 1.9.2.7-8 again and tried to set the time with putty.
here is the result:

[admin@WL-HDD harddisk]$ /tmp/harddisk/hwclock.sh --hctosys
date: invalid date `-91-91-91-911809.-91'

That means that the time/date read from the RTC is invalid.

In the syslog i also found the following errors:

Jan 1 01:28:50 kernel: SCL pin should be low
Jan 1 01:28:50 kernel: SCL pin should be low
Jan 1 01:28:50 kernel: SCL pin should be low
Jan 1 01:28:50 kernel: SCL pin should be low
Jan 1 01:28:50 kernel: SCL pin should be low
Jan 1 01:28:50 kernel: SCL pin should be low
Jan 1 01:28:50 kernel: SCL pin should be low
Jan 1 01:28:50 kernel: SCL pin should be low
Jan 1 01:28:50 kernel: SCL pin should be low
Jan 1 01:28:50 kernel: ***RTC BATTERY FAILURE***

Since it is working with the previous firmware release, this means that the I2C communication to the RTC chip doesn't work.

I've downloaded the source code of Oleg's patches and checked what he has changed. And in fact, he (indirectly and incompatibly) changed the access to the gpio pins (two gpio pins are used to communicate with the RTC). From what I see, the necessary changes to my driver seem to be trivial, but I'm currently unable to compile the driver myself because this also requires an updated toolchain (or at least updated kernel headers).

[Oleg]

Could you please share your source?

Seems like you've expected preconfigured scl/sda gpios, which is in fact should not be touched by watchdog...

[andi]

Could you please share your source?

Ok, here it is. Note that I've already modified the code to the best of my knowledge to comply with your changed function calls.

Seems like you've expected preconfigured scl/sda gpios, which is in fact should not be touched by watchdog...

That might be true. I stopped thinking about whether or not I've implemented it correct when I got the response that the driver was working.

[Oleg]

Thanks. BTW, which RTC chip is used by WL-HDD?

[Oleg]

Here is it. Someone should try it.

[andi]

Thanks. BTW, which RTC chip is used by WL-HDD?

Ricoh RV 5C386A

[simplyred]

Thanks Oleg, it works:

[admin@WL-HDD harddisk]$ /tmp/harddisk/hwclock.sh --hctosys
Sun Nov 11 20:51:49 MEZ 2007


is it possible, to get it in the next Update for WL-HDD ?

[Oleg]

Yes, perhaps. Well, tried on my WL-700gE and it also works (the only change is SDA gpio pin). It use the same ricoh chip.

Well, looks like we need to make general purpose: i.e. allow to specify sda/scl as module parameters.

Btw, does 24h switch destroys current clock setting completely? Or just hour value?

[Oleg]

Also, this driver should have automatic devfs registration...

[andi]

Well, looks like we need to make general purpose: i.e. allow to specify sda/scl as module parameters.

That shouldn't be a problem to implement. I assume you can do this yourself .

Btw, does 24h switch destroys current clock setting completely? Or just hour value?

The switch to 24h mode doesn't really destroy the setting. Depending on the current time, it just leads to invalid time values within the chip. And according to the data sheet: "Any carry from lower digits with the writing of non-existent time may cause the time counters to malfunction." In any case, I don't think it's worth optimizing this, as it is only relevant the very first time you load the module.

Also, this driver should have automatic devfs registration...

The driver uses misc_register(), which already does devfs registration.

BTW.: Did you need to make any adjustments to my code, or was it already correct?

[Oleg]

That shouldn't be a problem to implement. I assume you can do this yourself .

Yes.

The driver uses misc_register(), which already does devfs registration.

Ghm... Right. /dev/misc/rtc is available. I've added hwclock applet to busybox and it works fine.

BTW.: Did you need to make any adjustments to my code, or was it already correct?

It was correct.

Well, do we still need compatibility with original asus code? I mean reading/writing via /dev/rtc?

[andi]

Well, do we still need compatibility with original asus code? I mean reading/writing via /dev/rtc?

In my opinion, this isn't needed at all. The reason why I implemented it compatible to the original asus code was just the missing hwclock applet.