Date: Wed, 25 Jan 2017 20:21:46 -0700 From: Ian Lepore <ian@freebsd.org> To: Tony Hain <tony@tndh.net>, freebsd-arm@freebsd.org Subject: Re: BBB uarts & pps dts definitions Message-ID: <1485400906.30533.54.camel@freebsd.org> In-Reply-To: <03a801d2776e$cae997e0$60bcc7a0$@tndh.net> References: <03a801d2776e$cae997e0$60bcc7a0$@tndh.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1485400906.30533.54.camel>