topic Re: Simple GPIO Example - quandry in i.MX Processors

Simple GPIO Example - quandry

johncoleman — Thu, 03 Dec 2015 21:31:10 GMT

I am trying to build a simple GPIO Toggle Example on the IMX6UL UltraLite Board.

I have had no success yet.

I have created a simple HelloWorld project.

But, I can not expand it to include GPIO Access.

I can Not figure out how to include files such as gpio.h

But all of these fail: <gpio.h> <Linux/gpio.h> "Linux/gpio.h" etc..

#include <stdio.h>

#include <gpio.h>

typedef unsigned long U32;

typedef unsigned short U16;

typedef unsigned char U8;

#define MX6SL_PAD_EPDC_SDCLK__GPIO1_IO23 0x110 0x400 0x000 0x5 0x0

// IOMUXC_SW_MUX_CTL_PAD_GPIO_1_23 = 20E_0000h base + 0x010

#define GPIO_1_23_MUX_CTL ( 0x2000000 + 0x0110 )

// IOMUXC_SW_PAD_CTL_PAD_GPIO_1_23 = 20E_0000h base + 0x000

#define GPIO_1_23_PAD_CTL ( 0x2000000 + 0x0400 )

// IOMUXC_SW_PAD_INPUT_GPIO_1_23 = 20E_0000h base + 0x0000

#define GPIO_1_23_INPUT ( 0x2000000 + 0x0000 )

// IOMUXC_SW_MUX_DATA_GPIO_1_23 = 0x05

#define GPIO_1_23_MUX_DATA ( 0x05 )

// IOMUXC_SW_CTL_DATA_GPIO_1_23 = 1 << 0x00

#define GPIO_1_23_CTL_DATA ( 0x01 << 0x00 )

#define MX6SL_PAD_EPDC_SDLE__GPIO1_IO24 0x114 0x404 0x000 0x5 0x0

#define MX6SL_PAD_EPDC_SDOE__GPIO1_IO25 0x118 0x408 0x000 0x5 0x0

#define MX6SL_PAD_EPDC_SDSHR__GPIO1_IO26 0x11c 0x40c 0x000 0x5 0x0

int _t_;

#define msleep(n) for(_t_=1; _t_<10000; _t_++){_t_=_t_;}

#define true 1

//#define IMX_GPIO_NR(port, index) ((((port)-1)*32)+((index)&31))

#define IMX_GPIO_NR(b,p) ( ((b - 1) * 32) + p )

int main(int argc, char **argv)

{

printf("Hello World!\n");

gpio_request(IMX_GPIO_NR(3, 11), "external_gpio_0");

gpio_export(IMX_GPIO_NR(3, 11), true);

gpio_request(IMX_GPIO_NR(3, 27), "external_gpio_1");

gpio_export(IMX_GPIO_NR(3, 27), true);

　gpio_direction_output( IMX_GPIO_NR(1,0) , 1 );

msleep(300);

gpio_direction_output( IMX_GPIO_NR(2,18) , 1 );

msleep(300);

gpio_direction_output( IMX_GPIO_NR(2,19) , 1 );

msleep(300);

gpio_direction_output( IMX_GPIO_NR(1,20) , 0 );

gpio_direction_output( UART2_TX_DATA , 0 );

gpio_direction_output( IMX_GPIO_NR(1,21) , 0 );

gpio_direction_output( UART2_RX_DATA , 0 );

gpio_set_value(IMX_GPIO_NR(1, 0) , 1);

gpio_set_value(IMX_GPIO_NR(2, 18) , 1);

gpio_set_value(IMX_GPIO_NR(2, 19) , 1);

gpio_direction_output( IMX_GPIO_NR(1,23) , 1 );

gpio_set_value(IMX_GPIO_NR(1, 23) , 1);

msleep(1000);

gpio_set_value(IMX_GPIO_NR(1, 23) , 0);

msleep(1000);

gpio_set_value(IMX_GPIO_NR(1, 23) , 1);

msleep(1000);

gpio_export(IMX_GPIO_NR(1, 23), true);

gpio_direction_output( IMX_GPIO_NR(1,23) , 1 );

gpio_set_value(IMX_GPIO_NR(1, 23) , 1);

return 0;

}

I have also tried direct register access, but just got segment faults:

#include <stdio.h>

int main(int argc, char **argv)

{

printf("Hello World!\n");

//printf("\nset MUX\n");

// *((long*)0x0209C000??) = (5); // -set MUX

printf("\nset DIR\n");

*((long*)0x0209C004) = (1 << 23); // -set GPIO_1_23.Dir = 1

printf("\nset DATA 23\n");

*((long*)0x0209C000) = (1 << 23); // -set GPIO_1_23.Dat = 1

return 0;

}

Also this segmentation fault :

#include <stdio.h>

#define AIPS1_ARB_BASE_ADDR 0x02000000

#define AIPS1_ARB_END_ADDR 0x020FFFFF

#define AIPS2_ARB_BASE_ADDR 0x02100000

#define AIPS2_ARB_END_ADDR 0x021FFFFF

#define AIPS_TZ1_BASE_ADDR AIPS1_ARB_BASE_ADDR

#define AIPS_TZ2_BASE_ADDR AIPS2_ARB_BASE_ADDR

#define AIPS1_ON_BASE_ADDR (AIPS_TZ1_BASE_ADDR+0x7C000)

#define AIPS1_OFF_BASE_ADDR (AIPS_TZ1_BASE_ADDR+0x80000)

#define GPIO1_BASE_ADDR (AIPS1_OFF_BASE_ADDR+0x1C000)

#define IOMUXC_BASE_ADDR (AIPS1_OFF_BASE_ADDR+0x60000)

#define CCM_BASE_ADDR (AIPS1_OFF_BASE_ADDR+0x44000)

#define reg_32_CSU_SA (*(volatile U32*)(0x021C0218))

#define NSA_CP15 1

#define R32 (volatile unsigned long *)

