Dear Kernel Developers,
I have a requirement of getting the CMOS details at the user level. I have identified the interfaces as /dev/nvram & /dev/rtc.
But, the complete CMOS details are available to the user Applications as the driver does not provide the suitable interface to get the complete CMOS details.
I found an application that reads directly form the port 70, 71 and gets the complete details about the CMOS. It does not use any Device Interface and at the same disables all the interruptson the HOST system.
I would like to hear from you whether this kind of Applications can be used or NOT? Please see the attached source code I am planning to use to access the CMOS contents.
Please give me ur valuable suggestions.
Regards,
Mukund Jampala
<<dmpCmos.c>>
On Mon, 19 Dec 2005, Mukund JB. wrote:
>
> Dear Kernel Developers,
>
> I have a requirement of getting the CMOS details at the user level.
> I have identified the interfaces as /dev/nvram & /dev/rtc.
> But, the complete CMOS details are available to the user Applications
> as the driver does not provide the suitable interface to get the
> complete CMOS details.
>
> I found an application that reads directly form the port 70, 71
> and gets the complete details about the CMOS. It does not use any Device
> Interface and at the same disables all the interruptson the HOST system.
>
> I would like to hear from you whether this kind of Applications can be
> used or NOT? Please see the attached source code I am planning to use to
> access the CMOS contents.
>
> Please give me ur valuable suggestions.
>
> Regards,
> Mukund Jampala
>
First, only root can disable interrupts in user-mode and read/write
to ports. One must prepare for this with iopl(3).
Second, the RTC is a shared resource. It must be protected with
a lock.
If you want to make your own rtc driver, then feel free. However,
you can't just poke at the ports from user-mode and get away with
it for any period of time. You will find that the CMOS checksum
gets screwed up and/or the time gets changed to a previous epoch.
This is because the kernel may change the index register in between
the time that you set it and when you wrote to the data register.
You need to use the provided spin-lock, rtc_lock. This needs
to be accessed from within the kernel, in your driver.
>
>
> <<dmpCmos.c>>
>
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.56 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On Llu, 2005-12-19 at 17:45 +0530, Mukund JB. wrote:
> Dear Kernel Developers,
>
> I have a requirement of getting the CMOS details at the user level. I have identified the interfaces as /dev/nvram & /dev/rtc.
> But, the complete CMOS details are available to the user Applications as the driver does not provide the suitable interface to get the complete CMOS details.
Then you'll need to enhance the nvram or rtc driver to support the extra
bits you need. What doesn't it provide access to that you require >
Dear Alan,
I want the contents of A, B, C, D registers of CMOS mapped registers.
But instead the driver gives the details about the bit masks of few of register A, B only.
The others are NOT available.
I would also require to retrieve the day of the week info in RTC information.
I tried the /dev/rtc but I don't get it there.
at the same time, I am able to get the entire CMOS information using the application attached which does not use any driver interface and instead use the ports directly.
But, the application tried to disable the interrupts on the processor.
Suggest me the pros & cons of using this application.
Regards,
Mukund Jampala
-----Original Message-----
From: Alan Cox [mailto:[email protected]]
Sent: Monday, December 19, 2005 11:13 PM
To: Mukund JB.
Cc: [email protected]
Subject: Re: Kernel interrupts disable at user level - RIGHT/ WRONG -
Help
On Llu, 2005-12-19 at 17:45 +0530, Mukund JB. wrote:
> Dear Kernel Developers,
>
> I have a requirement of getting the CMOS details at the user level. I have identified the interfaces as /dev/nvram & /dev/rtc.
> But, the complete CMOS details are available to the user Applications as the driver does not provide the suitable interface to get the complete CMOS details.
Then you'll need to enhance the nvram or rtc driver to support the extra
bits you need. What doesn't it provide access to that you require >
On Tue, Dec 20, 2005 at 12:27:13PM +0530, Mukund JB. wrote:
>
> Dear Alan,
>
> I want the contents of A, B, C, D registers of CMOS mapped registers.
> But instead the driver gives the details about the bit masks of few of register A, B only.
> The others are NOT available.
>
> I would also require to retrieve the day of the week info in RTC information.
> I tried the /dev/rtc but I don't get it there.
Use /dev/nvram instead.
Dave
> -----Original Message-----
> From: Dave Jones [mailto:[email protected]]
> Sent: Tuesday, December 20, 2005 12:39 PM
> To: Mukund JB.
> Cc: Alan Cox; [email protected]
> Subject: Re: Kernel interrupts disable at user level - RIGHT/ WRONG -
> Help
>
>
> On Tue, Dec 20, 2005 at 12:27:13PM +0530, Mukund JB. wrote:
> >
> > Dear Alan,
> >
> > I want the contents of A, B, C, D registers of CMOS mapped
> registers.
> > But instead the driver gives the details about the bit
> masks of few of register A, B only.
> > The others are NOT available.
> >
> > I would also require to retrieve the day of the week info
> in RTC information.
> > I tried the /dev/rtc but I don't get it there.
>
> Use /dev/nvram instead.
>
> Dave
/dev/nvram does not give the cpomplete CMOS details. A part of RTC & date, tine and other info will be missing.
Regards,
Mukund Jampala
On Maw, 2005-12-20 at 14:32 +0530, Mukund JB. wrote:
> > > I tried the /dev/rtc but I don't get it there.
> >
> > Use /dev/nvram instead.
> >
> > Dave
>
> /dev/nvram does not give the cpomplete CMOS details. A part of RTC & date, tine and other info will be missing.
What Dave should have said is use /dev/nvram as well.
>From /dev/rtc you get registers 0-9 except as you said 6
>From /dev/nvram you get A+
The lack of day of week is odd but fixable. The struct tm already has a
field for tm_wday (day of week) so we can fill it in. Whether it is
valid is another question.
What do people thing about this ?
Signed-off-by: Alan Cox <[email protected]>
--- drivers/char/rtc.c~ 2005-12-20 23:40:34.912559808 +0000
+++ drivers/char/rtc.c 2005-12-20 23:51:16.428034632 +0000
@@ -46,10 +46,10 @@
* 1.11a Daniele Bellucci: Audit create_proc_read_entry in rtc_init
* 1.12 Venkatesh Pallipadi: Hooks for emulating rtc on HPET base-timer
* CONFIG_HPET_EMULATE_RTC
- *
+ * 1.12ac Alan Cox: Allow read access to the day of week register
*/
-#define RTC_VERSION "1.12"
+#define RTC_VERSION "1.12ac"
#define RTC_IO_EXTENT 0x8
@@ -1250,9 +1250,9 @@
/*
* Only the values that we read from the RTC are set. We leave
- * tm_wday, tm_yday and tm_isdst untouched. Even though the
- * RTC has RTC_DAY_OF_WEEK, we ignore it, as it is only updated
- * by the RTC when initially set to a non-zero value.
+ * tm_wday, tm_yday and tm_isdst untouched. Note that while the
+ * RTC has RTC_DAY_OF_WEEK, we should usually ignore it, as it is
+ * only updated by the RTC when initially set to a non-zero value.
*/
spin_lock_irq(&rtc_lock);
rtc_tm->tm_sec = CMOS_READ(RTC_SECONDS);
@@ -1261,6 +1261,9 @@
rtc_tm->tm_mday = CMOS_READ(RTC_DAY_OF_MONTH);
rtc_tm->tm_mon = CMOS_READ(RTC_MONTH);
rtc_tm->tm_year = CMOS_READ(RTC_YEAR);
+ /* Only set from 2.6.16 onwards */
+ rtc_tm->tm_wday = CMOS_READ(RTC_DAY_OF_WEEK);
+
#ifdef CONFIG_MACH_DECSTATION
real_year = CMOS_READ(RTC_DEC_YEAR);
#endif
@@ -1275,6 +1278,7 @@
BCD_TO_BIN(rtc_tm->tm_mday);
BCD_TO_BIN(rtc_tm->tm_mon);
BCD_TO_BIN(rtc_tm->tm_year);
+ BCD_TO_BIN(rtc_tm->tm_wday);
}
#ifdef CONFIG_MACH_DECSTATION
>What do people thing about this ?
Well why not. I doubt any program relied on the - anyway broken - tm_wday
field so far.
Jan Engelhardt
--