how to integrate iomux C code in u-boot and linux?

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

how to integrate iomux C code in u-boot and linux?

3,688 Views
jbd64
Contributor III

Hi,

I'm working on a project with imx6Solo custom board. My colleague generates output C code from iomux-tool v3, and now I have to integrate this on u-boot and linux kernel. I've read i.MX_6Solo6DualLite_BSP_Porting_Guide but it doesn't explain integration process of code provided by iomux.

Can you explain me how to integrate iomux C code in u-boot and linux ?

Thanks !


5 Replies

1,040 Views
weidong_sun
NXP TechSupport
NXP TechSupport

Hello,jbd64,

(1)In u-boot:

     you can open u-boot/board/freescale/mx6sl_arm2/mx6sl_arm.c and refer to the iomux usage of those pins.(such as i2c,spi,eMMC pins etc)

(2)In linux kernel:

     you can open linux/arch/arm/mach-mx6/board-mx6sl_common.h and find structure :

static iomux_v3_cfg_t mx6sl_brd_pads[] = {

....

/* all signals used on board are iomuxed here, you can add signal you want here */

....

}

(3)IOMUX definitions for i.mx6SL

open linux/arch/arm/plat-mxc/include/mach/iomux-mx6sl.h, you will find all signals are defined for i.mx6SL. if you use one, you only need to add it to (2)

Regards,

Weidong


1,040 Views
YixingKong
Senior Contributor IV

Weidong, could you finish the customr's questions?

Thanks,

Yixing

0 Kudos

1,040 Views
leoschwab
Contributor III

Bumping this thread.  We will shortly be facing the same issue for an i.MX6DL design.  Our HW designer has set up all the IOMux settings; we simply need a way to translate them to a form compatible with the existing 3.0.35 kernel sources.

0 Kudos

1,040 Views
jbd64
Contributor III

So, I have to begin with imx6Solo_arm2 board and customize it for my custom board ?

I've read that imx6Solo processor is compatible with imx6DualLite but not with imx6SoloLight.

Besides, output generated by iomux tools is like this :

     output

     |__ board

          |__ mx6sdl

               |__ iomux_config.h

               |__ rev__iomux

                    |__ dcic_iomux_config.c

                    |__ ecspi_iomux_config.c

                    |__ eim_iomux_config.c

                    ...

                    |__ usdhc_iomux_config.c

                    |__ wdog_iomux_config.c

     |__ sdk

          |__ include

               |__ mx6sdl

                    |__ registers

                         |__ regs.h

                         |__ regsiomuxc.h

- In output/board/mx6sdl/rev__iomux/*_iomux_config.c files, there is MUX control registers pad's functions definition, and pad characteristics.

- In output/sdk/include/mx6sdl/registers/regsiomuxc.h file, definition of all the PADs (i guess).

- In attachment, a tarball file containing output directory, with all sub-directories and files.

Can you explain me how to integrate these IOMUX code provided by IOMUX TOOLS in u-boot and linux ?

I've already looked at u-boot mx6sl_arm.c file, and linux kernel files.

What I think is that IOMUX TOOLS generates all the PADs definitions in regsiomuxc.h file.

Problem is u-boot and linux already have a file which defines all the PADS : for u-boot : include/asm-arm/arch-mx6/mx6_pins.h ; for linux : arch/arm/plat-mxc/include/mach/iomux-mx6X.h (X denotes SOC type).

So, how can I mix IOMUXTOOLS code with U-boot and Linux code ?

1,040 Views
leoschwab
Contributor III

For what it's worth, I wrote a program to translate the IOMux output into the form used by the Yocto/FSL U-Boot and the 3.0.35 Linux kernel.  The translation is ugly and, in some places, incomplete.  But at least I have something to feed U-Boot now...

EDIT:  *sigh* Never mind.  Linux re-packs the pad control bits so that the whole thing will fit in a uint64_t.

Also:  Neither U-Boot's nor Linux's IOMUX_PAD() macros provide for writing to the Pad Group Control registers.

Also also:  Although the macros are used identically, the IOMUX_PAD() field definitions are different between U-Boot and Linux (Linux sets aside 18 bits; U-Boot uses 19).

Happily, I didn't fry any hardware finding this out.  I have more work to do...

0 Kudos