#define R16 (volatile unsigned short *)

#define R8 (volatile unsigned char *)

typedef unsigned long U32;

typedef unsigned short U16;

typedef unsigned char U8;

int _t_;

#define msleep(n) for(_t_=1; _t_<10000; _t_++){_t_=_t_;}

#define true 1

int main(int argc, char **argv)

{

printf("Hello World!\n");

//Write to DIR register [DIR]

*R32(GPIO1_BASE_ADDR+4) = 0x00000004; // 1 : GPIO 1_2 - output

*R32 (GPIO1_BASE_ADDR) = 0x00000004; // 1 --> GPIO 1_2

*R32 ( GPIO1_BASE_ADDR) = 0 ; // 0 --> GPIO 1_2

return 0;

}

I also tried adding these lines below in the conf/bblayers.conf file, but still with No Results :

FILESPATH_append = "~/yocto_3.14.38-6UL/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/linux-libc-headers/3.14-r0/linux-3.14/include/linux:"
FILESPATH_append = "~/yocto_3.14.38-6UL/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/linux-libc-headers/3.14-r0/linux-3.14/include:"

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
FILESEXTRAPATHS_append = "~/yocto_3.14.38-6UL/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/linux-libc-headers/3.14-r0/linux-3.14/include/linux:"
FILESEXTRAPATHS_append = "~/yocto_3.14.38-6UL/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/linux-libc-headers/3.14-r0/linux-3.14/include:"

SRC_URI += "~/yocto_3.14.38-6UL/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/linux-libc-headers/3.14-r0/linux-3.14/include/linux/gpio.h"

Re: Simple GPIO Example - quandry

BiyongSUN — Mon, 07 Dec 2015 05:16:46 GMT

From your code, we can know you have no any experience of the linux programming.

And the code you listed is for the linux kernel. Not user space.

From the user space, the GPIO should access from sys, which also have API in userspace.

Details please check the linux document file.

3.14.28

Documentation/gpio/gpio-legacy.txt

suggest you can start at the beginning of the linux program and build up a concept of linux.

Sysfs Interface for Userspace (OPTIONAL) ======================================== Platforms which use the "gpiolib" implementors framework may choose to configure a sysfs user interface to GPIOs. This is different from the debugfs interface, since it provides control over GPIO direction and value instead of just showing a gpio state summary. Plus, it could be present on production systems without debugging support.

Given appropriate hardware documentation for the system, userspace could know for example that GPIO #23 controls the write protect line used to protect boot loader segments in flash memory. System upgrade procedures may need to temporarily remove that protection, first importing a GPIO, then changing its output state, then updating the code before re-enabling the write protection. In normal use, GPIO #23 would never be touched, and the kernel would have no need to know about it.

Again depending on appropriate hardware documentation, on some systems userspace GPIO can be used to determine system configuration data that standard kernels won't know about. And for some tasks, simple userspace GPIO drivers could be all that the system really needs.

Note that standard kernel drivers exist for common "LEDs and Buttons" GPIO tasks: "leds-gpio" and "gpio_keys", respectively. Use those instead of talking directly to the GPIOs; they integrate with kernel frameworks better than your userspace code could.

Paths in Sysfs

-------------- There are three kinds of entry in /sys/class/gpio:

- Control interfaces used to get userspace control over GPIOs;

- GPIOs themselves; and

- GPIO controllers ("gpio_chip" instances).

That's in addition to standard files including the "device" symlink.

The control interfaces are write-only:

/sys/class/gpio/

"export" ... Userspace may ask the kernel to export control of a GPIO to userspace by writing its number to this file.

Example: "echo 19 > export" will create a "gpio19" node

for GPIO #19, if that's not requested by kernel code.

"unexport" ... Reverses the effect of exporting to userspace.

Example: "echo 19 > unexport" will remove a "gpio19"

node exported using the "export" file.

