Understanding the configuration and usage of i.MX53 MUXIO pins for a customizing board -blog archive

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

Understanding the configuration and usage of i.MX53 MUXIO pins for a customizing board -blog archive

4,172 Views
AlanZhang
Contributor V

When Linux kernel entry to startup, the first data block it will execute is MACHINE_START/END where the map_io, init_irq, init_machine, and timer will be initialized to guarantee that these basic parts of Linux kernel work well or prepare low level runtime to support kernel-level APIs such as irq_request() etc. This entry block is usually defined in mx53_xxx.c (xxx stands for board name, such as smd), looking into this file, we can find out there exist a lot of GPIO definitions and IOMUX pins' configuration, platform devices' declarations that will be registered into Kernel, and used by driver later when insmod'ing.

To take a first look on mach-mx5/mx53_smd.c, the macros and mx53_smd_pads[] looks complilcated to a newbies, this article will explain the background behind these coding step by step, so these definitioins could be easy to be handled for a new specific customer's board based on i.MX53.

Step 1: Every customers' design must follow certain specification that can be derived to the top level design in which we can see what interfaces of i.MX53 will be utilized for the interactions between i.MX53 and external peripherals;

        At this phase, we use IOMUX_plan_calculatorMX53_100517_ext.xls developed by Roman Mostinski (maybe there exist new update of this tool) to plan the  pins-out bundled w/ interfaces (i.e. connecting to i.MX53 internal functional modules), its "Instruction" sheet tells you how to use this tool to customize the utilized interfaces in the target design. I briefly describe here. First, switch to "Configuration_Select" sheet, under "Module" column, the i.MX53 total modules have been listed, so you can choice one module that your design utilizes (ex. Camera Interface module) from the list, then set "TRUE" or "FALSE" of each module signal at column Z labeled "Needed for Usecase", then choice another module, do the same module signal setting, and so on till all utilized modules have been set up. For verification on the IOMUX pins planning, I cite the developer's description:

 


 "MX53_pins" tab
  This table shows current current status of port allocation
  >For each pad (row) check column "Conflict" (column "J"):
   - "TRUE" indicates there are conflicting ports (ALTxx cells colored in orange) or port(s) that could not be allocated at all (ALTxx cells colored in red). You should re-consider
IOMUX plan if some ports can not be allocated.
   - "FALSE" indicates there is no conflict. Please check ALTxx. If there is cell colored in orange it indicates port that have only single available location in the current IOMUX plan, and
therefore that port should be allocated.
  For pad allocation please select appropriate ALT mode (column "H") and lock pad (change "FREE" to "LOCK") in column "G"
   - column "I" shows function (port) corresponding to the selected ALT mode
   - Allocated ports will be marked in green. If the ALT mode in configured IOMUX is not the same as it is in the default configuration the cell in column H changes its color to bright yellow.
  Re-check conflicts and repeat pad allocation

        At this point, we have defined the dedicated IOMUX pins to connect the target board's peripherals, and these dedicated pins are routed to i.MX53 internal modules (ex. SPI, CSI, eMMC, SPDIF, DISP0/1 etc.), and we also know that some peripherals like HDMI transmitter may require extra switch signals to perform controlling purpose, so GPIO pins allocated from GPIO modules are involved. This requirement will definitely occur when no dedicated interfaces are  supported by default. Considering that GPIO is one modules in "Configuration_Select" sheet, so we can specify these needed GPIO switch signals randomly, if these setting cause "Conflict" in "MX53_pins" sheet, for more fine tune, we have to reference to chapter 4 in "i.MX53 Reference Manual" to figure out a proper choice.

 

Step 2: Add these interfaces' usage in mach-mx5/mx53_smd.c as following

static iomux_v3_cfg_t mx53_smd_pads[] = {

        ............

    /* DI_VGA_HSYNC */
    MX53_PAD_EIM_OE__IPU_DI1_PIN7,
    /* HDMI reset */
    MX53_PAD_EIM_WAIT__GPIO5_0,
    /* DI_VGA_VSYNC */
    MX53_PAD_EIM_RW__IPU_DI1_PIN8,
    /* CSPI1 */
    MX53_PAD_EIM_EB2__ECSPI1_SS0,
    MX53_PAD_EIM_D16__ECSPI1_SCLK,
    MX53_PAD_EIM_D17__ECSPI1_MISO,
    MX53_PAD_EIM_D18__ECSPI1_MOSI,
    MX53_PAD_EIM_D19__ECSPI1_SS1,
    /* BT: UART3*/
    MX53_PAD_EIM_D24__UART3_TXD_MUX,
    MX53_PAD_EIM_D25__UART3_RXD_MUX,
    MX53_PAD_EIM_EB3__UART3_RTS,
    MX53_PAD_EIM_D23__UART3_CTS,
        ............

}

