BBB uarts & pps dts definitions

[Tony Hain]

Ian Lepore wrote:

>>>>>>>> snip

> > >
> > > Even when it gets built though, the scope shows that the signal is
> > > being pulled to ground as soon as the wire is connected to P8-7, so
> > > I don't
> > expect it
> > >
> > > to work. Is there a way to check the state of the gpio? I would
> > > expect something like # gpioctl -N gpio_66 Can't find pin named
> > > "gpio_66"
> > >
> > > # gpioctl -l
> > > pin 00: 0       gpio_0<>
> > > pin 01: 0       gpio_1<>
> > > ...
> > > pin 30: 1       gpio_30<IN,PU>
> > > pin 31: 1       gpio_31<IN,PU>
> > > #
> > >
> > > How do the 3 additional pinmux controllers get enabled?
> > >
> > >
> > > >
> > > >   ./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
> > >
> 
> Everything I'm doing is with 12-current, but things shouldn't be very
different
> in 11-stable.
> 
> Pin P8-7 is pin 2 on controller 2, so
> 
>   gpioctl -f /dev/gpcio2 -l
> 
> when it's configured correctly it should look like:
> 
>   pin 02: 0       gpio_2<>

# gpioctl -lv -f /dev/gpioc2
pin 00: 1       gpio_0<IN,PU>,
caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
pin 01: 0       gpio_1<IN,PD>,
caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
pin 02: 0       gpio_2<>,
caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN>
...

So it looks like gpioctl defaults to the first controller if none are
listed, since  gpioctl -lv only shows the first 32. Nothing in gpioctl -h
indicates that would be the case, though the framework wiki does mention a
restriction at 32 in the hint files discussion. Nothing in -h, the man page,
or the wiki indicates what -t -c or -n do, so I am reluctant to try them. I
would guess toggle, capabilities, and name, but the help and documentation
should really be clear about that, and how to set direction.

> 
> If you do a verbose boot (in loader, at the prompt do boot -v) do you see
> these two lines right before the am335x_dmtimer0: line?
> 
>   ti_pinmux0: setting internal 2a for timer4
>   am335x_dmtpps: configured pin P8-7 as input for timer4

Booting from disk0s2a:
/boot/kernel/kernel data=0x6d6564+0x145a9c syms=[0x4+0x7eb30+0x4+0x922fa]
/boot/kernel/am335x_dmtpps.ko text=0x1c60 data=0x224+0x8
syms=[0x4+0x820+0x4+0x742]

loader> boot -v

# dmesg | grep er4
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

So all that looks as you indicated it should, though I am troubled that pin
2 is not restricted to IN on the gpioctl listing. It does say configured as
input in dmesg, so it should be doing the right thing. 

The only thing that comes to mind at this point is some electrical
restriction about the BBB input, where a 5/3 resistive divider (2.2k/3.3k)
is inadequate, but the fact that the uart is working would tend to rule that
out. Electrically it is acting as though the pin is set to Output at 0.
...... As I typed that it occurred to me I should really check that it is 0,
and found that there actually is a correct pulse at 60mv. This would imply
that the input impedance of the pin is 26 ohms. The system reference manual
doesn't discuss input impedance that I can find, and search isn't turning up
anything either. Why would the timer pin be different than the uart pin on
the same soc? What are you using to drive your pps?

This is so close, there must be something really trivial that I am
overlooking...

Tony