am335x pinmux.h and mux.h

Adrian Hart

I have generated my pinmux.h and mux.h files using the pinmux utility provided for the am335x . The pinmux utility documentation says to replace the existing mux.h file with the new one and also to comment out contents of the evm.h file and include the pinmux.h file instead.

I have located the evm.h file in: ~/ti-sdk-am335x-evm-05.03.02.00/board-support/u-boot-2011.09-psp04.06.00.03/board/ti/evm

and also the mux.h file in: ~/ti-sdk-am335x-evm-05.03.02.00/board-support/u-boot-2011.09-psp04.06.00.03/include/asm/arch-omap3

The evm.h file bears no resemblence to my new pinmux.h file and the contents don't seem to agree at all with the circuits for the board.

Am I looking in the wrong place - does anyone know anything about this.

Thanks,

over 11 years ago

0 Dan Donahue over 11 years ago

Prodigy 135 points

Hello Adrian,

Did you ever get an answer to your question or figure it out on your own? If so, please post. It would be much appreciated.

Thanks,

Dan

0 Adrian Hart over 11 years ago in reply to Dan Donahue

Prodigy 230 points

Hi,

I didn't get a reply from anyone regarding this not even Ti which I found surprising! What I have done in the end is to modify in the Linux SDK in...

/arch/arm/mach-omap2/mux.h and mux.c so that the settings are applicable to our custom hardware (which we haven't got yet) e.g I've removed the setups that don't apply and added some new ones that do by using the existing code as an example. I then rebuilt the Linux Kernel and downloaded that to the evm 335x board. Once Linux had booted, I then did:

mount -t debugfs debugfs /sys/kernel/debug

cat /sys/kernel/debug/gpio

I could then see the mods that I had made to the gpio settings. Hopefully they will work when our own hardware arrives and I can try it out.

From what I have seen, the pinmux utilty is excellent at allowing you to choose and set up what you want to do but after that is completely useless in as much as

you then can't use the header files that are generated, unless someone knows differently.

Thanks,

Adrian

0 Dan Donahue over 11 years ago in reply to Adrian Hart

Prodigy 135 points

Thanks for the quick reply.

I am in the same boat...waiting for custom hardware to arrive.

Using debugfs for gpio is a good idea. Thanks for sharing it.

I believe the generated headers are useful. Here's what I did (and plan to do) ...

I modified my U-Boot BSP (modeled after the beaglebone) to use the pinmux/mux generated headers instead of the functions in mux.c, which I deprecated because they're no longer needed (same should apply for you).

I plan on using the mux.h generated header as a common file for all BSPs that use the AM335x processor. I then plan to create pinmux.h's for each board type that have different mappings (renaming to pinmux_<myboardname>.h).

In the U-Boot BSP:

The generated MUX_EVM() macro in pinmux.h is all you should need to call to setup all GPIO mappings. The MUX_VAL() macros contained in the MUX_EVM() macro can be used to setup individual functions.

For example, in my early init code I call the MUX_VAL() macros associated with UART0 and I2C. I could choose to do the whole mapping in early init, but at this point I want to walk before I run. Later on, during the board-specific initialization, I call the MUX_EVM(), which sets up the rest of the mappings.

0 Mehmet Riza Oz over 9 years ago in reply to Adrian Hart

Intellectual 400 points

Hi,

I also have to change pin configuration of the am335x starter kit.

processors.wiki.ti.com/.../AM335x_PSP_User%27s_Guide

"Method I - Modify Linux Kernel, rebuilt and use" says "Default mux mode can be changed by adding specific mux entry in the beginning of board_mux array in board-am335xevm.c"

i found defined pin names in arch/arm/mach-omap2/mux33xx.c folder

added AM33XX_MUX(SPI0_D0, OMAP_MUX_MODE6), line beginning of the arch/arm/mach-omap2/board-am335xevm.c file

#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
/*
* Setting SYSBOOT[5] should set xdma_event_intr0 pin to mode 3 thereby
* allowing clkout1 to be available on xdma_event_intr0.
* However, on some boards (like EVM-SK), SYSBOOT[5] isn't properly
* latched.
* To be extra cautious, setup the pin-mux manually.
* If any modules/usecase requries it in different mode, then subsequent
* module init call will change the mux accordingly.
*/
AM33XX_MUX(SPI0_D0, OMAP_MUX_MODE6), //i added this
AM33XX_MUX(XDMA_EVENT_INTR0, OMAP_MUX_MODE3 | AM33XX_PIN_OUTPUT),
AM33XX_MUX(I2C0_SDA, OMAP_MUX_MODE0 | AM33XX_SLEWCTRL_SLOW |
AM33XX_INPUT_EN | AM33XX_PIN_OUTPUT),
AM33XX_MUX(I2C0_SCL, OMAP_MUX_MODE0 | AM33XX_SLEWCTRL_SLOW |
AM33XX_INPUT_EN | AM33XX_PIN_OUTPUT),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};

After boot i could see the change i made from console with following commands.

mkdir -p /debugfs
mount -t debugfs debugfs /debugfs
cd /debugfs/omap_mux/
cat spi0_d0

But i'm now sure if something else must be done too.

Mehmet

0 Mehmet Riza Oz over 9 years ago in reply to Mehmet Riza Oz

Intellectual 400 points

i finally got right solution

adding following line is useful just for the pins that are not initialized in mux.c file (in u-boot) or board-am335xevm.c file (in kernel)

AM33XX_MUX(SPI0_D0, OMAP_MUX_MODE6), //i added this

pin mux inits which are made in board-am335xevm.c kernel file overwrites mux.c u-boot file initializations.

i simplified board-am335xevm.c file for my custom use and deleted all other board options.
i used this file all of my pinmux features and got the right features for my hw.

in the meantime using following command from console will give you all selected pinmux options for your work.

mkdir -p /debugfs
mount -t debugfs debugfs /debugfs
cd /debugfs/omap_mux/
grep "" *

another point you have to be careful is the eeprom codes in board-am335xevm.c kernel file.
kernel decides pinmux options according to eval boards (beagle bone, am335x starter kit etc) by reading an eeprom.
i deleted all unnecessary eeprom reading codes.

regards
mehmet

Processors

Processors forum

am335x pinmux.h and mux.h