iMX6ULEVK - Repurpose SD1/mmc0 pins in DTS

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

iMX6ULEVK - Repurpose SD1/mmc0 pins in DTS

Jump to solution
1,449 Views
nickbedbury
Contributor III

I'm using the iMX6ULEVK.  I'd like to repurpose an SD1 pin for GPIO, specifically gpio1[19] (aka SD1_DAT3) to an accelerometer interrupt.  This should work since SD1 isn't being used currently (we use the micro SD card, SD2).

Starting with the base "imx6ul-14x14-evk.dts" and "imx6ul.dtsi", I deleted all references to MMC0, SD1, and SDHC1.  However, now the processor gets stuck during kernel init, right after the following printout:


"sm: restored 256-bit black key:
platform caam_sm: [0000] 97 9a 81 3a f7 d8 5a e9
platform caam_sm: [0008] ae 4d aa c9 a0 83 09 b2
platform caam_sm: [0016] 78 6f 1b 83 fe 23 5e 8a
platform caam_sm: [0024] b5 d7 08 fc 2c 0f 74 f7
snvs-secvio 20cc000.caam-snvs: can't get snvs clock
snvs-secvio 20cc000.caam-snvs: violation handlers armed - non-secure state
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver"

[stuck]

Can someone guide what I need to add/remove from the DTS files to get this working?  Modified files attached.

Thanks

Labels (2)
0 Kudos
1 Solution
1,153 Views
nickbedbury
Contributor III

This page has some info on the constants:

iMX6 Pad Mux and Pad Control · FrankBau/meta-marsboard-bsp Wiki · GitHub 

Led me to realize specific values are in the Linux kernel documentation:

Documentation/devicetree/bindings/pinctrl/fsl,imx6ul-pinctrl.txt

Changing 0x40017059 to 0x40000000 gives proper behavior.  Among other things, that disabled the pullup resistor on the pin.  With the pullup enabled, I think the driver was getting continuously interrupted (since the pin stayed HIGH) which caused Linux to look like it wasn't booting if the module was installed as part of the kernel and loaded at boot time.

View solution in original post

0 Kudos
4 Replies
1,153 Views
igorpadykov
NXP Employee
NXP Employee

Hi Nick

seems sd1 is used in uboot, one can try to remove it too

uboot/board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c

uboot-imx.git - Freescale i.MX u-boot Tree 

for gpio usage on i.MX6UL EVK one can look on

Simple GPIO Example - quandry 

https://www.kosagi.com/w/index.php?title=Definitive_GPIO_guide 

linux/arch/arm/boot/dts/imx6ul-14x14-evk.dts

linux-imx.git - i.MX Linux Kernel 

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
1,153 Views
nickbedbury
Contributor III

Thanks Igor.  From reading the referenced post, I need to add a pinmux entry to my DTS.  Hence I added this:

        pinctrl_hog_1: hoggrp-1 {
                fsl,pins = <
                        MX6UL_PAD_SNVS_TAMPER0__GPIO5_IO00      0x17059
+                      MX6UL_PAD_UART1_RTS_B__GPIO1_IO19       0x40017059 /* SD1 CD */
                >;
        };

Then I was able to use the sysfs export method to control gpio1[19] as an output from user space.  Now I'd like to make it an input with no pullup.

In the other post, it is unclear where the magic numbers 0x40000000 and 0x00017059 come from.  I think these are relevant to getting the pin configured for input using DTS.  For instance, how does 0x40000000 set the SION bit?  From the Application Processor Reference Manual, SION is bit index 4.  Once I understand these pinmux magic numbers, I think I can make some progress.

0 Kudos
1,154 Views
nickbedbury
Contributor III

This page has some info on the constants:

iMX6 Pad Mux and Pad Control · FrankBau/meta-marsboard-bsp Wiki · GitHub 

Led me to realize specific values are in the Linux kernel documentation:

Documentation/devicetree/bindings/pinctrl/fsl,imx6ul-pinctrl.txt

Changing 0x40017059 to 0x40000000 gives proper behavior.  Among other things, that disabled the pullup resistor on the pin.  With the pullup enabled, I think the driver was getting continuously interrupted (since the pin stayed HIGH) which caused Linux to look like it wasn't booting if the module was installed as part of the kernel and loaded at boot time.

0 Kudos
1,153 Views
nickbedbury
Contributor III

I'm not sure I have the correct interrupt pin referenced in the i2c device of the DTS file. 

SD1_DATA3 was the signal I initially wanted to repurpose.  But there might be a better suited one, ideally on the Arduino breakouts of the baseboard.

0 Kudos