GPIO signals have paths like /sys/class/gpio/gpio42/ (for GPIO #42) and have the following read/write attributes:

/sys/class/gpio/gpioN/

"direction" ... reads as either "in" or "out". This value may normally be written. Writing as "out" defaults to

initializing the value as low. To ensure glitch free

operation, values "low" and "high" may be written to

configure the GPIO as an output with that initial value.

Note that this attribute *will not exist* if the kernel

doesn't support changing the direction of a GPIO, or

it was exported by kernel code that didn't explicitly

allow userspace to reconfigure this GPIO's direction.

"value" ... reads as either 0 (low) or 1 (high). If the GPIO is configured as an output, this value may be written;

any nonzero value is treated as high.

If the pin can be configured as interrupt-generating interrupt

and if it has been configured to generate interrupts (see the description of "edge"), you can poll(2) on that file and

poll(2) will return whenever the interrupt was triggered. If

you use poll(2), set the events POLLPRI and POLLERR. If you

use select(2), set the file descriptor in exceptfds. After

poll(2) returns, either lseek(2) to the beginning of the sysfs

file and read the new value or close the file and re-open it

to read the value.

"edge" ... reads as either "none", "rising", "falling", or "both". Write these strings to select the signal edge(s)

that will make poll(2) on the "value" file return.

This file exists only if the pin can be configured as an

interrupt generating input pin.

"active_low" ... reads as either 0 (false) or 1 (true). Write any nonzero value to invert the value attribute both

for reading and writing. Existing and subsequent

poll(2) support configuration via the edge attribute

for "rising" and "falling" edges will follow this

setting.

GPIO controllers have paths like /sys/class/gpio/gpiochip42/ (for the controller implementing GPIOs starting at #42) and have the following read-only attributes:

/sys/class/gpio/gpiochipN/

"base" ... same as N, the first GPIO managed by this chip

"label" ... provided for diagnostics (not always unique)

"ngpio" ... how many GPIOs this manges (N to N + ngpio - 1)

Board documentation should in most cases cover what GPIOs are used for what purposes. However, those numbers are not always stable; GPIOs on a daughtercard might be different depending on the base board being used, or other cards in the stack. In such cases, you may need to use the gpiochip nodes (possibly in conjunction with schematics) to determine the correct GPIO number to use for a given signal.

Exporting from Kernel code

-------------------------- Kernel code can explicitly manage exports of GPIOs which have already been requested using gpio_request():

/* export the GPIO to userspace */

int gpio_export(unsigned gpio, bool direction_may_change);

/* reverse gpio_export() */

void gpio_unexport();

/* create a sysfs link to an exported GPIO node */

int gpio_export_link(struct device *dev, const char *name, unsigned gpio)

/* change the polarity of a GPIO node in sysfs */

int gpio_sysfs_set_active_low(unsigned gpio, int value);

After a kernel driver requests a GPIO, it may only be made available in the sysfs interface by gpio_export(). The driver can control whether the signal direction may change. This helps drivers prevent userspace code from accidentally clobbering important system state.

This explicit exporting can help with debugging (by making some kinds of experiments easier), or can provide an always-there interface that's suitable for documenting as part of a board support package.

After the GPIO has been exported, gpio_export_link() allows creating symlinks from elsewhere in sysfs to the GPIO sysfs node. Drivers can use this to provide the interface under their own device in sysfs with a descriptive name.

Drivers can use gpio_sysfs_set_active_low() to hide GPIO line polarity differences between boards from user space. This only affects the sysfs interface. Polarity change can be done both before and after gpio_export(), and previously enabled poll(2) support for either rising or falling edge will be reconfigured to follow this setting.

Re: Simple GPIO Example - quandry

christophertele — Mon, 07 Dec 2015 05:58:36 GMT

there are different ways to access the gpios. you can access them from kernel- and userspace. in kernel space you have to use simple kernel modules. in user space you can toggle in bash using sysfs or in c using mmap and so on. here are some toggle speed results i get

Using sysfs (bash/c) [userspace]: ~3500Hz

calling /dev/mem using mmap [userspace]: ~800kHz

using gpio.h in a simple kernel module [kernelspace]: ~280kHz

ioremap() with writel [kernelspace] : ~1.6MHz

ioremap() with pointers [kernelspace]: ~5.5MHz

check out my code:

Dropbox - gpio_examples.tar.gz

Re: Simple GPIO Example - quandry

johncoleman — Mon, 07 Dec 2015 13:43:50 GMT

I am quite familiar with the explanations that you list - but still provides No output on the UL-Evk Board pins (with a Vmeter or scope).

- As you can see I already tried as you specified (clipped short to not Load the Blogs of course).

Actually, I am taking these from examples of howto code for Gpios here.

I can only Assume to Follow these examples - that I can find on freescale for their boards..

I am used to working on large Linux embedded client/server systems without worrying about gpios.

I would hope to see examples on freescale on howto work with its board gpios and io - to make any used of it.

Re: Simple GPIO Example - quandry

johncoleman — Mon, 07 Dec 2015 13:50:22 GMT

Thanks Christopher,

Will list the results.

Re: Simple GPIO Example - quandry

johncoleman — Wed, 09 Dec 2015 17:30:46 GMT

Christopher - Thanks for the code !

I compiled your code and expanded it to about 8 more pins.

But, I still do not see any changes on the Port Pins.

- Maybe, there is something that I need to Enable the GPIO handler ?

(GPIO already seems enabled in MenuConfig)

#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <fcntl.h>
#include <sys/mman.h>
#include <errno.h>
#include <string.h>
#include <stdint.h>
#include <unistd.h>

//// MUX reg:
#define IOMUXC 0x020E0000
//// MUX PAD reg:
#define IOMUXC_SW_MUX_CTL_PAD_SD4_DATA0 0x020E031C

//// DATA reg:
#define GPIO1_DR 0x0209C000
//// DIR reg:
#define GPIO1_GDIR 0x0209C004

#define GPIO1_PSR 0x0209C008

#define GPIO2_DR                         0x020A0000
//// DIR reg:
#define GPIO2_GDIR                       0x020A0004
#define GPIO2_PSR                        0x020A0008

static volatile uint32_t *gpio;

int main(int argc, char **argv)
{
printf("\n*** Test GPIOs :\n");

int fd ;

printf("- Open /dev/mem ..\n");

    //Obtain handle to physical memory
    if ((fd = open ("/dev/mem", O_RDWR | O_SYNC) ) < 0) {
        printf("Unable to open /dev/mem: %s\n", strerror(errno));
        return -1;
    }

printf("- Map MUX Pins ..\n");

    /**
      * Map some of the pin mux registers within the range of the
      * GPIO40 GPIO40 pin.
    **/
    gpio = (uint32_t *)mmap(0, (getpagesize() * 250), PROT_READ|PROT_WRITE, MAP_SHARED, fd, IOMUXC);

    // The first 3 bits are the only thing that matters here according to the
    // datasheet.
    *(gpio + ((IOMUXC_SW_MUX_CTL_PAD_SD4_DATA0 - IOMUXC) / 4)) = 0x5;
//    *(gpio + ((0x020E031C                      - IOMUXC) / 4)) = 0x5;    // UART1_RTS
    *(gpio + ((0x020E04B8                      - IOMUXC) / 4)) = 0x5;    // USB_OTG1_ID
    *(gpio + ((0x020E0660                      - IOMUXC) / 4)) = 0x5;    // USB_OTG2_OC
    *(gpio + ((0x020E01BC                      - IOMUXC) / 4)) = 0x5;    // SD1_CMD
    *(gpio + ((0x020E01C0                      - IOMUXC) / 4)) = 0x5;    // SD1_CLK
    *(gpio + ((0x020E01C4                      - IOMUXC) / 4)) = 0x5;    // SD1_DATA0
    *(gpio + ((0x020E01C8                      - IOMUXC) / 4)) = 0x5;    // SD1_DATA1
    *(gpio + ((0x020E01CC                      - IOMUXC) / 4)) = 0x5;    // SD1_DATA2
    *(gpio + ((0x020E01D0                      - IOMUXC) / 4)) = 0x5;    // SD1_DATA3

printf("- MunMap ..\n");

    //Be a good neighbor
    if((munmap((void *)gpio, (getpagesize() * 250))) < 0){
        printf("munmap failed: %s\n", strerror(errno));
        exit(1);
    }

printf("- MMap => gpio addr ..\n");

    /** The i.MX 6 Dual and Quad Processor have 7 GPIO banks
      * Each bank amounts to 1mb of memory which is perfectly
      * aligned for a memory map. Mmap will fail if the offset
      * is not a multiple of 1mb. For this example I just want
      * the GPIO2 bank which starts at 0x020A0000. I want the
      * bank (1mb or 250 pages of memory). I could get away with
      * a single page, but I am greedy :-P.
    **/
    gpio = (uint32_t *)mmap(0, (getpagesize() * 250), PROT_READ|PROT_WRITE, MAP_SHARED, fd, GPIO2_DR);

    if ((int32_t)gpio < 0){
        printf("mmap failed: %s\n", strerror(errno));
        exit(1);
    }

printf("- Setup GPIOs DIR ..\n\n");

    /**
      * Setup GPIO40 or GPIO2_IO08 as an output.
      * gpio[1] is the GPIO direction register (GPIO2_GDIR).
      * We want to only want to set bit 8 of this register
      * to a binary 1 while leaving the rest intact.
    **/
    *(gpio + ((GPIO2_GDIR - GPIO2_DR) / 4)) = *(gpio + ((GPIO2_GDIR - GPIO2_DR) / 4)) | 1<<8;
    *(gpio + ((GPIO2_GDIR - GPIO2_DR) / 4)) = *(gpio + ((GPIO2_GDIR - GPIO2_DR) / 4)) | (0xFFFFFFFF);    // Gpio2.00-32

    printf("- Looping ..\n");

    /**
      * Blink GPIO40 every 1000 millisec=1sec //500 milliseconds.
      * gpio[0] is the GPIO data register (GPIO2_DR).
      * We only want to toggle bit 8 of this register
      * while leaving the rest alone.
    **/
    while(1)
    {
        printf(".\n");

        *(gpio + ((GPIO2_DR - GPIO2_DR) / 4)) = *(gpio + ((GPIO2_DR - GPIO2_DR) / 4)) ^ 1<<8;
        *(gpio + ((GPIO2_DR - GPIO2_DR) / 4)) = *(gpio + ((GPIO2_DR - GPIO2_DR) / 4)) | (0xFFFFFFFF);    // Gpio2.00-32
        usleep(500000); // usleep(250000);

        *(gpio + ((GPIO2_DR - GPIO2_DR) / 4)) = *(gpio + ((GPIO2_DR - GPIO2_DR) / 4)) ^ 1<<8;
        *(gpio + ((GPIO2_DR - GPIO2_DR) / 4)) = *(gpio + ((GPIO2_DR - GPIO2_DR) / 4)) & (0x00000000);    // Gpio2.00-32
        usleep(500000); // usleep(250000);
    }
}

Re: Simple GPIO Example - quandry

christophertele — Thu, 10 Dec 2015 05:40:15 GMT

have you tried the other examples?check out the example "gpiotoggle.sh". just use the pin you want to toggle. that should work or you will get an error code during exporting the gpio.

what about gpioMod.c ?

this exmaple makes use of gpio.h. usage is very simple and the function gpio_request() should work or will give back an error.

this is how you calculate the GPIO Numbers:

linux gpio number = (<X> - 1) * 32 + <Y>

GPIO<X>_IO<Y> (example: GPIO3_IO23, X=3, Y=23)

cheers

christopher

Re: Simple GPIO Example - quandry

BiyongSUN — Thu, 10 Dec 2015 05:50:20 GMT

The follow is the test on reference board. But it is pure linux topic, mentioned in 3.14.28 Documentation/gpio/gpio-legacy.txt, posted before.

This is just show you guys what is the correct method accessing gpio in linux, despite which kind of chip.

Suggest you guys again, read the linux document carefully.

christopher's solution is also a workaround.

The test use the sysfs, which mentioned in the linux documents. Then use memtool to verify the result.

memtool is using the same way as the christopher's code. christopher's code is just very small part of memtool. the christopher's code is to access the register directly as memtool does.

But again here, from the linux programming layer, it is a workround.

One important thing, you need to check the IOMUX you configured is correct for GPIO.

root@imx6qdlsolo:~# echo 115 > /sys/class/gpio/export
root@imx6qdlsolo:~# /unit_tests/memtool 0x20a8004 1
E
Reading 0x1 count starting at address 0x020A8004

0x020A8004: 0E050000

root@imx6qdlsolo:~# echo out > /sys/class/gpio/gpio115/direction
root@imx6qdlsolo:~# /unit_tests/memtool 0x20a8004 1
E
Reading 0x1 count starting at address 0x020A8004

0x020A8004: 0E0D0000

If you guys still don't believe, please google as following:

Re: Simple GPIO Example - quandry

johncoleman — Thu, 10 Dec 2015 13:45:33 GMT

Christopher,

I tried the gpiotoggle.sh but with no pin level changes.

I even wrote a script to cover All Gpios - but with No changes on the Pin Voltages.

vi setGpioAllOut.sh

#!/bin/sh

for i in {1..255}
do
    echo $i > /sys/class/gpio/export
    echo "out" > /sys/class/gpio/gpio$i/direction
    echo "1" > /sys/class/gpio/gpio$i/value
# cat /sys/class/gpio/gpio$i/value
done

chmod 777 setGpioAllOut.sh

./setGpioAllOut.sh

I can not compile GpioMod.c :

Log data follows:

| DEBUG: Executing shell function do_compile

| helloworld4.c:171:72: fatal error: linux/module.h: No such file or directory

| #include <linux/module.h> // dynamic loading of modules into the kernel

| compilation terminated.

| WARNING: exit code 1 from a shell command.

I have not been able to figure out how to add the extra include paths for <linux/..>.

Note: I am using the Ultralite board.

I am running the Minimal compile Image.

I am logged in as Root.

There must be something missing on Gpio config or enables. (But I have changed nothing)

What is left ?

John.

Re: Simple GPIO Example - quandry

christophertele — Thu, 10 Dec 2015 14:00:06 GMT

something wrong with your reference voltage?

are you measuring against GND or 3,3/1,8V??

i do compile GpioMod.c on target with the makefile in the examples directory. just add the target name in line #1.

using yocto you have to ad following to your local.conf:

IMAGE_FEATURES_append = " tools-sdk dev pkgs "

IMAGE_INSTALL_append = " kernel-dev "

after boot:

- log in

- call: cd /usr/src/kernel
make silentoldconfig scripts

- run your makefile

i dont know if you have to add your GPIOS to the device tree.

Re: Simple GPIO Example - quandry

johncoleman — Thu, 10 Dec 2015 14:53:52 GMT

Appended to local.conf :

IMAGE_FEATURES_append = " tools-sdk dev pkgs "

IMAGE_INSTALL_append = " kernel-dev "

ERROR: Nothing PROVIDES 'core-image-minimal'
ERROR: core-image-minimal was skipped: 'pkgs' in IMAGE_FEATURES (added via EXTRA_IMAGE_FEATURES) is not a valid image feature. Valid features: allow-empty-password dbg-pkgs debug-tweaks dev-pkgs doc doc-pkgs eclipse-debug empty-root-password hwcodecs nfs-server package-management post-install-logging ptest-pkgs qt4-pkgs qtcreator-debug read-only-rootfs splash ssh-server-dropbear ssh-server-openssh staticdev-pkgs tools-debug tools-profile tools-sdk tools-testapps x11 x11-base x11-sato

Summary: There was 1 ERROR message shown, returning a non-zero exit code.

Voltages should be correct.

I am reading 5V and 3.3V on the source pins.

Re: Simple GPIO Example - quandry

florian12 — Fri, 11 Dec 2015 01:22:03 GMT

:smileyplus::smileyplus::smileyplus: christophertelemanngreat table with the overview of different, achievable, frequency!

Re: Simple GPIO Example - quandry

BiyongSUN — Fri, 11 Dec 2015 04:25:56 GMT

Please check your IOMUX in devicee tree.

If you don't want to modify the code, you can use the memtool to set the IOMUX for GPIO.

Re: Simple GPIO Example - quandry

christophertele — Fri, 11 Dec 2015 05:40:21 GMT

oops! sorry! should be dev-pkgs!

can you check your devicetree?

Re: Simple GPIO Example - quandry

almarto — Fri, 11 Dec 2015 08:58:17 GMT

Hi Biyong,

I am really interested in working the way you have suggested. If I understand correctly, I don't need to modify the device tree everytime I want to check a different GPIO configuration .... is this right?

I would appreciate very much that you could show me how to do it with a concrete example ( I have few experience with embedded linux). I am also using imx6ulevk and would like to use arduino expansion port for gpio purposes.

SD1_DATA1 is configured in the device tree as:

&iomuxc {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_hog_1>;
imx6ul-evk {

....
pinctrl_usdhc1: usdhc1grp {

      fsl,pins = <
      ......
      MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x17059
     ......

      >;
      };
pinctrl_usdhc1_100mhz: usdhc1grp100mhz {
      fsl,pins = <
     .......

MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x170b9
......

      >;
      };
pinctrl_usdhc1_200mhz: usdhc1grp200mhz {
      fsl,pins = <

......

MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x170f9

.......

};
.....

}

as I am only using sdh2, I can completely redefine the use of these pins and SD1_DATA1 could be a gpio: MX6UL_PAD_SD1_DATA1__GPIO2_IO19

How can I redefine the use of this pin without modifying the device tree by using memtool?

Could you please illustrate this example as a reference?

Thank you in advance!

Re: Simple GPIO Example - quandry

BiyongSUN — Fri, 11 Dec 2015 10:42:23 GMT

Let's pick up usdhc1 cd pin on i.mx6ul evk for test.

The MX6UL_PAD_UART1_RTS_B is configured as GPIO1_IO19 in device tree, which is used by usdhc1 as sd1 cd.

MX6UL_PAD_UART1_RTS_B__GPIO1_IO19 0x17059 /* SD1 CD */

imx6ul-14x14-evk.dts

314 &usdhc1 {
315        pinctrl-names = "default", "state_100mhz", "state_200mhz";
316        pinctrl-0 = <&pinctrl_usdhc1>;
317        pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
318        pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
319        cd-gpios = <&gpio1 19 0>;
320        keep-power-in-suspend;
321        enable-sdio-wakeup;
322        vmmc-supply = <&reg_sd1_vmmc>;
323        status = "okay";
324 };

407 &iomuxc {
408        pinctrl-names = "default";
409        pinctrl-0 = <&pinctrl_hog_1>;
410        imx6ul-evk {
411                pinctrl_hog_1: hoggrp-1 {
412                        fsl,pins = <
413                                MX6UL_PAD_LCD_RESET__WDOG1_WDOG_ANY    0x30b0
414                                MX6UL_PAD_UART1_RTS_B__GPIO1_IO19      0x17059 /* SD1 CD */
415                                MX6UL_PAD_GPIO1_IO05__USDHC1_VSELECT    0x17059 /* SD1 VSELECT */
416                                MX6UL_PAD_GPIO1_IO09__GPIO1_IO09        0x17059 /* SD1 RESET */
417                        >;

Debug fs give us chance to check the gpio status:

cat /sys/kernel/debug/gpio

sdcard plugout: gpio-19 (2190000.usdhc cd ) in hi

sdcard plugin : gpio-19 (2190000.usdhc cd ) in lo

sdcard plug out:

root@imx6ulevk:~# cat /sys/kernel/debug/gpio

GPIOs 0-31, platform/209c000.gpio, 209c000.gpio:
gpio-3   (tsc_X-              ) in hi
gpio-9   (VSD_3V3             ) out lo
gpio-19 (2190000.usdhc cd    ) in hi

GPIOs 32-63, platform/20a0000.gpio, 20a0000.gpio:

GPIOs 64-95, platform/20a4000.gpio, 20a4000.gpio:

GPIOs 96-127, platform/20a8000.gpio, 20a8000.gpio:
gpio-119 (? ) out lo

GPIOs 128-159, platform/20ac000.gpio, 20ac000.gpio:
gpio-131 (?                   ) out lo
gpio-132 (headset detect      ) in lo
gpio-135 (spi32766.0          ) out lo
gpio-136 (?                   ) out lo
gpio-138 (spi4.14             ) out lo
gpio-139 (spi4.14             ) out lo

sdcard plugin:

root@imx6ulevk:~# cat /sys/kernel/debug/gpio

GPIOs 0-31, platform/209c000.gpio, 209c000.gpio:
gpio-3   (tsc_X-              ) in hi
gpio-9   (VSD_3V3             ) out lo
gpio-19 (2190000.usdhc cd    ) in lo

GPIOs 32-63, platform/20a0000.gpio, 20a0000.gpio:

GPIOs 64-95, platform/20a4000.gpio, 20a4000.gpio:

GPIOs 96-127, platform/20a8000.gpio, 20a8000.gpio:
gpio-119 (? ) out lo

But we could not use it as an indenpendent GPIO, because this GPIO is used by usdhc1 module.

You will get busy when you try to use it as an independent GPIO.

root@imx6ulevk:~# echo 19 > /sys/class/gpio/export

-sh: echo: write error: Device or resource busy

root@imx6ulevk:~#

Let's modify the device tree to make gpio-19 isolated from usdhc1:

314 &usdhc1 {

315 pinctrl-names = "default", "state_100mhz", "state_200mhz";

316 pinctrl-0 = <&pinctrl_usdhc1>;

317 pinctrl-1 = <&pinctrl_usdhc1_100mhz>;

318 pinctrl-2 = <&pinctrl_usdhc1_200mhz>;

319 // cd-gpios = <&gpio1 19 0>;

320 keep-power-in-suspend;

321 enable-sdio-wakeup;

322 vmmc-supply = <&reg_sd1_vmmc>;

323 status = "okay";

324 };

recompile the dts and get the new dtb file. replace the old one and reboot the i.mx6ul evk

let's check by debug fs and sys class we could not find the gpio-19.

root@imx6ulevk:~# cat /sys/kernel/debug/gpio
GPIOs 0-31, platform/209c000.gpio, 209c000.gpio:
gpio-3 (tsc_X- ) in hi
gpio-9 (VSD_3V3 ) out lo

GPIOs 32-63, platform/20a0000.gpio, 20a0000.gpio:

GPIOs 64-95, platform/20a4000.gpio, 20a4000.gpio:

GPIOs 96-127, platform/20a8000.gpio, 20a8000.gpio:
gpio-119 (? ) out lo

root@imx6ulevk:~# ls /sys/class/gpio/

export gpiochip0 gpiochip248 gpiochip64 unexport

gpio132 gpiochip128 gpiochip32 gpiochip96

Let's export gpio19

root@imx6ulevk:~# echo 19 > /sys/class/gpio/export

root@imx6ulevk:~# ls /sys/class/gpio/

export gpio19 gpiochip128 gpiochip32 gpiochip96

gpio132 gpiochip0 gpiochip248 gpiochip64 unexport

check with debug fs if we can see it.

Yes. we see it.

root@imx6ulevk:~# cat /sys/kernel/debug/gpio
GPIOs 0-31, platform/209c000.gpio, 209c000.gpio:
gpio-3   (tsc_X-              ) in hi
gpio-9   (VSD_3V3             ) out lo
gpio-19 (sysfs               ) in hi

GPIOs 32-63, platform/20a0000.gpio, 20a0000.gpio:

GPIOs 64-95, platform/20a4000.gpio, 20a4000.gpio:

GPIOs 96-127, platform/20a8000.gpio, 20a8000.gpio:
gpio-119 (? ) out lo

check the gpio-19 value

sdcard plugout:

root@imx6ulevk:~# cat /sys/class/gpio/gpio19/value

524288

sdcard plugin:

root@imx6ulevk:~# cat /sys/class/gpio/gpio19/value

why it is not 0 and 1? because it is raw data. any nonzero value is treated as high

The following is from linux document.

It may also provide a customvalue for ARCH_NR_GPIOS, so that it better reflects the number of GPIOs in
actual use on that platform, without wasting static table space. (It should count both built-in/SoC GPIOs and

also ones on GPIO expanders.

Sysfs Interface for Userspace (OPTIONAL)
"value" ... reads as either 0 (low) or 1 (high). If the GPIO
is configured as an output, this value may be written;

any nonzero value is treated as high.

let's check with debug fs.

sdcard plug out:

GPIOs 32-63, platform/20a0000.gpio, 20a0000.gpio:

GPIOs 64-95, platform/20a4000.gpio, 20a4000.gpio:

GPIOs 96-127, platform/20a8000.gpio, 20a8000.gpio:
gpio-119 (? ) out lo

sdcard plugin:

root@imx6ulevk:~# cat /sys/kernel/debug/gpio
GPIOs 0-31, platform/209c000.gpio, 209c000.gpio:
gpio-3   (tsc_X-              ) in hi
gpio-9   (VSD_3V3             ) out lo
gpio-19 (sysfs               ) in lo

GPIOs 32-63, platform/20a0000.gpio, 20a0000.gpio:

GPIOs 64-95, platform/20a4000.gpio, 20a4000.gpio:

GPIOs 96-127, platform/20a8000.gpio, 20a8000.gpio:
gpio-119 (? ) out lo

Do you notice it is show hi and lo, not a value. (remember any nonzero value is treated as high. )

Verify with memtool:

root@imx6ulevk:~# /unit_tests/memtool GPIO1.DR.DR

SOC: i.MX6UL

GPIO1 Addr:0x209c000

GPIO1.DR Addr:0x0209C000 Value:0xF00C0118 - The 32-bit GPIO_DR register stores data that is ready to be driven to the output lines.

GPIO1.DR.DR(0..31) :0xf00c0118

root@imx6ulevk:~# /unit_tests/memtool GPIO1.DR.DR

SOC: i.MX6UL

GPIO1 Addr:0x209c000

GPIO1.DR Addr:0x0209C000 Value:0xF0040118 - The 32-bit GPIO_DR register stores data that is ready to be driven to the output lines.

GPIO1.DR.DR(0..31) :0xf0040118

Data bits.

0xf00c0118 -> 0xf0040118

bit 19 1 -> 0 (hi->lo)

Could we use the debug fs for accessing gpio from use space.

No. Please don't do that.

a. It is for debug purpose.

b. it could not handle output.

What we need to do for an independent?

Only one thing: Correct IOMUX pinctrl in device tree.

In this example is:

MX6UL_PAD_UART1_RTS_B__GPIO1_IO19 0x17059 /* SD1 CD */

407 &iomuxc {

408 pinctrl-names = "default";

409 pinctrl-0 = <&pinctrl_hog_1>;

410 imx6ul-evk {

411 pinctrl_hog_1: hoggrp-1 {

412 fsl,pins = <

413 MX6UL_PAD_LCD_RESET__WDOG1_WDOG_ANY 0x30b0

414 MX6UL_PAD_UART1_RTS_B__GPIO1_IO19 0x17059 /* SD1 CD */

415 MX6UL_PAD_GPIO1_IO05__USDHC1_VSELECT 0x17059 /* SD1 VSELECT */

416 MX6UL_PAD_GPIO1_IO09__GPIO1_IO09 0x17059 /* SD1 RESET */

417 >;

Why we know echo 19 > /sys/class/gpio/export Not other number?

Please run the command

for i in /sys/class/gpio/* ; do cat $i/label; cat $i/base; echo; done

209c000.gpio
0

20ac000.gpio
128

74hc595
248

20a0000.gpio
32

20a4000.gpio
64

20a8000.gpio
96

imx6ul.dtsi

468 gpio1: gpio@0209c000 {

469 compatible = "fsl,imx6ul-gpio", "fsl,imx35-gpio";

470 reg = <0x0209c000 0x4000>;

471 interrupts = <GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH>,

472 <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>;

473 gpio-controller;

474 #gpio-cells = <2>;

475 interrupt-controller;

476 #interrupt-cells = <2>;

477 };

209c000 is for gpio1 and the base is "0".

So, the bit 19 is 0 + 19.

What does this caculation refer to?

It is the linux document I mentoined before.

Let take another example for 20a8000.gpio base is 96.

501 gpio4: gpio@020a8000 {

502 compatible = "fsl,imx6ul-gpio", "fsl,imx35-gpio";

503 reg = <0x020a8000 0x4000>;

504 interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,

505 <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;

506 gpio-controller;

507 #gpio-cells = <2>;

508 interrupt-controller;

509 #interrupt-cells = <2>;

510 };

If we want to use gpio4-11, we should do is to echo 107 > /sys/class/gpio/export

107 = 96 + 11

Re: Simple GPIO Example - quandry

BiyongSUN — Fri, 11 Dec 2015 11:31:18 GMT

Using memtool to set IOMUX as GPIO is just for test.

In the real project, you should modify the device tree.

memtool is very useful debug tool. Not only can configure pad as GPIO but others as well.

Here is example:

root@imx6ulevk:~# /unit_tests/memtool IOMUXC.SW_MUX_CTL_PAD_SD1_DATA1.
SOC: i.MX6UL
IOMUXC   Addr:0x20e0000
IOMUXC.SW_MUX_CTL_PAD_SD1_DATA1 Addr:0x020E01C8 Value:0x00000000 - SW_MUX_CTL Register
     IOMUXC.SW_MUX_CTL_PAD_SD1_DATA1.MUX_MODE(0..3)     :0x0
             Select 1 of 9 iomux modes to be used for pad: SD1_DATA1.
     IOMUXC.SW_MUX_CTL_PAD_SD1_DATA1.SION(4..4)         :0x0
             Force the selected mux mode Input path no matter of MUX_MODE functionality.

oot@imx6ulevk:~# /unit_tests/memtool IOMUXC.SW_MUX_CTL_PAD_SD1_DATA1.MUX_MODE=5
SOC: i.MX6UL

root@imx6ulevk:~# /unit_tests/memtool IOMUXC.SW_MUX_CTL_PAD_SD1_DATA1.
SOC: i.MX6UL
IOMUXC   Addr:0x20e0000
IOMUXC.SW_MUX_CTL_PAD_SD1_DATA1 Addr:0x020E01C8 Value:0x00000005 - SW_MUX_CTL Register
     IOMUXC.SW_MUX_CTL_PAD_SD1_DATA1.MUX_MODE(0..3)     :0x5
             Select 1 of 9 iomux modes to be used for pad: SD1_DATA1.
     IOMUXC.SW_MUX_CTL_PAD_SD1_DATA1.SION(4..4)         :0x0
             Force the selected mux mode Input path no matter of MUX_MODE functionality.

Note sometime you need to set the pad ctrl.

root@imx6ulevk:~# /unit_tests/memtool IOMUXC.SW_PAD_CTL_PAD_SD1_DATA1.
SOC: i.MX6UL
IOMUXC   Addr:0x20e0000
IOMUXC.SW_PAD_CTL_PAD_SD1_DATA1 Addr:0x020E0454 Value:0x00017059 - SW_PAD_CTL Register
     IOMUXC.SW_PAD_CTL_PAD_SD1_DATA1.SRE(0..0) :0x1
             Select one out of next values for pad: SD1_DATA1
     IOMUXC.SW_PAD_CTL_PAD_SD1_DATA1.DSE(3..5) :0x3
             Select one out of next values for pad: SD1_DATA1
     IOMUXC.SW_PAD_CTL_PAD_SD1_DATA1.SPEED(6..7)        :0x1
             Select one out of next values for pad: SD1_DATA1
     IOMUXC.SW_PAD_CTL_PAD_SD1_DATA1.ODE(11..11)        :0x0
             Select one out of next values for pad: SD1_DATA1
     IOMUXC.SW_PAD_CTL_PAD_SD1_DATA1.PKE(12..12)        :0x1
             Select one out of next values for pad: SD1_DATA1
     IOMUXC.SW_PAD_CTL_PAD_SD1_DATA1.PUE(13..13)        :0x1
             Select one out of next values for pad: SD1_DATA1
     IOMUXC.SW_PAD_CTL_PAD_SD1_DATA1.PUS(14..15)        :0x1
             Select one out of next values for pad: SD1_DATA1
     IOMUXC.SW_PAD_CTL_PAD_SD1_DATA1.HYS(16..16)        :0x1
             Select one out of next values for pad: SD1_DATA1

you can use "."(dot) to list all:

root@imx6ulevk:~# /unit_tests/memtool .

SOC: i.MX6UL

Module Base Address

ADC1 0x02198000

ADC2 0x0219C000

APBH 0x01804000

ASRC 0x02034000

BCH 0x01808000

CCM 0x020C4000

CCM_ANALOG 0x020C8000

CSI 0x021C4000

ECSPI1 0x02008000

ECSPI2 0x0200C000

I2S1 0x02028000

I2S2 0x0202C000

I2S3 0x02030000

IOMUXC 0x020E0000

IOMUXC_GPR 0x020E4000

KPP 0x020B8000

LCDIF 0x021C8000

MMDC 0x021B0000

Not only the IOMUX but other module registers you can check.

root@imx6ulevk:~# /unit_tests/memtool GPT1.

SOC: i.MX6UL

GPT1 Addr:0x2098000

GPT1.CR Addr:0x02098000 Value:0x00000749 - The GPT Control Register (GPT_CR) is used to program and configure GPT operations.

GPT1.CR.EN(0..0) :0x1

GPT Enable.

GPT1.CR.ENMOD(1..1) :0x0

GPT Enable mode.

GPT1.CR.DBGEN(2..2) :0x0

GPT debug mode enable.

GPT1.CR.WAITEN(3..3) :0x1

GPT Wait Mode enable.

GPT1.CR.DOZEEN(4..4) :0x0

GPT Doze Mode Enable.

GPT1.CR.STOPEN(5..5) :0x0

GPT Stop Mode enable.

GPT1.CR.CLKSRC(6..8) :0x5

Clock Source select.

GPT1.CR.FRR(9..9) :0x1

Free-Run or Restart mode.

GPT1.CR.EN_24M(10..10) :0x1

Re: Simple GPIO Example - quandry

johncoleman — Fri, 11 Dec 2015 14:18:27 GMT

Where do I find this memtool ?

Re: Simple GPIO Example - quandry

almarto — Mon, 14 Dec 2015 11:38:11 GMT

Thank you very much Biyong for such illustrative examples. They clarify many concepts for developers who still don't have a great knowledge in Linux which is exactly my situation. So thank you very much for your help!

I have gone through all your proposals for debugging and I have succeeded in all of them except for one important thing: I am unable to compile the device tree! and this is what I need for my board customization, since I cannot use debug tools for my board customization project.

This i what I try to do:

I modify imx6ul-evk-14x14.dts and save it with another name (imx6ul-evk-14x14-custom.dts) in the same directory, that is in:

/home/alvaro/yocto/fsl-release-bsp-ul/build-qt5/tmp/work-shared/imx6ulevk/kernel-source/arch/arm/boot/dts/imx6ul-evk-14x14-custom.dts

and execute from directory where dtc executable is:

./dtc /home/alvaro/yocto/fsl-release-bsp-ul/build-qt5/tmp/work-shared/imx6ulevk/kernel-source/arch/arm/boot/dts/imx6ul-evk-14x14-custom.dts

I get the following error:

Error: /home/alvaro/yocto/fsl-release-bsp-ul/build-qt5/tmp/work-shared/imx6ulevk/kernel-source/arch/arm/boot/dts/imx6ul-14x14-custom.dts:11.1-9 syntax error

FATAL ERROR: Unable to parse input tree

This also happens with the original file imx6ul-evk-14x14.dts, so that I guess it has nothing to do with the file modifications.

Do you have any idea of what might be happening?

Thank you in advance!

Re: Simple GPIO Example - quandry

johncoleman — Mon, 14 Dec 2015 16:31:38 GMT

We are working with the iMx6sx/sl processors, testing on the imx6-UltraLite and imx6-Sabre-Solo Boards.

I have been compiling the Images under Yocto on.

But, I can not find the relevant DTS files:

~/yocto_3.14.38-6UL/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/linux-libc-headers/3.14-r0/linux-3.14/arch/arm/boot/dts $

imx6sl-evk.dts

imx6sl-pinfunc.h

imx6sl-warp.dts

imx6sl.dtsi

imx6sx-pinfunc.h

imx6sx-sabreauto.dts

imx6sx-sdb-reva.dts

imx6sx-sdb.dts

imx6sx-sdb.dtsi

imx6sx.dtsi

Why are these files missing (but I can still compile the Images for the Board),

and how do I add them to the Yocto source ?

... I need to add GPIO access in the DTS via the DTS files.