And the investigation continues in the following thread on E2E:
https://e2e.ti.com/support/arm/sitara_arm/f/791/p/649900/2388226#pi316653=1 Thanks and FYI, On Monday, December 11, 2017 at 2:22:52 PM UTC-6, Jeff Andich wrote: > > > 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/55d84c2a-1fe8-4007-b86c-0bd190c6eb2b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