This array settings are used for IOMUXC set by mxc_iomux_v3_setup_pad(),  its naming pattern reflects the mapping relation in <MX53_PAD_xxx, Block_BlockPort>. ex. MX53_PAD_EIM_D24__UART3_TXD_MUX in which EIM_D24 stands for the pad name, and UART3_TXD_MUX stands for block instance is UART3, TXD_MUX is the block I/O (extracted from Table 4-3, i.MX53 Reference Manual).


 

The mx53_smd_pads[] enumerates all used interfaces that are connected to external peripherals, so certainly it also contains the controlling purpose switch signals bundled w/ certain peripheral that will be set as GPIO block I/O.

 

Step 3: Define bundled GPIO signals

For that extra control purpose switch signals (GPIO typed), we define these switch signals totally as being macros. For example:

#define MX53_SMD_HDMI_RESET_B        (4*32 + 0)    /* GPIO_5_0 */
#define MX53_SMD_MODEM_RESET_B        (4*32 + 2)    /* GPIO_5_2 */
#define MX53_SMD_KEY_INT            (4*32 + 4)    /* GPIO_5_4 */

where MX53_SMD stands for target board name, HDMI_RESET_B is the net name in schematic design,  (4 * 32 + 0) stands for the #0 block I/O of #5 GPIO Block Instance, these macro setting will be used by gpio_request(), gpio_get_value(), gpio_set_value(), gpio_direction_output(), and gpio_direction_input() APIs. These switch control signals will be referenced by devices' kernel driver to perform specific control purpose. Note the same pin declared in mx53_smd_pads[] is    

/* HDMI reset */
    MX53_PAD_EIM_WAIT__GPIO5_0,
it is for IOMUXC only.

 

Summary

When facing a new customer's board, we can deduce these pins' configuration and usage step by step without missing following the above guidelines.

 

 

s of port allocation
  >For each pad (row) check column "Cnflict" (colum "J"):
   - "TRUE" indicates there are conflicting ports (ALTxx cells colored in orange) or port(s) that could not be allocated at all (ALTxx cells colored in red). You should re-consider
IOMUX plan if some ports can not be allocated.
   - "FALSE" indicates there is no conflict. Please check ALTxx. If there is cell colored in orange it indicates port that have only single available location in the current IOMUX plan, and
therefore that port should be allocated.
  For pad allocation please select appropriate ALT mode (column "H") and lock pad (change "FREE" to "LOCK") in column "G"
   - column "I" shows function (port) corresponding to the selected ALT mode
   - Allocated ports will be marked in green. If the ALT mode in configured IOMUX is not the same as it is in the default configuration the cell in column H changes its color to bright yellow.
  Re-check conflicts and repeat pad allocation
r
each pad (row) check column "Conflict" (column "J"):
Tags (1)
0 Kudos
15 Replies

1,796 Views
jose
Contributor I

@Alan:

Yap I already have that tool already.

I'll check your blog about porting new h/w in android. Thanks Sir Alan.

0 Kudos

1,796 Views
AlanZhang
Contributor V

The statement "it is for IOMUXC only." is not correct, actually from iomux-mx53.h, we can see that this interface pin declaration contains both IOMUXC and PAD setting.

This blog presents the following points:

1. Define MX53_PAD_xxx to match the interfaces used in your target design, for example, your target design uses eMMc, LVDS, Camera, USB etc;

2. When the linux kernel driver is loaded, its corresponding interface's pins are driven by the internal module, for some extra control pins defined as GPIO but serve for the module, these extra control pins can be defined as device resource data that will be transferred into driver when probe;

3. After driver is loaded, the pins associated with this interface/module can be manipulated by application.

If you want to manipulate GPIO directly from application level, you have to implement the HAL code to wrap these used GPIOs (Because GPIO manipulation is not a standard devices defined in Android framework, not like Camera, GPS, BT etc). Pls check my blog on "Port a new h/w in Android"!

Regards,

Alan Zhang

0 Kudos

1,796 Views
AlanZhang
Contributor V

Hi, Jose,

