rtc driver module not being auto-loaded by kernel?

Howdy folks,

Bitbaking 2.6.29-r49 and have run into one or two issues when
deploying it to beagleboard C3.

1) Using default defconfig -- CONFIG_RTC_DRV_DS1307 is set, even
though the board does not have one of these RTCs. Attempting to probe
that device fails during boot (not a huge issue).
2) CONFIG_RTC_DRV_TWL4030 is set to module, which is fine -- however,
the module never gets loaded on boot and a read of the hwclock fails
since no rtc0 exists.

I read this post:
http://groups.google.com/group/beagleboard/browse_frm/thread/6677914e9da4589a/7ff06a0128bd4766?lnk=gst&q=modules#7ff06a0128bd4766

And it seems John did not get a solution to his problem. Has anyone
worked around this?

I can get the module to load by adding it to /etc/modules -- which
then gets loaded by the modutils.sh init script. However, despite
being listed in /etc/rcS.d as being called BEFORE the set-time-from-
rtc script, for some reason my dmesg shows that the module did not get
loaded until almost right at the end of kernel initialisation.
(Hence, it loads the rtc driver AFTER the attempt to set the clock
from hardware)

Ideas? I can't see where the call to hwclock is coming from -- I
presumed it was calling the /etc/init.d/hwclock.sh script but that
does not seem to occur until after modutils is called??

Folks,

Thinking right now that someone has commited updated defconfig
assuming that people will always want to use DS1307. Since module for
TWL4030 cannot be loaded until rootfs is mounted, the call to hwclock
by the kernel (yes, config to set hw-clock from rtc0 is set) fails due
to probe of DS1307 failing.

Next question is this: why would someone commit their system-specific
rtc changes so that the rest of us who don't have their specific
expansion boards get stuck with it...? Be nice if people just offer
an optional patch in future...