[LinuxPPS] Patches for kernel 2.6.26-rc8
Rodolfo Giometti
giometti at enneenne.com
Fri Jul 4 14:34:10 CEST 2008
On Thu, Jul 03, 2008 at 05:34:41PM -0700, Hal V. Engel wrote:
> OK I got it working. But I am not real happy with what has to be done to
> get everything started. Since there are some things going on that don't
> seem to be correct based on what little documentation is available and
> some of what I have done is an ugly hack.
Sorry for poor documentation but currently I have *no* time to update
it. I suppose this list is currently the best LinuxPPS documentation
available. :)
I need help on this topic.
> One change that I didn't expect that was causing me problems initially is
> that pps_core can not be built into the kernel anymore and is now a module
> only. For prior versions this could be built into the kernel. Perhaps this
> can be fixed?
That's strange... if you take a look at drivers/pps/Kconfig you can
see that "config PPS" is defined as tristate.
> Even after setting up my boot process so that it now loads pps_core I
> found getting ppsldisc to actually work is problematic. I found that
> running setserial ... before ppsldisc worked? I stumbled onto this by
> accident. So I am not sure that I understand the current implementation.
> But at this point I have not found any other combination of commands that
> works. Wasn't ppsldisc supposed to get rid of setserial and friends or is
> there something else going on here that I missed?
With full ldisc support the setserial command is going to be no more
needed. Please, take a look at these posts:
http://ml.enneenne.com/pipermail/linuxpps/2008-June/002020.html
http://ml.enneenne.com/pipermail/linuxpps/2008-June/002021.html
> I also tried using ttyctrl before ppsldisc and that did not work. To try
> to get things working without having to run stuff by hand I found that the
> following udev rules resulted in there being a working pps signal at
> startup:
>
> KERNEL=="ttyS1", RUN+="/bin/setserial -v /dev/%k low_latency hardpps",
> SYMLINK+="oncore.serial.0"
> KERNEL=="ttyS1", RUN+="/bin/ppsldisc /dev/%k"
>
> KERNEL=="pps0", OWNER="root", GROUP="uucp", MODE="0660",
> SYMLINK+="oncore.pps.0", OPTIONS+="last_rule"
>
> Since the above rules resulted in running ppstest having the expected
> output. But it also resulted in ntpd not seeing the GPS:
>
> 54650 85410.279 127.127.30.0 ONCORE DRIVER -- CONFIGURING
> 54650 85410.279 127.127.30.0 state = ONCORE_NO_IDEA
> 54650 85410.279 127.127.30.0 Input mode = 1
> 54650 85410.279 127.127.30.0 Initializing timeing to Assert..
> 54650 85410.279 127.127.30.0 SHMEM (size = 3584) is CONFIGURED and
> available as /var/log/ntp/oncore.0
> 54650 85410.279 127.127.30.0 state = ONCORE_CHECK_ID
> 54650 85411.272 127.127.30.0 Oncore: Resend @@Cj
> 54650 85426.272 127.127.30.0 Oncore: Resend @@Cj
> 54650 85442.272 127.127.30.0 Oncore: Resend @@Cj
> 54650 85460.272 127.127.30.0 Oncore: No response from @@Cj, shutting down
> driver
>
> So this looks like this somehow makes the serial interface not work but I
> can run WinOncore and it sees the GPS so that does not make sense. Based
> on this it appears that for this to work the following had to happen.
>
> 1. setserial with hardpps either by hand or in a udev rule
> 2. run ppsldisc
> 3. while #2 is still running start ntpd.
>
> So I ended up removing the ppsldisc line from the udev rule and modifying
> /etc/init.d/ntpd so that the line that starts the ntp deamon looks like
> this:
>
> /bin/ppsldisc /dev/ttyS1 & start-stop-daemon --start --exec /usr/sbin/ntpd
> \
>
> and this works and will start up everything at boot time. Of course this
> is hard coded for my hardware and my distro will want to clobber this if I
> happen to reinstall ntp. So at best this is an ugly hack.
>
> I used kernel 2.6.26-rc8 and the 2.6.26-rc8 patch set and the ppsldisc
> patch to build my kernel and the new user land tools. But I happen to have
> a patched setserial on my machine because I am using it with my older
> kernel built with older linuxpps patch sets.
>
> OK perhaps that gives someone some clues about what is going on and
> possibily how it can be fixed.
Ok, the right-thing(TM) is exactly what you did. Even bluetooth
subsystem has something similar (see hciattach command). :)
Ciao,
Rodolfo
--
GNU/Linux Solutions e-mail: giometti at enneenne.com
Linux Device Driver giometti at linux.it
Embedded Systems phone: +39 349 2432127
UNIX programming skype: rodolfo.giometti
More information about the LinuxPPS
mailing list