Hi,
I have IMX6SLEVK.
I want to toggle a free GPIO i.e. GPIO1_14 from userspace /sys/class/gpio.
But when I export this GPIO1_14 by the below steps, I do not see the values getting to '1':
echo 14 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio14/direction
echo 1 > /sys/class/gpio/gpio14/value
Please do let me know if I need to do anything else for the same.
I am probing the MX6SL_PAD_EPDC_D7_GPIO_1_14 pad on the board.
I went through the below discussion:
Re: Using GPIO's on IMX6 SLEVK
I wrote a kernel module exporting the GPIO1_14, but I am getting seg_fault for the same probably because I need to get a virtual address for this GPIO1_14.
But I am not sure how to get this address in kernel code.
Thanks,
Sunny
Solved! Go to Solution.
> It would be great if someone can point me out to the values.
I don't have the manual for the chip you have, so I'm looking in the IMX6SDLRM manual, which is similar, but different.
When trying to find stuff in a Reference Manual with over 5000 pages, "Search" is your friend.
So search for "EPDC_DATA07" or "GPIO1_IO14" in the Reference Manual and you'll soon end up looking at relevant tables.
Then you're looking to get to the right section of the IOMUX Controller chapter, and find the register referenced above.
In my manual, for a register like "IOMUXC_SW_PAD_CTL_PAD_EIM_RW", 0x110b0 would mean:
- 0x1****: Hysteresys
- 0x*1***: PUS=00 (100k pulldown), PUE=0, PKE=1 (KEEP enabled, PULL not)
- 0x**0**: ODE=0, not open-drain
- 0x***b0: Medium Speed, 40 ohm, slow slew
It is disappointing that they're using "magic hex numbers" rather than using proper definitions for these bitfields.
This is what those definitions look like in Linux.2.6.35 for the i.MX53:
#define MX53_GPIO_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE | \ PAD_CTL_DSE_HIGH | PAD_CTL_PUS_22K_UP) #define TX53_SDHC_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_DSE_HIGH | \ PAD_CTL_SRE_FAST | PAD_CTL_PUS_100K_DOWN)
/* I2C */ NEW_PAD_CTRL(MX53_PAD_EIM_D28__I2C1_SDA, MX53_GPIO_PAD_CTRL), NEW_PAD_CTRL(MX53_PAD_EIM_D21__I2C1_SCL, MX53_GPIO_PAD_CTRL),
/* CSPI (LCD) */ NEW_PAD_CTRL(MX53_PAD_SD1_CMD__CSPI_MOSI, TX53_SDHC_PAD_CTRL), NEW_PAD_CTRL(MX53_PAD_SD1_CLK__CSPI_SCLK, TX53_SDHC_PAD_CTRL),
It is easy to make this understandable in "C". Maybe the "magic numbers" are one of the disadvantages of the Device Tree. It may be too primitive as a "language" to allow a clear description of the hardware.
Tom
Hi Sunny
MX6SL_PAD_EPDC_D7_GPIO_1_14 pad is described in
sect.30.4.233 Pad Control Register (IOMUXC_SW_PAD_CTL_PAD_EPDC_DATA07)
i.MX6SL Reference Manual (rev.1 5/2013)
http://cache.freescale.com/files/32bit/doc/ref_manual/IMX6SLRM.pdf
Best regards
igor
Hi Igor,
Thanks for sharing the iMX6SL RM. This helped.
> Thanks for sharing the iMX6SL RM. This helped.
You should have been able to find this document yourself ages ago:
Select "Products / i.MX Application Processors":
http://www.freescale.com/webapp/sps/site/homepage.jsp?code=IMX_HOME
Click on i.MX6SL Link and then click on "Documentation" tab:
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX6SL&fpsp=1&tab=Documentation_Tab
Download ALL OF the Data Sheet, Reference Manual, Errata and App Notes. Read them.
Be careful when reading the Reference Manual. It should be better than the i.MX53 one, but there will still be a lot of errors in it, especially in the section detailing the pad multiplexors. For examples of what to look out for:
https://community.freescale.com/message/426929#426929
https://community.freescale.com/message/425415#425415
Tom
Hi Tom,
Thanks for the info.
It was really useful.
If possible, can you please check the below thread:
I am trying to cross compile a tool with the arm-poky 1.7 toolchain.
I am able to cross compile the tool. But when I run the executable, I get "No such file or directory error".
I had tried to cross compile a simple helloworld.c code with the same toolchain and I had got the same "No such file or directory error". Then I found few additional compiler arguments to be given in order to cross compile and then the helloworld.c worked.
I gave the same additional compiler arguments for the tool, but the generated executable is giving error.
Thanks,
Sunny
When GPIO pin is configured as output, it cannot be read, in general. Reading its value will produce the result you see. In order to be able to read output pins they have to be configured in a special way, I remember reading that in the Reference manual. I have not done it myself, so I can only recommend reviewing GPIO section of the Reference Manual for which bits must be set and in which registers.
Alex
When a GPIO pin is configured as an output it is possible to read its value back by setting the SION bit of the pad.
Regards,
Fabio Estevam
Hi,
I am able to configure the GPIO from userspace from /sys/class/gpio.
I did changes in the arch/arm/boot/dts/imx6sl-evk.dts file.
I added the below lines in the hoggrp for iomuxc group:
MX6SL_PAD_EPDC_D7__GPIO1_IO14 0x110b0
MX6SL_PAD_EPDC_D6__GPIO1_IO13 0x110b0
But can anybody please let me know, what the above values mean. Because I tried to use this pins with the values -->0x1b0b0 and 0x80000000, but it was not working for me.
Then I referred to the BSP Porting Guide for iMX6SL and there it is mentioned that the values corresponds to Hysteresis, Pull up/Pull down, etc but I am not able to see exact bit mappings for the above values.
It would be great if someone can point me out to the values.
Thanks,
Sunny
> It would be great if someone can point me out to the values.
I don't have the manual for the chip you have, so I'm looking in the IMX6SDLRM manual, which is similar, but different.
When trying to find stuff in a Reference Manual with over 5000 pages, "Search" is your friend.
So search for "EPDC_DATA07" or "GPIO1_IO14" in the Reference Manual and you'll soon end up looking at relevant tables.
Then you're looking to get to the right section of the IOMUX Controller chapter, and find the register referenced above.
In my manual, for a register like "IOMUXC_SW_PAD_CTL_PAD_EIM_RW", 0x110b0 would mean:
- 0x1****: Hysteresys
- 0x*1***: PUS=00 (100k pulldown), PUE=0, PKE=1 (KEEP enabled, PULL not)
- 0x**0**: ODE=0, not open-drain
- 0x***b0: Medium Speed, 40 ohm, slow slew
It is disappointing that they're using "magic hex numbers" rather than using proper definitions for these bitfields.
This is what those definitions look like in Linux.2.6.35 for the i.MX53:
#define MX53_GPIO_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE | \ PAD_CTL_DSE_HIGH | PAD_CTL_PUS_22K_UP) #define TX53_SDHC_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_DSE_HIGH | \ PAD_CTL_SRE_FAST | PAD_CTL_PUS_100K_DOWN)
/* I2C */ NEW_PAD_CTRL(MX53_PAD_EIM_D28__I2C1_SDA, MX53_GPIO_PAD_CTRL), NEW_PAD_CTRL(MX53_PAD_EIM_D21__I2C1_SCL, MX53_GPIO_PAD_CTRL),
/* CSPI (LCD) */ NEW_PAD_CTRL(MX53_PAD_SD1_CMD__CSPI_MOSI, TX53_SDHC_PAD_CTRL), NEW_PAD_CTRL(MX53_PAD_SD1_CLK__CSPI_SCLK, TX53_SDHC_PAD_CTRL),
It is easy to make this understandable in "C". Maybe the "magic numbers" are one of the disadvantages of the Device Tree. It may be too primitive as a "language" to allow a clear description of the hardware.
Tom
Hi Tom,
Thanks for the pointers. It helped.
I downloaded the iMX6SL RM which Igor has mentioned below, and then I checked my EPDC_D7 pad and looked at the Bit settings for the whole pad name i.e. MX6SL_PAD_EPDC_D7__GPIO1_IO14 and there it is mentioned what each bit or bitfields mean i.e. Hys, PKE, PKU, Speed, DSE, etc.
We need to manually calculate the whole 32-bit pad value by looking at the PAD Control Register of the corresponding Pad and enter it in the DTS file.
Below is snapshot for someone trying to look for the same:
Thanks a lot for the info.
Thanks,
Sunny