Re: gpsd 3.x successfully ported to embedded MIPS (Netgear wndr3700v2 router)

[Dave Taht]

gpsd 2.94 was already in openwrt, however getting gpsd 3.x to work required scons cross-support.

dealing with the scons support problem requires a patch to openwrt at present that may need some further work.

The openwrt specific patch for scons support is at: http://huchra.bufferbloat.net/~cero1/gpsd-patches/

A revised gpsd package, using gpsd from nearly-git-head (which also contains changes to support cross compilation in general), is presently available as part of the ceropackages git repository:

https://github.com/dtaht/ceropackages

(this repo has been where we've been spinning up new packages like pimd, ccnx, etc, which openwrt users can add to their feeds.conf:

git://github.com/dtaht/ceropackages.git

)

After gpsd stablizes (gpsd 3.2?) we can get it into openwrt head, but in the meantime it would be good to know if gpsd 3.x worked well on other variants of openwrt.  I note that you will have to install the right kmod-serial-* to get the right kernel support for your specific device, and enabling the -G option to gpsd allows you to contact the router remotely with tools like cgpsd, etc.

On Sat, Sep 17, 2011 at 6:33 AM, Eric Raymond <esr@...> wrote:

This is a heads-up for those of you looking into gpsd cross-build for
embedded deployments.

I've been cooperating with Dave Taht and the Bufferbloat project (see
http://www.bufferbloat.net/).  One consequence of this is that gpsd has
just been successfully ported into the CeroWrt distribution (a friendly fork
of OpenWrt intended as a test tool for studying network; thanks to Dave Taht
<dave.taht@...> and Stephen Walker <stephendwalker@...> for
excellent work on this.

Those of you trying to cross-build for other embedded deployments
might wanto to look into how CeroWrt does this.

The goal, by the way, is to use GPS time as a reliable local timebase
to support checking for NTP drift due to network latency.
--
               <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Rifles, muskets, long-bows and hand-grenades are inherently democratic
weapons.  A complex weapon makes the strong stronger, while a simple
weapon -- so long as there is no answer to it -- gives claws to the
weak.
       -- George Orwell, "You and the Atom Bomb", 1945

--
Dave Täht
SKYPE: davetaht
US Tel: [phone]
http://the-edge.blogspot.com

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Eric S. Raymond]

Dave Taht <dave.taht@...>:
> After gpsd stablizes (gpsd 3.2?) we can get it into openwrt head, but in the
> meantime it would be good to know if gpsd 3.x worked well on other variants
> of openwrt.

What counts as stable?  Changes since 3.0 have been minor, mostly tweaks
to the build recipe.  The biggest change I'm expecting in 3.2 is a bug
fix to the old (non-kernel) PPS code.

>  I note that you will have to install the right kmod-serial-* to
> get the right kernel support for your specific device,

Bu "your specific device" you mean the router hardware?  When we use that
phrase here we generally mean a make/model of GPS...

>                                                    and enabling the -G
> option to gpsd allows you to contact the router remotely with tools like
> cgpsd, etc.

I've added a force_global configuration option to force -G on for deployments
like CeroWrt where listening only on loopback is not a good idea.
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Dave Taht]

On Sat, Sep 17, 2011 at 7:35 AM, Eric Raymond <esr@...> wrote:

Dave Taht <dave.taht@...>:

> After gpsd stablizes (gpsd 3.2?) we can get it into openwrt head, but in the
> meantime it would be good to know if gpsd 3.x worked well on other variants
> of openwrt.

What counts as stable?  Changes since 3.0 have been minor, mostly tweaks
to the build recipe.  The biggest change I'm expecting in 3.2 is a bug
fix to the old (non-kernel) PPS code.

While there are several packages in openwrt head that pull directly from a git commit
of a given package, I would personally prefer that gpsd 3.x baked a little more
(with people testing on arm, mips, mobile devices, etc) and I am also hoping

However, I note that I am not in any way a gatekeeper to the main openwrt feeds. Their requirements are different.

We (bufferbloat.net) spun up ceropackages specifically to enable those newer to openwrt development and
embedded development to be able to use github as a base, and 'screw up' freely while mastering the cross-development process, while not necessarily being able to do builds on or for their own hardware.

Well, that, plus we wanted to try out some crazy things like a variety of new test tools, multicast routing, using xinetd, etc.

