Converting GPIO pins to MMC mode (BeagleBone Black)

[GJ]

I'm using a BeagleBone Black (kernel 4.14.108-ti-r131), and I was able to successfully configure the MMC0 Dat0 and Dat1 pins to GPIO mode.

In am335x-bone-common.dtsi, I just modified the 2 entries related to pinmux_mmc1_pins and changed them to MUX_MODE_7:

AM33XX_PADCONF(AM335X_PIN_MMC0_DAT0, PIN_OUTPUT_PULLUP, MUX_MODE7)
AM33XX_PADCONF(AM335X_PIN_MMC0_DAT1, PIN_OUTPUT_PULLUP, MUX_MODE7)

I then recompiled the .dtb files, installed them, rebooted my BeagleBone, and I was able to toggle those 2 pins as GPIO through sysfs.

Now i want to change those 2 pins back to MMC0 mode.  I wanted to be able to do that on the fly, but I was told that I wouldn't be able to do that and that I'd have to modify the device tree.  Basically the note was that I'd have to go back to the .dtsi file and change those pins back to MUX_MODE0 (which makes the mmc0).  

Is there a way I can do that and modify the device tree without having to reboot the BeagleBone?  Could I just modify the .dtsi file, compile the appropriate .dtb file, and if possible, issue some command that would load the updated device tree without rebooting?

Thanks!

Your privacy is important to us. That is why we have taken appropriate measures to ensure the data you provide to us is kept secure. To learn more about how we process your personal information, how we comply with applicable data protection laws, and care for the security and privacy of your personal data, please review our Privacy Policy. If you have any questions related to data protection and compliance with applicable laws, please contact us at our Security Operations Center at 1-800-674-4357.

[TJF]

Hi!

In a libpruio configuration you can handle this (and all other) pinmuxing task without any reboot or device tree manipulation.

Note: you've to drop the config-pin tool and all its cape-universal device tree blobs (resulting in faster booting time and less kernel-memory consumption).

Regards

[gerald...@motorolasolutions.com]

Actually I've checked this out and this looks very promising!  I did get an error with the:

deb http://beagle.tuks.nl/debian jessie/
deb-src http://beagle.tuks.nl/debian jessie/

The resolution I read in other forums didn't seem to work for me, but the library seemed to get installed so I just kept moving forward.

And I was able to use the library as you suggested.  First I used a pre-existing program that already reads the card in the micro SD slot - so I did that first to make sure that worked.  Then I compiled and ran a program that used the libruio library to modify two of those MMC0 lines (Dat0 and Dat1) to GPIO by basically setting up:

#define DAT1 SD_08 // 62

#define DAT0 SD_07 // 63

and using:

pruIo *io = pruio_new(PRUIO_ACT_FREMUX | PRUIO_DEF_ACTIVE, 4, 0x98, 0); /* create new driver structure */

and then using the functions: 

pruio_gpio_config()

pruio_gpio_setValue()

I was able to toggle those 2 lines as GPIO and validate their manipulation using a logic analyzer.

When done, I went back to the other program to communicate with the micro SD card in the slot and it worked just as if those pins had never been changed!  I was like Wow!  Very impressive!

So when I do a show-pins -v

μSD d3                            60 fast rx  up  0 mmc 0 d3         mmc@48060000 (pinmux_mmc1_pins)

μSD d2                            61 fast rx  up  0 mmc 0 d2         mmc@48060000 (pinmux_mmc1_pins)

μSD d1                            62 fast rx  up  0 mmc 0 d1         mmc@48060000 (pinmux_mmc1_pins)

μSD d0                            63 fast rx  up  0 mmc 0 d0         mmc@48060000 (pinmux_mmc1_pins)

μSD clk                           64 fast rx  up  0 mmc 0 clk        mmc@48060000 (pinmux_mmc1_pins)

μSD cmd                         65 fast rx  up  0 mmc 0 cmd        mmc@48060000 (pinmux_mmc1_pins)

this will always show uSD d0 and uSD d1 as mmc under pinmux_mmc1_pins even when they are switched to GPIO mode briefly under libpruio control?  Just asking out of curiosity?

Thank you very much!

[TJF]

Am Dienstag, 28. April 2020 23:56:34 UTC+2 schrieb geral...@motorolasolutions.com:

I was able to toggle those 2 lines as GPIO and validate their manipulation using a logic analyzer.

When done, I went back to the other program to communicate with the micro SD card in the slot and it worked just as if those pins had never been changed!  I was like Wow!  Very impressive!

Fine! Note: the pinmuxing is only active in the time after the pruio_config() call and before the DTOR call to pruio_destroy(). The DTOR restores the original setting (by default). (A cosmetic note: I prefer calling pruio_pgio_setValue() before pruio_config() -> all start values get set simultaneously.)

 

So when I do a show-pins -v

μSD d3                            60 fast rx  up  0 mmc 0 d3         mmc@48060000 (pinmux_mmc1_pins)

μSD d2                            61 fast rx  up  0 mmc 0 d2         mmc@48060000 (pinmux_mmc1_pins)

μSD d1                            62 fast rx  up  0 mmc 0 d1         mmc@48060000 (pinmux_mmc1_pins)

μSD d0                            63 fast rx  up  0 mmc 0 d0         mmc@48060000 (pinmux_mmc1_pins)

μSD clk                           64 fast rx  up  0 mmc 0 clk        mmc@48060000 (pinmux_mmc1_pins)

μSD cmd                         65 fast rx  up  0 mmc 0 cmd        mmc@48060000 (pinmux_mmc1_pins)

this will always show uSD d0 and uSD d1 as mmc under pinmux_mmc1_pins even when they are switched to GPIO mode briefly under libpruio control?  Just asking out of curiosity?

I don't know the show_pins tool. What happens when you execute it in a second shell while your libpruio prog is running? Perhaps it lists the kernel setting, but ignores the hardware state.