BBB uarts & pps dts definitions

[Ian Lepore]

On Wed, 2017-01-25 at 16:54 -0800, Tony Hain wrote:
> Hi,
> 
> First, thanks to all that have worked on getting FreeBSD on ARM. I tried it
> on a Rpi B awhile back, and gave up due to lack of time to work it through.
> I now have 11 running on a BBB with poudriere/Qemu cross-compiled ports, and
> also built NTPsec for it. The problem is figuring out the DTS mess.
> 
> I am not getting the PPS signal on P8-7 as per Ian's note about /dev/dmtpps:
> https://lists.freebsd.org/pipermail/freebsd-arm/2015-August/012077.html 
> I seriously suspect that is due to the default DTS, as gpioctl -lv only
> shows pins 0-31, and the scope shows P8-7 is pulling the signal to ground
> when I plug into the pin, suggesting it is in output mode. 
> While the thread at:
> https://forums.freebsd.org/threads/56920/
> suggests there is a way to expand to the full set of gpio pins, I couldn't
> figure out how from the references there.  I would guess there needs to be
> another pinmux@ besides the one @800, but there is nothing I can find that
> suggests what that should be.
> 
> I tried to use Gonzo's Overlay method referenced at:
> https://kernelnomicon.org/?p=498
> but the dtc version in /usr/bin doesn't support the -@ option to deal with
> unreferenced variables as suggested by Adafruit and Rpi sites for Linux
> builds. I don't see dtc in the ports tree, so short of chasing down the
> current linux version and trying to port that, I am stuck with embedding
> everything in the primary dts.
> 
> I figured it would be simpler to start debugging with the serial port first
> since there was an example for the working console port. My original intent
> was to use uart5 since it was also on P8, but given gpioctl is only listing
> the first 32 I switched to uart1  (P9-26). Simply changing the "disabled" to
> "okay" for the uart was sufficient to make it show up as /dev/ttyu1, but not
> enough to make it work. Taking hints from various dts files for uart1, I
> have:
>       uart1_pins:  pinmux_uart1_pins {
>                 pinctrl-single,pins = <0x180 0x020 0x184 0x0>;
>                  linux,phandle = <0x1>;
>                  phandle = <0x1>;
>         };
> ...
>                 serial at 48022000 {
>                         compatible = "ti,am3352-uart", "ti,omap3-uart";
>                         ti,hwmods = "uart2";
>                         clock-frequency = <0x2dc6c00>;
>                         reg = <0x48022000 0x2000>;
>                         interrupts = <0x49>;
> //                    status = "disabled";
>                         status = "okay";
>                         dmas = <0x29 0x1c 0x0 0x29 0x1d 0x0>;
>                         dma-names = "tx", "rx";
> 
>                         pinctrl-names = "default";
>                         pinctrl-0 = <&uart1_pins>;
>                 };
> I am getting a duplication error for the phandle lines. I realize the
> existing devices have unique hex values for those, but the only references
> search is turning up and downloadable dtb files I can find have the phandle
> for that uart as 0x1. Is there a reason that all the uarts are not listed
> with the correct values & commented out in the default DTS? In addition,
> uart4 & 5 don't have the dma lines that the others have ...  and those lines
> don't appear in the reference linux dts files so I can't tell what they are
> for. Comments in the dts hinting at where to look for references for other
> values would make it easier to clone a working device for another one. 
> 
> Is there a plan to have a wiki for the dts/dtb/dtbo mechanism as implemented
> for FreeBSD? 
> 
> Finally, adding beaglebone-green to my dts will be simple enough when I get
> ready to put FreeBSD on that, but that should be part of the stock dts since
> the hdmi itself is already marked as disabled in this dts, and removal of
> that hardware is the primary difference between black & green as I
> understand it. 
> 
> Tony

When I first read this I figured some change over the past few months
must have broken the driver.  But I just built a fresh world and kernel
for beaglebone and fired up my BB and hooked a PPS signal to P8-7 and
it all still works fine.

You don't need to do anything with the dts, the dmtpps driver will
reconfigure the pin to be a PPS input, overriding whatever the FDT data
might have set up.  All you need to do is set a couple lines in
/boot/loader.conf:

  hw.am335x_dmtpps.input="P8-7"
  am335x_dmtpps_load=YES

You can even do it all interactively without any config, even just
booting from a downloaded weekly snapshot, then do this:

  kenv hw.am335x_dmtpps.input="p8-7"
  kldload am335x_dmtpps

You should see something like this (some of this is extra bootverbose
output, so you may not see all these lines)...

  root at bb:~ # kldload am335x_dmtpps
  ti_pinmux0: setting internal 2a for timer4
  am335x_dmtpps: configured pin p8-7 as input for timer4
  am335x_dmtpps0: <AM335x PPS-Capture DMTimer4> mem 0x48044000-
       0x480443ff irq 30 on simplebus0
  Timecounter "DMTimer4" frequency 24000000 Hz quality 1000
  am335x_dmtpps0: Using DMTimer4 for PPS device /dev/dmtpps

If you have full source code on the BB, do:

  cd /usr/src/tools/test/ppsapi
  make ppsapitest
  ./ppsapitest /dev/dmtpps

You should get something like:

  1485400775 .009578536 204 0 .000000000 0
  1485400776 .009621995 205 0 .000000000 0
  1485400777 .009665453 206 0 .000000000 0
  1485400778 .009708869 207 0 .000000000 0

-- Ian