A side goal is to get the developers of a given piece of software's heads around how different embedded development can be, and also get needed patches pushed up into those mainline packages.

It has been fun getting evan hunt (bind9 maintainer at isc.org) and your respective heads around life inside 8MB of flash.

>  I note that you will have to install the right kmod-serial-* to
> get the right kernel support for your specific device,

Bu "your specific device" you mean the router hardware?  When we use that
phrase here we generally mean a make/model of GPS...

No, I meant the make/model of GPS that we tested, which required a

opkg install kmod-usb-serial-ftdi

in order for ttyUSB0 to be recognised by the openwrt/wndr3700v2 kernel. (I'm documenting this for your future builds)

I note many openwrt based devices have real serial ports, too. The wndr actually has one inside it that can be hacked onto.

I note that adding a kmod-usb-serial-* depenendency to the gpsd package is the wrong thing, as openwrt is more
like a 'distro to build hardware' distro, where the designer of the firmware would pick and choose the right kernel
modules for their particular hardware.

saving any and all space on precious flash is in large part what drives packaging for embedded firmware,
which is why I'd like to nuke the gpsd libusb dependency as it's only for one rarely used device.

>                                                    and enabling the -G
> option to gpsd allows you to contact the router remotely with tools like
> cgpsd, etc.

I've added a force_global configuration option to force -G on for deployments
like CeroWrt where listening only on loopback is not a good idea.

Well... then it needs to be invertible somehow. And the gpsd openwrt package could merely have an option in the gpsd.config file to enable it where needed. I can certainly see cases where lo can be used by other apps on the router and no other access is needed.

That said, full ipv6 support would be nice, too.
 

--

               <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

--
Dave Täht
SKYPE: davetaht
US Tel: [phone]
http://the-edge.blogspot.com

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Eric S. Raymond]

Dave Taht <dave.taht@...>:
> > What counts as stable?  Changes since 3.0 have been minor, mostly tweaks
> > to the build recipe.  The biggest change I'm expecting in 3.2 is a bug
> > fix to the old (non-kernel) PPS code.
> >
>
> While there are several packages in openwrt head that pull directly from a
> git commit of a given package, I would personally prefer that gpsd 3.x baked
> a little more

Dude, you *are* the testing on MIPS.  (We do have a couple or ARM devs.)

I hope you're at least a little reassured by the fact that the port required
exactly zero changes to C code.

> >  I note that you will have to install the right kmod-serial-* to
> > get the right kernel support for your specific device,
>
>  Bu "your specific device" you mean the router hardware?  When we use that
> > phrase here we generally mean a make/model of GPS...
> >
> > No, I meant the make/model of GPS that we tested, which required a
>
> opkg install kmod-usb-serial-ftdi
>
> in order for ttyUSB0 to be recognised by the openwrt/wndr3700v2 kernel. (I'm
> documenting this for your future builds)

Ahhhhh.  Light dawns.

No, actually, it's not the GPS you have to worry about.  It's the USB-to-serial
adapter.  The GPS chipsets actually speak RS-232 natively; to turn them into
USB devices requires one of the adaptor chips.  FTDI is about the second
most common of these, the most common being a PL2303.

Sometimes the adaptor is inboard, sometimes it's outboard in a housing
inline of the cable. This is why you'll often see two-piece cables with
the part coming out of the GPS ending in a mini-DIN connector; the mini-DIN
cable end it plugs into may have either a DB9 or USB connector on the
other end.

> I note many openwrt based devices have real serial ports, too. The wndr
> actually has one inside it that can be hacked onto.

That's useful to know.
 
> saving any and all space on precious flash is in large part what drives
> packaging for embedded firmware,
> which is why I'd like to nuke the gpsd libusb dependency as it's only for
> one rarely used device.

Reasonable. Just configure that driver out.

> > I've added a force_global configuration option to force -G on for
> > deployments
> > like CeroWrt where listening only on loopback is not a good idea.
>
> Well... then it needs to be invertible somehow.

I could make that option invert the sence of -G, I suppose.

>                                 And the gpsd openwrt package
> could merely have an option in the gpsd.config file to enable it where
> needed.

There is no runtime gpsd config file, by design.

 I can certainly see cases where lo can be used by other apps on the
> router and no other access is needed.
>
> That said, full ipv6 support would be nice, too.

What does it need for IPv6 that it doesn't have? (-G support may be fixed now.)
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev