My comments above about configuring the pinmux in u-boot SPL vs. the kernel device tree are somewhat misleading per the comments at the top of the following commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am57xx-beagle-x15.dts?h=v4.15-rc2&id=d20f997b4d1f3fc41703c95e4f4bb4ebca90da42 Except for the MMC, pinmuxing for the 5728 should only be done in isolation mode (e.g. by a program such as the SPL running from internal SRAM) and not in the kernel device tree If you attempt to re-configure the pinmux for everything else (not the MMC), IO glitches can occur. I'm not sure what the implications of these glitches are. Also, our TI rep advised to only do pinmuxing for the 5728 while in isolation mode, except for the MMC, which has to be done in the kernel device tree. On Friday, December 8, 2017 at 6:06:04 PM UTC-6, Jeff Andich wrote: > > Ok, here's some of what we tried today on the 572xEVM/BB-X15. Once again, > we were able to get GPIO working on our custom hardware board with the > 5728, but not yet on the 5728EVM/BB-X15. > > > 1) We re-configured a pin (VOUT1_D6 on header P18) on the expansion header > which is normally used for LCD video on the 572xEVM/BB-X15. > > 2) We first confirmed that this pin, VOUT1_D6, was producing signals on > the p18 expansion header, pin #45 (which I'm guessing is video for the LCD > touchscreen) with a running BB-X15 LXQT image. This gave a measure of > confidence that this expansion port pin is connected to something on the > 5728, so it should be possible to put out GPIO on this expansion header > pin, since the attached solder ball on the 5728 also has GPIO8_6 when you > change MUX mode from 0 to 14.. > > 3) We modified the pad configuration of VOUT_D6 in the SPL from MuxMode, > M0 to MuxMode 14 M14 by hacking the change directly into the operative pad > configuration array entry (pad conf array delta array) for mux_data.h. > {VOUT1_D6, (M14 | PIN_OUTPUT)}, /* vout1_d6.gpio8_6*/ > > 4) We left the Pullup/Pulldown and slewcontrol bits the same as in > VOUT_D6. just changed M0 to M14! I wasn't sure if this was correct, > because other GPIO outputs like the 4 USR LEDs are configured as > PIN_INPUT_PULLDOWN. Not sure if the PU/PD state is related to the > peripheral the PAD is connected to on the 5728 or what the peripheral > connects to downstream. > > 5) We didn't change the IO delay array, as I didn't see any entries in the > existing table for vout signals. > > 6) We then switched to a console image (uname_r 4.4.89-ti-r130 and > /etc/dogtag= BeagleBoard.org Debian Image 2017-10-02) and then DD'ed the > re-built SPL and u-boot.img to the uSD card. > > 7) We then checked the pin configuration by looking at > /sys/kerne/debug/pinctl/4a003400.pinmux: > root@BeagleBoard-X15:/sys/kernel/debug/pinctrl/4a003400.pinmux# > grep 35f4 * > pinmux-pins:pin 125 (4a0035f4.0): (MUX UNCLAIMED) (GPIO UNCLAIMED) > pins:pin 125 (4a0035f4.0) 0001000e pinctrl-single > > Note: The change from 0 to E in the least significant nibble confirms > change in pad configuration from M0 to M14. > Note: My assumption is that the kernel reads in an has knowledge of the > pad configuration on the BB-X15. Assume that you don't have to configure > the pad again in the device tree. The only peripheral which gets its > pinmux setup in the device tree on the 5728 is the MMC. I believe this is > all described in TI's SPRAC44 app note. Please correct and clarify this > statement as you see fit.. > > 8) We attempted to set the gpio pin, gpio8_6 via sysfs (Note, there are no > GPIO enable directives in the device tree yet!) > > Assume gpio8_6 is gpio 230 = [(8-1) * 32 + 6] = 230. > > /sys/class/gpio/echo 230 > export > > cat gpio230/direction = in > > echo out > gpio230/direction > > echo 1 >gpio230/value ==> scope indicates pin #45 on connector, > P18 is 0V. > > echo 0 >gpio230/value ==> scope indicates pin #45 on connector, > P18 is 0V. > > > So this didn't affect the voltage on pin #45 on the P18 connector. > > > 9) Then after not seeing any change in the voltage on pin #45, we > attempted to turn on GPIO8 in the device tree: > &gpio8 { > ti,no-reset-on-init; > ti,no-idle-on-init; > gpio = <&gpio8 6 GPIO_ACTIVE_HIGH>; > }; > Recompiled all the device trees in our 4.4.y RCN kernel tree using > a modified version of build_kernel.sh to just re-build the dtb's. > > copied to BB-X15, to /boot/dts/uname-r and then re-booted. > > 10) Repeat Step #8 > Got the same result. No variation in voltage on pin #45 when > echoing 1 vs 0 into the corresponding value file. > > Next-steps: > Investigate what the correct PU/PD and slew control states should be > for outputting signals on the expansion header. > Possibly update to a more recent image of u-boot and the kernel. > Possibly attempt to reproduce this on the latest TI SDK, as there was > a discussion thread on E2E about this, and TI will only support their SDK. > > Any and all suggestions/criticisms would be greatly appreciated!! > > > On Friday, December 8, 2017 at 10:21:54 AM UTC-6, Jeff Andich wrote: > >> Still investigating this. Still no luck with getting GPIO or UART to >> come out on the corresponding pins on the expansion header with our PCBA >> breakout board. >> >> I'll try to write up what I've found thus far by end of today (or by >> Sunday). >> >> >> In the meantime, just taking a poll: >> >> Who here has successfully gotten her/his BeagleBoard-X15 to output known >> signals on the expansion header pin? >> >> >> Any information would be greatly appreciated. Even a "Yes this worked >> fine for me," would be helpful! >> >> >> >> On Tuesday, December 5, 2017 at 6:28:00 PM UTC-6, Jeff Andich wrote: >>> >>> >>> >>> On Tuesday, December 5, 2017 at 6:25:17 PM UTC-6, Jeff Andich wrote: >>>> >>>> Note: Per the 572xEVM_REVA3 schematic and the pad configuration of our >>>> boot loader, gpio5_8 comes out on pin 55 of the P17 expansion header on >>>> the >>>> BB-X15. >>>> >>>> Incidentally, I tried varying the brightness in >>>> /sys/class/leds/gpio_jeff_test to see if the level of gpio5_8 would change >>>> on the scope, but no luck Varying the brightness works great with the >>>> blinking leds (gpio7_8, 7_9, 7_14, 7_15) on the top of the bb-x15. You >>>> can >>>> turn them on an off by echoing different values in for "brightness." >>>> >>>> I was wondering if the expansion headers could be mis-labled on my >>>> board. So I tried moving the breakout board around to all 4 of the >>>> expansion headers, but keeping the scope probe on the same pin, pin55. But >>>> no luck. >>>> >>>> I also tried the ADAFRUIT GPIO module in Python, yesterday, but it >>>> looks like there isn't yet a Python module which exposes all of the gpio >>>> chips for the BB-X15. Please correct me if I'm wrong. >>>> >>>> Also, I have the following gpio fragment in my dts. >>>> >>>> &gpio5 { >>>> ti,no-reset-on-init; >>>> ti,no-idle-on-init; >>>> }; >>>> >>>> Maybe a reasonable next-step is to find some known signals coming out >>>> on the expansion headers, and then reverse engineer how they're getting >>>> generated.. Maybe video signals or touchscreen input signals for the >>>> external touchscreen would be a good place to start.... >>>> >>>> Thanks! >>>> >>> >>> >>> >>>> >>>> On Monday, December 4, 2017 at 5:49:59 PM UTC-6, Jeff Andich wrote: >>>>> >>>>> Hi, >>>>> >>>>> Has anyone had any difficulty outputting GPIO,UART, I2C, signals from >>>>> the BB-X15's expansion header? I haven't yet been able to successfully >>>>> get >>>>> GPIO and/or UART data to come out on the associated pins of the 4 >>>>> expansion >>>>> ports of the am572xEVM/BB-X15. We made a PCBA breakout board which >>>>> breaks >>>>> out 30/60 signals on each header. >>>>> >>>>> If you were able to get this working, what were some of the key >>>>> considerations? >>>>> >>>>> I stumbled across this post on TI E2E, where others were encountering >>>>> issues with this as well. >>>>> >>>>> >>>>> https://e2e.ti.com/support/embedded/linux/f/354/p/595855/2206686#pi317016=1 >>>>> >>>>> >>>>> Here I THINK the TI employee indicated that one of the critical steps >>>>> is specifying the correct offset in the device tree for the pad >>>>> configuration register of interest. But when I look at the device tree, >>>>> am57xx-evm-reva3, and the associated included dtsi and dts files, I >>>>> didn't >>>>> see this kind of thing for GPIO pins: >>>>> >>>>> gpio5_pins: pinmux_gpio5_pins { >>>>> pinctrl-single,pins = < >>>>> DRA7XX_CORE_IOPAD(0xNNNN, (PIN_INPUT | >>>>> MUX_MODEX)) >>>>> DRA7XX_CORE_IOPAD(0xNNNN, (PIN_OUTPUT| >>>>> MUX_MODE3)) >>>>> >; >>>>> }; >>>>> >>>>> >>>>> in the case of attempting to set GPIO5_8, and using sysfs commands, >>>>> echo 1,0 > /sys/class/gpio/gpio136/value (after setting the direction to >>>>> OUT), the value and direction files always jive with what gets echo'd >>>>> into >>>>> the file - however the state of the line doesn't change. >>>>> >>>>> I DO have a modified board.c file, but I'm pretty confident the pinmux >>>>> in mux_data.h for GPIO5_8 is the same as the development board. Granted >>>>> this maybe an older revision, as I grabbed one of the earlier revisions >>>>> of >>>>> u-boot 2017.01. >>>>> >>>>> I even tried hacking, am57xx-beagle-x15-common.dtsi by adding another >>>>> phantom LED fragment/cluster. >>>>> >>>>> . >>>>> . >>>>> . >>>>> leds { >>>>> . >>>>> . >>>>> . >>>>> led@4 { >>>>> label = "gpio_jeff_test"; >>>>> gpios = <&gpio5 8 GPIO_ACTIVE_HIGH>; >>>>> linux,default-trigger = "ide-disk"; >>>>> default-state = "off"; >>>>> }; >>>>> }; >>>>> >>>>> The good news is, the gpio line is 3.3V with this statement. >>>>> The bad news: When I change this to GPIO_ACTIVE_LOW, gpio5_8 is still >>>>> stuck at 3.3V.. >>>>> >>>>> >>>>> The only luck I've had to date is on our custom hardware board, >>>>> coupling GPIO5_8 with UART5 for the rts line, and then toggle the GPIO >>>>> line >>>>> via sysfs commands and by toggling the state of the rtscts flag in >>>>> Pyserial >>>>> in Python (This after swapping out the 8250 serial driver for the OMAP >>>>> driver): >>>>> >>>>> &uart5 { >>>>> pinctrl-names = "default"; >>>>> pinctrl-0 = <&uart5_pins>; >>>>> status = "okay"; >>>>> rts-gpio = <&gpio5 8 GPIO_ACTIVE_HIGH>; >>>>> rs485-rts-active-high; >>>>> rs485-rts-delay = <0 0>; >>>>> linux,rs485-enabled-at-boot-time; >>>>> }; >>>>> >>>>> >>>>> Can you maybe provide any clues to steer us in the right direction? >>>>> >>>>> >>>>> Thanks!!! >>>>> >>>>> Jeff >>>>> >>>>> -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/f7ff476b-e951-4753-aa1e-a65add72313c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
