#2266: Set system time before bootscripts run
-------------------------------------+--------------------------------------
Reporter: [EMAIL PROTECTED] | Owner: [email protected]
Type: task | Status: new
Priority: normal | Milestone: 7.0
Component: Book | Version: SVN
Severity: normal | Resolution:
Keywords: |
-------------------------------------+--------------------------------------
Comment (by Bryan Kadzban):
Couple of comments:
Replying to [ticket:2266 [EMAIL PROTECTED]:
> x86_64 does not necessarily support /dev/rtc due to the new device
options (though udev creates a symlink).
Not entirely true.
It's not that x86_64 kernels don't support /dev/rtc. They do, if your
kernel was configured to match the device you're creating. The issue is
that my particular kernel has CONFIG_RTC and CONFIG_GEN_RTC both disabled,
since I turned on CONFIG_RTC_CLASS along with CONFIG_RTC_INTF_DEV ("/dev
interface") and CONFIG_RTC_DRV_CMOS (rtc-cmos module). This is an option
on 32-bit as well, along with lots of other non-x86 CPUs, although they
would use something other than rtc-cmos for the driver (that's sort of the
whole point of the RTC class).
(So it's not a 32-bit vs. 64-bit thing. It's a new option in the kernel
that changes the way it works with RTCs.)
Under this setup, /dev/rtc does exist (as a symlink to rtc0, as you said),
but the major and minor numbers are different. So a static node created
for the old CONFIG_RTC setup won't work with a kernel that only has the
new RTC class drivers, and a node created for the RTC class drivers won't
work with a kernel that only has the old CONFIG_RTC code enabled.
> It seems that util-linux-ng-2.14 does support a '--rtc=$device' option.
This does give us the possibility of using a pre-created device node in
/dev/ so that the clock is set very early for boot logging, but some text
would have to be written about the options and a new DEVICE= line added to
/etc/sysconfig/clock.
I'm not sure that helps, unless we create two devices and have the user
choose between them. (Which means that any time the user recompiles their
kernel, their choice may need to change.) And even two devices won't work
if the RTC stuff is built as a module -- udev loads the module today. (At
least for rtc-cmos it does, based on the PNP BIOS modalias.)
(Other details below.)
From your BTW question in #2189 -- no, this has nothing to do with HPETs.
It's a different subsystem for real-time clock drivers, which was created
to make adding new drivers easier (e.g. for embedded systems, which use
all kinds of crazy real-time clock chips). It also supports multiple
devices, and works on any CPU that will let the kernel talk to the RTC
chip (not just x86_32 and x86_64).
Looks like it was added in [http://lwn.net/Articles/176750/ 2.6.17],
according to LWN. See also [http://lwn.net/Articles/165077/ the original
proposal], along with [http://lwn.net/Articles/165735/ a change] to make
it support multiple devices. (Note that the udev rule there isn't great,
but current versions of udev have rules that work.)
I'll try a newer util-linux and see if the --directisa option works, but
if it does, relying on it will break Ken's PPC systems as well. ;-P
--
Ticket URL: <http://wiki.linuxfromscratch.org/lfs/ticket/2266#comment:1>
LFS Trac <http://wiki.linuxfromscratch.org/lfs/>
Linux From Scratch: Your Distro, Your Rules.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-book
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