Pls check http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=IMX53_SW&parentCode=RDIMX53SABRETAB&f... where you can see a hyperlink named "interactive i.MX Pin Mux Tool" under Design Tools.

NOTED: /arch/arm/plat-mxc/include/mach/iomux-mx53.h contains all mux pins' definiton, and bundled PAD control setting.

Regards,

Alan Zhang

Regards,

Alan Zhang

0 Kudos

1,796 Views
jose
Contributor I

Another thing, just need some clarifications.

About the last part" 

==============

/* HDMI reset */
    MX53_PAD_EIM_WAIT__GPIO5_0,
it is for IOMUXC only.

==============

What do you mean by "it is for IOMUXC only."?

This is for the platform side?

So what you have describe here is to setup the platform side so when you program on the user_space the linux API can access those defined pins?

0 Kudos

1,796 Views
jose
Contributor I

By the way just a follow up, where can we get that " IOMUX_plan_calculatorMX53_100517_ext.xls developed by Roman Mostinski"?

FSL has an IOMUX app right? Are they more or less the same in terms of purpose/usage?

0 Kudos

1,796 Views
jose
Contributor I

any updates on this?

@Alan:

Sir could I ask a favor from you? We will greatly appreciate it.

Can you give us a sample module code and expose that to user space (sysfs or devfs) and from there could you also make us a simple user space program that would access this module and let say blink the led.

This would be great and totally will help a lot.

0 Kudos

1,796 Views
MauricioCirelli
Contributor I

Hi Alan,

 

Thanks for your support.

Would you mind provide me some code sample or a quick step-by-step operations I need to perform to get this working?

How do I create this kernel module to access an I/O pin?

How do I create this /proc node to echo/cat and how my kernel module would write information about an I/O pin into this node?

 

Thanks in advance!

0 Kudos

1,796 Views
AlanZhang
Contributor V

Hi, Mauricio,

For GPIO usage from user space (such a simple plain control object), maybe no need to use sysfs node because it involves the platform device & platform driver implementation. So for easy & efficient way, just write a kernel module to use these GPIOs, and maybe create a /proc node to be "echo" & "cat" to write & read for quick debugging purpose.

Regards,

Alan

0 Kudos

1,796 Views
MauricioCirelli
Contributor I

Well, I would like to control some iMX53 I/O pins..

I was trying to follow the instructions you provided and other instructions I've googled, but Im still not able to expose the GPIO sysfs node in my Android BSP.

I can see many other sysfs nodes, but GPIO is not there.

 

Do you know what I need to do to have this GPIO sysfs node enabled/visible in Android 2.2 with Adeneo's BSP?

0 Kudos

1,796 Views
AlanZhang
Contributor V

Hi, Mauricio,

Sorry for late response! I do not know much about NDK. From my understanding, if your h/w (GPIOs direct control) is totally a new type that has not been covered by Android framework layer, so you can directly implement this hardware control from low to upper (Reference to my post on "how to integrate a new hardware type"). At low layer, maybe you could provide the h/w in standard device driver (i.e. devfs node, or just expose sysfs node for read and writing). If your h/w has been projected in Android platform like (GPS, BT etc.), maybe you need to use NDK.

Regards,

Alan

0 Kudos

1,796 Views
MauricioCirelli
Contributor I

Hi Alan,

 

Could you please provide me some steps to get it working on my enviroment?

I will give you some context:

We are working on a i.MX53 project, using Adeneo Android BSP 3.3 and 4.0.

We need to have access to some iMX53 pins (GPIO). We want to use Android NDK to have some C/C++ functions which will do this job and we will access these functions in our application through JNI (Java Native Interface).

Is it enough to import those headers to our Android NDK project and create our functions?

0 Kudos

1,796 Views
AlanZhang
Contributor V

Hi, Mauricio,

To find out each mux pin's mapping definitions (multi-func), you need to check plat-mxc/include/mach/iomux-mx53.h.

B.R.

AZ

0 Kudos

1,796 Views
MauricioCirelli
Contributor I
Where do I find those header files? I would like to use them with the Android BSP!
0 Kudos

1,796 Views
AlanZhang
Contributor V

Hi, Oceanblue! You could download i.MX53 Reference  Manual from Freescale.com site in which the chapter 4 & 43 contain the elaborate descriptions.

B.R.

AZ.

0 Kudos

1,796 Views
Oceanblue
Contributor III

the above explanation is good and plain to usnderstand, does FSL have the related document to introduce it? thanks.

0 Kudos