Printable View
@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
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.Quote:
Originally Posted by simplyred
Sorry for not being of much help here at the moment.
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 ?
That means that the time/date read from the RTC is invalid.Quote:
Originally Posted by simplyred
Since it is working with the previous firmware release, this means that the I2C communication to the RTC chip doesn't work.Quote:
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***
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).
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...
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.Quote:
Originally Posted by Oleg
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.Quote:
Seems like you've expected preconfigured scl/sda gpios, which is in fact should not be touched by watchdog...
Thanks. BTW, which RTC chip is used by WL-HDD?
Here is it. Someone should try it.
Ricoh RV 5C386AQuote:
Originally Posted by Oleg
Thanks Oleg, it works: :D
[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 ?
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?
Also, this driver should have automatic devfs registration...
That shouldn't be a problem to implement. I assume you can do this yourself ;).Quote:
Originally Posted by Oleg
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.Quote:
Btw, does 24h switch destroys current clock setting completely? Or just hour value?
The driver uses misc_register(), which already does devfs registration.Quote:
Also, this driver should have automatic devfs registration...
BTW.: Did you need to make any adjustments to my code, or was it already correct?
Yes. :)Quote:
Originally Posted by andi
Ghm... Right. /dev/misc/rtc is available. I've added hwclock applet to busybox and it works fine.Quote:
The driver uses misc_register(), which already does devfs registration.
It was correct.Quote:
BTW.: Did you need to make any adjustments to my code, or was it already correct?
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.Quote:
Originally Posted by Oleg